ドキュメントのボリュームと品質は一致しないと思う

ソフトウェア製品を作っていると、たまには障害が発生してしまいます。なかなか100%何の問題もないソフトウェアというのは作れないものです。特にインターネット相手のシステムでは、様々な種類の端末・ルーター・スイッチなどの機材が関係し合い、通信の流れ方も二度と同じパターンはなく、ビックリするような障害が忘れた頃に発生することもあります。

そんなときに、関係者の皆さんから言われて困ることが「どんなテストをして出荷したのかを見せろ」ということです。

テストにはいろいろなレベルがあります。プログラミングしながら同時に確認するホワイトボックス的なテストを単体テストと呼ぶようですが、一番重要なのはこの「コーディングと同時にするテスト」だと私は考えています。今どきのプログラムは人間の頭では記憶できないほど多くの機能があり、ソースコードも複雑になりがちです。作った瞬間が最も頭に展開されていて、テストの網羅性も高いのです。しかし、このテストはいちいち記録を残しませんので、見せろといわれても何もありません。

一通り実装が終わってから、結合・総合テストと呼ばれるような、仕様面での確認を中心としたテストや連続稼働・負荷テストなどを行います。それらはプログラミングした本人がやるよりも、仕様を理解している他の人が行う方が勘違いの発見もできて良いのですが、いずれにしても、このテストは資料が残ることもあります。

しかし、テスト結果のボリュームを見て品質が分かるとは私は思えません。やったかやらないかが分かるだけで、あまり意味があることだとは思えないからです。しかも、テストの結果を資料としてまとめることはとても手間がかかります。その時間があればさらにいろいろなテストをすることもできますし、まとめることに頭を使って、肝心のテストの質が下がることも想像できます。

幸い、私が携わる製品では、打ち合わせ・現場対応・調査・サポートなどでの、私の取り組みを見ていただいていることが多いためか、このような要求はまずこないのですが、間に入る関係者の間でこのような話が出ることは多いようです。

私が受託開発が嫌いになったひとつの理由がドキュメントです。後でほぼ読まれることのない仕様書やテスト成績書を作ることに、あまりにも多くの時間を使いすぎるのが嫌だったのです。

最近はウォーターフォール型の開発以外も増えてきて、納品物をとやかく言うよりも、一緒に素早く開発して運用しながら改良する、というやり方も認められてきました。製品でも、要望や障害の対応が、リリースまでの段取りが多すぎるために、半年後のアップデートのリリースまで待て、と言われるよりも、臨機応変かつ迅速に対応する方が喜ばれるケースも多いものです。もちろんシステムの規模・性質によって適した進め方は様々ですが、単純にドキュメントのボリュームで品質を判断するのはどうしても賛成できないのでした。