- その31：ネットワークグラフの利用面（その１）
- 今回は、前回ご紹介した新しい視覚化のためのネットワークグラフ利用の可能性の概要に触れました。今回は筆者の、その応用例について簡単にご紹介します。
- その応用例内容について触れる前に、経緯として今年の9月下旬から11月末に掛けて行われた「データモデリングコンテスト2016」について説明する必要があります。これはJEMUG（日本エンタープライズモデリング・ユーザーグループ（ERwinユーザーグループ）によって毎年開かれているオープンなコンテストです（詳細は、こちら）。会長により出題される課題に対して、オープンな形でデータモデル案を作成し、その表現について評価・表彰する試みです。光栄にも筆者が、審査員により今年のJEMUG賞（最高賞）に選出されました。筆者の作成したデータモデル図は、その簡単な解説と共に近日中にJEMUGホームページで紹介されていました（こちら）。
- 今回の課題として取り上げられたのが、パナマ文書データベースの話題でした。このデータベース（DB)は、新聞の話題で取り上げられていたように、ある流れによって漏れた税回避者に関する情報をインターネットを通じて世界の誰もが参照できるようにしたものです（パナマ文書DBは、こちら）。このDBは、オープンソースのネットワークデータベース環境であるNeo4jを用いて作成されており、データの性格上、グラフ理論をベースにしたモデル構造で表現されています。つまり、「ある会社（エンティティ）の役員（オフィサー）であるA氏と結びついている」というような関係性の集合としてDB内データが表されているということです。このパナマ文書DBのデータ設計の全体像を、データモデル設計手法のエンティティ・リレーションシップ技法（ER図）でどのように書き表せるかを競うのが、今年のコンテスト課題でした。
- このER図は、オフィサー（役員など）、仲介者、エンティティ（投資家など）、住所地という主要４情報と、それらの間の情報関係を表現したものです。筆者のER図によるデータモデルは幸運にも授賞した訳ですが、このER図だけでは、元のパナマ文書DBが表現しようとしている情報意図を十分には表現しきれないというモドカシサを同時に感じました。そこで採用したのが、ネットワークグラフ表現を活用するという手法です。この手法を用いると、上記の主要４情報のデータ量に加えて、それらの関係性の量的な大きさや重点的な関係性などを、うまく視覚的に表現することができ、コンテスト評価会の参加者にも高い評判を得ることができました。これらの表現における考え方は、JEMUGのコンテストサイトページで説明文を公開する予定です。
- 一方データ項目の詳細理解については、ER図による表現手段の方が勝るということもいえます。つまり、ER図技法によるデータ項目の構造図と表現と、その構成データの全体観というグラフ図とを併用することが、より良いデータ理解につながるという結果といえます。全てのデータベースに当てはまる訳ではありませんが、利用の仕方によって企業のプロジェクトに参加する関係者の課題への理解を深める手段が現れたということです。
- この稿では文章で表現しただけのため、大きな効果を生み出す新しい視覚表現の内容を十分にお知らせできませんが、この文章を読んでそういった内容に興味を抱かれた方は、「お問合せページ」を介して是非筆者へお問合せ下さい。次回も引続きネットワークグラフの威力に触れたいと考えています。
（先頭に戻る）
- その30： 新しい視覚化技術の利用可能性について
- 今回はビッグデータ活用に関連して、これからの技術分野としてのネットワークグラフ・アナリティクス（グラフを用いた視覚化分析技術）について触れたいと思います。「グラフ」という言葉を聞くと、Excelソフトウェアの利用を思い浮かべ、棒グラフや円グラフなどとっったイメージを浮かべる方が少なくないのではないかと想像します。ここで説明する「グラフ」というのは、そういったものではなく、いわゆる「グラフ理論」に基づくネットワークグラフ（トポロジー分野）に属するものです。グラフ理論の始まりについてはオイラーによるケーニヒスベルクの橋、つまり一筆書きの問題というのが上げられます。ここでは離れ島とそれらを結ぶ橋を点（島）と線（橋）で抽象化し、問題となる視点を検討するという考え方です。ここでは点と線の連結する関係性を問題にして、空間的な位置や距離を外して考えようということでした。
- 単に「グラフ」と呼ぶと上記のような誤解を生む可能性があるため、ここでは「ネットワークグラフ」と記述することにします。このような考え方の有効性は、世の中のモデルはモノとモノなどの関係性の有無で表せる問題が少なくないという点にあります。例えば、人気アプリであり多くの人が利用しているFacebookは、人と人との関係性とその意味付けを使ってビジネスにしている訳です。誰と誰がどういった繋がりを持っていて、どのようなコミュニティを形成しているのかということをモデル化し、コミニュケーション作りをビジネスにしているといえます。そこでは人（或いはグループ、団体）が点であり、それらの結びつきを線（ライン）で表すことでネットワークグラフとして構造をモデル化できることになります。
- また別の例を上げると、顧客の購買行動といったものも考えることができます。それは、ある顧客が点であり、その顧客の購入商品がまた別種の点で表現できます。そしてAさんがB商品を購入したというのが関係性としての線で表すことができます。こういった関係性を集めると、ある商品とある商品が集合的に一緒に購入されやすく、どの程度の頻度で買われているかといった関連購買性分析に結び付けることができる訳です。更にAさんなど購入者のプロファイルを知ることができ、その共通性をイメージすることができれば、商品購入の将来の形（いわゆる推奨（リコメンデーション））に結び付けるとう応用にも広がる可能性を示します。
- 上記は幾つかの例ですが、このように考えるとネットワークグラフは、ビッグデータが話題にされる中で広い応用性を持つことが容易に想像できるでしょう。そしてこういったネットワークグラフを取り扱うには、これまでのようなリレーショナルデータベース技術では、規模の拡大に実用上の対応ができない（処理パフォーマンスやデータモデル設計に課題が出る）ということが分ってきています。そこでグラフデータベースといった新しい所謂NOSQLと言われる分野の技術が注目されてきたという関係にあります。過去何回か触れてきたリンクトデータもこのような技術の一つの応用分野ということができます。
- このネットワークグラフの利用においてもデータの設計視点が大切になります。最初はデータ（点）とデータ（データ）およびそれらを結ぶ線を関係としてデータ構造として表現すれば良いのですが、無闇に関連性を導入するだけでは何れはデータの海に飲み込まれた混乱を生むことになりかねません。そこでオントロジーといった意味論の考え方を導入して概念的なデータ構造を表現・整理しておく必要性があるだろうというのが筆者の考え方です。データそのものの意味論を整理し、設計情報として表現し伝達することができるようにするというのが、今後のこのような技術の利用発展につながることになるという考え方です。その上にこそデータの表現技術（視覚化など）も有効にビジネス継続性として機能してゆくはずだという訳です。
- 今後、こういった考え方に基づいて何回かの本コラムメッセージの話題として取り上げたいと考えています。ご期待下さい。 （先頭に戻る）
-
- その29：オープンデータの利用と、その技術および幾つかの基本課題（その3）
- 前回から少し間が空きました（著者所用により、なかなか手が外せない状況になり先日香港から帰ってやっと記事を書こうという気分になりました）。
- これまでを要約すると、OLD（オープン・リンクトデータ）の活動は技術志向優先で進められており、国内での利用事例は官公庁や美術館などの公共施設関係の持つ情報に、一部地理空間情報をミックスして利用したケースが多いようだということです。利用形態は、限定された範囲で複数のデータソースを組み合わせて利用者に開示するといったようなものといえます。組み合わせたデータに対する品質保証やデータの最新性などはソースデータを提供する側の実行努力に任されているといったイメージです。それをOLDデータベースを保持する公開用サーバアプリが定期的に取りに行って自分の持つLODデータベースを更新するという形になります。
- インターネットというオープンなインタフェースを元にしたネットワークは、社会基盤として浸透することで、その上を流れるデータや利用アプリケーションは自由に任せた。このためネットを利用した金融サービスや購買・流通の仕組みなどがビジネス上の活用領域として生まれました。また個人向けにはメールシステムやSNS環境などの活用の広がりを持たせた。一報では、悪意のある利用者により、詐欺的な被害者を生みやすい便利なツールを提供し、ネットワーク上のウィルスの活動の場を提供することになった。どのような利用者がオープンな世界にはいるかが分らず、性善説だけでは語れない世界といえます。またオープンで安価な環境であるという視点から、企業や個人が利益主義に走り出していることで、ネットワークで宣伝・マーケティング活動をし出してから、本来は便利さをもたらした状況から、益々自分の探したい情報に辿り着くことが難しい状況を生み出したといえます。このため学術的な世界では、オープン技術を利用しながらも、インターネットとは異なる分割したネットワーク環境作りを行うという状況を生んでいます。
- データの世界についても、当初は広めるために自由なデータの利用環境とそのための技術提供から始まる訳です。それがどういった人たちに利用されるか、どのような利用形態に繋がってゆくかということを早い段階から検討する必要があるというのが著者の見解です。言わば、利用者の欲望を喚起する利用方法が優先されて広がると、ある段階で反ってマイナス面が強調され、不必要な管理コストを生み出す。更に信用のおけない情報が蔓延し、内容の正確さを確認するのに手間が掛かったり、最悪の場合には資源だけ無駄使いすることになって利用されなくなってしまうということも起こり得ます。技術面での拡張努力だけでなく、制度面での手当が早い内に必要であるということです。
- 補足すると、最近に筆者の経験での地図情報利用の経験を書いておきます。Googleの提供する地図サービスは多くの人たちが便利に利用していることと思います。その中で国内の施設名から住所、緯度経度を検索できるジオコーディングサービスも提供されています。これを使用した際に、都内のある施設名を入力して住所・緯度経度情報を取得して地図表示をしたのですが、どうも本来の場所を示していないことに気付きました。結果としていうとGoogle側の情報が当該施設の移動した情報を取り込んで更新していないことが原因らしいと分かりました。簡単な例ですが、このような情報の齟齬に対する責任を取るのは一体誰なのかと思案したという訳です。利用者責任ということで片付けられるでしょうが、便利なGoogleツールさえも迂闊には信じてはいけないという好例だと思った次第でした。 （先頭に戻る）
-
- その28：オープンデータの利用と、その技術および幾つかの基本課題（その2）
- 前回に引続きLOD（リンクト・オープン・データ）連続講義（第２、第３回）を聴講してイメージした内容を記述します。この講義は毎週火曜日１８時２０分から開始。７月26日まで開催されます。これらの会議では、リンクト・データの考え方を支えるRFD、OWLの基本的な技術背景を中心に説明が行われました。
- ネットワーク空間（これは通常、インターネット世界と捉えられる）での情報共有活用の枠組みの一つとして考え出された仕掛けとしてRDF（Resource
Description Framework)があります。これは情報を表現する形式として、３つ組（トリプル）を表現の最小単位として、この単位をグラフ的な表現でで連携させて、ネットワーク世界に散らばる情報を表現しようとするものです。ここでは情報の最小要素に対して唯一の識別子をつけることができるのが条件となります。この識別子の分かり易い例が、インターネット世界のURLで、その概念を広げるとURIという識別子概念になる。そしてこの識別子を付けたノードを主語と目的語としてその２つを関係表現としての述語で（エッジとして）結び付ける。この内容を文章だけで見やすくするのは難しいため、具体的には関係する資料を参照下さい（例：情報処理Vol.57 No.7
July 特集 リンクト・オープン・データの利活用）。
- このRDFを用いた情報表現によって、どのレベルまで共用データ表現をするのが、実際的で実用的かという疑問が筆者の持つ視点です。これは機械可読性を実現するという方達からみると、具体的数値レベルまででも表現可能であるという回答が出てきそうですが、人間の理解視点でその利用価値範囲を論じたいというのが筆者の立場であるということです。つまり、例えばオープン・データとして開示されるExcelファイル形式データの行（或いはセル）レベルの細かさでデータを表現するという考え方に立つのか、あるいは筆者のようにもう少し高い（粗い？）表現レベルまでで利用を抑える立場に立つのが良いのかという議論になることかも知れません。オープン・データを隅々まで利用する立場であれば、セル単位での表現利用になり得る。
- リンクト・データのアイデアはインターネット世界の情報管理を唱えたTom Berners Leeによるものという説明でしたが、彼の視点ではやはり細部の管理というよりは、情報の存在の在り方を（共有の視点で）まず見ることができるようにしたいということではなかったかと考えます（説明された図を見た限りでの筆者による想像です）。これはどちらかというと「トピックマップ」で情報を管理的に表現するという考え方に近いと思います。勿論最終的に、機械による情報可読状態にまで適用が進めば、最小単位は余り議論の必要はないという点の突っ込み具合が有り得るのですが、筆者はあくまでも人間のための利用を想定した議論をここでは扱いたいところです。
- この理由としては、ネット上の世界は（時に「クラウド」という表現が当を得た言葉と思えるように）取り留めの無い、或いは果ての無い情報世界と思われる点にあります。従って、個別的な出自がどこにあるのか良く分からない細かな数値よりも、全体の情報世界の様子を概念的に抑えておきたいという欲求が高まる、という感じです。繰り返しますが個別的な細部に拘るよりも、全体観を得ておきたい、位置付けを知った上でその中での個の利用に取組みたいという考え方です。リンクト・データに類似した技術は、この全体観を抑えるための技術として始まったが、LODのアプローチはどちらかというと個別データを取り扱うための応用分野として提唱されてきているように見えるというのが、ここまでの筆者の理解です。その適用境界を議論できるようにしておきたいという訳です。
- データを意味的に表現するのがRDF技術ならば、そのデータが置かれた世界（環境）概念を表現するために使用されるのがOWL（Web Ontology
Language）です。これは言わば世界に散らばったデータを、情報から見渡すための意味的フィルターとして用いられるものです。この場合、利用者の責任において使用するフィルターは様々であるともいえます。またオープンデータとして開示されたデータとその加工方法などへの品質保持責任の問題も存在し得るかとも思う。話が大分飛びましたが、これ以上の議論は、第４回以降の講義を聴いてから、更に進めたいと思っています。 （先頭に戻る）
-
その27：オープンデータの利用と、その技術および幾つかの基本課題（その１）
- 数年前のG8サミットでの決議以来、日本でもオープンデータの活用論議が、官公庁関連のデータ開示を中心に様々な場所で議論されることが目立ってきています。現在、私はLOD（Linked
Open Data）の6回シリーズ講義へ参加しています（今週21日に秋葉原駅近隣の開場での第１回が行われました。主催：リンクト・オープン・データ・イニシアティブ（国立情報学研究所））。以下では、その時の内容や議論を通じて、当方が理解し、また感じた内容について簡略的に説明してゆきます。
- まず「オープンデータ」とは何かという定義を確認するところから始まります。「オープンデータとは、誰でも自由に使えて再利用もでき、かつ再配布できるようなデータである。課すべき決まりは、たかだか『作者のクレジットを残す』あるいは『同じ条件で配布する』程度である。（http://opendatahandbook.org/ja/what-is-open-data/）」つまり、この定義による「オープンデータ」は、データ利用に関する権利関係を語ったものに過ぎないといえます。データの意味付けや品質については、そのデータを開示する者に委ねられるものといえます。LODイニシアティブは、このようにして開示されたオープンデータについて、それを利用するための技術的な基盤に関して議論する場であると理解できます。
- つまり、オープンデータを利用する上で「リンクト・データ」、具体的にはRDFの情報表現構造（およびその周辺技術（例：SPARQL））を用いることを提唱することということができます。これは特にWeb環境のようなネットワーク環境上での情報の共有に向いているという趣旨です（RDF（Resource
Description Framework)は、セマンティックWebを議論する中で発展してきた技術）。これはオープンデータの活用性を上げるために、セマンティックWeb論議で蓄積・向上させてきた技術を適用しようとする試みであるといえます。
- ここで、データモデリングの世界から入ってきた私にとって少々違和感を感じたのは、まずLODとして使用されている基本用語でした。例えば「エンティティ」。それはER（Entity
Relationship)方式では、最も初歩から使われる用語ですが、LODで使用する場合、その概念レベルが根本的に異なっています。LODでのエンティティは、ER方式では一つ（１行）のデータに相当する。オブジェクト指向的表現で言えば「インスタンス」に当る。ER方式でデータ対象の概念スキーマで括った「エンティティ」を、LODでは、データ内容を”ばらけさせて”いわば放り投げ細分化したという形でしょうか。抽象的な整理観点を放棄したとでもいうような。最もLODでも、スキーマという考え方を導入しているようであり、ER方式との親近性は図られる方向にあるのかもしれません。
- こういった基本用語の考え方レベルの違いに加えて、LODにおける構造表現では、「時間軸」に関する考え方が定まっていない点があるように思われます。表現した情報が「どの時点」の内容を表しているかが捉えにくいということです。この点に関しての基本表現方法を確立しないと、表された情報を実務的に利用する上で支障が生まれるであろうという点を危惧したいところです。つまり、ある場所や、ある対象を掴まえた場合に、それがいつの時点か（履歴的にでも）知ることができなければ、その情報の利用価値が減る（或いは誤解が生じる）だろうということ。対象が、データの品質や意味が提供者に委ねられるオープンデータであるからこそ、この点は重要なポイントであると考えます。
- 初回の講義を聴いた限りでは、LODの試みは、対象が限定された（オープン）データを限定した意味ネットワーク上で利用する場合には、使い勝手や管理上有効性が出る可能性があるものの、限定を取り払った「拡大世界」の中では様々な制約が生まれるのではないかというのが筆者の抱いた感想です。この先は、第２回以降の具体的技術論に期待をしたいと思います。 （先頭に戻る）
-
- その26：「年齢」変数の不思議さを解明する ．．． 用語定義の確認は重要だという話し
- 前回の視点では「年齢」変数が「間隔尺度」か「比率尺度」かという話題が議論になっている点を取り上げました。この議論が私の思わぬ形で決着したと思えるため、前回稿への補足として以下記載します。
- ことの発端は、Gaccoのデータサイエンス演習の講義映像で、講師が「年齢は間隔尺度」と説明し、これに疑問をもった参加者が意見を投稿したことでした。その中で何故年齢が「比率尺度」ではないのか、寧ろ比率尺度として扱い説明している資料もあるという展開でした。その議論に不審を抱いた筆者が、前回の「視点」話題としてメッセージ25が生まれたという次第。
- その議論の噛み合わなさの原因は、「用語の定義」にありました。
①私は議論されている「年齢」とは最初に所謂、誕生日を迎えた時点での「満年齢」を指した話しだと解釈しました。そうすると自明なものとして、離散変数なので比率尺度ではありえないという考えでした。
- ②ところが、講義内で提供された演習データの「世帯主の年齢（歳）」項目が情報提供された際に、その項目には小数点が入っているという現象が発生。つまりそのデータの「年齢」は、満年齢という離散数値ではなく（多分）「生まれてからの経過日数を用いて365（日）で割った計算値」と見えます。その意味で連続変数化した値として利用している。それなら、「比率尺度」であるとして使っても妥協はできるかなと、改めて考え尚した次第でした。
- つまり、議論の中にも「年齢」という言葉に認識のギャップがあったということ。講義の中で「年齢は間隔尺度」という話が出たのは、この議論から「満年齢」を暗黙に頭に入れて解説したものと想定します。単純に「年齢」という用語を聞いても、その内容を確認しなければ、統計処理上誤りが生じるという好例であると、改めて感じさせられました。投稿者の議論スレッドでも、この辺りの定義が確認されないまま、曖昧な形で議論が混在した感じを個人的には持っています。
- データを利用する上で定義の確認は大切です。以上今回は、メッセージ25への速報的な展開として、短文を記載しました。 （先頭に戻る）
- 補足： 尚、上記説明で「計算した年齢」を、「妥協的に、比率尺度としても良さそう」といった理由は、絶対ゼロの存在仮定には、利用上の暗黙の約束が背景にあると考えるからです。年齢計算上の「相対的なゼロ」でしかないと考える私には、その点若干の疑義を持つ。但し余りこれに拘る積もりはありません。変数利用上の注意点のようなものだと考える方が実用的です。（この議論については、興味ある方は、前回のメッセージを参照下さい）
その25：「年齢」変数の意味合いの不思議とは？
- 無料で参加利用できるオンライン講座の一つに「Gacco」というものがあります。筆者もそこに登録して、現在「社会人のためのデータサイエンス演習」という講座を利用しています。最近、その参加者間で「年齢」という変数は「間隔尺度」か又は「比（率）尺度」と考えるか(※)という議論がありました。筆者は、単純に「比尺度」と捉えることはいえないという立場で、その旨を投稿したのですが、この見方は案外にスンナリとは受け入れられないことに少々意外性を感じることになりました。それをきっかけに、ここでは、データ活用における変数の持つ意味合いと性質が大切だと考えるため、今回はこの「年齢」という変数の提供している概念について考察をしたいと考えます。
- ここで話題となっている尺度水準の分類は、Stevens（1951)による分類とのことです（「調査法講義」豊田秀樹、1998年、朝倉書店、pp.49-50）。そこで説明されているように、この分類の鍵は、変数値に対してどのような操作演算が適用できて、どういった統計量が意味を持つかを識別できることです。尚、今回議論されている「年齢」というのは、改めて確認すると、誕生日を基準とした「満年齢」を意味することにします。以下の内容が、年齢が「比（率）尺度」とはいえないことと、その変数を扱う上での配慮点の幾つかの補足です。
- １）「比（率）尺度」の性質からの議論(上記の定義から、議論上ずれていないことを前提にしています）・この尺度は絶対ゼロ点からの等間隔な目盛り付けが可能で、変数数値に対して四則演算が可能な変数の性質をもつことを指します。つまり適用できるのは「連続量」に対してであるということ。「満年齢」は離散量であり、比尺度としての単純な性質を満たしていません。・また、「絶対ゼロ点」ということに関して。絶対温度（°Ｋ）のような絶対ゼロ点を持つ変数の場合、物理的性質を元にした普遍的定義により、例えば100°Ｋにおける物理的特性を明瞭に語ることができ、そこでは100°Ｋと200°Ｋの違いも数値的・物理的性質として示すことができます。
- ・一方年齢はというと、誕生日という個人の時間軸上の発生起点（個人ゼロ点）を元にしてそこからの経過年を指します。ある人間集団を捉えた場合、それぞれの発生起点は（一般的には）異なるため、個人ゼロ点は一致しません。このため、当該集団の各個人ゼロ点を、「一つの仮想的な経過年軸」においてマッピング配置して共通化する。この経過年軸のゼロ点は普遍的なものではなく「相対的ゼロ点」であり、何ら共通の物理的性質を表現する意味の基準点ではない。また、そこでは元の個人に当て嵌められた性質は消えている。経過年軸上での変数配置を使ってマイルストン的に性質を比べる変数評価を行っても問題は生じないだろうという暗黙的な前提（その範囲で用いる）が利用の背景にあることを意味すると考えます。
- ２）「年齢」変数の性質的議論・漠然と「10歳」というと、相対的経過年があることを示すだけで具体的性質を語れません。10歳のＡさん、といって初めて語るべき意味内容が生まれる。個人を含めた対象集団が明示されて意味を生む変数。
- ・満年齢変数には実際には幅がある。40歳といった場合、経過日を考慮してみると、40.000から40.997（40（年）＋364/365（日換算））の間を意味する。この辺りの違いを実務で考慮しているのが、例えば生命保険会社が契約年齢を満年齢でなく、半年ずらして契約年齢と扱い、保険料を適用する会社があること。
- ・年齢間隔は、意味内容において万人に共通の等間隔概念と言い切ることはできない。－背景となる時期の違い。西暦1000年生まれの30歳と2016年現在の30歳が同じ性質を持つといえるでしょうか？－5歳から15歳までの10年間隔と、40歳から50歳までの10年間隔は同じでしょうか？－米国統計における20歳から25歳の集団の性質は、日本統計での20歳から25歳集団と単純に比較できますか？（比較するとすれば、何らかの妥協があるはず）
- ・年齢変数は、単独で用いるというよりは、個人を含む集団の他の属性や変数と一緒に用いるのが実際的な使い方と考える（単なる集団の年齢分布などの記述統計を除き）。例：マーケティング上のセグメント区分の一要素
- 結論としていえば、年齢を「比尺度」として捉えたいという期待には、何らかの”暗黙的な"仮定の存在があると考えられます。それを意識した「年齢」変数の取扱いを忘れないことが大切でしょう。但し、基本的な分析の場合には、それほど意識し過ぎる必要はないかもしれません。 （先頭に戻る）
- 注 ※ 統計的に扱う変数について、操作概念を元にして当該変数のもつ性質を元に、次のように分類する考え方がある。
- ・名義尺度(nominal scale)、順序尺度(ordinal scale)、間隔尺度(interval scale)、比尺度(ratio
scale) 詳細は、「調査法講義」豊田秀樹、1998年、朝倉書店、pp.49-50）などを参照
-
その24： もう一度見直そう、情報地図としてのデータモデリング視点
- 前回は、データの量と共に質が（より）大切という話題を提供しました。今回は、それに引き続いて「情報地図としてのデータモデル」という話しに触れます。
その必要性の趣旨は、ビジネスに携わる関係者（いわゆるステークホルダ）とのコミニュケーションと、知識の中長期的な継続性を大事にしようという視点から出てくる話題だと考えるから出てくるものです。M2M、IoTという言葉が盛んに喧伝される今こそ、発想を大切にしようという人間にとって、改めて着目すべき点だと考えられます。
- 最近様々な自治体を中心に、オープンデータの話題が色々出てくるようになりました。これは2013年にG8において「オープンデータ憲章」が決議されたことが、国内において盛んになったきっかけであると言われています。このG8会議には安倍首相も参加し、決議を受けて内閣官房に、そういったオープンデータ推進機関が設けられた。残念ながら日本国内のマスコミでは、こういった話題は余り取り上げられていない（2016年4月21日、東京大学坂村健教授談による）。従って様々な領域から、今後もデータのオープン化が広がって行くことが想定されます。
- こういう中にあって、データ（種類および量）は増えるものの、それらがいったいどこに存在して、またどういった関係にあるのかを見極めることがデータ活用の上では大切になってきます。今やインターネットビジネスの世界では代表企業となっているグーグル（Google)やAmazonといった企業は、単純化するとインターネット世界でのデータ地図とその索引（インデックス）処理技術、そしてそれらを参照可能なアプリケーションを広く提供したというのが成功の要因となったと考えることができます。しかし、筆者の考えるところでは、それらの技術を通じてマーケティングを始めとした世界に利用される度合いが高くなるほど、情報を探す個人にとっては使いにくい面も出てきていると思われます。商品やサービス情報を提供する側の論理が強調されることで、利用者側の単純な情報検索欲求に様々な雑音が生まれてきて、素朴な一次情報に辿り着きにくくなってきているということです。いわば、大衆（＝クラウド）にとっての便利さと、フィルターのない元情報入手欲求との相反する関係とでもいえる。
- そういった意味で、自分の周辺にあるデータを基本にして、追加される（オープンデータを初めとした）データの所在およびその意味と関係をしっかり把握しておくということが大切になってくるということでしょう。得られたデータをビジネス上で利用しようとするほど、その参照出典を理解しておく姿勢が求められる訳です。出所や意味づけの不明な情報・データを元に、重要な意思決定をしようとするほど、リスクの高いものはない。そこで、しっかりとした情報地図を備えておくことの必要性が生まれるということになるというのが筆書の本ノートの趣旨です。そのためには、データのモデリング（或いはデータモデル（＝情報地図）そのもの）が大切だということになります。以前の稿でも触れていますが、データモデリングというとその記法に拘りを持つ人の対立のような話が出てきてしまい、本来の利用趣旨から議論が離れていっていしまう傾向が高いという筆者の経験もあります。筆者としては、ある程度のデータモデリングの基本理解は必要だが、それに拘り過ぎると本末転倒であると考えます。もちろんデータ表現の正確性を議論することが大事であることは否定しません。
- そこで筆者の提案したいのは、データモデリングへの「ブレンド発想」という視点です。技法に拘り過ぎず、適度に方式に頼りながら、その効果（＝情報地図そのもの）およびメリットを楽しむということ。これについては、今後話題として触れてゆきたいと考えています。 （先頭に戻る）
-
- その23：量と質と、どちらをを優先すべきか？
- ビッグデータという言葉の概念はかなりの範囲をもって多様に用いられており、必ずしも確定しているとまではいえないというのが現在までの筆者の認識です。しかし何となく使いようによっては役に立つこともありそうだというのが最近の社会的認識といえるでしょうか。関連するベンダーや周辺のビジネスに係わる人たちから発せられる過剰なメッセージ発信というのが多くの雑音を生み出すというのは、常であるともいえます。これらの過剰メッセージが、また一つのビッグデータ（ビッグノイズ？）を生む要員ともなっていることは社会の皮肉といえるかもしれません。
- この多様なデータのソースから生まれる（いわゆる）ビッグデータの有用化進めるためには、ITの処理技術利用の高速化が貢献しているということが、社会の共通認識であることの否定はできません。しかし、最近目にする機会が少なくなりましたが、データ利用における「ガーベージイン・ガーベージアウト」（”ガラクの生むモノはガラクタ”とでも訳すか）という言葉は決して忘れてはならない重要視点です。様々なアルゴリズムやロジックを開発利用することで、どれだけ高速に大量データに潜む特徴を要約抽出したとしても、意味のない結果を取り出し、それに基づくビジネス的意思決定やアクションを繰り返すとしたら、経営資源の大きな損失に直接結びつきます。データの闇の中から抜け出して、いわば明るいところに向かって進んでいる積もりが、とんでもない方向に向かって進んでしまいかねないということになります。
- 従って、ここで注意しておきたい点は「量よりも質」に拘って取り組むべきだということです。「質が伴ってこそ、初めて量が意味をもつ」点に意識を配り、ビッグデータの蓄積と処理技術を生かすことが眼目となります。その質を支える事柄が何であるかと一言でいうのであれば、正しいデータマネジメントに徹することです。つまり、(1)ソースのデータの持つ意味を正確に捉えて、その姿を知り、選択維持を行うこと。(2)意味の曖昧なデータが含まれる場合には、それを利用するリスクについて意識を向け、利用上の許容範囲を設けた上で対処策を設定すること。(3)取扱いの量が大きくなる（または種類の多様性が広がる）のであれば、技術の力を十分に活用すること。(4)質を作り込み、維持するためのプロセスと組織立てに取組むこと。以上の点を胆に命じたマネジメントの仕掛け作りをしたいものです。
- そういった点を確実に行える高い可能性を持っているのが、本来の日本的文化の特質ということだと筆者は捉えています。マネジメント上で、それが必要である理由を共有し各自が理解する。それに従って各自の意識（動機付け）を高く維持行動する。職人気質のような自主性を、最大限に生かす。いずれも日本の人たちが長年培ってきた精神的文化の要素といえます。改めて「日本的」な人々の特徴や文化性を生かしたデータマネジメントの実現。そしてその上でのビッグデータ活用社会を形作りたいものです。
- 思えば、少し下火になる傾向が見え出したとはいわれるものの、まだまだ衰えることのない「中国の人たちによる日本製品の爆買い」という社会現象は、「安かろう悪かろう」型の普及品よりも、日本製品の「質」への信頼性を頼ろうとする意識の表れであるといえます。質を疎かにした製品やサービスは、一時的に多くの自己利益を生むかもしれませんが、中長期的な形で社会的面から見てマイナス要素であり、また大きな害悪を撒き散らしているともいうことができます。 （先頭に戻る）
- 補足： 賢人のことば（最近の風潮を思う）
- －ずるがしこい人間が賢人として通用することほど、国家に有害なことはない（フランシス・ベーコン） ダイヤモンド社「アリストテレスがGMを経営したら」P.250 トム・モリス（著）、沢崎冬日（訳）
-
その22：規模を踏まえた、データの管理と組織作りのヒント
- 組織におけるデータが横断的に利用できるためには、その品質が重要になってきます。個別の業務アプリケーション作りのためだけに設計された情報システムと、そこで処理するデータというのは、そのシステム内の範囲で矛盾無く設計され扱うことができていれば、一通りの役割を果たしていることになります。しかし一旦設計された情報システムは、その範囲での意味作りを行っているため、システム外部との連携を行おうとすると途端に立ち止まらなければならない自体を生じます。つまり、基本的なデータ用語（つまり定義）が外部と共通であるかどうかを確かめてからでないと、正しいコミュニケーションが行えないことに気付くからです。従って、組織横断的な資産としてのデータ活用を実現するためには、その意味合いとしての約束事を可能な限り参照辞書として定義・蓄積を行い、それを共同利用するという発想が行われる必要があるということです。
- この考え方からすれば、個別的発想のみで情報システムの設計を進めることには、大きな問題があるということになります。従って、組織的または小規模であればツールを活用した共通管理、という考え方が必須なものとなります。それでは、まずこの組織的な管理を行う上でどういった視点を用いて組織作りをする必要があるのでしょうか？ここでは、海外の情報システム構築の基本的な考え方を元に幾つかの考慮ポイントをヒントとして記述してみることにします。
- 組織作りを有効にするためには、その動機付けが必要です。単に絵に描いた餅のようにお絵かきをしているだけでは実効性の高い組織活動には繋がりにくいという意味です。そのために、組織の全体運営に責任あるポジションの人がデータの取扱いに対する基本方針を明示し、継続的にコミュニケーションを取り、体制と仕組みの運営を実施してゆくことを関係者に明示する必要があります。そしてそれを実際に運営する組織体制を準備する。最初は大がかりな体制作りは難しいかもしれませんが、小規模から始めることにしても良しとしましょう。ここで必要であれば、信頼のおける（外部の）専門家の協力を当初仰ぐというのも一つの選択肢であるといえます。繰り返すと、まず管理運営宣言を行って、見える形での組織立てを行うことです。
- そして、実務を主担当とできる部署（または人）を準備し、その部署（あるいは担当者）が管理上の発言権をもてるようにトップの経営部門がサポートを行う形式を取る。勿論ここでは形だけでなく実際の活動と結び付けることのできる人と役割が結びついている必要があります。そのための予算の割り当ても必要となります。ここは可能な限り、各ビジネス部門の責任者と連携を取れる意味での人を選任する意識が必要です。そして長期的な視点でその役割を果たすことができるように位置付けることです。そして個別のシステムプロジェクトにも連携することを明記する。これが継続的に行われることで初めて、部門横断的なデータ活用が可能となる。コミュニケーションの基本を考え方の基礎に置くという視点から攻めることが必要です。
- 少し考え方を変えて、中小規模での企業がデータ活用を行うことを見た場合、組織作りから始めるというのは現実的でない可能性があります。ここでは組織よりも「確実なデータ管理」という目で一貫した継続性の視点を重視する。そのためにツールを利用したデータ管理を積極的に行うことが大切でしょう。昨今、クラウド上でのデータ管理ツール（利用者本人がそのように意識していなくても）利用が流行している理由は、そのような所にあると考えられます。共通化とアクセスの利便性というメリットです。その場合には、データアクセスへのセキュリティ管理と確実なデータ保管および復元性（バックアップ確保）、という視点がより重きを置いた見方となる点に注意したいものです。 （先頭に戻る）
-
- その21：「良いデータモデルとは」、どんなデータモデルだろうか？
- 1月29日（金）には、 JEMUG（日本エンタープライズ・データモデリング・ユーザーグループ（ERwinユーザーで組織化されたグループ）の日本での活動団体）で主催するデータモデリング・コンテストの
結果審査のための集まりが開かれました。これは、毎年JEMUG日本グループの会長を中心にして、一つのテーマを決めて25個以内のエンティティを利用してテーマに対応するデータモデルを募集し、優秀者には賞品を提供し努力を讃え合おうという趣旨で開かれているものです（この結果については、その結果紹介ページを参照）。所長である筆者もこの会に参加し、応募されたデータモデル作品について議論を深め合ったという訳です。また、第2部では、米国Datavercityのページで配布していたメタデータに関する話題の白書を題材に議論を行いました。
- このデータモデル審査を行う中で、改めて「良いデータモデル」とはどういうものかということが幾つか議論になりました。コンテストでは、先に示したように25個以内のエンティティでテーマにあったデータモデルを記述するということなので、モデルの厳密性ということよりも、テーマの趣旨をできるだけ正しく捉え、表現の意図が審査参加者（今回は6名）に分かり易いかどうかという点を中心に話し合いました。つまり要約してみると、(1)テーマで表現したいデータ要素が、きちんと押さえられているかどうか、(2)用語の使い方は適度な表し方レベルをしているかどうか、(3)リレーションの表現やエンティティの配置などが分かり易く記述されているかどうか、などの点です。データモデルを作成する趣旨は、単に設計者の備忘録的なメモではなく、作成されたデータモデルが、他の参照者に正しく伝えられでこそ価値を生むものである、ということです。JEMUGのコンテストではERWinデータモデリングツール（コミュニティ版）を使って作成することが条件となっているため、使用技法はIDEF1X法によるリレーショナルモデルです。モデルの表現レベルは「論理レベル」を意図しています。
- ここでエンティティ数がかなり制約されることから、モデル作成においては、適度な「抽象化」の工夫が求められます。この抽象化というのは、帳票類を元に出現されるデータ項目やそこから現れてくるエンティティに目を向けてモデルを作成しただけでは、余り意識されない観点であることが多いです。簡単にいうと、類似のデータモデル構造としてエンティティを取りまとめて表現し、作成するエンティティ数をできるだけ少なくする技法の一つということができます。この技法を用いた場合、エンティティ群にまとめられた概念を区別するために「コード体系」を整理し、それを仕様として明示・管理してゆく必要が出てきます。本来はこれらのコード体系もデータモデルを構成するドキュメント要素として重要な位置付けとなります。特に規模の大きなデータモデルを作成・維持する場合には大切な内容であり、いわゆる「マスタデータ管理」の一つの胆でもあります。今回の応募作では、このコードを表現する補足ドキュメントまで完璧に備えたものはありませんでした（例示に留まるレベル）。
- 前記の審査のポイントで特に強調されたのは、テーマの捉え方でした。テーマとして表したい業務のプロセス領域と、業務支援の状態の流れが第３者にイメージが付けられるようなモデル表現になっているかということでした。鍵となる業務要素ができるだけ漏れなく、確実に表現されているかという点です。こういった議論により、先ほどの抽象化という観点は「余りに抽象化に拘り過ぎてもいけない」という点に辿り着きました。つまり、表現されるエンティティ数が少なければ少ないほど良いとはいえないということです。特に論理モデルの場合にはそういったことが大切ではないかということです。極端にいうとエンティティ数が数個あれば業務プログラムを動かすことができるということを強調するエンジニアが現れることがありますが、それでは他者にとって分かり易い論理モデルとはいえないということです。繰り返しますが、モデルから生み出された実際のシステムの概念が、正しく第３者（この場合には、後から維持・管理・拡張などの作業に携わる人たちを意味します）に伝えられるかということです。これが達成されることで、データモデルで表現される概念が、後続に伝わり、ライフサイクル全体として生産性が高く、かつ寿命の長いシステム作りに繋がるという発想です。
- そこでは、個別の細かな技術的表現を議論することは止めて、一番胆となるデータモデル作成への基本スタンスを記述しました。あまり特定の技法や教条主義的な方法論の強調では、データモデル利用者にとっての無理が生まれるという見方からです。システムは、単に動いていればそれで良いということではなく、継続的に概念が正しく伝えられることこそが重要ということです。特に論理的なレベルで伝えることができることが、ビジネスの視点では大切と思われます。クラウド環境の利用が進んで来た今日こそ、特に忘れてはいけない視点であると筆者は考えています。 （先頭に戻る）
-
その20：「システム作り」基本に立ち返るということ
- 筆者は、心理学分野にも興味をもつ者なのですが、最近その中で「色」というものの持つ力に興味を抱いています。考えると色を見てイメージ感じ、その中に意味を見出すというのは大変不思議なことです。「光線には色がついていない（The
Rays are not coloured.)」とプリズム実験により光線に潜む色の性質を喝破し、「ニュートン色環状」にまとめた（1704）のは、かの有名なアイザック・ニュートンです。虹が7色であるという考え方を提唱したということになります。光線には色がないというのは、白色光が自然界の物体により部分的に吸収、または反射が行われ、それを人間などの視覚器官が捉えることで、人は人なりの色を感知する。また物体の輪郭を識別するということです。
- 物事や事物の振る舞いを認識する、或いはシステム化するといったことも、この光からの色の認知ということに似ていると考えると分かり易いのでは考えてみました。つまり、対象としている事物自体の振る舞いには本来確定したものはなく、そこから観察者である人間の方が、何らかの規則性を見出そうとして努力し、それを言葉という機能により固定化しようとしている。そしてこの約束事を仮定して、外界の事物があたかも「そういった輪郭を持ったもの」であるかのように取り扱っている。自然光の場合、実際には色として関知できるのは、視覚器官の果たすことのできる範囲だけを対象として関知し、それ以外（例えば、赤外線や紫外線など、大変多くの電磁波成分）は無いもののように取り扱っているという訳です。
- ここで取り上げたいのは、結局システム化には本来の事物に（あろうはずの）様々な要素の一部のみが「規則」として固定化され、例えばコンピュータシステムであればそのシステム要素で組み立てられた範囲で認知され、取り扱われているものであるということになります。大方日常業務として支障のない範囲であれば、それを是としてシステムを利用しているということです。従って、システム作りにおける約束（外界の認識の仕方）を関係者で共通化しておくといったことが大変重要であるということに他ならないということです。
- ここで改めて、今回の題目の「基本に立ち返る」ことに行き着きました。システムを利用する自分たちが、どのように外界を定義し、また見ているのかという点をしっかりと表現しておくこと、そしてその内容を継続的に引継いでゆくことが、昨今ビジネス用語として用いられている「サステナビリティ」や「事業継続性」の概念にとって重要なものであるということが理解されるのではないでしょうか？クラウドやアウトソーシングなど、外部の資源を活用することは経済性の観点で避けられないものとなっていますが、根幹となる要素については、自分たちでしっかりと抑え守って行くことが求められます。
- つまり、そのための技術についての知識を所有し、その技術を生かして行く体制作りといったものが、経営視点からも重要であるということです。この要素の中に、データの定義や振る舞いをキチンと約束化する「データモデリング」の概念が含まれることはいうまでもないことであると、筆者は考えています。それは、「基本に返り、自分たちのビジネスの核となる要素をマネジメントする」ということだと考えます。 （先頭に戻る）