議事録は長すぎて、人もAIも読みづらい
第二段階は、聞けたエピソードを、話を聞いた本人以外のメンバーも、AIも使える形に整える段階である。
はてなのやり方は明快だった。議事録を作らない。
「議事録だと長すぎるし、AIも読みづらい、人間も読みづらい。なので、もう全部発言に分割してしまいます」
インタビューを1件の単位ではなく、そこで得られた「発言」の単位で保管する。下敷きにしたのは、質的分析におけるオープンコーディング、すなわち発話を切片に分解する手法だ。「誰がいつ、どんな話をした」を1件ずつ立てていくと、1回のインタビューから100件前後のデータが並ぶ。人力では到底やれないので、自社のプロダクトにやらせる。自社チームのデータ基盤はいまや約20万レコード。BigQueryにMCP（Model Context Protocol）をつなぎ、エージェントに操作させることもあるという。
もう一つ、米山氏が強調したのがメタデータの設計だ。
「さすがにこれは未来永劫、絶対にユニバーサル（普遍的）でしょう、腐らないでしょう、というメタデータを付けるようにしています」
思いつきでカテゴリーを付けると、後になって使えなくなる。煮詰めた結果は5W1Hに近づいた。いつ、誰が、何について、どんな背景で、どんな目的で語られた発言なのか。
その上に、さらに「発言の分類」を重ねる。試行錯誤の末に落ち着いたのは、リーンキャンバスの項目を下敷きにした形だった。項目は、状況、行動、課題、代替手段、そして自社製品の利用実態の5つ。利用実態はさらに、ポジティブとネガティブに分けて持つ。
そして米山氏は、この分類の付与について1つ付け加えた。
「ちなみに、これはまだ全部人間がやっています」
整えたデータは「秒で分かる」「空白が見える」「PRDが検証できる」
こうして整えたデータが大量にあると、欲しいアウトプットを好きな形で、しかも素早く取り出せるようになる。米山氏は取り出し方を3通り示した。
1つ目は、理解するために使う。顧客の課題は何か、いま考えている機能は誰のどんな行動のなかで使われるべきか。そうした問いに、AIへ議事録を読ませるのではなく、整えたデータベースを発言分類とセグメントで絞り込んで答える。それだけで「秒で分かる」。
2つ目は、発見するために使う。縦軸に業務プロセスの工程、横軸に発言の分類を置いてマトリクスにすると、課題の偏りや顧客群ごとの違い、そして空白地帯とボトルネックが視覚的に浮かび上がる。
3つ目は、検証に使う。PRD（プロダクト要求仕様書）を書くとき、その機能は本当に受け入れられるのかを、支持する発話と反証する発話の両方を根拠として出力させ、比較する。さらに件数が集まると母数や割合が意味を持ちはじめ、リリース前後の分類別件数の増減という形で、定性データをある種の定量データのように扱えるようになる。
ここまで来ると、「インタビューをしましたね、よかったですね」で終わらない。顧客の声が、組織の意思決定の基盤に転用される。インタビューの記録を組織の資産として扱うというこの発想は、前掲の記事でも「定性データウェアハウス」として語られている。
米山氏の話は、しかしここで終わらなかった。
