それに気づいたのはいつだろう。
それに気づいたのは、プログラムの大きさが300KB以上の巨大なものになっていることを見つけた時かもしれない。あるいは、プログラム全部をコンパイルしなおすのに、一時間近くかかることを知ったときかもしれない。それとも、一つのバグを直すと、別の数カ所で必ず新たなバグが発生することがわかった時だったろうか？
私は、私の率いるプロジェクト・チームが作っているソフトウェアが、人間の管理能力を越えていることに気がついたのである。
そのソフトはDOSで動くプログラムとしてはあまりにも大きすぎたし、各モジュールが複雑に入り組みすぎており、信頼性が非常に低かった。コマンドの仕様もはっきりしていなかったため、系統だった動作テストさえ思うようにはいかなかった。しかも納期は迫っており、大ざっぱな仕様については納入相手にも伝えてあった。八方ふさがりである。何らかの対策が必要であった。
＊ ＊ ＊
私がとった対策は３つあった。一つは営業に頼んで納期を遅らせてもらうこと。もう一つはスタッフを増員すること。そして最後の一つはプロジェクトの進行を自分以外の人に見てもらうこと。この３つである。
納期を遅らせることは、スタッフの焦りを減らし、作業を見直すのに役立ったが、社内でのプレッシャーを増す結果になった。
スタッフを増員することは、物量的な面では大いに助けとなったが、質的な解決には結びつかなかった。「ソフトの開発が遅れているときに、人員を追加すると余計に遅れる」というのはよく言われる話である。わかっていながら、やはり人員追加をやりたくなる。これは抗し難い誘惑である。
確かに人数が増えると、テストに人を割けるし、バグレポートの整理などの仕事も分担できる。けれど、ソフトの信頼性、安全性、保守性を増すのにはあまり役に立たないのである。
対策の中で唯一成功したのは、プロジェクトの進行を自分以外の人に見てもらうことであった。これは、自分の甘えをなくし、スタッフの気持ちを引き締めるのにたいへん役立った。
＊ ＊ ＊
つらい日々が続いた。
山のようなバグ。迫る納期。スタッフは必死に戦った。まがりなりにもソフトとしてまとまりがついたのは初めの納期から半年以上もたったときであった。その間「もうやめよう」と思ったのがいったい何回あったことか。そして「もっと早くプロジェクトの危機に気づいていたら」と何度くやしがったことか。
時間に余裕がありさえしたら、基本設計に戻ってプログラムの全面書き直しをすることさえできたかもしれない。けれど納期が迫っていたら、それはできない相談である。
＊ ＊ ＊
プロジェクトの作業見積りの誤り、また想像以上の遅れについては経験のあるプログラマなら誰しも苦い思い出を持っているだろう。もしかしたら今、そのつらい日々のまっただなかにいる人もいるかもしれない。
チューリング賞をとった大計算機科学者のホーアでさえ、あるプロジェクトで大失敗をしている。彼はなんと、30人年分の仕事、すなわち一人の人間がほぼ一生かけて行なう仕事量のプログラムを放棄せざるを得なかったのである。 (C. A. R. Hoare, "The Emperor's Old Clothes", Turing Award Lecture, 1980.) （邦訳「ＡＣＭチューリング賞講演集」共立出版,１９８９年）.
私のこの文章を読んでくれるプログラマが何人いるかはわからない。けれども私は、プログラム作りをなりわいとしている全国の人たちにエールを送りたいと思う。
つらい日々はあなたの財産だ。
(Oh!PC、1991年5月30日)