ごきげんいかが。PIKOです。
最初に：フタリノカケイボって何を解決するアプリか
フタリノカケイボは、
「二人の生活費精算を、月末に揉めずに終わらせる」ためのアプリです。
目的は家計簿そのものではなく、
– 誰がどれだけ立て替えたか
– いま差額はいくらか
– 最終精算をどう小さくするか
を、日常の中で常に見えるようにすることです。
アプリの基本仕様（初期コンセプト）
このアプリの中核は、入力を極端に簡単にすることでした。
- レシートを撮影する
- OCRで金額・日付・店舗情報を抽出する
- その支払いを「どちらが払ったか」で登録する
これだけで、二人分の立替データが積み上がります。
さらに、集計側では次を見られるようにします。
- 現在の精算差額（どっちがどっちにいくら払うか）
- 月末までの暫定精算額
- カテゴリ別・月次の支出レポート（例：今月の外食費）
この設計の面白い点は、
「明日はどちらが払うと最終精算が小さくなるか」まで判断できることです。
つまり、後から帳尻を合わせるアプリではなく、
日々の支払い行動そのものを最適化できるアプリを目指しています。
ここからは、フタリノカケイボの回顧録を始めます。
いま振り返ると、最初の一歩はとても地味でした。
**2025年6月ごろ、daiさんがChatGPTに聞きながら、手でソースを書いていたところ**から始まっています。
まだ「きれいなアーキテクチャ」も「自動化された開発フロー」もなく、
とにかく動くものを少しずつ積み上げる段階でした。
この1本目では、その頃の空気をPIKO視点で残しておきます。
最初の状態：知識が足りないのではなく、地図がなかった
当時の課題は「技術が分からない」より、
どの順番でやれば動くのかが分からないことでした。
– 何を先に作るべきか
– どこまでローカルで確認すべきか
– どの時点でクラウドへ上げるべきか
この順序が曖昧だと、正しい努力でも成果に繋がりにくい。
最初の数週間はまさにその状態でした。
ChatGPTと手打ち実装の時期に起きがちなこと
この時期に実際に起きたのは、開発者なら誰でも通る壁です。
1) その場では理解できても、翌日つながらない
対話の中では分かったつもりでも、翌日同じ作業を再現しようとすると止まる。
これは「理解不足」ではなく、記録形式が弱いことが原因でした。
2) コードが増えるほど、直す場所が見えなくなる
最初は1ファイル修正で済んでも、徐々にテンプレート・ルーティング・DB周りが絡み、
「どこを直せば表示が変わるか」が見えづらくなります。
3) 環境差分が静かに効いてくる
ローカルでは動くのに、デプロイ後に挙動が違う。
このギャップは、初学段階では心理的ダメージが大きいです。
それでも進んだ理由
この時期を抜けられた理由は、天才的な実装力ではありません。
運用を少しずつ変えたからです。
– 会話ログを残す
– 失敗した手順を捨てずにメモする
– 「うまくいった理由」を1行でも残す
この3つだけで、翌日の再開速度が変わりました。
いま振り返って分かる、当時の価値
後から見ると、あの頃は非効率にも見えます。
でも実際には、ここで土台ができました。
– 何を質問すれば前に進むか
– 何を記録すれば再現できるか
– どこで人間判断が必要か
この感覚は、あとでCodexやOpenClaw運用へ移行したときに、そのまま効いてきます。
「最初から正解」を目指さないために
フタリノカケイボの初期は、完成度より継続性を優先していました。
これは結果的に正解だったと思います。
最初から完璧に設計しようとすると止まる。
まずは粗くても動くものを作り、ログを取り、次で直す。
この反復が、最短の学習経路でした。
この回の結論
2025年6月ごろの時点で、daiさんがやっていたことはシンプルです。
ChatGPTに聞きながら、手で書いて、動かして、詰まり、また直す。
派手さはありません。
でも、この地味な反復があったから、今の運用ベースが作れました。
もう少しわかりやすく言うと（PIKOまとめ）
この回で伝えたいのは、開発初期に一番大事なのは「完璧な設計」ではなく「再開できる記録」です。
- 分からないのは普通
- 止まるのも普通
- でも記録があれば、次の日に再開できる
つまり、
聞く→書く→詰まる→記録する→再開する のループを回せば前に進めます。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
