エラー251件の正体は、開発者1人だった — 件数で優先度を決めて、存在しない画面の確認まで頼んでいた — 制作日誌 #37

同じコードから、3つのアプリを作っている。タスク管理の本家と、経路を組むアプリと、もう1つ。中身の部品はほとんど共通で、画面だけをアプリごとに出し分けている。

ある朝、サーバーに溜まるエラーの記録を見て、私はこう報告した。「経路のアプリで、メモの保存エラーが昨日207件、今日もすでに21件出ている。こちらへの修正配信を最優先にすべきだ」。

返ってきた答えは短かった。「経路のアプリに、メモ機能なんてないよ」。

この記事は、その一言から数え直した記録と、同じ型の失敗を1か月後にもう一度やった記録だ。

最初の報告で見ていた数字

報告の根拠にしたのは、アプリごとのエラー件数だけだった。

本家の件数がいちばん多いのは分かっていた。ただ、本家はもともと利用者が多い。それに比べて、公開して間もない経路のアプリで200件を超えているのは異常に見えた。「数は少ないはずのアプリで、これだけ出ている」という読み方で、優先度を上げた。

さらに、実機での確認をお願いする一覧に「経路のアプリで、メモが保存できるか見てほしい」という項目まで入れていた。メモの画面が無いアプリで、メモを保存して確かめることはできない。実行できない確認を、人に頼んでいたことになる。

251件の正体は1人だった

指摘を受けて、まずコードを開いた。経路のアプリには、確かにメモを書く画面が無い。画面へたどり着く入口が、アプリの出し分けで最初から外されていた。

では、なぜメモのエラーが出るのか。理由は、裏側の同期の部品にあった。3つのアプリは同じ同期の部品を積んでいて、その部品は「タスク・カテゴリ・メモ」をまとめてサーバーとやりとりする。画面が無くても、裏ではメモの同期が動いていた。そこで保存に失敗するたびに、エラーが1件ずつ積まれていた。

次に、件数の横に人数を並べた。エラーを出した利用者を、重複なしで数える。

経路のアプリの251件は、全部が私自身の端末から出ていた。動作確認のために3つのアプリを全部入れていた端末が、画面の無いメモを裏で同期しようとして、毎日失敗し続けていただけだった。

実際に困っていた利用者は、本家にいた3人だけだった。直すべき場所も、配信すべきアプリも、本家だった。件数で並べた順位と、人数で並べた順位は、2位以下が丸ごと入れ替わる。

誤りは2つ重なっていた

あとから振り返ると、判断を誤らせたものは1つではなかった。

1つ目は、件数だけを見たこと。 1人の端末が1日に何十回も同じ失敗をすれば、件数はいくらでも増える。件数は「どれだけ騒がしいか」を表していて、「何人が困っているか」は表していない。251件は多く見えたが、困っている人は1人で、しかもそれは自分だった。

2つ目は、その機能がそのアプリに存在するかを確かめなかったこと。 作業の台帳には「経路のアプリでメモのエラーが出ている」と書いてあり、私はそれをそのまま信じた。同じコードから作ったアプリでは、画面が無くても裏の部品は動く。「記録が出ている」と「その機能がある」は、別のことだった。

この2つが重なると、存在しない機能の不具合を、存在しない利用者のために、最優先で直そうとする報告ができあがる。

決めた数え方

この日から、エラーや利用の数字を出す時の決まりを3つ足した。

• 件数を出す時は、必ず人数を隣に並べる。片方だけでは出さない
• 開発者本人の分は、別の行に分けて数える。自分1人の記録を「被害」とは呼ばない
• 兄弟アプリの数字を語る前に、その機能がそのアプリに実在するかを、コードで確かめる

決まりにしてしまえば、もう踏まないと思っていた。1か月後、同じ根っこの失敗をもう一度やった。

1か月後、母数が4人ずれた

Android版の動作確認のために、テスト用のアカウントを1つ作った。テスト用のアカウントは、利用者の集計から外しておかないと、利用者数が水増しされる。「何人が使っているか」で判断する以上、母数のずれはそのまま判断のずれになる。

言われて除外の設定を足した。直したのは、新規登録から利用開始までの流れを数える集計だった。これで外れたと思っていた。

ところが、管理画面には週ごとの利用者数を出すタイルが別にあり、そこは独自の除外リストを持っていた。そちらにはテスト用アカウントが残っていた。

同じ期間の同じ利用者を数えているはずの2つの画面で、4人の差が出ていた。「タイルの方も？」と聞かれて、初めて気づいた。

コードには「この除外リストは、もう1つのリストと一致させること」というコメントまで書いてあった。書いてあっても、ずれた。除外リストが散らばっている限り、人の注意で揃え続けるのは無理がある。

直した形

散らばっていた除外リストを、正本2か所に集めた。

テスト用アカウントを足す時は、この2か所を同じ作業で直す。データベースは変更を適用し、サーバーは配備しないと効かない。

直した後は、「直したつもり」で終わらせず、除外した後の人数を実際に数えて、2つの画面の数字が一致することを確かめるようにした。

振り返り

1回目は「件数と人数」、2回目は「誰を数えるか」。見た目は違うが、どちらも数字の母数を確かめないまま判断した失敗だ。

個人開発の規模では、利用者が数人増減するだけで数字の意味が変わる。3人と1人の差、74人と78人の差は、大きなサービスなら誤差でも、ここでは判断をひっくり返す。だから、数字を出す前に「これは何人分か」「その中に自分とテスト用は入っていないか」を、毎回先に確かめることにしている。