前回、FileMakerでの壁にぶつかってGitに出会うまでの話を書いた。今回は、その後実際に何を作ったかの話。
30年前、実家の製造業では、月1,500枚の注文書を手書きで処理していた。1日50枚。毎日3時間の残業。この状況をなんとかしたくて、FileMakerで業務システムを組んだ。受注・製造指示書・納品書・請求書・領収書を、すべてリレーションで繋いだ。
結果、1日50枚の注文書を処理しても、1円のズレが出なくなった。事務員と自分の残業が、ゼロになった。
Gitに出会って、「じゃあ今度は何を作るか」を考えたとき、答えは新しく探すものではなかった。20年前に自分がすでに作っていた。あとは、それをGit管理できる技術に翻訳するだけだった。
進捗ステータスという列を、作らなかった
このシステムの受注テーブルには、進捗ステータスという列が存在しない。
1日50枚の伝票を処理していると、作業は必ず中断される。現場から呼ばれる。電話が鳴る。お客さんが来る。席に戻った事務員は、必ずこう思う。「あれ、どこまでやってたっけ」
これを解決する方法として、進捗ステータス列を持たせて手で更新する設計もある。でも、人が更新する列は、更新し忘れる。中断が多い現場ならなおさらだ。一度ズレた進捗は、実態と食い違ったまま放置され、そのうち誰も信用しなくなる。
だから、製造指示書が作られていれば「製造中」、納品明細があれば「納品済み」、請求書があれば「請求済み」と、実際に発生した記録そのものから進捗を導き出す構造にした。更新し忘れは、構造的に起こりえなくなる。
あえて自動化しなかった
このシステムは、請求書をPDFで自動生成もしないし、メールも自動送信しない。ブラウザの印刷機能で出力し、事務員がメールに添付して送る。
理由は単純で、「PDFを作った」ことと「送った」ことは、実務では別の事実だからだ。金額の確認待ちだったり、先方の担当者が不在だったり、今月はまとめて来月に回すことだってある。「作ったが、まだ送っていない」という状態は確かに存在する。それをシステムが表現できなければ、進捗はすぐ実態とズレる。
事務員が⌘+Pで印刷してメールに添付する作業は、数十秒で終わる。すでに毎日やっている操作でもある。その数十秒を消すために、開発費と保守費を払い続ける判断は、中小企業にとって合理的だとは思えなかった。
変わったのは実装手段だけ
コードは正直、正確には書けない。実装はClaude Codeに任せている。でも、テーブル間のリレーションをどう設計するか、どの情報をどこに持たせるか、という判断は、20年前にFileMakerで実務をやりながら身につけたものが、そのまま今も生きている。
FileMakerが劣っていたわけではない。今でもその設計思想は評価している。ただ、Git管理ができないという一点だけが、今の自分には譲れない制約になった。
20年前に手で組んだリレーショナルデータベースを、Git管理できるモダンなWeb技術に翻訳する。それが、今回作ったシステムの正体だ。
設計の詳細は、GitHubで公開している。
https://github.com/kuros-works/kuros-order-management
Kuro's Worksとしての事業内容は、こちらのサイトにまとめている。
https://www.kuros-works.com/
