DevLOVEで発表した資料になります。

1. 「手探りで始めた
企業内スタートアップで嵌まったこと」
in DevLOVE 2014/5/16
株式会社ヴァル研究所
Business Development Dept. 部長
篠原 徳隆

2. 自己紹介
Business Development Department

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

4. 部署紹介
Business Development Department

5. 組織目標
シーズを探求し、トレンドを把握しながら
既存事業と相乗効果のある事業計画を
創出・育成することで
新たな事業基盤・顧客基盤を生み出す

6. リーンスタートアップ
アジャイル
UXD
キーワード

7. 組織構成
部長 1名
（兼プロダクトオーナー 兼スクラムマスター 兼マーケター 兼システム設計
・・・コード以外なんでも）
エンジニア 2名
（AWS、Ruby on Rails、HTML5、GitHub、Jenkins、デザイン）
企画&マーケター 1名
（SMM、SEO、LP、Google Analitics、Google Adwords・・・コード以外なんでも）
※エンジニア以外の2名も元々エンジニアです。

8. 目標
MVPのリリースと製品・市場フィットを目的としてます。
手掛けるプロダクトには3千万円稼げる事業ポテンシャル
があることが条件となっています。
また、事業領域は駅すぱあとと相乗効果のある領域である
事が要求されています。
今期は5つのMVPを出すことが設定されています。

9. 予算
１つのプロダクトに対し予算は300万円。（人件費除く）
予算内であれば稟議は不要。

10. 環境
メンバー4人で集まって仕事してます。

11. 今期の取り組み

12. 2分でお店を決めて、5分でお店に到着
お店選びに迷ったら。
アプリを起動するだけで面倒な検索をすることなく
現在地から400m以内のあなたにあったお店を大きな
料理写真でオススメします

13. COSFUL
ながーく付き合える「コスとも」見つかります
COSFULはレイヤーさんがコスプレした過去・現在・未来のデータ
を元に「コスとも」候補を紹介するレイヤーさんのためのマッチン
グサービスです。

14. 企業でリーンスタートアップ
大事なことは全部本に書いてあった

15. 何か新たな事業基盤・顧客基盤を生み出すというミッションを遂行す
るにあたって参考にしたのはリーンスタートアップの手法でした。
「RUNNING LEAN」や「スタートアップ・マニュアル」など、いく
つかの書籍を読みながら手探りで始めて進めてきましたが、MVPリ
リースまで漕ぎ着けた今、その課程を振り返ってみて何に気づいたか
お話したいと思います。

16. ①インタビューで嵌まったこと
手探りで始めた企業内スタートアップで嵌まったこと

17. インタビューが空振った

18. あらまし
想定したターゲットを選んだはずにも関わらず、実際話しを聞き始めると全
くインタビューにならない（噛み合わない）ケースが多々ありました。
更に悩ませたのは課題を重要度と苦痛度で評価して貰ったが、苦痛度が全然
高くありませんでした。（重要度は相対的に並べ替えられるので優先度も何
となく決まりますが、苦痛度は違う）
なので、インタビュー結果を踏まえてUVPをアップデートしても、手応えが
全然ありませんでした。
Chronoリリースまでの作業の大半はこの部分の繰り返しに費やしました。
飲食店側へのインタビューでは最初の2回で即内容をバッサリ修正しました。

19. 何故そうなったのか
マルチサイドの場合、両サイドのベネフィットを噛み合わせないといけません。
最初は店舗側からインタビューを始めたせいもあり、
リピーターを増やすにはどうれば良いかとか、質の高
い顧客を獲得するにはどうすれば良いかとか、お店側
の視点から考え始めたので、一般ユーザーへのインタ
ビューの際、一般ユーザーの課題を知るというよりは、
お店側の課題を解決する仮説をぶつける感じになって
しまい、一般ユーザーのインサイトに対する理解が甘
くなっていました。
最初はお店のShop Cardを利用したゲーミフィケー
ションサービスを考えていたのですが、いざワイヤー
作って見せても当たり障りのない反応しか返ってきま
せんでした。
※マルチサイドプラットフォーム：複数の顧客グループをつなぎ合わせるもの。

20. 最大の課題
お店側の経営や1日の業務スケジュールなど、コンテキストを知れば知るほ
ど、お店側の状況に対する理解が足りなかったと痛感しました。
リピーターが欲しいとか、上客が欲しいとか、集客したいとか、ごく当たり
前の要望がある中で、お店側がどの程度お金や時間といったコストを掛けら
れるのか。聞いてみるとかなり厳しい現実でした。
どのお店も個人事業主であるが故に、考え方も十人十色。
ITリテラシーやコストに対する考え方もバラバラでした。
これはインタビュー中に言われてしまった事ですが、気をつけていたにも関
わらず、提案内容がどこかで自分達の都合になっている部分がありました。
（収益の部分があるので尚更）

21. どうしたか
お店にしろ、一般ユーザーにしろ、インタビューの時間を貰うのはかなり大
変だったので、インタビューが空振っても、目的を切り替えてインタビュー
相手のコンテキスト（日常）を聞きだす方向に切り替えました。
解決すべき本当の課題とそこに刺さる解決策のヒントを得るために、その中
でも特に苦痛な事を聞き出したり、苦痛を自覚して貰ったり、想像してもら
える様なインタビューを心掛けました。
その上で反応を持ち帰って検討しながら、マルチサイドが成立するようなお
互いのベネフィットを探り、UVPをアップデートしながらインタビューを繰
り返しました。

22. 振り返って
「絶対に必要な課題」を見つける事。
本には最初にそう書いてあるんですが、実際に経験してみて改めて理解する
事ができました。
その為には最初のインタビューで、対象のコンテキストを知る事が大事だと
思いました。そうすることで「苦痛な」課題に近づけるのではないかと思い
ます。
マルチサイドの場合は課題の解決策をそれぞれのサイドで切り分けるのでは
なく、共通の解決策で解決することでベネフィットもカチッとはめられるの
ではないかと思ってます。

23. 10店舗への提案中、8店舗からの賛同を頂きました。
課題については10店舗への提案中、全ての店舗からの賛同を頂きました。
ちなみに
実際にお金を払っても良いというユーザーを獲得しろということで、その辺
もトライしてみました。
※公開にあたって名刺はぼかしています。

24. まとめ
苦痛な課題を見つけましょう。
当たり前ですいません。でもやっぱりコレなんだと・・・

25. ②ＭＶＰで嵌まったこと
手探りで始めた企業内スタートアップで嵌まったこと

26. MVPという言葉に振り回された

27. あらまし
「検証可能な仮説」をMVPで検証・学習する。
だからMVPを早く作って検証しろ。
とはいうものの、MVPってどのレベルのものをMVPと言えば良いのか。
そもそもアプリの場合、MVPといえどもそれなりのクオリティは要求され
てしまうのでは？。レッドオーシャンとブルーオーシャンでは要求されるク
オリティも違うのでは？
アイデアの有効性や実現方法の検証にも時間を取られる。
検証している間に自分達のアイデアに似たアプリが続々リリースされる。
とにかく早くMVPを作らなければならないのか？
でも自分の中ではまだ何かはまらない感じ。こうじゃないという感覚。
MVPをどうすべきか、どうあるべきなのか迷いました。

28. どうしたか
とりあえず、分からないなら色々試して自分なりの考えを得たいと思い、
Chrono以外のプロダクト（COSFUL）も使って実験してみました。
Chronoはアプリを作る前にワイヤーフレームを作成し、その素材をモック
アプリで動かして繰り返しインタビューを行いました。諸々固まるまでは
MVP（アプリ）は作りませんでした。
一方、COSFULはWebサービスということもあり、課題検証もそこそこに
必要だと思った１つの機能をさっさと作って世に出して検証する事にしまし
た。

29. 結果
・・・どっちもどっちでした。
Chronoはもっとアプリ作成までのスピードを上げられたかもしれませんが、
結果的にしっかりとLean Canvasの各要素が固められたおかげか、最初か
らそれなりのユーザーを獲得できました。
逆にCOSFULはニッチ過ぎた価値と、セグメントへの響かなさをすぐに学ぶ
ことができて、次の仮説（プラン）への着手が早かったです。

30. 振り返って
結局どちらも仮説を検証している事には変わらないです。
思うのはMVPにソリューションインタビューの要素を含み過ぎたかなと。
だからMVPに色々なものを詰め込みすぎて迷っていたのかと。
先の二つで実験を通して、自分の中では
インタビューで繰り返し検証するもの：プロトタイプ（モック、α版）
公にリリースしてユーザーに利用して貰うもの：MVP
という整理ができました。
前段のソリューションインタビューの意味をもっと把握していれば、こんな
風に迷わなかったのかもしれません。

31. 大事なこと
自分の中ではまらない、こうじゃないという迷いは、このプロダクトで何が
変わるのだろうか、自分が描くプロダクトの未来は本当にくるのだろうか等、
考えていたことが自分の中で確信できる前に開発に着手することへの違和感
だったのだと思います。
作ることが目的じゃなく、誰の為に、何を、どうやって解決するのか、どう
当たり前を変えて行きたいのかを考え、探し、検証する。
その辺をクリアにするのがインタビューで、仮説検証を通して世の中のニー
ズと自分のやりたい事を重ねていくこのフェーズに色々なものが詰まってる
なと感じました。

32. まとめ
MVPは世の中のニーズと自分がやりたいことを
擦り合わせる段階で出すものではないです。

33. ③ユーザー獲得で嵌まったこと
手探りで始めた企業内スタートアップで嵌まったこと

34. ユーザーにリーチできない

35. あらまし
Lean Canvasで言うところのチャネルの部分。
「スタートアップが失敗する主な理由は顧客への経路が作れないことです」
本にもこう書いてあって「初日から考える」とあるのに、初期は他の項目よ
り思考の優先度が低かったです。これが実は後で一番悩むことに。
我々が想定したユーザーは確かに存在しました。
ですが、その人達は情報に受け身であるが故に、AppStoreも見ないし、
Yahooニュースをちょっと見るくらい。アプリは友人に教えて貰ったものを
入れるくらいなので、あらゆる販促施策が届かない所に存在していました。
そもそも友人が教えたくなる要素が含まれているのか。
チャネルのところでLean Canvasの各要素に疑問が出てきてしまいました。

36. 何故そうなったのか
①アーリーアダプターの想定が間違っていた。
我々が当初想定していたユーザーはレイトマジョリティーだった。
ニーズを持つユーザーがいたとして、そのユーザーがどのステージに属して
いるのかを考える必要があった。
②課題への解決策が平凡
解決策が平凡だと、全体的にやっぱり平凡になる。結果話題にならない。
サービスが広がるイメージ、話題になるイメージを盛り込めていなかった。
誰が解決策に興味を持つのか？誰が広めてくれるのか？
要求されているのは解決することだけではなく、新しい体験も要求されてい
る。

37. アーリーアダプターの再設定
課題はそのままに、アーリーアダプターにスマホに慣れた、日常的にグノ
シーなど何かしらのニュースサービスを利用しているなどの設定を追加。
どこかしらのメディア媒体が取り上げてくれれば目に付く可能性が出てくる
ので、ニュースリリースを出してそれを狙う事にしました。
飲食系はレッドオーシャンである事からDL施策はお金も掛かるので、リ
リース直後の目新しい時期にユーザーを獲得してしまう方法を選択しました。
それはリリース初期にある程度のユーザーを獲得できたならば、後は体験を
最大化できれば、口コミが発生して拡大できると考えたからです。

38. 教えたくなる要素
ネット上で取り上げて貰うには「話題性」が必要で、UVPには何かしら「話
題性」を組み込んでいないとなかなか厳しいです。
UVP = 解決策 （画期的 or 面白さ）＝ 興味を惹かれる体験
当初の案では友人・知人が薦めるお店だけを紹介するはずでしたが、我々が
データを元にお店を紹介するキュレーションに機能を切り替えました。
キュレーションによる「お店を推薦する」「お店を探さなくても済む」とい
う体験は充分話題性になると考えたからです。

39. 結果
Chronoは「キュレーション」が刺さったのか、
LINEニュースなどに取り上げて貰えました。
最初に目に付かせる施策が効果があったのか、
ユーザーもある程度狙い通り獲得することができました。
（リリース初日はフード/ドリンクカテゴリで7位！）

40. 振り返って
広がるイメージができないサービスは多分、どんなに課題と解決策がフィッ
トしていても駄目なんだと思います。
チャネルの観点から課題やUVP、ソリューション、顧客セグメントに問いか
け、検証することで、各要素も洗練されてくるんだなと実感しました。
本当に初日から考えるべきでした。
SNS全盛のこのご時世、最後は口コミ（バイラル）にどう持って行くかが全
てになると思いますが、そういう要素は最初から入れろって事ですね。
後で読んだグロースハッカーにもそんな事書いてあって頷いてしまいました。

41. まとめ
広がるイメージを最初から考え、組み入れましょう。

42. ④部署運営で嵌まったこと
手探りで始めた企業内スタートアップで嵌まったこと

43. チームが加速しない

44. あらまし
メンバーは会社の人事として配属された訳です。
当然、リーンスタートアップやChronoに対する思いなんかもゼロからです。
また、複数のプロダクトが課されている為、マルチタスクになってしまい、
作業ウェイトも分散してしまいます。
しかもこちらは手探りで進めてるので、指示もトライエラーの繰り返し。
リーンスタートアップのやり方を理解して貰えていないと、この辺の共有も
難しいです。
一方で組織なので評価をしなくてはならず、作るかどうかも分からないもの
を、会社が適切な評価方法を持たないため、適切かどうかもわからない指標
で評価してしまったために、軒並み低い評価になる始末。モチベーションを
削いでしまいかねない状況になってしました。

45. どうしたか
ビジョンと言うと大げさかもしれませんが、プロダクトの将来を語って、ま
ずは共感して貰うことから始めました。
その上でメンバーの役割を明確にしました。
どうしても自分が主体的に動かす事にはなってしまいますが、役割は適材適
所だと思うので、それぞれの役割を全うして貰える様な配置を考えました。
あとはスプリント0的な事やって、3ヶ月以内でやろうとしていること、狙っ
ていること、必要なことを、実現方法を共有してバックログを一緒に作って、
直近のイメージを共有しました。

46. 振り返って
新規事業の部署運営はトライエラーの繰り返し。
明確な基準（評価）と方針（目標）、権限の委譲（役割）によるモチベー
ションコントロールが鍵かなと。あと情報の共有。
集中できるシチュエーションを作れるとそこからは早かったです。
あとは小さくても良いので成功体験の共有をしたいです。
またこういう新規事業関連だと、エンジニアが伸びます。
部署の都合でエンジニアへの要求が高くなってしまうのですが、結果的にこ
れが良かったのか、えらい伸びました。
今後は自走できる様なマインドをどう高めて行くかが課題です。

47. まとめ
評価と目標と役割を明確にし、情報共有をしっかり行う

48. まとめ
さいごに

49. リーンキャンバスってよくできてる

50. リーンキャンバスに隙はありませんでした。
なぁなぁで済ませて良い部分なんて、何一つありませんでした。
本当凄いなと思いました。
それでも失敗の方が多いのだから、新規事業って本当に難しいと思います。
ヴァル研究所は今、なんでもやらせて貰える、チャレンジさせて貰える環境
なので、このチャンスを生かしてどんどんチャレンジして、どんどんアウト
プットして社内に新規事業の目を増やして行ければ良いなと考えております。
もちろん、チャレンジしたプロダクトが成功する事が第一です。
今度は成功事例をひっさげて、再びDevLOVEでお話しさせて貰える機会が
得られる様に頑張ります。

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