分担表が埋めていないもの——「誰が決めるか」を問わないとDXは止まる

導入の終盤になると、ベンダーから役割分担表が届く。縦に業務が並び、自社とベンダーの列に◎と○が入っている。よく整理された表で、誰が手を動かすかは一目でわかる。

ただ、その表で答えられない問いがある。「仕様が割れたとき、誰が決めるか」だ。プロジェクトが止まるのは、たいていそこだ。作業者が足りないのではなく、確認を受け止める人がいない。

分担表が映さないもの

◎と○という記号は、業務の実行責任を示すには向いている。しかし「この仕様はAかBか」という問いを、誰が判断して終わりにするかは、記号では表せない。

その構造を整理しようとする道具が、RACIチャートだ。R（Responsible＝実行する人）、A（Accountable＝決める人）、C（Consulted＝意見を聞く人）、I（Informed＝知らせる人）の4つに役割を分ける。このうちAは、1人に絞ることが原則とされている。

上流の会議にシステムの席はあるかでも書いたように、意思決定の構造は導入の早い段階で設計しておく必要がある。しかし実際には、RACIのAが埋まらないケースは珍しくない。

「A」が埋まらない理由

RACIのAが1人に絞れないとき、現場では「どう書けばいいのか」という議論になりがちだ。しかし埋まらない理由は、記入の難しさにあるのではない。

組織の中に、その業務の決定権を持つ人が置かれていない。それが表に現れているだけだ。

分担表を埋めることと、意思決定の仕組みを整えることは、別の作業だ。

RACIチャートの意義は、このような空白を「仕方ない」で流さず、議論の俎上に乗せることにある。失敗は流通しないという記事で書いたように、上流で起きた判断の空白は下流には届きにくい。RACIが機能しない現場では、その空白が静かに積み重なっていく。

誰がAを担うのかを決める前に、社内でその権限を持てる人物がどこにいるかを先に確認する必要がある。それはシステムの話ではなく、組織の話だ。

稼働後に効いてくる3つの盲点

分担表の問題はAの欄だけではない。導入フェーズで話題にならないまま、稼働後に毎日誰かの時間を使う業務がある。

• マスタ整備：品番、取引先、拠点情報などの基礎データは、システムが動き続けるかぎり更新が必要だ。分担表の1行だが、週単位の定常業務になる。
• データ移行：旧システムから新システムへのデータ引き継ぎは、一度の作業ではない。整合性の確認と修正が繰り返され、担当者が決まらないまま進む現場は多い。
• 障害の一次受け：稼働直後に不具合の第一報を受ける役割。ベンダーの窓口とは別に、社内側でも受け止める人が必要だ。導入前には名前が挙がらないことが多い。

これらは表の上で1行に収まる。しかし動き出すと、名前のない仕事として誰かに吸収され続ける。

稼働前に「週何時間、誰が担うか」を具体的に想定しておくことが、運用崩壊を防ぐ第一歩になる。DXの伴走支援しぼるでは、こうした運用設計の段階から関わることで、稼働後の負荷を事前に可視化する支援をしている。

---

DXが止まる理由を「人が足りない」で片付けると、追加された人が同じ場所で詰まる。問うべきは、その業務の決定権を持つ人が、組織のどこかに置かれているかどうかだ。