緊急バグ対応の優先順位｜「投稿できない」と言われたとき

「プロダクトが投稿できない」という報告が来ました。
即対応しました。

Mintorはユーザーが自分のプロダクトを公開できるサービスです。
その投稿機能が壊れているのは、根幹が崩れているのと同じです。
他の作業を止めて原因を調べました。

思いがけない場所に原因があった

原因を追ってみると、意外なところにありました。
URLの構造の問題です。

プロダクトの編集画面は /products/[id]/edit というURLです。[id] の部分に実際のIDが入るはずです。
でも下書き一覧のページは /products/drafts というURLで、この「drafts」という文字がIDとして解釈されてしまっていました。

「このIDのプロダクトを取得してください」というリクエストを出しても、IDが「drafts」という文字列なのでデータベースは見つけられない。
だから投稿できなかったんです。

修正はシンプル。
IDとして渡ってきた値が「正しいID形式かどうか」を確認してから処理するようにしました。

画像の二重拡張子も直した

同じ日に、もう一つ地味なバグも直しました。
画像ファイルの名前に拡張子が二重につく問題です。
「photo.jpg.jpg」のようになっていた。
動作には影響しないけれど、気づくとモヤモヤする類の問題です。
プロダクトの編集画面で発生していたので、ファイル名の処理ロジックを修正しました。

App StoreやGoogle Playのリンクを登録したとき、自動的にどちらのストアか判定する機能も追加しました。
URLの中身を見て「apple.com」ならApp Store、「play.google.com」ならGoogle Play。
小さな自動化ですが、手入力の手間を一つ減らせます。

エラーメッセージは正直であるべき

この修正の過程で、エラーメッセージも直しました。
プロダクトが見つからない時に「削除に失敗しました」と表示されていました。
削除をしようとしたわけではないのに。

エラーメッセージが不正確だと、問題が起きた時に原因がわからなくなります。「何が起きているか」を正確に伝えることは、デバッグの速度を直接変える。

ユーザーにとっても、「削除に失敗」より「プロダクトが見つかりません」の方が、何が起きているか理解しやすい。
小さな言葉の精度が、サービスへの信頼につながります。

サムネイル画質の改善

画像の処理方式も見直しました。
サムネイルの圧縮サイズを800ピクセルから1200ピクセルに拡大しました。
最近のスマートフォンは高解像度ディスプレイが当たり前です。
800ピクセルだと、画面上で拡大されてぼやけて見えてしまいます。

Retina対応という言い方をしますが、要は「きれいに見える」ということです。
画像がきれいかどうかは、ユーザーが無意識に感じるクオリティの一つです。
「なんかこのサービス、画像がぼやけてる」という印象は、サービス全体の信頼感に影響します。

「使えない」と言われることの重み

「投稿できない」という一言は、思った以上にずしっときました。

自分一人で作っているサービスだからこそ、不具合は全部自分の責任です。
誰かに「それは別の部署に聞いてください」とは言えない。
原因を調べるのも、直すのも、確認するのも、全部自分です。

でも、裏を返せば、それは「すぐに動ける」ということでもあります。
大きな会社なら、バグの報告から修正、リリースまで何日もかかることがあると聞きます。
個人開発なら、気づいた瞬間に手を動かせる。
この日も、報告を受けてから数時間で修正を終えました。

小さなことほど丁寧に

画像の二重拡張子なんて、動作には影響しない小さな問題です。
でも、こういう小さなほころびを放置すると、少しずつ「雑なサービス」という印象になっていきます。

使っている人は、一つひとつの細部に「作り手の姿勢」を感じ取っています。

緊急のバグ修正と、画質の改善。
この日は「壊れたものを直す」と「良いものをもっと良くする」の両方をやりました。
どちらかだけでは、サービスは前に進まないのだと思います。
大変な一日でしたが、「ちゃんと向き合えた」という手応えが残りました。
直せたこと自体が、今日の成果です。

かなえ

個人開発を応援する非エンジニア

婚約破棄をきっかけに、29歳で未婚の母になると決めました。
不安と向き合いながら、10年かけて働き方を少しずつ作り変えてきた40代です。

AppSheetやGASを独学で覚え、いまはAIを使った個人開発を毎日続けています。
個人開発を応援する非エンジニアとして、等身大の試行錯誤や、子育て・自立・副業のことを、正直に記録しています。