プロジェクト計画書（３）
前回に続き、プロジェクト全体計画に関して説明していきます。
前回の記事をご覧になりたい方はこちらからどうぞ。
-
-
参考プロジェクト計画書の作成（２）
プロジェクト計画書（２） それでは前回に引き続きプロジェクト計画書の作成について説明していきたいと思います。 前回の記事をご覧になりたい方はこちらからどうぞ。 まずは、計画書の概要や目的についての記載 ...
続きを見る
第2章
2-2.各工程の考え方と作業計画
ここでは、プロジェクトの各工程を定義します。
今回は、一般的なウォーターフォール型開発の工程で説明しますが、Salesforce開発プロジェクトでは、「アジャイル開発でお願いします」というお客様のリクエストが多いと思います。
ただし、よくよく話を聞くと契約方式も含めて、100%アジャイルでやるということではなく、アジャイルっぽく進めたいという曖昧な場合がほとんどです。
あとは、アジャイルとウォーターフォールのハイブリッドという便利な言い回しですね。この言葉には特に気を付けてください。
実際に契約はどうするのか、工程はどう考えるのか、アジャイルでシステム機能単位でテストまで含めてサイクルを回して完成させていくというスタイルで本当に進められるのか、お客様の業務やプロジェクトの特性など踏まえ実現可能か慎重に検討してください
このページで記載する内容は以下となります。
参考
- 工程名称：お客様が使う工程名と差異がある場合があるため、使う名称もお客様と合意しておきましょう
- 作業概要：各工程で行う作業を明確にします。要件定義と基本設計を一緒にしているプロジェクトも見かけますが、その場合は、基本設計（外部設計）の部分はどこまで、なにをやるのか明記しておきましょう。
- 作業期間：工程の作業期間（From-To）を記載します。 ※契約の内容とずれないようにしましょう。
2-3.各工程の開始/終了クライテリア
工程を定義したあとは、各工程のクライテリア（クライテリアとは、各工程での主要なタスクの開始と終了を判定するための評価基準）を定義します。
【クライテリア設定の目的】
特にウォーターフォール型の開発では、スケジュールの関係などで工程が平行して進められることも多々ありますが、その場合に、全工程が終了しているかどうかを明確に判断するためにも、クライテリアの定義は重要となります。
各工程のクライテリアの例としては以下のようなものがあります。
参考
クライテリア（成果物）
- 各部門の現行業務について業務プロセスが抜け漏れなく定義されていること (現行)業務プロセス図、(新)業務説明書
- 現行業務プロセスに対する課題に対して、解決策が検討されていること 業務課題改善案（業務要求一覧）
- 各部門の新業務について業務プロセスが抜け漏れなく定義されていること (新)業務プロセス図、(新)業務説明書
- 新プロセスに対するシステム化対象が明確に定義されていること (新)システム機能一覧
2-4.マスタスケジュールとマイルストーン
続いて、プロジェクトのマスタスケジュール（Master Schedule)とマイルストーン（Milestone)を定義します。
新システムの稼働時期（目標）はRFPで提示されていることも多く、契約前に決まっていることがほとんどだと思います。
カットオーバー（本番運用開始）時期が決まっていてそれが変更不可の場合、カットオーバーに合わせて各工程の期間を定義していく必要があります。
ここで気を付けるべきは、各工程の比率が一般的な開発プロジェクトの比率と大きくかけ離れていないかをチェックしておきましょう。
例えば、要件定義で4か月かけて実施するのに、設計・開発が2か月となっているなど。
標準的な開発期間に関しては、独立行政法人 情報処理推進機構（IPA）が発行している「ソフトウェア開発データ白書」を参考にしてください。
（外部リンク）独立行政法人 情報処理推進機構（IPA）「ソフトウェア開発データ白書」
マイルストーンに関しては、定義した工程のクライテリア評価時期を定義しておきましょう。
お客様もどの工程（プロセス）で遅延が発生するとマスタスケジュールの遅延につながるのか気にされています。
2-5.体制と役割
体制と役割のページでは、お客様と自社及びその他関係者全員の役割と体制を定義します。
お客様側やその他ステークホルダーの体制と役割に関しては、事前に確認しておきましょう。
自社の体制に関しては、プロジェクト責任者とよく相談して決めましょう。
プロジェクトの規模にもよりますが、一般的には以下のような体制を構築します。
- プロジェクト責任者、営業担当、プロジェクトマネージャ、（PMO）、プロジェクトリーダ、メンバー
大型案件の場合、管理系作業のボリュームが大きいため、PMとサブPM、PMOを2名体制にすることもあります。
また各業務/システム領域ごとに業務リーダー（PL、サブPL）をそれぞれ立てて、各領域の進捗はそれぞれのPLが取りまとめてPMOへ報告するなどのやり方をする場合もあります。
当然体制を増やすとコストも増加するため、あらかじめ提案時にプロジェクトの規模やリスクなどを考慮し、体制を検討しておきましょう。
またお客様や第三者ベンダーとのコミュニケーションの窓口も明確にしておきましょう。
業務/システム領域で担当を分けている場合は、それぞれお客様側の業務担当者とやり取りをした方が効率が良い場合もあります。
参考
- プロジェクト全体に関するコミュニケーション：お客様PM⇔当社PM
- 人事系業務に関しては、お客様人事担当者（〇〇様）⇔当社人事担当領域担当PL
- 会計業務に関しては、お客様会計担当者（〇〇様）⇔当社会計領域担当PL
当社内の体制と役割を明記する場合
当社内の体制と役割の詳細をさらに明記する場合は、以下のような形で提示するとよいでしょう。
こうすることで、お客様や関係者からみて、だれが何をする人なのかすぐに理解することができます。
参考
- 担当者の役割と氏名 ※下記例では、人のアイコンの色を分けて男女どちらかわかるようにしています。
- 本プロジェクトにおける責任と役割：役割を具体的に明記します。
2-6.成果物/納品物
最後にプロジェクトで作成する成果物/納品物を定義します。
納品物に関しては、基本的に契約時に提示しているはずなので、提案書の内容に基づいて記載すればよいです。
それ以外にも要件定義の確認のために一時的に作成する資料や設計の前段階で作成するような成果物があると思いますが、これらも成果物としては定義してもよいですが、納品の義務はないため、納品対象外とわかるように明記しておきましょう。
（納品対象かどうかの列を設けるとよいでしょう）
また、納品物の媒体や様式についてもこの時点で明確にしておきましょう。
できればサンプルのテンプレートを用意しておき、それらを合わせて提示することで認識の相違をなくすことができるため、早い段階で合意をしておくことをお勧めします。
ポイント
ここは本当に注意が必要で、お客様と揉めることが多いため成果物のうち何を納品対象とするのか、またレビュー対象とするのかを明確にしておきましょう。
また、議事録については特に注意が必要で、議事録を納品物としてほしいという要望もよくありますが、この場合には、議事録の作成者、記載粒度、承認方法、位置づけなどを必ず確認してください。できればサンプルを提示して合意することをお勧めします。
議事録の作成者が自社メンバーの場合は、どの会議体で誰が議事録を作成するか明確に役割として定義しておきましょう。
※議事録の工数も必ず見積に見込んでおいてください。
例えば、一般的な要件定義では以下のような成果物を納品物として定義することが多いでしょう。
参考
- 新業務フロー図
- 業務説明書
- 要件定義書（システム機能一覧、画面一覧、帳票一覧、IF連携一覧、オブジェクト一覧）
- 非機能要件定義書（移行要件、教育要件含む）
２．プロジェクト全体計画まとめ
以上でプロジェクト全体計画に関する記載の説明が終了となります。赤文字の箇所については、よく読んで理解してください。
多くのプロジェクトで問題になる可能性が高い内容となりますので、必ず内部の関係者全員で協議し、事前の対策を検討することを強くお勧めします。
続きは、次の記事へ
-
-
参考プロジェクト計画書の作成（４）各工程の品質計画についてまとめ
プロジェクト計画書（４） 続いては、品質計画について記述していきます。品質管理に関しては、ここで全体を詳細に述べることはしません。 （ボリューム的には品質のところだけで本が1冊書けるくらいの内容があり ...
続きを見る
関連記事
