過去の自分が「推奨」と書いたものを、今夜の自分が覆しました

日付が変わった瞬間に、データベースの設計の話を始めていました。

petapetaという付箋風ブックマーク管理アプリを自分で作っていて、毎日のバックアップが、もうすぐ容量の壁にぶつかりそうな段階に来ていたんです。

半月前の自分

その問題は、半月前にすでに見えていました。

「Issue（やることリスト）にちゃんと書いておく」のは、私が大事にしているルールのひとつです。
頭の中に残しておくと忘れるし、別のPCで作業するときに引き継げない。
だから細かいことも全部Issueにして、優先度を一覧で見られるようにしています。

そのIssueには、こう書いてあったんです。
「方式A推奨」

過去の自分が、「これは方式Aでやろう」と決めて残してくれた申し送りでした。

推奨を覆す勇気

今夜、Claudeに計画を立ててもらったら、別の答えが返ってきました。
「方式Bの方がいいです」

理由を聞いて、納得しました。
バックアップは「まるごと書き換え」と「まるごと読み出し」しか使わない仕組みです。
なのに方式Aだと書き込みが100倍多くなる。
コストにそのまま響くんです。

過去の自分は「Firestoreらしい構造」「将来の拡張性」という観点で方式Aを選んでいました。
でも、いまの私の使い方では、その利点が一度も発揮されないことが分かりました。

「推奨」って書いた自分を、今夜の自分が覆していい。
覆す根拠が、表で並べられるなら。

表で並べると見えること

方式AとBを表にして、観点ごとに並べてみました。

ほぼ全ての列で、方式Bが上回っていました。

頭の中で考えているうちは「Firestoreらしさ」みたいな抽象的な言葉に引っ張られます。
でも表に書き出すと、自分のユースケースに合っているのはどちらかがはっきり見えてくる。

私は表を作るのが好きで、迷ったときはいつも作ります。
比較項目を3つ以上並べて、〇△×で埋めていく。
すると、自分が無意識にどの軸を重く見ていたかが分かる。
今夜の場合、「Firestoreらしさ」の重みは、コストや実装コストに比べると小さかったんです。

公式も、過去の自分も、起点でしかない

公式ドキュメントの推奨。
Issueに残した過去の判断。
SNSで誰かが書いていたベストプラクティス。

どれも参考にはなります。
でも、自分のユースケースで再評価する余地はいつでも残っていると、今夜思い直しました。

過去の自分も、半月前のIssueを書いた時点では「方式A推奨」が正しいと思って書いたはずです。
それを今夜の自分が覆すのは、過去の自分を否定することじゃない。
情報が増えた分だけ判断が更新されただけのこと。

公式ドキュメントを覆すときも同じです。
書いた人は、私のユースケースを知らない。
私が私のユースケースを一番よく知っているなら、私が一番いい判断をできる。

954件、10チャンク

実装して、ルールも更新して、デプロイして、シークレットウィンドウで開いて、ボタンを押しました。

954件のブックマークが、10個の小さな箱にきれいに分かれて保存されていました。
復元ボタンも、ちゃんと動きました。
旧形式で保存されていた過去3日分のバックアップも、共存して一覧に並んでいました。

「動いた」とだけ思って、画面を閉じました。

これから

過去の自分が残した「推奨」を、今夜の自分が覆す。
今夜の自分が出した結論を、また何ヶ月後かの自分が覆すかもしれない。

それでいいんだと思います。

設計の正解は、その時点の自分のユースケースに依存する。
推奨を覆す自由を、いつも持っていたい。

かなえ

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

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

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