大仰なタイトルですみません。個人開発です。
パートナーと自分の経済状況が概ね一緒であるため、基本的に食事や買い物は割り勘しています。 とはいえ、会計を分けてもらったり、その都度PayPayで送金するのは手間。 市販の家計簿アプリもいくつか試したけど、これまた入力が手間。walicaなどの割り勘アプリは複数人対応だから余計なボタンが多い。
とにかく「どっちがどんだけ払ったか」だけ管理できればいいのに、ちょうどいいツールがありませんでした！
家計簿アプリを作った
そこで作ったのがこの「支出天秤(通称:天秤)」です。
「支出の入力」「金額の入力」以外の機能を完全に廃したシンプルな作りにしました。統計をとりたいわけではないから、これで十分です。
表示側も、月ごとの支出や合計金額などの概念を完全に捨てて、「どっちがどれだけ多く払っているか」だけを表示することにしました。ここに出ている数字をできるだけゼロに近づけるだけで、自動的に割り勘が達成される仕組みです。
あまりにもシンプルなつくりですが、意外に使用感がよく、ほぼすべての外食や買い物で利用されています。2人の間では、「天秤入れといて～」がすっかり常套句になりました。
2025年の4月に作成して以降、実にのべ141件・688300円の支払いが記録されています。
68万円！？！？！？！？！？！？！？！？
技術スタック
Next.js App Router + FireStore で、フロントエンドはShadcn/ui です。なぜこんな構成になっているかというと、開発に v0.devを利用したからです。
開発初期のログを引っ張り出してきましたが、わずか3行くらいのプロンプトで7割方の画面ができあがっていて、Vercelへのデプロイもワンクリックで行えるのだからとんでもないですね。
無論これではい完成…ではなく、その後のFireStore周りのつなぎこみはCursorでチマチマ進めました。FireStoreの開発用モックなどの準備に腐心した記憶があります。
それでも、手を動かしていたのは合計で2~3日のようですね。(この画面はClaude Codeに作ってもらったコミットログから稼働時間わかるくんです)
数日の作業で半年使えるものができるのだから夢があります。
見えている課題
建て替えボタンがない
割り勘専用で作ったので、ドメインモデルに建て替えの概念がありません。なので、建て替えのときは倍額で入力するというよく分からない慣習が生まれています。先述の合計金額も、これのせいで若干ズレていると思います(50万円は下回らないと思うけど)。
支払いを全件取得している
←ここに表示する値の計算をするために、過去の支払いをフロントエンド側で全件取得・差額の計算を都度行っています。ページングもしていないので、DBに蓄積されたデータが増えるほどにパフォーマンスが落ちる、いわゆるスケールしない状態になっています。
料金的にはFireStoreの無料枠に十分収まっているので困らないのですが、将来支払いが増えてきたときに、表示のパフォーマンスに問題が出てくることが容易に想像できます。
2人の名前を環境変数に直接埋め込んでいる
本当にバカなんかな俺？
展望
この辺りの課題を解決するために、そろそろリファクタをしたいなと思っています。認証基盤をちゃんとつければ、オープンインターネットに公開して、知り合いの割り勘派カップルにも使ってもらえるようになるかもしれませんし。
幸い、これを作ったのは関数型ドメインモデリングの読書会 の後だったので、ドメイン駆動設計を意識した作りになっています。モデルとI/Oはちゃんと分離されており、修正は容易そうです。
「とにかく小さくはじめて、スケールしなくなってきたら修正する」という鉄板の動きが実現できている、ということにしておきましょう。
それと、最近払ってもらってばっかなので、今後しばらくは自分が払おうと思います。
この記事ははてなエンジニア Advent Calendar 2025の14日目です。
PREV: プラモとIT - koudenpaのブログ NEXT:
