makopi23のブログ「LeanStartupNight - Eternal Rotation! -」に参加しました

2012/9/21(金) 「LeanStartupNight - Eternal Rotation! -」に参加してきました。

Doorkeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1687?auth_token=KtzNwSR5xptmQrC6sMfR

togetter（ツイートまとめ）
http://togetter.com/li/377362

DevLOVE LeanStartupNight -Eternal Rotation!- まとめ
http://matome.naver.jp/odai/2134822157181001701

会場は株式会社エムティーアイで、主催はDevloveです。
参加者は８０人くらいでしょうか。

このイベントも申し込みから満員まで一瞬でしたね。
アジャイルの勉強会は最近良く見かけるようになりましたが、リーンスタートアップをテーマにした
勉強会はほとんどないので、アジャイルやってる人からしたら今日の勉強会は願ったりだったのでしょう。
そんな私もリーンスタートアップは概要レベルしか知らなかったので、今日のイベントは非常に興味ありました。

講師はLean Startup Japanの和波俊久さんです。
以下は講演中の一幕。

以下、自分への覚書としてのメモ。

19:40 - 20:40 Startup! Lean Startup

■マーク・アンドリーセン（Marc Andreessen）
・Mosaicというブラウザを作成し、２０代前半で億万長者になったエンジニア
・「ソフトウェアが世界を飲み込んでいる（Sotfware is eating the world.）」

■スマートフォンが世界中にソフトウェアのチカラを届け始める。
５年以内に５０億の人がスマフォというコンピュータを毎日使うようになる。

■これまでは産業の中に根ざしたビジネスのルールの枠にいる競争者との戦いだった。
今はルールが全く変わっている。

■いつの間にか産業がなくなっている。

・手紙や図書券のような、紙媒体
・紙広告
・紙幣

→　デジタルへ移行した。誰が乗っ取ったかというと、ソフトウェア。

例：コダックの倒産。

・フィルムへの固執が命取りとなった。
・逆に富士フィルムは、フィルムに固執しなかったため、生き残っている。
・一度飲み込まれると、気づいてからでは遅すぎる。
・リーンスタートアップの先行事例として取り上げられていたコダックさえ倒産する時代。

■決めた計画の実行力より、想定外の変化への対応力が必要。
複数の人間がオセロをやっているような感じ。いきなり誰かが隅っこに石を置くような時代。

■昔は事業を立ち上げるのに、最低でも1000万円かかった。
今はOSSとかクラウドとかを利用すれば、0円でサービスが立ち上がる。
今の時代、ライバルは企業ではなく、親から貰ったお古のコンピュータを使いこなす幼い子供かもしれない。

■アンゾフの成長マトリクス
【参考】http://www.tam-tam.co.jp/tam_marketing/Ansoff_matrix.html

「製品開発」の象限↓

・何もノウハウが無い。未知の領域。
・既存領域はソフトウェアが飲み込んでいる。そこに挑んでもダメ。「新規開発」へ向かうしかない。
・社内で承認プロセスを経ようとしているようでは、「新規開発」のライバルは先に行ってしまう。

■Lean Startupは、大きな戦略の話。戦略論。

■Lean Startupを企業が手に入れると、「柔軟性＋走りながら考えるチーム」ができる。
→　状況が見えるようになり、新規事業のリスクが劇的に軽減される。

■Lean Startupを一言でいうと。。。

変化に対応できるチームを作るための、現存している唯一のバイブル

■生き残る企業と死んでいく企業がある。生き残る企業には理由がある。
→　誰に向けたサービスをどう作っていったのか、フォーカスできていると生き残れる。
→ 「誰が探してくれるの？」を意識するところが残る。コンセプトを持っていることが重要。

■最初から全員が欲しいものが出来なくても、その中の一人の、彼のためだけなら幸せにできる、
というものを少しずつ作っていくのがリーンスタートアップ。すばやく素早く。

■リーンスタートアップではPivotを繰り返しながら、マーケットが「Wow！スゲー！今すぐ欲しい！」と
言ってくれるまでビジネスモデルを探していく。

→ Wow！と強い反応が返ってこないとダメ。

■Pivot（方向転換）のコツ

・とにかく素早くやる
・とにかく何回でも試す
・小さなものからやる
・特定のマーケットからやる
・改良をする

■ビジネスをスタートした瞬間から、以下は凄いスピートで減る。

・お金
・外部から得られるサポート
・モチベーション

前者２つはあとから注入可能。
モチベーションはそうはいかないので、尽きる前に何回ビジネスを試せるかが重要。

■リーンスタートアップを加速させるための４つのポイント

１．小さく始める
２．繰り返す　（繰り返し繰り返し試す）
３．仮説から始める　（仮説を立ててから全ての行動を始める）
４．常識を変える

■１．小さく始める

・MVP（実用最小限の製品：Minimum Viable Product）
・完璧はいらない。すべて完璧が必要なのは、圧倒的なスケーリングが求められるタイミング。
（例えば1000万人の人にサービスを提供するとか）
・Simple is Best。後は走りながら考える
・人に頼るのはダメ。自分がまず変わること。自分が走り始めないと何も変わらない。

■２．繰り返す

・新規事業は何回失敗してもOK。法律さえ犯さなければ、ルール何にもなし。
・繰り返さないほうが損。３ヶ月もかけて１回しかリリースしないのは圧倒的な損。
・走り出さないからウォーターフォールになる。走り出せばウォーターフォールされようがない。
ウォーターフォールから抜けれない人は、走り出さない人。

■３．仮説から始める

・失敗の元凶１
- 一発勝負に出る。
- 先送りにする。

・失敗の元凶２
- ガントチャート
- チェックリスト

チェックボックスにチェックが増えると自己満足感は得られるが、何も終わってない。
もっと言えば、ビジネスは一つもも始まってない。

・タスクから始めてはいけない。仮説から始める。

■４．常識を変える

・経営者は「新規事業を立ち上げろ！」と言うが、以下にハマっている経営者が多い。

- 新しすぎて理解できない。
- 今までどおりの報告書を要求している。
- リスクを回避すると賞賛する。

→　これでは新規事業は生まれない。
斬新な考えを提供する秘密兵器が投入されても、経営者が理解できないので、秘密兵器が腐っていく。
こんなんでは、どんなに頑張っても竹弁当しか出てこない。無難の塊になる。

・経営者でも、新規事業はノウハウがゼロ。ゼロから書き直していかないと、無難の塊（竹弁当）になる。

・新規事業開発　＝　新しい「ものさし」を作ること。

新しい「ものさし」は、以下に適用していく。

- 進捗
- 将来性
- 貢献　・・・貢献度をちゃんと図る仕組み作らないと、タスク(ToDo）を埋める作業に戻っていく。
- 新規性・・・新規性を理解できるようになるにはどう測ったら良いのか。
- チームワーク
- スピード

・まずタスク管理をやめる。仮説をとにかく書き出し、どのくらいその仮説が証明されていくかが目安。
・自分たちがどういう状態にあるのか、間違った方法で計らないこと。
（例えば月に１回しかログインしない人をアクティブユーザとしてカウントするような測定は愚行）

■数年前に言われていたStartupのフレームワークから、現在言われているStartupのフレームワークへの変化を表した図

（@fullvirtue さんのTweetから写真引用）

如何にして私はリーンスタートアップにたどり着いたか

■下流から上流へ

・下流のプログラマをやっていて、恐ろしいデスマーチを経験した。
・一度、上流工程の人が集まる参謀会議に出席してみた。
→　参加者がまるで解を出そうとしない状況を目の当たりにした。ダメだコイツ、早く何とかしないと。。。
→　俺が上流へ行くしかない。

■上流に登ってみて、源流で見たもの（プロジェクトを生み出す立場から見たもの）

・矛盾の源流は、請負契約。

・請負契約では、発注者と受注者は当然のごとく、相反する。
- 発注者側のPM：とにかくたくさん、やすく、いいものを作りたい。思いついたものはすべて作ろう。
- 受注者側のPM：とにかく安く。仕様変更は追加料金を求める。粗利重視。

・受発注者の相反には高い壁があり、相容れることは今後ありえない。

■どうやら、ウォーターフォールやアジャイルといったメソドロジーの問題では無い、と気づいた。

・請負契約の問題を解決するには、発注者と受注者が同じ世界にいるしかない。同一化する。
・ただ、内製だけではダメ。情報システム部門と業務部門は、一般的に仲が良くない。

■スタートアップは、困難度は上がるが矛盾が少ない。

■Agile vs Lean

	Agile	Lean
価値	サービスイン	ローンチ後
満たすのは	要求事項	マーケットのニーズ
Driven by	ユーザーストリー／テスト	仮説（課題・ソリューション他）
アプローチ	インクリメンタル or イテレーティブ	MVP
ゴール	満足度	ROI

■ウォーターフォール vs アジャイル

　・いいアイデアもってるけどＷＦやってる人
　・いいアイデアはあんまないけど日々アジャイルやってる人　
　
　→　後者のほうが事業が成功する可能性は圧倒的に高い。

20:40 - 21:40 No-Bull Know-How LeanStartup

■Q1.
Q.
リーンスタートアップを社内教育にどう導入するか？

A.
Lean Startup Japanで講師を担当することも可能。5分バージョンから8時間バージョンまである。

■Q2.
Q.
リーンスタートアップをハードウェアベンチャーでハードを対象にどうやるか？
（ハードは、モノ作るのにそれなりの設備とか必要）

A.
ハードとソフトの対比は関係ないと思っている。
リーンが検証するのは、提供するバリューがマーケットに受け入れられるかどうか。
iPhoneは、iPodを作ってる段階でだいぶApple内で検証が進められていたハズ。
ハードの設計よりもUXが先。まず仮説を立てること。
あんまりマテリアルに縛られないほうがよい。

■Q3.
Q.
現在の抜けてる視点として、使う人に対する視点が置き去りになっている。そうじゃなく、UXが大事。
UXの大事さをうまく伝えていくには、どう伝えていくべきか？

A.
「今のコンセプトではダメだから、UXで変えましょう」と言って、会社を変える権限を持っているだけの
UXデザイナに、今まで会ったことがない。つまり、UXデザイナが会社の中で権限を持っていないのが問題。

海外では、UX担当者が執行役レベルで担当している。
日本の会社でも、UXを執行役員レベルで推進しないと、本当の価値は出せない。

■Q4.
Q.
日本でスタートアップを継続して価値出している企業はあるか？

A.
成功の定義が各社で違うので一概には言えない、というのが根本にはある。
ただ、サイクルを回しながら徐々に改善を目指していく仕組みがインストールされた段階で、いったん一つの成功と見て良いと考えている。
なぜなら、そこで学びを得て、必ず次へステップすることで成功に近づけるから。
その観点で言うと、いくつかの会社はやっている。（会社名は出していいのわからないので、控えます）

アジャイルは、サービス開始後を意識する人はチームにあんまいない。
「ある一定のサービスインに向かってリーンスタートアップやっていこうぜ」というのは、その時点でリーンスタートアップではない。
事業が成功する日に向かって、その日までやるのがリーンスタートアップ。

■Q5.
Q.
事業と開発を分けて考える時点で負けかな、と思ってる。
事業が言われたものを作る、という構図を実現するために効率的な方法として、
リーンな方法としてアジャイルを使う、という構図が生まれている。
この辺を打破しない限りリーンスタートアップは熟成するような組織は生まれないという危機感がある。
どうすれば良いと思うか？

A.
事業と開発が分離されていること自体が、最大の超えないといけない壁。
経営者の理解を勝ち取る必要がある。
理解を勝ち取る、というのがどういう状態になるのか。
「リーンやってもいいよ」と言われるだけでは、理解を勝ち取ったことにはならない。

まず、新規事業を開発する、というのを「プロジェクト化」してはいけない。
プロジェクト化した段階で、リーンじゃなくなる。
プロジェクト化すると、ゴールはプロジェクトを終えること。どうしても、終えようとする。
事業が成功することが目的ではなくなり、リーンじゃなくなる。

ビジネスは勝ちに与えられるパイは決まっており、相対評価できまる。
それに対して柔軟に対応できるかが、リーンに問われているところ。
リーンスタートアップを理解している、ということは、環境が何か変わったら手を打たなければいけない、ということ。

■Q6.
Q.
サービスの価値を提供する先のユーザと、収益の源泉（お金を出してくれる人）が結びつかないことがよくある。
例えば、facebook。価値を届ける先は、ユーザ。でもお金を払ってくれるのは企業。
新規事業を立ち上げる時に、どちらに集中していくべきなのか、という葛藤がある。どうすればよいか？

A.
ビジネスモデルの仮説に対して、真摯に普通にチャレンジする以外に何もないのでは。
無料なんだから、とか、お金を払ってくれる人が別なんだから、というのは関係ない。
ビジネスを成功させる仮説に基づいて、そこに向かってチャレンジしていくだけ。

■Q7.
Q.
英語の学習ソフトを作ろうと、リーンに基づいて、その辺にいる人にインタビューを敢行してみた。
・1回目のインタビューは、ランダムに聞いて回った
・2回目のインタビューは、MVPを作って話しかける対象をビジネスパーソンに絞った。
・3回名は、チームリーダの意向から、女性に絞った。

最初の仮説として、ビジネスパーソンに絞る、というのを決めるのは他のスタートアップだと難しかったと思うが、どうやって仮説を立てるのが良いのか。

A.
まず、事業のターゲットを絞るのに「ビジネスマン」という括りではターゲットがデカすぎる。
どういうような「ビジネスマン」なのか？を掘り下げる必要がある。
・何をしているシーンを想定するか
・どんなことに不満を持っているのか

今にでもお金を払ってくれるようなユーザに絞る必要があるので、課題をベースにセグメントを切っていくべき。
インタビューのクオリティは以下の公式で決まる。

インタビューのクオリティ
＝　インタビューする側のシナリオのクオリティ　×　インタビューされる人が適切なターゲットか

ターゲットをきっちり絞って、その条件に該当する人にインタビューしないと、インタビューの質は一向に上がらない。
ペルソナの有効性は、目的次第で変わる。

■Q8.
Q.
レベニューシェアでやるのは難しいと考えているか？

A.
レベニューシェアが銀の弾丸になるとは思わない。あれはただの請負契約の形の１つなので。
請負契約である以上、納品したら終わり。
請負だと、ローンチ後も要員を投入し続けるベンダなんてない。

■Q9.
Q.
仮説を立てるのは私たちはヘタ。
講師として、今回の勉強会にどういう仮説を立ててどういうフィードバックを期待して望んだか？

A.
今回の勉強会は事業だと考えていないので仮説立てない。
出席した人の満足度があがればいいなぁ、というところまで。
今回はどちらかというと、システム開発寄りの方をターゲットとした。

★感想：
和波さんの語りは非常に明快で、引き込まれました。
あと、どちらかというとアジャイルは手法寄り、リーンはビジネス寄りな感じですかねー
これはアジャイル、これはリーンと明確に区分けするよりも、両方の良いトコ取りする感じが良いのでは、
と思いました。（非ウォーターフォールみたいな）

パレートの法則（80:20の法則）というものがよく言われますが、早く市場に投入した2割の機能が8割の価値を生み出すのなら、それは非常に意義があることだと思います。
WordやExcelの機能だって、一般ユーザが普段使ってる機能なんて、全体の10%～20%くらいなのでは。
そーゆー意味で言うと、ほとんど使われない（≒価値を生まない）機能まで作りこんで、完成させてから市場に投入してるようでは、他社に市場を奪われてしまうでしょう。
また、早く失敗がわかる、という点も見逃せないと思います。

今日得たリーンスタートアップの知識を体系建てるためにも、今日の勉強会のターゲットにもなってた本を1冊読んでみようかなぁ、と思います。