初心にかえる②「品質を守る」
ヌーラボのTATSURUです。
初心にかえるシリーズ第2弾は、「品質を守る」について書いてみようと思います。
品質をどのように担保するか、そもそも品質といっても様々なベクトルの品質があるかと思います。ここでは、プロダクトの品質をどのように担保するかにフォーカスしたいと思います。
EMとしては、人や組織に関しても品質を担保する事に関心がありますが、今回はそこまで書けるか解りません。
品質は計画時に決まる
さてプロダクトの品質を担保するためには、どうすれば良いのでしょうか？
個人的には、計画時にどこまで想定できているかで決まるように思います。
では、計画時にどのように品質を担保すれば良いのでしょうか？
それは、今から何を作るのか明確にする事から始まります。
要するに要件定義になりますが、いわゆる開発手法がウォーターフォールであろうとアジャイルであろうと、製品の要件から担保すべき品質に対してもレベル感が決まっていないといけないのではないかと思います。
もし、その製品が100万人以上に利用してもらうSaaS製品であるならば、必要とされる品質のレベルはそれに応じたものでなければなりません。
サポートするデバイスやOSやブラウザの種類が多ければ、全ての組み合わせで正常に動作する事を担保しなければなりません。
個人情報や要配慮情報を取り扱うのであれば、個人情報保護の観点も重要になりますし、セキュリティも当然担保しなければなりませんよね。
そういった、何を担保しなければならないかは、プロジェクトの計画時には決まっているものですが、多くの場合は網羅性を欠いている事がほとんどですし、個別具体的な担保方法が解っていなかったりします。
網羅性を担保する
では、どのようにして網羅性を担保すれば良いのでしょうか？
ユニットテストやE2Eテストのテストコードでカバレッジをレポートして100％を目指せば良いのでしょうか。
セキュリティは脆弱性診断を行えば安心でしょうか。
それも手段・手法としては大切だと思いますが、まだ網羅的とは言えません。
本当の意味で品質を担保するのであれば、テストが漏れる事も考慮する必要があると思います。
テストは漏れるものですので、テストが漏れたらどうするか。
提供した製品が、想定外の動きをしたときにどういった影響をユーザーに与えるかを網羅的に想定する事をお勧めします。
特に、致命的なものに関しては、即時復旧の手段・手法を含め、あらかじめその運用方法が定義されているかなども品質担保の範疇だと考えておくと良いのではないかと思います。
具体例は以下の通り
インフラで障害が発生
不具合によりデータ流出
ユーザーの意図しない誤操作で損害発生
レギュレーション違反
外部からの攻撃
内部からの攻撃
こういった致命的な事象に対して、想定して品質を担保していくことが重要かと思いますが、これをプロジェクト計画に入れていますでしょうか。
インフラに障害が発生したときの復旧テストはしていますか？
データが流出した際、内容に応じて報告義務が発生しますがエスカレーションフローは定義されていますか？
ユーザーが意図しない誤操作でデータ消失や過剰請求など発生した場合の対応方針は規約などで想定されていますか？
様々な「規則、規約、規定、制限」に意図せず違反してしまった場合、その対応フローは定義されていますか？
外部からの攻撃への対処法や、内部からの攻撃の対策・抑制策は検討していますか？
インフラや不具合に対しては考える事はあると思いますが、法的な問題やセキュリティに関しても網羅性は担保する必要があると考えています。
テストのコストはムダにならない
品質を担保しようと思うと多くのテストが必要になります。
テストには非常に多くのコストがかかりますが、テストのコストはほとんどムダになりません。
逆にテストをしていなかった場合、致命的な問題が発生したときの損害と比較してみると、コストがムダでない事が良く解ると思います。
仮に100万人が使っているサービスが長期間停止したら、大変な損害になってしまいます。もしデータ流出やレギュレーション違反であれば会社の信頼を損なってしまいますし、セキュリティの問題は深刻な信用問題に発展する可能性が非常に高いのです。
なので、計画時に致命的な問題に発展しかねないような課題に関して、特にソフトウェアのレイヤーから遠い事に関しては、ケーススタディなどから過去の重大インシデントなどを元に対処を検討し、きちんとテストを行う事が大切だと思います。
そして、テストのノウハウは今後のプロジェクトにも活かせますので、絶対にムダにならないので様々なレイヤーのテスト（ここでは運用のロールプレイなども含めます）を行うと良いのかなと思います。
テストのコストを捻出する
テストには膨大なコストが発生します。しかしかけられるコストには限界があると思いますので、膨大なテストを効率よく行う必要があると思います。
テストのボリュームは、開発ボリュームに比例します。個人的な比率としては、開発：テストは１：１または１：２くらいかと思います。それ以下の場合は何か欠けているかもしれません。
テストで大変なのは、網羅的なテストパターンを洗い出す事と、適切なテストデータを用意する事だと思いますが、開発ボリュームが大きくなれば、その倍のテストが必要になるのは解るかと思います。
そこで、このコストを捻出するためにやるべき事がいくつかありますが、可能な限りの自動化は当然のこととして、そもそも1回のリリースにおける開発ボリュームを大きくし過ぎないという事に尽きると思います。
小さく作ればテストのボリュームが少なくなります。意外と開発に関わっていない人はこのシンプルな事実を理解していません。また、開発者も開発が楽しくなって、ついつい作りすぎてしまいますよね。テストの事は考えているかな。
また、優秀なフレームワークやライブラリは多くのユーザーに使われている場合、検証済みの状態で利用する事ができますので、開発コストだけでなくテストコストも削減ができます。もちろん自前で検証する必要は当然あります。
OSSの活用は、選定の難しさやバージョン管理の煩雑さはあるものの、品質という面においてのメリットも場合によっては教授されると思います。
とにかく動かしてみる
テストコードでテストできる事には限界があると思います。そもそも想定しきれない範囲もあるでしょうし、テストコードの網羅率を100％にするのは難しいですし、費用対効果によってはどこまでやるか範囲を決めるべきかと思います。
大事な事はとにかく動かしてみる事かと思います。可能な限り、多くの人でがしがし動かして、気づいた事は何でもＦＢしていく事が重要だと思います。
弊社ではドッグフーディングをやっていますが、これが仕様上の不具合だけでなく、使い勝手や利便性など、そもそもの機能としての問題も洗い出される可能性もあり、本質的な品質向上に役立っていると感じます。
まとめ
今回は製品の「品質を守る」というテーマで記事を書いてみました。
まずは計画時点で品質を担保するためにどこまで想定しておけるかというのが大切かと思います。
そして網羅性としては、ユニットテスト・E2Eテストや脆弱性診断も重要ですが、様々なインシデントを想定した非ソフトウェアレイヤーに関しても事前の想定を行いアクショナブルな状況を作る事で本当の意味での網羅性が担保されると思います。
そしてテストのコストを低減させるために開発ボリュームを少なくすることや信頼性の高いフレームワーク・ライブラリなどのOSSを採用する事で、相対的にオリジナルの実装を必要最小限にする事も品質向上の選択肢として良いかもしれません。
最終的には自分達で動かして確認するのが重要だと思いますが、マネージャの方はどうでしょう。一通り触ってみていますでしょうか。「百聞は一見に如かず」というように自分の目で見る事を忘れないようにしたいですね。
今回は以上です。
ではでは。