こんにちは。てぃろです。
今回はSI現場での「テストする時間がない」というときの話について書きます。
ソフトウェア開発ではQCD（Quality / Cost / Delivery）のバランスについてよく語られます。
ビジネスであるSI現場では大抵の場合Deliveryが先に決まってきていることが多いのではないかと思います。そして予算であるCostもおおよそ決まっていて、Qualityはそれら二つの制約から決められる、という順番になるのではないでしょうか。
これを現場レベルで言い換えると「納期と人員は決まっているのでその中で品質を最大化する」というミッションが与えられたものと同義です。
この制約のもとで開発が進むと、要件が追加されたり少し障害が出るなどして納期が少し遅れたりします。
すると、犠牲にされるのは「テスト」です。
でも、テストってやらなくていいんでしたっけ…？
テストは品質を証明するための行為
テストをなぜやるのか？というと、プロダクトの品質を確認するためです。
より具体的に言えば、開発物が決められた機能や性能を十分持っていることを証明するためです。
しかし、納期も人員も決まっている中でやることが増えてしまったら、やらないことを決めなければなりません。日本のSI現場ではたいていの場合機能を作ることが優先されていると思います。
すると、必然的にテストが削られてしまいます。
果たして本当にそれでよいのか？
作った開発チームは特に怖いことでしょう。障害を自分たちで作りこんでいたらおおごとです。
PMとしてもテストをしない中、出荷するということは検品していない = 機能の正常性の証明をしていない、ということですから責任重大です。
ただ、現実問題として期限までにテストができないことは仕方がないことではないでしょうか。
だからといって、全くテストをしなくてよいということにはならないはずです。
運用が必要なサービスなら当然ですが、ダウンロードさせるようなアプリであっても、今は継続的にアップデートをすることができる時代ですから、あとからいくらでも開発でカバーができるのです。
このような背景もあって、
「テストはあとで必ずやります」
と約束しておくことができるのではないでしょうか。
テストをあとでやるには、何をテストしてないのかはっきりさせる
本当に全くテストをせずにサービスをリリースするということはないでしょう（ないと思いたい…）から、テストが不十分なときのことですが、こう言いたい。
「テストは後日実施します。現在はXX～〇〇の範囲ではテストをしていますが、△△の範囲ではテストをしていないので障害が発生する可能性があります 」
つまり、どこまで品質保証をしており、どこが危険なのか、その障害リスクを明確にするのです。
そうすれば、運用でカバーが可能なのか、障害が無視できるのかなどの判断ができるので、テストが不十分でもリリースできる可能性が出てきます。
しかしリリースはできても品質保証ができていないことに変わりはないのでテストは実施しなくてはなりません。いつまでも運用カバーで賄っていては新たな機能の開発などやる余裕もなく、いつしか運用チームは疲弊して人的ミスによる大障害をひき起こすリスクがあります。
そのため、テストはあとからでも必ず全部やっていくべきだと思います。
そうして品質保証ができてはじめて、開発体制は落ち着いて新たな案件へチャレンジしていけるようになるのですから。
まとめ
IPAの教科書などにもある理想的な工程定義は理想論です。現場には必ずQCDのトレードオフが存在し、その理想を完全に実現することは不可能です。
ただ、理想だから無意味ということではなく、そこに近づけようと努めることが真にソフトウェアの品質を高めていくことに繋がると思います。
だからこそ、現場ではその理想的な品質保証ストーリーにいかに近づけていくのかノウハウを貯めていくしかないと思っています。
今回はこれまでのSI経験でもよくある「テストを実施する時間が十分にない」ケースについてよくやる対処方法を簡単に書いてみました。
当然、ビジネスの状況やプロダクトの品質によってはリリース延期が妥当な場合もあると思いますし、本当は私も基本的にはリリースは延期するべきだと思います。
しかし、ビジネスはタイミングも大事なので、そうはいかないケースも多々存在します。今回はそのようなリリース期限が延期できない場合の対処方法として紹介しています。
現場の方々の苦労が絶えないと思いますが、このような方法を使って一時しのぎをしつつも、必ずプロとして品質の高いソフトウェアに後からでも近づけていくという意識を示し、のちの本当に行動で証明する、ということを心がけていきたいものです。
それが顧客のビジネス成長を支援し、自分たちのビジネスや技術を成長させる一番の近道だと信じています。
