We’ve joined forces with Smartlogic to reveal smarter decisions—together.

ファクトとその意味

重要な状況に関連するファクトを特定するのは、決して簡単ではありません。ましてやその解釈の合意に至るのはもっと大変です。その一連の流れを記録し、他の人にも活用してもらうようにできる余力のある人はあまりいないでしょう。

しかしながら、ファクトおよびその意味の特定は、現代のデジタルライフにおけるさまざまな重要局面の基礎なのです。「データはあったのに、なぜ何もしなかったのか」と問われることもありえます。

これは経済学的に簡単に説明できます。データは比較的安価です。しかし成熟した解釈の方はそうでもありません。

ちょっと前まで想像もできなかったリッチなデータの入手は、今ではそんなに難しくありません。しかしその意味をきちんと理解できる賢い人を確保するのは、だんだん難しくなっています。そもそも「賢い人をもっと雇う」というアプローチは、効率的に共同作業ができるツールがないかぎり、あまり拡張性がありません。

ここで求められているのは「データから知識(ナレッジ)を得ること」また「インサイトをアクションに移せること」です。それではこれをもっとうまくやるには、どうしたら良いのでしょうか。

今日主流的な手法(賢い人々を使う)は、大変な問題に直面しています。というのも複雑なデータソースが倍々で増えていき、必要とされるスキルも拡大しているからです。とても賢くて知識豊富な人々が、自分たちの知識を容易に形式化して共有できる方法がないのです。

あらゆる大規模な組織には重要な業務部門が複数ありますが、それぞれ独自の方法で複雑なデータ内のファクトを把握し、その意味を理解する必要があります。

また、この知識(=ファクトおよび解釈)は他部門と共有したくなるでしょう。研究部門は製品紹介チームと、また情報機関は内部の複数の部署間で、またリスクに注意している組織ではコンプライアンスを順守し続けるためのナレッジに関して、情報を共有したいと考えます。

それでは極めて賢い人々のチームが、ファクトおよびその意味に関する共有データベースを使って共同作業するには、何が必要なのでしょうか。

この課題を簡単な例で説明します。

John Is the Parent of Sue(ジョンはスーの親である)

このようなステートメントは「ファクト」と呼ばれます。これはデータとして、アプリケーションやデータベースに容易に入力できます。それではこれは何を意味しているのでしょうか。

まず「ジョン」について、私たちは何を知っているのでしょうか。性別や年齢などについてどう把握しているのでしょうか。それでは「スー」というエンティティについては、私たちは何を知っているのでしょうか。

さらにここで「is parent of」に注目すると、話は面白くなってきます。この関係性は何を意味しているのでしょうか。生みの親なのか、財政的な関係なのか、法的なものか、宗教上のものか、それとも保護者/被保護者なのでしょうか。あるいはそれ以外の関係なのでしょうか。またそれは、誰によって正式に認定されているのでしょうか。

そしてこれらの用語や定義は、実際のコンテキストにおいてどのような意味を持つのでしょうか。例えば、このコンテキストは、銀行、学校、福祉関係、病院、航空会社、情報機関のどれなのでしょうか。

「John is the parent of Sue」がデータベース内のファクトであるとしたなら、「それが何を意味するのか」は、このエンティティおよび関係性に関する共通理解だということになります。つまり「これはこのコンテキストにおいてどんな意味なのか」また「またこれらの用語が何を意味するのか」に関する共通理解なのです。

このようなステートメント(あるいはどんなステートメントでも)を適切に理解するには、ちゃんとした「組み込まれた/導入されたナレッジ」が必要だということがわかるでしょう。

簡単に言うと、ここには「ファクト」と「ファクトについて知っていること」の両方があります。これをエンコードし共有できれば、他の人たちも「X is parent of Y(XはYの親である)」という共通解釈を活用できます。

これは必要不可欠な「組織知」となりえます(特に社会福祉においてしばしば問題となる「親」についての細かくかつ厳密な定義を決めることができた場合)。

こうすることで、数多くの組織が時間をかけて極めて専門的なナレッジを作り上げていくというのが、基本的な考え方です。エンティティや関係性をさらに正確に定義するため、仰々しい専門用語が新しく使われることもあります。

たくさんのファクトとたくさんの意味

今日の組織には、たくさんの「デジタルなファクト」とたくさんの「デジタルな意味」があります。このような「デジタルなファクト」は、通常データベースを使って読み込み/格納/管理/保護されますが、一方「ファクトの意味」はその対象とされません。というのも複雑な組織では、部署ごとにファクトの意味が大きく異なることが多いからです。

例えば、誰かが新しい電話機をオンラインで購入しているとします。これだけ聞くと単純に思えるかもしれませんが、これにはかなり大量の重要な業務処理が関わっていることにすぐに気づくでしょう。それぞれの処理において、ファクトは以下のようにかなり違った意味で解釈されます。

  • フルフィルメント部門は、お客さんにちゃんと電話が届くのか、ちゃんと問題なく電話を使ってもらえているのかに関心があります。
  • プロダクトマネジメント部門は、この電話を購入した人の人口統計量、新しい電話の機能セット、この顧客カテゴリの使用パターンに関するデータに興味があるでしょう。
  • サプライチェーン部門は、このタイプの電話の発注を増やさなければいけないかもしれません。もし十分な納品がない場合には類似した代替品を準備する必要があります。
  • ネットワークプランニング部門では、デバイスの5G需要総量をモニタリングしています。
  • クレジット部門は、使用量と支払いの関係に注目しています。
  • カスタマーサービス部門は、特定顧客とのすべてのやり取りの履歴を求めています。
  • これらのトランザクションは監査可能で、コンプライアンスを順守し、裁判所からの記録提出要請に対応できなければなりません。

こういった1つのデジタルイベント(単純な電話の購入)でさえ、時間の経過とともにさまざまな解釈がありえます。また今日、こういった各部門の作業は業務委託先によって行われている可能性もあります。

こういったファクトは関係付けられるかもしれませんが、通常、解釈は関係付けられません。例えば、ネットワークプランニング担当者は、「製品企画部門は、顧客があまり5Gデータを使わないと考えている」ことを知っておく必要があります。

共有された解釈が、共有された知識となります。現在、知識共有には一般的なコミュニケーション手段(会話、文書、ビジュアル)が使われています。しかしこれには拡張性がありません。

ファクトの共有は比較的優しいです。

一方、これまでの様子を見ると解釈や意味の共有は難しいようです。

ファクトとその意味を1つのエンティティとして一緒に共有できるとしたら、それによって世の中が変わる可能性もあります。

ファクトは共有しているが意味は共有していない

データ共有は、コンピュータの黎明期より存在しています。これはプライマリシステムに対するクエリ、レポートの出力、データマートの検索などさまざまな形を取っていますが、さらに進化を続ける多種多様なアプローチによって、デジタルファクト自体が生成され共有されています。

しかし意味および解釈のデジタル共有(セマンティック)が出てきたのは、比較的最近です。例えば、Siriは極めて制約が強く、かつ一般的な用途向けに物事を解釈します。具体的に言えば、私たちはSiriが「ゼロクーポン債」や「プロテアーゼ阻害剤」について教えてくれるとは考えないでしょう。

しかしセマンティックAI技術を使うと、こういった複雑な概念の実用的な意味を素早く学習させることができます。セマンティックAI技術は人間の発言を解釈し、人間と同様にメタデータを生成するためです。

新入社員に重要な用語や概念(およびその意味)を教えるように、その分野の専門家が指導すれば、セマンティックAIソフトウェアも同じようなことができるようになります。

このようにエンコードされた知識は、メタデータ(=情報についての情報)、つまりこの場合は「データについて知っていること」「その概念的定義」「データの解釈に使用される他のデータ概念との関係」として格納されます。

ここでは、データの意味(メタデータとしてエンコードされているもの)をデータ自体と一緒に格納することが理想です。こうすることで、データにアクセスしたい人は誰でも完全なコンテキスト(「そのデータについて知られているすべてのこと」「どうやって知られるようになったか」「いつから知られているのか」など)を得ることができます。

これは簡単に聞こえるかもしれませんが、実際に実現されることはほとんどありません。

身近な例としては、ほとんどの大組織に存在するデータマートがあります。そこに存在するレポートやデータディクショナリーを読んでみても、何百、何千もの用語の本当の意味を理解することは困難です。どの用語、概念、定義が自分の状況に合っているかどうかわからないからです。

ファクトと意味の一体化

データのライフサイクルは、外部ソースからの取り込み、あるいは何らかのアプリケーションによる作成から始まります。デジタルイベントが発生すると、私たちは「誰が」「何を」「いつ」などに関する記録を作りたくなります。

多くの場合、ソースドキュメント(契約書、研究報告書、公報、メッセージなど)の複雑なデータは、手作業でエンコードする必要があります。

多くの人にとって、最初の評価は重要です。そこでは「このデータには何か重要なものが含まれている可能性があるのか」「この新しい情報は無視しても問題ないのか/後回しにしても良いのか」などを確認します。

例えば、健康診断の記録、重要な顧客からのメール、新しい研究報告、あるいは金融市場からの報告などを受け取った場合などです。

ここで何らかの判断をするために、新しいファクトを既存のファクトやその解釈と「関連付ける」必要があります。これは誰もが自然に行っていることでしょう。

こういった既知の「ファクト」および「解釈」の重要な基礎を構築し、維持し、改善する必要があります。既存のファクトに対する新しい解釈が「生み出される」と、これが新しい知識となります。「ノウハウ」は、作成された共有解釈の豊かさによって数値化可能になります。知的資本は、改善可能かつ投資可能な資産となります。

これにより、データを何らかの目的で「消費する」ことは、そのデータについて知られているすべてのことに基づいたコンテキストにおいて可能になるのです。これにより検索は、イライラするものから、情報に基づいたものへと変わります。アプリケーションは、つまらないものからリッチなコンテキストへと変わります。アナリティクスは、抽象的な数値から、根拠のあるファクトをより深く理解したものへと変わります。

賢い人々が協力する

非常に賢い人たちのチームが、手近にある何らかのツールを使ってファクトとその意味を解釈するというケースはどこにでも見られます。このやり方は、部門内(研究チームなど)だけでなく、部門横断的(他の人の知識に基づいて行動する)にも行う必要があります。

しかし、デジタル時代になってしばらく経った今日において、このやり方に拡張性がないのは明らかです。デジタルファクトは大量にある一方、有用な解釈はほとんどないからです。

ここでは、多くの状況において比較的短期間で進化してきたものを考えてみます。何か重要なことに取り組んでいる、賢い人たちの典型的なチームを想像してみてください。

5年前、そのチームが解釈し、それに基づいて行動する必要があったデータの量はどのくらいだったでしょうか。

今ではどのくらいでしょうか。

また5年後にはどのくらいになるでしょうか。

10倍でしょうか。100倍でしょうか。あるいはそれよりも多いでしょうか。

デジタルファクトの供給が実質的に無制限の今、私たちは膨大なデジタルファクトを解釈することを求められています。重要なものもあれば、そうでないものもあるので、質の判断が重要です。表計算ソフトや分析ソフトでは限界があるため、新しいツールが必要になるでしょう。

こういった小規模で動きが早いチームが社内で成功しても、それだけでは十分ではありません。ここでは、人々がそれぞれ自分のインサイトに基づいて行動し、独自の知識と視点を加えることが求められています(特に意思決定がなされる、まさにその瞬間において)。

もし「再利用可能な知識を人々が創造できるようにするための取り組みは、うまくいっているのか」と自問した場合、おそらくその答えはあまり芳しいものではないでしょう。

これは人材が優秀でないからではなく、慣れ親しんだ「データのみ」のモデルがうまく拡張しないためです。実際のところ、ほとんどのナレッジマネジメントの取り組みはナレッジを生み出したファクトと切り離されているため、限定的にしか利用されません。

デジタル時代において、データは安く、解釈は高価なのです。

ある状況まで到達すると、単に賢い人をたくさん雇うだけでは解決にならなくなります。実際のところ、それがしばしば正反対の効果をもたらすことが過去の事例から明かになっています。「データおよびそれについて私たちが知っていること」に関するアジャイルなプラットフォームがなければ、意味の断片化が進み、新たな問題を引き起こすことになってしまうからです。

これはあちこちにある

重要な意思決定が行われる場所では、この問題が簡単に見つかるでしょう。新しい複雑なデータを取り込み、理解しなければならないのです(「これは重要なのか、そうでないのか」)。

例えばライフサイエンス研究に携わっている場合、毎日発表される1000件以上の関連論文から最新の知見を得つづけるにはどうしたらよいでしょうか。

不正行為やセキュリティ、諜報活動に携わる人は、さまざまなノイズの中のシグナルを見逃すことを恐れていますが、逆に過敏になり過ぎると疲労困憊になってしまいます。

こうしてみると、金融サービスや物流などさまざまな組織が、ミッションは全く異なりこそすれ同じような問題を抱えていることがわかります。

重要な可能性がある情報をきちんと解釈し、それ以外の情報を安心して無視できることは、「ファクトとその意味」を共有する優れたアプローチによってもたらさせる効用の一つであることは明らかです。

しかし、「ファクトとその意味」が大きな影響を与えるもう一つの非常に重要な領域として「組織を越えた重要な知識の共有」があります。大規模で複雑な組織で働いたことがある人なら、これが非常に難しいことをご存じでしょう。

例えば、非常に重要で複雑なもの(旅客機や新しい治療薬など)を作っている場合、その航空機や治療薬の作り方に関する知識の共有は、それ自体が非常に重要です。

そういった知識は、研究、設計・試験、製造、顧客業務、ライフサイクル、コンプライアンスなど、組織のあらゆる部分に影響するのですから。

ナレッジセントリックなビジネスや組織では、ファクトとそれについて知られていることを共有するための共有プラットフォームが、いずれ必要となります。金融サービス、専門コンサルティング、リサーチなど、深い専門知識が製品やサービスを実現する分野でも、同じことが言えるかもしれません。

ファクトとその意味

デジタル時代には、「ファクトとその意味」が非常に重要なことが明らかになりました。

今後の投稿では、セマンティックデータベース(複雑なデータと、そのデータの意味をセマンティックに解釈したものを一緒に格納する)の概念について解説していきます。

セマンティックデータベースが、アクティブなデータ、アクティブなメタデータ、アクティブな意味を結びつけることで、データアジリティがどのように生み出されるかを紹介します。

「データアジリティ」とは、情報の解釈方法およびそれに基づくアクションを、シンプルでパワフルに、かつ強力に変えられる能力のことです。さまざまな障害をなくすことで、実現可能なことが変わってきます。

またおそらくはそれ以上に興味を持っていただけることとして、実際の企業がセマンティックデータベースの概念とデータアジリティを利用して、複雑な情報の扱い方を変え、その過程で変革的な成果を上げている事例を紹介します。

Chuck joined the MarkLogic team in 2021, coming from Oracle as SVP Portfolio Management. Prior to Oracle, he was at VMware working on virtual storage. Chuck came to VMware after almost 20 years at EMC, working in a variety of field, product, and alliance leadership roles.

Chuck lives in Vero Beach, Florida with his wife and three dogs. He enjoys discussing the big ideas that are shaping the IT industry.

Start a discussion

Connect with the community

STACK OVERFLOW

EVENTS

GITHUB COMMUNITY

Most Recent

View All

Unifying Data, Metadata, and Meaning

We're all drowning in data. Keeping up with our data - and our understanding of it - requires using tools in new ways to unify data, metadata, and meaning.
Read Article

How to Achieve Data Agility

Successfully responding to changes in the business landscape requires data agility. Learn what visionary organizations have done, and how you can start your journey.
Read Article

Scaling Memory in MarkLogic Server

This not-too-technical article covers a number of questions about MarkLogic Server and its use of memory. Learn more about how MarkLogic uses memory, why you might need more memory, when you need more memory, and how you can add more memory.
Read Article
This website uses cookies.

By continuing to use this website you are giving consent to cookies being used in accordance with the MarkLogic Privacy Statement.