ウォーターフォールからアジャイルへ、重厚な仕様書からプロトタイピング重視へ。

近年のプロダクト開発は、ますます探索的で価値提供に向いたプロセスへと進化しています。

そんな中、多くの組織でアップデートされていない領域が「顧客の声の扱い方」です。「言われた通りにつくらない」と分かっていながらも、要望を受けて開発・改善を行うスタイルは、いまだ根強く残っています。

本ドキュメントでは、そんな「要望駆動開発」の問題点を明らかにし、要望ベースの開発スタイルから次のステップへ進めるためのヒントをご紹介します。

要望駆動開発の限界

「顧客から言われていた改善を行ったのに、なぜか使われなかった...」「インタビューの時点では、欲しいと聞いていたが、つくってみたら全然反応がよくなかった...」

このようなプロダクト開発の失敗経験をお持ちの方は、少なからずいるのではないでしょうか？そして、「自分はそんな安直な失敗をしない」と意気込むプロダクトマネージャーほど、同じような轍を踏むことになります。

では、要望をベースにしたプロダクト開発には、一体どのような問題点があるのでしょうか？

実はリスクの多い要望駆動開発

要望駆動開発では、C向けB向けに限らず、以下のような開発プロセスを通ることが一般的です。

1. 顧客（未顧客の場合も含む）との接点を持つ（例 : 要望やユーザーインタビュー、商談、CSでのミーティング）

2. 聞いた要望を、開発チームへフィードバックする

3. 開発チームは、優先度をつける

4. 優先度に従って、開発を進める

一見、理にかなったプロセスに見えるこの開発フローは、いくつかの大きなリスクを背負っています。

1. 顧客が、自身の求めているものを正確に伝えられなければ、ソリューションも不適切なものになる

2. 声が大きな顧客 or 関係性が深い顧客の声が優先されやすい

3. 1, 2の点から、「解決策の判断」に負荷がかかりやすく、属人的になりやすい

これらのリスクから、要望駆動開発はプロダクトの成長や、チームのスケールを考えると非常に”ツラい”アプローチだと言えるでしょう。

※ 顧客が少数で非常にリテラシーが高い場合や、ソリューションの幅が小さい場合などは、要望駆動開発が効果的な場合もあります。

応えるほど複雑になり、改善が遅くなるプロダクト

では、このような要望駆動開発を続けると、一体どうなるのでしょうか？

1. 要望が増えるほど、機能 / 画面が増える

2. 機能や画面が増えるほど、ユーザーにとってはますます複雑になる

3. ますます複雑になるほど、ますます別の要望も出やすくなる

4. 機能や画面が増えるほど、ソースコードやデザインデータも複雑になり、開発上考慮することが増える

5. 考慮することが増えるほど、改善スピードが遅くなる

6. 結果として、「これまで3日でリリースできていたものに、1週間かかる」などが発生する

7. 解消されない要望が積み上がり、メンテナンスしきれない量のバックログが積み上がる

8. 要望のペースが増え、要望あたりの解消スピードが下がるため、開発チームに負担がかかる

9. 場合によってはチームの士気も下がり、退職者も増加する

このように、要望駆動開発によって低価値のリリースが量産され、プロダクトはますます複雑になり、開発チームにはジワジワと重たい負担がのしかかっていくのです。

なぜ要望駆動開発は無くならないのか？

ここまで、要望駆動開発のリスクや問題点について触れました。しかし、依然として要望駆動開発は根強く存在します。なぜなのでしょうか？

要望駆動開発から抜け出せないチームは、以下のような複数の部門（組織内の機能）をまたいだ問題が絡み合っているためです。

1. 顧客コミュニケーションの問題 : 顧客の刹那的な喜びを優先するあまり、要望の改善を（お土産として）連絡したいと考えてしまう

2. プロダクトマネジメントの問題 : 「要望がある」ことが、開発の拠り所（判断の起点）になってしまい、要望に応えることが価値を生むことだと盲信してしまう

3. 顧客との関係性の問題 : 顧客からの期待値が低く、「リクエストしたものをつくってくれる人たち」というベンダー的な立ち位置にしかなれていない

4. 過去の栄光の問題 : 立ち上げ期など「要望を聞いたらうまくいった」という経験があり、状況の変化に気づかないまま、同じスタイルの意思決定が繰り返されている

要望駆動開発から、インサイト駆動開発へ

このような問題点を解決するのが「インサイト駆動開発」です。

要望からインサイトへ、プロダクト開発の拠り所を変化させるこの開発スタイルは、顧客の喜びも、チームの喜びも増加させるためのアプローチです。

そして、インサイト駆動開発と要望駆動開発のもっとも大きな違いは、「顧客の声のどこを捉えるか？」にあります。

インサイト駆動開発では、要望として表面化される以前の「実際に起こったこと」「それを受けて顧客が感じたことや、行った代替行動」に着目します。

これらの「要望の手前にあるファクト」を捉えて、インサイトデータに変換することで、解決策の幅が広がり、根本的な解決が可能になります。

ただ要望を受け取るだけでは、この「要望の手前」を把握することは難しい場合も多いため、追加でのユーザーインタビューや、既存の顧客接点（CSやセールスでの接点）を活用する必要があります（= プロダクトディスカバリーの必要性）。

例えば、音楽ストリーミングサービスを例に考えると、「顧客の声のどこを捉えるか？」によって解決策の幅が違うことがよく分かるでしょう。

• 起こったこと : 旅行中のドライブで、音楽が途切れた

• 感じたことや代替行動 : 車内での盛り上がりが、損なわれたと感じた

• 要望 : オフラインで音楽を再生したい

起こったことや感じたことなど、要望の手前に目を向けると「通信環境が悪いところでも、音楽で盛り上がりたい」というインサイトが考えられます。

このようなインサイトは、旅行中の車の中だけでなく地下の施設（クラブ等）や、キャンプなどアクティビティーのシーンなど、いくつものユースケースで当てはまると考えられます。

実際に、Spotifyでは単なるオフライン機能ではなく「オフラインプレイリスト機能」というプレイリスト単位で、オフライン設定をできるように開発されています。

インサイト駆動開発のポイントは、まさに「要望より手前にある事実」を捉えることであり、事実からインサイトへ、インサイトからソリューションへという流れに転換することです。

実践方法

インサイト駆動開発を実践するには、以下のようなプロセス・スキルセットが必要となります。

1. プロセス : 「取り組むインサイトの探索・決定」というインサイトマネジメントをプロダクト開発に組み込む

2. スキルセット : 要望やその他の顧客接点を、インサイトに変換するためのスキル

さらに具体的には、これまでの要望駆動開発ではなく、以下のようなプロセスへと変化させていくことが求められます。

1. 顧客との接点を持つ（例 : 要望やユーザーインタビュー、商談、CSでのミーティング）

2. ファクトからインサイトへの変換（参考ドキュメントはこちら）

3. インサイトデータに沿った優先度づけ / 施策の具体化

4. 開発の進行

よりイメージを具体化すると、顧客接点からファクト、ファクトからインサイトへと練り上げられる様子は、まるで樹形図のように捉えられます。

そして、インサイト駆動開発（インサイトマネジメントを取り入れた開発）を実践し、プロダクト成長に取り組む、先端的な事例はいくつもあります。

• なぜ、インサイトを集めるのか？(カミナシmigi氏によるnote)

• 2500万ダウンロード超えのC向けアプリ「タウンWiFi byGMO」でのインサイトマネジメント

また、要望ではなく「インサイトデータ」を開発の拠り所にするためには、（特にB向けサービスなど）ビジネスサイドの協力が必要な場合もあります。

要望駆動開発の末路をしっかりと共有しながら、「要望ではなく、生データを渡してほしい」と明確にコミュニケーションしましょう。

インサイト駆動開発で、プロダクト開発を次のレベルへ

プロダクト開発は、とかく開発の速度やデザインシステムを用いたUIデザインの速さなど「デリバリーの速さ」に目を向けられてきました。

しかしながら、価値の薄いものを100個リリースしても、複雑さは増すばかりであり、「機能を減らす」というのは、実際のところ非常に行いづらい意思決定であることがほとんどです。

一見、顧客を向いた合理的な開発スタイルである「要望駆動開発」には、限界があることを強く認識する必要があります。

デリバリーの進化だけでなく、ディスカバリーの進化こそ、昨今のプロダクト開発の現場に求められています。

要望駆動開発から、インサイト駆動開発へ進化させることで、プロダクト開発プロセスもプロダクトチームも、次のレベルに進めましょう。

インサイト駆動のプロダクト開発へと進化させるためのご相談は、こちらのフォームからお気軽にお問い合わせください。