前のページへ サイトマップへ ホームへ
 
DOAコラム一覧へ次のコラムへ
【データ中心アプローチとは】データ中心指向
DOA Evangelist:小見山 昌雄

1.データ中心指向の特徴

 データ中心指向技術とは「〜です。」とか、DOAとは「〜することです。」などと、一言で説明できれば何と素晴らしいことでしょう。
 例えば「山田進・堀内一著 データ中心システム設計技法 日経コンピュータ別冊 1986.8.10号」では、データ中心アプローチを「データを先に設計し、データに基づきシステムやソフォトウェアを設計する概念」とか「システムやソフトウェアの設計にあたって、その構造をデータに基づいて決定する」また「データやデータベースを共有資源とみなす」などと説明されています。
 先の幾つかのコラムで説明した内容を一言で言うと、上記のような表現になり、それはどういうことかを説明するには、あれだけの記述が必要になるということですが、今回は、今までのコラムで、データやビジネス・モデルなどを理解した上で、さてデータ中心とは何かと考えて見ます。
 最初は、それを使った作業の特徴から見て行きます。
 データ中心指向技術を使うかどうか、と言うか、データ中心指向技術を理解して導入しているかどうかが分かる顕著な特徴は「データ管理者(データ管理者⇒Data Administrator(以下DA))」の存在です。
 データモデルの作成だと思いましたか。
 今時は、データベースを使うために、ER図でデータモデルを描くことは常識なので、データ中心指向技術を意識して取り入れようとしているのかどうかの判断材料にはなりません。
 もっとも、私はデータベースを使うことイコールデータ中心アプローチだと考えているので、ERDを描くことは当然だと思いますが、作られたERDを拝見すると、なかなかテーブルのレイアウト以上のものにはお目にかかれません。
 特に驚くのは、関連が描かれていない、データ項目を羅列した長方形を並べて平気でデータモデルだと主張する方たちの存在です。
 もちろん「何故、関連を描いていないか」を質問しますが、何故かこの答えも「物理モデルを描いたものをお持ちしましたので」と画一的で驚きます。
 どこかに、その描き方や顧客の質問に対する回答要領を教えているセミナーでもあるのじゃないかと思う位同じです。
 更に「では、その物理モデルの元になった概念モデルを見せて下さい」と言うと、さすがに行き詰まり、概念モデルを作らなかった言い訳を並べ始めます。
 もちろん、彼らは「概念モデルとは何か」・「何故、概念モデルから作らなければならないのか」について、長々と説明を聞かされることになりますが。
 しかし、データベースやデータモデルについて、何も教えて貰わなければ「なぜ、データレイアウトをこんな形式で描かなければならないのだろう?」と思いながらも、指定された形式に合わせて表現しようと努力した彼らを責めるのはお門違いでしょう。
 さて気を取り直して、データ中心指向を実践する場合に、なぜDAが必要になるのか説明します。
 システム開発プロジェクトは「会社で1回全システムを開発して終わり」などと言うことなどあり得ません。
 部分的な再構築を繰り返したり、新しい機能を追加したり、繰り返し保守改修を行ったりで、大規模なシステム開発プロジェクトが繰り返されたり、時には並行して実施されたりします。
 さて、そのような状況で、さすがに最近は全体の資源配分や納期・タイミングの調整などで、複数のプロジェクトを管理・調整する、プログラム管理なる概念が認知されて来ましたが、そのプロジェクトの母体(例えば企業)が、データ中心指向技術に目覚め、コントロール出来る限り広い範囲のスコープで(実装時は別途最適化を検討するとしても)概念モデルは、一元的に管理したいと考えた場合、当然、プロジェクトを超える一元化機能が必要とtなります。
 それが、ここで言うDA(データ管理者)です。
 当然、各プロジェクト毎に具体的なデータ構造を分析する役割もあるので、DAと言う職務は、企業単位とプロジェクト単位の二つのレベルで存在する必要があります。
 前者をコーポレートDA、後者をプロジェクトDAと呼称し、CDA、PDAなどと略記したりします。
 この二つのレベルのデータ管理者が、相互に連携しながらデータを一元的・継続的に管理します。
 データモデルやデータ分析手法、リポジトリやデータベースの管理などは、一元的・継続的データ管理を効果的に効率良く行うためのツールでしかありません。
 どうですか、過去に経験したプロジェクトやシステムを思い出して下さい。
 データベースの管理者とか、担当する業務で振り分けられたマスターの管理担当者は存在しても、データ管理者に当たる存在は無かったのではありませんか。
 データベース管理者や、マスター管理者は、各業務担当が出した要求を物理的にまとめるしかありません。(ときどき委員会形式でデータベースの要件を決める運営を見受けますが、ほとんど形式的で無意味です。 これが機能すれば、それこそがデータ管理者と言うことですが)
 おまけに、プロジェクト終了後は、組織もうやむやで運用部隊への引き継ぎも不明確で、個別に修正要件を反映するなどと言うことも珍しくないのではありませんか。
 これに対して、データ管理者の管理とは、例えば、新規にデータ項目を設定しようとする場合、以下の対応となります。
 作業番号と作業名  作業概要
 1.申請  まず、申請を希望する担当者は、自分のプロジェクトDAに申請します
 2.PDA検証  プロジェクトDAは、管理するデータ項目を調べ、登録があれば、既登録であることと既登録名を通知します
   登録が無ければ、コーポレートDAに登録申請します
(ここでの確認は、帰属、導出ルール、型、桁などを含めて行い、名称だけを見る訳ではありません)
 3.CDA検証  コーポレートDAは全社レベルでの情報を対象に2と同じ作業を行います。
 4.追加情報の公開  コーポレートDAは、新規にデータ項目が追加された場合は、データモデルを修正し、データベースの変更を指示し、追加情報を公開して使用可能とします
 項目一つ追加するのも結構大変です。
 ましてや、これをシステムが続く限り継続して行くのは大変なことなので、組織的な対応とデータ管理者の継続的育成は不可欠です。
 「やったつもりのDOAが何時か気付けば元の黙阿弥」だったり、「あんなに一所懸命ER図を描いたのに、何故何も変わらないのか」と思う原因は、大概このあたりにあります。
 DOAと唱えると何故かデータの一元化が実現する訳では無いことがおわかり頂けたと思いますが、これらデータ管理者の地道なデータ管理作業こそが、データの一元管理を実現し、システムの保守性低下を防ぎ、システムの長寿命を実現するDOA最大の特徴であると言えるでしょう。
 

2.データ中心指向認識の変遷

 では、世間ではデータ中心指向をどう見ているのでしょうか。
 DOAは最初の段階から、先の説明にあるように、システム設計方として紹介されていますが、私などは、正規化技法と混同しており、しばらくはデータベースの設計技法だとばかり思ってました。
 システム開発技法だと分かってからも、データモデリングをやっている内に、データモデルを作ることは、業務分析そのもので、その分析結果であるデータモデルを元にデータベースを作り、プログラム・システムを作るので、データ中心指向の本質は、業務分析技法だと考えるようになりました。
 しかし、前節で説明したように、その考え方を適用し効果を継続的に実現し続けるには、データモデルさえ作れば良いとか、データベースの一元管理が実現すれば良いなどと言う、単純で局所的対応ではなく、幾つかの要素を組み合わせて、適切に連携・運用しなければなりません。
データ中心指向認識の変遷 そのため、現在では、DOA推進環境やデータモデルの管理環境から、リテラシ普及まで含んだ「データ管理の枠組み」であると考えています。
 その組織的なポイントがデータ管理者であり、技術的なポイントがデータモデルと言うことになります。
 ちなみに、システム業界では、毎年多くのコンセプトが提示され(なぜか、その多くは3文字の英字で省略されて紹介されています)ますが、データ中心指向の部分的な対応、つまり、ここで言う「データ管理の枠組み」の要素を一部分だけ対応する提案が何度か提示されています。(SOA・CRM・SCM・MDMなど挙げればきりがありません)
DOAの適用 部分的な提案に終始するので、その効果も部分的ですが、メーカー・ベンダーとしては、製品やサービスの販売が目的なので、システムの課題を最終的に解決し、保守の生産性を向上させ、システムの長寿命を実現するメカニズムについては、ユーザー自らが気付くしかないでしょう。
 しかし、DOAの効果を聞いて、ベンダーに「じゃ、DOAで宜しく」と依頼しても、その効き目はプロジェクト内に限定されます。
 また、当然、ベンダーの能力に見極めも必要になってきます。
 ER図のレビューに参加して、外形的・内容的問題があれば、それはDOAになっていないと指摘しなければなりません。
 さらに、ベンダー自身の理解が、システム開発技法とか、業務分析技法とかの理解では全社的なデータ管理の統合に行き着くわけもなく、DOAのつもりが、結局、プロジェクトごとに細分化・多重化され、その間の関連や整合性維持に関して、従来同様の負荷が掛り、システム肥大化の火種となります。
 現実問題として、パワーを補填する意味で作業自体は外部委託に頼らざるを得ませんが、データ中心アプローチとして当初期待した効果を実現し、それを継続するためには、社内にデータ管理者のしっかりとした管理体制を構築する必要があることを、ご理解いただけたと思います。


3.データ中心指向の考え方

 さて、最後にデータ中心と言う考え方についてまとめておきます。
 データ中心とは、単純に言えば「データ以外の要素は排除して考えましょう」と言うことです。
 ビジネスは、そのビジネスに関与している色々な存在や、行為・出来事を記録しなければなりません。
 そのビジネスの記録がデータで、通常はビジネスシステムを使って電子的に記録されています。
 そのため、ビジネスやビジネスシステムをどうしたいのかを検討したり、説明するには、データを使ったデータモデル(ER図)を作れば十分なので、ビジネスの分析/設計やビジネスシステムの設計と、データ中心指向は相性が良いのです。
 システムで言えば、「そのユーザインターフェースを実現するには、色々複雑な処理が必要になりますが、取りあえず、データをどう管理(データベース)して、どう使いたい(ユーザインターフェース)かだけをはっきりさせましょう」と言うことです。
 データベースとユーザインターフェースが決まれば、その間のデータの導出や編集の仕様は自ずと決まるので、システムの作りからプログラムの仕様まで自明であると考えます。
 データを記録する手順や仕組は気にせず、何を記録するのかだけを表現しているデータモデルは、文章で書かれたビジネスルールなどに比べて、はるかに容易にビジネスの全体を把握・理解することが可能です。(リテラシの問題はありますが)

 そのため、ビジネスを深く把握・理解することによって、質の向上が期待できるあらゆる分野での利用が可能です。
 なお、抽象化により、データモデルから外された要素も、ビジネス・データ・システムの関係においてビジネスルールを規定する場合に必要無いだけで、最終的なシステムの実装までには、プラットフォームや言語・実装方法論・ワークフローの仕組などを選定する必要があることは言うまでもありません。
 幸い、それらは具体的で可視的な世界である上に、システムの専門家が存在し、標準やベンチマークも明確で善し悪しが分かりやすく、ベンダーに依存し易い部分なので、大いに外部の専門家を活用しましょう。
 その余力をデータ管理に振り向ければ、データ中心指向によるシステム生産性の良循環が実現します。(データ管理者のレベルと関係者へのリテラシ教育の程度に依存しますが)
 丸投げではコントロールが効かなくなり、全て自前ではITの潮流から取り残されシステムの競争力を失います。
 データ中心指向でビジネスとシステムのあるべき姿をデータモデルで押さえ、コントロールの要とした上で、システムの作りの部分は、専門家に任せて新しく生産性の良い技術を適宜採用する使い分けで、品質維持・費用抑制・長寿命化と好いとこどりを実現しましょう。

ページトップへ