リーン・スタートアップ
2012年に発刊されて、今では割とスタートアップ界隈の教科書的なポジションにある（と思っている）本書ですが、改めて課題図書という形で読み直してみました。
速読形式ですが、気になった点を以下にいくつか抜粋。
■ルーツはトヨタの生産方式
本書の中で度々登場するように、TOYOTAの思想が色濃く反映された書籍のように感じます。そもそものリーンスタートアップという名称自体が、TOYOTAで大野・新郷の2名が開発したリーン生産方式にちなむものだとのこと。価値を生み出す活動と無駄を明確に区別し、質の高い製品が作れるように洗練されたものを言うのだとか。
・作業員の持つ知識/創造性の活用
・バッチサイズの縮小
・ジャストインタイムの製造と在庫管理
・サイクルタイムの短縮
…etc
■リーンスタートアップとは
上述の名称由来にもよるが、そもそもの言葉の定義について。リーンスタートアップとは、『サイクルタイムの短縮と顧客に対する洞察、大いなるビジョン、大望と様々なポイントに等しく気を配りながら、「検証による学び」を通して画期的な新製品を開発する方法』なのだそうです。
■独りよがりなプロダクトに陥らないための4つの問い
コダックの事例が引用されていますが、リーンスタートアップにおいて以下の4つの問いをメンバーに尋ねる事を大切にするようになった、と言っています。
1.我々が解決しようとしている問題に消費者は気づいているか？
2.解決策があれば消費者はそれを買うか？
3.我々から買ってくれるか？
4.その問題の解決策を我々は用意できるか？
今までは（通常の企業は）概して4番目の問いからいきなり製作に取り掛かってしまい、いざリリースすると全く売れないという悲惨な状態を迎えるのだとか。レガシーな大企業に見られそうな問題ですね。
■実用最小限の製品（MVP:Minimum Viable Product）
要となる仮説の段階をクリアしたら、最初のステップである構築フェーズに入り、なる早でMVPを作ることが大切です。ここで言うMVPとは、構築-計測-学習のループを回せるレベルの製品で、最小限の労力と時間で開発できるものを指しています。将来的に必須になるような機能さえ無い場合もあるのだとか。
■コンシェルジュ型MVP
事例として取り上げられたのはフードオンザテーブル社。自分の好みや食材に応じたレシピが提示されるという、「自分用にカスタマイズされたオンラインシェフがサポートしてくれる」ようなサービスです。
以外なことに、スタートは一人の顧客からスタートし、その時はサービス定義やレシピはおろか、ソフトウェアのモックさえなかったのだそうです。そのかわり、最初の顧客一人にCEOとVP（VicePresident）がつきっきりで対応し、どんなレシピが好きか、どういうサービスを求めるかを徹底してヒアリングしたのだとか。
そこからが肝で、これに慣れると数人単位に増やしていき、（徹底してヒアリングするスタイルは変わらず）人的リソースで対応しきれなくなった（要望の最も多い）機能を開発に着手するのだとか。そうしていくと、既に開発された部分は人手でコンシェルジュ対応する必要はなくなります。最初の一人or数人に対して如何にして徹底的に向き合うか、ペインを引き出すか、がプロダクトの肝となります、と言っているようです。
■恥ずかしがらない
低クオリティのMVPは十分役に立つ、という事例の紹介で、IMVUのアバターが取り上げられています。当初、アバターは3D上で固定されており、ユーザーがアバターをテレポートさせたい要望に応えられていませんでした。これに対し、高度な技術での対応は無理だったため、代わりにワンクリックで直線的に（ダサい形で）移動できるだけの機能を実装（到底テレポートなんてかっこいい言葉で呼べないレベル）。妥協の産物でしかなかったのですが、ユーザーアンケートのTOP3で毎回挙がってくるほどの人気機能として挙がったそうです。クオリティに拘る前に、まずは実装して試して改善していく、というスタンスが求められます、という話ですかね。
■ピボットの勇気
1.虚栄の評価基準からニセの認識を引き出し、自分だけの現実に生きてしまう
2.仮説が曖昧なら完全な失敗も無いが、完璧な失敗が無ければ根本的見直しも必要ない
3.失敗を認めると士気が下がる可能性がある
多くのアントレプレナーのうち、3番が意外にも最も大きな障壁となっているようです。これは現場でやってきた人間からすると、とても腹落ちする結果では無いでしょうか。でも一番の不幸は、中途半端なまま走り続けてしまう（ゴールを見誤る）まま疲弊していきやがて市場で淘汰されてしまう、という事なので、経営者（orPM）は思い切って舵を切る決断が大事なのだと言う事かと。
■メインストリーム顧客
MVPをアーリーアダプターに当ててアジャストさせていく、というフェーズを抜けると、そこからはメインストリームの顧客が対象になり、戦い方が変わってきます。これは非常に難しいらしく、アーリーアダプターで成功したやり方とメインストリーム顧客へのアプローチが全く違うのだそうです。成長する過程で（CASMに向かう中で）、ユーザー数や売上なども伸びていくが、どこか小さな部分で歯車が違うと感じ始める、ただ上述の勇気が出ないために無視し続けてしまう。そうなってからではピボットは難しい、というお話です。この違和感を感じ取って勇気を持ってピボットに踏み切れない企業やプロダクトが腐るほど有るわけですが、これを乗り越えないとCASM越えは難しい、と。
■5回のなぜ
何かの問題に直面したとき、立ち止まって5回の「なぜ」を繰り返してみた事はあるか、それがとても重要なのだそうです。逆に、5回のなぜを繰り返す前に解決してしまう問題は本質的なものではないからほっておいても良い、とも言えるのだとか。
（例）
1.新バージョンで使えなくなった機能があるが、それはなぜか？
⇒あるサーバーに障害が発生したから
2.なぜ、そのサーバーに障害が発生したのか？
⇒影で動くサブシステムの一つについて使い方が間違っていたから
3.なぜ、使い方が間違っていたのか？
⇒エンジニアが正しい使い方を知らなかったから
4.なぜ、エンジニアは知らなかったのか？
⇒教えられていなかったから
5.なぜ、教えられていなかったのか？
⇒忙しく新人教育に時間をさく余裕がチームにないとMGRが考えていたから
■イノベーションを隠さない
社内でイノベーションを起こすようなスタートアップがあった場合、ちゃんと透明性を担保すべき、という意味の章です。確かにAppleやIBMのように、超秘密主義で開発を進めて成功する企業もありますが、大抵の場合は逆で、秘密主義が軋轢を産むし、特にMGR層などの中間役職のメンバーは、「自分は共有を受けていない」と不信感を抱くようになるそうです。隠すメリットより、それによる組織内でのデメリットのほうが大きいという教訓です。
■ピータードラッカー
本書全体を通じて感じるのは、間違ったことを効率的にし続けていることへの警鐘を鳴らしています。「やってはいけないことを素晴らしい効率で行うほど無駄なことはない」という、最大の皮肉を込めた表現が挙げられています。日本に限らず、多くのレガシーな大企業ではそのような状態が続いているのでしょう。これは、本書の参考にも入っている『イノベーションのジレンマ』でも語られている話で、とても難しくて根深くて、興味深い話です。