AI translation
I was writing an essay. Around just past 1 AM, I was staring at my Mac screen, forgetting even to brew coffee. What was open was an app crash report. I had developed a habit of checking it every Monday morning, but that night, for some reason, I felt curious and peeked at it on Sunday late at night. The numbers were small…
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
I'm writing an essay. It was just past 1 AM when I found myself staring at my Mac screen, forgetting even to brew coffee. What was open was an app crash report. I'd developed a habit of checking it every Monday morning, but that night, for some reason, I felt curious and peeked at it on Sunday late at night. The numbers were small. Seven crashes in a week. For a large-scale service, that would be within the margin of error. But as I stared at it, something nagged at me.
Six out of the seven crashes came from the same device. The device model and the time of the crash. Twice in the early morning around 6 AM, once around noon at 12 PM, three times in the evening around 10 PM——
Someone was trying to use this app every day. And every day, it was crashing.
The crash was occurring on a "summary screen" that opened after a specific operation from the memo list screen. Tracing through each log, I could see the same user flow, the same operation, crashing at the same moment. It was a reproducible, definite bug.
From that device, there had been a total of 6 crashes over the past 10 days. By simple calculation, that's 0.6 times per day—the app was crashing almost every day. And yet, this person didn't give up. They kept opening the app the next day, and the day after that.
When I realized this, I felt both apologetic and, strangely, grateful at the same time.
I'm embarrassed to admit this.
The bug wasn't born from an implementation mistake, but from a lack of imagination in verification. The summary screen was designed with the premise that "data from the past 30 days exists," and I hadn't written the processing for when data was empty.
During development, I tested the functionality with a state where I had entered many memos myself. Naturally, I never tested the state where "there isn't a single piece of data." It never reproduced on my machine. If there had been no logs, I might never have noticed it for years.
Crash reports usually arrive as information about an abstract collective called "users." They tend to be processed as statistics—"how many people crashed where."
But that night, I saw it differently. The number 6 overlapped with the life rhythm of someone who wakes up at 6 AM every morning, opens the app, uses it during lunch break, and continues using it in the evening——. This person must have some goal they're using this app for. And every day, that goal was being blocked by crashes.
I couldn't sit still. I opened the code right then and there.
The fix itself was simple. When data is empty, just insert a screen displaying the message "No records yet." In terms of the scope of changes, it was just adding one screen.
However, I spent time on verification. "0 data," "1 item," "exactly 30 items," "31 or more items"——I ran the app in each state and checked that nothing was broken. This time, I imagined abnormal states.
As a reminder to myself, I left this verification pattern in my notes. "When touching the summary screen: always verify 4 states—empty, 1 item, boundary value, and overflow." A kind of checklist. So I wouldn't make the same oversight again.
The build passed and I submitted it for review at 2:30 AM.
When I checked the crash report the following week, crashes from that device had dropped to zero.
It was just 7 becoming 0. But that "0" meant that the one person who had been opening the app every day was now able to use it without a single crash that week.
In the release notes, I wrote only "Fixed a minor bug."
I didn't write "Fixed a crash that was occurring in specific situations. I fixed it for you, who kept using it every day." I couldn't write that, and I didn't think I should.
In large-scale services, 7 crashes would probably be classified as "low priority." It would appear in a few lines in the weekly incident report, a person would be assigned, and there would be discussion about whether it fits into the quarterly plan. It could take weeks, sometimes months, before it gets fixed.
Individual development is different.
That night, I identified one user, fixed it for that one person, and released it without telling anyone. No process, no priority meetings, no tickets needed. That's something a large service structurally can't do, but something only individual development can do.
There was a time when I felt ashamed of having few users, thinking of it as "not scaling." I was discouraged comparing an app used by only a few hundred people to services with tens of thousands of users. To be honest, I still sometimes feel that way.
But now I see it differently.
Because there are only a few hundred users, I can see a person behind the crash report. Because there are only a few hundred users, I can fix it that very night for someone who wakes up at 6 AM and opens the app every morning. I can treat everyone not as a unit called "users" but as "individuals"——that's a way of engaging that only individual development can do.
The more you grow, the more you lose. But we still have it.
Since that night, the way I check crash reports has changed.
Before looking at the "total number of incidents," I now look at "device duplicates." When the same device appears multiple times, it's a sign that "one person is repeatedly struggling." I start reading from there. Even if the number is small, if there's duplication, I open it even at midnight.
I changed from checking once a week to twice a week. Even if the numbers are small, if you change how you look, you can see things. Or rather, because the numbers are small, you can see things——I realized that night.
After finishing the review submission at 2:30 AM, I fell asleep on the sofa.
The next morning, when I woke up, the first thing I checked wasn't the review status, but the crash logs. Even though I'd just checked yesterday. There were no new crashes from that device. The review hadn't passed yet, but still, I was able to start that day's work with a clear feeling.
I think those of you doing individual development will understand. That clear feeling——no one praises you, no one notices, but you did what you thought was right, and that's the feeling you get the next morning. Just that alone makes me feel like I can keep creating.
There are days when things don't go well, weeks when hardly anyone uses it. But tonight, when someone opens the app, it won't crash. That's the most concrete sincerity I can offer right now.
I think there's someone opening your app tonight too. Try looking at those small logs just a little more carefully.
Lily（@bokuwalily）― Individual developer. Creating iOS apps and web services in tandem with AI.
🎁 A free bonus for you who read to the end: LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― Individual developer / AI adoption and business automation consultant. Creating iOS apps and web services in tandem with AI while consulting on AI adoption and automation for companies.
🖥️ Works and articles → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 Latest information and inquiries → X @bokuwalily
エッセイを書きます。 深夜1時を少し回ったころ、コーヒーを淹れるのも忘れてMacの画面を見つめていました。 開いていたのは、アプリのクラッシュレポートです。毎週月曜の朝に確認する習慣がついていたのですが、その夜はなんとなく気になって、日曜の深夜に覗いてしまいました。 数字は小さかった。一週間で7件のクラッシュ。規模の大きいサービスなら誤差の範囲でしょう。でも、じっと見ていると何か引っかかるものがありました。
7件のうち6件が、同じ端末から来ていました。機種名と、クラッシュした時刻。早朝6時台に2回、昼の12時台に1回、夜の22時台に3回——
誰かが毎日、このアプリを使おうとして。毎日、落としていた。
クラッシュが起きていたのは、メモの一覧画面から特定の操作を経て開く「まとめ画面」でした。ひとつひとつのログをたどると、同じ導線、同じ操作、同じ瞬間に落ちていることがわかりました。再現性のある、確かなバグです。
その端末からのクラッシュは、過去10日間で合計6回でした。単純計算で1日0.6回、ほぼ毎日アプリが落ちていた計算になります。しかもその方はそれでも諦めずに、翌日も翌々日もアプリを開き続けてくれていた。
そのことに気づいたとき、申し訳なさと、なぜかありがたさが同時に来ました。
恥ずかしい話をします。
このバグが生まれた原因は、実装のミスではなく、確認の想像力の貧しさでした。まとめ画面は「過去30日分のデータが存在する」という前提で画面を描いていて、データが空のときの処理を書いていなかったのです。
開発中、わたしは自分でたくさんのメモを入力した状態で動作確認をしていました。当然、「データが一件もない」という状態を一度もテストしていなかった。手元では一切再現しない。ログがなければ何年も気づかなかったかもしれません。
クラッシュレポートというのは、ふつう「ユーザー」という抽象的な集合体への情報として届きます。「何人がどこで落ちた」という統計として処理しがちです。
でもその夜は違う見え方がしました。6件という数字が、毎朝6時に起きてアプリを開き、昼休みに使い、夜も続けてくれている——そのひとりの生活リズムと重なって見えた。その人はきっと、何か目標があってこのアプリを使っている。それが毎日クラッシュで阻まれていた。
居ても立ってもいられなくて、そのままコードを開きました。
直し方そのものはシンプルでした。データが空のとき、「まだ記録がありません」というメッセージを表示する画面を挟むだけ。変更の規模としては、画面ひとつ分の追加です。
ただ、確認作業には時間をかけました。「データが0件」「1件だけ」「30件ちょうど」「31件以上」——それぞれの状態でアプリを動かして、崩れていないか確かめました。今度こそ、普通じゃない状態を想像しながら。
自分への戒めとして、この確認パターンはメモに残しました。「まとめ画面を触ったら：空・1件・境界値・超過の4状態を必ず確認する」という、一種のチェックリストです。次に同じ見落としをしないために。
ビルドが通って、審査を申請したのが深夜2時半でした。
翌週のクラッシュレポートを確認すると、その端末からのクラッシュはゼロになっていました。
たった7件が0件になっただけです。でもその「0」には、毎日アプリを開いてくれていたひとりの人が、今週は一度も落とさずに使えたという意味がありました。
リリースノートには「軽微な不具合の修正」とだけ書きました。
「特定の状況でクラッシュしていた問題を修正しました。毎日使い続けてくれていたあなたのために直しました」とは書きませんでした。書けないし、書かなくていいとも思った。
大規模なサービスでは、7件のクラッシュはおそらく「低優先度」に分類されます。週次のインシデントレポートに数行で載り、担当者がアサインされて、四半期の計画に入るかどうか議論される。修正されるまでに数週間、場合によっては数ヶ月かかることもある。
個人開発では違います。
その夜、わたしはひとりのユーザーを確認して、ひとりのために直して、誰にも言わずにリリースしました。プロセスも、優先度の会議も、チケットも必要なく。それは大きなサービスには構造上できないことで、個人開発だからこそできることでした。
ユーザーが少ないことを「スケールしていない」と恥ずかしく思っていた時期がありました。数百人しか使っていないアプリを、万単位のユーザーを持つサービスと比べて落ち込んでいた。正直に言うと、あります。
でも今は違う見え方をしています。
数百人だからこそ、クラッシュレポートの向こうに人が見える。数百人だからこそ、毎朝6時に起きてアプリを開いてくれている誰かのために、その夜のうちに直せる。全員を「ユーザー」という単位ではなく「個人」として扱える——それは、個人開発にしかできない関わり方です。
大きくなればなるほど失われていくものを、わたしたちはまだ持っています。
あの夜から、クラッシュレポートの確認の仕方が変わりました。
「件数の合計」より先に「端末の重複」を見るようにしました。同じ端末から複数回来ているとき、それは「繰り返し困っているひとりがいる」というサインです。そこを起点に読む。件数が少なくても、重複があれば深夜でも開きます。
週一だった確認を週二にしました。数字が小さくても、見る目を変えれば見えてくるものがある。というか、小さいからこそ見えるものがある——あの夜にそう気づいたからです。
深夜2時半にリリース申請を終えて、そのままソファで寝てしまいました。
翌朝、目が覚めて最初に確認したのは審査ステータスではなく、クラッシュログでした。昨日確認したばかりなのに。その端末から新しいクラッシュは来ていませんでした。審査はまだ通過していなかったけれど、それでも少しすっきりした気持ちで、その日の作業を始めることができました。
個人開発をしているみなさんには、きっとわかってもらえると思います。あのすっきり感——誰も褒めてくれないし、誰も気づかないけれど、自分が正しいと思うことをちゃんとやった朝の、あの感覚。それだけで、また作り続けられる気がします。
うまくいかない日も、全然使ってもらえない週も、あります。でも今夜、誰かがアプリを開いたとき、落ちない。それが今のわたしにできる、一番具体的な誠意です。
あなたのアプリにも、今夜開いてくれているひとりがいると思います。小さなログを、少しだけ丁寧に見てみてください。
Lily（@bokuwalily）― 個人開発者。AIと二人三脚で、iOSアプリやWebサービスを作っています
🎁 最後まで読んでくれたあなたへ、無料の特典があります: LINEで「自動化」と送って受け取る（実装テンプレ7本）
Lily（@bokuwalily）― 個人開発者 / AI導入・業務自動化のコンサルタント。AIと二人三脚でiOSアプリやWebサービスを作りながら、企業のAI導入と自動化の相談を受けています
🖥️ 制作物・記事 → bokuwalily.com
🐙 OSS → github.com/bokuwalily
🌍 最新情報・お問い合わせ → X @bokuwalily
