発注側リーダーのためのRACI活用と契約設計で防ぐ責任分界の混乱

会議の空気が重くなります。連携テストでAPIが時間切れ、アプリのA社は「インフラのスロットルが原因です」、インフラのB社は「ミドルの設定はC社の領域です」、テスト支援のD社は「試験仕様が確定していないので評価できません」。上長からは「結局、誰の責任？」とだけ問われ、あなたは社内説明のために「切り分け中」「関係者と調整中」という言葉を並べるしかない——そんな場面は珍しくありません。

本記事では、この「責任の空白」がなぜ起きるかを現場目線で整理し、明日から会議でそのまま使えるRACIの当て方と、契約での「連携責任の一本化」設計を提示します。

現場で起きる「責任の空白」：複数ベンダー案件の典型的な崩れ方

複数ベンダー体制では、設計・構築・連携・テスト・運用に分業が走ります。机上では「各社の役割は定義済み」と言いますが、実際に問題が起きるのは役割の境目です。とくに次の3つの場面で崩れます。

• 連携仕様の最終判断者が不在
  • APIのタイムアウト値、リトライ回数、エラーハンドリングなど、どちらが主導で決めるかが曖昧です。
  • 会話例：「A社の設計に合わせます」「いや、インフラのポリシーに合わせるべきです」→結論保留が積み上がる。
• 切り分けの一次対応が宙ぶらりん
  • 障害発生時、「まずログをどこが集め、仮説を誰が出し、誰が他社に依頼するのか」が決まっていません。
  • 会話例：「相手側のログがないと見れません」「では先に相手の調査を待ちます」→48時間が平気で溶けます。
• リリース可否の「責任を持って決める人」がいない
  • テスト支援ベンダーは結果を報告するだけ、アプリ・インフラは自領域の合格だけを主張。全体の合否判断が滞ります。
  • 上申資料は「未合意事項一覧」が膨らみ、経営は「いつ終わる？」とだけ詰め、現場は疲弊します。

失敗すると、その後はこう悪化します。

• 追加見積もりとスケジュール延伸の連鎖
• 「相互調整」「切り分け支援」が都度見積もり対象になり、予備費が尽きます。延長の根拠も割れます。
• ベンダー間の不信と情報遮断
• 自領域の防衛行動が強まり、共有すべきログや設計意図が出てこなくなります。「言った・言わない」が増えます。
• 社内政治の悪化
• 経営・情報システム部・業務部の間で「誰が決めるか」の議論に摩耗し、重要な仕様判断が先送りされます。

ここで必要なのは、「責任の定義を成果物・イベント単位に落とすこと」と「契約で連携責任の一本化を設計すること」の2点です。肩書きや会社名レベルの役割定義では現場は動きません。

原理は「RACI×契約（連携責任の一本化）」だけ

まず「RACI」を平易に整理します。RACIは作業や成果物ごとに責任の種類を割り当てる手法です。

• 実行者（Responsible、R）：手を動かしてやる人。複数いてよいです。
• 最終責任者（Accountable、A）：結果に責任を持ち、決める人。必ず1つにします。
• 相談先（Consulted、C）：レビューや助言をする人。双方向コミュニケーションです。
• 通知先（Informed、I）：結果を受け取る人。一方向の連絡です。

重要なのは、RACIを「部署やベンダーの大枠」で書かないことです。「APIタイムアウト値の決定」「疎通試験の再試験基準」「障害一次切り分け手順の作成」といった具体的な成果物・イベント単位に落とすと機能します。さらに、Aは必ず1つに絞る——この原理だけは譲らないでください。Aが複数だと意思決定が止まります。

次に契約設計です。RACIだけでは「やると言ったが、どこまで無償か」「他社待ちで遅れたら誰の責任か」をカバーできません。契約で次を明文化します。

• 連携責任の一本化（Integration Lead Vendor）
  • ベンダーのうち1社を「連携責任者」と指名します。連携仕様の整合、切り分けの一次窓口、他社調整を負わせます。
• お金：調整に関わる一定ボリュームを基本契約に含める（例：X人日まで含む）。超過は事前合意で別精算。
• 時間：切り分けSLA（初動2時間、暫定見解24時間、原因特定72時間など）を定義。
• 社内政治：経営への説明は「一本の喉（One throat to choke）」で通せます。責任追及先が明確です。
• 境界の定義単位を「インターフェース」と「運用イベント」にする
  • 単に「アプリはA社、インフラはB社」ではなく、「API Xのスロットル設定」「監視アラートYの一次対応」など粒度で定義。
• 連携試験・受入の最終責任者を発注側に置く
  • 合否のAは発注側が持ちます。Lead Vendorは判定提案をR、他社はC/I。この設計で裁定が早まります。

この2本柱で「誰が決め、誰が動き、どこまでが契約範囲か」を同時に固めます。結果として、見積もりの透明性が上がり、スケジュールの確度が上がり、社内説明が短くなります。

そのまま使えるフォーマットと話法（RACI表・合意メモ・メール文例）

まずは会議で配れる1枚フォーマットです。5つのルールとセットで使います。

• 記入ルール
  • Aは各行で1つ。迷ったら決めるまで次に進まない。
  • 成果物・イベント単位で書く（「疎通試験」「障害一次切り分け手順」など）。
  • ベンダー名で列を作る。発注側も1列にする。
  • 注記欄に「契約に含む/別精算」「SLA」を書く。
  • 会議の最後に「未定（TBD）」をゼロにする。

RACIひな形（例：基幹刷新の一部）

成果物/イベント	発注側	A社(アプリ)	B社(インフラ)	C社(連携)	D社(テスト)	注記
API仕様書（X系）	A	C	I	R	I	連携Lead=C社。レビュー工数は基本契約内で8h/IF
タイムアウト値の決定	A	C	C	R	I	C社が提案、発注側が決定
接続試験計画	A	C	C	C	R	再試験基準はD社起案、発注側承認
疎通試験（実施）	I	R	R	R	C	実施窓口はC社。調整は契約内4h/日まで
性能試験（統合）	A	R	R	C	R	合否判定は発注側
障害一次切り分け（手順作成）	A	C	C	R	I	切り分けSLA：初動2h/暫定24h/確定72h
障害一次切り分け（本番時）	I	C	C	A/R	I	連携Leadが一次窓口／他社へ依頼
監視アラート設定	A	I	R	C	I	監視設計変更はB社R、C社C
リリース判定会	A	C	C	R	C	C社が判定案作成、発注側が決定

1ページ合意メモ（配布用テンプレ）

• タイトル：責任分界合意メモ（v1.0／日付）
• 目的：連携領域の責任分界と初動SLAを明確化し、遅延と追加見積もりを防止する。
• 範囲：本メモはXシステム刷新の「連携・テスト・運用初期」フェーズに適用する。
• 主要合意
  • 連携責任者（Integration Lead Vendor）：C社
  • 切り分けSLA：初動2h／暫定見解24h／原因確定72h
• 追加費用ルール：切り分け・調整は各インシデントあたりY時間まで契約内。超過は事前合意。
  • 情報共有：各社は対象ログを事件発生2時間以内にLeadへ提供。
  • エスカレーション：SLA未達時は発注側PMに直通。翌営業日中に是正計画提出。
  • 添付：RACI表（最新版）

会議でのセリフ例
「この行のAが未確定です。Aが決まるまで次に進めません。Aは1つだけです。どちらが持ちますか？」
「この判断は『タイムアウト値の決定』という成果物に分解しましょう。C社が提案のR、発注側がAで決定します。」
「切り分けSLAに沿って、今ここで『初動2時間の証跡』を確認します。リードはC社、依頼はB社にCでお願いします。」
「本件は連携Leadの契約内調整時間を超過しそうです。超過見込み時点で事前合意に切り替えます。」

ベンダーへの依頼メール文例（抜粋）

件名：【責任分界の確定】X刷新_連携領域RACI（承認依頼）
本文：
A社、B社、C社、D社 各位

添付のRACI（v1.2）について、未定の3項目にAの割付が必要です。明日17時の会議で確定し、合意メモ（v1.0）を発行します。異議がある場合は根拠（契約・設計・リスク）を添えて本日中に返信ください。
なお、連携LeadはC社で合意済みです。切り分けSLA（初動2h／暫定24h／確定72h）を適用します。

発注側PM：□□

契約条項の叩き台（要点）

• 連携責任者（Integration Lead Vendor）条項
• 役割：他ベンダーとの連携仕様整合、切り分け一次窓口、エスカレーション実施。
• 対価：月次X時間の調整・切り分けを基本料金に含む。超過は発注側事前承認の上、レートY円/時。
• SLA：初動2h／暫定見解24h／原因確定72h。未達時のペナルティまたは是正計画提出義務。
• 相互協力義務とログ提供義務
  • 事件発生後2時間以内に要求ログを提供する義務。機微情報はマスキングのうえ提供。
• 受入とリリース判定
  • 合否の最終責任（A）は発注側に帰属。Leadは判定案の提出義務（R）。

事例への当てはめ：混線した連携不具合をRACIと契約で捌く

事例設定
– 体制：A社（アプリ）、B社（インフラ）、C社（連携）、D社（テスト支援）
– 事象：統合テストでAPI呼び出しがタイムアウト。A社は「B社のネットワーク制限」と主張、B社は「アプリのスレッド不足」と主張。D社は「再試験基準が未確定」。C社は「仕様どおり」と静観。

【よくある展開】
– 会議は原因論争で1時間消費。誰も初動の役割を引き受けません。
– 「それぞれ持ち帰って調査」で2日が過ぎる。ログはフォーマットも保管場所もバラバラ。
– テストは保留、経営には「相互調整中」と報告。A/B/Cから小口の追加見積もりが上がる。

【RACI×契約を適用】
– 事前にC社を連携Leadとして契約済み。RACIで「障害一次切り分け（本番同等）」のA/RをC社に割付。SLAも合意済み。
– 発生0〜2時間
– C社が一次窓口として全社のログ収集を主導（R）。A社・B社はCで協力し、要求ログを2時間以内に提出（契約義務）。
– 発注側PMはIで通知を受けるのみ。動きません。判断に集中します。
– 発生〜24時間
– C社が暫定見解を提出。「ネットワークのRTTは正常。アプリ側の非同期処理の枯渇が疑い。再試験はスレッド数N→2Nで実施提案」（提案のR）。
– D社は再試験計画の更新（R）。再試験基準は発注側（A）が承認。
– 24〜72時間
– 再試験で改善を確認。C社が原因確定報告書を提出。「原因：A社アプリの接続プール設定。対策：本番はMに設定。監視閾値の追加」（R）。
– 発注側が受入判定（A）。A社は設定変更を実施（R）。B社は監視閾値の適用（R）。
– 結果
– 切り分けは3日で完了。追加見積もりは「Leadの調整時間内」に収まり、ゼロ精算。
– 社内報告は「Leadが一次対応、原因確定、対策実施、受入承認済み」と一本化。経営からの追及も最小。

この差は、「Aが誰か」「初動SLAがあるか」「契約で調整が対価に含まれているか」の3点に尽きます。RACI表と合意メモを事前に持っているだけで、会議の質とスピードが別物になります。

まとめ

• 複数ベンダーの失敗は、領域の境目でA（最終責任者）が不在になることから始まります。
• 対策は「RACIを成果物・イベント単位で切る」「契約で連携責任を一本化する（Lead＋SLA＋対価）」の2点に絞ります。
• 1ページの責任分界メモとRACI表、SLAを会議と契約の両方に埋め込むことで、お金・時間・社内政治の摩耗を減らせます。
• 明日1つだけやるなら、次回の打合せ冒頭で「未定のAをゼロにする」RACIワークを30分でやり切ってください。Aが決まれば、現場は動きます。

参考リンク
– https://www.atlassian.com/team-playbook/plays/raci-matrix
– https://www.pmi.org/learning/library/responsibility-assignment-matrix-ram-7785
– https://www.gov.uk/service-manual/agile-delivery/working-with-suppliers
– https://www.meti.go.jp/press/2020/07/20200710002/20200710002.html