「顧客に会っている」のに、なぜ何も見つからないのか──はてな米山氏が示した顧客理解の3段階

【S-2】「顧客に会う」を今こそガチる - AIで価値も速さも妥協しないプロダクトディスカバリーの実践

　「顧客に会うのが大事」に反対するプロダクトマネージャーはいない。それなのに実際にやってみると、1人が孤独に走り続けるか、組織で始めても続かずに立ち消えるか、どちらかになりがちだ。ProductZine Day 2026に登壇したはてなの米山弘恭氏は、この行き詰まりの原因を「顧客理解とは何かの輪郭がふんわりしている」からだと述べ、顧客理解を3つの段階として定義し直した。問うべきは、会っているかどうかではない。どこまで到達できているか、である。自社プロダクト「toitta」のチームが2年間実践してきた中身とともに語られた、その階段の上り方を紹介する。

• ProductZine Day 2026

生成AIで速くなるほど、割を食っているのはプロダクトマネージャー

　米山弘恭氏は、はてなのコンテンツ本部で副本部長を務めるかたわら、AI時代の定性データ基盤「toitta（トイッタ）」のプロダクトマネージャーを担っている。HCD-Net認定 人間中心設計専門家でもある。

株式会社はてな コンテンツ本部 副本部長　米山弘恭（よねやま・ひろやす）氏

　toittaは、ユーザーインタビューの録画・録音を構造化して分析に使うプロダクトで、2024年7月のベータ版リリース以降、リコーやBASE、東急、TOPPANなどに導入されている。セッション前日の8月24日には、発話を資産化する「定性データウェアハウス」の実証実験開始も発表された。

　その米山氏がセッションの冒頭に置いたのは、製品の話ではなく、聴衆自身の身に何が起きているかという話だった。生成AIによって多くの作業が速くなり、人手をかけずに動くようになった。その副作用をもっとも重く受けているのは、実はプロダクトマネージャーではないか。これが米山氏の見立てである。

　速く進めるほどビルドトラップの罠は近づき、複数のプロジェクトが並列かつ高速に動けば、意思決定を担うプロダクトマネージャーがボトルネックになる。チームの外に目を向ければ、賢くなり続けるフロンティアモデルそのものが競合として立ちはだかる。

　toitta自身が、まさにその渦中にいる。対話データを分析できるようにするという一点で立ち上げたプロダクトが、Claude Codeなどのコーディングエージェントの進化によって、汎用AIで何でもできてしまう世界に置かれた。米山氏は自らの立ち位置を、SaaSはもう終わりだと言われる街道のど真ん中だと表現する。それでも成長を続けている。振り返ると、武器になっていたのは顧客理解だった。

　速度を上げながら品質にも顧客価値にも妥協しない、その先行事例として話す。これが本セッションの立て付けだった。

　なお、米山氏がAI時代になぜ一次情報が武器になるのかを論じた講演は、2025年のプロダクトマネージャーカンファレンスでのもので、「AI時代、プロダクトマネージャーの武器は一次情報だ──はてな米山氏の定性データウェアハウス論」にまとめている。対話の量の作り方から、聞く質の高め方、構造化して活用する方法までがそちらにある。本稿が追うのはその先だ。どこまで行けば「顧客を理解している」と言えるのか、である。

顧客理解には3つの段階がある

　「顧客に会いましょう」というテーマを、米山氏はより正確な形へ置き換える。顧客理解のレベルを上げていきましょうだ。

　顧客に会うのは大事だ、顧客に価値を届けるには顧客理解が要る。それは誰もが百も承知だろう。にしては、会うための方法論も、会って何をするのかも、そもそも顧客理解とは何なのかも、世間にあまり知見が落ちていない。輪郭がふんわりしたままだ。だからこそ、プロダクトマネージャーが1人で孤独に頑張るか、組織ぐるみでやろうとして断念するか、というパターンが起きる。

　そこで米山氏は、顧客理解を3つの段階に分けて定義した。第一段階、顧客が持つ「エピソード」が聞けている。第二段階、そのエピソードを集めて使えている。第三段階、その結果から「秘密」が発見できている。

図1　顧客理解を3つの段階に分けて定義した。第一段階「エピソードが聞けている」、第二段階「集めて使えている」、第三段階「秘密が発見できている」（米山氏の講演資料より／クリック・タップで拡大、以降同様）

「速い馬が欲しい」と言われるのは、聞き方が悪いから

　「もし顧客に望むものを聞いていたら、『もっと速い馬が欲しい』と言われただろう」

　プロダクトに関わる人なら、一度は耳にしたことがあるだろう。ふつうは「顧客に聞くだけでは駄目だ」という教訓として引かれる言葉だが、米山氏の読み方は違った。

　「それは、何が欲しいかと聞いたら『速いのが欲しい』と答えるでしょう、ということです」

　「速い馬が欲しい」と返ってくるのは、「何が欲しいですか」というあまりにも単純な聞き方をしたからではないか。悪いのは顧客ではない。

　「要は、聞き方が悪いのではないかと思うわけです」

　プロダクトマネジメントの究極の目的を、顧客の課題に対し期待を超える最高の解決手段を提供することだと置く。その手段を、情報ゼロから生み出せるだろうか。背景や文脈がセットになった課題と動機を聞きにいくしかない。それが第一段階である。

　手段として米山氏がもっとも高く評価するのはユーザーインタビューだ。誰に、いつ、何を聞くかを自分たちで設計できる。アンケートや行動データでは、結果は分かっても理由と背景までは分からない。

　では、何を聞くべきか。米山氏は3点を挙げた。

　第一に、5W1Hが揃ったエピソードを集めること。いつ、どんな人が、どんな状況で、何を目的に何をして、その結果何が起きたか。話し始めれば、きっかけから結果までが一続きにつながる話である。

図2　5W1H+αが揃ったエピソードの例。スライドでは架空の「ある平日の夕食」で示された（米山氏の講演資料より）

　第二に、WHY NOTが分かること。なぜそうしたかに加えて、あえて取らなかった選択肢の理由まで聞く。昼食にコンビニ弁当を買うという行動一つにも、裏には複数の選択肢がある。弁当を持ってこなかったのはなぜか。ファミレスに行かなかったのはなぜか。同じコンビニでも、あの店ではないのはなぜか。選択肢のなかから一つを選んだ理由に、価値観と意思決定の背景が現れる。

　第三に、解釈の隙間が埋まっていること。「けっこう多い」「速いと嬉しい」といった抽象語は、程度感が人によってまるで違う。多いとは週に何回か、速いとは何秒か。その隙間を対話で埋める。

　米山氏はこれを、負荷の低い形で回すことも勧める。名づけて「ちょっとだけユーザーインタビュー」。顧客と話す機会が多いBtoBプロダクトなら、セールスやカスタマーサクセスのミーティングのなかで10分だけもらい、ワントピックだけインタビューパートにさせてもらう。相手の負荷も自分たちの負荷も低く、速度と頻度を高く保てる。

　対話の機会を業務プロセスに組み込む考え方と、機能要望の裏にある文脈を掘り出す半構造化インタビューの実例は、前掲の記事に詳しい。聞き方や言葉づかいそのもののノウハウは、それだけで2時間は話せる量があるとして本セッションでは割愛された。

　ここまでが第一段階だ。だが、聞けただけでは「いい話が聞けてよかったね」で終わってしまう。