読者です 読者をやめる 読者になる 読者になる

ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

1/28(月)、「LeanStartupNight - Startup Begins -」に参加してきました。 #devlove

はじめに

 1ヶ月以上も前の話で恐縮ですが、1/28は東京:初台は株式会社エムティアイさんで開催された「LeanStartupNight - Startup Begins - - DevLOVE | Doorkeeper」に参加してきました。最近は転職したばかりということもあって仕事の関繁度合がつかめず、勉強会の参加自体を抑えめにしていたんですが、ちょうど定時帰りできそうだったのと開催場所が職場から近かったこと、なにより「Lean Startup」というキーワードにひかれて当日飛び込み参加した次第です。


 本エントリは、ブログの下書きにメモだけ貼ったまま長らく放置してたんですが、死蔵しておくのもどうかと思うので、恥をしのんで公開しておきます。

オープニング


 オープニングは、DevLOVE船長:@papandaさんから、いつものDevLOVEというコミュニティ自体の説明と、この日のメインである堤孝志氏のご紹介。DevLOVEは常連が多いのでコミュニティ紹介は割とサラッと流すことが多いんですが、この日は割合丁寧に話していた印象です。

    • DevLOVEの根底にあるもの
      • HangerFlight
        • かつて空が危険だった頃、飛行機乗り達が格納庫でそれぞれの知識・経験を語り合った
        • →これをソフトウェア開発でもやろう
      • ダイヤログ(対話)
        • 他人の視点を知るための手段・場所
  • 本日のアジェンダ
    • 堤孝志氏


顧客開発モデルとその実践について


 本日のメインである堤孝志氏にバトンタッチ。「スタートアップマニュアル」という書籍の訳者で、自身もスタートアップの企業を助けるベンチャーキャピタリストとして深くスタートアップに関わっていらっしゃいます。堤さんのご登壇のきっかけは、はたしてDevLOVEお得意の「謎の人脈」発動か、はたまたこの日の日中に開催された「リーンカンファレンス2013」つながりで引っ張ってきたか…?

  • 自己紹介
    • 堤孝志氏
      • ベンチャーキャピタリスト
      • 元々は総合商社
        • IT関連のビジネスに携わる:2年間
      • 大学の専攻は電気工学
        • Fortran C 開発を色々やってた
      • それからビジネスの道へ
  • スタートアップとの関わり
  • 90年代
    • インターネットのインフラが猛烈に開発されている時代
      • CISCOがまだベンチャーの頃
      • 日本でビジネスを1から立ち上げるようなことをやってた
  • 若き日の失敗(1990前半)
    • スイッチングハブ 500ー1000万してた
      • 大当たりした
        • 20億円くらいの利益に
        • ビギナーズラック
      • →驕り
    • ATM25Mbps
      • すごい技術
        • 性能:倍
        • 機能:不可能を可能に
        • 業界紙でも大きく取り上げられる
      • →いざ蓋を開けてみると全然売れない
    • →お客が買ったり使ってくれなければ始まらない
        • 自分の気に入ったものに惚れ込むと周りが見えなくなる
        • 顧客の声を聞きながらニーズを取り込むことが大事
  • →こういったことは私(堤氏)だけじゃない

  • イノベーティブなことをやってる企業はリスクを取ってる
    • MS ソーシャル携帯「KIN」
    • 2000円札(みんなが欲しがるお金でさえ!)

  • 顧客の声を聞け!
    • でも何を聞けばいいのか?
    • どのようなプロセスで進めればいいのか?
    • 進捗をどう計ればいいのか?
  • →顧客開発モデル
    • 誰も欲しがらないものに人モノカネを投じて行き詰るという新規事業の典型的失敗を避けるために「顧客の声を聞きながら新規事業をゼロから立ち上げるためのプロセス

  • 顧客開発モデル
    1. 最初に販売する
      • →失敗しても失うのはコンセプトのコストだけ
    2. ニーズがあると判明してから開発を始める
    3. 小さく小さく開発
    • 最初に自分が持った仮説を検証しながら進める
    • 確認できるまでは開発費用や販売費用を抑制する

→厚くて読めない、難しい
→実は書いてあるのは上記のことだけ

  • 顧客開発の哲学
    • 新規事業は上手くいくかどうか実際はわからない
    • 失敗はつきもの
    • どうせ失敗するなら早く小さく失敗し、修正かける方がむしろ重要
  • →例)ロッククライミング
    • いきなり上まで登ってはだめ
    • ちょっと登ってはすぐ落っこちて行けるかどうか確かめる
    • 間違った事業計画のまま、いつまでも続けてはいけない
  • →4つのステップで、顧客を相手に仮説検証を繰り返し、再現可能でスケーラブルなビジネスモデルを構築する

  • 効率的に「早く安く失敗して軌道修正をかける」ためのコツ
    1. 仮説を明確にして検証を行う
    • 仮説=思いつき
      • 紙に書いて、残す
        • ビジネスモデル・キャンバスにより仮説を構築
        • 一枚にまとめてチームで共有する
          • 例:オンライングループギフティング(出産祝い)サービスでのキャンバス

      • →書いただけで上手く行く気になっちゃうことも
        • あくまでまだ仮設段階
        • オフィスの中には顧客のニーズの情報は転がってない
        • →外でいろんな人に聞いてみる(インタビュー)
          • 仮説の検証
            • 親しい人には1 vs 1
            • N vs 1で贈答をする場合
          • →例つづき)企業(部署)でとりまとめを行って出産祝いを贈る
          • →例つづき)幹事の選定も行えるように
      • 検証結果を元にビジネスモデル仮説を修正(Pivot)する
        • 仮説を明確化し、目的を持って検証する
        • 検証する上で最適な実験方法を検討する
    1. 検証にかけるコストを抑える
      • 小さく開発
      • ←徹底してやってく
      • ←MVP
        • もっと見た目を綺麗にしなきゃ
        • もっと機能を充実させなきゃ
        • →顧客が価値を見出さなきゃいくら作っても意味ない
        • 顧客が価値を見出すであろうコアの部分だけに特化して作る
  • 「ワークをやりたいのでMVPの説明は飛ばします」
  • Pivot
    • 仮説が間違ったら軌道修正する
      • Pivotを頻繁にしたがる
      • 「今日はピボットしてから寝よう
      • ←そんなにホイホイするもんじゃない!
      • 辛い思いをしながらしなけりゃならんのがピボット
  • 実践例:
    • オンライン名刺管理サービス
    • 外出からクラウドベースで観れる
    • フリックでペラペラ名刺が回る
    • →名刺をみるときは遅刻しそうなとき
    • 余計な装飾より早く検索したい
  • ワークショップ
    • 製品と市場のフィット
      • ←ここが上手く行かないケースが多い
    • Value Proposition Canvas

      • 右と左で同じ製品に対して別々のグループで
    • やってみないと食い違いが起こることが多い
      • 思い違い
      • 思い込み
      • →ずれてる





 後半に実際にValue Proposition Canvasというビジネスモデルキャンバスの派生ツールを使って、各製品ごとに「顧客チーム」と「開発企業チーム」に分かれ(つまり4製品なので8チーム)、顧客側が製品に対して思っていることと企業がユーザーニーズの仮説を立てることが合致するかどうか、というワークショップを行いました。
 あまり時間が無かったことと、VPキャンバス自体に関する理解度が低い状態だったので、ワークを進めるのに非常に苦労しました。この後日、実際に何人かでVPキャンバスの素振りをやってみたんですが、やっぱりこのままでは使うことが難しく、もうちょっとキャンバスの中を細分化したりと試行錯誤が必要でした。何度か使ってみないと、本番での使用は難しそうですね。

 オレは「ヌーボード」という、持ち運びできるノート型ホワイトボードの開発企業チームだったんですが、そもそも製品自体初めて見たので、製品理解に多く時間を省いた分、開発企業チームと顧客チームでそれほど意識の齟齬が出ませんでした。「仮説はずれるという事象を体感する」という目的だと、ワークは失敗なんでしょうかね?
 ただ、製品を見てしまうと「答えから問題を推測する」的な思考になってしまうので、「それでも顧客と企業で多少は意識がずれる」という意味では面白い結果が得られたと思います。


休憩時間

近くにいた@papandaさんと@_N_A_さんと雑談。日中に開催された「リーンカンファレンス2013」で@papandaさんも登壇されたらしく、その準備が大変だったのかいつも以上にグッタリしてました。@papandaさんもライフワークバランスをなんとかせにゃあいけませんな。…いや、彼の場合は「ライフワークコミュニティバランス」か。


休憩時間終了間際の@papandaさんと堤さんの話を聞いていると、直前のワークショップで使ったVPキャンバスは堤さん自身も2〜3日前に知ったとのこと。ビジネスモデルキャンバスの登場以降、新しい派生キャンバスがどんどん出てきますね。


ダイアログ


 DevLOVEでは恒例のダイアログ。先ほどのワークショップのチームでそのまま互いの課題を話し合うことになりました。


 我々のチームはオレも含めて3人。

 お一人は筑波大発のベンチャー企業に就職されたばかりで、これからIT営業を専門にされていくという若い男性。自身も過去にスタートアップに関わった経験をお持ちですが、今回の勉強会には、IT業界そのものへの見識を広めることと、知り合いを増やすことを目的として参加されたようです。

 もう一方は、DevLOVEに限らず社外勉強会のコミュニティでは常連の方。Facebookグループでは良くお見かけしてたんですが、リアルでお会いするのはこれが初めてでした。オブジェクト指向やピクト図解に元々興味を持ち、その流れからBMG、そしてリーンスタートアップに興味を持たれて今回参加されたとのこと。


 とはいえ、我々のチームではリーススタートアップについて差し迫った問題を抱えている人はおらず、わりかしのらりくらりと話を進める形に。ところがお一方が大学ベンチャー経験者であることが発覚してからは、彼の経験を根掘り葉掘り聞く形に転向。ピボットも経験されたようで、新規ビジネスがなかなか上手くいかないという話を伺うことができました。


 この時、ピクト図解つながりで下記の書籍をご紹介頂きました。Kindle版もあるみたいですが、紙の書籍と比べてあんまり安くなっていませんね。



発表

 ダイアログで話し合われた内容をいくつか発表。発表というよりは、堤さんに対するQ&Aみたいな形になってました。意外と既に実践に入っている人が多いんだなぁ、という印象でした。

  • 実際に顧客駆動開発モデルを使う時に、どのタイミングでどのようにヒアリングをかけるべきか
    • →方程式があるわけじゃない
      • スタートするタイミング=コンセプトができたとき(コンセプトだけ)
      • 見せるものがない←「こういうものがあったら買いますか?」まともな答えは返ってこない、ネガティブなことを言う人は少ない
    • →ニーズの背景にあるものを聞く
      • →解決しようとしている課題があるかどうか
      • →ドリルが欲しいんじゃない、穴が欲しいんだ
      • →「穴、ありますか?」
    • 製品の話をしなくてもコンセプトが確認できる
  • ステップ0
    • →経営陣にコンセンサスを取る
  • コンセプトから開発に入るタイミング
    • →画面を手書きで書くくらいだったらコンセプトと同様にしかコストがかからない
    • →安く作れてリスクがないんだったら作っちゃっても良い
    • クラウドやツールを活用して安く早く作れるのであれば、どんどん作った方が聞きたいことが聞ける可能性が高くなる
  • 社内の人間のコンセンサスを取るのが難しい
    • チーム全体の前のめり感をどう出していくか
      • →どうして反対意見が出るの?
        • →慣れてない人が多くて、スクラップ&ビルドで心が折れてしまう、もしくは怖くてトライできない
      • →そもそも顧客開発モデルの「最初考えてたことが違ってた、のは別に問題ない」という意識が全員にないとそもそも難しい
      • →私(堤孝志氏)がもう一回説明するとか
      • →まずは顧客開発を行うということをチーム全員で理解する

クロージング


 @papandaさんからクロージング。実は堤さんは、このイベントにも参加していたイトウさんの紹介で登壇頂けたそうです。DevLOVEの謎の人脈の一部が、期せずしてここで明かされることとなったわけですな。


 最後に、会場提供頂いたエムティアイさんからご挨拶頂いて、イベントは終了となりました。


総評

 だいぶ昔に参加したまま放置してたんで、総括は軽めに。(すんません、だいぶ忘れました。)

 個人的には、書籍「スタートアップマニュアル」の印象よりは「VPキャンバス」の方が印象が強くなっちゃいました。使い方が分からない道具が出てくると、どうしてもそちらに意識を取られてしまいますね。

 前述の通り、この後一回4人くらいで集まって、VPキャンバスの素振りをやってみたことがありました。VPキャンバスは、リーンキャンバスでも更に「価値提供」と「顧客」にフォーカスして需給を確認する為のキャンバスですが、ここまで絞り込んでいても、このまま書くにはあまりに項目が粗すぎて書くことができませんでした。もっと小項目を付けてそれぞれ細分化してで無いと書けないんですよね。
 ニーズの確認を素早く行える、という目的は、確かにVPキャンバスを使えば実現できそうではありますが、それなりに熟練度を上げる必要はありそうです。
 ちなみに、この時の成果は内緒ってことで。出来上がったビジネスアイディアが、結構上手く行きそうだったので、パクられちゃ困るしw。(あと割と下品な内容でしたw)