なぜ「要件がブレる」のか？業務理解・分解・ヒアリングを正しい順番で実践する完全ガイド

プロジェクトが始まってから「やっぱり仕様が変わった」「そんなこと聞いてない」を3回以上経験したあなたへ。この記事を読めば、業務をどう理解し・どう分解し・どうヒアリングすれば「ブレない要件定義」に近づけるか、具体的な手順と態度の両方が分かります。

📌 業務理解とは何か——「地図」を持たずに家を建てるな

突然だが、あなたは「設計書が完成した後に仕様が追加された」という経験はないだろうか。あるいは、リリース後に「これ、実際の業務とぜんぜん違うじゃないですか」と言われた経験は？

これらの失敗の多くは、業務を理解する前にシステムを考え始めてしまったことに根本原因がある。

業務理解とは、一言で言えば「その仕事が今どうやって回っているかを、自分の頭の中で再現できる状態になること」だ。

料理で例えるなら、レシピ（要件書）を書く前に、「この料理は誰がどんな場面で食べるのか」「今の調理場の設備はどうなっているか」「どの工程がボトルネックになっているか」を把握することに相当する。この下準備を飛ばして、いきなり「では鍋を用意してください」と伝えるから、ちぐはぐな料理ができあがるわけだ。

業務理解には大きく3つのフェーズがある。

この順番を守ることが、手戻りを減らす最大の近道だ。

🔍 動機：「業務をわかっているつもり」が一番危ない

エンジニアが陥りがちな罠は、「ヒアリングをすっ飛ばしてシステムの話を始めてしまう」ことだ。気持ちはよくわかる。システムの話なら慣れているし、議論が盛り上がる。「こういう機能を作ればどうですか？」という提案は、確かに喜ばれる。

しかし現実は厳しい。現場の担当者は「今の業務が頭に染み付きすぎていて、暗黙の前提を言語化できない」ことが多い。「そんなの当たり前でしょ」と思っていることほど、ヒアリングでこぼれ落ちる。

筆者が過去に携わったプロジェクトでは、「月次の集計は手動でExcelでやっている」という事実を3ヶ月後に初めて知って、設計の半分をやり直した苦い思い出がある。最初の1時間のヒアリングで「Excelで何かやってることはありますか？」と聞いていれば、防げたはずの事態だ。

🗺️ 業務理解・分解の全体フロー

進め方を俯瞰すると、以下のような流れになる。コーヒーを用意して、ゆっくり眺めてほしい。

重要なのは、Phase 0（スコープ確認）を飛ばして Phase 1（現場ヒアリング）から始めないことだ。誰に話を聞けばいいかを決めずにヒアリングを始めると、「担当者Aが言っていたこと」と「担当者Bが言っていたこと」が矛盾して、どちらが正しいか分からなくなる地獄に落ちる。

🔬 Step 1：まず「鳥の目」で全体を掴む

最初にやることは、業務の全体地図を作ることだ。細部に入る前に、どこからどこまでが今回の対象なのかを確認する。

「鳥の目」で見るとは、たとえば「受注管理システムを作る」という依頼を受けたとき、「受注だけ」で完結しているわけではないことに気づく視点を持つことだ。受注の前には「見積もり」があり、後には「在庫確認」「出荷」「請求」がある。これらを一枚の図に収めて、今回のスコープがどの範囲なのかを赤枠で囲む。

この「業務プロセス関連図」を最初のMTG前に仮でも作っておくと、ヒアリングが格段にスムーズになる。なぜなら、「私の理解ではこの赤枠が対象ですが、合っていますか？」という質問ができるからだ。相手が「いや、請求まで含めてほしい」と言えば、スコープの誤解をこの時点で潰せる。

確認すべき3つの問いは次の通りだ。

• 誰がこの業務に関わっているか（ステークホルダーの特定）
• どこからどこまでが今回の対象か（スコープの境界確認）
• 何が「外側」にあるか（スコープ外の接続システム・部署の確認）

🔬 Step 2：3つの階層で業務を分解する

全体像が掴めたら、次は業務を3段階に分けて掘り下げる。ここが業務分解の核心だ。

階層のイメージは「Google Mapsのズームイン」に近い。最初は日本全体が見えていて、ズームするたびに都市・街・建物と詳細になっていく。業務フローも同じ構造で考える。

第1階層：業務プロセス関連図（俯瞰レベル）

「受注管理」「在庫管理」「出荷管理」のような大きな粒度で業務を並べる。このレベルでは「どの業務がスコープ内か」だけを確認する。細部に入ってはいけない。

第2階層：業務フロー（現場レベル）

スイムレーン形式（泳ぐコースのように、担当者ごとに横に区切ったフロー図）で、「誰が・いつ・何をするか」を時系列に並べる。ここで重要なのは、正常系だけでなく例外処理も書くことだ。「在庫がなかったら？」「承認が通らなかったら？」という「if」の分岐を漏れなく拾う。

第3階層：システム化業務フロー（システム設計レベル）

第2階層の業務フローに「どの画面を使って」「どのデータを操作するか」を書き込んだもの。ここまで来て初めてシステムの話ができる。逆に言えば、このレベルに至る前にシステムの議論を始めるのは早すぎる。

🔬 Step 3：As-Is の「課題」をRAカードで構造化する

業務フローが描けたら、次は「現状の何が問題なのか」を掘り下げる。このとき役立つのが、RAカード（Problem / Impact / Root Cause / Desire の4項目フレーム）だ。

日立製作所が要件定義の実務で活用していることで知られるこの手法は、以下の4軸で問題を整理する。

ポイントは「影響」と「原因」を表面で止めないことだ。「入力ミスが多い」という問題に対して「なぜ？」を3回繰り返すと、根本原因（基幹システムとExcelの分断）にたどり着く。根本原因を潰さずに表面的な対策（入力チェック機能の追加）だけで済ませると、後から「やっぱり足りない」と言われる原因になる。

👂 ヒアリングの設計——「質問は武器、使い方を間違えると自爆する」

業務を理解するうえで、ヒアリングは欠かせない。しかし「なんとなく質問する」のと「設計された質問をする」のとでは、得られる情報の質が天と地ほど違う。

ヒアリングは3段階のプロセスで構成されている。

1. 実施（Conduct）：相手の声を収集する
2. パース（Parse）：曖昧な言葉を具体的な構造に変換する
3. 抽出（Extract）：言葉の裏にある真意・ニーズを引き出す

多くのエンジニアが苦手にしているのは「2. パース」と「3. 抽出」だ。「いい感じにお願いします」「使いやすくしてほしい」という言葉を、そのまま受け取ってしまう。「いい感じ」とは何秒以内の応答速度なのか、「使いやすい」とは操作ステップが何ステップ以内なのかを、数字と条件で引き出す作業がパースだ。

質問の設計：オープンとクローズドを使い分ける

質問には大きく2種類ある。

オープンクエスチョン（開かれた質問）は、「どのような〜ですか？」「なぜ〜なのでしょうか？」のように、相手が自由に話せる形式だ。ヒアリングの序盤に使う。相手の思考の全体像を引き出せる。

クローズドクエスチョン（閉じた質問）は、「AとBのどちらですか？」「月に何件くらいですか？」のように、答えを絞り込む形式だ。具体的な数値・条件・優先順位を確認するときに使う。

実務では、「オープン→深掘り→クローズドで確認」の流れを意識するとよい。まず広く話してもらい、出てきた重要なキーワードを「それは具体的に〜ということですか？」と掘り下げ、最後に「つまり〜という理解で合っていますか？」で確認する。

🤝 ヒアリングの「態度」——テクニックより先に土台を作れ

ここまで「方法」の話をしてきたが、正直なところ、態度がテクニックに勝る場面は多い。

どんなに洗練された質問設計があっても、相手が「この人に話しても無駄だ」「評価されそうで怖い」と感じた瞬間、ヒアリングは形式的なものになる。特に現場担当者は「システムのことなんてわからない」「余計なことを言って仕事が増えたら困る」という防衛本能を持っていることが多い。

話す2割・聞く8割

ヒアリングは「聞く場」であって「提案する場」ではない。自分が話すのは全体の2割程度を目安に。エンジニアはつい「だったらこういう機能を作れば解決できますよ」と提案したくなるが、それはまだ早い。相手の話を8割聞いた後に、初めて仮説を添えて確認する形が適切だ。

「評価しない」姿勢を体で示す

「今の業務で非効率だと思っていることはありますか？」という質問に、担当者は「自分の仕事を批判されると思われないか」と身構えやすい。そのため、「こうするべきでした」「それは問題ですね」という評価・判断の言葉を使わないことが重要だ。代わりに「なるほど、それはなぜそのやり方になったんでしょう？」と背景を聞く形にすると、相手が防衛モードから離れやすい。

ミラーリング・ペーシング・バックトラッキングの3原則

心理学に基づく傾聴スキルに、ミラーリング（相手の動作・姿勢に自然に合わせる）・ペーシング（話すスピード・トーンを合わせる）・バックトラッキング（相手の言葉をそのまま繰り返す）の3つがある。

特にバックトラッキングは即日から使える。「月10件のミスが出ています」と言われたら「月10件のミスが出ているんですね」と繰り返す。たったそれだけで「ちゃんと聞いてもらえている」という安心感を相手に与えられる。

仮説を持って臨む・でも握りしめない

「何も知らない状態でフラットに聞く」は理想だが、実際には無理だ。事前に業務の仮説を立て、「おそらくこういう流れで動いているのでは？」という仮設計図を持ってヒアリングに臨んだ方がよい。なぜなら、仮説があると「そこが違う」という反応を引き出せるからだ。

ただし仮説を「正解」だと思い込んではいけない。仮説はあくまで「確認のための道具」だ。相手が「いや、そうじゃなくて」と言ったとき、素直に修正できる柔軟さが求められる。

🔥 ハマりポイント：やりがちな3つの過ち

その1：「システム要件から聞いてしまう」罠

「どんな機能が欲しいですか？」という質問から入るのは要注意だ。現場担当者は業務の専門家であって、システムの専門家ではない。「検索機能が欲しい」と言われたとき、それは「大量データの中から素早く見つけたい」という業務ニーズを言い換えたものかもしれない。まず業務ニーズを聞き、機能要件はその後に変換して提示する順序が正しい。

その2：「最も声の大きい人の話だけ聞く」罠

プロジェクトには必ず「よく喋る人」がいる。その人の言うことを要件にしがちだが、実際の業務は複数の担当者が関わっていることが多い。「Bさんにも同じことを確認しましたか？」と複数の視点から検証することが、矛盾の発見につながる。

その3：「聞いたことは聞いた通りに正しい」思い込み

担当者の話を鵜呑みにするのは危険だ。現場の人間は「今やっていること」を語るのは得意だが、「なぜそうなっているか」の背景や、「本当はこうしたい」という願望を自分でも意識できていないことがある。「言葉の裏にある真のニーズは何か？」という問いを常に持ちながら聞くことが重要だ。筆者はここで何度も「聞いたのに作ったら違った」を経験した。お互い気をつけよう。

💡 活用事例：「現場に行くのが怖かったエンジニア」が変わった話

ある中堅SIerのエンジニアAさんは、技術力は高いが「ヒアリングが苦手」という悩みを持っていた。特に「現場のおじさんたちが専門用語で話してくれない」ことに戸惑っていた。

変化のきっかけは、ヒアリングの前に「業務プロセス関連図の仮版」を自分で作って持参したことだ。「私の理解ではこういう流れだと思うんですが、違うところを教えてください」と見せた瞬間、現場担当者の反応が変わった。「違う違う、ここはこうなってる」「この矢印の間にもう一個ステップがある」と、向こうから情報を出してくれるようになったのだ。

空白の質問票に答えてもらうより、仮説の地図を見せて「間違いを指摘してもらう」方が、圧倒的に情報が引き出せる。これはAさんが「ヒアリングが怖くなくなった」転機だったと語っている。

✅ 要点まとめ

業務理解・分解・ヒアリングの核心を絞ると、次の7点に集約される。

1. 順番を守れ：スコープ確認 → As-Is把握 → 課題分析 → To-Be定義の順。システムの話は最後。

2. 3階層で分解する：俯瞰図 → 業務フロー → システム化フローの粒度で段階的に掘り下げる。

3. 「なぜ？」を3回繰り返す：問題の表面で止まらず、根本原因まで掘り下げる（RAカード活用）。

4. 質問はオープン→クローズドの順：広く話してもらった後に絞り込む。いきなり「AかBか」では情報が死ぬ。

5. 8割聞く：ヒアリングは提案の場ではなく、情報収集の場だ。

6. 仮説の地図を持参する：空白から質問するより、仮設計図を見せて「間違いを指摘してもらう」方が情報が引き出せる。

7. 評価しない：「それは問題ですね」という判断の言葉を使わない。相手の業務の背景・事情に好奇心を向ける。

🚀 取り込み方：明日から始める業務理解の3ステップ

今日（30分でできること）

次のヒアリングに向けて、「業務プロセス関連図（仮版）」をA4一枚でいいので書いてみる。自分が理解している業務の流れを箱と矢印で描き、「スコープ外」の領域も含めて全体像を可視化する。これだけでヒアリングの質が変わる。

今週

RAカード（問題・影響・原因・願望）のフォーマットを作り、次のヒアリング後に埋めてみる。特に「影響」欄は「だから何？」を3回繰り返して経営レベルの話につなげてみること。

今月

実際のヒアリングで「話す2割・聞く8割」を意識した録音（許可を取ること）を振り返り、自分が話しすぎていないかを確認する。バックトラッキングを意識的に使い、「相手が話しやすそうにしているか」を観察する。

📅 今後の展望：AIがヒアリングを補助する時代が来ている

2026年現在、生成AIを活用した「ヒアリング支援ツール」が台頭しつつある。録音した会話を自動でRAカード形式に整理し、課題・原因・要件候補を抽出するツールや、業務フロー図を自動生成するサービスが登場している。

ただし、重要なのはこれらのツールは「補助」であって「代替」ではないという点だ。AIは「言葉として発されたこと」は処理できるが、「担当者の表情が曇ったとき」「言いよどんだとき」に隠れている重要情報は拾えない。業務理解の本質は、相手との信頼関係の上に成り立つ人間的なプロセスだ。AIがどれだけ進化しても、「ヒアリングの態度」を磨く価値はなくならないと考えられる。

まとめ

この記事を読んだあなたは、業務理解・分解・ヒアリングの「正しい順番」と「正しい態度」の両方を手に入れた。次のプロジェクトで「要件がブレた」となったとき、どのフェーズで何が足りなかったかを診断できるはずだ。

業務を理解するとは、技術的なスキルより先に「相手の仕事に敬意と好奇心を持つ」姿勢から始まる。ヒアリングに慣れてきたエンジニアが口をそろえて言うのは、「現場に行くのが楽しくなった」という言葉だ。業務を深く理解できた瞬間の達成感は、コードがきれいに動いたときのそれと、また違う種類の満足感がある。

ぜひ、次のMTG前に「仮の業務プロセス関連図」を一枚書いてみてほしい。

参考文献

• [要件定義工程の進め方

  若手エンジニアの羅針盤](https://pm-rasinban.com/rd-process)

• [業務フローの書き方完全ガイド｜3つの階層で機能漏れ・手戻りを防ぐ実践術

  IT覚え書き oboegakIT](https://oboegakit.blog/three-workflows/)

• [1からわかる要件定義：ヒアリング【中編】深掘り術

  ecomottblog](https://www.ecomottblog.com/?p=23081)

• [As Is / To Beフレームワークとは？分析のやり方や活用例を解説

  カオナビ人事用語集](https://www.kaonavi.jp/dictionary/as_is_to_be/)

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

  studio-tale](https://studio-tale.co.jp/career-stories/guide/se-requirements-definition/)

• [要件ヒアリングのコツ

  Takashi Suda / かんた](https://note.com/sudatakashi/n/n6dcf725a2857)

• [ビジネスシーンにおける「ヒアリング」とは？悩みを引き出すコツ

  pro-seeds](https://www.pro-seeds.com/saleste/blog/hearing/)

• [傾聴とは？意味や三原則、具体的な実践方法

  アドバンテッジJOURNAL](https://www.armg.jp/journal/323-2/)