DXの脇役になりがちな「非構造化データ」の重要性 データレイクとコンテンツレイクの棲み分けを考える

 多くの日本企業でハイブリッド/マルチクラウド化が進展している中、ファイルサーバーなどの置き換え需要もあり「Box」の利用率が高まっています。連載「DX時代の『コンテンツ管理』とは?──Box活用術を交えてエバンジェリストが解説」では、声高に叫ばれるDXにおけるコンテンツ管理にフォーカスし、なぜクラウドネイティブな管理手法が必要なのかを紹介。実例として「Box」の活用術を交えながら、第一線で活躍するBoxエバンジェリスト 浅見顕祐氏がわかりやすく解説します。

「コンテンツも“重要な情報リソース”である」という考え方

「DX(デジタルトランスフォーメーション)を実現するためには、何から取り組めば良いのか」。こうした質問を聞いたとき、皆さんは何を思い浮かべるでしょうか。

これまで物理的に行っていた様々な「企業や組織の営み」をデジタル化し、データによる再現が可能な世界「デジタルツイン」を構築する。「データレイク」を構築し、アナリティクスを日常化することで「データドリブン経営」を実現する。蓄積したデータ自体が「価値ある情報」になることで、新たなビジネスを生み出していく。企業や組織が持つ価値あるデータをAPIでつなぎ合わせることで、これまで考えられなかったような革新的なビジネスプロセスを描き、新たなビジネス機会とする……このような回答を想像された方が、多いのではないでしょうか。

言うなれば、“DXの主役はデータである”ということであり、もう少し解像度を上げるならば、それはコンピューターが処理できる形の「構造化データ」を指しています。このとき「非構造化データ」であるコンテンツは、“DXにおいては主役ではなく脇役”と捉えられがちです。

図1:コンテンツも重要な情報リソース

[画像クリックで拡大]

しかし、図1にあるような観点を考慮すれば、コンテンツも主役級に据えるべき重要な情報リソースと言えるのではないでしょうか。

データドリブン経営と言っても、経営者が生データを見て物事を判断し、意思決定するわけではありません。あくまでも構造化データをBIツールなどで可視化し、「レポート」という“コンテンツにまとめられた情報”を見て、経営判断を下すわけです。アナリティクスにおいても同様です。もちろん、売上データの分析から客観的な気づきを得ることは重要ですが、「その商品が売れたとき、または売れなかったときの店内の様子を確認したい」「店舗を管轄するスーパーバイザーと店長との間でどのような会話がなされていたのか知りたい」といったときに頼りたい情報源は、店内映像や店舗巡回報告書といったコンテンツです。

データ分析による予測は、過去の延長線上にある未来でしかないのですが、自身の目で確かめて得られる主観的なインサイトやワイルド・アイデアは、ときに過去に囚われない非連続のイノベーションを起こす可能性を持ちます。「ビジネスプロセス革新(Business Process Innovation)」の分野でも同様に、APIによるデータ連携は欠かせない一方、プロセス上に必ず人間も登場します。そして、人間同士で交わされる情報はやはり、構造化データではなく資料や文書といったコンテンツなのです。

連載Vol.1『コンテンツ管理とは?』で紹介したように、企業や組織が持つ情報の大半[1]は「非構造化データ(コンテンツ)」であり、これらのすべてを構造化データに変換することは現実的ではありません。そうした観点からも、DXを進めるにあたってはデータ基盤やデータレイクを整備するだけでは不十分であり、コンテンツ基盤やコンテンツレイクの構築も同時に検討する必要があると言えるでしょう。

[1] Vol.1執筆の時点では、「企業が持つ情報の80%が非構造化データ(コンテンツ)と言われている」という説明をしましたが、その後、IDCの最新調査で、その数値は80%ではなく、90%であることが判明しました。詳細はこちらのブログを参照してください。

データレイクとコンテンツレイクの棲み分け

データウェアハウスやデータマートといった、従来の「構造化データ」を対象としたデータ分析・活用基盤に対して、「非構造化データ」の状態のままデータを扱うという考え方がデータレイクなのでは?と思われた読者の方もいらっしゃるかもしれません。そこで、コンテンツレイクとデータレイクの違いについて、少し補足したいと思います。

図2:データレイクとコンテンツレイクの棲み分け
[画像クリックで拡大]

シンプルに考えるならば、IoTや位置情報、ログなどの「半構造化データ」はデータレイクのストレージで管理する。一方で、文書や資料、図面、写真、動画などの「非構造化データ(コンテンツ)」はコンテンツレイクで管理するという棲み分けが一般的と言えます。なお、ここで言う「半構造化データ」とは、たとえば、1億行あるJSON形式のファイルなどです。完全な行列形式に構造化されていないこと、データ量が巨大であることなどの理由から従来型のデータベースに格納しきれないため、ストレージで管理する。これが、データレイクの基本的な考え方と言えるでしょう。

そして、このようなデータは人間が作成するものではなく、発生源はセンサーなどのコンピューター(前述したケースではIoT機器)です。また、JSON形式のようなファイルは人間が目視して理解するための情報ではないため、必然的に使用者もコンピューターとなります。典型的な例を挙げるとすれば、クエリによってデータを抽出する方法です。たとえば、1億行あるJSONファイルから、条件に合致した行と列だけを抽出してテーブルを作成するような処理を行うとします。このとき発生源と使用者がともにコンピューターであれば、“単なる入れ物”であるストレージでもデータレイクの要件を満たせるでしょう。

ところが、文書や資料、動画などのコンテンツは一部を除き、発生源(作成者)も使用者も人間です。故に人間が使いやすい仕組み、人間がそれを使えば自然とコンテンツが集まってくる仕組みでなければならず、単なる入れ物(単純なストレージ)ではない別のソリューションが必要となり、その役目を果たすものこそが「コンテンツレイク」なのです。

「アプリケーション内製化」を実現へ

DXにおけるテーマの1つとして、よく挙げられるものに「アプリケーション内製化」がありますが、ここにおいてもコンテンツレイクは重要な役割を果たします。

ある企業のCIOは、“顧客接点のデジタル化”や“データドリブン文化の現場浸透”に貢献するためには、変化するビジネスニーズにタイムリーに対応できるアプリケーション開発体制が必要という発想から、内製に適したIT基盤の再構築を検討していました。しかしながら、これまでシステムの開発と運用をベンダーに任せきりにしていたため、新たなアプリを1つ作るにも都度ベンダーに発注しなければならず、億単位の費用、年単位の期間が必要になることも珍しくありませんでした。まさに、DXにおけるボトルネックの1つと言っても過言ではない状況に頭を抱えていたのです。

図3:Boxを「コンテンツレイク」と位置づけてIT基盤の主要コンポーネントとして利用している例
[画像クリックで拡大]

この難題を解決するためにCIOが導入したのは「API基盤」。アプリケーションを開発する際に、最も工数がかかる部分は“データへのアクセス”だと考えたからです。「どのデータベースのテーブルを使うのか」「データへのアクセス権限をどう定義するのか」などを都度議論しなくても済むように、“必要なデータはすべて集約されている”状態を実現するためのデータレイクを整備。主要データへのアクセス手段をAPIで統一したのです。

このときCIOは、データだけでなくコンテンツも重要な情報リソースであり、データにアクセスするAPIを用意しただけでは不十分だとして、コンテンツへのアクセス手段も提供しなければならないと考えていました。そこで導入したのがコンテンツレイクとしてのBoxです。Boxには「Box Platform」という仕組みがあり、APIやUI部品(Box UI Elements)を用いることで、個社固有のカスタムアプリケーションにBoxの機能やUIを組み込むことができるのです(詳細は、後述の「Box 活用術」で解説)。こうした一連の施策によりCIOは、アプリケーションの内製化を加速させることに成功しました。

図4:データだけでなくコンテンツもAPI経由で取得しアプリ上で活用している例
[画像クリックで拡大]

Box活用術:カスタムアプリにBoxを組み込む「Box Platform」を使おう

前述したようにBox Platformとは、API経由でBoxを利用する際の総称であり、APIやUI部品などの技術的な仕組み、課金体系などを指しています。先ほどの事例のように、この仕組みを用いることで固有のカスタムアプリケーションにBoxを統合することが可能です。たとえば、

  • 金融サービス企業の担当者が顧客(個人投資家)の投資ポートフォリオを設計するために必要な書類を提出してもらう
  • 住宅メーカー企業の担当者が顧客(住宅オーナー)に住宅契約に関連する書類一式を渡す
  • 損害保険企業の担当者が自動車保険請求の審査に必要なドライビングレコーダー映像を顧客(保険加入者)から受け取る

など、顧客とセキュアな環境下でコンテンツ・コラボレーションを行いたいというニーズは高く、BtoC企業では頻繁に見受けられます。BtoB企業においても同様に、製造メーカーがサプライヤーなどの協力会社と受発注関連の書類や仕様変更に関する文書をタイムリーに連携したいといったニーズがあるでしょう。

こうしたときこそBoxの出番なのですが、ここで留意しなければならないのは、顧客や協力会社がBoxのアカウントを持っているかどうかです。もちろん、相手にBoxアカウントを作ってもらうという手段もありますが、もしWebサイト上に会員制の「マイページ」や情報連携用の「ポータルサイト」などのシステムが既にあるならば、そこで顧客や協業先とコラボレーションできた方がスマートではないでしょうか

これを可能にするものこそ、Box Platformなのです。利用者は、自身のマイページ用(またはポータルサイト用)のアカウントで一度ログインしてしまえば、Box用のIDとパスワードでログインせずにBoxに格納しているファイルやフォルダにアクセスできます。これは、「JWT(JSON Web Token)認証」という仕組みが使えるためです。Boxのアカウントを顧客に保持してもらう必要はなく、アプリの利用者ごとに「App User」という仮想的なアカウントを割り当てることができるため、Box内での権限定義や操作ログなども個人単位で設定・実行することができます。これにより、セキュアなアプリケーションを構築することができます。

また、Box UI Elementsを使うことで、ちょっとしたJavaScriptのコードをカスタムアプリのHTMLコード内に記述するだけで、Boxのプレビュー画面やファイル一覧画面などを“部品として”カスタムアプリのWeb画面に組み込むことができます。なお、Box Platformを使った開発についての詳細は、Box DEVサイトをご参照ください。

図5:Box Platform
[画像クリックで拡大]

本稿Vol.5の内容は、以上となります。最終回Vol.6では、「生成AIがコンテンツ活用をどう変えていくのか」というテーマを解説。また、Box活用術では、ベータ版の提供が開始された「Box AI」の活用法も紹介します。

Original Post>