システム開発の品質管理で現実的に有効な方法を考えてみた

システムの品質についてよく言われているのが

「いくらテストをしてもバグがないことは証明できない。テストをパスしたことが証明できるだけだ」

というものです。

テストをしてバグが出なかったのにリリース後バグが出るのは、バグを見つけられるテストケースを用意できなかったということです。

だからといって、テストをすることは無駄かというとそうではありませんよね。完璧な品質を実現することは原理的に不可能であっても、現実的に有効なアプローチをとるべきだからです。

そこで今回はシステム開発の品質管理の現実的な方法を考えてみたいと思います。

1. 開発期間を圧縮しすぎない

先ほど述べた通り、テストをいくらやってもバグがないことを証明できません ＝ テストでバグを完全になくすことは出来ないということです。ならば、テストですべて解決しようとするのではなく、テスト以外でも品質を上げるアプローチも探るべきです。

そういう意味で、開発の日程に余裕を持たせるのはとても有効な方法です。

私がコードを書く場合、日程の余裕によってコードの書き方が変わります。本当に余裕がないギチギチのスケジュールの場合は、必要最小限の実装にします。エラー処理やコードのメンテナンス性、セキュリティの安全性などは日程に余裕があれば、十分に考えて盛り込みますが、日程に余裕がなければ最小限の機能を実装するので精一杯です。

日程の余裕によって変わるコードの質の違いが最終的な品質にもつながります。ですから、品質を高めるためには日程に余裕を持たせるべきなんです。

「んなことはわかってるけど、スケジュールは伸ばせないんだよ」って場合は、機能を削るなどして開発スコープを狭くする方法もあります。それも出来ないとなるとお手上げですが、実際そういうプロジェクトは多いですよね。

2. テストケースは担当プログラマー以外が作るべき

通常、プログラムの単体テストは、そのプログラムを開発した人が行います。その単体テストのテストケースも当然、開発者が作ります。ここまでは担当者がテストケースを作ってOKです。

その後の結合テスト、システムテストは開発者以外の人（設計を担当した人や要件定義をした人）がテストケースを作るべきです。

開発者がこれらのテストケースを作ると、「自分が作った通りに動くか確認する」テストケースになってしまいます。

しかし、本来テストで確認すべきことは「そのシステムが要求される仕様通りに動いているか」です。

なので、要件定義や基本設計をした人がテストケースを作成すべきなのです。

が、しかし、ここで問題になるのが…、

ポンコツ上流SE問題

ポンコツ上流SEとは、お客さんとなんとなく打ち合わせしてなんとなく要件のようなものや基本設計のようなものをざっくり作って、後は開発者任せでシステムの要件や仕様を全く分かっていないポンコツ野郎のことです。

なぜかこういう人って首にもならず存在しますよね？こういう人が上流工程をやっているプロジェクトの場合、システムテストのテストケースもプログラマーが作ることになりがちです。

こういう場合「システムテストのテストケースをプログラマーが作ると自分が作った通り動くか確認するテストになってしまうので、要件定義や基本設計を担当した人が作らなければ意味がありません。」と説明しましょう。

ポンコツ上流SEは「…やべー、おれ全然仕様わかんねーよ、テストケースなんて作れないよ！？」と慌てるはずです。そうやって、慌ててもらってちゃんと要件や仕様を確認すべきなんです。ポンコツでも要件や仕様を確認すればテストケースは作れるはずなので、必ずやってもらいましょう。

3. 顧客に受け入れテストをしっかりやってもらう

要件定義や基本設計の担当者がシステムテストのテストケースをつくっても、それはシステムを作る側の視点になってしまいがちです。

そこで、システムテストの後に行う受け入れテストが重要になります。

この受け入れテスト、顧客によって様々で、ほとんどやってなさそうな顧客もいれば、じっくり時間をかけてテストしてバグが報告されることもあります。

受け入れテストをきちんとやってもらうことで、リリース後に発生したシステム障害、バグについても、開発側だけの責任ではなく、顧客側のチェック不足ということにもなります。そういう意味でも受け入れテストをきちんとやってもらう意義があります。

提案を受け入れてもらえない場合は？

ここまで述べてきたことをまとめると以下のようになります。

• 開発日程に余裕を持たせる。そのために納期を延ばしたり、開発スコープを小さくするよう提案する
• システムテストのケースは上流工程担当者につくってもらうよう交渉する
• 顧客に受け入れテストをきちんとやってもらうよう交渉する

全て真っ当な提案内容ですが、これらが受け入れられないプロジェクトも多々あると思います。しかし、これらを実践しなければシステムの品質を高めることは現実的に難しいでしょう。

そんな場合、どうすればいいでしょうか？

転職するしかないと思います。

「えっ？逃げるみたいで気が引けるんだけど？」と思われたかもしれませんが、出来る限りの交渉をし、やれることを全てやった上で、改善できない職場は去るしかないと思います。

私はこれまでに多くの会社で仕事をしてきましたが、会社によってカルチャーは全く違うし、自分に合う合わないの相性があります。それに、探せば、良い会社っていっぱいあります。作業フローがしっかり出来上がっていて、仕事はいっぱいあっても、ちゃんと予定通り進むから毎日定時帰りの会社とかもあったんです。

それに転職活動すると、いろいろな会社や仕事を知ることが出来て人生の可能性が広がると思います。