どうまとめるのか
システムの地図もやはり図的なものになります。UMLなどの図的な方法を使って表現します。UMLと聞くと「実際のシステムは混沌としているのに綺麗なモデルは役に立つのか？」という意見が聞こえてきそうです。あくまでも既存システムの調査分析が目的です。現実のシステムと接点がない地図では意味がありません。
一方混沌としたプログラムに近過ぎると、本質的な機能を表現することが難しくなります。ポイントは「現実とつながりながら現実の混沌に影響されずに整理する」ことです。
そのためにはシステム境界となるインターフェースに着目します。具体的には「画面や帳票」、外部システムとの入出力になります。同じくデータはDBのテーブルと対応させます。この2つで現実のシステムと対応させ、詳細にシステムを調べるときの入口とします。
一方機能はシステム境界とデータとの関係から導き出します。この時の機能はプログラムと対応するものではなく、行っていることを表す論理的なものとします。こうすることで現実のプログラムの混沌に影響されずに真に必要な機能を洗い出すことができます。機能の粒度はパンフレットに載るようなある程度大きな機能（システムが何をしているが分かる粒度にすることが重要）を洗い出します。
次にシステム境界とデータの関係から、システムを駆動しているビジネスルールを整理します。ここで整理したシステム境界が次期システムの要件を組み立てるときの材料になり、要件を決めるための判断材料がビジネスルールになります。
何を表現するのか
システムの地図は8種類の情報で表現します。
- 誰に： 「アクター」「外部システム」
- 何を行い： 「画面・帳票」「外部システムとの入出力」「機能」「データ」
- 何のために： 「ステートマシン図」「用語集」（「概念モデル」「ドメインモデル」）
「誰に」はシステムに関わる人と外部のシステムを表します。「何を行い」はシステムとのインターフェースとなる「画面、帳票、外部システムとの入出力」と「機能」、「データ」で表現します。構造に伴うビジネスルールとして「概念モデル」や用語集で表現し、手続きにともなうビジネスルールをステートマシン図で表現します（詳細は第3話）。
オブジェクト指向に慣れている場合は、これに概念モデルやドメインモデルが追加されます。
情報源は何か
プロジェクトによって入手できる情報には差があります。開発資料が残っていたとしても、詳細度や精度にはばらつきがあります。昔のドキュメントの場合は特殊なフォーマットの文書で読むことが難しい場合もあります。
このようにプロジェクトで取得できる情報はさまざまですが、必要な情報がすべて揃うことはありません。欠けた情報は周辺の情報をつなぎ合わせて埋めていきます。ちょうどジグソーパズルで抜けたピースを探すように情報をつなぎ合わせていきます。
既存システムの分析ではシステムそのものより、今そのシステムがどのように使われているかが重要です。業務の調査と並行してシステムの使われ方もヒアリングします。そして業務が成り立つ仕組みを整理することで、画面や帳票の使われ方が見えてきます。同時に欠けていた情報を補うこともできます。
まとめ
既存システムの調査分析はシステムの地図を作ることだ、という話を書きました。既存システムのプログラムや資料に依存した作業ではゴールが不明確になり無駄な時間を費やす可能性があります。まずはシステムの地図を作るという明確なゴールを掲げ、すべての情報が揃わなければ、揃えられる情報で形をつくり、システムの全体像を把握することを目指します。その上で抜けているピースを探し出し、全体のつじつまをあわせます。地図の作成では「現実とつながりながら現実の混沌に影響されずにまとめる」ことがポイントになります。
冒頭に佐藤さんと木村さんの会話を例として載せました。2人の会話は既存システムを土台にするか、新規に要求から考え直すかの二者択一的な極端な議論です。この会話の問題は具体的な議論に落とし込めていないことです。それは既存システムについての共通認識がなく、議論を掘り下げる材料がないことに起因します。システムの地図を作ることでプロジェクトの実情に合わせた進め方を具体的に議論することが可能になります。
次回は実際の分析方法について説明します。
