伊藤穣一（MITメディアラボ所長）のレビュー一覧

イノベーションを産み出す組織・ルール作りための教科書。訳が良いのですらすら読める。

以下メモ
p49 全員のアイデアを試す
　たくさんの中から1つしか選ばないとなると、アントレプレナーではなく政治家が生まれる。全員のテストを行うこととすれば、全員が、アントレプレナーになる

5回のなぜを繰り返すこ...続きを読むと。決して5回の「誰」にしないこと

小さなバッチサイズに順応すること

「起業の本」と思って長らく手を出さずにいたことを後悔した。ビジネスに限らず、人生におけるチャレンジ全般に対して示唆がある。

アジャイルとかfail fastといったキーワードはすっかり一般的になったが、まだまだ言うは易しだ。優秀な人ほど直感的にその逆の選択をする習性が染み付いているはず。

計画よ...続きを読むりも仮説を。分析よりも実験を。作業効率よりも学習効率を。

スタートアップにおける古典的名著です。
分かりやすくもあり、何度読んでも新たな発見がありそうです。

商品開発では「何を作るべきか」を確かめていく（顧客について理解をしていく）ことに最も重点を置くべきだということを主張し，その方法論を沢山の例示とともに説明している本．

イノベーションのジレンマ（The Innovator's Dilemma）を避ける方法論にもなっている．


----

- 成長...続きを読む仮説と価値仮説
例 p.222

p.79 「問うべきなのは「この製品を作れるか」ではなく「この製品は作るべきか」であり「このような製品やサービスを中心に持続可能な事業が構築できるか」である。」

p. 80 「耳を傾けるとしたらどの顧客の意見を聞くべきだろうか。...『とりあえず製品をリリースして様子を見よう』と言う方針で進むと、このような問題に悩まされがちだ。...この方針に従うと様子を見ることには必ず成功するが、検証による学びが得られるとは限らない。失敗がなければ学びもない---それが科学的手法の教えるところなのだ。」

p.81 ザッポスの例

p.90 Kodak Galleryの例（「4つの問い」と実験の例）

p.94 ビレッジランドリーサービスの例

p.97 消費者保護局の例

p.112 「我々が集めなければならない情報は『事務所の外』にしかない。」

p.126 グルーポンの例

p.132 ドロップボックスの例（動画型MVP）

p.135 フード・オン・ザ・テーブルの例（コンシェルジュ型MVP）

p.140 Aardvarkの例

p.150 実用最小限の製品を作るときこれさえ守ればいいというルールをシンプルな形でまとめておこう。「求める学びに直接貢献しない機能やプロセス、労力はすべて取りのぞく」である。

p.151 素晴らしいアイデアが簡単に盗まれるようなら、苦労はしないと思う。だいたいスタートアップの場合、自分のアイデアや会社、製品を競合他社どころか誰でもいいから知ってもらうことが難しいのだ。

p.152 スタートアップはすごいブランドを作りたいと考えているところが多く、MVPはブランド構築に対するリスクだと感じられたりする。既存組織内で活動するアントレプレナーの場合、親会社のブランドに傷をつけてはならないと思って行動が制約されたりするが、これモネは同じ話だ。どちらの場合にも使える便利な対策がある。MVPを別ブランドで出せばいいのだ。

p.201 ヴォティズンの例（ズームイン型ピボットとプラットフォーム型ピボットの例）

p.214 経験豊富なアントレプレナーは、スタートアップの滑走路について語ることが多い。...スタートアップが滑走路として考えるべきものは、もうあと何回のピボットが可能か、である。事業戦略を根本的に見直すチャンスがもうあと何回あるかとも表現できる。時間ではなくピボットというレンズを通して滑走路を見れば、滑走路を延ばす別の方法に気づくことができる。次のピボットまですばやく進むのだ。

p.215 ピボットを決意したアントレプレナーに話を聞くと、ほとんどの場合、もっと早くに決断すればよかったと言われる。こうなってしまう理由は3つある。...

p.220 ウェルスフロントの例（劇的なピボット）

p.228 顧客セグメント型ピボット（アーリーアダプター→メインストリームと拡大するとき、顧客の層が変化する）

p.231 ピボットのさまざまなタイプ：ズームイン型、ズームアウト型、顧客セグメント型、顧客ニーズ型、プラットフォーム型、事業構造型、価値補足型、成長エンジン型、チャンネル型、技術型のそれぞれのピボットの説明。

p.237 ピボットとは、単に変化を勧めるものではない。製品、ビジネスモデル、成長のエンジンに関する根本的な仮説を新たに策定し、それを検証できる構造の変化をピボットと呼ぶのだ。これこそリーン・スタートアップ方式の肝だと言える。ピボットがあるからリーン・スタートアップを採用した企業は失敗から立ち直れる。失敗しても、失敗だったと気づき、別の道をすばやくみつけることができるのだ。

p.238 第2部では、最初の要仮説からMVPによる検証、革新会計と行動につながる評価基準による成果の評価、ピボットか辛抱かの判断までスタートアップのさまざまな側面を紹介した。

p.250 バッチサイズの縮小の仕方の例。「製品自体の開発やデザインなど、隠れた部分は今も大きなバッチサイズで動いている。新製品の開発に関わる作業は、仮装の組み立てラインを流れるように進められる。顧客が喜びそうな機能をプロダクトマネージャーが判断する。続けてプロダクトデザイナーがその機能のルックアンドフィールを決める。このデザインがエンジニアリング部門に贈られ、既存製品を改造するか製品を1から作るかする。最後に、プロダクトマネージャーとプロダクトデザイナーが意図した通りの製品になっているかどうかをチェックの担当者が確認する。iPhoneなどの場合、社内のバトンタッチが月ごとや四半期ごとに行われるはずだ。ここで郵送作業の例を思い出しつつ、どうすればこの作業を効率的に行えるのかを考えてほしい。IMVUで我々は、バッチサイズ縮小のメリットを活用するため、新機能を一つずつデザイン・開発・リリースすることにした。こんな感じだ。普通なら別々の部門で働くエンジニアとデザイナーが隣り合わせに座って1機能ずつ作っていく。顧客に使ってみてもらえるレベルまで完成したら、新バージョンとしてすぐにリリースする。比較的少人数にウェブサイトで公開するのだ。こうすれば、作業の成果をすぐに確認し、顧客に対する効果を評価するとともに次にすべきことを決められる。ごく小さな変更が続くと、このプロセスが一日に何回も繰り返されたりした。後で集計した結果を見ると、1日平均で50前後もの変更をIMVUは行っていた。」

p.252 継続的デプロイメント。
（最近のゲームはDLコンテンツで更新が行われたり、リリース後にゲームバランスが調整されたりする。）

p.255 デザインワークスの例（小さなバッチサイズ）

p.258 School of Oneの例（教育分野での小さなバッチサイズ）

p.264 リーンスタートアップの着想の一部はリーン生産方式。そこでは、書きかけの設計図、未検証の仮説、事業計画→MVP→検証→・・・といった生産ラインがある。これを、バッチサイズを縮小し、プッシュをプルにして効率化する。すると在庫を減らせる（ジャストインタイム的考え方）。

p.265 顧客は自分の望みをわかっていないことが多い。

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

p.265 アルファベット・エナジー社の例（仮説プルなプロセス。熱電素子スタートアップ）

p.274 3種類の成長エンジン：粘着型、ウイルス型、支出型。それぞれに定量的指標がある（ウイルス係数など）。
p.286 成功するスタートアップはひとつのエンジンに集中することが多い。...3種類のエンジンすべてが動くダッシュボードを作ろうとすると、だいたい大混乱になる。

// 製品-市場フィットについて
p.286 成長のエンジンが市場のフィットを決める
p.289 成長のエンジンという概念を通して製品と市場のフィットを見れば、足を地につけて考えられるようになると思う。

p.295 スタートアップは新しく入った社員に教育訓練を施すべきだろうか。...しかし結局のところIMVUはすばらしい教育訓練のプログラムを作り、その結果、新人が初日からきちんと仕事ができるようになったし、数週間もせずにハイレベルの貢献もできるようになった。もちろん、仕事のプロセスを標準化し、新人が学ぶべき概念をカリキュラムにまとめるのは大変な作業だった。新しく入ったエンジニアには必ずメンターがつき、IMVUで生産的な仕事をするために必要なシステムや概念、手法といったカリキュラムの習得を支援する。メンターとその指導を受ける人の査定をリンクさせたので、メンターも真剣に指導する。

p.298 5回のなぜ
p.304 「5回のだれ」の呪い
p.307 5回のなぜをスムーズに導入するヒント

p.315 IGNエンターテイメントの例（5回のなぜの例）

p.318 QuickBooksの例（小さなバッチサイズを導入する試みの例）

p.332 予算について
p.331 スタートアップの場合、予算が多すぎるのは少なすぎるのと同じくらい危険だ。

p.334 実験のプラットフォームを作る

小さく始めて、フィードバックループを回して、改善しろ！

これはすべての心理な気がします。
会社を始めるのもそうかもしれませんが、何かを始めるときには小さく始めていけば良いのです。失敗はそこでやめてしまうことです。成功するまでループを回せば、それは失敗じゃないです。成功への過程でしか無いのです！
そ...続きを読むの際には、恥をかくこともあるでしょう！でも、それで良い！権威も権限も捨てて、恥をかこう！始めてなんだから、そういうもの！

って、思える大変良い本です。

ビジョンの達成に向けてMVP(最小限の製品)を最適化しながら、戦略のピボットを最速で繰り返すという手法。アイデアを構築して製品に、製品をアーリーアダプターに問い、計測し、データを得、そこから学び、アイデアに反映させる。構築・計測・学習のフィードバックループ。MVPは最悪動画等でも良い。計測時には比較...続きを読むとなるベースラインが必要。粘着型(マイクロソフトのように切り替えに莫大な労力がかかるモデル)、ウイルス型(Facebook、Paypalなど)、支出型(広告など)の成長エンジンが必要。またイノベーション条件として、①資源、②裁量権、③成果と個人的利害のリンクが必要と説いている。

ネットサービス業界の経営者だと、この概念が腹に落ちてるのとそうでないのでは明暗が分かれると思った。ネット業界でなくても、経営者でなくても、幸せに働きたい全ての人向けの考え方だな。

僕はエンジニアで開発を行っている立場で読みました。とてもリーンスタートアップの考え方に共感できた。今気になっているアジャイル開発ととても似ているなと感じました。
これから僕は副業の中で起業をしようと思っているので、まずはビジョンを考えてMVPを早々に作って評価をしてもらうことを注力しようと思います。...続きを読む

リーンスタートアップの話は、ビジネス以外でも無駄をなくして効率的に時間を使いたい方にも向いているので、ぜひ、皆さんにもおすすめしたいと思いました！

アジャイルでクイックに市場投下していくプロセスで進めるなら一度読んでおくとよい。完成していないプロダクトで如何にユーザFBを得るかがわかる

6/5
リーンスタートアップについての攻略本。とにかく最速で学習サイクルを回す。

Todo
実践リーンスタートアップを読む

リソースに限りがあるスタートアップでは、初めから完璧を目指さないほうがいい。
最低限動く状態のものを早くリリースして、顧客からフィードバックをもらうことが重要。
思えば自社サービスで新機能を追加する時、「こういう使い方の時はこれがいるかもしれない。」「この使い方をされた場合に備えて、この機能を追加し...続きを読むておこう」なんて考えてしまう。
そうすると予定していた工数の2〜３倍になってしまうことがよくある。
こういう時、もしもの時に備えて実装した機能は大抵使われない。YAGNIの法則を実感する。
新機能を作る段階では、顧客の希望するものを想像することはできても、100%合致したものを作るのは不可能に近い。
それよりも早く作ってフィードバックをもらってすり合わせるほうが、無駄なリソースを削除し、顧客に素早い価値を提供できる。
これからは最低限作るものをすり合わせるフェーズを取り入れていこうと思った。

リーンスタートアップとは、サイクルタイムの短縮と顧客に対する洞察、大いなるビジョン、大望とさまざまさなポイントに等しく気を配りながら、「検証による学び」を通して画期的な新製品を開発する方法なのである。

起業の教科書
筆者は自身で起業に携わった経験や起業サポートの経験から、スタートアップの成長に重要な要素を体系的に取りまとめた一冊
(個人的な学び)
顧客というのは製品を提示される前にどういうものが欲しいか分からないことが多い
→ペインポイントの特定が重要(顧客に何が欲しいかを聞いてはいけない)

重...続きを読む要な2つの仮説
①価値仮説
　
②成長仮説

仮説→検証→修正→検証
というプロセスを経てPMFを作り上げる
このプロセスの頻度をあげるためにMinimum Viable Productsが鍵となる

スタートアップの滑走路の長さ(離陸までに使える時間)はピボット(方向転換)可能な回数で数える
→検証を低コスト、高頻度で行うことで滑走路の距離を伸ばせる

PDCAをクイックに回しながら、科学的にプロダクトを作っていくアプローチを紹介する本。ITスタートアップでは当たり前になっていること。

今や事業立ち上げの超基本的な考え方。
事業立ち上げについて、「一発当てる」というイメージから「スモールスケールで検証しユーザーの声を聞きながら徐々にサービスを進化させて行く」という具体的な方法論に変わったのはリーン開発の考え方が世に出てからかと思います。

ただ依然これができず新規事業の成功確率が低...続きを読むい企業が多い印象です。

いきなり大きなことを目指すのではなく、小さな検証から始めていく。固定観念を無くしていく、色々と新しい考え方で楽しかったです。

リーンスタートアップの意味が大分わかった。
MVP（実用最小限の製品）を早く構築し、その価値を計測し、学習したことを次のMVPに繋げることで、イノベーションを起こす。この過程で、重要となるのが、ピボット（方向転換）。これには、様々な型があり、型を意識してピボットすることで、構築・計測・学習のループを...続きを読む的確に回せ、製品開発を成功させられる。

仮説検証を繰り返すことの重要性
走りながら改善を繰り返していくことの重要性に気づかされた。
最初から完璧なものを作ることよりも、出してみて反応を見ながら、細かい改善を繰り返すことが重要。
スタートアップをやる上で、一読すべき。