第III部 ・ 第13章
技術戦略について「たった1つだけアイデアを広められるとしたら、戦略を時間軸付きで展開しよう」が著者の答えだ、という言い方で章が始まる。なぜなら、ほとんどの戦略は「絶対的に正しい/間違い」と二分できるものではなく、置かれた環境とのフィット（適合）の良し悪しで評価すべきものだからだ。環境は変化する。だから一度決めた戦略は、現実の変化に応じて何度も洗練し続ける前提で扱う必要がある。
その洗練の核になるのが「戦略テスト」である。本格的にウォーターフォール的に広めてしまう前に、まず小さく適用して、現実とどう噛み合うかを観察する。ここで言うテストは品質保証(QA)的な検査ではなく、戦略の有用性と適合度を測るための実地検証だ。この章は、戦略テストの具体的な進め方を、プロセス・役割・会議体・指標・失敗時の立て直しという観点で解説していく。
戦略テストとは、ある戦略が許容できるコストで意図した目標を達成できるかを検証する作業だ。だが、思いついたあらゆる戦略トピックを片端からテストするのは現実的ではない。テストには労力がかかるので、本当にテストする価値のある対象を選ぶことが先決になる、というのがこの節の主旨だ。
テストすべきかどうかの判断材料として、いくつかの観点が挙げられている。最近導入したシステムやAPI連携を1つだけテスト対象にする、レビューやリリースのボトルネックになっているプロセスをチームメンバーにまず試してもらう、サービスインテグレーションの場合は仮実装(モック)で先に進めてもらいフィードバックを得る、新規コンポーネントは少人数で先行検証する、といった具合だ。要は、影響が大きく不確実性の高い部分を、安いコストで実地確認できる形に切り出すのがコツだ。
逆に必ずしもテストが要らない場面もある。すでに十分理解しており低リスクなもの、何度も同種の判断を下してきて結果が読めるもの、テストのコストが見込まれる価値を上回るものなどは、テストを省いてよい。判断軸は「あらゆる戦略をテストする」ではなく、「テストしない選択が合理的かを毎回問い直す」点にある。
テストは厳密に見積もりづらいステップだが、おおむね「シンプルな方から始めて、効きが弱ければ徐々に重い手段へ上げていく」という順序で進める、というのが基本の型だ。まず一番軽いやり方は、自分や同僚に「この戦略を君のチームに導入したら、どこで詰まりそうか」を尋ねることだ。プロダクト/組織が大きく変わるわけではないこの段階で、重大なテストを一度に走らせる必要はない。
次の段階は、実際に試せるドキュメントを書くこと。具体的にはプロセスのRFCや新しいツールの導入提案などだ。ここでは抽象論ではなく「この場面でこう振る舞う」という形まで具体化すると、現実とのズレが見えてくる。さらに進めると、戦略を一部の現場に小さく適用してみる実地テストに移る。設定変更やツール導入を一部チームだけで先行させ、本格展開してよいかを判断する。
大事なのは段階を上げるほどコストとリスクが増えるので、安い検証で答えが出るならそこで止めてよいという点だ。リスクの高い手段ほど後ろに置き、いきなり最重量のテストから始めない。ツールについても、新しいものを導入する前に「既存のツールで代替できないか」を必ず問う姿勢が推奨されている。
戦略テストのプロセスには、主に2つの役割が関わる。1つは組織内部で検証の実務を支えるスポンサー、もう1つはその検証を適切な方向へ調整するガイドだ。スポンサーは、経営層やそれに近い立場の人（小規模な会社ならプリンシパルエンジニア相当）であることが多い。彼らは検証対象を明確にし、ツールやプロセスに調整を加える権限を持ち、検証が脱線したときに軌道修正する。組織横断で扱うべき課題はスポンサーがエスカレーションし、検証の進む先のチームに「なぜこれをやるのか」を伝える役目も担う。
一方ガイドは、エンジニアリングマネージャーやテックリードといった、現場で実装に近い人物が務める。ガイドはテストが具体的な作業フェーズへ落ちる際の、いわば実装責任者だ。検証手順やマイルストーンを定め、必要なサポートを手配し、エスカレーションに対応する。スポンサーが「何を・なぜ」を決め、ガイドが「どう実行するか」を回す、という分担関係だと整理できる。
この2つの役割が揃わないまま検証を進めると、方向性の調整が効かなかったり（スポンサー不在）、実行が宙に浮いたり（ガイド不在）する。検証を有用にするには両方の役割を意識して埋めることが要点になる。
戦略テストを回すうえで欠かせないのが、関係者が集まって状況を共有・調整する会議だ。会議のメンバーには、スポンサー・ガイドという主要メンバーに加え、検証から学ぶべき人々（実際に手を動かすチーム）を含める。会議の目的は「検証がどう進んでいるか」を確かめ、必要なら軌道修正することにある。
理想的な会議は、プレゼンを最小限に抑え、データに沿った議論で時間を使う形だ。テストにつながる学びが得られたか、ペースが速すぎ/遅すぎないか、必要な検証でスポンサーに課題をエスカレーションできているか、目標とマイルストーンを追えているか、ペースに見合うリソースが足りているか――こうした点を定期的に確認する。データが不足していて判断材料が乏しいなら、それ自体が「検証設計に何か足りない」というサインだと受け止める。
すべての戦略がテストされて洗練されているとは限らない。失敗に終わる戦略には、はじめからテストの段階を欠いて／実際に進んでいないものが少なくない。だから、自分や他者の戦略を扱うときには「これはテストされたのか」を見抜く目が要る。社内政治的な圧力で特定の結論に誘導された戦略や、ベンダーロックインへ自分たちを縛りつける戦略は、未テストである典型例として挙げられる。
未テストの戦略を見分ける具体的な手がかりとして、サービスやプラットフォームの選定が他社の事例だけを根拠にしている（自社で検証していない）、「トップダウンでこう決まった」という前提が検証なしに置かれている、といった兆候がある。詳細が一切なく抽象論で語られる戦略も疑わしい。多くの戦略は立ち上げ時にはこうした検証不足を抱えており、それを見抜くこと自体が洗練への第一歩になる。
戦略がテストされていない、あるいはテストの結果に反して進められていると気づいたとき、次にすべきは立て直しだ。まずは「未テストである」という事実をはっきり認める。戦略ドキュメント（モノクロ分解で扱うような診断・方針の文書）に立ち返り、検証されていない前提を可視化する。
立て直しの基本は、いきなり全面ロールバックではなく、検証可能な小さい単位に戦略を切り直して、実地テストをやり直すことだ。とくに重要なのは、暗黙のうちに固まってしまった前提を表に出して問い直すこと（暗黙より明示の方針へ）である。ベンダーロックインのような戻すのが高コストな選択ほど、慎重に検証し直す価値がある。立て直しは技術作業であると同時に、関係者の合意とリーダーシップを必要とする調整作業でもある、という点も強調されている。
戦略の良し悪しは、思いつきの時点で正誤を判断できるものではなく、環境とのフィットを測りながら反復的に洗練していくものだ。その洗練の中核に据えるのが戦略テストであり、シンプルな検証から始めて段階的に重くしていく省力的なアプローチが要点になる。
そしてその転換プロセスを導くのが、スポンサーとガイドという2つの役割だ。両者を揃え、データ中心の会議で進捗と適合を確認し、未テストの戦略を見抜いて検証可能な単位へ立て直す。この一連の運用ができて初めて、戦略を本格展開してよいかを根拠を持って判断できるようになる。