IT分断は誰の失敗なのか

IT分断は誰の失敗なのか
IT分断という言葉が使われるとき、その原因はしばしば「現場がバラバラにツールを入れたから」「情シスが守りに入ったから」「ベンダーに任せすぎたから」と語られます。しかし、これらはいずれも結果として現れている現象に過ぎません。
本稿では、IT分断は誰の失敗なのかという問いを、責任転嫁や犯人探しではなく、経営判断の構造として整理します。
分断は「意図せず起きた事故」ではない
まず確認すべきことは、IT分断は偶然起きた事故ではない、という点です。事業ごとに最適なITを選び、部門ごとに合理的な判断をし、その時点では正しい選択をした結果として、ITは分断されました。
つまり分断は、誰かが間違ったから起きたのではなく、誰も全体を引き取らなかったから起きたのです。これは構造的な問題であり、個人の失敗ではありません。
事業最適
各事業に最適なITを選択
部門判断
合理的な個別判断
正しい選択
その時点での最適解
現場は「最適解」を選び続けた
現場は、目の前の業務を回す、売上を落とさない、顧客対応を止めないという制約の中で判断します。その結果、早く導入できるツール、今すぐ使える仕組み、個別最適な解決策を選ぶのは、極めて合理的な行動でした。
01
業務継続の優先
目の前の業務を止めないことが最優先
02
迅速な導入
早く導入できるツールを選択
03
個別最適化
部門ごとの最適な解決策を実装
現場は、分断を生みたくて生んだわけではありません。与えられた制約の中で、最も合理的な判断を積み重ねた結果なのです。
情シスは「守るべきもの」を守った
情シスは、障害を起こさない、情報を守る、コストを抑えるという期待のもとで評価されてきました。この評価軸の中では、全社最適の設計や事業スピードへの介入に踏み込むインセンティブは生まれません。
情シスもまた、与えられた役割を忠実に果たした結果として、分断構造の一部になりました。
障害防止
システムの安定稼働を最優先
情報保護
セキュリティとコンプライアンス
コスト管理
予算内での運用維持
ベンダーは「求められた仕事」をした
ベンダーは、要求された仕様を満たす、契約範囲で責任を果たす、プロジェクトを完遂することを役割としています。全社視点での統合や、長期的な経営構造までを引き取る立場にはありません。
1
仕様の実現
要求された機能を正確に実装
2
契約の遂行
契約範囲内での責任を完遂
3
プロジェクト完了
期限内での納品を実現
ベンダー依存が問題になるのは、本来経営が担うべき判断まで委ねたときです。ベンダーは与えられた役割を果たしただけであり、全体統合の責任を負う立場ではありません。
では、誰が失敗したのか
ここまでを整理すると、現場は合理的だった、情シスも役割を果たしていた、ベンダーも契約通り動いていた。それでも分断が起きたとすれば、原因は一つしかありません。
分断を統合する主体が存在しなかった
現場
合理的な個別判断を実行
情シス
与えられた役割を遂行
ベンダー
契約通りの仕事を完遂
統合主体
全体を引き取る存在が不在
統合されなかった理由は「経営判断」にある
ITを全体として統合するためには、どのITを残すのか、どこを標準化するのか、何を捨てるのかという、不可逆性を伴う判断が必要です。これらは、現場・情シス・ベンダーが単独で引き取れる判断ではありません。
選択の判断
どのITを残し、どれを廃止するか
標準化の範囲
どこまでを統一し、どこを個別化するか
取捨選択
何を捨て、何に投資するか
本来、経営だけが引き取れる判断です。これらの判断には、事業全体への影響、長期的な投資判断、組織横断的な調整が必要となります。
IT分断の失敗は「経営の不作為」
1
ITを定義しなかった
全社的なIT戦略の不在
2
判断を先送りした
統合の意思決定を回避
3
統合領域を主語にしなかった
全体最適の責任を取らず
重要なのは、これを「経営者個人の能力不足」と短絡的に結論づけないことです。IT分断は、ITを定義しなかった、判断を先送りした、統合領域を主語にしなかったという、経営構造としての不作為の結果です。
誰か一人の失敗ではなく、経営という意思決定システムが引き取らなかった領域が、分断として可視化されたのです。
責任を問うとは、構造を引き取ること
ここで言う「経営の失敗」とは、誰かを責めることではありません。どの判断が行われなかったのか、なぜ行われなかったのか、これから誰が引き取るのかを明確にすることです。
判断の可視化
どの判断が行われなかったのかを特定する
原因の理解
なぜその判断が行われなかったのかを分析する
責任の明確化
これから誰が引き取るのかを決定する
それができて初めて、IT分断は「過去の失敗」ではなく、再設計可能な課題になります。構造を理解し、責任を引き取ることで、初めて前に進むことができるのです。
第I章の結論
現場の暴走ではない
合理的な判断の積み重ね
情シスの怠慢ではない
役割を忠実に遂行した結果
ベンダー依存の問題ではない
契約通りの仕事を完遂
IT分断は、経営が定義せず、決めず、引き取らなかった結果です。
次章では、この結論を前提に、経営が定義しなかった「ITの目的関数」へと進み、これから何を引き取るべきかを具体化していきます。分断の構造を理解した今、再設計への道筋が見えてきます。