【登壇資料】「ツールを入れても解決しない？データ活用の現場に共通する課題とデータマネジメントの必要性と基本」というタイトルで登壇しました
はじめに
データ事業本部の渡部です。
ずいぶーん久しぶりのブログです。
先日クラスメソッドにて以下のウェビナーを開催し、登壇してきました。
この記事では、私の登壇資料についての簡単なまとめと振り返り、またウェビナー中にいただいたご質問について、私がお答えできる範囲で回答を書いていきます。
ウェビナー概要
クラスメソッドには日々、データ関連のさまざまなご相談が寄せられます。
- AI活用を進めたいが、根拠となるデータの信頼性に課題を感じている
- BIダッシュボードを整備したいが、そもそもデータの所在が整理しきれていない
- テキスト、音声、映像などの非構造データをAI活用につなげたいが、どこから整備すべきか分からない
これらの課題は、ツールやクラウドサービスを導入するだけでは解決しません。データそのものをどう定義し、どう管理し、どう運用に乗せるかというデータマネジメントの取り組みが必要になります。
本ウェビナーでは、クラスメソッドが実際の案件を通じて得た知見をもとに、構造化データ・非構造データの管理と活用について、考え方から具体的な進め方までご紹介しました。
後半では「データ品質とメタデータ管理で実現する構造化・非構造化データ活用のユースケース紹介」というタイトルで、同じくデータ事業本部の川中子さんの登壇がありました。
川中子さんのパートでは、データ品質やメタデータ管理をテーマに、より具体的な改善活動の進め方やデータ基盤への実装例について紹介しています。
私のブログは川中子さんの「フォーマットそのまま流用してもらっても」という愛のあるお言葉を受けて、同じ構成で作成させてもらっています！
私の登壇パート
私の登壇資料はこちらで公開しております。
私のパートでは、「ツールを入れても解決しない？データ活用の現場に共通する課題とデータマネジメントの必要性と基本」というタイトルで、データ活用のご相談でよく見える共通課題と、そこに対してデータマネジメントでどう向き合うかをお話ししました。
クラスメソッドでは、データ領域について次のようなご相談をよくいただきます。
- 社内外に散在するデータを整理・統合し、分析やAI活用に耐えられるデータ基盤を構築したい
- 散在するデータを可視化し、意思決定や改善施策に直結するダッシュボードを作成したい
- 構造化・非構造化データをつなぎ、AIを通じて業務効率化や知識活用を進めたい
相談内容はそれぞれ違いますが、深掘りしていくと、結局は土台となるデータの問題に行き着くことが多いです。
たとえば、データは存在しているものの、その品質や定義に責任を持つ担当者が明確ではない。データを統合して横断的に分析したいが、欠損や表記揺れがあり、そのままでは分析結果を信頼できない。分析に使えそうなデータはあるが、どこにあり、何を意味していて、正しいものなのか判断できない。
このような課題に対するアプローチとして、データマネジメントの必要性と基本を紹介しました。
データマネジメントとは
本資料では、データマネジメントを「目的に応じたデータをいつでも活用できる状態で継続的に維持・管理すること」として説明しました。
データマネジメントの教科書であるDMBOKでは、データマネジメントを11の領域で整理しています。
- データアーキテクチャ
- データストレージとオペレーション
- データ統合と相互運用性
- データモデリングとデザイン
- マスターデータ管理
- ドキュメントとコンテンツ管理
- データセキュリティ
- データ品質管理
- データウェアハウスとビジネスインテリジェンス
- メタデータ管理
- データガバナンス
こうして並べると非常に幅広く、最初に見ると「どこから手をつければいいのか分からない」と感じる方も多いと思います。
そこで登壇では、これらを「集める」「保管する」「整理する」「使う」「ルール」という大きな見方で整理しました。
たとえば、バラバラのシステムにあるデータを連携させるのは「集める」活動です。データを安全に保存し、必要なときに引き出せるようにするのは「保管する」活動です。データの形を設計したり、マスターのブレをなくしたり、非構造データを検索可能な状態にしたり、メタデータを管理したりするのは「整理する」活動です。そして、DWHやBIを通じて意思決定に使えるようにするのが「使う」活動です。
これら全体を、データガバナンス、データアーキテクチャ、データ品質管理、データセキュリティといった「ルール」の領域が支えます。
よくある課題と関係が深い領域
登壇では、よくある根本課題とデータマネジメント領域の関係も紹介しました。
「データの責任者が分からない」という課題は、データガバナンスと強く関係します。会社の中でデータを誰が、どう管理し、どう使うのかというルールと責任者を決める必要があります。
「データの信頼性に不安がある」という課題は、データ品質管理と強く関係します。分析結果やAIの出力をビジネスで使えるレベルにするためには、データの間違いや抜け漏れをチェックし、綺麗に保ち続ける必要があります。
「データの意味が分からない」という課題は、メタデータ管理と強く関係します。膨大なデータの中から欲しいものを見つけ、意味を誤解せずに使えるようにするためには、データそのものだけでなく、データについての説明を管理することが重要です。
課題ドリブンで進める
データマネジメントの領域は広いため、最初からすべてを網羅的に進めようとすると、活動自体が重くなりがちです。
そのため、登壇では「課題ドリブンで進めよう」という話をしました。
理由は大きく3つあります。
1つ目は、効果が大きいところから始めるためです。メタデータも品質ルールも、突き詰めればいくらでも凝ることができます。しかし、まずは事業や業務へのインパクトが大きい課題から取り組んだ方が、費用対効果が高く、次の投資にもつながりやすくなります。
2つ目は、データマネジメントそのものを目的にしないためです。課題がないまま始めると、「とりあえずデータカタログでメタデータを登録してみた」「とりあえず品質ルールを増やした」という活動になりがちです。
3つ目は、現場の協力を得やすいためです。「データを管理したい」よりも、「この業務課題を解決したい」の方が、関係者の納得を得やすいと考えています。
新しくデータ基盤を構築する場合の進め方
新しくデータ基盤を構築する場合も、まずは課題を整理し、あるべき姿を決め、マイルストーンを立てます。
そのうえで、最初から理想形をすべて作り込むのではなく、まずは動くものを作ります。もちろん、個人情報のセキュリティなど最初から外せないものはあります。一方で、モデリングなどは最初から完璧を目指すのではなく、まずはデータマートを作り、利用者からフィードバックをもらいながら整えていく進め方も現実的です。
その後、課題の優先度に沿って改善対応を行い、定期的に振り返って改善していきます。
ツールは導入ありきではなく、解決したい課題があり、その課題を解く手段として適していると分かったときに導入するのがよいと考えています。
Q＆A
以下は参加者の方からいただいた質問と、質問に対する私なりの回答です。
これまでのデータ基盤とAIが流行ってからのデータ基盤で違いはありますか。
これは、「データに対するAIによる分析活用ができるようになったデータ基盤」と、「AIを活用してデータマネジメントができるようになったデータ基盤」の2軸があるかなと思います。
まず前者については、大きくは異なりません。データの活用先がAIになっただけで、データを整えること自体は変わらないためです。強いて言うなら、AIに理解させるために、データ自体の意味や関係性を渡す必要があるため、そのレイヤーを整えることはあります。
後者については、触ったことがないサービスの調査や、ドキュメント作成などにAIを活用することで時間を削減できるようになりました。また、多くの案件から情報を吸い上げて、共通のプロジェクト進行や共通設計書などのテンプレートを作ることも、以前より迅速にできるようになったと感じています。
昨日kaimeiのセッションにも参加したのですが、kaimeiを活用することを前提にする場合、本日の内容では最低限どこまでを行えば活用が可能でしょうか？
こちらのウェビナーですね。
【6/10（水）】もうデータ待ちはいらない 民主化が拓くデータドリブン組織への道 | DevelopersIO
kaimeiは、日本語で質問するだけでSQLを自動生成・実行し、グラフやインサイトを返す弊社が開発したAIデータ分析ツールです。いわゆるText-to-SQLの領域に近く、DWHに蓄積されたデータをビジネスユーザーがより使いやすくするためのサービスと捉えると分かりやすいと思います。
kaimeiを活用する前提でも、基本的には通常のデータ基盤構築と大きく変わるわけではありません。まずは、分析対象となるデータがDWHなどに整理され、kaimeiから参照できる状態になっていることが前提になります。
そのうえで最低限必要になるのは、メタデータと社内文脈の整備です。
kaimeiでは、接続したDWHからメタデータを取得し、編集可能です。また、社内文脈についてはkaimei上にドキュメントをアップロードすると、AIがText-to-SQLで使えそうな情報を取捨選択してナレッジ登録が可能となっております。
本日の内容に当てはめると、最低限押さえたいのは次のあたりです。
- どのテーブルをkaimeiの分析対象にするか
- テーブルやカラムが何を意味するのか
- どのテーブルを正として扱うのか
- 業務上よく使う指標や集計条件は何か
- テーブル同士をどう結合するのか
- どの利用者に、どのデータを見せてよいのか
特にText-to-SQLでは、テーブル名やカラム名だけでは業務上の意味を判断しきれないことがあります。たとえば「売上」と言ったときに、受注ベースなのか、出荷ベースなのか、請求ベースなのか。キャンセルや返品を含むのか。どの部署の見方を正とするのか。こうした社内文脈が不足していると、SQLとしては正しく見えても、業務上期待した答えとずれる可能性があります。
そのため、最初から全社横断のデータカタログやガバナンス組織を作る必要はありませんが、対象ユースケースに関係するテーブル群については、メタデータ、業務用語、指標定義、結合条件、利用上の注意点を整えておくと、kaimeiの活用効果を出しやすくなると思います。
加えて、データ品質管理も重要です。kaimeiがSQLを生成できても、元データに欠損や表記揺れ、重複、更新遅延が多い場合、返ってくる結果を安心して業務判断に使うことは難しくなります。
まとめると、最低限のスタートラインは「DWH上に分析対象データがある」「対象テーブルのメタデータが分かる」「社内文脈や指標定義が説明できる」「主要な結合条件が整理されている」「利用権限とデータ品質に大きな問題がない」状態だと考えています。
ここまで整っていれば、まずは対象範囲を絞ってkaimeiを活用し始めることができます。その後、利用が広がってきた段階で、データオーナーの明確化、品質ルール、メタデータ管理、社内ナレッジ整備を段階的に広げていくのが現実的です。
ファイルサーバーに保存する非構造データをAIで利用したい場合、ファイルサーバー側で行うべき・行うことが推奨されることはありますでしょうか。データの整理やフォルダー構造の見直しなど。
ファイルサーバー上の非構造データをAIで利用する場合、まず重要なのは、AIに読ませる対象を整理することです。
ファイルサーバーには、最新版の資料だけでなく、作業途中のファイル、古い版、重複ファイル、個人用のメモ、権限上扱いに注意が必要なファイルなどが混在していることがよくあります。この状態のままAIに読み込ませると、古い情報を根拠に回答したり、不要なファイルまで検索対象になったりする可能性があります。
そのため、まずは次のような観点で整理することをおすすめします。
- AIに利用させたい業務領域やユースケースを決める
- 正として扱うファイルと、過去版・作業中ファイルを分ける
- ファイル名やフォルダー名の命名ルールを可能な範囲でそろえる
- 文書の種類、作成部門、対象業務、更新日などが分かるようにする
- アクセス権限を見直し、AI経由でも権限を超えた参照が起きないようにする
- 個人情報、機密情報、契約情報などの取り扱いルールを確認する
フォルダー構造については、完璧に作り直す必要はありません。ただし、少なくとも「最新版として使う場所」と「アーカイブ・過去版・作業中の場所」は分けた方がよいです。
AIの検索対象にする領域を明確に分けておくことで、読み込み対象を制御しやすくなります。また、不要なファイルを対象外にできるため、検索精度や回答精度の面でも効果があります。
加えて、ファイルそのものに含まれる情報だけでは判断しづらい内容については、メタデータを付与することも有効です。たとえば、文書種別、対象業務、顧客名、公開範囲、改訂日、文書オーナーなどです。
これはDMBOKの領域でいうと、ドキュメントとコンテンツ管理、メタデータ管理、データセキュリティ、データガバナンスに関係する取り組みです。
既存ファイルが大量にある場合は、すべてを一度に整理しようとせず、AIで使いたい領域から優先して進めるのが現実的です。まずは重要なフォルダーを1つ選び、重複や古いファイルを除外し、最新版と責任者が分かる状態にする。そこから小さく始めるのがよいと考えています。
さいごに
今回のウェビナーを通して、AI活用やBI活用を進めるうえで、データマネジメントの重要性がますます高まっていることを改めて感じました。
AIは非常に便利な技術ですが、AIが利用するデータの意味、品質、権限、鮮度が整理されていなければ、業務で安心して使うことは難しくなります。
一方で、データマネジメントは最初から大きく始める必要はありません。重要なのは、課題を整理し、何をやるのかを決め、そこに集中して取り組むことです。
生成AIもあり、「何をやれるのか」の情報収集は以前より容易になりました。技術やサービスのアップデートも目覚ましいです。その分、膨大な選択肢や変わる状況を前に、「何をやるのか」を決めること、そしてやり続けることがこれまでより難しくなったとも感じます。
だからこそ、「決める」「集中する」ことを大切に、データ基盤の構築・磨きあげに取り組んでいくとよいと考えています。
今回のウェビナーにご参加いただいた皆さま、ご参加いただきありがとうございました。登壇の発表内容、また本記事が少しでも参考になれば幸いです。
