プロジェクト計画書（２）
それでは前回に引き続きプロジェクト計画書の作成について説明していきたいと思います。
前回の記事をご覧になりたい方はこちらからどうぞ。
-
-
参考プロジェクト計画書の作成（１）
今回の記事は、プロジェクトの計画策定がテーマとなります。 営業の提案が採用されると、その後正式に契約となりますが、契約締結後（もしくはもう少し事前に）プロジェクト開始のための準備を始める必要があります ...
続きを見る
まずは、計画書の概要や目的についての記載から説明していきます。
はじめに（本書の目的）
ここでは、本書（プロジェクト計画書）の作成目的を記載します。
本ページは省略しても構いませんが、基本的に資料を作成する際は、その資料が何の目的で作成されたものかを利用者がわかるように記載しておきましょう。
目的の例）プロジェクト計画書（本書）を作成することにより、本プロジェクトに参画されるすべてのステークホルダー間で以下の内容についての合意形成を図ることを目的とします。
- プロジェクトの目的・ゴール（達成指標）
- プロジェクトの進め方（体制・役割、スケジュール等）
- QCD（品質・コスト・納期）管理方針
- 関係者間のコミュニケーション方針
１．プロジェクト概要
1章ではプロジェクト概要を記載します。
1-1.プロジェクトの目的とゴール
プロジェクト概要の最初は、プロジェクトが発足する契機となった背景やプロジェクトの目的を記載します。
プロジェクトの背景については、基本的にRFPの内容を転載したり、RFPの内容をベースに記載することが多いです。
内容としては、現状の課題や問題点を挙げるケースがほとんどです。例えば、背景としては、以下のようなものがあります。
参考
- 現行業務では各営業担当がそれぞれ独自のエクセルファイルで顧客情報を管理しているため、顧客データが散在しており、データの検索や分析に時間がかかる
- 承認申請や事務処理の社内業務では、電子化できておらず、いまだに書類の運用が多く、作業効率が向上できず、原本の管理も煩雑になっている
また、目的としては、基本的に上記の背景に対して、具体的な解決策の方針と最終的にどのような状態になっているべきかを記載することになります。
それぞれの課題に対になる形で目的を書いてもよいし、まとめて将来像を提示してもよいでしょう。
それぞれに対応した形で目的を書く場合の例
参考
- Salesforceで顧客情報を一元管理することにより、効率的なデータ検索や多角的な分析を可能とする
- 承認申請を電子化することによりペーパーレスを実現し、社内業務の効率化を目指す
全体的にまとめて将来像を示す場合の例
参考
- Salesforceプラットフォームを利用した新顧客管理システムを構築することにより、俗人化を排除し、散在している顧客情報を一元管理する。
- 蓄積されたデータを活用し、これまで以上に高度で多角的な顧客分析を行うことで、顧客への最適なアプローチを導出し、顧客満足度の向上を目指す
1-2.プロジェクトスコープ（開発範囲）
プロジェクトのスコープ（開発範囲）を明記します。
あとでこの部分もやってくれると思っていたのに話が違うということがないように、最初から明確にスコープを定義しておきましょう。
スコープ（開発範囲）の表現方法はいろいろありますが、以下のようなやり方が一般的なようです。
参考
- システム構成図（ポンチ絵）を用意して、赤枠で範囲を囲み、開発対象とそうでないシステムを明確にする
- 作業工程（要件定義、基本設計、詳細設計、開発、テスト、移行）を矢羽根で表現し、どの工程が作業範囲化明確にし、また各工程での作業概要を記載することで、作業工程と作業内容の範囲を明示する。
- 上流工程が終了していて開発以降を請け負うような場合には特に注意する必要があります。
- 開発を行う対象の機能一覧をベースにして、どの機能をどのように開発するかまでしっかり確認するようにしましょう。
- システム構成図（ポンチ絵）を用意して、赤枠で範囲を囲み、開発対象とそうでないシステムを明確にする
- 作業工程（要件定義、基本設計、詳細設計、開発、テスト、移行）を矢羽根で表現し、どの工程が作業範囲化明確にし、また各工程での作業概要を記載することで、作業工程と作業内容の範囲を明示する。
- 上流工程が終了していて開発以降を請け負うような場合には特に注意する必要があります。
- 開発を行う対象の機能一覧をベースにして、どの機能をどのように開発するかまでしっかり確認するようにしましょう。
1-3.要求機能概要
続いて、システムの位置づけについての説明を記載します。ここについてもRFPや提案書の内容をベースに記載すればよいでしょう。
新しく導入するシステムが経営や業務において、それぞれどのような位置づけになるかを明記します。
どのような目的で作成・利用されるのかが明確にわかるような記述にしましょう。
1-5.システム構成図
システム構成図は、大型案件であればRFPで提示されている場合も多いと思います。
提示されている場合は、それを利用しても構いませんが、要件定義書などの成果物として提示したり、プロジェクト終了まで利用することも多いため最初に作成しておくことをお勧めします。
システム構成図を作成することで、要求事項の全体像を整理することができます。
その際、現行システムとの関係性や、外部システムとの関係性、システム機能の位置づけなど不明点や未確定事項が出てくることも多く、早めに確認して対処することで認識の相違を防止することにもつながります。
1-6.ネットワーク構成図
社内ネットワークからSalesforceにアクセスする際のルートだけではなく、モバイルを利用する場合のルートや外部システム連携がある場合には、外部システムとSalesforce間のルートなどを定義します。
第一章は以上の内容となります。
次の第二章では、プロジェクトの全体計画を記述していきます。
２．プロジェクト全体計画
全体計画としては、以下の事項について記述します。
- プロジェクトの評価方法
- 全体計画（工程計画と作業概要）
- 各工程の開始/終了クライテリアの定義
- マスタスケジュール・マイルストーン定義など
2-1.プロジェクトの評価指標
まずは、プロジェクトが成功したかどうかを判断するための評価指標を定義します。
社内プロジェクトの場合などには記載していることもありますが、お客様に対して、プロジェクトの評価指標を提示するということは、プロジェクトを請け負う側のリスクになる場合があるため、明記されていないことが多いように思います。
評価指標を定義する場合は、通常QCD（Quality:品質、Cost：コスト、Delivery：納期）の観点でそれぞれ定量的に記述します。
例としては以下のような指標を定義します。
参考
- バグ件数：サービス開始直後Nか月間においてプログラムバグをN機能あたりN件以下とする
- コスト：プロジェクト計画時の予定原価以下でシステム構築を完了すること
- 納期：プロジェクト計画時の計画（マスタスケジュール）通りに進行し、遅延なく本番稼働を迎えること（遅延日数：0日）
続きは、次の記事へ
-
-
参考プロジェクト計画書の作成（３）各工程の作業計画~成果物/納品定義
プロジェクト計画書（３） 前回に続き、プロジェクト全体計画に関して説明していきます。 前回の記事をご覧になりたい方はこちらからどうぞ。 第2章 2-2.各工程の考え方と作業計画 ここでは、プロジェクト ...
続きを見る
