第II部 ・ 第9章
方針とは、現在および将来の意思決定を方向づける、具体的かつ実行可能な計画である。問題そのものを定義する診断とは違い、方針は「その問題に対してどう動くか」を示す行動の指針だ。明確な診断があれば、それを踏まえて何をすべきかが言葉にできる。逆に方針が曖昧だったり、いくらでも好きに解釈できる余地が残っていたりするなら、それはまだ方針として機能していない。
本書は方針を、互いに補強し合う複数の要素の集合体として捉える。たとえば「人員不足のチームに増員する」という単独の指示は、聞こえは良くても効果が薄いことが多い。なぜなら、増員だけでは実際の意思決定の役に立たないからだ。それを支える指針(ガイダンス)・配分の基準・例外を認めるプロセスなどがセットになって初めて、日々の判断に効いてくる。方針は1つの宣言で完結するものではなく、組織の振る舞いを実際に変える要素の組み合わせなのである。
新しく方針を作ること自体が目的化しやすいが、既存の方針を再利用したり、上位戦略の方針をそのまま踏襲したりするのも立派な選択肢だ。重要なのは新規性ではなく、診断で示された問題を実際に動かせるかどうかである。
戦略を書く作業のうち、多くの人が最も難しく、不快にすら感じるのが方針策定の部分だ。探究や診断は調査・分析として進めやすいが、方針は「ここからは別の道を捨てる」という選択を伴うため、痛みを感じやすい。だが、ここを避けて通ることはできない。
著者は方針策定を体系的なステップに分解する。第一に診断を見直す。最も重要なのは、解こうとしている問題を取り違えないことであり、診断の中で本当に対処すべき点を特定する。第二に方針を統合する。重要な2〜3点に絞り、特定のチームではなくエンジニアリング組織全体に対して機能する方針へとまとめる。第三にバックテストする。新しい方針を、過去の意思決定に当てはめて検証し、本当に望ましい結果を導けたかを確かめる。第四に対立を扱う準備をする。診断を率直に示すと反発を招きやすいため、フィードバックを事前に集めて備える。第五に洗練させる。診断と方針のステップを行き来しながら、より良いものへ磨き上げていく。
これらは一直線に進むものではなく、診断と方針を往復しながら少しずつ精度を上げる反復的なプロセスだと理解しておくとよい。
診断内容が複雑になるほど、対処すべき方針も多くなりがちだ。著者は具体例として、ある戦略を4つの方針に整理した例を挙げる。すなわち、(1)新規ビジネスユニットは専用のコードリポジトリとモノリスで運用する、(2)ビジネスユニットをまたぐモノリス間連携には gRPC を使う、(3)新しいビジネスユニット専用のモノリスを作る場合を除き、新たなサービスは作成しない、(4)可能な限り、既存のサービスはビジネスユニットごとのモノリスに統合する、というものだ。
方針が多すぎても少なすぎても、戦略は機能しにくい。重要なのは数そのものではなく、戦略の診断内容に対して網羅的に応えているか、各方針が互いに補強し合っているかである。目に見えてワクワクするような方針を狙うより、効果を発揮することを優先すべきだ。
方針は無数に作れるが、実務で繰り返し現れるタイプは大きく4つに分類できる。承認(Approvals)、配分(Allocations)、指示(Direction)、指針(Guidance)である。それぞれ役割と効きどころが異なる。
承認は、繰り返し発生する意思決定のプロセスを定義するもので、特定の権限者の合意を求める。アーキテクチャに関する決定プロセスを定めるなどが典型例だ。承認はガバナンスの手段になる一方、現場のフィードバックを軽視すると形骸化したり、過剰なボトルネックになったりする危険がある。
配分は、限りあるリソース(主に人員)をどう割り当てるかを示す方針だ。配分が組織の優先順位を最も雄弁に物語る。たとえば既存事業の維持に何割、新規事業に何割といった配分は、口先の優先順位よりも実態を表す。
指示は、意思決定をどう行うかという最も直接的な指針で、目指す目標と、それに反する決定を明確に禁じる形をとる。「外部向けの新サービスは Golang で書くこと。既存のコードはモノリスへの統合が完了するまではモノリスに従う」といった、具体的で迷いの余地が少ない宣言だ。指示は判断を速くするが、現場の実情を無視すると例外だらけになりかねない。
指針は、推奨はするが強制はしない、より柔らかい方針だ。「新しいコードは原則アプリケーションコードとして JavaScript のモノリスに書くべきだが、外部依存サービスは別言語でもよい」のように、原則を示しつつ例外の余地を残す。判断者に裁量を与え、現場の文脈に合わせやすい反面、強制力がないため徹底されにくい。著者の経験では、指針より指示の方がリソースの取り合いには強い場合が多い。
方針を書くとき、つい1つのチームやプロジェクトの都合に最適化してしまいがちだ。しかし戦略の視座とは、組織全体のレベルでものを考え、特定のチームを優遇しすぎないことを指す。たとえば「特定の言語の使用を全社で義務づける」といった方針は、ある組織では理にかなうが、別の組織では成り立たない。
視座を欠いた方針は、ある一部のチームには好都合でも、組織全体としては最適でない判断に組織を縛りつけてしまう。著者は、組織レベルで方針を考えることと、解こうとしている問題のレベルとを一致させる必要性を強調する。戦略は組織のためのものであり、特定チームの代弁者になってはいけない。
方針が効果を発揮するかどうかを見極める鍵は「適用可能(applicable)」かどうかだ。複雑で予測しづらいシナリオ、特にトレードオフを伴う判断において、その方針が実際に役立つかが問われる。チームが方針に背くインセンティブを持っているときこそ、方針の真価が試される。
著者は、適用可能な方針の典型としてレバレッジを効かせる(leverage)方針を挙げる。たとえば「世界トップクラスのエンジニアを採用する」より「評価が定量で少なくとも1つ以上の強い強みを備えたエンジニアを採用する」の方が、はるかに適用しやすい。前者は誰がトップクラスかが定まらず実務で使えないが、後者は具体的な基準を示すため、現場で実際に判断を下せる。
もう1つの基準はトレードオフを認める(acknowledges trade-offs)ことだ。たとえばコード再利用と DRY(重複排除)は望ましい一方で、過度に追求するとチーム間の依存が増えて結合が強まり、かえって機動性を損なうことがある。良い方針は、こうした緊張関係を直視し、どちらをどこまで優先するかを明示する。トレードオフを無視した方針は、聞こえは良くても成果を生まない。
既存の方針や上位戦略を再利用できないとき、新しい方針を作る。これは難度の高い作業で、白紙から良い方針を生み出すのは容易ではない。著者の経験では、最初から完璧な方針が書けることはほとんどなく、初稿は荒削りなものになる。
新しい方針を作る際の補助手段として、著者はいくつかの技法を挙げる。近い方針をたたき台にする(他社や別組織の類似方針を出発点にする)、システムモデル(14章)で検証する(方針を立てる前にモデルで挙動を確かめる)、試作段階の方針について戦略テストのサイクルを回す(小さく試して実地で適用してみる)、といったものだ。これらを使い、荒削りな初稿を実用に耐える方針へと育てていく。
方針を作っていると、1つの問題に対して複数の対立する選択肢が残ることがある。これは一見、診断が不十分なサインに見える。よく言われるのは「答えが1つに絞れないのは、まだ問題を十分に理解できていないからだ」という見方だ。
しかし著者は、この見方を一面的だと退ける。たとえば Stripe が Sorbet という Ruby の型付けツールを開発したとき、(1)中央の専任チームで全社的に型付けコードベースへ段階的に移行する、(2)コードベースを Golang や Java のような型の強い言語へ移行する、という2つの選択肢が拮抗していた。どちらも一長一短で、どちらが本当に優れているかは、実際に試してみるまで明確にならないこともある。
複数の方針案が残ること自体は必ずしも欠陥ではない。むしろ、本文に方針案そのものを併記し、その理由とトレードオフを明示することで、読者がなぜその決定に至ったかを理解できるようになる。決め切れない緊張関係を正直に示すことは、戦略の質をかえって高めうるのだ。
方針が失敗する最大の原因の1つは、そもそもそれを実行するためのリソースが足りないのに方針を作ってしまうことだ。リソースが十分でないなら、職員を簡単に増やせるなら誰も苦労しない。良い方針は、自分が動かせる制約を正直に踏まえて立てなければならない。
著者は制約の具体例を挙げる。たとえば「ユーザーデータへのアクセスを制限する戦略」では、すべてのデータアクセスに二要素認証を課したくなるが、それは社内の作業フローに大きな摩擦を生む。理想を追って実行不能な制約を課すより、現実に動かせる範囲で制約を設計する方が、最終的には機能する。制約を無視した方針は、聞こえは立派でも実を結ばない。
新しい戦略を最初から書ける機会はそう多くない。実際には、組織にすでにある不完全な戦略や、上位の方針の欠けたところに対処しなければならないことが多い。たとえば、上位の経営層がリソース配分の問題を解決してくれないとき、自分のレベルでできる範囲のドキュメントを書いて対処する。
欠けに対処するとき重要なのは、自分が動かせる範囲と動かせない範囲を区別することだ。上位の決定を覆そうとするのではなく、その制約を所与として受け入れ、その中で実行可能な方針を組み立てる。著者は、欠けを埋める作業も正義感あふれるリーダーシップではなく、現実的なリスクとして冷静に扱うべきだと述べる。空白を埋める作業は、しばしば組織を前進させる現実的な手段になる。
この章では、方針の定め方、診断内容を解決するために複数の方針を組み合わせる方法、そして方針を書く人が直面しやすい落とし穴の避け方を学んだ。診断と方針を往復しながら、適用可能でトレードオフを直視した方針へと磨き上げることが核心だ。
戦略づくりのフェーズとして残るのは、あと1つ。すなわち、作った方針を実際に組織で機能させる「運用」である。次章でそれを扱う。