プロジェクト計画書の書き方の説明です。
第五回は、プロジェクト体制と役割分担の説明です。
１．プロジェクト体制
プロジェクト体制図を記載する目的はいろいろありますが、プロジェクト計画書のプロジェクト体制で一番重要なことは、ベンダーにとってのカウンターパートを明確にすることです。
ベンダーにも PM やリーダーの立場の人たちがいて、彼らが仕事を進める上で発注者のカウンターパートが明確になっていると、ストレスなく仕事を進められます。問題が生じた時に誰に相談すればいいのか、適切な相手が分からないと、プロジェクトとして問題への対処が遅れます。
例えば上記図で専任のアプリ全体 PL がいない場合、機能 A の PL と兼任でも構いません。アプリ全体 PL というロールを置くことで、アプリで問題が発生した場合の発注者側の意思決定のルートが明確になり、ベンダーが誰に相談すればいいのかが分かります。
さらに業務部門の体制もきちんと記載した方が、ベンダーからもプロジェクト全体が分かるので、要件定義や受入テスト、教育等で話が通じやすくなります。
また体制図とセットで、それぞれの箱の役割を記載します。
ただこれは、名称から想像できるレベルのことしか書かないことが多く、重要なのは役割分担なので、私はよほど大きなプロジェクトでない限りは、この役割定義は省略してしまいます。
２．役割分担
役割分担は、大きくは発注者とベンダーの役割分担、発注者の IT 部門とユーザー部門の役割分担の２つを明確にすることが重要です。
また体制図の一つ一つの箱と役割分担の単位を合わせると、エスカレーションルートとセットになるので、役割と責任範囲が明確になります。
例えば、上図のような体制図と役割分断だと
・監査や品質管理のプロジェクト内での立場が分からない
・発注者の全体 PL と機能ごとの PL の役割分担が分からない
・共通基盤の役割が分からない
といった問題があります。
これを下図のようにすると、体制図と役割分担が一致するので、それぞれの役割とプロジェクト内での立場が明確になります。
【振り返り】
今回はプロジェクト計画書に記載するプロジェクト体制と役割分担の説明でした。次回は工程管理基準と会議体計画の説明です。
①プロジェクト概要（目的、背景、範囲、特徴、前提・制約事項等）
②開発方針（開発手法、技術、テスト環境、パッケージのカスタマイズ方針等）
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール
