組織設計にEAはどこまで踏み込むべきか――サービスカテゴリーという枠組みと失敗から学んだこと

社内IT部門の組織は毎年変わる――定点観測できていますか？

突然だが、あなたの会社の社内IT部門、去年と今年で組織図は同じだろうか。おそらく違う。リソース削減、間接部門のスリム化、統括部門の統合――方向性は違えど、何かしらの組織変更が毎年起きている。これはどの事業会社でも同じだ。

問題は、組織が変わるたびに「去年との比較」ができなくなることだ。本部全体の数字はわかる。個別の細かい数字もわかる。しかしその中間――サービス単位・機能単位での経年変化――が追えなくなる。数字は出せるのに、文脈が消える。「コストは下がっているが、何をしたのかわからない」という状態が生まれる。

これはコミュニケーションの問題ではなく、構造の問題だ。そしてこの構造的問題に向き合うのが、EA（エンタープライズアーキテクチャ）の仕事だと私は考えている。

EAがやるべきことは「定点観測の枠組みを作ること」

EA観点からこの問題を見ると、解決策はシンプルだ。組織の変化に左右されない「定点観測の枠組み」を先に作ること。そしてその枠組みを組織と連動させること。

私が実践したのは、社内IT部門のサービスカテゴリーを定義するというアプローチだ。ケイパビリティマップに近い考え方だが、社内IT部門はあくまで社内向けのサービス提供部門なので、「サービス」という軸で整理する方が実態に合う。

具体的には以下のような単位で整理した。

コーポレートITサービス（人事・会計・総務系システム）
インフラ・プラットフォームサービス（データセンター・クラウド・API基盤）
ネットワーク・セキュリティサービス
アイデンティティ・コラボレーションサービス（従業員管理・メール・会議基盤）
エンドポイントサービス（PC・ハードウェア管理）
データ連携サービス

この単位で整理する理由がある。社内IT部門の組織は、実態としてすでにこのサービスレイヤーに近い形で構成されていることが多い。組織とサービスカテゴリーが対応しやすいから、浸透しやすい。

社内ITのサービスカテゴリーはどの会社でもある程度パターンが決まっている。コーポレート系・インフラ系・セキュリティ系・コラボレーション系・エンドポイント系――この大枠は業種を問わずほぼ共通だ。特定のフレームワークを1つ使う必要はない。各種資料からつまみ食いして自社の実態に合わせれば十分機能する。

サービスカテゴリーと組織を連動させると定点観測が機能する

このサービスカテゴリーを組織の単位と合わせた結果、比較的スムーズに受け入れられた。枠組みと組織が対応していると、現場の人間が「自分ごと」として捉えやすくなるからだ。

枠組みを組織と連動させることで、以下が実現した。

コスト・システム数・人員をサービス単位で集計・比較できる
組織が変わっても同じ軸で前年度と比較できる
「どのサービスに投資して、どのサービスを削るか」という議論の土台ができる

投資の合意だけ取れて、削減の責任がうやむやになるという現場あるあるも、この枠組みがあれば多少は防げる。「このサービスカテゴリーのコストを下げる」という合意に変換できるからだ。議論の粒度が揃うと、責任の所在も明確になる。

組織再編が起きると枠組みがズレる――ベクトルの違いが原因だ

ここからが失敗談だ。

枠組みと組織を連動させた結果、浸透はした。しかし組織再編が起きるたびに、枠組みとのズレが生じた。

根本的な原因はベクトルの違いだ。サービスカテゴリーによる定点観測は「過去を正確に見るための仕組み」だ。一方、組織再編は「未来に向けた意思決定」だ。この2つは本来、目的が違う。

組織を変えるとき、現場間の調整は行われる。しかしその調整の中に「サービスカテゴリーとの整合性」という視点が入ることはほぼない。結果として、気づいたらカテゴリーと組織がズレていて、また定点観測ができなくなる。

枠組み自体は機能していた。問題は、組織変更と枠組みを連動させるメカニズムが不足していたことだ。枠組みの価値と連動の課題は、切り分けて考える必要がある。

EAが組織設計に踏み込む範囲――役割分担の線引きが重要だ

ここが今回の核心だ。

結論から言う。組織の人事的な意思決定には、EAは踏み込まないほうがいい。ただし、枠組みを理解してもらうための働きかけは徹底してやる。この役割分担の線引きが重要だ。

組織再編は本質的に人事の領域だ。誰をどのポジションに置くか、どのチームを統合するか――これはトップレイヤーでしか決められない。EAがいくら正しい枠組みを持っていても、人事的な意思決定に直接介入することはほぼ不可能だし、すべきでもない。

ではEAは何をすべきか。組織再編を担う人事企画の担当者が「このサービスカテゴリーの観点も考慮して組織を設計する」という状態を作ることだ。人事の意思決定そのものには踏み込まない。しかし枠組みを理解した仲間を人事側に作ることには、全力で取り組む。

ただし現実はそう簡単ではない。人事とITの課題が連動するタイミングは構造的に遅い。システム削減が決まって、ようやく人員をどうするかという議論になる。その順番がある以上、EAが早い段階で動ける余地は限られる。だから繰り返しコミュニケーションを取り続けることが、今のところ有効な手段だ。泥臭いが、これしかない。