品質保証技術（その６： プロジェクトの崩壊（逆発想））

１．失敗の原因

○どうすれば、プロジェクトを失敗させられるか！
・ 納期遅延を起こし、開発費オ－バ－
・ 品質が悪くバグだらけ、期待とおりに動かない
・ 性能が出ず、メモリも大幅超過

○失敗の原因の多くは、次の要因である
・ 量の変化は、質の変化をもたらす、という基本原則を理解していない
・ 大きいものは、「分割」して「制御」するという「構造設計の基本哲学」に従っていない
・ よく分かっていない人が何となく作る
・ 仕様が不明確で複雑．．．主任／サブリ－ダが仕様を正確に把握せよ
・ 仕様変更多発、仕様が決まらない．．．仕様は「変わる」という前提で仕事をせよ
・ 性能無視．．．基本としてディスクアクセス回数をキチンとおさえよ
・ 異常ケ－ス無視、最大値／最小値無視・ 論理拙劣、論理過大．．．テ－ブル化を図れ
・ 工程切迫の手抜き．．．結局高価になる、線表を強烈に守れ

２．混乱の要因

○開発体制の不備
・ 主設計者が不明確。全体の技術的責任者は誰なのか。
・ 全体としての意志統一不足。
・ 人員投入の遅れと場当たり的な人員投入。

○基本動作の欠落
・ ドキュメントの更新サボリ。
・ レビュ－のサボリ。
・ ＤＤをサボリ、工程遅延の調整に使用する。

○性能設計の欠落
・ オブジェクト性能の偏重
・ コンパイル性能（コンパイル時間、使用メモリ等）が欠落
・ 管理者の見通し力と決断力の欠如。”何とかなりそう”程度の見通しで、何とかなったためしがない。頑張ることは大切だが、具体的施策の裏付け要。
・ 結果として、一年かけて五月雨式改善とあいなる。