プログラムの品質を下げる原因は？

ちょうどある大規模（？）受託開発の一部を私が担当していて、依頼側の結合試験が始まり、「不具合票」のやり取りが始まりました。不具合票というのは、試験を行って問題が見つかった場合に試験担当者から発行され、解析者→修正者と流れて、修正後に逆方向に流れていくようなドキュメントです。バグ票とも呼ばれます。

不具合の修正自体は、大抵簡単なのですが、不具合票の記入も面倒ですし、不具合票は件数を管理されるので、件数が多いと品質が悪いと見られてしまうため、少なければ少ないほど良いのは言うまでもありません。

不具合の原因は細かくたくさん規定があるのですが、簡単に分類すると、「仕様の問題」と「プログラムバグ」があります。「仕様の問題」には、「依頼側の指示不足」と、「コーディング側の理解不足」があります。いずれにしても、プログラマーとして恥ずかしいのは「プログラムバグ」です。結合試験に入る前に、単体試験をプログラマー側で行うのが普通ですから、「まじめにやっているのか？」と見られてしまいます。まあ、単体試験に関しては、「単体テストの意義とは？」に書いてますので、繰り返しはしないでおきます。

さて、私が担当している部分の不具合票もちらほらと出てきていて、その内訳を見てみましょう。

後から仕様が確定したもの：2件
仕様が明確でなかったもの：2件
コーディングミス：1件
仕様組み込み忘れ：1件

私が担当している部分は完全な新規開発ではなく、以前開発したものの仕様変更なので少し微妙ですが、私の考えでは、不具合の一番の原因になるのは、「コーディング時点で仕様が確定していない」「コーディング後に仕様変更」だと感じています。「単体テストの意義とは？」に書いたように、プログラムの品質はコーディングしながら動作確認することで高めるのが一番です。頭に全体が入っているときに確認するので、漏れが少ないのです。ところが、コーディング時点に仕様が確定していないと、暫定的に作って進めておき、後で修正するときに確認不足になりやすいのです。コーディング後の仕様変更も同じです。

品質の観点から考えると「仕様変更ほど怖いものはない！」と言えるくらいでしょう。
「仕様組み込み忘れ」も、今回の仕事が以前開発したものの仕様変更なので、組み込みを見落としたものです。

幸いなことに、今のところコーディングミスは1件ですが、私はとにかくコーディングしながら動作確認は必ずやりますので、基本的にはほとんど起きないと考えているくらいです。それでも起きてしまうのは、想定が足りなかったときです。書いたコードは必ず確認するので、基本的な問題はないはず、というつもりでプログラミングしています。今回の仕事では、通信連携が4個あり、全て対向のテスト用プログラムも作って確認しています。対向側が先にできていればいいのですが、大抵は同時に進めますので、コーディング時点で確認しながら進めるためにはテスト用プログラムを作るしかありません。そのプログラム自体が間違えていれば仕方ないのですが、間違えるのは仕様的な部分がほとんどで、基本的な動きに関しては十分確認できます。この進め方のためにも、昨日書いた「生み出すタイプのプログラミングは一気に！」のように、一気に確認できるレベルまではやり遂げないと駄目なのです。

受託開発では、受け入れ側が試験をしてくれるので、対応が面倒とは言え、品質的には安心とも言えます。これが自社製品開発になると、自分たちで品質を高める必要があります。私は基本的に同じ姿勢で開発していて、とにかく「コーディングしたらすぐに確認」が基本です。自分だけで開発している製品は、極論すれば「最後のコンパイルが通った時点でリリースできる」くらいの確認をしながら進めています。後から全体のテストを行って品質を高めるのは、私は基本的には「無理」だと思っています。表面的な確認しかできないと思うからです。頭に入っている間に最大限の確認を行うのがベストです。従って、テストのエビデンスを残すなど有り得ません。そんな余計なことに頭と時間を使うと、確認の質が落ちてしまいます。まあ、少々言いすぎかもしれませんけど。。あとは「自分たちで使う」ですね。新バージョンを真っ先に社内向けにリリースするのはとても効果があります！？

当社の「IT関連製品」のなかで、私が開発し、その後も自分で対応しているものは、実は結構多いのですが、都度、品質にこだわって開発しているのでそんなことができているのです。片っ端から作っても、品質が悪ければ、対応だけでひどい状態になりますし、そもそも信頼を失ってビジネスになりません。特に商用DHCPサーバのProDHCPやメールセキュリティのATGatewayなどのように、不特定多数のクライアントを相手に、常時動き続けなければならないものは、品質が悪いと夜も寝られなくなるでしょう（というより、売れないでしょう）。自社製品だけでなく、共同開発製品なども全く同じ意識です。

少し話しが膨らんでしまいましたが、プログラムの品質を大きく左右するのは「仕様変更」「仕様の後出し」。さらに、品質を高めるのは、後からの確認ではなく、「コーディングしながらの確認」というのが私の考えです。