分類：実践記事 › PoC・MVPの進め方
画面名を教えない課題を作る
「検索ボタンを押してください」ではなく、「来週使える会議室を探してください」と目的を伝えます。操作方法を指定すると、その画面の分かりにくさが隠れてしまいます。対象者は、想定する業務や状況に近い人を選びます。
助けた場面も記録する
進行役はすぐ説明せず、どこを見ているか、何を期待しているかを尋ねます。途中で支援した場合は、どの説明が必要だったかを残します。参加者の能力を評価する場ではなく、製品側の問題を調べる場であることも伝えます。
問題を影響で並べる
好みの違い、時間がかかる問題、仕事を完了できない問題を分けます。一人が強く希望した機能を即座に追加するより、複数の場面で詰まる原因を優先します。少数のテスト結果を市場全体の利用率として扱わないでください。
修正後も同じ目的で確認する
問題、仮説、修正、再確認の結果を記録します。ボタンの色だけでなく、用語や業務の流れそのものが原因の場合もあります。操作の改善と、顧客が対価を払うかの検証は別に進めます。
Otsumuに相談できること
この記事の内容を自社の状況にあてはめて考えたいときの、関連サービスです。
この記事のテーマに最も近い支援は、MVPの範囲設計・要件定義支援です。
- 仮説から逆算して、作らない範囲を決める
- 引き継げる軽量な仕様書にまとめる
- リリース前の確認と公開後の判断まで伴走
まずはAIツール診断で、状況をお聞かせください。
この記事のテーマに近い開発メニューは、テスト・品質保証（QA）支援です。
- 事業で重要な操作から、テストの範囲を決める
- 検収基準と不具合管理を、発注側でそろえる
- テスト自動化まで見据えた設計も相談できる
参考資料と編集について
zigyo.ai の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日 2026.09.19