サイトマップ
安定性だけを評価されたIT組織
多くの企業で、IT組織に対して最も強く求められてきたのは、システムを止めないこと、トラブルを起こさないこと、既存業務を安定して回し続けることでした。
第1章
安定性は「失敗しにくい指標」だった
安定性が評価軸として選ばれた最大の理由は、それが最も分かりやすく、経営にとって説明しやすい指標だったからです。障害件数、稼働率、インシデントの有無など、これらは数値化しやすく、責任の所在も明確に見えます。
その結果、IT組織は「問題を起こさないこと」を最優先に最適化されていきました。この評価軸は一見すると極めて合理的ですが、IT組織を次第に「安定性だけを最適化する存在」として固定化していきました。
99.9%
稼働率
求められる基準
0
障害件数
目標値
安定性の最適化は、変化への耐性を奪う
安定性を最優先すると、変更は最小限にする、前例のないことは避ける、標準化を徹底するという判断が合理的になります。これらは短期的には正しく、事故を防ぎます。
変更の最小化
リスクを避けるため、変更を極力抑制する
前例主義
新しい試みは避け、実績のある方法を選ぶ
標準化の徹底
例外を認めず、統一されたルールを適用

しかし同時に、変化を取り込む能力を組織から奪っていきます。
第2章
IT組織は「ブレーキ役」になった
事業側から見たIT組織は、次第に次のように映るようになります。話を持ち込むと止められる、リスクばかり指摘される、スピード感が合わない。
これは、IT組織が保守的だからではありません。安定性だけを評価される構造の中で、そう振る舞うしかなかったのです。
「また却下された...」
「リスクばかり言われる」
「スピードが遅すぎる」
再現性が設計されなかった結果
本来、IT組織は判断を構造に落とし、成功を再利用可能にし、事業拡張を支える役割を担うはずでした。しかし、再現性が設計されないまま成長が進むと、IT組織は属人的な対応を抑制する、変更を嫌う、現状維持を最優先する方向へ追い込まれます。
本来の役割
判断を構造化し、成功を再利用可能にする
設計の欠如
再現性が設計されないまま成長
現実の姿
属人化を抑制し、変更を嫌う組織へ
重要
なぜ安定性だけが残ったのか
1
2
3
4
1
安定性
2
再現性は誰も引き取らない
3
スピードは現場ITが担う
4
統合判断は存在しない
速度も再現性も設計されなかった結果、最後に残った評価軸が安定性でした。この構造の中で、IT組織は「守る役割」に閉じ込められていきます。
安定性最適化は、IT組織を孤立させる
安定性だけを評価されるIT組織は、事業側との距離を広げていきます。事業の文脈を知らない、経営の意図が共有されない、相談されなくなる。
事業との断絶
事業の文脈を知らない
情報の遮断
経営の意図が共有されない
相談の減少
相談されなくなる
その結果、IT組織は経営の武器ではなく、管理装置として扱われるようになります。
第3章
経営判断として何が起きていたのか
重要なのは、これがIT組織の意識や能力の問題ではないという点です。何を評価するかを決めたのは経営、何を最適化するかを選んだのも経営です。
IT組織は、与えられた評価関数を忠実に最適化した結果、今の姿になりました。
評価軸の設定
経営が安定性を最重要指標として設定
最適化の実行
IT組織が評価関数に従って行動
構造の固定化
安定性最優先の組織文化が定着
安定性は悪ではない
ここで誤解してはいけないのは、安定性そのものが悪だったわけではない、という点です。安定性は不可欠であり、基盤が壊れれば事業は成り立ちません。
100%
必要性
安定性は不可欠な要素
0%
他の評価軸

問題は、安定性だけを永続的に最適化対象にしたことです。
問い
次に問うべきこと
ここで問うべきは、「IT組織は保守的か」ではありません。問うべきは、経営はIT組織に何を最適化させてきたのか、それは今も妥当なのか、です。
1
過去の評価軸を振り返る
経営はIT組織に何を最適化させてきたのか
2
現在の妥当性を検証する
その評価軸は今も妥当なのか
3
未来の設計を考える
これからどう変えていくべきか
次章では、この構造を前提に、情シスはなぜ「守りのIT」に閉じ込められたのかを、より組織設計の視点から掘り下げていきます。