この記事は ACCESS Advent Calendar 2023 8日目の記事です。
こんにちは、 @keigo1450 です。最近鯖缶の美味しさに目覚めました 
今日は JaSST Review'23 に参加して得られた気付きについて書きたいと思います。
要約すると
- レビューで何を見たのか報告しよう（特に指摘が不要だったレビュー観点）
- レビュー観点を活用しよう
- JaSST Review でレビューへの理解を深めよう
JaSST Review とは
JaSST Review は静的テストの一種である「レビュー」に特化したシンポジウムです。
- レビューで表面的な指摘ばかり出る（本来指摘したい、本質的・重大な問題を指摘できていない）
- 複数の人が同じ観点で同じ問題を見つけてしまう（非効率になっている可能性がある）
- レビューの成果がレビュアーのスキルに依存している（有識者にレビューが集中する）
といった、レビューあるあるな問題を解決するための知識・ヒント・事例・ワークが詰まったイベントです！
知っているようで知らない「レビュー」
ソフトウェア開発を行う中で、皆さん日々いろいろなレビューを行っていると思います。
- 要件定義書レビュー
- 仕様書レビュー
- 設計レビュー
- コードレビュー
- ドキュメントレビュー
- などなど…
先程 JaSST Review の説明で触れた通り、レビューは静的テストの一種とされています。
「テスト」というとテストコードを書いたり、実装が終わってから行うものというイメージがありますが、実は様々な場面で（意識せずに）テストしているということですね。
（話が逸れますがレビューは欠陥や不備の検出だけが目的ではなく「関係者内での情報共有」や「レビューによる教育・学習」などの側面もあり、他のテストとは毛色が違う感じもしますね…これらの効用はソフトウェアそのものではなく開発チームの質を上げているように見えるので、学習と適応を繰り返してチームとして成長していくアジャイル開発とレビューは相性が良さそうです）
さて、そのレビューですが、皆さん「なんとなく」行なっていませんか？
- レビューって何をやれば/どうやればいいんですか？
- レビューが負担になっているんですが、やらないのもどうかと思うし…どうすれば？
若手からこんな質問をされたら、どう答えますか？
レビューの結果報告…？
ところで、手動テストを行った場合はテスト実施者や管理者が結果報告（完了報告）を書くことが一般的でしょう。
もしチケットに試験表もなしに「OKでした！」とだけ書いてあったら、（よほど瑣末な対応でない限り）「何を見たのか？」「何をもってOKと判断したのか？」不安になりますよね。
（ちなみに試験表があったとしても要約を書こうという記事を 2019 年の Advent Calendar で書いていました。）
では、テストの一種であるレビューの結果報告は…？
「LGTM」「特に指摘はありません」とか書いてませんか？ （私は書いてました。）
もちろん、レビュー指摘（手動テストでのバグ報告や質問のような位置付けになると思います）があればそれは記録されていると思いますが、「確認した結果問題なかったこと」「少し引っかかったが相対的に軽微だったため指摘しないでおいたこと」は記録に残っていないのではないでしょうか…？
レビュー観点のリバースエンジニアリングをしよう
ということで、今回の本題は上で紹介した過去記事のレビュー版で、 「レビュー完了時に、レビュー結果からレビュー観点を言語化してみよう」 ということです。
例えばECサイトの仕様書レビューで 「商品をカートに追加したら即カート画面を表示する仕様は、他にも商品を買いたいユーザにとって面倒では？」という指摘をしていたら、Github の PullRequest や issue などに
レビューを行い、一点コメントしました。
レビュー観点：
・エンドユーザが商品を1種だけ購入する場合、複数種購入する場合など、現実にありうる様々なカート追加のパターンでシステムが使いにくくないか
・エンドユーザが商品をカートに入れたまま放置した場合に起きうる各ケースが仕様でカバーされているか
・競合他社と比較して機能が意図せず不足していないか
のように書くと、「何をレビューしたのか」「何をもってOK/NGとしたのか」が分かりやすくなると思います。
レビュー観点を書くメリット
レビュー観点を言語化することで、他にも確認した方がよい場所が見つかる
上の例だと「商品が0でカートを表示したときの記載あったっけ？」「エンドユーザがカートに商品を入れたまま退会するとどうなる？」などを思いつくかもしれません。
観点を書こうとすると自分が行ったレビューのレビューをすることになり、更に頭の中だけで見直すよりも抜け漏れに気付きやすくなります。
後からレビューするレビュアーが「どの観点ではレビュー済みか」が分かる
記載の粒度や前レビュアーのスキルにもよりますが、少なくとも「まだ誰もレビューしていない観点」にはより注意を払った方がよいでしょう。（例えば、誰も非機能的な観点でレビューしていないと気付くかもしれません。）
レビュー観点を再利用できる
明文化されたレビュー観点を基点として、様々な活用が考えられます。
- レビュイーが次回作業時のセルフチェックに使う
- 初心者レビュアーのガイドとして使う
- 下流のテストのインプット（テストベース）として使う
- 観点を重要度や欠陥検出数などでランク付けしてレビューの重みをコントロールする
- 時間がないとき、複数人で分担して短時間でレビューを終わらせる
- 後日指摘漏れが見つかったときに観点群にフィードバックする
- などなど
レビュー観点を書くときの課題
レビュー観点をうまく書けない…
JaSST Review'23 で「指摘から観点導出」のワークをやったんですが「これムズっ」てなりました。
観点を書こうとすると、観点同士の粒度を揃えたくなったり、網羅性や厳密性が気になったり、MECEにしたくなったりすると思いますが…難しかったら一旦忘れていいと思います！
- 正確な言語化ができているかはそこまで気にせず、ライトに書く
- 読みやすい量（例えば5つまでとか）になるように抽象化したりまとめたり重要度が低いものを削除したりする
という感じで、まずは書くこと、改善は中長期的に検討していけばよいのではないでしょうか。
「こんな素朴な観点でいいのかな…」ってなったときは…ChatGPTにそれらしい言い回しを考えてもらうといいかもしれません！（思いつき）
これって設計レビュー/コードレビューでも使えるの？
少なくとも要件/仕様など上流の成果物、そしてテスト系の成果物についてはレビュー観点の書き出しはできるし、何かしらの効果もあると思うのですが、実装寄りの成果物レビューで使えるのかは経験がないので何とも言えないです…。
もしかすると
- 設計方針やコーディングルールを明文化している場合はそれと重複しないようにする（記載されていない観点のみ書くようにする）
- 機能正確性、可読性、一貫性、変更容易性、試験容易性など、一部の観点は集約する
- 「ここはXXXじゃなくてYYYを使うのが正しいです」といった単純な誤りの指摘は観点導出しない
などの工夫が必要なのかもしれません。
または「この製品ではこんなことに気をつける必要がある」といったドメイン知識の形式知化に注力する、とかのアプローチが効果的かもしれません。
プロセスが重くならない？
さくっと書いてSlackでLGTMのリアクションをもらって完了、という迅速さも時には必要ですよね。
報告を必須にしてしまうと重いかもしれないときは、推奨にとどめてみたり、大きめの対応項目に絞ってみたり、立ち上げ期や新メンバーがいるときに取り入れてみたりするのもいいと思います。
おわりに：JaSST Review はいいぞ
今回の JaSST Review で「そういえばレビューってテストなのに結果報告してないじゃん」って気付いたのが個人的に衝撃だったのでこの記事を書きました。JaSST Review すごい。
詳細は書ききれないのですが、JaSST Reviewではレビュープロセス（テストプロセス相当のプロセス）を定義しようとしたり、レビュー目的、ハイレベル/ローレベルレビュー観点、レビューのアプローチなどの概念/用語が整理されたりしており、「なんとなく」を脱してレビューの質の改善に取り組むための道具がたくさん手に入る場だと思います。
気になった人はぜひ次回の JaSST Review を覗いてみてください！
明日は @SekiT が何かクールな記事を書いてくれます！お楽しみに！