第IV部 ケーススタディ ・ 第21章
本章は、著者がCalm在籍時に取り組んだ戦略を記憶を頼りに書き起こした2つのドキュメントで構成される。Calmへの参画は著者にとって初の経営幹部（executive）としての役割であり、戦略を「提案する」だけでなく「遂行を徹底させる」立場にあった点が、Uberのサービスマイグレーションなどそれまでのキャリアと異なる。スタートアップの常としてチームの方向性は当初バラバラで、「最もスケーラブルなインフラを作るべきか」「先進的な言語を逃すリスクはどうか」「停滞しかけているサービス分割をどう立て直すか」といった問いが並立していた。
収録されるのは、(1) Calmの全社的な方針を示すドキュメント21-1「私たちはプロダクトエンジニアリングカンパニー！」と、(2) エンジニアリング主導プロジェクトへのリソース配分方法を定めたドキュメント21-2 である。読む際は「論点（diagnosis）」「方針（policy）」「探究（exploration）」「考察」の枠組みで構造を追うと、各文書が何を診断し、どんな方針で応えたのかが見えてくる。
論点（診断）。Calmのエンジニアリング組織が抱えていた最大の問題は、ユーザーから見て大半が「ブラックボックス」化していたことだった。インフラ刷新で内部の技術的洗練を高めても、ユーザー体験の改善に直結しなければ価値は薄い。ステークホルダー（社内の他部門）は技術チームを「対立する課題」のように扱いがちで、エンジニアが製品の意思決定に十分関与できていない構造もあった。技術スタックは比較的シンプルで、将来のロードマップの大部分は既存技術で十分実現可能だった——つまり高度なインフラ投資の必然性は低かった。
方針と運用。そこで打ち出された中核メッセージが「私たちはプロダクトエンジニアリングカンパニーである」という再定義だ。エンジニアリングの存在意義をインフラの純粋な洗練ではなく、プロダクトとユーザー価値の向上に置く。具体的には、新機能・価値創出につながる仕事を優先し、技術的洗練（例：先進言語の採用）はプロダクトの優位に明確に資するときだけ正当化する。たとえば「すべてをモノリスにせよ」ではなく、Web基盤はモノリス（外部の例に倣う）に寄せつつ、コードはモジュール化を保つといった、極端に振れないバランスを取る。
探究で示された具体プロジェクト。方針を裏づけるため、いくつかの実例が挙げられる。TypeScriptへの段階的移行（ユーザー影響のあるサービスを優先し、深夜稼働の社内ツールは後回し）、Postgres Aurora＋リードレプリカでの水平スケール（Auroraはインフラ系チームの主導）、メディアライブラリのノーコード化（いつでもパブリッシュ可能にしエンジニアを別作業へ解放）、機械学習によるコンテンツ創出（新メディアの制作コストを下げる戦略的投資）など。いずれも「組織体制が現実に動かせる範囲か」「ユーザー価値に資するか」で取捨選択されている。
論点（診断）。長期的課題や短期的課題への投資は「いずれも大事」に見えてしまい、優先度の判断が属人化・場当たり化しやすい。COVID-19下のコロナ禍という特殊な状況で、限られたリソースをどこに割くかが切実な問題になっていた。技術主導のプロジェクトは緊急性が低く見られ後回しにされがちで、結果として技術的負債が積み上がるリスクがあった。
方針と運用。解決策は、各プロダクトエンジニアリングチームに「四半期ごとに1つのエンジニアリング主導プロジェクトを実施する枠」を割り当てるという明快なルールだ。各チームのリソースの一定割合（例：四半期あたり最大1つ）を技術案件に確保し、対象はそのチームのリソースで完結する技術プロジェクトに限る。優先順位づけはチームのEM（エンジニアリングマネージャー）が担い、四半期初めに「合理的か」をCTOがレビューしてフィードバックする。緊急時にはCTOがエスカレーションを受け、明示的に判断する。
探究で示された判断基準。どのプロジェクトを選ぶかの優先順位づけでは、「合理的か」「投資が回収できるか」を軸に据える。挙げられた候補例には、メディアライブラリのノーコード化（運用負荷の軽減・整理）、機械学習によるコンテンツ創出（新メディア制作の効率化）などがあり、いずれも保守作業の置き換えやスループット向上といった「組織レベルの最適化」として正当化されている。重要なのは、これらが個々の改善の寄せ集めではなく、チームの裁量と全社方針の整合のもとで選ばれている点だ。
著者は、経営幹部としての遂行責任を持つ立場でこの戦略を運用したことが成否を分けたと振り返る。戦略の基本は「先行する成功手法を見つけて活用する」ことであり、すでに成果を上げている手法（外部の事例や、Reach×Impact×Confidence÷Effortのような優先度フレーム、RICE/AHP/WSJFなどの確立された手法）を採用すれば、戦略の練り直し作業そのものを省略できる。理想は、車輪の再発明を避け、機能している型をそのまま借りることだ。
この章の教訓は、スケーラビリティや複雑さが過度に高くないコンシューマー向けプロダクトでは、インフラの純粋な洗練よりもプロダクト価値への直結を優先軸に据えるのが良い出発点になる、という点に集約される。「プロダクトカンパニーである」という自己定義と、四半期1枠の技術プロジェクトという運用ルールが、属人的になりがちな優先順位づけに共有された土台を与えた。