筆者が現行システムの見える化において「RUP（Rational Unified Process）」を用いる理由は二つある。一つは，作業の手順やその成果をすべてUMLで完結できること。全面的にUMLを用いることで，あいまいになりやすい成果物を論理的に一貫した形式で表現できる。
もう一つは，ビジネス分析モデルとシステム・モデルという抽象度の異なるモデル同士をひも付けられることだ。システムはあくまで業務を実現するための手段に過ぎない。そのシステムは業務とともに変化し続ける。こうした状況では，ビジネス分析モデルとシステム・モデルを同期させながら，継続的にメンテナンスできることが重要である。その点，UMLで業務とシステムをマッピングできるRUPは，見える化に向いた手法といえる。
まずはシステムをモデル化する
RUPによる現行システムの分析（As-Is分析）は，システムと業務のモデル化を並行して進め，最後にそれらをマッピングする。システムのモデル化と業務のモデル化は，それぞれ独立して実施してもよい。一方，新システムのあるべき姿（To-Be）の策定は，業務をモデル化したビジネス分析モデルを作り，そこからシステムのモデルを抽出する。基本的な手法は，As-Isの分析と変わらないと思っていい。
稼働中のシステムであっても，どの部署でどの担当者がどのような機能を使っているのか分からないことがある。これを明確にするのが，RUPによる見える化のゴールだ。
図1がその手順である。
まず，システムのモデル化から始める（前述のように業務のモデル化と並行してもよい）。モデル化に利用するツールは「ユースケース・モデル」である。ご存じの通り，UMLではシステムのユーザ－を「アクター」，システムの機能を「ユースケース」として表現する。RUPでは現行システムを「アクターから利用される複数のユースケースの集合体」として記述する。このアクターとユースケースを識別し，定義する作業が最初のステップとなる。
ユースケースには，連続した複数のアクション（処理）を「イベント・フロー」として付与する。システムの利用者が認識できる画面や帳票は，イベント・フローの処理の一部として記述すればよい。
ただし，ユースケース・モデルでは，システムの外部から見た機能要件（外部仕様）しか表現できない。もし保守開発などで内部仕様まで調べる必要があるなら，ソースコードを解析しなければならない。この場合，RUPではリバース・エンジニアリング機能を持つ開発ツールを用意している。これを使えば，（ある程度の）クラス図やシーケンス図を自動生成できる。
