リーン・スタートアップ

読むきっかけ

発売されたことは知りつつ、なんだか手付かずになってましたが、「「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - delirious thoughts」を読んで買いました（アフィリエイト経由じゃないけれど）。
id:antipopさんのブログを読んで、なんていうか、今、読んでおかないと！って、感じたからです。

読んでみて

オススメする前に、開発者視点で考えたら、アジャイルサムライとか読んでからで良かった、というのがあります。
小さく、素早く、変化しながら、回す感覚、というのは、強烈な体感を伴うんじゃないかと。そこから、一歩広がる視野があるんじゃないかな？と思います。そのため、アジャイルサムライという一冊があり、リーン・スタートアップを読んでいるというのは、意味があることなのではないかと思います。

リーン・スタートアップを読む前、「リーン」から、「リーンの翼」を思い出しました。「リーン」って何さ？と気になります。リーンとは、トヨタの改善方式に基づく方式・体系の事のようです（リーン生産方式 - Wikipedia）。この辺りも、アジャイル開発みたいに思えてきました。

著者が開発者であったこともあり、アジャイル開発について、言及があります。この点は、アジャイルサムライ読んでてよかった、と直接思う点でした。
ただし、ポイントはアジャイル開発にあるわけじゃなく、実用最低限のプロダクトを作り、リリースし、学びを得ること、に注目しています。

「とりあえず」を辞める。仮説、検証をしない、学びを得られないリリースは、しないというのは、大切なこと。とりあえず、のために、どんな時間の投資をしているのか？考えないといけないですね。

読みながらメモをしていたことを下記においておきます。

価値仮説

サービスが本当に価値を提供できるか、否か

成長仮説

新しい顧客がサービスをどう捉えるか？

MVP

実用最低限で常に問うこと。顧客と我々で評価が違っていないか？
求める学びに直接貢献しない機能やプロセス、労力は全て取り除く

コホート分析

→ユーザーグルーピングしてアクセス解析するとかしていないと、ウェブサービスとか、本当に成長しているのか？わからなくなる。PVや、UUというは、数値として分かりやすいが、本当に大切な数値なのか？

あれこれ

• ユーザーストーリーは、検証による学びをえられて、はじめて完結だと考える
• 行動しやすさ、わかりやすさ、チェックしやすさ

学びの中間目標

意味の無い計画を鉄の規律で実行しているかもしれない状況に着目し、負のスパイラルを防止する

巨大バッチ死のスパイラル

大きな機能リリースをすることがあるけれど、小さくリリースを繰り返すこと。
大きな機能をリリースして、使われませんでした、では、誰もが不幸。

品質

生産を止めなくていいようにするために生産を止める
スピード調整。時間のために、品質を犠牲にしてはいけない。品質問題の見逃しは、のちのちスピードダウンの原因
→アジャイルサムライでも触れられていたけれど、品質を犠牲にするのは無しなんですよね。機能の簡略化はありだけれど、品質は無し。取り違えちゃいけない点ですね（自戒を込めて）

五回のなぜ

五回のなぜと、五回のだれ？
犯人探しをすることに置き換わっていないか？
→事実を掘り下げていくこと。特にトラブルが起きたとき。

上司

部下の仕事の進め方に興味を抱く知識労働マネージャーはいるだろうか？
→管理するのではなく、「仕事の進め方」という共有しているのが気にになった

おすすめ

開発者であってもスタートアップ、新規事業などに関わることはあるし、事業を成長させることは、多くの開発者がすること。
なので、新規事業に関わる人は読むべき一冊。

リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす