「何に困ってますか」と聞いても、AIの使い道は出てこない

AI活用を進めるとき、多くの会社が最初にやることがあります。
現場への困りごとヒアリングです。

何に困っていますか、どの業務に時間を取られていますか。
アンケートを配ることもあります。
自分も同じことをやりました。

新規事業の検証で顧客に話を聞くときも、業務フローを整理するために現場に入るときも、やり方は同じでした。

回収した答えを並べて、気づいたことがあります。
多くが聞く前から想像できた内容でした。
転記が面倒、資料を探すのに時間がかかる、報告資料の作成が重い。どれも嘘ではありません。
簡単に本質的なところまでは出てきませんでした。

問題は現場の答えではなく、こちらの聞き方のほうにありました。
今回は、AI活用のニーズをどう集めるかについて、私が今使っている手順を共有したいと思います。

困りごとを聞いても出てこない理由

なぜ想像の範囲を超えないのか。3つの構造があると思っています。

1つ目は、人は自分の業務の当たり前を、課題として認識できないことです。
毎日繰り返している転記も、複数の画面を行き来する確認も、本人にとっては業務そのものです。
迂回路を通っている自覚がないので、困りごととして言葉になりません。
困っているかと聞かれれば、慣れました、と答えることになります。
やっている人たちだからこそ見えていないことがあります。
私はここを何度も見誤りました。

2つ目は、AIで何ができるかを知らないので、知っている解決策の言葉に寄せて答えることです。
転記を減らしたい、検索を速くしたい。
これは今使っているツールの改善要望であって、AIの使い道ではありません。
人は自分の知っている手段の範囲でしか、欲しいものを言えないのです。

3つ目は、欲しい機能を聞いた瞬間に、要望リストが返ってくることです。
項目は増えますが、どれも既存の業務を前提にした部分最適で、優先順位も付きません。
集めた側は満足しますが、そこから作るものは決まりません。

これは現場が悪いのではありません。
聞き方が、答えられない質問になっているだけです。

意見ではなく実際に起きたことを聞く

そこで、聞くものを変えました。
困っていますか、という抽象的な質問をやめて、時間と手間という具体の切り口から掘るようにしています。

最初に聞くのは、この2つです。

• 一番時間がかかっている作業は何ですか

• 面倒だと感じている作業は何ですか

困りごとは答えるのに評価が要りますが、時間と手間なら本人の体感でそのまま出てきます。
ここで出てきた作業を、さらに場面まで下ろしていきます。
それは直近だといつでしたか。そのとき何で止まりましたか。誰に確認しましたか。
意見ではなく、実際に起きたことだけを聞いていきます。

答えが場面で返ってくると、粒度が変わります。
例えば、資料探しに時間がかかる、ではなく、先週の頭に見積もりの前提を確認したくて、過去の議事録を順番に開いていった、という形になります。

そして、場面まで下りてくると、その作業をAIに置き換えられるかどうかを、こちら側で判定できるようになります。
止まったのは情報が揃っていなかったからなのか、揃っていたが探せなかったのか、探せたが読み解けなかったのか。原因によって手当ては変わります。
ここまで分解して初めて、AIで何を作るかが決まります。

逆に言えば、困りごとを聞くやり方は、この判定の宿題を現場に丸投げしています。自分の業務のどこがAIに向いているかを考えるのは、聞く側の仕事です。

もう1つの手は仮説をデモでぶつけること

場面を集めるだけでは、まだ足りません。
もう1つやっているのが、こちらから仮説をぶつけることです。

こういうことができたらどうですか、と口頭で聞いても、良いですねで終わります。想像できないものに評価はできません。
粗くていいので動く形にして見せます。実際のデータを1件だけ流し込んだ画面でも十分です。

見せたときに観察するのは、次の3つです。

• 表情が変わるか

• 出てくる追加要望が具体的になるか

• 何も出てこないか

当たっているときは、すごい、あれもしたい、これもしたい、と要望が続けて出てきます。
この瞬間に出てくる要望は、こちらが用意した仮説より鋭いことがあります。
外れているときは、逆に沈黙します。
良いですねと言われて話が続かないときは、ほぼ外れてます。

ただ、デモを見せて起きたことで一番大きかったのは、要望が増えたことではありません。
たしかにこれも困っていた、という話が出てくるようになったことです。

聞いても出てこなかった困りごとが、動くものを見た後には出てくる。
順番が逆でした。

困りごとを集めてから作るのではなく、作って見せることで、困りごとが言語化される。
最初に書いた「当たり前は課題として認識できない」という壁を、質問で越えるのは難しく、実物を見せると越えられます。

デモへの反応は、アンケート100枚より正確です。
ヒントを与えないと、答えは出てこないのだと思っています。

問いを聞く相手とデモを見せる相手は違う

もう1つ、設計として分けていることがあります。聞く相手です。

全員に同じ質問をすると、薄い答えが人数分集まります。
そうではなく、問いを集める相手と、仮説を当てる相手を分けるようにしました。

自分の業務を離れて場面を言語化できる人は、限られています。
企画や経営企画に近い層は、業務を外から見る訓練をしているので、どこで判断が止まっているかを構造で話せます。この層からは問いを集めます。

一方で、現場やマネージャー層は、実際に手を動かしている当事者です。
構造の話は出てきにくいのですが、目の前で動くものを見せたときの反応が、確かな手がかりになります。ここにはデモを当てます。

アンケートを使わないわけではありません。
頻度や所要時間のような実態の把握には、選択式で聞けば機械的に集計できます。
使わないのは、自由記述で使い道を聞く形式のほうです。
答える側の負担ばかり大きく、返ってくるのは想像の範囲内に収まります。

やっていることは社内向けのプロダクト開発でした

ここまで書いて、ずっと既視感がありました。
これは、プロダクトを作っていたときの顧客インタビューと同じ作法でした。

欲しい機能を聞かない。意見ではなく過去の行動を聞く。仮説は先に形にして、反応で検証する。
プロダクトマネージャーの教科書に書いてあることを、私は今、業務に対してやっています。

考えてみれば当然でした。
AI導入は、要するに社内向けのプロダクト開発です。

ユーザーは社内の人で、課題は業務の中にあり、作ったものが使われなければ価値はゼロになります。
であれば、ニーズ調査もプロダクトの型でやるのが正しい。
ツール選定の話でも、業務改善の話でもなく、開発の話として扱うということです。

違うところもあります。2つあると思っています。

1つは、サイクルが速くなったことです。
以前は仮説を形にして見せるまでに、設計して、実装を頼んで、と時間がかかりました。
今は聞いた話をその場で組んで、次の打ち合わせには動くものを持っていけます。仮説の当て外れを確かめる回数が、そのまま増えました。

もう1つは、定性情報を扱いやすくなったことです。
インタビューの記録は読み込んで自分の頭で分類するしかありませんでした。
今は、集めた会話をそのまま渡して、共通して出てくる場面や、言い回しは違うが同じことを指している発言をまとめられます。
人数分の話を横に並べる作業が軽くなった分、聞くこと自体に時間を使えます。

プロダクトを担うCPOから、プロセスを担うCPOへ。
これは私自身が意識しているシフトですが、こういうところで前職までの型がそのまま使えます。
プロダクトの中の体験を設計してきた人なら、業務プロセスの体験設計もできると思っています。

次のヒアリングで最初の質問を差し替える

何に困ってますか、は、聞く側が宿題を放棄した質問です。
答える側は自分の業務の当たり前を疑う作業を求められ、その上でAIの知識がないまま解決策まで想像しなければなりません。答えられなくて当然です。

代わりにやることは、仮説を作ってから聞きに行くことです。
AIの使い道は、現場の中に落ちているのではありません。
現場で実際に起きた事実と、こちらが持ち込んだ仮説がぶつかった場所から出てきます。

もし次にヒアリングの機会があるなら、最初の質問を1つだけ差し替えてみてください。
何に困っていますか、を、一番時間がかかっている作業は何ですか、に変える。
そこから、それは直近だといつでしたか、と場面まで下ろす。
それだけで返ってくるものが変わります。集まった場面をどう料理するかはこちらの仕事です。

AI活用がツール選定の話から抜けられないとしたら、詰まっているのは技術ではなく、その手前の聞き方のほうかもしれません。

deflagをもっと知りたい方へ

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a