初級SEが要件定義で迷うポイント
――次に何を聞くべきか分からない問題
知識はあるのに、現場で固まる
これまで3回にわたって、要件定義にまつわる構造的な問題を整理してきました。第1回「なぜ要件定義は失敗するのか」では、失敗の原因を「引き出せていない」「欠落に気づけない」「完了の基準がない」という3つの層に分けて整理しました。第2回「要求と要件を分ける意味」では、顧客の「要求」とSEが向き合う「要件」が、そもそも別物であることをお伝えしました。第3回「要件定義で抜け漏れが起きる理由」では、その背景にある「暗黙知」が、待っていても出てこないことを整理しました。
これらは、いわば要件定義における「べき論」です。
では、この「べき論」を理解したSEは、現場でうまくヒアリングができるようになるでしょうか。
実際には、そう簡単ではありません。
「例外ケースも聞かなければならない」と知っていることと、実際の打ち合わせの場で「この場合、例外的な対応はありますか？」と自然に問いを差し込めることは、まったく別の能力です。
知識として理解していても、目の前で顧客が話している最中に、「次に何を聞くべきか」が分からなくなる。これは、要件定義の経験が浅いSEのほぼ全員が通る道です。
今回は、この「知っているのに、できない」というギャップがなぜ生まれるのか、そして初級SEが現場で具体的にどこで迷うのかを整理します。
「知っている」と「できる」は別の能力
なぜ、知識が現場での行動に結びつかないのでしょうか。
ヒアリングは、台本通りに進むものではありません。顧客の発言は、こちらが想定した順序で出てくるわけではなく、ひとつの発言の中に複数の論点が混在していたり、重要な情報がさらりと一文で流されたりします。
このとき、SEに求められているのは、リアルタイムでの判断です。
「今、顧客が言ったこの一言は、深掘りすべき情報なのか、それとも雑談なのか」 「この話の流れで、関連する例外ケースを今聞くべきか、それとも後でまとめて聞くべきか」 「この発言の背景には、まだ語られていない暗黙のルールがあるのではないか」
こうした判断を、会話を止めずに、その場で行う必要があります。
さらに、リアルタイムでの判断には、もう一つの難しさが伴います。せっかく踏み込んだ質問をして、顧客が話を広げてくれたとします。すると、その回答が要求レベルの話から要件レベルの詳細、さらには例外条件まで、一気に詳細化されることがあります。これは望ましいことですが、同時に新たな課題を生みます。顧客は、同じことを二度、同じように話してくれるとは限りません。その場で出てきた詳細を正確に押さえておかなければ、二度と引き出せない情報になってしまう可能性があるのです。
しかも、顧客は自分が話したことを覚えています。後日、別の打ち合わせで「その話、最初の頃に言いましたよね」と言われることがあります。SE側がその情報を正確に押さえていなければ、「言った」「言われていない」という水面下の認識のズレが生まれます。
別の打ち合わせで指摘されるなら、まだ幸いです。同じことが、開発が終わってから出てくることも珍しくありません。「最初の打ち合わせで話しましたよね」という一言が、システムの完成後に出てくる。そのときには、もう手戻りという形でしかリカバリーできません。顧客にとっては一度話せば終わったことであり、SEがそれを覚えているか、正しく記録できているかは、顧客の関心の外にあります。
つまり、初級SEは「何を聞くか」という判断だけでなく、「聞けた内容を、その場でどう正確に捉えるか」「それを後から再現できる形で残せているか」という、もう一つの負荷も同時に抱えています。会話を進めながら、次の質問を考え、同時に今聞いた内容を正確に記憶・整理する。
これを同時に行うのは、決して簡単なことではありません。
これは、自転車の運転に似ています。「ハンドルを切るときは体重を傾ける」という知識を持っていても、実際に自転車に乗って曲がる瞬間に、その知識を意識して実行できるとは限りません。経験を通じて、知識が「とっさに使えるもの」に変わっていく必要があります。
要件定義のヒアリングも同じです。知識を「とっさに使える」状態にするには、経験の蓄積が必要です。しかし初級SEには、その蓄積がありません。
私自身も、同じ道を通ってきました
この話は、何年経っても忘れません。
独立して最初の頃、初めて顧客先へプレゼンに行く機会がありました。まずは会社紹介という、もっとも基本的なものです。資料も用意し、何度も練習したはずでした。
しかし実際の場では、しどろもどろになりました。会社紹介すら、まともに話せなかったのです。「こんな簡単なことすら、できないのか」と、帰りの電車で自己嫌悪に陥ったのを覚えています。
ヒアリングも同様でした。現場に行っても、相手は言葉少なで、「はい」「いいえ」程度の返答しか返ってきません。何を聞いても会話が広がらず、要件定義がスカスカな状態になる。
プログラマとしては、そこそこ自信を持っていました。コードを書くことには慣れていたし、論理的に物事を組み立てることもできていたつもりでした。それなのに、ヒアリングという場では、自分の力がまったく発揮できない。「自分は、優秀なSEにはすぐにはなれないのかもしれない」と、落ち込む日々が続きました。
今振り返ると、これは当然のことでした。プログラミングのスキルと、ヒアリングで「次に何を聞くか」を判断するスキルは、まったく別物です。前者を持っていても、後者はゼロから積み上げる必要があります。当時の私は、そのことを理解しておらず、「自分には向いていないのかもしれない」とまで考えていました。
なぜ「次の質問」が出てこないのか
初級SEのヒアリングを観察すると、いくつかの典型的な状況が見えてきます。
事前に用意した質問リストが尽きると、止まる
多くの初級SEは、ヒアリング前に質問リストを準備します。これは正しい準備です。しかし、リストにある質問を一通り聞き終えると、そこで思考が止まってしまうことがあります。
顧客の回答の中に、新たに聞くべき論点が含まれていても、それに気づいて「リストにない質問」を即興で立てることができない。リストは「最低限聞くべきこと」であって、「そこから先を広げるための土台」として機能していないのです。
顧客の話に「反応するだけ」になる
顧客が話している内容に対して、「なるほど」「分かりました」と相槌を打ちながら聞くことはできます。しかし、その話の中から「これは要件として重要な情報だ」「これは確認が必要な曖昧な表現だ」と判断し、その場で問いを返すことができない。
結果として、ヒアリングが「顧客が話したことをそのまま記録する作業」になってしまいます。これでは、議事録の質は、顧客の説明力にすべて依存することになります。
深掘りのタイミングを逃す
顧客が何気なく言った一言。
「まあ、基本的にはそうなんですけど」
「普通はこうなんですが」
には、例外や条件が隠れていることが多いです。
経験のあるSEであれば、こうした言葉を聞いた瞬間に「『基本的には』ということは、例外があるということですね。どんな場合に例外になりますか？」と即座に切り返します。
しかし初級SEには、この言葉が「深掘りのサイン」であるという認識がありません。聞き流してしまい、会話は次の話題に進んでしまいます。後からその発言を振り返って「あれ、もしかして」と気づくのは、たいてい開発が進んだ後です。
話題が広がりすぎて、収束させられない
逆のパターンもあります。顧客が話を広げてくれた場合、それをすべて深掘りしようとして、ヒアリングの時間内に収まらなくなる。あるいは、すべてを同じ重要度で記録してしまい、後で「これは要求なのか、要件なのか、それとも単なる感想だったのか」が分からなくなる。
優先度をつけながら聞く、というのも経験が必要なスキルです。
メモに追われて、聞き逃す
ヒアリングの最中、初級SEは「聞く」と「書く」を同時に行わなければなりません。しかし、相手が話すペースは、こちらの手が追いつくペースとは関係なく進みます。
メモを取ることに意識が向いている間も、顧客は話を続けています。「今のところ、ちゃんと書けただろうか」と気にしている間に、次の発言が始まっている。気づいたときには、その間に話された内容が抜け落ちています。
厄介なのは、抜け落ちた部分が重要な情報だったかどうかは、その場では判断できないということです。メモに残らなかった発言の中に、後から問題になる重要な一言が含まれていることもあります。
ただし、この聞き逃しは、初級SEに限った問題ではありません。「聞く」と「書く」を完全に同時並行で処理することは、人間の認知能力として簡単なことではなく、ベテランであっても、メモを取っている間に一瞬聞き逃すことは起こります。違いがあるとすれば、ベテランは「聞き逃した可能性がある」ということに自覚的で、その場で「すみません、今のところもう一度お願いできますか」と確認を入れたり、会話の流れの中で別の角度から同じ情報を引き出し直したりといった対処ができることです。初級SEは、聞き逃したこと自体に気づけないことが多く、欠落がそのまま残ってしまいます。
ベテランは、何をしているのか
ベテランのSEのヒアリングに同席すると、初級SEとの違いがよく分かります。
ベテランは、顧客の発言を聞きながら、頭の中で複数のことを同時に行っています。
ひとつは、「この発言は要求なのか、要件なのか、それとも前提条件や制約なのか」という分類です。発言を聞いた瞬間に、それがどの引き出しに入るものかを判断しています。
もうひとつは、「この発言の裏に、何が隠れていそうか」という予測です。「月次レポート」という言葉を聞いた瞬間に、「出力形式は何か」「誰が見るのか」「承認は必要か」といった論点が、自動的に頭に浮かびます。これは、過去に似たような要求を扱った経験から来るパターンマッチングです。
さらにもうひとつは、「今、この話を深掘りすべきか、それとも後回しにすべきか」という優先度の判断です。会話の流れを大きく崩さない範囲で、重要な論点だけをその場で深掘りし、それ以外は後でまとめて確認するという判断を、リアルタイムで行っています。
これらはすべて、明文化されたルールではなく、経験から形成された「感覚」です。
わかっていることと、できることの距離
ここで、少し視点を変えてみます。
スポーツの試合を見ていて、こんな経験はないでしょうか。応援している選手が、ここぞという大事な場面で結果を出せない。それを見ながら、「あそこはこうすればよかったのに」と、つい口にしてしまう。
しかし、その指摘を自分が実際にできるかと言えば、答えはほぼ間違いなく「できない」です。そして実は、その選手自身も同じです。「あそこはこうすべきだった」と、誰よりも分かっているのは選手本人です。分かっていても、その場でできるかどうかは別の話なのです。
これは、ベテランSEの「なんとなく」にも当てはまります。ベテラン自身、ヒアリングが終わった後に振り返れば、「ああ、確かにあそこは深掘りすべきポイントだった」と説明できます。しかし、その説明ができることと、別の場面でとっさにその判断ができることは、必ずしも一致しません。経験を持つ本人であっても、すべての場面で「分かっていることを、その場で実行できる」わけではないのです。
私自身、後輩のヒアリングに同席する機会が何度もありました。終わった後、「あの場面、なぜ深掘りしなかったの？」と聞くと、後輩は「言われていることをそのまま聞いていました。それ以上聞くという発想がなかったです」と答えることがよくありました。
これは、後輩の能力の問題ではありません。「そこで深掘りすべきだ」という判断基準そのものを、まだ持っていないのです。判断基準を持っていない人に「もっと深掘りしなさい」と言うのは、ものさしを持っていない人に「正確に測りなさい」と言うのに近い。
そして、私が同席して初めて気づくことができたのは、後輩のヒアリングの「結果」ではなく、「リアルタイムでの判断のプロセス」でした。これは、議事録を後から読んでも分かりません。その場にいて、会話の流れの中でどこで止まり、どこで流れたかを見て、初めて見えてくるものです。
しかし、すべての初級SEのヒアリングに、毎回ベテランが同席することは現実的ではありません。プロジェクトの数も、ベテランの数も限られています。
「案内してくれる存在」が必要
ここまでの話を整理すると、初級SEが現場で迷う本質的な理由は、「次に何を聞くべきか」を判断するための材料。
過去の経験から来るパターン認識。
を持っていないことにあります。
この問題に対して、「経験を積めば解決する」というのは、間違いではありませんが、時間がかかる解決策です。初級SEが経験を積む過程では、その間に多くのプロジェクトで欠落が発生し続けます。
必要なのは、リアルタイムで「次にこれを聞いたほうがいい」「この発言は深掘りが必要かもしれない」と示してくれる、案内役の存在です。
これは、ベテランが頭の中で行っている「分類」「予測」「優先度判断」を、外部から補助する仕組みと言えます。経験が浅いSEでも、その案内に従うことで、ベテランが自然に行っている問いの広がりに近づける。
ヒアリングが終わった後に「ここが足りていません」と指摘するのではなく、ヒアリングの最中、あるいはその前後に「次はこれを確認しておくとよいでしょう」と示してくれる。この「案内」があれば、初級SEは経験の蓄積を待たずに、一定水準の要件定義に近づくことができます。
AI時代における、この問題の重み
AIが下流工程を担う時代において、この問題はどう変化するでしょうか。
ひとつの見方として、「AIが要件定義のヒアリングそのものを代替するのではないか」という期待があるかもしれません。しかし、顧客との対話、関係構築、現場の空気を読むといった部分は、簡単には代替できません。
一方で、「次に何を聞くべきか」という判断を補助する役割については、AIが力を発揮しやすい領域です。過去の数多くのプロジェクトのパターンを学習し、「この種の要求には、こういう論点が伴うことが多い」という予測を提示することは、ベテランが頭の中で行っている処理に近いものです。
つまり、AIに置き換わるのは「ヒアリングそのもの」ではなく、「ヒアリングを支える経験の部分」である可能性があります。経験が浅いSEであっても、経験豊富なSEに近い視点でヒアリングに向き合えるようになる。
これは、初級SEにとって大きな変化になるはずです。
まとめ
要求と要件の違いを理解し、暗黙知の存在を知っていても、現場のヒアリングでそれを実践することは別の能力です。リアルタイムで「これは要求か要件か」「この発言の裏に何があるか」「今深掘りすべきか」を判断する力、そして「聞けた内容を正確に捉え、後から再現できる形で残す」力は、経験の蓄積によって形成されます。
初級SEは、この経験を持っていないため、質問リストが尽きると止まる、顧客の話に反応するだけになる、深掘りのタイミングを逃す、メモに追われて聞き逃す、といった状況に陥りやすくなります。聞き逃し自体は初級SEに限った問題ではありませんが、その後の対処。気づいて確認を入れる、別の角度から引き出し直す。
これができるかどうかに、経験の差が表れます。そして、その判断基準は、本人にとっても「なんとなく」としか説明できないものであり、経験者であっても、すべての場面でその基準をその場で実行できるわけではありません。
この問題への対処として、「経験を積む」という時間のかかる方法だけでなく、リアルタイムで「次に何を聞くべきか」を示してくれる案内役の存在が重要になります。これは、ベテランが頭の中で行っている判断を、外部から補助する仕組みです。
この問題に、仕組みで向き合うツールがあります。
AiRee（アイリー）は、要件定義の完了度をスコアで可視化するAIプラットフォームです。「勘」に頼らず、構造的な欠落を検出します。
現在（2026年7月31日まで）、10社限定で無償トライアルを受付中です。
［先行トライアルに応募する →］ ［資料をダウンロードする →］
最後までご覧いただきありがとうございました。
メルマガ登録をしていただければ、コラムが更新された時にお知らせします。
また、AI要件定義プラットフォーム AiRee（アイリー）の情報も合わせてお届けします。