2025年11月12日·1 分
48時間で動くプロトタイプを使ったユーザーインタビュー
48時間で動くプロトタイプを使ったユーザーインタビューを計画する：素早く参加者を集め、タスクスクリプトを作成し、メモを取り、フィードバックを明確な開発要件に変える方法。
48時間で動くプロトタイプを使ったユーザーインタビューを計画する：素早く参加者を集め、タスクスクリプトを作成し、メモを取り、フィードバックを明確な開発要件に変える方法。
動くプロトタイプは多くの議論をすばやく終わらせます。誰かが実際のタスクを実行しようとすると、彼らがどうするかを推測するのをやめて、実際に何をするかを見ることができます。だから荒削りでも、動くプロトタイプを使ったユーザーインタビューはチャットでの議論に勝ります。
スコープを絞れば、3〜6回のセッションで多くを学べます。完璧な統計は得られませんが、今週直せる繰り返しのパターンは見つかります。
48時間あれば、人がどこでつまずくか・戻るか、どのラベルが混乱を招くか、最初に何を試すか（何を無視するか）、いつフローを信頼するのに情報が足りないと感じるか、価格や権限、進行の保存など疑念を生む瞬間を確実に発見できます。
このやり方は大規模なリサーチや長いアンケート、手当たり次第の探索を避けます。目的は市場全体をマッピングすることではなく、重要なフローひとつにおける最大の摩擦を取り除くことです。
誰かをスケジュールする前に、単一の学習ゴールを定義してください。シンプルなフォーマットが効果的です：「初めてのユーザーがY分以内にXを助けなしでできるか？」 たとえばシンプルなCRMなら：「新規ユーザーが連絡先を追加し、タグ付けして再度見つけられるか？」のように。
もしKoder.aiのようなツールで素早くプロトタイプを作ったなら、ゴールは変わりません：ひとつのフローを選び、実際の人が試すのを見て、何を変えるべきかを正確に記録する、という点です。
48時間ラウンドが機能するのはスコープを小さくするからです。特定のユーザータイプと、彼らが既に理解しているシナリオを一つ選んでください。オンボーディング、価格、設定、エッジケースを同じセッションで扱おうとすると、証拠ではなく意見だらけになります。
一文のゴールを書きます：「初めてのフリーランスデザイナーが、3分以内に請求書を作成して送れるか？」というように。これで誰が対象で、何をする必要があり、「良い」とは何かが分かります。
誰にも会う前に何を測るかを決めておきます。セッション中に見やすくシンプルに保ってください。多くのチームにとって、それは速度（完了時間）、摩擦（どれだけつまずくかや「次は？」と聞く回数）、ナビゲーションの問題（ためらいや読み直し、戻る動作）、信頼シグナル（支払い、プライバシー、エラーへの不安）の組み合わせです。
次に、ラウンドの終わりまでに答えたい3〜5の質問を書きます。例：
できるからといって延々とインタビューを続けないでください。いつ止めるかを前もって決めておき、作る方に戻れるようにします。実用的なルール：5セッションで止める、または同じ上位2つの問題が3回連続で出たら早めに止める、など。
例：5人中3人が「Create invoice」が「Billing」の下に隠れて見つけられなければ、ラベルを変える、入口を移す、そしてその変更を再テストするという明確なビルドリクエストがあります。
募集、準備、実行、合成を短いスプリントとして扱えば、2日間で有用なユーザーインタビューを回せます。目安は3〜5セッション。3が最小で、5はパターンを示すことが多いです。
現実的な計画例：
募集が遅いなら待たないでください。スコープを減らし、利用可能な時間を増やします。早朝や夜の枠を増やす、セッションを15分に短縮する、あるいはターゲットに近い身近な層から募集するなどです。
整理のために、最初のコール前に小さなフォルダ構成を作っておくと便利です：
01_Recruiting02_Recordings03_Notes04_Synthesis05_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タスクが多く、パターンを見つけるには十分です。
まずメインのシナリオを平易に名前付けします（例：「最初のプロジェクトを設定してチームメイトを招待したい」）。次に、失敗すると痛手になる瞬間を表すタスクを選びます：初回セットアップ、重要機能の発見、意味あるアクションの完了など。
同じ構成を毎回使うと結果を比較しやすくなります：
各タスクの文面はボタン名や正確な経路を教えないように書きます。悪い例：「Snapshotsをクリックしてロールバックする」。良い例：「昨日の状態に戻したい。どうしますか？」
各タスクの前に「どこから始めますか？」、後に「なぜその道を選びましたか？」と短く聞きます。詰まったら「今何を探していますか？」と聞き、メニューを見たかどうかを直接聞くのは避けます。
Koder.aiでプロトタイプを作った場合は、タスクをプラットフォーム用語ではなく成果（アプリを作る、ソースコードをエクスポートする、カスタムドメインを設定する）に紐づけてください。そうすればノートがそのままビルドリクエストになります。
すべてのセッションを同じやり方で始めます。緊張を和らげ、結果を比較しやすくします。
短いスクリプトで開きます：感謝を述べ、製品をテストしていること（人をテストしているのではない）、間違いはないことを説明します。考えていることを声に出してもらい、クリック前に期待を共有してもらいます。
タスクを一つずつ与えたら黙って見守ります。あなたの役目は、彼らがためらう場所を観察し、中立的な短い質問（「今何を考えていますか？」「何を期待していましたか？」）をすることです。教えたり、褒めたり、プロトタイプを弁護したりしないでください。
詰まったら救済する前に一押しだけ入れます。良い一押しはインターフェースではなく目標に関するものです：「次に何を試しますか？」「どこを探しますか？」。本当に1分以上詰まっているなら次に進み、それを高優先度の問題として記録します。コール中にプロトタイプを直す誘惑に耐えてください。記録して先に進みます。
機能要望は有益ですが議論しないでください。「それは何の問題を解決しますか？」とだけ聞いて、今のタスクに戻ります。
終わり方も一貫させます。好きだった点、フラストレーション点、支払うかどうか（いくらが妥当か）を聞き、次のアップデート後に再連絡して良いか確認します。
良いノートは「起こったすべて」ではありません。後で仕分けできる小さな一貫した単位です。構造を統一すれば、3回目以降にパターンが見えます。
観察者全員が使う1つのドキュメントやスプレッドシートを選び、タスク試行ごとに1行作り短く事実ベースのノートを書きます。シンプルなレイアウト例：
タイムスタンプがあれば録画に戻って言葉を確認できます。タスク番号はフロー間の混同を防ぎます。
何かがうまくいかなかったら、文脈なしでもチームが理解できる短い文にします。解釈ではなく瞬間を含めます。
例：「T2 06:14: 'Save'をクリックしたが確認が出ず、動作したかどうか尋ねた。」
信頼や混乱に関する引用はポイントを強めるために載せます（「安全かわからない」「どこから始めればいい？」）。引用は優先順位付けを容易にします。
タグは小さく保ちフィルタしやすくします：
Koder.aiで作ったプロトタイプなら、ノートはプロトタイプの生成方法ではなくユーザー行動と製品挙動に集中させます。
最後のルール：ノートがチケットタイトルにできないなら、書き直してできるようにしてください。
感触や引用のままでは勢いを失います。見たことを、開発者が推測せずに動けるビルドリクエストに変えてください。
まずタスクごとに問題をグルーピングします。3人が「アカウント作成」で困ったなら、それは1つの問題であり、3つの意見ではありません。
一貫したリクエスト形式を使います：
「言葉や明瞭さ」の修正と「スコープ」の変更は分けます。「このボタンが何をするか分からない」はラベルや配置の修正で済むことが多く、「エクスポートやロール、承認が必要だ」はより大きなプロダクト判断です。混ぜるとチケットが肥大化します。
各問題について、今直すか、再テストか、後回しかを決めます。簡単な並べ方はユーザー影響、工数、確信度（繰り返し出たか）、次のアクション（ビルド、再テスト、保留）を割り振ることです。
Koder.aiで作業しているなら、受け入れチェックを平易な英語で書いてビルドチャットに貼れるようにすると便利です。
非技術系の創業者がKoder.aiでシンプルなCRMオンボーディングを作り、翌日にユーザーインタビューを実行します。ゴールは狭く：「営業担当が支援なしで“最初の取引を作る”まで行けるか」。
募集は素早く：ネットワークといくつかのローカルな営業コミュニティに短いメッセージを送り、小さなギフトカードを提供。5人の営業担当が午後の20分枠に予約します。
各セッションは同じ3タスクを読み上げます：
5セッションで繰り返しの問題といくつかのブロッカーが記録されます。2人がインポートの場所を見つけられない。3人が“Reminder”を通知設定だと思ってしまう。
その日の終わりには、観察はすぐに実装可能なビルドリクエストに変わります：
ポイントはこれです：タスクを一貫させ、繰り返しのパターンを見つけ、チケットを当日中に実装できるくらい明確に書くこと。
多くの悪い結果はプロトタイプ自体ではなく、いくつかの小さなミスから生まれます。
「これで分かりますよね？」のような誘導質問は丁寧な同意を引き出します。中立的な「これが何をすると思いますか？」を使い、黙って待ちます。
一度にあれこれ試すと表面的なコメントと弱いシグナルになります。2〜3のコアフローに絞ってください。
途中でスクリプトを変えると比較が壊れます。新しいアイデアはバックログに置き、タスクは安定させます。
雑なノートも静かな失敗です。記憶に頼ると面白い部分だけ覚えて痛い部分を忘れます。彼らが詰まった正確なステップと次に試したことを書き留めてください。
現実チェック：参加者が「良さそう」と言っても次のボタンを見つけるのに90秒かかっているなら、行動がデータです。褒め言葉はノイズです。
一つの強い意見が計画を決めてしまうことがあります。強い意見は仮説として扱い、複数セッションで同じ問題が出るまで確信しないでください。
大きな修正をしたらすぐに再テストしてください。短いセッション2回でも修正が効いたかを確認できます。
最初のコールを予約する前に基本を固めます：
各セッションの直後に3分チェックを行います：上位3つの問題と1つの驚きを書き留めます。名指しできないなら、タスクが広すぎるかノートが曖昧です。
同日中に生ノートを決断に変えます。似た問題をグループ化し、最も重要なものを選び、次に変えることを定義します。
修正を出したら72時間以内に再テストをスケジュールします。短い3セッションでも変更が効いたか確認できます。
もしKoder.aiで反復しているなら（koder.ai）、Planning Modeは所見を「Xを変えてユーザーがZなしでYできるようにする」のようなスコープされたタスクに書き直すのを助け、スナップショットは安定版を失わずに素早く修正を試すのに便利です。
目安は 3〜5 セッション。3回で大きな阻害要因が見えることが多く、5回ほどだとパターンを確認できます。もし3回連続で同じ上位の課題が出たら早めに止めて修正に戻ってください。
ユーザー、タスク、測定基準を1文で示します。フォーマットの例：「初めての**[ユーザータイプ]が[時間]以内に助けなしで[タスク]**を完了できるか？」これは観察可能な行動に集中させます。
各セッションで 2〜4 タスク を選んでください。重要な瞬間（初回セットアップや1つの意味あるアクション）を代表するタスクを成果ベースで設定すると、成功可否が分かりやすくなります。
まずは最速で手に入る層から始めます：トライアル利用者、ウェイトリスト登録者、最近のサポートスレッドやデモリクエスト。招待文は簡潔に、セールスではないこと、所要時間（例：20分）とやること（プロトタイプで2〜3タスク）を明記し、今日か明日の具体的な時間を2つ提示すると調整が早くなります。
軽めのスクリーナーは3つの質問で十分です：現在何を使っているか、最後にそのタスクをやったときの話、どの役割が近いか（理由も）。ターゲットから遠い人、過度に利害関係のある人（親しい友人、競合）、忙し過ぎる人は避けます。
録音の許可を取り、録音とノートが製品改善に使われること、引用は匿名化することを伝えます。録音を断る選択肢を用意し、それでも参加できる（代わりにメモを取る）ようにします。
タスクに必要な画面だけを残し、他は隠します。内容は本物らしく（lorem ipsumは避ける）、テスト用アカウントと簡単なリセット手順を用意して毎回同じ状態から始められるようにします。
毎回同じ導入、同じタスク、できるだけ沈黙を保つ。中立的な問いかけ（「今何を探していますか？」）を使い、教えたり擁護したりしないことで、本当にどこで失敗するかが見えます。
タスクの試行ごとに短く一貫したメモを書く：試したこと、期待したこと、起きたこと。重要なときだけ引用を一つ載せ、優先度タグ（ブロッカー、遅延、軽微）を付けると素早く優先順位を付けられます。
繰り返し出た問題を、ビルドできるリクエストに変換します。フォーマットは：問題（1文）、証拠（観察や引用＋場所）、影響（なぜ重要か）、提案変更（UIやフローの修正）、受け入れチェック（次のテストでの確認方法）。同じタスク内で問題をグループ化して扱います。