責任の切り方　縦（業務ドメイン）と横（全社基盤）を DX現場で使い分ける

DXエンジニア向け 責任の切り方 縦（業務ドメイン）と横（全社基盤）を DX現場で使い分ける うさうさ研修工房 ｜ Why・What・How 1

今日の流れ 1 Why 2 What 3 How なぜDXで重要か DXでの縦と横 現場での実践 主体が多い 業務ドメイン vs 全社基盤 ハブ・アンド・スポーク PoCの先で止まる 比較表 判断フロー 組織が構造を決める 失敗の型 ベンダー・PoC・RACI うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 2

DXは登場人物が多い DXプロジェクト 事業部 情シス・ DX推進 外部ベンダー 経営層 業務の課題とオーナー 基盤・ガバナンス 開発・導入支援 投資判断 主体が多いほど、境界が増え、揉めやすくなる うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 3

DXの失敗は「 PoCの先」で起きる 課題発見 PoC 本番化 運用・改善 ここで止まる 誰が本番化の責任を持つか不明 → PoC死蔵 PoCは担当が明確でも、本番化・運用では予算・保守・セキュリティ・データ など責任が一気に増える。ここで 責任の切り方が曖昧だと、プロジェクトは止まる。 うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 4

組織の切り方がシステムを決める 組織の切り方 システムの構造 似てくる 部署ごとに縦に切る サイロ化しやすい 似てくる 全社基盤を横に切る 部署ごとの SaaS・データ 共通のデータ基盤・認証 全社で統一しやすい ＝ コンウェイの法則 うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 5

縦と横： DXではこう置き換える 縦に切る ＝ 業務ドメイン 横に切る ＝ 全社基盤 事業部とITが一体で、業務単位に全層を持つ 全社共通の機能を、専門組織が持つ 営業DX 製造DX 人事DX データ基盤 営業・製造・人事の全データ 業務課題 業務課題 業務課題 SaaS・アプリ SaaS・アプリ SaaS・アプリ データ データ データ 認証・セキュリティ 営業・製造・人事の全権限 AI基盤 運用・改善 運用・改善 運用・改善 営業・製造・人事の全AI ※ 「縦」「横」の呼び方は現場で逆になることがある。最初に定義をそろえる うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 6

メリット・デメリット比較 観点 縦（業務ドメイン） 横（全社基盤） 現場との距離 ◎ 現場課題に直結 △ 現場とずれやすい スピード ◎ 意思決定が速い △ 依頼待ちの列ができる データの統一 △ 部署ごとに分断（サイロ化） ◎ 全社で統一しやすい セキュリティ・ガバナンス △ バラつく／シャドー IT ◎ 基準を統一しやすい コスト △ SaaSや仕組みが重複 ◎ 共通化で重複を減らせる 本番化・運用 △ 運用の専門性が不足 ◎ 運用・保守の専門性が高い 責任の所在 ◎ 業務の最終責任が明確 △ 「誰の業務か」が曖昧 ◎ 強い △ 弱い うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 7

起きやすい失敗の型 縦の失敗：サイロ化・乱立 営業部 契約 SaaS-A 製造部 契約 SaaS-B 横の失敗：現場とのずれ・依頼待ち 人事部 契約 SaaS-C 現場「すぐ試したい」 情シス：依頼の列に並ぶ データが分断 優先順位・要件のずれ 契約・権限・セキュリティがバラバラ 現場がシャドー ITに走る 例：SaaSの重複契約／シャドー IT うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 8

実践解：ハブ・アンド・スポーク 横：DX推進・全社基盤（ハブ） データ基盤 基準と支援を持つ（ CoE） 認証・セキュリティ AI基盤 共通基盤・基準・支援を提供 縦：業務ドメイン（スポーク） 営業DX うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 SaaS管理・基準 現場の要望・課題を伝える 結果責任（KPI・日々の改善）を持つ 製造DX 人事DX 9

判断フロー：縦か、横か いいえ 業務固有の知識が必要か？ はい 縦：業務ドメインが持つ 全社で統一しないとリスクが あるか？ （安全性・個人情報） いいえ はい 横：全社基盤が持つ いいえ 他部署も使い回せるか？ 縦：業務ドメインが 持つ はい 横：共通部品として提供 順番は「業務固有の知識」 →「全社統一のリスク」 →「使い回せるか」 うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 10

ベンダーとの責任の切り方 発注側が持つ ベンダーが持つ 事業部・DX推進 契約範囲 1. 課題の定義・優先順位 1. 合意した範囲の開発・導入 2. 要件の最終決定 2. 技術的な提案 3. 運用・改善の責任 3. 契約範囲の品質 契約形態で責任の持ち方が変わる 請負 成果物の完成に責任を持つ。要件が固まらな い初期は変更で揉めやすい 準委任 作業の遂行に責任を持つ。成果の責任は発注 側に残る 「ベンダーに任せれば責任も移る」は誤解 何をどこまで任せるかを、契約とRACIの両方で明文化する うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 11

PoCから本番化へ： 4つの条件 はい PoC開始時：本番化の責任者を 決める PoC実施 本番化へ 本番化の判断基準を満たし たか？ いいえ 中止／再設計 PoC開始前に決める 4つの条件 1 2 3 4 判断基準 責任者 運用担当 予算 何ができたら本番か 誰が最終判断するか 誰が保守するか どの部署が出すか うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 12

RACI：DXプロジェクトの例 業務 事業部 DX推進（横） ベンダー 経営層 課題の定義・優先順位 A/R C C I 要件の最終決定 A/R C C I 開発・導入 C C A/R I データ基盤・権限の設計 C A/R C I セキュリティ審査 I A/R C I 本番化の最終判断 R C C A 運用・改善 A/R C C I R 実行する人 A 最終責任を持つ人（ 1業務につき1人） うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 C 相談を受ける人 I 報告を受ける人 13

境界を設計する 3ステップ 1 2 3 RACIで責任を表にする 境界業務に担当者を置く エスカレーション先を決める 業務ごとにR・A・C・Iを割り当てる。 Aは 1業務につき1人 本番化の判断・ SaaS管理者・データ管 理責任者は、組織名でなく個人名で決 める 1つに決める。責任が曖昧な問題は、 事前に決めた先（例： DX推進責任者） へ エスカレーションの流れ 問題が発生 RACIで担当は決まって いる？ うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 未定なら：エスカレー ション先で担当を決定 担当者が対応 RACIを更新して次回に 備える 14

DXエンジニアの立ち回り 状況 起きやすいこと DXエンジニアの動き方 縦（事業部）側に入った 運用や基盤の専門性が足りない 全社基盤・CoEに早めに相談し、共通部品を使う 横（全社基盤）側に入った 現場の課題が見えない 事業部と定例を持ち、現場の言葉で要望を聞く ベンダーと進める 責任の線引きが曖昧になる 契約範囲とRACIを突き合わせ、不明点を先に確認 PoCを担当した 本番化されずに終わる PoC開始時に本番化の4条件を確認する うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 15

現場で確認する 4つの質問 1 このデータのオーナーは誰か 2 このSaaSの管理者は誰か 3 PoCの先の本番化の責任者は誰か 4 ベンダーと自分たちの責任の境界は どこか 4つに即答できるチームは整理されている。答えが返ってこなければ、そこが揉め事と PoC死蔵の火種 うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 16

まとめ 1 縦（業務ドメイン） 2 横（全社基盤） 3 実践解 4 ベンダー 5 PoC 現場に近くスピードが出る。失敗はサイロ化・乱立 統一とガバナンスが強み。失敗は現場とのずれ・依頼待ち 縦で結果責任、横で基準・基盤（ハブ・アンド・スポーク） 任せても、課題定義・要件の最終決定・運用の責任は発注側に残る 開始時に、判断基準・責任者・運用担当・予算を決める デザインは感性ではなく設計。 DXの責任の切り方も、気合や空気ではなく設計で決める。 うさうさ研修工房 ｜ DXエンジニア向け 責任の切り方 17