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

by shigemk2

当面は技術的なことしか書かない

リーン・スタートアップ

読書ノート

追記 + 感想

手法そのものがWeb系全般のノリである「とりあえずβ版を出してフィードバックを得て改善する」を地でいく方法だからなのか、はたまた著者がエンジニアの経験があるからなのか、 「アジャイル」とか「デプロイ」とかエンジニアの用語がちょくちょく出てくる。

そういうノリでローンチしようとして大失敗したStudyGiftなどを考えると、すべての起業で通用する手法でもないようではある。

まとめ

起業の理論は、立ち上がったばかりのベンチャーが必要とする機能のすべてをカバーする包括的なものでなければならない。すなわち、ビジョンとコンセプト、製品開発、マーケティングと営業、スケールアップ、提携と流通、そして、構造や組織の設計にいたるすべてをカバーすべきなの
企業が長期にわたって経済的な成長を継続できる道は、リーン・スタートアップ手法で破壊的イノベーションを継続的に生みだす「イノベーション工場」を作る以外にないと私は考えている。
このようなテストシステムを開発するのは経営幹部の仕事です。トップが用意しなければならないのです。これは、新しいアイデアをシーザーのように承認したり却下したりするだけだったリーダーが新しい文化とシステムを導入し、チームがどんどん動いてテストシステムと同じスピードでイノベーションが進められるようにすることなのです」
一番のポイントは、どのような業界であれスタートアップは大きな実験だと考えることだ。「この製品を作れるか」と自問したのでは駄目。いまは、人間が思いつける製品ならまずまちがいなく作れる時代だ。問うべきなのは「この製品は作るべきか」であり「このような製品やサービスを中心に持続可能な事業が構築できるか」である。
スタートアップとは、本質的に、アイデアを製品に変える触媒のようなものだ。その製品を顧客が使うとフィードバックやデータが得られる。フィードバックには、定性的なもの(何が気に入って何が気に入らないか)と定量的なもの(何人が利用して何人が役に立つと思ったか)とがある。
この成長のエンジンを始動する努力をくり返し、エンジンが回りはじめたらそのプロセスをくり返してギアを順次あげていく。
持続的イノベーションの場合はどこの誰が顧客なのかがはっきりとわかっており、現地・現物主義で顧客の望みを確認できるが、スタートアップが早期に見込み客と接触してもどの仮説から検証すべきなのかくらいしかわからない。
会社から顧客まで間に何がどれだけはさまっていようが、最終的に顧客となるのは息をし、いろいろと考え、買ってくれる個人なの
分析による停滞だ。計画の改定をくり返してばかりで先に進めなくなるの
アーリーアダプターが求める以上に機能を増やしたり完成度を高めたりするのは、資源も時間も無駄にする行為となる。
求める学びに直接貢献しない機能やプロセス、労力はすべて取りのぞく」
どちらもあらかじめきちんと理解しておかないと努力の方向性がおかしくなってしまう。
どの企業のどのマネージャーもすばらしいアイデアなら腐るほど持っているのが現実だ。彼らの課題はそのアイデアに優先順位をつけて実行すること──だからこそ、スタートアップに生き残れる希望があるの
スタートアップがやらなければならないのは、(1)現状を的確に計測し、評価で明らかになった厳しい現実を直視する、(2)事業計画に記された理想に現実の数字を近づける方法が学べる実験を考案する、である。
ピボットの道が開ける。方向転換するとさらなる実験の機会が生まれ、このサイクルがくり返される。毎回、くり返されるのは「ベースラインの設定、エンジンのチューニング、方向転換か辛抱かの判断」という
顧客数をはじめとする虚栄の評価基準でスタートアップの目がくらむと、革新会計が正しく機能しなくなる。虚栄の評価基準は捨て、その代わり、事業や学びの中間目標の判断に使える評価基準を採用すべきである。それを私は行動につながる評価基準(actionable metrics)と呼ぶ。
せるスプリント(sprint)をくり返し行う形にしていた。スプリントごとに、ファーブがユーザーストーリー(user story)をいくつも書き、その月にすべき仕事に優先順位をつける。ユーザーストーリーもアジャイル開発から取られた手法だ。技術的な言葉で新機能の仕様を書くかわりに、顧客の視点から機能がわかるストーリーをファーブが書くのだ。こうすれば、エンジニアが顧客の視点を中心に考えて開発プロセスを進められる。  機能は、技術的なバックグラウンドの有無にかかわらず理解できる言葉で明快に記述される。標準的なアジャイル開発手法に従い、ストーリーの優先順位はファーブがいつでも自由に変えてよいことになっている。ファーブは顧客の望みを調べ、必要だと思えば、これから作業にかかるストーリーが蓄えられているプロダクトバックログ(product backlog)の中身を自由にいじれるのだ。制限は、すでにとりかかってしまったタスクはやめさせられない──これだけだった。幸いなことに、作業のバッチサイズが1日か2日に収まるようにストーリーは書かれていた(この点については第9章で詳しく検討する)。  このやり方がアジャイル開発と呼ばれているのには理由がある。この方法を採用した場合、すばやく軌道修正ができる、身軽に動ける状態を保つ、オーナーからのビジネス的な要求が変化したときすばやく対応できるといった特長が得られるからだ(オーナーとはプロセスのマネージャーで、ストーリーの優先順位付けを行う者。この場合はファーブである)。  各スプリントが終了するたびチームは何を感じただろうか。毎回必ず新機能を提供した。感想や面談という形でフィードバックをもらい、少なくとも一部の顧客は新機能が気に入ったと確認される。顧客の総数が増えている、生徒が回答した質問の総数が増えている、リピート顧客の数が増えているなど、改善を示すデータも何かしらあるはずだ。
開発者という立場から見るとアジャイルは効率のよい開発方法である。機能や技術設計に集中できるからだ。このプロセスに学習を組み込むと、生産性が下がる可能性がある(リーン生産方式が工場に導入されたときもこれとよく似た問題が起きた。それまで工場の管理責任者は機械の稼働率を重視していた。工場の設計も、なるべく長い時間、能力いっぱいに機械を動かせるように考えられていた。機械という視点から見るとそのほうが生産性が高いからだが、工場全体の生産性を考えるとそれがとても非効率になる場合がある。システム理論でよく言われるように「システムの一部を最適化するとシステム全体は必ず劣化する」なのだ)。
スプリットテストというのは、異なるバージョンの製品を同時並行で顧客に提供する実験である。
3つの「しやすさ」──行動しやすさ、わかりやすさ、チェックしやすさ──が尺度として重要であることがわかる。
スタートアップにとってもっとも難しくもっとも時間もかかれば、無駄の源としてももっとも大きくなりうる意思決定がある。いつ方向転換するのか、いつ辛抱するのかの判断だ。我々は、この根本的な試練に必ず直面する。
スタートアップが滑走路として考えるべきものは、もうあと何回のピボットが可能か、である。事業戦略を根本的に見直すチャンスがもうあと何回あるかとも表現できる。時間ではなくピボットというレンズを通して滑走路を見れば、滑走路を延ばす別の方法に気づくことができる。次のピボットまですばやく進むのだ。つまり、検証による学びを低コストで、いや、短い期間で同じだけ得る方法をスタートアップは考えなければならない。
変えなければならないという認識自体がなくなるため、ピボットがとても決断しにくくなる。
第2に仮説があいまいだと完全な失敗というものもなくなるが、そうして失敗がなくなればピボットに必要な根本的見直しをする気にならないからだ。
わからない、違う方向に進むべきかがまんしてそのまま進むべきかがわからないのが普通だ。  第3の理由はアントレプレナーの多くが怖がっていることだ。失敗を認めると士気ががっくりと下がる可能性がある。アントレプレナーが一番恐れているのは自分のビジョンがまちがいだとわかることではない。一番恐ろしいのは、正しいか否かを証明するチャンスさえ与えられずにだめなビジョンだと思われてしまうことだ。
ピボットの決断は感情的になりがちだが、体系的に行わなければならない。対策としては、ピボットの検討会議をあらかじめスケジュールに組み込むのがいいだろう。スタートアップの場合、定期的に会議を開いて「方向転換か辛抱か」を検討すべきだと私は考えている。経験上、数週間間隔では頻繁すぎるし、数カ月間隔ではあきすぎだと思う。もちろん、自分たちにあった間隔をスタートアップごとに決めなければならない。
そのエネルギーが無駄だったと認めるのは、当然ながらつらいことだ。
方向転換は決心しにくく、結局、決断に失敗することが多い。私は必要に応じて上手に方向転換してきたと言えればいいのだが、残念ながらそのようなことはない。
ピボットにはさまざまなタイプがある。ピボットは変化と同義のように使われたりするが、これはまちがいだ。ピボットとは変化の一種で、製品やビジネスモデル、成長のエンジンについて根本的な仮説を新しく設定し、それを検証するための行動を指す。
ピボットとは新しい戦略的仮説であり、新しくMVPで検証しなければならないものなのだ。  事業を成長させようと思えば、ピボットを避けることはできない。最初の戦略で成功を収めた場合であっても、その後、方向転換する必要がある。
バッチサイズ縮小で得られる最大のメリットは、品質上の問題を早期に発見できることだ。ここから生まれたのが、トヨタの有名なアンドンである。アンドンは、部品に欠陥があるなどその場で解決できない問題に気づいたら、誰でも組立ライン全体を止めて助けを求められる仕組みだ。
バッチサイズを小さくすれば、あとあと無駄にしたと判明する時間やお金、労力を最小限に抑えられるのだ。
このサイクルをすばやく回すためには欠陥の有無をすぐに確認できなければならない。
トヨタのアンドンと同じように、大事なものをエンジニアがまちがって壊さないようにさまざまな防衛措置を講じたわけ
大企業で社内のイノベーションをスピードアップしたい場合、実験のプラットフォームは経営幹部が責任をもって用意しなければならない。
巨大バッチ死のスパイラル(large-batch death spiral)
直面する課題の変化に対応できるレベルの順応性と敏捷性を持つ組織が作れなければ、リーン・スタートアップが成功することもない。そのためには、新しい働き方に伴う人的課題に対応しなければならない。
成長のエンジンとは、スタートアップが持続的に成長するために必要とするメカニズムである。ここで持続的と言ったのは、瞬間的に顧客を増やすだけで長期的な効果が得られない方法を除外するためだ。単発の広告やメディアへの露出など、瞬間的には成長するが、長期的な成長を支えられない方法は成長のエンジンと言えない。
過去の顧客の行動が新しい顧客を呼び込む。
優先順位の議論が時間のかなりの部分を占めがちだというのは、私も経験者として実感している。
スタートアップは飢え死にしない。溺れ死ぬのだ」。
実用最小限の製品を構築する際、アーリーアダプターが必要とする以上の機能を作り込まないことが大事だと指摘した。この戦略をうまく実行すれば、ターゲットのアーリーアダプターをつかむ成長のエンジンを動かせる。しかし、ターゲットをメインストリームの顧客へ移行するためには、追加で膨大な作業が必要になる(注4)。理論的には、アーリーアダプターの間で成長する製品ができたら製品開発をやめてもいい。そうすれば、初期市場の限界まで成長し、成長速度が鈍化したりゼロになったりするはずだ。問題は、スローダウンに数カ月あるいは数年もかかることだ。まさしくこの理由でIMVUも苦労したこと
しまう。顧客の行動をまったく変えられていないのに、製品の改良が進んでいると誤解してしまう。成長をもたらすのは効率的に回転し、新しい顧客を呼びこむ成長エンジンであって製品開発による改善ではない。だから成長が突然スローダウンすると危機的状況になる。  同じ問題は大企業でも起きる。そういう企業
これは永遠の悩みで、サイズにかかわらずすべての会社が苦労する。会社というのは、成長のエンジンをチューニングしつつ、そのエンジンがへたったとき新しい成長の源になるべきものを開発するなど、さまざまな活動を総合的にマネジメントしなければならないのだ。
順応性の高い組織(adaptive organization)と表現するが、これは要するに、状況の変化に合わせてプロセスとパフォーマンスを自動的に調整する組織
スピードが重要だと言いつづけてきた。スタートアップというのは、資源を使いつぶす前に持続可能な事業の構築方法をみつけようと生きるか死ぬかの努力をするものだからだ。しかし、スピードばかりを重視するのもよくない。スタートアップには、理想的な仕事のペースをみつけるスピード調節器が必要だ。
まず、検証による学びと実用最小限の製品の話は、製品はなるべく早くに顧客へ届けるべきである、また、顧客から学ぶために必要な範囲を超える作業はすべて無駄であるということだ。一方、構築─計測─学習のフィードバックループは継続的なプロセスで、実用最小限の製品を出したところで止まることはなく、学んだ内容を活用して次のループに必要な作業を始めなければならない。
製品の機能が増えると、機能を増やしたせいで前の機能が使えなくなるなど、新機能の追加が難しくなる。
なぜを5回問えば、その人的問題を発掘できる可能性がある。
マネージャーやチームリーダーの賛同を得ずに導入しようとするのは危険だ。
回のなぜを導入する場合、まずはせまい範囲で使ってみることをお勧めする。
5回のなぜによる学びを促進するには、この方法を適用する分野ごとに責任者を置くとよい。
小さなバッチサイズに順応する
このような状況で変化を実現するにはコミュニケーションが大切だ。自分たちがどのような変化を推進しようとしているのか、また、なぜ推進しようとしているのかを各チームのリーダーが部下にくり返し伝えた。この
リーン・マネジメントでは仕事をシステムとしてとらえ、プロセス全体のバッチサイズやサイクルタイムに対応しなければならない。つまりクイックブックスのチームも、将来につながる変化を手にしたければ、新しいスピーディーな働き方を実現するツールやプラットフォームに投資しなければならない。
成長期に入ったリーン・スタートアップは、状況に適応していく形で、構築─計測─学習のフィードバックループの周回スピードが速いという強みを捨てることなく、プロセスを複雑化していける。
しかし、確立された企業になれれば話が終わるわけではない。スタートアップの苦労に終わりはない。第2章で検討したように、大企業であっても新たな成長の原動力を破壊的イノベーションでみつける努力をしなければならないのだから。しかも、その努力をしなければならない時期は早く来るようになっている。株式公開後、市場をリードする成功を何年もスタートアップが満喫できる時代は終わった。いまは成功すればすぐ、競合他社や急速に追い上げようとする企業、雑多なスタートアップにプレッシャーをかけられるようになってしまった。
それどころか、マネジメントの方針を変える勇気さえあれば、大企業であっても、ポートフォリオ思考と私が呼ぶこのシフトを実現できるはずだ。
チームを適切に構築しないとイノベーションの成功はおぼつかない。
少ないが確実に資源が用意されていること、自分たちの事業を興す権限を有していること、成果に個人的な利害がかかっていることの3点だ。いずれも、大きな企業の部門にはない特徴である。なお、組織は前提条件にすぎず、成功を約束しないことを忘れてはならない。ただ、組織がおかしいとまずまちがいなく失敗する。
スタートアップの場合、予算が多すぎるのは少なすぎるのと同じくらい危険
実験のプラットフォームを作る
社内イノベーションでは「どうすれば社内スタートアップを親組織から守れるか」が課題だとよく言われるが、私は逆に「どうすれば親組織を社内スタートアップから守れるか」が課題だと思う。人間は脅されれば自分を守ろうとするものだし、皆が自己防衛に走っている状態でイノベーションは成功しようがない。
イノベーションのサンドボックスを用意する
サンドボックスはごく小さく始める。
実用最小限の製品
製品が発展し、次の段階へと移動していくとき、人も一緒に移動するケースが多い。これはスタートアップにも大企業にも当てはまる問題だ。新しい製品や機能を開発した人が、最終的に商品化するチームや部門や資源の管理も行う場合が多いのだ。このため、創造性の高いマネージャーが製品の成長や最適化に力を取られ、新しいモノを生みだせなくなる。
アントレプレナーがイノベーションサンドボックスで生みだした製品は、親組織に吸収しなければならない。
小さなバッチサイズによる開発と行動につながる評価基準からフィードバックを継続的に得て改善を続ければ、学びの中間目標の達成に向けて歩いていけるはずだ。
リーン・スタートアップとは枠組みであって一定のステップを踏襲すればいいわけではないことを忘れてはならない。会社ごとの状況に合わせて応用すべきものなのだ。他人のまねをするのではなく、5回のなぜなどのテクニックにより、自分の会社にぴったり合ったモノを作り上げるのだ。
このようなアイデアをマスターし、さらに深めていくには、同じようなことをしている人々と交流するのが一番である。世界中にリーン・スタートアップのミートアップがあるし、オンラインのコミュニティーもある。この
我々が問うているのは「作れるのか?」ではなく「作るべきなのか?」だ。つまり、我々はかつてない状況に直面している。人類全体の想像力の質が未来を左右する状況
のが当たり前だ、市場の変化は予測できない、「大企業の人間」はどうしても創造性を失うなどだ。スローダウンしてプロセスをもっと注意深く進めれば、質の高いプロジェクトを少数行うことになり、失敗率が下がるはずだと言う人もいる。一部の人は何を作るべきかがわかる才能を生まれつき持っていると言う人もいる。そういうビジョナリーや名人をたくさんみつけられれば問題は解決できるというわけだ。しかしこのような「解決策」は、近代的なマネジメント手法が普及する前、19世紀において最新の経営手法だとされていたものだ。  世界はどんどんスピードアップしており、このような古いアプローチでは対応しきれなくなっ
重要なのは定量的な目標を設定することではなく、その目標を達成するための方法を整えることだ。
リーン・スタートアップ活動を進めるにあたり、狂信的な教義や硬直化したイデオロギーにならないように注意が必要だ。科学とは定型化であるとか、非人間的な仕事の進め方であるとか、おかしな印象を広めないように注意しなければならない。科学とは、人間らしい創造的な探究なのだから。科学を起業に応用すれば、人間のすばらしい可能性が解き放たれるはずだと私は信じている
リーン・スタートアップを活用した組織的スーパーパワーを全社員が手にしたら、どのような組織になるだろうか。  まず、仮説を明示し、その仮説について的確な試験を行うべきだと全員が言うようになる。もちろん、ごまかす口実としてでも仕事のための仕事を作るためでもなく、各仕事を支えるビジョンについて真実をあきらかにしようと思って、である。  品質ばかりを重視する陣営としゃにむに進もうとする無謀派とのあいだでいつまでも議論をくり返し、時間を無駄づかいすることはなくなる。逆に、スピードと品質が顧客の長期的なメリットを追求する二本柱になる。少しでも早くビジョンを検証しようと急ぐが、ビジョンを急いで捨てることはない。無駄をなくそうとして空中にすばらしい楼閣を築くのではなく、画期的な事業成果をすばやく出す。  失敗や挫折があっても悪者探しや非難はせず、正面から向きあい、そこから学ぶ。スローダウンし、バッチサイズを大きくして予防の呪いにとらわれることがないように注意する。逆に、学びにつながらない不要な仕事は省略し、スピードアップをはかる。持続可能な価値を生みだし、世界をよりよくするという長期ミッションを持つ組織を一生懸命に作る。  そして、時間の無駄づかいがなくなるのだ。

ぶんけん