概要
RACIでDRI（最終決定者）を明示する
「全員が納得するまで話し合う」は決定権の不在を隠す言葉になりやすい。決定領域ごとにAccountable（DRI）を1人定め、意見は聞くが決めるのは誰かを明確にする。
エスカレーションは時間SLAで設計する
「対立したら次回まで再検討」には期限が無い。24時間・48時間・72時間という具体的な時間軸を組み込んで初めて機能する。42日の滞留を数日に短縮する。
one-way door / two-way door で重さを可変に
ベゾスの不可逆/可逆の分類で、決定プロセスの慎重さを変える。可逆な決定は現場即決、不可逆な決定は上位承認という設計でスピードと安全性を両立する。
ADRで「なぜ」を残す
議事録の一行「〇〇に決定」だけでは後から蒸し返される。検討した選択肢・トレードオフ・却下理由をADR形式で構造化して残す。
問題
ECサイト MOps チームは、複数チーム横断で使われる基盤 「顧客セグメント配信API」（クーポン・レコメンド・メールキャンペーンなど、あらゆる販促施策から呼び出される共通API）をオーナーとして開発・運用している。この基盤には 在庫管理チーム・注文管理チーム・CRMチーム の3チームがそれぞれ異なる要望を持って関わっており、直近1四半期で仕様を巡る対立が繰り返し発生し、意思決定が長期間滞留している。
あなたはMOpsチームのシニアエンジニアとして、後輩PdM見習いが作成した以下の Bad ステークホルダー調整計画ドラフトをレビューし、次四半期から実際に運用できるレベルへ再設計することになった。以下のドラフトには 7つの問題点が潜んでいる。問題点を全て洗い出し、Good 調整計画へ再設計してください。
制約・前提条件
- MOpsチーム体制: エンジニア5名（API開発・運用を一手に担う）
- 案件A: APIレート制限値の設定 — 在庫管理チームは高頻度アクセス（1秒間10リクエスト）を要望、MOpsはコスト・キャパシティ懸念から低頻度を主張。解決まで23日（週次定例3回分）
- 案件B: セグメント配信失敗時のリトライ仕様 — 注文管理チームは「注文確定直後の即時性が必須、リトライ最大1回で即座にエラー通知」を要望、MOpsは「指数バックオフで最大5回リトライすべき」と主張し平行線。解決まで42日、この間に予定していた機能リリースが1ヶ月延期になった
- 案件C: 配信ペイロードへのPII（氏名・住所）含有可否 — CRMチームは分析効率のため含めたいと要望、MOpsはセキュリティ・個人情報保護方針の観点から反対。解決まで18日
- 3件とも「毎週月曜30分の定例で話し合い、意見が対立したら次回まで各チームで再検討」という現行プロセスのみで進行し、途中で誰かが最終的に決定を下す・上位者にエスカレーションするという動きは一度も発生しなかった
- 各案件とも、対立中は「声の大きさ」「直近で誰が強く主張したか」で議論の流れが左右され、なぜその結論に至ったかの根拠（トレードオフの比較）は議事録に「〇〇に決定」の一行しか残っていない
- 案件Bの42日は特に問題視されており、CTOから「なぜここまで時間がかかったのか、恒久対策を示してほしい」という指示が出ている
- Amazon創業者ジェフ・ベゾスの「one-way door（後戻りできない不可逆な決定）/ two-way door（後で修正可能な可逆な決定）」の考え方を、意思決定プロセスの設計に組み込むこと
期待する回答形式: 問題点の列挙（番号付き） + RACIマトリクス（決定領域別） + エスカレーションフロー（時間軸付き） + 優先順位判定基準表（トレードオフスコアリング） + ADR（Architecture Decision Record）形式の決定ログサンプル（案件Bを題材に） + 運用ケイデンス設計（定例・緊急シンクの使い分け）
悪い調整計画ドラフト (Before)
このドラフトには 7つの問題 が隠れています。見つけてみてください。
Bad ドラフト — 決定権者不在・期限なし・一律プロセス
件名: 顧客セグメント配信API ステークホルダー調整計画
関係者: 在庫管理チーム、注文管理チーム、CRMチーム、MOpsチーム全員
進め方:
- 毎週月曜の定例会議（30分）で、各チームの要望を持ち寄って議論する
← 問題④: 緊急の対立に対応する会議体が定例以外に存在しない
- 全員が納得するまで話し合い、合意が取れたら実装に進む
← 問題①: 最終決定権者(DRI)が不在。誰も決めないまま議論が続く
- 意見が対立した場合は、次回の定例までに各チームで再検討してもらう
← 問題②③: 期限が無く無期限に延長。エスカレーション先も未定義
← 問題⑤: 決定の重大性・可逆性による扱いの差が無く一律処理
← 問題⑥: 優先順位付けの共通基準が無く声の大きさで決まる
- 決まったことは議事録に残す
← 問題⑦: 決定根拠(選択肢・トレードオフ・却下理由)が残らない
以上で、円滑なコミュニケーションを実現し、対立を防ぎます。問題点サマリー（7点）
1最終決定権者(DRI)が不在 — 決定領域別RACIでAccountableを明示
2対立解決に期限が無い — 案件Bが42日滞留した直接原因
3エスカレーション基準・先が未定義 — 時間SLA付きフローを設計
4会議体が週次定例のみ — 緊急シンクの2層運用を追加
5決定の重大性・可逆性で扱いが同一 — one-way/two-way door分類
6優先順位付けの共通基準が無い — 4軸トレードオフスコアリング
7決定根拠が文書化されない — ADR形式で選択肢・却下理由を記録
ヒント（段階的開示）
ヒント1 — 方向性
Bad計画の罠は3系統。(1) 決定権者の不在 — 「全員が納得するまで話し合う」は聞こえは良いが、誰にも最終決定権（decision owner）が無いため、意見が割れた瞬間に議論が無限ループする。(2) 時間軸の不在 — 「意見が対立したら次回まで再検討」というルールには期限（SLA）が無く、42日かかった案件Bのように、対立が自然に収束するまで際限なく引き延ばされる。(3) 決定の性質（可逆性・重大性）に応じた扱いの違いが無い — レート制限値のような後から調整可能な決定（two-way door）と、PII含有可否のようなセキュリティ・法令に関わり後戻りが困難な決定（one-way door寄り）を同じ「週次30分の話し合い」という一律のプロセスで扱っており、リスクの高い決定ほど慎重な検討が必要という発想が欠けている。
ヒント2 — アプローチ
- 問題①: 「全員が納得するまで話し合う」で最終決定権者が定義されていない → 決定領域ごとにRACI（Responsible/Accountable/Consulted/Informed）を設計し、Accountable（最終決定者、DRI: Directly Responsible Individual）を明示する
- 問題②: 「意見が対立したら次回まで再検討」に期限が無く議論が無期限に延びる → 対立発生から解決までの時間SLAを設け、超過したらエスカレーションする仕組みにする
- 問題③: エスカレーション先・エスカレーション基準が定義されていない → 誰が・どの条件で・誰にエスカレーションするかをフロー図で明示する
- 問題④: 週次定例（30分）のみで、緊急の対立に対応する会議体が存在しない → 定例（進捗共有・軽微な調整）と緊急シンク（対立が発生した際の即時招集）の2層構造にする
- 問題⑤: 決定の重大性・可逆性による扱いの差が無く、全ての決定を同じ重さで扱っている → ベゾスのone-way door/two-way doorの考え方で決定を分類し、two-way doorは現場（DRI）の即断即決、one-way doorは慎重な合議＋上位承認とする
- 問題⑥: 各チームの要望に優先順位付けの共通基準が無く「声の大きさ」で議論が流れる → トレードオフを定量スコアリングする基準表を作る（ビジネスインパクト・セキュリティリスク・実装コスト・可逆性）
- 問題⑦: 決定の根拠が議事録に残らず、後から「なぜその結論になったのか」が蒸し返される → ADR（Architecture Decision Record）形式で、決定内容・背景・検討した選択肢・トレードオフ・却下理由を構造化して残す
ヒント3 — 誘導
【RACIマトリクスの骨格】
決定領域 | Responsible | Accountable(DRI) | Consulted | Informed
API仕様(レート制限等) | MOpsエンジニア | MOpsテックリード | 関連チームPM/エンジニア | 全ステークホルダー
セキュリティ/PII | MOpsセキュリティ担当 | MOps EM/CTO | 法務・セキュリティ部門 | 全ステークホルダー
【エスカレーションフロー（時間SLA付き）】
対立発生
→ 24時間以内: 当事者間で解決を試みる（two-way doorならDRIがその場で仮決定）
→ 解決しない場合、48時間以内: 緊急シンクを招集しDRIが最終判断
→ one-way door（不可逆・高リスク）の場合、72時間以内: MOps EM/CTOへエスカレーションし承認
【one-way door / two-way door 分類】
two-way door（可逆・現場即決）: レート制限値、リトライ回数 → 後から調整可能
one-way door（不可逆・慎重合議）: PII含有可否、外部公開API契約 → 一度リリースすると後戻りコストが大きい
【ADRサンプルの骨格】
# ADR-002: セグメント配信失敗時のリトライ仕様
状態: 決定
背景: 注文管理チームは即時性を重視...MOpsは配信基盤の信頼性を重視...
検討した選択肢: (1)即時1回のみ (2)指数バックオフ5回 (3)ハイブリッド...
決定: ...
トレードオフ・却下理由: ...問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 最終決定権者(DRI)が不在 | 決定権設計 | 決定領域別RACIでAccountableを明示 |
| 2 | 対立解決に時間SLAが無く無期限に延びる | 時間軸の欠如 | 24h/48h/72hの段階的SLA設計 |
| 3 | エスカレーション基準・先が未定義 | エスカレーション設計 | Step1〜3の明確なフロー |
| 4 | 会議体が週次定例のみで緊急対応不可 | 運用ケイデンス | 定例+緊急シンクの2層構造 |
| 5 | 決定の重大性・可逆性で扱いが同一 | プロセスの重さ | one-way/two-way door分類 |
| 6 | 優先順位付けの共通基準が無い | 優先順位付け | 4軸トレードオフスコアリング |
| 7 | 決定根拠が文書化されず蒸し返される | 決定の記録 | ADR形式で選択肢・却下理由を記録 |
エスカレーションフロー比較 — Bad vs Good
模範解答
修正①: 決定領域別RACIマトリクス
| 決定領域 | Responsible（実行） | Accountable（最終決定者/DRI） | Consulted（意見聴取） | Informed（結果共有） |
|---|---|---|---|---|
| API仕様（レート制限・リトライ回数等、two-way door） | MOpsエンジニア（担当者） | MOpsテックリード | 要望元チームのPM/エンジニア | 全ステークホルダー |
| セキュリティ/PII/コンプライアンス（one-way door） | MOpsセキュリティ担当 | MOps EM（重大時はCTO承認） | 法務・セキュリティ部門、要望元チーム | 全ステークホルダー |
| 配信基盤の可用性・SLA設計 | MOpsエンジニア（担当者） | MOpsテックリード | 注文管理チーム、CRMチーム | 全ステークホルダー |
| 新規統合先チームの追加 | MOpsエンジニア | MOps EM | 統合先チームPM | 全ステークホルダー |
Bad版は「全員がConsulted（意見は聞くが誰も決めない）」という状態に陥っていた。Good版は決定領域ごとにAccountable（最終的に責任を持って決める1人）を明示することで、「話し合いで自然に決まる」から「意見を聞いた上でDRIが決める」に構造を変える。
修正②③④: エスカレーションフロー（時間SLA付き）
【Step 0】対立の検知
週次定例、または随時のSlackチャンネルで対立が表面化
【Step 1】24時間以内 — 当事者間での一次解決
要望元チームの担当者とMOps担当エンジニアが直接協議
→ two-way door（後から調整可能）な決定であれば、MOpsテックリード(DRI)が
その場で仮決定を出し、実装を進めながら様子を見る
【Step 2】解決しない場合、48時間以内 — 緊急シンクの招集
DRI（テックリード or EM）・両チームの代表者を集めた30分の緊急ミーティングを招集
→ DRIがトレードオフスコアリング表を用いて最終判断を下す
→ 判断内容はADR形式で即日記録する
【Step 3】one-way door（不可逆・高リスク）と判定された場合、72時間以内 — 上位承認
MOps EM（必要に応じCTO）へエスカレーションし、ADRドラフトを提示して承認を得る
→ PII含有可否のような案件はここに該当する
案件Bへの適用シミュレーション: リトライ仕様はtwo-way door（後から調整可能）に分類されるため、Step1で当事者協議 → 24時間以内に解決しなければStep2で48時間以内にテックリードが決定。42日 → 最大3日（72時間）に短縮される想定。
修正⑤⑥: 優先順位判定基準表（トレードオフスコアリング）
| 軸 | 定義 | 案件A（レート制限） | 案件B（リトライ仕様） | 案件C（PII含有） |
|---|---|---|---|---|
| ビジネスインパクト | 未解決の場合の事業影響度 | 3（在庫同期遅延） | 4（販促機会損失） | 2（分析効率の低下のみ） |
| セキュリティ/コンプライアンスリスク | 誤った決定の法的・信頼リスク | 1 | 1 | 5（個人情報保護法・PCI DSS関連） |
| 実装コスト | 変更にかかるエンジニア工数 | 低（設定値変更のみ） | 中（リトライロジック再設計） | 低（ペイロード項目の追加のみ） |
| 可逆性（one-way/two-way） | 後から変更可能か | two-way | two-way | one-way（配信・外部保存されたPIIは回収不能） |
判断ロジック: セキュリティ/コンプライアンスリスクが4点以上、または可逆性がone-way doorの場合は、スコア合計に関わらず自動的にStep3（EM/CTO承認）へ回す。案件Cはビジネスインパクトが低くても、リスク軸とone-way door判定によりトップダウンで慎重ルートに乗る設計にする。
修正⑦: ADR（Architecture Decision Record）サンプル — 案件Bを題材に
# ADR-002: セグメント配信失敗時のリトライ仕様
## 状態
決定（2026-XX-XX）
## 背景
注文管理チームは「注文確定直後のセグメント反映は即時性が必須」として、
リトライ最大1回・即座にエラー通知を要望。MOpsは配信基盤の一時的な
ネットワーク断・下流API過負荷を考慮し、指数バックオフで最大5回の
リトライを主張。両者は42日間、週次定例での議論のみで平行線をたどった。
## 検討した選択肢
1. 即時1回のみ、失敗したら即エラー通知（注文管理チーム案）
2. 指数バックオフで最大5回リトライ（MOps当初案）
3. ハイブリッド: 最初の1回は即時実行、失敗時のみ指数バックオフで
最大3回リトライ + 3回目失敗時点で注文管理チームに非同期通知
（DRIによる折衷案）
## 決定
選択肢3を採用する。
## トレードオフ・却下理由
- 選択肢1: 一時的なネットワーク断でも即座に失敗扱いとなり、配信基盤側の
瞬間的な不安定さがそのまま業務影響に直結するため却下
- 選択肢2: 最大5回・数分にわたるリトライは、注文管理チームが求める
「即時性」の期待値と乖離が大きすぎるため却下
- 選択肢3: 即時性（1回目は即実行）と信頼性（一時障害への耐性）を両立し、
かつ3回失敗時点で非同期通知することで注文管理チーム側の後続処理が
無期限に待たされる事態を防ぐ
## 影響範囲
MOps配信基盤のリトライロジック改修（見積: 3人日）、注文管理チーム側の
非同期通知受信処理の追加実装（見積: 2人日）
## 可逆性
two-way door。リトライ回数・バックオフ間隔は設定値であり、運用実績を
見て後から調整可能。運用ケイデンス設計（定例・緊急シンクの使い分け）
| 会議体 | 頻度・所要時間 | 目的 | 参加者 |
|---|---|---|---|
| 週次定例 | 毎週月曜30分 | 進捗共有、軽微な調整（対立に発展していない要望のすり合わせ） | 全ステークホルダーPM/エンジニア |
| 緊急シンク | 対立発生から48時間以内に随時招集、30分 | エスカレーションフローStep2の意思決定 | DRI、当事者チーム代表 |
| 月次ADRレビュー | 毎月最終営業日 | 直近1ヶ月のADRを棚卸しし、two-way door決定の見直しが必要か確認 | MOpsテックリード、EM |
週次定例は「対立を発生させない・早期に芽を見つける」場として残しつつ、実際に対立が起きた際は定例を待たずに緊急シンクで48時間以内に決着させる。two-way doorの決定は「決めて終わり」ではなく、月次ADRレビューで実績を見ながら微修正できる余地を残す。
ポイント解説
1「全員が納得するまで話し合う」は決定権の不在を隠す美しい言葉になりやすい — 合意形成そのものは重要だが、最終的に誰が決めるか（DRI）を明示しない限り、対立は自然消滅を待つしかなくなり、案件Bのような42日という滞留を生む。
2エスカレーションは「揉めたら誰かに助けを求める」仕組みではなく、時間SLA付きのプロセスとして設計する — 「対立が起きたらエスカレーションする」だけでは基準が曖昧で誰も動かない。24時間・48時間・72時間という具体的な時間軸を組み込むことで、初めて機能する仕組みになる。
3ベゾスのone-way door / two-way doorは、決定プロセスの重さを決定の性質に合わせて変えるためのフレームワーク — 全ての決定を同じ慎重さで扱うと意思決定全体が遅くなり、逆に全ての決定を即断即決すると不可逆なリスクを見逃す。可逆性で分岐させることで、スピードと安全性を両立できる。
4優先順位付けは「声の大きさ」ではなく、ビジネスインパクト・リスク・コスト・可逆性という共通軸のスコアリングで行う — 特にセキュリティ/コンプライアンスリスクのような「事業インパクトは低く見えるが誤ると致命的」な軸は、単純な合計スコアではなく閾値判定でトップダウンに扱う設計が必要。
5ADRは「決定した」ではなく「なぜその決定に至ったか（検討した選択肢と却下理由）」を残すためのもの — 議事録の一行だけでは、後から異動・入れ替わりがあったチームメンバーが同じ議論を蒸し返すコストが発生する。却下した選択肢とその理由まで残すことが、将来の再議論を防ぐ最大の防御線になる。
実務への応用
MOpsチームが今後、より多くのチーム（在庫・注文・CRMに加え、将来的には物流・カスタマーサポート等）から利用される基盤を持つほど、ステークホルダー間の対立は頻度・複雑さともに増していく。本問題の型（RACIで決定権を明示 → 時間SLA付きエスカレーション → one-way/two-way door分類でプロセスの重さを可変にする → トレードオフの定量スコアリング → ADRでの根拠文書化 → 定例と緊急シンクの2層運用）は、基盤チームが複数の利害関係者を抱える場面全般に応用できる汎用的な設計パターンである。
証券会社経験との接続: 複数部門が絡む商品組成の意思決定において「誰が最終承認者か」「不可逆なリスク（規制対応など）は慎重に、可逆な運用ルールは現場裁量で」という切り分けが機能不全に陥ると、承認プロセスが数週間単位で滞留する事例をよく見た。技術組織でも全く同じ構造の問題が起きることを踏まえ、PM/CTOを目指す上ではこうした「決定の設計」自体を組織のプロセスとして持てるかどうかが、シニアエンジニアとマネジメント層を分ける差になる。
今日のまとめ
複数チーム横断の意思決定プロセスは、「全員が納得するまで話し合う」という理想論ではなく、決定領域ごとのDRI明示（RACI）・時間SLA付きエスカレーション・決定の可逆性に応じたプロセスの重さの可変化（one-way/two-way door）・共通軸でのトレードオフスコアリング・ADRによる根拠の文書化という5点セットで初めて、42日かかった対立を数日単位に短縮できる恒久対策になる。 決定を「早く」下すことと「安全に」下すことはトレードオフに見えるが、可逆性で分岐させることで両立できるという発想が、シニアエンジニアからPM/CTOへのキャリアで最も価値の見せどころになる。
次のステップ
- 発展問題: 緊急シンクでDRI（MOpsテックリード）が下した決定に対し、要望元チームのPMが「自分たちのビジネス影響を過小評価している」と不満を持ち、DRIの判断を覆すべくEM経由で再エスカレーションを試みたとする。このとき、（1）一度確定した決定を覆すための正式な再審査プロセスをどう設計するか、（2）再審査の乱発によってDRIの権威が形骸化するリスクをどう防ぐか、の2点を踏まえた運用ルールを設計せよ。
- 参考: RACIマトリクス / DRI（Directly Responsible Individual）/ ADR（Architecture Decision Record）/ one-way door・two-way door（Amazon, Jeff Bezos）/ エスカレーションSLA設計