“言われた通り”ではもうダメな理由──「データを中心に考える」とは、どういうことか：ゼロからのリレーショナルデータベース入門（4）（3/3 ページ）

本連載では、企業の成長に不可欠な「データ活用」を推進していくために必要なデータ基盤の基礎を“あらためて”解説していきます。今回は、ビジネス視点でのデータベース構築には欠かせないデータ中心アプローチ「DOA」の考え方と、それを推進するための手法を解説します。【更新版】

[佐瀬力，株式会社アシスト]

部分最適の手法では、ビジネスのスピードに対応できない

　さて、システムや部門ごとに最適なデータベースを作成できれば、当面は使い続けていくことが可能でしょう。

　しかし前述した通り、ビジネスの変化や変革が激しい昨今、その変化へ迅速に対応できるシステムが強く望まれています。何かあってから修正／対処する「部分最適」の方法では、そのスピードの要求に耐えられないことが予想されます。

　部分最適の考え方でデータベースシステムを作成した場合に発生しがちな例を、参考として以下に示します。

問題例1：「名称の違いやデータ重複」の問題

　これまで、営業部門、技術部門、生産部門がそれぞれ取引先情報を作成し、管理していた体制を改め、CRM（Customer Relationship Management：顧客関係最適化／管理）システムを構築して取引先との関係を全社で統合管理し、業務活動の効率化を図ることになりました。

　このプロジェクトでは、取引先情報を1つのデータベースに統合して実現します。しかし、部門ごとに管理する企業名、コードが異なっており、重複も多いようです。また、重複排除をするにも、どの部門の取引先関連データが最新でかつ正確なのか、担当者がデータを見るだけでは分かりません（図5）。

図5　データ統合時によくある、部門ごとのデータの違い

問題例2：「粒度」の違い

　同じ取引先の情報であっても、各部門で発生する業務や、やりとりする部署／担当者が異なることから、登録しているデータ対象の範囲が違うことも往々にしてあります。例えば営業部門は取引先企業単位を対象データとしていたのに対し、技術部門では取引先企業を部門単位で捉えている、などです（図6）。

図6　部門ごとに異なる「データの粒度」の違い

　この他に、店舗（販売部門）と工場（製造部門）の管理体系が違う例も多くあります。製品の開発工程段階では、工場のラインや日付、内部ソフトウェアのバージョンなどによって、製品コードを変えて管理しているかもしれません。その一方で、完成品として実際に店頭に並ぶ商品に違いがないならば、店舗が商品発注などで使う製品コードは同一のまま管理されることもあります（図7）。

図7　管理体系の違いによる製品コードの差異

　上記のような例では、データ統合に必要な前処理として「変換／整合する作業」が発生します。この作業に多くの時間、人力、コストが必要なのは言うまでもありません。つまり、企業のビジネス全体としてどんなデータが必要かを把握／整理できていれば、この工程を省いてスピードアップを図れることになります。

　具体的には、部門や地域を横断した処理に対しては、それぞれのデータや粒度を判断して、必要に応じて名寄せや値の変換を行うインタフェースが必要になるということになります（図8）。

図8　名寄せや変換による参照の例

今後のデータベース管理者／IT管理者に期待されていること

　1つのデータが企業内に幾つも散在していると、データに不整合が生じ、データの信頼性が低下することになります。これは、迅速な経営判断が求められる経営環境において、1つの事実を捉えるのに多くの時間を費やしてしまうことになります。

　このことは何より、変化の激しいビジネスに迅速に対応できる体制が望まれているのに、システム構築や改良で時間やコストがかかるならば、それはビジネスに貢献しにくいシステムと見なされてします。

　データの独立性を高めてプログラムからデータを分離し、経営資源の1つである「情報」をアクションにつなげる──。これを実現し、今後もITでビジネスの成長に貢献していくために必要となる、「データを中心」に考えるDOAの視点の重要性を理解できましたでしょうか。

目次に戻る

更新履歴

【2016/11/18】2016年時点の状況に合わせて、内容を追記更新しました

【2009/01/19】初版公開

筆者紹介

佐瀬力

株式会社アシスト所属。Oracle Databaseのフィールドエンジニアを経て、Oracle DatabaseやEDB Postgres、PostgreSQLのプロダクト担当。吉田類さんの信奉者。3児の父