トップダウンアプローチのメリットとデメリットを知ろう

実際にトップダウンアプローチでデータモデルを構築する場合、気をつけるポイントがいくつかあります。
どのようなポイントに気をつける必要があるのかを理解するために、トップダウンアプローチのメリット／デメリットについて説明しておきます。

【メリット】
まず、トップダウンアプローチのメリットですが、現行システムのファイル・データベースや画面・帳票類をもとにしないため、「業務的な観点から理想的なデータモデルを構築しやすい。」ということがあげられます。
本来業務としてどうあるべきかという視点でデータ構造を検討していくことになりますので、現状にとらわれない理想的（TOBE）なモデルを構築しやすいというメリットがあります。

２つめのメリットとしては、該当業務に精通した人が参画することで、「大体の内容であれば現状調査を実施しない分短期間でデータモデルを構築できる。」というメリットです。
大まかな内容であれば効率的にデータモデルを構築できる可能性があるということです。
ここでいっている「大まかな内容」というのは、エンティティとリレーションそれからキー項目レベルであれば、効率的にトップダウンで構築することが可能という意味です。
後述しますが、詳細な全ての属性を定義できるかというと、トップダウンアプローチのみでは限界があります。

【デメリット】
次にトップダウンアプローチのデメリットについてですが、

『こういう業務だから…』という、べき論的な作業で作成されるため「実際に業務が問題なく実施できる裏付けに欠け正しいかどうかの評価が難しい。」というデメリットがあります。
べき論（理想論）でデータモデルを構築していくことになります。しかし、ステークホルダー（利害関係者）が全て同じ理想を持っているかというと、通常はそれぞれが、別の理想像を持っています。
では、誰の理想像が一番正しいのでしょうか？
「あの人の意見も一理あるし・・・」「別の人のいうことも良くわかる」ということになりかちで、結果どのようなデータ構造であるべきなのかという評価が困難であるということです。

２つ目に「エンティティの属性項目を漏れなく定義することが困難である。」という点が上げられます。
ビジネスルールで「こういうことをやりたい」「こうあるべきだ」という整理に基づいてデータモデルを構築していきますが、ビジネスルール（文章）をもとに、全ての属性を抽出することはできません。

３つ目は、具体的な入出力媒体（画面・帳票・外部インタフェースファイル等）を意識しないため、「入力されない項目や使用されない項目がエンティティ属性として定義されやすい。」ということです。
ある意味、想像で属性を整理していくことになりますので、必要なデータが入手できるかどうかの裏づけをとらないまま、属性が定義される可能性があるということです。
逆にこううい項目が必要だろうとその時点では、属性として定義していたが、実際には不要な項目であったということもあります。

しかし、実際にはデータモデルの構築だけやるわけではなく、合わせてプロセス（処理）の検討も行っていますので、不要なデータであることが明らかになれば、その時点で削除すればいいだけですが・・・。

最後に「比較的、高いスキルが要求される。」ということです。現行業務に精通した人ほど、現行システムにこだわりやすい傾向があるため本来のニーズを引き出す能力が必要となります。
ここでいうスキルとは、業務要件をデータモデルで表現するスキルということと、コミュニケーションスキルの両方のことを言っています。
もちろん、一人の人が両方のスキルを保有していることが望ましいですが、別々の人が役割分担をして作業を行うことも可能でしょう。

上記を整理すると（表１）のようになります。