当サイトの記事を別媒体に流用する際は必ず問い合わせページからご連絡下さい

【三部構成】書籍「リーン・スタートアップ」を要約してみた 第一部

どうもへっぽこですー
会社の記事シリーズパート8です。

今回は書籍リーン・スタートアップの第一部を読んで100ページ分を意訳してみました。
原書は翻訳特有の回りくどい書き方がされてるので、ウゲエエってなる方は是非^^

ではれっつごおおおお

はじめに

2004年、とある事業に失敗した人が集まって会社を設立した。
会社には並外れたビジョンがあった。
アバターという新技術で新しいコミュニケーション方法を生み出そうというビジョンだ。
また、リーダーの「ハーベイ」は利用者間でアバターを売買できる仕組みを考えた。

私も共同創業者として最高技術責任者としてこの会社(IMVU)に関わっていた。
しかし、そのころ私の経験はまだ浅く、何をどうすべきかわかっておらず失敗ばかりしていた。
じっくり時間をかけて製品を完成させるべきだったのに、とりあえず動くものを製品化してしまった。
バグだらけで安定性に欠けていて、コンピュータをクラッシュさせる、製品とはとても言えない。
しかも最悪なことに有料なのである。

幸いにも、少ないユーザーがいたので、彼らの意見を参考にし、試行錯誤を繰り返した。
言ってしまえばユーザーで実験を繰り返したのだ
しかし覚えておいてほしい、これは本書で紹介するリーン・スタートアップという手法の一つである。

本書は

  • ビジョン
  • 舵取り
  • スピードアップ

の三部構成となっている。

ビジョンではアントレプレナースタートアップについて明らかにし、検証学習について学ぶ。
舵取りでは検証学習をもとに今後の方針をどう判断すべきかを学ぶ
スピードアップでは構築・検証・修正をできる限りはやく回す方法を学ぶ。

ビジョン

スタートアップとアントレプレナーについて

スタートアップとはとてつもなく不確実な状態で新しい製品やサービスを作り出さなければならない人的組織である
つまり、ビジネスモデルや価格、ターゲット層などの既存事業をコピーする形で事業を立ち上げることはスタートアップにあたらない。

スタートアップと聞くとそれを創り出すアントレプレナーを耳にする。
アントレプレナーとは広義的に「ゼロから会社や事業を創り出す人」として捉えられているが、それでは少し説明が足りない。
実はこれもスタートアップの意味と同じで不確実で新しい製品や事業を生み出そうとする者が、アントレプレナーなのである。
つまり、社長や副社長のみならず、部長、課長、平社員の誰もがアントレプレナーになる可能性があるのである

検証学習

では、そのアントレプレナーはどう不確実で新しい製品や事業を成功に導けばいいのか。
それは検証学習を行うことである。
まずは私の失敗体験を聞いてもらいたい。

失敗体験

2004年に私はインスタントメッセージ市場に参入した。
インスタントメッセージはアプリケーション上でリアルタイムでチャットをすることができ、当時は上位3社が80%のシェアを誇っているいわば巨大市場だった。
私は各社のアプリを横断的につなげて別のアプリ同士でアバターでチャットができるアドオンをつくった。
このサービスは爆発的に広がるとリリース前から確信していた。
アプリをいくつも入れなくてもこのアドオンだけで友達とアバター上でチャットができるからだ。
しかし、製品発表してもダウンロードはされることはなかった。
あ、なるほど。製品に欠陥があるからか。当時はそう思った。
ソースコードが欠陥だらけだったからだ。
なので、欠陥を修正し、改良を重ねればユーザーが増えると考えた。
しかし結果は同じ、購入者は増加することはなかった・・。
さすがに不安を覚えた私は一般女性を招き入れ、製品をその場で使用してもらうことにした。


まずはアドオンをダウンロードしてください

ユーザー

それってなんなの?

インスタントメッセンジャーとつなげるものです

ユーザー

なにそれ?知らないわ

とにかくダウンロードしてみてください、とっても便利ですよ

ユーザー

わかったわ

ダウンロードができたら友達をチャットに招待してみてください

ユーザー

絶対にいや!

なぜですか?

ユーザー

これがクールかどうかまだわからないから。それなのに友達を招待しなさいって?そんな危ないこと、できるわけがないじゃない

 

このヒアリングでわかったことは得体のしれないアドオンを友達に使わせたくない。
まずは自分一人でアドオンが問題ないか判断した上で問題なければ友達を誘いたいということだった。
私はチャットナウという機能を導入した。
ボタンを押すとランダムで誰かと繋がれるようにしたのだ。


 

ユーザー

これは面白い

そうでしょう

ユーザー

ちなみにさっきの人とまたお話したいんだけど、メンバーリストにはどうやって登録すればいいの?

いつもお使いのアプリの情報を教え合って互いに登録するだけです

ユーザー

冗談でしょう?なんで知らない人を他のアプリに登録しないといけないの?

でもいつものアプリに登録したほうがアカウント登録をまたイチからしなくていいから便利でしょう?

ユーザー

そんなことないわ!私インスタントメッセンジャーのアプリ8つ使い分けてるから!

・・・

 

私は間違っていた。
新しいソフトウェアの使い方を学ぶのは大変だし、友達を新しいメンバーリストに移すのは大変だと思いこんでいた。
しかし、顧客が求めていたのは独立したインスタントメッセンジャーであった。
さらに予想もしなかったのは、友達をアプリに誘いたいというより、新しい友達をアプリ上で作りたいという人が大勢いたのだ。

結局、私は数千行に渡るソースコードを破棄し、全く別のサービスを作ることになった。
私は反省した。
見込み顧客から話を聞きながらサービスを作り上げていけばこんな遠回りをせずに済んだと

検証学習の大切さ

この失敗体験から学んだことは時間をかけてヒト・モノ・カネを整え、入念なマーケティングをしたとしても全て無駄になるかもしれないということである。
重要なのは顧客の実の声であり、統計データをいくらチェックしてもかけ離れた結果になるかもしれないということだ。
つまり、顧客で検証し、学習した上で方向性を定めていくことが重要なのだ。
では、どうやって検証すればよいのだろうか?

検証はどのように行うか?

検証は仮説→顧客検証→学習→修正の順で行う。
実例をご紹介しよう。
コダックギャラリーは結婚を控えたカップル向けの披露宴の案内状を作る会社だった。
新しい試みとして、イベントで撮影した写真を参加者同士で共有できるイベントアルバムというWebアプリケーションを作ることにした。
まず、仮説を立てることにする。

  • イベント参加者は当日の写真をアルバムにまとめたいと考えている
  • 共有アルバムがあったら、参加者はそこにアップロードするはずだ

次にその仮説を実証するために、実際の顧客で検証する
方法は至ってシンプル、必要最低限しか実装されていないプロトタイプを顧客に提供することだ。

結果は最悪だった。
あって然るべき機能が実装されておらず、アルバムが作成できなかったと顧客からクレームが寄せられたのだ。

しかし、これは非常に喜ばしいことだった。
なぜならイベント参加者はアルバムを作りたいと考えていて、実際アップロードしようとしていたからだ。
仮説が正しいことが証明されたのだ。

逆に、ここで仮説と全く違うことを顧客から指摘されたら仮説の方向性を正さなければならない。
これがいわゆる学習の部分である。

もし顧客の反応と仮説が正しければ製品の修正を行い、仮説が正しくなければ仮説から組み直す。
このライフサイクルを行うことがリーンスタートアップのビジョンなのである。

まとめ

  • スタートアップとはとてつもなく不確実な状態で新しい製品やサービスを作り出さなければならない人的組織である
  • アントレプレナーは不確実で新しい製品や事業を生み出そうとする者
  • 不確実で新しい製品や事業を成功に導く秘訣は検証学習をすること
  • ヒト・モノ・カネ・マーケティングの準備に時間をかけてはいけない
ワンクリックでランキングに協力してください(´;ω;`)
※万一記事に関わる個人・団体の方で記事の削除依頼がある場合、本サイトのお問い合わせから連絡ください。内容を確認させていただきます。

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)