AI Readyなデータ基盤構築はなぜ大企業では進みづらいのか

Transcript

1. AI Readyなデータ基盤構築は、 なぜ⼤企業では進みづらいのか 現場での試⾏錯誤から考える、乗り越え⽅のヒント 2026.03.11 合同会社DMM.com ⾼橋 慶 データマネジメント2026 AI Ready Dataに舵を切れ
2. 何億円、何年もかけて 全社データ基盤を構築してきたが… 正直、思ったように データ利活⽤できていないな って思う⽅、いませんか？
3. 本セッションの主な対象者 このような課題感を持つ⽅々へ向けた内容です 経営責任者 AI推進の号令を出したが、 成果がでず悩んでいる⽅。 プロジェクト責任者 データ基盤関連PJの停滞に 頭を抱えている⽅。 推進担当者 組織の壁に阻まれ、⾝動き が取れず悩んでいる⽅。
4. セッションを通してお伝えしたいもの これまでの知⾒を抽出してアクションプランまでご提案 停滞要因の⾔語化 なぜ停滞するのか。その主な要因 を整理して解き明かす。 停滞要因への具体策 AI Readyなデータ基盤へ導く3本 の⽮とDMMでの実践事例 明⽇からのアクション 現場と経営を巻き込み、少しずつ 始める3つの具体アクション。 業界で広く⾒られる課題を分かりやすく脚⾊しています 特定の企業、団体、個⼈を指すものではありません ▪ ▪
5. スピーカー紹介 エンタープライズ企業（製造業 → 情報通信業）の現場経験10年強 ⾼橋 慶（@takaha4k） 合同会社DMM.com 開発統括本部 データ基盤開発部 前職： 製造業（2014 〜 2024） ソフトウェアエンジニア（コードよりパワポを書いていた） 現職： DMM.com (2024 〜 現在) マネージャー（コードよりプロンプト書いている） ▪ ▪
6. なぜデータ基盤は作るのが難しく、 作っても使われないのか 失敗の原因は技術やツールではなく⼈（役割）とプロセス（意思決定）にある 密室で決まる意思決定と放置される⼈材 ベンダー依存と契約の壁 判断できないデータセキュリティ 誰も⽬的を問い直さない定例会 ▪ ▪ ▪ ▪
7. ⽴ちはだかる壁① 密室で決まる意思決定と放置される⼈材 外部のベンダーに丸投げし、優秀な⼈材の成⻑と推進⼒を奪う 杜撰な技術‧ベンダー選定プロセス 社内⼈材が活かされていない 上層部でベンダーと技術‧サービスなどが決まり、 背景なく現場に降りてくる。 判断軸が短期（コストや契約のしやすさ）に偏り、 ⻑期視点（システムライフサイクル）が抜ける。 期限内PJ完遂が求められ、基盤が使われることよ り、終わらせることを優先する。 社内に優秀なエンジニアがいるのに、ベンダー管理 と調整業務に忙殺され、開発に注⼒できない。 レガシーな開発⼿法(ウォーターフォール開発、ドキュメ ントがExcel⽅眼紙、⼈⼒テスト、デプロイ職⼈芸など)がま かり通って、技術的なレビューやディスカッション もろくにできず、社内に技術知⾒がたまらない。 ▪ ▪ ▪ ▪ ▪ ベンダーは⾃社利益のため、使われることより、 スコープと責務を守る⽅向で最適化する。 ▪ 忙殺されている間に、他社のエンジニアは技術⼒を ⾼めているのかと思うと、⼼が折れてくる。 ▪
8. ⽴ちはだかる壁② ベンダー依存と契約の壁 握られているのはシステムではなく、判断する⼒ 連携元システムの聖域化 強要されるウォーターフォール 特定のベンダーに既存システムを握られている。 何かデータベースシステムに変更を加えようとす ると、既存への影響を盾にされる。 ブラックボックス化し、社内エンジニアが⼿を出 せない。 ちょっとしたデータ連携にも⼀括請負契約のウォー ターフォール開発を要求される。 ⼩さく試すアジャイルな開発プロセスが許されない。 主導権を奪われ、初⼿から多額コストが確定する。 出てくる設計品質が低い。（固定⼩数点を使うべき箇 所に浮動⼩数点で提案が来て、それを指摘しても強いこ だわりで押し通そうしてくるなど） ▪ ▪ ▪ ▪ ▪ ▪ ▪
9. ⽴ちはだかる壁③ 判断できないデータセキュリティ 誰も判断できない状態が、停滞をつくる クラウドへの過剰反応 決められない空気 連携が進まない 最⼤安全に倒れてコストが膨らむ クラウドに出す＝危険という漠然とした不安が先 ⾏し、リスク評価の前に議論が⽌まる。 責任者や判断基準が決まらず部署間で責任の押し 付け合いが起きる。合意形成が無限ループする。 セキュリティ要件が決められない。ちょっとした 現場データ連携すら前に進まない。 決められないから、最⼤安全に倒す。その結果、 データセキュリティ関連の⾒積もりがどんどん膨 らんでいく。 ▪ ▪ ▪ ▪
10. ⽴ちはだかる壁④ 誰も⽬的を問い直さない定例会 ⽬的が消えた瞬間、データ基盤の価値追求ではなく責任追及ゲームに変わる 不⽑すぎる会議 投下費⽤に引きずられるサンクコストの罠 会議ゴールが設定されず、進捗課題確認で終わる。 カメラオフミュートの参加者が散⾒される。 発注側は納期‧コスト管理に寄り、枝葉の指摘や 細部の確認に偏る。ベンダーは萎縮して、波⾵を ⽴てない報告に最適化していく。 誰も良いデータ基盤にするための問いを⽴てない。 ここまでプロジェクトに多⼤な時間とお⾦を投資 したから⽌められない。という空気が⽣まれ、 データ基盤プロジェクトの軌道修正ができない。 軌道修正できず、⼈による運⽤でカバーという免罪 符のもとで⼤量の負債（役⽴たない機能や重たい利 ⽤プロセスなど）が積み上がる。基盤は便利ではな く基盤は関所になり、現場は使わなくなる。 ▪ ▪ ▪ ▪ ▪ ▪
11. ⼼が折れる優秀な⼈材。 ベンダーの制約。セキュリティの障壁。 不⽑な会議。サンクコストの罠。 ⸺ 結果、プロジェクトが停滞する ここから、どう変えるか。
12. まずは意思決定 Readyなデータ基盤 ⼈が⾒てすぐ判断できる状態。 その後、AI Readyなデータ基盤へ AIが⾃律的にデータを探し、選び、使える状態 AI Readyなデータ基盤とは？ ⽬指すデータ基盤を定義する。⼈が判断できないデータは、AIにも使えない 集約: ⼀箇所に集まり、すぐアクセスできる 鮮度: タイムリーに判断できる 意味: 部⾨コードAが事業部Aだと分かる 責任: データ管理者が分かる Discoverable（⾒つけられる）: データカタログ と利⽤実績でAIが正しいデータを選べる Trustable（信頼できる）: データ来歴‧品質が追 え、異常やハルシネーションに気づける Actionable（実⾏できる）: AIがデータを取得 し、分析‧判断まで⾃律実⾏できる
13. AI Readyなデータ基盤へのアプローチ ゴールを決めたら、進め⽅の前提を揃える 旧来の⼤企業アプローチ 新たなアプローチ 数年以上かけて⼀括納品。 判断は最初と最後に集中し、決めた⼈と使 う⼈が分離する。 変更に弱く、リリース時には陳腐化。 誰も当事者として利⽤を推し進めない。 ⼩さく作って検証し、１〜２週間で 要求変化に追従する。 判断の頻度を上げ、決める⼈と作る⼈を 近づけ、当事者意識を持たせる。 ⾃律した推進チームをつくり、横串で 束ねる体制へ。 ▪ ▪ ▪ ▪ ▪ ▪
14. 3本の⽮ ゴールと進め⽅が揃っても、推進するチームがいなければ進まない。 第⼀の⽮ 現場起点 （ボトムアップ） 現場の痛みを起点に、⼩さな成功を 積み上げる推進チーム。 第⼆の⽮ 経営起点 （トップダウン） ビジネス成果へ直結させ、会社とし てやる⼤義を確⽴する推進チーム。 第三の⽮ 横串の統制 （ガバナンス） DWH‧BI‧メタデータを統制し、 視座‧視野‧視点を引き上げる。
15. 第⼀の⽮ 現場起点 ⸺ 現場の困りごとから始める データ統合しました、では現場は動かない。 現場の困りごとを特定し、 少ない労⼒で⼤きな効果がでる形で届ける ⼩さく早く、⽬に⾒える成果を出す。 例: Excelバケツリレーを終わらせる 例: 最初の数週間で、現場が毎⽇⾒るダッシュ ボードを1つ届ける ▪
16. 現場起点が回すデータサイクル 現場が価値を実感すると、データは⾃然と集まり始める。 ⾃分たちのデータを出せば、 もっといいものが返ってくるという実感 成功体験が次のデータ提供を呼ぶ ダッシュボードで業務が楽になった現場は、次は⾃分からデータを出してくれる。 データ活⽤を通じてメタデータが⾃然と育つ 現場が使う過程で、この項⽬のデータやこの計算式はこういう意味だという業務知識が明確になる。 これが意思決定Readyの⼟台になる。 意思決定ReadyからAI Readyへ ⼈が意味を理解できるデータが揃えば、AIが読み取れる状態へ。 ▪ ▪ ▪
17. 3本の⽮ ゴールと進め⽅が揃っても、推進するチームがいなければ進まない。 第⼀の⽮ 現場起点 （ボトムアップ） 現場の痛みを起点に、⼩さな成功を 積み上げる推進チーム。 第⼆の⽮ 経営起点 （トップダウン） ビジネス成果へ直結させ、会社とし てやる⼤義を確⽴する推進チーム。 第三の⽮ 横串の統制 （ガバナンス） DWH‧BI‧メタデータを統制し、 視座‧視野‧視点を引き上げる。
18. 第⼆の⽮ 経営起点 ⸺トップの号令を適切な⽬的に翻訳する 現場起点だけでは、組織の壁を越えられない。経営が⽬的を定めて初めて全社が動く。 DXしろ‧AIで何とかしろ ―― そのまま受けると 終わりが⾒えないIT投資になる。 曖昧な号令を適切なビジネスKPIに翻訳する （例: 物流リードタイムを〜、在庫回転率を〜） ビジネスKPIを上げるために必要なデータ要件 と優先順位をトップダウンで合意する。 ▪ ▪ ▪
19. 経営起点がもたらす3つの後ろ盾 経営層と⽬的を握ると、推進チームに後ろ盾ができる。 強⼒な⼤義名分 予算の根拠が⽴つ ビジネスKPIに紐づいた投資になるため、短期のコストカッ トに振り回されなくなる。 部⾨横断の調整⼒が⽣まれる 会社としてやる理由があるからこそ、他部署にデータ提供を 依頼するときに⼤義が通る。 推進チームの成果が⾒える KPIが改善すれば、それがそのままチームの評価になる。 ▪ ▪ ▪
20. 3本の⽮ ゴールと進め⽅が揃っても、推進するチームがいなければ進まない。 第⼀の⽮ 現場起点 （ボトムアップ） 現場の痛みを起点に、⼩さな成功を 積み上げる推進チーム。 第⼆の⽮ 経営起点 （トップダウン） ビジネス成果へ直結させ、会社とし てやる⼤義を確⽴する推進チーム。 第三の⽮ 横串の統制 （ガバナンス） DWH‧BI‧メタデータを統制し、 視座‧視野‧視点を引き上げる。
21. 第三の⽮ 横串の統制 ⸺ 技術‧ツールの増殖を⽌めるガバナンス 現場起点と経営起点、2本の⽮だけでは部署ごとにバラバラに進む。全体を⾒る⽬が要る。 横断組織の使命と役割 採⽤技術‧連携⽅式‧品質基準の最終判断 技術やツール増殖を⽌める統治統制 メタデータ‧命名規約の全社統⼀ チームの視点‧視野‧視座の引き上げ 個別最適を全体最適へ昇華 タスクの具体例 技術標準とルールを確⽴する 全社のDWH‧BI‧運⽤ルールなどを決める データカタログを整備する テーブル定義‧責任者を⼀覧化し全PJに適⽤ レビュープロセスで暴⾛を⽌める 外れたら理由を問い、例外の増殖を防ぐ
22. 横断チームの責務 すべてのチームの視点‧視野‧視座をあげていく 視点（鋭さ） 誰も決められない議論を前に 進める切り⼝を出す。 例: データの機密レベル分け 視野（広さ） 部署を越えた全体のつながりを ⾒渡す。 例: ベンダーからの脱出ルート設計 視座（⾼さ） なぜやるかを守り、経営と現場 を繋ぐ。 例: ⼤義名分なき推進を⽌める
23. 固定観念の壁を壊すデータの機密レベル分け 第三の⽮の実践（視点） 全部最⾼機密という固定観念を決められる状態に変える よくある課題 ⼯場のデータはすべて機密で、外部ネット ワーク絶対不可という⼀律の縛り。 判断基準も、誰が判断するのか決まってい ないから、全部ダメに倒れる。 アプローチ案 データを機密性でレベル分けする （⼯場操業に影響するデータはLv4など） レベルごとにアクセス制御‧連携⽅式を変える。 （閉域網に限定し、暗号化とログ全件記録を必須など） データセキュリティ判断の責任者を決める （データオーナーが判定→セキュリティ部が承認） ▪ ▪ ▪ ▪ ▪
24. ベンダー依存からの脱出ルートを作る 第三の⽮の実践（視野） 既存システムを変えずに、読み取り専⽤のルートを確保する よくある課題 連携元システムが特定のベンダーに握られ、単 純なデータ抽出ですら⼀括請負ウォーター フォールを強要される。 しかも、請負契約後からリリースまで、少なく とも数ヶ⽉はかかる。 納品後、保守契約のSLA‧SLOが曖昧で、データ 障害が発⽣した際に揉める。 アプローチ案 全⾯改修はしない。既存にほぼ⼿を⼊れず、読み 取り専⽤の出⼝を1つ確保する。 バックアップをもらって復元、リードレプリカ、 標準機能（APIや定期ファイル出⼒）など、新規開 発なしに使える出⼝を探す。 データ抽出から先の検証や開発が、⾯倒な契約変 更なしに⾃社の判断で動かせるようにする。 ▪ ▪ ▪ ▪ ▪ ▪
25. ⼤義名分なき推進を⽌める 第三の⽮の実践（視座） なぜやるかを全員が⾔える状態を作る よくある課題 なぜやるかを誰も答えられないまま⾛っている。 定例が進捗報告だけで、⽬的への問いが出ない。 投じた時間と費⽤を理由に⽌めることができず、 負債（不要な機能など）が積み上がる。 アプローチ案 起案時に、どの経営KPIに効くか、現場の誰の困り ごとを解くかを明記して、全員が⾒えるように。 ⽉次で⽬的を問い直す場を定例に組み込み、 進捗報告を意思決定の場に変える。 ⽬的が消えたPJは縮⼩か凍結を判断する。 投じた費⽤で続ける選択肢を排除する。 ▪ ▪ ▪ ▪ ▪ ▪
27. DMMのデータ基盤プロジェクトが成功したポイント 経営判断と横断組織の体制が成功に導いた 経営起点 EXNOA（DMM GAMES運営会社）の先⾏実績を根拠に、全社DWHとBIのGoogle Cloud統⼀を経営判断。 別の部署（データ活⽤推進部）が経営KPIの翻訳と事業部間の調整を担い、経営起点の推進⼒を確保。 現場への信頼 無意味な進捗報告を排除し、エンジニアが設計と実装に最⼤集中できる体制を確保。 横串 我々（データ基盤開発部）がオーナーシップを持ち、基盤設計‧データ移⾏‧運⽤を⼀貫して推進。 ▪ ▪ ▪
28. 任せた結果、現場で何が起きたか 信頼された現場が、⾃分たちの⼒で壁を越え続けた ネットワーク設計からデータパイプライン構築、データ移⾏まで⾃⾛で完遂 オンプレ‧クラウド間の専⽤線接続、各事業部DBとのデータパイプラインを設計‧構築‧運⽤。 未経験の技術領域もプロジェクト進⾏中に習得。 他事業部が建設的に協⼒ データ基盤との連携のために必要な事業DBシステム側の調整（インデックス付与やレプリカ作成、ト ンネリングなど）を各事業部が建設的に協⼒してくれた。 ▪ ▪
29. 重要なのは「⼈（役割）」と「プロセス」 情報の透明性 あらゆる事業のビジネスKPI（ダッシュボード）をいつでも⾒れる状態にした。 会⻑の⻲⼭が数字に厳しいからこそ、データ基盤が形骸化せず、価値が証明され続けた。 経営と現場の信頼関係 経営が⽅向を決め、現場に任せ、現場が経営に応える。この循環がDMMでは機能した。
30. 本⽇の3⾏まとめ ⼤義名分なき丸投げの連鎖と当事者意識の⽋如が停滞の要因である。 現場と経営の2軸推進と、横串のガバナンスで停滞を打破する。 トップが現場を信頼し、チームに⼤きな裁量を与えること。 ▪ ▪ ▪
31. 明⽇から始める3つのアクション 現場の困りごとを1つ拾ってなんとかする 現場で⼀番の困り事を特定する。Excel転記、⼈⼒のデータ突合など。それを解決する計画を出す。 経営層にアイデアを持ち込んでディスカッションする 今⽇の話を踏まえ、AI Readyなデータ基盤構築に向けた企画書を経営層に持っていく。 不⽑な会議をやめる 参加者と会議のあり⽅を⾒直す。その会議は誰のために、何を決めるためにやっているのか。 ▪ ▪ ▪