品質

俺の余り多くない経験によれば、バグはテストしにくい部分に多発するように思う。すなわち単純に言って、叩かれた回数の少ないロジックは品質が悪いと言うことだ。

では、テストしにくいとはどういう事だろうか。自分で作ったプログラムなのだから、自分で動かし方を判っていて当然だと、人は思うかも知れない。だが、現実はそうではないことが多い。

まず、既存システムとの絡みがある場合だ。新規に開発した部分でも、既存システム側である種の条件がそろわなければ実行されることがないロジックというものは存在しうる。例えば、株価を計算する既存システムに、「株価がある一定以下に下がったら警告を表示する機能」を付け加えることを考えてみる。この場合、既存システム側から受け渡される株価がある一定以下に下がらなければ、新たに作り込んだロジックは実行されないことになる。

そういったロジックのテストを行うためには、単純に考えれば、既存システム側で然るべき条件を発生させるようなテストデータを喰わせて、新規に作り込んだロジックを走らせればいいということになる。

だが、設計・開発する人間は必ずしも既存システムの方を理解しているとは限らない。そもそも、その既存システムなるものを完全に理解している人間がこの世の中に現存するとは限らない。

それに、例え知っている人間がいたとしても、やはりテストをする度にその人にお願いして、テストデータを用意してもらって、場合によってはシステムを操作してもらって、ということをやっていては、テストははかどらない。それが、自社の同じ受注案件に放り込まれた開発要員であればそうでもないのであろうが、お客や縁もゆかりもない他社の人間だった場合には、その周辺のロジックはほとんどまともに実行されることなくリリースされる運命にあると考えた方が良い。

他にも、テスト可能な環境の数が少ない場合にも、同様の問題が生じる。ライセンスやマシンの台数や、開発環境を用意する人間の怠慢などによって、テスト環境が一つしかないというのはよくある話である。特に、DBの環境が一つしか用意してくれていなかったりすると、自分がテストしている最中に、他の奴に勝手にDB内のデータを書き換えられて、長い長いテスト行程を初めからやり直すことになったりする。結果として、動作させにくい部分のロジックが一度しか実行されないままリリースされたり、場合によっては一度も動かされることなく本番を迎えたりと言うことも起こりうる。

そういうとき、当事者どうして話し合ってそういうことの起こらないようにとか、事前にスケジュールを立てて計画的にテストを実施するようにとか、管理者の人間ならなら言うだろう。子供じゃないんだから甘えるなと、そういうだろう。だが、それは責任者の甘えであり、怠慢である。

人と話し合うのには、それ相当な精神的エネルギーを使う。コミュニケーションこそは効率を低下させる最大の要因である。それは人も機械も同じである。

プログラムの品質を向上させるためには、純粋に実行される回数を増やす必要がある。同じ事を何度やっても意味がないというのは確かにそうなのだが、しかし、何度かやらなければバグに気がつかないこともあるし、たまにしか発生しないバグというものだってあるのだから、ある程度は回数をこなすことは重要である。

その為には、開発者が人とコミュニケーションを取らなくてもテストできるような環境を整えることが何よりも重要である。それ以外の部分をいくら充実させても、その分が改善されない限りはテスト効率が向上することはない。必然的に、プログラムの品質が低下することになる。

俺が思うには、プログラムの品質を規定する要因としては、開発者の能力よりもテスト環境の優劣の方が大きいのではないかと思う。

反省

今日は久しぶりの休日となった。明日からはまた仕事だが。

この国には本当に労働基準法という法律は存在するのだろうか？　労働組合は労働者の立場を守るために存在するのではないのか？　なぜに、このクソ忙しい時期に組合の仕事までしなければならないのだ。俺に死ねというのか。

現在火を噴いているこのプロジェクトは、簡単に言えば端末のリプレースである。今まで使ってきた端末の保守期限が切れるから、新しい奴と入れ替えようという、ただそれだけのプロジェクトである。ハードウェアの入れ替えと同時に業務アプリケーションの一部改変も行われたが、それを含めてもプロジェクトのリスクは経験の範囲を超えるものではなく、時間的余裕がないことを除けば、必ずしも失敗することが運命づけられたプロジェクトというわけではなかったはずだ。

ところがだ、一つだけ予測していなかったことがあった。それは、そのシステムではある特殊な機器が接続され利用されるということだ。そして、今回はその特殊機器のリプレースも同時行われたのだ。

確かに時間はなかった。提案活動がずるずると延びていつになっても発注してくれない癖して、不思議なことに時間の経過とともに納期はどんどん前倒しになり、当初は一つもないといっていた改修が次々と追加され、それなのに金が増えることはなく、人を増やすこともできない。どこにでも転がっている悲惨なプロジェクトの一つ、よくある物語だ。だがしかし、それもこれも全ては予測の範囲内であり、おおむね物事は予定通りに進んだはずだ。

だがそれなのに、それなのにだ。

本番を迎えると、時々端末が故障するという問題が発生した。しかも、単にハードが故障するだけならまだいい。最悪なことに、業務データとともに一蓮托生で天に召されるのだ。せめてデータさえ消えることがなければ、ここまで客がキレることはなかったであろう。ハードの交換には金はかかるが、しかしそれは金の問題にすぎない。モノを作った奴に責任をとらせれば、それで済む話だったのに。

業務のデータが消えるとなると、もはやいかなる言い訳も通らない。たとえどんな手段を用いようとも、データが消失することの無いよう、対処せざるを得ない。そこまではわかる。

わかるが、しかし、何でその対処法が業務アプリケーションの改修なんだ？　なんでハードウェアの不具合をプログラムで補完してやらなければならないんだ？　ある時突然、何の脈絡もなくファイルシステムが崩壊するとかいう意味不明な現象に対して、プログラムとしては一体何をしてやればいいというのだ？

しかもタチの悪いことに、ハードウェアの故障がプログラムの品質のせいにされているし。所詮OSの上で動くだけのノーマルな業務アプリケーションが、一体どうやってファイルシステムを破壊するというのだ。単にデータを破壊しているだけではないのだ。メディアがマウントできなくなるほどに完全にいかれてしまうのだ。

ひどい話もあったものだ。

後は客は言いたい放題で、どう考えてもおまえらの間違いとしかいいようのない問題まで、こちらの責任として直させられるし、どう見ても無意味としか思えない改修をやらされるし、明らかに何の関係もない新規機能を瑕疵担保責任の名の下に作らされるし。それに対してこちらは、何一つ言い返すことはできないし。

あのハードウェアの故障さえ無ければ、プロジェクトとしては失敗では無かったはずだ。カネ的にも利益は確保できていたし、アプリケーションも言われるほど品質は悪くなかった。全くバグがないとは言わないし、時には客に迷惑がかかることだって、あったかもしれない。だが、今までに出てきているアプリケーションの不具合は、件数的にも性質的にも、通常予想されうる範囲内にとどまっており、むしろプロジェクトの期間を考えればよくできている言っていいのではないかと思われる。

それなのに、それなのにだ。

教訓：１．ハードウェアの品質を過信しないこと。２．プログラマはハードの不具合は追求してくれないし、それどころか報告にも上げてくれない。しかし報告に無いからと言って、かならずしも問題がないというわけではない。