スタートアップのプロダクトにプロトタイプ開発は採用してはいけない

別の記事で、業務システムはプロトタイピングと特に相性がいいという話をしました。この相性の良さは、業務システムの不確実性が「既に組織の中に答えが存在する知識を、どれだけ正確に引き出せるか」という種類のものだったからです。スタートアップのプロダクト開発は、この前提がそもそも成立しません。プロトタイプ開発という開発モデルをそのまま持ち込むと、むしろ足かせになります。

不確実性の種類がまったく違う

業務システムの不確実性は「既知のステークホルダーが持つ既知の業務ルールを、正確に聞き出せるか」でした。スタートアップのプロダクト開発における不確実性は、これとは種類が異なります。「この機能をユーザーは本当に使うのか」「そもそもこの課題にお金を払う人はいるのか」という、開発チームの中にも、想定しているユーザーの中にも、まだ答えが存在しない不確実性です。

答えが組織の中に既に存在する業務システムでは、動くプロトタイプを見せて「それは違う、実際はこうだ」という正確な指摘を引き出せます。しかしプロダクトの初期段階でターゲットユーザーに動くプロトタイプを見せても、「良さそうですね」という反応は返ってきても、それが本当に使われるか・お金を払ってでも欲しいと思われるかまでは分かりません。プロトタイピングが得意とする「動くものを見せて正確なフィードバックを引き出す」という強みが、答えを持つ人がまだ存在しない領域では発動しないのです。

プロトタイプ開発という開発モデルは「ドメインの安定」を前提にしている

プロトタイプ開発という開発モデルは、プロトタイピングで固めた上流工程の理解を土台に、そのまま製造フェーズに移行して本番システムを組み上げていくことを前提にしています。この前提が機能するのは、上流工程で固めたドメインモデル・業務フロー・画面構成が、その後大きく覆らないという見込みが立つ場合です。業務システムでは、既知の業務ルールを土台にしているため、この見込みは比較的立てやすくなります。

一方スタートアップのプロダクトでは、ユーザーの反応次第でドメインモデルそのもの——「何を管理する対象とするか」「誰と誰の関係をどうデータ化するか」——が丸ごと覆ることが普通に起こります。プロトタイプ開発という開発モデルの上に本番相当の実装を積み上げてしまうと、ドメインモデルを土台から作り直すピボットのたびに、積み上げた実装が重荷になります。開発モデルとしての前提そのものが、スタートアップの実情と噛み合っていません。

積み上げた実装が、方向転換の抵抗になる

プロトタイプ開発は、上流工程で作ったプロトタイプの実装をそのまま製造フェーズに引き継ぐことを狙いとしています。業務システムであればこの引き継ぎは効率化につながりますが、スタートアップの初期段階でこれをやってしまうと、「せっかくここまで作ったのだから」という心理的な抵抗が、本来必要な方針転換の判断を鈍らせるリスクがあります。初期段階で必要なのは、仮説が外れたときに実装ごと丸ごと捨てられる身軽さであり、実装を育てて残していく前提の開発モデルとは方向性が逆です。

では何を使うべきか

スタートアップの初期段階で仮説を検証したいなら、実装を残さない・育てない前提の手法の方が向いています。ランディングページで需要の有無だけを見る、実際にはシステムを裏で動かさず人力で処理する「コンシェルジュMVP」で運用を検証する、ノーコードツールで数日だけ動く検証用の画面を作って壊す前提で使う、といった手法です。これらはいずれも「検証が終わったら実装ごと消える」ことを前提にしており、プロトタイプ開発が前提とする「実装を製造フェーズに引き継ぐ」こととは逆の設計思想を持っています。

まとめ

プロトタイプ開発という開発モデルが業務システムで有効なのは、既知のステークホルダーが持つ既知の業務ルールを土台にでき、上流工程で固めた理解がその後大きく覆らない見込みが立つからです。スタートアップのプロダクト開発は、答えがまだ誰の中にも存在しない不確実性を扱っており、この前提が成立しません。それどころか、プロトタイプ開発が持つ「実装を製造フェーズに引き継ぐ」という性質が、ピボットに必要な身軽さを奪う足かせになります。向き不向きを見極めず、業務システムで有効だった開発モデルをそのままスタートアップのプロダクトに持ち込むことは避けるべきです。