システム開発では、タスクそのものよりも、
「誰が決めるのか分からない」
「担当者だと思っていた人が対応していなかった」
「複数人が確認しているのに、最終判断する人がいない」
といった役割分担の曖昧さが原因でプロジェクトが止まることがあります。
例えば要件定義で、
- 現場担当者
- 部門責任者
- 情報システム担当
- プロジェクトマネージャー
- 開発会社
が参加していたとします。
要件について意見を出す人は多くても、
最終的に誰が決定するのか
が決まっていなければ、仕様を確定できません。
こうした役割分担を整理する方法の一つがRACIです。
RACIでは、プロジェクトのタスクごとに関係者を、
- R：Responsible
- A：Accountable
- C：Consulted
- I：Informed
の4つに分類します。
この記事では、システム開発でRACIを作る方法を、要件定義・設計・開発・受入テストなどの具体例と合わせて解説します。
RACIとは
RACIとは、プロジェクトにおける役割と責任を整理するためのフレームワークです。
タスクごとに、
誰が実行するのか
誰が最終責任を持つのか
誰に相談するのか
誰へ共有するのか
を明確にします。
例えば、
「機能要件を確定する」
というタスクがあった場合、
| 関係者 | RACI |
|---|---|
| 要件定義担当 | R |
| プロジェクト責任者 | A |
| 現場担当者 | C |
| 開発担当者 | C |
| 経営層 | I |
のように整理できます。
これによって、
「誰が作業するのか」
だけでなく、
誰が最終的に決めるのか
まで明確になります。
RACIの4つの役割
まず、それぞれの意味を整理します。
R｜Responsible：実行責任者
Rは、実際にそのタスクを実行する人です。
例えば、
「要件定義書を作成する」
というタスクなら、要件定義担当者やSEがRになります。
システム開発では、
- 資料を作る
- 設計する
- プログラムを書く
- テストする
など、実作業を担当する人です。
複数人をRに設定することもあります。
A｜Accountable：最終責任者
Aは、そのタスクについて最終的な責任・承認を持つ人です。
RACIで特に重要なのがAです。
例えば、
要件定義担当者が要件資料を作っても、
「この要件で開発へ進んでよい」
と最終判断する人が必要です。
その人をAにします。
一般的には、1タスクにつきAは1人にした方が責任の所在を明確にしやすくなります。
C｜Consulted：相談先
Cは、タスクを進めるときに意見・専門知識を確認する相手です。
例えば機能要件を整理するとき、
- 現場担当者
- 情報システム担当
- セキュリティ担当
などがCになる可能性があります。
Cは双方向のコミュニケーションが前提です。
単に結果を知らせるだけではなく、
「この要件で問題ありませんか？」
と相談します。
I｜Informed：情報共有先
Iは、作業には直接参加しないものの、結果や進捗を共有する必要がある人です。
例えば、
- 経営層
- 関連部署
- 他プロジェクト責任者
などです。
Iは原則として、相談して判断してもらう役割ではありません。
必要なタイミングで、
「要件定義が完了しました」
「リリース日は○月○日に決まりました」
と共有します。
RACIを使うメリット
1．「誰がやるのか」が明確になる
例えば、
「受入テストを実施する」
とだけタスク管理表に書かれていても、
誰が実行するのか分からなければ進みません。
RACIで、
業務担当者：R
業務責任者：A
開発会社：C
と決めれば役割が明確になります。
2．最終意思決定者が明確になる
システム開発で特に重要です。
例えば仕様について、
営業部：
「A案がよい」
経理部：
「B案がよい」
情報システム：
「C案がよい」
となったとします。
意見を出す人だけ決めても、最終判断できません。
RACIでAを決めておけば、
最終的に誰が決定するのか
が明確になります。
3．関係者を巻き込みすぎるのを防げる
すべての打ち合わせへ全員を呼ぶ必要はありません。
RACIで、
- R・Aは参加
- Cは必要に応じて相談
- Iには決定後共有
とすれば、コミュニケーションコストを抑えられます。
4．責任の押し付け合いを防ぎやすい
問題が発生したとき、
「それは開発会社が決めると思っていた」
「発注者が決めると思っていた」
という状態を防ぎやすくなります。
システム開発でRACIが有効な場面
RACIは、特に複数部署・複数会社が関わるプロジェクトで有効です。
例えば、
- 発注企業
- 開発会社
- インフラ会社
- 業務部門
- 情報システム部門
が参加する場合です。
特に役割が曖昧になりやすいのは、
- 要件定義
- 仕様変更
- データ移行
- セキュリティ確認
- 受入テスト
- リリース判定
などです。
RACIの作り方7ステップ
STEP1｜プロジェクトの関係者を洗い出す
まず、誰が参加するのか整理します。
例えば、
- プロジェクト責任者
- 業務部門責任者
- 現場担当者
- 情報システム担当
- PM
- 開発会社SE
- 開発者
などです。
個人名ではなく、最初は役割名で整理しても構いません。
例えば、
「田中さん」
ではなく、
「営業部門責任者」
とします。
担当者が変わってもRACIを維持しやすくなるためです。
STEP2｜主要タスクを洗い出す
次にプロジェクトで必要なタスクを整理します。
例えば、
- 開発目的の決定
- 業務フロー整理
- 業務要件整理
- 機能要件整理
- 非機能要件整理
- 画面設計
- DB設計
- 開発
- テスト
- データ移行
- 受入テスト
- リリース判定
です。
タスクが細かすぎるとRACI表が巨大になります。
まずは、意思決定や責任が重要な単位で作るのがおすすめです。
STEP3｜各タスクのRを決める
そのタスクを実際に行う人を決めます。
例えば、
「業務フロー整理」
なら、
要件定義担当：R
「プログラム開発」
なら、
開発担当：R
です。
Rがいないタスクは、実行担当者が決まっていないということです。
STEP4｜Aを決める
次に、
最終的に誰が責任を持つか
を決めます。
例えば、
「業務要件確定」
なら、開発会社ではなく発注側の業務責任者がAになるケースがあります。
なぜなら、
「自社業務をどうするか」
を最終的に判断するのは発注企業だからです。
RとAを同じ人にしても構いません。
重要なのは、最終責任者を曖昧にしないことです。
STEP5｜Cを決める
そのタスクを判断する際に相談が必要な人を決めます。
例えば、
「セキュリティ要件」
なら、
- 情報システム
- セキュリティ担当
- 開発会社
などがCになります。
Cを増やしすぎると意思決定が遅くなるため、本当に相談が必要な人へ絞ります。
STEP6｜Iを決める
進捗・決定事項を共有しておく人を設定します。
例えば、
「本番リリース日決定」
なら経営層・関連部署などへ共有する必要があるかもしれません。
ただし、情報共有先を増やしすぎると管理コストが高くなります。
STEP7｜空欄・重複をレビューする
最後にRACI表全体を確認します。
特に見るのは、
- Rがいないタスク
- Aがいないタスク
- Aが複数いるタスク
- Cが多すぎるタスク
- 特定人物へR・Aが集中している状態
です。
システム開発のRACI具体例
例えば次の体制で業務システムを開発するとします。
発注側
- プロジェクト責任者
- 業務責任者
- 現場担当者
- 情報システム担当
開発側
- PM
- SE
- 開発者
RACIは例えば次のようになります。
| タスク | PJ責任者 | 業務責任者 | 現場 | 情シス | PM | SE | 開発 |
|---|---|---|---|---|---|---|---|
| 開発目的決定 | A | R | C | C | C | I | I |
| 業務フロー整理 | I | A | C | C | R | R | I |
| 業務要件確定 | I | A | C | C | R | R | I |
| 機能要件整理 | I | A | C | C | R | R | I |
| 非機能要件 | I | C | I | A | R | R | I |
| 画面設計 | I | C | C | I | A | R | C |
| DB設計 | I | I | I | C | A | R | C |
| 開発 | I | I | I | I | A | C | R |
| 受入テスト | I | A | R | C | C | C | I |
| リリース判定 | A | C | I | C | R | C | I |
これはあくまで例です。
プロジェクトの規模・契約形態・社内体制によって役割は変わります。
重要なのは、テンプレートどおりに当てはめることではなく、
今回のプロジェクトでは誰が決めるのか
を明確にすることです。
要件定義でのRACI例
要件定義は特に責任が曖昧になりやすい工程です。
例えば、
現状業務ヒアリング
R：要件定義担当
A：業務責任者
C：現場担当者
I：PJ責任者
業務要件確定
R：要件定義担当
A：業務責任者
C：現場担当者・開発会社
I：PJ責任者
機能要件整理
R：SE
A：業務責任者
C：現場担当者・情報システム
I：PJ責任者
このように、
資料を作る人と、最終的に要件を承認する人を分ける
ことがポイントです。
受入テストでのRACI例
受入テストでも、
「誰がテストするのか」
「誰が合格と判断するのか」
を分けます。
例えば、
R：現場担当者
A：業務責任者
C：開発会社・情報システム
I：PJ責任者
とします。
開発会社は、
- テストデータ準備
- 不具合調査
- 操作説明
などを支援できます。
しかし、
業務として受け入れ可能か
を判断する役割は、発注側が持つケースが一般的です。
仕様変更でのRACI例
仕様変更は、RACIを決めておかないと混乱しやすい領域です。
例えば現場担当者が、
「この機能も追加してください」
と直接開発者へ伝えたとします。
そのまま開発すると、
- 追加費用
- 納期
- 他機能への影響
が管理されません。
そこで、
仕様変更案作成
R：SE
影響調査
R：開発会社
C：情報システム
業務上の必要性判断
R：業務責任者
最終承認
A：PJ責任者
などと決めます。
こうすることで、
誰でも勝手に仕様変更できる状態
を防ぎやすくなります。
RACIはプロジェクト全体を細かく書きすぎない
RACIの目的は役割を明確にすることであり、すべての作業を管理することではありません。
例えば、
- 顧客一覧画面のボタン実装
- CSS修正
- SQL作成
までRACIに入れると巨大になります。
こうした細かい作業は、
- WBS
- Backlog
- Jira
- GitHub Issues
などで担当者を管理する方が適しています。
RACIでは、
責任・判断・部門間調整が重要な単位
を中心にします。
RACIとWBSの違い
RACIとWBSは目的が違います。
WBS
プロジェクトで、
何をするか
を分解します。
例えば、
要件定義
→ 業務ヒアリング
→ 機能一覧
→ 画面一覧
などです。
RACI
そのタスクについて、
誰がどの責任を持つか
を整理します。
つまり、
WBS＝作業の分解
RACI＝責任の分解
です。
WBSの主要タスクを縦軸にしてRACIを作る方法もあります。
RACIと組織図の違い
組織図は、
- 部長
- 課長
- 担当
など、組織上の関係を表します。
RACIは、
特定プロジェクト・タスクでの役割
を表します。
例えば部長であっても、あるタスクではIになることがあります。
反対に、現場担当者でも専門業務についてAになる可能性があります。
役職だけで決めないことが重要です。
【コピペ用】システム開発RACIテンプレート
ExcelやGoogle Sheetsなら、次の形式で作れます。
| タスク | PJ責任者 | 業務責任者 | 現場担当 | 情シス | PM | SE | 開発 |
|---|---|---|---|---|---|---|---|
| 開発目的決定 | |||||||
| 業務フロー整理 | |||||||
| 業務要件整理 | |||||||
| 機能要件整理 | |||||||
| 非機能要件整理 | |||||||
| 画面一覧作成 | |||||||
| プロトタイプ | |||||||
| 基本設計 | |||||||
| 詳細設計 | |||||||
| 開発 | |||||||
| テスト | |||||||
| データ移行 | |||||||
| 受入テスト | |||||||
| リリース判定 |
各セルへ、
R / A / C / I
を入力します。
RACI作成時のチェックリスト
タスク側
- 各タスクにRが存在するか
- 各タスクにAが存在するか
- Aが複数になっていないか
- Cが多すぎないか
- Iが必要以上に多くないか
人側
- 一人へAが集中していないか
- 特定担当者へRが集中していないか
- 役割と実際の権限が一致しているか
- 判断できない人をAにしていないか
プロジェクト側
- 要件を最終判断する人が決まっているか
- 仕様変更を承認する人が決まっているか
- 受入を判断する人が決まっているか
- リリースを判断する人が決まっているか
RACIでよくある失敗
失敗1｜Aを複数人にする
例えば、
営業部長：A
情報システム部長：A
PJ責任者：A
となっている状態です。
最終判断が分散します。
原則として、
最後に誰が決定するか
を明確にします。
失敗2｜Rだけ決める
タスク担当者だけ決めても、
「最終承認する人」
がいなければ意思決定できません。
RとAは分けて考えます。
失敗3｜Cを増やしすぎる
関係者全員をCにすると、すべての判断で全員確認が必要になります。
本当に意見が必要な人だけ設定します。
失敗4｜偉い人を全部Aにする
Aは役職ではなく、そのタスクを最終判断できる人です。
例えば業務ルールの詳細について、経営者より業務責任者の方が適切な場合があります。
失敗5｜RACIを作っただけで終わる
RACIを作成しても、参加者が認識していなければ意味がありません。
プロジェクト開始時・要件定義開始時などに共有します。
失敗6｜変更があっても更新しない
担当者変更・体制変更があればRACIも更新します。
「Aは必ず1人」にした方がよい？
実務上は、原則1人にすると責任が明確になります。
例えば、
「業務要件を確定する」
タスクで2人のAがいると、
Aさん：
「OKです」
Bさん：
「NGです」
となった場合に判断できません。
どうしても複数部門の承認が必要なら、
- 各部門のレビューを別タスクへ分ける
- 最終承認タスクを別に作る
方法もあります。
RとAは同じ人でもよい？
問題ありません。
例えば小規模プロジェクトで、
「プロジェクト計画作成」
についてPMが、
R：PM
A：PM
となることがあります。
ただし、大きな意思決定では、
実行者と承認者を分けた方がよい
場合があります。
例えば、
開発：
R＝開発担当
A＝PM
とすればレビュー機能を持たせられます。
CとIの違いで迷ったら
判断基準は、
決定前に意見が必要か
です。
必要ならCです。
決定後に知っていればよいならIです。
例えば、
セキュリティ要件について情報システム担当の確認が必要ならC。
経営層には要件確定後に報告するだけならI。
となります。
小規模開発でもRACIは必要？
必ずしも正式なRACI表を作る必要はありません。
例えば、
発注者1名
開発者1名
の小規模開発なら、役割が明確な場合があります。
一方、数人のプロジェクトでも、
- 要件を決める人
- お金を承認する人
- 現場で使う人
が異なるならRACIは有効です。
重要なのは人数より、責任が分散しているかどうかです。
RACIはいつ作る？
おすすめはプロジェクト開始時です。
例えば、
プロジェクト企画
↓
関係者整理
↓
RACI作成
↓
業務ヒアリング
↓
要件定義
↓
設計・開発
という流れです。
ただし、プロジェクト途中でも、
「誰が決めるか分からない」
という問題が出ているなら、そこから作っても構いません。
特に、
- 要件定義開始時
- 開発開始時
- 受入テスト開始時
など、フェーズが変わるタイミングで見直すとよいでしょう。
RACIに関するよくある質問
RACIは何の略ですか？
Responsible、Accountable、Consulted、Informedの頭文字です。
実行担当、最終責任、相談先、情報共有先を整理します。
RACIと担当者表の違いは何ですか？
担当者表は「誰が担当するか」を中心に管理します。
RACIではさらに、
「誰が最終責任を持つか」
「誰へ相談するか」
「誰へ共有するか」
まで整理します。
一つのタスクにRは複数いてもよいですか？
複数人で実行するタスクなら設定できます。
ただし、誰も主体的に動かない状態にならないよう、主担当を明確にする方法もあります。
一つのタスクにAは複数いてもよいですか？
可能なケースはありますが、責任を明確にする目的では原則1人にする方が分かりやすいでしょう。
開発会社をAにしてよいですか？
技術設計・開発など、開発会社側が責任を持つタスクではあり得ます。
一方、業務要件・予算・リリース可否など、発注者側で判断すべき内容まで開発会社へ任せないことが重要です。
RACIはExcelで作れますか？
問題ありません。
行にタスク、列に役割・担当者を並べ、交差セルへR・A・C・Iを入力すれば作成できます。
hiro-dev-labの要件定義・業務システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなくプロジェクト初期の要件整理から対応しています。
例えば、
- 現状業務ヒアリング
- As-Is・To-Be業務フロー整理
- プロジェクト体制・役割整理
- 業務要件・機能要件整理
- ユーザーストーリー整理
- 受入条件整理
- 画面一覧・プロトタイプ整理
- データ・権限設計
- Java・Python・TypeScriptによるWebシステム開発
などを検討できます。
例えば、
「複数部署が関係しているが、誰が要件を決めるのか曖昧」
という状態なら、
関係者整理 → RACI → 業務ヒアリング → 要件定義 → 設計・開発
と進めることができます。
RACIの目的は「担当表を作ること」ではなく「誰が決めるかを明確にすること」
RACIを作るとき、
Rを埋めることばかりに注目しがちです。
しかしシステム開発で特に重要なのは、
A＝Accountableを明確にすること
です。
例えば、
- 業務要件を誰が確定するのか
- 仕様変更を誰が承認するのか
- 受入テストを誰が合格と判断するのか
- 本番リリースを誰が決定するのか
を決めます。
RACIを作る基本手順は、
- 関係者を洗い出す
- 主要タスクを洗い出す
- 実行担当のRを決める
- 最終責任者のAを決める
- 相談先のCを決める
- 情報共有先のIを決める
- 空欄・重複・偏りをレビューする
です。
RACIが適切に作られていれば、
「誰かがやると思っていた」
「誰に確認すればよいか分からない」
「関係者全員の承認待ちで進まない」
といった問題を減らしやすくなります。
システム開発では、技術だけでなく意思決定の設計も重要です。
「複数部署が関わるシステム開発を進めたい」
「要件定義の責任者が曖昧になっている」
「発注側と開発会社の役割を整理したい」
「業務整理から要件定義・開発まで相談したい」
といった段階からでも、プロジェクト体制を整理できます。
要件定義・業務システム開発について相談する