例えば「山田進・堀内一著 データ中心システム設計技法 日経コンピュータ別冊 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最大の特徴であると言えるでしょう。