リーンスタートアップ(原題: THE LEAN STARTUP)

今更感がありますが、リーンスタートアップ(第1版第4刷)を読んでみました。全400ページ程度で、最初の80ページはあまり得るものもなさそうかなーなどと思いながら読み進めていたのですが、読み終えてみると結構学びがありました。定期的に見返すために、心に響いた箇所をいくつか抜粋しておきます。

ちょっとでも気になった人は是非買いましょう。サクサクと読めますし、読了後は読了前よりもやる気にみなぎっていることに気付くのではないかなと思います。

リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (91件) を見る


以下、引用と所感です。

引用 P.105

構築 - 計測 - 学習 のフィードバックループ

アイディア → 【構築する】 → 製品 → 【計測する】 → データ → 【学ぶ】 → アイディア → ...

この本の主題である「構築ー計測ー学習」のループ。PDCAとかOODAとかと同じようにも見えますが、ステップが1つ少ないので個人的には好きです。このループを高速に回し続けることこそが、企業の規模やジャンルを問わず成功するために必要、とのことです。

引用 P.107

実用最小限の製品(minimum viable product)

革新会計(innovation accounting)

この本で度々出てくる重要な概念。要は凝った機能を開発するのは無駄な可能性が高いから、本当に必要かどうかはまず実験してみなさいということ。そして評価方法も既存の概念捨てるくらいの覚悟で行くべし、と。

引用 P.122

我々が集めなければならない情報は「事務所の外」にしかない。特にスタートアップは見込み客とのコンタクトを重ねなければそのような情報が得られないのだから、事務所の椅子に座っていてはいけない。出歩いて情報を集めなければならないのだ。

これはエンジニア宛てにも書かれているのかちょっとわかりませんが、意図は伝わります。

引用 P.151

法的リスクで二の足を踏むのはわかる気がするが、MVPを作るにあたって一番多い拒否反応が、競合相手ーーー特に大企業ーーーにアイデアを盗まれるかもしれないという不安であるのには驚くかもしれない。すばらしいアイデアが簡単に盗まれるようなら、苦労はしないと思う。だいたいスタートアップの場合、自分のアイデアや会社、製品を競合他社どころか誰でもいいから知ってもらうことが難しいのだ。この点を恐れるアントレプレナーに対して私は、「自分のアイデアをひとつ(重要性があまり高くないものでいい)、大企業でその領域を担当するプロダクトマネージャーに盗ませる」という課題を与える。電話をかける、レターを書く、プレスリリースを送る……思いつくかぎりのことをしてみればいい。どの企業のどのマネージャーもすばらしいアイデアなら腐るほど持っているのが現実だ。彼らの課題はそのアイデアに優先順位をつけて実行することーーーだからこそ、スタートアップに生き残れる希望があるのだ。

これはまさに目から鱗。

引用 P.185

スプリットテストを導入すると、顧客が望むことと望まないことを深く理解できるようにもなる。ソーシャルコミュニケーションのツールは多いほうが製品の価値は高いはずだと考え、グロキットのチームは顧客同士がやりとりする方法を次から次へと追加していた。もっとやりとりがしたいと顧客は勉強しながら思っているはずだと信じていたからだ。しかし、そのような機能を追加しても顧客の行動に変化が見られないとスプリットテストで確認され、その前提がまちがっているのではないかと疑問が投げかけられた。

ABテストの重要性に気付かされるという意味で、目から鱗。

引用 P.189

遅延登録はオンラインサービスにおけるベストプラクティスのひとつだと言われており、チームは自信をもってこの機能を推していた。遅延登録を導入すると、登録をしなくてもサービスが使えるようになる。とりあえずサービスを使ってみて、そのメリットを経験してから登録すればいいのだ。…中略… グロキットが遅延登録を採用していたのは、これが業界のベストプラクティスだと言われていたからだ。この機能に対し、私はシンプルなスプリットテストを提案した。あるグループの顧客に対し、グロキットのマーケティング資料を見るだけで登録を要求するのだ。驚いたことに、このコホートの行動は遅延登録グループとまったく同じだった。登録率、アクティベーション率、最終的な定着率に違いは見られなかった。つまり、遅延登録は業界のベストプラクティスだと言われているが、それにまつわる努力は無駄以外の何物でもなかったわけだ。

これはもう目から鱗っていうか目から鯨って感じです。自社サービスでも盲目的にやろうとしていたことだったので、やるにしても効果測定をしっかりしなければならないな、と。

引用 P.261

巨大バッチ死のスパイラル(large-batch death spiral)

前回リリースのあとに使った時間があまりに長くて、新バージョンの製品が「会社を賭ける」タイプになってしまうのだ。このときマネージャーは、製品の出荷よりバッチサイズの拡大に走りがちだ。開発期間の長さを思えば、バグをもうひとつ直したり機能をもうひとつ追加したりしたくなる。致命的な欠陥になるかもしれない点を見すごしてこの一大リリースの成功を危険にさらしたくないと思うのがマネージャーという人種なのだ。

いわゆる開発あるあるですね。バッチサイズは可能な限り細かくやるのが良いようです。100通の封筒に手紙を詰める作業も、100通折ってから100通詰めるよりも、1通折って1通詰めるということを100回やった方が効率的らしいです。

引用 P.265

検証したい仮説を設定したら、なるべく早く実験方法を考え、実行していく。このとき、バッチサイズは可能な限り小さくする。フィードバックループは実際に行う順番に合わせて「構築ー計測ー学習」としているが、計画はこの逆順で考えるーーーまず学ぶ必要があるものをみつけ、そこから逆順でその学びが得られる実験となる製品を考える。つまりポイントは顧客ではなく顧客に関する仮説(hypothesis about the customer)であり、それをプル信号として製品開発をはじめとするさまざまな仕事を動かす。これ以外の仕事はすべて無駄である。

つまり常に学びたいものを考え、それを検証しまくろうということですね。ソーシャルゲーム屋さんはこのサイクルがめちゃくちゃ速いイメージです。

引用 P.274

「スタートアップは餓え死にしない。溺れ死ぬのだ」。製品を改善するアイデアなら数えきれないほど浮かぶが、このようなアイデアの大半はごくわずかな違いしかもたらさない。それが現実だ。ほとんどが単なる最適化にすぎないからだ。スタートアップは検証による学びが得られる大きな実験に注力しなければならない。

すごく的を射ている表現だと思います。

引用 P.275-286

粘着型成長エンジン(sticky engine of growth)を使う企業は顧客の離反率や解約率と言われるものに注目する。

…中略…

ウイルス型成長を示す製品の場合、その製品を顧客が普通に使うだけで人から人へと認知が広まる。顧客は知り合いに勧めようとも思っていないし、必ずしも製品について何かを伝えようと思っているわけでもない。ただ、顧客が製品を使うとその副作用として自動的に成長していく。ウイルス効果は顧客がオン・オフできるものではないのだ。

…中略…

ウイルス型成長エンジンを使う場合にはウイルス係数の改善に注力しなければならない。この数字がほんの少し変わっただけで将来性が大きく変化するからだ。

…中略…

広告には100ドルかかり、その結果、50人がサービスを新規契約してくれるとしよう。このとき、この広告は顧客獲得単価(CPA)が2ドルだと言う。ここで商品の生涯価値が2ドルを超えていれば、成長が得られることになる。支出型成長エンジンの回転速度を決めるのは、この生涯価値と顧客獲得単価の差(限界利益)だ。

成長パターン(成長エンジン)が【粘着型成長エンジン】【ウイルス型成長エンジン】【支出型成長エンジン】の3つに分類され、とてもわかりやすい。とりあえずこの章は3回読んだ方が良いと感じました。

引用 P.296

しかし、スピードばかりを重視するのもよくない。スタートアップには、理想的な仕事のペースをみつけるスピード調整器が必要だ。

…中略…

「生産を止めなくていいようにするため生産を止める」という自己矛盾したトヨタの格言に集約されている。アンドンの役割は、品質に修正不可能な問題が発生したらただちに作業をストップすること、つまり、原因究明をしなければならない状況を作ることである。時間のために品質を犠牲にしてはならないーーーこれがリーン生産方式の肝だ。いま品質問題が発生しているなら、あるいは品質問題を見のがせば、その結果生じた欠陥によって後々スピードダウンせざるをえなくなる。欠陥があるとやり直しが必要になる、士気が低下する、顧客から苦情が入るなど、前進を妨げ、貴重な資源を食いつぶす原因がいろいろと発生する。

品質を落とすと結局あとで苦しい思いをする、ということなのだろうけど、とはいえ一方で実用最小限の製品(品質に重きを置かない製品)を小さなバッチサイズで改善させまくって学習しまくらなければならない。そのバランスはやっていくうちに身体で覚えるしかないのかな。このバランスの取り方を開発チームで共有できていれば良いチームになりそうな気がなんとなくします。(ので色々試してみよう。)

引用 P.304

スタートアップは、技術的になにかがうまくいかなかった場合や狙った事業成果がでなかった場合、顧客が予想外の行動をした場合など、障害に直面したら必ず5回のなぜを実行すべきだ。

何を障害と定義するか、正直悩ましいところですね。しかもなぜなぜ5回って本当に難しいんですよね。。。

引用 P.308

5回のなぜを導入する場合、特に初めのころ、組織のネガティブな部分を突きつけられると覚悟しなければならない。この方法を導入すると、新しい製品や機能に投入できたはずの時間やお金をミスの防止に使わなければならなくなる。長い目で見ればそのほうが時間の節約になるのだが、真因の探求に無駄づかいできる時間はないと感じたりする。5回のだれに陥っていしまうこともある。このようなとき、十分な権限を持つ人物が同席し、このプロセスをきちんと実行しろ、求められていることをやれと指示しなければならないし、意見が衝突したときには審判役を務めなければならない。つまり会社の上層部がこのプロセスを支持し、導入を推進しなければ順応性の高い組織は作れない。

ふむ。

引用 P.310

5回のなぜによる学びを促進するには、この方法を適用する分野ごとに責任者を置くとよい。

ふむ。

引用 P.340-341

イノベーションのサンドボックスを用意する

  1. 製品や(複数要素で構成された製品の場合は)サービスのうち、サンドボックスにいれられた部分のみ、あるいは、一部の顧客セグメントや(新製品の場合は)領域についてのみ、どのチームもスプリットテストによる実験を自由に行える。ただし、
  2. ひとつの実験は最初から最後までひとつのチームが管轄する。
  3. 実験期間には上限を設定する(シンプルな機能実験なら2〜3週間、破壊的イノベーションならもっと長期)。
  4. 実験対象の顧客にも上限を設定する(メインストリームの顧客ベース全体に対する割合で定めることが多い)。
  5. 実験の評価は、行動につながる評価基準が5〜10個(これを超えてはならない)ある標準報告書1通で行う。
  6. サンドボックスで作業するチームもそこで作られる製品も、すべて、同じ評価基準で成否を測る。
  7. 実験を準備したチームは評価基準と顧客の反応(サポートへの電話、ソーシャルメディアでの反応、フォーラムへの書き込みなど)を実験中にモニタリングし、大きな問題が発生したら実験を中断する。

どうやって進めようか迷いますね。

引用 P.351

チームの生産性について、その定義を機能的な卓越性ーーマーケティングや営業、製品開発などそれぞれにおけるエクセレンスーーから検証による学びに変えると問題が起きる。すでに紹介したように、各機能のスペシャリストは自分の仕事に没頭できた時間の割合で効率を測ってきた。プログラマーなら1日中プログラミングをしているのが一番という具合だ。このようなエキスパートにとって従来の職場環境は、会議や仕事の部門間 受け渡し、さまざまな上司への説明などで仕事を中断されることが多く、効率が落ちてフラストレーションを感じるものだった。リーン・スタートアップの場合、スペシャリスト一人ひとりの効率向上は目的に含まれない。機能横断的に仕事をして検証による学びを得るチームが欲しいのだ。行動につながる評価基準、継続的デプロイメント、全体的な構築ー計測ー学習のフィードバックループなど、そのためのテクニックはいずれも、チームメンバーの個人的効率を落とす。どれほど速く構築できても意味がない。どれほど速く計測できても意味がない。大事なのは、ループ全体を少しでも速く回すことだ。

これは耳が痛いですね。が、学びの量ベースでの評価スタイルや開発の進め方を鋭意検討中なので、きっとやります。

という感じで、これが僕の心に響いた箇所の全てです。 革新会計ってなんだよ!みたいに思った方もいるかと思いますが、あくまでこの記事は自分のためのメモなのでご容赦ください。

リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (91件) を見る