権限移譲に取り組んで見えてきた勘所 ~ 後編 ~
メダップで取締役CTOをしている馬場です。
今回の記事は、前回(権限移譲に取り組んで見えてきた勘所 ~ 前編 ~)の続編です。引き続き「権限移譲」をテーマに、立ち上げ期のCTOが開発組織をスケールさせていく初手としてどういった取り組みをしてきたかを書いていこうと思います。
前回は、開発業務の権限移譲を中心にまとめていきました。今回は、開発から一歩踏み出して、開発チームの権限移譲(リードエンジニア/エンジニアリングマネージャーの育成)を中心にお話できればと思っています。
どういった人物を権限移譲の対象とするのか？
チーム全体をリードしていく存在となると、これまでの開発業務の権限移譲とは数段考えるべきことが変わってきます。
開発業務の移譲との差分で見たときに、特に重要なテーマが誰に権限移譲をするのか？ということです。
権限移譲の対象とするかどうかを判断する際に私が扱う変数としては、大きく2つあります。
価値観/文化のベクトルがあっているか？
問題解決の範囲がチーム・組織になっているか？
価値観/文化のベクトルがあっているか？
極端な表現かもしれませんが、権限移譲をした人物を中心にチームを作り上げていくことになるので、その方の価値観/文化がそのままチームの文化として浸透していきます。
そのため、移譲対象としている方の価値観/文化が会社として想定しているチームの価値観/文化と重なり合うか？を考えることが、非常に重要です。
ここでポイントとなってくるのが、必ずしもチームで一番技術に詳しい・開発ができる(何を持って…というのがありますが…w)方が、移譲対象になるわけではないということです。
やはり重要となるのは、組織として大切にしたい価値観/文化を体現できているか？その考え方をチームに波及できるかどうか？だと思っています。
そしてこれらはチーム内での相対的な評価として決まるものではなく、あくまで基準を設けて絶対評価で行うべきだと考えています。
特に弊社では、セールス, マーケ, CS, 開発, デザイン, コーポレート, … とそれぞれ役割は置いているものの、組織一丸となってVisionに向かって進むことを最も重要視しています。そうした中で組織として掲げている価値観(バリュー)や組織に根付いた文化(カルチャー)と逆方向のベクトルのチームができてしまうと組織全体として機能しなくなってしまうと考えています。
問題解決の範囲がチーム・組織になっているか？
「視座」の言語化を非常に端的にまとめてくれているこちらの記事を参考にしつつ、思考を整理した背景があります。
チームの権限移譲を行うかどうかを判断する際には、どのレベルの課題に対してどういった行動を取ることができるのか？を整理することが多いです。
私の場合、チーム・組織レベルの課題に対して、問題解決に向けて実行ができる(ポテンシャルがある)方を権限移譲の対象として考えるようにしていますし、チームのマネジメントについて興味を持っている方に対しては、こうした領域へのチャレンジを促す/サポートするように心がけています。
(自分の好き嫌いで課題を捉えるだとか、クローズドな境界を作ってしまう/行動を取ってしまう状態ではまだまだ埒外です。)
また私の場合は、課題の範囲を考える際に考慮していることとして、「時間軸」も変数に入れるようにしています。どの時点でのチームのあるべき姿を考え、実行に移せるのか？といったイメージです。
こうした考え方を100%実行できていることを求めるわけではないですが(私自身もまだまだ。。。)
そういう思考にチャレンジしている状態であることは必要不可欠であると考えています！
権限移譲に向けた動き
実際に前述の内容を満たした方に対して、いかに権限移譲を行っていくか？というところですが、いまのところ結構時間をかけつつじっくりコトコトやっています。w
じっくりコトコトの具体としては、週次でお互いの思考を同期させることで、チームに対する考え方をすり合わせる場を作っています。
具体的には、思考を同期させるタイミングで大切にしていることは以下2つです。
信頼し、How を任せる
目的の手段化
信頼し、How を任せる
基本的に権限移譲を行う方に対しては、絶大な信頼を置いています。(言うまでもがなですが、メンバー全員を信頼してますw)
その前提で、実際に目標に対してどのように登っていくのか？というところは全ておまかせしています。これは、何もノータッチというわけではなくお手伝いできることがあれば、私自身が最高のフォロワーになれるように努めるのですが、計画から実行・振り返りまで、基本的には全ての意思決定を委ねています。そのため、思考を同期させるタイミングであってもプロジェクトや課題の整理を行うのみで、あとは全力でサポートするよ！と背中を押すのみですw
ただただ移譲対象の方が優秀という話かもしれませんが、この方法でプロジェクト・チームが間違った方向にいったことは一度もありません。
実際にチームをまとめて何かを達成してもらうことで一定の自信にもつながると思いますし、チームメンバーからの信頼も一段と高まります。
目的の手段化
思考を同期させるタイミングで、何か課題をぶつけてきてくれた場合や施策に対するレビューを求められた際には、必ずその課題・施策の上位にあるものはなにか？を質問するようにしています。
これを「目的の手段化」と呼ぶようにしているのですが、いま思考してくれているものの一段上に何があるのか？と視座を広げていただくきっかけになればいいなと考えています。毎週のように繰り返して行っていくことで、必然的にこちらから何かを言うまでもなく、目的を手段に落とし、上位の目的を思考するクセが身につきます。
まとめ
なかなかまとめるのが大変な内容で上手く書けたかはやや不安なのですが、開発チーム自体を移譲する際の勘所について書いてみました。
権限対象とする人物は、チーム内での相対的な評価ではなく、価値観/文化・視座という項目で明確に基準を設けること。そして、ウェットなコミュニケーションを通じて、思考のすり合わせを行うこと。何よりも大前提として相手を信頼すること
この辺りが、私が考えているチームを移譲する際の重要な要素です。
ここについては、私自身まだまだ暗中模索といった段階なので、ぜひ他の方と話してみたいですww
Meetyもやっているのでぜひこの辺りお話しましょう〜！！
前回の書いたことなのですが、そもそも、権限移譲を行う目的としては自律駆動な開発組織を作っていくことでスケールできる体制を強化していくためです。いかに開発組織をスケールさせていくか？といったことに興味をお持ちいただける方はぜひ一度お話しましょう！
(各ポジション採用中です！)