量に対応する
システムを分ける
システムの地図は入出力からデータまでを機能でつなぎ、データ構造と入出力の手続きを表した図で補完します。ある程度規模の大きなシステムの場合はパッケージに分けてシステム全体を俯瞰（図4）できるようにします。システムの地図において大事なことは、システムの役割や価値を一言で表現できることです。その時にパッケージ図を使用します。
各パッケージを業務分類で表すのかサブシステムで表すのかはプロジェクトの状況により分かれます。既存システムがサブシステムに分割されている場合は、そのサブシステムを採用します。しかし、一枚岩で明確な分類がないシステムもあります。そのような時は業務で認識されている分類を活用します。業務自体も明確に分かれていない場合（作業に名前がついているだけ）はERPパッケージによく出てくる分類を活用します。いずれにしてもシステムを分類し、理解しやすくするために分けることが重要です。
対象システムがきれいに分類されていることは希で、ほとんどの場合は明確な区切りがありません。そのような状況にあっても意識的に画面やデータをパッケージに分けて役割を明確にしていくことが既存システムを理解していく上で重要です。単純に画面、帳票やデータを羅列したのでは既存システムを分析していることにはなりません。
ネタを揃えて重要なものを抜き出す
画面とテーブルの数が1,000近くになるシステムもあります。そのような場合は全てを対象としてはいけません。まずは業務やサブシステム毎に分かる範囲で分類します。次にパッケージ間の関係も整理します。出来るだけ1方向の関係になるといいのですが、既存のシステムを対象にしているので双方向になることがほとんどです。
次に分類した各々のパッケージの中で主要なものを対象に検討を行います。主要なものとは、業務が一通り回るために必要なものを指します。
例えば販売管理と債務管理に分けたら、今度は各々の中で主要なものを見極めて、それらを対象に記述パターンに従ってつなげていきます。そして徐々に範囲を広げて行きます。一通りシステムの機能が洗い出されたところで終了します。つまり、残った画面やデータは「主要なものではない」ということで分離します。
システムを分類すると図5のようなパターンになることがあります。システム全体の共通的なパッケージと個別の機能を持ったパッケージに分かれ、個別の機能をもったものの中には似たような機能として整理できるものがあります。例えば販売管理の中にサービス1、サービス2のようなサービスとして同じような構造のものが出てくる場合があります。そのようなものは横展開するものとして扱い、典型的なもの1つを分析しその他のものは調査対象から外します。こうすることでシステムのすべてを調査するのではなく、典型的な部分だけを調べるなど、作業を省力化することができます。
トップダウンで全体の見通しをよくする
規模の大きなシステムの場合は30以上のダイアグラムに分かれることも少なくありません。そのような時はサブシステムあるいは業務毎に分けられたトップレベルのパッケージ図を出発点に、徐々にブレークダウンするような構成としてまとめていくことが重要です。一つのダイアグラムが巨大にならないようにパッケージに分け、分けたパッケージを階層化して整理します。
UMLツールの多くがパッケージアイコンをダブルクリックすることで、そのパッケージの定義に進むことができます。そのような機能を使ってシステムをトップダウンでナビゲートできるように構成することで見通しがよくなります。
まとめ
今回はUMLを拡張した表記方法を紹介しました。既存システムを分析する割には、プログラムをほとんど参照しない手法ということを理解できたと思います。
プログラムには貴重な情報もありますが、そこに引きずられると「木を見て森を見ず」になってしまいます。入出力とデータから機能を洗い出し、データ構造を把握し、入出力とビジネス上の状態からシステムの振る舞いを整理します。プログラムを調べなくてもシステムについて調べられることはたくさんあります。システムを広く網羅的に調べることがシステム理解の早道になります。
次回は要件定義ツールを使ったより簡単な方法を紹介します。今回は普段からUMLを使っている方を対象としていましたが、次回はUMLになじみのない方を対象にしたものになります。
