論理モデルと物理モデルを切り分けて考えよう！

以前、「システム開発のできるだけ早期の段階で、モデルを利用したシステムイメージの確認（共有）を行うことが、リスクを回避するもっとも効果的な方法なのです。」と記述しましたが、では、何をモデル化（可視化）すればよいのでしょうか？

何を表現するかによって、作成するもの（成果物、モデル）が異なってきます。

業務の中でシステムが何をするのかを表現するために、業務の流れをビジネスフロー図として記述したり、ユーザとシステムのインタフェースを画面・帳票のレイアウトとして定義したりすることになります。

これらの成果物・モデルをシステムの早い段階で、実装環境や手段を検討する前に実行することが重要です。

すなわち、どのように作るか（How）というまえに、まず、何を作るか（What）を明確にするということです。

この、何を作るのか（What）を明確にした成果物のことを、「論理モデル」と呼んでいます。

この論理モデルを作成する開発工程をXprimeでは『上流工程』と位置づけています。

これに対して、どのように作るか（How）を明確にした成果物を物理モデルと呼び、物理モデルを作成する工程を『下流』と位置づけています。

Xprimeでは、システム開発の上流工程と下流工程の境界線は『物理環境を意識するか否か』というところで線引きをしています。

これは、上流工程がユーザに関係のある業務的な要素を対象とするのに対し、下流工程では上流肯定で構築された論理モデルにハードウェア、ＯＳ、ミドルウェア、ＤＢＭＳ、プログラム言語等の物理的な条件を加えてコンピュータシステムとして稼動させることを目的とするべきだと考えるからです。（図１）

業務要件を確認する場合には、システム上の実装方法（物理条件）は、ユーザには直接関係がありません。
業務要件（What）と物理条件（How）が混在していると成果物（モデル）の維持管理が困難になるともに、ユーザにも開発者にも理解しにくくなります。

最後に、論理モデルと物理モデルを分けて考えることのメリットを整理すると以下のようになります。

◆物理情報のブラインド
　物理情報を隠すことによって、常に最新の論理モデルを照会することができます。（常に業務要件の確認が可能となります。）

◆物理情報のリセット
　物理環境の変化によりシステムを再構築する場合、物理情報の変更（リセット）のみで対応することができます。（最小限の変更で対応することができます。）

◆システム仕様の正規化
　システム開発に必要な情報が重複せずに管理できます。