研修が始まってしばらくして、のんびりとアプリを作り始めた。
朝の通勤中はマネーフォワードを眺めながら「ここが使いにくい」「こういう設計にしたい」と頭の中で整理して、夜だけ少しずつ実装する。当時は誰にも言わず、ただ「早く使いたい」という気持ちだけで、開発を進めていた。
約1週間後、ふと思った。もう、マネーフォワードより使いやすいかもしれない。
今回は、何を使って作ったか、なぜその技術を選んだかを書いておく。
🗺️ 技術スタック全体像
Flutter (Android)
↓
Supabase Auth（認証）
↓
Go (Gin) + JWT検証ミドルウェア（バックエンドAPI）
↓
PostgreSQL / Supabase DB
🤔 なぜこの技術を選んだか
📱 Flutter を選んだ理由
スマホアプリとして作りたかったから。
最初は「このサイト（Next.js）に家計簿機能をそのまま追加する」という選択肢もあった。でも、家計簿は毎日スマホからサっと入力するもの。Webアプリではどうしてもワンテンポ遅い。
iOS/Android の両対応を1つのコードベースで済ませたくて Flutter を選んだ。実際に書いてみると、ウィジェットの組み合わせ方が直感的で、想定より早くUIが形になった。
🗄️ Supabase を選んだ理由
PostgreSQL ベースの RDB だから。
NoSQL だと複雑な集計クエリが書きにくい。Supabase は PostgreSQL をそのまま使えるので、月次集計や残高の再計算など、SQL で表現したいロジックをそのまま書ける。ちょうど研修でも PostgreSQL を使っていたので、親しみがあったのも後押しになった。認証（Supabase Auth）とデータベースが一体になっているのも個人開発にはちょうどいい。
JWT の発行も Supabase が担当してくれるので、Go 側でその JWT を検証するだけでいい。
⚡ Go を選んだ理由
軽くて速くて、型安全だから。
Python と迷ったけど、いったん Go にした。新しい言語に触れるのが好きだし、今 Go が流行っているのも肌で感じておきたかった。実際に書いてみると、シンプルな文法と高速な起動時間がバックエンドAPIにちょうどいい。
📝 sqlc を選んだ理由
ORM を使わず、SQL を直書きしたかった。
ORMはデータモデルが複雑になってくると「裏で何が起きているか」が見えにくくなる。sqlc は、書いた SQL ファイルから型安全な Go コードを自動生成してくれる。SQL は自分で書く。でも、生成されたコードは型付きで使える。
golang-migrate でマイグレーションも SQL ファイルで管理しているので、DB の変更履歴がそのままコードとして残る。この組み合わせがかなり快適。
🚧 現在の進捗
研修の合間に少しずつ進めて、約1週間でここまで形になった。
Phase 1（土台）
- Supabase でテーブル設計・作成
- Go + Gin のAPIサーバー起動
- Supabase Auth の JWT をGo側で検証するミドルウェア（RS256公開鍵を動的取得）
- sqlc + golang-migrate のセットアップ
Phase 2（MVP）
- Flutter のログイン画面
- 明細一覧画面（日付グループ化 + 日次収支合計）
- 支出の手動入力フォーム（カテゴリ・サブカテゴリ・口座・日付を選択）
- Go API 側に categories / subcategories / accounts / expenses の CRUD 全対応
🔗 一番こだわった機能：親子明細
個人的に一番気に入っている機能が、親子明細だ。
割り勘やイベントでまとめて払ったとき、「合計額を1件の支出として記録しつつ、内訳を子明細として紐づける」という使い方ができる。
たとえば、飲み会で自分が3万円立て替えて、友人からあとで1万円返ってきたとする。このとき：
- 親明細: -32,000円（飲み会）
- 子明細: +8,000円（友人からの回収）× 3件
として登録すると、一覧では合算した正味額（-8,000円）が表示される。日次集計も二重計上なし。
親を0円で記録すれば、イベントの出費をまとめるコンテナとしても使える。
長押しでリンクモードに入り、既存の明細を子にリンクする操作も実装した。
🎯 マネーフォワードを超えたと感じた瞬間
ある日の昼休み、エミュレーターで動かしながら支出を入力していた。カテゴリを選んで、金額を打って、保存。一連の流れが3タップで終わった。
「あ、マネーフォワードより速い」と思った瞬間だった。
マネーフォワードは「連携口座の自動同期」が主役なので、手動入力には向いていない。画面遷移が多いし、カテゴリ分類も柔軟じゃない。
自作アプリは、自分の使い方に完全に合わせて設計できる。入力フォームのUX、カテゴリの階層設計、親子明細の考え方——全部自分が欲しいものだ。
🚀 今後の展望
次のステップは以下の2つ。
① Go API を Oracle Cloud にデプロイして実機で使い始める
エミュレーターではなく、実際に毎日使えるようにする。使い込まないと気づかない改善点が絶対あるから。
② クレカ通知メールの自動入力
クレジットカードの利用通知メールを自動解析して、Go API に自動投入する仕組みを作る予定。これが完成すれば、使った瞬間に家計簿に記録される。