サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（後編）
こんにちは！
株式会社LITALICO CTOの岸田崇志です。 『LITALICO Advent Calendar 2016』6日目の記事となります！
1日目の記事の続きです。
今回はサービスサイクル設計の話になります。
コンテンツを設計していこう
前回はリーンキャンバスでサービス全体の設計の話をしました。
今回はサービスコンセプトを意識しながら、機能に落としこんでいくプロセスを説明していきます。
サービス全体はリーンキャンバスで設計すればよいのですが、そこから先どうやっていけばいいんだろう？という意見をよく耳にします。
そこで今回は、前回説明した「リーンキャンバス」に加え「遷移概要図」「モチベ天秤」について紹介します。
コンテンツ価値を高める
サービスはコンテンツ（機能）の集合体であり、各々の価値の集合体です。
前述したようにサービス全体と機能単位（画面単位）に順々に落とし込んでいきます。
サービスにおいて無駄な画面というのは存在しません。1ページ1ページを丁寧に構成していきましょう。
機能デザインとビジュアルデザイン
サービスを画面に起こしていく際にデザインという言葉がよく使われると思います。 デザインはデザインでも、
- 機能デザイン
- ビジュアルデザイン
に分けて起こしていくことが重要です。 多くの人はビジュアルデザインの視点に意識が多く行くことが多いのですが、本章で説明しているのは機能デザインの話になります。
機能デザインも以下に分かれます。
- 画面間
- 画面ごとの意味付けや、画面観での訴求方法
- 画面内
- 1画面のボタン配置やUIに関係するもの
まずは、図中の①の画面間の意味のつながりを作ることに注目して説明していきます。
遷移概要図を作る
きちんとしたワイヤーフレームを作る前に遷移概要図というものを作ると訴求したいものを整理できます。 遷移概要図は以下の3項目で書きます。
- 各ページの概要
- そのページで訴求したい項目を最大3つ
- 1画面でたくさん訴求しすぎないことが重要です
- それぞれの画面への遷移関係
- 遷移後きちんとユーザーの意図に沿った遷移になっているかを確認します
- 各画面の訴求が一画面だけでなく、一連の流れとして構成されているかを確認します。
それぞれの画面で何を訴求したいか？無駄な遷移はないかをざっくりとこれで当たりをつけます。 思考の整理にもなるのでオススメです。
この時点で複雑な遷移になったり、各画面で訴求項目が多くなりすぎるサイトはユーザー視点でもわかりにくいサイトということになります。
遷移概要図からワイヤーフレームに起こす
②に該当する部分です。 この部分についてはいろいろとドキュメントがあると思うので、 ここではそのテクニックは省きます。
Sketch（Sketch - The digital design toolkit）は直感的でとても便利なのでオススメです。
基本的な使い方は以下のリンクから学ぶのがオススメです。 アイコン素材なども多いのでスピーディーにUIを組み立てることができます。
各種ツールの使い方 memo.goodpatch.co
テンプレなどはこちら www.sketchappsources.com
モチベ天秤について知ろう
ここからは画面モックを作成した後に、画面単位でユーザーさんのニーズを満たすことができているかを検証していくステップを説明していきます。
全てのアクションにはモチベーションが伴わないと成立しません。 そこで必要なのがコンテンツ価値です。
ユーザーアクションとコンテンツ価値を図で表すと以下のようになります。 これをモチベ天秤と呼びます。
天秤の左手が「コンテンツ価値」。右手が「ユーザーの行動」です。 そもそもサービスに対してユーザーさんが価値を感じてくれなければ、行動をしてくれません。
ユーザーさんが行動をしてくれるためのサービス設計がとても重要になります。 それを押し上げるパワーが必要です。それが「コンテンツ価値」になります。
コンテンツ価値を検証しよう
画面単位で前述したモチベ天秤がきちんと回っているかを検証しながら設計します。
遷移概要図で記述した訴求項目がきちんとユーザーに伝わるかを確認します。
リーンキャンバスで設定したソリューションや独自の価値提案がきちんと実装できているかをチェックします。
その際に、機能単位で以下のチェックリストで追っていくとわかりやすいと思います。
行動チェックリスト
- 見たくない。欲しくない。
- 見るだけならいい。
- 見たい触ってみたい。（であれば、何分くらい？）
- 継続的に使いたい。（であれば、どのくらいの期間？）
- 課金してでも使ってみたい。（であれば、いくら？）
（※5に行くほどモチベーションが高い）
作り手が3以上の観点を持てない場合は無駄な機能かもしれません
行動に対する価値（対価）
ところでユーザーがサービスに対して支払える対価について考えてみましょう。
ユーザーはサービスに触れる時に大きく２つのコストを支払ってくれています。 それは「時間」と「お金」です。
ユーザーさんはお財布にも限りがありますし、時間にも限りがあります。その対価を支払ってでも利用してもらえるサービスかをしっかり考える必要があります。
サービス設計にはなんとなくはNGです。
- タイムシェア（時間）
- 一日のどういう時間をサービスに割いてもらえるか / 割いてもらうべきか
- 時間を割いてもらっても価値のあるサービス提供ができているか
- 既存の代替サービスで時間や場所がネックとなっているケースはないか？
- ウォレットシェア（お金）
- 使えるお金はどのくらいか。どのくらいの価格であれば使ってもらえそうか。
- 既存で似たようなサービスを使っている場合においては、どのくらいのコストを支払っているか？
モチベーション設計のポイント
各画面単位で無駄なくきちんと訴求していくという方向はなんとなく理解できたと思います。 そこで各訴求項目に対して、モチベーションがきちんと一致したものを提供してあげなければなりません。
この図のように作り手のして欲しいことは伝わりにくいです。 ですので訴求事項をわかりやすくして、このギャップをきちんと埋めていくことが重要です。
- 「きっとわかるだろう」は分からない
- 「こうしてくれるといいな」は伝わらない
願望的サービス開発は止めましょう。 モチベーションの源泉を常に意識する必要があります。
- 各ページで意識するもの
- 何が欲しいかを明確にする
- 欲しいものを提供してあげているか明確にする
- ユーザーさんは運営側が思っているほどコンテンツを見てはくれません。
- 自分に置き換えてみても、普段サイトを訪れた時にすぐに離脱するケースは多いと思います。
- 時間軸で意識するもの
- 来サイト直後
- 運営視点：来サイトしてすぐに何をして欲しい？
- ユーザー視点：来サイトしてすぐに何をしてもらえることでサイト価値を感じてもらえるか？
- 会員登録してくれた人は1週間後
- 運営視点：どのようなアクションをしていて欲しい？
- ユーザー視点：一週間後にどのようなアクションをすることでユーザーメリットがでるか？
- 一ヶ月後
- 運営視点：一ヶ月後にはどういう機能まで使っていて欲しい？
- ユーザー視点：一ヶ月後に居続けるとどういうメリットがある？
- 来サイト直後
それぞれの軸を運営視点とユーザ視点でみることでギャップを減らしていきます。
サービスを習慣化する
ここまで説明したことは、サービスの設計から画面に落とし込むところまででした。
ユーザーの欲しいものを設計するというところで、ユーザーさんにも生活があります。 生活とのフックポイントを意識し、どういうきっかけでサービスを使ってもらえるかの仮説を立てます。
再度リーンキャンバスに立ち返り精度を上げていきます。 ここは前編のリーンキャンパスで設計したときの「課題」や「既存の代替品」に該当します。
その時に見る視点は以下の3つになります。
既存の代替品で感じている困りごとや課題感を以下の観点から具体化します。
- どういうタイミングでほしいと思うか？（困り頻度）
- どのくらい欲しいか（困り度合い）
- 困っている期間はどのくらいか？（困り期間）
この3項目を掛け算し本当に欲しいものかどうかを検証します。 特に困りの度合いが低かったり明確でない場合はサービスとして成立しません。
困り度合いを見積もったあとに、実際どういった頻度で困りが発生しているか？どのくらいの期間継続しているかを明確にしていきます。
ユーザーを明確にする
どういう人に生活のどういうタイミングで使ってもらうかを明確にイメージする（ペルソナを立てる） 生活とサービスとの交流点を設計する ペルソナを明確にイメージすることが、重要です。 ここは前編のリーンキャンパスで設計したときの「アーリーアダプタ」に注目します。
アーリーアダプタの記述のときに、自分の身近にいる人など実際に課題を感じている人を想定したと思います。 その人をより具体的により詳細に詰めていきます。
プロダクトの初期バージョンをリリースしたときには、その人は良質なテストユーザーになってくれる人のはずです。
この流れができていないと、計画から市場テストまで一貫性がないということになります。 次節からペルソナ（ユーザー仮説）を立てるときのヒントを記述していきます。
時間に注目する
マクロトレンドを知ろう
ユーザーがどのような時間帯にスマホアプリを使っているかは以下のツールで調べることができます。
「Apps HEATMAP」は、株式会社ビデオリサーチインタラクティブが提供する、スマートフォンユーザーの アプリ利用データを多面的に分析できるサービス「Cloudish by App Ape」のアプリ起動ログデータをもとに 作成した、アプリカテゴリ毎のヒートマップです。
カテゴリ別にも見れるのでどういった時間にアクセスが多いかのトレンドを知ることができます。
- 一日何回か？
- どの時間帯か？
を設計しましょう。
マクロトレンドを踏まえてペルソナをイメージしよう
これだけだと漠然としてしまうので、以下のような観点から想定するとより具体的な生活シチュエーションが見えてくると思います。
- 何をやっている時？
- ex. 通勤時
- 何をやる前？
- ex. 仕事前、寝る前
- 何をやった後？
- ex. 食後、家事の終わった後
- 何と何の時間の間？
- ex. 学校と塾の間
上記のような観点から、ユーザーさんの状況にあわせて以下もチェックします。
- 使いたいと思ってもらえるか？
- 使うことにハードルはないか？
- ニーズを満たせているか
こういった観点から、リーンキャンバスの「ソリューション」「独自の価値提案」「圧倒的な優位性」にその部分が訴求できているかを見直してみます。 「課題」設定にブレがないかそれに対し解決方法がマッチしているのかを再度見直すことでサービスの精度が上がっていきます。
また、課題とサービス価値を明確にすることで一過性のサービスではなく習慣的にいかに使ってもらえるか？ ということが本質的な価値提供です。
サービスの価値仮説とユーザさんのニーズをうまくマッチするように設計し、生活の一部を豊かにするサービスとなっているかを検証します。
まとめ
前編・後編を通して、サービス開発においてリーンキャンバスをベースとして画面やモックに落としていくところまでの流れを中心に説明しました。
また、機会があればプロトタイピングなどより実践的な内容を説明できればと思います。
さいごに
サービスはいきなり上手くは作れないものです。
ものづくりの世界では誰しもみんなはじめからうまいわけではありません。
例えば、絵がうまくなるためにはたくさん描かないとうまくなりません。
これはサービス開発においても同じです。 当てずっぽうで作っていくのではなく、ユーザーさんが何を欲していてそしてそれに対してきちんと解決を提供してあげることができているか？を繰り返し繰り返し考えていくことでサービスがより良くなっていきます。
サービスを作れる人がたくさん増え、世の中によりよいサービスが増えてくると良いなと思っています！
そのような気持ちを込めて本記事を書かせていただきました。
明日は、髙杉さんの『リファクタリングからはじめる iOS Clean Architecture』です。
以上、『LITALICO Advent Calendar 2016』6日目の記事でした！
