ヒアリングで「何を聞けばいいか」が分からない
業務アプリやシステムを作ろうと決めたものの、いざ現場に話を聞く段になると 「何から聞けばいいのか分からない」「聞いたつもりでも、あとから足りないことに気づく」―― こうした悩みは、開発を発注する側でも、社内で仕様をまとめる担当者でも非常によく起こります。
業務アプリ開発の成否は、実は完成後のプログラムの出来よりも、 最初のヒアリングでどれだけ現場の実態を引き出せたかで大きく決まります。 ここで聞き漏らした内容は、後工程で必ず「手戻り」となって跳ね返ってきます。
📌 ヒアリング不足でよく起きること
- 完成してから「この画面、現場ではこう使わない」と言われて作り直しになる
- 例外パターン（キャンセル・訂正・特急対応）を聞いておらず、運用初日に破綻する
- 誰がどこまで見られるか（権限）を決めておらず、公開後に情報漏えいの不安が出る
- 紙やExcelの「暗黙のルール」が反映されず、現場が二重管理を続ける羽目になる
手戻りのコストは、後工程ほど跳ね上がる
ソフトウェア開発の世界には「要件定義で見つかれば1の修正コストが、 設計段階では5、開発段階では10、リリース後では100になる」という経験則があります。 正確な数字は現場によって違いますが、問題の発見が遅れるほど修正が高くつくという傾向は、 小さな業務アプリでも同じように当てはまります。
ヒアリングは、この「後で高くつく問題」を、まだ紙とペンで直せるうちに見つけるための作業です。 逆に言えば、ヒアリングの質問リストが甘いと、その甘さがそのまま開発後半のトラブルとして表面化します。
同じ「言い忘れ」でも、見つかる段階が遅いほど直すコストは大きくなる（イメージ）
5つの分野から、必ず押さえる20の質問
闇雲に質問しても抜け漏れが出ます。ヒアリングは ①業務の全体像 ②扱うデータ ③画面と操作 ④権限と運用 ⑤例外への対応 という5つの分野に分けて聞くと、網羅性が一気に上がります。以下、分野ごとに4問ずつ、 合計20問を「なぜ聞くのか」とセットで紹介します。
- この業務は1日（1週間・1か月）に何件くらい発生しますか？件数によって、必要な画面の作り方や検索機能の重要度が変わります。
- 今はどんな流れで進めていますか？最初から最後まで教えてください。実際の手順を追うと、アプリ化すべき箇所と残す箇所が見えてきます。
- この業務に関わる人は誰ですか？部署や役割も教えてください。登場人物が権限設計・通知設計の土台になります。
- 今いちばん困っている・時間がかかっているのはどこですか？最優先で解決すべきポイントを最初に固定できます。
- この業務で記録・入力している項目をすべて教えてください。項目の抜けは、後から「その欄がない」という手戻りの元になります。
- 必ず入力する項目と、空でもいい項目はどれですか？必須項目の設計が、入力のしやすさと精度を左右します。
- 過去のデータは何年分くらい残しておく必要がありますか？保存期間は容量・検索・法令対応の判断に関わります。
- 今あるExcelや紙のデータを、新システムに移す必要はありますか？データ移行の有無で、初期の作業量が大きく変わります。
- 入力はパソコンとスマホ、どちらで行いますか？場所はどこですか？現場での入力ならスマホ最適化が必須になります。
- 1件の入力にかけられる時間はどれくらいですか？忙しい現場では、入力項目を絞る判断材料になります。
- よく検索・絞り込みする条件は何ですか？（日付・担当・ステータスなど）検索軸を先に決めると、一覧画面の設計が固まります。
- この業務でよく間違える・迷う操作はありますか？ミスが起きやすい箇所は、入力チェックや選択式で予防できます。
- この情報を見ていい人・編集していい人は誰ですか？権限を最初に決めないと、公開後に情報漏えいの不安が残ります。
- 承認や確認が必要な操作はありますか？（誰が承認しますか？）承認フローの有無で、画面数と通知設計が変わります。
- 担当者が休み・退職したとき、業務はどう引き継いでいますか？属人化の実態が分かり、共有の仕組みに反映できます。
- 誰かに知らせる必要がある場面はありますか？（通知・メール・アラート）通知は多すぎても少なすぎても失敗するので、最初に整理します。
- キャンセル・変更・訂正が発生したとき、どう処理していますか？例外処理は見落とされがちで、運用初日に必ず必要になります。
- 「いつもと違う」イレギュラーな依頼は、どのくらいの頻度でありますか？例外が多い業務は、柔軟性を持たせた設計が必要です。
- 過去に大きなトラブルやクレームになったケースはありますか？失敗事例には、防ぐべきポイントが凝縮されています。
- 繁忙期や締め日など、特に負荷が高くなる時期はいつですか？ピーク時を想定しておくと、実運用に耐える設計になります。
💡 質問のコツ
「Yes / No」で終わる質問より、「どうやっていますか？」「なぜそうしているのですか？」と 手順や理由を語ってもらう聞き方のほうが、暗黙のルールを引き出せます。 また、口頭だけでなく、実際に使っている紙やExcelの現物を見せてもらうと、 言葉にならない工夫まで拾えます。
同じ時間をかけても、成果はこれだけ違う
| 観点 | 成果につながるヒアリング | もったいないヒアリング |
|---|---|---|
| 聞く相手 | ◎ 実際に手を動かす現場担当者 | △ 管理職だけに聞いて終わる |
| 聞き方 | ◎ 手順・理由を語ってもらう | △ Yes/Noで確認するだけ |
| 資料 | ◎ 現物の紙・Excelを見せてもらう | △ 口頭説明だけで進める |
| 例外対応 | ◎ キャンセル・訂正まで確認 | △ 通常パターンだけ聞く |
| 記録 | ◎ その場でメモを見せて認識合わせ | △ 記憶頼りで後から食い違う |
ヒアリングを成果に変える4ステップ
ひとつ選ぶ
深く聞く
聞き取る
現物を見せてもらう
認識合わせ
ズレを潰す
再確認
認識のズレを最終確認
特に効果が大きいのが最後のステップです。言葉のヒアリングだけでは、 発注側と現場側で頭に描いている画面が微妙に違っていることがよくあります。 早い段階で「動く試作品」を見せて確認すると、 「思っていたのと違う」を紙のうちに、あるいは作り込む前に発見できます。
丁寧に聞いた場合と、省いた場合の差
- 完成後に「現場では使わない機能」が判明する
- 例外処理が抜けていて運用初日に止まる
- 仕様変更が繰り返され、費用と期間が膨らむ
- 現場が納得せず、結局元のやり方に戻る
- 本当に必要な機能に絞って開発できる
- 例外パターンも織り込み、初日から安定して回る
- 手戻りが減り、費用と期間が読みやすくなる
- 現場が「自分たちの業務に合っている」と定着する