読者です 読者をやめる 読者になる 読者になる

月曜日までに考えておきます

ITネタとゲームネタ中心に興味のあること色々書きます。

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

IT 技術書

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

感想

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

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

良かった点まとめ

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

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

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

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

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

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

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

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

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

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

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

CloudFire(p.25)

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

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

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

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

チャネル(p.38)

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

最近直面してる現実な感がある(;^ω^)

課金(p.40)

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

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

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

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

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

わかりやすいダッシュボードを作る(p.67)

ビジネスは水槽のように経営すべきだ。

経営にかぎらず、開発のバックログとかもちゃんと公開してステークホルダーと話した方がいいと最近すごく感じています。同じ会社なら仲間なんだから手の内見せあって、その中からいい手が作れる作戦を考えるべきなんですよね。

アンケート調査の話(p.75)

アンケートは正しい質問があることを前提にしています。

前のプロジェクトで、調査会社に依頼してすっげ長いアンケートを作って出してたりしてたけど、それに対して「これに回答してくれるユーザーと言うバイアスが既にかかっているよね」と言ってた人が居たのを思い出しました。

行動につながる指標の話(p.135)

行動につながる指標の反対は、虚栄の指標です(アクセス数やダウンロード数など)

すまぬ・・・すまぬ・・・って気持ちでいっぱいになった:(;゙゚'ω゚'):

80/20ルール(p.162)

ローンチ後は80%は既存機能の改良、20%を新機能にせよという話。 自分だけのせいじゃないにしろ、既存機能の改良全然してなくて、それをデキるエンジニアの人からは既存機能育てましょうって話をされてたなぁ・・・。

これももっと早く知っていれば、自分が周りを説得できたかもしれないのに、と感じます。(玉砕した可能性もとても高いですが)

成長エンジン(p.178)

  • 粘着型
  • ウイルス型
  • 支出型

についての説明。参考になりました。具体的にどういうことなのか気になるなら本を買って読めばいいと思いますよ!

フリーミアムの課題(p.205)

数年前、「FREE」が出版されて流行って、フリーミアムフリーミアムみんな言ってましたがこれはその課題(否定と言っても過言ではないかも)が書いてあってすごい。

ユニットテストよりも機能テスト(p.213)

テストカバレッジじゃなく機能テストを実現するテスト書けという話。 RSpecだけ書いてればいいんだよ、じゃないんだよってことがあってこれもすまぬ(ヽ´ω`)

さらに以下のところで最近やらかしたので

アクティベーションの流れから始める

▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああああああ

まとめ

ちょこっとエンジニアリングの話書いてますが、基本はスタートアップの話です。

  • ベンチャーで働いてる
  • 社内ベンチャー的なことやってる
  • 起業考えてる
  • エンジニアだけど自分もWebサービスで一儲けしたい

って人は読むといいんじゃないでしょうか。 エンタープライズ的な環境で閉塞的でつらい、という人はむしろ上層部にいかにして読ませるか、というのを考えるといいんじゃないでしょうか。

 

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)