なぜZunaviの図面台帳をゼロから作り直しているのか

誰もが聞く質問：なぜ旧システムに手を入れるのではなく作り直すのか

製造業向けに開発している図面管理プラットフォーム Zunavi について話すと、技術者から最初に出る質問はいつも同じです。「既に動いているシステムがあるのに、なぜパッチを当てて延命するのではなく作り直すのか」。

正直な答えは、Zunaviがいずれ置き換える予定のシステムは、そもそも今の製造業が本当に必要としている形にパッチで近づけられるようには作られていない、というものです。これは、技術的負債が製造業向けソフトウェアの中で静かに積み重なり、やがて「拡張し続けるコスト」が「ゼロから作り直すコスト」を上回ってしまう典型例です。

旧システムの実態

旧バックエンドはMS SQL Server上でTypeORMをORM層として動いています。それ自体は珍しくありません。珍しく、かつ保守を難しくしているのは、物理カラム名が日本語になっている点です。図番、来歴、材質など、数十個に及びます。中核となるdrawsテーブルは60列を超えるまで肥大化しており、公差、比重、刻印番号、座付、アイボルト仕様、吊りボス・取付ボスの寸法、製品系列など、独立した概念としてモデル化されるのではなく、年月をかけて1つの横長テーブルへ次々と要件が継ぎ足されてきた結果です。

横長で場当たり的なテーブル自体が即座に悪いわけではありません。多くの本番システムがそうした形を持ちながら問題なく動いています。本当の問題は、「どの版が現在の図面か」をこのシステムがどう追跡しているかに現れます。

「全削除してから再挿入」というパターン

旧スキーマにはlatestDrawsという別テーブルがあり、常にすべての図面の最新版だけを含んでいるはずのものです。これはクエリで導出されるものではなく、手動で維持されるキャッシュです。テーブルの全行を削除し、現在のセットをトランザクションで包んで再挿入することで同期しています。その上にQ_DrawsというSQLビューが乗っており、下流のコードはそこから読み取りますが、これは「最新版」という基礎データが実はスナップショットであり、毎回誰かが正しい順序（revision DESC, registerDate DESC）で正しく再構築することを覚えていなければならない、という事実を覆い隠しているに過ぎません。

このパターンは、うまくいっているうちは問題ありませんが、破綻すると一気に破綻します。同時書き込みに弱く、現実的な規模では負荷が高く（1つの図面の新版を反映するためにテーブル全体を書き直す）、そして何より、「現在の図面は何か」という正しさが、データモデル自体ではなく「同期処理を正しく実行することを覚えているアプリケーションコード」に委ねられてしまいます。図面という記録の正本を扱うシステムが、自分自身と静かにズレていく可能性があるというのは小さなバグではなく、プラットフォーム全体への信頼を蝕む類のバグです。

旧スキーマには小さくも示唆的な痕跡もあります。func_history.mongoIdという死んだカラムです。これは、SQL Serverへ移行する前、システムの一部がMongoDB上で動いていた時代の名残です。今は何の機能も持っていません。ただそこにあるだけ — 過去の移行がやはり後始末を完了しないまま終わった化石記録です。

私たちが代わりに作っているもの

Zunaviの新バックエンドはPostgreSQL上でPrismaをORMとして動きます。この切り替えだけでも、TypeORMの手動によるエンティティ⇄テーブル同期の代わりに、宣言的なスキーマ、本物のマイグレーション、生成された型が手に入ります。しかし本当に重要なスキーマ変更は、版の扱い方そのものです。

drawsテーブルと別途同期されるlatestDrawsキャッシュという組み合わせの代わりに、新モデルは責務を明確に分離します。Drawing（図番そのものを表す集約ルート）と、その子テーブルであるDrawingRevision（その図面の各版）です。「最新版」はもはや別テーブルではなく、対象の版の行に直接乗っているbooleanフラグ、DrawingRevision.isLatestです。

図面が新しい版を持つとき、その操作全体が1つのデータベーストランザクションの中で完結します。旧版のisLatestがfalseに切り替わり、新版がisLatest = trueとして挿入されます。全削除して再挿入するステップはありません。正本と静かに食い違う可能性のある別キャッシュテーブルもありません。一意制約 @@unique([drawingId, revision]) により、同じ図面に対して重複した版番号を挿入することが構造的に不可能になっており、これは旧システムには存在しなかった防御です。

もし「すべての図面の最新版を取得する」ための読み取り最適化ビューが必要になれば、それは単純なPostgreSQLビュー（DISTINCT ON (drawing_id) ... ORDER BY revision DESC）で対応できます。読み取り時に計算されるものであり、書き込みのたびに手動で維持するものではありません。

それ以外の整理

同じ考え方は版管理以外にも及びます。旧システムのお気に入り・閲覧履歴・ノート・アクションメモ・変更確認という5つの別々のfunc_*テーブルは、typeで区別する単一のUserEventテーブルに統合されます。図面添付ファイルと部品添付ファイル — これまで似て非なる2つのエンティティ階層だった — は、旧システムがPDFに使っていたのと同じ「差し替え時ソフトデリート」の挙動を持つ、section別の単一のAssetモデルになります。部品と旧parts/latestPartsの分裂は、独自の同期ロジックを必要とする第2の並行「最新版」テーブルではなく、使用履歴の追跡機能を持つ単一のItemモデルへ統合されます。

旧システムの60列超も、まとめて捨てられるわけではありません。意味が明確で頻度の高いもの（図番、品名、材質、寸法、担当、状態、版）はDrawingRevision上の正式な型付きカラムになります。頻度の低い可変フィールドの長い尾はDrawingRevision.extraというJSONBカラムに移され、そこでクエリ可能な状態を保ちつつ、後で重要だと判明すれば正式なカラムへ昇格できます。

この破綻パターンは私たちだけの問題ではない

これは特定の社内ツールに固有の問題ではありません。長く使われる製造業向けソフトウェアにおいて技術的負債がとる典型的な形であり、レガシーモダナイゼーションに関する業界の解説記事も、外側から見て同じパターンを描写しています。ある試算では、技術的負債は企業の技術資産価値全体の20〜40%を占めるとされ、負債を抱えたままレガシーシステムを移行しても、その負債をそのまま持ち越し、同じコストを払い続けることになります（IT Convergence）。製造業に特化した解説記事は、その数字の背景にあるメカニズムをそのまま描写しています。老朽化したERPやデータベースシステムは「多くの文書化されていない依存関係」を蓄積しており、1つのテーブルの構造を変えるだけで一見無関係に見える業務プロセスが壊れ、一時しのぎとして書かれたスクリプトが何年も日々の業務の一部として静かに定着してしまいます（Softacom）。SQL ServerからPostgreSQLへの移行ガイドも、同様に繰り返し現れる摩擦点を挙げています。ストアドプロシージャやトリガーに埋め込まれたビジネスロジックが、T-SQLとPL/pgSQLの違い、照合順序、例外処理の扱いといったSQL Server固有の挙動に強く結びついており、自動変換ツールは些細でないロジックについてはほとんど信頼できる形で変換できません（SourceFuse）。latestDrawsの全削除→再挿入パターンとQ_Drawsビューは、まさにこの種の文書化されていない依存関係です。単体で見れば妥当な対処であり、誰も意図的に脆いシステムを残そうとしたわけではありません。

Zunaviを超えて重要な理由

これはSQL Serverが悪くPostgreSQLが良いという話ではありません。「正本の現在の姿」が制約としてではなく手続きとして実装されたときに何が起きるか、という話です。旧システムは誰かが不注意なコードを書いたから壊れているのではなく、何年もかけて積み重なった、個々には妥当な段階的判断の集積が、一度も見直されなかった結果です。それこそが、長く使われる製造業向けソフトウェアにおいて技術的負債がふるまう典型的なパターンです。個々のパッチは単体で見れば問題なく見え、その山は、その上に何か新しいものを作ろうとして初めて姿を現します。

Zunaviは現在も活発に開発中で、まだリリースされていません。この記事は意図的に「出荷したものを見てほしい」という話ではありません。同種の問題を自分たちのシステムで抱えている方に向けた、私たちが下した具体的な技術判断とその理由についての記事です。

---

Zunaviに関する他の記事もあわせてどうぞ。「確実 vs オプション」機能フラグがエンジニアリングデータにとってなぜ重要か、半導体製造業向けにオンプレ第一で開発している理由、そしてZunaviの紹介記事。同じような移行に取り組んでいる方、Zunaviの開発状況を知りたい方はぜひ[email protected]までご連絡ください。