「なぜここで，無関係としか思えないパラメータを参照しているか」
「今の業務なら，ソース・コードのこの部分を実行することは絶対にないと思うのだが，削除しても大丈夫だろうか」――

　長年にわたる機能拡張や仕様書の紛失／メンテナンス不足により，こうしたシステムの「ブラックボックス化」が進んでいる。団塊の世代の大量退職などで，ブラックボックス化に拍車がかかるという2007年問題も取りざたされている。

　ブラックボックスを放置すれば，システムの仕様が不明確な部分への改修に多大なコストがかかってしまう。システムの改修によって生じる影響の分析には，改修自体の3～10倍の工数がかかるとも言われる。情報システムだけの問題で済めばまだよいが，経営環境の変化にITが追いつけなくなる点なども指摘されている。

　しかし最近，基幹系システムの再構築プロジェクトを取材する中で，システムに存在するブラックボックスには手を触れず，塩漬けにしたまま次期システムに移すだけの事例をいくつか見かけた。システムの再構築という，ブラックボックスを解消する好機にもかかわらず，問題を先送りにしているのだ。それなりに事情があってのことだが，ここではシステムの再構築で起こった2つの例を紹介したい。


存在に気付いていても，時間が足らず問題を先送り

　1つは，スケジュールやコストの制約により，問題を先送りせざるを得なかったケースだ。このプロジェクトでは，COBOLで構築したレガシー・システムをJavaで再構築しようとしていた。開発現場には「これまで20年もメインフレームで塩漬けされてきたシステムを，移行先のサーバー上でまた塩漬けするわけにはいかない」という意識があり，初めの頃はうまく行っていた。

　しかし，プロジェクトが山場を迎え，再構築の対象が“歴史のある”中核システムに差し掛かると，ブラックボックスの中身を解明する手間がかかり過ぎて，作業が先に進まなくなってしまった。プロジェクト・マネジャは業務をよく理解しているつもりだったが，ブラックボックス化したコードに手を入れるまでの自信はなかった。

　結局，納期を守るため，それらのCOBOLコードを含む中核システムには一切手を入れず，そっくりそのまま次期システムに移さざるを得なかった。全面的にJavaで書き換えるという当初の目論見も断念し，COBOLのまま新システムを実装する羽目に陥った。


優秀な自動変換ツールが問題解消の意欲を削ぐことも

　もう1つは，「リホスト（Re-host）」と呼ばれる方法で既存システムをオープン環境に移行させる際に，ブラックボックスを再び塩漬けにしてしまったケースだ。リホストは，ビジネス・ロジックには極力手を加えず，プラットフォームだけを入れ替える手法。例えば，メインフレームのCOBOLアプリケーションを，COBOLのままUNIXサーバーやWindowsサーバーに移植する。レガシー・システムを短期・低コストでオープン化したいときによく利用されている。

　リホストの移植作業では，移行先の環境に合わせてソース・コードを自動変換するツールを使うことが多い。この自動変換ツールを移行元と移行先のシステム環境に合わせて徹底的にチューニングすると，変換率を100％にまで高められる場合がある。これがブラックボックスを塩漬けにする誘因となりやすい。極端な話，ブラックボックス化した部分の仕様を解析しなかったとしても，移行先の環境に合わせたコードを自動生成できてしまうからだ。

　こうした“変換率100％”の自動変換ツールを目の前に用意されたら，追加予算を組んでブラックボックスを解消しようという意欲がわきにくくなることは容易に想像できる。現実にそういう企業も多い。


一時の開発費用増より長期間の保守費用削減を

　ブラックボックス化したシステムの仕様を「見える化」するためには，かなりのコストや時間が必要なことは周知の通りである。見える化を進めている企業は，仕様を一から起こしてシステムを再構築したり，情報システム部門のOB，OGを一時的に呼び戻してシステムの仕様を解析したりするなど，割り増しの予算を確保して取り組んでいる。

　上記の2つのケースは，こうした「見える化」のコストや時間の追加負担を避けた格好だ。ただし，ブラックボックス化がかなり進行しているなら，システム再構築時に割り増しのコストや時間がかかっても，その後，何年も続く保守フェーズのメンテナンス・コストを削減することで採算は合うだろう。その上で，経営環境の変化にITが追いつけなくなるリスクを回避できるなら，計り知れないメリットがある。やはり，ブラックボックスの「塩漬け」は避けるべし，というのが筆者の結論なのだが，ITpro読者はどのようにお考えになるだろうか。