Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

やってはいけない!新規事業チームの最悪な1週間の過ごし方

こんにちは、ライブエクスペリエンス事業部のポリック (id: poric_ries) です。

 

僕らのチームでは、Running LeanやSPRINTなどのメソッドを実際に導入し、僕らなりにカスタマイズしながら、新サービス「JOYMO(ジョイモ)」を作っています。

joymo.herokuapp.com

 

本ブログは、

「リーン・スタートアップはもう古い?企業内新規事業でよみがえるLeanな事業立ち上げ」

をテーマに、新規事業開発現場の”実践録”をシリーズで配信しています。

 

▼配信済
#0.はじめに 
#1.走り出す前の準備
#2.やってはいけない!新規事業チームの最悪な1週間の過ごし方 ← 今回はここ

▼配信予定
#3.方法論をチューニングしながら走る!
#4.走り慣れてきた!案外すぐにゴールできるんじゃね!と思ったら...
#5.ターゲットを変えて再スタート!
#6.ダーティー&セクシーな検証
#7.to be determined

 

 

今回はいよいよSPRINT開始!1周目の実践録を配信します。

f:id:poric_ries:20180331150258j:plain

 

教科書通りに実践してわかった”本と実際の違い”や”躓きポイント”など、このブログを読んで実際にやってみようと思った方に役立つことを中心に話します。

 

 

[前提] チームのミッションと3ヶ月の過ごし方

1.チームのミッション

  • 3ヶ月間でProblem/Solution Fitを完了すること
  • アウトプットとして「MVP」をローンチすること

これが僕らのチームのミッションでした。このミッションを達成するために、Running LeanとSPRINTを組み合わせて進めることを決めました。(背景は#1を参照)

 

 

2.あらためて「SPRINT」とは

デザイン思考やIDEOのメソッドをベースにGoogle Venturesが開発したプログラムで、開発やローンチなく、アイディアを形にしてユーザーテストして学びを得る(Idea to Lean)、5日間のプログラムです。

f:id:poric_ries:20180403120921p:plainThe sprint gives teams a shortcut to learning without building and launching.

引用元:Google Ventures Web Site

 

新規サービスを立ち上げるにあたり、Running Leanに沿って最小最速で価値検証を進めたいが、ぶっちゃけ現場をどう回したらよいかわからん!と思った矢先に見つけたのがこの「SPRINT」でした。

 

f:id:poric_ries:20180403121859p:plain

参考:「SPRINT」を詳しく知るための書籍&サイト

 

3.三ヶ月の過ごし方

このSPRINTにもとづき、3ヶ月の過ごし方を計画しました。

はじめの2ヶ月でSPRINTを5周回して課題/ソリューションを決め、残りの1ヶ月でMVPと事業計画を作る。正直どうなるかわからないけど、とにかく走り始めました。

f:id:poric_ries:20180331133252p:plain 

 

 

 

[結果] 1周目はあえなく失敗!!!

結論から言うと、1周目のチャレンジはあえなく失敗しましたorz
なお、ここでの”失敗”の定義は「ユーザーに関する学びが得られなかったこと」と定義します。

 

1周目は”とにかく教科書通りに”と決めてタスクは進めていたものの、振り返れば、タスクの目的やそれに適した品質を見極めきれずに進めた部分があり、それが要因となって失敗しました。

 

失敗の原因はここだった!

次の2点です。

  1. ターゲット(誰のどの瞬間に焦点を当てるか)があいまいだったため、適切なフィードバックが得られなかった。
  2. プロトタイプが”リアル”さを欠いていたため、適切なフィードバックを得られなかった。

結果、最大の成果であるはずの「ユーザーに関する学び」を得られませんでした。

 

 

 

 

[経緯] 1周目を時系列で振り返る

何をどのように進めたら失敗したのか?今後チャレンジする方の参考になるように、ポイントは絞りつつ、背景や流れがわかるように時系列で説明します。

 

1.スケジュール

f:id:poric_ries:20180403124715p:plain

 

 

2.SPRINT前にやったこと

2-1.三ヶ月で取り組むテーマを決める

SPRINTに入る以前に、そもそも僕らのチームはまだ何をやるか決めていませんでした。新規事業の制約条件(#1参照) を前提に「何に取り組むべきか?」をまずは決める必要がありました。

 

▼アイディアを持ち寄る

 そこで、Running Leanで採用している「リーンキャンバス」を用い、「顧客セグメント」「課題」「独自の価値提案」をメンバー各々がリストに書いて、それをもとに議論しました。

docs.google.com

※アイディアリストを公開します。チームで相談し、ドキュメントも出来る限りオープンにします。

 

▼テーマを決める

議論を経て、次の順で取り組むことを決めました。

  1. [顧客] 子連れファミリー
    [課題] 子供と一緒に行けるお出かけ先が見つからない 
  2. [顧客] アクティブな独身 / DINKs 男女
    [課題] 行きたいところはあるが、一緒に行く人が見つからない
  3. [顧客] 最近残業の減ったビジネスパーソン
    [課題] 平日夜に何をしたらよいかわからない

 

 

2-2.顧客を知る

最初に取り組む「子連れファミリー」を深く知るべく、社内のパパ・ママに”子供とのお出かけ”にまつわる課題をインタビューをしました。

インタビューは、実際にお出かけするまでの流れを書き出し、何に困っているかをヒアリングしたり、例えば実際にスマホで情報を探す姿を観察して、気付きを得る形で進めました。

f:id:poric_ries:20180403172305p:plain ※現場の雰囲気を伝えるために画像掲載しています。画像が荒く内容は読めませんがあしからず。 

 

パパ・ママの悩みの理解が進んだところで、いよいよSPRINTを開始しました! 

 

 

3.SPRINT開始

3-1.月曜日:目標を決める

月曜日はSPRINTの目標を決めます。具体的には次の3つです。

●決めること

  1. 長期目標
  2. SPRINT Question(このSPRINTで答えを出すべき問い、以降SQと表記)
  3. ターゲット(誰の、どの瞬間を対象にするか)

f:id:poric_ries:20180401124516p:plain

 

正直、それぞれをどの粒度で決めて進めば良いのか不確かでした。

SPRINTの教科書に出てくる事例は、既存サービスの抱える具体的な問題を扱うケースが多く、課題や対象者が明確です。僕らのように”新規サービスまるっと”という大きな粒度のものはありません。悩みつつも、月曜日の終わりに決まった内容はこちらです。 

▼決まったこと

  1. 長期目標
    ファミリーに対して「やりたい!行きたい!」との幸せな出会いを提供し、人生の思い出を増やすこと
  2. SQ
    どうすればファミリー(パパ・ママ)は納得の行くお出かけ先が見つけられるか?
  3. ターゲット
    誰:子供を持つパパ・ママ
    瞬間:お出かけ先を探して決めるとき

これを残りの4日間の道標としました。 

 

 

失敗ポイント①:ターゲットがあいまい

1つ目の失敗ポイントは、ここで設定したターゲットがあいまいだったことです。

 

”ファミリー”とひとくちに言っても、両親の職業(共働きか否かなど)や、子供の年齢/性別/趣味嗜好によって休日の過ごし方は大きく異なりますし、課題も異なります。ユーザー理解は進めてはいたものの、肌感がまだ鈍く、具体性に欠ける、不明確なターゲットの設定となっていました。

 

これが原因で、ソリューション検討やテスト対象者選定などの後続タスクが適切に進められず、結果としてユーザーに関する学びを十分に得ることができませんでした。

 

【教訓】最速で検証できる(繰り返せる)からこそ、ぐいっとターゲットを絞り込み、明確に定義したほうが学びの精度は上がる

 

 

3-2.火曜日:目標を決める

SQとターゲットが決まったら、次はソリューションを作ります。

火曜日はアイディアを集めて適した形に改良します。既存のサービスをとにかく使ってみて、役立ちそうな既存ソリューションを集めて共有し、そのインプットをもとに全員が手を動かし、ソリューションを文字通り”手描き”しました。

 

 

3-3.水曜日午前:ベストを決める

水曜日は数あるソリューションの中から、プロトタイプを作ってテストするものを決めます。 

今回の問い(SQ)「どうすればファミリーは納得のいくお出かけ先が見つけられるか?」で焦点を当てたのは「納得のいくお出かけ先を選ぶ基準として最も重要な要素が何か?」という点でした。

 

●2つのプロトタイプ

この点に対してソリューションが2つあり、結局チームを2つに分けました。

  1. 選ぶ基準=人軸
    サービス名「eXer(エクサー)」:自分(パパ・ママ)の属性に近しい人のおすすめするお出かけ先を探せる・選べる
  2. 選ぶ基準=効果・効能軸
    サービス名「JOYMO(ジョイモ)」:何を学べるか(効果・効能)軸でお出かけ先を探せる・選べる

 

 

3-4.水曜日午後:幻想をつくる

アイディアが決まれば、次はプロトタイプ作成です。

 

●プロトタイプ作成

ツールは Keynoteを使いました。広告からWeb/アプリ画面まで全てのクリエイティブをこれで作り、リンク機能を使って画面遷移させました。このツールのメリットは、職種問わず全員が扱える=分業作業に適している点です。

 

実際に2つのプロトタイプ(各10画面程度)を2名ずつ手分けして、半日で作ったものがこちら(eXer / JOYMOはファイル紛失)です。

 

 

3-5.木〜金曜日: テストする

1日前倒しでプロトタイプ作成が終わった僕らは、意気揚々とユーザーテストを開始しました。

 

●ユーザーテストの風景

全員で同じ情報をインプットできるよう、appear.in を使ってユーザーテストの様子をリモートで観察しました。

f:id:poric_ries:20180402110820p:plain

 

結果は・・・プロトタイプに必要なある部分を決定的に欠いたため、ユーザーから適切なフィードバックを得られず、SQに対する答えを得ることはできませんでした。

 

失敗ポイント②:”リアル”さの欠けるプロトタイプ

さて、SPRINTの最大のメリットのひとつが、開発すると数ヶ月掛かるプロダクトを、たったの1日でプロトタイプを作ってユーザーに触ってもらい、学びを得られるという点です。

 

そして、これが成り立つための欠かせないポイントが、

プロトタイプは”リアル”に見えなくてはいけない 

です。

 

教科書に明確に書いてあったにも関わらず、その重要性を十分理解しておらず、僕らの最初のプロトタイプはこの”リアルさ”を著しく欠いていました。

 

リアルさを欠いた部分は次の2点です。

  • コンテンツの数が少なくて、そもそも探せる状態になっていない
  • 動線が1つしかなく、選ぶ行動(複数のコンテンツを見比べる等)ができない

要は、納得のいくお出かけ先を探して選ぶまでのUX(普通の使い方)を実現できないプロトタイプだったため、テストがワークしませんでした。

 

正直「このレベルなら自分たちで気付けよ」とツッコミたいですが、「このくらいでもわかってくれるだろう」というユーザーに対する安易な期待があったのだと思います。

 

【教訓】ターゲットを絞り込んだ上で、検証したいUXを実現しうる必要最小限のプロトタイプを作成すること。

 

 

 

まとめ

この5日間を通して、次のことを学びました。

教訓

  1.  最速で検証できる(繰り返せる)からこそ、ぐいっとターゲットを絞り込み、明確に定義したほうが、学びの精度は上がる。
  2. ターゲットを絞り込んだ上で、検証したいUXを実現しうる必要最小限のプロトタイプを作成すること。
具体的な改善策「ターゲットを明確に定義する」

そもそもここでターゲットを具体化できない場合、顧客の理解が足りない可能性が高いため、SPRINTに入る前に今一度「顧客を知る」ことが必要。

具体的な改善策「プロトタイプの品質を上げる」
  1. コンテンツの質と量を上げる
    ・選べるくらいコンテンツの数を揃える(例:一覧で最低2、3スクロール可)
    ・ユーザー毎にコンテンツを準備する(例:居住地に近いコンテンツを揃える)
  2. 探して選べる動線を作る
    Prottを使い、Keynoteで作った画面を繋ぎ合わせ、画面遷移を作る。メリットは、画面遷移が直感的UIでとにかく簡単に作れること。

 

また、今回SPRINTを導入することで仕事の基本動作/スタンスを改めて学ぶこともできました。

 

基本動作/スタンス

  • 何事にも時間を決めて取り組む
    時間枠(5日間、10〜18時)内で成果を出すと決めたことで、小さなタスクまで時間を決めて取り組むことで、単純なことなのに生産性が劇的に上がった。
  • 脳内一致する
    同じインプットを受けるだけでなく、分からなかったら率直に聞く、思いつきでもいいから意見があれば怖がらず共有するなど、当たり前の徹底でアイディアを高め合えた。
  • ユーザーに使ってもらう
    「人の欲しがるものを作れ」の根本。ユーザーから直にフィードバックをもらう大切さを改めて学んだ。

 

以上、いかがでしたか?

 

とにかく学びは多かったものの、手順や基本動作に関するもの多く、ユーザーに関する学びは2周目以降に期待!ということで、次回は「#3.方法論をチューニングしながら走る!」です。

 

次回もお楽しみに!