ソフトウェア開発プロジェクトを蝕む10の典型的な過ち - (page 2)

3．現実離れしたスケジュールを組む

　一部のプロジェクト管理手法でよく見られる問題は、スケジュールや時間の見積もりに関して現実離れした想定で決めがちだというものだ。どの開発者がどの機能部分に1カ月か2カ月以上作業するかは分かっていると本気で思っているマネージャーがいたとしたら（非常に大きな、幅広い機能でない限り）、おそらく間違っているし、失望する可能性が高いだろう。ソフトウェア開発は非常に予測が難しいものだ。スケジュールや優先順位を変えてしまう可能性のあるあらゆることを防げるか、それらがすべて想定に入れられたとしても、想定通りの時間で仕事が進むという保証はあまりない。

4．時間の見積もりが大雑把すぎる

　時間の見積もりに関するもう1つの典型的な問題は、作業を十分に小さく分割しないというものだ。もしわたしが、ある仕事に1週間かかるだろうと言われたら、その数字はどこから来たのかと聞き返すだろう。その作業に含まれている小さな作業をすべて分析したのでない限り、「1週間」という時間の見積もりは単なる推測であり、無視すべきだ。

5．作業を計算に入れ忘れる

　テストのような必要不可欠な作業を計算に入れずに決められたために、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。

6．コミュニケーション不足

　常に全員にプロジェクトの状況を周知徹底しておくことは非常に重要であるにも関わらず、忘れられがちだ。これが原因でIT部門と事業部門の間に不信感が生じることも多い。事業部門が、プロジェクトで起こっていることを十分に掌握していないと感じるのだ。また、暗闇に取り残されていると感じるほど、事業部門はIT部門に対してマイクロマネジメントをし始めようとしたり、やり方を強制しようとする。関係者に対して、定期的に報告をし、また一定の節目を迎えたり状況が変わったりしたときに状況を知らせておけば、この問題を緩和することができる。

7．ビジネス上の優先順位を無視する

　開発を進めている組織内でのプロジェクトの優先順位と、全体的なビジネスの観点から見たプロジェクトの優先順位、そして開発を要求している側から見たプロジェクトの優先順位の間には、大きなギャップがあることが多い。よくある問題は、ある部門にとって「優先順位の高い」プロジェクトが、収益を生まないためビジネスの観点からは重要視されず、このため開発者もそのプロジェクトの優先順位を下げてしまうというものだ。全員の優先順位が一致している必要があり、そのためには、ビジネス全体から見て優先順位が低いと見なされているプロジェクトを元に、事業部門が評価されないということを保証する必要がある。