レビュー相手の決め方
アプリ操作デモのレビュアーは「動作の正確さを確認する開発者・QA」と「UI/UXを確認するデザイナー・PdM」と「ビジネス要件に沿っているかを確認するステークホルダー」の3層に分けるとよい。それぞれ確認すべき観点が異なるため、同じURLで同時に依頼するより、フェーズ分けしてレビューを回すほうが指摘の品質が上がる。
ステークホルダーにデモを見せる場合は、操作フローを限定した誘導付きのURLを渡すと効果的だ。「このURLを開き、画面上の案内に従って3ステップ操作してください」という形で依頼すると、相手が迷わずに主要機能を体験できる。全ての画面を見てもらおうとすると時間がかかりすぎてフィードバックが得られなくなる。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
認証方式の選び方
社内の開発・デザインチームには会社ドメイン認証が最も効率的だ。特定のgitブランチのビルド成果物を共有する場合、CIの都度URLを更新するワークフローと組み合わせると「最新のデモを常にこのURLで確認できる」という状態を作れる。ドメイン認証なら新メンバーが入っても追加設定なしでアクセスできる。
外部のデザイン会社や受託開発先へのレビュー依頼にはパスワード認証が適する。メール認証はアドレスを個別に登録する必要があるが、パスワードなら担当者が社内で自由に転送できるため、小規模なパートナー企業との連携時に摩擦が少ない。ただし契約終了時にパスワードを変更するか期限を終了するかを必ず実施する。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
フィードバック回収
デモのフィードバック依頼時には「画面名と操作の組み合わせ」で問題を報告してもらうようテンプレートを提供するとよい。「商品検索画面でキーワードを入力した後、候補が表示されるまでに時間がかかりすぎる」のように、どの画面のどの操作かが特定できる形式にすると、開発側が修正箇所をすぐに把握できる。
指摘が複数の観点から同時に集まった場合は、「動作バグ」「UI調整」「要件変更」の3分類でトリアージする。特に要件変更は開発コストが大きいため、デモレビューの段階で確認できると後工程での手戻りを防げる。Googleフォームやノーションのデータベースで分類しながら収集すると集計が楽になる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
公開終了の処理
デモの本番リリースが完了したら、レビュー用URLを即時無効化する。本番環境と異なるUIのデモが有効なままだと、ユーザーやメディアが誤って古いデモを本番と混同してスクリーンショットを拡散するリスクがある。リリース当日の作業チェックリストにURL無効化を必ず含めておく。
公開終了後も、どのバージョンのデモを誰がいつレビューしたかの記録は残しておく。製品の仕様変更について後から「なぜこの設計になったか」を追跡するとき、デモレビューのフィードバックが意思決定の根拠になることがある。URLとバージョン・レビュア・期間を1行でまとめた台帳をプロジェクト管理ツールに残す習慣をつける。
よくある質問
デモHTMLに未公開の機能名称が含まれている場合、会社ドメイン認証では社員全員が見られてしまいます。部署を絞る方法はありますか？
会社ドメイン認証は同一ドメインの全メールアドレスを許可する設定です。部署を絞りたい場合はメール認証に切り替えて対象者のアドレスを個別登録するか、パスワード認証にして特定の部署チャンネルだけで共有する運用で対応できます。
QAが指摘したバグを修正してHTMLを差し替えた場合、レビュアーは自動的に更新に気づきますか？
差し替えても閲覧者への自動通知は行われません。修正が完了したら「○時にデモを更新しました。再確認をお願いします」とSlackやメールで案内する必要があります。重要な修正の場合はキャッシュクリアの手順も合わせて伝えると確実です。
複数バージョンのデモを並行してレビューに回したいとき、同じHTMLファイル名でURLが別になりますか？
アップロードのたびに新しいURLが発行されるため、バージョンごとに別URLで管理できます。どのURLがどのバージョンかをわかりやすく管理するために、URLを発行するたびにバージョン番号と用途をメモしておくことを推奨します。