「データ中心アプローチ（Data oriented approach−以下DOA）でシステム開発をしましょう」と言われても、DOAに関する解説や説明は抽象的で、何をすれば良いのか困ってしまいませんか？
　そもそもシステム開発方法論とか開発技法と言われるものは、それぞれ得意で都合の良い所だけを主張するので、手順や作業の流れとしては分かりにくいものが多いですが、それにしてもデータの構造に着目してとか、データの流れを整理してなどの抽象的な表現ばかりが並べば混乱してしまいます。
　この【コラム】ＤＯＡの実施ステップでは、具体的なＤＯＡの進め方について、その手順の例をご紹介しています。　

　データ構造を表すもの・データの流れを整理した結果が、ビジネスの構成要素とその関連をER図などで表現した、データモデルを指していることは間違いないでしょう。
　DOAの最大にして唯一の外形的特長が、データモデルの作成です。（もちろん、ここで言うデータモデルは「概念データモデル」【注１】のことです。）
　もちろん、ＤＯＡでなくても、システム開発に関しては、手順書・ＤＦＤ・各種プロセス系フロー図・ワークフローツールなどでビジネスモデルを作ったり、ビジネスルールを特定し、把握し、理解しようと努めます。
　ビジネス上の存在や出来事に関する情報を漏れなく記録【注２】し、ビジネス現場の情報要求【注３】に対し、適時適切に対応するのが、ビジネスシステムの目的ですから、ビジネスの作りやビジネスルールを明らかにするのは当然です。
　と言うことは、ＤＯＡと他の開発方法の違いは、ビジネスルールを把握・理解するやり方の違い、程度の差でしかないと言うことになります。
　また、データベースと言うツールが一般化したために、ＤＯＡを表看板に出していなくても、データベース設計には、収集したユーザーインターフェースからデータ項目をデータ分析（正規化など）してＥＲ図を描くことが、当たり前に行われています。
　ＤＯＡの最大にして唯一の外形的特徴が、データモデルの作成ならば、現状のシステム開発プロジェクトのほとんどが、自覚があるか否かに関わらず、結果的にはＤＯＡでシステムを開発していると言えなくもないでしょう。
　ただし、世のシステム開発プロジェクトのほとんどがＤＯＡ開発をしている割には、巷間言われているＤＯＡの効果である生産性・保守性の向上やシステムの長寿命化に成功したと言う話はあまり聞きません。
　たまに、「〜銀行、ＤＯＡでプロジェクトの生産性アップに成功」などと記事が掲載される事がありますが、中を読むと「１２．５％の生産性アップ」などと書いてあるのでがっかりします。
　このコラムは、実施ステップの説明なので、詳しい話は「コラム【データ中心アプローチとは】」に譲りますが、ＤＯＡの効果の源泉は、ビジネスの構造をそのまま写し取った無駄のないデータベースなので、効果が出ていないと言うことは、データモデルの品質がビジネスのモデルとして通用するレベルに達していないと考えられます。
　また、プロジェクト単位にこそデータモデルを描くようにはなりましたが、データの一元化とか一元管理・共有化と言いながら、それがプロジェクトの中だけの話と言うことなら、結果的にシステム内のデータ一元管理が達成されたとしても、システム間のデータ交換機能が増殖してしまいます。　そのため、結局企業単位、組織単位に見ると、データ重複とデータ交換機能で肥大化した、以前のシステムと大差無いものになってしまいます。
　と言うことで、ＤＯＡの看板を出すなら、先ずは、ビジネスのモデルとして通用するデータモデルを描けなければならず、第二に、管理しうる最大のスコープに亘って、データを一元管理【注４】する管理体制を構築しなければなりません。
　さらに加えると、ＤＯＡはプログラムを作るわけではないので、ビジネスルールの明確化とデータベース以外の部分については、データモデルを活用できる整合性の良いやり方を別途検討し、手順の標準化などをしておく方が良いでしょう。

　【注１】：概念データモデル
　概念データモデルは、「私はこのビジネスをこのように理解しております」と言う考え（概念）をデータモデルとして表現しているもので、概要を表すものではありません。
　エンティティレベルで表現したものが、概念モデルで、詳細なアトリビュートまで明確にするものが論理モデルとの説明がされる場合がありますが、自分の考えがぼんやりして良く見えないのでなければ、データ項目（アトリビュート）も概念の表現には欠かせません。
　そうすると、概念モデルと論理モデルの違いがなくなると心配される方が居られるかも知れません。
　ちなみに、このサイトでは、ビジネスモデルの部分に関しては違いは無いと考えています。
　ただし、実際にプログラムで使う具体的なレイアウト（カラム編成）として論理モデルを考えると、登録年月日などの運用管理に関するデータ項目、適用年月日などの履歴管理に関するデータ項目など、次元の違うモデルからのデータを反映する必要があるので、当該データ項目を加えたものを論理データモデルと考えております。
　【注２】：情報を漏れなく記録
　まだ、磁気テープしか媒体がなかった時代はいざ知らず、今時のシステム開発において、使うデータ項目を洗い出すなど全くナンセンスであり、基本的にデータベース（データ基盤）には、当該ビジネスにおいて発生する（即ち、記録を必要とする）全データを網羅する必要があります。
　この件についても、後付け、思いつきでぞろぞろ発生する、中間値データのために、作業が完結しない場合があるので、ビジネスの記録部分と中間値の峻別し、完了を見極める必要があります。
　【注３】：ビジネス現場の情報要求
　ビジネスの現場からの情報要求には、情報集積度の低いトランザクション単位の操作情報、情報集積度が管理スパン単位の管理情報、情報集積度が全社的で期間的にも長期にわたる分析的・戦略的情報などを含む。
　通常、情報集積度の高い情報要求には、中間値を実装することで処理の軽減を図るが、これらの中間値データ項目と、ビジネスの記録としてのデータ項目の分割管理が整理できずにデータベース設計が混乱することが多い。
　【注４】：データを一元管理
　良く誤解されますが、一元管理は一元実装ではありません。
　コンピュータの能力向上やＤＢＭＳの性能強化で、一元管理＝一元実装と言えなくもない状況ではありますが、ポイントは整合性のコントロールなので、教条的にデータの一元化に固執する必要はありません。

　データモデルは、ER図で表現するビジネスのモデルです。
　モデルを描くからには、その対象を把握・理解しなければなりません。
　DOAでなくても、ビジネスシステムを作ろうと言うなら、対象のビジネスを、把握・理解しなければならないので、担当者へのヒアリングや、事務取扱手続き、各種帳票、画面定義、コード表などの基礎資料の収集は同じです。
　この中で最も頼りになるのが、現行システムの帳票・画面の情報です。
　ビジネス上の存在や出来事に関する情報を漏れなく記録するには、入力ユーザインターフェースが存在し、記録した情報をビジネスの現場で使うには出力ユーザインターフェースが必要なので、現行システムのユーザインターフェースを集めれば、当該ビジネスに存在するデータ項目について、Viewを含めほぼ網羅的に把握する事が出来ます。
　これら収集したユーザインターフェースとデータ項目をもとに、ビジネスの構成要素（エンティティ）やその関連（リレーションシップ）を明らかにして行くのが「データ分析」ですが、このようなデータ項目から分析を進める方法を、ボトムアップアプローチ・ボトムアップモデリング・ボトムアップデータ分析などと称しているようです。
　全ユーザーインターフェースを分析するとか、全データ項目を分析するとか言うと、なにか決死の覚悟で取り組む困難この上ない作業のような印象を与えているようですが、一つ一つのユーザインターフェースの分析は２〜３日の研修を受講すれば、ほぼ誰でも出来るので、ユーザーインターフェース一覧やデータ項目一覧で、あらかじめ全体量が把握出来ていれば、計画的に分析者の大量動員を行う事も可能です。
　また、限られた期間と工数で分析する場合には、ビジネスイベント系の入力ユーザインターフェースを網羅すれば、重要なビジネス要素を、ほぼ１００％網羅できるので、作業量的はキャパシティに応じて、かなりフレキシブルに調整が可能です。
　ただし、最後の総まとめと細部の調整は３日研修した位で出来るものではないので、データモデルの作成作業全体を統制・管理するデータ管理者は、あらかじめ、しっかり時間を掛けて、複数人育成しておく必要があります。
　一時的にデータ管理者を、外部の専門家に依頼する場合も、せっかくの貴重な経験の出来る機会を生かすために、社員を何人か張り付かせ、OJT教育によってデータ管理者を育成する必要があります。
　誰も読み書きできない謎のデータモデルを置いて行かれても困りますよね。

　さて、モデリングにボトムアップと言うからには、トップダウンもあるだろうと思うのが人情です。
　当然、トップダウンの方が扱う情報量が少なくて、早く出来るような気がします。
　ボトムアップが、データ項目とユーザーインターフェースを地道に分析して、エンティティと関連を明らかにして行くのに対し、ビジネスルールが既知のものであれば、それをモデルに書き換えるだけなので、簡単でスマートなやり方に思えます。
　しかし、残念ながらデータモデルの作成に関してトップダウンなどと言うことはあり得ません。
　なぜなら、そのビジネスルールを記録し、保守し、継承する方法がデータモデル以外に存在しないからです。
　ホストでCOBOLでウォーターフォルの時代、システム開発プロジェクトと言えば、紙の洪水【注１】だった事を覚えておられる方も多いと思いますが、あの設計書やら手続きやら、仕様書やらの束が、いわゆるビジネスルールです。
　もっとも、システムやプログラムの作りの部分や、同じレイアウト図をあちこちに挟んだり、ほとんど書くことが無くても規定通りの様式で編集するので、量的には幾分割り引いて考えないといけないとしても、とても継続的に保守出来るものでは無い事は、容易にご理解頂けると思います。
　つまり、そのような情報量のものを、生きた情報として使いこなすには、データモデルに作り込むしかありません。
　と言うことは、トップダウンとは、データモデルからデータモデルを作ると言うことなので、既にデータモデルが存在するなら、ビジネス自体が変わっていなければ、再作成の必要は無いし、データモデルが無ければ、ボトムアップで作るしか無い【注２】と言うことになります。
　ちなみに、世間には、驚いた事に、トップダウンアプローチでデータモデルを描く方法を説明している書籍やサイトが、結構沢山存在します。
　内容的には、エンティティと関連が、既に描かれている所にデータ項目を属性として配置したり、「まずER図を描いて」とか、汎用的なひな型モデルを用意してなどと説明されています。
　なぜか、アトリビュートの仕分けにしか興味が無いようですが、エンティティとアトリビュートの関係は自明なので、頭を使う話ではありませんが、仕分けの基になるＥＲ図を、データ項目に指一本触れないで描くなどと言う事が、本当に出来るんですかね。？
　ひな型持って来たのでは、すでにそのビジネスのモデルでは無いし。
　トップダウンデータモデリングって言う、ビジネスルールからデータモデルを描く方法自体は確かに存在し、このサイトでも解説していますが、ビジネスルールを列挙出来るような規模や範囲の話なので、部分的・概要レベルでは威力を発揮しますが、これを習得して全社モデルを描いてやろうと思っても、効果的に全社モデル分のビジネスルールを供給する情報元は、下記【注２】以外には無いので、無謀な事は考えない方が良いでしょう。
　なお、具体的なデータ分析の方法・手順・ポイントについては、さすがにコラムで簡単に説明することが出来ないので、実習を伴った、研修セミナーをご利用下さい。
　【注１】：紙の洪水
　紙が電子媒体に替わっても、テキスト情報の管理が難しいことには変わりはありません。
　複写や配布が容易になった分、情報の保守・同期制御が複雑になり手に負えなくなります。
　ダイアグラムを多用しても、作業途上でテキスト情報を使うのは避けられませんが、ＤＯＡではシステム開発での分析・検討の結果も、当然一元管理共用化の対象なので、リポジトリなどの情報管理ツールに移管したら、テキスト情報は廃棄してしまいましょう。
　そのためにも、ＤＯＡでは、データ項目単位、エンティティ単位、関連単位などで管理できる情報は、全てそれらに関連付けて一元的に管理する仕組み（リポジトリなど）を使います。
　【注２】：ボトムアップで作るしか無い
　実は、ビジネスルールを維持・管理する機能を持つものが、データモデル以外にもう一つあります。
　それは人です。
　お決まりのヒアリングと言うやり方は、人がビジネスルールを保持していると言う前提で行われている訳です。
　しかしながら、ビジネス自体の巨大化・複雑化に伴い、以前のように「何でも聞けば教えてくれるビジネスルールのキーマン」の存在はあきらめるしか無いようです。
　しかし、部分的・断片的ビジネスルールを持つ人を大勢集めて相互に抜け・漏れを補完すれば、一連のビジネスルールにまとまる可能性はあります。
　実際のモデリングもボトムアップで描いた後に、担当者へ説明（業務担当者は通常データモデルをそそまま読む事が出来ないので）しレビューを受けますが、これは「一応担当者にも見せました」と言う、アリバイ的な手続きを踏んでいる訳ではなく、暗にこの、人が持つ（っているはず、いや、持っていてほしい）ビジネスルールの知識をあてにして、行うことなのです。
　データモデルは、ビジネスを可視化したものなので、コミュニケーションを円滑に進めるためにも効果があると言うことです。

　データモデルは、作って終わりではありません。
　データモデルを作り、継続的に管理して行くには、それなりの人材と体制が必要になります。
　逆に言うと、それなりの人材と体制の無い所に、一時的に参加した専門家が作ったデータモデルを置いて行かれたのでは、データベースの保守もままなりません。
　例えば、新規追加が申請されたデータ項目が、ビジネスの記録（ファクト）なのか、ビューなのか、既に存在するのか、異音同義語はないか、同音意義はないかなどを判断して適切な指導を行えないと、データモデルの品質維持が困難になり、システム寿命を思ったほど延命する事が出来なくなってしまいます。
　これを担当する人材をデータ管理者（Data Administrator-以下ＤＡ、DBAとは職能が違います）と呼びます。
　また、データモデルはシステム開発プロジェクト単位に作りがちですが、それぞれのプロジェクトが独立して作業したのでは、作業が重複するだけでなく、結果としてのデータモデルも重複を前提に作っている事になってしまいます。
　その上、各プロジェクトでそれぞれ独自にデータ項目の命名ルールやデータモデルの作図ルールを決めたのでは、決めないよりは幾分ましとは言え、全社レベルでの混乱は避けられません。
　円滑なＤＯＡ推進には、最終的にデータの一元化を目指す範囲を全体的に統括する組織が必要になります。
　このため、データ管理者は、全社を統括するコーポレートＤＡと、プロジェクトごとに作業するプロジェクトＤＡの２階層に分かれてＤＯＡを進めることになります。
　データモデルは全社の統一ルールで管理された全社モデルをベースに必要に応じてプロジェクト単位に部分的な追加・変更を許可する対応で、独立した独自モデルの作成を許すことはありません。
　一般的なユーザ企業にとって、あるプロジェクトだけをＤＯＡで進めるなどと言う事は、意味の無いと言えば言い過ぎかも知れませんが、効果が小くなる事だと、ご理解頂けるかと思います。　

　ＤＯＡの進め方に関して、ある程度ご理解頂けたと思いますので、ここで、データモデルの作成とデータ管理体制の整備を中心に、ＤＯＡを進める手順を一覧表に整理しておきます。　

　　【注１】：ＤＯＡに基づく
　ＤＯＡの基本形である、データベースに一元化したデータとのやりとりで機能を果たす型の遵守、中間ファイルは原則禁止（特定のユーザインターフェースの実現経路に限定した使用は可）、導出計算はＤＢの定義で対応させ共有するなどを。実装言語やツール、ＤＢ機能などを考慮して規定する