これは自戒をこめてなのですが、世の中にはテストされていない、あるいはテストのできないプログラムが数多くあります。ここで言っている「テスト」というのは、通常のテストとは違います。
例えば、CDラジカセを作るとします。ユーザが操作する部分はもちろんテストされます。各種のつまみがきちんと機能しているか、音が鳴るかなどをテストするのは当然ですね。ここではそのようなテストのことではなく、ラジカセの中身のテストです。
ラジカセの裏蓋を開けてみますと、様々な配線やモジュール（ＩＣ、コンデンサ、変圧器などなど）が並んでいます。これらを一つ一つテストできるかどうかという問題です。こういった機器の場合には、保証期間やら部品の提供期間が法律で決められています。修理を行う場合は、技術者が「どこが悪いのかすぐにわかる」と言った状態、すなわちどこをテストして、どのような結果になれば良いのかという手順が決められているものと思います。
ラジカセと違って、プログラムの場合には配線やモジュールが「悪くなる」ということはありませんから、いっけんそんなものは必要無いように思います。どれほど配線がごちゃごちゃだろうが、モジュール分けされてなかろうが、関係ないのです。一般的なユーザは裏蓋を開けてみたりしません。だから、
どんな作り方をしようが、何を使って作ろうが関係ない。ユーザの要求するものが作れればそれでいいのだ。そして素早く作れれば、なお良いのだ。
という主張をする人がたまにいますが、これはその通りのように思わされてしまいます。しかし、このような議論で抜け落ちているのが、
プログラムはＣＤラジカセとは違う。
という点です。CDラジカセの場合、それ以上の機能を要求することはできません。例えば、小さい液晶画面をつけて、ワンセグを見れるように改造しろだとか、ＤＶＤも再生できるようにしろだとか。こういう要求のある場合は、「買い直せよ」ということになるでしょう。改造する位なら、新しいものを買った方が安く済むということは誰でもわかることでしょう。
ところが、プログラムの場合、安易にこのような要求が出てくるのです。そして、ユーザの方はそれが実現できるものと当たり前のように思いこんでいます。
ここで困った問題が起こることになります。裏蓋を開けると、ごちゃごちゃの塊が出てきます。こいつをどういう風にすれば、ユーザの改造要求が実現できるのか。しかも、改造を請け負った人は、元を作った人とは違う人だったりします。こういう問題が出てくるのは、たいていの場合、技術レベルの極めて低い人が最初に適当なものを作り、そして「作り逃げ」しているケースですね。
このごちゃごちゃの塊を改造して機能を追加しろ、というのですから請け負った人は大変です。しかも、このケースならまだよいのです。世の中には、
ごちゃごちゃの上に最初の要求も満足しておらず放棄された、「途中逃げ」されたシステムというのがあまたあります。
こういうものを、引き継いでちゃんと動くようにし、なおかつ機能追加しろというのですから、それは無茶な話というものです。これは完全に「失敗」というケースですね。世のソフトウェアの６，７割はこれに当たります。最初から作り直した方が早いのです。
話を元に戻します。ここで言う、テストされていないプログラムというのは、ユーザの要求に沿ったテストがされているかどうかという話ではありません。つまり、各種つまみや音が鳴るかという話ではなく、裏蓋の中のごちゃごちゃの中身が個別にテストされているかどうかという話です。
つまり、ごちゃごちゃの塊を機能ごとに分割し、それぞれテストすることができない、あるいはテストするためのツールが揃っていないと、改造した場合に元通りの機能を持っていることが保証できないのです。そして、世に流通しているプログラム（まがりなりにも動いているプログラム）は、これを満たしていないプログラムがほとんどであると言えます。
なぜこういうことになるのでしょうか？
てっとり早くユーザの要求を満たすためには、裏蓋の中のごちゃごちゃを整理する暇などない。
というのが一つの理由であり、そして
整理したそれぞれをテストするツールを作成する暇がない。
というのがもう一つの理由です。プログラマはユーザの要求を満たすという目標に向かって邁進しますが、それを早く実現しなくてはならないため、上の二つを無視して、とにかく必要なだけの配線を引き回してしまいます。そして配線ごちゃごちゃの代物ができてしまいます。
この結果、機能単位に分割してテストすることはできません。テストはユーザに見える部分、つまみや音で判断するしかないのです。
ソフトウェアのコスト面から考えてみると、次のようなことが言えると思います。つまり、機能拡張を一切しない予定のプログラムは比較的安く済み、これを行う予定のプログラムは高くつく、ということです。
これが当然の考え方であるのに、なぜかソフトウェアの「お見積り」なるものには、このような項目は現れてきません。「将来的な機能拡張を可能にするのだから高くなります」というのが本当のところであるにも関わらず。
しかしその一方で、ソフトウェアというものは、将来的に100%機能拡張すると言ってもよいと思います。ということは、実際に機能拡張が容易にできるか否かは、最初にそれを請け負った技術者の技術レベル、あるいは「良心」に委ねられているのです。
これは今日のソフトウェアビジネスには一切現れないけれども、とても重要な点です。A社も100万、B社も100万のお見積りで、ユーザの要求を満足するソフトを開発すると言ったとします。そして実際に、満足するソフトが作成できるものとします。しかし、そこには雲泥の差がありえます。
もしＢ社が上に書いたように、整理整頓された裏蓋の中身を提供しており、それらを個別にテストするツールまで提供してきたとしたら、Ｂ社を選んだ方が圧倒的にお得です。将来的な拡張要求にも耐えられるからです。
しかし、ユーザにはこれが理解できません。裏蓋の中身を理解できないからです。相変らず、つまみと音でしかその機能を判断することができません。あとは、ＣＤラジカセの「デザイン」でしょうか。外見がよければ「良いソフト」であると勘違いします。そして結局、大した技術は無いけれども外見だけは綺麗なものを作ることができるＡ社を選んでしまうのです。
そして、私の経験上ありそうなケースとしては、Ａ社が適当な物を作って、ユーザに納品し、その改造要求が出てくると、Ｂ社に頼むというものです。Ｂ社は技術レベルが高いですから、Ａ社が適当に作ったごちゃごちゃのものを整理しながら、さらに機能拡張することができるのです。こういうことがとにかく頻繁に起こっています。
本来書きたかったことから、話が大幅にずれてしまいました。本来書きたいのは、
ごちゃごちゃの塊にならずに整理整頓された形でプログラムを構成するにはそれなりの経験と技術が必要であり、テストのためのツールを作成するにはプログラム本体を書く時間以上の時間が必要になる。
というところです。ここで大事な点としては、整理整頓とテストツールの作成は、表裏一体で切り離すことができないという点です。テストツールを作成するためには、ごちゃごちゃにならずに整理整頓する必要があるということです。また逆に、単に整理整頓しただけではダメで、どのようにすればテストができるのかを考えながら作成しなくてはいけません。
そして、それらの方法論としてもあまたあり、どの方法論を選択すればベストであるのかを事前に判断することが大前提になります。ある方法論を選択し、システムとそのテストツールを作成して行くと、それを途中で変更するのはとても困難です。
これもまた、世にあまたあるプログラミングを教えるウェブサイトや書籍では、全く言及されていません。また、上の方法論について言及されているものであっても、以下のようなことが言えるのです。
なぜそのような方法論が必要になったのか。なぜ、その方法論をわざわざ苦労してまでも導入しなければならないのか、全く説明が無い。
一つの理由としては、これを理解するには経験が必要であるからと言えるでしょう。初心者に解説したところで理解することは不可能と言えます。実際に多くのシステムを作成し、困った経験が無いと理解できないのです。また、多くのシステムを作成した、とは言っても「作り逃げ」をして「後は野となれ」ばかりでは経験になりません。作って、運用して、機能拡張要求を受け、それを実現するというサイクルを経験することが必要です。
もう少し長くなりそうですが、今日はこの辺で。。。
