ソフトウェアレビュー勉強会 レビューワーク02～HDR法を使った仮説検証アプローチに参加してきました
2022年8月25日（木）に開催されたレビューワーク02～HDR法を使った仮説検証アプローチに参加してきましたので、その内容を共有したいと思います。
おことわり
今回のレポートは非公式なものであり、自分なりに整理したものです。
また所感の内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。
「こんなこと言っているんだな~」と思ってみていただければと<(_ _)>
お伝えしたいこと
HDR法はトップレビューアの思考プロセスに着目したレビュー技法であり、兆候をつかむ⇒仮説導出⇒検証というサイクルを回すもの
HDR法をうまく適用できると、重要度の高い欠陥の検出率が上がる
今回のワークではさまざまな仮説が導出され、人によって兆候のとらえ方が違うということを体験できた
HDR法は意外と無意識のうちにやっている部分があるということを感じれた
ソフトウェアレビュー勉強会とは？
2か月に1,2回の頻度で開催される勉強会で、レビュー観点の導出方法や指摘の伝え方などのコンテンツを実施する会です。
会としては1回もの（シリーズものではない）ため、途中からの参加でも問題ないものとなっています。
こちらの勉強会では運営メンバーも募集中とのことです。
概要は以下の通りです。
JaSST2022東京で実施したレビューワークをきっかけにしたソフトウェアレビューの非定期開催勉強会です。 下記のようなことを隔月開催程度の頻度で実施する予定です。
・普段のレビュー実践状況やその問題点、困りごとの共有。 ・これまでに提案されたレビュー関連の実践事例の共有と解決する課題の紐付け。 ・さまざまなソフトウェアレビュー手法の共有と実践。 ・レビューにおけるファシリテーションのあり方の明確化と実践。
今回はレビュー技法のひとつである、「HDR法」をテーマとした勉強会でした。
ソフトウェアレビュー勉強会その２ テーマ：HDR法を使った仮説検証アプローチ
重大な欠陥を検出するために、皆さんはどのような工夫をされているでしょうか？ レビュー対象を隅から隅まで熟読して、時間をかけて記載内容をしっかり理解する？ レビュー勉強会の第２回で取り上げるテーマは、実はそれとは全く逆のアプローチです。 レビュー対象物をざーっと眺めるだけで、ピタリ重大欠陥を射抜いてしまう方法です。 難しい知識や技術は不要です。初心者の方でもすぐに始められる手法です。 ぜひこの手法をマスターして、 「仕様書の中身も見ずに、なんでそんな重大欠陥を見つけてしまうの？」 と周りの人を驚かせてしまいましょう！
参加目的
いままでレビュー技法というものに触れてこなかったため、体験してみたい
事前に論文を読んで、参加者の皆さんはどんな仮説を導出するのか気になった
今回はどんなことをしたのか？
HDR法についての説明
まず初めに、HDR法について簡単に説明がありました。
以下のURLから論文とスライドがダウンロードできます。
【概要】
HDR法はトップレビューアの思考プロセス（どんなことを考えてレビューしているのか）に着目したもの
トップレビューアはレビュー対象物だけでなく、外部の状況から兆候をつかんでいる
そこから仮説（レビュー観点）を導出後、その観点をベースにレビューを行い、欠陥を検出するといったサイクルを回している
このサイクルを回すためには、兆候、仮説、欠陥がセットになった「欠陥知識」が重要であり、この知識は知見や経験が必要
（ワークの説明をもとに執筆者が作成）
【所感】
この方法を聞いて、確かにトップレビューアというか鋭い指摘する人はいろいろ観察している部分があるなと感じました。
また、いろんな外部要因から兆候をつかんで仮説を導出するという行為や欠陥知識の記憶方法（ベン図やツリー図等）はソフトウェアレビュー以外でも活かせそうだなと思いました。
個人的に気になったところは、兆候からどのように仮説を導出するかという部分です。
論文では仮説導出の際に参考にする品質要求・品質特性（※）や兆候/仮説/欠陥の例の一部などが記載されていましたが、実際参加者の皆さんがどんな仮説を立てるのか気になりました。
(※)品質要求・品質特性
レビュー対象物を作成する上での構築環境や前提条件・制約条件といった外部要因や、レビューチア商物の直接的な品質を示す要素のことである
ワーク①：実際のwebサイトから兆候⇒仮説導出⇒仮説検証を回してみよう
まず1つ目のワークは、実際のサイトをもとに、兆候⇒仮説導出⇒仮説検証を参加者全員で体験しました。（miroを使って実施しました。）
まずは兆候をつかむ部分ですが、今回はレビュー対象物しかないため、兆候をつかむよりも先に欠陥を見つけてしまうことが多々ありました。（私も先に欠陥を出してしまいました。）
そのため、途中からはその欠陥からどんな兆候が考えられるかといった時間になりました。
ワークでは「AとBの内容が矛盾している」という欠陥に対して、以下の兆候があげられていました。
・AとBは別々の人が担当していて、あまり相談せずに作成したのでは？
・継ぎ足しでBが追加されたのでは？
次に仮説導出ですが、自分は「整合性が取れていない」ぐらいしか出ませんでしたが、様々な仮説が出ていました。
中には大喜利チックな仮説もあり、ところどころ笑いがありました。^-^
最後に仮説検証（欠陥検出）があり、仮説をもとにレビュー対象物の欠陥を洗い出しました。
序盤の兆候をつかむ段階で欠陥は出てしまったものの、それに加えていろいろな欠陥が検出されていました。
序盤で検出していた欠陥と比べて「個人情報の取り扱いに必要なプライバシーポリシーを載せていない」「緊急連絡先の記載がない」等、重要度の高い欠陥が多く見つかっていた印象でした。
【やってみた感想】
＜兆候をつかむ＞
「欠陥⇒兆候」を考えることを普段の業務ではしてこなかったため、ワーク中は非常に新鮮に感じていました。
ただ、起きたことをふりかえって次に活かすという行為は、普段のふりかえりでもやっているため、一つの事象から背景を考えるという行為はレビュー以外でも非常に重要なことなんだなと改めて学びました。
＜仮説導出＞
他の参加者の皆さんはいろいろと導出されており、「そういう仮説につながるのか～」と感じるものが多かったです。（これが経験や知見の差なのかなと。。）
普段から仮説を出す癖をつけないといけないなと感じました。
また仮説内容が具体的だったので、HDR法の説明時に気になっていた部分はある程度解消されました。
＜欠陥検出＞
重要度の高い欠陥が見つかるかどうかは仮説次第という印象で、結構属人化しそうだなとも感じました。
miroでいろいろと記録が残っているため、後日確認して他の参加者はどんな仮説を立てたのか確認したいと思います。
ワーク②：普段の業務で感じている兆候を洗い出す
このワークでは、参加者の皆さんが普段の業務で感じている兆候を洗い出しました。
【やってみた感想】
いろいろ多くの兆候がありましたが、「わかるわ～」と共感する内容が多く、皆さんも同じような経験しているんだなと感じました。
兆候の全体を見てみると、成果物の作成プロセス、プロダクト、過去のレビュー結果など様々なところから兆候が出ているところを見て、論文に掲載している品質要求・品質特性一覧に当てはまるな～と感じました。
全体の感想
説明やワークを通して、参加者の考えを知ることができて、良い勉強会だったと思います。
個人的にはレビュー経験が浅く、兆候⇒仮説導出部分はまだまだなところがあるため、実務ですぐに活かすのは難しそうだなと感じました。
ただHDR法はレビュー以外でも活かせそうなので、論文も再度確認しながら、業務でなるべく兆候をつかむ（観察する）というところから始めてみたいと思います。
最後に
今回は第2回の参加報告をしました。
次回は10月ごろ、レビューのファシリテータをテーマにして開催するとのことです。（東北おじさんが見れるかも）
私も日程があえば、参加したいと思います。
第1回勉強会の参加レポートはこちら
この記事が気に入ったらサポートをしてみませんか？