システム開発 発注者の体制の作り方｜RACI表で役割分担を明文化する手順

「貴社側の体制図と役割分担表を提出してください」とベンダーから依頼を受けて、手が止まってしまった経験はないでしょうか。組織図にある肩書きを並べることはできても、誰が最終承認者で、どこまでが自社の責任でどこからがベンダーの責任なのか、いざ書き出そうとすると言葉に詰まってしまう。前回のプロジェクトで承認者が会議に出てこず、決定が宙に浮いて炎上した記憶がよみがえり、同じ失敗を繰り返したくない一心で情報を探している──そんな状況の方も多いはずです。

特に中堅企業では、専任のPMOやプロジェクトマネジメント経験者が社内にいないことが珍しくありません。事業部から「基幹システム刷新のプロジェクトリーダーをお願いしたい」と任命された情シス担当者が、業務知識のある事業部メンバーとインフラ寄りの自部門メンバーを寄せ集めて体制を組まなければならない、という状況はよくあるパターンです。

問題は「体制図を書くこと」自体ではありません。本当の論点は「自社内で誰が何を決めるのかを言語化できていない」ことと、「ベンダーとの責任境界を文書として残せていない」ことの2点です。これを曖昧にしたままキックオフを迎えると、要件定義の途中で「これは誰が決めるんでしたっけ」が繰り返され、最悪の場合は受入テストの直前に経営層から「聞いていない」と差し戻されます。

本記事では、システム開発の発注者として体制をどう作るべきかを、肩書きの羅列ではなく「責任の明文化」というアプローチで解説します。中心になるのは、各タスクごとに役割を割り当てるRACI表という考え方です。発注者側の登場人物の整理から、要件定義から受入までのフェーズ別RACI表の具体例、5ステップでの作成手順、ベンダー提出物のレビュー観点、そして発注者が陥りがちな5つの失敗パターンとその回避策まで、キックオフ前夜に必要な実務情報をひと通りまとめました。

読み終えた頃には、自社の登場人物をRACI表に落とし込み、ベンダーに対して「この部分は当社が決めます」「ここはお任せします」と明確に説明できる状態を目指せるはずです。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

なぜ発注者側のプロジェクト体制づくりがシステム開発成否の分かれ目になるのか

システム開発のプロジェクトでは、しばしば「ベンダー選定さえうまくいけば成功する」という誤解が語られます。しかし実際には、発注者側の体制が曖昧なまま走り出したプロジェクトは、どれだけ優秀なベンダーを選んでも途中で停滞してしまいます。なぜ発注者側の体制づくりが、システム開発の成否を分ける最初の分岐点になるのかを整理しておきましょう。

発注者側で体制が曖昧だと起きる4つの典型的トラブル

発注者側の体制が言語化されていないプロジェクトでは、おおむね次の4つのトラブルが起きます。

1つ目は「決裁の停滞」です。要件定義で論点が浮上したとき、誰が最終判断するのかが決まっていないと、関係者の意見調整に時間がかかり、ベンダー側のスケジュールを圧迫します。

2つ目は「要件のブレ」です。現場担当者・部門長・経営層がそれぞれ異なる優先順位で発言し、その都度ベンダーが仕様を修正することになります。結果として開発フェーズに入ってから「やっぱりこの機能が必要だった」が頻発します。

3つ目は「受入判断の宙づり」です。検収のタイミングで「誰がOKと言えば本番稼働できるのか」が決まっていないと、現場の声・情シスの声・経営層の声がぶつかり、稼働判断ができなくなります。

4つ目は「ベンダーへの責任丸投げ」です。発注者が何を担い、何をベンダーに任せるかの線引きがないまま走ると、トラブル発生時に「これは御社の責任では」「いえ、貴社で決めていただく前提でした」という押し付け合いに発展し、追加費用や納期遅延の原因になります。

これら4つは個別の事故ではなく、いずれも「責任の所在が文書化されていない」という同じ根に由来しています。

「体制図」と「役割分担」は別物──肩書きを並べるだけでは何も決まらない

ここで一度、用語を整理しておきます。「体制図」と「役割分担」は混同されがちですが、両者は別物です。

体制図は、プロジェクトに関わる組織や人をビジュアルで示したものです。役職名や所属部署、レポートライン（指揮命令系統）を表現します。一方の役割分担は、「どのタスクを、誰が、どのような関わり方で担うか」を定義したものです。

ところが現場では、組織図を少し編集した程度の「体制図」を提出して終わり、というケースがよく見られます。肩書きが並んでいるだけで、要件定義で論点が浮上したときに誰が決めるのか、テスト工程で不具合が見つかったときに誰が判断するのかは、その図からは一切読み取れません。上司から「これじゃ前回の二の舞だぞ」と差し戻される体制図は、たいていこのパターンです。

肩書きを並べただけでは、プロジェクトは何も前に進みません。必要なのは、タスク単位で「誰が決めるのか・誰が手を動かすのか・誰に相談すべきか・誰に報告すべきか」を一目で読み取れるドキュメントです。

発注者側体制を「整える」とはどういう状態か

では発注者側の体制が「整っている」とは、具体的にどういう状態を指すのでしょうか。本記事では、次の3点を満たす状態を到達目標とします。

第一に、プロジェクトのすべての主要タスクについて、最終承認者が1人に絞られていることです。会議の議事録に「事業部長と情シス部長の協議の上、決定する」のような曖昧な書き方が残っていないことが目安です。

第二に、発注者側とベンダー側の責任境界が、フェーズごとに文書化されていることです。たとえば「要件定義は発注者側PMが取りまとめる」「設計はベンダー側SEが主導し、発注者は承認のみ」のように、誰が主体で誰が脇役かを誰もが説明できる状態を指します。

第三に、上記2点がキックオフ前に関係者の合意を得られた状態で、文書として残っていることです。口頭やSlackのやり取りで合意しただけでは、人事異動や担当者変更ですぐに崩れます。

この3点をまとめて表現するのに、最も実用的なのが「システム開発 発注者 体制 作り方」の中核となるRACI表です。次の章から具体的な作り方に入っていきます。

発注者側プロジェクト体制の典型パターン（登場人物と役割）

RACI表を埋める前に、まず発注者側にどんな登場人物がいるべきかを整理しておきましょう。中堅企業のシステム開発プロジェクトで典型的に登場する6つの役割と、それぞれが「何を決め・何をし・何を確認する」のかを順に見ていきます。

プロジェクトオーナー（経営層・事業部長）の役割──最終承認者は1人に絞る

プロジェクトオーナーは、プロジェクトの最終承認権限を持つ人物です。具体的には、予算の承認、スコープ変更の最終判断、本番稼働の最終GoサインなどがオーナーのR・A（実行責任・承認責任）に該当します。

よくある誤りは、「事業部長と情シス部長の合議制」「複数役員の協議で決定」といった形でオーナーを複数置いてしまうことです。これでは、いざ判断が必要になった瞬間に「両者の意見を聞かないと決められない」状態になり、決裁が停滞します。

オーナーは必ず1人に絞り、その人物の不在時に誰が代理判断するか（デリゲーション先）も併せて決めておきましょう。代理判断の権限範囲（金額・スコープ）も明示するとさらに堅牢です。

発注者側PMの役割──情報の集約と意思決定の前さばき

発注者側PMは、プロジェクトの現場指揮官です。ベンダーとの定例会議への参加、社内関係者からの情報集約、論点の整理と意思決定者への打診、議事録の管理など、プロジェクト運営の実務を担います。

ここで重要なのは、発注者側PMは「実行責任者」であって「最終承認者」ではないという点です。発注者側PMの仕事は、論点を整理してオーナーが判断できる形に持っていくことであり、自分で全部決めることではありません。この線引きが曖昧だと、後述する「PMが事実上2人いる」状態に陥りやすくなります。

中堅企業では、情シス部門のリーダーや業務改革推進担当者が兼任することが多いポジションです。プロジェクト管理の発注者役割分担を考えるうえで、最も忙しくなる役回りでもあります。

業務担当・現場代表の役割──業務要件のオーナー

業務担当は、対象業務を実際に担っている現場の代表者です。新しいシステムが「業務として何ができれば成功か」を定義する責任を持ちます。

要件定義フェーズでは業務担当が主役になります。ベンダーが業務ヒアリングを行う際の窓口であり、業務フロー図のレビュー責任者でもあります。受入テストの計画立案・実施にも深く関わります。

業務担当を選ぶときは、業務に精通しているだけでなく、プロジェクトに割ける時間を事前に確保できる人物を選ぶことが重要です。「業務が忙しくて要件定義の会議に出られない」状態になると、要件のブレが一気に進みます。

情シス担当の役割──既存システム・インフラとの整合性チェッカー

情シス担当は、既存システム・既存インフラとの接続性、セキュリティ、運用引き継ぎの観点でプロジェクトに関与します。新システムが既存のID基盤・ネットワーク・データ連携の仕組みと矛盾しないかを確認するチェッカーの役割です。

中堅企業では、情シス担当が発注者側PMを兼任することも珍しくありません。その場合は「PMとしての視点」と「情シス担当としての視点」を意図的に切り替えて考える必要があります。両者を混ぜると、技術的な細部にこだわりすぎてプロジェクト全体の論点を見失う、という事態が起きます。

PMOを置くべきケース・置かなくてよいケース

PMO（プロジェクトマネジメントオフィス）は、プロジェクトの進捗管理・課題管理・文書管理を専門に行う支援機能です。大規模なプロジェクトや、複数のサブプロジェクトが並走する場合に効果を発揮します。

中堅企業の単一プロジェクトであれば、必ずしもPMOを置く必要はありません。発注者側PMが進捗・課題・文書を直接管理するほうが、コミュニケーションのオーバーヘッドを減らせる場合が多いからです。

PMOを置くべきケースの目安は、(a) 関係部門が5部門以上にまたがる、(b) サブプロジェクトが3つ以上並走する、(c) プロジェクト期間が1年以上、のいずれかに当てはまるケースです。これらに該当しない場合は、PMOを置かずにシンプルな体制でスタートすることをおすすめします。

受入担当（UAT責任者）の役割──稼働判断の最終ゲート

受入担当は、受入テスト（UAT）を計画し、結果に基づいて本番稼働の可否を判断する役割です。業務担当が兼任することもありますが、責任範囲が「業務要件の定義」と「稼働可否の判断」では大きく性質が違うため、可能であれば別人を立てることをおすすめします。

受入担当のもっとも重要な仕事は、「何ができていれば稼働OKか」という受入基準を、要件定義の段階で言語化しておくことです。テスト工程に入ってから基準を決めようとすると、「あれもこれも完璧でなければ稼働させたくない」という心理が働き、稼働判断が無限に先送りされます。

中堅企業向けの最小体制例

中堅企業（従業員100〜500名規模）の基幹システム刷新プロジェクトであれば、次の最小体制から始めることが現実的です。

• プロジェクトオーナー: 事業部長または担当役員（1名）
• 発注者側PM: 情シス担当または業務改革推進担当（1名）
• 業務担当: 対象業務の現場リーダー（2〜3名）
• 情シス担当: 情シス部門のインフラ・運用担当（1〜2名）
• 受入担当: 業務担当のうち1名が兼任、または別途任命（1名）

PMOは置きません。関係部門が増えたり、サブプロジェクトが増えたりした場合に追加を検討します。この最小体制が、次の章で扱うRACI表の「発注者側ロール」のベースになります。

RACI表とは何か──R/A/C/Iの定義と「Aを1人に絞る」鉄則

ここからが本記事の中心です。プロジェクト管理における発注者の役割分担を実用レベルに落とし込むツールとして、RACI表という考え方を紹介します。

RACI表（RACIチャートとも呼ばれます）は、プロジェクトのタスクごとに、関係者一人ひとりがどう関わるかを記号で示したマトリクスです。R/A/C/Iの4つの記号の意味を理解すれば、誰でも作れるシンプルなツールです（汎用的な定義はAsana の RACI チャート解説などにもまとまっています）。

R/A/C/Iそれぞれの意味──「実行」と「承認」と「相談」と「報告」を分ける

RACIの4文字は、それぞれ次の意味を持ちます。

ポイントは、「実行」と「承認」を分ける、そして「相談」と「報告」を分ける、という2つの区別です。

実行と承認を分けるとは、「手を動かす人」と「OKを出す人」を別人格として扱うことです。発注者側PMが要件定義書を書く（R）一方で、その内容を最終承認するのは事業部長（A）、というように分けます。両方を同一人物が担うことは可能ですが、役割としては別物だと意識することが重要です。

相談と報告を分けるとは、「議論に巻き込むべき人」と「結果だけ伝えればよい人」を区別することです。すべての関係者を相談先（C）にしてしまうと、レビュー会議が膨らみすぎて意思決定が遅延します。報告先（I）でよい人は明確にIに置き、レビューの輪に引き入れないことが大切です。

RACIの3つの鉄則

実務でRACI表を機能させるには、次の3つの鉄則を守る必要があります。

1つ目は「Aは1タスク1人」という鉄則です。最終承認者を複数置いた瞬間に、判断が宙に浮きます。これがRACI最大のルールです。

2つ目は「Rは複数可」という補足ルールです。実行責任者は1人でも複数でも構いません。要件定義書の作成を、業務担当2名と発注者側PM1名の合計3名で分担する、というのは普通にあり得る形です。

3つ目は「全タスクに最低1人のAが必要」というチェックポイントです。RACI表を埋め終わったら、Aの欄が空白になっているタスクがないかを必ず確認します。Aが空白のタスクは「誰の責任でもないタスク」となり、後で必ず問題が発生します。

発注者プロジェクトでありがちなRACI誤用

発注者がRACI表を作る際にやりがちな誤用が3つあります。

ひとつめは「Aを複数置く」です。たとえば「事業部長と情シス部長の合議でA」と書いてしまうケース。これはAではなく、事業部長をAにして情シス部長をCに置くのが正しい構造です。

ふたつめは「Cを大量に並べる」誤用です。関係者全員に意見を聞きたい気持ちは分かりますが、Cを5名以上置くとレビュー会議が破綻します。本当に意見が必要な人だけをCにして、それ以外はIに回しましょう。

みっつめは「Iを忘れる」誤用です。報告先を定義していないと、「あの件、知らされていなかった」「うちには関係ないと思っていた」というすれ違いが発生します。とくに経営層や他部門の長は、明示的にIに置いておくことを推奨します。

このRACI表を、自社の発注者プロジェクトに当てはめていきます。発注側のRACI表を扱う記事は数多くありますが、システム開発の発注者×ベンダー文脈に絞った具体例は意外と見つかりません。次の章で、フェーズ別の具体例を提示します。

発注者×ベンダーの役割分担をRACI表で明文化する（フェーズ別実例）

ここからが本記事の主役パートです。要件定義から受入までの各フェーズで、発注者側ロールとベンダー側ロールの責任分担をRACI表に落とし込みます。プロジェクト管理で発注者の役割分担に悩んでいる方は、この表をたたき台として自社に持ち帰ってください。

フェーズ別RACI表の全体像（マスターテーブル）

まず、全フェーズを俯瞰したマスターテーブルを示します。横軸に発注者側ロール（オーナー／発注者側PM／業務担当／情シス担当／受入担当）とベンダー側ロール（ベンダーPM／SE／PG）を、縦軸にフェーズの代表タスクを並べました。

この1枚があれば、キックオフでベンダーと「どこからどこまでが当社の仕事か」を整理する素材になります。以下、フェーズごとに表を読み解いていきましょう。

要件定義フェーズのRACI──業務要件は発注者がオーナー

要件定義フェーズでは、業務要件の定義を発注者が主体的に担います。「ベンダーがヒアリングしてまとめてくれる」と思っていると、後で「自社が言いたかったこと」と「ベンダーが書いた要件」のズレが噴出します。

このフェーズのRACI表の読み方は次の通りです。

業務要件と機能要件の最終承認者（A）は発注者側PMです。業務担当が実行責任者（R）として業務フローや機能の使い勝手を定義し、発注者側PMがそれをレビューして要件定義書としてまとめます。ベンダー側SEはCの立場で、技術的に実現可能か・他要件と矛盾しないかを助言します。

非機能要件は少し特殊で、性能・可用性・セキュリティの観点が中心になるため、情シス担当をRに、ベンダーSEもRに置く構成にしています。両者の協議の結果を発注者側PMが承認する形です。

要件定義書全体の最終承認はオーナー（事業部長等）のAになります。ここを「事業部長と情シス部長の合議」にしてしまうと、後でスコープ変更が発生したときに毎回両者の調整が必要になり、プロジェクトが停滞します。

設計フェーズ（基本設計・詳細設計）のRACI──発注者は「レビュー＆承認」に徹する

設計フェーズに入ると、主役はベンダーに移ります。発注者の役割は、ベンダーが作成した設計書をレビューし、業務要件を満たしているかを確認することに集中します。

基本設計書のレビューでは、発注者側PMがAとして承認の最終責任を持ち、業務担当と情シス担当がCとして観点別のレビューを担います。詳細設計に入ると業務担当の関与は薄まり、画面・帳票など業務担当が判断すべき部分だけ別タスクとして切り出して関与してもらうのが現実的です。

ここで重要なのは、発注者が「設計の細部まで自分たちで決める」モードに入らないことです。基本設計の妥当性レビューを丁寧に行うことは大切ですが、ベンダーが提案した技術的な実装方式に過剰に介入すると、ベンダーの責任範囲が不明確になります。発注者の関与は「業務要件を満たしているか」「既存システムと整合しているか」の2点に絞るのが基本姿勢です。

開発フェーズのRACI──発注者の関与は「報告受領」と「随時相談先」中心

開発フェーズは、発注者が最も「待つ時間」になるフェーズです。ベンダーがほぼ全てのR・Aを担い、発注者はIとして週次・隔週の進捗報告を受領するのが基本構造になります。

ただし発注者が完全に手を放してよいわけではありません。開発中にベンダーから出てくる「仕様の解釈確認」や「軽微な仕様変更の相談」には、発注者側PMがAの立場で迅速に回答する責任があります。回答が遅れると、ベンダー側で勝手な解釈が進み、後で「言った・言わない」のトラブルになります。

進捗報告の受領は発注者側PMがAです。報告会議でリスクや遅延の兆候が見えたら、即座にオーナーへのエスカレーションを判断する役割でもあります。なお、開発が予定通り進まずプロジェクトに大きなリスクが出てきた場合の対応方針については、プロジェクトリスク管理ガイド（発注者が知るべき4つのリスクと対策）も参考になります。

テスト・受入フェーズのRACI──UATは発注者が主役に戻る

テスト・受入フェーズでは、発注者が再び主役に戻ります。とくに受入テスト（UAT）は、発注者が「業務として使えるかどうか」を判定する場であり、発注者の関与が薄いと本番稼働後の運用トラブルにつながります。

受入テストの計画策定と実施の最終承認者（A）は受入担当です。業務担当がRとして実際にテストケースを実行し、不具合を発見します。

注目すべきは、本番稼働判定のRACIです。Aはプロジェクトオーナーで、Rに発注者側PMと受入担当の2名を置いています。これは「現場の受入判断（受入担当）」「プロジェクト全体の品質判断（発注者側PM）」の2つの観点を、オーナーが最終的に統合して承認するという構造を示しています。ここを曖昧にすると、稼働判定の会議で「結局、誰がGoサインを出すんですか」が起きやすくなります。

表を作る際の粒度の決め方──タスクが細かすぎても粗すぎてもうまくいかない

ここまで提示したRACI表は、フェーズ別に5〜10タスク程度の粒度でまとめています。実務でRACI表を作るときの粒度の決め方を補足しておきます。

粒度の目安は「成果物が1つ生まれるごとに1行」です。要件定義書・基本設計書・詳細設計書・テスト計画書・テスト結果報告書のような、形に残る成果物を縦軸に置くと、レビュー漏れも起きにくくなります。

逆に避けたいのは「画面ごとに1行」のような細かすぎる粒度です。中規模システムで画面数が30面ある場合、RACI表が30行を超えて管理不能になります。同様に、「要件定義」「設計」「開発」のような大粒度すぎる行も、結局誰が何をするかが見えなくなるため避けてください。

迷ったら、本記事のマスターテーブルをたたき台として、自社で追加・削除しながら20〜30行に収まる範囲で整える、というアプローチが現実的です。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

発注者側RACI表の作り方（5ステップ）

ここからは、自社のRACI表を一から作るための5ステップを示します。RACI表の作り方は、IT・システム開発の文脈であっても基本的な手順は変わりません。順番を間違えないことが、表を機能させる最大のコツです。

ステップ1──プロジェクトの主要タスクを洗い出す

最初にやるのは、タスクの洗い出しです。フェーズ別RACI表の章で示したマスターテーブルをたたき台にして、自社のプロジェクトに固有のタスクを追加・削除します。

タスク洗い出しの観点は次の3つです。

• フェーズごとの代表的な成果物が含まれているか（要件定義書・設計書・テスト計画書など）
• 自社固有のイベント（経営会議への報告・社内研修・運用引き継ぎ）が含まれているか
• 既存システムとの連携・データ移行など、技術的なマイルストーンが含まれているか

この段階では、誰が担当するかは考えなくて構いません。タスクの一覧を完成させることに集中しましょう。20〜30行に収まる粒度を目安にします。

ステップ2──発注者側・ベンダー側の登場人物を列挙する

次に、横軸の登場人物を埋めます。発注者側は、本記事の登場人物セクションで挙げた6つの役割（オーナー／発注者側PM／業務担当／情シス担当／受入担当／必要に応じてPMO）から、自社に必要なものを選んで配置します。

ベンダー側は、ベンダーPM・SE・PGの3区分で十分です。実際の体制では「ベンダーPM＋PMO」「上級SE＋若手SE」のように細分化されていますが、RACI表上は3区分でまとめておくほうが管理しやすくなります。

このステップで重要なのは、「役割名」を書くのか「個人名」を書くのかをチームで揃えることです。役割名で書くと人事異動に強い一方、誰が担当か瞬時には分かりません。個人名で書くと分かりやすい一方、異動・退職で更新が必要になります。中堅企業では「役割名（兼任者: 個人名）」のような併記が実用的です。

ステップ3──A（最終承認）を先に埋める

横軸と縦軸が決まったら、いよいよ表を埋めます。ここで最重要なのが、「A（最終承認）から先に埋める」というルールです。

なぜAから埋めるのか。理由は、Aが最も揉めるからです。「業務要件の最終承認は誰か」「本番稼働判定は誰が出すのか」といった論点は、関係者の意見が分かれやすく、決めるのに時間がかかります。RやCから埋めていくと、Aを決める頃にはタイムアップになり、結局曖昧なまま残ってしまうのです。

Aを埋める際は、「Aは1タスク1人」の鉄則を必ず守ります。複数人で迷ったら、その場で決め切ることが大切です。決められない場合は、その場でオーナー（事業部長など）に判断を仰ぎ、決着をつけてから次のタスクに進みます。

すべてのタスクのA列が埋まった時点で、表の骨格は完成です。

ステップ4──R（実行）・C（相談）・I（報告）を埋める

Aが埋まった後は、R・C・Iの順で埋めていきます。

Rは「そのタスクを実際に進める人」です。1人でも複数でも構いません。Aと同一人物が兼任することも可能です。

Cは「そのタスクの判断・遂行に意見を反映すべき人」です。ここで重要なのは、Cを多くしすぎないことです。1タスクあたりCは2〜3名までを目安にしましょう。「念のため聞いておこう」という発想でCを増やすと、レビュー会議が膨らみ意思決定が遅延します。

Iは「結果だけ知らせれば足りる人」です。とくに経営層・他部門長・運用部門の代表は、明示的にIに置きます。漏れがちなのは、運用引き継ぎ先の保守チームや、関連プロジェクトの担当者です。

すべての欄が埋まったら、Aの空白がないか・複数Aがないかを最終確認します。

ステップ5──ベンダーとレビュー会議を行い、合意形成して文書化する

自社内でRACI表が完成したら、最後にベンダーとのレビュー会議を行います。発注者が一方的にRACI表を作って渡すのではなく、ベンダー側ロール（ベンダーPM・SE・PG）の部分を一緒にレビューし、合意形成することが重要です。

レビュー会議では次の論点を確認します。

• ベンダーPM・SE・PGのR/A/C/I配置に過不足はないか
• 発注者側がIになっているタスクで、本当はCに置くべきものはないか
• 障害発生時・スコープ変更時のエスカレーションルートはRACI表で読み取れるか

合意形成できた表は、プロジェクト計画書の付属資料として正式に文書化します。可能であれば、ベンダーとの契約書類に添付する形にすると、後の責任境界の議論が格段に楽になります。Excelで作る・スプレッドシートで共有する・プロジェクト管理ツールに格納する、いずれの運用でも構いませんが、「最新版がどこにあるか」を関係者全員が把握できる場所に置くことが大切です。

ベンダー提出の体制図・役割分担表をレビューする観点

ここまでは発注者側でRACI表を作るアプローチを解説してきました。実務ではこれと並行して、ベンダー側から提示される体制図・役割分担表をレビューする場面が頻繁にあります。ベンダー提出物を鵜呑みにせず、発注者として確認すべき観点を5つに整理します。

ベンダー提出体制図でチェックすべき5観点

ベンダーから提出される体制図・役割分担表は、ベンダーにとって都合のよい構造で書かれていることがあります。悪意があるわけではなく、ベンダーは自社の働き方に基づいて図を書くため、発注者視点での違和感が残るのは自然なことです。発注者として次の5観点をチェックしましょう。

1つ目は「A権限の偏り」です。重要な意思決定がベンダー側のA（ベンダーPM等）に集まりすぎていないか、を確認します。たとえば「スコープ変更の最終承認: ベンダーPM」のような記載は、本来は発注者側PMまたはオーナーがAであるべきタスクです。

2つ目は「発注者の意思決定ポイントが過小評価されていないか」です。要件定義の承認・本番稼働判定など、発注者が主役になるべきタスクが「ベンダー主導・発注者承認」のような曖昧な書き方になっていないかを確認します。

3つ目は「連絡窓口の一本化」です。発注者から複数の問い合わせがバラバラにベンダーに入ると、情報が分散して品質が下がります。「発注者側PM ↔ ベンダーPM」のラインを正式な窓口として一本化し、それ以外の経路は補助的なものと位置付ける記述が体制図にあるかを確認しましょう。

4つ目は「障害時の責任者と連絡経路」です。本番稼働後の障害対応・運用引き継ぎ後の問い合わせ窓口・保守期間中のエスカレーション先が、体制図または別ドキュメントで明示されているかを必ず確認します。

5つ目は「サードパーティ連携先の明示」です。ベンダーがさらに外部のパートナーに一部の作業を再委託している場合、その関係性が体制図に表現されているかを確認します。再委託先が透明化されていないと、トラブル時に「誰がやった作業か」が追えなくなります。

ベンダーに修正を求めるべき典型的な記述例とその伝え方

上記の観点で気になる記述があった場合は、ベンダーに修正を依頼します。よくある典型例を、修正依頼の伝え方とあわせて示します。

「最終承認: 両社協議の上、決定する」と書かれている場合は、「タスクごとの最終承認者を1人に絞っていただけますか。具体的には、要件定義書の承認は弊社オーナーが、設計書の承認は弊社発注者側PMが行います」と返します。

「ベンダー側で適宜判断します」と書かれている場合は、「『適宜』の範囲を金額・スコープで具体化してください。弊社の承認が必要となる閾値（たとえば工数10人日以上、または機能スコープに関わる変更）を明文化したい」と返します。

「障害時の窓口: 営業担当」と書かれている場合は、「営業担当ではなく、技術的に判断・対応できる方を窓口に立てていただけますか。一次受付までの時間と、初動対応の責任者を分けて明記してください」と返します。

このように、ベンダー提出物のレビューは「より明確な表現に書き直してもらう」ためのものです。曖昧な記述を残したまま進めると、トラブル時に必ず損をするのは発注者側です。発注者が外部の開発会社にどう関与すべきかという観点では、発注者が担うべき3つの役割（任せきりにしないチェックリスト付き）もあわせて参考にしてください。

よくある発注者側体制設計の失敗パターンと対策

ここまでの内容を踏まえても、実際のプロジェクトでは発注者側体制の典型的な失敗が繰り返されます。発注者組織で頻発する5つの失敗パターンと、それぞれの原因・RACI表での具体的な回避策を示します。前回のプロジェクトでつまずいた経験のある方ほど、自社の状況と照らし合わせてご覧ください。

失敗1──「最終承認者」が会議に出ない／決められない

最も多い失敗が、最終承認者であるはずのオーナー（事業部長・役員）が要件定義の重要会議に出席せず、決定が宙に浮くパターンです。会議の翌週に「あの件、部長に確認したら待ったがかかった」が頻発し、要件定義の進捗が停滞します。

原因: 多くの場合、オーナーがプロジェクトの優先度を低く見積もっていることが根本原因です。日々の事業判断に追われ、システム開発プロジェクトを「情シス案件」として情シスに任せきりにしてしまう構造があります。

RACI表での回避策: Aの欄に置かれた人物は、そのタスクに関する重要会議への参加義務を持ちます。これを「Aの参加義務」としてRACI表の運用ルールに明記しましょう。あわせて、Aが出席できない場合の代理判断者（デリゲーション先）と、代理判断できる範囲（金額・スコープの上限）を事前に決めておきます。「Aが3回連続で会議を欠席した場合、代理判断者にA権限を一時的に移譲する」のようなエスカレーションルールを定めると、運用上の保険になります。

失敗2──PMが事実上2人いて意思決定が二転三転する

発注者側PMが正式には1名だが、事業部から「うちの代表として○○さんも入れてください」と要望が出て、結果として現場PM・部門PMの二頭体制になってしまうパターンです。両者が異なる優先順位で発言し、ベンダーへの指示が日替わりで変わります。

原因: 「PM」というラベルが、組織内で「窓口担当」「情報共有担当」「意思決定者」のどれを指すか定義されていないことが原因です。事業部から見ると「うちの意見を吸い上げる人」もPMに見えてしまいます。

RACI表での回避策: 「発注者側PM」の役割を「ベンダーとの調整権限・社内取りまとめ権限・スコープ変更の発注者側Aの担当者」と具体的に定義し、RACI表のA・R配置で唯一性を担保します。事業部代表は、業務担当（R）または相談先（C）として明示的に別ロールに置きます。「事業部代表は意見を出す立場であり、ベンダーへの指示・スコープ判断は発注者側PMを経由する」というルールも併記しましょう。

失敗3──現場が蚊帳の外で、受入テスト直前に反対が噴出する

要件定義から開発まで現場ユーザーがほぼ関与せず、受入テストの直前になって「これでは業務にならない」「現場の実態と違う」という反対意見が一斉に噴出するパターンです。最悪の場合、稼働延期や大規模手戻りに発展します。

原因: 業務担当のロールに、現場ユーザーの代表が含まれていないことが原因です。事業部長や課長クラスを業務担当に据えて、実務を回している現場メンバーが要件定義に参加しない構造になっているケースが典型です。

RACI表での回避策: 業務要件の定義タスクのR（実行責任者）に、実際の業務オペレーターを2〜3名含めます。受入テスト計画策定のCにも、現場代表を入れます。あわせて「業務要件の確定前に、現場ユーザー10名以上に対するヒアリングまたはデモを実施する」というマイルストーンをタスク化し、そのタスクのAを業務担当に割り当てると、現場との接点を担保できます。

失敗4──情シスがベンダーと直接やり取りし、ブラックボックス化する

情シス担当がベンダーと技術的なやり取りを直接行い、その内容が発注者側PM・業務担当・オーナーに共有されないまま進むパターンです。情シスが退職・異動した瞬間に、誰もプロジェクトの技術判断の経緯を説明できなくなります。

原因: 情シス担当の役割が「技術的な相談窓口」と定義されているために、ベンダーが情シスに直接相談する構造ができてしまうことが原因です。情シス側も「自分が一番技術的に分かるから」という意識でそれを受けてしまいます。

RACI表での回避策: 技術的な仕様判断・スコープ変更のAを、必ず発注者側PMに置きます。情シスはC（相談先）として意見を述べる立場とし、最終判断と記録は発注者側PMが行う構造にします。「情シスとベンダー間で行われた技術的な議論は、48時間以内に発注者側PMに議事として共有する」というルールも併記すると、ブラックボックス化を防げます。

失敗5──経営層への報告ルートが定義されず、撤退判断が遅れる

プロジェクトに重大な遅延・コスト超過が発生しているにもかかわらず、経営層への報告が「順調です」のまま続き、最終的に大規模なコスト超過が発覚してから撤退判断が議論される、というパターンです。

原因: 経営層が報告ルート（I）として明示されておらず、現場が「悪い情報を上げにくい」状態になっていることが原因です。発注者側PMが進捗を共有する相手として、定例会議のメンバーしか想定していないケースで起きがちです。

RACI表での回避策: プロジェクトオーナーまたはより上位の経営層を、月次の進捗報告タスクのI（報告先）として明示します。あわせて「赤信号トリガー」として、遅延が2週間以上発生・コストが10%超過・重大障害発生のいずれかに該当した場合は、24時間以内にオーナーへエスカレーションする、というルールをRACI表の運用ガイドに併記します。「悪い情報ほど早く上げる」を文書化された運用ルールにしておくことが、撤退判断を遅らせない鍵になります。

もし既にプロジェクトが危機的な状況に陥っている場合は、別記事の開発プロジェクトが危機に陥ったときのリカバリーアクションガイドも参考になります。

キックオフ前に体制を確定させるためのチェックリスト

ここまで読んでいただいた内容を、キックオフ前にチェックする項目としてまとめます。以下の10項目すべてに「Yes」と答えられる状態であれば、キックオフを迎える準備は整っています。

体制設計のチェックリスト10項目

1. プロジェクトオーナー（最終承認者）が1名に絞られ、本人が任命を承諾しているか
2. 発注者側PMが1名に絞られ、業務時間の確保（目安として工数の50%以上）について上長の合意があるか
3. 業務担当に、現場の実務オペレーターが2〜3名含まれているか
4. 情シス担当の役割が「相談先（C）」であり、技術的判断のAは発注者側PMに置かれているか
5. 受入担当（UAT責任者）が任命され、受入基準の言語化に着手しているか
6. RACI表のA列に空白のタスクが1つもなく、すべてのAが1名に絞られているか
7. ベンダー提出の体制図・役割分担表が、RACI表の発注者・ベンダー責任境界と矛盾していないか
8. 定例会議体（週次の発注者側PM↔ベンダーPM、月次の経営層への報告）が定義されているか
9. 意思決定エスカレーションパス（Aが不在時の代理判断者・赤信号トリガー）が定義されているか
10. スコープ変更管理のプロセス（変更要求の起票・影響評価・承認フロー）がRACI表に組み込まれているか

チェックがNGの項目があった場合の対処順序

NGがあった場合は、項目1から順に潰していくことを推奨します。とくに項目1（オーナー任命）と項目2（PMの工数確保）は、後続のすべての項目の前提になります。ここが固まらないままキックオフを迎えると、ほぼ確実にプロジェクトは初期段階で停滞します。

項目6（RACI表のA列）は、本記事の内容に沿って表を埋めればクリアできます。項目9・10は、自社の他プロジェクトでの運用ルールが流用できる場合が多いので、過去資料を探してみてください。

なお、AI関連プロジェクトに特化した推進体制を組む場合は、汎用の発注者体制とは異なる役割定義が必要になります。AI導入の推進体制と企業規模別の3モデルに、RACI付きの具体例を掲載しているので、AIプロジェクトを担当する方はあわせてご覧ください。

まとめ──「役割が決まれば、プロジェクトは8割うまくいく」

ここまで、発注者側のプロジェクト体制の作り方を、RACI表による責任の明文化というアプローチで解説してきました。最後に要点を振り返ります。

肩書きを並べた体制図と、責任が明文化されたRACI表は別物です。前者は組織を説明するための図にすぎず、後者はプロジェクトを動かすための運用ツールです。発注者として目指すべきは、すべての主要タスクについて「誰が決め・誰が実行し・誰に相談し・誰に報告するか」を1枚のマトリクスで説明できる状態です。

特に重要なのが、Aを1タスク1人に絞ること、要件定義と受入テストでは発注者が主役であること、設計と開発ではベンダーが主役で発注者はレビューと承認に徹すること、の3点です。本記事のフェーズ別RACI表をたたき台に、自社の状況に合わせて1〜2日かけて埋めれば、ベンダーとの責任境界の議論に堂々と臨めるはずです。

そして、前回のプロジェクトで承認者不在や複数PMによる失敗を経験した方であれば、今回の体制設計は同じ失敗を構造的に防ぐ仕組みづくりの機会でもあります。「Aが会議に出ない」「PMが二頭体制になる」「現場が蚊帳の外」「情シスがブラックボックス化」「経営層への報告が遅れる」──これら5つの典型パターンに対する具体的な回避策を、RACI表の運用ルールとして明文化しておきましょう。

役割が決まれば、プロジェクトは8割うまくいきます。残りの2割は、その役割を実際に動かしていく日々の運用です。キックオフ後は、本記事で組み立てたRACI表をプロジェクト計画書の付属資料として保管し、人事異動・スコープ変更のたびに定期的に見直すことで、体制を生きたドキュメントとして機能させてください。

画像指示

アイキャッチ

アイキャッチ推奨クエリ: "project team planning meeting whiteboard"

本文内画像

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。