【知識】顧客の「本当の欲しい」を引き出す！「要求獲得」の全貌｜情報処理問題1000本ノック（解説編）

システム開発の最上流工程であり、プロジェクトの成否を握る最重要局面「要求獲得（要求エライシテーション）」。単に言われたことをメモするのではない、本質的な知識を整理しましょう。

1. 要求獲得で「絶対に聞き出すべき」4つの本質

ステークホルダー（利害関係者）に対してヒアリングを行う際は、表面的な機能の要望（「画面にボタンが欲しい」など）ではなく、以下の根本的な問いをぶつけ、合意形成を行う必要があります。

・システムの目的は？（Why：なぜこのシステムを作るのか）

・何を達成したいの？（Goal：最終的なゴール、経営目標は何か）

・どんなビジネスニーズに対応するの？（Need：市場や業務のどんな課題を解決したいのか）

・システムがビジネスで、どう使われていくの？（Operation：現場でどのような業務フローになるのか）

2. 要求獲得が「極めて難しい」3つの理由

要求獲得は、システム開発の中で最も人間臭く、トラブルが起きやすい工程です。それには以下の3つの大きな原因が存在します。

1. スコープの問題
システム化の「境界線（どこまでやるか）」の設定が甘いと、「あれもやりたい、これもやりたい」とスコープが無限に広がっていき、予算と納期が崩壊します。

2. 要求や問題自体の問題
・利用者が、問題自体を正しく認識していない（何に困っているか、何が欲しいのかを自分たちで言語化できない）。
・立場（経営層、現場のリーダー、一般社員など）によって、問題のとらえ方が全く異なる。

3. 時間による変化の問題
ビジネス環境の変化、法改正、あるいは開発が進んで画面が見えてくることによって、要求は時間とともに必ず変化・追加される性質を持っています。

3. 要求獲得プロセスの「7つの実践ステップ」

要求を獲得し、仕様として確立するまでには、以下の一連のエンジニアリング作業を順番に進めていきます。

ステップ	作業内容
ステップ 1	ビジネスや技術の面から実現可能性を検討（フィージビリティスタディ）
ステップ 2	要求の定義および組織での役割の特定（誰がどの要求を出しているかの明確化）
ステップ 3	技術環境（アーキテクチャ等）の定義（システムを動かす土台の策定）
ステップ 4	ドメインの制約定義（業界ルールや法規制などの縛りの定義）
ステップ 5	要求獲得の技法の定義（インタビュー、ミーティング、観察など手法の決定）
ステップ 6	要求獲得、プロトタイプでの確認（試作品を見せて認識ズレを早期に解消する）
ステップ 7	ユースケースシナリオの定義（実際の利用シーンに沿った具体的な動きの落とし込み）

1. 理解のコツ: 顧客は「ドリル（機能）」が欲しいのではなく「穴（ビジネスの成果）」が欲しいのだ、という格言があります。要求獲得の難しさを突破するには、ステップ6にあるプロトタイプ（試作品）を素早く見せ、「欲しかったのはこれじゃない」を先に言わせることが最大の防御になります。
2. 試験対策の視点: 応用情報以上の高度試験（システムアーキテクトなど）では、「利用者は要件を正しく認識していない」という前提をもとに、それを解決するための「プロトタイプ」「ユースケース記述」「JAD（共同アプリケーション開発）」などの技法と絡めて、午後問題の記述や論文のテーマとして非常によく狙われます。

4. まとめ

「ステークホルダーの潜在的なニーズを引き出し、実現可能性や制約を考慮しながら、具体的な利用シナリオに落とし込んでいく一連のプロセス」。それが要求獲得です。ここでの妥協や認識ズレは、後々の工程（設計・テスト）で何十倍もの手戻りコストとなって跳ね返ってくるため、7つのステップを堅実に回していく管理能力が求められます。