📝
Legacyなデータベースに関わる一切の実装を新規実装に持ち込まないこと
それでもAIが答えてくれないこと #2
導入
前回の 「技術的にはできる。でもやらない判断をした話」 に関わる続編だ。
今回のテーマは、検索データのデータソースをリプレイスする案件での判断について。
自分の信条のひとつは、「Legacyなデータベースに関わる一切の実装を、新規実装に持ち込まないこと」。
短期的には「早く動くものを作る」誘惑があるが、長期的に見れば負債でしかない。
事例
当初、検索機能のデータソースは PostgreSQL の既存テーブルだった。
しかしプロジェクトのフェーズで大きな刷新があり、新しいテーブル定義に切り替え、現行の多くの機能は新定義上で動くようになった。
にも関わらず、検索データだけは古いテーブルを参照し続けていた。
- 推進担当の要望：古いテーブルと新しいテーブルの両方を検索対象にしたい
- 開発チームの要望：データソースを OpenSearch にリプレイスしたい
状況を調べると、古いテーブルのデータは検索専用であり、現機能ではすでに使われていないことが分かった。
にもかかわらず、もし要望通りに実装すると「古いテーブル用」と「新しいテーブル用」の二重の取り込み機能を作ることになる。
技術的に可能か？
もちろん可能だ。
古いテーブルからデータを整形して OpenSearch 用のドキュメントに変換すればよい。
ただし、その場合…
- 今後も古いテーブルの構造を理解し続ける必要がある
- 古い実装コードの改修や保守が延々と発生する
- 結果として、新実装が「過去に縛られる」
つまり、未来永劫負債を抱える選択になる。
自分の判断
「やりたくない」。
理由は単純で、今後のエンジニアが困るだけだから。
そこで、自分はこう判断した：
- 新しい取り込み機能は新テーブルのみに責任を持たせる
- 古いテーブルは、検索結果や実装コードを Claude Code に読み込ませ、人力＋AIで一度変換ドキュメントを生成するだけにとどめる
これにより、新実装は完全に「新テーブル専用」となり、古い取り込み機能とは無縁で済むようになった。
未来
近い将来、古いテーブルとそれに関連するコードは削除できるはずだ。
そして新実装は「Legacyを持ち込まなかった」という選択によって、クリーンなまま保たれる。
学び
- 生きているデータと死んでいるデータをごちゃ混ぜにすると、実装的負荷・心理的負荷が跳ね上がり、手に負えなくなる
- リバースエンジニアリングしたコードを新実装に流用すると、古い設計が残り続ける
- 古いデータは、人力やAIを駆使してでも「履歴を断ち切る」くらいの覚悟が必要
まとめ
技術的にはできる。
だが、Legacyを持ち込むことで未来の開発者が苦しむなら、やらない方がいい。
この判断こそ、AIが答えられない「人間の信条」であり、記事に残す意味がある。
Discussion