リーンスタートアップを読んで その2

最近読んでいるリーンスタートアップの備忘録

内容

舵取り

始動

スタートアップの事業計画は仮説に基いており、その検証を行うことが立ち上げ時の目標となる。 「評価尺度の実体は人である」と言われているように、実際の顧客にあってその仮説が正しいか確認してくことが重要である。と述べている。

構築・検証

リーンスタートアップでMVPと呼ばれる、仮説を検証できる実用最小限の製品を構築して、実際に見込み客のフィードバックを得るべきだと述べている。

現職のゲーム開発では、このへんの取り組みが出来ていないなと感じた。
簡単なモックを作って、ユーザーテストをして。といったサイクルは出来ないわけではないのに。。
これはチーム内でも、会社内の公開を通してでも良いので、
作ろうとしているゲームが本当に面白いのかを、本開発の前にきちんと確認しないといけないと感じた。
(α開発は1ヶ月くらいで出来るけど、本開発は4ヶ月くらいかかってしまうから。)
フラッシュエンジニアとプロデューサーだけでこの試行は出来る気がする。

計測

一般的な管理会計では、スタートアップを正当に評価できないので、行動につながる評価基準を持ち、広告などによってつくるのことの出来る虚栄の評価基準を見て判断してはいけない。
評価の尺度はコホート型にし、新機能の投入はスプリットテスト(A/Bテスト)で確認することで、顧客が本当に望んでいるのは何であるのか学習するサイクルにすることを提案している。
また1つの開発は検証による学びを得られてはじめて完結だと考えることが重要だと述べている。

以前海外向けのゲームプロダクトを運営していた時、とにかくチュートリアルの突破率が高く、A/Bテストを軸に導線や遷移改善を繰り返し行なったことを思い出した。
「スマホのファーストビューに押して欲しいボタンが入っているか」「このページは無くせるのではないか」１つ１つは単純でちいさな仮説であったけど、結果としてチュートリアルの突破率を10%以上高めることができた。 これはまさに必要なことだったと再認識しました。

この辺は実際に運用や開発をしているからわかるけど、そもそも仕組み化しないと計測のコストがいちいち掛かるので、 機能のA/Bの出し分け -> 計測 -> グラフ化 までを自動で出来るようになっていると良いなと思った。

方向転換

事例を踏まえて、スタートアップの方向性を変更するか、辛抱するかの判断について述べている。

この辺りは、スタートアップにチャレンジしたことが無いのでわからないが、
恐らく実際にこの状況になったときに方向転換できるのか、また辛抱するのかの決断を冷静に勇気を持って行えるかが重要だと思う。

まとめ

自分のプロダクト運営の経験の中でも実感として分かる部分と、参考にしなければいけない部分があり、 非常に重要な章だなと思いました。
仕事を続けていく上で、繰り返し読み返したいと思います。