顧客課題を「詳しい誰か」に依存させない
- プロダクト開発
顧客課題やインサイトの重要性は多くのところで語られるものの、「顧客課題を"詳しい誰か"しか語れない」ことのリスクはまだまだ知られていません。生成AIによって開発スピードが上がっても、「詳しいあの人に聞かないと進まない」状況では、結局のところプロセス全体でのスピードは上がりません。本ドキュメントでは、顧客価値にこだわるチームが、本当の意味でスピードを高めるための「チームでインサイトを扱う方法論」について探ります。
増え続けるミーティング
顧客課題に詳しくなるにつれ、あなたに1つの変化が起こります。
それは、社内からの相談の増加です。
例えば、あなたがプロダクトマネジメントや企画に関わっているならば、以下のような依頼が来るかもしれません。
- 〇〇機能を考えているが、どう思うか？
- XX機能のUIについてレビューをもらえないか？
- △△機能の仕様はこのようなもので良いか？
社内からの信頼があることは素晴らしいことです。チームにとっても、顧客解像度が高いあなたの存在はありがたいことでしょう。
しかし、徐々に問題が発生します。
相談が増えることは、ほとんどつまりミーティングが増えることです。あなたのカレンダーは「〇〇機能について相談」や「1on1」などの予定が増え、知らない間にギチギチの予定になります。
集中できるのは早朝か深夜、あるいは「ブロック」という予定をねじ込んだときのみ。徐々に集中は失われていき、説明する時間が増える。やった感はあるけど前に進んだ手応えはイマイチ。
顧客に詳しく優秀な人が、気づけば（頼れる存在な一方で）ボトルネックになってしまう事態が、さまざまな組織で起こっています。
顧客解像度を上げようと取り組んだことがレベル1だとすると、まさに今「レベル2」を私たちは模索する必要に迫られているのです。
- レベル1：顧客に詳しい「個人」をつくる
- レベル2：顧客に詳しい「チーム」をつくる
顧客課題をチームで共有された状態を目指す、このレベル2こそ価値提供のスピードを飛躍的に上げるための大きな一歩です。
個人の努力から、構造の変化へ
顧客に詳しくなることは個人レベルでできる取り組みです。顧客ヒアリングを行ったり、実際に顧客の生活や仕事現場に訪問することで、解像度を高められます。
しかし、「チームが顧客に詳しくなる」のは単に個々人の努力では限界があります。顧客と話すことと遠い業務（コーディングやデザイン、コンテンツ制作などなど）を行うメンバーと、普段から顧客と話すことが日常的な役割（セールスやCSなど）では、明らかに情報量も異なります。
つまり、チームが顧客に詳しくなるためには「みんな顧客と話そうよ」という努力型アプローチではない、構造を変えるアプローチが必要なのです。
では、個人からチームへ、顧客課題が共有された状態にするにはどうすれば良いのでしょうか？
まずは、現在の構造を理解するところから始めるのが良いでしょう。顧客に詳しいあなたの置かれた状況は、多くの場合以下の図のように整理できます。
各メンバーの相談ごととあなた、そしてあなたの脳内やどこかの議事録に散らばっている顧客インサイト（顧客課題・価値）、この3者の関係性を把握することが重要です。
あふれる「すり合わせのミーティング」が終わらないのは、「あなた"しか"顧客課題を語れない、あなた"しか"顧客課題についての判断軸を持っていない」構造から生まれています。だから、あなた経由でしか顧客課題にたどりつけない。
このような「インサイトが人に依存した状況」では、あなたが集中する時間が減ることはもちろん、相談をするメンバーの集中する時間も減ることになります。
顧客課題をチームで共有する
よりスピーディーに、より大きな成果を上げるには、各メンバーが自身で判断できることを増やせることが必要です。
顧客課題がストックされた場所（= インサイトセンター）があることは、顧客に詳しいあなたの多忙さを減らし、チームの生産性に大きく貢献します。あなたが毎回説明するのではなく、仕組みを通して各メンバーが自律的に顧客課題の判断ができるようになれば、あなたはより重要なことにフォーカスできます。
そして、このインサイトセンターについてより直感的に理解するためには、具体的な機能開発をイメージするのが効果的です。例として、タスク管理機能をあなたのチームでつくることを想定してみましょう。
- 施策の方向性レベル ... 該当シーンでの課題があることで、そもそも取り組むべきか判断できる
- UI・要件レベル ... 顧客の業務の流れやメンタルモデルがあることで、UIや要件に落とし込むことができる
- 実装レベル ... 顧客の利用人数・利用想定によって、実装の設計に落とし込むことができる
これらの全ての判断を、毎回あなたがミーティングに入っていては、体がいくつあっても足りません。何より、その分野の専門家にしかできない判断は、専門家が判断できる状況をつくってあげるべきでしょう。
話しながら決めることはもちろん重要ですが、それを前提にしてはスピードに限界があります。どんなプロセスでも「（課題を都度聞くのではなく）課題やインサイトをいつでも取り出せる状態」にすればするほど、専門性は輝きます。
事業やプロダクトの側面からも、企画シーンから実装シーンまで、徹底的にインサイト意識が高いチームでは、「どこにこだわるか？どこを捨てるか？」の判断がクリアになることで、一貫したリリースが可能になります。
実際にAmazonの1クリック注文機能や、家族アルバムアプリ「みてね」の立ち上げなど、大きな成長をしているサービスを研究すると、戦略から実装のどのプロセスでも一貫してインサイトを満たすような打ち手を打っています。
つまり、個人からチームへ、顧客課題をチームが語れる構造をつくることは、顧客課題やインサイトを以下のように捉え直すことに他なりません。
- インサイトは、誰かが頭の中で把握しておけばいいものではなく、可視化され他の人がたどれる状態にすること
- インサイトは、特定のプロセスだけで使うものではなく、どのプロセスでも使う「背骨」であること
- インサイトは、都度考えるのではなく、必要なときに取り出せるようにすること
自律的なチームをつくるために必要なこと
ここまで、顧客課題をチームが語れるようにするために必要な、構造を変えることについて掘り下げました。
さいごに、チームが自律的に動けるようになるための、インサイトセンター構築のヒントを提供します。
顧客に詳しいあなたの多忙さを減らし、チームの生産性を上げるためのインサイトセンターは、大きく2パートに分けて考えられます。
- 一次情報を集めること
- ビルドアップすること
まずは、一次情報を集めていくことが必要です。しかし、いきなり全てを集める必要はありません。集めること自体にも労力が必要なため、身近に集められる情報からはじめましょう。
一次情報は、インサイトセンターが価値を増すほど自然に集まるようになります。そのため、一次情報を完璧に集めてから次のステップにいくのではなく、次のステップ（ビルドアップ）に進みながら、必要に応じて集めるようにするスタンスで問題ありません。
そして、2点目こそ最も重要で、あなたの組織のインサイトセンターの価値を決めることになります。そのプロセスこそビルドアップ（具体から抽象へと組み上げること）です。
顧客課題やインサイトを考えることの難しさこそ、まさにこのビルドアップの思考にあります。
たとえば、事業計画で「100億円の売り上げをつくろう」と考えるとき、あなたはどのような思考をするでしょうか？
- 例 : 2年後に100億円の売り上げ
- →50億円はA事業
- →残りの50億円はB事業
- →1年後に20億円
- ...
- →1年後に20億円
などなど、このように目標から逆算することがほとんどではないでしょうか？
このような考え方は、抽象から具体へ「ブレイクダウン」するような思考プロセスです。
一方で、顧客課題やインサイトの思考法は、ほとんどの場合、ボトムアップに具体から抽象へと組み上げていくような、ビルドアップする思考プロセスです。
実際にさまざまなインサイト起点の成長事例を見ても、ビルドアップの思考プロセスで改善施策まで辿り着いています。
例 : Netflixの「イントロをスキップ」ボタンにおけるインサイト例
このビルドアップのプロセスこそ、「あなたのチームしか知らない、他社には内緒の顧客の秘密集」を作り上げていくプロセスであり、AIではなくあなたが主役になれる場面です。
上記の例ではシンプルな抽象化ですが、実態はもっといくつものステップを踏み、いくつもの具体→抽象のジャンプを行います。
このようなビルドアップのプロセスをチームで共有できれば、あなたのチームはより自律的に顧客課題を判断できるようになるでしょう。ビルドアップのプロセスの蓄積こそインサイトセンターの実態です。インサイトセンターがあるチームは、はるかにスピーディーで、はるかに気持ちよく動けるでしょう。
Centouでは、チームが自律的に動くためのインサイトセンターの構築を支援しています。「顧客に詳しいあの人」から、「顧客に詳しいあのチーム」になるために進化するステップを一緒に考えさせてください。
どこから始めるか？誰を巻き込むか？など、あなたのチームに合った動き方を、期間限定で無料の1on1を実施しております。いつでもこちらのフォームからご連絡ください。
その他のお役立ち情報 :
無料デモを依頼
