RACIの作り方｜実行者と責任者を分けて役割の空白を見つける

「担当は決まっているのに、確認や承認が進まない」。作業する人と最終責任を持つ人を、同じ意味の「担当者」でまとめると、役割の空白が見えにくくなります。RACIは活動・成果物ごとに実行・責任・相談・共有を整理する表です。役職の序列ではなく、空白や集中を見つけ、関係者と合意するために使います。

R・A・C・Iの意味を区別する

RはResponsibleで実行する役割、AはAccountableでその活動の最終的な責任を持つ役割です。CはConsultedで意見・専門知識を求める相手、IはInformedで情報を共有する相手を指します。この記事は一行につきAを一つにする運用で説明します。Rは複数の場合もありますが、分担や取りまとめが不明なら活動を別行にします。Aは全作業を行う人という意味ではありません。表にAと記載しても社内規程上の権限が付くわけではないので、実際の判断権限と整合させます。

作成・確認・承認を別の活動にする例

社内申請機能の開発の説明用で、標準体制ではありません。

「要件を作る」という広い活動は、案の作成、技術確認、業務承認へ分けられます。上表でPMOが要件案を作成するのは説明用の割り当てで、すべてのPMOの職務ではありません。AとRを兼ねる行もありますが、独立した確認が必要な活動では、組織の職務分離や承認基準を優先します。複数部門の承認が必要なら、部門別の承認活動と全体の取りまとめを分けて表現できます。

空欄・重複・集中を点検する

Aのない行を探します。最終責任が未決なら作業担当がいても完了できません。Aが複数ある行では、責任範囲を分けるか活動を分解します。次にRがいない行、Cが多すぎる行を見ます。毎回すべての専門家の確認を求めると遅れることがあるため、必須確認と必要時の相談を分けます。列方向で、一人にRやAが集中していないかも確認します。役割が明確でも稼働枠がなければ動きません。集中は努力の問題でなく、分担・範囲・予定の見直し材料にします。

説明してから割り当てを合意する

表を作って送っただけでは合意になりません。入力、成果物、完了条件、権限を確認し、割り当てる人が対応できるかを相談します。Cだからいつでも相談できるとは限らないので、依頼方法と回答期限は別に決めます。Iにも共有時点と内容が必要です。RACIだけで連絡計画全体を代替しないようにします。反対があるなら、役割の認識差、権限不足、時間不足など理由を確認します。名前を埋めるために押し付けず、未決行として判断者へ相談します。兼務と代理対応の違いも明記すると、欠席時の対応が分かります。

変更時に更新し、決定の記録と分ける

担当交代、新しい成果物、外部委託の開始時は更新します。旧担当へ依頼が飛ばないよう版と適用日を周知します。RACIは「誰がどの役割か」の表です。「今回はどの案をなぜ選んだか」は決定事項ログに残し、セルに議論を詰め込みません。最初は主要成果物や判断が止まりやすい活動に絞って作ります。活動が多くなったら目的別に分け、表同士で責任の定義が変わらないかを点検します。細かさより、空白を見つけて合意することを優先しましょう。

次に確認したい実務ガイド

• ステークホルダー整理の方法｜権限・影響・関心から相談先を決める
• 決定事項管理表の作り方｜理由・判断者・対象版を残す

PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。

参考情報とこの記事の位置づけ

R・A・C・Iの役割と各行のAを一つにする基本を確認しました。役職ごとの割り当ては説明用で標準体制ではありません。 Atlassian：RACI Chart（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

PMOとPMの違いも必要な作業に合わせて参照してください。

アイキャッチ写真：Headway / Unsplash。職場の実写ではなくイメージ写真です。