第II部 ・ 第10章
運用とは、方針を実際に機能させ、定着させるための取り組みである。優れた方針を立てても、対象チームが日々の意思決定で実際に使ってくれなければ役に立たない。著者は、方針を効果的に運用させることの3分の2は「一般的にうまく機能しないやり方」を避けるだけで達成でき、残り3分の1は試行錯誤で身につくと述べる。この技能は経営幹部になるまで待つ必要はない。
運用の仕組みとは、方針が現実の判断に反映されるよう後押しする具体的な仕掛けを指す。たとえば新規エンジニアリングプロジェクトに上限を設ける方針なら、レビュー会で承認を求める仕組み、提供側チームの負担を抑える仕組みなどがそれにあたる。エスカレーション(escalation)を方針として採用することも仕組みの1つで、現場で判断に迷ったとき上位に判断を仰ぐ道筋を用意することで、方針が実際の運用に組み込まれる。
著者は良い運用の特徴として、方針への準拠を促す、採用チームの負担を減らす、採用マネージャーを信頼して任せる、といった点を挙げる。これらが揃うと、方針は強制ではなく自然に守られるものになっていく。
運用の仕組みは複数の選択肢から選ぶことになる。著者は仕組みを比較・評価するためのルーブリック(評価軸)を提示する。完全に標準化された評価ではないが、選択肢を見比べるのに役立つ。主な評価軸は次の通り。
測定可能性: その仕組みの効果を測れるか。導入コスト: 移行や作業がどれくらい必要か、段階的に進められるか。利用者の負担(またはその減らしやすさ): この方針を導入する側、つまり日々従う側にどれくらい負荷がかかるか。提供側の負担(またはその減らしやすさ): この仕組みを提供・維持する中央チームやプラットフォームチームに、継続的にどの程度の負担がかかるか。
これらの軸で各仕組みを点数化していくと、どれがトレードオフ的に最良かを冷静に判断できる。直感だけで選ぶより、軸を明示して比較する方が説得力のある選択になる。
運用プランは、方針を支えるために使われる仕組みをまとめたものだ。著者は運用プランを作る前に、いくつかの問いを自問することを勧める。たとえば、作りたい方針はそもそも運用が必要なのか(運用なしでも自然に守られるなら不要かもしれない)、どの仕組みがこの方針に最も効果的か、最も低コストなのはどれか、といった問いだ。
すべての方針に重厚な運用が要るわけではない。自然に守られる方針に過剰な仕組みを付ければ、利用者・提供者双方の負担を無駄に増やすだけだ。運用プランの設計は、方針の性質に応じて軽重を調整する作業である。
著者は、実際に効果を発揮した運用の仕組みをいくつか紹介する。代表的なものは次の通り。
承認と助言の場(承認とアドバイスのフォーラム): 高い視点から見え、誰も適切に解こうとしていない問題を扱う場を設けること。問題が複雑なときに有効だ。点検(Inspection): 方針が実際に守られているか、自動的に点検する仕組み。たとえば「すべてのデータアクセスを点検し、新規が現れたらレビューにかける」といったルールや、コードレビュー時に方針違反を自動検知する仕組みなどが該当する。手作業より自動化された点検の方が、長期的には信頼でき安価になりやすい。
ナッジ(Nudge): 新しい方針に慣れていない不慣れさを和らげる、まるで自助的に振る舞う通知。たとえば現場が方針に沿った判断をしやすいよう、適切なタイミングでリマインドや情報を提供する仕掛けだ。著者の経験では、人間がやると不快に感じさせがちな指摘も、自動的なナッジに任せれば角が立たない。選択肢は、クラウド支出が上限を超えそうなときに知らせる、期限が近いプロジェクトに通知する、といった形をとる。
ドキュメントとトレーニング: 最も身近なアプローチだが効果は限定的。最初に方針を説明する手段としては機能するが、これだけで方針を定着させるのは難しい。自動化(Automation): 新しい方針への対応を人に頼ると、時間とともに古びて対応が抜け落ちる。著者の例では、Uber のサービスマイグレーション戦略は手動プロセスから自動化へ移行することで、構造的な準拠を保ち、移行時間を大幅に削減できた。自動化された仕組みは、人手に頼る仕組みより構造的に方針への準拠を保ちやすい。
効果が薄い、あるいは逆効果な運用の仕組みも存在する。著者は代表的なものを挙げる。
会議(Meetings): 紹介した仕組みの中には会議の場で実施できるものもあるが、会議そのものを方針運用の主軸に据えるのは要注意だ。会議は説明責任が分散しがちで、問題解決の場として最も効果が薄いことが多い。会議に頼り切る運用は形骸化しやすい。
トップダウンの宣言: リーダーが「この方法に従わなければならない」と宣言するだけで、それを支える仕組みを用意しないやり方。著者は「オフィス回帰」の方針でチームにオフィス出社の日数を義務づけたが運用が伴わない例を挙げ、本当の変化を生まないと指摘する。教育という名の関所: 方針が複雑すぎて、教育やトレーニングなしに理解できないほどになっている状態。これは多くの場合、方針そのものを簡素化すべきサインだ。強制や関所の定期トレーニング: コンプライアンス研修のような強制トレーニングは、形だけ実施しても実態が変わらないことが多い。「文化を変えればいい」: 文化を変えれば方針が定着すると考えるリーダーがいるが、文化を変えるのは一筋縄ではいかず、これに頼り切るのも危うい。
強制を伴う運用の仕組みを設計できるのは、しばしば権限を持つ立場の人に限られる。だが、経営幹部でなくても運用に貢献する道はある。承認や助言の場を開いたり、アーキテクチャレビューに参加したりして、方針を現場から後押しできる。
権限の弱い立場では、関所のような強制力よりも、現場で実際に使ってもらうための支援の方が効く。実装をやってみせる、ドキュメントを整える、困っているメンバーを助けるといった、影響力を通じた貢献が中心になる。著者は、権限がなくても自分のチームや影響範囲で方針を運用し、支援を惜しまないことが大切だと述べる。困っている人を助け、方針に沿いやすくする支援こそが、権限の弱い立場での最良の運用手段になる。
カーゴカルトとは、以前ある問題を解決したプロセスを、それがなぜ効果的だったのかという背景事情を理解しないまま再現することだ。場合によってはそれで十分なこともある(物理学を理解していなくてもボールは蹴れる)。だが、悲惨な結果を招くこともよくある。幼い子供が考える車の運転と実際の運転がまったくの別物であるのと同じだ。
著者は、ソフトウェア業界で長く働くほど、自分のやり方が実際に機能するかを気にかけている戦略担当者がいかに少ないかに驚かされると述べる。彼らは「うまくいきそうな何か」をすること、説明責任を組織やどこかのチームに押し付けること、そして次の問題に移ることばかりに集中しているように見える。これは、リーダーが「何を成し遂げたか」より「どう見えるか」で評価されがちな残念な現実に突き動かされているためかもしれない。
戦略の展開や実装で、どのパターンを取り入れるべきかを見極めるのは驚くほど難しい。著者の最善のアドバイスは「懐疑的でありつつも楽観的であれ」だ。アイデアは広く集め、しかしその真価は厳しく見極めること。模倣ではなく、なぜ効くのかを理解した上で取り入れる姿勢が要る。
本章を読み終えれば、完全で有用な戦略を書く力が身につくはずだ。戦略を支える運用は他のどのステップにも劣らず不可欠だが、つい省略されがちなものでもある。運用のない戦略は、組織の歴史の中に静かに消えていくことになる。