業務ヒアリングの進め方とは？FDEが現場で課題を掘り当てる手順と質問術

業務ヒアリングとは？目的と要件定義との違いは？

業務ヒアリングは、現場の業務と困りごとを聞き取り、解くべき課題を特定するための活動です。システム開発やDX推進の最初の工程として扱われることが多いものの、その役割は「話を聞くこと」だけにとどまりません。業務の流れ、判断の基準、例外への対応、関わる人の力関係まで含めて把握し、「どこに手を入れると効果が大きいか」を見極めることが業務ヒアリングの本質です。

業務ヒアリングの目的は何か

目的は、何を作るかを決める前に、何が本当の問題なのかを現場の事実から確かめることです。依頼者が最初に言う「こういうツールが欲しい」は、多くの場合は解決策の案であり、課題そのものではありません。たとえば「Excelの集計を自動化したい」という要望の裏に、「集計結果を翌朝の会議に間に合わせられない」という時間の制約がある、といった形です。業務ヒアリングは、要望の奥にある制約と目的を掘り当てる作業だといえます。

要件定義との違いは何か

要件定義は解決策の仕様を決める工程で、業務ヒアリングはその前に課題のありかを見極める工程です。両者は連続していますが、問いの立て方が異なります。

現場の実務者としての実感を言えば、手戻りの原因の多くは要件定義の書き方ではなく、その前のヒアリングで課題を取り違えたことにあるように思います。

FDEの業務ヒアリングは何が違う？Palantir型の現場主義とは？

FDEのヒアリングは、会議室で聞いて終わりではなく、現場に入って観察と試作を行き来しながら課題を掘る点が違います。FDE（Forward Deployed Engineer）は顧客の現場の近くで働くエンジニアで、ヒアリング、データ理解、実装、運用定着までを一人または少人数で担うのが特徴です。そのため業務ヒアリングも「開発前の一工程」ではなく、開発と並行して何度も繰り返す活動になります。

Palantir型の現場主義とは

Palantir型の現場主義とは、エンジニアが顧客の現場に入り込み、実データと実業務のそばで課題を定義する考え方です。Palantirは公式ブログなどで、Forward Deployed Software Engineerが顧客組織と直接向き合って課題を特定し、自社プラットフォームを使ってその場で解決策を組み立てる働き方を紹介しています。ここで大事なのは、課題を聞いてから本社に持ち帰って設計するのではなく、現場で動くものを見せながら課題の輪郭をはっきりさせていくという順序です。

従来型ヒアリングとFDE型ヒアリングの比較

従来型は「聞いて持ち帰る」、FDE型は「聞いて、見て、その場で小さく作って確かめる」が基本の動きです。

実装できる人がヒアリングする利点は、「それは技術的にすぐできる」「そこはデータが無いと難しい」とその場で判断できることです。ただし、エンジニアは解決策を先に思いつきやすいので、後で述べる失敗パターンに注意が必要です。

業務ヒアリングはどんな手順で進める？準備から合意形成までの流れは？

業務ヒアリングは、事前準備、現場観察、深掘り質問、合意形成の4段階で進めると抜け漏れが減ります。各段階の目的とアウトプットは次のとおりです。

準備段階でやること

準備では、既存資料と関係者を洗い出し、ヒアリングで確かめたい論点を事前に3〜5個に絞り込みます。業務マニュアル、帳票、システムの画面、過去の改善の経緯などに目を通し、用語集を作っておくと当日の聞き返しが減ります。あわせて、決裁者、現場リーダー、実作業者、周辺部門を分けた関係者マップを作り、誰に何を聞くかを決めておきます。

当日の進め方と観察のポイント

当日は、業務の目的、流れ、例外の順に聞き、そのあと実際の作業を横で見せてもらうのが基本です。進め方の一例は次のとおりです。

1. ヒアリングの目的と所要時間、記録の扱いを最初に伝える
2. 担当業務のゴール（誰に何を届けるか）を聞く
3. 直近の具体的な1件を例に、作業を時系列で説明してもらう
4. 例外やトラブルが起きたときの対応を聞く
5. 可能であれば実際の画面や作業を見せてもらう
6. 聞いた内容を要約して読み上げ、認識違いがないか確かめる

「説明された手順」と「実際の作業」がずれていることは珍しくありません。ずれている箇所こそ、属人化や非効率が潜んでいる場所である可能性が高いといえます。

合意形成までの流れ

合意形成では、課題の仮説を小さな試作や数値で確かめてから、優先順位を関係者と一緒に決めます。ヒアリング直後に課題一覧を出すよりも、簡単なダッシュボードや自動化のモックを見せて反応を確かめてから議論するほうが、話が具体的になりやすいと感じます。

業務ヒアリングでは何を質問すればよい？使える質問の型は？

質問は「事実」「頻度と影響」「理由の深掘り」「例外」の4つの型を使い分けると、課題を掘り当てやすくなります。

事実を引き出す質問の型

事実を引き出すには、「普段どうしていますか」ではなく「直近の1件ではどうしましたか」と過去の具体的な出来事を聞きます。Rob Fitzpatrickの著書『The Mom Test』（2013年）でも、仮定の質問や意見を求める質問は当てにならず、過去の具体的な行動を聞くべきだと説かれています。「このツールがあったら使いますか？」と聞けば多くの人は「使うと思う」と答えますが、それは実際に使うかどうかの根拠にはなりません。

深掘りの質問と例外の聞き方

深掘りは「なぜ」を重ねて目的までさかのぼり、例外は「うまくいかなかったとき」を聞いて見つけ出します。トヨタ生産方式で知られる「なぜなぜ分析」の考え方は業務ヒアリングにも使えます。ただし「なぜ」を立て続けに聞くと問い詰められているように感じさせるので、「それをしないと何が起きますか」「その作業の結果は誰が使いますか」のように言い換えるのがおすすめです。例外処理は、業務の自動化やシステム化で最も見落とされやすい部分です。

避けたほうがよい質問

誘導する質問、はい・いいえで終わる質問、解決策を前提にした質問は、得られる情報を狭めるので避けます。「手入力は大変ですよね？」と聞けば、相手は同意するだけで終わります。「その入力作業で一番時間がかかるのはどこですか？」と開いた形で聞くほうが、思いがけない事実が出てきやすくなります。

業務ヒアリングでよくある失敗は？避けるためのコツは？

よくある失敗は、解決策を先に語る、一部の人にしか聞かない、例外を見落とす、の3つにほぼ集約されます。

よくある失敗パターン

失敗の多くは聞き方の技術よりも、ヒアリングの設計と聞き手の姿勢から生まれます。

失敗を避けるためのコツ

コツは、聞き手が話す時間を減らし、観察と要約の確認を習慣にすることです。エンジニア出身の聞き手は、相手の説明の途中で解決策を思いつき、つい口にしてしまいがちです。思いついた案はメモに書き留めるだけにし、面談では相手の業務を理解することに集中するほうが、結果として良い提案につながりやすいと感じます。また、面談の最後に「今日伺った内容を3点にまとめると〜という理解で合っていますか」と確認するだけでも、認識違いはかなり減らせます。

ヒアリング結果はどうまとめる？次の打ち手につなげる方法は？

ヒアリング結果は、事実・解釈・仮説を分けて記録し、優先度を付けた課題一覧として関係者と合意します。まとめ方の質が、次の打ち手の質をほぼ決めます。

事実と解釈を分けて記録する

記録は「相手が実際に言ったこと・見たこと」と「聞き手の解釈」を分けて書くことが基本です。たとえば「月末に3人が集計作業をしている」は事実、「集計が属人化している」は解釈、「集計を自動化すれば月末の残業が減る」は仮説です。この3つが混ざると、後から別のメンバーが読んだときに、どこまでが確かな情報なのか判断できなくなります。

次の打ち手につなげる方法

次の打ち手は、影響の大きさ、発生頻度、実現しやすさの3つの軸で課題を並べ、上位のものから小さく試すことで決めます。FDE型の進め方では、優先度の高い課題について短い期間でプロトタイプを作り、現場に触ってもらって再びヒアリングする、というループを回すのが特徴です。課題一覧は一度作って終わりの成果物ではなく、ループのたびに更新していく作業台帳として扱うのがよいでしょう。

業務ヒアリングは、FDEにとって技術力と同じくらい価値を左右するスキルです。現場の事実に根ざして課題を定義できれば、Palantir型の「現場で作り、現場で確かめる」働き方の土台になります。まずは次の面談で、「直近の1件を例に教えてください」という質問から試してみてください。

姉妹メディアの関連記事