エンジニアリング戦略の作り方 — FL#127 メモ

要約

この動画の主題は、「エンジニアリング戦略とは何か」「なぜ言語化が必要なのか」「どう作り、どう運用するのか」です。

単に「方針を決める」「資料を作る」という話ではなく、組織の中で複数のチームや関係者が同じ方向へ動けるようにするための実務として、戦略を扱っています。特に重要なのは、戦略を作ること自体よりも、作った戦略が現場の行動に落ち、定期的に点検され、必要なら修正されるところまで含めて考える点です。

講演では、最初にAIコーディング導入の例を使って「戦略がないとどうなるか」が説明されます。その後、一般的な戦略論としてリチャード・ルメルトの「診断・基本方針・一貫した行動」を紹介し、それをエンジニアリング戦略に落とし込むための5ステップとして「探求・診断・洗練・方針・運用」が説明されます。

後半では、運用の具体パターン、Wardley Map、StripeのAPI廃止方針の例、Q&Aでの補足が扱われます。

1. なぜエンジニアリング戦略が必要なのか

AIコーディング導入の例

講演の導入では、大企業でAIコーディング活用が話題になったときに起こりがちな状況が例として出されます。

経営層が「AIコーディングを使って開発生産性を上げたい」「競合もやっているので急いで進めたい」と言い出すと、各部門が一斉に動き始めます。3ヶ月後には多数のPoCが走り、半年後にはさらに件数が増え、資料上は「全社で多数のAI PoCが進行中」「プロトタイプが大量に作られた」「研修にも多くの人が参加した」という見栄えのよい報告になります。

しかし、よく見ると次のような状態になりがちです。

この失敗の背景には、戦略の不在があります。

ここでのポイントは、PoC自体が悪いわけではないことです。問題は、何を学び、どのアウトカムにつなげ、どの判断をするためのPoCなのかが定義されていないことです。

2. 戦略とは何か

戦略の定義には複数の流派がある

戦略という言葉は広く使われますが、講演ではいくつかの代表的な考え方が紹介されます。

アルフレッド・チャンドラーの考え方では、戦略とは長期的な目標や目的を決め、それを達成するための行動方針を選び、資源を配分することです。つまり「ゴールを決める」「何をやるか決める」「そこにリソースを投入する」という考え方です。

マイケル・ポーターは、競争戦略やポジショニングの文脈で戦略を捉えます。どこで戦うか、どこで戦わないかを決める意味合いが強いです。

講演では、この3つがエンジニアリング戦略を考える土台として扱われます。

悪い戦略とは何か

悪い戦略の例として、「世界一の企業になる」「顧客満足を最大化する」「革新的で持続可能な成長を実現する」といった、耳触りはよいが具体的な判断に使えない言葉が挙げられます。

「戦いを略す」という見方

講演では、戦略を「戦いを略す」と捉える見方も紹介されます。

ゴールに向かうルートは複数あります。その中で、できるだけ不毛な戦いを避け、勝ちやすい場所や進みやすい経路を選ぶことが戦略です。これはビジネスの競争戦略だけでなく、エンジニアリング組織にも当てはまります。

3. 戦略を言語化しないリスク

戦略は、暗黙的に存在しているだけでは不十分です。講演では、言語化されていない戦略には大きく3つのリスクがあると説明されます。

1. 誤解のリスク

結果として、「なぜその判断になったのか」「何を優先しているのか」「どこまで例外が許されるのか」が人によってずれます。

2. チーム間の一貫性が失われるリスク

言語化されていない方針は、古くからいる人だけが知っているローカルルールになりがちです。

たとえば昇進や評価の方針、技術選定の基準、アーキテクチャ上の判断基準などが明文化されていないと、新しく入ったマネージャーやチームが異なる判断をします。すると、同じ組織の中でチームごとに違うルールが動き、一貫性が失われます。

3. 時間とともに背景が失われるリスク

人は異動し、退職します。意思決定の背景を知っている人がいなくなると、「たぶんこういう意味だったのでは」という推測が入り込みます。

その結果、戦略が少しずつ変質します。過去の判断のコンテキストが残っていないと、後から見直すことも難しくなります。

4. 戦略を書くべきタイミング

戦略は常に新しく作ればよいわけではありません。

すでに同じ課題に取り組んでいる人がいるなら、新しい戦略を上書きするより、その人たちに協力する方がよい場合があります。また、すぐに結果を出したいからといって勢いだけで戦略を作ると、短期的には動いても、長期的な行動変容や定着につながらないことがあります。

講演では、戦略が必要になる状況として、組織内の理解や行動が揃っていないケースが挙げられます。

逆に、すでに組織全体で同じ理解があり、行動も揃っているなら、新しい戦略を立てる必要は薄いです。戦略は少ない方がよく、むやみに増やすと集中投資ができなくなります。

5. 規範的戦略と寛容的戦略

戦略には、強制力の強さによって大きく2つのタイプがあります。

寛容的戦略

寛容的戦略は、ガイドラインに近いものです。大まかな方針は示すが、現場のチームが状況に応じて調整できる余地を残します。

メリットは、導入しやすく、現場が始めやすいことです。一方で、強制力が弱いため、チームごとのばらつきが残りやすいという弱点があります。

規範的戦略

規範的戦略は、ルールや標準を明確にし、組織として強く揃えるものです。

うまくいけば、確実に実行され、一貫性が高まります。一方で、導入や移行のコストが大きく、現場への負担も増えます。

講演者が特に刺さった点として、この2つを意図的に使い分けることが挙げられています。すべてを強制すればよいわけではなく、逆にすべてをガイドラインにすると揃いません。課題の性質や組織の状態に合わせて選ぶ必要があります。

6. エンジニアリング戦略を作る5ステップ

Will Larsonの本では、エンジニアリング戦略を作るプロセスとして次の5ステップが紹介されます。

講演では、この5ステップが実務に落とし込むうえで最も重要な部分として扱われています。

1. 探求

探求は、業界全体や社内外の事例、既存のプラクティスを調べるプロセスです。

探求では、以下のような情報源を使います。

2. 診断

診断は、ルメルトの戦略論における診断と同じく、根本的な問題やボトルネックを見極めるプロセスです。

ここで大事なのは、すぐに解決策へ飛びつかないことです。エンジニアは課題を見つけるとすぐに解きたくなりますが、戦略づくりでは一度立ち止まり、「本当に一番重要な問題は何か」を見極める必要があります。

AIコーディング導入の例でいえば、課題は「AIツールを使っていないこと」ではないかもしれません。本当の課題は、リードタイムの長さ、レビュー待ち、仕様の曖昧さ、テスト不足、セキュリティ審査の重さ、開発者体験の悪さなど、別の場所にある可能性があります。

診断を誤ると、方針も運用もずれます。

3. 洗練

洗練は、診断から出てきた仮説や方針案を、現実に照らして磨くプロセスです。

「この方針で本当に解けるのか」「制約を見落としていないか」「関係者に受け入れられるか」「副作用はどこに出るか」を確認します。

講演では、洗練に使えるツールとして次の3つが紹介されます。

戦略テストは、いきなり大きく展開せず、小さく試して検証する考え方です。システムモデリングは、システム思考の枠組みを使い、要素同士の関係やフィードバックを捉える方法です。Wardley Mapは、状況認識を可視化するための地図として紹介されます。

4. 方針

方針は、組織としてどの方向へ進むのかを言語化するものです。

5. 運用

運用は、戦略を現場のルールやプロセスに落とし込み、実際に組織へ定着させるプロセスです。

講演者は、運用が最も重要ではないかと述べています。戦略は作っただけでは何も起こりません。運用がないと、資料が完成しただけで終わります。

7. 探求の進め方

ステップ1: 情報を集める

まず、Web検索、LLM、同僚、社外ネットワークなどから広く情報を集めます。

特に大きな組織では、同じような課題に誰かがすでに取り組んでいることが多いです。AIコーディングのようなテーマなら、社内のどこかで必ず試している人がいます。社外の知人やコミュニティからも、機密情報ではない範囲で進め方や失敗例を聞けることがあります。

ステップ2: リソースを選別する

集めた情報をリスト化し、深く調べるものと、参照した事実だけ残すものに分けます。

すべてを深掘りすると時間が足りません。関連性が高く、意思決定に効くものを選びます。

ステップ3: 深掘りしてメモを残す

深く読むと決めたものは、重要な点をメモに残します。

後で方針や診断の根拠として使うため、単に読んで終わりにせず、なぜ重要なのか、どの判断に関係するのかを残すことが大切です。

ステップ4: やめどきを決める

社内外の主要なパターンが見えてきたら、探求を終えます。

広く読む・狭く読む

Will Larsonは、読む対象を「広く読む」と「狭く読む」に分けていると紹介されます。

広く読むとは、今の仕事に直結しないが、業界や技術の変化を理解するために幅広く読むことです。半導体、組織、プロダクト、歴史、経済など、直接の専門外も含まれます。

狭く読むとは、今まさに取り組んでいるテーマについて深く読むことです。たとえばAIエンジニアリングを扱うなら、そのテーマの本や事例を集中的に読む。

戦略を作るには、目の前の課題に対する深い理解だけでなく、広い視野も必要になります。

8. 運用の設計

運用は、戦略を現場で動く形にすることです。

講演では、運用を評価する観点として、ルーブリックのような採点表を使う考え方が紹介されます。具体的には次のような観点です。

特に印象的なのは、利用者と提供者の負担です。

ルールを作る側は、現場にとっての負担を軽く見積もりがちです。セキュリティ、法務、経理など、守るべきルールはありますが、現場が耐えられないほど複雑な運用にすると定着しません。

また、提供者側の負担も見落とされがちです。仕組みを作ったチームや担当者が疲れ切ってしまうと、運用は継続できません。

権威への依存も重要です。トップや特定のリーダーが強く推進している間だけ動く仕組みは、その人が異動・退職した途端に止まる可能性があります。戦略が本当に定着しているかを見るには、その人がいなくなっても運用が残るかを考える必要があります。

9. 運用パターン

講演では、戦略を運用するためのパターンがいくつか紹介されます。

承認と助言

方針に沿っている行動は自由に進めてよいが、例外やガードレールから外れる可能性がある場合は、CTOやディレクターなどの承認を得る、という形です。

これは、すべてを中央集権的に管理するのではなく、通常ケースは自律的に動かし、例外だけを明確に扱う運用です。

点検

運用が機能しているかを定期的に確認します。

AIコーディング導入なら、単に利用者数やPoC数を見るだけでは不十分です。リードタイム、レビュー時間、バグ率、開発者体験、コスト、セキュリティ事故など、目的に合った指標を見る必要があります。

ナッジ

ナッジは、強制ではなく、行動をそっと促す仕組みです。

例として、AIコーディングのトークンコストが予算の一定割合を超えたチームだけに通知する、といった運用が挙げられます。全員を呼び出して詰めるのではなく、必要な人だけに気づきを与えて修正を促します。

ナッジは、点検と組み合わせて使われることが多いです。

ドキュメントとトレーニング

新しい仕組みやルールを広めるために、ドキュメントや研修を用意する方法です。

ただし、ナレッジベースはすぐ古くなります。研修も、動画を流しているだけ、資料をクリックするだけになりがちです。

ここで紹介される考え方が「情報の集団免疫」です。全員が完璧に知る必要はなく、組織内の一定割合の人が十分に理解していれば、知識が広がりやすくなります。重要なのは、形式的に全員受講させることではなく、必要な人数が実際に理解している状態を作ることです。

先送りを明記する

今は決められないこと、エンジニアリング組織だけでは決められないこともあります。

その場合、曖昧なまま放置するのではなく、「これは今は決めない」「この条件が揃ったら判断する」と明記することも運用の一部になります。

会議

会議も運用の重要な道具です。

10. 運用のアンチパターン

トップが宣言して、各組織に丸投げする

トップダウンの戦略でよくある失敗は、トップが「このやり方でやってください」と宣言し、その後の運用を各組織に任せるパターンです。

説明責任だけが各組織に転嫁され、実際の行動変容につながりません。リモートワークの出社ルールのような例では、トップが宣言しても、現場でどう運用するかが曖昧だと混乱します。

強制研修だけで済ませる

研修を受けたことと、理解して行動できることは別です。

動画を再生しただけ、資料を読んだことにしただけでは、行動は変わりません。

文化の問題にしてしまう

文化は、行動が積み重なって定着した結果です。最初から文化を直接変えようとしてもうまくいきません。先に具体的な行動や運用を変え、その結果として文化が変わると考える方が現実的です。

11. 読まれる戦略文書にする

戦略を丁寧に書くと長くなります。

策定時には、探求から始めて診断し、方針と運用に落とし込む必要があります。しかし、文書として伝えるときは、最初に方針や運用を書いてよい。つまり、読み手がまず知りたい「結局どうすればいいのか」を先に置きます。

詳しい背景や診断は、その後に置けばよいです。方針だけで十分な人はそこで読み終え、なぜその方針なのか気になる人は診断や探求の部分を読む。この構成にすると、戦略文書が実際に使われやすくなります。

Q&Aでも、戦略は短く伝える方がよいという話が補足されます。理想は「これだけやってくれ」が伝わることです。一方で、詳細が必要な場面もあるため、短い要約と詳しい参照先を分けるのがよい、という整理です。

12. Wardley Mapの位置づけ

講演では、チャットツールを例に説明されます。縦軸はユーザーに見える価値か、見えない価値か。横軸は、左から特注的なもの、カスタム、プロダクト、コモディティへと進みます。

たとえばチャットツールであれば、ユーザーから見える価値としてメッセージ作成、検索、チャンネル閲覧などがあります。一方で、ユーザーから見えない価値として、検索インデックス、履歴保存、基盤技術などがあります。

Wardley Mapを書くことで、今の状況認識を可視化できます。

重要なのは、Wardley Mapは実行そのもののツールではなく、状況認識や戦略の洗練に使うツールだということです。Q&Aでも、Wardley Mapは運用のためというより、方針を作る途中で自分たちの見立てを検証するためのものだと説明されています。

講演では、StripeにおけるAPI廃止方針の例が紹介されます。

方針としては、やむを得ない事情がない限りAPIを廃止しない。サポートに高い技術的コストがかかるとしても、そのコストは自社で負担する、という考え方です。

ここでいうAPI廃止は、顧客側の実装修正を必要とする変更を広く指します。例外的にそのような変更を行う場合は、APIレビューで承認され、さらにCEOの承認も必要になる、という運用まで含まれています。

この例が重要なのは、方針と運用がセットで書かれていることです。

単に「後方互換性を大事にする」と言うだけではなく、例外をどう扱うか、誰が承認するかまで決めています。

さらに、その背景には診断があります。小さなエンジニア中心のスタートアップなら、新しい決済APIへの移行は簡単かもしれません。しかし、専任エンジニアがいない中小企業や、多数のステークホルダーを抱える大企業にとって、API変更への対応は非常に重い作業です。

APIの安定性が長期的な収益や解約防止に大きく効く、という見立てがあるため、後方互換性を強く守る戦略が成立しています。

この例は、戦略文書における「診断・方針・運用」のつながりを示しています。

14. 戦略は誰が作れるのか

講演では、戦略を作るのはCTOや経営層だけではないと説明されます。

インディビジュアルコントリビューターでも、戦略を素振りすることはできます。むしろ、自分で作ってみないと戦略はしっくりこない。実際に探求し、診断し、方針を書き、運用まで考えることで、戦略を作る力が身につきます。

ただし、戦略は他者にレビューしてもらうことが重要です。Q&Aでは、戦略の作成そのものはAIによって短縮できるが、同僚やピアにレビューしてもらう時間の方が大事ではないか、という話が出ています。

15. Q&Aで補足された論点

US企業の事例を日本企業に持ち込むときの注意

US企業の事例をそのまま持ち込むのはうまくいかないことが多い、という話が出ます。

日本企業が戦略づくりを苦手としているかどうかについては、両面あるとされています。うまくやっている企業もあるが、ビジネス戦略やエンジニアリング戦略の作り方をきちんと学ばず、なんとなく作ってきた組織もあるのではないか、という見立てです。

戦略は短く伝えるべきか

戦略は長く書くと読まれません。Q&Aでは、文章は短いほどよく、最初に「これだけやってくれ」が分かる形が親切だという話が出ます。

ただし、短くすると詳細や厳密さは削られます。そのため、絶対に覚えてほしいことは短くし、具体的な運用や例外は参照先として残すのがよい、という整理です。

ベゾスルールやTwo Pizza Ruleは戦略か

AmazonのTwo Pizza Ruleのようなものは、戦略でもあり文化でもあると整理されます。

会議の進め方やドキュメント文化は、働き方の文化に近い。一方で、「チーム構成は原則このサイズにする」と明確に決めるなら、それは組織設計上の戦略にもなります。

戦略とADRは似ているか

戦略の作り方はADRに似ている、というコメントに対して、講演者はかなり似ていると答えています。

共通点は、なぜその判断になったのか、背景やコンテキストを言語化して残すことです。形式や順番には違いがありますが、後から意思決定を理解できるようにする点は共通しています。

AI時代の戦略は軽量になるのか

AIの進化によって、戦略を作るサイクルや振り返りのサイクルは短くなるだろう、という話が出ます。

探求はAIやディープリサーチで大幅に短縮できます。戦略文書のたたき台を作ることも、テンプレートやプロンプトを使えば速くなります。

一方で、人の理解や組織への定着は簡単には短縮できません。作成は速くなっても、レビュー、納得、運用への落とし込みには人間側の時間が必要です。

変化が激しい時代の戦略

変化が激しいからといって、戦略を曖昧に広くしておけばよいわけではない、という話が出ます。

むしろ戦略は「やらないこと」を明確にして、リソースを集中させるものです。間違っていたら素早く変える。そのための組織のアジリティを持つことが重要です。

各ステップにどれくらい時間をかけるか

特に探求はAIによって短縮しやすい領域です。情報収集や初稿作成はAIで効率化できます。一方で、レビューや壁打ちに時間をかけた方がよい、という補足があります。

Wardley Mapは運用ではなく洗練のツール

Wardley Mapは、戦略を実行・運用するためのツールというより、戦略を作る途中で状況認識を検証し、方針を磨くためのツールです。

自分たちの見立てが正しいか、技術や市場の変化をどう見ているかを可視化することで、方針の妥当性を確認します。

10倍ルールはそのまま使うべきか

標準化と探索のトレードオフに関して、「探索は少なくとも10倍の改善が見込めるときに正当化される」という話題が出ます。

これを日本企業や中規模組織にそのまま適用できるかについては、状況によるとされています。本の5ステップもあくまで型であり、必要に応じてカスタマイズしてよい。10倍という基準も、一度試してみて、自組織に合わなければ変えればよい、という考え方です。

16. 実践に落とすなら

この講演から実務に持ち帰るなら、まず次の順番で試すのがよさそうです。

1. 今ある「暗黙の戦略」を書き出す

いきなり新しい戦略を作る前に、今の組織で暗黙的に共有されている方針を言語化します。

これを書くだけでも、認識のずれが見えます。

2. 課題を診断する

「AIを使う」「マイクロサービス化する」「テストを書く」といった解決策から入らず、今一番効いているボトルネックを診断します。

たとえば開発生産性が低いなら、原因はコーディング速度ではなく、仕様決定、レビュー待ち、テスト環境、リリース承認、問い合わせ対応にあるかもしれません。

3. トレードオフを書く

方針には、必ず「何を優先し、何を優先しないか」を含めます。

例:

ここが書けない場合、まだ戦略になっていない可能性があります。

4. 運用まで決める

方針だけで終わらせず、現場でどう動くかまで決めます。

運用がない戦略は、読まれない資料になりやすいです。

5. 短い版と詳しい版を分ける

全員に長い戦略文書を読ませるのは現実的ではありません。

最初に短い版を置きます。

その後に、診断、探求、背景、参考資料を置きます。実務で使う人には短い版が刺さり、判断に迷った人は詳しい版へ進める構成にします。

17. この動画の要点

この動画で最も重要なのは、エンジニアリング戦略を「立派な資料」ではなく「組織の意思決定と行動を揃えるための仕組み」として捉えることです。

戦略には、診断、方針、行動が必要です。エンジニアリング戦略では、それをさらに実務的に「探求・診断・洗練・方針・運用」の5ステップで進めます。

特に大事なのは運用です。どれだけよい方針を書いても、承認、点検、ナッジ、トレーニング、会議、指標、見直しの仕組みがなければ現場には定着しません。

また、戦略は長く書けばよいものではありません。作るときは深く考え、伝えるときは読み手が行動できる順番に並べ替える。短い方針と、必要な人が掘れる背景を分けることが重要です。