前回は、MVP で最初から削るべき機能の話を書きました。今回はその続きです。機能を削っても、なぜか公開が遅い人がいます。実際、MVP を作るところまでは進むのに、リリースだけがやたら遠い。これは珍しくありません。
その原因は、コードが遅いからではないことが多いです。むしろ多いのは、公開の直前で判断が増えすぎていることです。文言をどうするか、導線を足すか、デザインをもう少し触るか、設定画面を要るか、説明文を変えるか。こういう小さい判断が連続すると、MVP からリリースまでの距離は一気に伸びます。
MVP からリリースまでを劇的に早くする方法は、実装を速くすることではなく、公開までに必要な判断を減らすことです。
この記事の要点
- リリースを遅らせる最大要因は、実装速度より公開直前の判断の多さです。
- 最初に公開条件を一行で決めるだけで、今やるべき作業と後回しにする作業が切りやすくなります。
- 一本道の体験、毎日の通し確認、追加仕様を別メモへ逃がす運用が、公開速度を大きく上げます。
- デプロイや運用は賢くしすぎず、まずは怖くなく公開できる形を持つ方が強いです。
最初に「公開の定義」を一行で決める
まず強いのは、公開の定義を最初に決めることです。たとえば「この一つのユーザーフローが最後まで通ったら出す」「この画面からこの結果が得られたら出す」と決める。ここが曖昧だと、作りながら公開ラインがどんどん後ろに下がります。
逆に、公開条件が一行で言えるだけでかなり速くなります。なぜなら、今やっている作業がリリースに必要かどうかを、その場で切れるからです。公開の定義がない人は、完成度で判断します。公開の定義がある人は、条件で判断します。この差は大きいです。
リリース用の一本道を一つだけ作る
MVP の段階で必要なのは、すべてのケースに対応した綺麗な設計より、一本道の体験です。一人のユーザーが来て、何をして、どこで価値を感じるか。その一本が通るだけで、かなり十分です。
ここでやりがちなのが、分岐を増やすことです。ログインありとなし、無料と有料、PC とスマホで別体験、複数の開始導線。こういう分岐は、リリースを遅らせる代表格です。最初は一番強い入り口を一つだけ通した方がいいです。
「あとで足すもの」を別のメモへ逃がす
リリースが遅い人は、思いついた改善をそのまま今の開発へ混ぜてしまいます。これがかなり危ないです。改善は正しそうに見えるので、足す言い訳が無限に出ます。でもその瞬間、MVP は終わりません。
だから、追加したくなったものは別のメモに逃がした方がいいです。今やることと、出した後に考えることを分ける。たったこれだけで、進み方がかなり変わります。リリースが速い人は、思いつきを捨てるのではなく、今の列車に乗せないだけです。
「動く」ではなく「公開できる」を先に作る
実装が終わっても公開できないのは、公開に必要なものを後回しにしているからです。タイトル、説明、最低限の導線、エラー時の見え方、問い合わせ先、公開 URL。こういうものはコードの本筋ではないので、後ろへ押しやすいです。
でも、MVP からリリースまでを短くしたいなら、公開に必要な外側も先に持った方がいいです。アプリ本体だけ作って、最後に公開準備を積むと、心理的にも作業的にも重くなります。最初から「出す器」ごと作る方が、結果として速いです。
自分で最後まで使うテストを毎日やる
リリース直前で止まる理由の一つは、自分で最後まで通していないからです。部分的には動く。でも、最初の画面から最後の結果まで一気に触ると、細かい詰まりが出る。これが積み重なると、公開直前で大量の修正が出ます。
だから、毎日一回でいいので、最初から最後まで自分で使うべきです。これは QA というより、公開の距離を測る作業です。一本道が毎日通っていれば、リリースは近い。毎日通らないなら、まだ遠い。この感覚があるだけで、優先順位はかなり正しくなります。
デプロイを賢くしすぎない
公開が遅い原因は、アプリ側だけではありません。デプロイの仕組みを凝りすぎると、それ自体が別プロジェクトになります。リリースを早くしたい段階では、運用の美しさより、出せる確実さの方が大事です。
一回で同じ形に出せる、戻せる、最低限確認できる。この三つがあれば十分なことは多いです。リリース初期に必要なのは華麗なパイプラインではなく、怖くなく公開できる流れです。公開を重くしているのがプロダクトなのか、運用なのかは早めに切り分けた方がいいです。
締切を「状態」ではなく「日付」で持つ
完成したら出す、はだいたい出ません。完成の定義が揺れるからです。なので、MVP からリリースを早くしたいなら、出す日を先に置いた方がいいです。もちろん雑に壊れたものを出す意味ではありません。ただ、日付があると「この日までに公開条件を満たす」という考え方になります。
状態で締めると、永遠に改善できます。日付で締めると、何を切るかが決まります。ここでも必要なのは根性より判断です。劇的に早くなる人は、頑張る人というより、締切に合わせて迷いを削れる人です。
結局、最速で出せる人は「公開のための判断」が速い
MVP からリリースまでを早くする劇的な方法は、特殊な技術ではありません。公開条件を先に決める。一本道を一つ作る。追加仕様は別メモへ逃がす。公開に必要な外側を先に持つ。毎日最後まで自分で使う。デプロイを凝りすぎない。締切を日付で持つ。この積み重ねです。
前回の「何を削るか」は、MVP を軽くする話でした。今回は、その軽くしたものをちゃんと世に出す話です。個人開発で一番もったいないのは、作れなかったことより、出せたはずなのに出なかったことだと思っています。リリースを速くするというのは、開発速度の話というより、公開の意思決定を前に進める技術です。
よくある質問
MVPを作ったのにリリースが遅くなるのはなぜですか？
実装より、公開直前に判断が増えすぎるからです。文言、導線、見た目、追加機能などの細かい迷いが積み重なると、MVPからリリースまでの距離が急に伸びます。
公開条件はどう決めるのがいいですか？
一つのユーザーフローが最後まで通る、ある画面からある結果が得られる、のように一行で言える条件にするのが強いです。完成度ではなく条件で判断できるようになります。
デプロイはどこまで作り込むべきですか？
最初は一回で同じ形に出せる、戻せる、最低限確認できる、の三つがあれば十分なことが多いです。リリース初期は運用の美しさより、怖くなく公開できる確実さの方が重要です。