社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

プロジェクト計画書の書き方:概要

プロジェクト計画書の書き方の説明です。

第一回は、概要をつかむため、目次レベルでの説明です。 

1.プロジェクト計画書の構成

プロジェクト計画書の大部分は、RFP の焼き直しです。RFP と大きく異なるのは、ベンダーと内容について合意をすることです。

またパターンとしては、発注者とベンダーの両社でそれぞれ作成する、ベンダーだけが作成する、発注者だけが作成する、の3パターンがあります。

最初のパターンは、ベンダーのプロジェクト計画書だと細かかったり、業務部門側の情報が欠けていたりする場合に、発注者側で主に社内のステークホルダー向けに作るようなケースです。

2つ目のパターンは、ベンダー丸投げのプロジェクトに多いパターンです。ベンダーの作成したプロジェクト計画書に、業務部門側の情報(ベンダーの委託範囲外)が含まれていれば問題ないですが、ベンダーの委託範囲内だけ記載されていると、プロジェクト計画書としては不完全なものになります。

最後の発注者だけが作成するというパターンは、通常はありません。プロジェクト計画書を作らないベンダーを選んでしまったのであれば、発注者側がかなり力を入れないと、プロジェクトの成功が危ういです。

以下は、プロジェクト計画書のよくある構成です。

①プロジェクト概要(目的、背景、範囲、特徴、前提・制約事項等)

②開発方針(開発手法、技術、テスト環境、パッケージのカスタマイズ方針等)

③マスタースケジュールと工程定義

④プロジェクト体制と役割分担

⑤工程管理基準と会議体計画

⑥プロジェクト管理ルール

⑦用語の定義や関連文書

2.プロジェクト計画書の目的

では、なぜプロジェクト計画書が必要なのでしょうか?

一つ目は、初期プロジェクトメンバーの認識の共有です。特にマスタースケジュールやプロジェクト管理ルールは、プロジェクトを進める上で全員が認識しておく必要があります。

二つ目は、ステークホルダーの関与を高めることです。プロジェクト計画書に概要や会議体計画を記載することで、そのプロジェクトへの関心が高まり、協力的になります。

三つ目は、後から入ったメンバーのプロジェクトに対しての理解を深めるためです。このプロジェクトはどんなルールで動いていて、どんな人たちが関わっているのか、どんなリスクがあって、何を重視しているのか、開発の規模や手法などを、プロジェクト計画書を読むことで知ることができます。

逆にいうと、上記のような目的を達成できるようなプロジェクト計画書にしていく必要があるのです。

【振り返り】

今回はプロジェクト計画書の概要の説明でした。次回から一つ一つの詳細を説明していきたいと思います。

①プロジェクト概要(目的、背景、範囲、特徴、前提・制約事項等)
②開発方針(開発手法、技術、テスト環境、パッケージのカスタマイズ方針等)
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール