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

4章いつ戦略を書くべきか、どれくらい書くべきか？

戦略の有用性を理解していても、「今日からエンジニアリング戦略を書き始めよう」と決断するのは簡単ではありません。また、いざ書き始めると戦略が膨大になりすぎてしまい、組織がそれを理解するために時間をかけるのではなく、無視してしまうことも少なくありません。

幸い、これはどんな組織も共通して抱えがちな問題であり、この両極端を避けるのに役立つ思考モデルがいくつか存在します。この章では次の内容を取り上げます。

• いつ戦略を書くべきか
• 組織が耐えられる戦略の量はどれくらいか
• 戦略の寛容度や適用範囲といった「戦略の視座」を調整することで戦略が生む付帯的コストを管理する方法
• 戦略への取り組みが過剰か不足かをデバッグする仕組み

この章を読み終える頃には、戦略を書き始めるタイミング、書くべき戦略の量、そして実際に多くの戦略を書く必要がある場合に「戦略の視座」という概念を使って付帯的コストを抑える方法について、明確な見通しが持てるようになっているはずです。

4.1　戦略を書くべきタイミング

CalmのCTOになってすぐの頃、私はドキュメントを新しく作成しようとし、それに「エンジニアリング戦略」とタイトルを付けました。しかし、まっさらな画面を前にして何も書けないまま閉じてしまいました。1年後に改めて開いた時、ようやく次の3つの指針を書き留めました。

• 退屈な技術を選ぶ（https://oreil.ly/P3TY9）
• 好奇心を持って衝突を解決する
• コモディティ化された機能はベンダー製品を優先する

これらのシンプルな方針によって意思決定時の対立は大幅に減り、より多くのエネルギーをプロダクト改善に割けるようになりました。CTOになった当初も明確な戦略が必要だと感じてはいましたが、何を書けばよいのか分からず、結局何も書かなかったのです。 ...