「ソフトウェアレビュー勉強会 レビューワーク04~レビュー結果評価とふりかえり」に参加してきました
最近、時間がとれずイベント参加レポートを書けていませんでした。。
少しずつたまっているものを消化します。。
ということで、
2022年11月14日（月）19:00~21:00に開催された「レビューワーク04～レビュー結果評価とふりかえり」の内容を共有します。
おことわり
今回のレポートは非公式なものであり、自分なりに整理したものです
所感は個人の意見であり、所属企業・部門見解を代表するものではありません。
「こんなこと言っているんだな～」と思ってみていただければと<(_ _)>
まとめ
今回はレビューの評価とふりかえりをテーマとした勉強会
レビューをやりっぱなしにするのではなく、指摘結果を客観的に評価し、ふりかえりを実施することで、レビューノウハウの蓄積、レビュー技術の向上、追加指摘につなげられる
レビューを客観的に評価するためには、レビュー目的を明確に設定する必要がある
テーマ：レビュー結果評価とふりかえり
イベント概要
みなさんは普段のレビュー結果を評価していますか？
また、レビューに対するふりかえりをおこなっているでしょうか？
レビュー結果の評価やふりかえりがないと、いつも同じようにレビューする、習慣に従うレビューになってしまい、レビューのパフォーマンスの向上は期待できなくなります。
今回の勉強会ではレビュー結果の評価方法（の一つ）と、その結果をもとにしたふりかえりをみなさんと一緒にやってみたいと思います。
結果評価とふりかえりがどのような意味を持つのか？／どのような効果を獲得できるのか？／実際、普段のレビューに組み込むにはどうしたらよいか？ などを一緒に考えてみましょう！
私の場合、レビューしっぱなしになっています（笑）
ふりかえりや評価は確かにレビューでも必要だなと感じていましたが、
どんな指標でどういう感じに評価すれば良いのだろうかと思ってました。
どんな内容だったか
以下のワークを実施しました。
【個人ワーク】参加者全員でどんなものをレビュー評価で使用すると良いか考え共有する
【グループワーク】指摘から実際に評価するワーク
【グループワーク】実際に評価したものをベースにふりかえるワーク
①【個人ワーク】参加者全員でどの指標をレビュー評価で使用すると良いか考え共有する
共有会であがった指標は以下です。
見逃した場合後工程で問題になった欠陥かどうか
集中度
どれくらい考えたか
欠陥密度
欠陥指摘数/手戻り数
指摘数
指摘に対する修正工数
成果物を修正するためにかかった工数
全員分のレビュー工数
有効指摘率
所感
指摘内容や工数に着目した指標が多かった印象です。
集中度や見逃した場合に関する指標は考えたことがなかったため、非常に勉強になりました。
今回出たものを参考に評価できればと思います。
②【グループワーク】指摘から実際に評価するワーク
このワークではある成果物（交通費精算システムの要求仕様書）をレビューした結果から10個の指摘を評価するワークでした。
指摘は以下のようなものです。
【指摘1】
利用ユーザは社内システムが利用できる全ユーザ想定になっている。社内システムのセキュリティポリシー等により社内システムにアクセス出来ない社員はいないのか？
（例：外勤者）そのような社員がいた場合の処理はどうするのかが不明である
【指摘2】
申請者、申請日、申請番号はシステム側で表示、申請者は変更できない、とあるが、代理申請などの場合も考えられるため、代理申請であることを知らせる方法（例：備考欄）が必要なのではないか？
【指摘3】
交通費承認一覧画面イメージでは印刷ボタンが先頭になっている。承認・否認・印刷の順、または印刷だけ別場所が良いのでは？
上記の指摘を指摘効果別に分類するワークでした【大・中・小】
自分たちのグループで考えた分類は以下になりました。
効果【大】の指摘：交通費精算システムの目的を達成できないもの
上の例では、指摘1に入るモノです
効果【中】の指摘：目的を達成するためにあってよいもの
上の例では指摘2です。
これがなくても最低限申請できるけど、ある方が良いよねっというものです
効果【小】の指摘：この指摘が漏れても目的遂行のためには支障が出ないもの
上の例では指摘3です。
講師からのFB
評価をするうえで、追加の質問が必要な場合もある（システムの背景によっては効果が変わるモノあり）
代理申請をしたいという背景があれば、【指摘2】の効果は大きくなる
また、講師が考えるレビュー評価基準は以下でした。
レビュー目的を達成しているかどうか
後工程で見逃すと大変なこと
その指摘を見逃したら、どの後工程で発見されるか、そして手戻りはどのくらいかかるのか
所感
こうやって評価することで、追加確認すべきことが見つかったり、
あらたな欠陥を見つられたりと良いきっかけにもなるなと感じました。
また、レビュー目的をちゃんと決めていなかったなとも感じました。
「重大な欠陥が見つかればいいな～」ぐらいしか考えていなかったため、
レビュー目的を評価しやすいレベルに落とし込む必要があるなと感じました。
③【グループワーク】実際に評価したものをベースにふりかえるワーク
実際にチームで出たふりかえりは以下です。
ドメインや背景を理解していないと欠陥を見逃す可能性が高い≒レビュー行うためにはドメイン知識が必要
仕様書の文言だけでなく、背景や業務フローをもとに指摘する内容が多く見られたため
評価を実施することで、レビュー目的や観点などを考えるきっかけになる
所感
ふりかえりを実施することで、「次はこの視点を優先に見ようとか」「この指摘に至った背景はなんだろう」と考えるきっかけになりました。
また、ふりかえることでよりナレッジがたまり、レビュー技術も向上できるなと感じました。
講師おすすめのレビュー評価・ふりかえりフロー
講師によると、
レビュー実施直後に評価（評価軸をもとに分類）⇒ふりかえり
が良いとお話ししていました。
理由としては、評価結果をもとにすることでふりかえりに客観性がますとのことでした。
また、レビュー内容を鮮明に覚えているうちに実施することで大事なことが抜け漏れないという点もあります。
（後日、このレポートのFBをいただきました。ありがとうございます。）
あと、ふりかえりを時間を空けてから実施すると、記憶がベースになるので、思い出すのに時間がかかる、的を外すことが多くなる、大事なことが取り上げられなかったりします。そんなことにならないようにレビュー会直後に行うのがよいんです～。
またレビュー評価を行うためにはレビュー目的を明確にし、共有することが必要とお話ししていました。
※もちろんこの時の評価は人事評価に使わないという前提があります。
全体の感想
いままでは、レビューはなんとなくやっていることが多かったなと思います。
目的なんかまさにそう。。（重大な欠陥をみつけることぐらいしか考えていない気がする）
もう少し、レビューの目的は詳細に決めるのが良いと感じました。
目的を詳細に設定するには成果物の背景などもより調査すべきなんだなというのも感じました。
事前準備大事ですね。非常に勉強になる会でした。
最後に
次回は、レビューワーク06~認知バイアスに着目した欠陥予測の参加レポート書きます。
いつかはわかりませんが。
補足
ソフトウェアレビュー勉強会グループについて
レビュー評価やふりかえりについてのSQiP論文
この記事が気に入ったらサポートをしてみませんか？