プロジェクトの活動計画　－まとめ－

　今回、調査結果の評点の高かった企業の具体的な事例を通して、開発規模の違いで計画書に記載される項目が異なること、計画書の中身だけでなく、計画を成立させる仕組みが組織に必要であることを確認できた。成功事例を他の組織にそのまま適用できるとは思えないので、以下にまとめとして、成功するプロジェクト活動計画を作るためのプロセスと組織の仕組みについて整理した（下図参照）。

図 活動計画を作るためのプロセスと組織の仕組み

　冒頭で紹介したPMBOKの計画項目を計画書の中に全て含んでいるわけではなかったが、標準プロセスや組織の仕組みなど、違う形で実践されているともいえるのではないだろうか。

 1.根拠ある見積

• 要件の分析後作業タスクを洗い出し、過去の類似した開発実績や、実績をもとに作られた標準工数や日数を参考にして、根拠のある見積を作成する。
• このとき、活動を細分化し工数や期間を積み上げて見積りするだけでなく、過去の実績データと比較したり、各活動に潜むリスクを洗い出し余裕を持たせたり、過去の教訓から必要な活動を追加したり、等することで、より根拠ある見積を作成できる。根拠を示すことで関係者の理解やレビューが可能にもなる。
• 過去実績を組織的に蓄積し分析を行なう組織的な仕組みが、根拠ある見積を作成する上で必要になる。

 2.計画作成

• 活動に抜け漏れが多ければ計画通りには進まないため、計画はスキルと経験を持つ者が作成し、抜け漏れの少ない実行性ある計画とすること。また全てを予見して計画に盛り込むことは不可能だしそうするためには時間もコストもかかる。多少抜け漏れがあってもカバーできる程度に余裕を持たせた計画を作成する必要がある。過去の実績をベースにした作業標準や標準プロセスがあると、その抜け漏れを軽減することが可能となるだけでなく、見積精度の安定にも貢献できる。
• 開発に関与する部門の活動計画を統合し、かつ計画間の整合性をとり、各部門に承認をもらうこと。
• 計画に思いを込めること。（思いを込めることで、形骸化を防止できる。）
  例えば、開発者が直にエンドユーザの現場を訪問し意見交換等を行うなどして、使命感や達成感を得る場合がある。この開発者の計画にはものづくりに対する思いが込められるという。
• 計画には日程やコストだけでなく、必要に応じて品質面での目標を具体化した計画等も含めること。
• 所帯の大きいプロジェクトであれば、各チームを方向つける方針やチーム間のコミュニケーションや調整方法といったプロジェクトの決まりやルールも準備すること。ただし、新しいルールの徹底は難しく時間もかかるため、組織内に普段から情報共有のルールやコミュニケーション方法が確立できているほうが望ましい。
• 開発が進むとともに計画を実行可能なレベルに詳細化し、必要に応じて再計画する。
• 計画を関係者間で常に共有し見える状態にしておくこと。（進捗は計画とのずれを見るもの。進捗管理では計画が常に基準となる。）

 3.有識者のレビュー

• スキルと経験を持つ者がレビューを行なうことで、作成者の思い込みや経験不足をカバーし、より抜け漏れの少ない実行性ある計画とすることができる。
• 有識者として、資格を与えて運用している組織もあるが、直近の類似プロジェクトのPMをレビューに参加させている組織もある。

 4.関係者のコミット

• 開発に関与する部門やメンバから作成した計画についてコミットを得なければならない。
• コミットがあっても突発的な問題が発生しどうしても計画とおり推進できない場合もある。そのような場合にリソース調整や決定を行なう仕組みがあるとすばやい意思決定が行なえる。追加リソース、特に要員補充の場合、戦力として使えるまでに時間がかかるので、開発期間に猶予が与えられない以上、リカバリープランに対する意思決定は早急に行なわなければならない。

 おわりに

　昨今益々、少量多品種、短納期、他社製品との差別化が求められている。開発現場においては、最初立てた計画が開発途中で見直されることも多いのではないだろうか。計画が見直しできるからといって最初の計画がいい加減であってよいはずがなく、また現場が混乱するので頻繁に見直すものでもない。見直した計画にも、最初の計画と同様に根拠ある見積と関係者のコミットが当然必要である。今回の報告はプロジェクト計画のプロセス改善を進める組織にとって有益な情報となるであろう。是非参考にしてほしい。

多事想論