最後に起きた具体例は？
「前回この問題が起きたとき、最初に何をしましたか？」と、実際の出来事から聞く。
01 / Discovery Flow
Do not skip the middle.
Request から Solution へ直行しない。途中の問いが、正しい解決策をつくる。
01
Request
何を作ってほしい？
→02
Context
なぜ今それが必要？
→03
Workflow
今はどう進めている？
→04
Pain
どこで困っている？
→05
Root cause
本当の原因は？
→06
Impact
何がどれだけ変わる？
→07
Options
他の選択肢は？
→08
Solution
何を選ぶ？
“Fall in love with the problem, not the solution.”
02 / Ask better questions
仮説ではなく、現実を聞く。
「使いますか？」ではなく、「前回どうしましたか？」。実際の行動は、仮説より信頼できる。
避ける質問
「一括承認機能があれば便利ですか？」
聞く質問
「最後にそれが起きたとき、どう対処しましたか？」
今はどう回避していますか？
誰が、どの順番で、どのシステムを使っているか。手作業や引き継ぎも含めて把握する。
誰に、どんな影響がありますか？
頻度・時間・コスト・リスク・苛立ちのどれが大きいのかを揃える。
なぜ今、変える必要がありますか？
何もしなかった場合に起きることと、他の課題との優先順位を確認する。
該当する質問がありません。別のキーワードで試してください。
03 / Principles
Discovery の7原則
Job を理解する
機能ではなく、顧客が最終的に成し遂げたい仕事を理解する。
Design より先に Discover
Workflow、Pain、Priority、Success を整理してから解決策を考える。
Root cause を探す
症状を自動化しない。ときには、ソフトウェアより先に業務を変える。
Request を signal と見る
小さな要望の裏に、別のチーム・機会・共通課題が隠れている。
Commit しすぎない
技術的に可能でも、価値・努力・優先度・保守コストを見てから決める。
Discovery を続ける
正式な打ち合わせだけでなく、日常の会話からも顧客理解を深める。
小さく広げる
一つの価値ある改善で信頼をつくり、隣の課題へ段階的に広げる。
Remember
Understand the problem first. Design the solution second.
Quick Discovery Checklist
Meaningful なプロダクト変更を相談する前に、ここだけ確認する。
これは官僚主義ではなく、判断の質を上げるための道具。Flow に戻る ↑