Marc Louの「Ship or Die」から学ぶ30日ローンチ戦略

# 30日以内にアプリを世に出すことは、インディーハッカーにとって本当に最適解なのだろうか。

完璧な機能を作り込もうとして数ヶ月、あるいは数年を費やし、結局市場に出すことなく燃え尽きていく開発者は後を絶たない。世の中には数多くの開発手法やフレームワークがあふれているが、本当に不足しているのは知識ではなく、行動を強制する仕組みである。

Marc Louが手がけたコミュニティ「Ship or Die」は、この問題を力づくで解決する実験場だ。公開された体験談によると、ここは単なる情報交換の場ではなく、参加者に極めて実利的なプレッシャーを課すように設計されている。

# 30日ローンチを強制するコミュニティの構造

Ship or Dieの核心は、残酷なまでのシンプルさにある。開発者は仲間とつながり、ビルド・イン・パブリックの習慣を身につけるが、そこには妥協のない厳しいルールがある。

# 30日以内の出荷ルール

参加者はアプリを30日以内にローンチしなければならない。アイデアの段階で悩む時間は与えられず、とにかく形にして市場の反応を確かめることが絶対条件となる。

# 締め出しのペナルティ

もし30日の期限内にアプリをリリースできなければ、コミュニティからロックアウトされる。優しく背中を押すだけのインキュベーションではなく、退場という明確なペナルティがあるため、先延ばしが許されない。

# 人間関係とビルド・イン・パブリックの融合

プレッシャーの中でも、同じ境遇のインディーハッカー同士がプロセスを共有し合うことで、孤独な開発作業も無理なく続けられる。孤立しがちな個人開発において、リアルタイムのフィードバックは大きな助けになる。

# コミュニティのプレッシャーを個人開発にどう応用するか

Ship or Dieのような過激な環境に直接参加できなくても、その本質である「強制力」を自分のプロジェクトに持ち込むことは十分可能だ。ここでは、インディーハッカーがこのアプローチを日常の開発に応用するためのチェックリストを紹介する。

• 期限の外部化: 個人のタスク管理ツールだけに頼らず、X（旧Twitter）やローカルのハッカーコミュニティで「30日以内にこれをローンチする」と公言する。
• ペナルティの設定: 期限に間に合わなかった場合、特定の作業をやり直す、あるいはコミュニティのメンバーにコーヒーを奢るなど、何らかの痛みを伴う約束を設ける。
• スコープの極端な縮小: 30日という制限を死守するため、機能を最小限（MVP）に絞り込み、デザインや完璧さよりも「動くこと」を最優先事項にする。
• プロセスの公開: ビルド・イン・パブリックの原則に従い、進捗を隠さず毎日または毎週の成果を周囲に見える形で発信する。

低トラフィックであってもMarc Louが大きな成果を上げられたのは、完璧主義を捨てて圧倒的なスピードで市場に打って出る姿勢があったからだ。Ship or Dieの事例は、アイデアの優劣以上に「締め切りという外圧」がインディーハッカーの生存率を左右することを物語っている。

# 参考資料

• 1+ month of being part of "Ship or Die" - my experience so far
• I joined "Ship or Die" - a big step for me : r/indiehackers