権限移譲に取り組んで見えてきた勘所 ~ 前編 ~
メダップで取締役CTOをしている馬場です。
今回の記事では、私が最近特に力を入れて取り組んでいる「権限移譲」をテーマに、立ち上げ期のCTOが開発組織をスケールさせていく初手としてどういった取り組みをしてきたかを書き起こしてみました！
組織をスケールさせていく上で、適切な権限移譲を行っていくことは非常に重要だと思っています。「いま自分が持っているイシューをメンバーにパスしていく」と、テキストでは簡単に書けます。その一方で、いざ権限移譲を行うとなると、思っていた以上に難しいものだなと痛感しております。。。まだまだ答えが見えていない状況ではありますが、現時点で私が考えている権限移譲の勘所をまとめてみます。
(追記)
実際に書いてみると、かなり長文になってしまったのでこのテーマに関しては、前後編に分けてお送りします。
前編では、開発業務の権限移譲を中心にお話します。後編では、開発から一歩踏み出して、開発チームの権限移譲(リードエンジニア/エンジニアリングマネージャーの育成)について書く想定です！
「カタ」を作る
弊社のプロダクト開発では、オーナー制という制度を設けており、バックログアイテムごとに設計 ~ リリースまでを責任を持って推し進める存在(= オーナー)をアサインするようにしています。1年前は、全てのバックログアイテムに対して、私がこのオーナーを持っており開発を行っていました。
1年たった現在では、(オンボーディング中を除く)メンバーがそれぞれオーナーとして開発を推し進めることができる体制になっています。
こうした状況に至るには時間を要しましたが、オーナーを複数立てることができ、私自身が直接マネジメントすることなく、素早くリリースをし続けられる体制を構築できています。
メンバーに対してオーナーという役割を移譲していくために整備したこととしては、大きく2つあります。
開発のカタを作る
メトリクスの計測する
開発のカタを作る
なにか機能を作る際、私たちはバックログアイテムという形でその機能開発を管理するようにしています。
まず、機能の概要・要求・要件をまとめ(ここまではPdMの役割)、その後オーナーが、以下画像の項目を埋めていくことで開発が始められる状態を作っています。この際、オーナーは1人で項目を埋めていくのではなく、「開発キックオフ準備」という形でメンバーを巻き込みながら、どんなタスクがあるのか？をすり合わせしています。
こうしたテンプレートは、「作業の標準化」という思想に基づいて用意しています。
オーナーとして、バックログアイテムを受け持った際に、リリースに向けて何をすればよいのか？が明確であり、初めてのオーナーであってもチャレンジしやすい状況を作る。誰がオーナーをやったとしてもある程度形にできるカタを作っていくことを心がけています。
バックログアイテムをリリースに向けて動かすカタを作れたことで、オーナーをできるメンバーが一気に増えていった印象がありました。
メトリクスの計測する
開発のカタを作ることができれば、リリースまでを進められるようにはなるのですが、ペースメーカーとなる存在が必要になってきます。というのも、どれくらいのスピード感で開発を進めるべきなのか？という目安がないと振り返りもしづらいですし、期待値がマッチしません。
そこで、私たちの開発チームではバックログアイテム1ポイントあたりに目指すべきリードタイムを設けています。
このリードタイム/ポイントを計測することで開発スピードの期待値が自動で調整される仕組みを取り入れています。
オーナーとしては、自分がいま進めようとしている機能をリリースするまでにどれくらいのスピード感で進めるべきかが明確になり、周囲との温度感も擦り合うため、お互いに要求しやすくなる(事に向き合いやすくなる)のではないかと考えています。
開発の守破離
世の中には「守破離」という考え方がありますが、開発のカタを定義することもこの考え方に近いかなと思っています。
各オーナーは、まず開発のカタに沿って、リリースに向けた機能開発を主導します。(「守」)
ある程度オーナーに慣れてきたところで、もっと短いリードタイムで機能を開発するためには？と考え始め、自らの経験や知恵を元に、バックログアイテムの進め方に工夫をしていくようになります。(Ex. 平行して進めることができる開発はないか？ペアで作業したほうが早く進められるのではないか？など。「破」)
更にオーナーを進めていく中で、独自にそのバックログアイテムに関わるメンバーで朝会を開いたり、開発を管理するためにタスクマップという概念を生み出したり(いまでは、必須項目になっています。)とオーナー独自のアイデアを確立させていきます。(「離」)
ここまで来ると完全に権限移譲が完了しています。守破離にもあるように、まずはカタを忠実にこなすようになることでその後の発展につながるので、権限移譲においては、メンバーが守るべきカタを作り出すことが極めて重要だと考えています。
適切なレベル分けと責任(役割)の明確化
権限移譲の段階をレベルで分ける効用
現在の開発チームでは、前述したオーナーまでは誰でもこなすことができるような仕組みを作れている状態です。
そして、既にオーナーをしているメンバーからすると、次のステップを目指したくなるものです。
メダップの開発組織では、権限移譲の段階をレベル分けして明文化しており、メンバーごとに適切な高さの権限移譲を行うように努めています。
段階別にすることで、「まずはレベル1までできるようになろう！」といった具合に目標とする対象が明確になります。
そして何より、段階別にする最大の効用は、権限移譲を行う人が必ずしもそのチームのリーダーでなくても良くなるというポイントです。
既にレベル1に到達しているメンバーがいれば、レベル1への引き上げをそのメンバーが行えるようになります。オーナーの話でいうと、既にオーナーをやっているメンバーからオーナーをやる術を学べば良いですし、レベル2以降についても同様のことがいえます。
各レベルにいるメンバーがそれぞれ2人までそのレベルに引き上げることができれば、組織全体として必然的に権限移譲が促進されることになります。
責任(役割)の明確化
責任を明確にすることは言わずもがなですが、明確化のポイントとしては、図に起こすこともまた重要だと感じています。
開発がどういったサイクルで行われており、その開発サイクルのどの部分に責任があるのか？(上記で添付した画像で言うところの赤い点線で囲まれた箇所)を明示的にすることで、より具体的に自分が何をすべきなのか？キャッチアップしていくべきなのか？のイメージを掴みやすくなります。
どうしても文字だけで書かれていてもイメージを完全にマッチさせることは難しいです。
なるべく権限移譲を行う側/される側で、同じイメージを持つことが権限移譲のポイントだと考えています。
まとめ
今回は、開発組織で権限移譲に取り組んできた中で見えてきた勘所について書き起こしてみました。
守破離の考え方を基としたカタ作り、それぞれのレベル設定 ~ 各レベルのイメージの明確化を徹底して行っていくことでより自走できる開発チームを作ることができると考えています。
そして、冒頭でも触れましたが、より難易度があがるリードエンジニア/エンジニアリングマネージャーの役割をどう移譲していくのか？については、後編としてまとめていきたいと思っています。
(今回の内容に比べてもまだまだ暗中模索といった段階です…)
そもそも、権限移譲を行う目的としては自律駆動な開発組織を作っていくことでスケールできる体制を強化していくためです。いかに開発組織をすけーるさせていくか？といったことに興味をお持ちいただける方はぜひ一度お話しましょう！
(各ポジション採用中です！)