アジャイルの根底には，大きく二つの考え方がある。一つは，一度の開発でユーザーの要求に対応するのではなく，部分的な機能を切り出して素早く繰り返し対応すること。もう一つは，オブジェクト指向技術を活用して再利用を徹底させることである。多くの方は，前者だけをアジャイルと認識しがちだが，オブジェクト指向をベースにした再利用性も重要な要素である。
この二つの考え方によって高い生産性を得られるのが，アジャイルの魅力だといえる。では，アジャイルによる現行システムの見える化とはどんなものか。これは，三つの観点から整理できる。一つ目は，現行システムの業務構造の明確化。二つ目は，システムのアーキテクチャ構造，特にオブジェクト構造の明確化。三つ目は，過去の変更履歴（どんな変更がどの構造になされているのか）の明確化である。
これら三つの点を明確にすることによって，現行システムが今後の変更要求に対応できる構造かどうかを判定する。これが，アジャイルによる現行システムの見える化のゴールだ。
未処理の変更要求も見える化する
具体的な見える化の手順を，図1に示した。アジャイルではまず，変更履歴や未処理の変更要求（バックログと呼ぶ）の調査から始める。未処理の変更要求も見える化の対象としている点に「おやっ」と思った方がいるかもしれない。これは，現行システムに対する変更要求が少なければ，その後の調査や開発時にアジャイルを導入する必要がないためだ。逆に未処理の変更要求が例えば50件を超える場合などは深刻な状況であり，引き続いて現状調査，設計，実装，テストとアジャイルを適用する価値がある。
変更履歴や変更要求は通常，表形式で一覧としてまとめる。ただし，アジャイルの代表的な方法論である「XP（eXtreme Programming）」のように，各要求を「ストーリー・カード」と呼ばれる紙に書き出してもよい。ストーリー・カードを使うと，各変更の関係を調べたり，同様の変更をグルーピング化したりしやすくなる。
変更がどこに集中しているか
変更履歴と変更要求を確認したら，次にそれらと，業務構造およびアーキテクチャ構造の対応関係を調べる。このステップの目的は，変更履歴や変更要求が，業務構造上どの部分に集中しているのか，アーキテクチャ構造上どのコンポーネントに集中しているのかをはっきりさせることにある。
業務構造はシステムの「論理構造」，アーキテクチャ構造は「物理構造」を意味する。これらの構造を調べるにはドキュメントが必要だが，それが存在していなかったり，不正確であったりすることは多い。そうした場合でも，ヒアリングやソースコードの分析によって構造を明らかにしたい。業務構造の洗い出しが難しい場合は，アーキテクチャ構造だけでもリバース・エンジニアリング機能を持つ開発支援ツールを使って，必ず明確にしよう。
筆者の経験上，変更が集中しやすいのは「HMI（Human Machine Interface）」と呼ばれるシステムの表層部分である。機能拡張時に，現行システムのデータをそのまま使うが，表示方法を新しい技術に対応させたり，表示内容を組み合わせたりすることが多いためだ。携帯電話，モバイル端末，カーナビなど多彩な画面に対応させる変更がその代表といえる。
なお，業務とアーキテクチャの構造は，UMLを使って表すことが多い。ただしUMLでなくても，使い慣れた表記法を使えばよいだろう。このステップで確認すべきは，あくまで業務とアーキテクチャの構造上，どこに変更履歴/要求が集中しているかである。筆者は既存のドキュメントの変更履歴/要求個所に直接，赤ペンで印を付けている。
