責任分担マトリックス

ビジネスおよびプロジェクト管理において、責任割当マトリックス^[1] ( RAM ) は、RACIマトリックス^[2] ( / ˈ r eɪ s i / ;責任、説明責任、相談、および通知) ^[3]^[4]または線形責任チャート^[5] ( LRC ) としても知られ、プロジェクトまたはビジネスプロセスのタスクまたは成果物^[4]を完了するためのさまざまな役割の参加を説明するモデルです。最も一般的に使用される4つの主要な責任は、責任、説明責任、相談、および通知です。これは、機能横断的または部門間のプロジェクトとプロセスの役割と責任を明確にし、定義するために使用されます。^[6] RACIモデルにはいくつかの代替モデルがあります。

RACIモデルにおける主要な責任役割

役割の区別

役割と個別に識別される人々の間には違いがあります。役割は、関連する一連のタスクの記述子であり、多くの人が実行できますが、1 人のユーザーが複数の役割を実行できます。たとえば、組織にはプロジェクトマネージャーの役割を実行できる 10 人のユーザーがいる場合がありますが、従来は各プロジェクトに同時に存在するプロジェクトマネージャーは 1 人だけです。また、プロジェクトマネージャーの役割を実行できるユーザーは、ビジネスアナリストおよびテスターの役割も実行できる場合があります。

R = 責任者（推薦者でもある）: タスクを完了する者。^{[7]参加タイプが}責任者である役割が少なくとも1つありますが、必要な作業を支援するために他の役割を委任することができます。（サポート役割に参加する者を個別に特定するには、以下のRASCIも参照してください。）

A = 責任者（承認者または最終承認権限者でもある）: 成果物またはタスクの正確かつ完全な完了に最終的に責任を負う者であり、タスクの前提条件が満たされていることを確認し、責任者に作業を委任する者。^[7]言い換えれば、責任者は責任者が提供する作業を承認する必要があります。各タスクまたは成果物には、1人の責任者のみを指定する必要があります。 [ ^8]

C = 相談を受けた（コンサルタントまたは顧問の場合もある）: 意見を求められる相手、典型的には主題の専門家であり、双方向のコミュニケーションがとれる人々。^[7]

I = 通知を受けた（通知を受ける側とも言う）: 進捗状況について最新情報を知らされる人、多くの場合はタスクや成果物の完了時のみ、一方通行のコミュニケーションのみが行われる人。^[7]

多くの場合、タスクまたは成果物に責任を負う役割は、それを完了する責任も負うことがあります(タスクまたは成果物に責任を負う役割はあるが、完了する責任がある役割がない、つまり暗黙的に示される)。この例外を除き、通常、各タスクのプロジェクトまたはプロセスの各役割には、最大で 1 つの参加タイプのみを割り当てることが推奨されます。複数の参加タイプが示されている場合、これは通常、参加がまだ完全に解決されていないことを意味し、各タスクの各役割の参加を明確にするこの手法の価値を妨げる可能性があります。

施設への人材の割り当て

マトリックスは通常、タスク (作業分解構造から) または成果物 (製品分解構造から)の垂直軸 (左側の列) と、役割 (組織図から) の水平軸 (一番上の行) を使用して作成されます。

メンテナンスと信頼性のコミュニティからの別の例:

代替案

RACI 参加タイプには、いくつかの選択肢があります。

パリ

これは責任割り当てマトリックスの初期バージョン^[9]であり、役割は次のように定義されています。

参加者

責任を負う

レビューが必要です

入力が必要です

サインオフが必要です

パシ

これは、文化の協調的な性質により、単一の人物/機能の説明責任の下での活動の出力が複数の利害関係者によってレビューされ、拒否される可能性がある組織にとって非常に便利なバージョンです。

実行する

アクティビティを実行する人物/機能。

責任を負う

成果物またはタスクの正確かつ完全な完了に対して最終的な責任を負う人物/機能であり、多くの場合、作業を実行者に委任する人物です。

コントロール: 活動の結果を検討する人物/機能。拒否権を持ち、そのアドバイスには拘束力があります。

提案する

認められた専門知識に基づいてアドバイスを提供するために相談する人物/機能。アドバイスは拘束力がありません。

情報提供

アクティビティの結果を通知する必要がある人物/機能。

RASIC または RASCI

これは標準的なRACIの拡張版^{[10]であり、}RASCI ^[11]としてはあまり知られていないが、責任ある参加を以下のように分類している。

責任者

タスクの責任者であり、承認者の指示通りにタスクが実行されることを確認する人

サポート: 責任者に割り当てられたリソース。タスクに入力を提供できる相談先とは異なり、サポートはタスクの完了を支援します。

ラシ

これは標準的なRACIの代替バージョン^{[12]であり、}相談参加を省略し、代わりに次のものを採用しています。

サポート: 実装をサポートする役割を果たすリソース。

RACI + F

これは標準RACIの拡張版で、参加タイプとしてファシリテートが追加されています。このバリエーションは2012年にクリストフ・ル・コエントによって導入されました。^[13]コエントは、ファシリテーターまたはコーチの役割はアジャイルソフトウェア開発環境では重要であるため、RAMに明示的に含める必要があると主張しました。^[13]アジャイル環境でのRAMの使用は、アジャイルチームで働く全員が共同で責任と説明責任を持つべきだと考える実践者もいるため、議論の的となっています。^[14]

促進する: Scrum プロジェクト中のアクティビティを促進します。

RACIQ

これは、追加の参加タイプを備えた標準 RACI の拡張バージョンです。

品質レビュー: 製品が品質要件を満たしているかどうかを確認する人。

RACI-VS

これは標準RACIの拡張版^{[3]であり、2つの参加タイプが追加されています。}

検証者: 製品内訳構造の製品が製品説明書に記載された受入テストの受入基準を満たしているかどうかを確認する者。

署名者

検証決定を承認し、製品の引き渡しを許可する者。署名者は、その成功に対して責任を負う当事者である必要があります。

カイロ

これは、 RACI ^[16]としても知られる標準RACIの拡張版^[15]であり、参加タイプが1つ追加されています。

ループ外（または省略）: タスクに特に参加しない個人またはグループを指定します。リソースが参加しないことを指定すると、参加するリソースを指定するのと同じくらい、タスクの完了に役立ちます。

ダキ

意思決定を集中化し、誰が議論を再開できるかを明確にするために使用されてきた別のバージョン。^[17]

ドライバ: 車を運転する人のように、プロジェクト全体を牽引する唯一の人物。

承認者: ほとんどのプロジェクトの決定を行い、プロジェクトが失敗した場合に責任を負う1 人以上の承認者。

寄稿者: 成果物に対して責任を持ち、双方向のコミュニケーションを行う働き蜂です。

情報提供: プロジェクトの影響を受け、ステータスが提供され、決定が通知され、一方的なコミュニケーションが行われる人々。

急速な

意思決定の役割を明確にし、それによって意思決定を改善するために使用されるもう 1 つのツールは、 Bain & Companyによって作成され、同社の登録商標であるRAPIDです。

推薦する: 推奨者の役割は、通常、意思決定の作業の 80% を占めます。推奨者は、関連する情報を収集し、行動方針を提案します。場合によっては、意思決定者の選択が可能な限り明確でシンプルかつタイムリーなものとなるよう、長所と短所を説明した代替案も提案します。

同意する: 同意ロールは、推奨事項の正式な承認を表します。「A」と「R」は協力して、決定者に提出する相互に満足できる提案を作成する必要があります。ただし、同意ロールは、通常、何らかの規制またはコンプライアンスの承認が必要な状況にのみ使用されるため、すべての決定に必要というわけではありません。

実行する: 実行役割は、決定が下された後にその決定を実行または実装する責任者を定義します。ベストプラクティスを実践する企業は通常、P を定義し、プロセスの早い段階でそれらからの入力を収集します。

入力: 入力ロールは、推奨者と決定者がすべての関連事実を評価して正しい決定を下せるように、関連情報と事実を提供します。ただし、「I」ロールはあくまでも助言的なものです。推奨者はすべての入力を考慮する必要がありますが、最終的な推奨にすべての観点を反映させる必要はありません。

決める: 決定者の役割は、最終的な決定を下し、グループに行動を促し、決定が確実に実行されるようにする責任を負う単一の人物です。

ラツィ

組織設計や役割分析で使用される別のツール。

責任: 作業を確実に完了させる責任者を特定します。

権限: 作業に対する最終決定権を持つ人物を特定します。

タスク: 実際に作業を行う人物を特定します。

サポート: 作業をサポートするために誰が関与しているかを特定します。

情報提供: 作業が完了したこと（または開始されること）を誰に通知するかを特定する

ドラスキ

3 人のホワイトホール理論家 (ケイン、ジャクソン、ギルバート) によって開発された RASCI の変種。このスキームはマトリックス管理環境での使用に適応しており、ドライバーの役割が追加され、サポートの定義が狭められている点のみが RASCI と異なります。

ドライバ: タスクの遂行に責任を持つ個人または団体の全体的な目標に沿って、サポート資料を作成し、遂行のスケジュールを設定することで、タスクの遂行に責任を持つ個人または団体を支援する個人または団体。ドライバーとサポートの違いは、前者は責任を持つ人に代わってタスクのパラメーターを補強および明確にするのに対し、後者は特定の目標を達成するために責任を持つ人を支援する人を指す点です。

PDQA

東京大学とMITでモデルベースのプロジェクト管理のために開発されたバージョン。PDQAの役割セットは、チームの能力に対する需要に対応しています。役割には、スコープの作業、調整としての依存関係の処理、プロジェクト組織全体のエラー検出と決定による例外処理などが含まれます。PDQAは、エージェントベースモデリングで使用され、プロジェクト内のチームによるこれらの能力の供給をシミュレートします。^[18]

主要な: 能力の範囲内でスキルベースの努力を提供し、範囲を完了し、調整を通じて依存関係も管理します。

決断: 許容可能なスコープや例外処理の決定など、やり直しにつながるあらゆる決定を処理します。(名目スコープは生成しません)。

品質: スコープをレビューして品質の低さを検出し、必要に応じて意思決定者にエスカレーションします (名目上のスコープを一般化しません)。

アシスト: プライマリを支援して、範囲を完了する能力を備えたスキルベースの取り組みを提供します。(調整を通じて依存関係を管理しません)。

ダイナミクス

組織設計や役割分析で使用される意思決定カテゴリの最小限のセット。

意思決定者: 意思決定を行い、その意思決定がビジネスに与える影響について責任を負う個人。

相談した: 機能上の専門知識と経験に基づいてガイダンスを提供し、問題点を指摘し、意思決定者をサポートするために代替案を提示する責任を負う個人。

情報提供: 影響を受ける利害関係者には、決定が下された後に通知され、決定の実行をサポートする必要がある人が示されます。

ラセイオ

ガバナンス、リスク、コンプライアンス (GRC) およびアウトソーシングの問題に取り組むときに使用します。

責任者

責任を負う

サポート

相談する

実行する: サービスレベル契約に従って活動を実行するために契約した第三者
知らせる

概要: リスクオーナー、ポリシーオーナーなどの主要なGRCの役割 - 説明責任は委譲されているが、説明責任がすべて適切に機能しているかどうかを監督する役割が必要である

ラクティ

主導、説明責任、相談、任務、情報提供

バリエーション

RACI 参加タイプの意味にもさまざまなバリエーションがあります。

RACI（代替スキーム）

あまり広く公開されていないものの、一部の専門家やプロセスマッピングソフトウェアによって使用されている代替コーディングがあり、これは元のスキームにおけるRおよびAコードの適用方法を変更します。全体的な方法論は同じままですが、この代替方法により、管理の専門家には理解できるものの、他の人には必ずしも明確に区別できない、説明責任と責任という用語の潜在的な混乱を回避できます。

責任者: タスクの実行責任者。各タスクに対して、この割り当てを受ける担当者が 1 人だけいる必要があります。

アシスト: タスクの完了を支援する人々

相談した: 意見を求められ、双方向のコミュニケーションが取れる人。

情報提供: 進捗状況を常に把握し、一方的なコミュニケーションが取れる人。

ARCI（決定）

この代替案は、誰がどのような決定を下す権限を持っているかを文書化することにのみ焦点を当てています。これは、あらゆる規模のワークグループで機能します。

責任を負う: 決定に対する回答を承認する権限があります。

責任者: 決定に対する回答を推奨する責任があります。

相談した: 意見を求められ、双方向のコミュニケーションが取れる人。

情報提供: 決定が下された後に通知され、一方的なコミュニケーションが行われる人々。

参照

責任の分散

引用

^ 「9.1.2.1 組織図と役職記述書」。プロジェクトマネジメント知識体系ガイド（PMBOK ガイド）（第 5 版）。プロジェクトマネジメント協会。2013 年。262 ページ。ISBN 978-1-935589-67-9。
^ Jacka, Mike; Keller, Paulette (2009).ビジネスプロセスマッピング: 顧客満足度の向上. John Wiley and Sons . p. 257. ISBN 978-0-470-44458-0。
^ ab Blokdijk, Gerard (2008)。サービスレベル契約 SLA ガイド - SLA ブック、サービスレベル管理のテンプレート、サービスレベル契約フォーム。SLA をすばやく簡単に作成する方法。Lulu。p. 81。ISBN 978-1-921523-62-5。
^ ab Project Management Institute 2021、§4.6.6 価値に焦点を当てる。
^ Cleland, David; Ireland, Lewis (2006).プロジェクトマネジメント: 戦略的設計と実装. McGraw-Hill Professional . p. 234. ISBN 0-07-147160-X。
^ Brennan, Kevin (2009).ビジネス分析知識体系ガイド (BABOK ガイド)。国際ビジネス分析研究所。p. 29。ISBN 978-0-9811292-1-1。
^ abcd Smith, Michael L.; Erwin, James. 「Role & Responsibility Charting (RACI)」（PDF） . Project Management Institute California Inland Empire Chapter . p. 5. 2022年9月16日時点のオリジナルよりアーカイブ。 2023年5月18日閲覧。
^ Tiziana Margaria :形式手法、検証、妥当性確認の活用アプリケーション: 活用アプリケーションに関する第 4 回国際シンポジウム議事録、パート 1、Springer、2010 年、p. 492
^ プロジェクトマネジメント知識体系ガイド。プロジェクトマネジメント協会。2000年。111ページ。ISBN 1-880410-22-2。
^ Hightower, Rose (2008).内部統制ポリシーと手順. John Wiley & Sons. p. 83. ISBN 978-0-470-28717-0。
^ ベイカー、ディーン（2009）。「複数企業プロジェクト管理：戦略的コラボレーションによるビジネス成果の最大化」 Jロス。p.58。ISBN 978-1-60427-035-8。
^ Mikes, Joe; Denton, Tara (2011)。トレーニングが継続的な改善を加速します。ライフサイクルエンジニアリング。
^ ab 「The RACI+F Matrix - Scrum Alliance」。www.scrumalliance.org。2017年10月16日時点のオリジナルよりアーカイブ。2022年8月10日閲覧。
^ 「RACI マトリックス | 定義と例 | 方法」。
^ ボルマン、リー（2008年）。組織の再構築：芸術性、選択、リーダーシップ。ジョン・ワイリー・アンド・サンズ。112ページ。ISBN 978-0-7879-8799-2。
^ Dickstein, Dennis (2008). No Excuses: A Business Process Approach to Managing Operational Risk . John Wiley & Sons. ISBN 978-0-470-48110-3。
^ ケンドリック、トム (2006)。権限のない結果: チームがあなたに報告しない場合のプロジェクトの管理。AMACOM Books、アメリカ経営協会の部門。p. 106。ISBN 0-8144-7343-1。
^ Moser, BR ; Wood, RT (2015). 「社会技術システムとしての複雑なプログラムの設計」。21世紀のコンカレントエンジニアリング。Springer。pp. 197–220。doi : 10.1007 /978-3-319-13776-6_8。ISBN 978-3-319-13775-9。

参考文献

プロジェクトマネジメント協会 (2021)。プロジェクトマネジメント知識体系ガイド (PMBOK ガイド)。プロジェクトマネジメント協会 (第 7 版)。ニュータウンスクエア、ペンシルバニア州。ISBN 978-1-62825-664-2。{{cite book}}: CS1 メンテナンス: 場所が見つかりません発行者 (リンク)

外部リンク

RACIに関する総合シリーズ

[pmbok-1] 「9.1.2.1 組織図と役職記述書」。プロジェクトマネジメント知識体系ガイド（PMBOK ガイド）（第 5 版）。プロジェクトマネジメント協会。2013 年。262 ページ。ISBN 978-1-935589-67-9。

[2] Jacka, Mike; Keller, Paulette (2009).ビジネスプロセスマッピング: 顧客満足度の向上. John Wiley and Sons . p. 257. ISBN 978-0-470-44458-0。

[slaguide-3] Blokdijk, Gerard (2008)。サービスレベル契約 SLA ガイド - SLA ブック、サービスレベル管理のテンプレート、サービスレベル契約フォーム。SLA をすばやく簡単に作成する方法。Lulu。p. 81。ISBN 978-1-921523-62-5。

[FOOTNOTEProject_Management_Institute2021§4.6.6_Focus_on_Value-4] Project Management Institute 2021、§4.6.6 価値に焦点を当てる。

[5] Cleland, David; Ireland, Lewis (2006).プロジェクトマネジメント: 戦略的設計と実装. McGraw-Hill Professional . p. 234. ISBN 0-07-147160-X。

[babok-6] Brennan, Kevin (2009).ビジネス分析知識体系ガイド (BABOK ガイド)。国際ビジネス分析研究所。p. 29。ISBN 978-0-9811292-1-1。

[pmicie-7] Smith, Michael L.; Erwin, James. 「Role & Responsibility Charting (RACI)」（PDF） . Project Management Institute California Inland Empire Chapter . p. 5. 2022年9月16日時点のオリジナルよりアーカイブ。 2023年5月18日閲覧。

[formal-8] Tiziana Margaria :形式手法、検証、妥当性確認の活用アプリケーション: 活用アプリケーションに関する第 4 回国際シンポジウム議事録、パート 1、Springer、2010 年、p. 492

[9] プロジェクトマネジメント知識体系ガイド。プロジェクトマネジメント協会。2000年。111ページ。ISBN 1-880410-22-2。

[10] Hightower, Rose (2008).内部統制ポリシーと手順. John Wiley & Sons. p. 83. ISBN 978-0-470-28717-0。

[11] ベイカー、ディーン（2009）。「複数企業プロジェクト管理：戦略的コラボレーションによるビジネス成果の最大化」 Jロス。p.58。ISBN 978-1-60427-035-8。

[LCE_Training-12] Mikes, Joe; Denton, Tara (2011)。トレーニングが継続的な改善を加速します。ライフサイクルエンジニアリング。

[Archived_copy-13] 「The RACI+F Matrix - Scrum Alliance」。www.scrumalliance.org。2017年10月16日時点のオリジナルよりアーカイブ。2022年8月10日閲覧。

[14] 「RACI マトリックス | 定義と例 | 方法」。

[15] ボルマン、リー（2008年）。組織の再構築：芸術性、選択、リーダーシップ。ジョン・ワイリー・アンド・サンズ。112ページ。ISBN 978-0-7879-8799-2。

[16] Dickstein, Dennis (2008). No Excuses: A Business Process Approach to Managing Operational Risk . John Wiley & Sons. ISBN 978-0-470-48110-3。

[17] ケンドリック、トム (2006)。権限のない結果: チームがあなたに報告しない場合のプロジェクトの管理。AMACOM Books、アメリカ経営協会の部門。p. 106。ISBN 0-8144-7343-1。

[18] ^ Moser, BR ; Wood, RT (2015). 「社会技術システムとしての複雑なプログラムの設計」。21世紀のコンカレントエンジニアリング。Springer。pp. 197–220。doi : 10.1007 /978-3-319-13776-6_8。ISBN 978-3-319-13775-9。