エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定

23章この戦略は優れているか？

本書ではここまで多くの戦略を読んできました。読者のみなさんは今や、戦略のフォーマットや構成を評価できるようになったはずです。しかし、フォーマットは品質の予測因子であって、品質そのものではありません。では、ある戦略が本当に優れているかどうか、どのように評価すればよいのでしょうか？

Uberのサービスマイグレーション戦略（ドキュメント16-1）は、組織全体の足かせを外し、急成長を実現しました。しかしその一方で、後にアーキテクチャが無秩序に広がるという問題も引き起こしました。これは優れた戦略だったのでしょうか、それともひどい戦略だったのでしょうか？ 意見が分かれるところですが、どちらの解釈を支持すべきか、自分なりの視点を持つことには価値があります。

本章では、以下のテーマに焦点を当てます。

• 戦略を評価するための一般的な手法
• フェーズごとに戦略を評価するためのルーブリック
• 戦略を終わらせることが、むしろ優れた戦略家の証である理由
• 他社の戦略を評価することの問題点
• 失敗した戦略からも、成功した戦略と同じくらい学べる理由

ここからは、戦略の品質を見極める力を磨いていきましょう。

23.1　業界全体で戦略はどのように評価されているか？

独自のルーブリックを提案する前に、ソフトウェア業界で実際に使われている戦略評価の手法をいくつか見ておきましょう。私自身はこれらのアプローチに全面的に賛成しているわけではありません。どれも重要なニュアンスを少なくとも1つは見落としていると思います。とはいえその欠点を理解することが、より良い評価基準を築くための土台になります。

戦略をアウトプットで評価する手法は、最も広く使われているアプローチです。戦略は結果が何よりも重要である、という考え方は理にかなっています。しかし、この一見魅力的な考え方には落とし穴があります。Googleのような巨大企業がサービスアーキテクチャに移行すると、他の企業も真似をします。「Googleでうまくいったなら、自分たちもうまくいくはずだ」というわけです。しかし ...