「RUNNING LEAN 実践リーンスタートアップ」読みました

今度会社で訳者の角さんに研修を行なっていただくという機会に恵まれたということもあり、デブサミで「RUNNING LEAN 実践リーンスタートアップ」を買いまして、読みました。

感想

スタートアップの事業が成功を得るためにやるべきことが書かれた本です。特にITベンチャー向けの話で、エンジニアとして参考になる部分は多かったです。ただ、やはり自分の興味あるところは経営・企画ではなく、要求を仕様に落としたり開発のスピードアップを上げる、というところに興味の中心があって、「アジャイルな見積もりと計画づくり」を読んだ時のように、これすぐやろう！みたいになる部分は少なかったですね。最もスタートアップ系の企業は一人〜数名で全部やらなくちゃいけないんだよ、僕はITエンジニアなのでITだけやります、と言うのは許されないよ、というのがあるのでスタートアップできる人たちのスキルやモチベーションはやっぱりすごいものなんだなぁと感じました。

一方で、半年ほど前まで社内の新規事業のWebサービスの部署にいたので（終了宣言しちゃいましたが・・・）、その時に知っておくといろいろできたのになぁ、とか確かにこういう考え方はだめだよなぁ、みたいに感じる部分はたくさんあってそういう点ではとても面白かったですね。

良かった点まとめ

顧客の言うことを聞かないといけないけどそのまま聞いてはいけない(p.xxii)

顧客に欲しいものを聞いていたら、彼らは「もっと早い馬が欲しい」と答えていただろう（中略）既存の代替品よりもっと速い何かを求めていたからです。

これ、最近よく聞く言葉ですけどたしかに早い馬をお客さんが望んでるんだからなんとかして作れ、みたいな話ありがちです。

事業計画書が無駄(p.4)

テストしていない仮説に基づいた60ページの事業計画書をわざわざ時間をかけて書くなんてムダです。「無駄」とは、実行すると資源を消費するだけで、なにも価値を生まない活動のことだ。

事業計画書じゃないですけど、エンジニアリングでも無駄なドキュメント作るときに感じていた違和感がこの言葉で具体的になってしっくりきました。しっくりきても現状はなにも解決はしてないんですけどｗ

ビジネスモデルが製品(p.7)

起業家・エンジニアはソリューション語ってドヤ顔したくなるけど、ビジネスモデルまで含めてが製品だという考え方。この視点はなかったので参考になりました。

顧客とユーザーを区別(p.23)

製品にお金を支払ってくれる人が「顧客」です。「ユーザー」はお金を支払ってくれません。

無料ユーザーを大事にしすぎてた人とか前のプロジェクトで居て違和感があったので、この言葉もっと早く知っておけば言えたのに、ドヤ顔でろくろ回しながら言えたのに！

CloudFire(p.25)

こんな感じのサービス、前の部署で考えていた人居たのですが、やっぱり前に進められるものはここまでちゃんと資料に落とし込んでるんだなぁ、と感じました。プレゼン用のパワポをまとめるだけで精一杯なのではなく。

アーリーアダプター(p.31)

メインの顧客に手を伸ばそうとして、「中間」の顧客をターゲットにした薄っぺらなメッセージを作るマーケッター

汎用的な、みんながターゲットで薄っぺら、というのはありがちですね。

チャネル(p.38)

自分のよく知った製品と、上司から割り当てられた実績のない製品。どちらかを売らなければいけないとしたら、どちらを選ぶでしょうか？

最近直面してる現実な感がある（；^ω^）

課金(p.40)

繰り返しでてきますが、課金は早い段階（最初）からやる、ということ。無料アカウントでトライアルを長くもうけるとかダメらしい。最初から課金してくれる人は優れた「顧客（≠ユーザー）」で、そういう人の意見には非常に価値がある。

圧倒的な優位性の話(p.46)

圧倒的な優位性とは簡単に真似・コピーされないものだという話。具体的なものはなにかっていうのが気になったら本買って読むといいと思います。

課題チームと解決チーム(p.59)

建物の外で課題を見つけてくる「課題」チームと、それを建物の中で解決する「解決」チーム。要するにプラニングとエンジニアリングのように読めるのですが、企業規模が大きくなると変に縦割りが強くなって壁ができるんですよね。プラニングはパワポと基本仕様作って開発に投げて自分の仕事done.エンジニアリングは降りてきた仕様を開発してdoneみたいに自分の範囲だけ達成して、上司に評価してもらうのが目的になる。お客さんの方を見なくなっちゃうんですよね。