JaSST Review'22に参加後、レビュー再考

こんにちは、カトです。弥生でQAエンジニアをしています。

JSTQBシラバスでは、レビューは静的テストであり、テスト活動の一部と定義されています。

弥生では「レビューはテスト」を合言葉に、品質を向上するための重要な活動だと捉えています。
「否定される」「面倒ごとが発生する」といったネガティブな感情を持つことのない、やさしい世界です。

しかし一方で、レビューには課題もあります。

マネージャーやテクニカルリードのような、一部のベテランと呼ばれるようなメンバーしか検出できない指摘がある
自分が他の人が検出できなかった問題点を検出した場合に、なぜ検出できたのかわからないので、再現性がない

これらの課題により、一部のメンバーにレビューの負荷が偏ってしまっています。

自分が検出できたレビュー指摘を、他のプロジェクトでも確実に検出できる
セルフチェックでレビューイーが抜け漏れに気づくことができる

この2点が達成できれば、レビューアーの負荷削減、COPQ（Cost of Poor Quality）の削減となり、より速く、より高品質なプロダクトをお客さまに提供できるようになるのではないかと考えました。
そこで、「レビューで考えることを広げよう！」というテーマで開催されたJaSST Review'22へ、QAエンジニア3人で参加してきました。

レビュー観点は階層構造

ワークショップにて、「交通費精算システム要求仕様書」のレビューを実施しました。

「レビュー観点は階層構造」であるということが説明されました。階層構造を知ることで、「なぜセルフチェックで問題点を検出できなかったのか」「なぜ同じレビュー対象物を見ていても人によってレビューでの指摘内容や指摘件数が異なるのか」ということがはっきりとしてきました。
そして、ワークを実施しながら「次にレビューを依頼するときは、階層構造をつくってみよう」と心に誓いました。

…それが、今です。

この弥生開発者ブログは、何人かのレビューを経て公開しています。
このブログ作成のレビューについて、レビュー階層構造を考えていきましょう。

いかがでしょうか？
レビューアーのみなさんに確認いただきたい観点にマークをつけました。
これを使うことで、レビューの内容が過剰に重複したり、指摘の抜け漏れを防ぐことができるようになります。
また、開発者ブログを公開するにあたり、私が考えるレビュー内容と、レビューアーが考えるレビュー内容がずれている場合には、この一覧を使って合わせをすることができそうです。

JaSST Review'22のワークでは、レビュー観点の階層構造は事前に準備されており、提示があったうえで、それぞれが選んだHow toに基づいてレビューを実施しました。
このため、今回のブログ作成で、レビュー観点の階層構造をはじめて作成しました。何を見てほしいのかが明らかになり、セルフチェックもしやすくなりそうだと感じています。

レビュー観点の階層構造のメリットは以下です。

レビューする必要がある、あらゆる成果物に対して応用ができる
成果物を作成前に、どのようなゴールを目指して成果物を作成するのか、理解を合わせることができる

弥生のレビュー記録表

弥生では成果物を作成すると同時にレビュー記録表を作成する手順になっています。作成するレビュー記録表に、レビューイーがあらかじめ以下を記載します。

プロジェクト名
レビュー対象物の名称
レビューイーの名前
レビュー観点

今まで、なぜレビュー観点をレビューイーが書くのか、私は説明できませんでした。
そして、レビュー観点を階層構造化できていなかったため、レビュー観点と思われる内容をなんとなく書いていました。
さらに、レビューアーはレビューイーが書いたレビュー観点以外の指摘事項を挙げており、「レビューイーがレビュー観点を記入する」ということが形骸化してきてしまっていました。

今回、JaSST Review'22のワークでレビュー観点の階層構造を知ったことで、レビューイーが記載するレビュー観点は「Why」だけでは足りないという気づきがありました。

レビューは技術なので、階層構造化するだけで「誰でも漏れなく指摘が可能になる」ということにはなりません。しかし、「あの人でないと指摘ができない」を少しでも減らして、みんなで品質を高めていく活動へ、一歩近づいたような気がしています。