「現行システムとドキュメントの内容が全く違う」──。今から1年前，基幹システムの刷新プロジェクトに参加していたファミリーマートの上條公也氏（システム本部 システム運用部長）は，大きな問題に直面した。
アプリケーションに関する要件定義の真っただ中。従来利用してきた現行機能を新システムに引き継ぐために，現行システムを調査した。ところが，120あるサブシステムのうち，20のサブシステムで既存のドキュメントがきちんとメンテナンスされておらず，それを読んでもシステムの内容を把握できなかったのだ（図1左）。
上條氏は「これでは現行機能を引き継げない」と考え，20のサブシステムのソースコードに直接当たることにした。すると今度は，度重なる改修でプログラムの構造が複雑化しており，なぜそのロジックになっているのか解釈できない。ブラックボックス化した現行システムに，メンバーらは苦戦を強いられた。
画面/帳票を一つずつ地道に確認
そこで上條氏らは，画面や帳票，データといった外部仕様を洗い出し，その関係を整理していった。外部仕様は入出力情報に相当する。そのため入出力情報を基に，機能に当たる処理ロジックを推測しようと考えたのだ（図1右）。
例えば，入力情報にデータとして「売上データ」，出力情報に帳票として「地域別売上集計表」があったとする。この場合は，両者の間の集計ロジックを新たに考えていった。
これで難所は切り抜けられる。しかし，今もなお続ける画面や帳票を一つずつ調べる作業には，予想以上の工数を費やすことになった。
3～4割は不要なコード
このように，現行システムを見える化する作業に苦労した経験を持つ開発・運用の現場は多いだろう。ここでいう「見える化」とは，システムの内部仕様や外部仕様を明らかにすることを指す。ソースコードのロジックやデータとの関係といった内部仕様のほか，画面や帳票と業務フローの関係といった本来目に見えやすい外部仕様までブラックボックス化してしまうケースは珍しくない。また，稼働中のソースコードと不要なソースコードがライブラリ上に混在する例もある。
問題なのは，このようにシステムの仕様を“あいまい”なままにすることだ。現行システムの調査・分析に詳しい野村総合研究所の木村綾太郎氏（情報技術本部 生産技術部 上級テクニカルエンジニア）は「ドキュメントの不備はよくあること。さらに不要なソースコードやデータを放置してシステムを肥大化させるケースも目立つ。大切なのは，そうした状況をきちんと把握し，改善することだ」と指摘する。
木村氏によると，企業で管理するソースコードの3～4割は未使用や重複など不要なもの。それを見える化していない状況，つまり“あいまい”な状況を断ち切らなければ，さまざまな問題を引き起こすという。
実際，冒頭の例のように，現行システムがブラックボックス化したことで起こる問題はいくつもある（図2）。
「現行システムのドキュメントが整備されておらず，地道な調査で疲弊した経験があるITエンジニアは少なくないはず」。こう指摘するのは，日立製作所の石川貞裕氏（プロジェクトマネジメント統括推進本部 担当本部長）。調査対象は画面や帳票だけではない。「バッチ処理だと，画面や帳票だけではそのロジックが分からない。ドキュメントがないなら，地道にプログラムを調べざるを得ない」（石川氏）。
不透明なシステムでは，障害発生時の原因特定も難しくなる。クレジットカード決済システム「CAFIS（Credit And Finance Information System）」を運用するNTTデータネッツの須崎正志氏（第七開発担当 第三開発担当 部長）は「システムを構成する製品・技術が多岐にわたり，さらに外部とのシステム連携も増えた。想定外の障害発生とは常に背中合わせ。使用製品のメーカーを極力絞る，むやみに担当者を配置替えしないなど，その対策に頭を悩ます」と打ち明ける。
