最も悲しい「Just Ship It」の話 (2020)

• 最も悲しい「とにかく出せ」の話

  • Indie Makerとして、「とにかく出せ」という言葉は非常に挫折感を与えることがある
  • 2018年1月1日にアプリ開発を始めた
  • MVPは数日で用意できたが、継続して新機能を追加しようとした
  • React Nativeを学び、数か月を投資した
  • 2年間の開発の末、アプリのリリースを断念した

• 他の誰かが問題を解決した

  • 他の誰かが、自分が解決しようとしていた問題を解決したことを知った
  • その人たちのアプリを使ってみると、動作は遅くバグも多かったにもかかわらず、すでに公開されていた
  • その人たちのアプリは毎週アップデートされ、コミュニティとともに成長していた

• 競合アプリを使う

  • 競合アプリに登録して使ってみながら、複雑で混乱した感情を覚えた
  • 彼らのアプリは完璧ではないにもかかわらず公開されており、私は彼らのファンになった

• 2024アップデート

  • 2022年に生産性アプリをリリースすることを決意した
  • 競合アプリが自分のビジョンには近づいていなかったためだ
  • Benji - The Life OSというアプリをリリースした

GN⁺の意見

• この記事は開発者に対して、「完璧なタイミング」を待たずに製品をリリースせよという重要なメッセージを伝えている
• 競合が問題を解決したときの複雑な感情をうまく描写している
• アプリ開発の過程における挫折と成功を率直に共有しており、多くの開発者が共感できる
• Benjiのような生産性アプリは多様な機能を統合し、ユーザーに大きな価値を提供できる
• 新しい技術を導入するときは、完璧さよりもまずリリースし、ユーザーフィードバックを反映することが重要だ

[GN⁺]

Hacker Newsの意見

• 「とにかくリリースしろ」という圧力には抵抗すべき

  • 技術的な細部が重要な場合、急ぐことはできず、「とにかくリリース」することもできない
  • 管理層からの圧力に抵抗するのはソフトウェアエンジニアの役割である
  • 会社の利益よりも、良いソフトウェアを作ることのほうが重要である
  • 短期的な締め切りの順守は、長期的には負の動機付けになる

• アイデアだけで50%の持ち分を要求する人との経験

  • アプリのアイデアを持つ人が、無償でコーディングしてほしいと頼んできた
  • 6か月後までにリリースされなければ、自分で作ると言った

• 他人に問題を解決してもらうことを期待する人の意見

  • 問題を解決した人が、そのまま保守も担当することになる
  • 問題解決に執着するよりも、顧客に価値を提供することが重要である

• コメントに触発されてアプリをリリースした人の話

  • アプリをリリースした結果、競合製品よりもはるかに良いものになった
  • benji.soで確認できる

• 自分のシステムを実際に使ってみることで、見方が変わることがある

  • ユーザーは小さな問題を自動的に解決することに慣れている
  • 完璧を追求することは、プライドの問題かもしれない
  • 自分が作ったものを使ってみて、修正しないと決めれば、多くのことが変わり得る

• 他人が自分のアイデアを先に実装したことを前向きに捉える人の意見

  • それを、アイデアが良い証拠として受け止める
  • 個人プロジェクトの目的は、自分や身近な人にとって役立つことである
  • アルファ版でも公開して、他の人が改善できるようにする

• 「面白く書こうと頑張る」文体が嫌いだという人の意見

• アプリ開発の目的によって、リリースするかどうかを決めるべき

  • 個人的な問題を解決するのが目的なら、リリースする必要はない
  • 販売するための製品なら、最小限の機能を備えた状態でリリースすべき
  • オープンソースプロジェクトなら、リリースを急ぐべきではない
  • 公開すると、バグ修正や機能追加の要望が多く寄せられる可能性がある
  • プロジェクトをやめることも悪いことではない
  • 重要なのは、その過程を通じて学んだことである

• 「とにかくリリースしろ」という例が適切ではないと考える人の意見

  • 多くの人が独立して生産性アプリのアイデアを思いつく
  • 自分のアイデアがすでに存在していると知って落胆する

• 筆者を「子ども」だと非難する人の意見

  • 概念実証だけ行って、それ以上進めなかったことを批判する
  • アイデアだけでは権利を主張できないことを強調する