RASICを使用した責務明確化

この記事ではRASICについて説明します。RASICは、プロジェクトや業務の役割と責務を明確化するためのフレームワークです。5つの役割（実行責任者、説明責任者、支援者、報告先、相談先）を定義し、企業間の責務分担を明確にします。

RASIC（ラシック） は、プロジェクトや業務の役割/責務を明確化するためのフレームワークです。
RASICチャートやRASCI（ラスキー） とも呼ばれます。

RASICの5つの役割

役割は以下5つ。
それぞれの頭文字をとって「RASIC」と呼ばれています。

役割	役割（日本語）	概要	具体例	設定人数
R： Responsible	実行責任者	タスクを遂行し完了させる担当者	システム開発やテストを行うエンジニア	1名
A： Accountable	説明責任者	タスクに最終的な責任を持つ人	プロジェクトマネージャ、プロダクトオーナー	1名
S： Support	支援者	実行責任者をサポートし、必要なリソースや助言を提供する人	PMO、スクラムマスター	0名以上
I： Informed	報告先	進捗や結果について情報を受け取る人	上層部、他部署関係者、クライアント	0名以上
C： Consulted	相談先	意見や助言を求められる専門家や関係者	法務、ある分野のスペシャリスト	0名以上

「人」や「～者」と記載していますが、チームや企業の場合もあります。

特に、企業間の責務分担を明確化するためにRASICが使用されることも多いです。
複数企業での開発となると、規模が大きく、抜け漏れが発生すると大きな問題となってしまうためです。

「い社」があるシステムの開発を「ろ社」に依頼したとします。

あくまで一例ですが、この場合以下のようなRASICとなります。

タスク	い社	ろ社	は社	に社	補足
要件定義	A/R	C	-	-	実現性可否などは「ろ社」へ相談が必要 →実現できない要件は、実現可能な要件に変更する必要あるため
機能仕様書作成	I	A	R	I	テストを実施する「に社」に仕様書の報告が必要 →機能仕様書をもとに、テスト仕様書を作成する必要があるため
設計、実装	I	A	R	I	テストを実施する「に社」にテスト開始時期の報告が必要 →「に社」の環境構築やリソース調整が必要なため
テスト実施	I	A	S/C	R	「に社」では困難なテストやテストで問題発生した場合は、「は社」へ相談や「は社」の支援が必要

Responsible（実行責任者）とAccountable（説明責任者）は、必ず1名/チーム/社のみとする
→責任の所在が不明確にならないようにするため。
Support（支援者）やInformed（報告先）、Consulted（相談先）は、必要最小限とする
→「念のため」として設定し過ぎると、これも責任が不明確になる要因となるため。
タスクの粒度を適切に
→細かすぎると、RASICが巨大になり、誰が何を担当するのかが分かりづらくなるため。
→粗すぎると、漏れが発生してしまうため。
必要あればRASICを見直す
→様々な変化により、途中で役割変更が必要となる時もあります。
その変更時にRASICも更新しないと、漏れや問題発生した際の責任の所在が不明確になるため。