リスクポイントの活用 ～スクラムにてリスクポーカーでリスクポイントを算出しリスクベースドテストをやってみた～
はじめに
こんにちは。スクラムマスターの伊藤です。
先日、愛車（平成10年式 25年目!?）を車検に出しました。引っ越したこともあり、いつも出しているところで無いのでリスク回避のために知人に紹介していただいたお店でやってもらいました。
値段も相応で細かい注文にも丁寧に対応していただき満足の車検となりました。ちなみに最近は土日は代車が出せないなど、とても忙しいそうでした。
リスク（悪いことが起こる可能性）という言葉もだいぶ一般的になってきました。ソフトウェア業界ではリスクは常に隣り合わせになっています。
その際たるもが障害発生時のリスクではないでしょうか。特に医療やインフラ、金融といった人命や金銭に直接関係してくるシステムは影響度が大きいです。その、リスクを低減させるものがテストになるわけです。
タイトルに何度もリスクを書かれていますが、今回はリスクを見える化するリスクポイントを活用したテストについてお話したいと思います。
よもやま話
車を長く乗るタイプの人は次の車をどうするのか悩んでいる方も多いのではないでしょうか。EVにすべきかプラグイン・ハイブリッドか、EVならトヨタを待つべきか等など私はここまで来たら、今の車を30年目、そして2030年を目指して乗り続けてEVを検討しようと思っています。
リスクベースドテストとは？
リスクが入っているワードが３つタイトルに含まれていますが、まずは１つ目「リスクベースドテスト」についてみていきましょう。
まず、テストの目的は何でしょうか？ 端的に言えば、ソフトウェアが正しく動作して、不具合が無いことを確認する作業です。
では、テストにて不具合はゼロに出来るのでしょうか。様々な前提条件にもよりますが、一般的には残念ながらNoです。正確に言えば、普段使うようなことでは発生しませんが、ある条件下では発生してしまうかも知れないためゼロとは言い切れないためです。
そして、組み合わせは事実上無制限に増やせるため全てをテストすることは不可能です（例えば、ECサイトで購入者、商品、数量の組み合わせだけでも途方も無いことになります）
そこで、オールペア法（ペアワイズ法）といった手法でテストを行ったりするのですが、本件とは外れますので割愛します。
全てテストをすることは物理的・時間的に不可能
テストにかけられるリソース（人的・時間）も有限であるならば、リスクが高い機能や箇所を優先してテストしようという考えか方がリスクベースドテストになります。
例えば、スクラムであればプロダクトバックログ単位で開発を行うため、プロダクトバックログ毎にリスクが高・中・小として、テストのボリュームや手法を変えるという考え方です。
ここで、リスクを測る基準・指標というものが無いと主観的なものになってしまうことに気付きます。
そこで、リスクポイントという考え方が出てきました。
リスクポイント
リスクを測る指標として考え出されたのがリスクポイントです。
可能性
影響度
の2軸から算出されます。
可能性
障害が発生する可能性です。新しい技術を使う場合、複雑な機能な場合など障害が発生する可能性が高いプロダクトバックログ。逆に、メッセージやレイアウトの修正といった可能性が低い場合もあるはずです。
影響度
障害が発生した場合の影響度（英語の原文はDamage）、この機能で障害が発生した場合どんな影響・ダメージがあるのかという軸です。 必ず使うメイン機能なのか、知る人ぞ知る便利機能なのかによって変わってくるはずです。
レンジ
この可能性と影響度を１～４（低いほうが１）のレンジで算出しかけ合わせたものがリスクポイントになります。
最低で１ 最高で16となります。
※レンジは３でも良いですが日本人は並を選びがちなので４段階で実施しました
可能性が低くても重要度が高い場合はリスクポイントが高くなるなど考えられた指標になっています。 それでは、このリスクポイントをどうやって決めるのがいいのでしょうか。スクラムならばプロダクトバックログのストーリーポイントを決めるのにプランニングポーカーが実施されますが、同様にリスクポーカーという手段があります。
よもやま話
プランニングポーカー、リスクポーカー
ポーカーというと、少し楽しそうですよね。最近はオンラインでやることが多いですが、対面では実際にカードを使ってやりました。認定スクラムマスター研修でいただいた貴重（？）な萌え絵の痛プランニングポーカーはどこかにあるはずだが行方不明
リスクポーカー
それでは、リスクポーカーのやり方について紹介していきます。
時期
スプリント準備完了後～リファインメントの間までに実施します。プランニングポーカーと同時に行うことも可能ですが、本案件ではプランニング後に実施していました。
参加者
プロダクトオーナーも含むチーム全体が理想ですが、本案件では開発チーム全員にて実施しました。
ファシリテーターは通常スクラムマスターが担当します。
手順
参加者はカード(1～4 多いほどリスクが高い)を用意します
ファシリテーターは対象プロダクトバックログのユーザーストーリーを読み上げます
ファシリテーターは障害が発生する可能性についてのリスクを見積ってもらうように依頼します
参加者はリスクを1～ 4（低 ～ 高）から選択します
全員が選択できたら、同時に公開してもらいます
全員が同じスコアだった場合、この見積は終了です
異なる場合、チームで議論します
合意が得られるまで４～７を繰り返す。合意後、スコアを書き留めます
続いて障害発生時の重要度（ダメージ）について３～８の手順を行います
リスクポイント（可能性 ✕ 重要度）を書き留めます
上記の手順で各プロダクトバックログのリスクポイントを算出していきます。 手順１はオンラインの場合は、オンラインツールや投票機能、チャットなどを利用します。 手順６で同じスコアでも認識違いがある場合があるので、理由を聞いて相違が無いことを確認すると効果的です。
リスクポーカーのヒント
タイムボックス
時間がかかりすぎないようにタイムボックスを決めることが推奨されてます。例えば１プロダクトバックログを５分まで時間を超過した場合は、多数決で決める、高いポイントにするといったルールを決めておきます。
リスクについて話し合う
手順7で、「チームで議論します」とありますがこちらが重要でありメリットでもあります。
ファシリテーターが指名して、何名かスコアの根拠を聞いていきます。
メンバーはこういったリスクがあるということを話していき、認識の差異や
新たな気付きを得ることが出来、開発やテスト設計にも活かすことが出来ます。
視覚化ボードの活用
リスクポイントが算出される度に以下のような視覚化ボードに貼り付け、
全てのプロダクトバックログのリスクポイント算出が完了した後に、ポイントが同じものはあっているか違和感がないか確認し、必要に応じて調整します。
実際にやっていると、このバックログとこれが同じリスクポイント？といった違和感が発生することがあります。
リスクポイントの活用
無事にリスクポーカーが終わるとリスクポイントがプロダクトバックログ毎の決定します。
この値が大きいものはテストを厚く、小さいものは軽くすることでリスクに応じたテストを実施することが出来ます。
しかしながら16段階もテスト手法を変更するのは煩雑なため、視覚化ボードの色に従い４パターンほどにすることを推奨します。
以下に例を記載します。他にも自動テストを組み合わせるなどプロジェクトに応じて決めて下さい。
初めてリスクポイントを利用する場合は、事前、またはリスクポイントが算出されイメージが湧くリスクポーカー後に話し合って各リスクポイントに応じた対応を決めると良いでしょう。 また、レトロスペクティブで必要に応じて見直していきます。
※ここでいうDevは開発チームがコーディングを行うDevチームと、テストを行うQAチームで別れているための表現となっています
※ちなみにレッドゾーンになったことは無いです。オレンジも稀でした。
おわりに
リスクポイントを活用したリスクベースドテストをやってみたところ以下のような効果がありました。
テストに濃淡を付け最適化
明確な指標で、ほとんど障害が出ないような箇所は軽くし、リスクが高い箇所にテストのボリュームを増やすという最適化が出来るようになった
リスクポーカーで新たな気付きが
QAチームでは気付かないリスクが指摘されたり、チームとしてリスクの明確化が行うことが出来た。 また、プログラマーは可能性１にしたバックログでバグを発生させると、レトロスペクティブで恥ずかしいということで気が引き締まったというテストだけでなく副次的な効果があった。
レトロスペクティブに使える
リスクポイントとテストケース数・障害発生率との相関グラフを使うことで想定通りだったが異なったか、その場合は原因は何かといった議論が行えます。異常値が出た場合は、想定外の事象が発生していることが多いので、今後はそれに気を付けるといった改善ポイントも見えてきます。
デメリット
光があれば陰があるようにデメリットが皆無ではありません。
まず、第1にはどうしても時間がかかってしまいます。タイムボックスを使う。プロジェクトに沿ったスコアの目安を用意するなどして短時間で終えるようにしていきましょう。
本案件ではリスクポイント導入により期待した効果が得られた考え継続して実行しています。
各Sprintでプロダクトバックログ毎に適切にテストを実施したいと考えている方、リスクポイントを活用位したリスクベースドテストを検討してみてはいかがでしょうか。
参考サイト
Risk Poker https://www.tmap.net/wiki/risk-poker
執筆者プロフィール：伊藤 慶紀
大手SIerにて業務用アプリケーションの開発に従事。 ウォーターフォールは何故炎上するのか疑問を感じ、アジャイルに目覚め、 一時期、休職してアメリカに語学留学。 Facebookの勢いを目の当たりにしたのち、帰国後、クラウド関連のサービス・プロダクト企画・立ち上げを行う。 その後、ベンチャーに転職し、個人向けアプリ・WebサービスのPM、社内システム刷新など様々なプロジェクト経験を経てSHIFTに入社。 趣味は将棋、ドライブ、ラーメン、花火、読書など
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら