「何かお困りのことはありますか」
ある製造業の生産管理担当者は、システム開発会社の担当者からそう聞かれて、少し考えてからこう答えた。「特にないですね。今のやり方でなんとか回っていますから」。ヒアリングは30分で終わった。議事録には「現状特に大きな課題なし。効率化を希望」とだけ書かれていた。
半年後、新しい生産管理システムが完成し、現場に導入された。使い始めて三日で、現場のベテラン作業員から不満が噴き出した。「なんで在庫の引き当てを手動で確認しなきゃいけないんだ」「朝一番に前日の出荷実績を一覧で見たかったのに、画面を三回タップしないと出てこない」「そもそも紙の指示書と併用前提で作ってたのに、システムはそれを想定してない」。一つ、二つではない。山のような不満が、ヒアリングでは一言も出てこなかった不満が、完成後になって初めて姿を現した。
発注担当者は困惑した。「あのときちゃんと聞いたのに」。その通りだ。聞いた。だが、聞き方が本音を引き出す設計になっていなかった。この記事は、その「聞き方」そのものを扱う。要件定義書に何を書くべきかという話ではなく、要件定義の前段階、現場から本当の情報を引き出すためのヒアリングの技術についての話だ。
なぜ「困っていることは？」では本音が出てこないのか
「困っていることはありますか」という質問は、一見すると誠実で開かれた問いに見える。だが現場の人間にとって、この質問には答えにくい理由がいくつも重なっている。
第一に、抽象度が高すぎる。人は日々の業務の中で、無数の小さな不便と折り合いをつけながら働いている。それらは意識の表面に浮かんでいない。「困っていること」を聞かれても、日常に溶け込んでしまった不便は思い出せない。人間の記憶は、抽象的な問いに対しては抽象的にしか答えられない。具体的な場面を提示されて初めて、そこに紐づいた記憶が引き出される。
第二に、質問の主語が曖昧だ。「困っていること」は誰にとっての困りごとなのか。自分個人の作業か、チーム全体の業務か、会社の経営課題か。現場の担当者は、経営層や外部の人間を前にすると、無意識のうちに「会社にとって重要そうなこと」を答えようとしてしまう。結果、自分の作業レベルでの小さな不満は「言うほどのことではない」と判断され、口に出されないまま消えていく。
第三に、その場での即興回答を強いている。人間は準備なしに複雑な業務プロセスを言語化することが苦手だ。特に長年その仕事に慣れている熟練者ほど、自分の作業を無意識化・自動化しているため、いざ言葉にしようとすると「うーん、特にないですね」という反応になりやすい。これは本音を隠しているのではなく、単に想起の準備ができていないだけのことが多い。
つまり「困っていることは？」という質問が引き出せなかったのは、現場の人間に問題があったのではない。質問の設計に問題があったのだ。壁を越えて現場と経営をつなごうとする担当者が本当に向き合うべきは、相手の口の重さではなく、自分の質問の立て方である。
本音を引き出すための質問の技術
本音を引き出すヒアリングには、いくつかの共通した技術がある。ここでは実務で使える具体的な問いのパターンを紹介する。
抽象的な問いではなく、一日の流れを具体的に聞く
最も効果的なのは「困っていることは？」ではなく「今日の朝、出社してから最初に何をしますか」と聞くことだ。そこから「その次は？」「その作業にはだいたい何分くらいかかりますか」「その情報はどこから取ってきますか」と、時系列に沿って一つひとつ具体的に追いかけていく。
先の生産管理担当者の例で言えば、「朝一番に前日の出荷実績を確認する」という作業は、抽象的に聞かれれば「特に困っていない」ものだった。しかし「朝、出社して最初に何をしますか」と聞かれれば、「まず紙の帳票を出力して、Excelの実績表と突き合わせて、差異があれば倉庫に電話で確認する」という具体的な行動が出てくる。この時系列の中にこそ、システム化すべき業務の実態が埋まっている。
一日の流れを聞くことのもう一つの利点は、非エンジニアの発注担当者自身にとっても理解しやすいという点だ。抽象的な業務フロー図を読み解く必要はない。相手の一日をそのまま追体験するだけでいい。
「困っていること」ではなく「今どうしているか」を聞く
「困っていることは？」という質問を、「今、その作業はどうやってやっていますか」という質問に置き換えるだけで、返ってくる情報の量と質は大きく変わる。
「今どうしているか」という問いは、評価を求めていない。良いとも悪いとも言わせず、事実だけを述べればいい問いだ。答える側の心理的なハードルが一気に下がる。そして「今どうしているか」を丁寧に聞いていくと、自然と非効率な部分、二重入力になっている部分、属人化している部分が浮かび上がってくる。それを指摘するのは現場ではなく、聞き手であるあなたの仕事だ。
例えば「在庫確認はどうしていますか」と聞いて「Excelで管理してます」という答えが返ってきたら、そこで終わらせない。「そのExcelは誰が更新しますか」「更新のタイミングは」「複数の人が同時に見ることはありますか」「更新が漏れたときはどう気づきますか」と、一段深く掘り下げる。この掘り下げの中に、後になって「本当はこうしてほしかった」という不満の種が眠っている。
「もし〇〇だったら」で仮定の負担を取り除く
変化への提案を歓迎しない現場も多い。そこで「もし今の仕組みを全部変えられるとしたら、何を変えたいですか」という仮定の質問が効く。仮定の質問は、現実の制約から相手を一時的に解放する。今の会社の予算やシステムの都合を気にせず、理想を語ってもらう余地を作る。
ただし、この質問だけでは終わらせない。理想を聞いたあとに「その中で、今一番現場が困っているのはどれですか」と優先順位を聞くところまでがセットだ。理想と現実的な優先順位、その両方を押さえることで、要件定義の土台になる情報が揃う。
数字を聞く
「その作業は一日に何回発生しますか」「一件あたりどのくらい時間がかかりますか」「月末は特に増えますか」といった数字を聞くことも重要だ。数字は感情を伴わない事実であり、現場の人間も答えやすい。そして数字を積み上げていくと、どの業務がボトルネックになっているか、どこにシステム投資の効果が最も出るかが客観的に見えてくる。「なんとなく面倒」という感覚的な不満を、「一日15回、一回あたり3分」という定量情報に変換することが、要件の優先順位づけの土台になる。
現場が話しにくい理由への配慮
質問の技術だけでは不十分なこともある。現場が本音を話さない背景には、質問の設計とは別の、心理的な壁が存在するからだ。
一つは評価される不安だ。「今のやり方に不満がある」と言うことは、裏を返せば「今までのやり方が非効率だった」と認めることに近い。特にその業務フローを長年作り上げてきた本人や、その上司が同席している場では、率直な不満を口にすることが自分自身への評価につながりかねないという緊張が生まれる。この不安を取り除くには、ヒアリングの冒頭で「今のやり方が悪いという話ではなく、次のシステムをより現場に合ったものにするための情報収集です」と目的を明確に伝えることが有効だ。可能であれば、上司や決裁者を同席させずに現場担当者だけで話を聞く時間を作ることも検討したい。
もう一つは変化への抵抗だ。新しいシステムが入ることで、自分の仕事のやり方が変わる、あるいは自分の役割そのものがなくなるかもしれないという不安を抱く現場の人間は少なくない。この不安を抱えたまま質問されると、「余計なことを言うと自分の仕事が奪われるかもしれない」という防衛的な姿勢になり、本音は語られない。この場合は、システム導入の目的が人員削減ではなく、日々の負担軽減であることを丁寧に説明し、現場の声がシステムの設計に直接反映されるのだと伝えることが安心材料になる。
さらに見落とされがちなのが、過去の失敗体験だ。以前にも別のシステムを導入した際、現場の意見を聞いたはずなのに全く反映されなかった、という経験がある職場では、現場は「どうせ言っても変わらない」という諦めを抱えている。この諦めを溶かすには、時間はかかるが、聞いた内容を必ず要件定義書やシステム設計に反映し、それを現場にフィードバックするプロセスを見せることが最も効果的だ。話を聞くだけでなく、聞いた結果がどう反映されたかを見せることまでが、ヒアリングという行為の一部だと捉えたい。
現場と経営の間に立つ担当者の仕事は、ときにどちらからも十分に理解されない孤独な役割だ。だが、この配慮を一つひとつ積み重ねる姿勢こそが、単なる情報収集の担当者ではなく、現場の信頼を勝ち取る橋渡し役への一歩になる。
ヒアリングで集めた情報の整理方法
ヒアリングを重ねると、断片的なメモが大量に蓄積される。これを放置すると、後になって「あれ、誰が何を言っていたか分からない」という状態に陥る。集めた情報は、次の三つの軸で整理すると要件定義につながりやすい。
- 業務フロー軸で整理する。誰が話したかではなく、一日の業務の流れに沿って、聞き取った内容を時系列に並べ直す。これにより、複数の担当者から聞いた話が一枚の業務フロー図として統合され、部門を横断した業務の全体像が見えてくる。
- 事実と要望を分けて記録する。「今どうしているか」という事実情報と、「こうしてほしい」という要望情報は、性質が異なる。事実は業務フローの理解に使い、要望は要件の候補リストとして別立てで管理する。混在させると、後で優先順位をつける際に事実と願望の区別がつかなくなる。
- 頻度と影響度でタグをつける。聞き取った要望や課題それぞれに、「どのくらいの頻度で発生するか」「発生したときの業務への影響はどの程度か」を簡単なタグとして付けておく。これにより、複数の現場から集まった情報を横断的に比較し、システム化の優先順位を客観的な根拠を持って議論できるようになる。
整理した情報は、必ず一度、ヒアリング対象者に見せて確認を取ることも忘れずにいたい。「こういう理解で合っていますか」と確認するプロセスそのものが、現場に対して「あなたの話はちゃんと聞かれている」というメッセージになり、次のヒアリングへの協力度も変わってくる。
よくある失敗パターン
最後に、現場ヒアリングで陥りがちな失敗パターンをいくつか挙げておく。冒頭の事例のように、失敗の多くはヒアリングの「その場」ではなく、システム完成後に初めて表面化する。だからこそ、事前に知っておく価値がある。
- 声の大きい人の意見だけを聞いてしまう。管理者や声の大きいベテランの意見だけを聞いて満足してしまい、実際に日々その業務を手を動かして行っている担当者の声を聞き逃すケースは非常に多い。役職の上下に関わらず、実務を担う全員から話を聞く設計にすることが重要だ。
- 一回のヒアリングで終わらせてしまう。一度きりのヒアリングで全ての情報が出揃うことはまずない。最初のヒアリングで出てくるのは表面的な情報にとどまることが多く、二回目、三回目と重ねる中で、より深い本音や、最初は思い出せなかった細かい業務の実態が出てくる。
- 繁忙期と閑散期の差を聞き漏らす。月初と月末、繁忙期と閑散期で業務の負荷や優先順位が大きく変わる現場は多い。ヒアリングを一つの時期だけで済ませると、変動する業務の実態を見落とし、繁忙期に使えないシステムができあがってしまう。
- 例外処理を聞かない。「通常はこう」という業務フローだけを聞いて満足し、「イレギュラーが起きたときはどうするか」を聞き漏らすケースも多い。実は現場の負担の多くは、この例外処理にこそ潜んでいる。
- ヒアリング結果を発注担当者だけで抱え込む。現場から聞いた情報を、発注担当者が自分の解釈でまとめてから開発会社に伝えると、その過程で重要なニュアンスが失われることがある。可能であれば、開発会社の担当者にもヒアリングの場に同席してもらい、一次情報を直接聞いてもらうことが望ましい。
まとめ
「何か困っていることはありますか」という一言では、現場の本音は出てこない。それは現場の人間が不誠実だからではなく、質問の設計が本音を引き出す構造になっていないからだ。一日の流れを具体的に聞くこと、「今どうしているか」という事実を積み重ねること、仮定の質問で理想を語ってもらうこと、数字で裏付けを取ること。これらの技術を組み合わせることで、表面には出てこなかった不満や要望が姿を現す。
そして、質問の技術と同じくらい重要なのが、現場が話しにくい理由への配慮だ。評価される不安、変化への抵抗、過去の失敗体験。これらを理解し、丁寧に取り除いていく姿勢がなければ、どれだけ優れた質問を投げかけても、心を開いてもらうことはできない。
現場と経営の間に立ち、双方の言葉を翻訳し、本音を形にしていく。それは地味で、時に孤独な作業だ。だが、そこに丁寧に向き合った先にこそ、完成後に「本当はこうしてほしかった」という不満が噴き出すのではなく、「よく分かってくれていた」と言われるシステムが生まれる。ヒアリングは、要件定義書を書く前の準備作業ではない。壁を越えて現場の声を経営に届けるという、システム発注担当者にしかできない仕事そのものなのだ。