読者です 読者をやめる 読者になる 読者になる

サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ(前編)

f:id:chipa34:20161130094929p:plain:w300

こんにちは!

株式会社LITALICO CTOの岸田崇志です。 記念すべき『LITALICO Engineers Advent Calendar 2016』1日目の記事となります!

f:id:chipa34:20161020161425j:plain:w200

LITALICOでは現在『教育×テクノロジー』での可能性を広げるべく、チャレンジを広げています。 今回は、サービスを組み立てる話をしたいと思います。

1.はじめに

サービスを立ち上げの現場では戸惑うことが多いと思います。 特に初めての場合ははなおさらです。 サービスの企画を初めてやるときに、

  • どうやっていいかわからない。
  • やってみたものの何が正解かわからない。
  • 正しい方向に向かっているのかわからない。

といったことはありませんか?

サービス開発で失敗する場合は、ひとつひとつの施策がうんぬんというよりも全体設計や進め方が原因になっているケースが多いです。 どの組織でも大体ハマるパターンは決まっているため、症状別にまとめてみました。

タイプ別にみる失敗パターン

こんな経験や課題はありませんか? あなたのチームはどのタイプですか?

  • 行き当たりばったり症候群
    • サービス設計を場当たり的に進めてきたため、うまくいかないときに何が悪かったかわからない
    • サービスをいくつか作っているが、どれも鳴かず飛ばず
    • 日々とても忙しいが、振り返ると何をやったか思い出せない
  • 「世界取ってやるゼ!」症候群
    • やっているうちに計画が壮大になり、収集がつかない
    • いきなり大きなサービスを作ろうとして、結果凡庸なものになってしまった
    • 焦るがゆえに機能を盛り込みすぎた
  • 「俺とんでもないバケモノを生み出してしまったゼ!」症候群
    • 他サービスを「参考」にしすぎて、キメラみたいなツギハギサービスになった
    • 参考にしたものの見た目は似ているが、むしろ本家より使いにくい 劣化コピーになっている
  • サグラダ・ファミリア症候群
    • 今の組織の開発力では開発が不可能なものを対象としている。
    • 開発スケジュールを見積もれていない
    • また、開発はできそうだが壮大な時間がかかりそう
  • 自分探し症候群
    • 作っているうちに何を作りたいか見失ってしまった
    • チームでコンセンサスをとることに時間がかかる
  • 「事件は会議室で起きてるんじゃない!現場で起きてるんだ!」症候群
    • ミーティングがやたらめったら多い
    • 仕様書やプレゼン資料がやたらめったら多い

上記にような症状に誰しも心当たりがある方もあると思います。

サービスの企画において知っておくべきルールがあります。 それを説明していきます。

2.基本を理解しよう!

サービス設計には基本があります。 まずは基本の原理を理解しましょう。

f:id:chipa34:20161127114305p:plain

こう書くととても当たり前のように見えますが、当たり前を当たり前に設計をすることがサービス成長においてとても大事になります。 ユーザーの行動一つ一つは行動のモチベーションとアクションに分解できます。 これらの行動欲求とアクションがきちんと回っているか?を段階的に見たものが次に説明するAARRRです。

AARRR - Pirate Metrics(海賊モデル)

Dave McClureが提唱したモデルです。アーと読むのですが、発音しにくいのでPirate Metrics(海賊モデル)とも呼ばれます。

サービスが成長し続けるためには以下のサイクルを意識する必要があります。 AARRRの名称はサービスの各成長段階を表すAcquisition、Activation、Retention、Referral、Revenueの頭文字です。

スクリーンショット 2016-11-22 15.37.50.png

各項目を説明していきます。

  • Acquisition(ユーザー獲得)
    • アクイジションと読みます。ユーザーを獲得することです。
      • ウェブサイト、ランディングページなどへの初回訪問
  • Activation(ユーザー活性化)
    • アクイジションと異なり、訪問ユーザーのより積極的な行動に焦点を当てたステップがActivation(アクティベーション=利用開始)です。
      • 複数ページの閲覧・巡回
      • 「いいね」などユーザーアクションの実施
      • ユーザー登録
  • Retention(ユーザー継続利用)
    • 初回訪問及びアクティベーション以降、ユーザーがサービスを継続的に利用したか否かを計測するのがRetention(リテンション=継続)です。
      • 再訪問:1ヶ月以内に何回サービスを利用したか
      • これをトラックするためには一ヶ月以内に何回サービスを利用してもらいたいかというサービス設計(仮説)も必要です
  • Referral(紹介)
    • コンテンツを気に入った既存ユーザーが新規ユーザーを同コンテンツに紹介・誘導することです。
    • ユーザーがユーザーを呼ぶ仕組みで、これを設計できるかどうかがとても重要です。
  • Revenue(収益)
    • ユーザーからどれくらいの売上げをあげることができるか

必要なことは 打った施策により、どのくらいステップを進められたかになります。 単発の施策と単発の数字をにらめっこするよりこれをまず頭に入れてサービスを設計していきましょう。 次章では、まずサービスのコアとなるコンセプトの決め方を説明します。

3. サービスのコンセプトを設計しよう

f:id:chipa34:20161127114734p:plain:w300

サービスのコンセプトを設計するためにはリーンキャンバスを使うと便利です。 サービスを成長させるためにはその前にサービスの価値をきちんと設計しておくことがもっとも重要です。

リーンキャンバスを知る

リーンキャンバスとは、 O’REILLY から出版されている書籍「Running Lean」に掲載されている、ビジネスモデルの企画のためのツールです。 作ってから失敗をするよりも作れる前に検証できることがあればそれに超したことはありません。 そのためのツールになります。

  • 高速性

    • 必要な項目が1枚のシートに収まっているため、半日もあれば複数のビジネスモデルの概要が書けてしまいます。
  • 簡潔性

    • リーンキャンバスの記述により、推敲を重ねるうちにうまく要点を伝えられるようになります。 これは、コンセプトを抽出する練習にもなります。 ランディングページの訪問者の50%が、8秒以内に離脱すると言われているのでコンセプトの抽出はとても重要です。
  • 携帯性

    • 1ページにまとまるためサービスの全体像を簡単に共有できます。

リーンキャンバスについて

フォーマットは以下のようになります。画像をダウンロードしてお使い下さい。

  • フォーマット

スクリーンショット 2016-11-22 16.12.22.png

  • 各項目の説明
    • それぞれのフィールドと書くべき内容をマッピングしました
    • これに基づいて記述していきます

スクリーンショット 2016-11-22 16.17.56.png

  • 各項目と製品 / 顧客 / 市場
    • このようにそれぞれの項目は製品 / 顧客 / 市場に紐付いておりこの三者を俯瞰しながら設計することで初期に考慮すべき考え漏れをなくすことができます

スクリーンショット 2016-11-22 20.22.44.png

リーンキャンバスの使い方

各順番も重要です。手順を追って説明していきます。

  • STEP1: 課題と顧客セグメントの記述
    • 「課題」と「既存の代替手段」を記述します
      • 「課題」は特に優先度の高いものから3つ程度記述します
      • また、「課題」を感じている既存のサービスや手法を「既存の代替品」欄に記述します
    • 次にターゲットとする「顧客セグメント」を記述します

STEP1.png

  • STEP2:独自の価値(Unique Value Proposition)を考える
    • 「課題」で上げたものに対して、ユーザーに惹きのある機能や価値を考えます
      • これはとても重要なプロセスです
      • ここが魅力的でないとそもそも使ってもらえません
    • 前述したAcquisition(ユーザー獲得)やActivation(利用開始)に最も影響するポイントです

STEP2.png

  • 独自の価値(UVP)を考える上で以下のフレームワークで検討すると整理しやすいと思います
    • STEP1の顧客セグメントで書いたものと、課題をそれぞれ当てはめてみるといいでしょう
    • サービスによっては対象がBtoCとBtoBが混在したものもあると思いますので、それぞれで書きます

STEP3.png

  • STEP3:解決方法の検討
    • STEP2で決めたこのサービスのUVP(独自の価値)に対してそれを実現するための解決方法を検討します
    • 課題と照らし合わせながら記述していきますが、きちんと独自の価値提案につながるようなソリューションになるよう気をつけて記述します
    • 下の図に青の矢印で記述しているように「課題」「独自の価値提案」「ソリューション」これらをそれぞれ対応付ける形で書くことがポイントです

STEP3-2.png

  • STEP4:顧客セグメントの深掘り
    • STEP1で記述した顧客セグメントをここでもう一段深掘ります
    • アーリーアダプタ」が「独自の価値提案」に反応しそうか?を見ます
      • 反応が薄そうであれば「独自の価値提案」再度見直します
    • また、「アーリーアダプタ」の先の顧客セグメントを見積もります
      • 0がいくつつくかの想定ができる程度でいいです
      • 1万人なのか、10万人なのか、100万人なのか、1000万人なのかどのくらいの規模を対象としているのかを再度検討します
    • STEP4のプロセスがリーンキャンバスでは大事で、このようにシートの左右を行き来することで施策の精度を上げていきます

STEP4.png

  • STEP5:チャネルの記述
    • ユーザーにリーチするための手段です
    • それらを実践するためのチャネルを記述します

STEP5.png

  • STEP6:コスト構造と収益の流れの記述
    • 「コスト構造」と「収益の流れ」について記述します
    • 主には人件費などの固定費とプロモーション費用などの変動費となると思います
    • 収益の流れに書くものは、当初は読みにくいと思いますが何で収益を取るか、その時の単価をいくらにすれば「既存の代替品」とくらべてコストメリットがあるかという視点で検討するといいと思います
      • 既存がWebサービスでない場合などは、時間的制約や場所的制約を解消することにもメリットはありますので、そういったところから価格設定もできると思います

STEP6.png

  • STEP7:主要KPIの設定
    • サービスの成長をどのように追っていくかを考えます
    • ここで選定する指標はサービスが成長し続ける指標に設定するとよいです(これをトラクションと呼んでいます)
    • ここで使うのが先程ご紹介した「海賊モデル」となります。

STEP7.png

まとめ

このようにサービスを作る際には、リーンキャンバスを用いることで

  • プロダクトがユーザーさんが欲しているものか?
  • 課題と解決手法がマッチしているか?

を一覧してみることができます。

個々の要素をバラバラに考えるよりもそれぞれの要素を対比させて考えることで実現したいサービスを整理できます。 練習に既存のサービスをリーンキャンバスで起こしてみるのもいいでしょう。

5.次回は…

12/6(火) - 後編:サービスのサイクルを設計しよう asagao.hatenablog.jp

です。

LITALICO Engineers Advent Calendar 2016』も盛り上げていきますので購読いただけると幸いです。 明日は、石田さんの『分析基盤&BIツールについて』です。

おたのしみに!

広告を非表示にする
twitter: takish