はじめに
「レガシー」という言葉は、単にシステムが古いことを指すだけではなく、そこにある種の「苦労」や「技術的負債」が凝縮されているときにこそ使われるべき言葉かもしれません。
これは数年前、ある海外案件で新バージョンの与信モデルをリリースした際の、冷や汗が出るような実体験です。
状況：異国の地でのリリース作業
当時、私は新バージョンの与信モデル（クレジットスコアリングモデル）を開発し、その導入のためにクライアントの拠点へ出張していました。先代のモデルも私が実装したものだったので、勝手知ったるシステムであり、意気揚々と現地へ乗り込みました。
今回のミッションは、基幹システムに組み込まれているモデルを新バージョンに差し替えること。当然ながら、モデルを呼び出すためのバインディング（連携コード）の変更が必要になります。
バインディングを変更しなければ、新しいモデルのコードが呼び出されることはありません。そして、バインディングを変更する最も確実で簡単な方法は、ソースコードを修正して再度ビルドすることです。
発生した問題：ソースコードが存在しない
リリースの準備を進めていたその時、致命的な事実が発覚しました。
「つなぎ込み（バインディング）部分のソースコードが、どこにもない」
私の責任範囲はあくまで「与信モデルのロジック開発」と「基幹系へのライブラリ提供」であり、それを呼び出すための「つなぎ込みコード」の管理は管轄外でした。しかし、現実に目の前にあるのは、コンパイル済みのバイナリだけで、その元となるソースコードが見当たりません。
迫りくるタイムリミット
状況は深刻でした。
そう、帰国予定です。帰りの飛行機の日程は刻一刻と迫っている。
「担当者がいないから分からない」「ソースが見つかるまで探す」といった悠長なことを言っている時間は残されていませんでした。帰国を延期したとしても、ソースコードが出てくる保証はどこにもありません。
解決策：禁断の「逆コンパイル」
普通に考えれば、詰んでいます。しかし、エンジニアとして「できませんでした」で終わらせるわけにはいきません。
手元にある材料を見直しました。
- ソースコードはない。
- しかし、現在稼働しているバイナリは基幹システムの中に存在する。
ここから導き出される唯一の解、それは 「逆コンパイル（Decompile）」 でした。
- 現行のバイナリを逆コンパイルして、失われたソースコードを復元する。
- 復元したコードをベースに、新モデル用のバインディング修正を行う。
- 再コンパイルしてリリースする。
これは正規の手順ではありませんが、背に腹は代えられません。実際、関係者の同意は比較的、簡単に取り付けることが出来ました。
実行と結果
私は覚悟を決め、OSSの逆コンパイラを導入しました。
バイナリから生成されたコードは、コメントこそ失われていましたが、ロジックは明瞭でした。そこへ必要な修正を加え、慎重にビルドを通しました。
テスト環境での動作確認を経て、震える手で本番環境へデプロイ。
結果、システムは正常に稼働し、新しい与信モデルは正しく呼び出されました。
強行突破ではありましたが、エンジニアとしての執念がリリースを成功させた、忘れられないプロジェクトとなりました。