第2回に引き続き，「現行システムの見える化に関するアンケート」に寄せられた読者の声を紹介しよう。

現行システムの調査に5カ月

Case9：悪循環から抜け出せない
（40代，SE）
　影響分析の時間を少しでも減らしたい。そんな思いからドキュメントが一切ないシステムを調査した。既存メンバーからシステム概要について説明を受けたが，それだけでは不十分。ソースコードやDBの解析を始めると，結局，5カ月もの期間を費やしてしまった。ドキュメントを最新の状態に保てばよいことだが，度重なる改修作業でそこまで手が回らない。いつまで経っても悪循環から抜け出せない。
Case10：時間切れで調査を断念
（30代，SE）
　システム刷新プロジェクトに携わったときのこと。顧客から現行システムのソースコードを提供してもらい，動いていないコードを探し出した。ところがデータの構造や，関数の仕様，システム改修の履歴といった必要情報が断片的。その上，プラットフォームをUNIXからWindowsに置き換えるプロジェクトであり，システムを開発環境上で動かして確認することもできなかった。そのため開発当初の機能仕様書と運用中の帳票データ，担当者のヒアリングによって機能を取りまとめたが，あえなく時間切れ。途中で調査を打ち切った。このときは現行システムの移植ではなかったのでまだよかったが，これが完全な移植だったらと思うと恐ろしくなる。
Case11：全く関係ない機能に影響
（30代，SE）
　現行システムの一部の機能を修正した際，全く関係がないと思っていた別のシステムに影響が出てしまった。障害が発生したシステムは，直接データベースを参照するのではなく，修正したシステムが生成する中間ファイルを参照していたのが原因だった。そもそも顧客と交わした見積もりでは，調査範囲が修正するシステムのみだったのも問題。修正範囲が広がったときの費用は要求しやすいが，調査工数のみの追加は難しいのが実情である。
Case12：インフラもブラックボックス化
（30代，ITアーキテクト）
　アプリケーションだけではない。インフラ面でもブラックボックス化が進んでいる。さまざまな“疑問”に直面する機会が多い。例えばなぜこのOSはこのバージョンなのか，なぜ待機系のみこのパッチなのか，なぜこんなカーネルの設定なのか…。さらに言えば，帳票作成のソフトが入っているが動いているのか，X-Windowシステムは使っているのか，ドキュメントの更新日は1年以上前だが最新なのかなど，挙げたらきりがない。見えやすいと思われがちなインフラ面でさえこの状況だ。解決策は，担当者にしつこく聞く，実際にログインして確かめる，ログを解析する，運用監視面から追求するなどが主なところか。