アプリのマーケティング・プロダクトマネジメントで陥りがちな思考の壁（第2回アプリグロースラボ）

こんにちは、Product Growth Labの松下 三四郎です。

Software Engineerから始まり、Growth Hacker、UX Designer、Product Manager、メガベンチャーで事業責任者、マーケティング、CS、プロダクト開発、デザインの複数の部を配下に持つ本部長などを経験してきました。これまでの自身の経験や知識を踏まえて、CX Clipで「アプリグロースラボ」と題した連載を行っており、第2回となります。

第1回はこちら：「言葉の定義を揃える」ことから始めよう。アプリ企画者向け重要用語集（第1回アプリグロースラボ）

今回の記事の対象となる職種、役割

この連載は、スマートフォンのアプリ運用、プロダクトマネジメント、アプリマーケティングなどに携わる担当者とそのレポートラインの方（本部長や経営者）を対象にしています。

今回は、実際にアプリの改善をする担当者が主な対象になります。

はじめに

アプリを運営する目的として、より便利な生活にする、ビジネスとして成立させるなどそれぞれの事業や活動によって目的があります。

共通することは、利用者となるユーザーの問題またはペインを見つけ、それを改善することで結果として喜んでいただいたり、本来の目標を達成することを、アプリ運営者として目指していをることだと思います。

しかし、運営をしていると、日々さまざまな事象や問題またはペインに遭遇します。

例えば、ターゲットとなるKPIが成長できない、顧客からのクレームや要望が多い…

ときには、どうやって解決するべきか分からなくなったり、問題に対して何かしらの対策を講じてもうまくいかない…という結果を招いてしまう「思考の壁」が存在します。

その思考の壁を乗り越えることでよりシャープなアイデアが浮かび、結果アプリグロースに寄与すると考えています。

今回は、その「思考の壁」4つと、乗り越えるためのポイントもご紹介します。

1.フレームワークで手段の目的化をしてしまう

前提と事象

・世の中には多くのフレームワークが存在する
・そのようなフレームワークのインプット/アウトプットを理解せずに型から入ると活用が続かない
・運用を始めようとしたが、引き継ぎもできておらず誰もボールを持っていない

以前筆者が書籍の企画を頂いた時に、ある出版社の担当者に言われた言葉です。
「その考えは大変素晴らしい、是非フレームワークにしましょう！」

書店にはいつも魅力的で便利そうなフレームワークが溢れており、多くの人がフレームワークを知りたがっています。

しかし、本来あるべきは「業務で解くべきイシューをどのように解決するか？」であり、そこにフレームワークが接続していることです。そこがうまく接続しないまま「まずはカスタマージャーニーマップを作ろう、リーンキャンバスを取り入れよう、デザイン思考でやってみよう…KPIツリーを作ってみよう」と考えて実際にうまく運用できるかは難しいものです。挫折している組織をいくつも見てきました。

フレームワークのインプット・アウトプットの情報と目的がフィットしないとうまく整理できません。

例として「KPIツリー」を用いて、アプリのMECE（漏れなくダブりのない）なツリーを構築すると最もシンプルな形でこのようになるでしょう。

そこで、「お客さまは一回だけ購入してすぐにいなくなってしまう…　継続率をあげよう」となった場合、この「継続率」だけを見ても指標の粒度が大きすぎて、プロダクトのどの場所が問題なのか、顧客の困っている箇所はどこか状態が見えず、改善するべき箇所が具体的にならないのです。多くのチームがここで止まってしまう状態を見てきました。経営指標としてだけしか見られず、プロダクトの担当者が使えないKPIツリーが存在しているのです。

実際には、より深く多くのKPIが線で繋がっており、MECEに描き切ること自体に意味はありません。

「継続率」を一段掘り下げて、「翌日継続率」を置いた時、「翌日継続率」を上げるためには、更に前の行動のKPI設定が重要となり…MECEに描き切れるものではありません。

今回はKPIツリーを例に用いましたが、
思考の整理をするためには、インプットと、アウトプット、何をフレームワークに入れて何を導き出すかを知った上で使わなければ運用もできないし、チューニングして自分なりの型にすることもできません。

アプリのKPI設計については、詳しくはこちらの記事を参照ください。
アプリグロースの鍵！改善が回りやすいKPI設計とは

フレームワークを利用するために心得ておくこと
・フレームワークは思考の整理をするための一つの手段である
・何をインプットして、何がアウトプットされるか？
・それが達成したい目的にフィットするか？

2.ユーザーの便益ではなく、作りたい機能で考えてしまう

フレームワークの利用についての注意点を書きましたが、フレームワーク以外に何を頼りに企画や改善を進めるといいでしょうか。

事象

・Push通知を配信してもあまり効果が見られない
・継続率が向上しない
・Androidの数字が低い

アプリマーケティング・プロダクトマネジメントにおいて、事業者の悩みはつきませんが、上記のような事象に対して、むやみにクーポン配布や機能開発などを行ってもなかなか成果がでないケースが多いのではないでしょうか。

これらの事象の背景には事業者と顧客の間になんらかのコミュニケーションギャップが生じていると考えられます。良かれと思って作った機能やクーポン配布などの施策が、全く欲しがられておらず、時にはストレスになってしまうケースもあります。

ここで重要なのは
ユーザーはアプリの「機能」ではなく、そこから得られる「便益」に、お金や時間を使い継続利用してくれる
ということです。

これだけあらゆるサービスが存在し便利な世の中になっている時代、もはやユーザーは機能でサービスを選ぶのではなく、そこから得られる体験にどのような便益があるのか、という点でサービスを選ぶのです。

改めて、機能と便益について解説しましょう。

• 便益：便利で利益があること
• 機能：モノの働き、能力のこと

便益に限らず、他の言葉も前回ご紹介していますので参考にしてください。
「言葉の定義を揃える」ことから始めよう。アプリ企画者向け重要用語集（第1回アプリグロースラボ）

例えば、子供服のECサービスが2つあるとします。

1. 商品数が少ないが、オンリーワンでオーガニックや環境に優しい製品を取り扱うサービス
2. 低価格で業界ナンバーワンのラインナップ豊富なサービス

するとそれぞれのサービスの「便益」と、求められる「機能」には次のような差が出てくるのではないでしょうか？

1
・便益は、「子供の肌に優しい」「買うことそのものが環境に優しい貢献活動」「ギフトに最適」
・求められる機能としては、「創業者や作り手、素材のこだわりを知ることが出来る動画」「ギフト包装の見栄えについての紹介」商品数が少ない分、「スクロールするだけでこだわりを知ることが出来るページ」

2
・便益は、「幅広い商品から好きなものを選べる」「まとめてたくさん買える」「汚れても気にならない」
・求められる機能としては、「検索性が高い」、「身長、年齢、色から絞り込める」

便益は、顧客が感じているペインや欲求を満たし、解決するものになりえます。機能はそのための手段のうちの一部となります。
また、解決方法は、複数考えることも出来るため、設定すべき課題がズレてしまうと、解決方法も際限なく広がる可能性があります。

この点を見失ってしまうと、ユーザーが本来欲しかった便益にズレが生じ、刺さらない機能開発やクーポン・ポイントのばらまきなどによりユーザーが離れていってしまいます。

ただ、根拠なく便益を考えても、その便益ですらユーザーに受け入れられない可能性もあります。
そこで重要なのが、ユーザーが便益を得るための障害となっているペインポイントや置かれている事象を理解して解決すべき「課題」を定義することです。

ユーザーのペインポイントとは、ユーザーが何かをする時に困っていたり、プロダクトやサービスを利用する際に経験する、フラストレーションや手間などを引き起こす事象を指します。

このペインポイントは、社内にマーケティング・リサーチや、UXリサーチャーなどの専門家がいれば、その手法に則り実施しやすいでしょう。
しかし、専門家でなくても、調査会社を使って知ることもできますし、ユーザーと接点を持つセールスやマーケティングの社員を通じて聞き取りを行う、自分自身もユーザーであれば、どのようなペインポイントがあるかを書き出して、課題を定義してみるとよいでしょう。

課題を解決してくれる便益に「使う理由」があり、他社と比較しても独自性があることで「使い続ける理由」になるのです。

3.課題となるコンテキストを考えないまま、ユーザーのウォンツで考えてしまう

サービスを運営していると、顧客からのお問い合わせや、アプリストアのレビューに「使いにくい、だからこんな機能がほしい」などのご意見をいただくことがあるかもしれません。

顧客はアプリをダウンロードして、目で見て指で触って、他の日々使い慣れたアプリの感覚で「使いにくい」と感じたりしていると思います。その結果「あのアプリの機能があればいいのに…」と感じたのかもしれません。

ところで、そのお客さまの「欲しいもの」は本当にペインを解決してくれるでしょうか。
先ほど、ペインポイントを理解し課題を定義することが重要と書きましたが、ペインが発生する事象、環境、タイミング、そしてどのような人か、という取り巻く情報全ての「コンテキスト（背景、状況、場面）」を理解することが非常に重要です。

注意点として、ウォンツはあるものの、実際には使われない可能性があるものの例を挙げています。

例えば、

• ニュースサービスの「ブックマーク機能」
  また後で読みたいというニーズは実際にあると思いますが、日々変わるニュースは、常に情報が入れ替わっているため実は保存しても全く読まない、忘れてしまう可能性がある
• ECサイトの「多言語機能」
  越境ECの需要があったとしても、機能開発を先行してしまい想定より利用されず、運用上も負の遺産になってしまった

重要なことは
「ユーザーの"コンテキスト"を理解する」

だからこそ顧客は誰か？利用環境は？メインの時間帯は？デバイスは？場所は？その問題またはペインがいつ・どの頻度で発生する？といったコンテキストを理解することで、便益を届け、施策の打率を上げることができるのです。

4.仮説を立てず、数字だけで判断してしまう

昨今、生成AIを初め、多くの学習データによって、問いに対して精度の高い結果を返してくれる時代になりました。とはいえ、数字から仮説を立てる力は、これからも必須のスキルと言えるでしょう。

10年前になりますが、エンジニアからプロダクトマネージャーに転身し初めてのレポートをする時に、当時のマネージャーに言われた言葉です。

マネージャー　「その数字から何が見えますか？」
私　　　　　　「うーん、◯◯かもしれません」（しどろもどろで…）
マネージャー　「その◯◯だとユーザーはどんな状態ですか？」
マネージャー　「◯◯は数字はどうなっていますか？」

このやりとりはいつまで経っても自分の記憶に残っています。

これは「その結果になったユーザーの状態」の仮説を問われています。
当時の私は、表面上の数値をレポートするのみで、ユーザーの状態に対する見立てがなかったのです。

例えば、前述の「低価格で業界ナンバーワンのラインナップ豊富なサービス」を運営したとします。

便益は、「幅広い商品から好きなものを選べる」「まとめてたくさん買える」「汚れても気にならない」
求められる機能としては、「検索性が高い」、「身長、年齢、色から絞り込める」など

商品ラインナップが豊富なだけに、検索窓をトップページの最も目立つ場所に置いているとします。

検索を実行したユーザーが全体の40％だった場合、検索しないと商品に出会えないと想定してサイトを構成していた場合、残りの60％の人はどんな状態なのかを仮説立てる必要があります。

事実のデータを確認する
1.検索を実行しなかったとしても、検索画面に遷移したかどうか
2.検索画面そのものにたどり着かず、セール品のバナーをタップしていたかどうか
3.何もせず離脱したか

1の場合の仮説立て
1.検索の方法を知らない
2.検索ワードが思いつかない
3.検索条件が複雑

2の場合の仮説立て
1.最初からセール品のみ興味があった
2.セール推しの広告からサイトに流入してきた
3.検索窓の位置が目立たなかった
4.セールのバナーのクリエイティブが強すぎた

3の場合の仮説立て
1.サイトに出てくる子供服が好みじゃなかった
2.うっかり表示しただけ

ここでは、「検索を実行しなかったとしても、検索画面にいったのかどうか」を優先度1にして、検索画面に行ったのかどうかを検証し、仮説の可能性が大きそうなものから調査していくことにしました。

このようにここから可能性が高そうなものに優先度をつけ、より事実の状態に近づけていきます。

ユーザー行動の結果である「数字」ももちろん大事ですが、時にはユーザーインタビューなども行い定性的な情報も組み合わせながらコンテキストを捉え、仮説を立てていきます。仮説を通して事実に近づいていく行為が、今後の改善の「打ち手」につながっていくのです。

また、数字を見るときの注意点があります。
例えば、ユーザーがアプリをバックグラウンドに遷移させたとします。
アプリに飽きたり、アプリの使い方がよくわからずにバックグラウンドに遷移するというネガティブな理由も考えられますし、ユーザーが目的を達成したというポジティブな理由も考えられます。

ひとつのログだけでも様々な仮説が存在

競合との比較も大事ですが、数字を仮説立てて事実に近づける行為は、自身のサービスのユーザーの状態を理解することに繋がり、チームにとって今後のサービスの成長に最も有益な資産となるはずです。

重要なことは
・定性、定量面を行き来し、ユーザーの状態を仮説立てる
・ポジティブな面、ネガティブな面を洗い出す

いかがだったでしょうか？

ユーザーのコンテキストを定量、定性面で捉え、仮説を事実に近づける行為は、セールス、マーケティング、プロダクトすべての部門で有効な考え方となるはずです。

少しでも参考になる項目があれば、ぜひ取り入れてみてください。