サイトマップ
目的関数が分裂した瞬間
成長速度を最優先したIT、再現性を設計しなかった経営判断、安定性だけを評価されたIT組織。これらが同時に成立し、引き返せなくなった瞬間を探ります。
目的関数とは何か
目的関数とは、「何を最適化するために存在しているのか」という定義です。経営においては、何を成功とみなすのか、何を犠牲にしてよいのか、どの指標を優先するのかを決める役割を果たします。
ITも本来、一つの明確な目的関数を持つべき存在でした。しかし、現実はそうではありませんでした。
成功の定義
何を成功とみなすのか
犠牲の範囲
何を犠牲にしてよいのか
優先指標
どの指標を優先するのか
分裂は一度に起きたわけではない
ITの目的関数は、ある日突然分裂したわけではありません。それぞれのフェーズで、その時点では合理的な選択がなされました。
1
成長フェーズ
速度が選ばれた時期
2
拡張フェーズ
再現性が後回しにされた時期
3
運用フェーズ
安定性だけが残った時期

問題は、フェーズが変わっても目的関数が更新されなかったことです。
同じ「IT」が別のものになった
目的関数が更新されないまま時間が経つと、ITは次のように分裂します。これらは、同じ企業の中に存在しながら、異なる最適化問題を解いている別物です。
事業IT
成長速度を最大化する
  • 新機能の迅速な実装
  • 市場投入スピード重視
  • 柔軟性と変化対応
業務IT
安定性と効率を最大化する
  • システムの安定稼働
  • 運用コスト削減
  • リスク管理徹底
統合IT
誰も主語にしない
  • 曖昧な責任範囲
  • 不明確な評価基準
  • 調整役としての存在
分裂した目的関数は、互いを破壊する
成長速度の最適化
成長速度を最適化するITは、安定性を犠牲にします。新機能の追加や変更を優先し、既存システムの保守は後回しになります。
安定性の最適化
安定性を最適化するITは、変化への対応を拒みます。リスクを避けるため、新しい取り組みに慎重になりすぎます。
1
事業側の視点
ITを足かせだと感じる
2
対立構造
再現性が設計されていないため接続できない
3
IT側の視点
事業を無謀だと感じる
経営は「選ばなかった」
重要なのは、経営が誤った目的関数を選んだことではありません。経営が行った最大の判断は、どれか一つを選ばなかったことです。
速度の優先期限
いつまで速度を優先するのか
再現性への切り替え
どの段階で再現性に切り替えるのか
安定性の主役化
安定性をどこで主役にするのか
これらを明示しないまま、すべてを同時に満たそうとしました。
分裂が固定化された理由
目的関数の分裂は、やがて組織構造に埋め込まれます。こうして、分裂は個人の意識ではなく、組織の前提条件になります。
1
2
3
1
再現性
誰も評価しない
2
IT組織
安定性を評価
3
事業部門
速度を評価
評価指標が組織ごとに異なることで、分裂は制度として固定化されました。個人の努力では変えられない構造的な問題となったのです。
なぜ統合は後からできなかったのか
分裂した目的関数は、後から統合することが極めて困難です。それぞれが、自分なりに正しく最適化してきたからです。
評価指標の違い
何を成功とするかの基準が異なる
時間軸の違い
短期と長期の視点が対立する
成功体験の違い
過去の勝ちパターンが異なる

統合には、誰かが何を捨てるのか、何を優先するのかを決める必要があります。これは、経営しか引き取れない判断です。
目的関数の分裂は、失敗ではなく警告
ここまでを見ると、目的関数の分裂は失敗のように見えるかもしれません。しかし本質的には、経営がITを主語にすべきタイミング、統合判断を下すべき段階を示す警告でした。
100%
警告の意味
分裂は経営判断を求めるシグナル
0%
対応率
それを見過ごした結果、分裂は慢性化
警告を無視することで、一時的な問題は構造的な課題へと変化しました。早期の介入があれば、統合の可能性は残されていたのです。
第II章の結論
ITの問題は、技術でも、人でも、組織でもありません。何を最適化するのかを、経営が一度も選ばなかったことです。
技術の問題ではない
システムやツールの選択は本質ではありません
人の問題でもない
個人のスキルや意識の問題ではありません
組織の問題でもない
構造や体制の問題だけではありません
経営判断の不在
目的関数を選ばなかったことが根本原因です
次章では、この分裂した目的関数が、事業推進の現場でどのように暴走していったのかを、事業レイヤーから検証していきます。