1. 「手探りで始めた
企業内スタートアップで嵌まったことEX」
in DevLOVE現場甲子園2014 東日本大会
株式会社ヴァル研究所
Business Development Dept. 部長
篠原 徳隆

2. 自己紹介
プロフィール

3. 篠原徳隆（しのはらのりたか）
株式会社ヴァル研究所
Business Development Department
部長
1999年 ヴァル研究所入社。
企業の基幹・業務システムの開発を経
て、駅すぱあとを利用した旅費や通勤
費などの精算業務のシステムを開発。
その後3年間の営業経験を経て、プロ
デューサーとして社内の新企画に従事。
2013年よりBusiness Development
Dept.にて新規事業を模索中。
主なプロダクト
通勤費管理システム
通勤費申請Web
駅すぱあとWebサービス
まるごと路線図（iPhone/iPad）
駅すぱあと for iPhone

4. 今回の内容について
手探りで始めた企業内スタートアップで嵌まったことEX

6. 今回のお話は2014/5/16にDevLOVEにてお話させて頂いた
「手探りで始めた企業内スタートアップで嵌まったこと」
の続編になります。
スライドシェア
http://www.slideshare.net/noritakashinohara/dev-love20140516-ss

7. 前回はMVPリリースまでに嵌まった事についてお話しました。
「インタビューが空振った」
「MVPという言葉に振り回された」
「ユーザーにリーチできない」
「チームが加速しない」
今回はMVPリリース後に現在進行形で嵌まっている事について
お話したいと思います。

8. MVPの検証で嵌まったこと
手探りで始めた企業内スタートアップで嵌まったことEX

9. MVPの検証条件が整っていたのか迷った

10. あらまし
MVP開発において、ある問題を抱えてました。
「Chrono」はお店の検索をさせずに、ユーザーが好みそうな料理を
写真で表示して、且つ現在地から直ぐに行けるお店をオススメする
事を目的としています。
実現の重要な要素は「検索しない」という事と「料理写真」です。
前者はキュレーションロジックで解決できる目処は立てていました。
ですが、問題は後者。我々が想定するシチュエーションで使う為に
必要な情報については、当時から不足しているという認識でした。

11. コンテンツのクオリティが体験に大きく影響することは、「駅すぱ
あと」の経験からも分かっていました。
（ダイヤや運賃等のデータクオリティはユーザー体験に大きく影響します）
しかしながら、我々は自分達が欲しい情報（コンテンツ）を揃える
だけのリソースも資金も備えてはいないのが現状でした。

12. そもそも今回のMVPで検証するべき仮説はChronoの価値提案
「2分でお店を決めて5分でお店に到着する」
が本当にユーザーに刺さるのかを検証することにあります。
であれば、キュレーションロジックを実装し、店舗情報も今できる
範囲の中で利用可能なAPIを使わせて貰って、キュレーションを実現
する事に注力する事にしました。

13. 検証
MVPの検証方法として以下の項目を計測することにしました。
①ニュースリリースの反響具合
②DL数
③アクティベーション率（初回起動）
④定着率

14. 検証結果（MVPリリースした当月）
①ニュースリリースの反響具合
LINEニュースや産経など、6つのメディアに取り上げて頂きました。
（それ以外にも飲食キュレーションアプリの認知度調査にランクインしてたりしました）
②DL数
最初の1週間で1500DL。
販促施策がニュースリリースぐらいであることを考えれば、数字は
それほど悪くないと思いました。
③アクティベーション率（初回起動）
81.4%。
④定着率（同月に2日以上利用した率）
77.6%。かなり高いという印象。

15. 出足は上々。
この結果から見れば、飲食におけるキュレーションへのニーズは存在
していると言えると思うし、アーリーアダプターを1000人以上獲得
できたことは今後の検証においても価値のあることだと思いました。
ですが・・・

16. コホートによる厳しい現実
コホートでユーザーの利用頻度を計測しました。
週を経るに従って、ユーザーの利用頻度が下がっていきます。
月別に見れば、DLしたユーザーのアクティベーション率や定着率は
相変わらず高いです。ですが、週を経ると利用頻度が急激に下がる
ことがコホートにハッキリ現れていました。
何故か？
表示されるコンテンツのクオリティが、ユーザーの期待値、とくに
ランチというシチュエーションでは要求に満たないからだと我々は
考えました。

17. 疑念
こうなることは分かっていたはず。
それでも仮説は検証できると思ったからこそ、対応しなかったはず。
しかしながら現状を見てしまうと、MVPの仮説を検証する条件が
整っていなかったのではないか、検証は店舗情報のクオリティも担
保した状態で行うべきだったのではないか、それがMVPリリースと
はいえ初回リリースという絶好の機会を台無しにしてしまったので
はないかという思いに苛まれました。

18. どうしたか
開き直りました。
わかっていた事であれば、それも仮説通りではないかと。
つまり、今回のMVPでは必要だと思える２つの要素を異なるアプ
ローチで検証し、1つは実現することで必要性を検証でき、もう1つ
は実現しないことで必要性を検証できたのです。
と、学習できたことに意味を見いだしました。

19. 振り返って
キュレーションと店舗情報の二つに割けるリソースはなかったし、
両方とも揃えて失敗するより、一番検証したいところを先に検証し
ておく事は間違ってないと思います。
もちろん、今の状況を考えれば両方揃えてリリースできていれば、
順調だったかもしれません。
ですが、店舗情報の検証だってやっぱり必要だと思います。
情報があれば本当に良いのかどうか、どう集めるべきなのか、情報
が有効性はどうなのか・・・。

20. 振り返って
それにMVPに盛り込む仮説が多くなると、PDCAを回すサイクルが
どうしても大きく（遅く）なります。
MVPの言う実用最小限の商品というのは、最小限の仮説検証と
いう意味もあるではないかと、私は思いました。
（どっかに書いてあったらすいません）

21. まとめ
学習できたことに価値を見出しましょう。
失敗したくないですけど、失敗にも意味があります

22. KPIで嵌まったこと
手探りで始めた企業内スタートアップで嵌まったことEX

23. KPIの会社との合意方法を間違った

24. あらまし
Chronoに限りませんが、プロジェクトのKPI設定はプロジェクトを
発足させる段階で設定します。
ということは、そもそも課題検証からで、何を作るかも分からない
段階でKPIを設定する訳です。

25. 新たな手法に合わない評価制度
従来であれば、プロジェクト発足時に事業目的や事業計画などを通
して、KPIとして捉えられるものがあるのですが、今回のプロジェク
トは特定のミッションや課題解決などが目的に設定されておらず、
ゼロベースから模索する実験・検証的なものでした。
会社もこの様な形の取り組みが初めてだったこともあり、最初から
評価方法については課題があるという認識ではありました。

26. 要求のズレ
課題を認識しながらも、KPIは設定しなければなりません。
リーンスタートアップの手法で進めるという事は共有できていても、
その手法への理解は様々で、「MVP」を素早く作って検証するとい
う部分だけを大きく捉えて話す人が多く、KPI設定においてもMVP
リリースとそれによるユーザー獲得を要求されました。
この時点ではまだ私自身未知数な部分が多く、この要求に対しても
アウトプットへの評価としては妥当ではないかと考えていました。

27. どうだったか
課題インタビューやモックを使ったソリューションインタビューな
ど、不慣れな要素が多く時間が掛かってしまいました。
また、フィードバックの中でリーンキャンバスの見直しも多く発生し、
実現方法の検証など、各要素の検討・検証にも時間を要してしまい
ました。
結果、顧客検証に時間を取られて、予定の期間内ではMVPリリース
できず、ユーザー獲得以前の問題でした。
理由はどうあれKPIは未達であり、未達としての評価が自動的に付き
ました。救済措置はあったものの、これはメンバーの士気を落とし
てしまいました。

28. 余談ですが
顧客検証への時間の割き方については、平行して動かしてた異なる
プロダクトで実験していたのですが、甲乙つけがたいと言ったとこ
ろです。
この辺はスタートする時点での課題設定の状況で異なるのかと思い
ます。（誰かの課題が先にあるのか、潜在する課題を見つけるのか）

29. どうするべきだったか
①フェーズを分けてKPIを設定する
進める中で内容も変わって行きます。そもそも中止する可能性もあり
ます。それらを見極める為にもプロダクトをリリースする前提でのKPI
設定ではなく、フェーズ毎のKPI設定が良いと思います。
また、その課程でKPIの意味も変わるし、大事にしなければならない
KPIが他にあるかもしれませんので、KPIの変更も柔軟にできる様にし
ておいた方が良いと思います。

30. どうするべきだったか
②新たな取り組みに対する評価方法は新たに最初に考える
上層部も含めて既存の制度では当てはまらない事はわかっていたので
すが、何となくやってみて考える的な感じで、ズルズルと先送りして
しまった感があり、いざ評価する時期になると、最初に設定してある
通りに評価してまいました。
評価というものは先に評価方法を明確にしておかなければならず、先
送りにできないものである事をもっと理解するべきでした。
（メンバーの士気に影響します）
とはいえ、この辺はまだ模索中です。
結果評価以外に、変動しない基礎評価要素が必要だと思います。

31. まとめ
わからないものにKPIは設定しない（できない）
そもそもそんなものKPIって呼べません。

32. PDCAを回して嵌まったこと
手探りで始めた企業内スタートアップで嵌まったことEX

33. 店舗情報の収集に失敗した

34. あらまし
前述の話から、店舗情報の拡充を図り、指標の改善に取り組むこと
にしました。
あまり方法が思いつかない中で、試してみたのがクラウドワーキン
グでした。
低価格で多くの情報を集めるべく、我々もどんな感じなのかわから
ないので、まずはやってみるという事で実施しました。

35. 募集はかなり集まりました。
合計4500件の応募に対し、約9割の応募がありました。
ですが、その内容に大きな問題があったことに後で気づきました。
アプリに必須な情報として料理写真を挙げていたのですが、当然な
がら他サイトに掲載しているものなどはNGであり、その旨募集要項
には記載しておりました。

36. 最初は問題ない感じで進んでおり、私もこんなに集まるのかと非常
に驚いていたのですが、チェック作業の課程である写真が某サイト
にあるものと同じであることが分かりました。
で、調べた訳です。
4000件。
1人で週末全て使ってGoogle画像検索で1件づつ。

37. 結果

38. 7割が飲食ポータルサイトや
Blogなどからの
不正流用であることが判明

39. 立ててた計測計画が全部パーです。
初っ端から大きくつまずきました。
人間不信に陥りました

40. どうしたか
どうもこうもないです。使えるわけないです。
事後処理に追われつつも、次の施策を検討しなくてはなりません。
（事後処理、数ヶ月続いてます・・・）
我々には時間が無いのです。
実は・・・

41. 12月までにKPIに対し一定の数字を示せない場合は
プロジェクト解散なんですΣΣ(ﾟдﾟlll)！

42. このままだと社内ニート（メンバー談）になってしまいます。
なので、まずは検証方針はそのままに、店舗情報の収集は自分たち
で出来る範囲からやることにしました。
つまり、会社のある高円寺のお店を自分たちで集めて、高円寺で
改善施策を検証する所から始めました。
（利用状況から当初は新宿、渋谷で検証する予定だったのですが）

43. 高円寺の利用者はほとんど弊社社員だと思いますが、ユーザーには
変わりません。
意図した検証ができるだけのデータが集まれば、キュレーションロ
ジックの改善も見込めますし、検証規模が小さくてもKPIに効いてく
る要素や手がかりを見つけられるのではないかと考えました。

44. 「できる範囲」というのは結構重要で、これができたらこうなる、
こう改善されるというイメージが明確になるので、ワクワク感や
モチベーションが高まります。
スプリントでのメンバーの感触がイマイチだと思ったら、この辺を
改善してみると良いかもしれません。

45. まとめ
人を信じてはいけません。
検証が出来る要素（データ/ユーザー）をきちんと考える。
足りていさえすれば小さくとも検証はできる（はず）。

46. 今思ってること・悩んでること
さいごに

47. いつかお話できれば（またはお話を聞かせてください）
・鶏と卵
マルチサイドプラットフォームはどちらから手をつけるか。
どう成立させるべきか、本当に悩ましい。
・UXデザインをどう組み入れていくべきか
UXデザインの考えはリーンスタートアップと近いです。
どう組み入れて、そしてどうビジネスという視点を成立させて行くか、
いかにスピード性を担保するか、今後進める新しい企画でトライします。
・データアナリティクス
Tableau使ったりしてますが、まだまだ全然出来てません。
計測って本当に重要で、最初から考えてサービス作らないと絶対駄目です。
今後精進したい領域です。

48. ご静聴ありがとうございました