Shawna MartellとDan Fikeとともに意思決定を分散化する
- Aisha Washington
- 2 時間前
- 読了時間: 11分
エンジニアリング組織は、チームに自律的に動いてほしいとよく口にします。しかし実際には、意思決定は上層へと流れ、会議で停滞し、その場にいるシニアアーキテクト次第になることが少なくありません。Shawna MartellとDan Fikeは、Cartekで開発された別のモデルを説明します。明示的なエンジニアリング戦略を確立し、その適用をチームに支援させるため、Navigatorと呼ばれる信頼された技術リーダーに権限を与えるのです。
彼らのアプローチでは、分散化は単なる権限移譲にとどまりません。人々には、共有された原則、十分なローカルコンテキスト、経験豊富な助言者へのアクセス、そして戦略に異議を唱えたり改善したりする手段が必要です。これらの要素が連携すれば、個人の貢献者は、あらゆる問いを管理職や中央集権的なアーキテクチャ機能に委ねることなく、重要な意思決定を行えます。
自律性にエンジニアリング戦略が必要な理由
MartellとFikeは、Navigatorプログラムの起点を繰り返し生じる問題にたどります。エンジニアは、より明確な指針を求めていました。合意されたフレームワークがなければ、チームは競合する技術的選択肢を確実に評価できず、どの組織的優先事項を優先すべきかも分かりませんでした。
その結果は、必ずしも悪いエンジニアリングではありませんでした。しかし、一貫性のないエンジニアリングでした。似たトレードオフに直面する二つのチームが、それぞれ異なる、主に暗黙的な基準を使うために、互換性のない結論に至ることがありました。同じ議論が何度も再燃し、永続的な組織知を生み出すことなく時間を消費していました。
すべての選択を中央で承認すれば、ボトルネックを作る代わりに一貫性の欠如には対処できたでしょう。そこでCartekは、よい意思決定の根拠を広く利用できるようにしようとしました。同社のエンジニアリング戦略は、共有の参照点となりました。すなわち、組織がトレードオフをどのように評価するか、特定の状況で何を重視する傾向にあるかを文書化したものです。
重要なのは、この戦略がコンテキストを求めるエンジニアの声に応じて生まれたことです。MartellとFikeは、これを経営陣が孤立して考案した命令として提示していません。その目的は、貢献者がより大きな方向性とつながったまま行動できる自信を与えることでした。
目指すべきポスターではなく、現実から始める
Cartekのプロセスで注目すべき点は、意思決定がすでにどのように行われているかを文書化することに重点を置いた点です。チームは、理想的な将来の組織像を描くことから始めませんでした。まず、矛盾しているように見える、あるいは正当化しにくい慣行も含め、現在の状態を検討しました。
この種の組織的な発掘は重要です。なぜなら、どのエンジニアリング組織にも、たとえ誰も書き留めていなくても、すでに戦略があるからです。それは繰り返される選択の中にあります。たとえば、チームが短期的なパフォーマンスと将来のスケールのどちらを最適化するのか、柔軟性を高めるために運用上の複雑さを受け入れるのか、新しいサービスを作るのではなく既存システムを拡張するのか、といった選択です。
過去の設計文書やアーキテクチャ意思決定記録は、こうしたパターンを明らかにできます。有用な記録は、検討した代替案、それぞれの利点とコスト、そして一つの選択肢が優勢となった理由を捉えています。複数の記録をまとめて見ると、それらの選択の背後にある価値観が浮かび上がります。
MartellとFikeは、その価値観を意思決定そのものと区別します。意思決定は、ある一つのケースで何が起きたかを示します。原則は、別のケースにも持ち運べる条件付きの指針を提供します。実質的には、「この条件が当てはまるときは、この対応を優先する」ということです。こうした原則を抽出するには、特に文書が結果だけを記録し、その根拠を省いている場合、過去の意思決定に関わった人々や状況を改めて確認する必要があるかもしれません。
正直に始めることは、変化を測定可能にもします。理想化された戦略は、方針と実践の隔たりを隠したまま、刺激的に聞こえることがあります。実際のシステムを記述することで、組織はそこを基準線として、意図的によりよくなっていけます。
Navigatorはチームが地図を読むのを助ける
このプログラム名は、責任の重要な分担を表しています。エンジニアリング戦略は地図のように機能し、Navigatorは不慣れな地形で人々がそれを解釈できるよう支援します。Navigatorも戦略に貢献しますが、その主な役割はマスタープランを発行したり、すべての技術的問いを自ら決定したりすることではありません。
議論された時点では、約12人のNavigatorが、およそ400人のエンジニアリング組織を支えていました。彼らはフロントエンドおよびバックエンドのエンジニアリング、信頼性、セキュリティを含む複数の技術分野から集まっていました。正式な階層における立場はさまざまでした。チームの深いところで働く人もいれば、シニアリーダーシップにより近いところで活動する人もいました。
選出は肩書きよりも、実証された判断力、技術的な深さ、影響力に左右されました。MartellとFikeは、マネジメントチャートと並行して存在する非公式なネットワークを説明します。ある問題が曖昧なとき、同僚が自然と相談する相手になるエンジニアがいます。Navigatorモデルは、権限が報告ラインを通じてのみ流れると考えるのではなく、そうした信頼される人々を認識し、つなげます。
Navigatorには、周囲のプロダクトやシステムに関する十分なコンテキストが必要です。どの意思決定が進行中かを把握し、作業が戦略と衝突する時を認識し、チームに支援が必要なときに介入できなければなりません。ただし、それは主導権を握ることを意味しません。Navigatorは、チームにトレードオフを検討させ、関連する原則を特定し、未解決の問題をより広いNavigatorグループへ持ち込めます。
彼らは双方向に情報を運びます。戦略はチームがローカルな選択をする助けとなり、一方でチームが直面する困難は、戦略のどこが不完全かを明らかにします。そのためNavigatorは、解釈者であると同時に、戦略の継続的な改訂における重要な貢献者でもあります。
アーキテクチャのボトルネックを作らない助言
Cartekは、正式なアーキテクトを技術的意思決定の必須の入口にしないよう、意図的にしています。スタッフエンジニアは必要に応じてアーキテクチャの仕事を担うことがありますが、組織は意思決定の権限を一箇所に集中させる恒久的な役割を望んでいません。
代わりに、そのモデルはアーキテクチャに関する助言プロセスに似ています。エンジニアは、影響を受ける人々、関連する経験を持つ同僚、文書化された戦略、必要に応じてNavigatorに相談したうえで、意思決定を行えます。権限は分散されたままですが、相談は期待されています。
戦略は、助言の集合的な情報源として機能します。経験の浅いエンジニアであっても、提案を検証するための基準を得られます。たとえば、組織がパフォーマンスとスケーラビリティをどう比較衡量するか、あるいは保守コストと提供速度をどう比較衡量するかを明確にできます。
すべての問いを普遍的な指針に還元できるわけではありません。MartellとFikeは、ある機能を既存のモノリスに置くべきか、それとも新しいサービスを正当化するものか、といった選択に言及しています。組織には一般的な方向性があっても、あらゆる状況に十分な精度で適用できるルールがあるとは限りません。そのような場合、戦略は曖昧さを認め、エンジニアを十分な情報に基づく相談へ導くべきです。
これにより、判断力を官僚主義に置き換えるのではなく、維持できます。目標は、将来のすべての答えをコード化することではありません。日常的な選択を容易にし、本当に難しい問題を明らかにし、例外について一貫して考える方法を人々に与えることです。
戦略は徐々に「より間違っていないもの」になるべき
MartellとFikeは、戦略を完成した教義ではなく、進化する道具として捉えています。初期の原則には欠落があります。広すぎるものもあれば、作成者が予想していなかった条件では機能しないものもあります。
実際の意思決定は、それらを改善するために必要なフィードバックをもたらします。チームは選択肢を戦略と照らし合わせ、指針が役立つ箇所や機能しなくなる箇所を発見し、その証拠をNavigatorを通じて報告します。時間とともに、個々の意思決定と共有フレームワークの両方が、より間違いの少ないものになり得ます。
限定的な曖昧さを許容することも、設計の一部です。チームにはなお、自らのシステムと制約に合ったローカルな「マイクロ戦略」を発展させる余地が必要です。Navigatorは、すべてのチームに同一の実装を強いることなく、こうしたローカルなアプローチが組織のより大きな方向性と両立するよう支援します。
Navigator同士の関係は、このフィードバックループを強化します。彼らがすべての意思決定を共同で担うわけではありませんが、問題が領域をまたぐときには仲間に相談できます。組織全体への幅広い認識と、深い専門知識の組み合わせは、セキュリティ、信頼性、プラットフォームアーキテクチャ、プロダクト開発にまたがる懸念に対して特に有用です。
分散化はメンタリングの仕組みでもある
権限の分散が機能するのは、より多くの人がそれを行使する方法を学ぶ場合に限られます。したがってNavigatorの役割には、トレードオフの見極め方、適切な助言の求め方、判断の根拠の記録方法、不完全な情報のもとでの意思決定方法を教えるという、暗黙の責任も含まれます。
これは、これまで影響の大きい選択を任されたことのないエンジニアにとって特に重要です。重要な提案がすべて、アクセスしづらいシニアグループによって後から覆されるのであれば、彼らに「オーナーシップを持て」と伝えるだけでは不十分です。Navigatorは、意思決定のプロセスを可視化し、判断を実務に近い場所に残したまま、貢献者を支援できます。
MartellとFikeは、Navigatorの視点とマネジメントの視点も分けています。マネージャーは、人、デリバリー、チームの実行のバランスを取る必要があります。Navigatorは深い技術的判断を提供し、現場のエンジニアリング上の選択を組織全体の戦略へとつなげます。この2つの視点は、単一の役割に統合されるのではなく、互いを補完すべきです。
候補者は、既存の貢献を通じて認められ、従来型の応募プロセスではなくシニアリーダーによって推薦されます。技術的な信頼性だけでは十分ではありません。他者を育成したり、自身の判断を共有したりする意思のない人は、このプログラムの目的を果たすのが難しいでしょう。
より良い意思決定によって成功を測る
分散化の価値は、具体的な意思決定の結果に現れます。MartellとFikeは、複数のドメインで見られる問題に対し、新しい共有プラットフォームサービスを検討していたチームについて説明しています。一見もっともらしい対応は、汎用的なソリューションを構築し、あらゆるステークホルダーの合意を取り付けるための長期的な取り組みを始めることだったかもしれません。
あるNavigatorはこの提案を組織の戦略と照らし合わせ、万能型のプラットフォームは望ましい方向性ではないと結論づけました。その戦略がすでに合意済みのデフォルトを示していたため、Navigatorは議論全体をゼロから組み立て直すことなく、この問題を解決できました。
これは、立証責任における意味のある変化を示しています。ある方向性が正しいと支持者が繰り返し他者を説得する代わりに、文書化された戦略が出発点を提供します。そこから逸脱することは引き続き可能ですが、そのためには説得力のある説明が求められます。
進捗の有用な指標には、より迅速な意思決定、不必要なエスカレーションの減少、設計文書におけるより明確な論拠、そして貢献者の自信の向上が含まれます。定性的なシグナルも重要です。エンジニアが迷いを感じにくくなり、繰り返される議論から、また一つの一時的な妥協ではなく、再利用可能な原則が徐々に生み出されるようになるべきです。
エンジニアリングリーダーが始める方法
MartellとFikeは、戦略を明確にする前にNavigatorを任命しても、うまく機能する可能性は低いと明言しています。共有された地図がなければ、信頼される個人が単に自分の好みをより効率的に広めるだけになりかねません。
リーダーは、過去のアーキテクチャ上の意思決定と現在の設計文書を見直すことから始められます。繰り返されるトレードオフを特定し、まずは最も議論の少ない原則を書き留め、掲げられた価値観と観察された行動との隔たりを検討すべきです。その記録に対する居心地の悪さは、有用な証拠です。そこには、組織が変えたいと考える実践が示されています。
実践的な手順は次のとおりです。
代表的な意思決定とその論拠を文書化する。
繰り返されるパターンから条件付きの原則を抽出する。
現在の実践が望ましい方向性と矛盾している領域を特定する。
すでに他者に助言している、尊敬される技術的貢献者を見つける。
その人たちを、現場の仕事と組織戦略を結びつけられる位置に置く。
実際の意思決定によって抜け漏れや矛盾が明らかになったら、フレームワークを見直す。
より深い教訓は、分散化には判断のためのインフラが必要だということです。文書化された原則は一貫性をもたらし、Navigatorは文脈とメンタリングを提供し、チームはシステムを現実に根ざしたものに保つ証拠をもたらします。これらの仕組みが組み合わさることで、組織が互換性のない技術的方向性へと分断されることなく、権限を実務により近い場所へ移すことが可能になります。
