プロジェクト計画書の書き方の説明です。
第四回は、マスタースケジュールと工程定義の説明です。
１．マスタースケジュール
RFP でもマスタースケジュールを作成しますが、本番日などの重要なマイルストーンが変わらなければ、RFP のマスタースケジュールにこだわらず、ベンダーと現実的なスケジュールを作成します。
RFP との違いはベンダーが決まり、メンバーも決まり WBS に落とせるということです。逆にいうと WBS を意識してマスタースケジュールを作成します。
本来はマスタースケジュールがあって、それをベースに WBS に落としていくものですが、現実のプロジェクトでは要員や環境などの様々な制約があるので、誰がどの環境で作業するのかを意識してマスタースケジュールを作成します。
特に注意が必要なのが、サーバー環境の構築とテストのタイミングです。これを意識せずにマスタースケジュールを作成すると、テストをする段階でサーバー環境ができあがっていない、という状態になります。
また通常、機能系のテストと非機能系のテストは並行して行われます。機能系のテストは、単体、結合、総合といった流れでテストの順番を意識して計画しますが、性能負荷テストや障害復旧テストは、これらと並行して行われることが多いです。
契約を細かくしている場合には、契約手続きに必要な期間を設けることも重要です。
よくあるケースでは、要件定義、基本設計、詳細設計から結合テスト、総合テスト、受入テスト以降の支援、という単位で契約を分けるプロジェクトもあります。
また教育と受入テストも要注意です。本来は受入テストが終わって教育の実施ですが、並行で実施することも多いのが現実です。もっと言えば、開発が遅れて総合テストと教育を並行で行うことも多々あります。マスタースケジュールをそのように計画することができませんが、開発の遅延を想定して、総合テストの環境と教育の環境をあらかじめ分けて計画しておくとベストです。
開発環境と本番環境のどちらを先に構築するかも重要です。通常、開発環境と本番環境は同じサーバー構成・スペックではないので、開発環境の構築手順をそのまま本番環境に利用できるわけではありません。本番環境を先に構築して、テストで使ってみて環境の不具合を早期に見つけるプロジェクトも多いです。
２．工程定義
基本的な考え方は RFP と同じです。
マスタースケジュールの工程と工程定義を一致させることが重要です。
また単体テストの定義についても、改めてベンダーと確認します。教科書通りのモジュールレベルの単体テストなのか、それとも単機能の結合テストなのか（画面内のテスト等）、それによって単体テスト以降のテスト工程の考え方が変わってきます。
各工程で作成する成果物も明確にします。
サンプルを作成して、具体的なレベルで認識合わせができればベストです。
成果物の作成は、一連の開発作業の中でかなりの部分を占めるので、このボリュームの認識がずれるとベンダーと揉める元になります。
要件定義工程だから要件定義書、基本設計工程だから基本設計書のような安直な考えで成果物を定義すると、あとで痛い目にあいます。
【振り返り】
今回はプロジェクト計画書に記載するマスタースケジュールと工程定義の説明でした。次回はプロジェクト体制と役割分担の説明です。
①プロジェクト概要（目的、背景、範囲、特徴、前提・制約事項等）
②開発方針（開発手法、技術、テスト環境、パッケージのカスタマイズ方針等）
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール
