開発組織に導入した「リスクベースドテスト」の活動まとめと今後の課題
はじめに
プロダクト開発の生産性向上文脈で「限られた時間で最大の効果を発揮するテスト戦略を作る」をテーマに活動しましたので、そのまとめと今後の課題を発信します。
現状、私の所属しているエンジニア組織では本格導入が進んでいるので、一部の組織では有効だと考えていますので、皆さんの参考になれば幸いです。
本戦略を導入する以前、私のチームは「粒度様々なテスト項目を担当者が思いつくだけ一覧化し、経験豊富な先輩エンジニアにテスト項目をレビューしてもらう」といった方法で品質担保を行っていました。
リスクベースドテストとは
リスクベースドテストとは、リスク度合いの高いリスクに対して検収リソースを投下していくためのテスト戦略であると私は認識しています。
ここでいう「リスク」とは「プロダクトリスク」のことを指しており、製品自体の機能や性能に関連するリスク（製品の欠陥や不具合・性能問題など）のことです。
リスクベースドテストの活動まとめ
私のチームは、検収工程のアップデートと責務分担の整理を行いました。
検収工程のアップデートとして「リスク分析」という工程を追加し、責務分担の整理で検収リソースの配分を見直したという関係です。詳細は後述します。
リスク分析
リスク分析の工程では「リスクの特定」「リスクの評価」「リスクレビュー」を行います。それぞれ説明していきます。
※リスクレビューは「上長が確認/承認しましょう」という内容なので今回は記載を省きます。
リスクの特定
リスクの特定では、該当案件に携わっているエンジニア全員を集めたミーティングを実施し、下記の手順を行います。（補足：私の所属している会社は、同一のプロダクトを開発するチームが複数あり、機能や案件単位でチーム開発を行ってます）
- 開発担当者は、開発した機能の仕様と変更差分を共有します
- 参加者全員は、発生しそうな・発生したらやばそうな不具合を挙げていきます
- 参加者全員は、2で上げた不具合が発生した際に「ユーザー目線で起こっている事象」を考えます
- 参加者全員は、3で上げた事象を生み出す不具合が他に無いかを探し、見つかれば挙げます
※下図がアウトプットイメージです。
補足：私のチームはスクラム開発の2週間スプリントを回しているため、共有する情報量は多くても9人日程度の作業量におさまります
リスクの評価
リスクの評価では、リスクの「発生可能性」と「影響」の2軸で評価し、下記の計算式でリスク評価値を算出します。
※下図がアウトプットイメージ
※下図がリスクレベル表
リスクの「発生可能性」と「影響」もそれぞれ指標を設定しました。
発生可能性の評価
まず「発生可能性」ですが、4大リスクというものを参考にしました。これは、不具合発生の傾向として見られる4つのスポットを表したもので、「スキル」「Hotspot」「難易度」「境界」になります。
発生可能性のリスクレベルは条件を満たしているスポット数で評価します。
【発生可能性のリスクレベル】
| リスクレベル | 条件 |
|---|---|
| 高 | 該当スポットが３つ以上 |
| 中 | 該当スポットが２つ |
| 低 | 該当スポットが１つ以下 |
【各スポットの評価基準】
| 評価指標 | 評価基準 | 補足 |
|---|---|---|
| スキル | 開発担当者は、中途入社１年以内、または新卒入社２年以内 | エンジニアのスキルを定数評価するのは難しいため所属年数とした |
| Hotspot | Hotspotのファイルを変更した | Hotspotは過去2年の変更量(コミット数)が多い上位20%のファイル |
| 難易度 | プロダクトにとって新しい技術を使っている or ストーリーポイントが13を超えている or ソフトウェアの複雑性が高い |
新規性・規模・複雑性のOr条件になっている。規模は開発組織で合意を取った数値にしている。複雑性はチーム判断になっている。 |
| 境界 | API 連携・外部サービス連携をしている or 自チーム外の開発物に依存した設計/仕様になっている or 〇以上や〇未満といった境界値による分岐が存在する |
影響の評価
次に「影響」ですが、これは自社のプロダクトで不具合が漏れ出た際にどれだけのインパクトがあるかを一から軸を決めました。それが「利用頻度」「代替策の有無」「障害復旧の難易度」の３つです
影響のリスクレベルも条件を満たしている数で評価します。
【影響のリスクレベル】
| リスクレベル | 条件 |
|---|---|
| 高 | 該当指標が３つ |
| 中 | 該当指標が２つ |
| 低 | 該当指標が１つ以下 |
【各指標の評価基準】
| 評価指標 | 評価基準 | 補足 |
|---|---|---|
| 利用頻度 | エンプラ～SMB・新卒～中途と様々な利用者がいる中で、どの立場のエンドユーザーでも月に1回は利用する機能を「利用頻度が多い」と判定 | 評価にはプロダクト知識が必要です |
| 代替策の有無 | sonar_ATSの他機能を利用し、代替策を案内できない | 代替策の有無を判断する上で、「参照/登録できるデータが同じか」を判断軸とする |
| 障害復旧の難易度 | 技術領域における復旧作業が不可能または困難 | ソフトウェアの改修やデータメンテ、システム基盤の調整など、エンジニア作業だけで収束させられるかを重要視している |
検収の責務分離を整理
リスク評価値を基に責務分離と検収への向き合い方を整理しました。
責務分担として「開発担当者」「開発ユニット」「上長EM」の３つのロールに分けて、下図のように整理しました。（ユニット = エンジニア3～4名からなる開発チーム）
各ロールのリスクに対する向き合い方としては下記になります。
| ロール | 責務と役割 |
|---|---|
| EM | EMが品質担保にリソースを割く。 テストによるリスクの低減が難しい場合、実装方法を変更するなどしてリスクを回避することも視野に入る。 不具合が漏れ出た場合は復旧作業に加えて、再発防止策の考察と実施。 |
| ユニット | ユニット構成員全員で担保。 テストによるリスクの低減、代替策の準備や復旧難易度の引き下げによるリスクの転嫁を行う。 不具合が漏れ出た場合は復旧作業に加えて、再発防止策の考察と実施。 |
| 担当者 | 担当者できっちり担保。 不具合が漏れ出た場合は担当者が復旧まで責任を持つ。 |
今後の課題
現在、全開発チームに導入していく上でリスク評価の属人性や作業者の負担が課題になっています。詳細としては下記のようなものです。
- 「難易度 > 複雑性」が曖昧すぎる
- 「利用頻度」がプロダクト知識が少ない人には判断できない
- Hotspotの一覧に当てはまるかを目で確認するのは大変。。
課題に対しては、機械的に評価できる方が良いよね！という声が上がっており、7月までに対応予定です。
また、SLO/SLIを導入して「品質を犠牲にしていないこと」を側面から観測しましょうという取り組みも始まっています。
おわりに
リスク評価の指標を検討する際、Web上に転がっている情報が多くなくて一から考える部分も多く大変でした。これを導入したことで、スクラムスプリントでスプリント内の品質担保が安定しているので、アップデートしていけば生産性は上がっていくと今のところは考えています。
リスク指標を考える際の話も後日発信できればと考えていますので、気になるところがあればコメントをください！
以上、長文を参照いただき、ありがとうございました。
参考文献まとめ
Discussion