"Lean Startup Japan"

新規事業を成功させる4つのステップ

ケーススタディ9 リーンスタートアップ流の取締役会とは?

今週の月曜日5/23に、今年で2回目の開催となる”Startup Lessons Learned Conference“が開催されました。Lean Startupのイベントとしては、Meetup以外で唯一公式に開催されるものです。

以前の記事でご紹介したケーススタディも昨年の開催から起こしたものが多く、今年も充実した内容でした。

初めての開催だった昨年は、リーンスタートアップの必要性についての講演が多かったのですが、今年の内容はいかに実践するか?といった事例や実績が数多く紹介され、リーンスタートアップの浸透を実感させます。

もちろんこちらで順次紹介していきますのでご期待ください。

第一弾はもちろん基調講演となるスティーブ・ブランクの講演です。

昨年は伝説的な”Why Accountants Don’t Run Startups“で会場を大いに沸かせましたが、今年の内容も実に充実でした。

今年のトピックは4つ

  1. 昨年学んだ10つのこと
  2. 経験知に基づくアドバイスに潜む問題点
  3. アーリーステージと経験知のギャップ
  4. スタートアップの取締役会の問題点

メイントピックは「スタートアップの取締役会の問題点」についてです。

本トピックでは、スタートアップが外部取締役も交えた定例的なミーティングをどのように行うべきなのか?という課題に対して、リーンスタートアップの概念にピッタリフィットする事例を披露してくれています。

顧客発見、顧客実証を行っている間、ウォーターフォール的なスケジュール管理には価値がありません。ローンチしてもニーズがあるか未検証のプロダクト制作の進捗を確認しても、スタートアップが成功に近付いているかどうかの確認にはならないからです。

同様に、メインストリーム市場にチャレンジ前のスタートアップにとって、収支報告も意味がありません。創業者の親族、友人が購入してくれた売り上げ報告などを聞いても、やはりスタートアップが成功に近付いているのかまったく確認することが出来ないからです。

顧客発見、顧客実証の段階にあるスタートアップにおいて、取締役会が定期的に確認してアドバイスをすべきは以下の4点です。

  1. どのような仮説を立てたか(重要度と共に)
  2. それをどのように検証したか(するべきか)
  3. そこから何を測定し、学習したか
  4. 学習に対してどのような方向転換(Pivot)を行ったか?

そのためには、こうした情報は常にネット上で「リアルタイム」に公開、更新されるのべきです。

そこでスティーブ・ブランクは、スタートアップはすべての活動をブログ形式で公開(もちろん限定されたメンバーに)し、リアルタイムに投資家からのアドバイスを得るための手段を提案しています。

これは、スティーブ・ブランクがスタンフォード大学のLaunchPadという講義の中で実際に使用した方法で、具体的なやり方とツールが紹介されています。

※こちらのビデオの25:30ぐらいから実例が紹介されています。

基本は顧客開発モデルです。

  • ブログ上にはスタートアップが記述した仮説が「ビジネスモデル・キャンバス」というシートに記載されています。
  • その仮説をどのように検証していくかのプロセスがスケジュールされます。
  • そして実際に行なった検証は、インタビュー、アンケート、ビデオ、プロトタイプを問わず、ネットに公開されます。
  • こうした活動に対して、アドバイザリーメンバーはリアルタイムにウォールに書き込みを行うことでアドバイスを送ることができます。

そして、このような取締役会のためのツールも同時に紹介されました。

Lean LaunchLab“と呼ばれるこのサービスは現在ベータ版の公開に向けてランディングページだけが用意されている状態ですが、デモを見る限り確かにリアルタイムで有効な情報交換が可能であり、従来の取締役会の開催が本当に不要になりそうです。

このような取締役会の開催による効果は次のようなものです。

■スタートアップ向け

  1. スタートアップが経験知に基づくアドバイスをリアルタイムで得られること
  2. 実際の活動を投資家に見せられること
  3. 日和見的な計画から、戦略主導のスタートアップに変化すること
  4. 取締役会のために割く時間が大幅に削減
  5. 地域を超えた投資が期待できる!

■投資家向け

  1. スタートアップをリアルタイムにモニタリング可能
  2. 軌道修正のためのタイムラグが「ゼロ」!
  3. 管理できるスタートアップの数が大幅に増大
  4. 投資対象先に対する地域の壁を無くす

また講演の最後には、こうした取締役会を行うことができるスタートアップに投資を希望するVCも紹介されました。

まさにこうした取り組みが私たちリーンスタートアップジャパンとしての方針でもあり、スタートアップと投資家がロードマップを共有しながら共に成功を目指していく状態に近づいて行きたいと思っています。

When the Boardroom is Bits

View more presentations from steve blank

ケーススタディ8 Zyngaのゲットーテストとは? 効果的な仮説検証の必要性

すっかり更新をサボりました・・・

大変申し訳ありません。。。

何にもしてなかった訳ではないのですが、言い訳はNGです。

様々落ち着いてきましたので、また再開します!

といいながら結局言い訳になってしまうのかも知れませんが、この空白期間の活動とお知らせを何点か。

まず来月から、ようやくセミナーを開催していくことになりました!

1日完結のプログラムと5日間のプログラムが共に出来上がりましたので、日程や場所が決まりましたら、随時報告していきたいと思います。

さらに、近日中にリーンスタートアップ・ジャパンを法人化し、本格的な活動にしていくこととなりました。

収益モデルなどはこれから手探りで進めていきますが、私たち自身もリーンスタートアップモデルで方向性を探っていきたいと思っています。

さらにさらに、法人化にあたり、とても強力なパートナーが見つかりました。

またこちらでご紹介させていただきますが、スタートアップ界のインフルエンサーですのでご期待ください!

というわけで、ブログ上は更新停止状態でしたが、様々な活動が一気に動き始めたここ1ヶ月半ぐらいでした。

今後とも引き続きよろしくお願いします。


今日は更新停止のお詫びを兼ねて、ケーススタディを1件ご紹介します。

様々な方と話をしていると、やはり仮説の検証をどのように進めていくか?というところは大きな課題のようです。特に直接顧客候補と対面によるフィードバックを受けることが出来ない個人向けサービスの場合、適切なメトリクスが設定できるかどうかが、仮説検証の最大のキーとなります。

Zynga-logo

そこで、今日は少々古い記事ではありますが、ZyngaのCEO, Mark Pincusがスタンフォード大学で講演したマーケット・デマンドの検証方法をご紹介します。

Zyngaでは、星の数ほどあるアイディアの中から、本当にヒットするプランにリソースを集中させるために「ゲットー・テスティング」という手段を使っているそうです。

ゲットー・テスティングとは、ゲームデザイナーのアイディアを実際にユーザ候補に問いかけながら、最小限機能の製品(Minimum Viable Products)を開発していくという手法です。

手順をご紹介しましょう。

  1. 製品や機能のアイディア出し
  2. 5-wordで新製品や新機能の紹介文を作成
  3. それをWeb上のハイトラフィックなサイトに5分ずつ掲載
  4. ユーザがクリックするとサーベイサイトにジャンプ。ローンチ時の通知アドレスなどを登録。
  5. 「ゲットー・バージョン」と呼ばれる製品を開発(最小機能だけを持った製品)
  6. すべてをテストする
  7. 継続的にイテレートする

具体的に説明すると、例えば「病院経営シュミレーションゲーム」というアイディアがあるとします。

そこで、「自分の病院を経営したいと思ったことあるでしょ?」といったティーザー広告をハイトラフィックなサイトに流します。

そのリンクからのクリックに応じて製品の開発作業に着手していきますが、最初に目指していくのは「必要最小機能」だけを備えた製品を作っていきます。

目安としては1週間で開発可能なもの。そしてA/B Testとフローテストを実施し、わずか1%~10%のユーザ向けにリリースします。

リリースしたら測定の開始です。

Zyngaではテスト用のプラットフォームにデータウェアハウスを構築し、いつでも数百のテストが稼動しているそうです。

そして測定結果がある一定のレベルを超えたら、フル機能を備えたバージョンへと移行していくのだそうです。

このやり方は、一般的な「机上でユーザウケする機能を考え、機能を盛り込んだ製品を開発しリリースする」という手法の真逆を行く手順です。

最後の方でMark Pincusが発する言葉が、リーンスタートアップの本質を突いています。

It won’t be ‘build it for three months and hope and pray.’

「これは、『3ヶ月かけて開発し、その後は祈るだけ』っていうやり方じゃないんだ!」

リーンスタートアップの基本的な考え方は、テンコ盛りの機能を資源を大量に消費しながら開発するのではなく、まずは最小限の機能を備えたプロダクトをリリースし、ひたすら測定して検証を繰り返し、ビジネスとして成立する機能へと方向転換していくことです。これによって「フタを開けてみたら誰もユーザがいなかった・・・」という事態を回避するのです。

スタートアップはどうしてもプロダクトの開発に注力しがちですが、この記事を読むと、Zyngaの強さはすべての測定が可能なテスト環境にある気がします。

本記事では残念ながらそのメトリクスがどのようなものなのかは紹介されていませんが、こうした測定をどう並行して進めていくことができるかが、現代のテック・ベンチャーにとっての分水嶺になるのかもしれません。

ちなみに「ゲットー・テスティング」という名前ですが、ゲットーとはもともとヨーロッパのユダヤ人居住区を指していたのですが、いまでは少数民族の居住区を意味しています。つまり、ゲットー・テスティングとは、新製品や新機能をテストするときには、いきなり大人数に対して行うのではなく、ごく限られた少人数に対して実施し、とにかく測定を重視しようという意味が込められているかと思います。

オリジナル記事はこちら

ビデオも4分半と短めなのでぜひ合わせて御覧ください。