「それって主観ですよね？」で終わらせない。データマネジメントの手法でユーザーの声を定量化する方法

プロダクトマネージャー（PM）にとって、顧客の「生の声」は意思決定の重要な判断材料です。

一方で、その扱いは想像以上に難しく、落とし穴だらけです。ヒアリング先の偏りや「N=1」の誤った一般化、さらにはデータの価値をチームで共有する難しさ…、多くのPMがこうした課題に頭を抱えた経験があるのではないでしょうか。

本記事では、昨年12月4日に開催された「pmconf 2025 東京」から、株式会社カミナシの右田涼氏によるセッション「“主観で終わらせない”定性データ活用 ― プロダクトディスカバリーを加速させるインサイトマネジメント」の内容を一部再構成してお届けします。

プロダクトのドメイン知識もユーザーもゼロの状態から、いかにして顧客のインサイトを掴み、「愛されるプロダクト」へと育てていったのか。その核となった「インサイトマネジメント」の考え方、具体的な3つのステップ、そして開発プロセスへの組み込み方を紐解きます。

• keyboard_arrow_down 定性データを「客観的な判断材料」として扱う難しさ
• keyboard_arrow_down 顧客の課題を見極め、「広く使われるプロダクト」をつくるためのインサイトマネジメント
• keyboard_arrow_down 「データマネジメント」の仕組みを活用して「生の声」を管理
• keyboard_arrow_down インサイトマネジメントを実現する3ステップ
• keyboard_arrow_down 開発優先度の見極めに効く、3つの活用例
• keyboard_arrow_down 2年弱の取り組みが顧客からの高評価として結実
• keyboard_arrow_down AI時代、インサイトマネジメントの仕組み化と運用が競合優位性を生み出す

皆さんはユーザーヒアリングで、こんな経験をしたことはありませんか？

UXリサーチなどで得られる現場の声を集めた「定性データ」は一見、わかりやすく扱いやすいように見えて、実はうまく活用することが難しいのです。

私がカミナシに入社した当初も、定性データの管理、共有、活用の方法をチーム内で確立できておらず、せっかく顧客の声を集めても、データが属人化しリサーチした人にしか納得感がない、というシーンを何度も見てきました。

この扱いが難しい定性データを意思決定に活かそうと、私が立ち上げに関わった新規事業「カミナシ 設備保全」チームでは、「インサイトマネジメント」を実践しています。

「ユーザーインサイト」は事業や機能の価値を生み出す源泉です。インサイトマネジメントとは、担当者がユーザーとの会話で掴んだインサイトを「いつでも、誰でも、何度でも」使えるように管理していく手法と言えます。

「カミナシ 設備保全」は、現場DXプラットフォーム「カミナシ」というマルチプロダクトのうちの一つで、現場で「設備」をメンテナンスする人たち向けのSaaSです。

当初、「設備保全」という領域は私たちの会社にとって完全に未知のドメインでした。ドメインエキスパートが0人の状態で、新規事業のため当然ユーザーは一人もおらず、定量データもない。そこからインサイトマネジメントを仕組み化しながら、プロダクト開発を進め、今年2月に正式リリースをしました。リリースから10ヶ月経過した現在、「顧客から愛されるプロダクトが提供できている」という実感があります。

では、なぜインサイトマネジメントという仕組みを取り入れたのか。

そこには、私たちが向き合うドメインの複雑さが関係しているのです。

カミナシは、「ノンデスクワーカーの才能を解き放つ」をミッションに掲げ、工場やホテル、飲食店などで働く方々向けのデジタルツールを提供しています。ツールの導入先となる現場では、まだまだ紙が多いのが現状。扱われる情報によっては属人性が高く、アナログ管理に閉じ込められた業務やノウハウをデジタル化しなければいけない難しさがありました。

「カミナシ 設備保全」を立ち上げるときも、最初にぶち当たった壁が「デスクトップリサーチしても課題が全然分からない」ということでした。

「設備」と言っても工場に何がどのくらいあるのか、保全担当の方がどういう業務の流れでどの作業で詰まるのか、顧客が直面する課題がリアルにイメージできませんでした。

そこで現場の解像度を上げようと、とにかく現場に行って顧客と話しました。

カミナシはもともと現場訪問に力を入れており、昨年1年間の訪問数は全社で約3,900回に上ります。私自身も入社してから70回ほど訪問しているので、平均して月に3回以上は工場などの施設を訪問している計算になります。

当然、集めた定性データをインサイトとしてプロダクト開発に活かしたいと考えます。しかし、主観の入りがちな定性データの扱いを間違えると、意思決定の再現性がなくなり、プロダクトの価値を継続的に生み出す難易度が上がっていくのです。

ここで、陥りがちなアンチパターンを2つ紹介します。

1つは、「N=1に刺さった」事実のみを判断基準にしてしまい、PMの「お気持ち駆動開発」を生み出すケースです。

SaaSである以上、特定の誰か一人ではなく「広く使われること」が重要で、一部の好反応だけでGoサインを出すのは危険です。使われないものをつくってしまうリスクを甘く見てはいけないと考えています。

次に、定性データが適切に管理されずに属人化し、似たようなリサーチが繰り返されるケースです。

たとえばバラバラなExcelファイルが散らばっていても、リサーチした人しか記憶していないのです。自分も1年前のリサーチのことは、完全に忘れてしまっています。覚えていたとしても、チーム内での共有が難しい。ユーザー課題の深刻さや前後の文脈を伝えようとすると長文になり読まれない、要約しすぎるとニュアンスが伝わらない、というトレードオフに悩まされます。

その結果、過去のリサーチが活かされず、無駄な再リサーチを繰り返すことになります。

実際、私が入社した当時、現場訪問の議事録がNotionに貯まっていましたが、件数が増えるほどどこに何が書いてあるかわかりにくくなり情報の属人化が進んでいました。その結果、かえって意思決定が難しくなっていたのです。

こうしたアンチパターンを避けるため、定量データの世界にある「データマネジメント」の仕組みを定性データに転用できないかと考えました。個別具体に見えがちな顧客の声を客観的な「ファクト」として集計・分析し、その「ファクト」をもとに判断したい。主観や直感に頼る意思決定は最後の重要な局面まで取っておきたい。それが、「インサイトマネジメント」の仕組みを取り入れた最大の理由でした。

早めにインサイトマネジメントの基盤に投資すればプロダクト開発に複利が効くと考え、新規事業のチームができてすぐに、当時の上司であるCTOに相談。二つ返事でOKをもらいました。

ツールとしては、国内外のUXリサーチのマネジメントツールを調べ、インサイトマネジメントに特化した「Centou」を使うことにしました。β版開発の手前からずっと投資を続け、今では他のプロダクトチームにも展開しています。

ここからは、インサイトマネジメントを実施する具体的な3つのステップを紹介します。

この3つのステップは、定量データの分析基盤（データレイク、DWH、データマート）を模倣した設計になっています。

• 1. 事実を集める：議事録やVoC（顧客の声）、現場訪問の写真などをとにかく集めてきます。
• 2. インサイトに変換、まとめる：集めた事実をインサイトに抽象化し、変換してグルーピングします。
• 3. 活用する：業務フローやカスタマージャーニーと紐付けて可視化し、意思決定に活用します。

「事実を集める」フェーズでは、ヒアリングの議事録や現場訪問の写真などの生データを、マネジメントツール「Centou」のリサーチページに入れます。

チームには、主観や要約ではなく「とにかく事実を書いてほしい」とお願いしています。最近は議事録を動画でも残し、AIで書き起こしたものを入れたりもしています。

ポイントは議事録から「課題・現状・理想」の箇所をハイライトして抽出すること。過去の経験や直感に頼る側面もあるのですが、その中でも意識していることの一つが、「他の顧客も同じことを言いそうか」という点です。「故障時の音声を記録したい」「文章で伝えるのが難しい情報を動画で残したい」など、目の前の顧客だけでなく、他の現場でも共通して発生しそうな課題をピックアップしています。

次に、収集した生データから、「インサイト」を抽出して分類・整理します。

ここでのポイントは、「抽象と具体を行き来すること」です。ハイライトした具体的な顧客の発言を、より抽象度の高いインサイトへと変換し、グルーピングしていきます。その際、「VoC」や「開発テーマ」などのタグを付けておくことで、「あれ、どこかの顧客に聞いたことあるな」というようなことも、すぐに検索できるようになります。

そして3つ目の「活用する」フェーズでは、業務フローなどと紐付けて意思決定に使います。

私のチームでは、PMやデザイナーだけでなく、エンジニア、カスタマーサクセス（CS）、BizDevなど、他の職種も巻き込みながら、インサイトをチームの共通言語にしています。これにより、リサーチからVoC回収まで、ほぼ全ての開発プロセスでインサイトを活用することができています。

ユーザーインサイトの具体的な活用例を3つご紹介します。

活用例1：顧客のニーズの大きさを可視化

現在、1,000件を超えるインサイトが集約され、チームにとっての「Single Source of Truth（信頼できる唯一の情報源）」となっています。

これらのインサイトをグルーピングして可視化すると、円の大きさが「顧客の声の量」を表します。そのため、基本的にはこの円が大きい順に開発の優先度をつけていけばいい、というシンプルな判断が可能になりました。

もちろん、プロダクトビジョンやセールス上の優先順位も加味しますが、ベースとして「最も多くの顧客が求めていること」から着手しているので「開発が外れていない」という実感があります。

活用例2：ペインと業務フローの紐付け

新規機能開発では、顧客の痛み（ペイン）の見極めが重要です。日々蓄積しているインサイトを業務フローと紐付けて管理することで、「どの業務にどのぐらいのペインがあるのか」が一目瞭然になります。

さらに、「具体的にどんな顧客が、どこで、何に困っているのか」まで逆引きで辿れます。

結果として、チーム内で「どこのペインを取り除く必要があるのか」という共通認識を持ったうえで、議論できるようになりました。

活用例3：VoC管理と優先度付け

最後はVoC管理です。要望を件数ベースでリストアップし、対応優先度を精査します。

ポイントはリストを元にCSチームと優先度をすり合わせることです。 「それは実は運用でカバーできますよ」「ここはペインがかなり深いです」といった現場目線のフィードバックをもらいながら、開発工数と事業成果へのインパクトを見極め、最終的な優先順位を決定します。

1年9ヶ月の実践を経て辿り着いた結論は、「現場ドリブンな開発」と「インサイトマネジメント」の相性はかなり良いということです。

まず、顧客からとても良い反応をもらっています。

商談の時に「これが欲しかったんです」と言っていただけるのは大変嬉しいですし、もっと嬉しいのは、実際に「カミナシ 設備保全」を使っている現場の保全担当の方から「よく分かってますね」と言われることです。

これは、顧客の業務内容や抱える課題、要望を解像度高く把握し、インサイトを管理できているからこそ引き出せたコメントだと思っています。

社内の経営陣からも、継続的な取り組みにより「プロダクト開発にも複利が効いている」という評価をもらっています。

そして何より、PMの自分自身も、「手戻りがない開発を続けられている」という実感があります。

チームが高いドメイン解像度を持ち続け、PMである私の主観や伝え方に寄らずに開発ができるので、意思決定の透明性が高い。「自分たちで決めている」という感覚が、各メンバーのオーナーシップや良いモメンタムを生み、顧客に価値をデリバリーできるチーム運営ができていると感じています。

そして、結果的に定性データの属人化を防いでいるので、仮に今後PMが交代する時にも、過去のリサーチを検索して活用できる状態を保っています。

このように「外さない開発」をし続けることで、ディスカバリーが加速し、顧客から良い声が返ってくる。これこそが、インサイトマネジメントの有効性を示す何よりの証左だと信じています。

このアプローチに対して、「組織で仕組み化して運用するのは大変ではないのか」という疑問を持つ方もいると思います。

これは正直、大変です。

地道にコツコツ顧客の声を集め、インサイトをつくり、グルーピングしていくというのは、非常に手間のかかる作業です。AIでリサーチを効率化して迅速に成果物を出す、という時代の流れとは逆行していると感じています。

しかし、AI時代においても、「解くべき課題を見つけ、どんな機能を提供するのか」を決めるのは、これからもPMの重要な責務です。この地道な作業を丁寧に1つずつ愚直に積み上げること自体が、顧客の声を細かく拾うことにつながり、良い機能をつくる源泉になっていると信じています。

同時に、これまで主観に頼りがちだった場面でも集めたファクトをもとに判断することで、本当に大事な局面での「決断」に集中できるようになります。

私は、「やる」と決めて「やりきる」ことが大切だと思います。腰を据えて取り組むことで、私自身が理想としていたファクトベースの判断が実現できるようになってきました。

データがない新規事業であっても自らデータをつくり、早めに仕組みを構築すれば、複利的に資産が積み上がり、競合優位性へと変わります。

ぜひ皆さんもインサイトマネジメントを試してみてください。定性データの活用に一緒に取り組んでいけたら嬉しいです。