PRDや画面仕様書に対するレビュー技法のワークショップの内容を大公開！

はじめに

この記事はCommune Advent Calendar 2024シリーズ2の25日目の記事です。

コミューンでQAチームのチームリーダーをしている須賀です。
弊社ではデザイナー、プロダクトマネージャー、エンジニアなどの様々な職種の人が協力してプロダクトを共創する文化を築くために、これらの職種が集まったワークショップを定期的に行っています。各職種の相互理解のために各職種の方が持ち回りでワークショップを行っていますが、今回は私が行ったレビュー技法のワークショップの内容について紹介します。
レビュー技法について知りたい方、ワークショップをやってみたい方の参考になれば幸いです。

レビュー技法をテーマに選んだ理由

今までのデザイナーの方のワークショップでは、いかにして良いユーザー体験を作るかという視点で様々なワークショップが行われてきました。
良いユーザー体験も重要ですが、PRD（プロダクト要求仕様書）や画面仕様書を作る上では

ユーザーが実現したいことをちゃんと実現できるものになっているか
実際にサービスに対して発生しうる様々な事情を考慮しているか

という点も重要になってきます。
そこで、そういった事情の考慮漏れを減らすための方法としてレビュー技法のワークショップを選びました。

レビュー技法とは何か

レビュー技法とは、簡単に言えば、文書等をレビューする際に特定の問題を見つけるための意図を持ってレビューを行う方法です。特定の意図を持ってレビューを行うことで、何も考えずにレビューを行う場合よりもレビュー効率やレビューの品質が向上する可能性があります。
今回はJSTQB Foundation Levelのシラバスに記載されているレビュー技法のワークショップを行いました。
レビュー技法の詳細については、以下の記事をご参照ください。

note.com

ワークショップ全体の流れ

ワークショップでは、前半にレビュー技法の説明と練習のパート、後半に5人1チームに分かれたグループワークのパートに分けて行いました。
どのパートも自由にレビューする時間の後にレビュー技法を使う時間にしています。そうすることで、レビュー技法の良さ（問題の気づきやすさ）を体感してもらいます。

レビュー技法の説明と練習のパート

練習のパートでは主に以下の流れで各レビュー技法の練習を行いました。

仮のプロジェクトの目的、ユーザーストーリーや画面仕様書の説明
自由にレビューする
レビュー技法の説明
レビュー技法を使ってレビューを実施
レビュー技法で期待する指摘内容の提示

以下では、私が実際にワークショップで使ったスライドに記載していた内容を転記しています。
社外の方でもプロジェクトの内容を理解できるように、仮のプロジェクトの説明を一部改変したものになります。
※のコメント は、私の狙いなどを記載しています。

なお、タイムスケジュールは60分に収めるためにタイトになっております。皆さんがもし同様のワークショップを行う場合は、もう少しゆとりを持たせると良いと思います。

シナリオとドライラン

レビュー対象となる仮のプロジェクトの説明

社員同士が交流する社内用SNSで、管理者しか使えなかったクイズ機能を一般ユーザーでも使えるように仕様変更を行うプロジェクトです。

目的
- ユーザー同士がクイズを出して社内用SNSを盛り上げる
- ついでに、ユーザーに何らかの学習効果を出す
ユーザーストーリー
- 管理者は、一般ユーザーに対して、クイズの作成権限を付与できる
- クイズの作成権限を与えられた一般ユーザーは、一般ユーザー側のクイズ一覧画面からクイズを作成、編集、削除できる
  - 参考までに、管理者は管理画面からクイズを作成します
- 一般ユーザーは、上記一般ユーザーが作成したクイズに回答することができる
  - クイズの回答の選択肢を1つ以上選択し、回答ボタンを押すと、正解と解説が表示されます

レビューして欲しい内容

まずは、説明したユーザーストーリーに対して、自由にレビューをしていただきます。
クイズを作成する一般ユーザーとクイズに回答する一般ユーザーは、このユーザーストーリーでプロジェクトの目的を達成できそうかをレビューしてください。（ユーザーストーリーの過不足、または、別のユーザーストーリーの案はないか）

考える時間は2分です。

レビュー技法の説明

シナリオとドライランとは、その名の通り、あらかじめプロジェクトに関係するいくつかのシナリオを用意し、作成したPRDや画面設計書で用意したシナリオが適切に実現できるかを想像で実施（ドライラン）してみます。
そうすることで、ユーザーストーリー全体の矛盾点や不足点などに気づくことができるようになります。

細かい仕様の考慮漏れなどを見つけるのは苦手です。

レビュー技法を使ったレビューを実施

私が練習用に用意したシナリオは以下になります。以下のシナリオを見ながらドライランを実施してレビューしてみてください。

レビュー時間は2分です。

シナリオ
- 誰かがクイズを作成する
- 一般ユーザーはクイズが作成されたことを知る
- 一般ユーザーがクイズを受講する
- 一般ユーザーはクイズの結果を他のユーザーに共有する
- クイズの作成者はクイズの回答結果を見て次の行動を検討する

期待するレビュー結果の例

クイズが作成されたことを知る方法が必要
- ユーザーへの通知
- ユーザーがよく閲覧する画面へのクイズの表示
クイズの結果を他ユーザーに共有する方法が必要
- スクショを撮って投稿する（新規機能開発なし。ユーザーは手間がかかる）
- クイズのURLと回答結果を本文に入力した状態で投稿作成画面を開ける
- クイズに対するコメント機能を実装する
クイズの作成者がクイズの回答結果を見る方法が必要
- 管理者と同様の画面をクイズ作成権限のある一般ユーザーにも用意する

このように、機能の目的を実現するまでにステークホルダーが行うシナリオを頭の中で実際に試してみることで、ユーザーストーリーの過不足などに気づきやすくなります。

※この題材を選んだ狙いは、上記のような既存機能を改修する場合は一般ユーザーがクイズを投稿するまでのユーザーストーリーのみを考えがちだが、実際はクイズを投稿した目的を達成するために必要なフローが他にもあることを知ってほしいためです。

チェックリストベース

レビュー対象となる仮のプロジェクトの説明

あなたは社員同士が交流する社内SNSをノーコードで構築できるサービスを提供しています。このサービスはマルチテナント（複数の顧客・ユーザーが同じサーバーやアプリケーション、データベースといったシステムやサービスを共有して利用する方式）で構築しています。
今回はこのサービスのログイン機能を開発するプロジェクトです。

目的
- 社内SNSの内容は社内の人しか閲覧できないようにする
画面仕様書

受け入れ要件
- Usersテーブルに存在するIDと正しいPWを入力してログインボタンを押した場合、ログイン状態となる
- Usersテーブルに存在するIDと誤ったPWを入力してログインボタンを押した場合、ログイン画面にとどまり、「IDまたはパスワードが正しくありません」というエラーメッセージが表示される
- 「パスワードをお忘れの方」「アカウント登録」のリンクも必要ですが、時間の関係で割愛しています

レビューして欲しい内容

まずは、説明したユーザーストーリーに対して、自由にレビューをしていただきます。
ログイン画面の振る舞いとして定義すべきものが漏れていないか、振る舞いとして不適切な受け入れ要件がないかを自由にレビューしてください。
見た目の良し悪し、セキュリティなどの非機能要件はレビュー対象外です。

レビュー時間は2分です。

レビュー技法の説明

チェックリストベースレビューは、過去の経験などからチェックした方が良いレビューの観点をあらかじめ用意し、チェックリストの観点の通りにレビューをします。
チェックリストベースレビューの利点は、レビューの品質が属人化しにくい点、重要な観点のレビューが少ない時間で効率的に行える点にあります。
ただし、チェックリストは定期的にチェック項目の有効性を確認したり、チェック項目が増え過ぎないように気をつける必要があります。
また、チェックリスト以外の観点については、別のレビュー方法で補う必要があります。

レビュー技法を使ったレビューを実施

私が練習用に用意したチェックリストは以下になります。以下のチェックリストを見ながらレビューをしてみてください。

レビュー時間は2分です。

各機能固有のチェックリスト（今回はログイン）
- ログイン成功後はログイン前に訪れようとしていた画面に遷移するべき
各データ固有のチェックリスト
- ユーザーのテーブルのデータを扱う場合、退会者のデータや別のSNSのユーザーのデータについて、どのように扱うかを気にする必要がある

期待するレビュー結果の例

閲覧にログインが必要なSNSのページにアクセスした時にログイン画面にリダイレクトした場合は、ログイン後に元々アクセスしようとしていたページに画面遷移する
退会者のIDと正しいPWを入力してもログインに失敗するようにする
別コミュニティにあるIDと正しいPWを入力してもログインに失敗するようにする

このように、考慮漏れが起きやすい観点についてチェックリストを作成することで、考慮漏れを効率的に見つけることができます。

※この題材を選んだ狙いは、ログイン画面1つでも考えるべきことはID/PWの正しさ以外にたくさんあることを知ってほしいためです。

パースペクティブベース、ロールベース

ワークショップの時間の関係で、これらの技法の練習は省略しました。

レビュー技法の説明

ロールベースレビュー
- ロールベースレビューとは、プロダクトのステークホルダーの視点でレビューをする方法です。
- 開発する側とは異なる視点を持つことで、考慮漏れに気づけるようになります。
  - たとえば、ユーザーの属性（年齢、性別）、管理者と一般ユーザー、システムの運用担当者、など
パースペクティブレビュー
- パースペクティブレビューは、自分の職種の視点でレビューをする方法です。
- 職種が異なる人同士が集まってレビューをすると、重複が少ない様々な観点でレビューをすることができます。

期待するレビュー結果

年齢が60代のユーザー
- 老眼に配慮して、文字のサイズを大きくできる方が良い
年齢が6歳のユーザー
- 機能の重要性を正しく理解できない子供に配慮して、決済機能を使うためには保護者の操作が必要な方が良い
Webエンジニア
- 実装の難易度が高い受け入れ要件を、実装しやすい受け入れ要件に変更するように提案
システムの運用者
- 運用者しか知らない実際運用する上での問題点を指摘

グループワークのパート

グループワークはFigjamを使って行いました。

以下は実際にグループワークの時に用いたテキスト・画像になります。

グループワークの流れ

グループワークでは、私が考えた仮のプロジェクトに対して、考慮漏れがないかのレビューをしていただきます。レビューの順番は、以下の順番で行い、必ず全てのレビュー方法でレビューを行うようにしてください。

記載している各レビュー方法のレビュー時間は目安です。今のレビュー方法でレビューし切ったと感じたら、早めに次のレビュー方法に移っても構いません。

ユーザーストーリーの過不足や適切さのレビュー
- 自由なレビュー　7分
- シナリオとドライラン　5分
- ロールベース　3分
画面仕様書、および、受け入れ要件の過不足や適切さのレビュー
- 自由なレビュー　7分
- チェックリスト　3分
残り時間が余ったら、自由にレビュー

※ Figjam上ではレビュー技法で見てほしい観点（ヒント）は隠しておき、時間が来たら表示してもらいました

レビュー対象となるプロジェクトの説明

とあるメーカーのファンが集まるSNS（オンラインコミュニティ）を展開しています。もともとSNS上でログイン、投稿、いいねなどをするとポイントを獲得する機能が実装されていました。今回は、このポイントをサイト上で何らかの商品に交換する機能を実装するプロジェクトです。

目的

ポイント獲得のメリットを増やすことで、ユーザーのアクティブ率を向上させます。

ユーザーストーリー

管理者は、ポイント交換商品を作成、編集、削除できる
- ポイント交換商品には以下の項目を設定できる
  - 商品名、商品画像、交換に必要なポイント、商品の在庫、商品の表示順
ユーザーは、コミュニティ画面のマイページからポイント交換画面へ遷移できる
ユーザーは、ポイント交換画面で、ポイント交換用の商品を確認できる
ユーザーは、ポイント交換画面で、自分の利用可能ポイントを確認できる
ユーザーは、ポイント交換画面で、利用可能ポイントを使って商品を交換できる
ユーザーは、利用可能ポイントが足りない商品を交換できない
ユーザーは、在庫が足りない商品を交換できない

ポイント交換画面の画面仕様書

※グループワークでの画面仕様書のレビュー対象はポイント交換画面のみです。

受け入れ要件

ポイント交換商品の一覧は、商品を管理画面の表示順通りに表示する
ポイント交換商品には、名前、画像、必要ポイント、交換するボタンを表示する
交換するボタンは、条件によってボタンの代わりに以下のテキストを表示する
- 自分の利用可能ポイント不足で交換できない商品の場合、「ポイント不足」を表示する
- 在庫切れの商品の場合、「在庫切れ」を表示する
ユーザーは、ポイントを利用して商品を獲得できる
- 交換するボタンを押すと以下の処理が発生する。
  - 「交換成功しました」というトーストがUI上に表示される
  - DB上でユーザーのポイントが減る
  - DB上で交換した商品の在庫が1つ減る

レビュー技法のヒント

シナリオとドライランのヒント

ヒントとなるシナリオ

ユーザーが正しいポイント交換を行った場合のシナリオ
- ユーザーがポイントを獲得する
- ユーザーがポイント交換できることに気づく
- ユーザーがポイント交換画面に遷移
- ユーザーがポイント交換を実施
- 管理者はポイント交換商品をユーザーに渡す
ユーザーが交換する商品を間違えてしまった場合のシナリオ
- ユーザーがポイント交換を実施
- ユーザーが間違えてポイント交換を実施したことに気づく
- ユーザーは管理者に間違えてポイント交換したことを連絡
- 管理者はポイント交換のキャンセルを実施

※この題材の狙いは、商品に交換というシナリオはサイト上だけでは完結しないことに気づいてもらう点、商品の交換に成功したパターンだけでなく失敗したパターンも考える必要がある点にあります

ロールベースのヒント

悪意のある攻撃者がユーザーのアカウントを不正に利用している場合、攻撃者がポイント交換によって利益を得られないようにしてください。

※この題材の狙いは、想定する顧客だけでなく、悪意のある人のことも想定すべき場合があることを知ってもらう点にあります。

チェックリストベースのヒント

ダブルクリックした時に二重でデータが更新されないか
データの一覧を表示する場合に、様々な件数の場合にどのように表示するか
テキストの文字数が多い場合、省略するのか、折り返すのか
ある画面で操作してデータが更新された後、今表示している画面や他の画面に結果がリアルタイムに反映されるかどうか
あるデータに対して同時に複数の更新処理が走った場合に、データ不整合等の問題が生じないことを確認する
- 例）
  - 1人が複数タブを開き、同じデータを同時に更新
  - 複数人が同じデータをほぼ同時に更新
  - 人とバッチが同じデータをほぼ同時に更新
ある機能Aで利用しているデータを機能Bが更新・削除した場合に、機能Aは正しく動作するか。または、機能Bで上記データを更新・削除できないようになっているかを確認する。

※この題材の狙いは、Webサービスにおいて考慮が漏れがちな観点を知ってもらう点です。

グループワークの結果

参考までに、グループワークの結果の一部をご紹介します。

ワークショップに参加したメンバーからは、ワークショップを通じて色々な観点が必要だということに気づけた、グループでレビューを行えて楽しかった、といった感想をいただきました。

おわりに

ここまで長文を読んでいただきありがとうございました。

いかがでしたでしょうか？
実は、このワークの内容は私が普段よく考えていたレビュー観点を言語化したものになります。
私たちQAチームは開発組織全員が品質向上のためのスキルを身につけることを目指しています。今回ワークショップを主催するにあたって、私のレビュー観点を言語化して他の人も様々な観点でレビューできるようになれればと考えていました。

ぜひ皆さんもレビュー技法を使ってレビューを行ってみてください。