Git管理できることを前提に技術選定すべきだと気づいた話

はじめに

30年前、実家は製造業を営んでいた。月商3,000万円、注文数は月1,500枚。1日あたり50枚の伝票処理があり、毎日3時間の残業が当たり前だった。

正直に言うと、自分は字が下手で、手書きで伝票を書くこと自体が嫌で嫌でしょうがなかった。この状況をなんとか打破したくて、FileMakerでの業務システム構築に挑んだ。

それから5年間、FileMakerで業務システムを構築・運用した。1日50枚の注文書を処理しても、1円のズレが出なかった。今思えば、当時から「正確に、リレーショナルに、業務を管理する」という感覚は身についていたのだと思う。

時を経て、現在は子供向けの英語教室を運営している。ただ、稼働時間は16時から18時のみ。稼働前の日中の時間で何かできないかと、2年以上、色々な事業を試行錯誤していた。

そんな中で最初に手を伸ばしたのは、一番身近だったGoogle Apps Script(GAS)だった。

GASで作ろうとして、壊れた

GASでスプレッドシートを操作しながら、受注管理のようなものを組もうとした。最初はうまくいくように見えた。しかし、扱うデータが増えるにつれ、あちこちで整合性が崩れ始めた。

原因ははっきりしていた。スプレッドシートは、行と列の2次元でしかデータを表現できない。受注・製造・納品・請求・入金という、業務の流れそのものを表現するには、根本的に構造が足りていなかった。

ここで気づいた。自分が本当に必要としているのは、テーブル・レコード・リレーションという発想だった。

FileMakerに戻る、しかし

「テーブルとリレーション」と言われて真っ先に思い浮かんだのは、30年前に使っていたFileMakerだった。実務でリレーショナルな業務システムを組んだ経験があるので、迷わずFileMakerに向かった。

しかし、ここで一つの壁にぶつかった。FileMakerはGit管理ができない。

変更履歴を追えない。バージョン管理ができない。複数人での安全な共同開発が前提になっていない。当時は気にしていなかったこの制約が、今の自分には致命的に感じられた。

技術選定の軸が変わった瞬間

ここで、自分の技術選定の基準がはっきりと言語化された。

Git管理できるかどうか

これが、それ以降のすべての判断の軸になった。

この軸で他の選択肢も見直してみた。

	Git管理	データの持ち方	拡張時のコスト
FileMaker	不可	リレーション(参照)	中
ノーコード業務ツール(kintone等)	限定的	ルックアップ(転記が基本)	高
Supabase + Vercel	可	リレーション(参照)	低

kintoneの「ルックアップ」機能は、名前こそリレーションのように見えるが、実態は値をコピーしてくる転送機構だ。参照元が更新されても、コピー先には自動で反映されない。PostgreSQLのような「参照し続ける」構造とは根本的に違う。

なお、SAPのような大規模ERPは、そもそも比較の土俵が違うため今回は対象に含めていない。数百人規模・部門横断の統制と監査が前提であり、個人や小規模チームが受注から請求までを繋ぎたいという目的で選ぶものではない。

こうして残ったのが、Supabase + Vercelという組み合わせだった。正確なリレーションが組め、Gitでバージョン管理ができ、しかもマネージドSaaSなのでインフラの複雑さを自分で抱え込む必要がない。

個人で2ヶ月、コードは書けないままで

ここが自分でも意外だったポイントだが、このシステムは個人開発・2ヶ月で形になった。しかも、正直に言うと、自分はコードを正確に書くことが得意なタイプではない。

設計判断(このテーブルは何を持つべきか、どこを正規化すべきか、進捗はどう管理するか)は自分が担い、実装はAI(Claude Code)に任せる、という分担で進めた。

FileMaker時代に培った「構造を分析する力」は、コードを書く力とは別物として、そのまま現在のスタックの上でも通用した。むしろ、コードを書く作業をAIに任せられる時代になったことで、構造を見抜く力の価値が相対的に上がっているとすら感じている。

おわりに

FileMakerが機能的に劣っていたわけではない。今でもそのリレーション設計の思想は評価している。ただ、Git管理ができないという一点が、今の自分には譲れない制約になった。

「Git管理できることを前提に技術選定する」というのは、エンジニアであれば当たり前に聞こえるかもしれない。しかし、業務システムの世界では、まだこの前提を持たずに選ばれているツールが数多くある。

ノーコードでは構造が持たない。ERPでは重すぎる。その中間の空白を、Supabase + Vercel + GitHubという組み合わせが埋めてくれた、というのが今回たどり着いた結論だ。

今回は製造業の業務管理を想定し、受注・製造指示書・納品書・請求書・領収書という一連の流れをBtoB向けのRDBとして構築した。今後も、Gitで管理できる技術スタックを軸に、業務システムの設計・開発を続けていきたい。

実際に組んだ受発注管理システムは、GitHubで公開している。設計の詳細は、また別の記事で書いていきたい。