---
title: 責任の切り方　縦（業務ドメイン）と横（全社基盤）を DX現場で使い分ける
tags:  #マネジメント向け  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L71Y65QKJG.jpg?width=480
description: 責任の切り方　縦（業務ドメイン）と横（全社基盤）を DX現場で使い分ける by Yukiko
published: October 13, 26
canonical: https://image.docswell.com/s/yukiko_it/Z4NWDG-2026-10-13-051611
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L71Y65QKJG.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G7WGW5MPE2.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JZL5NQ6E3.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE6W986LEV.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE5MN96ME4.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/972952MRJR.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DJY4KYX57M.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7NYRP14E8.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YJ9PM35473.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJ8DLMYVJD.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJLML34RER.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/47MYMDKP7W.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7R9V4XYE9.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PJXQZ2647X.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/3JK98M1PJD.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LE3W2YQ4E5.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/8EDKZ5957G.jpg)

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