■ 1. 背景: AIコーディング導入の失敗パターン
- 経営陣がVibeコーディングブームに感化され、全社的にAIコーディングの活用を指示
- 3か月後に17件、半年後に33件のPoCが立ち上がり、コード生成・テスト作成・リファクタリング・障害調査など多様な取り組みが生まれた
- 各部門でそれぞれの懸念が噴出:
- 開発支援部門: 「標準を決めて云々」
- 事業部門: 「共通の仕組みを待つとプロダクト開発が遅くなるから独自で」
- セキュリティ部門: 「ソースコードや機密情報を外部モデルに送るのはリスク」
- 法務部門: 「著作権・ライセンス・生成コードの責任範囲を整理する必要がある」
- 経営: 「スピード感を持って進めてください」
- 表面上は「全社63件のPoC進行中」「300超えるプロトが完成」と報告されたが、ほぼすべてが本番運用に至らず、アウトカムが消えた
- 失敗の根本原因:
- 戦略が定められず、あるいは言語化されておらず、関係者間でブレブレ
- 現状認識（課題）のないままとりあえずPoCで何か作っており、「やる・やらない」のトレードオフが存在しない
- 現場定着が想定されておらず、運用開始後の振り返りもない
■ 2. 本講演のゴールと紹介書籍
- 書籍: 『エンジニアリング戦略の作り方: エンジニアリングの難局を打破する意思決定』（Will Larson著、岩瀬義昌・岩瀬迪子訳、O'Reilly Japan）
- 本日のゴール:
- 同書の内容をざっくり知る
- 戦略そのものの考え方を知る
■ 3. 戦略の定義
- 戦略の定義は論者によって多様:
- アルフレッド・チャンドラー: 「企業の長期的な目標と目的を決定し、それらを達成するために必要な行動方針を採用し、資源を配分すること」
- ヘンリー・ミンツバーグ: Plan・Ploy・Pattern・Position・Perspectiveの5Pから成る
- マイケル・ポーター: 「独自で価値あるポジションを選び、それを支える活動システムを構築すること」
- リチャード・ルメルト: 「診断」「基本方針」「（一貫した）行動」から成る
- 本書はルメルトの定義をベースとしている
- 「戦いを略す」という語源的解釈: ゴールに到達するために最も競合と戦わずに済むルートを選ぶことが戦略
- 悪い戦略の例: 「世界一の企業になる」「顧客満足度を最大化する」「革新的で持続可能な成長を実現する」（トレードオフを含まない目標は戦略ではない）
■ 4. 書籍の構成
- 第I部: エンジニアリング戦略とは何か、誰が・いつ・なぜ書くのか
- 第II部（コア）: 探究・診断・洗練・方針策定・運用の5ステップでの戦略策定
- 第III部（コア）: 洗練に使うツール×3の説明
- 第IV部: エンジニアリング戦略の具体の策定プロセスや戦略の具体例
- 第V部: 今後に向けて
■ 5. 第I部: 戦略が言語化されていないことによる影響
- 誤解のリスク:
- 意思決定の場にいた人物が、後から他の関係者にどれだけ正確に情報を伝えられるかに依存（えてして不正確）
- チーム間の一貫性の欠如:
- チーム間で不公平な判断が起きてくる（例: 昇進判断）
- 時間経過による一貫性の喪失:
- 方針が文書化されないと、時間とともに考えがズレて別の実装や暗黙的な判断が入り込んでしまう
- 新任リーダーへのリスク:
- 過去の意思決定背景が共有されないと、新任リーダーが文脈を理解できず、成功が個人の学習力に依存してしまう
■ 6. 第I部: 戦略に取り組むべき状況とタイミング
- 戦略に取り組むべきでない状況:
- 既に同じ課題に取り組むチームがある場合は、新戦略を作るより直接協力するのが最善
- 即効性を求めるお気持ちドリブンで戦略に着手すると、長期的な変化につながりにくい（トップダウン戦略は一部で無視されやすく、ボトムアップ戦略は浸透に時間がかかる）
- 戦略を立てすぎるのも悪いパターンであり、そもそも作らない方が良いことも多い
- 戦略に取り組むべきタイミング（組織の3レベル）:
- a. 全体として一貫している（例: 新規コードはモノリシックなコードベースに実装）→ 不要
- b. チーム内では一貫しているが、チーム間では不一致がある（例: プロダクトチームとプラットフォームチームでズレ）→ 必要
- c. 個人レベルでばらついている（例: モノレポとポリレポで作られていく）→ 必要
■ 7. 第I部: 寛容的戦略と規範的戦略
- 寛容的戦略:
- 現場やチームごとの裁量を残しておいて、ローカルでの上書きやカスタマイズを許容する戦略
- 強制力が小さく導入しやすいため、低コストで始められる
- 一方で、広まると情報が薄まり、抜け落ちやばらつきが起きやすい
- 規範的戦略:
- 組織全体で守るべきルールや標準を明確にして、例外を減らして統一を図る戦略
- 品質や判断基準を組織全体で揃えやすく、確実な実行につながりやすい
- 一方で、強制力がほぼ必須であり、導入・維持コストが高い
■ 8. 第II部: 戦略を作る5ステップ
- 探究:
- 業界全体のアイデアやプラクティスを調べ、最新研究や先端事例を把握
- 過去の類似課題から学ぶ
- アンカリング効果を回避するために探究が必要（「今流行っているから」「前職で慣れ親しんだ技術スタック」などを避ける）
- 探求の方法（書籍の簡易版）: トピックに関するリソースを収集 → リストにまとめて優先度づけ → 深く読んでノートを取る → 一旦打ち切る
- 広く読む（業界関連書籍で知らないテーマをピックアップ）と狭く読む（今取り組んでいるトピックをじっくり読む）を組み合わせる
- 診断:
- 自分たちが抱える課題を明確化する（すぐに解決に着手しない）
- 課題の本質を説明する仮説や根本原因を特定
- 洗練:
- アイデアや仮説を現実に照らす + ツールを使い検証して、実行可能なレベルまで磨き込む
- 方針:
- 解決に向けた意思決定や判断基準を明確化して、組織の方向性を定める
- 運用:
- 方針を実際に機能させる仕組みを整備して、継続的に進捗を確認する
- 運用がなければ、戦略を立てただけで何も起きない
■ 9. 第II部: 運用のパターンとアンチパターン
- 定番パターン:
- 承認と助言: 現場の詳細によってはやりたい方針から逸脱するかわからない場合に、承認と助言の場が一般的な対応プロセスとなる
- 点検: ある方針が成果を上げているか、修正が必要かを判断する。「どこで」「どのように」「何を」トラックするか具体的に定義
- ナッジ: 対象の人・チームにだけ気づいてもらえるように知らせて行動を後押しする（点検と組み合わせると効果的）
- ドキュメントとトレーニング: ナレッジベースが陳腐化しやすい点と研修の効果が残りにくい点に注意。情報の集団免疫を意識する
- 将来への先送り: 現場ではどうしようもない事象に対して、lazyな意思決定をして先送りを明記する
- 会議: これまでの内容を組み合わせて使う万能な仕組み。コストが高いが試行錯誤は簡単
- アンチパターン:
- トップダウンの宣言: 著者の経験上、行動変容につながるのは滅多にない
- 教育という名の周知: （書籍参照）
- 強制参加のトレーニング: （書籍参照）
- 文化の問題として捉える: 文化を変えるのは一筋縄では行かない。色々なテクニックを使って運用に定着して初めて文化として根づく
■ 10. 第III部: 洗練に用いるツールセット
- 戦略テスト: いきなりドカーンを止めようという話（詳細は書籍参照）
- システムモデリング: （書籍参照）
- Wardleyマップ:
- 日本ではあまり見かけないが、非常に有用なツール
- 縦軸はユーザーからの可視性（上に行くほど見える、下に行くほど見えない）、横軸は進化度（ジェネシス・カスタム・プロダクト・コモディティ）
- 成功する戦略には制約と状況の理解が必須。WardleyマップではこれをSituation Awareness（状況認識）と呼ぶ
- この業界は常に激変するダイナミックな環境であり、エコシステムを含む状況が常に変化し続けている
- Wardleyマップを描くことで、「思いつき」ではなく状況理解に基づいて思考できるようになり、周囲の関係者に脳内にある前提を共有しやすくなる
■ 11. 第IV部: 具体的な戦略例（Stripe API廃止）
- 書籍には多数の戦略ドキュメント具体例が掲載されている（Uber、Calm、Stripeなど）
- Stripeの「API廃止しない」方針の例:
- 方針: 「やむを得ない事情がない限り、APIを廃止しない。たとえサポート維持に高い技術的コストがかかるとしても、そのコストは当社で負担する」
- 例外はAPIレビューで承認後、CEOによって承認が必要
- 診断: 「エンジニア中心の小さなスタートアップであれば、新しい決済APIの組み込みは容易に思えるかもしれない。しかし専任エンジニアがいない中小企業や、多数のステークホルダーが絡む大企業にとって、外部APIの変更に対応するのは極めて困難な作業である」
■ 12. まとめ
- 効果的なエンジニアリング戦略は「探究」「診断」「洗練」「方針」「運用」の5要素で構成される
- 戦略が言語化されていないことは、誤解・不一貫性・時間経過による劣化・新任者への情報断絶を招く
- 戦略は常に新規に作ればよいわけではなく、組織の一貫性レベルによって取り組むべき状況を判断する
- 戦略には寛容的戦略と規範的戦略の区別があり、状況に応じて使い分ける
- 運用なき戦略は絵に描いた餅であり、方針の定着に向けた仕組みが不可欠
- 書籍の詳細はWill Larson著『エンジニアリング戦略の作り方』を参照