フリーランス向けアプリ開発、元PFM開発者が機能を削るところから始めた話

👋 はじめに

請求書、稼働時間、契約書の更新期限。フリーランスになると、案件そのものより周辺の事務作業に時間を取られますよね。「自分で作れば早い」と思って着手したのに、技術選定で3日迷い、機能を盛って1か月かかり、結局スプレッドシートに戻る。私も最初はまさにこのルートを通りました。この記事では、PFM（家計簿・資産管理）開発で見てきた「使われる機能の条件」を個人開発に当てはめて、機能の絞り方、技術の決め方、運用の形を順番に確認します。結論から言うと、作る前に削る、覚える前に借りる、の2つで大半の停滞は解消できると思います。

🧭 1. 「便利そう」ではなく「入力しなくていい」機能だけ残す

私が最初に作ったのは、案件ごとの実質時給を出すツールでした。稼働時間、単価、移動時間、打ち合わせの回数、経費。全部記録できるように画面を設計して、正直かなり満足していました。ところが、1週間で自分が入力しなくなりました。作った本人が使わないツールは、他の誰にも使われません。

PFM開発で痛感したのは、家計簿アプリで生き残る機能は自動でデータが入ってくるものだという点です。手入力が必要な項目は、どれだけ画面がきれいでも続きません。自分向けツールもまったく同じで、機能を作る前に、スプレッドシートで2週間だけ手作業で回してみて、続いた項目だけをアプリの機能にするのが、私が今もやっている見極め方です。私の場合、残ったのは「月の稼働時間」と「請求額」の2つだけで、その2つを割れば実質時給は出ました。

逆に、契約書の要点を整理するツールは続きました。理由は、PDFを貼るだけで入力コストがほぼゼロだったからです。私なら、最初のバージョンは1画面、入力項目は3つ以内と決めて、それ以上は「続いてから」足します。

⚙️ 2. 技術選定は「いま案件で書いているもの」で決める

ぶっちゃけ、最初は気になっていた新しめの構成（GoのAPIとNext.js、PostgreSQL）で組もうとして止まりました。日中の案件を終えたあとに、慣れない言語のビルドエラーと向き合う体力が残っていなかったのが正直なところです。

業務効率化が目的なら、技術選定で優先すべきは学習コストの低さでも技術的な面白さでもなく、導入スピードです。具体的には次の3点で決めます。ひとつ、言語とフレームワークは案件で日常的に書いているものをそのまま使う。ふたつ、認証とデータベースはSupabaseやFirebaseのようなマネージドサービスに任せて自作しない。みっつ、デプロイはGit連携で自動化できるVercelやCloudflare Pagesのようなサービスの無料枠で始める。

私はAIとペアプロしながら進めましたが、AIが本当に効いたのは知っているスタックで手を速くする場面でした。知らないスタックだと、出力の正誤を自分で判断できず、結局デバッグに時間を吸われます。新技術の学習と業務効率化を1つのプロジェクトで同時にやろうとしない、これが私の一番の反省点です。

🚀 3. 実装と運用は「壊れても請求に影響しない」形にする

自分用ツールの運用は、どうしても緩くなります。私は月末に「ちょっと直すだけ」と思ってデプロイ設定を触り、稼働時間の画面が開かなくなって請求書の作成が遅れたことがあります。趣味のアプリなら笑い話ですが、請求に使うデータはお金に直結します。

そこで決めた運用ルールは4つです。データはいつでもCSVで書き出せるようにして、最悪スプレッドシートに戻れる状態を保つ。請求に関わるデータは月末前に必ずエクスポートしておく。機能追加は月初だけ、月末には触らない。コストは無料枠の範囲で始めて、超えそうになったら機能を足す前に使い方を見直す。監視やアラートは自分専用なら不要ですが、バックアップと書き出しだけは、最初のデプロイと同じ日に用意します。

もうひとつ、他のフリーランスにも使ってもらいたくなる瞬間が来ますが、私ならまず自分専用で3か月回します。契約書のような書類を扱うツールを他人に開くと、個人情報や機密情報の扱いを確認する必要が出てきて、開発の性質が変わるからです。自分ひとりで毎日開いているか、が公開を考える最初の条件だと思います。

✅ まとめ

フリーランス向けアプリを自分で作るときの流れは、削る、借りる、戻れる形で運用する、の3段階に集約されます。技術選定で迷う時間があるなら、案件で書いているスタックとマネージドサービスで先に動かしたほうが、結果的に使い続けられるものになります。私なら、コードを書く前に、スプレッドシートで2週間だけ手で記録をつけて、続いた項目を書き出すところから始めます。そこに残ったものが、あなたのアプリの最初の1画面です。