第II部 ・ 第8章
『Great by Choice』（邦訳『ビジョナリー・カンパニー4』）の中で、Jim Collins と Morten T. Hansen は「まず小さな弾丸を撃ち、それから大砲を撃て」というコンセプトを示した。新しいアイデアに大きくコミットする前に、まず小規模にテストせよ、という主張だ。組織が撃てる「大砲」の数は限られているが、「小さな弾丸」なら数多く撃てる。だからまず小さな弾丸で狙いを定め、大砲を外すリスクを減らせばよい。洗練とは、まさにこの「小さな弾丸を撃つ」段階に当たる。
大きな戦略の全体を作るのは間違いを犯しやすく、迅速に検証できるツールキットを揃えておくと、それらをうまく組み合わせることで間違いを早く見つけられるようになる。洗練のために著者が用いてきたのは、戦略テスト、システムモデリング、そして Wardley マップの3つだ。これらは典型的な技法であり、自分用に戦略を磨くための道具として紹介される。
Stripe では、エンジニアリング部門のトップが、たった1回のミーティングでアジャイル開発手法の大方針を決めてしまうことがあった。本質として「ノー」と言いづらい文化の中で、多数のステークホルダーからの要望にうなずいた結果、誰も望まないものへと変質しやすい。これはサービスマイグレーションのような戦略でも起こり、洗練を欠いた戦略は、現場が学びを反映させる前に固まってしまう。
洗練が重要だと頭で理解していても、組織のインセンティブの食い違いによって洗練フェーズはしばしば省かれる。経営幹部から見れば、洗練に時間をかけることは進捗の遅れとして映りがちで、低コストで成功率を高める手段であるにもかかわらず、わざわざコストをかけて遅らせる動機を持ちにくい。組織全体では悪い結果につながるのに、個々のインセンティブが洗練を省かせてしまう。これがアンチパターンの温床になる。
著者は、ボストンで開かれたシステムモデリングのワークショップに参加した経験から、洗練の道具に開眼したという。ここでは、戦略の洗練に使える3つの技法を紹介する。問題そのものに違和感がある場合、前進を妨げる要因がわかっていないなら、まず戦略テストが役立つ。これらの道具は1つずつ独立して使えるが、組み合わせるとさらに強力になる。
戦略テスト＝問題そのものに違和感があるとき、前進を妨げる要因がわかっていないときは、戦略テストが役立つ。実際の現場で戦略を当てはめて検証し、共通課題をテストして洗練する手法だ。詳細は第11章で掘り下げられる。著者の経験では、問題の捉え方が間違っているとき、戦略テストが最も早く違和感を表面化させてくれる。
システムモデリング＝『Thinking in Systems』のレバレッジポイントのような考え方を借り、システムの挙動を時間軸で予測する技法だ。ロードバランサーとサーバーから成るシステムのモデル（図8-1）のように、各要素のつながりと因果を図に起こし、ある変更が将来どんな結果を生むかを予測する。第16-2章の Uber のサービスマイグレーション戦略でも使われている。最大の効果は、システムモデリングは投じる価値の高い手法だが、自分にとってまったく新しい手法であり、習得には時間がかかる。
Wardley マップ＝多くのエンジニアリング戦略は「自分たちが置かれているエコシステムは静的であり変化しない」という前提を暗黙に置いてしまいがちだが、この前提が長くは正しくない。Wardley マップは、業界の各要素が「ジェネシス→カスタム→プロダクト→コモディティ」という進化軸のどこにあるかを描き、エコシステムの動きを可視化する技法だ（図8-2は LLM エコシステムのマップを例示）。2010年代のオブザーバビリティのように変化の激しい技術を採用する場合や、5年以上の長期戦略を立てる場合に、業界の進化が自分たちのアプローチに及ぼす影響を浮き彫りにしてくれる。
最も頻出で致命的な「洗練のアンチパターン」は、洗練フェーズそのものが省かれることだ。Calm では、周囲の似たような企業がそうしていたという理由だけで、自社のモノリシックなコードベースを分割してしまった。それが開発者の生産性を実際に改善させているという根拠は何ひとつなかったにもかかわらず、1年間もこの戦略を続けてから、ようやく省かれた洗練フェーズをスキップしたことによる問題に気づいた、という。
第2に挙げられるのが「でっちあげられた合意」だ。Uber では、新しく加わったシニアリーダーが洗練されたかのような幻想を作り出していたケースがあった。実際にはエンジニアが分担して書いた複数のリーダーが互いに合意を示すよう促されたが、彼らはほとんど中身に意見を反映できておらず、表面的な同意があるだけで本質的な洗練は欠けていた。形ばかりの合意形成によって、あたかも洗練ができたかのような幻想を抱いてしまうのがこのアンチパターンだ。
最後のパターンは、洗練自体は行われているものの、組織の目標を優先してしまうあまり、戦略のプロセスから得られるはずだった学びを切り捨ててしまうケースだ。著者は、自分たちが Yahoo! の Build Your Own Search Service（doc 21-3）の検証で Erlang を採用したとき、技術コミュニティから集めた知見を組織目標の都合で軽視してしまった例を挙げる。15人のチームのうち3人だけがエンジニアで Erlang のコードベースを触ったことがなかったにもかかわらず、そういった学びは結局過小評価され無視されてしまった。
この章では、戦略の洗練という考え方とその技法を見てきた。代表的な洗練手法として、戦略テスト、システムモデリング、Wardley マップの3つを概観した。あわせて、独自の洗練に使うツールキットを揃えるためのフレームワークも紹介した。
洗練は、低コストで戦略の成功率を高められるにもかかわらず、インセンティブの食い違いによって省かれやすい。だからこそ、フェーズの省略や「でっちあげられた合意」、学びの切り捨てといったアンチパターンを意識的に避けることが大切になる。