アーカイブ2018年

  • その66： データモデリングとオントロジーの関係性
  • 12月10日（月）に、筆者の所属する日本エンタープライズデータモデリング・ユーザーズグループ（JEMUG）の定例勉強会が行われました。筆者もその中で、メッセージその64で触れたTheBrainツールに関して１セッションの紹介説明を行いました（この時の資料については游悠レポートサイトで公開する予定です）。この時のもう一つの話題として「データモデリングvs.オントロジー」という題目で議論が繰り広げられました。今回はその時の内容について簡単に触れることにします。（また、今年もJEMUG主催による「データモデリングコンテスト2018」が開かれます。その要領は、JEMUGのWebページに掲載されていますので、興味のある方は是非チャレンジして下さい。=>　こちら
  • データモデルを扱っていると、オントロジーと言っている領域との違いが曖昧になることが、筆者には良くあります。しかし、オントロジーを近年標榜する人達からすると、データモデリングに携わる人々とは大きな違いがあると意見する記事が見受けられます。今回の話題はそういった内容の議論資料を元に提供されたものでした。
  • 昨今のオントロジーを語る記事では、RDF（Resource Description Framework）とOWL（Web Ontology Language）の表現技術を利用した、意味ネットワーク系の考え方を主体としたものです。一方のデータモデリングの技術は、オントロジー論者からは、リレーショナル表現を用いた主にリレーショナルデータベース（RDB）向けの技術として捉えられている形です。この辺りに互いの認識の差異が生まれていると筆者には考えられます。
  • リレーショナル表現を用いたデータモデル設計は、階層的に異なった設計視点レベルがあると考えられており（概念・論理・物理）、それぞれに設計表現の範囲の違いがあります。筆者の見方としては、概念モデルはモデル対象のスコープを表現するのが主目的であり、論理モデルは正規化を主軸としたデータ構造の在り方を記述するものであり、物理モデルは実装上の物理環境を考慮した設計変更の手段を表現するものです。また特に論理レベルでの設計では、対象領域の「抽象化」という捉え方と「集合的なまとまり」を基礎に置いているのが特徴と言えます。実際はプロセスの部分は、エンティティ・リレーションシップ図（ER図）だけでは表現しきれないため、別途のプロセス表現をするための補足情報や、エンティティの表す内容を説明するコード値情報などが必要になります。単なるER図だけでなく、前記の情報を含めてデータモデルの意味が分かるというのが正確なところです。
  • 一方、意味ネットワークの技術を介したオントロジー設計というのは、抽象化というより、実世界に存在する個別のオブジェクトに目を向けて設計表現を行うといった、敢えて表現すればボトムアップ式の捉え方をしているという具合に筆者には見えます。個別対象およびその振る舞いに主要着眼点があるという意味です。このような視点のオントロジー発想からすると、ＥＲ図式のデータモデリングは個別の構造表現を行っていないと映るようだということです。このような見方と互いの理解度の違いにより、今回の話題のような両者の「対立的」な議論が生まれているのではないか、というのが筆者の感じた点でした。実際には、元の資料での議論となるような大きな差異はないという意味です。
  • また、以前にこのメッセージ欄で筆者が触れたように、(1)高い抽象化レベルをデータモデルに適用しすぎると、反ってモデルで表現しようとする対象領域が分かりにくくなる、(2)構造の分かりやすさの点では、具体的な個別インスタンスをＥＲ図で表現しておきたいことも生まれる、といった点がデータモデルへの要請としてあるのではないかというのも、議論の補足になります。そういった部分を、意味ネットワークベースのオントロジー表現が補完することがあるという意味です。
  • 今回の話題に関して、両方の世界の技術者が全て納得するという状況にはならないでしょうが、こういった折衷的な視点を交えながら、モデル化とシステム構築の世界が発展してゆくと考えるのが筆者の結論ということにしておきます。 　　　（先頭に戻る）
  • その64：　メタデータ、データ、そして情報利用＆発想への新しい形
    • 皆さんは、パソコンに集まってきたデータや情報の整理・活用にどういった工夫をしているでしょうか？　それとも、全く困っていないなどという方もあるでしょうか？　それで本当に、有効な仕事やくらしへの時間配分が満足にできてると宣言できますか？今回は、そういった課題を日常的に抱えていると感じ、それを何とかしたいと考えている方のために、情報ツールを活用した対策方法について簡単に紹介したいと考えています。
    • 課題その１：　資料は色々集まって来るし、ネット検索すれば何かと情報を手に入れられるが、量が多すぎて結局何から手を付けたらよいかを考える前にくたびれてしまう。確かに役に立ちそうなデータや資料があったはずだが、それを後から探し出すのに時間が掛かっている。
    • 課題その２：　様々なデータや資料についての関連性を整理したいが、パソコンの上であちこち行ったり来たりしているうちに、肝心の要点を忘れてしまって、思い出すのに一苦労させられた。
    • 課題その３：　以前に結論を出したときに利用した情報を見直していたら、別の新しい視点からそれを使えることが分かったが、コピーして使ううちに同じようなデータが（PCの）あちこちに散らばってしまった。どれがオリジナルで、どれが最新のものなのか見分けが付きにくくなってきた。
    • これらは何れも、データや資料についての意味付けや、物理的な配置構造管理の問題と関わっています。今のパソコンやタブレット／スマートフォンなどが提供する基本機能が、必ずしも個人個人の必要としている情報の見方・使い方ニーズに合致していないという中途半端な状態であるからだといえます。いってみれば、データや情報を貯めるバケツにはなっているが、それを自由自在に操ることができるような仕掛けを十分に提供してくれてはいないということです。
    • 正直これは、筆者にとっても長年の悩みの種であったといえます。そしてそれを解決してくれそうなツールとして数年前に目を付けたのが、
      「TheBrain」というものでした。このツールの当初の発想は、マインドマップのような人の発想を支援するためのネットワーク図を管理するためのものであったと想像されます。現在はバージョン10が出ており、キャチフレーズとして「The Ultimate Digital Memory」を標榜しています。このツールの面白いところは、各利用者の発想で、個別に情報同士の関係性を自由に定義できることにあります。いわば自分に合った意味のネットワークを作れることです。スケジュールやタスクの管理に結び付けることができるという優れものです。
    • この紙面幅で、言葉だけで言われてもピンと来ないと想像しますが、YouTubeの動画サイトで「TheBrain」をキーワードにして検索すると基本的な機能や使い方、利用事例といったものを見ることができます。説明は英語だけですが、視覚的に動きを知れば理解が深まると思います。是非覗いてみて下さい。製品の価格もそれほど高くはありません。
    • 筆者は、次回のJEMUG勉強会でこのツールの利用について、少し時間を使って説明実施する予定です。もしご興味のある方は参加してみて下さい。
      （筆者宛て、「お問い合せ」から連絡を頂ければ、申込み方法をご案内します） 　　　　（先頭に戻る）
    •  
    その63：　恒例、JEMUGグループ勉強会での話題 について
  • 昨日（10月9日）、ほぼ３ケ月ごとに開催しているJEMUG（日本エンテープライズデータモデリングユーザーグループ）の勉強会がありました。今回は、そこで話題になった内容について簡単に紹介します。
  • 一つ目の話題は、システムの見直し・再構築に当りデータモデルを中心に据えて、どのようにシステムの利用者部門とのコミニュケーションを正しく図れるようにできるかということでした。これはある大手のシステムベンダー企業に所属しているA氏からの体験に基づく事例紹介に近いものです。ここでは、その利用方法に加えてシステムの再構築に当ってのデータモデル利用をする方法論として、どうしたらそのステップが必要なものとして利用者部門、ひいてはスポンサーとなる経営者に理解を深めてもらえるだろうかという点も話題になりました。そういう点では、筆者がこのコラム記事の中で何度か触れてきた内容と重なる部分が多いものでした。
  • 経済産業省が最近、2025年を目処に古いシステムは何とか再構築をしておかないと過去の遺産にシステム部門が押し潰されてしまうという危機について警鐘を鳴らし始めています。放っておくと旧来システムの維持だけでシステムを担当している人たちの時間が１００％取られてしまうことになるということでしょう。これを回避するための中長期的手段としてデータモデリングの手法をうまく利用して、実質的な効果を生むプロジェクト進行をするようにしたいという関係者の思いということです。勿論これには、本当の経営者の理解が必要です。世の中の流行だけに追い回されるような対応をしていると、いつの間にかドロ船に乗っていたことに気付かない状態（あるいは茹でカエルか？）になりかねないということです。
  • 二つ目の話題は、データモデルの中でエンティティのある属性項目を変更する必要が生まれたときの所謂マスタデータ管理に関連するものでした。具体的な話としては、商品マスタの中である商品について名称の変更が発生した時に生じうる不都合についてでした。主キーに日付けを入れてマスタ履歴として管理すればこの問題にうまく対応できるだろうかという点。下手するとマスタ内の変更が起き得る全ての属性項目に有効日付項目を対応させる必要が出てくるのではないかという点。これはアプリケーションプロセスで何らかの対応（ロジックの組み込み）が必要になるだろうということ、或いはトランザクション内に属性の必要項目として、発生時点情報として含めておけば良いといったような手段が議論されました。これはいわゆるSCD（Slowly Changing Dimension）の話題になるというのが一つの結論でした。
  • 三つ目の話題の投げ掛けは、データモデリングとオントロジー分野の連携性の話がありました。海外の医療関係領域で、病名と対処方法との間の関係としてオントロジー的な動詞句表現で整理表現する動きが出て来ているということ。この流れに日本語を乗せるのは難しいという話題にもなりました。その具体的な内容に関してはここでは触れませんが、オントロジーを専門としている人々とデータモデリングに携わる人々の意見の交流と理解度深化が必要となるだろうといった意見も生まれました。この話題は次回の勉強会で継続する予定になっています。
  • 筆者は、第四の話題として、前回にこのコラムで取上げた「データモデリングを支えるツール」について、一部のツールに関しては具体的な内容を取上げて説明し議論しました。この内容の一部は以下の「游悠レポートサイト」でのレポートを参照下さい。
  • ⇒　「2018-001参照」
  • こういった勉強会への積極的参加者を増やして行きたいということで、この回（会）はお開きとなりました。このコラムに興味を持っている方であれば、できれば参加を促したいものです。 　　　（先頭に戻る）
  • その62：　データモデル作成を支援するツール群 の紹介
  • これまでデータモデルに関して、何度も話題を取上げました。今回はそういったデータモデル作成を支援するツール群の概要紹介をしたいと思います。
  • ツール類の利用というのは、年月が経つ毎に変更が行われ、また流行廃りが起きるためそういったモノの選定に悩む利用者は多いでしょう。折角幾分かの投資をして導入されたツールが直ぐにサポートや提供終了ということになると目も当てられないといったことが気になります。しかし使えるツールを活用せずに、全て手作業で対応するというのはもっと時間や手間ということで考えれば、余り良いこととも思えません。要するにツールは単なるツールとして捉えて、そういったサポート期限も考えながら利用ノウハウとして自分の中に蓄積される知識を大事にするという考え方で臨むのが、一番上手い方法ということができるでしょう。
  • 今回「データモデリングを支えるツール」は、３つの分類で捉えることにしました。第１番目はエンティティリレーションシップ図（ER図）による記述方法をメインで提供するツール群。これらは、ER図を単純に記述するだけでなく、そこで書かれた設計情報を元に、論理（考え方設計）・物理（実装）を支援する機能を提供する役割を果たすものが大部分です。例えば、リレーショナルデータベース（RDB）へのテーブル作成用DDLを自動作成する、或いはRDBに作成されているテーブルからモデル内にその定義情報を取込む（リバースエンジニアリング）ことができるといった具合です。また設計情報のメタデータを保有するリポジトリという位置付けで広範囲に応用できる製品もあるのが特徴です。
  • 第２番目は、データモデル図として、UMLのクラス図での記述を中心に据えているツールです。これはどちらかというとオブジェクト指向によるシステム開発を支援する立場で考えられているツールといえるでしょう。クラス図以外のUML記法や、プラスアルファの機能を合わせて提供して、設計者や開発者の作業を手助けする立場といえるかも知れません（ER図記述も補完的に一緒に提供するものもあります）。
  • 第３番目は、システム開発の上流（要件収集）から下流（開発工程）までの流れを捉えて、データモデリングというより全体的な開発プロセスを支援する位置付けのツールです。データモデリング部分は全体プロセスの一部分として考えられているのが特徴といえます。どちらかといえば「方法論を含めて、開発全体の流れをを一つのベンダに依存しても良い」と考える利用者が取り得る選択肢と考えられます。そのベンダからの当該ツール環境の長期的サポートを期待できるという前提が期待できれば、良い考え方といえます。後はどれだけ費用の交渉力を維持できるかという点が鈎になるかもしれません。また、中にはマインドマップ表記を可能としているものがあります。提供機能範囲に比較して安価に入手できるものもあります。
  • 敢えてサポート（或いは製品のライフサイクル）について記述したのは、この分野のベンダやツールの移り変わりが、近年結構行われているという点にあります。少し前まで開発元であった会社がいつの間にか別会社に移っていて、その結果開発やサポート方針が大きく変わったという例も少なからずあります。今回の調査に当っては、2009年12月のIT Leadersで取上げられた記事を基準にして、その後の移り変わりという視点で整理してみました。（筆者としては、日本のツール開発・提供社が少ないというのは少々残念ではあります。）このため、例えばVisioのような描画ツールに近いと考えられるものは、検討対象から外して考えています。
  • 個別のツール情報に関しては紙面の都合上ここでは省いているため、具体的内容は以下の「游悠レポートサイト」でのレポートを参照下さい。
  • 　⇒　「2018-001参照」 　　　　　　　（先頭に戻る）
  • その61：　メタデータ活用への第三歩（メタデータ活用に特別なツールは必要か？）
  • 前回、「メタデータ」利用の視点として人気のある見方に三種類位あるということを記述しました。では、これらの見方を実際導入する際に特別なツールが必要でしょうか？答えは、目的によって、「イエスでもありノーでもある」でしょう。メタデータの管理そのものは、いってみれば保持している情報／データについての論理的な手続きなので、管理する本人がそのデータの関係を理解できれば良く、それはスプレッドシート・ツール（例えばExcelなど）を使えば管理することができます。これが「イエス」の意味です。しかし管理するメタデータの対象ボリュームが増大すると、中々スプレッドシートだけで対応することは難しくなります。また、保有内容の共有、或いは視覚的工夫により利便性を向上させるという点でも、スプレッドシートだけでは効果を上げるのが難しいといえます。これが「ノー」ということの意味合いです。
  • 「特別な」ということでいうと、その範囲はピンからキリまであるといえるでしょう。データベースや視覚化ツールにはオープンソースをベースにして用意されたものから、かなり専門的で大規模なメタデータ量までの対応を可能にするプロユースのものまで幅が広いということです。導入や管理に必要なコストも大きな違いがあります。手始めに簡単なツール利用の導入から始めて、要領やイメージを得た上で、自分たちに必要な機能を頭に描きながら拡張を考えて行くのが一般的な進め方だといえます。いずれにせよ、旧来の技術の考え方の範囲だけで収まってしまい、ツール利用の恩恵を得ない状態に止まるというのが最も良いとはいえない立場だということは間違いないでしょう。この点は、システムに携わる者として忘れて欲しくない点です。
  • 「メタデータ管理」は、ある意味データの関係性についての把握ということでもあるため、例えばデータのモデリングツールをうまく活用するという考え方もあります。「メタモデル」は当然のようにデータモデルツールを使って可視化をすることができるし、メタデータエンティティ間の関係性を図表現することにも使うことができます。後は一段と進んだ視覚化への要求、メタデータ共有の方法、維持継続性といった点を踏まえて、どのようなツールの組合わせを選択するかということです。コスト／費用の点も実際には外すことができない要素です。
  • 「メタデータを制する者は、データ活用の実態を制することができる」という意気込みで、是非取組むべき分野であると、筆者は考えています。後は、「実行あるのみ」ということができます。 　　　（先頭に戻る）
  • その60：　メタデータ活用への第二歩（メタデータの活躍の場はアラユル所に存在するということ）
  • 前回、「メタデータ」という用語の基本的な再確認と、それを管理することの大切さを考えてみました。つまり、データというのは、「メタデータ」と一緒に使ってこそ意味（データの表す背景）が理解できるということです。同じ文字・数値が並んでいても、それに付加されているメタデータの内容によって意味が大きく異なります。単位を誤解したために、大きな宇宙開発プロジェクトの活動が失敗に終わったという海外エピソードも、事例や教訓として流布しています。
  • 「この『メタデータ管理』をキチンと実施したからといって、一体どれだけの収益に繋がるのか？」といった点に明確な数値で応えることができない場合、その手間に掛かる活動時間や経営的投資を妨げる元になるという点を気にする人たち（特に経営者に少なくないと想定しますが）があれば、それは「データを活用するための投資」の意味を理解していないと言えると考えます。「数字で表せない事柄は管理できない」という言葉を耳にした方は少なくないと思いますが、それは所謂PDCAサイクルを回すという、プロセス管理や品質管理での話題です。つまり戦術上の議論でアルということを示したい訳です。しかし、データやシステムの「活用」を目指すという議論の中では、「メタデータ管理」は「戦略議論」に位置すると考えるべきです。つまり、見返りを期待する投資発想ではなく、企業における前提となる基本態度であるという視点です。
  • 自分たちがどちらの方向に進んでいるかが分からないのに、精一杯動くということに不安を抱かない人があるでしょうか？あるとしたら、それはイエスマンだけの状況であるということに事ならず、そういった企業活動こそが効率性を欠く企業活動の原因になり得るといったら過言でしょうか？（これに対する意見は色々あることと考えますので、一先ずこのレベルで止めておくことにします）
  • メタデータがコンテキストを支えるものだとしたら、基本は５W１H発想で考えることが一番分かりやすいといえるでしょう。データの持つ意味を考えるのにどういった内容をメタデータとして揃えて行くかということです。次に考えるのはその構成です。これは、データにデータモデルがあるように、メタデータにもモデルがあるということです。これを専門的には「メタモデル」と呼んでいます。三番目の要素が、集積し関係付けたメタデータをどのように利用するかという利用者としての視点です。これには、現在人気のあるシステム視点として、次の３つがあります。(1)グロッサリー（企業用語集）、(2)データリネージ（データ間の繋がりや関係性を捉える）、(3)影響分析（一つの修正が、連携している下流のプロセスにどのような影響があるかを知る）、といったような項目です。
  • 続きは、次回に考えることにしましょう。 　　　（先頭に戻る）
  • その59：　メタデータ活用への第一歩（データへのコンテキストを与え、管理することの重要性）
  • 6月26日に、ほぼ3ケ月ごとに開催しているJEMUG（日本エンタープライズデータモデリング・ユーザーズグループ）の勉強会が実施されました。そこでの議題項目は、(1)データモデリング・スコアカード、(2)エンタープライズ・アーキテクチャを指向する支援環境（ツール類）の動向、(3)データ分析活用におけるメタデータ処理の課題、といったようなものでした。それぞれ、興味深い話題でしたが（そのうちの一つは筆者によるものなので、尚更です（笑））、今回は(3)の「分析とメタデータ」で触れられた内容に関連して考察を加えます。
  • 「メタデータ」は単純には「データのデータ」、少し説明を加えると「データに関する情報を記述したデータ」として理解されています。「データ」は、言ってみれば単なる数値や文字の集まりですが、このデータが意味している内容および取扱い上の背景を説明するモノが「メタデータ」であるということです。「マスタデータ」という言葉もありますが、それはどちらかというと「同類のデータ集合」そのものの持つ意味合いや分類に着目した話です。これに対して「メタデータ」は「あるデータそのものの説明」及び「データ群の違い」を表現するといったかなり広い概念に用いられていると言えます（「メタ」という用語そのものが「上位概念を指す言葉です）。従って、「データのある所にメタデータが必ず付与されている」ということができます。
  • このメタデータがデータ群についての意味を表しているのですから、その意味が正確に共有されないと「データ」の示す内容がうまく伝わらないことになります。単純には「１２３」という数字があっても、それが貨幣を指していて「円」なのか「米ドル」なのか、或いは重さを示していて「グラム」なのか「ポンド」なのか、といったことが全く議論できないということです。これだけでも如何にメタデータ無しの生活ができないということが分かるでしょう。実際、この単位を誤って処理したために、宇宙開発分野で大きな損失を蒙ったという例が存在しています。「曖昧なデータは取り扱うことができない」、寧ろ「曖昧なままに扱うと危険を伴う」ということです。企業には多種多様なデータが溢れているのですから、メタデータを管理していくことが非常に大切であるということが分かると思います。
  • そのメタデータを管理するということは、かなり以前から「情報資源管理」という言葉で重要視され、ISO/IEC11179という技術標準などでも扱われています。また図書館の分野では書籍類の管理についてのダブリンコア・メタデータ標準をベースに書誌管理を行う取組みとして早くから利用されています。データを資源として活用しよう、AI（人口知能）分野でビジネスを広げようという時代背景にあって、メタデータがキチンと管理されている状態というのが大前提になるという意味が、読者にはよく分かるのではないでしょうか？しかし、このメタデータをうまく取り扱えるようにするということは、一朝一夕にできることでない点を忘れることができません。言わば、何種類ものデータに関する辞書作り（維持）を行うということですから、その手間と継続性確保には「決意と持続する意思」が要求されるといって過言ではありません。
  • 小規模なメタデータであれば、表管理ソフトで個人的に扱うことができるでしょう。しかし、企業・組織レベルでのメタデータをうまく扱ってゆくには、そういった単純な手段だけでは継続が難しいと思います。昨今、メタデータの管理・活用をするためのツール類も出ていますので、そういったものを利用しながら、中長期的な視野をもってメタデータマネジメントに取組む企業が増えることを期待します。今後もこの話題は続けたいと考えています。
    　　　　（先頭に戻る）
  • その58：　もう一度、システム作りにおける「デザイン」の意義を考える
  • 既に何度かDMBOK(Data Management Body of Knowledge)　第2版の話題を紹介していますが、今回は5月29日に行った、Dama（米国Data Management Associatiton)日本支部#9分科会での活動について書いてみたいと思います。この分科会では、DMBOK　第2版を元にほぼ毎月１回程度の割合で勉強会を開催しており、筆者が第５章の「Data Modeling and Design」に関しての内容の説明を担当しました。そこでの説明の中で、あらためて感じたことを中心に触れてみます。
  • DMBOK　初版では、今回の第５章に当る部分は、「Data Development」という表題でした。そこで、今回「Data Modeling and Design」という名称に変わったことについての筆者の期待から説明を始めた訳です。この期待は、必ずしも原文の記述者の意図に合ったものかどうかは分かりませんが、敢えて期待として述べたのは次のようなことでした。データや情報の活用を目的に、「情報の可視化（いわゆる見える化）」という分野があるが、そこで対象となる「Information Design」は「コンテンツ技術であり伝える技術である。」という考え方があります（出典は、文末の【参考】を参照）。これは、情報を如何にして第３者に分かり易く伝えるかという視点からの言葉です。そこで筆者としては、今回の「Data Design」という呼び方に共通の考え方があって良いと感じたことを説明しました。
  • つまり「データに関するデザイン」は、設計・開発者のためだけのものではなく、利用者であるビジネスユーザや、後からメンテナンスを実施する担当者にも、その考え方がしっかりと伝わるものでなければならないだろうということです。設計者や開発者の満足で終わるのではなく、第３者にデザイン内容を継承できるようにしていなければ意味が半減してしまうという意味です。この考え方を設計や開発に携わる人々がしっかりと意識して、シッカリとした仕事として、作成物の仕様を伝えられるようにしていることにこそ「デザイン」の意味があるということ。そして、その生成物が時代と共に変更される際にも、その変更情報がキッチリと伝えられる（ようにする）必要があるということです。そのためにも、標準化活用やガバナンス維持の考え方が必要です。
  • この意識が、しっかりと経営者・マネージャー・設計・開発担当者の中で伝わっていてこそ、品質の高いシステムが構築・維持できるという点がポイントです。大きく言えば、組織というのはややもすると既存の習慣に慣れてしまい、なかなか改革を推進することに難しさを伴いますが、ビジネスとシステムの継続性と安全性の視点から、是非ともこの考え方が根付くようにしていきたいものです。勿論これが、開発コストやメンテナンスコストの大幅な改善に結びつくことは疑いがありません。是非とも経営視点からの達成すべきビジョンとして、システムを利用する人々が胆に命じて欲しいものです。その場しのぎの安易な設計や開発という考え方は、将来への禍根に結びつくと言って過言ではありません。
  • こういった考え方を、関係者に広めるためにも、このDMBOKの参照をお勧めしたいと思います。この資料は、現在Dama日本支部の有志の方々により、日本語化が進められています。近いうちに日本語版も発行されることが予定されています。是非ご期待の上、活用下さい。
  • 【参考】「Information Designはコンテンツ技術であり伝える技術である。情報が伝わるか伝わらないかは受信者側の解釈や理解度に大きく依存するとはいえ、情報を作り出す発信者側の工夫に余地がないわけではない。そうした余地を考えるのが、あるいは伝わる情報の形を考えるのがInformation Designである。・・・過不足なく、曖昧さなく、適切に、情報が伝わるよう情報の中身および情報の表現を設計することがInformation Designである。」（以上、「情報の可視化」放送大学2018年夏講義ノートp.7より（作成：松田裕幸講師）） 　　　　　（先頭に戻る）
    • その57：　「あらためて見直す『売り場作り』の基本発想とは？」ブログ記事
    • 今回も、(株)Flow Solutions（フローソリューションズ）様のWebページに掲載させて頂いたブログ記事（第3回）を再掲させて頂きます。（表題：「あらためて見直す「売り場作り」の基本発想とは？」）
    • この話題は、店舗運営に長く携わっている方たちには、イマサラ感の話題と受け取れるかもしれません。それでも日々頭をひねっている方たちには、大切な見方と思えるでしょう。 それでは、毎回のように質問から始めます。
    • 「私たちは、どうして売り場作りに知恵も時間もエネルギーも使うのでしょうか？」（先を読む前に、できればここで目を閉じ、１分間だけ考えてみましょう）
    • 答えの例：　売上を上げたいから。　来店者を増やしたいから。　店長（本部）の指示だから。　その他・・・
    • 目的としてみれば、多分どれも違ってはいないでしょう。でもどうして、売上が上がり、来店者が増え、上司（？）からの指示が生まれたのでしょうか？　大きな一要素として、お客さまが前提になる小売業にとって「場を作ること」で価値を生み出せるからだと、筆者は考えています。その結果として、先の色々な目的が満たされる関係にあるということです。それでは、ここで取上げる「場」はどのようなもので、一体それでどんなことが期待できるのでしょうか。
    • この「場」というのは、単に商品を揃えてある場所という意味ではなく、少し大きく捉えて「空間的な広がり」、「時間的タイミング」、「そこに集まるヒト」という多面的見方で捉えるものだということです。それらの総合的状況として、「ココニ・イマ」生まれているものが「場」であるという考え方です。こう考えると、単に商品を並べた売り場を眺めるだけでは物足りないと感じることができるでしょう。お店作りに愛着のある方なら、きっと何か工夫せずにはいられないことがあるハズです。
    • このような「場」として捉えると、どういった効果が期待できるのでしょう。ここでは少し専門的な言葉を使って、「場」においての「共鳴」・「共振」が生まれると指摘します（「共鳴」・「共振」の辞書的意味は最後に補足引用しています）。一言での要点としては「影響が伝わるトコロ」ということです。誰から誰に伝わるかというと、「お店から来店したお客さまへ」であり、「お客さま同士」であり、「その先のまだ見えない見込みのお客さまへ」という具合です。現在のネット社会からすると、伝わりの仕方や範囲は更に広がるといえるでしょう。お店や売り場として認識される「場」を通じて、どのような伝わり方をして欲しいのか、あるいはどこまで伝えたいのかを考えるのが店作りといえます。
    • 考えを更に進めて、敢えて「共鳴」と「共振」の使い分けをすると、共振の方がより（物理的）振動数が高いというイメ－ジを踏まえて、もっと能動的なイメージとして「共振」を捉えることができます。つまり、「共鳴」というのは、音叉（おんさ）のように、お店の雰囲気を元にその場において受動的な反応が起きる。これは短期的で、一旦お客さまが店舗を離れると、その共鳴状況は長続きしません。これに対して能動的な意味での「共振」が起きるレベルまで体験として響かせる。するとお店を離れた後でも、お客さまの（意識として）自発的発振が生まれるようになる。そして繰返し来店をする、或いはお気に入りの話題に取上げるといった継続的関係が期待できるという具合です。このように、影響の段階をイメージした上で、お客さま対応を想定して活動することが大切ということです。
    • こうした「共鳴」「共振」の場作りを意識することで、お客さまとの係わりをひと味違う見方で工夫することができるのではないでしょうか。そのために現状の把握や施策結果の確認手段として、どういったお客さまが（プロフィールや好みの傾向等）、お店のどのような場所／商品を目指して、いつ頃どの程度来店されているかを材料にする必要性が生まれ、そのための「データ利用への動機」が意識されることでしょう。この上で、昨今は様々なセンサの利用や道具立てを利用した具体的な対応手段が揃ってきています。
    • それぞれが目指す「場」作りの実現にどうすると良いかという個別の内容は、色々な考え方や方法が情報として溢れています。それぞれの立場から、それらをどう工夫して使ってゆくかは各お店の大きな宿題にしておきしょう。
    • 【以下ご参考】
      ［電子辞書　広辞苑（第六版）より引用］
      共鳴：　(1)〔理〕（resonance）物理系が外部からの刺激で固有振動を始めること。特に刺激が固有振動数に近い振動数を持つ場合を指す。共振。(3)転じて、他人の思想や意見に同感の念を起こすこと。（(2)省略）
      共振：　共鳴(1)に同じ。特に電気振動の共鳴をいうことが多い。
      （以上、2018年5月29日掲載ブログ記事より転載）　　　　　　　　　　　（先頭に戻る）
    • その56：　EA（エンタープライズ・アーキテクチャ）を素朴に考えると
    • 一頃のエンタープライズアーキテクチャ（EA）談義からみると、最近は余りその話題を聞かなくなったのではないかと思っています。それでEAという考え方が色々な企業に根付いているのかと考えると、それも疑問符が付く状況ではないかといえるでしょう。その必要性を感じて以前から取組みを行っているという企業でも、なかなか企業レベルでの実効性を上げて結果を出したかどうかと結論を出すのが難しそうです。寧ろ着実に継続したプロジェクトや人のレベルで止まっていて、企業レベルに至っていないと考えるのが大多数の実態といえるでしょうか。
    • 余り、EAという言葉を大上段に振りかざす方が難しいのかもしれません。基本は「企業活動としてのビジネスから技術基盤までの全般棚卸しを行い、関係者の間で業務やシステムの様子を見えるようにしましょう」という話で考えたいことなのですが、それが企業内で認知され、継続されたものとして実行してゆく事が、多くの企業で継続的な実践として、うまくいっているとまで胸を張ることができていないということ。これを続けるためには、人も時間も手間も掛ける必要があるため、やはり経営上の課題として扱う話題であると言わざるをえません。単に技術論議で動いていると、ツール導入の話して終わってしまい、そういったツールを入れたから後は何とかなるだろうという程度の話題で終わりかねません。ツールを提供するベンダーにとっては、ある意味思うツボという状況を生みます（失礼）。
    • 人の流動性や、高齢化を踏まえた人手不足、そして一見新しい技術であるAI領域の喧伝を元に世の中が浮き足立っている印象が強いというのが、筆者の正直なところです。おまけに五輪の話題もある。少し限定的で専門的な言葉を使うことにすると、「サヌキ」性がとても目立つ状況にあり、こういうトキにこそ「アワ」性の本来的な必要度が高まるということです。こういったことを理解し、実行する経営者と人が見えて来ないと、本格的で実効性の高い、EAの継続が難しいといえるでしょう。経営者は、それが可能なヒト探しを課題として急務なものとする必要性があるでしょう。それができなければ、イワユル３K的な業務としてシステム担当者を継続的に心理上で追い込む形になってしまう。この意味で、ITの話題を語るマスコミ業界は殆ど役に立ってはいないというのが、筆者の偽らざる見解です。どちらかというと海外情報やベンダーの立場から、単に自分のビジネスを短期的に生めば良いという立場での物言いが多いと感じさせられます。
    • 引続き専門用語を使うと「オサ」としての経営者と、「アワ」の意思を持った指導者、そして「サヌキ」性の高い実行者がうまく連携して企業を運営してゆくことが理想といえるでしょう。最近のXerox買収がうまくいかないのは、この反例であるかも知れません。今回は簡単でしたが、少しばかり筆者流の「ナゲキ」を言葉にしてみたというトコロです。悪しからず。 　　　（先頭に戻る）
    •  
    その55：「『鷹の目』と『蟻の目』の立体的視点で捉えるということ」ブログ記事
  • 前回に引続き、(株)Flow Solutions（フローソリューションズ）様のWebページに掲載させて頂いたブログ記事（第2回）を再掲させて頂きます。（表題：「「鷹の目」と「蟻の目」の立体的視点で捉えるということ」）
  • 今回は、業務効果向上を目指すのに大切な立体的視点と、それを目的とした情報やデータを共有する際の着目点を、業界にこだわらない形で考えてみましょう。
  • まず質問です。業務上の目標数値（つまり動機付け）が示されたとして、それで私たちは、速やかに動き出せるものでしょうか？
  • 初めに一言でいえることは、もしそれで動き出すとしたら、それは「暗闇で動き回る（闇雲）戦法」だということです。つまり、動く方向とその進度を決めてからでないと見境のないデタラメな動きになってしまう。時間枠と利用できる資源量に限りのあるビジネス世界では、このような無制限の活動は資源の大きな無駄使いに他なりません。
  • そこで、動き方を決めるのに大切な基本的考え方として、表題の立体的活動視点、つまり「鷹の目」と「蟻の目」の話が出てくるという訳です。
  • 「鷹の目」視点というのは、平面上ではなく数段高い視野で対象課題の全体像を捉え、イメージ（図式）的に整理する戦略的アプローチから始めることです。自分たちの立ち位置を上位目線で把握し、その上で目的に至る方向とタイミングを測るやり方です。実行に当たっては目にも止まらぬ速さで目的地に到達する方法が理想的といえるかもしれません。これは実際には置かれた状況次第です。
  • それに対して「蟻の目」視点は、具体的に目的を達成するために、行動への意思決定に柔軟性を持たせつつ、現場重視で必要資源を投入する協働の見方です。現場情報をフルに共有・利用し、細部にこだわりを持たせた目的指向の戦術的アプローチといえます。
  • この立体的考え方は単独活動でも有効ですが、特にグループや組織活動の上では、「鷹の目」と「蟻の目」の両視点が一体化され関連付けて用いられてこそ、相乗効果が期待できるというものです。但しこの関連付けは、単に工程の上流－下流（または原因－結果）という関係では必ずしもないことに注意しておきたいです。それらは、もっと同時並行的内容と考えるべきでしょう。
  • それでは、この協働を前提に、そのための情報共有やデータ利用に目を向けてみましょう。
  • 「鷹の目」では、対象領域の全体像を広く捉え、状況の背景を含めた脈絡作りを支援し、方向性と進度を見定めるための情報利用が主体です。具体的活動準備・見直しに向けての地図作りの作業と考えると分かり易いかもしれません。一方で「蟻の目」は示される方向性を参照して、個別状況への対応（アクション化）を目指す情報利用です。現場役立ち情報の把握・共有・フィードバック化と考えておくと良いでしょう。できるだけ最新のデータ利用が期待されます。また入手情報を元に、現場が判断して動けるだけの「活動の自由度」が与えられることも大切でしょう。
  • 「鷹の目」からの地図提供に当っては、時間軸を踏まえて脈絡を整理するという見方が有効です。このための情報表現は「論理的」な見方（「概念的」と表現する人もある）で行うのが分かりやすいです。その際には散らばった情報やデータを高い目線から見直し、単純化するために「抽象化」という考え方を取り入れます。少し言葉が難しいですが、似たもの同士をまとめてできるだけ簡潔に表現する考え方だと理解しましょう。具体的には、情報の出所や時間的な関係性、意味を踏まえた要約整理することです。この抽象化に当っては、技術的には「モデリング（モデル化）」手法を取るのが一般的です。また、必要なのは単なるデータ量の問題や細かさではない点に注意したいところです。
  • 心理学では「マジックナンバー7＋（または5＋）」といって、一度に提示される情報量の人間の短期的記憶度はそれ程多くはないことが話題にされています。同様にいきなり細かな地図だけを提供されても、人は通常理解に困ってしまいます。身近な例を上げると、ネット上での最近の東京メトロ構内地図があるでしょう。試しにどこかの駅の構内図を検索してみて下さい。とても正確で細かな構内図が表示されます（2018年3月現在）。しかし、まず目的地に向けて大体どちらの方向に進んだら良いかを知りたい検索者にとっては、余り細かすぎる地図を最初に与えられるのは困りものです。（これは筆者を初め何名かが最近感じた意見です。正確な構内地図も時と場合によっては必要なこともあるでしょうが、それを最初から必要とする人の方が少ないのではないでしょうか。要は目的と理解度に応じたレベルでの、段階的情報提供が必要という例です。関係者にはその点悪しからず。）
  • 次に「蟻の目」の情報・データ利用について簡単に考えましょう。そこでは個別の出来事や取引（トランザクション）に着目した現場データ主体の利用が期待されます。個別的で一貫性のある内容として、手軽に扱いたいという現場要望に応えることが求められます。直面する事柄を中心に、それに付随する属性的データを一緒に扱いたいという要望が出るでしょう。更に、ある出来事に関連して、その時間・空間的な状況も含めたい。対象の視野は限られるものの現場での具体的アクションに必要な程度での情報・データを得たいということです。
  • こういった立体的視点と要望に沿って、情報・データをグループとして提供し合える環境実現を前提方針に、具体的に導入構築するソリューションを選択することが大切です。この場合、たった一つの解決策では全ての要求に応えられない可能性があります。「One size does not fit all.（一事が万事とはいかない）」を忘れたくないところです。今回は経営的見知から期待される、基本の取組み方を考えてみました。
  • 最後に、「鷹の目」と「蟻の目」両視点からの立体的協働環境として、タイムリに両者の意識合わせやアイデア共有実施を目的とした双方向コミュニケーションの場を設けることも大切だと付け加えておきます。その一つの形態がビジネスチャットといった機能で実現できる可能性があるでしょう。
  • 【閑話休題】花や虫を独特の表現で描くことで知られる故熊谷守一画伯に、「よく見ていると『蟻は（６本ある）足の左側２番目から歩み出す』ことが分かった」との言葉があります。これも細かい現場観察の話題といえるでしょう。
  • （以上、2018年4月10日掲載ブログ記事より転載） 　　　（先頭に戻る）
  • その54：　「Retail Tech 2018」参加と「リテール・イズ・ディテール」ブログ記事
    • 今年のRetail Tech (2018)は、東京ビッグサイトで3月6日(火）～3月9日(金）で開催されました。筆者は仕事上でサポートさせて頂いている関係があり6日、8日の2日間(株)Flow Solutions（フローソリューションズ）様のブースで、ソリューション製品の説明デモンストレーションを多くのビジネスパーソンに行う機会があり色々お話をさせて頂きました。また(株)Flow Solutions様のWebページには、以下のような筆者のブログ記事を掲載させて頂きました。再掲させて頂きます。（表題：「リテール・イズ・ディテール」小売業は小さなことの積み重ね）
    • 今回は基本に戻って、この題目の意味を考えてみましょう。流通業に深く関わる読者にとっては当たり前のことですが、見直せる点もあるのではないでしょうか。
    • 顧客管理と商品の品揃え（マ－チャンダイジング）が小売業を支える両輪であると耳にする方は少なくないと思います。今回は主に店舗運営に携わるマネジャーの見方から、「小さなことの積み重ね」へのヒントとして、幾つかの要素を見てみましょう。
    • 元来、お店はそれぞれが異なっていて当たり前です。店前の通行者傾向は一様ではないし、そこからお店に訪れ商品購入をする顧客となるのはその一部です。少し以前からネット店舗を利用して買物をすることも当たり前になっており、何もせずに自分のお店に興味を抱いてもらえたら、逆に不思議な位です。来店した人には何か動機があったに違いありません。仮に時間の合間を使ったにしても、その店を選んだのは何か理由があるはず。そう思いませんか？
    • 何がその来店客の目を引いたのか、または引くのか？来店動機を問い、その誘因となる要素を軸にアクションをする、それが小売業の「顧客（来店客）を見る」出発点です。このツールとして、店構えを整え、アイキャッチ素材（Pop等）を用意し、顧客の目的を満たす流れを作ることは多くの店舗運営者の基本活動といえるでしょう。それはネット店舗、実店舗に係わらず共通ですが、ネットとの連携を図る実店舗では更に重要性を増しているといえます。
    • 来店客にしても、特定の商品を目的にした来店客と商品をぶらりと見回っているお客とでは、行動に違いが生まれます。しかし実際に全ての来店客に張り付いて見ていることはできないため、代わりの方法の例を考えてみましょう。身近な方法として、購入レシートを用いて傾向を類推する方法があります。前者は１点（商品種類）買いとして現れ、後者は何点かまとめ買いをする可能性が高まります。また店舗内行動として見ると、前者は短時間にお店を去る可能性が高いでしょうし、後者は比較的長い時間留まってお店の広い範囲を歩き回る可能性があるでしょう。セール商品中心の購入者と比較的単価の高い商品の購入者も行動パターンや来店サイクルが気になります。
    • こういったことを要素にして自店の来店客を想定しながら、「思っての『まとめ買い』」「思わずの『ついで買い』」という行動を引き出し、来店の頻度を高め、結果としてお店の売上げや利益向上につなげるという施策を実施することになるでしょう。
    • 来店体験がお客の満足度要素に結び付いて記憶に残れば、来店頻度の向上も期待できるというものです。心理学的には、その場限りの短期記憶的な瞬間体験と、長期記憶として残る店舗への満足体験とを分けて考えることが大切といえるでしょう。記憶に定着した満足体験は再度の来店を促すきっかけとなります。また来店への味付けとして例えば、カードポイント方式を取る店舗も少なくありませんが、この方式が単なる値引きアイテムに終わってしまうことは避けるべきです。更に個人情報というコトバに敏感な消費者傾向が生まれている昨今では注意点が多いといえます。
    • 商品（マーチャンダイジング）の視点からすると、企画商品や人気商品、季節性商品をどのようにタイミング良く取り揃えて、しかも可能な限り売り切ってしまうという点に目がゆきます。扱うモノによっては、サイズ・色・デザイン・賞味期限なども考慮する必要が出ます。これらの推測には、販売のピークやサイクルを知るために過去2から3年分の商品分類別売上げデータを利用するというのが良く用いられる方法です。また多くの店舗を抱えるチェーン店であれば、地域性を考慮しながら自店と似た店舗を知ってその傾向性を参考にできます。この類似性や違いを知るために、単なる感に頼るのではなく幾つかの属性や指標を用いて店舗の分類（クラスタリング）というデータに基づいた手法を利用することが考えられるでしょう。
    • このように様々な要素の細部に目を配りつつ、顧客と商品の両面から日々の活動を計画し（Plan）、実行し（Do）、結果を観察し（Check）、改善に結び付ける（Action）、そしてそれを怠りなく実行し続けることが表題の意味する大きな一面です。そしてそれを上手く行うために、日々のデータを活用するのが賢い流通業であるということができるでしょう。そこではデータの厳密性を問うというよりその中から傾向を見つけ出し利用するという立場を取るのがポイントです。
    • （以上、2018年3月6日掲載ブログ記事より転載）　　　（先頭に戻る）
    •  
    • その53：　JEMUGデータモデリング・コンテストに参加して考えたこと
    • ここで話題として取上げたいのは次のようなことです。(1)仕様文書を単に提示しただけの場合、データモデル作成者はそれぞれの理解の範囲で（概念）モデルを作成する。(2)その作成モデルの内容は、モデル作成者の持つ当該分野の知識量や興味の範囲に影響される。(3)結果として作成されるデータモデルは、似ているがかなり異なった様相を示すことになり得る。つまり、要求仕様文書を提示しただけでは、生まれてくる結果としてのデータモデルが大きく違った形式になり得るということを、改めて感じさせられた。そしてこれは開発の方法論に影響することで重要性を持つ話だと、筆者は認識したという訳です。
    • 一般にデータモデルというのは、対象とする分野を表現し、安定的なデータ構造を表現するために作成するものであるといわれます。そしてそれが開発の長期的な生産性や品質の向上に寄与するものだとされます。 しかしこれを達成するには、要求仕様提示者との間で、どのような背景や到達目標を元にしいるかの認識を共有する必要があります。基本となるリソースエンティティ群、振る舞いを記述するトランザクションエンティティ群、分類等を記述説明するリファレンス（コード）エンティティ群などを一つ一つ確認するということです。いきなり両者との間でヒアリングやインタビューを始めるという訳にはゆかないため、暫定的に共通の立場で議論可能な初期或いは中間的モデル（仮にこれを「プロトタイプモデル」と呼ぶことにします）が必要になるでしょう。このプロトタイプモデルを介して、双方の対象概念に関する認識のギャップを埋めてゆき、成果物としてのデータモデルをブラッシュアップします。これは一つのレビュープロセスです。
    • 最終的には、要求仕様提示者の承認手続きが必要です。これは成果物に対する責任の所在と、以下の開発工程で開発者が安心して参照できるものであることを保証するためです。これによって開発のスコープも明確にできるというものです。更に、開発プロセスに進んだ中で発生した疑問点や修正事項は、モデル設計プロセスに戻って反映する点を忘れてはならない注意が必要です。またこれらの一連の流れによって生まれた情報は、最終的にドキュメントや開発情報に取り込んで、後で経緯を参照できるようにしておくことが大切な習慣行動になるでしょう。これが行われていないと、後日の追加開発・修正開発は、現在の状況を調べ直すところから始まることになり、コスト的にも、時間的にも大変手間の掛かる作業を生む結果となります。
    • ここで書いたことは、「当たり前」と思われることと受け止められるかもしれませんが、その当たり前を着実に実行し、更にそれを継続することが中々実行するのが難しいというのが、多くのシステム開発実態といえるでしょう。余談ではありますが、AIを利用した開発作業であっても、これは単純に解決できる課題ではないように筆者には思えました。 　　　（先頭に戻る）
    • その52：　新年のご挨拶とデ ータモデル初め
    • いよいよ2018年という新年が始まりました。今年の皆様のご多幸をお祈り致します。社会的には様々な出来事の発生が予感されます。中でも取り分け着目しておきたいのが、米国トランプ大統領とその周辺の動向でしょうか。イスラエルの首都認定の話は、今年の大きな動きとして目を離すことができないでしょう。とはいえ、それに対して何か決定権を持つ訳ではない普通人としての筆者のできることは、目を注いでいるだけですが。表面に現れる状況やニュースだけでは、背面の動きを知ることができないのがやっかいな点です。特にこの問題には宗教的な信念が絡んでいるというのが一筋縄では進められない所です。いつどんな話として進むかが予測し難い。
    • 前回JEMUG（エンタープライズデータモデリング・ユーザーズグループ）のデータモデリングコンテストについて触れましたが、2018年のデータモデル初めとして、早速筆者もコンテスト課題のモデルを作成し元旦応募を行いました（皆様も是非参加下さい！）。この課題に取組みながら筆者が改めて感じたことについて、今回は少し書いてみたいと思います。読者の参考になる点がありましたら幸いです。
    • 気付きその1：　「データモデルというのは、モデル作成者の対象世界の捉え方を表している」これは、データモデルで表現しようとしている対象を、どのような方向から、どの程度の精度／粒度で見ようとしているかを示しているということです。データモデル図およびそれを支えるコード体系、付加的情報（メタデータとも呼ぶ）により、その内容がモデルを見る第三者にも分かるようになります。勿論少しばかりのモデル図を読む訓練が必要とされますが。逆に言うと、こういった図的表現がなければ、ただ言語だけで伝えようとするしかないことになります。モデル図を利用することで視覚的な方向からの対象理解の共有を可能にすることということができます。「理解の共有と伝承」このために役立てることができる。他者の理解を可能にすることで、その誤りや不足について第3者視点での気付きを与えることができるという点が重要です。この第3者には、時間的な隔てを経た「作成者自信」が含まれます。
    • 気付きその2：　「データモデルというのは、図式だけではない」データモデルは、通常エンティティ・リレーションシップ図（ER図）やUML図（Unified Modeling Language）で表されます。但し単なる図表示だけではないという点が大切です。その図を正しく読むためには、コード体系とその内容説明が必要とされます。コード体系というのは、具体的な見方と対象に関する視野を表現するツールです。コード体系が与えられることで、図表現の切り口や視点の範囲を知ることができます。この範囲というのは値という点では、しばしば「ドメイン」と表現されることもあります。コード体系の設計・運営・維持管理の分野は、「マスタデータ管理」と呼ばれることが多いです。
    • 気付きその3：　「データモデルというのは、意図が伝えられ再利用されることで価値が拡大する」先に書いたように、データモデルの利点は、（本人を含む）第3者に表現の意図を正しく伝えるのに威力を発揮するという点です。ただ書いて棚にしまっておくだけでは宝の持ち腐れと言われかねない。再利用を行うことで、いつもゼロベースから設計を始めるという非効率性をも防ぐことができます。それは過去の設計状態をそのまま踏襲するという意味で無しに、設計の良い点を踏まえつつ改良を加える（その発想を支える）という点で重要です。ゼロから考え直すよりも、発想の時間短縮に繋がるということです。この考え方は、いわゆる科学（サイエンス）が発達し、多くの人々に有用性が理解されたという原点でもあります。こういった意味からは、作成するデータモデル図（メタデータを含む）は、本人のためだけのものではなく、それを後から読む（参照する）人の視点で作成することが必要と言えます。単に義務や趣味で作るものではない。
    • 他にも細々とした点で、良い点を上げることができると思いますが、折角データモデル作成に時間を掛けるなら、上記の点を考慮しながら、是非うまく伝えることができるモデル作りを実践したいものです。これを今回の筆者からのささやかなメッセージとします。是非データモデルコンテストを一つの場として、挑戦してみて下さい。　　（先頭に戻る）