プロジェクト内容
|
中堅SIベンダーX社。運送会社の配車管理システムの開発をしている。システムは、車載端末からリアルタイムで情報を得て、トラッキングするとともに、再配送の指示、荷物の受け取りの指示などをするシステム。
登場人物 Aさん 今回のシステムのプロジェクトマネージャー。
Bさん 今回のプロジェクトの承認をするAさんの上司
<AさんがBさんにプロジェクトの月次概況報告をしている場面>
Aさん「予定通り、先週からテストに入りました。テストも順調で、テストケースの半数を終えたところです」
Bさん「何か問題はあるか」
Aさん「今回の外注先のZ社はあまりよくないですね。結合に入ってかなり、バグがでて、結構、修正に苦労しています。が、何とかテストケースは予定通りに消化していっています」
Bさん「そうか、引き続き、がんばってくれ」
<次の月にAさんがBさんにプロジェクトの概況報告をしている場面>
Bさん「どうかね、もう、そろそろテストも終わりじゃないか?」
Aさん「計画ではそうなっています。実際に、テストケースの数でいえば終わっているんですが、ただ。。。」
Bさん「ただ、何だね?」
Aさん「テストの結果でバグ修正したところがかなり多くて、結局、影響のある部分を再テストしているとテストしたテストケースの数は順調に増えているんですが、まだ、終わらないという状況になっています」 |
このプロジェクトの結末 |
テストが結局予定の3倍の時間がかかり、その分、プロジェクトは遅延した。 |
問題点 |
これはプロジェクトマネジメントの中で陥りやすい罠である。人間が管理をするときには、どうしても分かりやすい部分でチェックする。その典型が予算である。予算を見ていて、順調に消化していれば、プロジェクトによほど大きな、しかも予想外の異変がない限り、プロジェクトは順調に進んでいると考えてよい。
同じ感覚で成果物を定量化し(たとえば、画面何枚、モジュールいくつ、ドキュメント何枚、テストケース何点)、それに注目して進捗を把握することがあるが、その際に、過去に完了した成果物が、プロジェクトの進捗とともに仕様変更などがあり、無用になるというのは実はよくあるケースである。
ここで注意しておきたいのは、この種のトラブルではもちろん、手戻りが出ることも問題なのだが、むしろ、ある時点までそれに気がつかないことが問題だという点である。 |
処方箋 |
・数字の裏を取る
・複眼的な異常検出 |
解説 |
このような罠にはまらない方法はひとつしかない。進捗管理をきちんとやって、手戻りが出てきたことをできるだけ早いタイミングで認識し、そして手戻り分を早いタイミングで計画に反映していくという計画変更管理をきちんとやることである。ただし、問題は進捗チェックの方法にある。
別の項目でも述べたように進捗管理を定量的に行うことはよいことであるが、機械的に行うことは考えものである。それがすべてになってしまうからだ。たとえば、進捗管理の中で予算の消化状況を見るというのはあくまでも以上を早期に検知するためであり、予算がきちんと消化していればプロジェクトが順調かというとそんなことはない。誰かが意図的に予算を消化しているのかもしれないし、意図的ではないとしても予算が順調に上がっているからといって、作業が予定通り進んでいるという保証はない。管理というのはえてしてこういう落とし穴にはまりやすい。
そのように考えて、異常の検出にも複眼的な視点を常に持つ必要がある。つまり、クロスチェックである。このケースでも、設計したモジュール数だけはなく、たとえば、修正したモジュール数も見ておけば、もっと早いタイミングで気がついた可能性がある。あるいは、作業時間の分析をしていれば、気がついたかもしれない。 |
ワンポイント |
管理というのは複眼的に行うべきである。プロジェクト管理の手法は計数管理にどうしても注意が行ってしまう。それは悪いことはでなく、むしろ、よいことだが、計数管理の一方で、常に内容のチェックをしておき、整合性を取ることは不可欠である。 |
参考文献: |