arsro.net

「リーン・スタートアップ」を読み返した。


久々に読み返した。前回読み返した時と比べると見えてる世界が全然違うので、また得たものがありました。

キーワードは、バッチサイズ。

定量的な目標があったから定性的な調査をしようという話になったのだし、また、どういう質問をするのかも決められたわけだ。

オフィスを出て顧客に会おう。みたいな話はあるけど、定性的な調査を行うためには定量的な目標があることが前提ということかなー。

我々の努力のうち価値を生みだしているのはどの部分で無駄なのはどの部分なのかということだ。 リーン生産方式の中核にはこの問いがある。

脳内ではわかってるところだけど、自戒を込めて。

リーンな考え方における価値とは顧客にとってのメリットを提供するものを指し、それ以外はすべて無駄だと考える。 製造業に関して言えば、製品がどのように組みたてられているのかは顧客にとって意味がない。 顧客が気にするのは製品がきちんと動いてくれるかどうかだけだからだ。 ところがスタートアップの場合、顧客が誰なのかもわからなければその顧客が何に価値を見いだすのかもわからない。 スタートアップというのは、その定義から、このような不確実性を必ず持つものなのだ。 だからスタートアップの場合、価値の定義自体を見直す必要がある。 つまり、何が顧客にとっての価値を生みだすのかについて最初の数カ月間で学んだこと──それこそがIMVUにおける前進の実体だったのだ。

なにが顧客にとって価値があるのか?を学ぶ。

これ以外の学びに関連する機能やこの学びに繋がらなかった機能は「全て無駄」くらいのマインドセットでないとついつい機能を盛ってしまう。

IMVUの話をするたび気になるのが、学生がその戦術に目を奪われがちになる点だ。 できの悪いプロトタイプの段階で製品としてリリースする、最初から料金を徴収する、売上目標を低くおさえて結果責任を負えるようにするなどの戦術だ。 いずれも有用なテクニックだがそこが肝ではない。例外が多すぎるのだ。

ありがち。

戦術も重要だけど、リーンスタートアップの根本、戦略がなんなのかを今一度認識する必要がありそう。

問うべきなのは「この製品は作るべきか」であり「このような製品やサービスを中心に持続可能な事業が構築できるか」である。 このような問いに答えるためには、事業計画を体系的に構成要素へと分解し、部分ごとに実験で検証する必要がある。

たしかにプロダクトを0から作るならそういうことが言えるかもしれない。

例えば、機能レベルでも同じことがいえるのか。

「この製品は作るべきか」→「この機能は作るべきか」

「このような製品やサービスを中心に持続可能な事業が構築できるか」→「この機能は持続可能な事業を構築するために必要か」「この機能は持続可能な事業の構成要素になり得るのか」

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「やってみよう」型起業と呼ぶ。 この方針に従うと様子を見ることには必ず成功するが、検証による学びが得られるとはかぎらない。失敗がなければ学びもない。

やってみよう型なので改めて自戒。

企業向け製品なら、他社がまだ持っていない何かを採用するというリスクを取り、競争力を強化したいと思う。 そう思うアーリーアダプターは、逆に完成度が高いと不安になる。 誰にでも使えるレベルに仕上がっているのなら、早く使ってもどれほどのメリットが得られるのかと考えてしまうのだ。 だから、アーリーアダプターが求める以上に機能を増やしたり完成度を高めたりするのは、資源も時間も無駄にする行為となる。

企業向け製品だと、ある程度の完成度を求められそうで、機能をきちんと準備したり、機能の完成度を一定以上高めてからでないとリリースできないと考えてしまいがち。

結局、そのプロダクトでも機能でも、誰が顧客なのかがわからなければ、何が品質なのかもわからないのだから、学びのための最小限のバッチサイズでリリースしないと。

一つひとつのプロセスに要する時間がまったく同じだった場合でも、バッチサイズは小さいほうが効率的になる。 理由はさらに反直感的だ。 もし、折ったニュースレターが封筒に入らなかったらどうなるだろうか。 バッチサイズが大きい場合、作業がかなり進んでからでなければこの失敗に気づけないが、バッチサイズが小さければ、作業を始めると同時に気づく。 封筒に問題があってうまく封ができなかったらどうなるだろうか。 バッチサイズが大きい場合、全部の封筒からニュースレターを取りだし、新しい封筒を用意してそちらに詰め直さなければならない。 バッチサイズが小さければ、作業を始めると同時に気づき、方向修正ができる。

直感に反しすぎて、ついつい忘れがち。

ただこの例はめちゃくちゃわかりやすいので定期的に思い出そう。

自分が新製品担当のプロダクトデザイナーで、新製品のデザインを30種類、制作しなければならない状況にあると想像してほしい。 この場合、自分だけでどこかにこもり、1枚ずつデザインを描き上げていくのがもっとも効率的だろう。 30種類が描き上がったらエンジニアリングチームに引きつぐ。 これは大きなバッチサイズである。

ユーザーに対してのリリースに限らず、小さなバッチサイズでプロダクトマネージャー・デザイナー・エンジニアのやりとりが行われるようにした方が良いのかもしれない。

リーン生産方式では、「プル」という手法で在庫切れの問題を解決する。 ディーラーに修理の車が持ちこまれると、新型カムリのバンパーがひとつ使われる。 こうして在庫に「穴」が空くと、近くのトヨタ部品流通センターへ自動的に信号が送られ、新しいバンパーがひとつ届く。 このとき部品流通センター側に穴が生まれるので、同じように地域の部品再配分センターに信号が送られる。 ここは、サプライヤーが部品を納入する場所だ。 ここからさらにバンパーを製造している工場に信号が送られ、バンパーがひとつ製造・納品される。 理想は、サプライチェーン全体で1個流しになるまでバッチサイズを縮小することだ。 一直線に並んだ各段階が、上流側から必要な部品を引いてくる。 これが有名なトヨタのジャストインタイム方式だ。

必要になるまで準備しない。ということかな?

たしかに部品だと補填が簡単かもしれないけど、例えばデータベースとかは前もって設計とかしてないと逆にスピードを落とす結果となるけど、、、。

2021.01.13 追記:

違う気がしてきた。

必要になるまで準備しないというのは前提で、バッチサイズを最小化することを目指してプル型手法を取り入れてるという話に見えてきた。

データベース設計を前もってやるべきかどうかなどは、どちらかというと投資の話でそれはまた別の話で考えたほうが良さそう。

ジャスト・イン・タイム方式、もう少し詳しく掘ってみたい。

この辺かなー。

全容のわからないメリットを比べなければならないからだ。 だいたい、この手の判断はどうしてもバッチサイズが大きくなる。 だから、教育訓練プログラムは充実したものがあるか全くないかに二極分化する。 完全なプログラムを作ったとき投資が回収できるとわからないかぎり、何もしないのが普通の会社なのだ。 別の進め方としては、「5回のなぜ」を通じて少しずつ投資を行い、プロセスを徐々に進化させていく方法が考えられる。 5回のなぜは、問題が一番大きな症状を直接的に防止することが目的である。 こう呼ばれているのは、「なぜ」を5回くり返して本当のところ何が起きたのか(真因)をあきらかにするものだからだ。

こっちの方が先述のデータベース設計に対して答えてくれそう🤔

よくある話ではあるが、表面的な症状の裏に隠れた原因を見つけること。

それらに対する対策だけでなく、今やるべきかどうかを判定すること。みたいな感じかな。

5回のなぜで順応性の高い組織を作るには、その5つのレベル、それぞれについて比例投資を続ければいい。

5回のなぜで深堀りした原因に対する対策とやるやらは考えたことあったけど、各階層に応じた投資。という感じだと思うけど、これは今まで考えたことなかった。

たしかに最下層の対応は今できないかもしれないけど、1階層目、2階層目とかならできる。みたいな場面もあるので、積極的に検討したい。

#読書

最近のポスト