エンジニアリング戦略の作り方 / Crafting Engineering Strategy

https://forkwell.connpass.com/event/395423 の登壇資料です。

Transcript

1. #Forkwell_Library エンジニアリング戦略の作り方 エンジニアリングの難局を打破する意思決定 2026/6/14 @iwashi86
2. 2 昔々、 ある大きな企業で...... つくり話です
3. #Forkwell_Library 3 「これからは Vibe コーディングだ！」 • ニュース記事や競合に感化された経営陣からコメントが出る ◦ 「うちもAIコーディングを活用しよう」 ◦ 「AIを使って開発生産性を上げたい」 ◦ 「競合に勝つためにいち早く進めて」 • すると...
4. #Forkwell_Library 4 各チームが一斉に動き出す • 3か月後、全社で17件のAIコーディングを使ったPoCが動き始め、 半年後には33件になった • コード生成、テスト作成、リファクタリング、レビュー支援、 仕様書からの自動実装、障害調査、ナレッジ検索、 などと色々な取り組みが立ち上がった
5. #Forkwell_Library 5 もちろん中では、こんな話が... • 開発支援部門 ◦ 「将来的なAIコーディング活用を考えると、標準を決めて云々」
6. #Forkwell_Library 6 もちろん中では、こんな話が... • 開発支援部門 ◦ 「将来的なAIコーディング活用を考えると、標準を決めて云々」 • 事業部門 ◦ 「共通の仕組みを待っているとプロダクト開発が遅くなるから独自で」
7. #Forkwell_Library 7 もちろん中では、こんな話が... • 開発支援部門 ◦ 「将来的なAIコーディング活用を考えると、標準を決めて云々」 • 事業部門 ◦ 「共通の仕組みを待っているとプロダクト開発が遅くなるから独自で」 • セキュリティ部門 ◦ 「ソースコードや機密情報を外部モデルに送るのはリスクが」
8. #Forkwell_Library 8 もちろん中では、こんな話が... • 開発支援部門 ◦ 「将来的なAIコーディング活用を考えると、標準を決めて云々」 • 事業部門 ◦ 「共通の仕組みを待っているとプロダクト開発が遅くなるから独自で」 • セキュリティ部門 ◦ 「ソースコードや機密情報を外部モデルに送るのはリスクが」 • 法務部門 ◦ 「著作権、ライセンス、生成コードの責任範囲を整理する必要がある」
9. #Forkwell_Library 9 もちろん中では、こんな話が... • 開発支援部門 ◦ 「将来的なAIコーディング活用を考えると、標準を決めて云々」 • 事業部門 ◦ 「共通の仕組みを待っているとプロダクト開発が遅くなるから独自で」 • セキュリティ部門 ◦ 「ソースコードや機密情報を外部モデルに送るのはリスクが」 • 法務部門 ◦ 「著作権、ライセンス、生成コードの責任範囲を整理する必要がある」 • 最後に、経営はこう語る ◦ 「スピード感を持って進めてください」
10. #Forkwell_Library 10 うまくいっている！！！ • 経営会議向けの資料には、こう書かれる 「☀ 全社で63件の生成AI PoCが進行中」 「☀ AIコーディングによりすでに300を超えるプロトが完成」 「☀ 開発生産性、品質向上、リードタイムの3領域で検討中」 「☀ 社内のAIコーディング事例共有会に、200人が参加」
11. #Forkwell_Library 11 その後を観察すると...... • ほぼすべてが本番運用にはいたらず それらは成功とも失敗ともジャッジされることなく 最終的に「☀ AIコーディングPoC完了」と 書かれた報告スライドが残った...
12. 12 <完?>
13. 13 あれ？ アウトカムは どこに行った？？ こんなひどい話はない
14. #Forkwell_Library 14 なぜこうなったのか？ • 理由の1つは戦略が定められなかったから ◦ あるいはあ言語化されておらず、関係者間でブレブレ • 現状認識（課題）がないままとりあえずPoCで何か作ってる ◦ もちろん「やる、やらない」のトレードオフがない ▪ できる範囲で薄く全部やってみた • 現場定着が想定されておらず、運用開始後のふりかえりもない • etc…
15. 15 ではどうすれば 効果的な戦略を 定められるのか？
16. #Forkwell_Library 16 良い本あります
17. #Forkwell_Library 17 今日のゴール • 『エンジニアリング戦略の作り方』本の中身を ざっくり知ること • 戦略そのものの考え方を知ること
18. 18 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業（育休中） ◦ NTT ドコモビジネス にて生成AI向けの技術開発 • サイドワーク ◦ 大小問わずエンジニア組織支援 ◦ 非常勤講師（プログラミング） ◦ Podcaster (fukabori.fm) ◦ 翻訳者
19. 19 本題
20. #Forkwell_Library 20 そもそも戦略って何だ？ • いろいろな大家が、いろいろなことを言っている
21. #Forkwell_Library 21 そもそも戦略って何だ？ いろいろな大家が、いろいろなことを言っている アルフレッド・チャンドラー 企業の長期的な目標と目的を決定し、 それらの目標を達成するために 必要な行動方針を採用し、資源を配分すること
22. #Forkwell_Library 22 そもそも戦略って何だ？ いろいろな大家が、いろいろなことを言っている • Plan、Ploy、Pattern、Position、Perspectiveの5つから成る ー ヘンリー・ミンツバーグ • 戦略とは、独自で価値あるポジションを選び、 それを支える活動システムを構築すること ー マイケル・ポーター • 「診断」「基本方針」「(一貫した)行動」から成る ー リチャード・ルメルト 注：上記内容はざっくりまとめしている
23. #Forkwell_Library 23 そもそも戦略って何だ？ いろいろな大家が、いろいろなことを言っている • Plan、Ploy、Pattern、Position、Perspectiveの5つから成る ー ヘンリー・ミンツバーグ • 戦略とは、独自で価値あるポジションを選び、 それを支える活動システムを構築すること ー マイケル・ポーター • 「診断」「基本方針」「(一貫した)行動」から成る ー リチャード・ルメルト 注：上記内容はざっくりまとめしている 企業戦略の話 だったり、 もっと抽象論 だったり粒度 もいろいろ 何に対する 戦略の話かを 意識しておく
24. #Forkwell_Library 24 そもそも戦略って何だ？ いろいろな大家が、いろいろなことを言っている • Plan、Ploy、Pattern、Position、Perspectiveの5つから成る ー ヘンリー・ミンツバーグ • 戦略とは、独自で価値あるポジションを選び、 それを支える活動システムを構築すること ー マイケル・ポーター • 「診断」「基本方針」「(一貫した)行動」から成る ー リチャード・ルメルト 注：上記内容はざっくりまとめしている ウィル・ラーソン氏がよく 参照しているのがルメルトの定義。 どの著書にもでてきており 本書のベースにもなっている
25. #Forkwell_Library 25 大元はこちらを 読んでいただくのが一番良い 戦略のカーネルが 丁寧に解説されている
26. #Forkwell_Library 26 大元はこちらを 読んでいただくのが一番良い 戦略のカーネルが 丁寧に解説されている ちなみにこういうのが悪い戦略 「世界一の企業になる」 「顧客満足度を最大化する」 「革新的で持続可能な成長を実現する」
27. #Forkwell_Library 27 あるいはPodcast(readline.fm)でも ・ ・ ・
28. #Forkwell_Library • 診断 ◦ 課題の本質を説明する仮説や その課題に影響を及ぼしている根本原因 28 ルメルトの戦略
29. #Forkwell_Library • 診断 ◦ 課題の本質を説明する仮説や その課題に影響を及ぼしている根本原因 • 方針 ◦ 課題に取り組む際に導入される一連の一般的な方針 ◦ 明示的または暗黙的なトレードオフを伴う ▪ トレードオフを含まないような基本方針は疑うべき 29 ルメルトの戦略
30. #Forkwell_Library • 診断 ◦ 課題の本質を説明する仮説や その課題に影響を及ぼしている根本原因 • 方針 ◦ 課題に取り組む際に導入される一連の一般的な方針 ◦ 明示的または暗黙的なトレードオフを伴う ▪ トレードオフを含まないような基本方針は疑うべき • 行動 ◦ 課題に対処するための、基本方針に基づいた 具体的な行動の集合のこと。バラバラにならないように。 30 ルメルトの戦略
31. #Forkwell_Library • 診断 ◦ 課題の本質を説明する仮説や その課題に影響を及ぼしている根本原因 • 方針 ◦ 課題に取り組む際に導入される一連の一般的な方針 ◦ 明示的または暗黙的なトレードオフを伴う ▪ トレードオフを含まないような基本方針は疑うべき • 行動 ◦ 課題に対処するための、基本方針に基づいた 具体的な行動の集合のこと。バラバラにならないように。 31 ルメルトの戦略 めちゃくちゃ抽象論！ 心配になるかもしれませんが、 書籍の第Ⅳ部に具体例が たくさん載っています。 他社の戦略文書って、 あまり読んだことないですよね？
32. #Forkwell_Library 32 参考：もう1つの捉え方 • 「戦いを略す」（戦いを省略する） • つまり、あるゴールに到達するために 最も（競合と）戦わなくて済むルートが狙うべき戦略
33. 33 書籍の中身 個人的に特に刺さった部分の概要だけ抜粋
34. #Forkwell_Library 34 書籍概要 • 第Ⅰ部 ◦ エンジニアリング戦略とは何か、誰が・いつ・なぜ書くのか • 第Ⅱ部 ◦ 探究・診断・洗練・方針策定・運用の5ステップでの戦略策定 • 第Ⅲ部 ◦ 洗練に使うツールx3の説明 • 第Ⅳ部 ◦ エンジニアリング戦略の具体の策定プロセスや戦略の具体例 • 第Ⅴ部 ◦ 今後に向けて
35. #Forkwell_Library 35 書籍概要 • 第Ⅰ部 ◦ エンジニアリング戦略とは何か、誰が・いつ・なぜ書くのか • 第Ⅱ部 ◦ 探究・診断・洗練・方針策定・運用の5ステップでの戦略策定 • 第Ⅲ部 ◦ 洗練に使うツールx3の説明 • 第Ⅳ部 ◦ エンジニアリング戦略の具体の策定プロセスや戦略の具体例 • 第Ⅴ部 ◦ 今後に向けて 作り方そのものを説明しているのは Ⅱ部とⅢ部でありコア
36. #Forkwell_Library 36 書籍概要 • 第Ⅰ部 ◦ エンジニアリング戦略とは何か、誰が・いつ・なぜ書くのか • 第Ⅱ部 ◦ 探究・診断・洗練・方針策定・運用の5ステップでの戦略策定 • 第Ⅲ部 ◦ 洗練に使うツールx3の説明 • 第Ⅳ部 ◦ エンジニアリング戦略の具体の策定プロセスや戦略の具体例 • 第Ⅴ部 ◦ 今後に向けて 戦略の書籍は抽象論で終わりがち。 で、具体的にどうやって書くの？ 実物見せて、 に答えているパート
37. 37 第Ⅰ部から抜粋
38. #Forkwell_Library • 誤解のリスク ◦ 意思決定の場にいた人物が、後から他の関係者に どれだけ情報を正確に伝えられるかに依存する（えてして不正確） 38 戦略が言語化されていないことによる影響
39. #Forkwell_Library • 誤解のリスク ◦ 意思決定の場にいた人物が、後から他の関係者に どれだけ情報を正確に伝えられるかに依存する（えてして不正確） • チーム間の一貫性の欠如 ◦ チーム間で不公平な判断が起きてくる（e.g. 昇進判断） 39 戦略が言語化されていないことによる影響
40. #Forkwell_Library • 誤解のリスク ◦ 意思決定の場にいた人物が、後から他の関係者に どれだけ情報を正確に伝えられるかに依存する（えてして不正確） • チーム間の一貫性の欠如 ◦ チーム間で不公平な判断が起きてくる（e.g. 昇進判断） • 時間経過による一貫性の喪失 ◦ 方針が文書化されないと、時間とともに考えがズレて 別の実装や暗黙的な判断が入り込んでしまう 40 戦略が言語化されていないことによる影響
41. #Forkwell_Library • 誤解のリスク ◦ 意思決定の場にいた人物が、後から他の関係者に どれだけ情報を正確に伝えられるかに依存する（えてして不正確） • チーム間の一貫性の欠如 ◦ チーム間で不公平な判断が起きてくる（e.g. 昇進判断） • 時間経過による一貫性の喪失 ◦ 方針が文書化されないと、時間とともに考えがズレて 別の実装や暗黙的な判断が入り込んでしまう • 新任リーダーたちへのリスク ◦ 過去の意思決定背景が共有されないと、新任リーダーが文脈を理解できず、 成功が個人の学習力に依存してしまう 41 戦略が言語化されていないことによる影響
42. #Forkwell_Library • 戦略に取り組めない人はほとんどいないが（書籍参照） 取り組むべきでない状況はある 42 戦略にいつも新規に取り組めばいいわけじゃない
43. #Forkwell_Library • 戦略に取り組めない人はほとんどいないが（書籍参照） 取り組むべきでない状況はある ◦ 既に同じ課題に取り組むチームがある場合は 新戦略を作るより直接協力するのが最善 43 戦略にいつも新規に取り組めばいいわけじゃない
44. #Forkwell_Library • 戦略に取り組めない人はほとんどいないが（書籍参照） 取り組むべきでない状況はある ◦ 既に同じ課題に取り組むチームがある場合は 新戦略を作るより直接協力するのが最善 ◦ 即効性が欲しいという、お気持ちドリブンで戦略に着手すると 結果的に長期的な変化にはつながりにくい ▪ トップダウン戦略は一部で無視されやすい ▪ ボトムアップ戦略は浸透に時間がかかる 44 戦略にいつも新規に取り組めばいいわけじゃない
45. #Forkwell_Library • 組織の状態を以下の3レベルで判断する a. 全体として一貫している ▪ e.g. 新規コードはモノリシックなコードベースに実装 45 戦略に取り組むべきタイミング
46. #Forkwell_Library • 組織の状態を以下の3レベルで判断する a. 全体として一貫している ▪ e.g. 新規コードはモノリシックなコードベースに実装 b. チーム内では一貫しているが、チーム間では不一致がある ▪ e.g. プロダクトチームとプラットフォームチームでズレ c. 個人レベルでばらついている ▪ e.g. モノレポとポリレポで作られていく 46 戦略に取り組むべきタイミング
47. #Forkwell_Library • 組織の状態を以下の3レベルで判断する a. 全体として一貫している ▪ e.g. 新規コードはモノリシックなコードベースに実装 b. チーム内では一貫しているが、チーム間では不一致がある ▪ e.g. プロダクトチームとプラットフォームチームでズレ c. 個人レベルでばらついている ▪ e.g. モノレポとポリレポで作られていく 47 戦略に取り組むべきタイミング 不 要 必 要
48. #Forkwell_Library • 組織の状態を以下の3レベルで判断する a. 全体として一貫している ▪ e.g. 新規コードはモノリシックなコードベースに実装 b. チーム内では一貫しているが、チーム間では不一致がある ▪ e.g. プロダクトチームとプラットフォームチームでズレ c. 個人レベルでばらついている ▪ e.g. モノレポとポリレポで作られていく 48 戦略に取り組むべきタイミング 不 要 必 要 戦略を立てすぎちゃうのも悪いパターンなので そもそも作らない方が良いことも多い
49. #Forkwell_Library • 寛容的戦略 ◦ 現場やチームごとの裁量を残しておいて ローカルでの上書きやカスタマイズを許容する戦略 ◦ 強制力が小さく導入しやすいため、低コストで始められる ◦ 一方で、広まると情報が薄まり、抜け落ちやばらつきが起きやすい 49 寛容的戦略と規範的戦略
50. #Forkwell_Library • 寛容的戦略 ◦ 現場やチームごとの裁量を残しておいて ローカルでの上書きやカスタマイズを許容する戦略 ◦ 強制力が小さく導入しやすいため、低コストで始められる ◦ 一方で、広まると情報が薄まり、抜け落ちやばらつきが起きやすい • 規範的戦略 ◦ 組織全体で守るべきルールや標準を明確にして 例外を減らして統一を図る戦略 ◦ 品質や判断基準を組織全体で揃えやすく、確実な実行につながりやすい ◦ 一方で、強制力がほぼ必須であり、導入・維持コストが高い 50 寛容的戦略と規範的戦略 参考：書籍では、これに「戦略の視座」を組み合わせてマトリクスで説明している
51. 51 第Ⅱ部から抜粋
52. #Forkwell_Library • 探究 ◦ 業界全体のアイデアやプラクティスを調ベ、最新研究や先端事例を把握 ◦ また、過去の類似課題から学ぶ • 診断 ◦ 自分たちが抱える課題を明確化する（すぐに解決に着手しない） • 洗練 ◦ アイデアや仮説を現実に照らす + ツールを使い検証して、 実行可能なレベルまでで磨き込む • 方針 ◦ 解決に向けた意思決定や判断基準を明確化して、組織の方向性を定める • 運用 ◦ 方針を実際に機能させる仕組みを整備して、継続的に進捗を確認する 52 戦略を作る5ステップ（今日1枚覚えるとしたらこの全体像） 注：必ずしもこの順番ではなくても良い
53. #Forkwell_Library • 探究 ◦ 業界全体のアイデアやプラクティスを調ベ、最新研究や先端事例を把握 ◦ また、過去の類似課題から学ぶ • 診断 ◦ 自分たちが抱える課題を明確化する（すぐに解決に着手しない） • 洗練 ◦ アイデアや仮説を現実に照らす + ツールを使い検証して、 実行可能なレベルまでで磨き込む • 方針 ◦ 解決に向けた意思決定や判断基準を明確化して、組織の方向性を定める • 運用 ◦ 方針を実際に機能させる仕組みを整備して、継続的に進捗を確認する 53 戦略を作る5ステップ 注：必ずしもこの順番ではなくても良い
54. #Forkwell_Library • 自然と起こるアンカリング効果を回避するため ◦ e.g. エンジニアが「今流行っているから」という理由だけで技術選定している ◦ e.g. 経営幹部が、前職で慣れ親しんだ技術スタックを 　　 今の職場にも押し通して導入しようとしている • すっ飛ばすと、必ずあとで後悔することになる 54 なぜ探求するのか？
55. #Forkwell_Library 1. あるトピックに関係しそうなリソースをひたすら集める ◦ Web検索 ◦ LLMの活用 ◦ 同僚（大きな会社であれば、誰かが取り組んでいる） ◦ 社外ネットワークの知人 55 どうやって探求するのか？（書籍の簡易版）
56. #Forkwell_Library 1. あるトピックに関係しそうなリソースをひたすら集める ◦ Web検索 ◦ LLMの活用 ◦ 同僚（大きな会社であれば、誰かが取り組んでいる） ◦ 社外ネットワークの知人 2. リソースをリストにまとめて、より深く掘るものと、言及するだけのものに選別 56 どうやって探求するのか？（書籍の簡易版）
57. #Forkwell_Library 1. あるトピックに関係しそうなリソースをひたすら集める ◦ Web検索 ◦ LLMの活用 ◦ 同僚（大きな会社であれば、誰かが取り組んでいる） ◦ 社外ネットワークの知人 2. リソースをリストにまとめて、より深く掘るものと、言及するだけのものに選別 3. より深く掘ると決めたものを読みつつ、ノートを取っておく ◦ 終わったら簡潔で読みやすいようにまとめておく 57 どうやって探求するのか？（書籍の簡易版）
58. #Forkwell_Library 1. あるトピックに関係しそうなリソースをひたすら集める ◦ Web検索 ◦ LLMの活用 ◦ 同僚（大きな会社であれば、誰かが取り組んでいる） ◦ 社外ネットワークの知人 2. リソースをリストにまとめて、より深く掘るものと、言及するだけのものに選別 3. より深く掘ると決めたものを読みつつ、ノートを取っておく ◦ 終わったら簡潔で読みやすいようにまとめておく 4. 社内外のアプローチが理解できたら、一旦打ち切る ◦ というのも、探求はやろうと思えばいくらでもできるプロセスのため 58 どうやって探求するのか？（書籍の簡易版）
59. #Forkwell_Library • 広く読む ◦ 業界関連の書籍等で、自分があまり知らないテーマをピックアップして読む ▪ e.g. 『半導体戦争』、『BIG THINGS』 など ◦ 何かしらアイデアが応用できることがある 59 FYI: 広く読む ＋ 狭く読む
60. #Forkwell_Library • 広く読む ◦ 業界関連の書籍等で、自分があまり知らないテーマをピックアップして読む ▪ e.g. 『半導体戦争』、『BIG THINGS』 など ◦ 何かしらアイデアが応用できることがある • 狭く読む ◦ 今取り組んでいるトピックをピックアップしてじっくり読む ▪ e.g. 『AIエンジニアリング』や、関連論文 60 FYI: 広く読む ＋ 狭く読む
61. #Forkwell_Library • 広く読む ◦ 業界関連の書籍等で、自分があまり知らないテーマをピックアップして読む ▪ e.g. 『半導体戦争』、『BIG THINGS』 など ◦ 何かしらアイデアが応用できることがある • 狭く読む ◦ 今取り組んでいるトピックをピックアップしてじっくり読む ▪ e.g. 『AIエンジニアリング』や、関連論文 • いずれにせよ ◦ 「ざっと読む」スキルをつけておくと良い。その時、必要な情報は一部かも？ ◦ 必ずしも書籍に限らない。エッセイや講演も対象 61 FYI: 広く読む ＋ 狭く読む
62. #Forkwell_Library • 探究 ◦ 業界全体のアイデアやプラクティスを調ベ、最新研究や先端事例を把握 ◦ また、過去の類似課題から学ぶ • 診断 ◦ 自分たちが抱える課題を明確化する（すぐに解決に着手しない） • 洗練 ◦ アイデアや仮説を現実に照らす + ツールを使い検証して、 実行可能なレベルまでで磨き込む • 方針 ◦ 解決に向けた意思決定や判断基準を明確化して、組織の方向性を定める • 運用 ◦ 方針を実際に機能させる仕組みを整備して、継続的に進捗を確認する 62 戦略を作る5ステップ 注：必ずしもこの順番ではなくても良い
63. #Forkwell_Library • 前のステップで策定した方針を実際に動く形にして 組織やチームに定着させるための取り組みのこと ◦ これがないと、戦略を立てただけで何も起きない • 運用の例 ◦ 毎週の定例ミーティング ◦ 閾値を超えた時に知らせてくれるアラート ◦ 昇進に関する要件の追加　など 63 運用とは
64. #Forkwell_Library • 評価用のルーブリックを用いると便利（詳細は書籍参照） ◦ 測定可能性 ◦ 導入コスト ◦ 利用者の負担 ▪ どれぐらいの負担を強いる？ ◦ 提供者の負担 ▪ 継続的に提供側が続けられるレベル？ ◦ 権威への依存度 ▪ トップダウンで進めるとして、トップが退任したら？ ◦ 文化への整合性 64 運用の仕組みをどう評価するか？
65. #Forkwell_Library • 承認と助言 ◦ 現場の詳細によっては、やりたい方針から逸脱するかわからない場合がある ◦ その場合に、承認と助言の場が一般的な対応プロセスとなる ▪ （具体の運営のコツは書籍参照） 65 運用で使われる定番のパターン
66. #Forkwell_Library • 承認と助言 ◦ 現場の詳細によっては、やりたい方針から逸脱するかわからない場合がある ◦ その場合に、承認と助言の場が一般的な対応プロセスとなる ▪ （具体の運営のコツは書籍参照） • 点検 ◦ ある方針が成果を上げているか、修正が必要かを判断する ◦ 「どこで」「どのように」「何を」トラックするか具体的に定義する 66 運用で使われる定番のパターン
67. #Forkwell_Library • 承認と助言 ◦ 現場の詳細によっては、やりたい方針から逸脱するかわからない場合がある ◦ その場合に、承認と助言の場が一般的な対応プロセスとなる ▪ （具体の運営のコツは書籍参照） • 点検 ◦ ある方針が成果を上げているか、修正が必要かを判断する ◦ 「どこで」「どのように」「何を」トラックするか具体的に定義する • ナッジ ◦ 対象の人・チームにだけ気づいてもらえるように知らせて行動を後押しする ◦ 点検と組み合わせると効果的 ▪ e.g. トークンコストが予算を50%超過したチームにだけ通知 • これを強制でやろうとすると、使いすぎている全てのチームとの予算レビューなどに 67 運用で使われる定番のパターン(1/2)
68. #Forkwell_Library • ドキュメントとトレーニング ◦ 何らかのマニュアルやナレッジベースを用意して、研修を実施する方法 ▪ ただ、意外とうまくいかない。ナレッジベースがすぐに陳腐化するし、 研修は何度やっても全く残ってない人もいる（とりあえずクリックだけとか） ◦ やる場合は、情報の集団免疫を意識しておくと良い 68 運用で使われる定番のパターン(2/2)
69. #Forkwell_Library • ドキュメントとトレーニング ◦ 何らかのマニュアルやナレッジベースを用意して、研修を実施する方法 ▪ ただ、意外とうまくいかない。ナレッジベースがすぐに陳腐化するし、 研修は何度やっても全く残ってない人もいる（とりあえずクリックだけとか） ◦ やる場合は、情報の集団免疫を意識しておくと良い • 自動化（略） • 将来への先送り ◦ 買収といった、現場ではどうしようもない事象もある ▪ その場合は、lazyな意思決定するのも手。わからないので先送りを明記する 69 運用で使われる定番のパターン(2/2)
70. #Forkwell_Library • ドキュメントとトレーニング ◦ 何らかのマニュアルやナレッジベースを用意して、研修を実施する方法 ▪ ただ、意外とうまくいかない。ナレッジベースがすぐに陳腐化するし、 研修は何度やっても全く残ってない人もいる（とりあえずクリックだけとか） ◦ やる場合は、情報の集団免疫を意識しておくと良い • 自動化（略） • 将来への先送り ◦ 買収といった、現場ではどうしようもない事象もある ▪ その場合は、lazyな意思決定するのも手。わからないので先送りを明記する • 会議 ◦ ここまでの内容を組み合わせて使う万能な仕組み ◦ コストが高いが、試行錯誤は簡単。いずれにせよ、自ら始めた定例はなくすのがゴール 70 運用で使われる定番のパターン(2/2)
71. #Forkwell_Library • トップダウンの宣言 ◦ 「このやり方に従ってください」と宣言するいわゆる権威的なパターン ◦ 説明責任を各組織に転嫁する意味ではうまくいくが、 著者の経験上、行動変容につながるのは滅多にない 71 運用のアンチパターン
72. #Forkwell_Library • トップダウンの宣言 ◦ 「このやり方に従ってください」と宣言するいわゆる権威的なパターン ◦ 説明責任を各組織に転嫁する意味ではうまくいくが、 著者の経験上、行動変容につながるのは滅多にない • 教育という名の周知 ◦ （書籍参照） • 強制参加のトレーニング ◦ （書籍参照） 72 運用のアンチパターン
73. #Forkwell_Library • トップダウンの宣言 ◦ 「このやり方に従ってください」と宣言するいわゆる権威的なパターン ◦ 説明責任を各組織に転嫁する意味ではうまくいくが、 著者の経験上、行動変容につながるのは滅多にない • 教育という名の周知 ◦ （書籍参照） • 強制参加のトレーニング ◦ （書籍参照） • 文化の問題として捉える ◦ 文化を変えるのは一筋縄では行かない ◦ 色々なテクニックを使って、運用に定着して初めて文化として根づくもの 73 運用のアンチパターン
74. #Forkwell_Library • 完全なエンジニアリング戦略は 「探究」「診断」「洗練」「方針」「運用」で構成される 74 どうすれば読みやすい戦略になるのか？
75. #Forkwell_Library • 完全なエンジニアリング戦略は 「探究」「診断」「洗練」「方針」「運用」で構成される • これは策定する順番としては非常に理にかなっている • だが、全員が戦略をゼロから読んで理解したいわけではない ◦ むしろ、方針と運用を理解して、素早く実践したい場合の方が多い 75 どうすれば読みやすい戦略になるのか？
76. #Forkwell_Library • 完全なエンジニアリング戦略は 「探究」「診断」「洗練」「方針」「運用」で構成される • これは策定する順番としては非常に理にかなっている • だが、全員が戦略をゼロから読んで理解したいわけではない ◦ むしろ、方針と運用を理解して、素早く実践したい場合の方が多い • そこで、順番を変えたり、項目をリファクタする（詳細は書籍を参照） 76 どうすれば読みやすい戦略になるのか？
77. 77 第Ⅲ部から抜粋
78. #Forkwell_Library • 戦略テスト（書籍参照だが、いきなりドカーンは止めようという話） • システムモデリング（書籍参照） • Wardleyマップ ◦ 日本だとあんまり見かけない(?)けど、非常に有用なので紹介 ◦ 書籍だと、オーケストレーション関連（k8sやサーバーレスなど）を 使ったWardleyマップの例が紹介されている 78 洗練に用いるツールセット
79. #Forkwell_Library 79 Wardleyマップでチャットツールを描いてみた例
80. #Forkwell_Library 80 Wardleyマップでチャットツールを描いてみた例 上に行くほどユーザーからよく見える （Visible） 下に行くほどユーザーから見えない
81. #Forkwell_Library 81 Wardleyマップでチャットツールを描いてみた例 特別に 作り込む機能 標準的で 当たり前な機能 動かすために専門 的な知識が必要 買ってこれる もの
82. #Forkwell_Library 82 Wardleyマップでチャットツールを描いてみた例
83. #Forkwell_Library 83 Wardleyマップでチャットツールを描いてみた例 技術予測を 描いてもOK
84. #Forkwell_Library • そもそも成功する戦略には、制約と状況の理解が必須 ◦ Wardleyマップでは、この理解を状況認識と呼ぶ 84 Wardleyマップがなぜ有効なのか？
85. #Forkwell_Library • そもそも成功する戦略には、制約と状況の理解が必須 ◦ Wardleyマップでは、この理解を状況認識と呼ぶ • この業界は常に激変するダイナミックな環境であり、 エコシステムを含む状況が常に変化し続けている 85 Wardleyマップがなぜ有効なのか？
86. #Forkwell_Library • そもそも成功する戦略には、制約と状況の理解が必須 ◦ Wardleyマップでは、この理解を状況認識と呼ぶ • この業界は常に激変するダイナミックな環境であり、 エコシステムを含む状況が常に変化し続けている • Wardleyマップを描くことで、「思いつき」ではなく 状況理解に基づいて思考できるようになる ◦ また周囲の関係者に、脳内にある前提を共有しやすくなる 86 Wardleyマップがなぜ有効なのか？
87. 87 第Ⅳ部から抜粋
88. #Forkwell_Library 88 StripeにおけるAPI廃止の方針と運用項目 “やむを得ない事情がない限り、APIを廃止しない。 　たとえサポート維持に高い技術的コストがかかるとしても、 　そのコストは当社で負担する。 　念のため明確にしておくと、ここで言うAPI廃止とは、 　顧客の実装に修正を強いるようなあらゆる変更を指す。 　もしそのような変更が本方針の例外として承認される場合、 　まずはAPIレビューで承認され、次にCEO によって承認されなければならない。 　例外が認められた例として、PCIコンプライアンス義務による 　TLS 1.2 サポートの廃止がある。” • 具体の戦略ドキュメントから方針(上部)と運用(下部)を1つだけ抜粋
89. #Forkwell_Library 89 StripeにおけるAPI廃止の診断項目 “エンジニア中心の小さなスタートアップであれば、 　新しい決済APIの組み込みは容易に思えるかもしれない。 　しかし、専任エンジニアがいない中小企業や、 　多数のステークホルダーが絡む大企業にとって、 　外部APIの変更に対応するのは極めて困難な作業である。 　たとえこの見立てが部分的にしか正しくないとしても、 　APIの変更を最小限に抑えることが長期的な収益成長に与える影響を 　モデリング（ドキュメント22-2）した結果、 　API安定化の効果は甚大である。 　これは、他の解約抑止策の効果を引き出す鍵となる。” • なぜ先ほどの方針に至ったのか？、も戦略ドキュメントで明記される
90. #Forkwell_Library 90 書籍掲載の戦略具体例 • ドキュメント16-1：サービスマイグレーション戦略：Uber • ドキュメント16-2：サービスオンボーディングモデル • ドキュメント16-3：サービスオーケストレーションエコシステムのWardleyマップ • ドキュメント17-1：LLMをどのように導入すべきか？ • ドキュメント17-2：LLMが開発者体験に与える影響のモデリング • ドキュメント17-3：LLMエコシステムのWardleyマップ • ドキュメント17-4：ドライバーオンボーディングのモデリング • ドキュメント18-1：プライベートエクイティ体制への対応 • ドキュメント18-2：エンジニアリング組織のシニア層構成モデル • ドキュメント19-1：ユーザーデータへのアクセスをどう制御すべきか？ • ドキュメント20-1：モノリスを分解すべきか？ • ドキュメント21-1：「私たちはプロダクトエンジニアリングカンパニー！」：Calmのエンジニアリング戦略 • ドキュメント21-2：Calmにおけるエンジニアリング主導プロジェクトのリソース配分方法 • ドキュメント22-1：StripeにおけるAPI 廃止のあり方 • ドキュメント22-2：API廃止のシステムモデル • ドキュメント22-3：なぜStripeはSorbetを作ったのか • ドキュメント22-4：Stripeは買収したIndexをどう統合するか これだけ読めばエンジニアリング戦略のイメージがつかめるはず！
91. #Forkwell_Library 91 続きは書籍で
92. 92 まとめ
93. #Forkwell_Library 93 今日のゴール • 『エンジニアリング戦略の作り方』本の中身を ざっくり知ること • 戦略そのものの考え方を知ること