あまりにもひどい。確かに、プロジェクトメンバーを打ち合わせに呼ばないのには、それなりの理由があることも多い。例えば、彼らには関係がないのかもしれないし、「船頭が多すぎる」という問題が起こりがちだという理由もあり得る。しかし結局は、プロジェクトの全員が、少なくともどのような議論が行われているかを知っている必要がある。わたしも、議論されていることをまったく知らないという似たような状況に陥ったことがあり、その結果そのプロジェクトでは、隠された要件を満たすことができなかった。
4．機能よりも形を重んじる
長年の読者であるTony Hopkinson氏は、関係のないことにのめり込んでしまうプロジェクトが多いと指摘しているが、彼は正しい。例えば、プロジェクトそのものが「ダッシュボードを作る」というものでない限り、ダッシュボードに取り組み始めるのは、アプリケーションの実際の機能が整ってからにすべきだ。準備が済む前に、プロジェクトの細部に手を取られてしまってはならない。
5．何が問題かを知っている人間を無視する
この教訓を指摘してくれた読者は「前線にいる人間の話を聞かないという失敗がある。これは、マンガのDilbertによく出てくる典型的なストーリーであり、開発者が突き当たっている問題を助けようとして情報を知らせに来た人間を、マネージャーが罰するというものだ。これによって、マネージャーから悪いニュースを隠すという土壌が形成される」と述べている。
少しでも考えてみれば、これがどれほどひどい機能不全を引き起こすか分かるはずだ。ところが、この問題は非常によく見られるものの1つだ。残念ながら、これはソフトウェア開発プロジェクトに限った話ではないが、間違いが非常に高くつくということを考えると、ソフトウェア開発プロジェクトでは特に問題が大きい。
6．知らぬ間に責任を負わされる
わたしが元の記事を書いていたときには、10項目以外にもかなりの数の項目を考えていたし、その多くは読者にも指摘されてこの記事に収録している。しかしある読者は、わたしがまったく考えていなかったものを指摘してくれた。それは、知らない間に責任を負わされるという問題だ。彼は次のように説明している。「わたしは『いつのまにか責任を負わされる』という問題も目にしている。例えば、特定の作業のために新人が配属され、その後なんらかの理由で、まったく関連のないプロジェクトに異動になったとする。言うまでもなく、これはもともとのプロジェクトとスケジュールにとって破滅的な影響を及ぼす」。まったくその通りだ。
