2024.01.25
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
第1回：いまどきのソフトウェア開発に求められるもの 第2回：新しい開発スタイルの概要 第3回：新しい開発スタイルに合わせたテストの概要 第4回：開発チームとテストチームの関係～成功のための大事な役割～ 第5回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い 第6回：テストレベル間のテスト量の関係は？テストピラミッドとの関係も
本連載では、ソフトウェアテストをする際には、ビジネスの成功に貢献するという本来の目的を意識しながら、これからの開発に役立つことを考えていくことが重要だと説明してきました。考えていくべきことは、以下の４つになります。
- 開発チームとテストチームの関係
- 品質リスクの許容度合い
- テストレベル間のテスト量の関係
- QA（Quality Assurance）の考え方
前回は、「開発チームとテストチームの関係」について詳しく説明していきました。今回は「品質リスクの許容度合い」についてです。まずは、品質リスクや品質リスクを使ったテストのアプローチを説明していき、最後に品質リスクの許容度合いについて述べます。
- もくじ
1．品質リスクとは何か
リスクとは一般的に「悪い結果になってしまう可能性」を指します。ソフトウェア開発におけるリスクは、大きく2つに分けることができます。
1つは、開発プロジェクトのコストや納期を順守できないリスクです。これは開発プロジェクトが計画したとおりに進まず、かつプロジェクトのマネジメントが機能しないことに起因するリスクであることから、計画リスク（プロジェクトリスク）と呼ばれます。通常、リスクマネジメントの話をする際は、計画リスクだけが対象になっていることが多いです。
もう1つのリスクは、開発したソフトウェアを利用する際に、利用者の想定通りにソフトウェアが機能しないというリスクです。これはまさに、価値あるソフトウェアが開発できないというリスクであり、これを品質リスク（プロダクトリスク）と呼びます。言い換えれば、ソフトウェア開発を進める中で、この品質リスクをうまくマネジメントしていくことが、ビジネスの成功に貢献するソフトウェアを開発することに直結するというわけです。
2．品質リスクをマネジメントする3つの方法
品質リスクをマネジメントする方法は、通常のリスクマネジメントと同様にいくつかあります。
方法の1つは、リスクを完全に回避することです。これは要するに、「品質リスクが高いものは開発しない」という方法です。この方法を採用することで、当然、品質リスクはゼロになりますが、ソフトウェア開発で得られるリターンもゼロになります。
次に考えられる方法は、リスクの移転、あるいは分散化です。具体的には、リスクが顕在化したときに被る損失を他者と分担できるようにしておくことです。その一般的な例としては損失の補てん分を保険にかけるという方法が挙げられます。また、新規性が高いソフトウェアを開発する場合、想定どおりのものが作れない恐れが強くあります。そのようなケースにおいて、ベータ版リリースといった形で、品質リスク上の損失をプロダクトやサービスの提供側と利用者側とで分担し合う契約をあらかじめ結んでおくといったことも一例として考えられます。
さらに、もう1つの方法として考えられるのがリスクの軽減です。この方法はすなわち、ソフトウェアの開発時に、品質リスクの軽減に向けたさまざまな工夫を凝らすというものです。工夫の一例として、開発の初期段階に開発者が設計上の課題をすべて解決し、本番リリース後に品質リスクが顕在化しないようにすることが挙げられます。
とはいえ、この方法はビジネス価値を上げるためトライアルアンドエラーができる開発を行うという方針にそぐいません。したがって、品質リスクの高低を評価し、品質リスクが高いところに対して優先的に対処する必要があります。これは、品質リスクの考え方を用いて、ビジネス的な成功に対する判断のための優先順位づけを行うことになります。
3．品質リスクは投資や時間とのバランスを取るパラメーター
テストやレビューは、品質を確認するための手段ですが、品質リスクの考えを用いる場合は、テストやレビューの結果を品質リスクが軽減したかを確認する情報源として位置付けることが重要になります。
品質リスクをベースにしたテストのアプローチでは、品質リスクの高い機能を洗い出し、それらのテストの優先度を高くして、それぞれの品質リスクが軽減していることを確実に確認し、関係者に情報提供するようにします。
具体的なテストのやり方としては、例えば、品質リスクが高い機能に対しては、テストの実行時期を早めたり、テストケースを増やしたり、自動化を推進してリグレッションテストを何度も行ったりといった方法が考えられます。
ただし、それだけではテスト量が増えることはあっても、減ることはありません。そこで、品質リスクの低い機能については単体テストを行うが、システムテストではテストの対象外にしてテストケース数を減らすといった方法で全体のテスト量を調整します。
このように、品質リスクの高低をパラメーターにしてテストのやり方を変えていくことをリスクベースドテストと呼びます。リスクベースドテストにより、ソフトウェアのビジネス的な成功に対する判断のために必要な情報量と、その情報を得るために必要なコストや時間との間でバランスを取ることが可能になります。
4．品質リスクを評価する方法
品質リスクは、要求を分析するフェーズにおいて、ソフトウェアが想定どおりに動かないことがビジネスにどの程度の影響を及ぼすのかを評価して算出します。
品質リスクは、以下の式で表し、評価することが可能です。
ソフトウェアの問題によって引き起こされる損害×問題が発生する確率
「問題により引き起こされる損害」に関しては、よりビジネスに近い要求に対して評価を行います。例えば、以下のような要因に対して損害の度合いを評価します。
- 不具合が出た機能の使用頻度
- イメージの悪化による（不具合が出た機能による）業務の喪失
- 財政的、経済的、社会的損失または責任の可能性
- 民事上または刑事上の法的拘束
一方、問題が発生する確率は、システムへの要求に対する技術的なリスクと解釈して評価を行います。例えば、以下のような要因に基づいて実施します。
- 技術およびチームの複雑性
- ツールや技術に慣れていない
- 管理または技術的なリーダーシップの劣悪性
- 時間、リソース、管理のプレッシャー
- 初期品質保証の欠如（レビュー、ソフトウェア構成管理）
- 仕様変更多発
- インタフェースと統合の問題
5．大切なのは「正確さの追求」ではなく「比較を可能にする」こと
ソフトウェアに品質リスクがあるということは、そのソフトウェアの機能を利用する際に問題が起きる可能性があることを意味しますが、問題発生の確率は不確かなものです。そのため、前述した計算式はリスクの重大さを理解するうえでは役立ちますが、問題発生の不確実性に対処するのには役立ちません。つまり、ソフトウェアの品質リスクは計算することは可能であっても、そのリスクが顕在化するかどうはあくまでも不確実な予測でしかないということです。
その意味で、品質リスク評価の目的は、個々のリスクの正確な分析を行うというよりも、それぞれの深刻さを比較し優先順位をつけることにあります。したがって、品質リスクの評価結果には関係者間の合意が不可欠であり、リスク評価ミーティングは、テスト担当だけではなく、ビジネスと開発、またカスタマーサポートの関係者が垣根を超えて一緒に行わなければなりません。そうすることで、ソフトウェアのビジネス価値の適切な評価につながります。
さらに、リスク評価に関する合意形成というプロセスを開発工程に組み入れて、開発側、ビジネス側、そしてカスタマーサポートで品質リスクを共有することは、関係者間の意識のギャップを埋める役割も果たします。
6．いまどきのソフトウェア開発での品質リスクの許容度合い
これまでの連載にて、トライアルアンドエラーをできる開発をすることがビジネスの成功に貢献につながる、そのためにはスピードが命であると述べてきました。トライアルアンドエラーをするということは、不確実性が高いことを意味してします。
つまり、利用者のもとで欠陥が出ないように十分にテストをしても、テストした機能が不要になる可能性もあります。不要になるかもしれない機能の品質リスクを軽減することにコストや時間をかけることは、ビジネスに貢献しないかもしれません。その場合、すぐに修正／リリースできれば利用者へそれほど迷惑がかからない欠陥は許容する、つまりリスクの軽減をするのではなく、リスクが現実化した後のカスタマーサポートの対処や開発での修正対応へとリスクの移転、あるいは分散化をするアプローチの方が適切になります。
リスク分散をしてよいかは、開発対象ソフトウェアの特徴によって異なります。人の生死に関わる、事業の機会損失に繋がるような品質リスクへはこの考え方を適用できず、品質リスクを確実に軽減させるべきです。しかし、その機能があれば魅力的であるが、無くても回避策があり、かつ修正した最新モジュールのデプロイが数時間で出来れば問題にならない機能であれば、テストをすることによってリリースまでのスピードを落とさない方が良いわけです。
いまどきのソフトウェアは、サービスとして提供していくビジネスが増えており、サブスクリプション方式のビジネスモデルを適用することが多くなります。この場合、リリース直後のプロダクト品質を最高にするのではなく、運用しながら品質を適切に保つことが重要になります。つまり、運用やカスタマーサポートまで含めた最適化を考えないといけません。
品質リスクの許容度合いを見直してテスト量を減らすことに成功すると、テスト量を減らした分だけリリースをするスピードが上がります。ただし、テストをしない分だけ欠陥を修正対応するエンジニアやカスタマーサポートへリスクを移転、あるいは分散していることになります。この時に、修正対応するエンジニアやカスタマーサポートと前述したリスク評価に関する合意形成をしていない状態では、想定外の仕事が彼らに対して降りかかることになります。
たとえ、その品質リスクの許容度合いの見直しがトータルで考えた時に利用者へ提供できる価値から考えた上での判断だとしても、リスクが顕在化した後の欠陥の迅速な対応とリリース、および利用者への適切な説明が伴わなくなってしまうと、利用者へ迷惑がかかってしまいます。つまり、その判断が逆効果になります。
おわりに
今回は、「品質リスクの許容度合い」について深掘りをしていきました。
これからの開発はトライアルアンドエラーとチームの垣根を超えて開発をすることが大切です。
そのためには、品質リスクの高低をパラメーターにしてバランスをとること、また、品質リスクへの対処にはテストによるリスク軽減するだけではなく、リスク移転や分散するアプローチも取り入れることの意義が理解できたかと思います。
次回は「テストレベル間のテスト量の関係」について深掘りしていきます。
