サービスの成長にとって、ユーザーに価値を感じてもらうこと(アクティベーション)は非常に重要です。

アクティベーションの成功なくして高いユーザー継続率（リテンション）は達成できないため、リテンションと並んで最も重要なフェーズだと考えています。

本記事では、アクティベーションを２つのフェーズに分解し、特に重要な1つ目のフェーズにおいてどういった考え方・手順で施策を行っていけばいいかを解説します。

アクティベーションを再定義する

アクティベーションとは、ユーザーがサービスに価値を感じることを指します。

したがってアクティベーションは、 ①そもそもサービスに価値があるのか、②その価値をサービスの初回利用時にユーザーにしっかりと伝えられているか(ユーザーオンボーディング)の２つのフェーズに分けられます。

言い換えれば、①サービスにそもそも価値が内在しているのか、②その価値をきちんとユーザーが認識できる形で届けられているか、という２つに分けられるのです。

多くの人がグロースハックは②以降のサービス利用の最適化作業だと考えていますが、それは違います。
いかに優秀なグロースハッカーでも、そもそも価値のないサービスのオンボーディング最適化はできません。

サービスに本当に価値があるのかというそもそもの前提を検証するところからグロースハックは始まります。

※ サービスに価値があるかを検証することを「Problem Solution Fit（PSF）」を検証すると言います。PSFという概念を知っておくとグロースの勉強をする上で非常に便利です。

PSF：まずユーザーが求めているかどうかを検証する

基本的にサービスのアイデア は「誰の・どんな課題を・どうやって解決するか」 という「顧客・課題・解決法」の3要素で成り立っています。

例えば、Airbnbであれば、「家を持て余している人」と「旅行者」という２サイドの顧客がそれぞれ「部屋や不動産が機会損失を起こしている」「ホテル代が高い」という課題を抱えているところに、「両者のマッチングプラットフォーム」という方法で解決を図っているサービスです。

PSF(プロブレム・ソリューション・ フィット)とは、そうしたアイデアの前提となる「顧客は本当にその課題を抱えているか (作り手の思い込みではないのか？)」「アプローチが間違った前提に立脚していないか」を検証するステップです。

多くのサービスやスタートアップが失敗する理由は、上記2つの前提が間違っていて、ユーザーから求められないサービスを作ってしまうことです。

そうした事態を避けるためには、サービスが解決しようとしているユーザーの課題が存在しており、ユーザーがそのサービスを求めているという“証拠”を本格的な開発を始める前から得る必要があります。

PSFの検証をスマートに行った２つの典型事例

PSFを検証するにあたって、多くの場合開発は必要ありません。

むしろ、PSFを検証する中でいかに自分たちのアイデアが誤った前提に立脚していたか気づくことになるため、開発は行わない方が機動性が上がって良い場合が多いです。

実際に開発の工数を最小に抑えてPSFを検証しきった２つの典型的な事例をここでは紹介します。

Pebble：コンセプト動画で顧客の反応を集めて検証する

スマートウォッチの先駆け的な存在であるPebbleは、Kickstarterというクラウドファンディングサイトでデモ動画を公開し、12億円以上を集め、実際に顧客から求められているという確かな証拠を得てから本格的な開発に入りました。

Zappos：最小限機能する製品で検証する

靴のECサイトである「Zappos」 はPSFをうまく検証した事例としても有名です。

当時、オンラインで靴は売れないというのが常識でした。
なぜなら靴は同じサイズ表記でもメーカーによって実際の大きさは異なっていたためです。実店舗での試着が非常に重要だったからです

しかし、Zapposの創業者は、「地方に住んでいて靴を買いに行くまでに時間がかかったり、実店舗よりも安く靴を買いたい人々が多くいるのではないか」「そしてECサイトという方法で彼らの課題を解決できるのではないか」と考えました。

そこで彼は、本格的なシステムを構築する前に、まずは注文ページのみのウェブサイトを作成し、注文が来るたびに創業者自らが実店舗に靴を買いに行っては梱包して発送するという行動を取ったのです。

これにより大規模な開発をせずとも PSFの検証、すなわち「想定した課題をユーザーが抱えており、サービスがその解決策として適切である」ことを検証することに成功したのです。

PSFをスマートに検証するためのフレームワーク

ZapposやPebbleのやり方のような検証をいざ自分がやろうと思ったときに、どうやれば良いのかと迷ってしまう人が多いかと思います。

実はPSFの検証設計を比較的簡単にできるフレームワークというものが存在します。
以下でそんなフレームワークである「Javelin Board」を紹介します。

■ PSFを達成するための基本的な考え方

先に述べたようにサービスのアイデアを突き詰めると、「誰の・どんな課題を・どうやって解決するか」、すなわち「顧客・課題・解決法」という3つの要素しかありません。

PSFの達成のためには、この「顧客」「課題」「解決法」という3つの組み合わせが正しいか、すなわち顧客が課題を本当に抱えていて、解決策がその課題に対して最も効果的なものになっているかを検証します。

そして、間違っている部分があれば、ピボット(方向修正)してまた検証を繰り返します。このサイクルを、3つの要素の仮説が正しいという確証が得られるまで行います。

■「ジャベリンボード」でスマートに検証する

PSFの検証、すなわち「顧客・課題・解決法」の 仮説が正しいかを検証する際には、Javelinが公開していた「Experiment Board」、通称「ジャベリンボード」の手法を使うと便利です。

ジャベリンボードは「顧客・課題・解決法」という1セットの仮説に対して、オフィスの外に出てユーザーと対話をするなどの実験を通し、ピボットを繰り返しながら検証するツールです。

以下で実際の使い方を紹介します。

■ STEP 1:ブレインストーミングをして最初の仮説をセットする

まず最初にサービスの「顧客・課題・解決法」をチームでブレストして、しっかりと定義します。

自分たちのサービスは「誰の・どんな課題を・どうやって解決する」サービスだと言えるのか。

ブレインストーミングが終わったら、出てきたアイデアの中からチームで1つのアイデアを選び、下図のようにボードの 1列目に「顧客・課題・解決法」 を貼っていきます。

■ STEP 2:最も検証すべき前提を洗い出す

「顧客・課題・解決法」という1セットのアイデア は、複数の想定の上に成り立っています。

例えば STEP 1で挙げたアイデアは、「1人暮らしの大学生は家に荷物を沢山持っているだろう」「1人暮らしの大学生は倉庫に荷物を取りに行くことに苦痛を感じないだろう」といった前提を想定しています。

したがって、これらの前提が実際に正しくなければ、STEP1の課題や解決策はそもそも間違っていることになります。

このように、その前提が崩れてしまうとアイデアが成り立たなくなってしまうという「検証すべき前提」を可能な限り洗い出します。

そして、それが崩れたときに最もサービスの根幹が揺らぐような前提条件を選んで、優先的に検証していくようにします。

この「最も検証すべき前提」 を選ぶときは、検証が必要な「不明度」と、前提が崩れたときのサービスへの「インパクト」のマトリクスでアイデアを位置付けると、分かりやすくなります。

※ 例えば「日本に十分な数の大学生がいる」という前提は崩れた時のインパクトは確かに大きいですが、この前提が正しいことは”明白”なため「不明度」は低いです。

■ STEP 3:検証方法と判断規準を決定する

先ほど選んだ「最も検証すべき前提」のアイデアをボードに貼り付け、それが正しいかどうかを検証する方法を考えましょう。

ここでは「1人暮らしの大学生は家に荷物を沢山持っているだろう」という想定を検証するため、「荷物が家の50%を占めているか」という質問を、道を歩いている1人暮らしの大学生10人にアンケートするという方法を考えてみます。

次に、どの規準を達成したら正しいとみなすかの基準値を決めておきます。

ここでは 「10人中 6人が Yesと回答」と設定します。基準値の設定で困ったときは、経験則的に妥当とされている60%を用いましょう。

■ STEP 4:オフィスの外に出て検証・学習する

「最も検証すべき前提」とその「検証方法」「達成規準」が決まったら、さっそくオフィスの外に出て検証していきます。
道を歩いている学生10人に 実際に話を聞いてみるのです。

そして、検証の結果をまとめ、「最も検証すべき前提」が正しいのかを判断します。

ユーザーと話す中では、検証以外にも学びを得られるように意識しましょう。
例えば、 検証の質問の他に、複数のオープンクエスチョン (はい/いいえでは答えられない質問)をすることで、さまざまな気づきを得ることができます。

検証の結果、「荷物が家の50%以上を占めている」 と答えた大学生は2人だけだったとすれば、「1人暮らしの大学生は家に荷物を沢山持っているだろう」という前提条件は間違っていたことになり、想定していたような課題を顧客が抱えていないということが分かります。

■ STEP 5:学びを生かしてアイデアをアップデートする

インタビューで検証した結果、始めに想定していた前提条件が間違っていたことが分かりました。

そこで、新しい顧客、または課題を設定する必要が出てきます。すなわち、「顧客」もしくは「課題」のどちらかをピボットするのです。

このとき、インタビューで得た学びが役に立ちます。

「むしろ実家のほうが荷物であふれている」という学びがあれば、顧客を「都心の家族」にピボットする、といった具合です。

■ STEP 6:確証を持てるまで検証&ピボットを繰り返す

「顧客・課題・解決法」という1セットのアイデアに対して、「検証すべき前提」が全て検証し終わり、アイデアに確証を持てるようになるまでSTEP1~5を繰り返しましょう。

私の経験上、5周も繰り返せばかなりの精度でアイデアの検証ができます。

ユーザーに求められていることを確認するところからがグロースハック

冒頭で述べたように、細かいサービスの最適化の前に「そもそもこのサービスに価値があるのか」を検証し、その価値を最大限高めるところからがグロースハッカーの仕事です。

本記事で紹介したJavelin Boardなどのツールを使いながら、皆さんのサービスが「”俗にいうグロースハック”を始めるべきステージにいるのか」を確認しましょう。