開発会社から「要件定義のヒアリングをさせてください」と言われたとき、何を聞かれるのか、こちらは何を準備すればいいのか、誰を出席させるべきか、と不安になる方は多いはずです。ヒアリングは開発会社が主導する場なので、つい受け身で臨みがちです。
しかし、要件定義のヒアリングの成否は、実は発注側の準備で半分以上が決まります。当日その場で思い出しながら答えるのと、業務情報を整理して臨むのとでは、出来上がる要件定義書の精度がまるで違うからです。準備不足のまま進むと、後から「言い忘れていた」「現場と違う」が噴き出し、手戻りにつながります。
この記事では、要件定義のヒアリングや打ち合わせで何を聞かれるのか、発注側が用意しておくべき情報、誰を参加者として出すか、当日の進め方までを、発注側の目線で解説します。次の打ち合わせの準備にそのまま使える形でまとめました。
この記事のポイント
- 要件定義のヒアリングの成否は発注側の事前準備で大きく決まる
- 聞かれるのは業務の流れ・課題・優先順位で、答えるのは発注側にしかできない
- 参加者は取りまとめ役だけでなく現場を知る利用部門と決裁者を揃える
- その場で即答できない質問は持ち帰り、宿題として期限を切って返す
目次
要件定義のヒアリングとは何のための場か
ヒアリングの目的と全体の流れ
要件定義のヒアリングとは、開発会社が発注側から業務の実態や要望を聞き取り、システムに落とし込むための情報を集める場です。打ち合わせやセッションと呼ばれることもありますが、やることは同じで、発注側の頭の中にある業務知識をベンダーに渡す作業だと考えると分かりやすくなります。
全体の流れは、開発会社が質問を投げかけ、発注側が業務や要望を答え、その内容を開発会社が整理して要件定義書にまとめる、という順序で進みます。1回で終わることは少なく、初回で全体像を聞き、2回目以降で詳細を詰めるなど、複数回に分けて行うのが一般的です。プロジェクトの規模にもよりますが、数週間にわたって数回の打ち合わせを重ねるイメージを持っておくと、スケジュールの見通しが立てやすくなります。
ここで誤解しがちなのが、ヒアリングは開発会社の仕事だから任せておけばよい、という考えです。質問するのは開発会社ですが、答えを持っているのは発注側だけです。要件定義の役割分担を整理した要件定義書は誰が作るかの解説でも触れているとおり、業務情報の提供は発注側にしかできない役割です。
ヒアリングで聞かれる主な内容
何を聞かれるか分かっていれば、準備もしやすくなります。要件定義のヒアリングで問われるのは、おおむね次のような内容です。
- システム化で解決したい課題と、実現したい状態
- 現状の業務の流れと、関わる人・部署
- 現場で起きている困りごとや非効率な作業
- 例外的な業務（締め処理、特殊な承認、繁忙期の対応など）
- 絶対に外せない要件と、あれば良い程度の要望の違い
- 予算の上限と、いつまでに使い始めたいかの希望
これらは技術的な質問ではなく、すべて自社の業務に関する質問です。専門知識がないと答えられないものではなく、むしろ業務を一番知っている発注側にしか答えられないものばかりだと分かります。
開発会社によっては、これらの質問をまとめたヒアリングシートを事前に渡してくれることもあります。シートがあると論点が整理しやすい一方、項目が業務と合わずに埋めにくいこともあります。その場合は無理に全部埋めず、答えにくい項目こそ当日の対話で深掘りするテーマとして残しておくと、ヒアリングが有意義になります。質問の意図が分からないときは、遠慮なく「これは何のために聞いていますか」と確認して構いません。背景が分かると、的確に答えられるようになります。
準備不足のヒアリングが招く失敗
準備せずにヒアリングへ臨むと、典型的な失敗が起こります。その場の思いつきで答えてしまい、後から「やっぱり違った」と要件が二転三転するケースです。ベンダーは聞いた内容で要件定義書を作るため、発注側の回答がぶれると、文書もぶれます。
もう一つよくあるのが、現場を知らない人だけがヒアリングに出てしまうパターンです。取りまとめ役が想像で答えた結果、現場の実態と違う要件が固まり、テスト段階で「この業務が回らない」と発覚します。この時点での手戻りは、設計のやり直しと追加費用に直結します。
逆に言えば、業務情報を整理し、適切な人を出席させるだけで、こうした失敗の多くは防げます。準備が9割と言われるのは、このためです。
もう一つ見落とされがちなのが、開発会社へ丸投げしてしまう失敗です。「プロなんだから、うまく聞き出してくれるだろう」と期待して受け身でいると、開発会社は表面的な情報しか得られません。開発会社はシステムの専門家ですが、あなたの会社の業務には詳しくないため、こちらが積極的に語らないと深い要件は出てこないのです。ヒアリングは尋問ではなく、業務を一緒に整理する共同作業だと捉えると、準備にも前向きになれます。
要件定義のヒアリングに向けた準備と進め方
事前に用意しておきたい情報と資料
ヒアリングの前に、自社の業務を語るための材料を揃えておきましょう。完璧な文書である必要はなく、箇条書きのメモや現行の帳票で十分です。大事なのは、口頭で思い出すのではなく、見せられる形にしておくことです。
ヒアリング前に用意したい資料
- 現状の業務の流れを書き出したメモ（手書きでも可）
- 今使っている帳票・Excel・画面のスクリーンショット
- 解決したい課題と、その優先順位
- 関係する部署・担当者の一覧
- 予算の上限と希望する稼働時期
特に効くのが、今使っている帳票や画面の実物を見せることです。言葉で業務を説明するのは難しくても、実物があれば「これをこの順番で入力していて、ここが手間」と具体的に伝わります。要望の優先順位の付け方に迷うときは、誰がどう使うかというペルソナとユーザーストーリーの考え方で整理すると、必須と任意の線引きがしやすくなります。
準備でもう一つ意識したいのが、社内の意見をある程度すり合わせておくことです。ヒアリングの場で部署ごとに言うことが食い違うと、開発会社はどれを要件にすべきか判断できず、議論が止まります。事前に関係者へ「こういう打ち合わせがあるが、譲れない点はあるか」と一声かけておくだけで、当日の発言がまとまり、後からの蒸し返しも減ります。完璧に意見を統一する必要はありませんが、対立しそうな論点を把握しておくと、当日その場で「ここは持ち帰って社内調整します」と切り分けやすくなります。
誰を参加者として出すべきか
ヒアリングの質は、誰が出席するかで大きく変わります。取りまとめ役の担当者だけで臨むと、現場の実態や経営判断が抜け落ちます。最低でも次の3つの立場を揃えるのが理想です。
| 立場 | 持っている情報 | 役割 |
|---|---|---|
| 取りまとめ担当 | プロジェクト全体・進行 | 論点を整理し、宿題を管理する |
| 利用部門の担当者 | 現場の業務・例外・使い勝手 | 実態に即した要望を伝える |
| 決裁者・予算責任者 | 投資判断・優先順位 | 譲れない条件と予算を示す |
全員が毎回出る必要はありません。全体像を聞く初回は決裁者にも入ってもらい、業務の詳細を詰める回は利用部門中心にするなど、回ごとに必要な人を呼ぶと負担を抑えられます。ワークショップ形式で複数部署を集める場合も、目的を絞って人選すると議論が発散しません。
逆に避けたいのは、忙しいからと現場を知らない代理の人だけを出すことです。代理の人は想像で答えるしかなく、その回答が要件として固まってしまいます。どうしても担当者が出られないときは、その部分は仮の回答とし、後日実際の担当者に確認して正式な回答を返す、という運用にしておきましょう。誰の発言を正式な要件として扱うかを曖昧にしないことが、後のトラブルを防ぎます。
当日の進め方と答え方のコツ
当日は、開発会社の質問に答えるだけでなく、こちらから業務の背景や狙いを積極的に伝える姿勢が役立ちます。「なぜその作業をしているのか」という背景を共有すると、ベンダーはより良い実現方法を提案しやすくなります。単に「今こうしている」と現状を伝えるだけでなく、「本当はこうしたい」という理想や、「ここだけは変えたくない」という制約まで言葉にすると、要件の輪郭がはっきりします。
その場で即答できない質問が出るのは当然です。無理にその場で決めず、「持ち帰って確認します」と宿題にして構いません。大事なのは、宿題に期限を切り、誰が回答するかを決めて、確実に戻すことです。宿題が放置されると、その分だけ要件定義もベンダーの作業も止まります。
当日に意識したいのは、質問された範囲だけ答えて終わらないことです。たとえば「この帳票はどう使いますか」と聞かれたら、使い方だけでなく「月末に集中するので時間がかかって困っている」といった困りごとまで添えると、ベンダーは改善の余地に気づけます。要件定義のヒアリングは、現状をなぞる場ではなく、より良いやり方を一緒に探す場でもあります。聞かれていないことでも、業務上の悩みは積極的に共有する価値があります。
また、開発会社からヒアリングシートを渡された場合は、埋められる範囲で事前に記入しておくと当日の議論が深まります。空欄は無理に埋めず、「ここは決まっていない」と分かるようにしておくほうが、論点が明確になって有益です。打ち合わせ中はメモ役を一人決めておくと、後で議事録と照らし合わせやすくなります。発言が多くなると誰が何を言ったか曖昧になりがちなので、こちら側でも記録を残しておくと、認識のズレを早く発見できます。
ヒアリング後に確認すべきこと
ヒアリングが終わったら、開発会社が議事録や整理した内容を共有してくれることが多いので、必ず目を通します。自分が伝えたつもりのことが、正しく理解されているかを確認するためです。ここで認識のズレを見つけておけば、要件定義書になる前に修正できます。
確認のポイントは、専門用語の正しさではなく「自社の業務と合っているか」「伝えたかった優先順位が反映されているか」です。違和感があれば、早いうちに事実ベースで伝えましょう。最終的に出てくる要件定義書をどう確認するかは要件定義の進め方と失敗しない準備もあわせて読むと、ヒアリングから承認までの流れが一本でつかめます。
議事録を確認する際は、決まったことと、まだ決まっていないこと（宿題）が区別して書かれているかも見ておきましょう。両者が混ざっていると、後で「あれは決定だったのか保留だったのか」で揉めます。曖昧な箇所があれば、その場で開発会社に確認し、認識を揃えてから次の回へ進むのが安全です。こうした往復を丁寧に重ねた記録は、そのまま要件定義書のたたき台にもなり、発注側と開発会社の双方にとって財産になります。
ヒアリングは一度きりの場ではなく、認識をすり合わせていく往復のプロセスです。完璧に答えようと気負わず、分かることを正直に伝え、分からないことは持ち帰る。この姿勢が、結果的に最も精度の高い要件定義につながります。
