「設計が甘かった」という言い訳は本質を表現していない

ソフトウェアはどれだけお金と時間をかけても、やっぱりバグが残る。止まると人が死ぬぐらい大事なシステムでも、バグが出る時は出る。

バグが出た時の言い訳が、「設計が甘かった」とか「テストが足りなかった」というのはお約束で、「今後は体制を見直す」というのも反省時のお約束である。

まじめな話、それ以上何も言えないのである。「人員を刷新して～」とかどこから集めてくるのかわからないような言い訳もあるが、とりあえず止まったものはしょうがないので、早急に修正するというのが基本的な対応となる。

ソフトウェアというものは、基本的に間違いがなければ動きつづけるのである。なので止まったらどこか間違っていたのである。やっかいなのは、エラーの原因が納得できるようなものはほとんどなく、解ってしまえば簡単に修正できるという類のものばかりであるということだ。

なんでそんな簡単なことをちゃんとテストしなかったのか、とその部分に注目すると誰もが思う。顧客の目から見てもミスだとわかるようなバグもよくある。なので、一方的に開発側が攻められることになる。

しかし、事の本質はそう単純ではない。なぜそんな簡単なことも見つからないのかということだ。決してケアレスミスで済ませてはいけない。トラブルが発生するまで見つからないのだから、同じ方法論では同じ失敗を繰り返すだけである。

例えばコンシューマ向けのゲームソフトは、徹底的に大人数で長時間叩いてバグを全部潰すという、もぐら叩き的なデバッグを行っているらしい。それでも、一度出荷されると一切拡張しないので、その方法でもいいのかもしれない。

それに引き換え業務システムは、納品後も、やれ追加開発だ、仕様変更だ、スケールアップだと、当初の想定をはるかに越えた拡張を行うことが多い。そういう意味で生き物みたいに成長していく。餌はプログラマの知恵なのだろうか。

生き物だとすると、たまに休止とかありそうなものなのだが、ソフトウェアはそれを許さない。結局のところ、先にプログラマの方が力尽きてしまう。どんな人にも限界があるので、どれほど工夫しても一定以上の規模は把握できないのだ。

で、サブシステムを他の人に任せて、どんどん関わる人数を増やしていって、誰か１人でもミスをすると、システムが止まってしまうということになる。

結局のところ、システムの規模をどうコントロールするか、という問題に帰結するのかもしれない。

チェックできない規模のシステムを納品して、バグが出てから「設計が甘かった」という言い訳を言うのはやめにしたい・・と心に刻みつつ、今日もバグを修正しているのであった。