とあるエンジニアの作業ブログ

コンサル ビジネス書要約 マネジメント

改めてリーンスタートアップの要点まとめ(3/3) 第3部

投稿日:2019年1月9日 更新日:

lean_startup_image

リーンスタートアップの第3部のまとめ。
第1部、第2部のまとめは以下から。
第1部
第2部

【通年】最新機器レンタル

リーン実践にあたっての案件サイズ(バッチサイズ) :本書 9、11章に対応

9章で述べられているバッチサイズの縮小とは、リーンスタートアップにおけるフィードバックループの1サイクルを、目的を達成できる(必要な”検証による学び”を得られる)最小サイズにすることで、スピードアップとリスクの極小化を図るというもの。

これをもうちょっと現場に即した形で捉え直す。なお、11章の「小さなバッチサイズに順応する」についてもここでまとめる。

バッチサイズ=案件サイズとしてリーンのプロセスの健全性を担保

実際の現場だと、プロジェクトは案件単位に動くだろう。請負のプロジェクトなら大きな本流の案件があり、その下に仕様変更や追加で発生したサブプロジェクトに該当する小規模案件がいくつもぶら下がるという感じかと思う。一方アジャイルのプロジェクトだと、明確に案件ごとに契約するというよりは、契約は1本だがその中で複数のバックログ(もしくはスプリント)を走らせるという感じになると思う。

このバックログをフィードバックループ=バッチサイズと捉えると良い。
つまりバックログは仮説を検証できないほど軽微・過少なものであってはいけないし(実際は細かなバグ修正などはあるだろうが)、作った後に引き返せないほど大きく過剰であってもいけない。
例で示した方がわかりやすい。

例 家計簿アプリにお得情報を配信する記事・広告枠を設ける)
この時バックログ(バッチサイズ)は、「顧客は家計簿を使う傍ら、お得情報に興味・関心を持つはずだ」という仮説が検証できる最低限のサイズであることが望ましい。

【望ましいバックログのサイズ】
  • アプリ中に記事・広告枠を設けトライアル的にお得情報を表示してみる
【望ましくないバックログのサイズ】
  • アプリ中に記事・広告枠を設ける
  • 記事・広告のカテゴリをタブ形式で切り替えれるようにする
  • 検索機能を設ける
  • 記事・広告を投入するCMS機能を設ける

少し極端な例としたが、【望ましくないバックログのサイズ】で開発してしまったら、実は顧客はお得情報になんの興味・関心も示さず、それどころか鬱陶しいとさえ思っているという学びが得られた場合どうすれば良いのだろう。開発にはそれ相応の工数(お金)と期間を費やしているだろうから、第2部まとめの方向転換における特記の箇所で記載した通りそうやすやすとピボットできない状態に陥る。
また、仮にアーリーアダプターに対する検証で価値が認められたからといって、メインストリームの顧客に拡大する際にバックログのサイズを大きくしすぎてはいけない。メインストリームの顧客規模にまでこの価値を拡大できるかどうかが未検証だからである。

つまり、バッチサイズを縮小することはピボットしやすい状態を維持する(リーンスタートアップにおける健全な状態を維持する)という役割も担っている。これが、バッチサイズを縮小することの重要性である。

バッチサイズを縮小するにはそのための投資が必要なケースもある

金融などのミッションクリティカルな業種の仕事をしていると、どうしてもバッチサイズは大きくなりがちだ。
そういった難しさに対して、本書中の以下の文章が一定の解を出している。

たとえば2年目にアルファ版を早期リリースしようとしたが、そのとき大きなストレスになったのが、クイックブックスがミッションクリティカルな製品であることだった。
[···中略···]
バッチサイズを小さくするには技術投資が必要だった。作ったのは、顧客のコンピューターで複数バージョンのクイックブックスを走らせられる仮想化システムだ。

つまり、ミッションクリティカルだからといってバッチサイズの縮小を諦めるのではなく、ミッションクリティカルな製品のバッチサイズを縮小するためにはどうすればよいかを先に考え、そこに投資する必要があるということだ。
逆に言えば、ミッションクリティカルでかつバッチサイズ縮小のための投資ができないのであれば、リーンスタートアップの適用には向いていないということだろう。

事業拡大において注力すべきこと :本書 10章に対応

7章で事業において成長の原動力を計測・改善することで事業拡大を図るということが述べられていたが、10章ではもう少し具体的に事業の成長エンジンのフレームワークを定めている。フレームワーク化することで、事業拡大のために注力箇所が一定明確になる。

注力することの難しさ

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

これはアイデアがいっぱい出ても何が成長に寄与するからわからず、結果労力を無駄にするという皮肉。成長のエンジンを理解すれば、どこに注力して検証による学びを得なければならないかがわかりやすくなる。

3種の成長エンジン

粘着型成長エンジン
一度製品を購入した後、継続的に利用してもらうことで成長を得るタイプ。ベンダロックインなどもこれ。
新規顧客の獲得速度が解約速度を上回れば成長が得られる。

例)
単位期間における定着率が61%(離反率39%)で新規顧客の増加率が39%の場合、成長率はほぼ0となる。
この場合離反率を下げるか新規顧客増加率を上げるかで成長が得られる。

ウイルス型成長エンジン
SNSなどのように、製品を顧客が普通に使うだけで人から人へと認知が広まり成長を得るタイプ。
ウイルス係数という成長を定量的に測る係数の改善に注力する必要があり、ウイルス係数が1を越えると指数的な成長が得られる。

例)
100人がサービスを利用して10人の友達を連れてくる。この場合のウイルス係数は0.1となる。

支出型成長エンジン
売上を新規顧客の獲得に再投資することで成長を得るタイプ。
顧客あたりの売上を増やすか新規顧客の獲得コストを減らすかして、売上に対する新規顧客の獲得に再投資できる割合を増やす。

例)
100ドルの広告で50人の新規顧客を獲得する場合、顧客獲得単価(CPA)は2ドルとなる。ここで製品の生涯価値が2ドルを超えていれば成長が得られる。

実践するための組織 :本書 11、12章に対応

組織はいつでも大切であり、リーンスタートアップでもそれは例外ではない。方法論をどれだけ理解しても、それを実行するための組織基盤が整っていなければ意味はない。

組織は前提条件にすぎず、成功を約束しないことを忘れてはならない。ただ、組織がおかしいとまずまちがいなく失敗する。

リーンスタートアップを実践するための組織に求められる要件として、「順応性の高い組織」と「イノベーションを担う組織」の2つが挙げられている。

順応性の高い組織

「順応性の高い組織」とは「状況の変化に合わせてプロセスとパフォーマンスを自動的に調整する組織」らしい。。。
意味がよくわからないが、以下の例をベースに考えるとしっくりくる。

新人エンジニアが入ると初日にプロダクション環境の変更をやらせることにした。
[···中略···]
IMVUでは「ここで働く初日に壊せるほどプロダクションのプロセスがヤワだったら、それはそうしてしまった我々の責任だ」となる。

要は、何か問題が発生した場合にそれを個人の責任とせずにその問題の原因分析を行い、それを防止する”仕組み”を考案しプロセスに組み入れる。
”仕組み”は継続的(新たな問題の発生有無に関わらず)にメンテナンスされ、自発的にプロセスを堅牢にすることができる組織ということだろう。

具体的には、

  • チェックリストを導入してレビューの漏れをなくす
  • 単体テストを自動化してリグレッションの漏れを防ぐ
  • CIを導入しデプロイにおけるミスをなくす
  • etc…

といった、基本的なことからそこそこ体力のかかるものまで地道なプロセス改善のことだと思う。

また、問題の大きさに比例して対策の重みを変える”比例投資”という考え方も紹介されている。

  • 影響が小さく発生頻度も低い問題 →レビュー体制の強化で改善するか様子を見る
  • 影響が小さく発生頻度が高い問題 →発生した時の対策Tipsをまとめると共に、並行して防止の”仕組み”を構築する
  • 影響が大きく発生頻度が低い問題 →しばらくは該当作業をするときに2名体制とし、並行して防止の”仕組み”を構築する
  • 影響が大きく発生頻度も高い問題 →現行のプロセスを止めてでも最優先で対応し、二度と発生しないような”仕組み”を構築する

といった具合だ。

イノベーションを担う組織

他の本でもいろいろ紹介されているイノベーション組織の作り方的な話である。
そこまで目新しい話はないが、いくつか印象に残った箇所があるのでメモ。

  • イノベーションを実現する組織構造にするためには経営幹部の協力が必要不可欠 →ホントそれ
  • スタートアップチームに裁量権は与えるが、守らなければならない基本原則も必要(親組織の守り方、マネージャの責任の問い方、成功したイノベーションの母体への組戻方法など)
  • スタートアップを親から守るよりも、親組織をどうやってスタートアップから守るかが課題 →社内スタートアップではホントその通り。スタートアップの失敗により親組織の信用が地に落ちることもある。そのために影響を限定したイノベーションサンドボックスなどを用意する
  • イノベーションにおいてもライフサイクルマネジメントは存在する。「導入期」、「成長期」、「成熟期」、「衰退期」的なやつだが、少しだけニュアンスが違うかなと感じた。
    1. 製品を開発する →事業仮説を検証しながら立ち上げる段階
    2. スケールアップ →事業の拡大期。新たにメインストリームの顧客に展開していく
    3. 最適化 →模倣品なども出回り競争激化。オペレーショナルエクセレンスが求められる
    4. 業務コストとレガシー化 →アウトソーシングや自動化によるコスト削減の時代。投資をしても売上が伸びることはまずない
  • 上記の4段階においてアントレプレナーはイノベーションを生み出す創生的なマネージャーから体制側に回っていく(同一人物がになっても良いし別人・別組織にバトンタッチしても良い)

おわりに

まとめるのにめっちゃ時間かかった。
そしてまとめてはみたものの、「ほーん」っていう感じ。。。

やっぱり昔と違ってイノベーション系のプロジェクトをいくつか進めた経験のある今でも、この本に書いてあることまんまだと所詮理想論でしかないなって感じです。

  • そもそも経営層の理解とある程度のまとまった資金が必要不可欠
  • イノベーション組織の中に全ビジネスファンクションが揃いワンチームで推進できる体制(設計・開発の外注などはもってのほか) →開発を外注するとそもそも小さなバッチサイズでフィードバックループを回すことが契約面の観点から非常に困難になる
  • ワンチームの中で働く一人一人がアジャイルやリーンに対して深い関心と理解を持つ
  • テクノロジーやマーケティング、営業などそれぞれのビジネスファンクションで高い能力を持つ人材がいる

こういう前提がバッチリ揃ってれば可能かもしれませんが、これ全部って正直無理だと思います。

重要なのは、
自分たちの組織と人材、資金面などのおかれている状態を贔屓目なしに把握し、
リーンを実践するためには何が足りないのか、それは頑張れば補完できるものなのかを考え、
それを踏まえて本に書かれている内容を教科書にし、自分たちにあったやり方にアレンジすることだと思います。

やっぱり正解になりそうな方法論を知っているっていうのは重要なことだと思うので、今回まとめた内容を忘れずに現場でアジャストさせて活用していこうと思います。
 

-コンサル, ビジネス書要約, マネジメント
-,

執筆者:


comment

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

関連記事

重み付け決定手法(ウェイト計算)

定量評価における重みづけの決定手法に関して勉強した内容をメモ。 目次 総論 一対比較法とウェイト計算 一対比較法 重要度の判定と9点法 一対比較表の作成 ウェイトの計算 総論 AHP(Analytic …

改めてリーンスタートアップの要点まとめ(1/3) 全体概要&第1部

ここ2、3年の仕事はプロジェクトをアジャイルで進めることが多く、かつ今度リーンスタートアップで提唱されているプロセスを採用するということで改めてリーンスタートアップを読んでみた。 以前読んだときは自分 …

銀行システムのセキュリティ要件整理

銀行システム/組織のセキュリティ要件を整理する機会がありました。セキュリティはあんまり詳しくないので自分の勉強がてらメモ。 目次 ざっくり結論 各評価項目の定義 セキュリティ要件解説 前提の整理 セキ …

改めてリーンスタートアップの要点まとめ(2/3) 第2部

リーンスタートアップの第2部のまとめ。 第1部のまとめはこちら。 目次 構築→計測→学びのサイクルと事業拡大/転換 :本書 5、6、7、8章に対応 構築・検証プロセスにおける特記 :本書 6章に対応 …

システムアーキテクチャ設計メソトロジー

システムアーキテクチャ設計のメソトロジー(方法論)をメモ。 目次 アプリケーションの原則とアーキテクチャパターン(Application Principle and Architecture Patt …