業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも﹁論理設計﹂とは何か。﹁受注情報だけを管理する﹂という単純なシステム要件があったとしよう。その際、たとえば以下のような﹁論理定義﹂がまとめられることになる。1.業務構成 受注登録業務、受注保守業務、受注照会業務2.データ構成 受注見出しテーブル、受注明細テーブル3.機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば﹁業務構成﹂は﹁いつ誰がどのようにこのシステムを利用するか﹂についての定義のまとまりなのだが、それぞれ﹁いつ(