［資質編］計画書をコピペしてはいけない

2008.04.08

　プロジェクトを一つこなすと，プロジェクト・マネージャ（PM）は一つ成長する。だが，その進め方次第では，全く成長できないこともある。これについて，南極越冬隊隊長，西堀榮三郎氏が次のことを語っている。

　人材を育てる方法は，ただ一つ。仕事をさせ，成功させることである。成功体験が人を育てる。さらに大きな仕事をさせる。人と仕事の美しい循環を成立させることである。
「プロジェクトXリーダーたちの言葉」（今井彰，文藝春秋）

　成功体験は重要である。それは事実だが，成功した後のことも忘れてはならない。成功体験にこだわっていると，かえって大きな失敗を犯すことがある。

　成功したプロジェクトの計画書をコピー＆ペースト（コピペ）して自分のプロジェクトの計画書を作成し，失敗した例は多い。そのような失敗を経験したPMは西堀氏の言う「人と仕事の美しい循環」の意味を取り違えている。

プロジェクトは“段取り7割”

　プロジェクトの成功・失敗はPMの責任である。プロジェクト計画書は，ベンダーであれば受注後にPMが最初に作成するドキュメントである（図1）。ソフトウエア開発プロジェクトにおいては，段取りを立てる部分に相当する。

図1●プロジェクト計画書の位置付け

　この部分できちんとした計画を立てておかないと，プロジェクトが失敗する可能性は非常に高くなる。筆者はこれを「段取り7割」と呼ぶ。ところが，この段取り部分をコピペして作成するPMがいる。そのPMは，その後のプロジェクトの運命を過去のプロジェクトに委ねているということになる。

D君の失敗

　D君という若手SEがいた。彼は先月まで契約金額数億円という規模の大きなWebシステム開発のメンバーとして活躍してきた。そのときの彼の成果とプロジェクト無事に成功したという成功体験を買われて一躍，小規模ながらWebシステムのPMとして抜擢された。

　D君はプロジェクト計画書を書くに当たり，先のプロジェクトで使った計画書を参考にすることにした。しかし，優秀とはいえ経験の浅いD君である。プロジェクト体制図を作成するに当たっては，そのまま前の計画書の内容をコピーして作成した。D君にしてみれば，初めてのPMということでどういう体制を敷くべきか自分では分からなかったことと，先のプロジェクトが非常に順調に進んだという成功体験に基づく判断であった。

　数カ月後，プロジェクトは暗礁に乗り上げた。原因は，要員不足とチーム間の連携不足である。D君が参考にした前プロジェクトは大規模開発ということもあり，開発側・ユーザー側共にそれなりに要員が確保されていた。チーム編成も，プレゼンテーション層，ビジネス・ロジック層，データ・アクセス層の3層に分けられており，これら3層を業務面から横串で支援する業務チームや，ソフトウエア品質を監視する専属の品質管理チームも存在していた。D君は自分のプロジェクトでも全く同じ構成を取ろうとしたのである。

　しかし，同じWeb系システム開発とはいえ，規模も違えば投入できる要員数も異なる。開発する機能数，画面数，開発期間も全く異なるシステムである。それをそのまま利用してしまったために，要員不足となってしまったのである。

　さらに，必要以上にプロジェクト組織を細切れにしてしまったことによる分割損が大きくなり，忙しい技術者とそうでない技術者との間に溝ができてしまった。これがコミュニケーション不足を生み出し，とうとう各層連携部分の仕様の欠落という結果になった（図2）。