サービスデリバリー部門に「自分事」として動いてもらうために、EAがすべき設計とは

社内ITでEA（エンタープライズアーキテクチャ）を推進していると、必ずぶつかる壁がある。それが「サービスデリバリー部門の他人事問題」だ。

EAが横断的に課題を分析して、「ここに問題がある」「ここに注力すべきだ」と提言する。その瞬間に課題はEAに落ちてくる。現場は動かない。これはEAの能力の問題ではなく、構造の問題だ。

EAが語るほど、現場は他人事になる

EAは横断的にヒアリングを繰り返し、現場より詳しくなることがある。これは構造的に起きやすい。そしてその知識を武器に、第三者的な視点で「課題はここだ」と語り始める。

問題はここだ。

サービスデリバリー部門からすると、「上の方で勝手に話がまとまっていて、なんとなく自分たちに降りてきた」という感覚になる。当事者として課題を認識する機会がないまま、アクションだけを求められる。そうなれば「なぜやるのか」という説明をEAに求め、EAが答え、また説明が必要になる。コミュニケーションが2倍になる。スピードは半分になる。

EAの役割は「語ること」ではなく「設計すること」

ここで発想を切り替える必要がある。

EAは黒子に徹する必要はない。設計者として堂々と動くべきだ。ただし、設計の対象は「システム」だけではない。会議体そのものを設計することが、EAの重要な仕事のひとつだ。

設計者だからこそ、お膳立てをする。これは矛盾ではない。報告の場でEAが課題を語るのをやめ、サービスデリバリー部門が自分たちの言葉で現状・課題・リスクを報告する場を設計する。その場が機能するように整えることが、EAの設計者としての役割だ。

自分事化のカギは「会議体設計」にある

会議体を設計する前提として、ステークホルダーの洗い出しが必要だ。課題になる箇所がどこにあり、関係するプレーヤーが誰なのかを整理する。これはプログラム管理の一部でもある。

サービスデリバリー部門だけでなく、経営層・他部門との関係性も踏まえた上で、誰をどの場に呼ぶかを設計する。この設計の精度がそのまま自分事化の成否に直結する。

報告の場では、全体の進捗状況はEAが示す。しかし現状・課題・リスクはサービスデリバリー部門が自分たちの言葉で語る。この役割分担を明確にすることで、現場は当事者として課題を認識するようになる。マネジメント層が「なぜこうなっているのか」と問えば、現場が直接答える。EAが中間に入る必要がなくなる。コミュニケーションコストが下がり、スピードが上がる。

お膳立ての具体的な中身

「やってもらう」を目的にしてしまうと丸投げになる。「やってもらうためのお膳立てをする」がEAの正しい立ち位置だ。

お膳立てに必要なものは以下のとおりだ。

データの整理：横断的なシステム状況・課題・リスクのデータを揃える。アセット管理・システム管理が基盤として必要になる
議題の設計：何を・誰が・どの順番で報告するかを設計する
説明会の実施：報告の場に先立って目的と課題感を共有する。「自分たちがやったが伝えきれなかった」という失敗経験を正直に開示することで、役割を渡す正当性を作る
スケジュール管理：全体方針とスケジュールを整理し、現場が動きやすい環境を整える
根回し：事前に関係者と個別に話し、場の設計を機能させる

これはほぼイベント設計と同じだ。

「なぜ自分たちが報告するのか」という抵抗への対処

サービスデリバリー部門から必ず出る反応がある。「それはあなたたちがやることでしょう」というものだ。

この抵抗には二重の構造がある。ひとつはジョブディスクリプションの壁。自分の担当範囲を超えた仕事に見えてしまう。もうひとつは第三者への心理的抵抗。トップから言われるのとEAから言われるのとでは、受け取り方が違う。

この壁を崩すのは、地道な活動の積み重ねだ。

現場に課題があれば、ステークホルダーとの調整をEAが代わりに動く。現場の担当者が文書を書かなくていいように、ヒアリングをEAが引き受ける。「この人に頼めば何とかなる」という実績を一つひとつ積み上げることで、ジョブディスクリプションの壁は少しずつ溶けていく。

「困ったらまずあの人に連絡する」と名前を呼ばれるようになったとき、それがEAとして認められた証だと思っている。

自分事化が進むと、何が変わるのか

会議体設計が機能し始めると、変化は明確に現れる。

マネジメント層の問いに現場が直接答えるようになる。課題がEAに落ちてこなくなる。現場が自ら課題を認識し、次の報告までに動こうとする。EAがいなくても会議が回り始める。これが自分事化が進んだ状態だ。

「やってみる→続ける→定着」の3フェーズ

EAの取り組みには成熟度がある。数値で測れるものではなく、感覚的なフェーズだ。

やってみるフェーズ：会議体を設計し、お膳立てをしながら現場を動かし始める時期。EAの関与が最も濃く、属人化も最も強い。とにかく信頼を積み上げることに集中する
続けるフェーズ：仕組みが少しずつ回り始める。現場が「やること」を理解し、EAへの確認が減ってくる。関与のグラデーションが薄まり始める時期
定着フェーズ：担当者が変わっても会議体や仕組みが回り続ける状態。EAの関与はさらに薄まり、現場がイニシアチブを持って自走している

EAの役割はどのフェーズでも変わらない。設計し、お膳立てし、現場を支える。ただし関与の濃淡が変わる。

会議体設計によってコミュニケーションコストが下がり、現場の動くスピードは早い段階から上がる。一方で、担当者が変わっても回る定着フェーズに到達するまでには、軽く5年はかかる。データを揃えるだけで1年、プログラムを設計するだけで1年、それを運用させるのにさらに時間がかかる。

次々と要求が積み上がり、終わりなき戦いのように感じる瞬間もある。それでも続けられるのは、自分が設計したものに人が乗っている手応えと、横断的な知識が蓄積されていく面白さがあるからだ。