「いざビッグデータ活用!」への備えとして、企業はデータ・アーキテクチャの管理強化を

ビッグデータ時代とも言われる今日、Oracle ExadataをはじめとするオラクルのEngineered Systemsが可能にした従来とはケタ違いの処理性能/スケールを生かして、これまでは不可能だった新たな情報活用に取り組もうという企業が増えている。ただし、ここで忘れてはならないのは、ビッグデータは多くの企業がすでに保持している構造化データ、すなわちRDBMS内のデータと組み合わせて利用して初めて価値を生むと言うことだ。つまり、RDBMS内に格納された各種のデータを、いつでも活用できる状態に整える「データ・アーキテクチャ管理」の活動が一層重要になる。日本オラクル テクノロジーソリューションコンサルティング統括本部に所属し、日ごろ顧客企業のデータ・アーキテクチャ管理を支援しているプリンシパルコンサルタントの伊藤幹也氏(テクニカルアーキテクト本部 データベースアーキテクト部)に、このデータ・アーキテクチャ管理の重要性や活動におけるポイント、メリットなどを聞いた(編集部)。

ビッグデータの価値に気づいた企業は、データ・アーキテクチャの管理に
目を向けるべし

 本サイト掲載記事「新世代の情報処理基盤が企業にもたらすケタ外れの性能が今、ビジネスのルール/仕組み/常識を変える」で紹介したように、Oracle ExadataなどのEngineered Systemsとその周辺ソフトウェアを活用することで、これまでは多くの時間がかかっていたデータ・ウェアハウス(DWH)処理などにかかる時間を大幅に圧縮することができる。

 それにより、従来は情報が発生してから活用できるようになるまでに数時間から数日を要していたところを、発生した情報をリアルタイムにビジネスで活用することが可能になる。その結果、企業のビジネスがどう変わる可能性があるのかは、前掲の記事で流通小売業などの例を挙げて説明したとおりだ。

 ただし、こうした情報活用を行うためには、その大前提として、「現在、自社がどのような情報(データ)を保持しているのか、それらのデータがどのデータベースに、どのような状態で格納されているのか」を把握していなければならない。なぜなら多くの場合、SNSや各種のセンサー・デバイスから収集されるデータは、RDBMS内の顧客情報や商品情報などと組み合わせて活用することで、企業にとって初めて価値のある情報となるからだ。

 そして実際に、先進的なIT活用に取り組む組織は、RDBMS内の情報と社外のさまざまな情報を組み合わせて活用することにより、すでに大きな成果を上げている。

 例えば、米国のシカゴ市警察は、重要な国際会議の開催期間中における治安維持や犯罪抑止を目的として、TwitterなどSNS上のソーシャルな情報と管内の署員配備計画の情報を組み合わせた分析を実施した。Twitterのつぶやきの内容の分析結果(ポジティブな発言か、ネガティブな発言か)と、つぶやきのあった場所の位置情報を併せて地図上に表示し、不穏な地域をリアルタイムに視覚化。これを署員の配備状況と照らし合わせ、暴動などを未然に防ぐべく署員の配置を最適化したという。

 また、北米のアパレル・メーカーは、顧客がFacebookに書き込む同社製品へのコメントを分析し、特定製品の売り上げが低下しているのは、その価格が適正ではないと評価されているからだと判断。同製品の価格を改定し、併せて新たなプロモーションを実施することで、売り上げを伸ばすことに成功した。

 前述したように、このような情報活用を行うためには、まず自社内にどのような情報があるのかを把握していることが必須となるが、「実は多くの企業は、自社内にあるデータの管理、具体的にはデータ・アーキテクチャの管理がきちんと行えていない」と伊藤氏は指摘する。

日本オラクル テクノロジーソリューションコンサルティング統括本部 テクニカルアーキテクト本部 データベースアーキテクト部 プリンシパルコンサルタントの伊藤幹也氏
 「そのため、ビッグデータの活用を検討し始めた段階で、『そもそも、社外から集めた各種データと組み合わせて使うべき構造化データ(RDBMSなどの中にある顧客情報や商品情報などのデータ)が何なのか、どこにあるのかがわからない』、『同じようなデータが複数のデータベースに存在しており、どれが最新のものか、正しいものかがわからない』といったことになり、必要なデータを探したり、整備したりするために数カ月の期間が必要になる。多くの時間がかかるため、計画が先送りになるケースもあるだろう。

 チャンスを逃さず素早く取り組みを始めるために、ビッグデータの価値を理解した企業がまずやるべきことは、RDBMSをはじめ社内に保持するデータを見える化し、また新たに作られるシステムも含めデータを正しく作り、維持していくこと、すなわちデータ・アーキテクチャの管理なのだ」(伊藤氏)

 オラクルは現在、下図に示すような各種データの「取得」、「体系化」、「分析」、「決定」を支えるソリューション群から成る、ビッグデータ活用のためのリファレンス・アーキテクチャを提唱している。



 伊藤氏が言うデータ・アーキテクチャとは、このリファレンス・アーキテクチャに沿ってEngineered Systemsなども利用して行う新たな情報活用の下地となるものだと考えればよい。

 伊藤氏らは現在、日本オラクルのデータ・アーキテクトとして、データ・マネジメントのための知識体系として知られる「DMBOK(Data Management Body Of Knowledge)」のフレームワークも援用しながら、企業のデータ・モデル作成から維持/管理までを包括的に支援している。その中で氏が実践しているデータ・アーキテクチャ管理のポイントを以下に紹介していこう。

データの"One Fact In One Place"を保つための「見える化」と「レビュー」

 ご存じのとおり、データ・アーキテクチャの管理で肝となるのは、"One Fact in One Place"だ。すなわち、「ある情報を表すデータは、ただ1つだけ存在する」という状態を保つことが鍵となる。

 「企業が絶対に忘れてはならないのは、データは維持/メンテナンスを止めた瞬間に価値を失ってしまうということだ」と伊藤氏は強調する。単に後述するデータ・モデルを作成してデータを見える化するだけでなく、データの"One Fact in One Place"原則にのっとり、それぞれの情報が常にただ1つのデータとして、高い品質で正しく作られ続けるのを保つこと、それによっていつでも即座にデータを活用できるよう "データの鮮度"を維持することが重要なのである。

データ・モデルを作成してデータを見える化する

 データの見える化は、データ・モデルと、データ・モデルの情報を補完する設計資料の作成によって実現する。この作業の中では、企業が扱う個々のデータに関して、次のような成果物を作成する。

  • データ・モデル(ER図:Entity Relationship Diagram):各データの構造とカーディナリティを含むデータ間のリレーションシップを見える化したモデル。データの静的な状態を表す。概念レベル、論理レベル、物理レベルの3種類のモデルを作成する
  • DFD(Data Flow Diagram):システム間またはシステム内のデータの流れを表現したモデル。対象業務をデータ・フロー(発生、処理、蓄積、破棄までのフロー)として見える化する。データ・モデルがデータの静的な状態を表すのに対して、DFDはデータの動的な状態を表す

  • CRUD(Create/Read/Update/Delete)図:各データに関して、どのシステムの、どの機能が、どのテータベース/テーブルを操作(作成/参照/更新/削除)するのかをマトリクス形式で見える化したもの。DFDと併せて見ることでデータの動的状態を把握する

 これらのモデルによってデータを見える化するメリットとしては、次のようなことが挙げられる

  • コミュニケーションの円滑化:データに関する情報がすべて可視化されるので、関係者間でコミュニケーションを取りやすくなる

  • 全体像の把握:データ間の関係、システム上に存在するデータ・オブジェクト、稼働中のデータベースと仕様との整合性など、システムの全体像を把握することが容易になる。「私が担当するお客様の中には、各システムで作成されたデータ・モデルをすべて統合し、全社レベルのデータ・モデルとして管理しているところもある。これにより、システムを横断して全体像を把握することも可能になる」(伊藤氏)

  • システム変更の影響範囲の把握:システムに変更が生じた際、データ・モデル、DFD、CRUD図などから、変更の影響範囲を即座に把握できる

  • データ管理という役割の明確化:データをモデルによって見える化することで、その資産状況が明らかになり、「(見える化した)データ(情報)を管理する」という役割も明確になる

データの品質を高め、維持する

 一方、データの維持/管理においては、データの"One Fact in One Place"を保つためのガバナンスの確立/運用が重要になる。その中で肝となるのは、次のような活動だ。

(1)データベース設計の標準化と、その定着化の促進:データ・モデルを作成する際の各種設計規約を策定(および改定)し、その内容を各担当/委託先に展開する

(2)データベース設計成果物のレビュー:各工程で作成されるデータベース関連の設計書のレビュー

 これらは、個々のプロジェクトの中で実施される。その中で、伊藤氏らは次のような作業を行っている。

(1)データベース設計の標準化と、その定着化の促進

 この活動では、各システムが利用するデータの論理設計と物理設計を行う際のモデル作成に関する規約を定めるとともに、その規約を組織/プロジェクトに浸透させる。

 「企業のプロジェクトでは通常、外部のSIerが個々のシステムやデータベースの設計/構築を担う。このとき、標準の規約がないまま個別のプロジェクトを進めるところが少なくないが、そのようなガバナンス不在の帰結として訪れるのは、『同じ情報を表現したデータの乱立』や『互換性のないデータが作られることによるデータのサイロ化』、『個々のシステムが持つデータの実情がわからなくなることによるデータの鮮度低下』だ」(伊藤氏)

 データ・モデルは、エンジニアの技術レベルや嗜好などにより、作られるモデルの品質や特性にぶれが生じがちである。そのぶれを最小限に抑え、組織/プロジェクト内のデータ・モデルの品質を高いレベルで平準化して維持することが、この活動の目的なのだ。

 データベース設計の標準化では、次のような規約を策定する。

  • モデリング規約:データ・モデルを作成する際の設計方法(分析アプローチや正規化レベルの規定、リレーションシップの表現方法など)について定めた規約

  • 命名規約:テーブルや属性などの名前の付け方を定めた規約

  • コード定義規約:組織内で使用する製品コードなどの付け方やコード設計時の考慮点について定めた規約。重要なコードに関してはこの規約によって明示的に縛りをかけることで、「名前だけからでは、それが何なのかが推測しづらいコード」などが作られるのを防ぐ

 なお、モデリング規約に関して重要なのは、「データの性質を分けて考えること」だと伊藤氏は指摘する。

 「私たちがモデリング規約を策定する際には、データの性質に応じて『連携データ』、『共通データ』、『個別データ』という3種類のデータを認識する。

 このうち、連携データは外部のシステムから取り込まれるデータ、共通データはシステム間で共通に使うことを想定したデータ、個別データは各システムに固有のデータとなる。

 この分類を意識しておくと、各プロジェクトの担当者がデータ・モデルを作成する際、例えば『これは人事情報を扱うデータだから、すでに共通データとして他のシステムで使われているのではないか? そうであれば、どこかのシステムに該当のテーブルが存在するはずだから、それを再利用すればよい』といった具合に、データの重複を避けながら効率的にモデル作成を進められるようになる」

 こうしたことも考慮して規約を作り、ドキュメント化したうえで、それを外部も含めた関係者に配布するとともに、説明会などを実施して周知することで、規約の浸透を促進するのである。

(2)データベース設計成果物のレビュー


 ただし、単に規約を作成して説明するだけで、正しいデータ・モデルが作られると保証することはできない。そこで伊藤氏らは、協力会社らが作成したデータ・モデルの設計書をレビューし、規約に反したものがあれば修正を依頼することで、データ・モデルの品質を担保している。

データ・ガバナンスを担うデータ・アーキテクトの意義

 このように、「規約の作成/定着化」と「レビュー」を行う体制を確立して運用することにより、企業が持つデータを見える化し、その品質を維持していくことが可能となる。こうした活動により、企業は次のようなメリットが得られる。

  • 明確な規約の作成/定着化と、その適用を徹底するレビューにより、企業が持つデータの品質が一様に向上する

  • 企業が持つデータが見える化され、重複のない状態で維持されるため、ビッグデータ活用やシステム変更などの際、データの所在やシステム変更の影響がおよぶ範囲などを即座に把握できる

  • 規約に従ってデータ・モデルを作ればよいので、規約のない状態で個々のエンジニアがそれぞれ悩みながら作りよりも、作業が効率化される。当初は規約の浸透に時間がかかるものの、やがては作業がスムーズに進むようになり、工数削減の面でコスト・メリットが生まれる

  • データの性質(連携データ、共通データ、個別データ)を意識してデータ・モデルを作ることで、特に共通データに対する意識が高まり、データの再利用が促進される。これによってデータ・モデルの作成量が減り、工数削減の面でコスト・メリットが生まれる

 これらは結局、"One Fact in One Place"の原則を忠実に守ることで得られるメリットである。日本企業のように、個々のプロジェクトをSIerなどに委託するケースが多いところでは、プロジェクトごとにデータがサイロ化し、この原則を守ることが難しくなりがちだ。それを伊藤氏のようなデータ・アーキテクトが全体を通してガバナンスすることにより、データの見える化が正しく行われ、いつでもデータの状態を把握し、活用することが可能になるのだ。


データのサイロ化はクラウド上でも進行。その管理も視野に

 データ・アーキテクチャ管理の活動は、企業がオンプレミスで抱えるデータだけを対象とするわけではない。

 クラウドの普及が進む今日、SaaS(Software as a Service)やPaaS(Platform as a Service)を活用し、必要に応じてアプリケーションを調達する企業が増えている。クラウドであればインフラの調達や構築、運用が不要となるため、手軽に導入できる点がメリットとして評価されているのだ。しかし、データを中心に見たとき、そこに落とし穴があると伊藤氏は警告する。

 「クラウドでは、CRMなどの業務アプリケーションが調達されることが多く、そこには顧客データなど企業にとって重要なデータが蓄えられる場合が少なくない。このとき、部門ごと、業務ごとにアプリケーションが作られると、同じようなデータが複数存在するようになるなど、ガバナンスの効いていない状態になりがちだ。その結果、重複や(データ・モデルの作り方の違いによる)ばらつきなどが生じてデータの品質が総体的に低下し、各アプリケーション内でデータがサイロ化してしまうわけだ」

 1980年代に始まったPCサーバの普及により、部門ごとにシステムが乱立した結果、システムやデータのサイロ化が起きたのと同じ現象が今、クラウド上で進行しているわけだ。実際に伊藤氏らが支援している企業でも、今後はクラウド上のデータに対しても、オンプレミスと同様の「規約策定/定着化」と「レビュー」によるデータ・アーキテクチャ管理の取り組みを広げていこうという機運が高まっているという。


 近年はビッグデータやアナリティクスといったデータ活用への関心から、データの分析を行うアナリストやデータ・サイエンティストなどに注目が集まっている。そうした役割に関心を寄せる企業に対して、伊藤氏は次のようにアドバイスする。

 「ビッグデータやアナリティクスなども含め、企業が高度なよりデータ活用を行うためには、『データは自社の重要な資産である』という認識を、マネジメント層だけでなく関係者全員が持つことが重要。特に現場レベルでは個々のシステムに関することが優先されがちで、データ管理についてはあまり重視されていないのが実情だ。まずは現場レベルでこの認識を浸透させることが第一歩となるだろう。

 また、ビッグデータなどの"流行語"に踊らされないことも大切だ。ビッグデータは、必ずすべての企業が儲かったり、ビジネスに有益な気づきを得られたりする"魔法"ではない。非構造化データというとSNSなどのデータが注目されがちだが、自社にとって重要なデータは、もっと身近なところ、例えば社員の週報や業務で作成されるWord/Excelファイルなどの中に埋もれているかもしれない。今回お話ししたようなデータ・アーキテクチャ管理の活動を継続的に行いながら、どのデータをどう活用するのが適しているのかを明確にしていくことで、結果として、それらのデータが"自社にとってのビッグデータ"になるかもしれないのだ」

 日本オラクルは今後も、ビッグデータ活用を促進するソリューションの提供と併せて、企業のデータ・ガバナンスを支援するコンサルティング・サービスや各種ソリューションの提供にも注力していく。

【本記事で紹介しているサービスに関するお問い合わせ先】
 本記事で紹介しているデータ・アーキテクチャ管理などのコンサルティング・サービスについてのご相談は、
下記のOracle Directまでお問い合わせください。
● Oracle Direct
TEL(フリーダイヤル):0120-155-096
Webサイト:http://oracle.com/jp/direct/

Comments:

Post a Comment:
Comments are closed for this entry.
About

Twitter
Facebook

Search

Recent Posts
Archives
« 7月 2014
  
1
2
3
4
5
6
7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today