オオハシさん、大変だよー！このままだと他社と揉めそうだよ！

おやおや、また何か問題が起きたのかい？

うん…。今回のプロジェクトで、一部の作業を他社にお願いしてるんだけど、
どこまでがウチの担当で、どこからが向こうの担当なのか、すごく曖昧なんだ。

ふむ、それはまずいな。他社と役割分担が不明確だと、責任の押し付け合いになりかねないぞ。

そうなんだよ！しかも、最初はめちゃくちゃ雰囲気よかったんだよ！
最初のキックオフMTGでは、お互いニコニコしながら、
「今回は一緒にいいもの作りましょう！」
「協力しながら進めていきましょうね！」
って、めちゃくちゃ和やかムードだったんだ。

その後も、何度かMTGを重ねて、要件を整理して、着実に進めてると思ってたんだけど…。
でも、開発が進むにつれて「あれ？これ誰がやるの？」っていう作業がポロポロ出てきてさ…。
最初の要件定義には入ってなかった細かい部分が見えてきたんだ。

ああ、プロジェクトあるあるだな。要件が完全に網羅されてることなんて、まずない。

そう！で、その「要件から漏れてた作業」をどっちがやるかって話になったんだけど、
これがまあ、どっちもやりたがらなくてさ…。
うちも向こうも、既存の業務で手一杯だから、追加の作業なんてやりたくないんだよね。

まあ、スケジュールもリソースもギリギリなら、余計な仕事は押し付けたくなる気持ちも分かる。

最初は「ここまでがうちの担当ですよね？」くらいの確認だったのに、だんだん雰囲気が怪しくなってきて…。
向こうの担当者が、「いやいや、そこまでウチがやるって話じゃなかったですよね？」って言い出してさ。
こっちも「え？そっちでやるって言ってませんでした？」って返したら、
そこからもう、完全に押し付け合いモード突入！

おっと、これはもう完全に炎上寸前だな。クライアント側はどうなんだ？

最初は「まぁまぁ、どっちがやるか決めて進めてくださいね」って感じだったんだけど、
どっちも譲らないもんだから、クライアント側もだんだんイライラし始めて…
「こっちとしては、決まったスケジュールで進めてもらわないと困るんですが？」
「今さら揉められても、納期は変えられませんよ？」
って、めっちゃ圧かけられた！

なるほど、これはSOW（作業範囲記述書：Statement of Work）がしっかり定義されてなかったのが原因だな。

うぅ… どうしたらいいの？

今からでも遅くない。RACIチャートを作成して、誰が何を担当するのか整理しよう。

なるほど！じゃあ、今から関係者を集めて、RACIチャートを作ってみるよ！

そうだな。他社との関係も悪化する前に、しっかり役割を整理しておこう！

作業範囲記述書（Statement of Work: SoW）とは

作業範囲記述書（SoW）とは、プロジェクトの作業範囲、責任の分担、納品物、スケジュール、品質基準などを明確に記述する公式文書です。SoWはプロジェクト開始前に作成され、関係者全員が合意することで、後々の認識のずれを防ぐ役割を果たします。

なぜSoWが重要なのか？

プロジェクトにおいて、関係者間で期待される作業範囲が異なっていると、進行中に「これは誰の仕事なのか？」といったトラブルが発生する可能性があります。SoWは以下のような問題を防ぐために不可欠です：

関係者間の認識のずれを防ぐ
作業範囲の明確化により、責任の所在を明らかにする
スケジュール管理を容易にし、納期の遵守を確実にする
契約内容の確認として、後々のトラブル回避に役立つ

SoWに含まれる主な項目

SoWには、プロジェクトのスムーズな進行を確保するため、以下のような重要な情報が含まれます。

1. プロジェクトの目的と背景

プロジェクトの背景、目的、達成すべき目標を明確に記述します。この情報があることで、プロジェクトの意義を関係者全員が共有できます。

2. 作業範囲（Scope of Work）

プロジェクトにおける具体的な作業範囲を明確にします。「何が含まれるか」「何が含まれないか」を記載することで、後々のトラブルを防ぎます。

3. タスクと成果物（Deliverables）

プロジェクトの中で発生するタスクと、その結果として作成される納品物を定義します。例えば、システム開発プロジェクトでは「設計書」「ソースコード」「マニュアル」などが該当します。

4. スケジュールとマイルストーン

各タスクの実施時期と、重要なマイルストーン（プロジェクトの節目）を明示します。これにより、遅延リスクを低減できます。

5. 品質基準と検査条件

プロジェクトの成果物が満たすべき品質基準を定義します。また、どのような条件で検査・承認を行うのかを明確にします。

6. 予算とコスト管理

プロジェクトに必要な予算や、各タスクごとの費用見積もりを記載します。予算管理を明確にすることで、不必要なコスト増加を防ぎます。

7. 契約条件・リスク管理

プロジェクトで発生しうるリスクを特定し、それに対する対策を記載します。また、支払い条件や契約解除に関する情報も含まれることが多いです。

SoWを活用するメリット

SoWがしっかりと定義されていることで、以下のようなメリットがあります：

プロジェクトの進行がスムーズになる
ステークホルダーの期待値を統一できる
作業の抜け漏れを防ぎ、後からのトラブルを防止
契約上の責任範囲が明確になる

SoW作成時の注意点

SoWを作成する際には、以下の点に注意が必要です：

作業範囲を詳細に定義し、あいまいな表現を避ける
関係者全員と十分に協議し、合意を得た上で作成する
変更が発生した場合の手続きを明確にする

まとめ

SoW（作業範囲記述書）は、プロジェクトの成功に不可欠な文書です。プロジェクトのスコープ、タスク、スケジュール、品質基準などを明確にし、関係者間で共通認識を持つために活用されます。
事前にしっかりとSoWを作成することで、プロジェクトのトラブルを未然に防ぎ、スムーズな進行を実現しましょう。

RACI チャートとは？

RACI チャート（RACI 図）とは、プロジェクト内のすべてのタスク、マイルストーン、成果物における役割と責任をメンバーに割り当てた表のことです。日本語では「責任分担表」とも呼ばれます。「RACI」は以下の4つの役割の頭文字を取ったものです。

RACI の4つの役割

Responsible（実行責任者）: 特定のプロジェクトタスクを担当する人。各タスクについて一人だけであることが重要です。実行責任者が複数いると、他の実行責任者の判断を待つ必要が生じ、プロジェクトの遅れにつながる可能性があります。また、ステークホルダーも誰に質問すればよいのか分からず、混乱のもととなります。
Accountable（説明責任者）: タスクの遂行を監督し、最終的な責任を持つ人。多くの場合、マネージャーがこれに該当します。説明責任者も各タスクにつき一人のみであることが望ましいです。
Consulted（協業先）: 作業を次の段階に進める前、または完了とする前に、内容を確認して承認する人。協業先は複数人いる場合もあります。
Informed（報告先）: 作業の進捗状況や結果に関して報告を受ける人。作業中に意見を述べることはありませんが、結果を知る必要がある人々です。

RACI チャートの重要性

プロジェクトにおいて、各メンバーの役割と責任を明確にすることは、以下の理由で重要です。

責任の明確化: 誰が何をするべきかが明確になることで、タスクの重複や抜け漏れを防ぎます。
コミュニケーションの円滑化: 各メンバーの役割が明確であれば、適切な情報共有が可能となり、意思決定の迅速化につながります。
プロジェクトの効率化: 役割と責任が明確であることで、無駄な作業を減らし、プロジェクトの効率を高めることができます。

RACI チャートの作成方法

RACI チャートを作成する際の一般的な手順は以下の通りです。

タスクの洗い出し: プロジェクト内のすべてのタスク、マイルストーン、成果物をリストアップします。
チームメンバーの特定: プロジェクトに関与する全てのメンバーをリストアップします。
マトリックスの作成: 縦軸にタスク、横軸にチームメンバーを配置したマトリックスを作成します。
役割の割り当て: 各タスクに対して、R（実行責任者）、A（説明責任者）、C（協業先）、I（報告先）を割り当てます。
確認と合意: 作成したRACI チャートをチーム全体で確認し、合意を得ます。

RACI チャートのメリットとデメリット

RACI チャートには以下のようなメリットとデメリットがあります。

メリット

責任の明確化: 各メンバーの役割と責任が明確になることで、プロジェクトの進行がスムーズになります。
コミュニケーションの向上: 誰が何を担当しているかが明確になることで、情報共有が円滑になります。
問題の早期発見: 役割が明確であれば、問題が発生した際に迅速に対応できます。

デメリット

柔軟性の欠如: 役割を固定化しすぎると、状況の変化に対応しづらくなる可能性があります。
作成の手間: 大規模なプロジェクトでは、RACI チャートの作成と維持に時間と労力がかかることがあります。

サンプル

RACIチャートの例（システム開発プロジェクト）

以下は、システム開発プロジェクトにおけるRACIチャートのサンプルです。

タスク	プロジェクトマネージャー	開発リーダー	エンジニア	クライアント
要件定義	A	C	I	R
設計	C	A	R	I
開発	I	C	R	I
テスト	C	A	R	I
リリース	A	R	C	I

凡例（RACIの意味）

R（Responsible: 実行責任者） – 実際に作業を行う担当者
A（Accountable: 説明責任者） – タスクの最終的な責任を持つ人
C（Consulted: 協業先） – 意見や助言を求められる人
I（Informed: 報告先） – タスクの進捗や結果を知らされる人

まとめ

RACI チャートは、プロジェクト内の役割と責任を明確にし、チームの効率的な運営をサポートする有用なツールです。適切に活用することで、プロジェクトの成功率を高めることが期待できます。

他社との作業範囲が曖昧で、火種になりそうです。