プロダクトリスクの影響を定量化する
先日、「開発組織に導入したリスクベースドテストの活動まとめ」という記事を書きました。そちらでは結論だけ書いたので、ここでは当時の学びや考察について書こうと思います。
同様の記事を書きましたので、そちらもご参照ください。
記事「プロダクトリスクの発生確率を定量化する」
対象読者
- リスクベースドテストの導入を考えている方
- プロダクトリスクの影響の定量化を模索されている方
私の開発チームでは「リスクレベル ＝ 発生確率 × 影響度」でプロダクトリスク（不具合）のレベルをランク分けし、より高いリスクに検収リソースを投下する戦略を試しています。
その中の「影響」を評価する上での学びや考察を記載しています。
影響を考える
プロダクトリスクの影響とは、「その不具合が発生した際に顧客やビジネスへどれだけ影響を与えるか」を数値化したものです。
ただ、不具合の内容によって顧客やビジネスに対する影響の与え方は多岐にわたるため、影響の大きさを全て順番に並べることは大変ですし実質難しいという認識です。
そんなに精緻にやるとなると膨大な時間がかかってしまうため、リスクベースドテスト戦略が期待する「限られたリソースで最大の効果(品質担保)を発揮する」ことの趣旨から外れてしまいます。
そのため私の開発チームでは、高・中・低の3つに分類することにしました。
なぜなら、高いか低いかを思い切って振り分けた方が導入時は効率が良いと考えたからです。
（これは発生確率と同様の考え方ですね）
次に、高・中・低の振り分け方を決める必要がありました。
開発チームの規模感が7チーム（計30名）なので、属人的な判断になると製品品質の低下を引き起こす恐れがあるためです。
私たちは「この不具合が流出したらヤバイ/ヤバかった」というものを洗い出し、そこから共通点を見つけようとしました。
その結果、私たちにとっての「影響」とは、利用頻度・代替策の有無・障害復旧の難易度、の3つに分類されるとしました。
これらに当てはまるほど影響は大きいと感じたので、当てはまる数によって 高・中・低を分類することにしました。
「利用頻度」について考える
ここでいう「利用頻度」とは、「ユーザーが該当機能を利用する量」を指しています。
利用するユーザーが多い機能程、不具合が発生した際に困るユーザーが多いため、その分問い合わせも多くなります。
私の開発チームは「エンプラ~SMB・新卒/中途と様々な利用者がいる中で、どの立場のエンドユーザーでも月に1回は利用する機能は利用頻度が多い機能」として判断するようにしました。
欲を言えば利用実績データを基に判断をする仕組みにしたかったのですが、「新機能は実績データ無いけど？」や「シーズンによって利用される機能に偏りがあるけど？」、「そもそも利用実績を集計するのは容易ではないよ」など、実現に向けた課題が多くて今回は上記を採用することにしました。
たとえ「利用頻度が多い機能」を一覧化出来たとしても、対象が多くなれば目視で確認する負担も大きくなるため、良し悪しがあると私は考えています。
「代替策の有無」について考える
ここでいう「代替策の有無」とは、「障害発生時、問い合わせいただいた顧客の問題を解決する代替策を提示できるか」を指します。
私のチームでは、「代替策が無い」または「チームが代替策を考えられない」場合には、リスク有りと判断する運用になっています。
判断軸の検討時、仕組みとして「代替策の有無をどのように判断するか？」を決めるのに少し苦労をしました。なぜなら「代替策の有無」といっても人によって捉え方が違ったからです。
事の発端は「アプリ内メッセージ送信はEメール送信の代替策になるのか？」という疑問からでした。
どちらとも「該当者へ連絡する」という目的は達成しています。ただし「該当者が連絡に気づけるか」という点では大きく違ってきます。
アプリ内メッセージは受信者に通知が飛ばないので、アプリにログインするまで気づけません。。
私のチームが開発しているのは採用管理システムであるため、学生向けの連絡は伝わるまでのスピードが重要なケースもあります。
結論、私のチームでは代替策の有無を判断する上で「参照/登録できるデータが同じか」を一つの基準としました。
上記であれば、ユーザーの目的は必ず達成することが出来ますし、開発者視点でも判断がしやすいということでした。
「代替策の有無」は、品質管理方針の一つ「転嫁」とも親和性があるため、観点としては良い観点になったかと思います。
転嫁とは、「責任を転嫁する」などで使われる言葉ですが、品質管理では「その機能がダメになったと用に別のソリューションを準備しておこうね」という考え方らしいです。
今の判断軸は、ビジネス視点での代替策とは若干異なるので、今後判断軸に違和感を感じた例を基にアップデートしていこうと考えています。
「障害復旧の難易度」について考える
「障害復旧の難易度」は、「本来のあるべき姿に戻すことは可能か？」を問うている項目です。
「本来あるべき姿」は、ソフトウェア上の不具合を改修することに留まらず、障害発生中に起こったデータ不整合なども復旧も含みます。
またチームの視点では「障害復旧の方針が立てられるか」も判断基準の一つになります。
特に個人情報の取り扱いには注意したかったのでこの項目を入れています。
私のチームでは、「ソフトウェア改修で済むなら容易」という合意が取られました。
難易度が高いとされた観点としては下記があります。
- Web上に出てしまったデータは取り返しつかない
- 復旧対象のデータの特定が出来ない
- 復旧対象のデータが数百~数千と膨大で作業が実質不可能に近い
「1」の例としては「Eメール送信の対象を間違えた」などですね。
現状の課題感
運用していて感じている課題感は下記です。
- 「利用頻度」判断にプロダクト知識が必要
課題改善の後に、また記事にまとめようと思います。
まとめ
リスクベースドテストを導入するにあたっての、プロダクトリスクの「影響」の評価方法について学びと考察を記載しました。
評価軸は良い出来だと個人的には思うのですが、業務の難易度は少し上がってしまったかもしれません。その分、品質担保の目線が上がっているため、慣れてくれば生産性も上がることでしょう。
導入を考えている方、導入を実際に行われた方は是非記事を書いてほしいです。
私が検討している時点では、インターネット上に情報が少なかったので、この分野の発展に役立つと思います！
Discussion