日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。

中山裕美子（なかやまゆみこ）
日本アイ・ビー・エム 技術ソフトウェア・エンジニアリング主任 ITスペシャリスト

　「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。

　本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範囲）を早い段階で明確にし，新システムに対する要求仕様を確かなものにしたうえでユーザーと合意しておくことが最重要である。しかし実際には先を急ぐあまり，これが行われないまま，あるいは，どのように要件を決めていけばよいか分からないまま，開発を進めてしまうことが多い。これでは冒頭に挙げたような状況はいつまでたってもなくならない。

　要求仕様を確かなものにするための実践的な要件定義の進め方を，多くのシステム開発で実績を持つ日本IBMの「IBM-DOA（Data Oriented Approach，データ中心型アプローチ）」に基づいて説明する。

必然的に生まれたDOA

　DOAという言葉は，システム開発に携わるエンジニアなら一度は聞いたことがあるだろう。DOAは，もともとクリス・ゲイン/トリッシュ・サーソンの著書「Structured Systems Analysis」（1977年）と，ロングセラーになったトム・デマルコの著書「Structured Analysis and System Specification（構造化分析とシステム仕様）」（1978年）に端を発する考え方である。ちなみにDOAという用語は，1980年代の初めに提案された“和製英語”なので，欧米のITエンジニアにはそのままでは通じにくい。

　DOAは，システム開発の重点がデータベース設計に移行した時代の流れに対応する形で，必然的に生まれた考え方である。

　DOA以前は，「このシステムは，販売，仕入，在庫管理，顧客サービスを含む営業業務を対象とする」，「販売業務には受注，集荷，納品，請求の機能が含まれる」といったように，単に機能名称を羅列したり文章で記述していた。しかし，システム化の対象となる業務の種類が増えその規模が巨大になるに従い，こうした方法では業務の本質的な仕組みや体系を「仕様（Specification）」レベルで十分に表現できなくなった。

　これに対してDOAでは，対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進める。具体的には，業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram），データ項目の集まり（エンティティ）とエンティティ間の関連を図で表現するER図（Entity-Relationship Diagram），データの正規化＊2，複合設計/構造化設計＊3などの手法を組み合わせる。

様々なタイプがあるDOA

　ただし，一口にDOAと言っても様々なタイプがある。例えば，（1）企業/業務にとっての「あるべき姿」としてのER図を最初に作成するトップダウン型，（2）現行業務のファイルやデータベース，画面，帳票からデータ項目を抽出して正規化したうえでER図を作成し，新システムで扱うエンティティやデータ項目を付け加えていくボトムアップ型，（3）ER図とDFDを別のチームが同時に作成した後で両者をつき合わせる手法――などである。

　しかし，トップダウン型では最初に作成した概念レベルのER図から業務で実際に必要となるデータ項目に落とし込む過程が大変難しく，行き詰まるケースが多い。ボトムアップ型は，データ項目数が少ない小規模なプロジェクトには適用できるが，大規模開発での実績は少ない。ER図とDFDを並行して作成する手法も，通常は両者の成果に大きな食い違いが出るためチーム間の主導権争いが発生し，議論が収束せずになかなか設計に入れないケースが多い。

　このため日本IBMでは，プロジェクトでの実践ノウハウを取り入れながら，上のいずれの手法にも当たらないDFD主導型の構造化手法を採用している。