以前、 要件定義は相互理解により精緻化される (TakeITEasy 2007/03/06) というコラムを書いた。 これは、システム開発の要件定義一般について書いたものだが、特にシステム移行時の要件定義について考察してみる。

BPR

システムの再構築においては、最初に現行の業務フローをWFA(Work Flow Architecture)などを用いて定義し、 次に、業務およびシステムの最適化という視点で、これをどう改善するかを考え、新システムの業務フローを定義する。 この作業がBPR（Business Process Re-engineering）である。 この時点で、新システムの業務の流れとシステム化の範囲が明確になるとともに、 旧システムの移行対象範囲（機能とデータ）も明確になる。

システムの要件定義の方法として、DFD(Data Flow Diagram)とWFAを比べると、 「システムの利用組織」と「システムと人の作業の境界」 が明確であるWFAの方が情報量は多い。 DFDの方は、逆に、組織というものを考慮せず、全体最適な処理とデータの流れを考えるのに向いている。 ただし、最終的な要件定義としては、どの機能を誰（どの組織）が使うかという定義が必要になるため、 要件定義の際、どちらか一つにするということであれば、WFAであろう。

データモデルが要件の根幹

データモデルを中心にシステムを定義するDOA（Data Oriented Approach)は、オブジェクト指向設計が登場する以前の 古くから使われている手法である。 データがクラスやオブジェクトになれば、UML(Unified Modeling Language)にて記述するということになるが、 筆者は、DOAは、要件定義の中核として未だ有効であると考えている。 なぜなら、旧システムから新システムへの移行を考えるとき、もっとも重要なのは、現在使われており 今後も使う予定であるデータモデルであるからである。 特に業務システムにおいては、複雑な計算はあまり存在せず、データベースへの入力と その参照、帳票出力が、主な処理となる。 よって新旧システムでもっとも共有すべきは、データモデルということになる。

既存システムよりデータモデルをどう抽出するかだが、例えば、RDBMSに基づくシステムは、 往々にして複雑怪奇な物理データモデルを有していることが多い。 これは、最初は、論理的にきれいな（別のいい方をすると適度に正規化された）データモデルに基づき設計を 行っていたのだろうが、例えば、処理性能を追求するために、わざとテーブルを非正規化し、 テーブル結合の影響を受けにくくしたり、システム改修のたびに似たよう異なるテーブルを追加していったり、 あるいは、システムの都合だけの管理テーブルを追加していったりしているうちに 物理データモデルが複雑怪奇となったことが想像される。 これにより、物理データモデルに対応する上位の論理モデルも整合がとれなくなっていることが多い。

よって、既存システムのデータモデルの抽出は、入力と出力のみから、 論理的なモデルを再構築することが望ましいと考える。 世の中の調達仕様書の多くは、機能要件、帳票要件等に加え、DFD、 WFA等により定義されることが多いが これらの根幹をなすものは、やはりデータモデルであろう。 データモデルの表現は、ERD（Entity Rerationship Diagram)でもUMLでもよい。

モデル利用の薦め

調達の仕様書の多くは、特に新規のスクラッチ開発を除いては、 業務フローに加え、 「○○ができること」という機能要件と、帳票要件（帳票一覧および出力項目）を 核にして作成されることが多い。 これは、つまり、システム的なモデルにあまり踏み込まないものとなっている。 ところが、システムは、調達仕様書のみにより構築することは不可能であり、 開発業者決定後の要件定義および詳細設計で、作ろうとするシステムの実像が決まっていく。

画面デザインや帳票レイアウト等の表面的な定義であれば、 大きな問題にはならないが、データモデルの理解が発注者と受注者で全く異なっていると システム開発の手戻りとなり、大きな問題となる。 そのためにも、調達仕様書作成の段階で、極力データモデルを定義しておくことが重要となる。