プロダクト開発の文脈ではいつも「速さ」が重要だと言われる。MVP、リーン、アジャイル。どれもスピードを前提にした考え方だ。
確かに、速く動くことが評価される場面は多い。でも、なぜそこまで「速さ」が重要視されるのか。 早く作ること自体に本当に価値があるのだろうか。
Running Leanという本を読んでその問いに一つの答えを見つけた。 問題は「早く作れるか」ではない。「早く学べるか」だったのだ。
#「早く作る」は目的ではない
Running Leanでは、プロダクト開発において「自分たちの考えや仮説はほとんどが間違っている」という前提に立っている。そして最大のリスクは、技術的に作れないことではなく、誰も欲しがらないものを作ってしまうことだと繰り返し述べられている。
だからこそ「早く作れ」と言われる。しかしそれは、アウトプットを増やすためではなく、仮説の答え合わせを早くするためなのだ。
#作ることがゴールになると止まる
プロダクト開発者は、「作ること」自体が目的になりやすい。 とりあえず実装する、リリースした事実に満足する、でも何が分かったのかは説明できない。
この状態ではどれくらい早く作ってもプロダクトは賢くならない。作業量は増えているが、理解は更新されていない。
Running Leanの文脈で言えば、学びに繋がらないBuildはただのコストだ。
#速さの正体は、学習速度
Build → Measure → Learn このループで私が最も重要だと考えるのは、BuildでもMeasureでもない。Learnだ。
プロダクト開発における本当の速さとは、仮説が否定・更新される速さ、次の意思決定が変わるまでの時間、リスクが一つずつ減っていくスピード、だと思う。
実装速度が早くても、判断が変わらなければ前進ではない。学習が加速している状態こそが、速いプロダクト開発だと考える。
#学習が速いプロダクト
Running Leanの考え方を借り、学習が早いプロダクトの共通点を挙げる。
仮説が明確に言語化されている
今、何を検証しているかがチームで共有されている
成功・失敗の基準が事前に決まっている
リリース後に、必ず次の一手が変わる
作るたびに、理解が更新される。だから結果として、迷いが減り、スピードも上がる。
#MVPという誤解
MVPという言葉は、しばしば誤解される。「機能を削った完成品」のように扱われがちだ。 Running LeanにおけるMVPは違う。それは最大の学びを得るための最小の実験だ。
場合によっては、コードを書く必要すらない。ユーザーに話を聞くだけで十分なこともある。逆に、作らなければ分からないことも確かにある。
重要なのは、何を学びたいかだ。
ちなみにタイミーというアプリも、最初は専用アプリを実装せず、LINE上での運用から検証が行われていた。
#まとめ
スピードこそパワーと言われる。でも、プロダクト開発においてそのパワーとは、実装速度ではない。
どれだけ早く、間違いに気づけるか。どれだけ早く、判断を更新できるか。なのだ。
Running Leanが教えてくれたのは、「早く作れ」ではなく、「早く学べ」というメッセージだった。 プロダクト開発で本当に加速すべきものは、コードではなく、理解なのだと思う。