個人開発アプリの最初の10人インタビュー｜売る前に「困る場面」を確かめる

個人開発アプリでは、作る技術より先に詰まることがあります。誰の、どの場面の、どれほど切実な困り事を解くのか分からないことです。

機能は増やせます。画面も整えられます。しかし、フォロワーがいてもアプリが使われるとは限りません。投稿を見てくれる理由と、アプリをダウンロードして生活へ組み込む理由は別だからです。フォロワー数を、そのまま利用意向へ読み替えないことが大切です。

公開後の利用者が自分と妻だけだったとしても、そこで「宣伝が足りない」と即断しないでください。身近な二人が使えたことと、同じ問題を抱える第三者が自分から使い続けることの間には、大きな隔たりがあります。必要なのは架空の成功談でも、買わせる営業でもありません。最初の10人との会話から、問題が実在する場面を探すことです。

この記事では、「買いますか」と聞く代わりに、相手が過去に実際に取った行動を聞く方法を紹介します。15問の質問台本、記録シート、続ける基準、打ち切る基準、あえて作らない判断まで、そのまま使える形にしました。

結論: アプリを売り込まず、相手が過去に取った行動を聞きます。10人を人数目標にせず、似た条件の人から比較できる事実を集めます。調査を始める前に、継続・修正・中止を決める打ち切り条件も用意します。

対象条件を決める → 同意を取る → 事実を聞く → 記録を比較する → 継続・修正・中止を決める

最初の10人は顧客名簿ではない

ここでいう「最初の10人」は、10件の契約を取る相手ではありません。仮説を10回ほめてもらう相手でもありません。同じ種類の場面を経験した人から、事実を集めるための最初の調査単位です。

10人に聞けば必ず正解になる、という意味でもありません。人数だけを達成目標にすると、対象がばらばらな10人を集めてしまいます。大切なのは、一つの仮説に対して似た条件の人へ聞き、共通点と相違点を比べられることです。

たとえば「予定管理に困る人」では広すぎます。学生、会社員、子育て中の家庭、店舗責任者では、予定の種類も失敗の影響も違います。次のように、人物属性より「直近の行動と場面」で絞ります。

• 直近1か月に、家族間の予定共有で二重予約や確認漏れを経験した人
• 毎週、複数の連絡手段から予定を手作業で一つへまとめている人
• 直近3か月に、写真整理を途中で諦めた経験がある人
• 月に複数回、同じ形式の報告を表計算やメモへ転記している人

公的な英国政府のサービス設計ガイドも、調査参加者は実際の利用者または利用する可能性がある人であること、対象条件には特定の経験や問題場面を使えることを案内しています。

出典: https://www.gov.uk/service-manual/user-research/find-user-research-participants

「30代」「会社員」のような属性は補助条件です。先に見るべきなのは、その問題を最近経験したか、今も何らかの手段で対処しているかです。

フォロワー数とダウンロード数を直結させない

発信を続けていると、フォロワーは最初の候補に見えます。ただし、フォローは「投稿を見てもよい」という軽い選択です。アプリの利用は、探す、入れる、権限を確認する、初期設定をする、使い方を覚えるという複数の行動を伴います。

この違いを無視すると、「フォロワーがいるのに使われない。価格か宣伝が悪い」と考えがちです。実際には、次のどこで切れているかを分けて考える必要があります。

1. その問題を経験する人へ届いていない
2. 問題はあるが、今の手段で十分に間に合っている
3. 解決したいが、アプリの使い始めに手間がかかる
4. 試したが、重要な場面で役に立たなかった
5. 一度は役立ったが、繰り返し使う場面がなかった

インタビューの役割は、この断絶の場所を探すことです。宣伝文の感想を聞くことではありません。相手が前回困ったとき、どんな順番で何をしたかを聞くと、アプリが入る余地と、入らない理由の両方が見えます。

アプリを説明する前に現行手段を聞く

会話の冒頭で画面を見せると、相手はアプリの評価者になります。「便利そう」「色がきれい」「この機能もほしい」と答えやすくなります。しかし、知りたいのは作品の感想ではなく、相手の生活にある問題です。

最初の20分は、できればアプリ名も機能一覧も出しません。先に次の順番で現行手段を聞きます。

1. 最後に問題が起きた場面
2. 問題へ気づいたきっかけ
3. そのとき実際に使った道具
4. 手順、待ち時間、やり直し
5. 結果と、その後の影響

英国政府のユーザーリサーチ入門も、利用者が何をしようとしているか、現在どうしているか、既存サービスをどう経験しているかを理解する必要があると説明しています。

出典: https://www.gov.uk/service-manual/user-research/how-user-research-improves-service-design

現行手段は競合アプリとは限りません。紙、付箋、家族への口頭確認、表計算、チャットの検索、何もしないことも立派な現行手段です。「何もしない」は、問題が弱い可能性だけでなく、解決コストが高すぎて諦めている可能性もあります。理由まで聞いて初めて区別できます。

意見より過去の具体行動を聞く

未来の質問は、相手に予想を求めます。「この機能を使いますか」「月額ならいくら払いますか」と聞かれると、相手は会話を壊さないように好意的な答えを返すかもしれません。答えがうそでなくても、将来の行動を保証しません。

代わりに、過去の一回を詳しく聞きます。

• 「普段どうしていますか」より「最後にそれをしたのはいつですか」
• 「困りますか」より「前回、何が起きましたか」
• 「時間がかかりますか」より「どこから始め、どこで終わりましたか」
• 「お金を払いますか」より「これまでに何へお金や時間を使いましたか」

記憶が曖昧なら、無理に数字を出してもらいません。「たぶん毎日」を実績として記録せず、「頻度は本人も不明」と残します。正確そうな数字を作るより、不明のまま持ち帰るほうが安全です。

価格を誘導しない

価格の話を避ける必要はありません。ただし、「500円なら買いますよね」のように答えを誘導しないことが重要です。

問題の強さは、過去に支払った金額だけでは測れません。時間を使う、家族へ確認する、複数の無料ツールを組み合わせる、失敗のリスクを受け入れる、といった行動も負担です。まず現在の負担を確認します。

その後で価格を聞く場合も、アプリの希望価格を当ててもらうのではなく、既存の選択を聞きます。

• 今の方法に費用はかかっているか
• 無料の方法を選ぶ代わりに、何分・何手かかっているか
• 過去に別の道具を試したか
• 有料の道具をやめたなら、なぜやめたか

「無料なら使う」は、問題が強い証拠ではありません。無料でも初期設定や学習には時間がかかります。相手が何を差し出してでも解決した経験があるかを見ます。

対象候補を3段階で絞る

無差別に連絡先を集めたり、面識のない人へ一斉にDMを送ったりする必要はありません。個人情報を増やさず、すでに正当に接点がある範囲から、次の3段階で候補を絞ります。

1. 問題場面を一文にする

「誰が、いつ、何をしようとして、どこで止まるか」を一文にします。

例: 「家族の予定をまとめる人が、複数の連絡から予定を転記するときに、確認漏れを防げない」

2. 経験条件を決める

年齢や職業だけでなく、最近その場面を経験したことを条件にします。

例: 「直近1か月に、家族の予定を二つ以上の手段から一つへまとめた」

3. 比較できる小さな組にする

最初から10人を一まとめにしません。まず似た条件の3人前後へ聞き、質問の意味が通じるか、同じ問題が出るかを確認します。その後、同じ条件を続けるか、意図的に異なる条件を足します。人数を埋めるために条件外の人を混ぜないでください。

参加者候補へ声をかけるときは、目的、所要時間、記録方法、任意参加であることを先に伝えます。すでにサービス利用者であっても、調査への連絡に同意していない人へ勝手に送らない設計が必要です。英国政府の参加者募集ガイドも、既存利用者へ個別調査の招待を送る前に許可を得るよう案内しています。

開始前の同意とプライバシー

小さな個人開発でも、聞き取りメモには個人情報が含まれます。名前を集めなくても、勤務先、家族構成、病歴、位置情報、具体的な出来事の組み合わせから個人を特定できる場合があります。

開始前に、少なくとも次を平易な言葉で伝え、同意を得ます。

• 誰が、何の目的で聞くのか
• 何を記録するか。録音や画面記録をするか
• 記録を何に使い、誰が見るか
• いつまで保管し、いつ削除するか
• 答えたくない質問を飛ばせること
• 途中で中止でき、同意を撤回できること

英国政府の同意ガイドは、参加が任意であること、途中で中止・撤回できること、収集するデータ、利用方法、共有先、保管期間を理解してもらう必要があると説明しています。

出典: https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research

録音は便利ですが、必須ではありません。録音しないと目的を達成できないかを先に考えます。メモだけで足りるなら、データを増やさない選択ができます。録音する場合は、録音開始前に同意を確認し、保管期限を決めます。

参加者の連絡先とインタビュー内容は分けて管理します。記録上は「P01」のような番号を使い、氏名、メールアドレス、SNSアカウントを書き写しません。画面共有では通知を切り、関係のない名前、住所、メッセージが映らないようにします。

公的なプライバシーガイドは、募集に必要な最小限の情報だけを集め、必要がなくなったら削除し、調査結果に使う抜粋は可能な限り匿名化するよう案内しています。

出典: https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy

これは法律相談ではありません。扱う情報や地域、対象者によって必要な対応は変わります。健康、子ども、金融、正確な位置情報など、影響の大きい情報を扱う調査は、個人開発の簡易インタビューとして始めず、必要な専門確認を先に行います。

そのまま使える質問台本15問

最初に「今日はアプリを売る場ではなく、現在のやり方を理解するための聞き取りです。答えたくない質問は飛ばせます」と伝えます。以下は順番どおりでなくても構いませんが、説明前に過去の行動を聞く原則は守ります。

1. このことを最後に行ったのはいつですか。 日付を正確に思い出せなければ、どんな日の前後だったかを聞きます。
2. そのとき、何を終わらせようとしていましたか。 本人の目的を、開発者の言葉へ置き換えずに記録します。
3. 最初に問題へ気づいたきっかけは何でしたか。 通知、誰かの一言、締切、失敗など、開始点を確認します。
4. その場にいた人や関わった人は誰ですか。 氏名は聞かず、本人、家族、同僚など役割だけを記録します。
5. 最初に使った道具や方法は何でしたか。 アプリ名だけでなく、紙、口頭、検索、放置も含めます。
6. そこから終わるまで、どんな順番で進めましたか。 一工程ずつたどり、途中で道具を替えた箇所を探します。
7. 途中で止まった、迷った、やり直した場所はどこですか。 「大変でしたか」と評価を迫らず、起きたことを聞きます。
8. そのとき、何を確認するために誰へ聞きましたか。 人への依存と確認待ちを把握します。
9. 終わったと判断したのは、どんな状態になったときですか。 利用者にとっての完了条件を確認します。
10. うまくいかなかった場合、何が起きましたか。 時間、再作業、機会損失、気まずさなど、実際の影響だけを聞きます。
11. 同じことは、その前にも起きましたか。直近で思い出せる別の一回はありますか。 一度限りか反復する問題かを分けます。
12. これまでに別の方法を試したことはありますか。 試した理由、やめた理由、今の方法へ戻った理由を続けて聞きます。
13. 今の方法に、お金以外でどんな手間がかかっていますか。 入力、確認、学習、待ち時間、家族への説明などを具体化します。
14. 今の方法や道具へ実際に費用を払ったことはありますか。 金額を誘導せず、払った事実と継続・解約の理由を聞きます。
15. こちらが聞かなかったことで、この場面を理解するために重要なことはありますか。 開発者の想定外を拾って終了します。

質問をすべて消化することが目的ではありません。具体的な一回が出てきたら、「その前は」「次に」「実際の画面では」「なぜそう判断したか」と掘り下げます。ただし「なぜ」は責められたように感じることがあります。「何がそうさせましたか」「そのとき何を見て決めましたか」と聞き換えると、行動をたどりやすくなります。

観察と意見を分ける

インタビュー直後は、印象が強いうちに機能案を書きたくなります。しかし、一人の「自動化してほしい」をそのまま仕様にすると、声の大きさで優先順位が決まります。

記録を次の3層に分けます。

• 観察: 参加者が話した過去の行動、見せた手順、止まった場所
• 本人の意見: 欲しい機能、好み、将来使うという予想
• 開発者の解釈: 問題の原因、解決案、優先度についての仮説

「毎回面倒そうだった」は観察ではありません。「前回は二つのチャットを検索し、紙へ写してからカレンダーへ入力した」が観察です。「一括取込が必要」は開発者の解釈です。

意見を捨てる必要はありません。列を分けるだけです。観察と混ぜなければ、あとで別の解決策を考えられます。

1人につき1枚の記録シート

次のシートを複製して使います。個人を特定する情報は書かず、分からない箇所は「不明」と記録します。

項目	記録内容
参加者番号	P01など。氏名やアカウント名は書かない
実施日	会話を行った日
対象条件	どの経験条件に合ったか
同意	目的・記録方法・利用範囲・保管期限を説明し、同意を得たか
直近の場面	いつ、どこで、何を終えようとしたか
現行手段	道具と手順を開始から終了まで書く
詰まった箇所	止まった、迷った、待った、やり直した事実
発生した影響	再作業、遅れ、断念など実際に起きたこと
反復	別の具体例が出たか。頻度が不明なら不明とする
既に試した代替	試した手段、続かなかった理由
支払った負担	実際の費用、時間、確認、学習、心理的負担
本人の意見	欲しい物、好み、将来の予想。観察と分ける
開発者の解釈	問題仮説と解決仮説。事実とは扱わない
反証	この人にはアプリが不要だと示す事実
次に確かめること	次の参加者へ追加する質問を一つだけ書く
削除予定日	連絡先、メモ、録音を削除する日

AppleのTestFlightでは、ベータ版を配布してスクリーンショットやフィードバック、クラッシュに関する追加情報を受け取れます。一方、詳細なフィードバック画面には、提供可能な場合の氏名やメールアドレスに加え、端末、OS、通信種別など複数の情報が表示されるとAppleが説明しています。ベータテストだから匿名だと思い込まず、何が収集・共有されるかを確認して参加者へ説明します。

出典: https://developer.apple.com/testflight/

出典: https://developer.apple.com/help/app-store-connect/reference/testflight/beta-tester-feedback

Google Playも、内部・限定・公開のテストで特定のグループまたはGoogle Play利用者へテスト版を提供できると案内しています。聞き取りで問題を確認する段階と、実物の操作を確かめるベータテストの段階を分けると、何を学んだかが混ざりません。

出典: https://support.google.com/googleplay/android-developer/answer/9845334?hl=en

結果を機能優先度へ戻す

10枚の記録を、要望の人気投票にしないでください。まず「場面」を横断して並べます。

1. 同じ問題場面をまとめる

言葉が違っても、開始点、現行手段、詰まり、影響が似ていれば同じ組へまとめます。逆に「予定管理」という同じ言葉でも、家庭の共有と店舗の人員配置は別の問題として扱います。

2. 証拠の強さをそろえる

強い順に並べると、判断しやすくなります。

1. 直近の具体例があり、実際の手順や失敗を説明できる
2. 別の回にも同じ行動があり、反復を確認できる
3. 既に時間や費用を使って回避している
4. 問題の感想はあるが、具体例が出ない
5. アプリを見た後の要望だけがある

下の証拠を無価値と決めるのではなく、機能決定の根拠として混ぜないことが重要です。

3. 問題と機能を一対一に結び付ける

候補機能ごとに、次を一文で書きます。

「誰が、どの場面で、今のどの手順を減らし、何が起きれば改善と判断するか」

書けない機能は保留します。「便利そう」「よくあるから」「一人が欲しいと言ったから」では優先しません。

4. 最小の確認方法を選ぶ

いきなり実装せず、紙の手順、画面案、手動代行など、仮説を確かめる最小の方法を選びます。技術的に作れるかではなく、その方法を相手が実際の場面で選ぶかを確かめます。

5. 次の判断日を決める

調査を永遠に続けないよう、次の3人または次の一巡が終わった時点で、続行、対象変更、中止のどれかを決めます。新しい機能案が出るたびに期限を延ばさないでください。

打ち切り条件を先に決める

インタビューは、続ける理由だけでなく、やめる理由を探す作業でもあります。開始前に打ち切り条件を書いておくと、作りたい気持ちに判断を引っ張られにくくなります。

次のいずれかが続くなら、いったん実装を止めます。

• 対象条件に合う人へ複数回聞いても、直近の具体的な問題場面が出ない
• 問題はあるが、現行手段で十分で、切り替える理由が見つからない
• 困ったという意見は出るが、過去の回避行動、再作業、支払いが確認できない
• 問題が一度限りで、再び使う場面が想定できない
• 解決に必要なデータが、個人開発で安全に扱える範囲を超える
• 必要な正確性や責任を、現在の体制では担保できない
• 話を聞くほど、アプリより既存の設定変更や短い手順書のほうが適切だと分かる

ここで「複数回」としているのは、万能な固定人数を作らないためです。似た条件の人へ聞いても具体例が集まらないのか、対象条件そのものが間違っているのかを分けて判断します。条件を変えたら、別の仮説として記録を分けます。

「作らない」が正解になる例

既存機能を知らないだけだった

家族の予定共有が難しいと思って聞いたところ、困り事の中心が既存カレンダーの共有設定だったとします。この場合、新しいカレンダーアプリより、設定を迷わず終える短い案内のほうが問題へ近いかもしれません。

発生頻度が低く、紙で十分だった

年に一度だけ行う作業で、紙のチェック表なら数分で終わり、失敗の影響も小さいなら、専用アプリの導入・更新・学習のほうが重くなります。作れることと、作る価値は別です。

安全に扱えない情報が必要だった

解決するには健康情報、子どもの情報、金融情報などを広く集める必要があり、保護・削除・問い合わせ対応を担えない場合があります。機能を減らして個人情報を端末外へ出さない設計へ変えるか、その問題を選ばない判断が必要です。

問題より習慣の変更が大きかった

相手が今の手段を長年使い、周囲の人も同じ流れで動いているなら、一人用の便利機能だけでは切り替わりません。導入に必要な説明や移行が、解決できる負担を上回ることがあります。

作らない判断は失敗ではありません。数週間や数か月を、使われない機能へ投入する前に止められた結果です。そこで得た「誰には不要だったか」「どの条件なら現行手段が勝つか」は、次の仮説を狭くする材料になります。

インタビューからベータテストへ進む境目

問題場面、現行手段、反復、影響が複数の記録で確認できたら、初めて解決案の確認へ進みます。ここからは、言葉ではなく実物に近い物を触ってもらいます。

AppleのTestFlightは公開前のベータ版を配布し、テスターからフィードバックを得る仕組みです。Google Playにも内部、限定、公開のテストがあります。どちらも、問題発見の代わりではありません。誰の何を確かめるかが決まった後に、操作や技術上の問題を見つける手段です。

ベータテスト前には、次の一つを明記します。

「今回は、初回登録から最初の予定共有までを一人で完了できるかを確認する」

「自由に使って感想をください」だけでは、結果を機能優先度へ戻しにくくなります。確認したい場面、成功条件、中止条件を一つに絞ります。参加者が迷ったら、すぐ説明する前に、どこを見て何を期待したかを観察します。

ベータ版でも、集める情報は最小限にします。クラッシュ報告、画面記録、アクセス解析を使うなら、送られる内容を確認し、目的と保管を説明します。不要な権限は求めず、実在する個人情報をテスト入力として使わせません。

10人を終えた後の判定表

最後に、人数ではなく証拠で判断します。

判断	証拠	次の行動
続ける	同じ条件の複数人から、直近の具体場面、反復、現行の負担が確認できた	最も小さい解決案を一つ試す
条件を狭める	問題は一部の場面だけで強く、ほかでは現行手段が勝つ	強い場面だけを対象に質問を作り直す
対象を変える	開発者が想定した人には弱いが、別の役割の人に負担が集中している	新しい対象条件として記録を分ける
保留する	具体例が少なく、頻度や影響が不明	実装せず、自然に次の場面が起きるまで待つ
作らない	現行手段で十分、安全に扱えない、導入負担が効果を上回る	判断理由を残して終了する

一番避けたいのは、10人から10個の機能要望を集め、全部を作ることです。最初の10人に聞く目的は、アプリを豪華にすることではありません。問題の境界を狭くし、作る価値がある一つと、作らなくてよい多くを分けることです。

調査結果を実装へ移すときはAI個人開発の実践手順、成果の測り方や提供範囲を考えるときはAI自動化の成果と価格ガイドへ進めます。

まとめ

個人開発アプリの最初の利用者探しは、営業件数を増やす作業ではありません。誰が、いつ、何を終えようとして、今のどこで止まるのかを確認する調査です。

アプリを説明する前に、最後に起きた具体的な一回を聞きます。未来の利用意向より過去の行動、希望価格より既に払った負担、機能の感想より現行手段を優先します。観察、本人の意見、開発者の解釈を分けて記録し、個人情報は必要最小限にします。

そして、始める前に打ち切り条件を決めます。問題が弱い、既存手段で十分、安全に扱えないと分かったら、作らない判断を選べます。最初の10人から得たいのは「売れそう」という励ましではなく、次に作る一手か、今は作らない一手を選べる証拠です。