要件定義でつまずかないヒアリングのコツ

「要件定義のヒアリングを何度も重ねているのに、開発が始まってから『こんなはずじゃなかった』と言われてしまう」

——このような経験を持つシステムエンジニアやプロジェクトマネージャーは非常に多いのが現実です。

要件定義は、システム開発プロジェクトの成否を左右する最も重要な工程の一つです。しかし、適切なヒアリング技術を身につけていないと、外見上は順調に進んでいるように見えても、実際には「上滑りなヒアリング」となってしまい、最終的に大きなトラブルに発展するケースが後を絶ちません。

実際の現場では、ヒアリングが不十分な内容で終了したことは、その時点では明確には分からないのが普通です。その後の工程が予定通り進捗したことで、正しく終了したと形式的には認定されます。しかし、最後のテストフェーズで顧客や利用者側がシステムにダメ出しをした時、初めてヒアリングの不備が誰の目にも明瞭になるのです。

本記事では、実際にプロジェクトで発生した失敗事例を分析しながら、要件定義のヒアリングで絶対に押さえておくべきポイントと、つまずかないための実践的なテクニックを詳しく解説していきます。

要件定義ヒアリングの重要性とその難しさ

要件定義とヒアリングの関係性

要件定義とは、顧客のニーズから持ちうる技術力やノウハウを用いて、「業務」「システム」「実現機能」「非機能」「移行」等の要件を整理し、必要に応じて提案する工程です。

この要件定義において、ヒアリングは情報収集の最も重要な手段となります。なぜなら、要件は要求を元に作られ、業務や事業側の「何をしたいか」「何をシステムに求めるのか」をヒアリングし、そのインプットを元に要件を形作っていくからです。

ヒアリングが困難な理由

どんなプロジェクトでも、ユーザーの要求は得てして曖昧です。どちらかというと、ユーザーもヒアリングやディスカッションを通して何が本当にしたい事かを発見していきます。そのため、要件定義を進めるために、既にある文章からユーザー要望を理解することに加え、ヒアリングで必要な情報を引き出すことが重要になってきます。

要件定義とヒアリングで陥りがちな罠

陥りがちな悪いパターン

要件定義の責任を果たそうとせず顧客側に「結局、何作ってほしいの？」と聞いてしまうことです。

その作業を顧客側に押し付けるのは、要件定義を遂行するIT企業側の善管注意義務違反と言われても仕方がありません。

逆に、顧客側にその認識がなく、開発側に「アレやれ」「コレやれ」と指示・命令をしだし、その指示・命令を受け入れるのも同様に善管注意義務違反となります。これは「偽装請負」として顧客側にも問題があるのですが、それを甘んじて受け入れる姿勢を「プロのすることではない」と判断されてしまうからです。

実際に起きた失敗事例とその分析

失敗事例1：「聞くだけヒアリング」の落とし穴

プロジェクト概要

• 業界：製造業

• システム：在庫管理システムの刷新

• 期間：6ヶ月の予定が12ヶ月に延長

• 問題：テスト段階で大幅な仕様変更が発生

何が起きたのか

ベテランプロジェクトマネージャーのDさんの下で、担当技術者がクライアントとのヒアリングを担当していました。技術者は毎回の打ち合わせで顧客の話を丁寧に聞き、議事録も詳細に作成していました。

しかし、Dさんはそのヒアリングに不満を持っていました。なぜなら、その技術者は自らは積極的に情報発信をしないという姿勢でヒアリングに臨み、相手の語る話を聞くのみだったからです。

問題が表面化したタイミング

要件定義は予定通り完了し、設計・開発も順調に進みました。しかし、ユーザー受け入れテストの段階で、クライアント側から以下のような指摘が相次ぎました：

• 「在庫の自動発注機能で、緊急時の手動介入ができない」

• 「月次レポートに必要な項目が不足している」

• 「他部署との連携フローが想定と違う」

失敗の根本原因分析

この失敗の特徴は、実際に多くの現場で見られる「受け身のヒアリング」にありました：

1. 疑問点の未解消: 技術者が感じた疑問点を曖昧なままにしていた

2. 確認不足: 理解した内容が正しいかの確認を怠った

3. 深掘り不足: 表面的な要求の背景にある真のニーズを探らなかった

4. 想定ケースの未検討: 例外的なケースや運用上の課題を想定していなかった

失敗事例2：「堂々巡りヒアリング」の時間浪費

プロジェクト概要

• 業界：小売業

• システム：ECサイトリニューアル

• 期間：要件定義だけで予定の2倍の期間を消費

• 問題：ゴール設定が曖昧で進捗が見えない

何が起きたのか

要件定義では「どうなったら完了」というゴール設定も曖昧で、そのまま時間切れで開発に突入してしまうケースは珍しくありません。このプロジェクトでも、ヒアリングを重ねても堂々巡りになってしまいました。

問題の具体的な症状

• 前回の打合せ課題を継続検討していた

• 「そもそも論」に立ち戻ることが頻発

• 進捗を示す際に「全体として半分程度進んでいる」といった曖昧な説明

• 同じような議論が何度も繰り返される

失敗の原因

1. 明確な完了基準の未設定: 何をもって要件定義完了とするかが不明確

2. 進捗の可視化不足: 具体的な作業の状態（ステータス）が曖昧

3. 議論の整理不足: 決定事項と未決定事項の明確な区別ができていない

4. 優先順位の未設定: すべての要求を同列に扱ってしまった

失敗事例3：「担当者人選ミス」による情報の歪み

プロジェクト概要

• 業界：金融業

• システム：融資審査システム

• 問題：業務を理解していない担当者との打ち合わせで要件が歪む

何が起きたのか

クライアント側の担当者が、実際の業務を正しく理解していない人物でした。その結果、ヒアリングで得られた情報と実際の業務に大きなギャップが生じました。

問題の具体例

• 想定していた審査プロセス: 申請 → 自動判定 → 承認

• 実際の審査プロセス: 申請 → 事前チェック → 複数部署での協議 → 条件交渉 → 最終承認

担当者は「簡単な審査フローで自動化したい」と説明していましたが、実際には複雑な人的判断が多く含まれる業務でした。

問題が発覚したタイミング

開発終盤で実際の審査担当者がシステムを確認した際、「これでは実務で使えない」という問題が発覚しました。

教訓

ユーザー側の担当者をテキトーな人選で決めるとトラブル率が圧倒的に上昇します。仮にどんなにSIer、ITベンダー側が優れていたとしても、彼らは「必要十分な情報」を揃えられない限りは上手くマネジメントできません。

成功するヒアリングの3つのポイント

ポイント1：「聞く」だけでなく「引き出す」姿勢

基本的な心構え

ヒアリングはそもそも「聴く」ことが第一目的です。まずは話をよく聴きましょう。そして先入観にとらわれないように柔軟でオープンな気持ちを持ってください。

ただし、聴くのは目的の第一義ですが、最終的に聴きだす対象は要件ではなく、その前段である「要求事項（ニーズ）」を聞き出すことです。

重要な考え方

要求事項（ニーズ）を聞き出す場合、私たち開発側に対して「〇〇してください」という答えを聴くことが目的にはなりません。それはむしろ悪手です。

ここで聴きたいのはあくまで「要求事項（ニーズ）」、つまり：

「今の現状（As-Is）を、理想（To-Be）にしたい」

という要望であって、それを具体的で実現可能な要件にするのは、提案も兼ねて私たち開発側の仕事です。

ポイント2：5W2Hを意識した体系的なヒアリング

要求を正しく引き出すためには5W2Hを意識するとヒアリング精度が格段に向上します。ヒアリングの抜け漏れ、曖昧など要件定義不備にならないよう、以下に注意しながらヒアリングを行いましょう。

5W2Hのフレームワーク

• What（何を）: 現場の課題、改善したいポイントは何か？何を実現したいのか？

• Why（なぜ）: なぜシステム化が必要なのか？背景・目的は何か？

• Who（誰が）: システムの利用者や運用者は誰なのか？

• When（いつ）: システム化したい時期は？業務のタイミングは？

• Where（どこで）: 要求を満たすための開発範囲はどこまでか？

• How（どのように）: 現在はどのように業務を行っているのか？

• How much（いくら）: 予算や投資対効果の期待値は？

実践例：在庫管理システムの場合

• What: 在庫の過不足を解消し、適正在庫を維持したい

• Why: 欠品による売上機会損失と過剰在庫による倉庫コスト圧迫を解決したい

• Who: 倉庫管理者、営業担当、経営陣が利用

• When: 繁忙期前の4月までに稼働開始、日次で在庫チェック

• Where: 本社倉庫と3つの地方倉庫が対象

• How: 現在は手作業でExcel管理、週1回の実地棚卸

• How much: 年間300万円のコスト削減を期待、予算上限500万円

ポイント3：オープン質問とクローズ質問の使い分け

オープン質問（開放型質問）

相手が自由に答えられる質問形式で、豊富な情報を収集するのに適しています。

使用場面と効果

• ヒアリング初期の情報収集

• 相手の本音や潜在ニーズの把握

• 予想外の課題や要求の発見

質問例

• 「現在の業務で最も困っていることを教えてください」

• 「理想的なシステムがあるとしたら、どのような機能があると嬉しいですか？」

• 「この業務を効率化できたら、どのようなメリットがありますか？」

クローズ質問（限定型質問）

選択肢を限定した質問形式で、具体的な確認や意思決定に適しています。

使用場面と効果

• 具体的な仕様の確定

• 優先順位の決定

• 理解内容の確認

質問例

• 「データの更新頻度は、リアルタイム・1時間毎・日次のどれをご希望ですか？」

• 「承認フローは、部長承認のみで良いですか？それとも課長→部長の二段階ですか？」

• 「予算は300万円以内とのことですが、機能を限定すれば問題ありませんか？」

効果的な組み合わせ例

1. オープン質問で全体像を把握 「売上管理で困っていることを詳しく教えてください」

2. クローズ質問で具体化 「売上データの集計は、日次・週次・月次のどの単位が必要ですか？」

3. オープン質問で深掘り 「その集計データをどのような場面で、どなたが使用されますか？」

4. クローズ質問で確認 「つまり、営業会議用の週次レポートが最優先ということでよろしいですか？」

実践的なヒアリング技術

事前準備の重要性

依頼状の作成

ヒアリングの準備として最も重要なのは、依頼状を作ることです。相手にヒアリングの目的に沿った意見や情報を用意してもらうために、以下の5つの項目をしっかりと依頼状に記載する必要があります：

1. ヒアリングの目的・背景

2. 想定される所要時間

3. 質問予定の項目（大まかなアジェンダ）

4. 事前に準備していただきたい資料・情報

5. 参加者（こちら側・先方側）

業界・業務知識の事前学習

効率良く要件定義を行うためには、単にクライアントから挙げられた課題をヒアリングするだけではなく、既存システムや業務フローについて改善点がどこにあるのか把握する必要があります。

これにより、ヒアリング時の精度が上がることはもちろん、別の解決方法を提案することも可能になります。

ヒアリング実施時のテクニック

複数名での実施

漏れがなく、あとから記録を追いかけやすい質の高い議事録を残すためにも、ヒアリングの際は自社から2名以上で行うといいでしょう。

役割分担の例

• 右脳人間: お客様の話を引き出す役割（傾聴、共感、発想）

• 左脳人間: それをロジカルに整理し、記録として残す役割（分析、整理、文書化）

4つの実践ワザ

1. 二つの反復質問

   • 「つまり、〇〇ということでしょうか？」（理解確認）

   • 「もう少し詳しく教えていただけますか？」（深掘り）

2. 意味の明確化

   • 「〇〇とおっしゃいましたが、具体的にはどのような状況ですか？」

   • 専門用語や曖昧な表現の具体化

3. 論理性の確認

   • 「AだからBということですが、他に要因はありませんか？」

   • 因果関係の整理と確認

4. クローズ質問による確認

   • 「優先順位としては、A、B、Cの順番でよろしいですか？」

   • 重要な決定事項の明確化

ヒアリング時の禁止事項

やってはいけない4つのこと

1. 相手の話を遮る

   • 話の途中で結論を急がない

   • 最後まで聞いてから質問する

2. 否定的な反応を示す

   • 「それは技術的に無理です」などの即座の否定

   • まずは要求として受け止める姿勢

3. 専門用語を多用する

   • 相手のITリテラシーに合わせた説明

   • 必要に応じてサンプルや図解を活用

4. 曖昧な相槌で済ませる

   • 「なるほど」「分かりました」だけでは不十分

   • 具体的な確認と言い換えが必要

段階別ヒアリング戦略

第1段階：全体像の把握（初回ヒアリング）

目的: プロジェクトの背景と大まかな要求の理解

重点的に確認すべき項目

1. システム化の目的・背景

   • なぜ今システム化が必要なのか？

   • 解決したい課題は何か？

   • 期待する効果は？

2. 現状の業務フロー

   • 現在はどのように業務を行っているか？

   • 関係者・関係部署は？

   • 業務量・頻度は？

3. 制約条件の確認

   • 予算の上限

   • 納期の希望

   • 技術的な制約

第1段階での成果物例

• プロジェクト概要書

• 現状業務フロー図（概要版）

• 課題整理表

• 次回ヒアリングの論点整理

第2段階：業務詳細の深掘り（2-3回目）

目的: 具体的な業務要件の詳細化

重点的に確認すべき項目

1. 詳細業務フロー

   • 業務の手順・判断基準

   • 例外処理・エラー処理

   • 他システムとの連携

2. データの詳細

   • 入力項目・出力項目

   • データの形式・精度

   • データの保管期間・世代管理

3. 非機能要件

   • 性能要件（応答時間、同時接続数など）

   • 可用性要件（稼働時間、障害対応など）

   • セキュリティ要件

第2段階での成果物例

• 詳細業務フロー図

• データ項目定義書

• 非機能要件一覧

• 画面イメージ（ラフスケッチ）

第3段階：要件の確定と合意形成（最終段階）

目的: 要件の最終確認と合意

重点的に確認すべき項目

1. 要件の優先順位

   • Must（必須）、Want（希望）、Nice to have（あれば良い）の分類

   • 予算・期間の制約下での実現範囲

2. 運用・保守の考慮

   • システム運用体制

   • 保守・メンテナンス方針

   • ユーザーサポート体制

3. 移行・展開計画

   • データ移行方針

   • 段階展開の可否

   • ユーザー教育計画

第3段階での成果物例

• 要件定義書（最終版）

• 要件トレーサビリティマトリクス

• 開発計画書

• 合意確認書

よくある質問とその対処法

Q1: 「とにかく使いやすいシステムを作ってほしい」と言われた場合

問題: 抽象的すぎて具体的な要件に落とし込めない

対処法:

1. 具体例で確認: 「使いやすいというのは、例えばどのようなことでしょうか？」

2. 現状の問題点から逆算: 「現在のシステムで使いにくいと感じる点を教えてください」

3. 他社事例の活用: 「他社のこのようなシステムはいかがですか？」

Q2: ユーザーが技術的に不可能な要求をしてきた場合

問題: 予算や技術的制約で実現困難な要求

対処法:

1. 即座に否定しない: まずは要求として受け止める

2. 背景の確認: 「それはどのような課題を解決するためでしょうか？」

3. 代替案の提示: 「技術的には△△になりますが、〇〇という方法はいかがでしょう？」

Q3: 要求が頻繁に変わる場合

問題: 要件が固まらず、プロジェクトが進まない

対処法:

1. 変更理由の確認: なぜ変更が必要なのか背景を理解

2. 変更の影響を可視化: コスト・期間への影響を明確に提示

3. 変更管理ルールの設定: 変更申請のプロセスを明確化

Q4: 異なる部署から矛盾する要求が出た場合

問題: 部署間で利害が対立している

対処法:

1. 利害関係者の整理: 誰がどのような立場・権限を持つか確認

2. 上位目標の確認: 会社全体としての目標から判断

3. 調整会議の設定: 関係者を集めた調整の場を設ける

要件定義成功のための組織体制

クライアント側の体制整備

理想的な担当者の条件

1. 業務知識: 対象業務を深く理解している

2. 決定権限: 一定範囲内での意思決定ができる

3. コミュニケーション能力: 要求を明確に伝えられる

4. プロジェクト参加時間: 十分な時間を確保できる

体制整備のポイント

• プロジェクトオーナー: 最終決定権を持つ責任者の明確化

• 業務担当者: 実際の業務を行っている現場担当者の参加

• IT担当者: 技術的な観点からのサポート

• 承認者: 要件変更時の承認ルートの明確化

開発側の体制整備

必要なスキルを持つメンバー構成

1. ヒアリングスキル: 要求を正しく引き出す能力

2. 業界知識: クライアントの業界・業務への理解

3. 技術知識: 実現可能性を判断できる技術力

4. 文書化スキル: 要件を明確に文書化する能力

効果的な役割分担

• プロジェクトマネージャー: 全体統括・意思決定支援

• 業務アナリスト: 業務要件の整理・分析

• システムアーキテクト: 技術要件の検討・実現方式の提案

• コミュニケーター: ヒアリング・調整の専任担当

要件定義書の品質を上げるポイント

要件定義書に必要な要素

業務要件に関するもの

• 業務フロー図

• 業務ルール定義

• 組織・役割定義

• 業務量・頻度

システム機能要件に関するもの

• 機能一覧・機能概要

• 画面仕様書

• 帳票仕様書

• インターフェース仕様書

• データベース概要

非機能要件に関するもの

• 性能要件

• 可用性要件

• セキュリティ要件

• 運用・保守要件

要件定義書作成のコツ

分かりやすい記述のポイント

1. 専門用語の統一: 用語集を作成し、定義を明確化

2. 図表の活用: フローチャート、画面イメージ、データ構造図

3. 具体例の併記: 抽象的な説明には具体例を付ける

4. 段階的詳細化: 概要から詳細へと段階的に記述

レビュー・承認プロセス

1. 内部レビュー: 開発チーム内での確認

2. クライアントレビュー: 各部署での確認

3. 統合レビュー: 全体整合性の確認

4. 最終承認: 責任者による正式承認

トラブル回避のための進捗管理

進捗の可視化

具体的なステータス管理

進捗を示す際には「全体として半分程度進んでいる」といった曖昧な説明ではなく、「注文業務は完了。発注業務はレビュー待ち…」などというように作業の状態（ステータス）を具体的に明確化します。

進捗管理の例

業務領域 要件ヒアリング 要件整理 仕様確定 承認 ステータス 受注管理 ✓ ✓ ✓ ✓ 完了 在庫管理 ✓ ✓ ✓ - レビュー中 売上管理 ✓ ✓ - - 仕様検討中 請求管理 ✓ - - - 要件整理中

課題管理と解決

課題の分類と優先度設定

• クリティカル: プロジェクト続行に影響する重要課題

• ハイ: 仕様に大きく影響する課題

• ミディアム: 一部仕様に影響する課題

• ロー: 影響は軽微だが解決が望ましい課題

エスカレーションルール

1. 担当者レベル: 1週間以内に解決を試行

2. マネージャーレベル: 2週間以内に解決方針を決定

3. 幹部レベル: 1ヶ月以内に最終判断

まとめ：継続的な改善で成功を手に入れる

要件定義ヒアリング成功の3原則

1. 準備が成功の8割を決める

• 業界・業務知識の事前学習

• ヒアリング計画の詳細化

• 適切な体制・役割分担の構築

2. 相手の立場に立った傾聴と提案

• 要求の背景にある真のニーズの理解

• 技術的制約を考慮した現実的な提案

• 継続的な確認と合意形成

3. 文書化と可視化による認識共有

• 曖昧さを排除した明確な要件定義書

• 進捗と課題の可視化

• 定期的なレビューと軌道修正

よくある失敗パターンの回避法

「上滑りヒアリング」の回避

• 疑問点リストの作成と徹底的な解消

• 理解内容の言い換えによる確認

• 複数の観点からの検証

「堂々巡り議論」の回避

• 明確なゴール設定と完了基準

• 決定事項と未決定事項の明確な区別

• 優先順位に基づく段階的な決定

「要求の後出し」の回避

• 関係者全員の巻き込み

• 段階的な要件公開と確認

• 変更管理プロセスの確立

継続的なスキル向上

ヒアリングスキルの向上

• 日常会話での傾聴の実践

• 質問技術の習得と練習

• 業界知識の継続的な学習

文書化スキルの向上

• 論理的な文章構成の習得

• 図表を活用した表現力の向上

• 読み手を意識した分かりやすい記述

プロジェクト管理スキルの向上

• 進捗管理手法の学習

• リスク管理の実践

• ステークホルダー管理の強化

要件定義のヒアリングは、技術力だけでなく、コミュニケーション能力、業務理解力、そして継続的な改善意欲が求められる総合的なスキルです。本記事で紹介した手法を参考に、あなたのプロジェクトでも確実な成果を上げる要件定義を実現してください。

お問い合わせ: info@zetlinker.com

---

参考記事

• 要件ヒアリングのコツ：効果的な進め方と実践テクニック

• 要件定義の進め方は？効率的に進める方法や必要な項目を詳解

• 要件定義とは？具体例をあげながら手戻りを防ぐ進め方のコツ

• SEのための要件定義ガイド：ヒアリングの進め方と設計成功のコツ

• 要件定義のヒアリングコツまとめ：フォーマット・項目・実践法

• システム開発の要件定義：進め方やコツを実例付きで解説

• 要件定義を成功に導く進め方と定義書の書き方

• ITエンジニアを強くするヒューマンスキル講座：ヒアリング編

• 要件定義とは？基本的な進め方やポイント、必要なスキル解説

• 手戻りなしの要件定義：効果的なヒアリング手法とコツ