48時間で動くプロトタイプを使ったユーザーインタビュー

48時間のインタビューで何が分かるか

動くプロトタイプは多くの議論をすばやく終わらせます。誰かが実際のタスクを実行しようとすると、彼らがどうするかを推測するのをやめて、実際に何をするかを見ることができます。だから荒削りでも、動くプロトタイプを使ったユーザーインタビューはチャットでの議論に勝ります。

スコープを絞れば、3〜6回のセッションで多くを学べます。完璧な統計は得られませんが、今週直せる繰り返しのパターンは見つかります。

48時間あれば、人がどこでつまずくか・戻るか、どのラベルが混乱を招くか、最初に何を試すか（何を無視するか）、いつフローを信頼するのに情報が足りないと感じるか、価格や権限、進行の保存など疑念を生む瞬間を確実に発見できます。

このやり方は大規模なリサーチや長いアンケート、手当たり次第の探索を避けます。目的は市場全体をマッピングすることではなく、重要なフローひとつにおける最大の摩擦を取り除くことです。

誰かをスケジュールする前に、単一の学習ゴールを定義してください。シンプルなフォーマットが効果的です：「初めてのユーザーがY分以内にXを助けなしでできるか？」 たとえばシンプルなCRMなら：「新規ユーザーが連絡先を追加し、タグ付けして再度見つけられるか？」のように。

もしKoder.aiのようなツールで素早くプロトタイプを作ったなら、ゴールは変わりません：ひとつのフローを選び、実際の人が試すのを見て、何を変えるべきかを正確に記録する、という点です。

ゴールは狭く設定する（インタビューを集中させるため）

48時間ラウンドが機能するのはスコープを小さくするからです。特定のユーザータイプと、彼らが既に理解しているシナリオを一つ選んでください。オンボーディング、価格、設定、エッジケースを同じセッションで扱おうとすると、証拠ではなく意見だらけになります。

一文のゴールを書きます：「初めてのフリーランスデザイナーが、3分以内に請求書を作成して送れるか？」というように。これで誰が対象で、何をする必要があり、「良い」とは何かが分かります。

観察できる成功シグナルを選ぶ

誰にも会う前に何を測るかを決めておきます。セッション中に見やすくシンプルに保ってください。多くのチームにとって、それは速度（完了時間）、摩擦（どれだけつまずくかや「次は？」と聞く回数）、ナビゲーションの問題（ためらいや読み直し、戻る動作）、信頼シグナル（支払い、プライバシー、エラーへの不安）の組み合わせです。

次に、ラウンドの終わりまでに答えたい3〜5の質問を書きます。例：

• 人はどこからこのフローを始めると期待するか？
• 最初に本当の混乱を起こす画面はどれか？
• どの文言が不安にさせるか？
• プロトタイプがサポートしていないことは何か？
• 何があれば「使いたい」と言わせられるか？

ストップルールを設定する

できるからといって延々とインタビューを続けないでください。いつ止めるかを前もって決めておき、作る方に戻れるようにします。実用的なルール：5セッションで止める、または同じ上位2つの問題が3回連続で出たら早めに止める、など。

例：5人中3人が「Create invoice」が「Billing」の下に隠れて見つけられなければ、ラベルを変える、入口を移す、そしてその変更を再テストするという明確なビルドリクエストがあります。

48時間のスケジュール（シンプルで現実的）

募集、準備、実行、合成を短いスプリントとして扱えば、2日間で有用なユーザーインタビューを回せます。目安は3〜5セッション。3が最小で、5はパターンを示すことが多いです。

現実的な計画例：

• Hours 0-4: 1文のゴールを書き、2〜4のタスクを選び、短い招待文を作成して募集を開始。
• Hours 4-12: スロットを予約、適合確認、同意取得、明らかなバグを潰すためのプロトタイプチェック。
• Hours 12-24: 2セッション 実行。各セッションの直後に5分で要約を書く：彼らが試したこと、ためらった場所、期待していたこと。
• Hours 24-36: 1〜3セッション 追加で実行。スクリプトとセットアップは同じにして比較できるように。
• Hours 36-48: 合成。ノートをテーマ別にクラスタリングし、上位3つの問題を選び、ビルドリクエストに変える。

募集が遅いなら待たないでください。スコープを減らし、利用可能な時間を増やします。早朝や夜の枠を増やす、セッションを15分に短縮する、あるいはターゲットに近い身近な層から募集するなどです。

整理のために、最初のコール前に小さなフォルダ構成を作っておくと便利です：

• 01_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

ファイル名は P01_2026-01-16_Record.mp4 や P01_Notes.md のようにします。この小さな習慣がプロトタイプのユーザビリティテストを後で見返しやすくします。

迅速に募集する（深く考えすぎない）

速度は完璧さより重要です。統計的に完璧なサンプルを目指すのではなく、ターゲットに大まかに合うリアルな人を5〜8人、1日以内に予約するのが目標です。

最速のプールから始め、徐々に広げます。製品を求めている人（顧客、トライアル利用者、ウェイトリスト）から始め、次に最近の会話（サポートスレッド、デモ申込、メールの返信）。さらに必要なら問題が語られているコミュニティや友人の紹介（意見ではなく紹介）を使い、同じワークフローの過去の同僚やクライアントにも声をかけます。

招待は短く具体的に。セールスの電話ではないこと、人ではなく製品をテストしていることを明確に伝えます。作っているものと対象、依頼内容（ビデオか音声で20分）、やること（プロトタイプで2〜3タスクを試す）、そして小さな謝礼（ギフトカード、1か月無料、寄付など）を書きます。今日か明日の時間を2つ提示してください。

例えばKoder.aiで内部向けのCRMプロトタイプを作ったなら、乱雑なスプレッドシート利用者と既にCRMを使っている人の両方を招待します。こうした混合がパワーユーザーだけのフィードバックに偏るのを防ぎます。また親しい友人だけに頼るべきではありません。彼らは好意的に振る舞いがちです。

インセンティブは自然に感じられるものが良いです。小さな固定額は「好きなだけ払って」より効果的です。無料期間を提供するなら購入を要求しないようにします。

最後に余分を予約してください。必要人数より2人多めに集めることを目安に。ノーショーは起こります。

スクリーニング、スケジュール、同意を一度で済ませる

スクリーニング、スケジュール設定、同意を一つの流れで処理すれば時間を節約できます。本当にターゲットに見えるかを確認し、時間を予約し、録音とノート取りを事前に明確にしてから会いましょう。

軽いスクリーニングは3問で十分です：

• 現在この問題をどう解決しているか（または代わりに何をしているか）？
• 最後にそれをやったときのことを教えてください。何が起きましたか？
• 次のうちどれが自分に一番近いか：[あなたのターゲット役割]、理由は？

無駄なセッションを生む赤旗に注意します。ターゲットから大きく外れた人は自信満々なフィードバックを与えますが合致しません。過度に利害関係のある人（親しい友人、パートナー、同じことを作っている人）は個人的なアジェンダを押し付けがちです。忙しすぎる人は焦る、マルチタスクする、または来ないことがあります。

スケジューリングはタイトに：30分セッションに15分のバッファ。バッファではきれいなノートを書き、録画に名前を付け、プロトタイプをリセットします。連続で詰め込むとノートが雑になりパターンを見逃します。

同意のメッセージは短くて良い：録音の許可、ノートは製品改善に使うこと、共有時は引用を匿名化することを説明します。録音を断る選択肢を与えれば、録音なしで参加してもらってメモを取ることができます。

事前メッセージには時間、予想所要時間、アジェンダ（導入5分、タスク20分、まとめ5分）、必要なもの（ラップトップかスマホ、ログインの有無、静かな場所）を送ります。これで「モバイルで参加している」などの驚きを防げます。

セッションが脱線しないようにプロトタイプを準備する

良いインタビューでもプロトタイプが雑だと失敗します。目的は幅を見せることではなく、参加者が説明を受けずにタスクに取り組めるようにすることです。

プロトタイプは小さく保ちます。タスクに必要な画面と経路だけ残し、他は隠します。半分しか完成していない「フルアプリ」よりも、短く完結した経路の方が効果的です。

内容は現実味を持たせます。lorem ipsumを置かず、信じられる文言とデータを入れて反応を自然にします。CRMフローをテストするなら連絡先を6〜10件、名前や会社、メモを表示します。チェックアウトをテストするなら現実的な価格と配送オプションを使います。具体性のあるフェイクは汎用のままより良いです。

セッション前に観察項目を決め、毎回書き留めます：最初にクリックした場所、混乱の瞬間（言ったことと次に取った行動）、ループや戻りの場所、機能に対する言葉、欠けている情報が分かる質問。

専用のテストアカウントとリセットルーチンを用意して、参加者全員が同じ状態から始められるようにします。プロトタイプがレコードを作るなら、カートを空にする、最後に作られた項目を削除する、ホームに戻す、ログアウトして再ログインする、といった簡単なチェックリストを用意します。

録画できるなら記録し、タスク、観察（何が起きたか）、引用（正確な言葉）の3列テンプレートでノートを取ります。Koder.aiを使っているなら、最初のセッション前にスナップショットを取っておくと、日中に誤って変更しても戻せます。

明確なシグナルを出すタスクスクリプトを書く

良いタスクスクリプトは、参加者を試験を受けているようにさせるのではなく、自然に振る舞わせます。短く、再現可能で、ひとつのシナリオに結びつけてください。動くプロトタイプでは2〜4タスクが多く、パターンを見つけるには十分です。

まずメインのシナリオを平易に名前付けします（例：「最初のプロジェクトを設定してチームメイトを招待したい」）。次に、失敗すると痛手になる瞬間を表すタスクを選びます：初回セットアップ、重要機能の発見、意味あるアクションの完了など。

使い回せるシンプルなスクリプト

同じ構成を毎回使うと結果を比較しやすくなります：

• 導入（1分）: 「製品をテストしています。あなたをテストしているわけではありません。考えていることを声に出してください。」
• ウォームアップ（2分）: 「この製品が何を助けてくれると思いますか？」
• タスク（20-25分）: 2〜4タスクを1つずつ。
• まとめ（3分）: 簡単な評価と改善要望1つ。

各タスクの文面はボタン名や正確な経路を教えないように書きます。悪い例：「Snapshotsをクリックしてロールバックする」。良い例：「昨日の状態に戻したい。どうしますか？」

各タスクの前に「どこから始めますか？」、後に「なぜその道を選びましたか？」と短く聞きます。詰まったら「今何を探していますか？」と聞き、メニューを見たかどうかを直接聞くのは避けます。

Koder.aiでプロトタイプを作った場合は、タスクをプラットフォーム用語ではなく成果（アプリを作る、ソースコードをエクスポートする、カスタムドメインを設定する）に紐づけてください。そうすればノートがそのままビルドリクエストになります。

セッションを運営し、一貫性を保つ

すべてのセッションを同じやり方で始めます。緊張を和らげ、結果を比較しやすくします。

短いスクリプトで開きます：感謝を述べ、製品をテストしていること（人をテストしているのではない）、間違いはないことを説明します。考えていることを声に出してもらい、クリック前に期待を共有してもらいます。

タスクを一つずつ与えたら黙って見守ります。あなたの役目は、彼らがためらう場所を観察し、中立的な短い質問（「今何を考えていますか？」「何を期待していましたか？」）をすることです。教えたり、褒めたり、プロトタイプを弁護したりしないでください。

詰まったら救済する前に一押しだけ入れます。良い一押しはインターフェースではなく目標に関するものです：「次に何を試しますか？」「どこを探しますか？」。本当に1分以上詰まっているなら次に進み、それを高優先度の問題として記録します。コール中にプロトタイプを直す誘惑に耐えてください。記録して先に進みます。

機能要望は有益ですが議論しないでください。「それは何の問題を解決しますか？」とだけ聞いて、今のタスクに戻ります。

終わり方も一貫させます。好きだった点、フラストレーション点、支払うかどうか（いくらが妥当か）を聞き、次のアップデート後に再連絡して良いか確認します。

後で合成しやすいノートの取り方

良いノートは「起こったすべて」ではありません。後で仕分けできる小さな一貫した単位です。構造を統一すれば、3回目以降にパターンが見えます。

みんなで使う1つのシートを使う

観察者全員が使う1つのドキュメントやスプレッドシートを選び、タスク試行ごとに1行作り短く事実ベースのノートを書きます。シンプルなレイアウト例：

• タイムスタンプ（mm:ss）と参加者ID
• タスク番号とその時の画面
• 彼らが試したこと、期待したこと、起きたこと
• 重要な場合の引用1つ
• タグ：重大度（高/中/低）＋タイプ

タイムスタンプがあれば録画に戻って言葉を確認できます。タスク番号はフロー間の混同を防ぎます。

証拠を記録し、意見を減らす

何かがうまくいかなかったら、文脈なしでもチームが理解できる短い文にします。解釈ではなく瞬間を含めます。

例：「T2 06:14: 'Save'をクリックしたが確認が出ず、動作したかどうか尋ねた。」

信頼や混乱に関する引用はポイントを強めるために載せます（「安全かわからない」「どこから始めればいい？」）。引用は優先順位付けを容易にします。

タグは小さく保ちフィルタしやすくします：

• 重大度：high（タスクを妨げる）、med（遅らせる）、low（煩わしい）
• タイプ：confusion、trust、missing、bug

Koder.aiで作ったプロトタイプなら、ノートはプロトタイプの生成方法ではなくユーザー行動と製品挙動に集中させます。

最後のルール：ノートがチケットタイトルにできないなら、書き直してできるようにしてください。

フィードバックを正確なビルドリクエストに変える

感触や引用のままでは勢いを失います。見たことを、開発者が推測せずに動けるビルドリクエストに変えてください。

まずタスクごとに問題をグルーピングします。3人が「アカウント作成」で困ったなら、それは1つの問題であり、3つの意見ではありません。

一貫したリクエスト形式を使います：

• 問題：ユーザーができなかったこと（一文）
• 証拠：正確な観察や引用＋発生箇所
• 影響：なぜ重要か（時間の損失、混乱、離脱、誤データ）
• 提案変更：UIやフローで何を変えるか
• 受け入れチェック：次のテストでどう確認するか

「言葉や明瞭さ」の修正と「スコープ」の変更は分けます。「このボタンが何をするか分からない」はラベルや配置の修正で済むことが多く、「エクスポートやロール、承認が必要だ」はより大きなプロダクト判断です。混ぜるとチケットが肥大化します。

各問題について、今直すか、再テストか、後回しかを決めます。簡単な並べ方はユーザー影響、工数、確信度（繰り返し出たか）、次のアクション（ビルド、再テスト、保留）を割り振ることです。

Koder.aiで作業しているなら、受け入れチェックを平易な英語で書いてビルドチャットに貼れるようにすると便利です。

例：5回のインタビューが5つの実行可能なチケットになるまで

非技術系の創業者がKoder.aiでシンプルなCRMオンボーディングを作り、翌日にユーザーインタビューを実行します。ゴールは狭く：「営業担当が支援なしで“最初の取引を作る”まで行けるか」。

募集は素早く：ネットワークといくつかのローカルな営業コミュニティに短いメッセージを送り、小さなギフトカードを提供。5人の営業担当が午後の20分枠に予約します。

各セッションは同じ3タスクを読み上げます：

• 小さな連絡先リストを取り込む（CSVまたはコピー＆ペースト）
• 連絡先の1件に対して最初のディールを作り、次のステージに移す
• 明日9:00にフォローアップのリマインダーを設定する

5セッションで繰り返しの問題といくつかのブロッカーが記録されます。2人がインポートの場所を見つけられない。3人が“Reminder”を通知設定だと思ってしまう。

その日の終わりには、観察はすぐに実装可能なビルドリクエストに変わります：

• 空の状態に「Import contacts」ボタンを追加する。 受け入れ条件：最初の画面で見えること。CSVアップロードとペーストをサポート。
• 「Reminder」を全て「Follow-up」に名称変更する。 受け入れ条件：ボタン、モーダルタイトル、確認メッセージ全て更新。
• デフォルトのパイプラインを自動作成する（3ステージ）。 受け入れ条件：新規アカウントに「New, Contacted, Won」があり、後で編集可能。
• 「Create deal」フォームにインラインヘルプを追加する。 受け入れ条件：「Deal name」の下に例文が1行表示され、空白送信が減る。
• 各タスク後に次のステップを示す成功バナーを表示する。 受け入れ条件：インポート後に「Create your first deal」を提案、ディール後に「Set a follow-up」を提案。

ポイントはこれです：タスクを一貫させ、繰り返しのパターンを見つけ、チケットを当日中に実装できるくらい明確に書くこと。

インタビューを無駄にするよくある落とし穴

多くの悪い結果はプロトタイプ自体ではなく、いくつかの小さなミスから生まれます。

フィードバックを良く見せてしまう落とし穴

「これで分かりますよね？」のような誘導質問は丁寧な同意を引き出します。中立的な「これが何をすると思いますか？」を使い、黙って待ちます。

一度にあれこれ試すと表面的なコメントと弱いシグナルになります。2〜3のコアフローに絞ってください。

途中でスクリプトを変えると比較が壊れます。新しいアイデアはバックログに置き、タスクは安定させます。

雑なノートも静かな失敗です。記憶に頼ると面白い部分だけ覚えて痛い部分を忘れます。彼らが詰まった正確なステップと次に試したことを書き留めてください。

現実チェック：参加者が「良さそう」と言っても次のボタンを見つけるのに90秒かかっているなら、行動がデータです。褒め言葉はノイズです。

結果を解釈するときの落とし穴

一つの強い意見が計画を決めてしまうことがあります。強い意見は仮説として扱い、複数セッションで同じ問題が出るまで確信しないでください。

大きな修正をしたらすぐに再テストしてください。短いセッション2回でも修正が効いたかを確認できます。

すぐ使えるチェックリストと次のステップ

最初のコールを予約する前に基本を固めます：

• 今回のラウンドのゴール（1文）
• ターゲットユーザープロファイル（誰のためか、誰ではないか）
• スクリーナー質問＋募集計画
• タスクスクリプト（2〜4タスク）＋各タスクのフォローアップ質問1つ
• プロトタイプのリセット計画（初期状態、テストデータ）
• 録画方法（バックアップ含む）と同意文
• ノートテンプレート（課題、引用、重大度、証拠）

各セッションの直後に3分チェックを行います：上位3つの問題と1つの驚きを書き留めます。名指しできないなら、タスクが広すぎるかノートが曖昧です。

同日中に生ノートを決断に変えます。似た問題をグループ化し、最も重要なものを選び、次に変えることを定義します。

同日ラップアップ（20分）

• パターン：少なくとも2回見たこと
• 優先順位：最初に直すトップ3
• 次のビルドステップ：各問題を解決する最小の変更

修正を出したら72時間以内に再テストをスケジュールします。短い3セッションでも変更が効いたか確認できます。

もしKoder.aiで反復しているなら（koder.ai）、Planning Modeは所見を「Xを変えてユーザーがZなしでYできるようにする」のようなスコープされたタスクに書き直すのを助け、スナップショットは安定版を失わずに素早く修正を試すのに便利です。