第2回と第3回で，先に実施した「現行システムの見える化に関するアンケート」の結果を報告させていただく。このアンケートでは，大きく三つの点をお聞きした。

　一つは，現行システムを見える化することの難しさや，実際に苦労した経験など。二つ目は，そもそも現行システムを見える化する目的は何かである。そして三つ目は，現行システムを見える化する方法だ。有効な方法をご存知であれば，それをお寄せいただこうと考えた。ご協力いただいたITpro読者の方々に，この場を借りて感謝申し上げます。

　以下は，三つの回答を含む読者からのコメントである。結論から言えば，現行システムの見える化に関する“魔法の杖”は，ほぼないと言っていい。むしろ際立ったのは，見える化に苦しむ現場の実態である。システムの再構築や運用・保守の効率化など，見える化の目的はさまざま。だがいずれの場合も，地道に見える化に取り組む現場の実態が浮かび上がった。

蔓延する「設計書の不備」

　まず予想通り多かったのは，設計書の不備である。設計書が最新の状態にメンテナンスされておらず，現行システムの見える化に苦労するケースだ。

Case1：地道に解きほぐすしかない
（40代，プロジェクト・マネージャ）
　開発や運用保守の工数を削減するために，現行システムを調査した。だがドキュメントを頼りに影響調査を始めたものの，そのドキュメントがメンテナンスされていなかったり，ドキュメントそのものが存在しなかったりした。やむなくソースコードから調査すると，今度は使用されているコードと，不要なコードが混在。結局，地道にソースコード間のつながりを調べ上げ，その間のI/Oをはっきりさせた。効率的に見える化できる情報がほとんどない現状である。絡まった糸をほぐすには地道に進めるしかないだろう。
Case2：下手に触ると障害を招く
（40代，運用担当者）
　見える化の目的は，障害時の影響範囲を特定することだった。しかし障害が起きても何がどうなっているのか全く分からない。担当者から引き継いだばかりで，完全なドキュメントはどこにもない。こんなシステムで障害発生時の影響範囲を特定するのは無理だ。障害復旧の手順書もないので，障害発生時の復旧時間も長期化することがしばしば。システムを改修したくても怖くて触れない。下手に触って障害を発生させた苦い経験もある。
Case3：リバースを愚直に行う
（20代，SE）
　機能拡張時に影響範囲を特定するため，現行システムを調査した。機能の目的や意図を知りたかったが，そもそも設計書が作成された様子がない。結局，現行システムの調査は，人とツールによるリバース・エンジニアリングを愚直に行った。新規開発時にはドキュメントの作成を義務化する，開発完了時にはドキュメントの有無と内容の適正さを確認する，といった対策を講じてほしいものだ。
Case4：プログラムの概要とデータの関連ぐらいは
（30代，プロジェクト・マネージャ）
　設計書がないので，ソースコードが何を意味しているのか分からない。途中でデータ仕様が変わっているので，データの移行で苦労することになる。確かに成果物のバージョン管理は大変である。それでもプログラムの概要とデータの関連ぐらいはきちんと見える化してほしい。プログラムのコメントもしっかりと書くことが大事だ。