プロダクト開発は、ますますスピーディで効率的になってきました。生成AIはもちろん、デザインシステムやテスト自動化、ノーコードツールなど、さまざまな側面からアプローチがなされてきました。

しかし、すばやくリリースできるようになった一方で、価値提供もすばやくなっているでしょうか？

あなたのチームが開発した機能やプロダクトは、開発速度に比例して価値提供（ひいてはそこから生み出される売上UP）ができているでしょうか？

本ドキュメントは、「速いリリース」を「速い価値提供」に繋げるために必要な「良い問い」についてまとめます。

リリースが速いだけでは、うまくいかない

冒頭にも記載したように、近年のプロダクト開発はますます効率的になってきました。

しかし、開発速度が早ければ十分なのでしょうか？

• 会社から「もっと売上につながる開発を」と、求められることが増えた

• ビジネス職種から、売上を優先されてプロダクトの検証が後回しにされる

• エンジニアにも、ビジネスや売上の意識が求められるようになった

などなど...プロダクト開発の現場ではこのような声も聞こえてきます。

実際に、SaaS CapitalのCEOであるTodd Gardnerによると2000年にリリースされたSaaSのうち、利益が出ている企業は11%しかないというデータもあります（※1）。また別の調査では、C向けのモバイルアプリに至っては0.5%しか収益に成功したアプリがないともされています（※2）。

※1 Growth vs. Profits in SaaS Company Valuations / Todd Gardner ※2 What Percentage of Mobile Apps Are Successful? / Mark Wood

このように、速いリリースだけでは、価値提供はうまくいかず、事業はうまくいきません。

「生産性」という大義名分をかかげ、（何を生産するかを後回しにして）リリース速度だけを追い求めてしまい、徐々に事業への貢献度合いが下がるプロダクトチーム...

そんなチームに待っているのは、納得感の薄いコミュニケーション、KPIや事業のプレッシャーからくる焦りと空回り、優秀なメンバーの退職、締切確認ばかりのコミュニケーションなどの悪循環です。

"良い問い"の必要性

では、リリースを遅くして熟考すれば良いのか？と言われると、そうではありません。常にある成長圧力の中で、スピードを遅くすることは現実的にも難しいでしょう。

そこで、必要なのが「良い問い」です。同じスピードでも、問いが違うとアウトプットも異なります。

闇雲なリリースではなく、価値にフォーカスしたリリースになるように、メンバーの行動を変える問いが必要です。

本ドキュメントでは、戦略レイヤー・機能開発レイヤー・改善レイヤー・組織レイヤーの4種類に分けて、必要な問いを示します。

問いの使い方

以下に示す問いに答えていくことで、「今考えていることが本当に価値になるか？事業成長につながるか？」が判断しやすくなります。

そして、問いリストの前に、その向き合い方の確認です。それぞれの問いには、具体的に回答するようにしましょう。

答えられない場合も、必ずしもチームの動きを止める必要はなく、「分かってないが、進む」とあえてリスクを取ることも時に必要です。進むことでしか得られない学習も多くあります。

あくまで、「今、わたしたちは、どれだけの不確実さを抱えてリリースをしようとしているか？」をチーム全員が認識できることが重要です。

1.  経営〜プロダクト戦略で必要な問い

戦略レベルで取り組む顧客課題・顧客インサイトがぼやけていると、各施策でどれだけ努力しても限界があります。プロダクト成長の天井を決めるのが以下の問いです。

つい流行の技術やKPIなど分かりやすい話題を出発点にしてしまいがちな方は、まずは自分自身でこっそり回答し、そしてチームで見直すことを強くおすすめします。

1. 現状把握 : 顧客は今、自社のプロダクトの代わりに、どんな代替手段を選んでいるか？

2. プロダクトビジョン : 顧客の「痛み」や「実現したい未来」が、プロダクトビジョンに明確に反映されているか？

3. ポジショニング : なぜ顧客に自社のプロダクトを選んでもらえるのか、選ばれる理由は明確か？（トップレベルのインサイトは何か？）

4. 注力する顧客課題 : 自社のプロダクトで、特に取り組むべき顧客課題はどれか？（取り組まない課題、やらないことは何か？）

5. プロダクト戦略 : 取り組むべき顧客課題のうち、売上や競争優位につながるものはどれか？

6. メトリクス : 自社のプロダクトが、顧客価値になっているかどうか測定できる指標はあるか？（その指標は、売上などの事業指標に連動しているか？）

7. ロードマップ : 複数の解決する課題や提供する価値に、「いつ取り組むのか」という優先順位が明確になっているか？

8. チームの解像度 : 「自社のプロダクトがあなたの課題をどのように解決するのか」について、他メンバーまたは顧客に説明できるか？

9. チームの解像度 : 今注力する顧客課題と、あえて今は注力しない顧客課題に対して、共通認識が持てているか？

10. 明確な根拠 : これまでの問いに対して、説得力のある顧客インサイトや元のデータがあるか？具体的な顧客名を例に挙げられるか？

2. 機能開発・プロジェクト単位で必要な問い

すばやいリリースを、確実に価値にするための問いがこちらです。

各施策でなんとなく類似プロダクトを模倣してしまっている場合や、「本当にやるべきなのか？どこまでやるべきなのか？」で議論が噛み合わない場合は、チームで目線をそろえましょう。

1. 目的の明確さ : 施策で解こうとしている顧客課題はなにか？

2. 事業との接続 : 今回取り組む顧客課題が解決されたことで、どの指標が伸びるか？

3. 現状把握 : 現在の施策が解こうとしている課題は「顧客のどんな状況・文脈で発生するか？」について明確になっているか？

4. 手段の確からしさ : 今回取り組む顧客課題は、本当にプロダクトで解決するべきものか？顧客へのコミュニケーション、コンテンツなど、他の手段で解決できないか？

5. ソリューション : 課題が発生しているシーンで、顧客がやりたいことは何か？

6. MVP : ソリューションを満たす最小限の要件や顧客体験は何か？

7. 建設的な議論 : 今回の施策が解決しようとしてる顧客課題・インサイトについて、各職種が納得感を持って、自分のアウトプットを出せているか？

8. 明確な根拠 : これまでの問いに対して、説得力のある顧客インサイトや元のデータがあるか？具体的な顧客名を例に挙げられるか？

3. 機能改善・要望対応で必要な問い

一度リリースした機能は、最初のリリースで終わることはほとんどないでしょう。「開発しっぱなしの機能がなんか多い気がする...」と感じてきた際や、「サクッとやれるからやろう」など実現可能性ファーストの対応になりすぎている時、幅広い要望に対応が後手になってきた時には、以下の問いをチームで見直しましょう。

1. ギャップの把握 : 改善に取り組もうとしている機能は、顧客課題をどれだけ解決できているか？（どれだけ解決できていないか）

2. 要望の解釈 : 届いた要望は、どの顧客課題・インサイトに属するものか？

3. 優先度 : 改善案や対処予定の要望は、本当に重要なものか？（「サクッとできるから」ではなく、今取り組むべき理由があるか）

4. コスト : より時間や実装工数をかけずに解決できる方法はないか？

5. 職種間の共通認識 : 「今プロダクトが解決すべき課題」について、他の職種も理解しているか？

6. 代替案の用意 : プロダクトで解決すべきだが後回しになった顧客課題について、他の手段で解決ができないか？

7. 明確な根拠 : これまでの問いに対して、説得力のある顧客インサイトや元のデータがあるか？具体的な顧客名を例に挙げられるか？

4. チーム体制・適切な開発プロセスに必要な問い

ここまでの問いに答えてきた方はすでにお気づきかもしれませんが、「顧客価値や顧客課題を事実にもとづいて捉える、チームでそろえる」というだけのことが、（普段おろそかにしていたチームにとっては）非常に難しいことに感じるでしょう。

答えられないものが多いと感じた方やチームは、これらの問いからスタートしましょう。

1.  議論の土台の用意: 満たすべきインサイトや解決すべき課題について、まとまったドキュメントなどがあるか？

2. 更新可能な状態 : 定義している顧客課題やインサイトについて、継続的に更新可能（デバッグ可能）な状態になっているか？

3. 議論可能な状態 : どの顧客課題に取り組むのか、なぜこの課題を優先するのかなど、チームメンバーが議論できる状態になっているか？

4. 自走可能な状態 : 取り組む顧客課題やインサイトをもとに、各職種が自分の専門性を発揮できる状態になっているか？（都度、キャッチアップやすり合わせが発生するような状態にならない仕組みがあるか？）

インサイトマネジメントでベストな答えにたどりつく

これらの問いに答えるには、一朝一夕の顧客理解、点の顧客理解では不十分です。

施策単位で間に合わせのユーザーインタビューを行ったとしても、得られるインサイトはほんのわずかです。きれいにまとめられつつも根拠不在のペルソナやジャーニー、その他の可視化も気休めにすぎません。

課題についてのインサイト、顧客の現状についてのインサイト、顧客が実現したい状態についてのインサイト、シーン別のインサイト...などなど、継続的なインサイトの蓄積・管理（インサイトマネジメント）が必要です。

生成AIによって、誰でもスピードが出せるようになってきた昨今、ますます「10のリリースで1の価値しか生めないチーム」と「10のリリースで100の価値を生めるチーム」の差はますます広がるでしょう。「たくさんリリース」はもはや強みにはなりません。

あなたのチームが、「速さだけでない強み」を得られることを強く願っています。

Centouでは、顧客価値に向き合うチームを、仕組みで支えるインサイトマネジメント基盤を提供しています。

開発速度向上だけでは頭打ちを感じている方、顧客課題や価値をチームで扱えるようにしたい方には、インサイトマネジメントのはじめ方からご相談に乗っております。ご興味がある方は、ぜひこちらのページからお気軽にご相談ください。