「手探りで始めた 　　企業内スタートアップで嵌まったこと」

in DevLOVE 2014/5/16 株式会社ヴァル研究所

Business Development Dept. 部長 篠原　徳隆

自己紹介 Business Development Department

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

主なプロダクト 通勤費管理システム 通勤費申請Web 駅すぱあとWebサービス まるごと路線図（iPhone/iPad） 駅すぱあと for iPhone

部署紹介 Business Development Department

組織目標

シーズを探求し、トレンドを把握しながら

既存事業と相乗効果のある事業計画を

創出・育成することで

新たな事業基盤・顧客基盤を生み出す

リーンスタートアップ ×

アジャイル × UXD

キーワード

組織構成

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

※エンジニア以外の2名も元々エンジニアです。

目標

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

予算

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

環境

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

今期の取り組み

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

COSFUL

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

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

何か新たな事業基盤・顧客基盤を生み出すというミッションを遂行するにあたって参考にしたのはリーンスタートアップの手法でした。

「RUNNING LEAN」や「スタートアップ・マニュアル」など、いくつかの書籍を読みながら手探りで始めて進めてきましたが、MVPリリースまで漕ぎ着けた今、その課程を振り返ってみて何に気づいたかお話したいと思います。

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

インタビューが空振った

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

何故そうなったのか マルチサイドの場合、両サイドのベネフィットを噛み合わせないといけません。

最初は店舗側からインタビューを始めたせいもあり、リピーターを増やすにはどうれば良いかとか、質の高い顧客を獲得するにはどうすれば良いかとか、お店側の視点から考え始めたので、一般ユーザーへのインタビューの際、一般ユーザーの課題を知るというよりは、お店側の課題を解決する仮説をぶつける感じになってしまい、一般ユーザーのインサイトに対する理解が甘くなっていました。

最初はお店のShop Cardを利用したゲーミフィケーションサービスを考えていたのですが、いざワイヤー作って見せても当たり障りのない反応しか返ってきませんでした。

※マルチサイドプラットフォーム：複数の顧客グループをつなぎ合わせるもの。

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

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

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

10店舗への提案中、8店舗からの賛同を頂きました。 課題については10店舗への提案中、全ての店舗からの賛同を頂きました。

ちなみに 実際にお金を払っても良いというユーザーを獲得しろということで、その辺もトライしてみました。

※公開にあたって名刺はぼかしています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結果 Chronoは「キュレーション」が刺さったのか、LINEニュースなどに取り上げて貰えました。

最初に目に付かせる施策が効果があったのか、 ユーザーもある程度狙い通り獲得することができました。 （リリース初日はフード/ドリンクカテゴリで7位！）

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

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

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

チームが加速しない

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

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

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

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

まとめ さいごに

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

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

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