サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（前編）
こんにちは！
株式会社LITALICO CTOの岸田崇志です。 記念すべき『LITALICO Engineers Advent Calendar 2016』1日目の記事となります！
LITALICOでは現在『教育×テクノロジー』での可能性を広げるべく、チャレンジを広げています。 今回は、サービスを組み立てる話をしたいと思います。
1.はじめに
サービスを立ち上げの現場では戸惑うことが多いと思います。 特に初めての場合ははなおさらです。 サービスの企画を初めてやるときに、
- どうやっていいかわからない。
- やってみたものの何が正解かわからない。
- 正しい方向に向かっているのかわからない。
といったことはありませんか？
サービス開発で失敗する場合は、ひとつひとつの施策がうんぬんというよりも全体設計や進め方が原因になっているケースが多いです。 どの組織でも大体ハマるパターンは決まっているため、症状別にまとめてみました。
タイプ別にみる失敗パターン
こんな経験や課題はありませんか？ あなたのチームはどのタイプですか？
- 行き当たりばったり症候群
- サービス設計を場当たり的に進めてきたため、うまくいかないときに何が悪かったかわからない
- サービスをいくつか作っているが、どれも鳴かず飛ばずだ
- 日々とても忙しいが、振り返ると何をやったか思い出せない
- 「世界取ってやるゼ！」症候群
- やっているうちに計画が壮大になり、収集がつかない
- いきなり大きなサービスを作ろうとして、結果凡庸なものになってしまった
- 焦るがゆえに機能を盛り込みすぎた
- 「俺とんでもないバケモノを生み出してしまったゼ！」症候群
- 他サービスを「参考」にしすぎて、キメラみたいなツギハギサービスになった
- 参考にしたものの見た目は似ているが、むしろ本家より使いにくい 「劣化コピー」になっている
- サグラダ・ファミリア症候群
- 今の組織の開発力では開発が不可能なものを対象としている。
- 開発スケジュールを見積もれていない
- また、開発はできそうだが壮大な時間がかかりそう
- 自分探し症候群
- 作っているうちに何を作りたいか見失ってしまった
- チームでコンセンサスをとることに時間がかかる
- 「事件は会議室で起きてるんじゃない！現場で起きてるんだ！」症候群
- ミーティングがやたらめったら多い
- 仕様書やプレゼン資料がやたらめったら多い
上記にような症状に誰しも心当たりがある方もあると思います。
サービスの企画において知っておくべきルールがあります。 それを説明していきます。
2.基本を理解しよう！
サービス設計には基本があります。 まずは基本の原理を理解しましょう。
こう書くととても当たり前のように見えますが、当たり前を当たり前に設計をすることがサービス成長においてとても大事になります。 ユーザーの行動一つ一つは行動のモチベーションとアクションに分解できます。 これらの行動欲求とアクションがきちんと回っているか？を段階的に見たものが次に説明するAARRRです。
AARRR - Pirate Metrics（海賊モデル）
Dave McClureが提唱したモデルです。アーと読むのですが、発音しにくいのでPirate Metrics（海賊モデル）とも呼ばれます。
サービスが成長し続けるためには以下のサイクルを意識する必要があります。 AARRRの名称はサービスの各成長段階を表すAcquisition、Activation、Retention、Referral、Revenueの頭文字です。
各項目を説明していきます。
- Acquisition(ユーザー獲得)
- アクイジションと読みます。ユーザーを獲得することです。
- 例
- ウェブサイト、ランディングページなどへの初回訪問
- Activation(ユーザー活性化)
- アクイジションと異なり、訪問ユーザーのより積極的な行動に焦点を当てたステップがActivation（アクティベーション＝利用開始）です。
- 例
- 複数ページの閲覧・巡回
- 「いいね」などユーザーアクションの実施
- ユーザー登録
- Retention(ユーザー継続利用)
- 初回訪問及びアクティベーション以降、ユーザーがサービスを継続的に利用したか否かを計測するのがRetention(リテンション=継続)です。
- 例
- 再訪問：1ヶ月以内に何回サービスを利用したか
- これをトラックするためには一ヶ月以内に何回サービスを利用してもらいたいかというサービス設計（仮説）も必要です
- Referral(紹介)
- コンテンツを気に入った既存ユーザーが新規ユーザーを同コンテンツに紹介・誘導することです。
- ユーザーがユーザーを呼ぶ仕組みで、これを設計できるかどうかがとても重要です。
- Revenue(収益)
- ユーザーからどれくらいの売上げをあげることができるか
必要なことは 打った施策により、どのくらいステップを進められたかになります。 単発の施策と単発の数字をにらめっこするよりこれをまず頭に入れてサービスを設計していきましょう。 次章では、まずサービスのコアとなるコンセプトの決め方を説明します。
3. サービスのコンセプトを設計しよう
サービスのコンセプトを設計するためにはリーンキャンバスを使うと便利です。 サービスを成長させるためにはその前にサービスの価値をきちんと設計しておくことがもっとも重要です。
リーンキャンバスを知る
リーンキャンバスとは、 O’REILLY から出版されている書籍「Running Lean」に掲載されている、ビジネスモデルの企画のためのツールです。 作ってから失敗をするよりも作れる前に検証できることがあればそれに超したことはありません。 そのためのツールになります。
高速性
- 必要な項目が1枚のシートに収まっているため、半日もあれば複数のビジネスモデルの概要が書けてしまいます。
簡潔性
- リーンキャンバスの記述により、推敲を重ねるうちにうまく要点を伝えられるようになります。 これは、コンセプトを抽出する練習にもなります。 ランディングページの訪問者の50%が、8秒以内に離脱すると言われているのでコンセプトの抽出はとても重要です。
携帯性
- １ページにまとまるためサービスの全体像を簡単に共有できます。
リーンキャンバスについて
フォーマットは以下のようになります。画像をダウンロードしてお使い下さい。
- フォーマット
- 各項目の説明
- それぞれのフィールドと書くべき内容をマッピングしました
- これに基づいて記述していきます
- 各項目と製品 / 顧客 / 市場
- このようにそれぞれの項目は製品 / 顧客 / 市場に紐付いておりこの三者を俯瞰しながら設計することで初期に考慮すべき考え漏れをなくすことができます
リーンキャンバスの使い方
各順番も重要です。手順を追って説明していきます。
- STEP1: 課題と顧客セグメントの記述
- STEP2：独自の価値（Unique Value Proposition）を考える
- 「課題」で上げたものに対して、ユーザーに惹きのある機能や価値を考えます
- これはとても重要なプロセスです
- ここが魅力的でないとそもそも使ってもらえません
- 前述したAcquisition(ユーザー獲得)やActivation(利用開始)に最も影響するポイントです
- 「課題」で上げたものに対して、ユーザーに惹きのある機能や価値を考えます
- 独自の価値(UVP)を考える上で以下のフレームワークで検討すると整理しやすいと思います
- STEP1の顧客セグメントで書いたものと、課題をそれぞれ当てはめてみるといいでしょう
- サービスによっては対象がBtoCとBtoBが混在したものもあると思いますので、それぞれで書きます
- STEP3：解決方法の検討
- STEP2で決めたこのサービスのUVP（独自の価値）に対してそれを実現するための解決方法を検討します
- 課題と照らし合わせながら記述していきますが、きちんと独自の価値提案につながるようなソリューションになるよう気をつけて記述します
- 下の図に青の矢印で記述しているように「課題」「独自の価値提案」「ソリューション」これらをそれぞれ対応付ける形で書くことがポイントです
- STEP4：顧客セグメントの深掘り
- STEP5：チャネルの記述
- ユーザーにリーチするための手段です
- それらを実践するためのチャネルを記述します
- STEP6：コスト構造と収益の流れの記述
- 「コスト構造」と「収益の流れ」について記述します
- 主には人件費などの固定費とプロモーション費用などの変動費となると思います
- 収益の流れに書くものは、当初は読みにくいと思いますが何で収益を取るか、その時の単価をいくらにすれば「既存の代替品」とくらべてコストメリットがあるかという視点で検討するといいと思います
- 既存がWebサービスでない場合などは、時間的制約や場所的制約を解消することにもメリットはありますので、そういったところから価格設定もできると思います
- STEP7：主要KPIの設定
- サービスの成長をどのように追っていくかを考えます
- ここで選定する指標はサービスが成長し続ける指標に設定するとよいです（これをトラクションと呼んでいます）
- ここで使うのが先程ご紹介した「海賊モデル」となります。
（おまけ）KPIを設定しよう
サービス成長をKPIで追えるようにする話となります。 数字を個別に見るのではなく、一連の線でみることがポイントです。 AARRRのうち、特にユーザーがユーザーを呼び続ける仕組みをブレイクダウンして見ていきましょう。 Facebookを例にブレイクダウンしてみます。
※ DAU：Daily Active Userの略で一日あたりに来訪したユーザー数 ※ UU：Unique Userの略で特定のサービスに来訪した人数
左の青い四角がサービスの実数値となります。 右の赤い四角がそれぞれの率となっていることに注目して下さい。これを中間指標と呼ぶことにします。
中間指標の分解の方法を上から説明していきます。
サービスに来たDAUのうち、ここではいいねを付けたユーザーの率を「いいね率」と定義しています。 いいねを付けたUUをDAUでわると「いいね率」が分かります。
次に、いいねUUに着目してみてみます。 いいねをしたユーザーでも、ユーザーによっては何回したかも変わってきます。 それを「一人あたりいいね回数」と定義します。 全体のいいねの回数からいいねUUで割るとひとりあたりいいね回数となります。
いいねの中でもどのくらいのユーザーに拡散しているのか？というのもしっかり見ておく必要があります。 いいねを受けたUUを「被いいねUU」と定義し、被いいねUU ÷ いいねUUをみると、いいねをしたUUといいねを受けたUUの比率がわかりますので、どのくらいのユーザーに拡散しているかがわかります。 被いいねUU ÷ いいねUUが「拡散率」となり、どのくらいのユーザーに拡散しているかを見る指標になります。
被いいねUUのうち再ログインに繋がった率が「再ログイン率」となります。 最終的には再ログインUUに繋がったかどうかを見ます
これらのうち大事なのが再ログインUUとなります。 再ログインに繋がった指標が赤い四角で囲われたどの指標が貢献したかを見たり、どの指標が足りていないのかを見ながら施策を打っていくことになります。
このように青い実数値と赤い中間指標を分けて記述することで、サービスの構造を分解できます。 例えばKGIを再ログインUUと定義すると、それに至る改善項目は赤い四角で囲った「いいね率」「1人あたりいいね回数」「拡散率」「再ログイン率」になります。 実数値は様々な要因でブレて追いにくいため、サービス改善には赤い四角の中間指標を元に改善していきます。
再ログインUUだけをみるとその要因はどこに起因するか見えにくいですが、このように設計することでどの施策がどの中間指標に響いたのか？を見ながらサービスを改善していきます。
ユーザーのアクションは「いいね」だけではないので、これを他サービスでも使える公式に書き直してみます。
被アクションユーザーには、Push通知やメール配信などで再訪しやすい仕組みも合わせて用意して上げる必要があります。
ソーシャル性が高いサービスでは上記の指標を用いて、ユーザーがユーザーを呼ぶ仕組みを作れているか？をまず設計するといいでしょう。
Facebookなどは、いいねなどのアクションが他ユーザーの再来訪を促す仕組みになっており、サービスが成長し続ける仕組みを築けています。 また、各ユーザーはいいねを押してもらいたいという欲求がありますので、その起点となりうるモチベーション設計も大事となります。
のスパイラルを設計はこの手のサービス成長の基本となります。 アクションがユーザーを呼び起こす仕組みにつながっているかをこのモデルで見える化します。
まとめ
このようにサービスを作る際には、リーンキャンバスを用いることで
- プロダクトがユーザーさんが欲しているものか？
- 課題と解決手法がマッチしているか？
を一覧してみることができます。
個々の要素をバラバラに考えるよりもそれぞれの要素を対比させて考えることで実現したいサービスを整理できます。 練習に既存のサービスをリーンキャンバスで起こしてみるのもいいでしょう。
5.次回は…
12/6（火） - 後編：サービスのサイクルを設計しよう asagao.hatenablog.jp
です。
『LITALICO Engineers Advent Calendar 2016』も盛り上げていきますので購読いただけると幸いです。 明日は、石田さんの『分析基盤&BIツールについて』です。
おたのしみに！
