Googleが2008年に始めた「Project Oxygen」という研究がある。
きっかけはある仮説の検証だった。
「マネージャーは実際には重要ではないのではないか」という仮説だ。
20年にわたる研究の結論は正反対だった。
高い効果を発揮するマネージャーを持つチームは、より良い結果を達成し、より幸せで、離職率が低い。
マネージャーは極めて重要な存在だった。
では何をすればいいのか。
研究データと自分の経験を組み合わせて、開発チームのマネージャーが取るべき行動を整理してみる。
目次
チームに目標を定義し自律的に動ける権限を与える
チームにはたくさんの人がいて、人の数だけ視点と得意領域がある。
それらを活かすためには、チームに方向性を示す目標の定義と自律的に動ける権限が必要だ。
自分の経験のなかでも、動きやすく、楽しく、良いものを作れる開発チームは非常に良い体験だったし成果も一定のものが出せていたと思う。
チームが自律的に動くには、「何を目指すか」が明確であることと、「どう動くかを自分たちで決められる」権限の両方が必要だ。
目標があいまいなまま権限だけ渡しても機能しないし、目標が明確でも細部まで指示し続ければ同じことになる。
具体的に何が問題かという話でいくと、マイクロマネジメントに行き着く。
Project Oxygenが特定した優れたマネージャーの10の行動特性のうち、2番目に「チームをエンパワーし、マイクロマネジメントをしない」が挙げられている。
マイクロマネジメントが何をもたらすかは、94本の論文を対象にした体系的な文献レビューでもまとめられている。
職務ストレスの増加、心理的安全性の低下、創造性の低下、最終的には離職率の上昇。
どれも直感と一致する話だと思う。
一方で、マイクロマネジメントが短期的に有効な場面はある。
未経験者やそのタスクへの新規参入者には、一時的に細かい指示が助けになることもある。
問題はそれが常態化することだ。
同記事では、Googleのソフトウェアエンジニアリングマネージャーの言葉が引用されている。
エンジニアは技術面でマイクロマネジメントされることを嫌いますが、キャリア面で密接に管理されることを好みます。
技術的な判断はチームに任せて、キャリアや成長の方向性には丁寧に関与する。
この非対称さが大事なんだと思う。
目標の定義とそこへの道筋はマネージャーが責任を持って示しつつ、実現の方法はチームに委ねる。
それがこの指針の実態だと思っている。
コーチであること
Project Oxygenの10特性のうち、筆頭に挙げられているのが「優れたコーチである」だ。
コーチングとティーチングは別物で、ティーチングは答えを渡すことで、コーチングは相手が自ら答えを見つけられるように問いかけることだと思っている。
1on1で「どうすればいいか」を言い続けるマネージャーは、チームを依存させてしまう。
「どう思う？」「何が障害になってると思う？」と問い返す習慣が、メンバーの自律的な思考力を育てる。
Googleがマネージャー向けに提供しているAIプロンプト例が参考になる。
「課題に直面しているチームメンバーが自分自身の解決策を特定するのを助けるための、3つの効果的なオープンエンドのコーチング質問は何ですか？」
答えを渡す前に、まず「あなたはどう考えているか」を聞く。
それだけで1on1の質はかなり変わる。
フロー状態を守る
エンジニアにとって集中状態（フロー）がいかに大切かは感覚的に理解している人が多いと思う。
ソフトウェアエンジニアリング活動中の中断に関する研究によると、Slackメッセージや急ぎの通知のような高支配度のオンスクリーン中断は、コード理解タスクにかかる時間を有意に増加させる。
文脈を積み上げていたところに割り込みが入ると、また最初から積み上げ直しになる。
さらに面白いのは、生理学的なストレス指標と主観的な感覚の乖離だ。
対面での中断は生理学的にはストレスを低下させていたにもかかわらず、参加者はより高いストレスを報告した。
つまり中断そのものを「邪魔された」という感覚で受け取っていて、仮に雑談でリラックスできていたとしても「集中を切られた感」は残る。
このあたりはオライリーも触れていて、エンジニアのための時間管理術 という書籍でも「割り込み」についてかなりの文量を持って語られている。
急ぎでない質問は非同期にする。
コア集中時間帯を設定して、チーム全体でそれを守る文化を作る。
マネージャー自身がその文化の最初の実践者になる必要がある。
個人ではなくチームを測定する
何を測定するかで組織の文化が変わる。
コード行数、1日あたりのコミット数、こなしたチケット数。
これで個人をランク付けすれば、チームはたちまち競合関係になる。
Project Aristotleでは、チームメンバーの個人パフォーマンスとチームの効果性は有意に関連しないことが示されている。
チームとして「どのように協力するか」が「誰がいるか」より重要と述べられている。
代わりに使いたいのが、DORA（DevOps Research and Assessment）が特定したFour Key Metricsだ。
デプロイ頻度・変更リードタイム・変更失敗率・サービス復旧時間の4つで、これらはチーム全体のデリバリーパフォーマンスを測る指標なので個人攻撃のツールになりにくい。
構造的なボトルネックを見つけるためのものとして機能する。
この指標でエリートパフォーマーとされた企業は「チームを働くのに最適な場所として推薦する可能性が1.8倍高い」というデータも出ていて、開発者体験との相関も高い。
チームの心理的安全性をつくる
ここまでの話はどれも、チームが連携できていることを前提にしている。
でも、そもそもメンバーが互いのことをよく知らなかったり、意見を出しづらい雰囲気があったりすると、権限を渡されても動きにくいし、測定結果を見ても議論が生まれない。
心理的安全性はいきなり生まれるものではなく、積み重ねで生まれるものだと思っている。
自分が効果を感じたのは、週30分でも「作業と直接関係ない話をする時間」を意図的に設けることだ。
雑談でも近況共有でも何でもいい。
互いの人となりが少しわかるだけで、Slackでの一言の受け取り方がずいぶん変わる。
もう1つ有効だと思っているのが、メンバーそれぞれの得意領域を可視化することだ。
誰が何に詳しいかがわかっていると、「この判断はあの人に相談しよう」が自然に起きるようになる。
相談が増えると連携が増えて、連携が増えると互いへの信頼が育つ。
マネージャーがこれをやるべき理由は、自然発生を待っていると手遅れになりやすいからだ。
時間を確保して、仕組みをつくって、まず自分がオープンに振る舞う。
その繰り返しで土台ができていく、という感覚がある。
今の自分の中では、「チームが自律的に動ける状態をつくる人」
Googleは研究の結果として、マネージャーの責任を3つに整理している。
結果を出す、人材を育成する、コミュニティを構築する。
「結果を出す」が最初に来ているが、「人材を育成する」と「コミュニティを構築する」なしに持続的な結果は出ない。
この3つは並列というより相互に支え合っている。
リーダーシップを「判断と決断を一手に担って指示し続けること」と捉えている人は多いが、僕はそれだけだと組織はうまくいかないと思っている（そうして死にかけた話が書籍「LEADER’S LANGUAGE」の書き出しにある）。
自分がここ1年で行き着いているのは、チームが自律的に動ける状態をつくるのがリーダーの仕事だという像だ。
技術判断を任せる、フローを守る、チームで測定する、コーチングする。
どれも「チームが自分で考えて動ける」ための条件づくりだと思う。
変えたいものがあるときは批判の前に「なぜそうなっているか」を理解しようとすること、「自分の判断には盲点があるかもしれない」という感覚を持ち続けること。
この姿勢もまた、チームが動きやすい状態をつくるための前提になっている。
書いてみて気づくのは、たどり着いた結論がよく記事や本で見る一般的なことばかりだということ。
調べれば出てくるし、言われてみれば当たり前とも思える。
ただ、研究データを漁ったり自分の経験と照らしたりしながら自分の言葉にしていく過程は、「知っている」と「腑に落ちている」の間にある距離を埋めてくれる気がしている。
今の自分が言語化するとしたらこうだった、という記録として残す。