生成AIで速くなるほど、割を食っているのはプロダクトマネージャー
米山弘恭氏は、はてなのコンテンツ本部で副本部長を務めるかたわら、AI時代の定性データ基盤「toitta（トイッタ）」のプロダクトマネージャーを担っている。HCD-Net認定 人間中心設計専門家でもある。
toittaは、ユーザーインタビューの録画・録音を構造化して分析に使うプロダクトで、2024年7月のベータ版リリース以降、リコーやBASE、東急、TOPPANなどに導入されている。セッション前日の8月24日には、発話を資産化する「定性データウェアハウス」の実証実験開始も発表された。
その米山氏がセッションの冒頭に置いたのは、製品の話ではなく、聴衆自身の身に何が起きているかという話だった。生成AIによって多くの作業が速くなり、人手をかけずに動くようになった。その副作用をもっとも重く受けているのは、実はプロダクトマネージャーではないか。これが米山氏の見立てである。
速く進めるほどビルドトラップの罠は近づき、複数のプロジェクトが並列かつ高速に動けば、意思決定を担うプロダクトマネージャーがボトルネックになる。チームの外に目を向ければ、賢くなり続けるフロンティアモデルそのものが競合として立ちはだかる。
toitta自身が、まさにその渦中にいる。対話データを分析できるようにするという一点で立ち上げたプロダクトが、Claude Codeなどのコーディングエージェントの進化によって、汎用AIで何でもできてしまう世界に置かれた。米山氏は自らの立ち位置を、SaaSはもう終わりだと言われる街道のど真ん中だと表現する。それでも成長を続けている。振り返ると、武器になっていたのは顧客理解だった。
速度を上げながら品質にも顧客価値にも妥協しない、その先行事例として話す。これが本セッションの立て付けだった。
なお、米山氏がAI時代になぜ一次情報が武器になるのかを論じた講演は、2025年のプロダクトマネージャーカンファレンスでのもので、「AI時代、プロダクトマネージャーの武器は一次情報だ──はてな米山氏の定性データウェアハウス論」にまとめている。対話の量の作り方から、聞く質の高め方、構造化して活用する方法までがそちらにある。本稿が追うのはその先だ。どこまで行けば「顧客を理解している」と言えるのか、である。
顧客理解には3つの段階がある
「顧客に会いましょう」というテーマを、米山氏はより正確な形へ置き換える。顧客理解のレベルを上げていきましょうだ。
顧客に会うのは大事だ、顧客に価値を届けるには顧客理解が要る。それは誰もが百も承知だろう。にしては、会うための方法論も、会って何をするのかも、そもそも顧客理解とは何なのかも、世間にあまり知見が落ちていない。輪郭がふんわりしたままだ。だからこそ、プロダクトマネージャーが1人で孤独に頑張るか、組織ぐるみでやろうとして断念するか、というパターンが起きる。
そこで米山氏は、顧客理解を3つの段階に分けて定義した。第一段階、顧客が持つ「エピソード」が聞けている。第二段階、そのエピソードを集めて使えている。第三段階、その結果から「秘密」が発見できている。
「速い馬が欲しい」と言われるのは、聞き方が悪いから
「もし顧客に望むものを聞いていたら、『もっと速い馬が欲しい』と言われただろう」
プロダクトに関わる人なら、一度は耳にしたことがあるだろう。ふつうは「顧客に聞くだけでは駄目だ」という教訓として引かれる言葉だが、米山氏の読み方は違った。
「それは、何が欲しいかと聞いたら『速いのが欲しい』と答えるでしょう、ということです」
「速い馬が欲しい」と返ってくるのは、「何が欲しいですか」というあまりにも単純な聞き方をしたからではないか。悪いのは顧客ではない。
「要は、聞き方が悪いのではないかと思うわけです」
プロダクトマネジメントの究極の目的を、顧客の課題に対し期待を超える最高の解決手段を提供することだと置く。その手段を、情報ゼロから生み出せるだろうか。背景や文脈がセットになった課題と動機を聞きにいくしかない。それが第一段階である。
手段として米山氏がもっとも高く評価するのはユーザーインタビューだ。誰に、いつ、何を聞くかを自分たちで設計できる。アンケートや行動データでは、結果は分かっても理由と背景までは分からない。
では、何を聞くべきか。米山氏は3点を挙げた。
第一に、5W1Hが揃ったエピソードを集めること。いつ、どんな人が、どんな状況で、何を目的に何をして、その結果何が起きたか。話し始めれば、きっかけから結果までが一続きにつながる話である。
第二に、WHY NOTが分かること。なぜそうしたかに加えて、あえて取らなかった選択肢の理由まで聞く。昼食にコンビニ弁当を買うという行動一つにも、裏には複数の選択肢がある。弁当を持ってこなかったのはなぜか。ファミレスに行かなかったのはなぜか。同じコンビニでも、あの店ではないのはなぜか。選択肢のなかから一つを選んだ理由に、価値観と意思決定の背景が現れる。
第三に、解釈の隙間が埋まっていること。「けっこう多い」「速いと嬉しい」といった抽象語は、程度感が人によってまるで違う。多いとは週に何回か、速いとは何秒か。その隙間を対話で埋める。
米山氏はこれを、負荷の低い形で回すことも勧める。名づけて「ちょっとだけユーザーインタビュー」。顧客と話す機会が多いBtoBプロダクトなら、セールスやカスタマーサクセスのミーティングのなかで10分だけもらい、ワントピックだけインタビューパートにさせてもらう。相手の負荷も自分たちの負荷も低く、速度と頻度を高く保てる。
対話の機会を業務プロセスに組み込む考え方と、機能要望の裏にある文脈を掘り出す半構造化インタビューの実例は、前掲の記事に詳しい。聞き方や言葉づかいそのもののノウハウは、それだけで2時間は話せる量があるとして本セッションでは割愛された。
ここまでが第一段階だ。だが、聞けただけでは「いい話が聞けてよかったね」で終わってしまう。
議事録は長すぎて、人もAIも読みづらい
第二段階は、聞けたエピソードを、話を聞いた本人以外のメンバーも、AIも使える形に整える段階である。
はてなのやり方は明快だった。議事録を作らない。
「議事録だと長すぎるし、AIも読みづらい、人間も読みづらい。なので、もう全部発言に分割してしまいます」
インタビューを1件の単位ではなく、そこで得られた「発言」の単位で保管する。下敷きにしたのは、質的分析におけるオープンコーディング、すなわち発話を切片に分解する手法だ。「誰がいつ、どんな話をした」を1件ずつ立てていくと、1回のインタビューから100件前後のデータが並ぶ。人力では到底やれないので、自社のプロダクトにやらせる。自社チームのデータ基盤はいまや約20万レコード。BigQueryにMCP（Model Context Protocol）をつなぎ、エージェントに操作させることもあるという。
もう一つ、米山氏が強調したのがメタデータの設計だ。
「さすがにこれは未来永劫、絶対にユニバーサル（普遍的）でしょう、腐らないでしょう、というメタデータを付けるようにしています」
思いつきでカテゴリーを付けると、後になって使えなくなる。煮詰めた結果は5W1Hに近づいた。いつ、誰が、何について、どんな背景で、どんな目的で語られた発言なのか。
その上に、さらに「発言の分類」を重ねる。試行錯誤の末に落ち着いたのは、リーンキャンバスの項目を下敷きにした形だった。項目は、状況、行動、課題、代替手段、そして自社製品の利用実態の5つ。利用実態はさらに、ポジティブとネガティブに分けて持つ。
そして米山氏は、この分類の付与について1つ付け加えた。
「ちなみに、これはまだ全部人間がやっています」
整えたデータは「秒で分かる」「空白が見える」「PRDが検証できる」
こうして整えたデータが大量にあると、欲しいアウトプットを好きな形で、しかも素早く取り出せるようになる。米山氏は取り出し方を3通り示した。
1つ目は、理解するために使う。顧客の課題は何か、いま考えている機能は誰のどんな行動のなかで使われるべきか。そうした問いに、AIへ議事録を読ませるのではなく、整えたデータベースを発言分類とセグメントで絞り込んで答える。それだけで「秒で分かる」。
2つ目は、発見するために使う。縦軸に業務プロセスの工程、横軸に発言の分類を置いてマトリクスにすると、課題の偏りや顧客群ごとの違い、そして空白地帯とボトルネックが視覚的に浮かび上がる。
3つ目は、検証に使う。PRD（プロダクト要求仕様書）を書くとき、その機能は本当に受け入れられるのかを、支持する発話と反証する発話の両方を根拠として出力させ、比較する。さらに件数が集まると母数や割合が意味を持ちはじめ、リリース前後の分類別件数の増減という形で、定性データをある種の定量データのように扱えるようになる。
ここまで来ると、「インタビューをしましたね、よかったですね」で終わらない。顧客の声が、組織の意思決定の基盤に転用される。インタビューの記録を組織の資産として扱うというこの発想は、前掲の記事でも「定性データウェアハウス」として語られている。
米山氏の話は、しかしここで終わらなかった。
顧客理解の最終段階は、「秘密」が発見できている状態
「ここからはもう100パーセント自論です」
そう前置きして、米山氏は第三段階を語りはじめた。第一段階で話を聞き、第二段階で集めて意思決定に使う。このプロセスをチームで回し続けていると、ある日のミーティングで急に「分かってしまった」「めちゃくちゃひらめいた」という瞬間が、まれに訪れる。これを顧客理解の最終段階、「秘密の発見」と定義してみたい、と。
冒頭で紹介した「速い馬」の話にも、続きがある。本当は速い馬が欲しいのではなく、速く目的地に着きたいだけだ。そこに気づけたから自動車が生まれた。これもまた、顧客自身がまだ気づいていない発見、つまり秘密である。
米山氏は前掲の講演でも、競合にもAIにも知られていない独自の理解を「ファウンダーズシークレット」と呼んでいた。本セッションはその「秘密」を顧客理解の到達段階として定義し直し、中身まで開けてみせたことになる。
米山氏は自社で見つけた秘密を3つ開示した。いずれも、そのままプロダクトの機能になっている。
1つ目。生成AIを機能として組み込んでいる以上、「生成AIが出す情報はいまいち信用できない」という声はよく寄せられる。だが向き合った末に見えてきたのは、正確性や根拠の確からしさだけでなく、元のインタビュー相手の顔が見えることが安心感を大きく左右する、ということだった。それよりも、元のインタビューで話す相手の顔が見えるかどうかで、安心感と信頼感が段違いに変わる。この発見は、分析画面のどこからでも元の動画に戻れるUIになった。
2つ目。発話データを分析するプロダクトの性質上、顧客がどんな分析手法を使っているかを数多く聞いてきた。手法は人によってばらばらなのに、目的まで遡ると2パターンしかない。仮説を整理して根拠を得るか、まったく知らない発見をするか。これは、「根拠付きの発見」というデータ構造でエージェントが回答する機能になった。
3つ目。個人情報のマスクのような作業が大変だという課題認識は共通する一方で、それでも自分で確認・承認しなければ安心できないという意識もある。これは、マスク機能に「レビュー」工程を加える形になった。
では、秘密はどういう形で現れるのか。米山氏は3つの傾向を挙げた。
1つ目に、秘密は特定の言葉を伴いやすい。「結局こうだよね」「なんだかんだ言ってもこうだよね」「そうは言っても、こうなるのが人情だよね」。大量の顧客の声からパターンや構造を見出した末に、相対的な総括として見えてくるものなので、「結局」という言葉を帯びる。
2つ目に、秘密は顧客が直接語っていないことが多い。顧客は言っていないが、その裏に潜在的にあるもの。だから「そうは言っても、実はこうなんじゃないか」という形になる。
3つ目に、秘密は強い共感を伴う。
「いつしか自分たち自身が顧客の側に立つんです」
パターンを何度も見出し、顧客の声に向き合い続けるうちに、顧客を内面化していく。だから気づいた瞬間の感覚は「顧客はこうらしい」ではなく、「そうなるのが人情ですよね、辛いですよね」になる。副次的に、解決へのモチベーションが上がるという効用もある。
そこにどうすればたどり着けるのか。米山氏は点・線・面・立体という比喩で整理した。点は個別の要望や困りごとで、それだけあってもどうにもならない。背景情報を伴ったエピソードが線であり、これが第一段階。線が集まって傾向やパターンが見える状態が面で、これが第二段階。そして面が階層構造を持ち、いろいろな角度から見ることでふとつながり、像を結ぶ瞬間がある。これが第三段階、秘密の発見である。
ただし、点を面にするのも、面を立体にするのも、1人ではとても手に負えない。だからこそチームぐるみの仕組みとして運用する必要がある。人間も分かり、AIも分かる形で、発言を一か所に集めて整理しておく。第二段階の設計は、そのための土台だったことになる。
そこまで説いたうえで、米山氏は最後に一つ、率直な留保を置いた。秘密にたどり着くための手順そのものは、まだ確立できていない、と。
「最後の最後まで、まだ再現性は見つかっていないと思っています。まだ研究過程です」
どうすれば必ず秘密に出会えるのか、その方法は分からない。現時点で有力なのは、第一段階と第二段階を繰り返すことだという。
まず、自分のチームがどの段階にいるかを確かめる
顧客理解を仕組み化し、レベルを1つずつ上げていく。第一段階では5W1Hで背景と文脈ごと聞き、エピソードを集める。第二段階では発言単位のデータベースに腐らないメタデータを付け、理解と発見と検証に使い倒す。第三段階では点から線、線から面、面から立体へと重ね、顧客がまだ語っていないことに気づく。そこまで到達すれば、顧客の期待を超えるものを作れる。これが米山氏の総括だった。
自分のチームは、いま第何段階にいるだろうか。エピソードは聞けているか。聞けたものは、本人以外とAIにも使える形になっているか。その集積から、誰も言っていない何かを見つけられているか。3つの問いは、明日そのまま確かめられる。
お知らせ
はてなは、2年間の顧客理解の知見をエージェントに置き換えてtoittaへ組み込むプロジェクトを進めていく。プロダクト単体だけでなく、インタビューの実行支援やデータ構造の設計、プロダクトマネジメントの顧問といった支援業務も提供している。詳細はtoitta公式サイトから。
