はじめに
RACIチャートは、誰もが「マネジメントの一員」として主体的に成果を上げるための設計図です。 本記事では、ドラッカーの責任の概念に基づき、RACIを使って役割・責任・行動を明確化し、主体的なチームを育てる手法を解説します。
関連記事：
note記事「ドラッカーのマネジメントにおける責任の原則 ～成果は誰の責任か？を問い直す～」
note記事「「報・連・相」できない部下をさり気なく変える方法 ～RACIチャートでチームの役割分担を明確にする～」
1．RACIチャート作成に必要な情報の収集
RACIチャートを作る最初のステップは、対象となる業務やタスクを洗い出すことです。ここで大事なのは、「何をやるか」だけでなく「どれくらいの量なのか」「どれくらいの頻度／日数が必要か」まで言語化することです。
社内・チーム内業務の場合
定常業務であれば、以下を一覧化します。
- 業務の流れ（誰から依頼が来て、誰に引き渡すのか）
- 関係部門・関係メンバー
- 主要なアウトプット（成果物）
- 必要な作業量・頻度（毎日／週次／月次など）
業務には必ずインプットとアウトプットがあります。したがって、以下の3点を整理しておくことが重要です。
- インプットを誰から得るのか？
- アウトプットを誰に渡すのか？
- インプットをどのように加工・作業してアウトプットを創り出すのか？
提案作成の場合
提案書完成までのステップを分解して考えます。
- 提案の骨子作成
- ドラフト作成
- レビュー（内容・リスク・価格）
- 最終承認
- 提出とフォローアップ
それぞれのステップに対して、R（実行）、A（最終責任・承認）、C（相談）、I（報告）を割り振ります。
また、RFP（Request For Proposal）のような正式な提案依頼書がある場合、要求事項ごとにRACIを定義することが重要です。これにより「誰が何をどこまで責任を持つか」が明確になります。
プロジェクトの場合
プロジェクト型業務では、「企画 → 設計 → 実行 → 検証 → クローズ」とフェーズごとにタスクを分解します。 WBS（Work Breakdown Structure）やガントチャートと連動させると、「いつ・何を・誰が」を同時に可視化できます。 目的は、指示待ちではなく全員が自分の責任領域を理解し主体的に動ける状態をつくることです。
2．RACIチャートへの役割の決め方
- R（Responsible / 実行者）：実際に手を動かして成果物を作る人。複数名いてもOK。
- A（Accountable / 最終責任者）：品質と最終判断を担う人。1タスクにつき1名が原則。
- C（Consulted / 相談先）：知見提供やレビュー支援を行う人。
- I（Informed / 報告先）：結果や進捗を共有すべき人。
RACIを設定する目的は「指示系統の固定」ではなく、「誰もが自分の成果に責任を持ち、他者との連携の中で主体的に動ける関係」をつくることです。
3．チーム内での相談・認識合わせが重要
RACIは作った瞬間に完成するものではありません。 チーム全員で共有し、「この分担で現実的か」「責任の重複や抜け漏れはないか」を議論します。 この認識合わせのプロセス自体が、ドラッカーの言う「全員がマネジメントに参加する組織」への第一歩です。
4．ステークホルダーへの説明・承認
RACIを他部門・クライアントに共有し、必要なら承認を得ます。
- 誰が最終責任者なのか（A）
- 誰が相談先なのか（C）
- 誰に報告が届くのか（I）
ここでの合意は、後々の責任論争や情報共有の遅延を防ぎます。
特に、プロジェクト経験の少ないステークホルダーはRACIチャートを知らない、慣れていない、ことが多いので、単にチャートの説明にとどまらず、内容を噛み砕いて丁寧に説明する必要があります。
5．最小単位での試行運用
まずは小規模な業務で試運用します。1〜2週間でPDCAを回せる単位が理想です。 小さな成功体験を積むことで、RACI運用が現場文化として定着します。
6．フィードバックを元に最適化
- タスク粒度を調整（粗すぎ／細かすぎを修正）
- R/C/Iが多すぎて混乱していないかを確認
- 報告頻度・内容・深さを現実に即して最適化
RACIは一度決めたら終わりではなく、変化する業務環境に合わせてアップデートすべき「生きたツール」です。
7．進捗とレポートの設計
RACIで役割が明確になったら、「いつ・何を・誰に・どの深さで共有するか」を決めます。
- Rは週次でAへ進捗報告
- Aは月次でレビュー・承認
- I対象には概要を月報で共有
8．まとめ（中間）
RACIチャートは、チームを「主体的に動く組織」へ進化させるための設計図です。 ドラッカーは、「誰もが責任を引き受け、主体的に成果をあげる仕組みを作ること」がマネジメントの本質だと述べています。 つまり、RACIとは命令系統を整理するためのものではなく、責任の範囲を可視化して自律行動を促す仕組みです。
9．タスク粒度とRACI適用範囲を明確にする
- 「提案書作成」全体＝大きすぎる
- 「フォント選定」＝細かすぎる
理想は、Aがレビュー可能な粒度。 また、チーム・部門・プロジェクトなど、どの範囲でRACIを適用するかを最初に定義します。
10．定期レビューと意思決定の整合性を確保する
RACIは静的文書ではなく、変化に応じて見直す運用ツールです。ここでは、チーム全員が自分のタスクのアウトプットが正しいのか？成果に結びつけられるのか？という「問い」を持ち続けて、主体的にレビューをすることが大切になります。
| 点検項目 | 確認観点 | 対応策 |
|---|---|---|
| 負荷の偏り | Rが集中していないか | タスク再配分 |
| 承認の停滞 | Aが意思決定権を持つか | 権限移譲・代行設定 |
| 情報遅延 | C/Iが多すぎないか | 報告ライン短縮 |
11．RACIチャートが失敗する典型例と回避策
| 失敗例 | 原因 | 改善策 |
|---|---|---|
| 粒度がバラバラ | 適用範囲が曖昧 | 定義ルールを明文化 |
| Aが複数人いる | 意思決定構造と不整合 | Aは常に1名に限定 |
| Rが偏る | 負荷見積りが甘い | レビューで再分配 |
| 意味を理解していない | 導入時説明不足 | 共有ミーティングを実施 |
| 更新されない | レビュー体制なし | 例：四半期レビューを設定 |
12．まとめ（最終）
RACIチャートは、単なる「役割表」ではなく、「主体的に成果を生み出すための責任設計図」です。 R＝実行、A＝最終責任、C＝相談、I＝報告の4区分を通じて、全員が自分の成果に責任を持ち、他者の成果にも関心を向けるチーム文化を醸成します。
ドラッカーの言葉を借りれば、「マネジメントとは、人を通じて成果をあげる行為である」。 その第一歩は、全員が“自分の成果に責任を持つ”こと。 RACIチャートは、その責任を形式ではなく行動に落とし込む実践ツールです。
作って・合意して・試して・直して・定期的に見直す。 このサイクルを回すことで、指示待ちではなく主体的に成果を生み出すチームが育ちます。
※本記事にはプロモーションが含まれています。
コメント