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

• 日程: Day 10 / セッション 3
• 時間: 11:10-12:40（90分）
• 形式: 実習（ハンズオン実習、AIサポートあり、相互レビュー）
• ゴール:

  • 行動: 画面遷移図の通りに遷移するプロトタイプを完成させ、他チームのレビューで指摘を得て改善点を特定できる
  • 条件: 他チームに「ペルソナになりきって」操作してもらいながら
  • 基準: 90分以内に、（1）全主要画面が遷移で繋がっている、（2）他チームから指摘1件以上を得る、（3）改善タスクをかんばんに登録する
• 学習形式: AI協働型（ハンズオン実習、相互レビュー）

前のセッションで、画面の枠組みができました。ここからやることは2つ。

1. 画面遷移図の通りに「繋ぐ」 — ボタンを押すと次の画面に行く、という動きを実装
2. 他チームに見せてレビューをもらう — 自分たちでは気付かない盲点を発見

特に2番が大事。自分の作ったものは、自分には欠点が見えません。料理を作った本人は味見しすぎて「もう何が美味しいか分からない」状態になります。プロトタイプも同じ。他者の目を通すことで、初めて改善点が見えます。

合言葉。

「ペルソナになりきって、迷う場所を記録する」

各ボタン・リンクに「どの画面に行くか」を設定していきます。

ツール別の繋ぎ方の概念。

遷移を全部繋ぐ前に1本通す。最も重要な経路（ペルソナがCJM上で必ず通る経路）を最初に繋ぎ、動くことを確認してから残りに広げます。

レビューはペアまたは小グループで行います。本研修では2チーム1組のペアにします。

各ステップの時間と内容。

最大のコツは**「無言観察」の5分**。作り手はつい「あ、それは右上のボタンです」と言いたくなります。言ったら負け。黙って観察するからこそ「ここで迷う」がわかります。

ユーザビリティテストの第一人者ヤコブ・ニールセンは、「5人ユーザに使ってもらえば、ユーザビリティ問題の85%が見つかる」と言っています。何十人も呼ぶ必要はなく、少人数で良いから観察することが大事。本研修の相互レビューも、同じ思想です。1ペアの観察でも、自分たちでは見つけられなかった問題が驚くほど出てきます。

観察結果はテンプレートで記録します。

優先度をつけて**「全部対応する必要はない」**ことを明確に。Day14中間発表までに改善する余裕は限られています。高優先度から対応。中・低は実装スプリント中に取り組みます。

「人ではなく成果物にフィードバックする」「良い点も必ず伝える」の原則を守ります。

レビューはチームの実力差ではなく、成果物の改善余地を見つける場。お互いに敬意を持って、事実ベースで伝えましょう。

他チームに見せる前に、AIにペルソナ役を演じてもらってセルフレビューします。

AIへの依頼例。

「あなたは私たちのペルソナ『田中花子（30代女性、子育て中、平日昼間に時間がある）』です。これから私たちのプロトタイプの画面遷移を説明しますので、彼女の立場で『迷う場所』『使いにくい場所』を指摘してください」

セルフレビューで明らかな問題を潰してから、他チームレビューに臨むとより深い指摘が得られます。

画面遷移図の通りに、すべての主要画面が遷移で繋がっているプロトタイプを完成させる。

他チームとペアになり、相互にレビューを実施。各チーム最低1件以上の指摘を受ける／出す。

得たフィードバックを、優先度をつけてかんばんに「改善タスク」として登録する。

• 画面遷移図の通りに遷移するプロトタイプ（一連の操作が止まらずに最後まで動く）
• レビュー記録（テンプレート形式、最低1件のペルソナの迷いを記載）
• かんばんに追加された改善タスク（最低1件、優先度つき）

• 最重要経路を最初に繋ぐ。CJM（To-Be版）の主要シナリオが動けば、最低限のプロトタイプとして成立
• 繋ぎ込み中にミスした遷移は、付箋に書いて後で直す（中断して直さない）
• セルフレビューで「明らかな迷い箇所」を先に潰す
• 相互レビューはペルソナの設定をきちんと共有してから始める（「30代女性、IT初心者」など）
• 受け取ったフィードバックを全部対応しようとしない。優先度の高いものに絞る勇気を

• 「あなたはペルソナ〇〇さんです。次の画面遷移を見て、どこで迷うかを指摘してください」
• 「相互レビューで他チームから『〜が分かりにくい』と言われました。よくある改善パターンを3つ教えてください」
• 「明日からの実装スプリントで、レビューで出た改善タスクの優先順位の付け方を教えてください」

• ペルソナ設定を相手に説明した
• 操作タスク（〜したい）を明示した
• 操作中は口出ししなかった
• 観察した「迷い」を記録した
• 良い点も必ず伝えた
• レビュー記録テンプレートに記入した
• 高優先度の改善タスクをかんばんに追加した

このセッションでは、プロトタイプを完成させ、相互レビューを通じて改善点を発見しました。

明日からの実装スプリント（Day11-17）で意識すること。

• このプロトタイプが「動く設計書」。実装の北極星になる
• レビューで出た改善タスクは、かんばんに入って通常タスクと同じ優先度判断にかける
• プロトタイプを更新したら、画面仕様書も更新する（ドキュメントドリフト防止）

22日間の研修のうち、ここまでが「設計と試作」のフェーズです。明日からはいよいよコードを書いて動くものを作ります。プロトタイプは捨ててOKですが、プロトタイプで得た学び（特にレビューでの気づき）は実装に活かしましょう。

最後に、完成したプロトタイプをチームで通し操作してみてください（話す＆行う）。「最初の画面から最後まで、止まらず操作できる」ことを全員で確認できれば、Day10は成功です。

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

• プロトタイプの相互レビューで「無言観察」が重要なのはなぜですか？
• 良いフィードバックの伝え方には、どんなコツがありますか？
• レビューで出た指摘をすべて対応しないのはなぜですか？

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

• 関連用語: ユーザビリティテスト、ヤコブ・ニールセン、ヒューリスティック評価
• 発展課題: 同じプロトタイプを、別のペルソナ視点でもう一度レビューしてみる（「ITが苦手な60代」「忙しいビジネスパーソン」など）
• 参考: 明日からの実装スプリント（Day11-17）で、このプロトタイプを設計書として使います