プロトタイプ作成（後半）と相互レビュー

• 日程: Day 10 / セッション 3
• 時間: 11:10-12:40
• 形式: 実習
• ゴール: 画面遷移図の通りに遷移するプロトタイプを完成させ、他チームのレビューで指摘を1件以上得て改善点を特定できる
• 学習形式: ハンズオン実習（AIサポートあり）、相互レビュー

前のセッションで主要画面のモックアップがそろいました。
でも今はまだ「バラバラの紙芝居のページ」です。これをつないで動かすのがこのセッションの前半です。

そして後半は、いよいよ他チームによる相互レビュー。

ここで問いかけです。
なぜ、作った本人ではなく「他チームの人」に操作してもらうのでしょうか？

理由は、作った本人は迷えないからです。
自分で描いた画面は、どこを押せば何が起きるか知り尽くしています。つまり「初めて使う人がどこで迷うか」を、作った本人は原理的に発見できません。
間違い探しの問題は、出題者には解けて当たり前なのと同じです。

今日初めて、みなさんの製品は「他人の指」で試されます。
そこで得られる「迷い」こそが、実装前に手に入る最高の宝物です。

やることは明確です。画面遷移図にある矢印を、すべてプロトタイプ上で再現すること。

• Figmaなど: ボタンと遷移先画面をリンク（プロトタイプ機能）でつなぐ
• 紙: 各画面の「どのボタンを押したらどの紙に替えるか」の対応表を作り、操作役が紙を差し替える

完成チェックは簡単です。画面遷移図の矢印を1本ずつ指でなぞり、プロトタイプで同じ遷移ができるか確認します。
「遷移図に矢印があるのにプロトタイプで飛べない」は未完成。「プロトタイプでは飛べるのに遷移図に矢印がない」は設計書とのずれです。どちらも今見つければタダで直せます。

• 仕様の正は画面遷移図。プロトタイプは遷移図の写し
• 「戻る」遷移を忘れがち。行きの矢印だけでなく帰りの矢印も確認
• ずれを見つけたら、勝手に直さずチームで合意して遷移図側も更新する

Webの世界には「行き止まりページ」という古典的な失敗があります。リンクもボタンもなく、ユーザがどこにも行けなくなるページです。1990年代のWebデザイン論争では「すべてのページに出口を」が大原則とされました。ゲーム業界にも同じ知恵があり、マリオの最初の画面は「右に進むしかない」ようにデザインされています。ユーザを迷わせないとは、実は「進める道を1本に見せる」技術なのです。

レビューの進め方には、大事な作法が3つあります。

1つ目: 操作する人は「ペルソナになりきる」。
レビューに来た他チームの人に、自チームのペルソナのプロフィールを30秒で説明します。「あなたは60代・スマホが苦手な田中さんです。お弁当を予約したい」のように。レビュアーはその人物として操作します。

2つ目: 作った側は「黙る」。
操作中、説明したくなっても我慢です。「あ、そこはですね…」と言った瞬間、検証は台無しになります。本番のユーザの隣に、みなさんは立てないのですから。記録係は迷った場所・押し間違えた場所・眉が動いた瞬間をメモします。

3つ目: 指摘は成果物へ、感謝を添えて。
レビューする側は「この画面が悪い」ではなく「この画面で次にどこを押すか3秒迷った」と事実を伝えます。受ける側は反論せず「ありがとうございます」とメモ。直すかどうかは後でチームで決めればよいのです。

「指摘ゼロでした！」は誇れる結果に該当しません。観察が浅かった可能性が高いからです。「迷いを3件もらえました」が該当します。実装前に3件の手戻りを防げたのですから、今日の勝者です。

• レビュアーには先にペルソナを演じてもらう設定を渡す
• 作った側は操作中に口出ししない。沈黙が最高の観察環境
• 指摘は人格ではなく成果物へ。もらった指摘は宝物としてメモする

ユーザビリティテストの世界的権威ヤコブ・ニールセンの研究によると、「ユーザテストは5人で十分」だそうです。5人テストすれば問題の約85%が見つかり、それ以上増やしても発見が重複していくとのこと。つまり今日の「他チーム数人による15分のレビュー」は、遊びではなく統計的に裏付けのある検証手法のミニ版です。ちなみにニールセンは「企業がユーザテストをしない言い訳ランキング」も発表していて、1位は「時間がない」。みなさんは今日、その言い訳を卒業します。

作業・レビュー中、こんな使い方ができます：

• 「Figmaのプロトタイプ機能で画面をつなぐ手順を教えて」
• 「相互レビューで観察すべきポイントをチェックリストにして」
• 「『一覧画面で次の操作に迷う』という指摘をもらった。考えられる原因と改善案は？」
• 「このペルソナ（プロフィールを貼る）になりきって、この画面遷移の気になる点を挙げて」（AIにもレビュアーをやってもらえます）

プロトタイプを完成させ、他チームと相互レビューを行ってください。

1. 遷移をつなぐ（25分）

   • 画面遷移図のすべての矢印をプロトタイプ上で再現する
   • 遷移図を1本ずつ指でなぞり、漏れチェックする（戻る遷移も）
   • 紙チームは「ボタン→差し替え先」の対応表を作り、操作役を1人決める
2. 相互レビュー（20分: 10分×2セット）

   • 他チームとペアになり、互いのプロトタイプを操作し合う
   • 受け入れ側: ペルソナのプロフィールを30秒で説明→黙って観察→迷った箇所を記録
   • 操作側: ペルソナになりきり、声に出して考えながら操作する（「えっと、予約したいから…これかな？」）
   • 役割: 操作する人1名、記録係1名以上を決めておく
3. 改善点の整理（10分）

   • もらった指摘を一覧化し、「実装前に直す / 実装時に考慮 / 対応しない」に仕分ける
   • 直すと決めた項目は、画面遷移図・画面仕様書側も更新する
   • 対応する項目は明日のかんばんにタスクとして追加する

• 画面遷移図の通りに遷移するプロトタイプ（本日の最終成果物）
• レビュー指摘の記録（1件以上。迷った箇所・気づき）
• 指摘の仕分け結果（対応する/しないの判断付き）と、かんばんへ追加したタスク

• 遷移のつなぎ込みで詰まったら、ツール名と症状をセットでAIに質問しましょう。「Figmaでプロトタイプの矢印が表示されない」など
• 時間が押している場合、全部の遷移ではなく「ペルソナの本筋の1往復」を最優先でつなぎましょう。本筋が動けばレビューは成立します
• レビュー中、説明したくなったら深呼吸。どうしても伝わらないときだけ「ゴールは〜です」と目的だけ伝え、操作方法は言わない
• 操作役は「思っていることを実況する」（シンクアラウド法）と、記録係のメモが充実します
• 指摘をもらいすぎて落ち込みそうになったら思い出してください。今日の指摘1件＝実装後の手戻り数時間の節約です
• 仕分けに迷う指摘は、AIに「この指摘に対応するコストと価値を整理して」と相談できます

今回学んだことを一言でまとめると、**「プロトタイプは他人の指で検証して初めて意味を持つ」**です。

• 画面遷移図の矢印をすべて再現し、遷移図とのずれを解消した
• ペルソナになりきった他者の「迷い」から、実装前に改善点を発見した
• 指摘は仕分けて、対応するものはかんばんのタスクに変換した

これでDay 10のゴール「画面遷移図の通りに遷移するプロトタイプ」が完成です。

明日からはいよいよ実装スプリント。朝会→実装→終会のリズムで、Day 9に作ったかんばんが毎日動き始めます。今日のプロトタイプは、実装中「何を作っているんだっけ？」と迷ったときの道しるべになります。

以下の問いに答えられるか確認してみましょう：

• プロトタイプの完成判定は、何と突き合わせて行いましたか？
• レビューで操作してもらうとき、作った側が守るべきことは何ですか？
• 「ペルソナになりきって操作してもらう」のはなぜですか？
• もらった指摘はどう仕分けましたか？ すべてに対応しない理由は？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: ヤコブ・ニールセン「Why You Only Need to Test with 5 Users」（英語記事。英語の資料を読む練習にも最適）、シンクアラウド法の解説記事
• 発展課題: 家族や友人に自チームのプロトタイプを操作してもらいましょう。IT業界の外の人の「迷い」は、チーム内では絶対に見つからない発見をくれます

このセクションは、受講者が理解を深めることをサポートする参考情報です。