🌙 1人のために、夜中にバグを直した

エッセイを書きます。 深夜1時を少し回ったころ、コーヒーを淹れるのも忘れてMacの画面を見つめていました。 開いていたのは、アプリのクラッシュレポートです。毎週月曜の朝に確認する習慣がついていたのですが、その夜はなんとなく気になって、日曜の深夜に覗いてしまいました。 数字は小さかった。一週間で7件のクラッシュ。規模の大きいサービスなら誤差の範囲でしょう。でも、じっと見ていると何か引っかかるものがありました。

ひとりの人が、毎日困っていた

数字の奥にある生活

7件のうち6件が、同じ端末から来ていました。機種名と、クラッシュした時刻。早朝6時台に2回、昼の12時台に1回、夜の22時台に3回——

誰かが毎日、このアプリを使おうとして。毎日、落としていた。

クラッシュが起きていたのは、メモの一覧画面から特定の操作を経て開く「まとめ画面」でした。ひとつひとつのログをたどると、同じ導線、同じ操作、同じ瞬間に落ちていることがわかりました。再現性のある、確かなバグです。

Before：修正前の状態

その端末からのクラッシュは、過去10日間で合計6回でした。単純計算で1日0.6回、ほぼ毎日アプリが落ちていた計算になります。しかもその方はそれでも諦めずに、翌日も翌々日もアプリを開き続けてくれていた。

そのことに気づいたとき、申し訳なさと、なぜかありがたさが同時に来ました。

なぜ気づかなかったのか

テストが「普通のユーザー」しか想定していなかった

恥ずかしい話をします。

このバグが生まれた原因は、実装のミスではなく、確認の想像力の貧しさでした。まとめ画面は「過去30日分のデータが存在する」という前提で画面を描いていて、データが空のときの処理を書いていなかったのです。

開発中、わたしは自分でたくさんのメモを入力した状態で動作確認をしていました。当然、「データが一件もない」という状態を一度もテストしていなかった。手元では一切再現しない。ログがなければ何年も気づかなかったかもしれません。

「誰か」ではなく「この人」

クラッシュレポートというのは、ふつう「ユーザー」という抽象的な集合体への情報として届きます。「何人がどこで落ちた」という統計として処理しがちです。

でもその夜は違う見え方がしました。6件という数字が、毎朝6時に起きてアプリを開き、昼休みに使い、夜も続けてくれている——そのひとりの生活リズムと重なって見えた。その人はきっと、何か目標があってこのアプリを使っている。それが毎日クラッシュで阻まれていた。

居ても立ってもいられなくて、そのままコードを開きました。

夜中に直した

問題は意外とシンプルだった

直し方そのものはシンプルでした。データが空のとき、「まだ記録がありません」というメッセージを表示する画面を挟むだけ。変更の規模としては、画面ひとつ分の追加です。

ただ、確認作業には時間をかけました。「データが0件」「1件だけ」「30件ちょうど」「31件以上」——それぞれの状態でアプリを動かして、崩れていないか確かめました。今度こそ、普通じゃない状態を想像しながら。

自分への戒めとして、この確認パターンはメモに残しました。「まとめ画面を触ったら：空・1件・境界値・超過の4状態を必ず確認する」という、一種のチェックリストです。次に同じ見落としをしないために。

ビルドが通って、審査を申請したのが深夜2時半でした。

After：修正後の数字

翌週のクラッシュレポートを確認すると、その端末からのクラッシュはゼロになっていました。

たった7件が0件になっただけです。でもその「0」には、毎日アプリを開いてくれていたひとりの人が、今週は一度も落とさずに使えたという意味がありました。

誰にも言わなかった

リリースノートには「軽微な不具合の修正」とだけ書きました。

「特定の状況でクラッシュしていた問題を修正しました。毎日使い続けてくれていたあなたのために直しました」とは書きませんでした。書けないし、書かなくていいとも思った。

大規模なサービスでは、7件のクラッシュはおそらく「低優先度」に分類されます。週次のインシデントレポートに数行で載り、担当者がアサインされて、四半期の計画に入るかどうか議論される。修正されるまでに数週間、場合によっては数ヶ月かかることもある。

個人開発では違います。

その夜、わたしはひとりのユーザーを確認して、ひとりのために直して、誰にも言わずにリリースしました。プロセスも、優先度の会議も、チケットも必要なく。それは大きなサービスには構造上できないことで、個人開発だからこそできることでした。

全員を「個人」として扱えること

ユーザーが少ないことの意味

ユーザーが少ないことを「スケールしていない」と恥ずかしく思っていた時期がありました。数百人しか使っていないアプリを、万単位のユーザーを持つサービスと比べて落ち込んでいた。正直に言うと、あります。

でも今は違う見え方をしています。

数百人だからこそ、クラッシュレポートの向こうに人が見える。数百人だからこそ、毎朝6時に起きてアプリを開いてくれている誰かのために、その夜のうちに直せる。全員を「ユーザー」という単位ではなく「個人」として扱える——それは、個人開発にしかできない関わり方です。

大きくなればなるほど失われていくものを、わたしたちはまだ持っています。

ログを見る目が変わった

あの夜から、クラッシュレポートの確認の仕方が変わりました。

「件数の合計」より先に「端末の重複」を見るようにしました。同じ端末から複数回来ているとき、それは「繰り返し困っているひとりがいる」というサインです。そこを起点に読む。件数が少なくても、重複があれば深夜でも開きます。

週一だった確認を週二にしました。数字が小さくても、見る目を変えれば見えてくるものがある。というか、小さいからこそ見えるものがある——あの夜にそう気づいたからです。

朝、気持ちよく仕事ができた

深夜2時半にリリース申請を終えて、そのままソファで寝てしまいました。

翌朝、目が覚めて最初に確認したのは審査ステータスではなく、クラッシュログでした。昨日確認したばかりなのに。その端末から新しいクラッシュは来ていませんでした。審査はまだ通過していなかったけれど、それでも少しすっきりした気持ちで、その日の作業を始めることができました。

個人開発をしているみなさんには、きっとわかってもらえると思います。あのすっきり感——誰も褒めてくれないし、誰も気づかないけれど、自分が正しいと思うことをちゃんとやった朝の、あの感覚。それだけで、また作り続けられる気がします。

うまくいかない日も、全然使ってもらえない週も、あります。でも今夜、誰かがアプリを開いたとき、落ちない。それが今のわたしにできる、一番具体的な誠意です。

あなたのアプリにも、今夜開いてくれているひとりがいると思います。小さなログを、少しだけ丁寧に見てみてください。

Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています

• 制作物・記事は bokuwalily.com にまとめています🖥️

• OSS: github.com/bokuwalily 🐙

• 最新情報・お問い合わせは X @bokuwalily へ🌍

🎁 最後まで読んでくれたあなたへ、無料の特典があります: LINEで「自動化」と送って受け取る（実装テンプレ7本）

Lily（@bokuwalily）― 個人開発者 / AI導入・業務自動化のコンサルタント。AIと二人三脚でiOSアプリやWebサービスを作りながら、企業のAI導入と自動化の相談を受けています
🖥️ 制作物・記事 → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 最新情報・お問い合わせ → X @bokuwalily