■ 1. 研修の構成と方針
- 三部構成の研修:
- 第一部はデータマネジメントの全体感を伝える話で45〜60分
- 第二部は12領域の紹介で50〜60分
- 第三部はExcelでのデータ整備実習で45〜60分
- 第一部の狙い:
- 分野の全体感、重要な概念、推進時の期待値、直面する課題を扱う
- 知識を身につけるというより、データマネジメントの面倒くささに共感して覚悟を決める時間とする
- 各部署が抱えるデータ課題やコストについても想像を巡らせてもらう
- 第二部の狙い:
- 12領域それぞれの要点とキーワードのみを伝える
- 1領域5分でも60分かかるため、後から自身で調べるためのキーワードを手に入れる時間と位置づける
- 第三部の狙い:
- 政府から公表されているデータを例に、機械可読性を高めるExcelの加工実習を行う
- 第一部・第二部で学んだ全体感と知識を元に作業し、背景や課題を想像することが目的
- 最後にAIの力も使ったデータ整備の事例も紹介する
- 研修の対象と方針:
- ExcelやSpreadsheet形式でデータを扱うことが多い人を主な対象とする
- データエンジニアリングに代表されるシステム知識を前提とせず、専門用語を出来るだけ避けて解説する
- 厳密さより分かりやすさ:
- データマネジメントで普遍的に扱われる概念を優先し、AI時代で変化した点も一部伝える
- 各領域の詳細解説や最新情報を自分で調べられるようにキーワードを抽出して伝える
- 用語をただ覚えるだけの研修とせず、概念とセットでキーワードを持ち帰る研修を目指す
- 参考図書DMBOK:
- 米国のデータマネジメント団体DAMAがまとめたデータマネジメントの教科書的な書籍
- ガバナンス、品質、セキュリティ等11領域に分類して解説している
- 現在発売されているのはDMBOK 2.0であり、AIやクラウド技術を反映したDMBOK3.0プロジェクトが発足中
- DMBOKのハードル:
- Amazonでも1万2000円以上、600ページ以上の大ボリュームで、訳本のためカタカナ語が多い
- アカデミックな記述が多く、手にいれること、読み切ることそれぞれにハードルがある
- 本研修の立ち位置:
- DMBOKで紹介されている概念や分類方法を元に、AI時代に伴う変化もあわせて解説する
- 時間も限られるため概念を伝えることを優先した内容とする
- DMBOKによる整理をベースにしつつ、より実務的な視点から解説する
■ 2. データマネジメントの大原則
- データを資産として考える:
- データマネジメントにおける最も基本的な原則
- 資産だからこそ、活用方法を考え、優先順位を決め、盗まれないように守る活動が必要になる
- 置いてあるだけの資産:
- ただ置いてあるだけの資産は価値を産まず、管理コストやリスクだけが増えていく
- その資産は誰にとって価値があるか、その価値をどう引き出せばいいかという問いに答える必要がある
- データマネジメントの定義:
- データという資産の価値を最大化する活動全般を指す
- ざっくり言えば「資産管理に必要なこと」のデータ版と捉えればよい
- データ固有の特性:
- 一般的な資産と異なり、電子情報であるデータはコピーが容易である
- 使っても価値が減らないという特性がある
■ 3. データマネジメントの12領域
- Aikenのピラミッド図:
- DMBOKにおいてデータマネジメントは12(表現によっては11)の領域に分かれるとされている
- Aikenのピラミッド図は領域が何であるかを示すと共に、各領域の相互関係を示す
- 頂点にあるデータ分析:
- 頂点にあるのがデータ分析であり、データから価値が取り出される場所となっている
- 頂点を支える各領域のデータマネジメントが不十分だと、取り出せる価値も不十分となる
- 推奨される取り組み順:
- 色分けは推奨される取り組み順であり、青色、オレンジ色、緑色、赤色の順が論理的で良いとされる
- 扱うデータを統合して構成を決め、置き場所とセキュリティを確保する
- 全体図と説明書、品質基準などを定める
- 基盤システムを用意してルール、ドキュメント、管理方法を定める
- データ分析を行なって価値を取り出す
- 価値を生む場所の限定:
- データが価値を生むのは頂点のデータ分析のみである
- 準備万端でデータ分析できれば理想的だが、現場では中々そうはいかない
- 課題は頂点から降りてくる:
- 多くの場合、データは分析・活用されたとき初めて課題が露見する
- 価値を取り出そうとして上手くいかなかったとき、課題として頂点から降りてくる
- そのため現場では、頂点のデータ分析から基盤へという順番で取り組みが進む
- 現場から出る課題の例:
- データが更新されていない、個人情報が漏れていないか、このデータは何のためにあるのか
- 営業と製造のデータが紐付かない、あのデータはどこか、分析のコストが大きい
■ 4. 花形のデータ分析と裏方のデータマネジメント
- 利益に直接繋がるデータ分析:
- 需要予測、パーソナライズ、投資最適化など、組織の利益に直接貢献しうる知見を取り出せる
- 間接的な利益貢献:
- データマネジメントはセキュリティやデータ品質などを担う
- データ分析を安心・安全・簡単に実施させることで間接的な利益貢献を行う
- 地味な個別活動:
- 全体像を書き出す、メタデータを拡充する、ドキュメントを体系的に管理する等が中心となる
- 個別のデータマネジメント業務は地味で目立たないことが多い
- 地味な活動の積み重ねで「安心・安全・簡単にデータを使える状況」を作るのがデータマネジメント
■ 5. AI時代におけるデータマネジメント
- AIによるデータ需要の発生:
- 生成AI(LLM)はデータの意味を含むあらゆる情報を解釈対象とする
- 従来のログデータや統計データに加え、定義書、活用事例、記録日時なども対象となる
- 社内ドキュメント、監査記録、利活用ポリシーなども対象となる
- あらゆる情報が生成AIのインプットとなり、AIの出力精度に影響するようになった
- サイレントな悪影響:
- AI活用の広がるスピードに、データ品質の向上やデータガバナンスによる統制が追いついていない
- 品質の低いデータが参照されたり、逆に機密情報など参照すべきでないデータが学習される
- 根拠不足のままの判断やハルシネーションでの情報補完など、気づきにくい悪影響が生まれている
- AI-Readyデータ:
- AIが安心して学習・推論に使えるデータを指す概念として登場した
- AIが読めるような機械可読性、意味の補完に役立つメタデータ、高い品質、適切な権限管理を備える
- 既存データをAI-Readyな状態に整備する必要性が高まっている
- 大規模化する基盤部分:
- AIという巨大なデータ利活用需要に対し、それを支えるピラミッドの基盤部分も大規模化が求められる
- 特定部署で実施されていたデータ活用は、全ての部署がAI活用と名前を変えて実施するようになった
- 組織構成、人材リソース、各部署の保有データ、活用事例、社内ドキュメント等が対象となる
- AIによりデータの価値が更に高まり、データの資産管理であるデータマネジメントの価値も再認識された
■ 6. 行政機関の動き
- デジタル庁のガバナンス指針:
- 2025年6月20日に「データ・ガバナンスガイドライン」を公表している
- 4つの柱として越境データの扱い、セキュリティ、総合(マチュリティ)、AIへの対応指針を挙げている
- 組織間、産業間、国境間でのデータの取り扱いも含めた経営層向けの指針を示している
- IPAのデータマネジメント試験:
- 情報処理技術者試験にデータマネジメント試験(仮称)が2027年度から新設される
- ITパスポート試験の次のステップの試験として位置づけられ、サンプル問題も公表されている
- デジタルスキル標準(DSS)にもデータマネジメント類型を追加している
- データ利活用制度の基本方針:
- デジタル行財政改革会議が2025年6月13日に「データ利活用制度の在り方に関する基本方針」を公表した
- データとAIの社会実装に向けて、データを社会の共通資源として再定義する
- トラスト基盤の構築や個人情報保護法の更新を通じて透明性を確保する
- 先行する個別分野でデータ連携基盤を整備し、政府内では行政データの品質向上に取り組む
■ 7. データマネジメント推進の難しさ
- ボトムアップの限界:
- 現場の課題解決からスタートして適用領域を広げても、ボトムアップの取り組みはいつか限界を迎える
- 基盤領域には全社的な視点、組織のルール策定、業務フローの変革が必要になるためである
- エンジニア部署が直面する課題:
- ビジネスサイドとの接続不足により、最新のビジネス状況とデータを紐づけるコネクションが弱い
- 要件定義の乖離により、ビジネス要求を適切なメタデータやデータ品質基準に落とし込めない
- 統率力の不足により、全社的なデータガバナンスを牽引するリーダーシップを発揮しにくい
- ステークホルダー調整の課題:
- データはステークホルダーが多くなりがちである
- 関連部署との調整そのものが大きな課題となる
- トップダウンの正論の弊害:
- トップダウンから計画ばかりを打ち下ろしても、データマネジメントは進まない
- 現場の状況を顧みない計画は、結局は喫緊の課題解決に結び付かない
- 人的・時間的リソースを投じても成果が出るのが遠い未来になりがちである
- 結果としてデータ利活用の現場やデータ関連部署を疲弊させてしまう
- 実現可能性を見極める力:
- 現場でのデータマネジメントの実装、あるいは移行計画を現実的に組み立てる必要がある
- 実現可能性を見極める力が必要となる
- ありがちな推進パターン:
- トップダウンで理想像を立て、生成・保存・活用などのフェーズに応じた管理ポリシーを定める
- 各部門・領域の現在のデータ管理レベルをポリシーに従って計測し、理想状態との乖離を計測可能とする
- 生成から利活用までのサイクルが比較的短い領域で実践し、成功事例を横展開する
- 基本的な流れは全社プロジェクトのPoCと同じである
- 王道でも変わらない現実:
- 王道の流れを踏んでも、数年後にあまり変わっていないデータ環境がそこに残ることがある
- やり切ることの難しさ:
- ルールを打ち立てることも小さく始めることも、それ自体が大変な偉業である
- しかしデータマネジメントは放置しても勝手に広がっていくことはない
- 現場への適用を推し進めるリソースや、推進力の源泉となる要因もあわせて考える必要がある
- データに関わる全てのステークホルダーに影響するため、一過性の盛り上がりでやり切ることは難しい
- 計画の途中でリソースが不足したり組織の優先度が変われば、推進力は低下し停滞してしまう
- だからこそ中長期でゴールまでの計画を描く必要がある
- 上下左右に繋げる役割:
- 中長期の計画を実行し続けるには、トップダウンの支援とボトムアップの事例創出が必要となる
- 加えて横方向の協力者も必要となる
- 経営層など組織の意思決定者から計画の承認とリソースを得る
- データマネジメントの実践で目にみえる成果を示す
- エンジニアやビジネス現場など他部署との連携を築く
- 繋ぎ役の必要性:
- これらの部署はサイロ化していることも多い
- だからこそ誰かが意識的に「繋ぎ役」を担い、組織全体としてデータマネジメントを推進する
- 同時に、理想の状態に向けて業務フローの変革そのものをマネジメントしていく必要がある
- 完了は運用の始まり:
- データマネジメントは、着手や完了そのものより継続することの方が難しい
- データ品質やメタデータなどビジネス状況を反映すべき領域はメンテナンスし続ける必要がある
- そのメカニズムそのものを仕組み化しなければならない
- 成果物の陳腐化:
- 全体図、パイプライン、ドキュメント、品質基準は完成した瞬間から陳腐化が始まり劣化していく
- 従来の情報システムと同じことだが、データは情報システム以上に変化のスピードが速い
- 中長期の計画に加え、状況を把握し現場の運用に繋げ続けるためのモニタリングが欠かせない
- 現場からの期待:
- データ利活用の現場からの期待は「データは使えて当たり前」という素直な欲求であることが多い
- 利活用時の「できない、わからない」という不によりデータマネジメントの課題が注目される
- 逆に完璧に機能しているときはデータ利活用に障害はなく、データマネジメントは注目されない
- 課題が見当たらないときは、完璧に利活用できているか誰も利活用していないかのどちらかである
■ 8. 物理インフラ事業との類似性
- 既存インフラと同種の難しさ:
- 電気・水道・ガス・通信といった既存インフラが「動いていて当たり前」とみなされることと似ている
- データは単なるIT部署の持ち物ではなく、ビジネスを支える社会インフラである
- そのために生まれる課題も社会インフラと類似している
- 終わりのない維持管理:
- レポートの数値が正しい、システム間でユーザーデータが連携されている状態は当たり前とされる
- これを支えるにはパイプラインの監視、メタデータの更新、データクレンジングが欠かせない
- 物理インフラの断水や停電が社会活動を麻痺させるのと同様である
- 運用が止まれば業務停止や意思決定のミスといった致命的な障害を引き起こす
- 見えにくい投資対効果:
- データ基盤、マスターデータ管理、データガバナンス体制の構築には多くの時間とコストがかかる
- それ自体が価値を生むわけではなく、データが利活用されて初めて利益が生まれる
- そのため投資対効果の説明が難しい
- 送電網や水道管の敷設と似ており、老朽化対策の保守費用の合意を得にくい点も共通する
- 説明が難しいからと投資対効果の提示を放棄せず、恩恵を丁寧に測定し示すべきである
- レガシーからの段階的移行:
- 24/365で動作しているITシステムをデータ利活用しやすい形に移行・統合する場面がある
- ビジネスを止めずに段階的に移行する綿密な計画が必要となる
- 都市機能を維持しながら古い水道管を少しずつ刷新していくことに似ている
- 標準化への抵抗:
- 全社で統一したデータ定義を進めようとすると、部署ごとの独自規格が障壁となる
- 「今までの運用を変えたくない」という心理も障壁となる
■ 9. 第一部のまとめ
- 難しさの要約:
- データマネジメントはトップダウンとボトムアップのバランスが重要
- ステークホルダーが多く、データ関連部署からビジネスの現場まで横断的な調整能力が求められる
- 一過性の盛り上がりだけで整備しきることは難しく、中長期の計画と継続的なリソース確保が必要
- 「データは使えて当たり前」の状況を実現するために維持管理や運用設計を考える必要がある
- これらの調整や業務をこなせる人材にデータマネジメントの未来はかかっている
- 重要性の真の意味:
- データを資産として捉えて資産管理を考えるのがデータマネジメントの根幹
- AIという巨大なデータ利活用者の登場によって注目されるようになった
- 物理インフラと比べて耐用年数は短く、状況は刻々と変化し、無秩序になりやすい難しさがある
- データ利活用を行いたいヒトやAIに対して「当たり前」を「提供し続ける」ことが重要な価値
- 横断的な調整能力、中長期の計画、リソースの確保、保守運用の設計など必要な要素は多い
■ 10. データ分析
- 頂点からの説明順:
- 本研修ではピラミッドの頂点から順に説明する
- データ利活用時に課題が表に出てきやすい順であり、想像しやすいためである
- 全12領域を同熱量で語らず、特に詳しく伝えたい領域を詳細に解説する
- データ利活用の範囲拡大:
- 従来のデータ分析は、過去のデータから何が起きているかを把握し将来を予測するものだった
- AI時代にはコンテンツやプログラムを生成することもデータ利活用に含まれる
- 非構造化データの扱いやすさ:
- ビジネスにおいて分析対象とされにくかった非構造化データがAIによって扱いやすくなった
- 組織内の文書、画像、会議音声や録画はAI自体の学習に利用される
- AIの回答精度を高めるための情報源の拡張(RAG: 検索拡張生成)としても活用され始めている
- 求められるスキルの変化:
- AIによりデータ加工・集計や統計学等の技術的なスキルの重要度は下がった
- 代わりに問いを立てる力や検証力、事業理解、ストーリーを語る力など概念的スキルの重要度が増した
- 何が知りたいか:
- ビジネスの状況に対して適切な問いを立てられる力が求められる
- 「何がわかればビジネスに貢献できるか」を判断するには事業に対する理解が必要となる
- AIによる分析成果物が増える中、それを批判的に検証する力も大事になっている
- 「なぜそれを知るべきなのか」を意思決定者に伝えるストーリーテリングの能力も求められる
- 分析に足るデータの存在:
- 問いを立てた後は、それを解くためのデータが組織内外に存在するかを見極める必要がある
- 問いが良くてもデータが存在しなかったり品質が悪ければ、分析結果は意味をなさない
- データサイエンティストの作業時間の8割は探索やクレンジングなどの整備に費やされるという説がある
- データは「あるかどうか」ではなく「使える品質かどうか」と「アクセスできるか」が重要となる
- 活用可能性の判断:
- データがあることと使えることは別問題である
- 機械可読性や鮮度、表記ゆれといったデータ品質を判断する必要がある
- 複数のデータを組み合わせる場合は、データ同士が連結できるかも見極める必要がある
- 制度面では個人情報やプライバシー、セキュリティの観点から特別な権限が必要な場合もある
- AIによる分析では、機密データを誤って読み込ませないためのガードレールとデータ整理が重要となる
- 分析者に求められるもの:
- 「正しく理解し、正しく問う」ための経験とセンスが求められる時代となった
■ 11. DWH & BI
- データウェアハウスの定義:
- データを収集・蓄積・分析するための基盤であり、「データ分析基盤」は多くの場合これを指す
- BigQueryやSnowflakeなど、パブリッククラウドの分析基盤製品もこれにあたる
- 構造化ログデータや業務用データベースからデータを集約・加工・集計・分析するシステム基盤である
- ダッシュボードなどで可視化するための基盤でもある
- 関連する領域:
- データ統合と相互運用性、ストレージ&データ運用、モデリング&デザインと密接に関わる
- セキュリティ、データ品質とも密接に関わる
- これらの領域で検討した内容が実際のシステムとして具体化されたものがデータウェアハウスとなる
- 集めるだけでは不十分:
- データが集まっていればよいわけではない
- 統合され、整理され、拡張性やアクセス管理を備える必要がある
- データを集約しただけの巨大なExcelはデータウェアハウスではない
- BIの位置づけ:
- 広義にはデータから示唆を得る行動すべてがBIだが、実用上はBIツールと捉えられることが多い
- 多くのBIツールはExcelファイルなど単一のデータに接続して使うこともできる
- 様々なデータが蓄積・連携されたデータウェアハウスと接続することで本領を発揮する
- ベクトルデータベースの統合:
- AI活用にはテキスト・画像・音声・動画などの非構造化データも求められるようになった
- 非構造化データをベクトル化して蓄積するベクトルデータベースをDWHに統合する動きが出ている
- AIが参照できるデータソース(RAG)として活用する動きが出てきている
- 利用者の変化:
- DWHの最たる利用者はデータ分析者だったが、AIが自然言語から機械言語に変換できるようになった
- 人間の自然言語で指示を受けたAIが、DWHから直接データを取り出す方法が生まれた
- AIによる変換では指標の計算方法が毎回ぶれるリスクがある
- 集計方法やビジネス用語を定義した「意味層(セマンティックレイヤー)」を組み込み精度を高めている
- 分散型のアプローチ:
- 中央集権的な一つの分析基盤に集約せず、各データソースに分散させたまま集計・分析する手法も登場した
- データファブリックは、データを分散させたまま仮想的に統合環境を提供する方法である
- データメッシュは、管理権限を移譲し標準化された共通の連携機能とルールを持つ方法である
- いずれもデータソースごとに適用できるルール・ポリシーの制定と、それを支えるガバナンスが重要となる
- DWHの進化:
- ただの巨大で高速なデータベースではなく、AIにデータを提供するインターフェイスとして進化している
■ 12. マスターデータとコード
- マスターデータの定義:
- 組織内における唯一の、一貫した、信頼できるデータを指す
- 顧客マスター、商品マスター、店舗マスターのように現実のビジネス対象ごとに作成される
- 一度登録されれば頻繁には更新されない
- コードの定義:
- 「1: 男性, 2:女性, 3:その他」「01000: 北海道, 02000: 青森県」のように選択肢を定義したもの
- 実務上はマスターデータとコードを同じものとして管理されることも多い
- 重要な問題意識:
- 「同じ実体を指すデータが複数あるとブレる」という問題意識が重要である
- 同じユーザーが複数のIDで登録されると、システムは別人として扱ってしまう
- 現実の状態を正しくデータに反映するために、マスターデータとコードは厳密に管理する必要がある
- ビジネス現場との連携:
- 顧客マスターでは、営業部門は案件発生や見積もり時点で顧客として登録したい
- 一方で経理部門は請求書発行時点で顧客としたいといった定義のブレが生じる
- 組織全体として「顧客とは、いつ・何を指すのか」を統一する必要がある
- マスターデータ管理にはビジネスへの理解と、ルールを決めるオーナーシップが求められる
- 変更の慎重さ:
- マスターデータとコードは組織内の様々な箇所から参照される「信頼できるデータソース」である
- 安易な変更は事故のもととなる
- 設計段階から「将来変更が起こりうるか」を想定しておくことが望ましい
- 「1:令和」「2:平成」「3:昭和」というコードは次の年号が登場すると困ることになる
- 未知の値にどのコードを振るかを、あらかじめ意識すべきである
- 守るべき条件:
- 唯一の正解であること、一貫していること、最新であることが期待される
- マスターが信用できないとき、データ利活用者は自分だけのマスターデータを作り始める
- 結果として組織全体の唯一性が崩れる
- 誤りや掲載場所ごとのブレ、古い情報による陳腐化を防ぐ定期的な保守点検が必要となる
- マスターデータの位置づけ:
- データの量としては少ないが、特に重要な資産として管理する
■ 13. ドキュメント管理
- 従来のドキュメント管理:
- 組織内のマニュアルや文書・画像・音声・動画といった非構造化データを対象とする
- コンプライアンス維持のための分類・ラベリング(メタデータ付与)を行う
- キーワード検索への対応、閲覧権限の管理などを行う活動だった
- AI時代の位置づけ:
- 非構造化データは「AIの重要なインプット」「データウェアハウスの一部」として存在感を増している
- 人間が手作業で行なっていたラベリングも、AIが文書内容を理解して分類する効率化が進んでいる
- 検索面でもAIが文書の意味を解釈して適切な文書を返せるようになってきた
- 「有給の取り方」で検索して「社内勤怠マニュアル」が返るような検索が可能になっている
- 構造化データとの組み合わせ:
- 非構造化データを文書ストレージに保管するだけでなく、ベクトル化してDWHと統合する動きがある
- 文書の内容は業務システムのログなど他の構造化データと組み合わせられる
- AIによる分析の背景情報の補強に役立てられる
- ドキュメント管理の位置づけ:
- ただの裏方事務ではなく、AIのための重要なデータ整備業務となっている
■ 14. データ統合と相互運用性
- データ統合の定義:
- 組織内に散らばったデータを一箇所に集めて統合データ基盤を作る取り組み
- 各システムからデータを抽出・変換・取込するプロセスが必要となる
- 相互運用性の定義:
- システムAとシステムB間でデータを相互にやり取りできることを指す
- 標準化された共通規格でやり取りできるのが理想である
- データを変換すれば相互にやり取り可能な場合も、相互運用性があると言える
- AI時代の相互運用性:
- システム間だけでなく、AIとシステムの間の相互運用性も課題となる
- データがただ保管されているだけでなく、人間の利用とAIの利用の双方を考えて統合・管理する
- エンジニアリング要素:
- ビジネスが求める形式とタイミングで提供できるよう、抽出・変換・取込(ETL)の仕組みを整える
- クラウド上で構築することも多く、クラウドの知識も踏まえてシステム全体を設計する必要がある
- ビジネス要求通りに統合・管理できているかの計測にはデータ品質が用いられる
- 繋げるためのキー:
- データは意識して設計しなければ繋がらない
- WebアクセスログとアカウントIDを取得しても、重ね合わせる共通のキーがなければ繋がらない
- キー以外にも、データの粒度や取得時点のズレが繋げる際の課題となる
- 繋がるべきデータが繋げられる構造になるよう、事前の設計と調整が重要である
- AI向けの機械可読性:
- データ統合基盤を利用するのは人間だけでなくAIも同様である
- 社内ドキュメントなどの非構造化データは元々人間向けに作られている
- そのためAIが読み込めない、あるいは非効率にしか読めない場合がある
- 既存文書を機械可読な構造に変換すると同時に、新規文書を最初からAI向けの形式で作成する必要がある
■ 15. データストレージ & データ運用
- データにも運用がある:
- データを生成・収集・蓄積し、利活用に繋げるまでの一連の流れは保守・運用する必要がある
- 使いたい時に使えることの保証、障害時の復旧、素早いアクセスのための技術的な活動が求められる
- ライフサイクル全体の管理:
- 生成・取得から保存・加工・活用、そして最後の破棄までを考える必要がある
- 忘れがちなのが「破棄」であり、データは腐らず簡単にコピーできるため総量は際限なく増えやすい
- 使われないとわかっているデータを持ち続けることは、コストとリスクの両方を増加させる
- データの削除ポリシーを定め、適切にライフサイクルを管理する必要がある
- データの流れの俯瞰:
- 個別システム単位で保存場所を管理するだけでなく、データの流れ全体を俯瞰する必要がある
- 「どこから来て、どこに保存され、誰がアクセスできるのか」を管理しなければならない
- 物流センターの運営に似ており、データも適切に整理し最適な物流網を構築する必要がある
- 目立つ領域ではないが、物流網のようにデータ利活用の現場を支えている
■ 16. データセキュリティ
- 資産とリスクの両面:
- データは活用すれば価値を生む資産だが、漏洩や不正利用で組織に被害をもたらすリスクでもある
- 正当なアクセス権を持つ人・システム・AIだけが承認された目的で利用できるようにする
- そのためにポリシー策定、権限管理、監査モニタリングを行う必要がある
- 個人情報とプライバシー:
- 個人情報に加え、宗教・病歴といった要配慮情報やプライバシー関連情報の管理が必要となる
- 適切に管理しなければ組織に重大なインシデントをもたらしかねない
- 「リスクは、それをリスクと認識していない時が一番大きなリスクとなる」という意識が重要である
- ライフサイクル全体を管理し、透明性を確保する必要がある
- AI時代の脅威:
- 外部からの脅威やシステムの脆弱性への対策に加える必要がある
- 組織内の管理外でのAI利用(シャドーAI)による意図しないデータ学習への対策も必要となる
- アクセス者が人間・AI問わず適切な権限を持っているかを常に確認する仕組みが求められる
- 法改正への追随:
- 令和8年に成立した改正個人情報保護法では、統計作成目的での要配慮個人情報の取り扱いが緩和された
- 法改正によってセキュリティ基準が変わりうる
- 法務部門等とも連携して関連法令を把握し、セキュリティポリシーを適時見直す必要がある
- データのリターンだけでなく、リスク面も正しく見据えて時代に即した守りを固める
■ 17. データモデリング & デザイン
- データモデリングの定義:
- データベースあるいはRDBにおいて、ビジネス対象をどのようにデータ上で表現するかを考えること
- DWH & BIやデータ統合と相互運用性と同様、データエンジニアリングとしての色が強い領域である
- 狭義の意味:
- 収集・統合したデータ群をどう組み合わせれば使いやすいデータになるかを考える
- 「関連性」に着目した技術領域を指すこともある
- 5W1Hによる整理:
- 「顧客が(Who)ある製品を(What)先月に(When)ECサイトで(Where)注文して(Why)発注書を作成した(How)」と考える
- 顧客・製品・時点・場所・取引タイプ・発注書IDという一連のデータの組が見えてくる
- 情報の関連性をまとめたデータの組をデータモデルと呼ぶ
- 多様なアプローチ:
- クラウド技術を取り込みつつ、非構造化データを含む大量のデータに対応する手法が開発されている
- アジャイル型、蓄積して用途を後から決める型、分散型など各組織がそれぞれの手法を実践している
- 設計の影響範囲:
- データの設計はデータを収集・加工・統合する際の効率にも影響する
- 地味ながら重要な領域である
■ 18. メタデータ
- メタデータの定義:
- あるデータAが何なのかを示す、Aを説明するためのデータα
- データマネジメントの中でも最重要とも言える領域であり、AI時代にさらに重要性が増している
- ログの発生時刻や対象システム名、どのビジネスで使われているかを示すドキュメントも該当する
- 個人情報かどうかを識別するラベルもメタデータである
- イメージとしては図書館の分類目録が近い
- メタデータなしには大量のデータを管理できないため、メタデータそのものも適切に管理する必要がある
- 人間向けの従来用途:
- システムがデータに付与した周辺情報、データベース上の説明文、組織内メンバーによるFAQが該当する
- データ同士の関連性を記した「リネージ」による障害原因の特定にも役立つ
- 個人情報を含むデータへのタグ付けによる権限管理など運用面でも役立てられている
- AIにとっての効果:
- AI時代にはAIがメタデータの最大の消費者となる
- メタデータはAIに文脈(コンテキスト)を与え、AIが自律的にデータを取捨選択できるようにする
- AIの想定外の挙動を防ぐためのガードレールとしても機能する
- メタデータがない状態は、分類や目録が存在しない図書館と同じである
- その場合AIは、棚の中の本を一冊ずつ全部読むような非効率な動きを強いられかねない
- 限られたAIリソースを効率的に使い精度を高めるには、適切なメタデータが欠かせない
- アクティブ・メタデータ:
- AIが十分な推論能力とコンテキストを持てば、データをスキャンしてメタデータを自動生成できる
- 組織のポリシーや利活用事例をコンテキストとして持つAIが自動で生成・更新し続ける仕組みが注目される
- 最終的な人間の承認プロセスは必須である
- AI自身の利用状況までメタデータ生成のソースとできる点が、注目される理由である
- 成功の鍵:
- 「十分な量と質を備えたメタデータを高速に提供できるか」が組織のデータマネジメント成功の鍵を握る
■ 19. データ品質
- データ品質の役割:
- 収集・加工・利活用の中で、利用者が求める水準を満たさないデータが出てくる
- 更新日付の古さ、不正確なデータの混入、データの重複などが価値抽出に悪影響を及ぼす
- こうした状態は「Garbage In, Garbage Out」と揶揄される
- 利用者の求める水準をデータが満たしているかを測るのがデータ品質の役割である
- 利活用における問いに答えられるデータこそが「品質の良いデータ」となる
- 正しく定義・測定するには、利用者側のニーズを正しく把握する必要がある
- 簡易な評価軸:
- データはどこから来たのか、正しいのか、使えるのか、使いやすいのか、守られているかが評価軸となる
- 計測されたデータ品質はメタデータの一部として管理される
- ISO 25012による規定:
- データ品質の評価軸は国際標準のISO 25012で規定されている
- 「データは正しいか(完全性、正確性、精度、一貫性)」が含まれる
- 「新しいか(適時性・最新性)」「使える状態か(可用性、アクセシビリティ、回復性)」が含まれる
- 「安心できるか(機密性、信憑性、追跡可能性)」が含まれる
- 「使いやすいか(標準適合性、理解性、効率性、移植性)」が含まれる
- 利用者の求めに応じてこれ以外の評価軸が必要になることもある
- AIによる重要性の増大:
- 従来のデータ利活用でも分析精度に直結する要素だったが、AI活用の広がりで認識が強まった
- AIの推論は途中経過がブラックボックス化しやすく、間違えた原因の検証・修正が難しい
- だからこそ最初から高品質なデータをAIに与えられるよう、データ品質を高く保つことが求められる
- 何でも与えればよいわけではなく、メタデータと品質を組み合わせた取捨選択も重要である
- 指標と目標の取捨選択:
- すべてを高水準に高めればよいわけではなく、セキュリティと似ている
- ビジネスの要求に応じて必要な品質を定義し、測定・監視・改善し続けることが求められる
- リアルタイムな利用を求めるなら最新性を優先すべきである
- 「データが使いにくい」という声が多いなら標準適合性や理解性を高めるべきである
- 常に利用者と、求める品質のレベルをすり合わせることが重要である
- 注目される領域:
- データ品質はメタデータと共に、AI時代において最も注目されるデータマネジメント領域である
■ 20. データアーキテクチャ
- データアーキテクチャの定義:
- データがどのような目的・用途でビジネスと接続されているかを書き出すもの
- サイロ化の防止:
- データは組織内の一箇所で生まれるわけではなく、各部署のシステムや外部から複数の箇所で流入する
- 利活用も複数の部署や関連組織にまたがる場合がある
- 生成・利活用それぞれでサイロ化が起きるのを防ぐ役割を担う
- 活用現場と生成現場を橋渡しする「地図」となる
- 川の流域管理との類似:
- 雨が川となり、どこで別の川と合流するかを管理することに似ている
- 最終的にどこまで流れ、どのように利用されているかを管理するのと同様にデータのフローも管理する
- 作成方法:
- 組織内の活動を「ビジネス」「データ」「アプリケーション」「インフラ」等に分けて図示する
- エンタープライズ・アーキテクチャ(EA)の枠組みを流用することが推奨される
- AI時代の役割:
- データとビジネスの関連を示す「文脈」そのものとしてAIに参照される
- 特にメタデータやデータ品質で触れたような監視目的のAIにとって重要な文脈となる
- 分散型のデータ基盤を採用している場合はデータフローが細分化しやすく、重要性はさらに増す
- データの「流域」を書き出しておくことで、全体を俯瞰した文脈が得られる
■ 21. データガバナンス
- データガバナンスの定義:
- ニュース等ではプライバシーやセキュリティ面を指して呼ばれることも多い
- 本来はデータ分析からアーキテクチャまで、これまで紹介したすべての領域を監督する活動である
- 監督者の役割:
- 野球の監督と同じく、リソース(ヒト・カネ・データ)をいつ、どこに配置するかを考える
- 全体方針を打ち出す役割を担う
- 監督のいない野球チームが次第に連携を失うように、ガバナンスなしでは局所最適化が進む
- 結果として全体のバランスを失ってしまう
- 常に全体を俯瞰してポリシーを定める
- 状況をモニタリングし、取り組みの優先度を決め続けなければならない
- 組織体制の課題:
- 最も全体的な視点が求められる領域であるため影響範囲は大きい
- 影響範囲に見合った組織体制を築けるかどうかが最大の課題となる
- 経営企画やホールディングス組織など、全体の意思決定者に近い位置に組織を置くことが望ましい
- ボトムアップで始めるのは、一選手がフィールドに立ちながら監督を兼任するようなものである
- 指示は行き渡らないか、無視されてしまう
- AI時代の難易度:
- 監督役に求められる責務そのものは変わらない
- 内部ではAI利用に関するアクセス権限の再編が必要となる
- 外部ではAIに関わる法制度・規制の変化への対応を検討し、組織全体に行き渡らせる必要がある
- そのためデータガバナンスの難易度は相対的に上昇している
- 「全体を見渡して指示を出せるだけのポジションを作れるか」が一番の難所となる
■ 22. 第二部のまとめ
- 12領域の性質:
- 技術的側面が強い領域、ビジネスの側面が強い領域、その両方を横断する領域がある
- ピラミッドの下部に行くほど全体的な視点が求められる
- AI時代においては特に重要な領域となる
- 調整の不可欠さ:
- 真にデータマネジメントでインパクトを出すには組織内外との調整が不可欠である
- 一人で全てを担うことはできず、領域ごと任せられるパートナーを見つける必要がある
■ 23. Excelでのデータ整備実習
- 実習の位置づけ:
- 既存のExcelデータについて、AIにとって読みやすい機械可読性を確保する作業実習を行う
- Excel形式であっても、内部のセル構成によって機械にとっての読みやすさは大きく変化する
- 実習の目的:
- 機械可読性の基準を知ること
- データ整備を人力で実施するコストを知ること
- 「機械にとっての問題は何か」「根本的な原因は何か」を考えること
- 「所属部署のデータに当てはめるとどうか」を考えること
- 特に考察が重要であり、苦行を経てデータマネジメント的な解決策を自ら考えてもらう
- 機械可読性の定義:
- AIを含む機械処理の際、事前のデータクリーニングを挟まずに集計・分析等ができるかの度合い
- 行政データのルール:
- 「行政データにおける機械可読性に関するルール」が公表されている
- 複数のチェック項目をレベル分けし、レベル1を最低限遵守すべき内容と位置付けている
- レベル1の項目:
- 1Sheetに複数の表が掲載されていないか
- データ本体と無関係な情報がないか
- データが空白行で分断されていないか
- スペースや改行等で体裁を整えていないか
- セル結合をしていないか
- レベル2の項目:
- データ内で項目名等の省略をしていないか
- 各列が一意に識別可能な項目名を持っているか
- 数値データは数値属性とし、文字列を含まないこと
- レベル3の項目:
- 項目名行から始まり、次行からデータ入力されているか
- データの単位を記載しているか
- データが縦持ち形式になっているか
- 実習課題:
- 経済産業省の石油統計の時系列表から、任意の月のExcelファイルをダウンロードする
- ルールをベースに方針を立て、機械可読が可能と思えるレベルまでExcelの構造を修正する
- 目安は、どの表でもExcel機能だけでグラフ描画ができる程度である
- 考察課題:
- AIがこのデータを読むとき、読み間違うとしたらどこかを考える(データ品質の特定)
- データ公開の目的と手段は一貫しているかを考える
- 機械可読可能な状態で公表するとき、どのような調整を行い業務を変えるべきかを考える(データガバナンス)
- 時間があれば所属部署が所持しているデータについても機械可読性を評価する
■ 24. 整備後のデータ例
- 整備後の状態:
- 表を整理することで、Excel機能だけでグラフ描画ができる状態になる
- もう一工夫した場合:
- 種別、更新年月、指標レベル、親指標といった列を追加する
- 単一のExcel内のレベルだが、これもメタデータの一部である
- 指標間の関係性を記述する部分にはデータモデリングの要素も含まれる
- 個別のデータファイルレベルでも、使いやすさや処理のしやすさを考えることが活動につながる
■ 25. AIを使ったデータ整備の事例
- チェックツールHarunobu:
- 「行政データにおける機械可読性に関するルール」の準拠状況をチェックするツールとして公開している
- CSVまたはExcelファイルに対し、ルールに記載されたチェック項目を判定するアプリケーションである
- ルールに付随するサンプルアプリという位置付けで、自動判定が難しいルールについては未対応である
- ローカルで動作させるにはpython実行環境とパッケージインストールが必要である
- ローカルサーバーで立ち上がるUI画面のほか、単独プログラムとして他システムに組み込める
- Harunobu自体はAIなしの機械的な判断のみで動くプログラムとして成立している
- AIに接続しなくても実行環境さえあればどこでも動く
- 判定結果の例:
- 石油統計のExcelはレベル1・2・3すべてで重大ルール違反により強制0点となった
- 1Sheetに17個のテーブルが検出されるという致命的な違反があった
- データ範囲内のテーブル間空白行8件、テーブル外のセル13件が検出された
- 体裁用スペース・改行5件、1件のセルでの複数データが検出された
- AIとの組み合わせ:
- ガバメントAI「源内」にHarunobuを実行させ、採点結果.jsonを得る
- 採点結果.jsonを元に、Excelを加工して機械可読性を向上させるscriptを作成させる
- そのscriptを実行して、加工したExcelのCSVファイルを作成させる
- ツール名の由来:
- Harunobuは江戸時代中期の浮世絵師 鈴木晴信に由来する
- 錦絵を大流行させた浮世絵師であり、美人画で人気を博し浮世絵の発展に貢献した
- 複数の色の版を使うことから、複数のルールを適用して機械にとって美しいデータを作る意味を込めた
- 紙を入れて版を刷ることから、神(Excel)を入れて綺麗なデータを作るという意味も込めた
- 近所には平賀源内が住んでおり、友人として親しく共に錦絵の工夫をしたという
■ 26. 全体まとめ
- 第一部の持ち帰り:
- 全体概要と、推進することの難しさ、直面する課題を紹介した
- 研修後、所属組織の課題を解決するために必要なコストとリソースについて考える
- 必要な気合いと覚悟の程を推し計る
- 第二部の持ち帰り:
- 12領域を頂点から底辺に向けて順に解説した
- どの領域も少なからずAI時代の影響を受けている
- 所属組織ではどの領域から始めるべきか、それは何故なのかを論理的に導き出す
- 第三部の持ち帰り:
- Excelの機械可読性について作業実習し、AIやルールによって省力化する事例を紹介した
- ここで触れたのは1領域のさらに一部分に過ぎない
- 実践で立ち塞がる更に多くの課題を、楽に解決するための思考を続ける
- 最低限持ち帰ってほしいこと:
- 「気合いと覚悟」「ピラミッドとキーワード」「楽する道を探すこと」の3点