エンジニアリングリーダーのためのアンチパターン（Anti-patterns）

xguru · 2024-07-08T11:23:01+09:00

CTOやエンジニアリングリーダーと会うと、最も頻繁に話題に上るのは「エンジニアリングのスピードを上げろ」というCEOからのプレッシャー営業や採用と違い、エンジニアリングには明確な成果指標がないエンジニアリングリーダーの立場では、CEOに「エンジニアリングは芸術なので成果を予測しにくい」と言うのは難しいエンジニアリングリーダーと経営陣の間で意見が食い違う原因エンジニアリングリーダーは、慣習的なリーダーシップ助言にあまりにも硬直的に従う傾向があるある慣行が有用かそうでないかを一般化してしまうと、組織の状況に合わせた適用が難しくなる状況に応じて慣行に従うか、新しいアプローチを試すかを判断することが、効果的なエンジニアリングリーダーシップの核心 CartaのCTO、Will Larsonがポッドキャストで語った内容を整理した記事エンジニアリングリーダーシップの3つのアンチパターンマイクロマネジメントの回避不完全な指標の測定を避けることリーダーがチームのための傘になること [アンチパターン #1: マイクロマネジメントの回避] 最高のエンジニアリング幹部になるための、3つの矛盾した役割エンジニアリング幹部は、互いに相反する3つの役割を果たさなければならず、優れた幹部はそれらの役割の間を巧みに行き来できる経営陣の一員としての役割: 事業を発展させる方法を模索する時には、エンジニアリング予算の削減など「エンジニアリング全体には悪い」決定を下さなければならないこともある特定のテーマについてエンジニアリングの発言力が弱まる事業部制モデルへ移行することも含まれるエンジニアリングマネージャーとしての役割エンジニアリング組織の運営に必要なポリシーの構造を把握し、効果的な人材リーダーになる方法を模索するエンジニアとしての役割外部のストレス要因にもかかわらず、技術的卓越性とエンジニアリング実行に責任を持つ技術的卓越性に対する基準を高く維持しなければならない多くの幹部は、この3つの役割のうち1つに偏りすぎる傾向があるどの役割を担っていても、もはや役に立たない管理慣行に固執すると、リーダーは失敗する突然チームのマネージャーになると、技術的にはチームが行うあらゆることについて最も多くの文脈を持っている一方で、同時にピープルマネージャーにもなるこの時点で、人は詳細から距離を取れという助言を受け続ける新任のエンジニアリングマネージャーはしばしば「コードから離れろ」と助言される人によっては、こうした助言が役立つこともあると認めているしかし、高度に有能な経営幹部は、自分が運営するドメインについてある程度の詳細な理解を持っている詳細から離れすぎると官僚になるだけであり、多くのエンジニアリングマネージャーが最終的に官僚化してしまう理由でもあるリーダーシップスタイルの育成 Larsonはエンジニアリング幹部に対し、マイクロマネジメントという用語は完全に忘れ、その代わりに選択可能なさまざまなリーダーシップスタイルを育てることに集中すべきだと言う明確な進路がない、あるいは進むべき道について文脈を持つ人たちの意見が激しく対立している場合には、詳細に踏み込み、自ら意思決定することが有効それによって、ビジネスを実際に変えうるレバー、チームが達成すべき成果、それを実現する期間、ユーザーにより良いサービスを提供する方法を理解できる意思決定へのより強い確信を育てることは、一生を通じて練習すべきことであり、Larson自身もなお取り組んでいる「私たちは何をしているのか？なぜそうしているのか？データは何か？実際のデータソースはどこか？」のような問いを毎月または四半期ごとに投げかけることが、詳細により深く踏み込む助けになる詳細に近づくための2つの戦術「対立の採掘」で文脈を把握する新しい環境では、小さな文脈の違いを見落とすだけでも運営の成功を損なう可能性がある反対の視点を持つ人たちと対話し、「対立の種」を見つけ出すプロセスは、時間がかかっても重要成功するリーダーは「組織に合わせるために自分はどう変わるべきか？」と問うのであって、「自分のやり方に合わせるために組織をどう変えるべきか？」とは問わない詳細を文書化する戦略は至る所にあるが、ほとんど文書化されていない重要な意思決定の根拠が文書化されていないことが多い文書化の文化を築くことが、素早く動くエンジニアリング組織の鍵新しいリーダーは、戦略を自分で作る前に既存のあらゆるものを調査し、他社の成功事例をベンチマークにすべき戦略文書の作成にはRichard Rumeltの「良い戦略、悪い戦略」フレームワークの活用を推奨戦略をどれほどひどく書いたとしても、とにかく文書化するだけで一夜にして戦略が改善することがある [アンチパターン #2: 不完全な指標の測定を避けること] 測定にはアンチパターンが蔓延している理想的には純粋に「それは測定すべきではない」と言えるかもしれないが、そうすると周囲の組織の学習を遅らせるだけになるエンジニアリング幹部が最も価値を生み出せる仕事は、他の幹部に対して工学がどのように機能するかを教育することメンタルモデルの改善に焦点を当てる指標には現実を映してほしいが、指標は真実を示すだけでなく、人を教育するものでもある自分のメンタルモデルが傷つくことよりも、取締役会やCEOのメンタルモデルを啓発することを気にかけるべき CEOを詳細へ引き込む「これはひどい測定方法だ」と言う代わりに、「ここから始めて、このように測ることの限界を理解するまで掘り下げてみよう」と言うべき人を無理やり詳細から遠ざけるのは決して良いやり方ではない。詳細へ引き込み、そこで教育すべき [アンチパターン #3: チームのための傘になること] 以前は、チームを守るためにマネージャーが「傘」のように振る舞うべきだと信じていたしかし、チームを現実から守ることは、長期的にはチームに害を与えるマネージャーとエンジニアの両方が、重要な対話に参加できるようにすべき戦略的意思決定には新しい視点が必要 Bottom-Up戦略長所: チームが素早く動き、ツールをコントロールできるようにする短所: 集中的な技術投資ができず、情報を少し遅れて知ることになる Top-Down戦略短所: CTOやアーキテクチャグループがすべての決定を下すのは非効率委員会が最善の決定を下すことはほとんどない「ナビゲーター」を活用して意思決定を加速する事業ユニットごとに「ミニCTO」の役割を担う「ナビゲーター」を置き、意思決定の速度を高める現場で最も多くの文脈を持つ人が、最も適切な技術スタックの決定を下せるようにする成功のための教訓: 文書化を欠かさないこと事後レビューを行うこと信頼を置く人の選定には極めて慎重であること組織とは少数の個人の判断力の蓄積であり、そこから逃れることはできないまとめルールを厳格に守りすぎることの危険性会社とともにエンジニアリングチームが成長し始めるとき、リーダーは、以前多くの善意ある幹部を窮地に追い込んだものを忘れてはならない究極の目標は、人々が好奇心を持って例外を探すための、高品質な仕組みを作ること学習サークル（Learning Circle） Larsonは過去3年半にわたり、2週間に一度「学習サークル」を開催してきた 6〜10人のCTO、VP of Engineering、またはテック企業のその他の上級エンジニアリング幹部が集まり、近況を共有し、戦術やプロセスの課題を交換する各会議は、1人1分ずつ順番に、今週集中していることと話したいテーマを述べることから始まる約5分間テーマについて話した後、グループで1つを選び、その後20分ほどそれを深く掘り下げるテーマは「このプロジェクトのせいで困っている」から「本当に素晴らしい人を新たに採用できて期待している」までさまざま実践による学習実践を通じて学ぶ人は、学習サークルや個人的な内省のような日常的な振り返りに頼ることで、ルールを繊細に調整するために必要な自己省察を自らに促すことができる Larsonは「私は、自分と似た失敗をした他の人たちの教訓から学び、より良いリーダーになった」と語る

(review.firstround.com)

53 ポイント投稿者 xguru 2024-07-08 | 9件のコメント | WhatsAppで共有

CTOやエンジニアリングリーダーと会うと、最も頻繁に話題に上るのは「エンジニアリングのスピードを上げろ」というCEOからのプレッシャー
営業や採用と違い、エンジニアリングには明確な成果指標がない
エンジニアリングリーダーの立場では、CEOに「エンジニアリングは芸術なので成果を予測しにくい」と言うのは難しい
エンジニアリングリーダーと経営陣の間で意見が食い違う原因
- エンジニアリングリーダーは、慣習的なリーダーシップ助言にあまりにも硬直的に従う傾向がある
- ある慣行が有用かそうでないかを一般化してしまうと、組織の状況に合わせた適用が難しくなる
- 状況に応じて慣行に従うか、新しいアプローチを試すかを判断することが、効果的なエンジニアリングリーダーシップの核心
CartaのCTO、Will Larsonがポッドキャストで語った内容を整理した記事

エンジニアリングリーダーシップの3つのアンチパターン

マイクロマネジメントの回避
不完全な指標の測定を避けること
リーダーがチームのための傘になること

[アンチパターン #1: マイクロマネジメントの回避]

最高のエンジニアリング幹部になるための、3つの矛盾した役割

エンジニアリング幹部は、互いに相反する3つの役割を果たさなければならず、優れた幹部はそれらの役割の間を巧みに行き来できる
- 経営陣の一員としての役割: 事業を発展させる方法を模索する
  - 時には、エンジニアリング予算の削減など「エンジニアリング全体には悪い」決定を下さなければならないこともある
  - 特定のテーマについてエンジニアリングの発言力が弱まる事業部制モデルへ移行することも含まれる
- エンジニアリングマネージャーとしての役割
  - エンジニアリング組織の運営に必要なポリシーの構造を把握し、効果的な人材リーダーになる方法を模索する
- エンジニアとしての役割
  - 外部のストレス要因にもかかわらず、技術的卓越性とエンジニアリング実行に責任を持つ
  - 技術的卓越性に対する基準を高く維持しなければならない
多くの幹部は、この3つの役割のうち1つに偏りすぎる傾向がある
どの役割を担っていても、もはや役に立たない管理慣行に固執すると、リーダーは失敗する
突然チームのマネージャーになると、技術的にはチームが行うあらゆることについて最も多くの文脈を持っている一方で、同時にピープルマネージャーにもなる
この時点で、人は詳細から距離を取れという助言を受け続ける
新任のエンジニアリングマネージャーはしばしば「コードから離れろ」と助言される
人によっては、こうした助言が役立つこともあると認めている
しかし、高度に有能な経営幹部は、自分が運営するドメインについてある程度の詳細な理解を持っている
詳細から離れすぎると官僚になるだけであり、多くのエンジニアリングマネージャーが最終的に官僚化してしまう理由でもある

リーダーシップスタイルの育成

Larsonはエンジニアリング幹部に対し、マイクロマネジメントという用語は完全に忘れ、その代わりに選択可能なさまざまなリーダーシップスタイルを育てることに集中すべきだと言う
明確な進路がない、あるいは進むべき道について文脈を持つ人たちの意見が激しく対立している場合には、詳細に踏み込み、自ら意思決定することが有効
それによって、ビジネスを実際に変えうるレバー、チームが達成すべき成果、それを実現する期間、ユーザーにより良いサービスを提供する方法を理解できる
意思決定へのより強い確信を育てることは、一生を通じて練習すべきことであり、Larson自身もなお取り組んでいる
「私たちは何をしているのか？なぜそうしているのか？データは何か？実際のデータソースはどこか？」のような問いを毎月または四半期ごとに投げかけることが、詳細により深く踏み込む助けになる

詳細に近づくための2つの戦術

「対立の採掘」で文脈を把握する
- 新しい環境では、小さな文脈の違いを見落とすだけでも運営の成功を損なう可能性がある
- 反対の視点を持つ人たちと対話し、「対立の種」を見つけ出すプロセスは、時間がかかっても重要
- 成功するリーダーは「組織に合わせるために自分はどう変わるべきか？」と問うのであって、「自分のやり方に合わせるために組織をどう変えるべきか？」とは問わない
詳細を文書化する
- 戦略は至る所にあるが、ほとんど文書化されていない
- 重要な意思決定の根拠が文書化されていないことが多い
- 文書化の文化を築くことが、素早く動くエンジニアリング組織の鍵
- 新しいリーダーは、戦略を自分で作る前に既存のあらゆるものを調査し、他社の成功事例をベンチマークにすべき
- 戦略文書の作成にはRichard Rumeltの「良い戦略、悪い戦略」フレームワークの活用を推奨
- 戦略をどれほどひどく書いたとしても、とにかく文書化するだけで一夜にして戦略が改善することがある

[アンチパターン #2: 不完全な指標の測定を避けること]

測定にはアンチパターンが蔓延している
理想的には純粋に「それは測定すべきではない」と言えるかもしれないが、そうすると周囲の組織の学習を遅らせるだけになる
エンジニアリング幹部が最も価値を生み出せる仕事は、他の幹部に対して工学がどのように機能するかを教育すること

メンタルモデルの改善に焦点を当てる

指標には現実を映してほしいが、指標は真実を示すだけでなく、人を教育するものでもある
自分のメンタルモデルが傷つくことよりも、取締役会やCEOのメンタルモデルを啓発することを気にかけるべき

CEOを詳細へ引き込む

「これはひどい測定方法だ」と言う代わりに、「ここから始めて、このように測ることの限界を理解するまで掘り下げてみよう」と言うべき
人を無理やり詳細から遠ざけるのは決して良いやり方ではない。詳細へ引き込み、そこで教育すべき

[アンチパターン #3: チームのための傘になること]

以前は、チームを守るためにマネージャーが「傘」のように振る舞うべきだと信じていた
しかし、チームを現実から守ることは、長期的にはチームに害を与える
マネージャーとエンジニアの両方が、重要な対話に参加できるようにすべき

戦略的意思決定には新しい視点が必要

Bottom-Up戦略
- 長所: チームが素早く動き、ツールをコントロールできるようにする
- 短所: 集中的な技術投資ができず、情報を少し遅れて知ることになる
Top-Down戦略
- 短所: CTOやアーキテクチャグループがすべての決定を下すのは非効率
- 委員会が最善の決定を下すことはほとんどない

「ナビゲーター」を活用して意思決定を加速する

事業ユニットごとに「ミニCTO」の役割を担う「ナビゲーター」を置き、意思決定の速度を高める
現場で最も多くの文脈を持つ人が、最も適切な技術スタックの決定を下せるようにする
成功のための教訓:
1. 文書化を欠かさないこと
2. 事後レビューを行うこと
3. 信頼を置く人の選定には極めて慎重であること
組織とは少数の個人の判断力の蓄積であり、そこから逃れることはできない

まとめ

ルールを厳格に守りすぎることの危険性
- 会社とともにエンジニアリングチームが成長し始めるとき、リーダーは、以前多くの善意ある幹部を窮地に追い込んだものを忘れてはならない
- 究極の目標は、人々が好奇心を持って例外を探すための、高品質な仕組みを作ること
学習サークル（Learning Circle）
- Larsonは過去3年半にわたり、2週間に一度「学習サークル」を開催してきた
  - 6〜10人のCTO、VP of Engineering、またはテック企業のその他の上級エンジニアリング幹部が集まり、近況を共有し、戦術やプロセスの課題を交換する
  - 各会議は、1人1分ずつ順番に、今週集中していることと話したいテーマを述べることから始まる
  - 約5分間テーマについて話した後、グループで1つを選び、その後20分ほどそれを深く掘り下げる
  - テーマは「このプロジェクトのせいで困っている」から「本当に素晴らしい人を新たに採用できて期待している」までさまざま
実践による学習
- 実践を通じて学ぶ人は、学習サークルや個人的な内省のような日常的な振り返りに頼ることで、ルールを繊細に調整するために必要な自己省察を自らに促すことができる
- Larsonは「私は、自分と似た失敗をした他の人たちの教訓から学び、より良いリーダーになった」と語る

9件のコメント

geniuskey 2024-07-09

最後の「Larsonは『私は…より良いリーダーになった』と語っている。」という部分は、少し気恥ずかしいですね。むしろ「リーダーは…するために継続的に努力しなければならない。私もまだ至らない点があり、より良くなるために努力している最中だ」といった表現のほうが、もう少し読みやすかった気がします。あまりにも韓国的な視点でしょうか？ ^^;;

savvykang 2024-07-10

韓国的な観点かと尋ねているあたり、よくご存じのようですね。私には話し手がナルシシズムを見せているようには見えないので、このような反応は少し意外です。

tofumaker 2024-07-10

文章の本質や内容ではなく話し手の態度に注目するのは、いかにも韓国的ですね

2024-07-08

[このコメントは非表示になっています。]

savvykang 2024-07-08

『アンチパターン #1: マイクロマネジメント回避』なのにマイクロマネジメントを忘れろというのは、内容の展開がおかしいですね

frog08 2024-07-08

マイクロマネジメントを悪いもの、してはいけないものと見なして無条件に避けることこそがアンチパターンだ、ということです。マイクロマネジメントかどうかを判断するのではなく、必要に応じて細部をきちんと見るべきだ、という話です。