ソフトウェアの制作を頼んだ人に「時間がないから、先ずは正常系ケースから行きましょう」と言われたことがあります。
正常ケースだけ考えてきちんとできるのかな?と、その時は腑におちなかったのです。しかし、私よりもソフトウェアの設計、プログラミングに携わっていた人なので、あえて「それで大丈夫?」なんていいませんでした。
でき上がったものは制作期間が短かったこともあり、当前のように正常ケースも手直しが必要でしたし、ましてや異常ケースとなった場合などは、異常ケースであることすらすぐには判別できないほどのものでした。
不安的中ということですが、何故そうなってしまったのでしょうか。
あの言葉を額面通りに受け取ると次のようなプログラムになります。
1 2 3 4 5 6 7 |
if (error) { // **あとで必ず**エラー処理を書く } else { // 正常処理 : } |
この様なプログラムには次のような問題がおきるでしょう。
- 単にエラー処理を書くのをわすれる
- 正常系さえも納期に間に合わない状況になると、エラー処理を書かない
- 異常となる場合の振るまいの設計が正常系の出来に左右される
- 後から書いた異常系によって、それまで書いていた正常系が正常に動かなくかなくなる
- プログラマはその関数の機能を思いだしながらコーディングしなければならない
そして一番の問題は、未完成の関数を**沢山**つくってしまうことです。正常、異常に関らす後から書き足す関数はプログラマにとって未完成です。
未完成であることの心理的圧迫はプログラマにとって重いものです。納期が迫っている状況で未完成の関数が沢山あるということは、これからそれらを完成させ、すべてテストしなければならないということなのですから。
この失敗の影響は全てユーザに付けられます。保証期間が切れれば、改修コストさえも負担しなければならなくなるでしょう。
やはり最初のアプローチで失敗しています。制作作業の中で削る部分をまちがえているのです。ソフトウェアに求められる機能と制作する期間が合わなければ、文字通り機能を削るか期間を延ばすのが筋です。機能の中には必ずしも必要でないものがあるはずです。また、機能には優先度があるでしょうから、それにしたがって制作し、段階リリースすることで全体制作期間を延ばすことはできるはずです。そして、その両方を必要とする場合もあるでしょう。
機能を削ったり、期間を延ばしたりというのは印象わるいかもしれません。しかし、中途半端なソフトウェアを産み出して、リリース後のコストを増やすよりもよほど建設的な解決方法です。