要件定義ヒアリングのコツ｜要望の洪水から「真のニーズ」を引き出す翻訳術

本連載について
この記事は、IT現場で最も炎上しやすいと言われる「要件定義」の進め方を、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全7回のシリーズです。（※どの回からでも単独でお読みいただけます）

第3回となる今回は、ユーザーのわがままを実装可能な仕様に変える「ヒアリングと翻訳の技術」についてお届けします！

「ユーザーに欲しいものを聞いたら、要望が多すぎて収拾がつかなくなった……」
「現場の要望をすべて盛り込んだら、予算もスケジュールも完全にパンクした……」

要件定義のヒアリングフェーズで、多くのリーダーが陥るのがこの「要望の洪水」です。前回（第2回：全体像）で情報を整理する「4つの階層」の地図を手に入れましたが、その中身を埋めるためのヒアリングは一筋縄ではいきません。

なぜなら、ユーザーは自分たちが「本当に必要なもの」を正しく言葉にできるとは限らないからです。今回は、バラバラな「わがまま（要望）」を、実装可能な「真のニーズ（要件）」へと整理していくテクニックを紐解いていきましょう。

要望（Want）とニーズ（Need）の決定的な違い

ヒアリングにおいて最も大切なことは、相手が言っていること（要望）を、そのまま「要件」として受け入れないことです。

旅行の計画中、家族からこんな要望が出たとします。

これらをすべて叶えようとすると、「ハワイで温泉に入りながらスキーをする」という、実現不可能（予算オーバー）な計画になります。これが「全部盛りで失敗するプロジェクト」の縮図です。

ここでリーダー（お父さん役）がすべきは、言葉の裏にある「なぜ？」を深掘りすることです。

この「背景にある目的」こそが本当のニーズです。ハワイやスキーは、そのニーズを満たすための「一つの手段」に過ぎません。

相手の本音（ニーズ）にたどり着くためには、単に話を聞き流すのではなく、戦略的な問いかけが必要です。

「なぜハワイなの？」と聞くことで、特定の手段に固執している理由を明らかにします。

「ほかに行きたい場所や、やりたいことはある？」と聞くことで、最初に出てきた強い要望以外のこだわりを引き出します。

「もしハワイに行けないとしたら、海とショッピングどっちを優先したい？」と二者択一を迫ります。

ユーザーの曖昧な言葉を、エンジニアが理解できる具体的な「仕様」へと変換する。これこそがリーダーの腕の見せ所です。

ユーザーの主観的な言葉は、以下のポイントを意識して客観的な数字や基準に翻訳しましょう。

ユーザーの言葉（曖昧）	リーダーの翻訳（具体的・客観的）	翻訳のポイント
「とにかく使いやすくして」	「現在10分かかっている入力を、3分以内に完了できるようにする」	形容詞を「数字」に置き換える。
「誰が見てもわかるレポートにして」	「主要5項目の推移を折れ線グラフ化し、前月比10%以上の変動を自動で赤色強調する」	「判断基準」を視覚化・具体化する。
「絶対に止まらないで」	「24時間365日の安定稼働、障害時の復旧目標は1時間以内」	万が一の「許容範囲」を具体的に決める。

ヒアリングのゴールは、相手の要望をすべて受け入れる（イエスマンになる）ことではありません。相手が「何を解決したくてその発言をしているのか」を深く理解し、納得感のある代替案を提示することです。

これができれば、わがままの洪水に飲み込まれてプロジェクトが難航することはなくなります。

ユーザーとの打ち合わせの際は、リーダーは以下の3点を意識してヒアリングに臨みましょう。

[ ] 手段と目的を切り分ける
ユーザーが「〇〇機能が欲しい」と言ったら、そのままメモするのではなく「それを使ってどんな作業を楽にしたいか（目的）」を問い返しているか。
[ ] 主観的な言葉を数字に変える
「速い」「使いやすい」という言葉が出たら、「具体的に何秒？何クリック？」と具体的な数値を握り合っているか。
[ ] ストレスの源泉を探る
「今のやり方で一番ストレス（不満）を感じる瞬間はいつですか？」と聞き、表面的な機能要望ではなく、解決すべき本質的な課題を特定できているか。