はじめに
普段、お客様先で、テストプロセス改善の支援をしています。
実際に、テストを実施しよう！となると、「具体的にどんな製品品質リスクをテストで取り除きたいのですか？」と聞くケースが結構あります。
そういったことがあるため、業務では品質リスク分析ワークショップを行いました。
今回は、その内容を書いてみます。
品質リスク分析ワークショップ
やり方
今回は、実践リスクベーステスト-PRISMAメソッド-をベースに実施しました。
詳細については上記ドキュメントご参照ください。
簡単に説明すると下記のようになります。
- ①「計画」で、具体的なテストベースを収集し、リスク分析の計画を立て、リスクの識別を行います。そして、リスク分析計画書に基づき、必要があれば、その後にスコアリングやコンセンサスミーティングを行うメンバを招集し、「キックオフ」を実施します。
- ②「個々の準備」では、収集されたメンバは、リスク分析計画書に基づきリスクの重みづけ(スコアリング)を行います。
- ③「スコアの収集」では、提出された個別用のスコアリングシートを収集し、スコアリングが適切に行えているかをチェックします。
- ④「コンセンサスミーティング」では、リスク分析計画書に基づき、収集されたスコアからリスクマトリクスを作成し、スコアをつけたメンバ間で、対応すべきリスクについて合意形成を行います。
- ➄「テストアプローチの決定」では、合意された対応すべきリスクについて、テストアプローチを決めます。
ツール
品質リスク分析を行う場合には、リスクのスコアリングをするための道具が必要になります。
今回は下記のようなリスク分析シートを作成して行いました。(項目記載は省略)
分析シート
下記のシートの「発生可能性」と「影響度」をスコアリングし、その乗算結果を「優先度」として算出しています。
| No. | リスク分類 | 製品品質リスク | 導出理由、ドキュメント | 発生原因 | 影響度 | 優先度 | スコアリング理由 | 対応要否 |
|---|---|---|---|---|---|---|---|---|
リスクを出す際のガイドワードとしては、下記の製品品質特性を利用しました。
リスクの影響度の基準は、下記を利用し、営業やプロジェクトマネージャの方にスコアリングしていただきました。
リスクの発生頻度の基準は、下記を利用し、開発者の方にスコアリングしていただきました。
また、対応するかどうかの指針としては下記のようなグラフと指標を利用しました。
直面した課題
実際に実施してみると、「計画」、「コンセンサスミーティング」において、下記の問題に直面しました。
この「やばいこと」（≒リスク）ってどういうことですか？
今回、「計画」におけるリスクの特定には下記のような、KJ法のようなやり方で実施しました。
リスク出しの段階では、このようなやり方で出したリスクは、メンバ間で共有されていたのですが、「個々の準備」や「コンセンサスミーティング」において、リスクの中身がわからないということが起こりました。
これは、「コンセンサスミーティング」において、リスク出しに関与しないメンバが参加していたため、組織間のリスクに関する事前の理解がないことにより合意形成が難しくなっていました。
「やばいこと」（≒リスク）が出てこない！
次に、リスクの洗い出しですが、製品理解が浅いメンバはリスク（＝「やばいこと」）が思いつかないということがありました。
これは、テスト観点にも通じますが、開発対象となるもののコンセプトややりたいことなどが共有されていないことによるものでした。
次回をより良くするために
基本的に「やばいこと」（≒リスク）を考えるためには、その対象物に対する理解ができていなければなりません。
そのためには、ユーザーや製品への理解があり、「やばいこと」（≒リスク）が特定できるメンバの参加が大前提となります。
日々、ご支援をさせて頂いて思うのですが、「やばいこと」が起こるのは、製品品質(≒ユーザー要求)の理解や共有不足から起こることを痛感しています。
開発の皆さんで一度是非、製品はどういうものなのか見直して、「やばいこと」を考えてみませんか。
（製品やシステムの分析方法については別途機会があれば…）
参考文献
- 実践リスクベーステスト-PRISMAメソッド-
- Drs Erik van Veenendaal
- https://qiita.com/freddiefujiwara/items/44882bb35e000d9cb546
- ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ
- ISTQB
以上。