【DOAソリューション】-データ中心アプローチの実践

　　　　　　　　　　DOAソリューションとは

　データ中心アプローチは、良く「システム設計」の技法として紹介されている。
　確かに、システム開発プロジェクトの単位で考えると「システム設計」の技法に違いないが、その効果の源泉はデータの一元管理にある。
　「データは幾ら使っても減ったり無くなったりしないので、一つを全体で使えば良い。」と言う原理に基づいて、情報システムの処理を考えると、データを一元管理するデータベースと、データを入力・検索するためのユーザインターフェースと言うシンプルな処理構造となる。

　この構造の中で、データベースはビジネスに必要なデータの全てを記録するので、過去の何時の時点にでも遡って状態を再現出来る。
　そのため、締めや月末など、特定の時点のViewを作っておく必要がないのでバッチ処理が激減する。
　また、中間ファイルやローカルマスターなどを持つ必要も無い。
　そのため、システム規模が一般的に70％以上縮小する。
　しかし、御察しの通り、これらの効果は、単に品質の良いER図を描いただけで、自動的に実現すると言う訳ではない。
　また、部分的にデータの一元管理を実現するためには、プロジェクトを、小さく限られたスコープで行えば簡単だが、その様な小さなサブシステムが沢山出来ると、逆に、サブシステム間のデータ連携が複雑・肥大化し、システム全体の負荷を上げてしまう。

　そのため、データ中心アプローチの効果を拡大するには、可能な範囲で段階的にスコープ内のシステム・サブシステムを統合して行く必要がある。
　
　確かに、情報システムの肥大化・複雑化・冗長性・保守性など、システム運営の根幹に関わる根の深い問題に対する最終的な解決は、データ中心アプローチしかないが、ER図によるデータベース設計など、一般に紹介されているＤＯＡの技法を実践しただけては、最終的な問題解決には至らない。
　体制・環境・教育を含む情報システムの運営全体を、データ管理の徹底とその継続に向けて整備・充実することが必要となる。
　ＱＭＳやＩＳＭＳをご存じの方は、ＱＭＳやＩＳＭＳと同様、ＰＤＣＡによる継続的なスパイラルアップを目的とするＤＭＳ（Data Management System）と言う形でイメージすれば理解し易いだろう。
　ここでは、それらデータ中心アプローチの効果最大化を狙った活動全般を「ＤＯＡソリューション」として紹介する。

参考：データ中心アプローチの実践レベル
　最終的には、企業や組織がコントロール出来る、最大スコープ内にある全データの一元管理がゴールです。
　しかし、一挙にそのような高度なデータ管理を実現する事は困難です。
　もちろん、中小の情報システムでは、規模的に容易に達成可能なのですが、規模が小さいと、肥大化・複雑化による問題も小さいので、なかなか事前にはやる気にならないようです。
　ここでは、段階を踏んで進めるデータ中心アプローチの実践レベル例を説明します。
１．対応なしー従来通りユーザインターフェースとデータファイルを作り続け、肥大化・複雑化が進む。
２．プロジェクト単位ープロジェクト単位の一元化アプローチ採用。バックグラウンドの連携機能肥大。
３．データ管理ポリシーースコープ内での一元化方針を策定。
４．データ管理体制ーデータ管理部隊を組織化し、ノウハウの提供と全体のコントロールを実施。
５．ゴールースコープ内データ一元管理の実現と維持管理体制の確立。

　　　　　　　　　　DOAソリューションの障害

　ＤＯＡソリューションの難しさは、システムやプログラムを作って解決すると言う、従来のソリューションからすると異質な、データを整備し管理すると言う考え方が、説明すれば分かると言う簡単な問題では無い所にある。
　IT業界と言う所は、新しい技術やコンセプトが次々と発表されている半面、結局、それらの技術やコンセプトを古いパラダイムの中でしか使えていない所がある。
　データベースと言いながら、昔ながらのファイルシステムとしてしか使えていないなどはその典型だが、プログラムを早く多く作る事が、IT業界の集約体質とマッチして、良いことだとして来たパラダイムに真っ向から対立するデータ中心指向は、最新の技術を理解するよりはるかに難解と映るらしい。（時に、不純な動機で意識的に無視しているのではなかろうかと思われる時もあるが）

ビジネスシステムの目的
　ビジネスシステムの目的は「ビジネスの支援」と明快だ。
　ビジネスシステムは、文字通りに情報処理を行うものなので「ビジネスの支援」とは、ビジネスの円滑な運営と、ビジネスのライフサイクルに応じた適切な判断を容易に行うための情報提供と言う事になる。
　では、次に、目的を果たすシステムの開発方法の違いを比較する。

従来のシステム開発方法
　コンピュータの商業利用が始まった当時は、当然ながら電子化されているデータは存在しない。
　また、ハードディスクのようにデータを常駐させ、随時アクセスを可能にする環境もなく、データは磁気テープからレコード単位で、順番に読むしか方法がない。
　そのような環境の中で、今、提供しなければならない情報を、編集・出力するには、どのデータを電子化すべきかと言う事を検討する事が、システムの性能や効率に大きく影響する設計上の重要事項となる。
　そこで、システムを開発する場合の、具体的な設計作業【注１】の開始は、ユーザインターフェース設計からと言う事になる。

【注1】：具体的な設計作業
　実際のシステム開発プロジェクトでは、具体的な設計作業以前に色々な作業を行うが、具体的な情報として後続工程に継承されるものは少ない。
　もちろん、作業標準や開発環境などについては、決まっていないなら検討する必要はあるが、その他多くの要素と同様、プロジェクトの一環として行わなくても良い作業、さらに言うと、企業や企業グループなどの大きなスコープで、事前に標準化しておけば良い事項について、プロジェクト単位で決めたり、プロジェクトのタイミングで検討するのは、おかしな話である。
　少なくとも、それらの標準作業に関しては、何らかの実績があり、費用や工数・期間・所要スキルなどが明らかになっていないと見積を行う事も出来ない。
　よって、実績が無い技法やツールを適用する場合はテスト使用などで、見積の基礎データを収集する位の周到さが欲しい。

　つまり、最初にユーザインターフェース毎に、必要なデータ項目が決定され、そのデータを提供する主なファイル（中間ファイル）が設定されると言う段取りでシステム開発が進む。

　そうなるとプログラムを作るのは簡単だ。
　何しろ、作ろうとする帳票に最も都合の良いデータ構造を持ったファイルが前提だから話は早い。
　例えば、地区別・支店別・担当者別・取引先別売上金額集計表を作るためには、地区別・支店別・担当者別・取引先別にソートされた売上データを中間ファイルに持つので、プログラムは簡単なコントロールブレーク処理で出来てしまうと言う訳だ。
　しかし、全く同じデータをあちこちに持つと、データの正本と複写の関係がはっきりしない。
　そのため、取りあえず良く使われるデータ項目を集め、マスターと言う建前上の共用データを設定することになる。
　もちろんマスターと言えども媒体は磁気テープだ。

　例えば、前述の例で、リスト上に地区・支店・担当者・取引先それぞれの名称を印刷する必要があると、それぞれのマスターから名称データを読まなければならない。
　印刷時にその場で読もうとすると、中間ファイルと、地区マスター、支店マスター、担当者マスター、取引先マスターの多重マッチング処理となり、磁気テープのリールを５つも専有する上、磁気テープに記録されたマスターそのものも専有してしまうので、これらマスターを使う処理があると全て、今の処理が完了するのを待たなければならない。
　印刷出力のスプーリング機能も無かった時代では、最も遅い印刷処理で、無駄に大量の資源やデータ（マスター)を専有されると、高価なコンピュータのスループットを下げてしまう。
　ならばと言う事で、このような環境では、締めや月末の更新処理で、事前に最新状態に更新したマスターから、追加更新分のデータを反映して、中間ファイル上に、名称を始め印刷処理に必要な全てのデータを持つような仕様に成らざるを得ない。
　共用データと言っても、直接データが必要な時点で共用する訳では無く、データを複写する元データとして共用すると言う訳だ。
　こうして「ユーザインターフェースを実現するアプリケーションが、使い易いデータ構造を持つファイル」を用意する事が重要なスキルとして、システムエンジニアの集団深層心理に焼き付けられ、記憶媒体が磁気テープからＤＡＳＤに変わり、ファイルシステムがＲＤＢへと変わる中でシステムエンジニアのビリーフとして継承される事になる。

データベース前提のシステム開発方法
　現在では、データベースを前提にしてシステムを構築するが、既に電子化されていないデータは無い。
　新システムを言うまでもなく、現行システムで既に全てのデータが電子化されているのだから、どのデータを電子化するか迷う必要は無く、全てのデータを、如何に無駄なく関連付けて持つかを考えれば良い。
　データベースをその定義「複数の目的で共用する、相互に関連づけられた冗長性の無いデータの集まり」の通りに整理しておけば良いと言う事だ。
　全てのデータはデータベースにしか存在しないので、全てのユーザインターフェースを実現するアプリケーションは常にデータベースに直接アクセスする事で、最新のデータだけでなく、過去の何れの時点にでも遡って再現する事が出来る。
　全ての売上データが時系列に記録されているなら、ある支店の先月分の売上合計を求めると同様に、去年の同月売上合計でも、一昨年の５月の売上合計でも、任意の時期の売上合計の計算が出来ると言う訳だ。
　ならば、従来、データ更新のタイミングを計って、バッチ処理で作っていた大量のView系ユーザインターフェース（使うかどうかも怪しい集計表・統計表の類や、様々な視点からの指標など）は、必要な時点で、必要な対象データだけを抽出して処理すれば良いと言うことになる。
　つまり、月末や締めのバッチ処理は無くなり、処理の負荷を平準化するので、従来、ピークに合わせて装備していた機器の能力も余裕が出来ると言う訳だ。
　これは一つの例に過ぎないが、データベースを使うと言う事は、本来、使い方も含めて従来の情報システムの在り方を根底から変えてしまうものだ。

処理方式の転換
　従来のシステム開発方法に比べて、データベース前提のシステム開発方法の方が、無駄も無く、間違いも少なく、データの齟齬も起こり難いであろう事は、このコンピュータ利用の歴史の流れの詳細を知らなくても、一目で明らかである。
　両者を比較すると、従来のシステム開発方法では必要だった、大量の中間ファイルと大量のマッチング処理が、全てのデータを直接データベースから取得する事で、無くなっている事が分かる。
　しかし、一度システムエンジニアの集団深層心理に焼き付けられた思想は、簡単には変わらないらしい。
　例えば、中間ファイルと言う形を「～推移テーブル」とか「～状態管理テーブル」などとして、データベース内に持ち込もうとするケースすらある。
　ＤＯＡソリューションの難しさはここにある。
　つまり、単純な知識の伝達やスキルの修得以前に、エンジニアの脳裏にビリーフとして染み込んでいる考え方を変えていかなければならないのだ。
　データ管理者など、データ管理の中心となる少数の者を対象としていたのでは埒が明かないと言う事だ。
　もちろん、データ管理者を中心として推進体制を構築するのだが、開発者・利用者などの関係者も必要に応じて、対象として教育し、考え方の理解やスキルの修得を求めて行く必要がある。
　また、教えたからと言って、すぐに対応できる訳でもないので、通常、機能や遵守事項のレビューを行う体制の中に、データ中心指向に反する処理を組み込んでいないかを確認する機能を追加し、データ中心アプローチがビリーフとして定着するのを促進する。

　　　　　　　　　　DOAソリューションの種類

ＤＯＡソリューションは、その中心は教育と作業支援の仕組み作りが中心となる。
　それぞれの組織が、現在おかれている状況に応じて様々なレベルの教育と、仕組みの整備を行う。

	認識段階	状況	代表的ソリューション例
１	ＤＯＡ前段階	・データ中心アプローチの存在や必要性を認識する以前の段階。	・情報システムの課題認識・データ中心アプローチの考え方・作業管理システム（工数把握など）

２	データベース設計段階	・データベース設計スキル修得の必要性を認識する段階。	・データベース設計・データ管理システム・作業基準

３	環境整備段階	・データ管理作業自体の生産性向上と継続性の必要を認識する段階。	・モデリング作業環境整備・ＤＯＡリテラシ・モデルの変更管理/ＤＤＬ自動生成

4	プロジェクト実施段階	・データ中心アプローチで情報システム開発プロジェクトを実施する段階	・ＤＯＡ指標設定・移行中心設計・テストデータ

5	リポジトリ段階	・運用管理の統合ツールとしてリポジトリの必要性を認識する段階。	・リポジトリシステム・文書/データ一元管理・データ管理体制

6	データ管理ポリシー段階	・スコープ内の一元化推進の必要性を認識する段階。	・データ管理ポリシー・案件管理システム・情報戦略

　以下、各段階別の説明する。

　　　　　　　　　　（１）DOA前段階

　
　システムの肥大化・複雑化・保守性低下などを問題として認識し、不満や不安はあるが、システム部門の能力不足のせいなどとし、問題解決が棚上げされている様なケースが該当する。
　また、情報システムの生産性を、プログラムの生産量と混同し、生産性の良いソフトウェアーエンジニアリングの適用で、問題を解決しているつもりが、更に肥大化を加速する事で、問題を大きくするような場合も含まれる。
　不満はあるので、その解決を専ら専門家への委託で解決しようと、コンサルタントの導入や、情報戦略の策定や上流工程の分析などまでもメーカーやSierに委託したり、ＥＲＰ・ＤＷＨ・ＣＲＭなどの技法やツールの適用で何とかしよう等と、お門違いな対応を繰り返し、データ管理の構造をさらに複雑【注2】にしている組織体に対しては、複雑化や生産性低下の状況と、データ管理の状況を確認する所から始める必要があるかも知れない。
【注2】：複雑
　個別機能の実現を目的とするベンダー毎の閉鎖的なシステム開発や、個別に専用データベースを持つツールの導入などは、必ずデータ連携機能の複雑化が伴うので、スコープ全体としてのデータ一元管理の方向性に逆行し更に運用を困難にする。

　この段階の具体的なソリューションは、気付き、啓蒙のための教育が中心となるが、現行システムに対する問題認識が無い場合などは、情報システムの状況を認識するための、システム監査やシステム案件別に対応工数を把握するシステムの導入などが必要となるケースも考えられる。
　但し、具体的な状況変化（保守の生産性低下状況など）を追跡するためには、様々な指標を時系列で採取する必要があるので、現行管理システムに現状を把握するための情報が無ければ、少々時間が掛る事になる。
　そのような場合には、一般論としてビジネスシステムは、データベースを中心んとしてデータ管理を如何に充実して行く必要があるのかと言う、一般論で社内世論を形成する手段もあるので、状況に応じて、早く気付く方法を検討することになる。

　　　　　　　　　　（２）データベース設計段階

　気付きがあれば、ソリューションの提供は話が早い。
　データを一元管理しなければならないと気付けば、データ分析/データモデリングのスキル修得は必須だ。
　データ中心アプローチのコアスキルがデータ分析/データモデリング（＝データベース設計）である事は間違いないが、動機がどうであれ、データ分析/データモデリングを習得すれば、データ中心指向と言う、新しい視点を持つことになり、データ管理を中心とした新しい情報システムの形が見えてくる。
　と言うことで、ここで、責任を持ってデータ中心アプローチを進めるには、どうしても組織としてデータ分析/データモデリングのスキルを習得する必要がある。
　理由は簡単だ。
　データ中心アプローチの効果を理解し、必要性を認識し、ベンダーにデータ中心アプローチを依頼しても、データベース設計の品質や実装の妥当性・処理方式の親和性などを見極める能力が無ければどうだろう。
　残念ながら、この業界には品質保証のマークも、原材料の表示も無いので、成果物が自分の要求する方法・品質・機能を満たしているかどうかを見極めるには、自分で判断するしかない。
　もちろん、直接的な検証作業に関しては専門家の手を借りる事も可能だが、その場合ですら、少なくとも専門家が指摘した内容を理解し、それに対する対処方法を検討する能力が無ければ、評価自体に意味が無い。
　つまり、最終的に利害を一にする組織内に、信頼できるスキルの保有者が居なければどうにもならない。

　この段階の具体的なソリューションはデータ分析/データモデリングのスキル教育となる。
　但し、データ分析/データモデリング教育は、一部のデータ管理者が理解すれば良い訳ではない。
　例えば、せっかく作ったデータモデルから、データ関連によるアクセスパスや、関連の多重度によるチェック要領などが読み取れないと、仕様と言う形で情報提供する必要が生じる事になる。
　実は、これも情報の重複であり、保守性低下の原因となっている。
　文書ベースで情報を連携しようとする巨大プロジェクトが、変更管理がネックで作業が頓挫する例も多い。
　それを防ぐには、データ管理者と同じレベルとは言わないまでも、せめて、データモデルを読むことは、大部分のプロジェクト関係者の前提知識とする必要がある。
　と言う事でデータ分析/データモデリング教育は質と量の両面から充実を図る必要がある。
　また、教育と並行してデータ分析/データモデリングの方法と関連する命名基準などの整備を忘れず行う必要があるが、当初、頻繁な事例や表現の追加が行われる事になるので、変更管理と情報共有の方法についても準備しておく必要がある。

　　　　　　　　　　（３）環境整備段階

　ＤＯＡ関連の作業は、生産性が低くて良い訳は無い。
　データモデリングの作業は、プロジェクトの期間、及びシステムの保守期間を通じて、情報システムの変更を反映して繰り返し実施されるので、その作業自体の生産性向上を目指す必要がある。
　教育を受けて、データベース設計のスキルが持てましたと、勇んでデータモデリングを行うのは良いが、通常、全社ベースのＥＲ図は、エンティティが５００～６００、アトリビュート【注３】は２０００を超える事になるので、Ｖｉｓｉｏやエクセルを使って作図していたのでは、規模にもよるが、全体図を描くことも難しい。
　先日、インターネットで「ＷｏｒdでＥＲ図を描く刑を申し渡す」と言うジョークを見たが、生産性を言えば、エクセルやVisioも似たようなものだ。
　多分、サブシステムや特定範囲のＥＲ図しか作っていないか、参考資料としてのＥＲ図なので、全体図や図面統合、関連情報の管理やＤＤＬのジェネレートの必要性を感じた事がないのかも知れない。
　また、大量のユーザインターフェースを分析する場合などは、作業内容に応じて標準化しておかなければならない事も多い。
　つまり、データ管理に関わる作業自体も、単に力ずくで進めれば良いと言う訳ではなく、将来へ向けて情報を継承する事も考えて、変更管理を取り込んだマネージメントシステムとして考えて行く必要がある。
　これに止まらず、文書管理やライブラリ管理に関連して、データベース／データ中心とすることによって、独自に整備しておかなければならない事が幾つか存在するので、作業や管理対象の規模・レベルに応じて適切な環境設定・ツール導入・運用体制・マネジメントシステムなどの環境整備が必要となる。

　この段階の具体的なソリューションは、ツール選定やそれらの連携検討が中心となるが、データモデルのチェックアウト、チェックインや関連情報の貸出管理、及びデータモデルを変更する場合の手続きなども必要に応じて整備する必要がある。

【注３】：アトリビュート
　ここで２０００としているアトリビュートとは、View系の導出項目を除く、入力情報とエンティティへの所属が明確な導出項目の数なので、全データ項目数から比べるとかなり少ない可能性があるが、実際にエンティティの属性として認識しなければならないデータ項目数（＝アトリビュート）はせいぜいその程度の数である。

　　　　　　　　　　（４）プロジェクト実施段階

　データ中心アプローチと言う考え方が、データベース設計やデータベース管理の要領に止まらない、広いスコープに亘るデータ管理のフレームワークがと言う事に対する理解が進んで来ると、その考え方をベースにしたシステム開発プロジェクトが可能となる。
　データ中心指向をベースにシステム開発プロジェクトを考えると、真っ先にデータモデリングによるビジネスの把握が来る。
　ビジネスをデータモデルとして表現すれば、データベースの構造・データ移行の仕様・入力登録システムの仕様は自明となる。

　よって、モデルを基礎資料として、それぞれの構築や開発の作業を非同期で進める事が出来る。
　また、通例、最も確定が難航する出力検索系のシステムに関しては、要求される項目の編成に関して、View系の中間ファイルを追加する必要がある可能性はあるものの、ビジネスの事実を記録するデータベースの構造に関わる変更はまずない【注4】ので、これも非同期で納得の行くまで検討を続ければ良い。

【注４】：データベースの構造に関わる変更
　データベースはビジネスで生まれるデータを記録するデータの入れ物なので、現行システムを分析する事で得られた、ビジネスのモデルはビジネス自体が変わらない限り変更が発生する事はない。
　また、ビジネスが変更され、新しく記録する対象が増えたり、既存の記録対象のデータ項目が増えた場合などは、そのままデータ構造に反映するえば済む事なので、何ら慌てる事はない。
　また、これら記録から二次的に作られる導出項目は、対象データをどう見たいか（支店別に見たいとか、担当者別に見たいなど）によって、適宜増減するものなので、ファイル（テーブル）自体を増減する事になるが、その変更が、ビジネスを記録する部分に影響しないように作るのがデータベース設計である。
　データベース設計の変更に対し、費用にセンシティブなプロジェクトがあるが、多分、上述のような切り分け・分離が出来ていないために、頻繁な変更が発生するので、全体が安定するまで設計段階で議論を尽くそうと言う事らしいが、どう見たいかが変化し推移するのは止められない。
　きちんとデータベース設計を行い、変化の多い部分が、安定な部分に影響しないデータ構造を作りしかない。

　つまり、データベース設計（データ分析/データモデリング⇒実はデータベース設計をしている訳ではなく、ビジネスのモデルを作ったものが、データベースの設計に使えると言うことだ。）が終われば、基本的に後の実装作業は力仕事になるので、組織力・動員力による解決が可能だ。
　このデータ中心アプローチ独自の情報連携を中心に開発プロジェクトを進める訳だが、出力検索系システムだけ置いてきぼりになっているのが気になる所だ。
　この部分い関しては、ビジネスを円滑に処理する部分への情報提供は、基本的に現行継承で大した問題は無い。
　また、戦略的な情報提供部分は、どちらにしても延々と検討しつつトライアンドエラーを繰り返す所なので、気にぜず検討を続けて貰えば良い。
　何しろ、ＤＯＡプロジェクトで作ったレスポンスの良いシステム（このデータが見たいと決まればSQL一発で必要なデータが取り出せる⇒ＢＩツールなどしていれば更にスマートに）が控えているのだから何の心配も無いと言うことだ。

　この段階の具体的なソリューションは、プロジェクト参加者へのリテラシ教育を中心に、プロジェクトの推進やデータ中心指向に関する文書化を行い、データ中心指向によるプロジェクトの円滑な実施を促進する。
　また、プロジェクトの作業工程に於ける判断の支援も重要なポイントとなる。
　例えば、データベース設計の品質に関する判断を、ＥＲ図を見て最終的に決定するには、ある程度の慣れが必要となる。
　これがなかなか難しいので、有る程度腕に自身がある分析者が集まってデータ分析／データモデリングを行う場合、細かい吟味を繰り返す余り、いつまで経っても終わらない事がある。
　既に、検討が趣味の領域に入っていれば、誰かが判断して作業を終了させなければならない。
　このような要所要所での判断の支援などを行う事で、プロジェクトの円滑な進捗を実現する。

　　　　　　　　　　（5）リポジトリ段階

　情報システムの開発や運用・管理などの情報も当然一元管理すべきと気付いた所が、リポジトリの出番となる。
　その意味で、この段階は、必ずしもこの位置にある必要はない。
　但し、プロジェクト実施段階で、単体プロジェクトをデータ中心指向で運営する事を習得した段階から、更に管理対象のスコープを組織全体、ビジネス全体に広げて行こうと言う段階で、それら情報整理のツールとして、リポジトリが利用可能となっていないと作業ははかどらない。
　
　リポジトリとは、要するに情報システムの開発、運用、管理を対象ビジネスとしたデータ構造を明らかとし、それをデータベースとして実装したものだと考えて貰えばイメージし易い。
　例えば、データ項目とそれが存在するエンティティとの関係、エンティティが物理的に実装されているデータベースやテーブルとの関係、それを更新したり検索するプログラムとの関係、更にプログラムを保守する担当部署・担当者との関係などを全て一元的に管理することが出来る。
　管理対象がプロジェクト毎などと限定されている場合は、単純な一覧表や表計算ソフトの利用でも十分な場合もあるが、この手のものは、使えば使うほど新しい要求が増えてくる。
　さらに、管理対象のスコープが広がって来ると、参照や更新が競合する事になるので、利用目的や管理対象の規模に応じて、適切な管理システムを使い分ける必要がある。
　
　この段階の具体的なソリューションは、情報システムの開発・運用・管理に関わる作業と資源、手続き、ユーザインターフェースから、情報システムの開発・運用・管理に関するデータモデルの作成がある。
　これが、リポジトリの設計図になるので、データモデルを作ったら、必要な機能を備えた製品を探すか、内部で開発する。
　また、情報システムの開発・運用・管理に関する作業手順や手続きを全て、リポジトリをユーザインターフェースとするものに改める。

　　　　　　　　　　（6）データ管理ポリシー段階

　データ中心アプローチを標榜してシステム開発を幾つか行えば、システム開発プロジェクト毎にデータを一元管理するとして作られているデータベースが、ビジネスのスコープ全体で見ると、体よくデータ重複になっていると言う事はすぐに分かる。
　更に、個別のシステム/サブシステム単位にデータを一元管理する事で効果があるなら、さらに大きな単位で統合し一元化すれば、更に大きな効果があろ事も容易に推測可能だ。
　実は、そんな事はデータ中心アプローチを云々するまでも無く、誰でも分かっていた事だが、磁気テープを媒体とした順次処理中心の処理構造の中で、出来れば理想的だが現実的には出来ない事だとの認識が深層心理で共有されている様だ。
　もちろん、現在の機器構成と処理形態を以ってすればスコープ全体のデータ一元化は難しい事ではないし、プロセスを踏んで、段階的にデータ中心アプローチの考え方を理解し、スキルを身につけ、環境と整備し、体制を作って来た組織にとって、十分に実現性のある話なので、そろそろ呪縛の力も期限切れかと思われる時期ではある。
　しかし、処理には、定期定例のトランザクション処理から、不定期の分析処理まで、多様で、如何に現在のデータベース管理システムが優秀で、データベース設計の品質が高いとしても、避けた方が良い使い方もある。
　例えば、基幹業務系とは別に、情報系とかDWHと呼ばれる、テンポラリな処理専用のデータベースを作る場合などだ。
　因みに、本来この二つのデータベースは全く同じ設計で問題ない。
　確かに、情報系のデータベースには、履歴や集計データなども共用データとして持つ事が多いが、利用目的に合わせた工夫の部分であり、ビジネスのデータを記録する部分に相違が出るはずもない。
　しかし、通例、期間業務は商品・機能・ロケーションなどで、別々に作られていることが多く、全体のデータ構造が把握されないままに成っているので、情報系構築のタイミングでビジネス全体のデータ構造を始めて認識する事が多く、全体のデータモデルは共通だとの認識に至らないケースがある。
　そこで、ビジネススコープ全体のデータ構造を明らかにすると同時に、それらデータの使い方についての方針を決めておかなければならない。
　例えば、データの連携が少ないシステムに分割可能で、すでにその分割単位にシステムが分かれているような場合は、全体のデータ構造を明確にした上で、各個別システムがどの部分をカバーするのかを線引き・調整すれば、物理的な一元化を行う必要も無い。
　また、全体のデータ構造は情報系に反映するが、業務系は命名やルールの統一に止め、最終的には、業務系で一元管理を目指すが、再構築のタイミングで順次進めて行くなどだ。
　スコープ全体で、最終的な目標や方針が明らかになっていないと、個別のシステム開発プロジェクトで、冗長性や無駄の排除が進まない。

　この段階での具体的なソリューションは、エンタープライズデータモデル【注５】の作成（この作業はデータ分析・データモデリングのスキルが備わったらなるべく早く行った方が良い）、データ管理ポリシーの策定を中心に、最終的にポリシーで示した、組織にとって好ましいデータ管理状態に推移するためのマネージメントシステムの構築となる。

【注5】：エンタープライズデータモデル
　企業/組織の最大スコープでのデータ構造を把握するために作成するデータモデル。
　巨大な図に成りそうな気がするが、世の中でビジネスに使われるリソースや、ビジネスで発生するイベントは、どれも似たり寄ったりなので、形としては、既存のシステム毎にデータモデルを統合する事になるが、５００エンティティのデータモデルを２つ統合すると言っても、エンティティ数が１０００に成るわけではない。
　逆にほとんど増えない事の方が多いので、大きさに圧倒される必要はない。
　これを、一元化方針(データ管理ポリシー)や、早い段階で作れば、データ項目命名基準策定などの基礎資料とする。

　　　　　　　　　　まとめ

　
　ここにDOAソリューションとして説明したものは、実際の適用に際しては、それぞれの組織の状況と、ニーズの応じて調整する事になるので、自分達のペースで段階を踏んで貰いたい。
　早く理解が深まれば、早く段階を上げる事も出来るが、往々にして早く進んだ積りが、振り返れば誰も居ない事があるので注意して欲しい。
　特定の個人が頑張って何とかなるのは、データベース設計段階までだ。
　それ以上の効果を拡大定着する場合には、必ず組織的な対応が必要なので焦りは禁物だ。
　そのため、データ中心アプローチと言いながら、単にデータベース設計の品質が良い段階から先に進んでいるケースにはなかなかお目にかからない。
　情報システム部門の管理者や経営者層を巻き込んだ対応が必要となるが、それらの層に分かるように説明するレベルで知識を吸収し、自信を以って対応可能と言えるスキルを持つには相応の学習と経験が必要となる。
　このData Centric Art Galleryを活用して貰えれば幸いだ。

　これらデータ管理を行う事、即ちデータマネジメントシステムのPDCAを回す事が、情報システム部門の最終的で普遍的な業務となる事は間違いないので、　組織的な対応とは別に、いや、組織的な対応を円滑に進める為にも、個人のスキルは十分磨いて貰いたい。

なお、本件に関する具体的なサービス提供については、株式会社エフ・エム・エスのサイトで説明しているので参照して欲しい。株式会社エフ・エム・エスのサイトへ⇒