プロジェクト計画の作り方

1 / 2
プロジェクト計画作成の流れ
プロジェクト計画作成の大まかな流れは、以下のフローで表すことが出来ます。
次の項目からは、それぞれフローの詳細について説明していきます。
プロジェクトプロファイルの作成
プロジェクトプロファイル作成の目的は、プロジェクトの概観を掴むことです。
その為、プロジェクトプロファイルでは以下の項目を明確にしなければなりません。
- プロジェクト種別
- プロジェクト期間
- プロジェクトオーナー
- プロジェクトリーダー
- 営業担当者名
- 主管部門
- 品質担当者(QR)名
- 案件No
- 顧客名
- 顧客担当者名
- プロジェクト目的
- プロジェクト目標
- 制約条件
- 前提条件
- プロダクトスコープ (*開発プロジェクトのみ)
- ステージスコープ (*開発プロジェクトのみ)
- ソースプロジェクトNo (*保守プロジェクトのみ)
- 保守窓口担当者 (*保守プロジェクトのみ)
上記の情報は、
案件管理ライブラリに記載されている内容を元に、
顧客やプロジェクトオーナーとの折衝により決定します。
これらの内容を明確にした後、プロジェクトリーダーはCOMPASS-ITSの
プロジェクト登録画面を使用してプロジェクトプロファイルを登録します。
以下、画面のサンプルを示します。
各項目の入力が完了した後、プロジェクト登録画面の下方に存在する登録ボタンをクリックし、
プロジェクトプロファイルを登録して下さい。
既にプロジェクトプロファイルが登録されている場合は更新(上書き)ボタンをクリックして下さい。
(*更新(Revアップ)ボタンは、プロジェクト計画が合意され、確定された後に
クリックするボタンですので、この段階では、クリックしないで下さい。)
[コラム] プロジェクトスコープとプロダクトスコープ |
スコープを明確にすることは、プロジェクトの概観を掴む為の第一歩ともいえます。
プロジェクト管理において、スコープはプロジェクトで作成する成果物とプロジェクトで行う
作業の両方の側面から見ることが重要になります。作成する成果物の側面からみたスコープを
プロダクトスコープと呼び、行う作業の側面からみたスコープを
プロジェクトスコープ(ステージスコープ)と呼びます。
下図はスコープに対するイメージを載せた図です。
|
WBSの作成
プロジェクトプロファイルで明確化された目標を達成する為に、どのような作業(タスク)を行えば
よいかを明確化します。より詳細なタスクを作成していく為に、大きなタスクから実行可能な
細かなタスクへブレイクダウンしていくと言った方法で明確化していきます。
この時に出来る作業成果物が
WBS(ワーク・ブレイクダウン・ストラクチャー)です。
WBSの作り方はフェーズを基点にどのようなタスクを行うかを明確化していく方法と
作業成果物を基点にどのようなタスクを行うかを明確化していく方法の2点が考えられます。
また、それらの複合系でも構いません。下図は複合形式のWBSのサンプルです。
 |
複合形式のWBSのサンプル
この図では最初に単体テストというフェーズの視点で切り、
次に作業成果物(○○コンポーネントの単体テスト)という視点で切っている。
|
WBSを作成する時には、単純に成果物を開発する活動だけでなく、
成果物の品質を向上させる為の活動やプロジェクトを管理する為の活動なども
明確化しておく必要があります。
基本的にプロジェクトで行う活動は全てWBSに反映させるようにしましょう。
この時点のWBSでは、以下の項目を明確にしておく必要があります。
(下記項目に関する詳細な情報は(付録)タスクの各項目に関してを参照ください)
- タスク名
- 活動種別
- 作業ステージ
- タスク種別
- 成果物種別
上記の情報はプロジェクトプロファイルの情報
(特にプロダクトスコープとプロジェクトスコープ(ステージスコープ))
を用いて決定します。
これらの情報を明確にした後、Microsoft Projectを用いてWBSを作成していきます。
WBSのサンプルを作成しましたので、項目をどのように入力してよいか分からない方は、
WBSサンプルファイル〜WBS作成時を参照してください。
作業量の見積り
WBSの各タスクに対して、どのくらいの工数が掛かるかを予測する為に、
見積りを行ないます。基本的に、見積りでは、作業成果物の規模を見積った後に、
それらの活動に対してどれくらいの工数が掛かるかを見積っていきます。
見積りの手法に関しては、
見積もりガイドライン
を参照して下さい。
この時点のWBSでは、以下の項目が明確にしておく必要があります。
上記の情報を、作成したWBSに反映させます。
WBSサンプルファイル〜工数見積時を参照してください。
[コラム] 見積管理に関して |
見積りとは、成果物の未来像を想像し、「大体こんなものだろう」と予測を立てる行為です。
その為、開発終了後に、実際の規模を計測してみると見積りよりも多かった少なかったと思うことは
珍しくありません。(最も作業工数が同じだからといって、必ずしも見積りが適切だったとは言えない
部分もあるのですが・・・。)
予測を的中させる為には、豊富な実績データが必要です。その為、フルバージョンのCOMPASSでは、
見積りは見積DBに登録することが義務付けられています。
この見積DBには、見積り時の規模・工数だけではなくて、
見積種別と見積根拠を記入し、追跡していく必要があります。
このような情報を残すことで、見積りの精度が徐々に上がって妥当な見積が出力されるようになります。
見積りの失敗は、ソフトウェア開発プロジェクトの失敗原因のNo.1と言われています。
プロジェクトの失敗を防ぐ為にも、見積りの管理を行っていきましょう。
|
リソース計画の作成
プロジェクト活動を行う為に必要なリソース(人・物)とその役割を
明確化し、作成したタスクに割り当てる必要があります。
リソース計画の作成では以下の活動を行う必要があります。
- リソース計画の作成
- プロジェクト体制の構築
- タスクへのリソース割り当て
リソース計画の作成
プロジェクト活動を行う為に必要なリソース(人・物)とその役割を
明確化する為に、リソース計画を作成します。
リソース計画では以下の項目を明確にしなければなりません。
- リソース名
- フェーズ
- 必要数
- 種別
- 役割
- 必要スキル
- 充足数または担当者名
- 不足数
- 不足リソース獲得計画(*リソースが不足している場合のみ)
上記の情報は、WBSやプロジェクトプロファイル、組織の状況などから
総合的に判断して決定します。
リソース計画では、組織のリソースを使用するため、
ラインマネージャー(課長)や
シニアマネージャー(部長)の協力が必要になります。
これらの内容を明確にした後、プロジェクトリーダーはCOMPASS-ITSの
アサイン画面を使用してリソース計画を登録します。
以下、画面サンプルを示します。
上の2つの画面のうち、上の画面は、プロジェクトに人を割り当てる画面です。
前述した項目のうち
を明確にします。
社員追加ボタンをクリックして、社員を選択することで、
所属と社員名が選択されます。所属と社員名を選択した後、期間と役割を入力します。
役割の定義に関しましては、
役割マップを参照してください)
各項目の入力が完了した後、アサイン(人)画面の下方に存在する
登録ボタンをクリックし、
リソースを登録して下さい。
リソースが登録できた後、
アサイン(工数)へボタンをクリックすることで、
下の画面が現れます。
この画面は、登録されたリソースの稼動を割り当てる画面です。
この画面は人個別の週単位で入力できますが、
画面サンプルで8が入力されている項目が、各個人の一日の稼働時間を表す時間です。
画面サンプルで5や4が入力されている項目が、週の稼働日数です。
自動計算ボタンをクリックすることで、
この2つの積で与えられる時間が自動的に入力されます。
各項目の入力が完了した後、
登録ボタンをクリックすることで、
リソースの稼動が登録されます。
[コラム] トレーニング計画に関して |
プロジェクトにアサインされるリソースは、毎回、プロジェクトリーダーの望む
ようなリソースがアサインされるとは限りません。
(寧ろ、理想的なアサインがなされる事の方が少ないかと思います。)
プロジェクトで必要となるスキルまで到達していないメンバーをアサインする
ということは、明確なプロジェクト目的になっていなくとも、
日常的に行われることです。
このような場合、スキルギャップを埋める為に、プロジェクトでは、
トレーニングを計画する必要があります。
COMPASSではプロジェクトに必要なトレーニングを特定するプロセスが明確に
規定されています。
COMPASS-Liteでも必要になることは間違いありませんので、行ってみて下さい。
|
プロジェクト体制の構築
リソース計画を登録した後は、どんな場面で誰とコミュニケーションを
とればよいかを明確にする為に、プロジェクト体制図を作成します。
プロジェクト体制図では、どんな時に誰とコミュニケーションをとるのかを
という
コミュニケーションルートを明確にすることが重要になります。
プロジェクト体制図の中でコミュニケーションルートは、
コミュニケーションを取るべき人同士を線で繋ぐことによって記述されます。
サンプルを作成しましたので、どのように記述してよいか分からない方は、
プロジェクト体制図サンプルを
参照してください。
[コラム] ステークホルダーとプロジェクト体制に関して |
プロジェクトの成功は、ステークホルダー全員の満足にあります。
従って、プロジェクトにおいてステークホルダーを適切に認識することは重要です。
サンプルで作成したプロジェクト体制図において、顧客側の体制や
組織の体制まで記述しているのはステークホルダーを認識しておく為です。
全てのステークホルダーを書き出すのは難しいかもしれませんが、
コミュニケーションを取る必要のあるステークホルダーは、
きちんと書き出しておくべきでしょう。
|
タスクへのリソース割り当て
リソース計画の作成の最後に、リソース計画でアサインされたメンバーを
WBS上に書かれてある各タスクへ割り当てる必要があります。
サンプルを作成しましたので、入力方法がわからない方は、
WBSサンプルファイル〜アサイン時を参照してください。
プロジェクトの最適化
プロジェクトの目標が達成できるように、プロジェクトの最適化を行います。
目標が達成できない場合は、メンバーの入れ替えや作業順序を入れ替えたりして
明確化していきます。また、必要に応じて作業の外注化を計画することもあります。
最適化した結果をこれまで作成してきたドキュメント(プロジェクトプロファイル、
WBS、リソース計画...etc)に反映させます。
[コラム] 最適化の方法 |
最適化には様々な方法があります。ここではその中の一部を紹介しています。
- クリティカルパス
タスクの依存関係からプロジェクトのクリティカルな部分に着目し、
その期間を短縮させることで期間の短縮を図ります。
- 山崩し
工数を平準化することで負荷の偏りを避け、期間の短縮を図ります。
- 人の入れ替え
より生産性の高い人物を入れることで、工数の削減を図ります。
但し、プロジェクトの途中で入れ替えた場合は、トレーニングなどの
作業が別途必要になりますので、工数が増大します。
- 人の追加
工数の分散を行うことで、期間の短縮を図ります。但し、
人が増えることで管理コストは増大します。(基本的に、コミュニ
ケーションパスの分だけ管理コストは増大すると言われています)
その為、安直にこの方法を取ると却って、期間の増大を招きかねません。
また、基本的に人の追加は工数を増大させることも忘れてはなりません。
(トレーニングコストなどが必要な為)
- リスクの許容
リスクを許容することで、工数の削減や期間の短縮を図ります。
必要な作業成果物が出来上がる前に作業を開始するラグタイムなどはその一つと言えるでしょう。
- 本番時期の変更
本番時期をずらすことで、期間の確保を図ります。
ユーザーの理解と協力が必須です。
- スペックダウン
成果物の仕様をダウンさせることで、工数の削減を図ります。
ユーザーの理解と協力が必須です。
|
リスクの特定
プロジェクトの成功を妨げる要因となるリスクを特定し、リスクに対する対処方法を決定します。
詳しくは、
リスク管理ガイドラインを参照して下さい。
管理計画の作成
各種管理計画を作成します。管理計画には以下のような種類があります。
- メトリクス計画
- 構成管理計画
- 検証計画
- 外注管理計画
- 進捗管理計画
個々の管理計画作成に対する詳細は、
(付録)管理計画に関してを参照してください。
プロジェクト計画の作成(全計画の統合)
プロジェクトプロファイルやWBS、管理計画などこれまで作成した
全てのドキュメント統合し、1つの計画として保管します。
[コラム] プロジェクト計画のバージョン |
プロジェクト計画は、進捗管理計画などそれぞれ個別のバージョン以外に、
プロジェクト計画全体で1つのバージョンを持つ必要があります。
何故なら、それぞれ個別のアーティファクトは、
お互いに密接に絡み合いプロジェクトの進行を補助するものだからです。
例えば、進捗管理計画のバージョンだけを見ても、それはどんな前提で書かれた
計画なのかをきちんと踏まえる必要があります。
システム開発に例えると、個別のアーティファクトがコンポーネントで、
プロジェクト計画は、全体のシステムと言えるでしょう。
|
プロジェクト計画の合意
プロジェクト計画を全ステークホルダーで合意します。プロジェクト
計画の変更に応じて、会議を開催して合意をとるか、それとも
メールなど文書の回覧のみで合意をとるかは
その重要性により判断して下さい。
但し、原則、プロジェクト計画が作られた最初の一回目の合意は、
キックオフミーティングという形で会議形式による合意を行うようにして下さい。
[コラム] キックオフミーティングの意図 |
キックオフミーティングはプロジェクト計画の合意の他に、
プロジェクトをこれから開始すると言うことをステーク
ホルダーへ意識付けするのにも一役買います。
|
おわりに〜プロジェクト計画を有効活用するために
ここまでプロジェクト計画を作成してきました。これで目標がしっかりと
定まりいよいよプロジェクトがスタートできるところまで来ました。
しかし、いざプロジェクトが進行すると思った以上に
そしてあまりにも計画から乖離しすぎると、プロジェクト計画そのものが
プロジェクトの足枷と感じることが出てくるかもしれません。
というものは日々変化する
ということです。
最初に書いたプロジェクト計画はまだ手探り段階で書いていますので、
必ずしも計画通り行くとは限りません。
そしてあまりにも計画から乖離しすぎると、プロジェクト計画そのものが
プロジェクトの足枷と感じることが出てくるかもしれません。
計画が重要な意味を持つのは
プロジェクト計画で重要な要素は

1 / 2