サービスは、作り終えたところがスタートです。お客様に使ってもらい、その反応で直していくことで、PMF（プロダクト・マーケット・フィット。お客様に必要とされ、使われ続ける状態）に近づいていきます。ただ、「使ってみてください」と渡すだけでは、ばらばらな感想が少し返ってくるだけで終わりがちです。この記事では、お客様に試してもらうときに決めておくこと、渡す前の確認、指摘や追加の要望への答え方を整理し、当社がある支援先にサービスを試してもらったときの記録を紹介します。
何人に、何を見てもらうかを先に決める
お試しは、人数を増やせばよいというものではありません。使いやすさの調査で知られるNielsen Norman Groupのヤコブ・ニールセンは、使いやすさのテストは5人までにとどめ、小さなテストを何度もくり返すほうがよい、と書いています。5人の最初のテストで使いにくさの問題の85%が見つかり、15人に一度に試してもらうより、5人ずつ3回に分けるほうが結果がよい、という考え方です[1]。
この考え方から言えるのは、1回のお試しで全部を見つけようとしない、ということです。少ない人数で試してもらい、直してから、また試してもらう。そのくり返しを前提にすると、1回あたりの負担も小さくできます。
そのうえで、渡す前に次の3つを決めておくと、返ってくる反応がそろいます。
- どの順番で触ってもらうか：迷わず一通り触れる道順を用意します。
- どれくらいの時間で終わるか：相手の負担の目安を先に伝えます。
- 何を見てほしいか：見てほしい点を数個に絞ります。全部を見てもらおうとすると、どこも浅くなります。
🛠 この記事のようなプロダクト開発の課題は、ご相談ください。何をつくるかの整理から、開発、反応を見た手直しまで一緒に進めます（相談は無料）。
Trial
ある支援先に渡したお試しの案内
ここからは当社の記録です。当社では、ある支援先にサービスを試してもらうとき、10の手順に沿って30〜40分で一通り触れる案内を渡しました。
見てほしい点は、次の4つに絞りました。
- 言葉づかい
- 項目の過不足
- 順番
- 知らせの量
この4つは、作った側がいくら確かめても判断しにくい点です。一般に、次のようなずれが見つかります。
- 言葉づかい：作った側の呼び方と、相手の職場での呼び方が違う。同じものを別の言葉で呼んでいる。
- 項目の過不足：業務で必ず書く項目が無い。逆に、だれも使わない項目を入力させている。
- 順番：実際の仕事の流れと、画面の並びが前後している。
- 知らせの量：メールや画面の知らせが多すぎて読まれない。あるいは、知りたいときに知らせが来ない。
手順と時間と見る点が決まっていると、試す側は「何を言えばよいか」に迷わずに済みます。返ってくる指摘も、この4つの観点で並べて読めます。
Before Handing
渡す前に、自分たちで確かめること
当社では、渡す前に全部の画面を確かめました。見たのは「動くか」「言葉が分かるか」「間違った入力をはじくか」の3つです。直した所には、元に戻すと失敗する確認用のテストを足しました。
3つ目の「間違った入力をはじくか」は、公的なガイドラインでも求められている点です。デジタル庁のユーザビリティガイドラインは、入力フォームなどで、入力内容の確かめ（バリデーション）や入力を助ける機能を確実に用意するよう定めています[2]。ウェブの使いやすさの国際的な基準であるWCAG 2.2でも、入力の誤りを自動で見つけた場合は、どの項目が誤りかを示し、その内容を文字で伝えることが求められています。直し方が分かっている場合は、それも示すよう定めています[3]。
一般に、作った側で先に確かめておくと、相手の時間が「動かない」「意味が分からない」といった指摘に使われずに済みます。そこが片付いていれば、相手は言葉づかいや順番といった、使う人にしか分からない点に集中できます。
| 確かめる人 | 見る点 | 見つかりやすいこと |
|---|---|---|
| 作った側（渡す前） | 動くか・言葉が分かるか・間違った入力をはじくか | 止まる画面、意味の通らない文言、変な入力が通ってしまう所 |
| 試してもらう相手（手順つきの案内） | 言葉づかい・項目の過不足・順番・知らせの量 | 業務の言葉とのずれ、足りない項目、手順の前後、知らせの多すぎ・少なすぎ |
| 試してもらう相手（自由に触ってもらう） | 決めない | 思わぬ使い方。ただし指摘の観点がばらつき、比べにくい |
| 開発会社に任せる | 渡す前の確認から、指摘を受けた手直しまで | 作った側の確認を厚くできる。ただし業務の言葉が合っているかは、使う人にしか判断できない |
作ったあとに使ってもらい、直していくところまで一緒に進められます。お試しの準備の段階からご相談ください。
無料で相談するResponse
指摘の一覧への答え方
当社の記録では、案内を渡してから約2週間後に、支援先から指摘の一覧が返ってきました。当社では翌日、回答を「質問で返さずに、こう直すと言い切る」形に整え、その日のうちに全部を直して本番に反映しました。
指摘に質問で返すと、相手はもう一度考えて書き直すことになり、やりとりが一往復増えます。「こう直します」と言い切っておけば、相手は違うときだけ指摘すれば済みます。直したあとに本番で確かめてもらえるので、次のお試しの材料にもなります。
一般的なやり方として、指摘の一覧には次の3つを並べて返すと、相手が確かめやすくなります。
- いただいた指摘（相手の言葉のまま）
- どう直すか（言い切りの1文）
- 直した場所と、本番に反映したかどうか
たとえば「この項目名の意味が分からない」という指摘なら、「この項目の意味は何ですか？」と聞き返すのではなく、「項目名を、職場で使っている呼び方に合わせて〇〇に変えます」と書きます。こちらの読み違いがあれば、相手はその1行を直すだけで済みます。言い切るためには、指摘の裏にある業務を想像する必要があるので、返す側の手間は増えます。その分、相手の手間は減ります。
Lessons
つまずいた所：「送りました」と出たのに届いていなかった
当社の記録では、試してもらう中で、相手がメールアドレスを打ち間違え、送信が届かなかったのに、画面には「送りました」と出ていたことがありました。当社では、届かなかったことを画面に出す機能を足しました。
メールは、送る仕組みが受け付けた時点と、相手に届いた時点が別です。メールの送り方を定めた技術の決まり（RFC 5321）でも、いったん受け付けたメールが届けられないと後で分かった場合は、「届けられなかった」という知らせを作って送り主に返さなければならない、とされています[4]。つまり、届かなかったことは後から分かるのが普通です。
メール配信サービスの一つであるTwilio SendGridの説明書でも、メールの状態は分けて扱われています。「処理済み（Processed）」は受け付けて配信できる状態、「配信済み（Delivered）」は相手側のメールサーバーへの配信に成功した状態、「バウンス（Bounce）」は相手側のサーバーがその宛先へのメールを受け付けなかった状態です[5]。画面に「送りました」と出すなら、それがどの段階のことかを決めておく必要があります。
知らせ方も大切です。WCAG 2.2は、処理の結果などの状態の知らせを、画面の操作を邪魔せずに利用者へ伝えられるようにすることを求めています[3]。Nielsen Norman Groupも、誤りの知らせは目に留まりやすく、どうすればよいかが分かる形で出すよう勧めています[6]。届かなかったことが画面の片すみに小さく出るだけでは、相手は気づけません。
Requests
追加の要望は、いったん保留にしてから選ぶ
当社の記録では、追加の要望21件をいったん保留にし、サービスの目的を見直してから、その方向に合う分だけを進めました。
要望への返し方にも決まりを置いています。大きい・重いことを先送りの理由にせず、「進められます。そのために次を教えてください」と返します。
お試しのあとは、要望が一気に集まります。その場で一つずつ受けると、サービスが何のためのものかがぼやけていきます。いったん全部を保留の一覧に入れ、目的に照らして選ぶ順番にすると、断る場合も進める場合も理由を説明しやすくなります。
Next Step
お試しのあとに見るもの：言われたことより、続けて使われているか
お試しで返ってくる指摘は、言葉づかいや順番といった「使い始めのつまずき」が中心になります。これを直すのは大事ですが、それだけではPMFに近づいたかどうかは分かりません。PMFは「必要とされ、使われ続ける状態」なので、見るべきは、お試しが終わったあとも相手がそのサービスを使い続けているかどうかです。
そのため、お試しを何回かくり返すときは、指摘の一覧とは別に、次のような点を毎回同じ形で書き留めておくと、回を追って比べられます。
- 案内が終わったあとも使われたか：お試しの期間が過ぎても、相手が自分から開いているか。
- どの手順で止まったか：案内のどこで手が止まり、どこを飛ばしたか。
- 使われなかった機能：作ったのに一度も触られなかった画面や項目はどれか。
- 指摘の種類の変化：前の回と比べて、言葉や順番の指摘が減り、業務の中身についての指摘に移ってきているか。
使われなかった機能は、次に削る候補にもなります。足す話ばかりでなく、削る話もできるようにしておくと、追加の要望を選ぶときの物差しにもなります。お試しは「直す所を集める場」であると同時に、「このサービスが何のためにあるか」を確かめ直す場でもあります。
Checklist
お試しを渡す前のチェックリスト
- 人数と回数：少人数で試してもらい、直してまた試す前提にしたか。
- 案内：手順の数と、かかる時間の目安を書いたか。
- 見てほしい点：数個に絞って、案内の最初に書いたか。
- 渡す前の確認：全部の画面で「動くか」「言葉が分かるか」「間違った入力をはじくか」を見たか。
- 知らせの言葉：「送りました」「保存しました」などが、本当にその段階を指しているか。
- 返し方：指摘には言い切りで答え、追加の要望はいったん保留の一覧に入れる段取りがあるか。
Sources
参考にした資料
- Nielsen Norman Group, Jakob Nielsen「Why You Only Need to Test with 5 Users」（2000年3月）
- デジタル庁「DS-670.1 ユーザビリティガイドライン」4.2.3 バリデーション等の確実な実施（2026年6月改定）
- W3C「Web Content Accessibility Guidelines (WCAG) 2.2」達成基準3.3.1・3.3.3・4.1.3（2024年12月）
- IETF「RFC 5321 Simple Mail Transfer Protocol」（2008年10月）
- Twilio SendGrid「Event Webhook Reference」公式ドキュメント
- Nielsen Norman Group「Error-Message Guidelines」（2023年5月）
FAQ
お客様に試してもらうときによくある質問
PMFとは何ですか？
プロダクト・マーケット・フィットの略で、お客様に必要とされ、使われ続ける状態のことです。試してもらって直すことをくり返して、この状態に近づけていきます。
何人くらいに試してもらえばよいですか？
一度に大勢より、少人数で試してもらい、直してからまた試してもらうほうが効率的だという考え方が知られています。上で紹介したNielsen Norman Groupの記事では、5人ずつ複数回に分けることが勧められています。
試してもらう前に、何を確かめればよいですか？
上の記録では、全部の画面について「動くか」「言葉が分かるか」「間違った入力をはじくか」を確かめてから渡しました。作った側で先に確かめておくと、相手は使う人にしか分からない点に集中できます。
指摘が多く返ってきたら、どう答えればよいですか？
一つずつ「こう直す」と言い切る形で答えると、相手は違うときだけ指摘すれば済みます。質問で返すと、やりとりの回数が増えます。
追加の要望は、全部受けたほうがよいですか？
サービスの目的に合うかで決めます。上の記録では、追加の要望をいったん保留にし、目的を見直してから合う分だけを進めました。
サービスは、お客様に使ってもらい、その反応で直していくことで育っていきます。少ない人数で試してもらい、見てほしい点を絞り、渡す前に自分たちで確かめ、指摘には言い切りで答える。そのくり返しで、使われ続ける状態に近づけていきます。当社では、開発したプロダクトの運用保守や機能の追加まで、続けてご相談いただけます。
