IT組織をどう設計すべきか
IT組織の議論では、情シスの強化やDX部門の創設が話題になります。しかし、これらの問いは出発点として誤っています。本稿では、組織図や人数の話から離れ、経営が引き取るべき判断構造の設計という観点から整理します。
機能から設計してはいけない理由
従来の設計アプローチ
多くの企業では、IT組織をインフラ、アプリケーション、セキュリティ、データといった機能分解から設計します。
なぜ行き詰まるのか
IT組織の役割は機能ではなく「判断」を担うことです。機能から設計すると、部門間の境界が固定化し、調整コストが増え、全体最適が失われます。
設計の起点は「判断の種類」
IT組織を設計する際、最初に問うべきは「この会社には、どんな種類の判断が存在するのか」です。
事業を変える判断
スピードと柔軟性が求められる領域です。
日々の運用を回す判断
安定性と再現性が最優先される領域です。
将来構造を決める判断
長期的な視点と全体最適が必要な領域です。
これらは要求が異なるため、異なる判断を同じ組織で担わせること自体が無理なのです。
目的関数で組織を分ける
IT組織を分けるべき軸は技術領域ではなく、「何を最適化するための組織か」です。典型的には3つに分かれます。
1
安定性を最適化する組織
基幹システム、インフラ、セキュリティを担当します。目的関数は「止めないこと」であり、評価軸は明確です。
2
成長速度を最適化する組織
事業IT、プロダクト開発、データ活用を担います。ここでは「速く試し、速く学ぶこと」が価値になります。
3
再現性を最適化する組織
業務構造設計、判断基準の固定化、全体設計を担当します。経営の意思決定を構造に落とす役割を果たします。
日本企業で最も欠けていた組織
存在してきた組織
- 安定性の組織(情シス)
- 成長速度の組織(事業IT)
欠けていた組織
再現性を最適化する組織は、ほぼ存在してきませんでした。
その役割を誰も担わなかった結果、全体最適が不在になり、情シスは守りに閉じ込められ、事業ITは暴走しました。
経営が引き取るべき判断
IT組織を設計する上で、経営が引き取るべき判断は明確です。
1
どの判断を中央に集めるか
全社的な視点が必要な判断を特定します。
2
どの判断を現場に委ねるか
スピードと柔軟性が求められる判断を明確にします。
3
その境界をどこに引くか
中央と現場の責任範囲を定義します。
これを決めずに、組織図を変え、名前を変え、人を入れ替えることは意味を持ちません。
「情シスを強くする」は答えではない
よくある処方箋として、情シスを強化し権限を持たせるという議論があります。
しかし、役割が定義されていないまま権限を渡しても、混乱が増えるだけです。重要なのは、どの目的関数を担う組織なのかを明確にすることです。
判断構造を組織に写す
IT組織設計の答えは、経営の判断構造をそのまま組織に写すことです。
成長を優先する判断
市場機会を捉え、事業を拡大する領域
安定を守る判断
既存の価値を維持し、リスクを管理する領域
再現性を作る判断
仕組みを設計し、全体最適を実現する領域
これらを混ぜてはいけません。それぞれ異なる目的関数を持つからです。
IT組織の本質
IT組織とは、経営の意思決定を分業するための構造である。
この前提に立てたとき、情シス、事業IT、DX組織といった名称は本質ではなくなります。重要なのは、誰が、どの判断を担うのかです。
責任は常に経営にある
IT組織設計において最も重要なことは、判断の構造を明確にすることです。
01
判断の種類を特定する
会社に存在する判断を洗い出します
02
目的関数を定義する
各判断が何を最適化するかを明確にします
03
組織構造に落とし込む
判断構造を組織設計に反映させます
04
責任範囲を明確化する
誰が何を決めるのかを定義します
それを決める責任は、常に経営にあります。技術の話ではなく、経営の意思決定の話なのです。