感想: エンジニアリング統括責任者の手引き

CTOは技術の方向性を決める人に対し、VPoEはその方向性を実現するための組織を整える人、という違いがあるらしい。とすると、「エンジニアリング統括責任者の手引き」でいうところの「エンジニアリング統括責任者」とは、VPoEのイメージの方が近い。本書は「経営陣とどう協業するか」だったり、全社戦略ではなくエンジニアリング戦略にフォーカスするなど、経営視点というより組織設計や技術文化形成について語られることが多かった。とはいえ、「財務諸表を読め」「枯れた技術を採用せよ」なども、エンジニアリング統括責任者に求められている。

訳者も原題の Engineering Executive の訳には悩んだらしい（あとがきより）。

エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ Will Larson

以下、個人的に面白かったポイントをメモ

目標と計画

• 新任のエンジニアリング統括責任者は、優先順位や目標を手にするとすぐに変更を行いたがる。しかし、真に優れたエンジニア統括責任者になるには、システムを変更する前に、まず関連する組織やシステムの仕組みをよく理解しなければらならない。

誰も十分なコンテキストや視点を持ち合わせておらず、代わりに解決してくれる者もいないような複雑な問題に圧倒されたとき、唯一の解決策は、立ち止まって考える余地を作り出すことだ。問題が極めて複雑な場合は特に、学びはふりかえりを通じて得ることになる†6。

2章 最初の90日間

• 戦略とは、診断、基本方針（アプローチ）、一貫した行動の3つから構成される。エンジニアリング戦略の策定は、まずデザイン文書を書くのが最も優れた方法だ。このアプローチで、合意形成するために十分に文書化された前例を収集できる。
• ほとんどの企業が全社戦略を文書化していない。一方で文書化されてなくても、戦略かそれに類するものは確かに存在する。まずは現状の良い戦略をモデル化する。非エンジニアリングは同格の統括責任者と確認しながら非公式の文書化をお勧めする。
• 戦略はトップダウンでしか採用できない。トップダウンのリーダーシップだけが、効果的な戦略に必要な施策を取れる。

• 戦略の核心は、機能するものを標準化すること、優れた技術を探索・支援すること、このトレードオフとタイミング
• 標準化と探索はしばしば対立する。探索は桁違いの改善がもたらされるようにする、というのが著者の持論

私は、「標準化か、それとも探索か」という戦略の議論を何度か繰り返してきたが、実際に何が効果的かについて、私がこれまでに見つけた中で最も明確な方針はこうだ。ほぼすべてを標準化し、探索では桁違いの改善がもたらされるようにし、同時並行的な探索を制限する。

付録E 探索の重大さ

• 計画はのダイナミズムを通じで会社を導く。以下の3つの基本フェーズがある。
  1. 年間財務計画の記載内容に従って、事業領域ごとのリソース配分を設定する
  2. エンジニアリング戦略におけるリソース配分を見直す
  3. 最も密接な部門パートナーと提携し、四半期または半期のロードマップを確立する

バリュー

• バリューは、すでに進行中の変化を後押しし、それを永続的なものにするのに役立つ。文化改革を開始するための手段ではない。
• 効果的なバリューの条件は、リバーシブルで、適用可能で、正直であること。

このリバーリスブルというのが分かりにくいが、非常に重要な視点だと思った。本書では、リバーシブルなバリューの例として、Y Combinatorの「Do Things That Don’t Scale」を挙げる。この逆である「スケールを目指す」も成り立ち、かつそれをしないことを明確にしている。作業の適切な規模や優先順を決めるコンテキストを提供するバリューが良い。

バリューがリバーシブルであることは、次の2つの条件の前提でもあるが、それ自体も意味を持つ。効果的なバリューは行動を導く。そして、行動を導くとは、複数の実行可能なアプローチのどれかを選ぶということを指している。リバーシブルでないバリューは、積極的な参加ではなく、口先だけの合意を招く。

5章 効果的なバリューを作る

リーダーシップ

• 統括責任者は複数のリーダーシップスタイル、ポリシーで導く、コンセンサスで導く、信念で導く、の3つのポリシーを使い分けることが必要である。あまり頻繁に使わないリーダーシップスタイルに慣れるために、問題をリストアップし、苦手なスタイルで解決する問題を特定し、思考実験する訓練を行うことをお勧めしている。
• 会社、チーム、自分自身、という意思決定における優先順位決めフレームワークが使いやすい。一方で、常に会社のニーズを優先することは文字通りの解決策にすぎず、個人の活力を奪う可能性がある。

会社とチームを最優先にするという私がしたような、概念的には正しい優先順位付けモデルであっても、それに厳格に従うと、優先順位は正しくても、前進するためのエネルギーが足りないチームになってしまうことがよくある。 … リーダーシップとは、正しい場所に素早く到達することであり、必ずしも最も直線的な道を歩むことではない。無秩序な道を楽しそうに歩く方が、最も安全な道を意図的に歩くよりも速いことがよくあるのだ。

9章 優先順位とエネルギーの管理

• 統括責任者である自分が支持されているか、容認されているか、それとも嫌われているかを理解し、暗黙のパワーダイナミクスを舵取りする。CEOなどの経営陣の視点に耳を傾けつつ、チームとも直接話をする。このパワーダイナミクスの影響を過小評価してはいけない。

優秀な統括責任者は、これらの食い違っている懸念事項の原因を突き止め、1つの首尾一貫した視点へと統合していく。一方で優秀でない統括責任者は、1つか2つの視点に固執して、残りを切り捨ててしまう。

13章 CEO、統括責任者陣、エンジニアリング組織との協働

• 対立は本質的にネガティブなものではないが、未解決の繰り返し起こる対立は避けたい。
• 著者が見てきた、競争の一般的な原因は、機会の欠如の認識、縮小傾向にある企業や官僚的な企業で身についた悪習の持ち込み、リーダーにより自チームの調停不足、の3つ。特に「機会の欠如」がよく見られる。

幹部層の中に個人的な成長の余地を使い果たしたと考えているメンバーがいた場合、彼らは自分たちのために機会を作る方法を探すだろう。それはしばしば他の幹部との競争を引き起こす。ごく少数のメンバーしか挑戦的な任務を引き受けられないのは間違いないからだ。

14章 エンジニアリング組織の幹部層を団結させる

働き過ぎは興味深い悪習だ。なぜなら、それは社会的に容認され、一部の人々からは並外れた成功を収めるための必要条件とみなされているからだ。… 私がこれまで見てきた中で、最も統括責任者のキャリアに悪影響を与える「社会的に許容されている悪習」は、所属する組織がよしとするよりも高い基準を周囲に求めることだ。

18章 基準の調整

採用と育成

• エンジニアリングの評価・育成プロセスには正しいパターンは存在しない。現在の制約に最も適したパターンがあるだけ。
• 中央集権的な人事組織が会社規模のプロセスを運営し、エンジニアリングマネージャーがエンジニアリング範囲のプロセスを運営するという、著者が「ベースライン」パターンと呼ぶものが、実際にうまくいくことが多い。より機能させるために、以下の点に注力する。
  1. 仕事のローテーション
  2. 運営する人々自身が興味を持つプロセス
  3. 昇進で評価する ¹
• 採用プロセスは完璧さより効果的なものを設計する。採用プロセスはすぐに煩雑化し運用できなくなる。特殊化、カスタマイズ、オーダーメイドには用心する。
• エンジニアリングのオンボーディングプログラムはエンジニアが設計する。オンボーディングのエグゼクティブスポンサーとして、オーケストレーターの選任やモニタリングの指示を行い、プログラムに貢献したメンバーは評価に含める

企業文化

企業内のインクルーシブに関連するアンケート＝企業文化診断データを活用すべし²。ただ情報を眺めるだけでなく、診断結果に基づいて行動を起こすべし

企業文化診断データを活用することについて掘り下げた。多くのリーダーは評価が得にくいという理由で、このデータに取り組むことを避けるが、組織のより良いリーダーになるために、これほど貴重な情報源はない。

23章 企業文化診断データの活用