ソフトウェア開発にはトラブルがつきものか

ソフトウェアの開発では、よくこんな事が問題になります.

• どれだけプログラムを書いてもいっこうに終わりが見えない。

• バグが次から次へと出る。

• なんとなく動作するプログラムはできたが、試しにやってみた操作以外の操作 をすると正常に動くかどうか自信がない。

• すぐエラーを出して異常終了する。

• 確かに最初に要求として出した機能はあるにはあるのだが、実際のところ使い ものにならない。

• プログラムが完成して客先に出してみると、いろいろと注文をつけられて結局 全部作り直す羽目になってしまった。

仕事でソフトウェア開発をしている人だったらいくつも心当たりがあるでしょ う。それらを「ソフトウェアの開発はこういうものだから仕方がない」で片付 けていませんか？もちろんプロジェクトにいくらかのトラブルはつきものです が、それにしてもソフトウェア業界にはトラブルが多すぎやしないでしょうか？ まずは問題を問題として認識する所から始めなくてはなりません。

まず、これらの問題を「仕方がない」であきらめてしまわず、どうやったら無 くせるかを考えなくてはなりません。そして実際のところある程度まで無くす ことができます。まずはこれらの問題の根本原因を考えてみましょう。

納期が遅れる

この問題はよく突発的な事故のせいにされます。「開発の後期になって大きな バグが発見された」というのがその理由になります。しかし、本来ならそんな 事はあってはならない事です。大きなバグを引き起こしそうな事項は事前によ く検討すべきなのです。「バグは出るものだから仕方がない」ではなく、出さ ないように考えなくてはなりません。

全体の見通しがないまま最初の方からプログラムを作っていくとこの危険性が 高まります。プログラムの後の方で何か根本的な思い違いを発見することになっ てしまい、全部が作り直しになってしまいます。本当はそうではなく、最初に 全体の動作について考えなくてはなりません。この事は、いきなりプログラム を書き始めずにまず分析と設計をすることで防ぐことができます。

これは楽観的なマネージャが無理なスケジュールを組んだ時にも起こります。 残念ながらソフトウェアでは工期を正確に見積るのは困難で、たいがいはマネー ジャが「まあこのくらいだろ」とどんぶり勘定で決めてしまいます。そんない い加減な納期なら守れないのも当たり前です。こういう人は問題が起きると、 「納期の見積りが甘かった。もっと長目に設定しておけばよかった」と反省し がちです。そしてこの反省は間違っています。「納期を短目に設定した」のが 問題なのではありません。「どんぶり勘定で適当に決めた」のが問題なのです。

バグが頻発する

できたプログラムのトラブルを何でもかんでも「バグ」と呼んではいませんか？ 単にプログラム中の名前のつづり間違いとアルゴリズムの根本的な間違いでは 重要度が全然違います。重要度も原因も違うこれらを一緒くたに「バグ」と呼 んでしまうのが問題なのです。

根本原因を考えず、とにかくプログラムがうまく動くようにいきあたりばった りな修正を繰り返していくと、だんだんわけのわからないプログラムになって きてしまいます。つぎはぎだらけのプログラムではバグが頻発し、それにまた つぎはぎで対処するからだんだんプログラムは崩壊に向かっていきます。

バグに対してその場しのぎの修正を繰り返してしまう主原因は、バグ取りの段 階で納期がせまっていることにあります。「もう根本の設計から見直している 暇はないから、なんとかその場しのぎで対処してくれ」とマネージャから言わ れてしまうからです。こんな状況に陥った時点で既におかしいのです。本来な ら根本の設計が間違っているというような重要事はプロジェクトの初めの方で 見つけ出さなくてはならないものです。何度も言いますが、いきなりプログラ ムを書き始めずにまず分析と設計をきちんと行うことでこの手の問題は防ぐこ とができます。

もう一つ考え直してほしい事があります。「バグは出て当たり前」という風潮 です。「バグを潰すこと」ではなく「バグを出さない事」に力を入れて欲しい のです。

信頼性がない

ソフトウェアが完成し、試しに動かしてみるとうまく動作したがどうも自信が ない、という事がよくあります。こうした不安を感じるのは初心者ではなくあ る程度のベテランです ^[1] 。複雑な動作を複雑なままプログラムで表現すると、本当にそれで正しいのか どうか自信を持てないのです。

この主原因はもともとの「複雑な動作」にあります。「仕様がもともと 複雑なんだから仕方がない」と言う人もあるかもしれませんが、「仕様が多い」 と「仕様が複雑」は違うことに注意しなくてはなりません。例え仕様の量が膨 大でも、その一つ一つが単純なら手間暇や工数の問題だけですみます。仕様を 単純化しようとせず、複雑なままでプログラム作成まで持っていこうとするか らトラブルが起きるのです。

少々回り道でも、複雑な仕様は単純な仕様に書き換えるべきです。そして、単 純になった仕様で部分ごとにテストしましょう。一見工数が増えるように見え ますが、最終的にはずっと速く仕上がるのです。

プログラムが完成してしまってから仕様変更がある

顧客相手だとよくある話です。プログラムが完成して客先に持っていくとここ が使いにくいとかこういう機能があるとよいといった話になり、それが小変更 ではすまなくなる場合がよくあります。 この場合、往々にして顧客側の責任になりがちです。「完成してしまってから そんなケチをつけられても困る。そういう事はもっと早く言ってくれ。」と言 われ、契約を盾に不満は押し込められてしまいます。

しかし、顧客はプログラムに対してはアマチュアなのですから、完成してもい ないソフトの機能がこれでいいかどうかなんて文書だけからわかるはずもあり ません。何百万も払って出来てきたソフトウェアがまるっきり見当違いで使え ないものだったら、誰でも文句を言いたくなるのは当たり前です。

もしこれが注文住宅だったらどうでしょう？設計士は家の設計図を作ったら施 主に「これでいいですか？」と確認するでしょう。しかし、例え施主が承認し ても、建てた家が強度不足でつぶれてしまったら、責任は承認した施主ではな く設計士にあります。こんな当たり前の事がソフトウェア業界では通りません。

この問題は、仕様をきっちり決めないままプログラムだけ先行することにあり ます。ソフトウェアを作る前に「どういうソフトウェアを作るか」という話が 本来あるべきなのに、多くの場合は「まず出来るところから」と全体のビジョ ンがないままに話が始まってしまいます。まずシステム全体の仕様を決めるべ きです。これは一般に「システム分析」と呼ばれる分野です。

メンテナンス性が悪い

ソフトウェアが完成して問題なく動いてはいるものの、ある機能を付け加えた いとなった時にもはやどうしていいかよくわからない、担当者が今は会社を辞 めてしまったのでもう中身がわかる人がいない、という問題もよく見かけます。

この問題は「ドキュメントの問題」ととらえられがちです。ソフトウェアにき ちんとドキュメントを書かないからこうなるんだ、ちゃんとプログラムの○割 以上コメントを書きなさい、と。しかし、ドキュメントを書きさえすればよい というわけでもありません。

わかりやすいプログラムにはポリシーと信念があります。こういう観点からソ フトウェアを設計し、こういうポリシーに従ってプログラムを書いた、という ものです。これらがドキュメントにして残っていれば、プログラムの細部につ いてのドキュメントなどはいらないのです。関数の動作説明なんてだいたい名 前とプログラムを見ればわかるでしょう？

こうしたドキュメントを残すためには、そもそもプログラムにポリシーと信念 が必要です。設計を考えずにコード書きから入るのがそもそもの問題なのです。