カミナシに学ぶ、外さないプロダクト開発

※ このドキュメントは、急成長スタートアップ「カミナシ」でプロダクトマネージャーを務める右田氏（@migii000）による寄稿文です。

多くのプロダクト開発者にとって、「作ったのに使われない」は最も避けたいことの1つです。

2025年のプロダクトマネージャーカンファレンス（通称：pmconf）での、インサイトマネジメントについての登壇は大きな反響をいただきました。

参考 : 主観で終わらせない"定性データ活用 ― プロダクトディスカバリーを加速させるインサイトマネジメント

ありがたいことに、登壇後さまざまな方から「詳しく話を聞きたい」と相談をいただきました。そして話を伺う中で、実は多くの方に共通する悩みがあったのです。

その共通の悩みこそ、今回のテーマである「プロダクト開発の意思決定をどのように行うべきか？」という意思決定の悩みです。

プロダクト開発は外れやすい

そもそもプロダクト開発は、外れやすい性質を持っています。ある成果を狙った意思決定が当たらない、思ったよりも反響がなかった、そんな経験はありませんか？

できるなら根拠を持って意思決定をしたい。そのために、データやインサイトを集め、活用します。

顧客を観察するために現場を訪問したり、コンセプトやモック、プロトタイプをお客様に見ていただいた上でヒアリングを実施するなど、現場に根拠（顧客の実態・課題）を集めにいきます。

しかし、この集めた顧客データ = 定性データの扱いは難しいことは、見落とされがちな点です。定性データは人から人へ伝達される情報なので、話す人・受け取る人の双方にバイアスが生じやすく、そのバイアスに気づきにくいからです。

定性データの難しさを、もう少し分解してイメージしてみましょう。

例えば、顧客は自身の状況を省略して話します。顧客自身にとっての日常であり当たり前になっていることは、わざわざ言葉にする必要性を感じにくいからです。さらに、受け取り手である私たちは、欠落した行間を良いように解釈し、徐々にずれていく...これがチーム内外さまざまなメンバー・調査で繰り返される...といった具合です。

また、業界の基礎知識や慣習といった背景知識をもっているかいないかで、ヒアリングして同じ内容を聞いていても、情報の受け取り方や解釈は変わってしまいます。ただ、その情報の受け取り方の違いに気づくことは困難です。

こうして、せっかく得られた定性データが不正確・欠落のある情報として意思決定に用いられることで、「顧客と話しているのに、プロダクトが伸びない」が起こります。

私自身、何度も定性データの扱いに失敗してきました。リリースした機能が使われなくてクローズしたり、出す機能の順番を誤ったり、そもそも提供したい価値の定義がうまくできていない、なんてこともありました。

それらの失敗から学んだのは、プロダクト開発において外さないためのコツがあるということです。

外さないためのコツ

では、どうすれば意思決定を外さない状態をつくれるのか？インサイトマネジメントによってズレを解消することも要素の1つですが、より俯瞰的に意思決定について考える必要があります。

プロダクトマネージャーや企画職、事業責任者のような立場の方にとって、意思決定（決めること）は大きな責務です。これらの役割に限らず、開発チームなどあらゆるチームにおいても、決めることの連続です。

どんな役割においても、プロダクト開発を外さないためのコツは、以下の3点に集約できます。

1. 意思決定のアンチパターン（失敗の型）を知ること
2. “判断を増やす仕組み”をつくること
3. 模倣できないほど、突き詰めること

1. 意思決定のアンチパターンを知る

外さないプロダクト開発のためには、まずは「外れるパターン」を知る必要があります。パターン認識できれば避けられるようになります。

そして、これまでの失敗や経験をもとにすると、外れる意思決定にはいくつかの特徴があります。

不透明な意思決定

決めることには主観が混ざりやすく、その決定の透明性が低いとチームの納得感も薄れてしまいます。透明性の低い意思決定が続くと、チームの勢い（モメンタム）が失われ、チームメンバーの自主性が徐々に失われます。最悪の場合、メンバーの意図しない離職につながることもあります。

全員で決める必要はないですが、「なぜこの意思決定なのか？」が説明可能であることは重要です。そしてそれは、「〇〇さんが決めたから」ではない状態になっていることが理想です。

判断を顧客に委ねてしまう

また、顧客の声を盲目的に信じ、顧客が欲しいと言っているものをつくれば「外れない」開発ができるわけではないということです。むしろ、顧客の欲しい機能をそのまま作り続けると、顧客が欲しかったプロダクトからどんどん外れていきます。

このパターンの危うさを感覚的に知るには、「解決策をひたすら聞かれる顧客役」をイメージするといいかも知れません。たとえば、自分の家を買いたいときに、「家の素材は何がいいですか？」「柱のサイズは何cmにしましょう？」など仕様を何度も聞かれるとどうでしょうか？

顧客は現状や問題に関してはプロですが、解決策に関しては素人であることがほとんどです。顧客の声は集めるものであり、その通りに開発するのはアンチパターンと言えます。

決断と判断のバランスが悪い

意思決定は、判断と決断の2つに分かれます。

前述の通り、決めるという行為は非常に属人性が高いので、なるべく透明性が高い決め方を作っておくことが重要です。

その中で重要なのは、事実に基づいた「判断」の領域を増やしていくことです。

とにかく情報を一箇所に集め、誰でも見えるようにして、理想的にはプロダクトマネージャーを介さずとも、開発するメンバーが情報にアクセスできるようにする。そうすることで「これは既知の事実である」と、誰が見ても同じ判断ができる土壌が整っていきます。

2. “判断を増やす仕組み”をつくる

不透明な意思決定を避け、判断を顧客に委ねることなく、判断を増やして決断を減らすこと。これができれば、意思決定の「空振り」（外れること）がなくなります。ヒットかホームランかの状態にできます。

これらの外れる要因を乗り越えるには、良い意思決定の仕組みをつくることが重要です。

その仕組みとは、以下のようなものです。

• 一次情報のインプット
• インサイトマネジメント
• 開発
• 顧客フィードバック

私たちのチームでは、これらを以下のようなプロセスに落とし込んでいます。

1. 検証する仮説の決定
2. 現場訪問・ヒアリング
3. インサイトとして構造化
4. 施策決定・具体化
5. 開発
6. フィードバック回収

この流れを回し続けることで、事実に基づいた意思決定の「判断」を増やし、スピードを高めたまま外さない意思決定を量産しています。

3. 模倣できないほど、仕組みを突き詰める

上記でお伝えしたような、プロダクト開発における「判断を増やす仕組み」について、実は特別なことは何もしていません。

仮説検証やアジャイル開発はもはやプロダクト開発のスタンダードでしょう。ここ数年取り組んでいるインサイトマネジメントも、特定のツールに依存するものではありません。

つまり、このプロセス自体は模倣可能なものです。

それでも差がつく理由

では、なぜこの模倣可能なプロセスが、チームによって結果に差を生むのでしょうか。

それはきっと、この仕組みをやり切ることが難しいからだと思っています。この差が、そのままプロダクト開発の打率の差になります。

いくつかの顧客ヒアリングをして、10個、20個インサイトが溜まった程度では、プロダクト開発で検証したい仮説やアイデアに対して、不足する場面も多いです。

数十では足りず、数百、数千と積み上がってはじめて、インサイト同士のつながりや全体の構造が見えてきます。この積み上がったコンテキストこそが、チームの「判断」を助けます。

つまり、この仕組みは、作るだけでは意味がありません。運用し続けて、やり切って、初めて意味を持ちます。私たちのチームでは、この運用を支えるためにインサイトマネジメントの基盤（Centou）を活用していますが、本質はツールではなく、この運用をやり切ることにあります。

インサイトを管理していないときと比べると、アドバンテージをもってスタートダッシュを決められているような感覚です。新しい打ち手を打つ時の初速が大きく違います。

私たちのチームでは、一次情報から得られたインサイトを日々蓄積し、それを共通言語として使っています。数回のヒアリングでは見えなかったものも、蓄積によって構造として見えてきます。

現在では1,500を超えるインサイトが蓄積されています。

1,500を超えるインサイトとその塊が見えていると「次に何を作るべきか分からない」という状態にはなりません。むしろ、「どんどん次にチャレンジしたいことが見えている状態」をつくれるようなっています。常に、次に探索すべきテーマが見えている状態です。

これまでの開発を通して、結果的にお客様からもありがたい声をいただき、さらに社内でも嬉しい声がいくつも生まれています。私以外のメンバーが、蓄積されたインサイトと自身の専門性を発揮して、「判断」をしている場面もいくつもあります。

これは、やり切って蓄積してきたからこそ得られた状態だと思っています。

“意思決定のスケール”に投資する

ここまでで、外さない意思決定について必要な3つの点について整理しました。

1. 意思決定のアンチパターン（失敗の型）を知ること
2. “判断を増やす仕組み”をつくること
3. 模倣できないほど、突き詰めること

これら、外さない意思決定の仕組みをつくる大きな目的の1つは、意思決定をスケールさせるためです。

プロダクトマネージャーとして意識していることは、意思決定を なるべく属人化させないことです。チームが判断できる領域を増やし、自分の存在を消していくことをめざしています。

プロダクトマネージャーがすべての意思決定に関与していると、プロダクトマネージャー自身がボトルネックになってしまいます。チームが判断できる状態を作ることで、意思決定そのものをスケールさせることができます。

そのために必要なのが、ここまで述べてきたような仕組みです。仕組みによって、意思決定のスケールを実現させられるのです。

仕組みとセットで重要なこと

意思決定のスケールという視点で見ると、判断の仕組みとセットで「共通言語づくり」もとても大切にしています。

チームが判断できている状態とは、言い換えるとチームの誰でも顧客の課題が語れる状態をつくることでもあります。

たとえば、顧客の似たような発言であっても、

• お客様の発言が出てきた背景
• これまでの関係性
• お客様が置かれている状況

など文脈（コンテキスト）を含んだ「発言の温度感」をチームに共有できることで、自律的な判断を促します。

私たちのチームではβ版プロダクトを開発している頃から、顧客の現場を訪問したら「現場行ってきた LT 」をするようにしています。

この LT では、

• 何を見聞きしたのか
• どんな業務をしていたか
• どんなポイントが面白かったのか
• プロダクト開発に活かせる学びは何か

を15分程度で共有し、チームで同じイメージを持てるようにしています。

こうした取り組みを継続することで、チームの誰でも顧客の課題が語れる状態を作り、維持し続けています。この状態があるからこそ、意思決定がスムーズになり、外れにくくなります。

やることではなく顧客の課題が共通言語になること、つまり「インサイトが共通言語な状態」をつくることで、誰か一人が承認しないと決まらない構造や人がボトルネックな状態を解消できます。

まとめ

プロダクト開発は、本質的に外れやすい営みです。だからこそ、「外さない意思決定の仕組み」を持つことが重要になります。

しかし、その仕組み自体は特別なものではありません。多くのチームが理解している、模倣可能なものです。

それでも差が生まれるのは、仕組みは作って終わりではなく、やり切ることにこそ難しさがあるからです。

インサイトを集め、共有し、学習し続ける。それを日々積み重ねることで、意思決定の質は上がっていきます。つまり、外さないプロダクト開発とは、特別なセンスではなく、意思決定の仕組みをつくり、運用をやり切ることによって実現されるものです。

そして、その「やり切り」こそが、最も模倣されにくい競争優位なのだと考えています。生成AIで誰でもすぐに機能がつくれるようになった時代において、いかに泥臭く情報を集め、構造化し、自分たちが作るべきものを「作り続けられる」か、ここが外さないプロダクトを作る分かれ目ではないでしょうか。

まずは、顧客の一次情報をチームで共有するところから始めてみてください。そこから、顧客課題を事実ベースでチームが語れるかチェックしてみてください。ズレがあれば少しずつ埋めてみてください。それだけでも、意思決定の打率が良くなりはじめます。