体験を重視するチームマネジメント
photo by feserc @flickr
本記事は、以下リンクの記事を読んでから、お読みいただくと理解が深まります。
情報流通で企業の思考停止を防ぐために上司と部下でできること
この上司は、デザイン思考（※参考資料後述）で考えると、根本を損なっていると思いました。
Empathize（共感） -> Define（問題定義） -> Ideate（創造） -> Prototype -> Test
部下への共感・問題定義を曖昧にしたまま、反射的に解決策を創造し指導（Test）しているように思います。
Facebookページはじめました。
宣伝し忘れていたのですが、Facebookぺーじはじめました。
https://www.facebook.com/LeanStartupManiax
ブログに載せようとしている話題や、ブログに載せるほどでもないという話題を掲載しています。
ご興味ありましたらぜひチェックされてください！
DevOps Case Study - Etsy
“Etsy” をご存知でしょうか？
Web上にハンドメイドマーケットを作り上げ、６年で売上500ミリオンドルをあげている脅威のサービスです。
日本語の説明については、こちらのリンクが参考になります。
昨日話をしていたところ、リーンスタートアップを実践した企業のDevOpsの話になりまして、EtsyのCTOである Kellan のプレゼンテーションが参考になると思いましたのでご紹介します。
以下、かいつまんで内容を書きます。
- Etsyのスローガン＝「もっとリスクをとろう」「良いソフトウェアをつくろう」「もっと楽しもう」
- 継続デプロイ ＝ 小さな変更を頻繁にPush（デプロイ）する
- ミスすることは避けられないが、大きなミスを避ける事はできる （MTTR <-> MTBF）※Mean Time To Recovery, Mean Time Between Failure
以下、４つの重要なテクニックを使っている
- ボタンを置くにとどめる（Basic認証、ログインなど、社内ツールに煩わしい機能をつけずに、誰でも１ボタンデプロイができる）
- 「機能フラグ」をつくり新旧コードの差し戻しを保証する。エンジニアは、「１％への顧客へのデプロイ」は、事前承認なしで行動してよいと認められている。その代わり、実行後は必ず数値をベースとした報告が必要となる。(measure everything!)
- Trunkブランチは常にデプロイ可能なソースとする。
- ユーザーに告知しない機能リリースをしている。
あまり詳しくは書きませんでしたが、後半部の青文字のスライドはとても良い内容で、楽しんで読める内容だと思います。
また、DevOpsらしい話に関して言うと、彼らが顧客の分析をするために開発したソフトウェアがあり、これを ” statsd ” と呼んでいるようです。
https://github.com/etsy/statsd
-> CookPadでいうChankoに近いイメージです。（僕は両方ともさわったことありませんが。。）
CookPad 研究
リーンスタートアップを学習していると、「顧客志向の強いカンパニー」に対する興味が湧いて尽きません。
日本でその代表格として考えていいのは、間違いなくCookpadです。Cookpadはリーンスタートアップに関する様々な示唆を与えてくれます。
2013/01/26に翔泳社からWEB+DB PRESSのムックが発売され、Cookpadの方法論が載っています。
時々、リーンスタートアップの事例を訪ねられるのですが、この本をオススメいたします。理解の補助程度にされるのがいいと思います。（リーンスタートアップにおいて ”他社事例の模倣に意味はない” という話は別の機会に。）
Cookpad以外にもニコニコ動画、pixiv、ライブドアなどコンテンツがありますが、Cookpadに限りコンテンツを紹介しておきます。
- プロセス（価値仮説シート、成長仮説シート）
- EGOS（Emotional Oriented Goal Setting）
- バックグラウンドにあるシステムと技術の話
- モデルユーザ、ユーザーインタビュー
- DevOps／AARRRの重視
なかなか読み応えがあります。詳細を書くとアレなのですが、事例から理解も進むこともあるだろうかなぁと、紹介してみました。
Lean Startup Machine Tokyo is unlocked!
リーンスタートアップマシーン東京がUnlockされました。
http://leanstartupmachine.com/events/tokyo-may-17-19/
顧客開発は、仮説を書いてフィードバックループがまわせて初めて成立です。このイベントでは”Validation Board”(http://leanstartupmachine.com/validationboard/)を使って、そのプロセスを体験することができます。
改めてValidation Boardをじっくり見ると、これは良くできたフレームワークだと感じます。何が優れているかというと、初回の仮説立案に時間を費やしてしまうようなフレームワークになっていない点です。 先日のブログ（http://leanstartupmaniax.com/post/41832062236）にも書きましたが、初期の仮説なんてものは事実が集まっていない状況ですので、他人からみたら稚拙で当たり前なのです。紙の前でいくら唸っても事実はあなたの手元にやってきません。
新規事業などで顧客開発に取り組もうとする企業が増えてきましたが、get out of the building する部分に精神的抵抗をもつ文化がどうしても立ちはだかります。 僕も勿論この精神的抵抗があるのですが、実は体験してみるとそんなに辛いものではないのではないかと推測しています。
Lean Startup Machine は世界中で行われている、この get out of the building & 顧客ヒアリング をやってしまおう！というイベントです。
この壁を最初に打ち破った人のみが、フィードバックループに入って事実を手に入れることができます。その点においては、能力の優秀さの問題や投入可能なコストの総量の問題など、何も不公平は無いのです。
“NEXT” : combination of “Startup Week End” and “Customer Development”
Original Link about this topics：http://startupweekend.org/2012/10/30/introducing-next/
Startup Weekend NEXT： http://swnext.co/
少し昔の情報ですが、スタートアップウィークエンドチームが、顧客開発へ次の活路を見出したようです。
顧客開発、顧客開発を包含するリーンスタートアップが、次のビジネスビルドのスタンダードになっていく様相が伺えます。
以下、俺訳です。
次のグーグルやFacebookになるスタートアップをどのように作ればよいかはわからないが、ビジネスモデルデザイン、顧客開発、アジャイルの組み合わせで失敗確率を劇的に減らす方法について、ファウンダーへどのように教えるかはわかる。これらはスタートアップが成功するニュースタンダードになると確信している。
・スティーブンブランクのリーンローンチパッドクラスをUdacity.comで受けてもらいビジネスモデルキャンバスを作る、それを持って最初のクラスへ来てもらう。
・スタートアップウィークエンドNEXTチームによるライブコーチングを週次ミーティングで受けてもらう。
・週次ミーティングで受けた提案について話、顧客と会話するために”get out of the building”し、プロダクトのイテレーション、マーケティング、価格付け、チャネルなどといった面でビジネスモデルを改善してもらう。
・自分たちのビジネスを世の中に出し始めるために、スタートアップウィークエンドのボランディアパートナー※と、一緒に動いてもらう。
※スタートアップアメリカとテックスター：全員、連続起業家もしくは熟練投資家
book about “LEAN ANALYTICS” you can pre-order now.
一昨日発表されたオライリーの Eric Ries 監修 ”LEAN ANALYTICS” (pre-order)に関して。（先日サンフランシスコで催されたLeanStartup Conf.にてプレビュー版が配られていました。）本はもちろん英語です。
こちらから申し込めます。
ちなみに同サイトから、Analytics Lessonsというfree e-bookが配られており、Airbnbなど13社のケースが読めるようです。僕もこれから読んでみます。
以下は本の紹介スライドです。
how&utm_medium=email&utm_campaign=upload_digest
椅子のうしろに丸めたキャンバスが沢山あるあなたへ。
最近リーンスタートアップの話を聞くと、キャンバスの話が中心で、MVPの話・KPIの話をほとんど聞かない。
つまり、仮説を立てるのに夢中で、フィードバックループに入っていない。
いわゆる”精度の高い仮説”を求めている。
仮説づくりに時間をかければかけるほど、仮説の失敗コストがでかくなるはずなのに。
仮説思考なんていうとコンサルタント様の高尚な話に聞こえるけど、
仮説とか結局は洞察力と言語表現力の複合問題で、仮説を立てるためのコレといった手法なんて存在していない。
だから、仮説は他人から見たら十分稚拙でいい。
稚拙な仮説から検証方法が思いつかなかったら、もっと細かくすればいい。
それよりも、検証のスピードを上げるための方法、MVPのパターンをどれぐらいストックしているか、Actionable KPIとはどんな内容で、どう図れるかの測定ナレッジが必要。
関連して、堤さんが先日話していたことがとても印象深かった。
「顧客という真実」。
早く真実に触れ、その量を増やさないと洞察は蓄積されないのではと思います。
改めてリーンスタートアップを簡単に説明してと言われたら、
「安い失敗を早く繰り返す中で、洞察を得ていき、その事実へ製品を適合させること」
僕はこんなふうに説明します。
この説明のどこにもビジネスセンスや、精度の高い仮説は関与しません。ただそこにあるもの、それはフィードバックループ以外の何物でもないのです。
フィードバックループ（Build-Measure-Learn）もPDCAもそうですが、結局回さないと意味なんてないと思いませんか？
恐る恐る言いますが、キャンバスの話ばかりするの、もうやめませんか？
LEAN & FAT
It’ll better to think “what is fat”, instead of thinking “what is lean”.
何がリーンかなんて考える代わりに、何がファットか考えたほうがいいんじゃないのか。
And it’ll better to think “what is fat”, instead of thinking “what is waste”.
何が無駄なんだと考える代わりに、何がファットか考えたほうがいいんじゃないのだろうか。
“Fat” is a problem of silent. Most of organization couldn’t notice it.
ファットとは静かな問題で、殆どの組織がその問題に気がつくことができていなかった。
So, let’s make it should be. It’ll be “Lean”.
だからファットであるものを、あるべき姿に変える。それは「リーン」と言える。
無駄なことを沢山していたのが問題じゃなくて、ファットなことを沢山していたせいで、無駄が増えたって、そういうことなんだと思う。とすれば、リーンになるにはファットにならなければいいんじゃないかと。発想の転換的なイメージです。
