🐖

プロダクトリスクの発生確率を定量化する

2024/04/03に公開

学習

プロダクト開発

先日、「開発組織に導入したリスクベースドテストの活動まとめ」という記事を書きました。そちらでは結論だけ書いたので、ここでは当時の学びや考察について書こうと思います。

対象読者

リスクベースドテストの導入を考えている方
プロダクトリスクの発生確率の定量化を模索されている方

私の開発チームでは「リスクレベル＝発生確率 × 影響度」でプロダクトリスク（不具合）のレベルをランク分けし、より高いリスクに検収リソースを投下する戦略を試しています。

その中の「発生確率」を評価する上での学びや考察を記載しています。

発生確率を考える

プロダクトリスクの発生確率とは、文字通り「その不具合が発生しやすいものか」を数値化したものです。

ただ、これは「0-100%」のように細かく数値化するメリットが少ないと一般的には言われています。

そんなに細かく計測しようとなると、計測事態に膨大な時間がかかってしまって、リスクベースドテスト戦略が期待する「限られたリソースで最大の効果(品質担保)を発揮する」ことの趣旨から外れてしまいます。

そのため私の開発チームでは、高・中・低の3つに分類することにしました。
なぜなら、高いか低いかを思い切って振り分けた方が導入時は効率が良いと考えたからです。

次に、高・中・低の振り分け方を決める必要がありました。
開発チームの規模感が7チーム（計30名）なので、属人的な判断になると製品品質の低下を引き起こす恐れがあるためです。

私は「4大リスクスポット」というものを参考にしました。
これは、2・8の法則からよく発生する不具合の傾向を分類したもので、スキル・Hotspot・難易度・境界の4つに分類されるというものです。

これらのスポットに当てはまるほど発生確率は高いと感じたので、当てはまるスポット数によって高・中・低に分類することにしました。

「スキル」について考える

ここでいう「スキル」とは、「担当エンジニアの開発スキル」を指しています。

開発予定の製品/機能に対して、担当エンジニアの開発スキルがアンマッチ（低い）場合、不具合を生みやすいという考え方ですね。

私の開発チームは「担当エンジニアが、中途入社１年以内、または新卒入社２年以内であればリスク有」として判断するようにしました。

「エンジニアのスキルを測るのに入社年数ってどうなの？」という声もあるかと思いますが、該当の開発に必要なスキルレベルと担当エンジニアのスキルレベルを天秤にかける難易度は、私たちには高すぎました。

たとえスキルレベルが可視化できたとしても、この1項目を評価するために割く労力としては過剰だという話もあります。。

ただし、ずっとこの方法で判断する予定ではありません。
開発速度を落とさず、評価精度を上げる方法を今後も考える必要があります。

「Hotspot」について考える

ここでいう「Hotspot」とは、「変更が集中しているところ」を指します。

製品開発をしていると、不具合問い合わせや製品の仕様変更で既存のソフトウェアを変更することが多々あるかと思います。
そういった変更が集中するところほど不具合が起こりやすいという考え方です。

変更量の計測方法は決められていないため、開発チームごとに考える必要がありました。

私たちは「過去2年の変更量(コミット数)が多い上位20%のファイル」としました。

私の開発チームではGitでバージョン管理をしているため、コミット数を計測対象としました。

「過去2年」としたのには二つ理由があります。一つは、「リリースからの経過年月に関わらず、リスクの有無判断をしたいこと」です。もう一つは「リリースから1年も立てば不具合報告が落ち着く傾向にあること」です。

対象を上位20%にしているのは、2・8の法則を参考にしています。
2・8の法則とは「不具合の8割は2割の機能に集まる」性質を表すものです。

「難易度」について考える

ここでいう「難易度」とは、「開発の難易度」を指します。
「チームにとっての難易度」ではなく、開発物の難易度を絶対評価したものとして考えます。

開発の難易度は、新規性・規模・複雑性の3つで測ることが出来るとされています。
私のチームでもこの三つの何れかに該当する場合はリスク有と判定するようにしました。

新規性とは、「開発チームにとって新しい技術を扱う際、知見が少ない傾向にあるため不具合発生率が上がる」という考え方です。
「新しい技術」とは、開発基盤や開発言語のような環境面、Open AIや多要素認証などの機能面、新規ライブラリ導入等を指します。
いろいろあるのでチームで共通認識を持っておいた方がいいでしょう。

規模とは、「開発規模が大きくなれば考慮する量が増えるため不具合発生率が上がる」という考え方です。
開発規模には、開発したコード量・機能の多さ・開発期間・開発担当者数・設計書の物量・設計期間など、様々な方向で測ることが考えられます。
私たちのチームでは「開発上の作業量」で計測することにしました。スクラムスプリントをやっていて作業量を相対見積もりしているため、運用に乗せやすかったからです。

複雑性とは、「仕様や設計が複雑だと不具合発生率が上がる」という考え方です。
複雑性は定量・定性評価が今の私たちには難しいため、チームで判断することにしてあります。
ソフトウェアの複雑度を計測できるライブラリも世の中にはあるようなので、将来的には導入したいですね。プロダクトリスク単位で複雑性を測ることが手間なので、今回は保留しました。

「境界」について考える

境界とは、言葉の通りです。何かと何かの境は不具合が発生しやすい傾向にあります。

境界に対するプロダクトリスクは、サービス間（API）・開発チーム間・境界値による分岐（ソフトウェア上）といったところに現れる傾向があります。

サービス間・開発チーム間については、自分たちが設計/開発していないものを前提として開発するため、自分たちの意図しないところで不具合発生することがよくあるように思います。

境界値による分岐については、不具合が発生しやすい傾向を感じていたので理解しやすかったです。確認パターンが多くなるため、人的ミスを誘発しやすいんでしょうね。

私のチームでは下記の何れかを満たす場合としました。

API 連携・外部サービス連携をしている
自チーム外の開発物に依存した設計/仕様になっている
〇以上や〇未満といった境界値による分岐が存在する

現状の課題感

運用していて感じている課題感は下記三つです。

「複雑性」判断の属人性
新規開発における「Hotspot」の考え方がむずい
「スキル」の判断が不安

課題改善の後に、また記事にまとめようと思います。

まとめ

リスクベースドテストを導入するにあたっての、プロダクトリスク発生確率の評価方法について学びと考察を記載しました。

4大リスクスポットについて、概念としては理解しやすかったのですが、自チームで生産性を落とさずに導入することを考えると準備に結構時間がかかりました。

導入を考えている方、導入を実際に行われた方は是非記事を書いてほしいです。検討時はインターネット上に情報が少なかったので、この分野の発展に役立つと思います。