全体を俯瞰する
既存システムの分析では、システムを一言で表現することが重要です。そのためにはシステムを役割や働きごとにいくつかのまとまりに分類し、理解しやすくすることが必要です。そして、分類の構成要素が各モデル情報になるようにまとめます。トップダウンでシステムを説明できるように絶えずシステム全体を意識する必要があります。
パッケージに分けて登録する
規模の大きなシステムを扱う場合はパッケージに分類して管理した方が分かりやすくなります。業務が分類されている、もしくはサブシステムに分割されている場合は、その分類に従ってパッケージに分けて管理します。パッケージに分け、パッケージ間の関係が示されるとシステム全体の構成を把握することが容易になり、見通しをよくすることができます。
パッケージ間の関係とは次のような個々の情報間の関係（販売管理パッケージ／受注機能が在庫パッケージ／在庫データと関連する）があるとき、「販売管理パッケージと在庫パッケージが関係する」と考えます。従ってパッケージ間の関係を変えるためには、パッケージ内の個々の情報を移動することで関係が変わります。
理想的にはパッケージ間の関係は疎であることが望まれ、一方向の関係にすることが重要です。しかし、既存システムを対象にしているので、きれいに分類することはほぼ不可能です。ここでは無理矢理一方向性にするのではなく、既存システムの実際の構成と分かりやすさを天秤にかけてパッケージ間の関係を調整します。
図6のパッケージ登録では、パッケージ間の関係を示すことができ、個々の情報をパッケージ間で移動させる機能もあります。この機能を使ってパッケージに含まれる情報を調整し、関係を疎にすることでシステムの機能とデータの見通しをよくします。
全体像を確認する
入出力とデータを機能でつなぐと全体としては図7のようにすべてがつながります。全体を俯瞰してみることで「データ」「機能」の偏りや特徴をつかむことができ、データを中心につながりを確認することで、システム全体の一貫性を検証することができます。全体から部分へ、部分から全体へと視点を変えることでシステムを立体的に捉えることが可能になり、視点を変えながら分析することでバランスよく整理することができます。
図8はアクターを出発点に特定のつながりを確認する機能です。全体を表示してしまうと個々のつながりが分かりにくくなるので、ある情報を起点にそのつながりを順次確認することができます。個別のつながりを確認することでアクターとデータの関わりや外部システムとデータのつながりなども把握することができます。
個々の情報を深掘りするのではなく、つながりを考えることで浅く広くシステムをとらえることができます。実際にプログラムを調べるときは、入出力情報を手がかりに対応する情報からプログラムを探っていきます。ピンポイントでプログラムを調べることができれば調査のスピードがあがります。
システム全体を意識して進める
既存システムの分析はついつい詳細に入っていきがちです。しかし、重要なのはシステムの地図を作成し、システムの全体像を把握できるようにすることです。必要なことはプログラムの機能を知ることではなく、ビジネスとシステムの関わりを理解し、システムに埋め込まれたビジネスルールを明らかにすることです。
「要件のツボ」を使い、全体と個別の情報を交互に確認できれば、個々の情報の粒度をそろえることができ、全体をバランスよく整理することができます。
まとめ
システムの地図を作る上で必要なことは重要な情報に着目し、不要な情報をそぎ落とすことです。そのために少数の記号を使ってシステムを表現し、全体視点からシステムとビジネスの関係を捉えることが大事です。個々の情報を深掘りするのではなく、広く浅く対象を把握します。材料を集め、個々の要素をつなげながら分析します。不明な点やつじつまの合わないところを洗い出し、そこを埋めていく。この繰り返しにより効率的に分析を行うことができます。
既存システムを分析するための明確な手法をもち、ツールを使って素早くまとめる「コツ」をつかめば、大規模なシステムでも一定期間で全体像をつかむことができます。
調べたことが徐々に形になってくる作業は、調査分析に弾みを付けます。既存システムの分析を創造的なものへと変えることで単調になりがちな作業を変えることができます。
今回まではトップダウンでシステム全体をとらえる方法を説明してきました。次回は最終回としてボトムアップで分析する方法を紹介します。トップダウンで分析した結果をボトムアップで検証することで、より精度を上げることができます。
情報源
- 要件定義ツール：要件のツボ
- UMLによる記述方法：RDRA
- 『要件定義マニュアル』 神崎善司 著、秀和システム、2008年10月
