はじめに

「レガシー」という言葉は、単にシステムが古いことを指すだけではなく、そこにある種の「苦労」や「技術的負債」が凝縮されているときにこそ使われるべき言葉かもしれません。

これは数年前、ある海外案件で新バージョンの与信モデルをリリースした際の、冷や汗が出るような実体験です。

状況：異国の地でのリリース作業

当時、私は新バージョンの与信モデル（クレジットスコアリングモデル）を開発し、その導入のためにクライアントの拠点へ出張していました。先代のモデルも私が実装したものだったので、勝手知ったるシステムであり、意気揚々と現地へ乗り込みました。

今回のミッションは、基幹システムに組み込まれているモデルを新バージョンに差し替えること。当然ながら、モデルを呼び出すためのバインディング（連携コード）の変更が必要になります。

バインディングを変更しなければ、新しいモデルのコードが呼び出されることはありません。そして、バインディングを変更する最も確実で簡単な方法は、ソースコードを修正して再度ビルドすることです。

リリースの準備を進めていたその時、致命的な事実が発覚しました。

「つなぎ込み（バインディング）部分のソースコードが、どこにもない」

私の責任範囲はあくまで「与信モデルのロジック開発」と「基幹系へのライブラリ提供」であり、それを呼び出すための「つなぎ込みコード」の管理は管轄外でした。しかし、現実に目の前にあるのは、コンパイル済みのバイナリだけで、その元となるソースコードが見当たりません。

状況は深刻でした。

そう、帰国予定です。帰りの飛行機の日程は刻一刻と迫っている。

「担当者がいないから分からない」「ソースが見つかるまで探す」といった悠長なことを言っている時間は残されていませんでした。帰国を延期したとしても、ソースコードが出てくる保証はどこにもありません。

普通に考えれば、詰んでいます。しかし、エンジニアとして「できませんでした」で終わらせるわけにはいきません。

手元にある材料を見直しました。

ここから導き出される唯一の解、それは 「逆コンパイル（Decompile）」 でした。

これは正規の手順ではありませんが、背に腹は代えられません。実際、関係者の同意は比較的、簡単に取り付けることが出来ました。

私は覚悟を決め、OSSの逆コンパイラを導入しました。
バイナリから生成されたコードは、コメントこそ失われていましたが、ロジックは明瞭でした。そこへ必要な修正を加え、慎重にビルドを通しました。

テスト環境での動作確認を経て、震える手で本番環境へデプロイ。
結果、システムは正常に稼働し、新しい与信モデルは正しく呼び出されました。

強行突破ではありましたが、エンジニアとしての執念がリリースを成功させた、忘れられないプロジェクトとなりました。