はじめまして。株式会社PRUMでエンジニアをしているひとみです。
日々、プログラミング学習や実務の中で、つまずきやすいポイントや、
仕事で起きやすい"ズレ"について整理して発信しています。
誰かの助けになれば幸いです。
「言った・言わない」を防ぐ。要件定義で使うべき質問の技術
はじめに
新人の頃、私はこう思っていました。
「コードが書ければ、仕事は回る」
技術さえ磨けば評価される。そう信じてプログラミングの勉強を続けていました。ところが現場に入ってみると、むしろ評価されている先輩は「 聞き方が上手い人 」でした。
会議で話をしっかりメモしていても、後から「 そんなことは言っていない 」、「 こういう意味じゃなかった 」とトラブルになる。そういうことが私も最初は何度も起きました。
問題は理解力でも技術力でもなく、質問の仕方 にありました。
この記事では、要件定義のヒアリングで本当に使える「 問いの技術 」を整理します。
「聞けばいい」という勘違い
要件定義のミーティングで、
こんな経験はないでしょうか。
クライアント：「システムをもう少し使いやすくしてほしいんです」
私：「わかりました。改善します」
打ち合わせは和やかに終わり、
「よし、要件は把握できた」と思っていたのに、
いざ開発が進むと「そういう意味じゃなかった」と言われる。
足りていなかったのは「 情報量 」ではありませんでした。問いの意図 が曖昧だったのです。
たとえば、「使いやすくしてほしい」の裏には、
何が隠れているでしょうか。
- ボタンが押しにくいという UI の問題かもしれない。
- 処理が遅いという性能の問題かもしれない。
- 操作の手順が多いという設計の問題かもしれない。
聞いたつもりで、聞けていない。
これが「言った・言わない」のほとんどの原因です。
Step1 質問には2つの方向がある
ヒアリングの質を上げるために、まず覚えてほしいのが「 水平質問 」と「 垂直質問 」の使い分けです。
水平質問――情報を横に広げる
「他に困っていることはありますか？」
「今回のリニューアルで、優先したい項目はありますか？」
このような「範囲を広げる問い」を打ち合わせの序盤に繰り返すと、クライアントの要望の全体像が見えてきます。一番怖いのは、開発の終盤になって「実はあの機能も必要だったんです」と言われること。
水平質問をしっかり使うことで、その仕様漏れを
早い段階で防ぐことができます。
垂直質問――情報を縦に深める
「具体的にはどのような状態ですか？」
「そのシステム遅延は、ネットワーク環境の問題とお考えですか、
それともサーバーの問題でしょうか？」
全体像がつかめたら、次は一点を深掘りする番です。「使いにくい」の奥には必ず具体的な原因があります。垂直質問はその原因を言語化させるための技術です。
この垂直質問を怠ると、見当違いの改修をしてしまうことになります。
Step2 「何を作るか」より「なぜ作るか」を聞く
もう一つ、現場でよく起きる失敗があります。
クライアントから「AIを使った売上予測システムを作ってほしい」と言われたとき、そのまま AI システムの設計に入ってしまうことです。
私が先輩から教わったのは、
要望よりも目的を先に聞く ということでした。
「なぜ、このタイミングで検討されたのですか？」
「数あるIT技術の中で、なぜAIに注目されたのでしょうか？」
こう聞くと、
「実は毎月20時間かけて手作業で集計しているのが辛くて...」
という本音が出てきます。そうなれば、AI よりもシンプルな自動集計ツールの方が、コストも安く、喜ばれることが多いのです。
クライアントの言葉をそのまま受け取るのではなく、その言葉の裏にある「困りごと」を聞く。これができると、ただプログラムを書くエンジニアから、課題を解決するパートナーとして見てもらえるようになります。
Step3 「はい」か「いいえ」で合意を取る技術
情報を集め、目的を確認したら、次は「確認」のステップです。ここで覚えてほしいのが、2種類の質問の使い分けです。
限定質問――確認と合意に使う
「今回の会員登録画面には、SNSログイン機能は含めない、
という方向で確定してよろしいですか？」
「来月〇〇日までにプロトタイプをご提出するスケジュールで
進めてよろしいでしょうか？」
「いかがでしょうか？」と曖昧に聞くのではなく、
「 これでいいですか？ 」と一点を確認する。
「はい」という言葉をもらうことで、後の
「言った・言わない」を防ぐことができます。
拡大質問――情報収集に使う
「新システムを導入した後、現場のスタッフの方には
どのように運用していただくのが理想ですか？」
「現在のシステムで、一番ストレスを感じる瞬間はいつですか？」
こうした問いかけで、クライアント自身も言語化できていなかった情報が引き出されてきます。
「拡大質問」 で広げて、「限定質問」 で確定させる。
この流れを意識するだけで、打ち合わせの後に残る
「ふわっとした感じ」がなくなっていきます。
Step4 要望を「具体化」して「抽象化」する
最後に、少し上級の技術を紹介します。
要望の具体化
新人の頃、「スマホ対応にしてほしい」と言われたとき、「わかりました」と答えてそのまま設計に入ったことがありました。
後から「Android に対応していないのはなぜ？」「横向きが崩れる」と、次々と指摘が来て、設計をやり直す羽目になりました。
あのとき必要だったのは、こういう確認でした。
「iOS と Android どちらも対象ですか？」
「どのブラウザで動作を保証しますか？」
「横向き表示は必要ですか？」
大雑把な要望を細かい要素に切り分けていく。
これを チャンクダウン（具体化） といいます。
先回りして確認しておくと、設計のやり直しがなくなります。
本質を抽象化
画面デザインの細かい話に終始しているとき、
こう聞くことで一度視座を引き上げます。
「そもそも、今回のDX化を通じて、5年後にどんな組織にしたいですか？」
これが 抽象化（チャンクアップ） です。目先のスペック比較から離れ、「何のためにIT化するのか」という本質的な目的に目を向けさせることで、本当に必要なシステムの姿が見えてきます。
新人の頃の私は、ただ言われたことをメモするだけで
「要件は取れた」と思っていました。でも実は
問いの種類によって、引き出せる情報がまったく変わる のです。
まとめ
「言った・言わない」は、技術力の問題ではありません。質問の設計の問題です。
大事なのは「 この問いで何を引き出したいのか 」という意図を持って聞くか、ただ話を聞くだけで終わるか、その差です。
先輩に言われて最初に変えたのは「 会議中に自分が話す時間を減らすこと 」でした。
自分が話している時間、クライアントは情報を出してくれません。
聞く姿勢を増やして、問いの質を上げる。その変化で、打ち合わせの後に感じる「ふわっとしたまま終わった感」が減少するのではないでしょうか。
PRUMのエンジニアの95%以上は未経験からの採用です。もし弊社にご興味あれば下記のサイト記事を覗いてみてください。