AI Readyなデータ基盤構築は、なぜ大企業では進みづらいのか ─現場での試行錯誤から考える、乗り越え方のヒント

多くの企業でデータマネジメントの重要性が理解されつつありますが、基盤構築からその先の利活用までを一気通貫で成功させるのは容易ではありません。私はこれまで数多くのデータ基盤プロジェクトに携わってきましたが、その中では、思うように進まなかったり道半ばで停滞してしまった事例もさまざま経験しています。本講演では、そうした実体験を基に、特に規模の大きな企業において、なぜデータマネジメントの取り組みが「AI Readyなデータ基盤」に至る前で停滞しやすいのか、その要因を整理します。併せて、現在所属するDMM.comにおいて試行錯誤を重ねながら進めてきた取り組みの一部を例に、もし今あらためて取り組むとしたら、どのような考え方・進め方を選ぶのかについてもお話しします。データ基盤の構築・刷新やデータ活用に携わる方々が、自社の状況を見つめ直し、明日から何に着手すべきかを考えるためのヒントをお持ち帰りいただければ幸いです。

Transcript

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