概念データモデルは、業務的な視点で意味の構造を表しています。論理データモデルは、実装するファイルの構造を表しています。
通常のシステム開発では、この２つを別々の工程で作成します。もちろん、まったく無関係にこの２つを作成することはありません。概念データモデルをインプットとして論理データモデルを作成します。
さて、開発が一段落して保守工程に入ると、せっかく作成した概念データモデルが捨てられてしまうことがあります。実装された状況は論理データモデルで理解できるため、これだけ保守すれば良いというわけです。しかし、意味の構造を正しく理解できるのは概念データモデルですから、論理データモデルだけでは不都合なことがあります。場合によると、保守する際にバグを発生させるかもしれません。
私は、保守工程では概念と論理が同一平面状に記述されたモデル（概念と論理を透かして見るモデル）が必要であると思っています。「意味の構造がどうなっているか」「実際の構造はどう作られているか」この２つをいっしょに見れば、正しく保守できると思うのです。
ところで、プログラム仕様書が最新状態で維持されていないという話を良く聞きます。しかし、プログラム仕様書は陳腐化していても、プログラムソースはしっかりと最新状態になっていることは多いものです。良くみるとプログラムソースの中に、業務的な意味を表したコメントがたくさん書き込まれています。これも、一種の「概念と論理を透かして見る」仕様書です。
