最も悲しい「Just Ship It」の話（2020）
(kitze.io)- 2018年に始めたサイドプロジェクトは数日でMVPが準備できたものの、公開時期を先延ばしし続けるうちに、2年越しの未リリースプロジェクトになった
- 遅延の中心には「あと1つだけ」という判断の繰り返しがあり、React NativeやExpoまで学ぶ中でプロダクトの範囲が広がった
- 同じ問題を解く競合アプリは遅くバグもあったが、すでにリリースされ、ユーザーとコミュニティを獲得し、毎週改善されていた
- 30日間のトライアル後に競合アプリへ支払いをしたことで、ハードドライブにだけ残っていた自分のアプリは事実上死んだプロダクトになった
- 2024年のアップデートでは、2022年に生産性アプリBenjiを最終的にリリースしたとされており、結論は月並みでも先に出せ、という方向に近い
数日で作ったMVPを2年間出せなかった理由
- 2018年1月1日にアプリ開発を始め、MVPは数日で準備できた
- 0.0.1アルファ版も公開できる状態だったが、そのたびに「機能をあと1つだけ」「画面をあと1つだけ」を理由にリリースを先延ばしした
- 「きちんとしたネイティブモバイルアプリがなければ、人々は使ってくれない」と判断し、React Nativeを学んでさらに数か月を費やすことにした
- その後2年間、Webプラットフォーム、React Native、Expo、GraphQL、技術スタックの悩み、別プロジェクトへの転換、Sizzyのような別アプリのリリース、情熱の喪失と回復が繰り返された
- 結局、開発を止め、そのアプリをリリースするという考えも手放した
同じ問題を解くアプリを見つけた瞬間
- 時間が経って自分でそのアプリを使い続けるうちに、必要な機能が多いことに気づき、再び開発するか代替を探さなければならない状況になった
- 代替アプリのランディングページを見たとき、自分が解こうとしていた問題を誰かがすでに解決したのだという感情が強く押し寄せた
- 以前に自分のアプリの動画を数人に送ったことがあり、その動画が共有されたのではないかと疑うほど、機能と問題意識が似ていると感じた
- しかし競合アプリの存在は彼らの落ち度ではなく、自分があまりにも遅く、しかるべき時期にリリースしなかったからだと受け止めた
完成度よりリリースが先だった競合アプリ
- アカウントを作り、ヘルプセンターの動画を見ながら、実装方法が賢いと感じるたびに、自分が競争相手であることを意識した
- 2年間、自分のアプリは粗く、バグがあり、機能も不足していて誰も使わないだろうと思っていたが、競合アプリを使ってみて、その判断は間違っていたと考えた
- 競合アプリも数年かけて開発されていたが、それでも遅く、バグがあり、あまり磨き込まれていない状態だった
- モバイルアプリは同期に10秒かかるほど良くなかったが、すでにリリースされたプロダクトであり、ユーザーは次のアップデートを待つことができた
- ToDoリストが大きくても、毎週リリースを続けながら、アプリとコミュニティが一緒に成長していた
支払い後に残った教訓
- 30日間のトライアルが終わった後、クレジットカード情報を入力し、単なる購読者ではなくファンになった
- 支払い通知は、自分がリリースできなかったという事実を繰り返し思い出させる体験として残った
- この瞬間、自分のアプリは正式に死んだと受け止めた
- 同じ状況にいる人の多くは、まだプロジェクトを始めて数週間しか経っていないかもしれないので、同じ過ちを避けるべきだ
- 「あと1つだけ」が認証、決済、ボイラープレートを作り直すことなら、それは罠であり、その後その罠を減らすためにZero To Shippedを作った
2024年アップデート：ついにBenjiをリリース
- 2024年のアップデートによると、2022年についにBenjiをリリースした
- リリースした理由は、どの競合アプリも自分のビジョンに十分近くなかったためだ
- 望んでいたアプリは、Todos、Habits、Planner、Goals、Pomodoros、Meal tracking、Fasting、Hydration、Packing、Tripsなどを組み合わせた形だった
- Benjiには、人々が自分の生活を改善しながら成功や達成を共有する公開タイムラインもある
- 月並みに聞こえても、ひと息ついて、それでもJust Ship Itすべきだ
1件のコメント
Hacker News のコメント
こういう「そのときにただリリースしなかったせいで終わった話」には大きな手がかりがある。作っていたアプリの価値が、急げない技術的ディテールにある場合もあり、その場合は「とにかく出す」が答えではない。
ソフトウェアエンジニア／アーキテクトの仕事は、経営陣の「とにかく出せ」という圧力にできるだけ耐えることでもある。自分が直接所有しているプロダクトで、リリースが自分の利益になる状況でないなら、時間をかければより専門的な成果になるのであれば、時間を使うべきだ。JIRA チケットを受け取って、できるだけ早く雑なコードを吐き出す自動機械ではないし、そうやって働き続ければ精神的に消耗し、最終的にはバーンアウトする。
会社の持ち分がないなら、会社の利益を最大化することが自分の仕事なのではなく、履歴書に恥ずかしくなく載せられる良いソフトウェアを作ることが仕事だ。恣意的な締め切りをまた守れたという安堵感は、短期的な負の動機づけにすぎず長続きしないので、上から降ってくる圧力に耐えて、きちんと作るべきだ。解雇されたとしても、最近はどうせ転職が上に行く道なのだから。
ただし、収益性は「とにかく出す」と同義ではない。この2つをしょっちゅう混同する会社なら、経営陣側のシニアリティが不足しているサインだ。
開発者の仕事は「良いソフトウェア」ではなく、良いプロダクトを作ることに近い。良いプロダクトにはたいてい良いソフトウェアが必要だが、常にそうとは限らず、素晴らしいプロダクトの裏にひどいソフトウェアがあることも多い。プロダクト、営業、開発の間の緊張関係は、短期・中期・長期の価値を最大化する妥協につながるべきであり、開発者は何を雑に処理してよいのか、会社にどんな優先順位があるのか、いつ妥協せずに良いソフトウェアを作るべきなのかを理解しなければならない。
ソフトウェア品質で絶対に妥協できない開発者は、本当に妥協してはいけない瞬間にも力を失う。
だから最優先は、ユーザーのために価値を生み、可能な限り効率よく開発することだ。誰も使わないソフトウェアに何の意味があるのか。
開発者の仕事は良いソフトウェアを作ることではなく、ユーザーに価値を届けることだ。キャリアの中で見てきた限りでは、むしろ開発者が過剰設計に酔い、誰も必要としていない機能でコードを膨らませ、まだ来てもいない将来の開発に備えてコードを増やすケースの方が多かった。だから難しい課題はミニマルなままでいることで、原文もその話をしているように思う。
中小規模の会社では間違いなく妥協が必要で、最善のビジネス成果につながる選択をすることも専門家の仕事だ。
多くの開発者は、複数階層のマネージャー、PM、デザイナーに「守られて」いるため、ビジネス側とのつながりが弱い。プロダクトを早く出せば、フィードバックも早く得られ、実装が仮説と合っているか評価する機会も生まれる。プレッシャーの中で「完璧な」解決策をデプロイしてから作り直すより、ストレスは少なかった。
現在の職場で開発者としてしている仕事は、複雑さを減らし、PM・デザイナーに初期計画を最小限まで削ってもらうことだ。そうすれば恣意的な締め切りのストレスも減り、遅延の影響も小さくなる。
価値がある部分は、特定の職場に執着しすぎず、解雇を過度に心配するなという程度だが、その理由づけも間違っていると思う。こうした敵対的な態度の人たちと実際に一緒に働いているかもしれないというのは驚きだ。
ゲーム理論で間違った象限にとどまる人生を好む人もいるようだ。
「自分のアプリの動画を誰がこの人たちに共有したのかと疑った。文字どおり同じ問題を解いていたからだ」という部分を見て、以前、なかなか良いアプリのアイデアを持つ人に会ったことを思い出した。
彼はアプリを無料でコーディングしてほしいと言い、収益を分けようと言った。本人は何を貢献するのかと尋ねると、会社を「運営」するつもりで、50%の取り分は「アイデアを出したから」だと答えた。そこで、6か月の先行期間を与えると言い、それまでに市場に出せなければ自分で作ると伝えた。
3人のうち2人はただ座って形を作り始めたが、3人目は壊れたコードを SVN に上げ、アイデア全体を自分の功績として記した設計文書を作り、会議を招集して、自分がゲームデザイナーであり、私たちが別の場所でゲームを作ったら訴えると言った。実際に貢献していた2人は互いに顔を見合わせ、プロジェクトを畳んだ。彼は手の内をすべて見せてしまい、大した人間ではないことが分かった。
後に Steam で似たアイデアのゲームを見た。彼らが独自に思いついたのならそれでよいし、あの負け犬から盗んだのだとしてもそれでよいし、その人の下で最後まで耐え抜いたのなら、金を受け取る資格がある。
アイデアが本当に良く、信頼できるものだったなら、正直かなり良い提案だった可能性もある。
誰かに「6か月後に君の素晴らしいアイデアを盗む」と言ってもよいと考えるなら、その人が問題を起こしたり、極端には危害を加えたりするタイプではないことを願うしかない。
自分の問題を誰かが代わりに解いてくれるといい。今その問題に取り組んでいる理由は、単に買って使える解決策がないからだ。
誰かが血と汗を流して自分の問題を解き、オンコールと保守まで引き受けてくれるなら喜ばしいことだ。
なぜ必ず自分がこの問題を解かなければならないのか？ なぜ必ず自分の解決策が事業でなければならないのか？ 事業とは、自分と顧客に価値を生み出すことだ。問題そのものに執着しているなら、他の人が多大な努力を払って解いてくれることに感謝すればいいし、顧客に執着していたなら、フィードバックを得るためにずっと前に何かを顧客へ出しているべきだった。
長期的に会社を運営したい人は多くないだろうが、興味深い問題を解いたり扱ったりしたという理由で突然大金を受け取ることを、たいていの人は嫌がらないだろう。
自分のアプリに入れたいアイデアが次々に浮かびましたが、他の開発者たちはそうしたアイデアを実装することに興味がなかったでしょう。コントロールが欲しかったので、最終的に Benji をリリースしました: https://benji.so
原文の著者です。この記事は更新しなければなりません。数年後、この記事が投稿されるたびに付く HN のコメントに、実際に動機づけられました。
人々がいつも「なぜただアプリをリリースしないのか」と言うので、結局リリースしました。
最後までやり遂げられてうれしいですし、このカテゴリーのどの競合製品よりもずっと優れていると思います。
https://benji.so で見られます。ランディングページはまだ作業中です。
私のアプリにも、習慣の動機づけ、目標遵守の測定、タスクのスケジューリングと再スケジューリングをつなぐという似た目標がありました。何年も作業し、いつかブートストラップ企業にするという考えが、自分のアイデンティティにかなり結びついていました。
プロジェクトを手放す決断はいくつもの段階を経て訪れましたが、大きな締めくくりのきっかけの一つは、長期的にアプリ開発者として生きたいわけではないと気づいたことでした。手放すのは難しかったものの、今はその決断に満足しています。原文のように後で復活することもあるので「完全に消えるものはない」とも言えますが、この特定のプロジェクトに戻ることはなさそうです。
ほとんどの生産性アプリが抱える「高い認知負荷」を乗り越えるための中核的なアイデアの一つが、生活モジュールのマーケットプレイスでした。たとえばフィットネスインフルエンサーがワークアウトルーティン、食事プラン、ジャーナルテンプレートをまとめて販売し、ユーザーがそれを自分の生活に「インストール」する、といった形です。
大規模言語モデルは、離脱を検知して原因を推定したり、「やらなかった行動」に対応したりすることを、はるかに可能にするでしょう。毎日こつこつ生産性アプリを使うタイプA気質ではない人にとって重要だと思います。
GMT との差は合っていますが、Brussels、Copenhagen、Madrid、Paris はアフリカではないので非常に混乱します。使用しているタイムゾーン情報を確認したほうがよさそうです。
下のコメントを見ると、これは問題ではありませんでした。
それから「競合」の名前を言わなかったことについて、もどかしさと疑念を表明してすみません。今ではご自身のアプリをリリースしたので、その競合製品がまだ存在しているとしても、名前を言う可能性はさらに小さくなったように思います。
自分のシステムの実際のユーザーになってみると、視点が完全に変わります。私も自分のために作っていたものがあり、準備ができておらず、まったく使えないと思っていました。
プロジェクトを諦めた後、実際のユーザーのように使ってみることにしたところ、ユーザーは数多くの小さな問題に慣れていて、自動的に回避策を見つけるのだと気づきました。何かを作った人は、多くの粗さが失格理由ではなく、ユーザーがさまざまな不足を大きな労力なしに避けていくという事実を忘れがちです。その地点で、完璧の追求は自尊心に近くなります。
自分が作った人間だという事実をしばらく無視し、一定期間修正も禁止したうえで実際に使ってみることが、すべてを変える可能性があります。
現実的には、実際のユーザーに公開するまで、ユーザーが遭遇する大半の「バグ」は見つかりません。リリースしなければ、ユーザーが実際に影響を受けるバグを直す機会もありません。
そのまま Web ページを直接開いて使い、ユーザー名とパスワードは当然 iCloud で同期されていました。Safari でユーザーフローを再開するのに5秒、完了するのに30秒しかかかりませんでした。
「とにかくリリースしろ」の例としては最良ではない。生産性アプリ、ToDo、習慣トラッカー、支出トラッカー、ジャーナリング、運動計画のようなカテゴリは、多くの人が独立して同じアイデアを思いつくものだ。
支出を記録できるアプリのアイデアを思いついたとき、自分がどれほど賢いと感じたか分からない。そしてPlay Storeを確認した。KRAZAMも5年前の「The Hustle」動画でこれを茶化していた。
新しいバリエーションが成功できないという意味ではない。成功したものの多くは完全に独創的なわけではないからだ。ただ、誰かが先に自分のバージョンを出して勝ってしまうのではと心配しているなら、周囲を一度見回せばいい。
個人的には、「一生懸命おもしろくしようとしている」文体が耐えられない。
読んでいる途中で諦めた。あまりに幼稚で、見ていて気恥ずかしい。
結局、概念実証だけ作って、そこに安住したということだ。残念だが、それが人生だ。彼らは仕事をし、報酬を得た。
学ぶべき点は、アイデアは所有できないということだ。
この意見には全面的に同意する。Kvikletを始めたとき、私たちは3人で、そのうち1人は他の2人よりずっと完璧主義だった。正直、出来の悪かった最初のWebサイト版を公開するだけでも説得がかなり必要で、リポジトリの公開はさらに難しかった。
その「共同創業者」は初期に離れたが、早くリリースして売ろうとしたのは本当に幸いだった。
うまくはいかず、買い手も見つからなかったが、誰かが金を払うかまったく分からないまま、暗闇の中で希望だけにすがって今もプロダクトを作っていたと想像するとぞっとする。
今はバックアッププランとしてオープンソース化し、かなり素敵なユーザーも何人かできた。小さなコミュニティと言ってもよさそうだ: https://github.com/kviklet/kviklet
1年前に望んでいたスタートアップ成功談ではないが、今も期待だけを抱いて現実感のない状態でいるよりはずっといい。オープンソースだからといって、サポートやプレミアム版を売って多少のお金を稼げないわけでもないだろう。今は単に楽しいサイドプロジェクトだ。
mutation、edit、update、modificationのような単語を使うべきだ。queryが技術的には正しくても、語感としては間違っていて混乱を招くように聞こえる。
自分のために何かを作っているなら、誰かが先に作ったからといって悲しくはならない。それはアイデアが良かったという証拠にすぎない。
もちろん、頭の中や紙の上にある多くの個人プロジェクト、さらには実際に少し始めたものですら、販売用にリリースしようとしているわけではない。自分が欲しいもの、あるいは友人や家族、ほかの人が便利だと思いそうなものだ。
アルファ品質程度でもできているなら、公開して、誰かが「アイデアは有用だけど実装はいまいちだな。自分がもっと良く作ろう」と思ってくれることを期待してもいいかもしれない。
そのうえ、最初の参入者だったとしても、すぐに競合が現れて優位性を削っていくだろうし、先行し続ける努力が必要になる。
だから、どうせ常に誰かが先にいて、競争は今であれ後であれ確実に起きるのなら、先取りされることを心配するのではなく、競争優位に集中すればいい。原文の筆者も最終的にはその気づきにたどり着いたようだし、うまくいくことを願っている。