先日、Rorkで作ったアプリの一つをリリースして3日目の夜、Slackにつないだストアレビュー通知が30件ほど溜まっていました。半分は「とても良いです」のような短い感想で、残りの半分が機能要望と不具合報告が入り混じった内容でした。同じ時間にFirebase Crashlyticsの画面を開くと、レビューには一行も出てきていないのに、ある機種でだけ起動直後に落ちている報告が並んでいて、私は少し手が止まりました。
リリース直後の72時間というのは、個人開発者にとって判断ミスが一番起きやすい時間だと、12年運営してきて感じています。レビューの数だけ見ると要望対応をしたくなるのですが、Crashlyticsの数字を見ると別のものを直すべきだとわかる。Rorkで作れる速度が上がった今、「最初のアップデートに何を入れるか」を間違えると、せっかく集まり始めたユーザーをまとめて失います。今日は、私がリリース後の最初のアップデートで必ず守っている3つの優先順位を、最近のアプリ運営の感覚で書き残しておこうと思います。
優先順位① レビューに書かれないクラッシュを先に直す
最初に向き合うべきは、必ずCrashlyticsの数字です。レビューに書かれた要望ではありません。
これは少し意外に思われるかもしれませんが、本当にアプリを壊しているクラッシュは、レビューにほとんど書かれません。書く前にユーザーがアンインストールしてしまうからです。「使えなかったので削除した」という1行レビューが残れば良いほうで、ほとんどは無言の離脱として記録されます。私が運営しているBeautiful HD Wallpapersでも、過去のリリースでRecyclerViewのIndexOutOfBoundsExceptionが出ていた時期があり、レビューには「重い」「画像が出ない」程度しか書かれていなかったのに、Crashlyticsを見ると同じクラッシュが28日間で50ユーザー以上を巻き込んでいました。
ここで仕込むのは、機能追加ではなく防御的なコードの修正です。Rorkで作ったアプリでもネイティブ実装でも同じで、起動直後に走るパスと、初回ユーザーだけが通るパスは、リリース後にだけ顔を出すバグの巣になります。最初のアップデートには、レビューには一行も出てこないけれど、Crashlyticsのcrash-free usersが99.5%を切るような問題から潰すと決めています。これは派手ではありませんが、無言の離脱を止める一番の薬になります。
具体的なチェック手順は次のような順序で進めるようにしています。
[リリース直後のCrashlytics確認手順]
1. crash-free users が 99.7% を切っていないか
2. ANR が 0.20% を切っていないか
3. 過去24時間で同一スタックトレースが3件以上ないか
4. Android 6.0 / iOS 16 など『古い端末1機種だけ』で発生していないか
5. 起動5秒以内のクラッシュが集中していないかこのうち1つでも引っかかったら、最初のアップデートはそのクラッシュ修正だけにします。レビューに書かれた機能要望は、次のアップデートに回しても誰も困りません。
優先順位② 見える壊れ方を直してから、見えない改善に進む
クラッシュの次に来るのは「機能不全」と「見た目の壊れ」です。ここで一つ判断軸が必要になります。
リリース直後のアプリには、「起動はするのに途中で動かない」「ボタンを押しても反応しない」「画像が表示されない」という、ユーザーから見て明らかに壊れている動きが必ずいくつか残ります。Rorkで素早く作るほど、コーナーケースの動作確認が後回しになりがちで、私もここでよくつまずきます。
このとき、見える壊れ方と見えない改善のどちらを先にやるかは、最初のアップデートでは必ず見える壊れ方を先に処理しています。理由は単純で、ユーザーの信頼は最初の7日で大半が決まるからです。「最初に開いたときに動かなかった」という記憶は、後から内部実装をいくら美しく直しても、簡単には上書きできません。
たとえば、Ukiyo-e Wallpapersを多言語対応でリリースした最初の週に、ある言語のときだけシェアボタンが効かない問題がありました。レビューには一件も書かれていませんでしたが、その言語の国からのリテンションが目に見えて低かったのです。最初のアップデートで内部的なロード処理の最適化と一緒に出そうとしていましたが、結局シェア問題だけを単独で先に出し、最適化は次回に回しました。
ここで私が意識しているのは、「アプリの第一印象を守るための修正」と「将来のために重要な改善」は、混ぜずに出すということです。混ぜると、もし新しい不具合が混入したときに、どちらの修正が原因かを切り分けにくくなります。最初のアップデートは小さく、目に見える壊れ方だけに絞る判断にしています。
優先順位③ レビューに書かれた要望は『信頼の窓』が閉じてから判断する
3つ目が、最初のアップデートで一番悩むレビューの機能要望への対応です。
リリース直後のレビューには、本当にさまざまな要望が並びます。「お気に入り機能がほしい」「ダークモードを足してほしい」「広告が多い」「無料版がほしい」。一見すると、ここで言われたことを順番に対応していけば、ユーザーは喜んでくれそうに見えます。けれど、私が12年やってきて学んだのは、リリース直後の要望の半分は、3週間後には書いた本人も忘れているということです。
リリース直後の数日間というのは、ユーザーがアプリに対してまだ自分の使い方を確立していない時期です。この時期のフィードバックは、思いつきや一般論が混じりやすく、後から振り返ると「本当に欲しかった機能」とずれていることがよくあります。だから、最初のアップデートでレビューの要望に応えるとしても、私は次の問いを通してから対応を決めています。
[要望対応の判断問い]
1. その要望は、複数の異なるユーザーから1週間以内に届いているか
2. それを足すことで、既存のシンプルさを壊さないか
3. 3週間後の自分が振り返ってもこの要望に応える意味があるか
4. AdMobの広告枠を含めた収益設計と矛盾しないか
5. 既存ユーザーへの責任（今動いているアプリの安定性）と両立できるかこのうち2つ以上が「No」になる要望は、最初のアップデートでは見送ります。代わりに、別途返信で「次回以降に検討します」と伝えるだけでも、誠実さは伝わります。Beautiful HD Wallpapersでも、初期の頃にレビューの要望を片端から実装した時期があり、結果としてアプリが膨らみすぎて、本来の壁紙体験が薄まったことがありました。あれから私は、機能を増やすよりも、ある機能を磨くほうが、結果としてレビューの満点率が上がるという感覚を持つようになりました。
Rorkで作るほど、最初のアップデートの設計が問われる
Rorkで作ったアプリは、リリースまでが速いぶん、最初のアップデートの内容が運営の方向性を強く決めます。作る速度ではなく、直す順序が、個人開発の運営姿勢として可視化される瞬間なのだと感じています。
私自身、宮大工だった両祖父の影響もあって、手を動かして直すことは一つの信心のようなものだと小さい頃から思っていました。アプリの最初のアップデートも、私にとっては同じ性質のものです。派手な機能追加よりも、まず壊れているところを丁寧に直し、見える壊れ方を先に整え、ユーザーの声を急がず深く聞く。この順序を守れるかどうかが、5年後もそのアプリを愛していられるかどうかにつながると、累計5,000万ダウンロードのアプリ事業を運営してきた中で感じています。
Rork以前の時代は、リリース後にゆっくり直す時間がありました。アプリストアの審査も今より長く、ユーザー数の伸び方も穏やかだったからです。Rork以後の時代は、リリースから72時間で評価がほぼ決まるようなテンポになってきています。だからこそ最初のアップデートをどう仕込むかは、Rorkで作る速度を上げる前に、各人が自分の中で言語化しておく価値のあるテーマだと思っています。
リリース後の運営をもう少し体系的に考えてみたい方は、Rorkで作ったアプリの最初の100ダウンロードをどう取るか — 個人開発で実践した小さな施策の記録や、Rorkで『今すぐ作りたいもの』が多すぎる人へ — 12年で多くのアプリ案を諦めてきた個人開発者の判断軸も、合わせて読んでいただけると、私の今の運営感覚がもう少し伝わるかもしれません。
静かに、けれど確かに直す
リリース直後の72時間は、レビューの数字や星の動きに引きずられやすい時間です。私自身も、夜中にレビューを開いて気持ちが揺れることが今でもあります。それでも、Crashlyticsの数字とレビューの要望を並べたとき、私は静かにCrashlyticsの方を選ぶようにしています。無言の離脱を止めるほうが、声の大きな要望に応えるよりも、長くアプリを使ってもらうことにつながる、というのが12年やってきた感覚です。
Rorkでアプリを世に出すことは、個人開発者にとって以前よりずっと身近になりました。だからこそ、出した後にどう直していくかという運営の姿勢が、これからの個人開発の差になっていくのだと思います。最初のアップデートで何を入れるかは、その人がこの先アプリとどう付き合っていきたいかの宣言のようなものだと、私は感じています。同じようにリリース直後で揺れている方の、判断の何かのヒントになれば嬉しいです。