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

f:id:chipa34:20161130095746p:plain:w300

こんにちは!

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

1日目の記事の続きです。

asagao.hatenablog.jp

今回はサービスサイクル設計の話になります。

コンテンツを設計していこう

前回はリーンキャンバスでサービス全体の設計の話をしました。

今回はサービスコンセプトを意識しながら、機能に落としこんでいくプロセスを説明していきます。

f:id:chipa34:20161201164850p:plain

サービス全体はリーンキャンバスで設計すればよいのですが、そこから先どうやっていけばいいんだろう?という意見をよく耳にします。

そこで今回は、前回説明した「リーンキャンバス」に加え「遷移概要図」「モチベ天秤」について紹介します。

コンテンツ価値を高める

サービスはコンテンツ(機能)の集合体であり、各々の価値の集合体です。

前述したようにサービス全体と機能単位(画面単位)に順々に落とし込んでいきます。

サービスにおいて無駄な画面というのは存在しません。1ページ1ページを丁寧に構成していきましょう。

機能デザインとビジュアルデザイン

f:id:chipa34:20161130182017p:plain

サービスを画面に起こしていく際にデザインという言葉がよく使われると思います。 デザインはデザインでも、

  • 機能デザイン
  • ビジュアルデザイン

に分けて起こしていくことが重要です。 多くの人はビジュアルデザインの視点に意識が多く行くことが多いのですが、本章で説明しているのは機能デザインの話になります。

機能デザインも以下に分かれます。

  • 画面間
    • 画面ごとの意味付けや、画面観での訴求方法
  • 画面内
    • 1画面のボタン配置やUIに関係するもの

まずは、図中の①の画面間の意味のつながりを作ることに注目して説明していきます。

遷移概要図を作る

きちんとしたワイヤーフレームを作る前に遷移概要図というものを作ると訴求したいものを整理できます。 遷移概要図は以下の3項目で書きます。

  • 各ページの概要
  • そのページで訴求したい項目を最大3つ
    • 1画面でたくさん訴求しすぎないことが重要です
  • それぞれの画面への遷移関係
    • 遷移後きちんとユーザーの意図に沿った遷移になっているかを確認します
    • 各画面の訴求が一画面だけでなく、一連の流れとして構成されているかを確認します。

f:id:chipa34:20161201165442p:plain

それぞれの画面で何を訴求したいか?無駄な遷移はないかをざっくりとこれで当たりをつけます。 思考の整理にもなるのでオススメです。

この時点で複雑な遷移になったり、各画面で訴求項目が多くなりすぎるサイトはユーザー視点でもわかりにくいサイトということになります。

遷移概要図からワイヤーフレームに起こす

②に該当する部分です。 この部分についてはいろいろとドキュメントがあると思うので、 ここではそのテクニックは省きます。

Sketch(Sketch - Professional Digital Design for Mac)は直感的でとても便利なのでオススメです。

基本的な使い方は以下のリンクから学ぶのがオススメです。 アイコン素材なども多いのでスピーディーにUIを組み立てることができます。

モチベ天秤について知ろう

ここからは画面モックを作成した後に、画面単位でユーザーさんのニーズを満たすことができているかを検証していくステップを説明していきます。

スクリーンショット 2016-11-29 15.42.20.png

全てのアクションにはモチベーションが伴わないと成立しません。 そこで必要なのがコンテンツ価値です。

ユーザーアクションとコンテンツ価値を図で表すと以下のようになります。 これをモチベ天秤と呼びます。

スクリーンショット 2016-11-27 16.31.23.png

天秤の左手が「コンテンツ価値」。右手が「ユーザーの行動」です。 そもそもサービスに対してユーザーさんが価値を感じてくれなければ、行動をしてくれません。

ユーザーさんが行動をしてくれるためのサービス設計がとても重要になります。 それを押し上げるパワーが必要です。それが「コンテンツ価値」になります。

コンテンツ価値を検証しよう

画面単位で前述したモチベ天秤がきちんと回っているかを検証しながら設計します。

遷移概要図で記述した訴求項目がきちんとユーザーに伝わるかを確認します。

リーンキャンバスで設定したソリューションや独自の価値提案がきちんと実装できているかをチェックします。

f:id:chipa34:20161130175753p:plain

その際に、機能単位で以下のチェックリストで追っていくとわかりやすいと思います。

行動チェックリスト

  1. 見たくない。欲しくない。
  2. 見るだけならいい。
  3. 見たい触ってみたい。(であれば、何分くらい?)
  4. 継続的に使いたい。(であれば、どのくらいの期間?)
  5. 課金してでも使ってみたい。(であれば、いくら?)

(※5に行くほどモチベーションが高い)

作り手が3以上の観点を持てない場合は無駄な機能かもしれません

行動に対する価値(対価)

ところでユーザーがサービスに対して支払える対価について考えてみましょう。

ユーザーはサービスに触れる時に大きく2つのコストを支払ってくれています。 それは「時間」と「お金」です。

ユーザーさんはお財布にも限りがありますし、時間にも限りがあります。その対価を支払ってでも利用してもらえるサービスかをしっかり考える必要があります。

サービス設計にはなんとなくはNGです。

  • タイムシェア(時間)
    • 一日のどういう時間をサービスに割いてもらえるか / 割いてもらうべきか
    • 時間を割いてもらっても価値のあるサービス提供ができているか
    • 既存の代替サービスで時間や場所がネックとなっているケースはないか?
  • ウォレットシェア(お金)
    • 使えるお金はどのくらいか。どのくらいの価格であれば使ってもらえそうか。
    • 既存で似たようなサービスを使っている場合においては、どのくらいのコストを支払っているか?

モチベーション設計のポイント

各画面単位で無駄なくきちんと訴求していくという方向はなんとなく理解できたと思います。 そこで各訴求項目に対して、モチベーションがきちんと一致したものを提供してあげなければなりません。

スクリーンショット 2016-11-29 16.41.50.png

この図のように作り手のして欲しいことは伝わりにくいです。 ですので訴求事項をわかりやすくして、このギャップをきちんと埋めていくことが重要です。

  • 「きっとわかるだろう」は分からない
  • 「こうしてくれるといいな」は伝わらない

願望的サービス開発は止めましょう。 モチベーションの源泉を常に意識する必要があります。

  • 各ページで意識するもの
    • 何が欲しいかを明確にする
    • 欲しいものを提供してあげているか明確にする
    • ユーザーさんは運営側が思っているほどコンテンツを見てはくれません。
      • 自分に置き換えてみても、普段サイトを訪れた時にすぐに離脱するケースは多いと思います。
  • 時間軸で意識するもの
    • 来サイト直後
      • 運営視点:来サイトしてすぐに何をして欲しい?
      • ユーザー視点:来サイトしてすぐに何をしてもらえることでサイト価値を感じてもらえるか?
    • 会員登録してくれた人は1週間後
      • 運営視点:どのようなアクションをしていて欲しい?
      • ユーザー視点:一週間後にどのようなアクションをすることでユーザーメリットがでるか?
    • 一ヶ月後
      • 運営視点:一ヶ月後にはどういう機能まで使っていて欲しい?
      • ユーザー視点:一ヶ月後に居続けるとどういうメリットがある?

それぞれの軸を運営視点とユーザ視点でみることでギャップを減らしていきます。

サービスを習慣化する

ここまで説明したことは、サービスの設計から画面に落とし込むところまででした。

ユーザーの欲しいものを設計するというところで、ユーザーさんにも生活があります。 生活とのフックポイントを意識し、どういうきっかけでサービスを使ってもらえるかの仮説を立てます。

再度リーンキャンバスに立ち返り精度を上げていきます。 ここは前編のリーンキャンパスで設計したときの「課題」や「既存の代替品」に該当します。

f:id:chipa34:20161130175556p:plain

その時に見る視点は以下の3つになります。

既存の代替品で感じている困りごとや課題感を以下の観点から具体化します。

  • どういうタイミングでほしいと思うか?(困り頻度)
  • どのくらい欲しいか(困り度合い)
  • 困っている期間はどのくらいか?(困り期間)

この3項目を掛け算し本当に欲しいものかどうかを検証します。 特に困りの度合いが低かったり明確でない場合はサービスとして成立しません。

困り度合いを見積もったあとに、実際どういった頻度で困りが発生しているか?どのくらいの期間継続しているかを明確にしていきます。

f:id:chipa34:20161201164604p:plain

ユーザーを明確にする

どういう人に生活のどういうタイミングで使ってもらうかを明確にイメージする(ペルソナを立てる) 生活とサービスとの交流点を設計する ペルソナを明確にイメージすることが、重要です。 ここは前編のリーンキャンパスで設計したときの「アーリーアダプタ」に注目します。

f:id:chipa34:20161130175429p:plain

f:id:chipa34:20161130162531p:plain

アーリーアダプタの記述のときに、自分の身近にいる人など実際に課題を感じている人を想定したと思います。 その人をより具体的により詳細に詰めていきます。

プロダクトの初期バージョンをリリースしたときには、その人は良質なテストユーザーになってくれる人のはずです。

この流れができていないと、計画から市場テストまで一貫性がないということになります。 次節からペルソナ(ユーザー仮説)を立てるときのヒントを記述していきます。

時間に注目する

マクロトレンドを知ろう

ユーザーがどのような時間帯にスマホアプリを使っているかは以下のツールで調べることができます。

Apps HEATMAP

「Apps HEATMAP」は、株式会社ビデオリサーチインタラクティブが提供する、スマートフォンユーザーの アプリ利用データを多面的に分析できるサービス「Cloudish by App Ape」のアプリ起動ログデータをもとに 作成した、アプリカテゴリ毎のヒートマップです。

f:id:chipa34:20161130155756p:plain

カテゴリ別にも見れるのでどういった時間にアクセスが多いかのトレンドを知ることができます。

  • 一日何回か?
  • どの時間帯か?

を設計しましょう。

マクロトレンドを踏まえてペルソナをイメージしよう

これだけだと漠然としてしまうので、以下のような観点から想定するとより具体的な生活シチュエーションが見えてくると思います。

  • 何をやっている時?
    • ex. 通勤時
  • 何をやる前?
    • ex. 仕事前、寝る前
  • 何をやった後?
    • ex. 食後、家事の終わった後
  • 何と何の時間の間?  
    • ex. 学校と塾の間

上記のような観点から、ユーザーさんの状況にあわせて以下もチェックします。

  • 使いたいと思ってもらえるか?
  • 使うことにハードルはないか?
  • ニーズを満たせているか

こういった観点から、リーンキャンバスの「ソリューション」「独自の価値提案」「圧倒的な優位性」にその部分が訴求できているかを見直してみます。 「課題」設定にブレがないかそれに対し解決方法がマッチしているのかを再度見直すことでサービスの精度が上がっていきます。

また、課題とサービス価値を明確にすることで一過性のサービスではなく習慣的にいかに使ってもらえるか? ということが本質的な価値提供です。

サービスの価値仮説とユーザさんのニーズをうまくマッチするように設計し、生活の一部を豊かにするサービスとなっているかを検証します。

まとめ

前編・後編を通して、サービス開発においてリーンキャンバスをベースとして画面やモックに落としていくところまでの流れを中心に説明しました。

また、機会があればプロトタイピングなどより実践的な内容を説明できればと思います。

さいごに

サービスはいきなり上手くは作れないものです。

ものづくりの世界では誰しもみんなはじめからうまいわけではありません。

例えば、絵がうまくなるためにはたくさん描かないとうまくなりません。

これはサービス開発においても同じです。 当てずっぽうで作っていくのではなく、ユーザーさんが何を欲していてそしてそれに対してきちんと解決を提供してあげることができているか?を繰り返し繰り返し考えていくことでサービスがより良くなっていきます。

サービスを作れる人がたくさん増え、世の中によりよいサービスが増えてくると良いなと思っています!

そのような気持ちを込めて本記事を書かせていただきました。

明日は、髙杉さんの『リファクタリングからはじめる iOS Clean Architecture』です。

以上、『LITALICO Advent Calendar 2016』6日目の記事でした!

サービス開発は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ツールについて』です。

おたのしみに!

マイノリティ・リポートみたいなことができるサイバー手袋作ってみた

 

 

f:id:chipa34:20151219004223j:plain

 

こんにちは!

Arduino Advent Calender 2015 19日目の記事になります。

はじめに

今回は、昔からの憧れのマイノリティーリポートサマーウォーズなどそのような世界観をarduinoとunityを使って再現しようと思いました。

2007年にMITのsixth sensesをみてすごいなーと思ったのもきっかけの1つです。

 

コンセプト

手をセンシングデバイスと考え、手でバーチャル空間を操作することを考えました。

こんな感じのことを実現していきます↓ 

f:id:chipa34:20151218234059j:plain

 

使ったもの

  • MPU6050 :加速度センサー
  • 曲げセンサー112mm:指の曲げ伸ばしをこれで検知
  • タクトスイッチ:指先センシング用
  • 手袋:センサーを埋め込む本体
  • Unity:アプリ開発用

ブレッドボード図

f:id:chipa34:20151218100710j:image

 

できたもの

制作過程や成果物を動画に収めました。

こちらを御覧ください!

 

youtu.be

 

動画に力を入れすぎてブログが文字少なめになってしましました。

是非動画を見て頂けるとありがたいです!

今後について

  • これからこの手袋を使って様々なアプリを開発する土台ができました。2週間程度と十分な時間も取れなかったのでこれから徐々に完成度を上げていこうと思います。
  • また、より仮想空間のアプリや利用方法などを広げていこうと思っています

 

f:id:chipa34:20151215001744j:plain

 

 デバイスやセンサの価格がお手頃になったのでまだまだいろいろできそうです!

 

 

twitter: takish