【ITニュース解説】Python beside Delphi, not instead of it

このニュース記事は、長年運用されている古いシステム（レガシーシステム）を、最新の技術であるPythonと連携させることで、いかに効率的かつ安全に改善していくかという実践的なアプローチを紹介している。舞台は靴工場で使われているDelphi製のERPシステムで、これは約16万行のObject Pascalコードと342テーブルを持つMySQLデータベースで構成されており、工場運営のあらゆる側面を管理している。このシステムはただ一人のエンジニアによって担当され、工場を止めることも、システム全体をゼロから書き直すこともできないという制約の中で運用されている。

多くのエンジニアがレガシーシステムに対して「いつ書き直すのか？」という問いに直面するが、この筆者の答えは「書き直さない」という現実的なものだ。システム全体を書き直すには、新旧二つのシステムを並行稼働させながらビジネスの変化に対応し続けるという、一人で解決するにはあまりにも困難な大規模なプロジェクトになるためだ。

そこで筆者が選んだのは、PythonをDelphiシステムを「置き換える」のではなく、「隣に置いて」補完的なツールとして活用するという戦略だった。既存のDelphiアプリケーション自体には一切変更を加えず、ビルドプロセスや依存関係もそのままに保つことで、Python製のツールが本番環境を直接壊すリスクを排除した。

Pythonが具体的に何を実現したのか、見ていこう。

まず、Pythonはデータベースのスキーマ（テーブルやカラム、データ型などの構造情報）をJSONファイルとして出力し、バージョン管理システムに登録することを可能にした。これにより、以前はデータベースクライアントで手動確認するしかなかったデータベース構造が、コードと同じように変更履歴を追えるようになった。特に、「3月のデータベース構造はどうなっていたか？」といった過去の状態確認が容易になり、AIコーディングアシスタントに正確なスキーマ情報を渡すことで、AIが生成するSQLの精度も格段に向上した。

次に、PythonはDelphiのソースコード自体を解析するツールとして活躍した。このERPシステムでは、SQLクエリがDelphiのコード内に文字列として埋め込まれており、特定のテーブルにアクセスしている全クエリを把握することは困難だった。筆者はPythonスクリプトを使い、正規表現を用いてDelphiのソースコードからSQLクエリを抽出し、アプリケーション内の全クエリリストを作成した。これにより、レガシーコード自体を「データセット」として扱い、現代のツールで解析するという新たな視点が開かれた。同様に、Delphiのフォームファイルに埋め込まれたキーボードショートカットの情報をデコードし、一覧化することも可能になった。

さらに、Pythonは「変更の事前検証（プリフライト）」という極めて重要な機能を提供した。これは、システムに新しい変更を加える際に、それが本番環境にどのような影響を与えるかをデデプロイする前にシミュレーションする仕組みだ。例えば、新しいバリデーションルールを導入する際に、それが既存の大量の注文データにどう影響するか（拒否される注文はいくつあるかなど）を、本番環境に影響を与えない読み取り専用のPythonスクリプトで事前に確認できるようになった。これにより、デプロイ後に初めて問題が発覚するというリスクを避け、安全にシステム変更を進めることが可能になった。

また、Pythonは「専用の画面を作るには費用対効果が低いが、手作業では手間がかかる定型業務」の自動化にも活用された。例えば、倉庫から送られてくるスプレッドシートのデータをERPシステムに登録する作業などだ。Delphiで専用画面を開発するには多大な時間とコストがかかるが、Pythonスクリプトを使えば比較的少ないコード量で実現できた。このスクリプトは、デフォルトで「ドライラン」（実際にデータを書き込まずにシミュレーション結果を表示する）機能を備えており、誤って本番データを変更してしまうリスクを大幅に低減している。

しかし、モダンなPythonツールを古いDelphiコードベースに適用する際には、予期せぬ落とし穴も存在した。特に問題となったのは「文字エンコーディング」だ。DelphiシステムはWindows-1252というエンコーディングを使用していたが、現代のPythonツールはUTF-8を前提としていることが多い。この違いにより、ポルトガル語のアクセント記号付き文字が文字化けしたり破損したりする問題が発生した。この課題は、書き込みを行う際に明示的にCP1252エンコーディングを指定すること、そしてファイルのエンコーディングを自動判別するロジックを導入することで解決された。この経験は、新しいツールが持つ暗黙の前提が、古いシステムでは適用されず、予期せぬ問題を引き起こす可能性があるという重要な教訓を示している。

これらのPythonによるツール層が整備されたことで、次のステップとして、一部の機能をWebアプリケーションとして提供することが可能になった。現在では、Flaskフレームワークで開発されたWebアプリケーションが、工場の日報ダッシュボードや部品構成表などの機能を提供している。これはDelphiのデスクトップアプリケーションを置き換えるものではなく、既存のデータベースに接続する「第二のフロントエンド」として機能している。このWebアプリケーションを自信を持って構築できたのは、Pythonによって実現されたスキーマのバージョン管理、全クエリのインベントリ、そして変更の事前検証といった強固な基盤があったからだ。

筆者が過去の自分に贈るアドバイスは、「システム全体を書き直す」という壮大な目標ではなく、「良いライブラリを持つ言語を使って、このシステムから何を学び、何を改善できるか」という現実的な視点で取り組むべきだということだ。Delphiのビルドプロセスに手を出さないという制約は、Pythonツールが本番環境を壊す心配がないという安心感を与え、迅速なツール開発を可能にした。そして、何よりもまずデータベースのスキーマをファイル化することから始めるべきだと強調されている。データ構造が明確になり、その変更履歴を追え、それを他のツールに渡せるようになれば、他のすべての作業が格段に容易になるからだ。