🐛 バグを残したままリリースした日

リリース前日の夜11時過ぎ、わたしはターミナルの出力をじっと見つめていました。 流れるログの末尾に、小さく一行だけ残っていた文字を見たとき、思わず声が出そうになりました。exit 124——タイムアウトによる強制終了のコード。毎朝自動でSNSへ投稿するスクリプトが、ときどき黙って死んでいたのです。 「致命的ではない」と自分に言い聞かせました。4回に1回ほどしか起きないし、動くときはきちんと動く。でも確かに「壊れている」。それを知りながら、翌朝わたしはリリースボタンを押しました。このエッセイは、その判断のこと、そしてその後に起きたことの正直な記録です。

バグを見つけた夜のこと

その日、ようやく仕上がった自動化ツールの最終テストをしていました。個人で運用しているブランドアカウントへのSNS投稿をスケジュール管理してくれるスクリプトで、2週間かけて少しずつ形にしてきたものです。

テスト実行のログを眺めていたとき、見慣れない数字が目に入りました。exit 124。Linuxでこの終了コードが出るのはタイムアウト——決められた時間内に処理が終わらず、OSに強制終了させられたとき。確認してみると、投稿処理のタイムアウト設定が実際の処理時間に対してギリギリすぎたのです。

数字で見えた現状

後になってちゃんと計測してわかったことですが、前夜の時点ではざっくりとした感覚しかありませんでした。処理の平均所要時間は約150秒、タイムアウトの設定値は180秒。余裕が30秒しかなく、APIのレスポンスが少し遅れただけで即アウトになっていました。

Before：成功率 約75%（10回中7〜8回は完走） After（修正前のまま1週間運用）：成功率 約40%（環境の変化でタイミングが悪化）

ただし、この数字を把握したのはリリース後のことです。前夜の時点では「4回に1回くらい」と目分量で感じていただけで、きちんと計測してはいませんでした。これが後に悔いを残すことになります。

「直すか、出すか」の30分

バグを確認してから30分、わたしはその場で考え続けました。

修正するなら、タイムアウト値を増やすだけでは根本解決になりません。処理が遅い原因を特定して、リトライの仕組みを組み直して、再テストして——少なく見積もっても丸1日かかります。すでに夜の11時。翌日には「公開します」と宣言してしまっていました。

「直してから出す」を選べば、約束を破ることになる。「このまま出す」を選べば、壊れたものを渡すことになる。どちらも正解ではない選択肢が、ふたつ並んでいました。

わたしが「出す」を選んだ理由

最終的に出すことにしたのは、理屈というより感覚に近い判断でした。

このバグは「動かない」ではなく「ときどき動かない」。完全に壊れているわけではない。そして、出さないことで失うもの——試してもらえる機会、フィードバックをもらえる時間、自分のモチベーション——のほうが、バグひとつより大きいと思った。

もうひとつ正直に言うと、「完璧にしてから」を続けると、永遠に出せないことをこれまでの経験で知っていたからです。

完璧を待っていたら、出せなかった

個人開発を始めて以来、何度同じことを繰り返したかわかりません。「もう少し整えたら」「あの機能をつけてから」「ちゃんとテストしたら」——そうやって引き延ばしたまま、お蔵入りになったものがいくつもあります。

完璧なものを出したいという気持ちは本物です。でも、完璧とリリースは、たいていの場合、両立しない。特に個人開発では、時間も体力も有限で、「完璧」のハードルは自分で上げ続けてしまう。

今回のバグも、直せる自信はありました。ただ、「今夜」ではなかった。そして「今夜じゃないなら、いつ直すか」を考えたとき、出してからのほうが現実的だと思いました。使われていないものを直しても、誰にも届かない。

出した後に起きたこと——失敗と立て直し

リリースの翌週、状況は悪化しました。

最初は「4回に1回」の失敗だったはずが、気づけば10回中6回が途中で止まるようになっていました。調べると、APIのレスポンス時間が全体的に遅くなる時間帯があり、もともとギリギリだったタイムアウト設定がその影響をまともに受けていたのです。成功率が40%を切ったとき、さすがにこれは放置できないと判断しました。

緊急パッチと根本修正

その週末、2時間かけてタイムアウト値と処理の順序を見直しました。タイムアウトを180秒から300秒に延ばし、重い処理の前に軽い疎通確認を挟むように順序を組み直しました。設定ファイルの数字を一行変えるだけの地味な変更です。

それだけで、成功率は翌日から95%以上に回復しました。所要時間は2時間。リリース前夜に「丸1日かかる」と思っていた修正が、実際には2時間で終わった。あのときの見積もりは、疲労と焦りで大げさになっていたのだと思います。

バグを残して渡すということ

このエピソードで一番後悔しているのは、バグを残してリリースしたことではありません。計測をせずに「たぶん4回に1回くらい」と感覚だけで判断したことです。

もし前夜にちゃんと10回計測して「成功率75%」と数字で把握できていれば、「出す」という判断は変わらなかったとしても、もう少し速く対処できていたはずです。感覚は大事ですが、数字には敵わないことがある。エンジニア的な話というより、自分の認識をちゃんと疑う、という話だと思っています。

それと、リリース後にこんな一言を添えておけばよかったとも思いました。「まだ完成形ではありません。動かないことがあったら教えてください」——完璧でないものを渡すなら、そのことを正直に伝える誠実さがあれば、受け取った側の印象はずいぶん変わる気がします。不完全を隠すより、不完全を共有するほうが、個人開発者としての信頼につながる気がしています。

完璧じゃなくても、前に進んでいい

バグを残したままリリースした日の記録を書きながら、「あれでよかった」とも「やっぱりまずかった」とも言えない気持ちのままでいます。

ただひとつ確かなことは、出したから修正できた、ということです。お蔵入りにしていたら、そのバグは永遠にそこに存在したまま、誰にも知られず、直されることもなかった。リリースしたから壊れたのではなく、リリースしたから壊れていることがわかって、直せた。

個人開発は、完璧を目指す場所ではなく、動かしながら育てる場所だと、今はそう思っています。

あなたの手の中にある「もう少しで完成」のあれは、今日出してもいいかもしれない。

---

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

• 制作物・記事は bokuwalily.com にまとめています🖥️
• OSS: github.com/bokuwalily 🐙
• 最新情報・お問い合わせは X @bokuwalily へ🌍