目的関数が分裂した瞬間

第II章では、成長速度を最優先したIT、再現性を設計しなかった経営判断、安定性だけで評価されたIT組織を、一つずつ見てきました。

本稿で扱うのは、それらがある時点で同時に成り立ち、もう引き返せなくなった瞬間です。言い換えれば、「ITの目的関数が分裂した瞬間」です。

目的関数とは、何のために存在するかの定義

目的関数とは、「何を最適化するために存在しているのか」という定義です。経営においては、何を成功とみなすのか、何を犠牲にしてよいのか、どの指標を優先するのかを決める役割を果たします。ITも本来は、一つの明確な目的関数を持つべき存在でした。

分裂は、一度に起きたわけではない

ITの目的関数は、ある日突然分裂したわけではありません。成長フェーズでは速度が選ばれ、拡張フェーズでは再現性が後回しにされ、運用フェーズでは安定性だけが残りました。

どれも、その時点では合理的な判断でした。問題は、フェーズが変わっても目的関数が更新されなかったことです。

同じ「IT」が、別々のものになった

目的関数が更新されないまま時間が経つと、ITは次のように分裂していきます。

• 事業IT：成長速度を最大化する。
• 業務IT：安定性と効率を最大化する。
• 統合IT：誰も主語にしない。

これらは同じ企業の中にありながら、異なる最適化問題を解いている別物です。

分裂した目的関数は、互いを壊し合う

成長速度を最適化するITは安定性を犠牲にし、安定性を最適化するITは変化への対応を拒みます。再現性が設計されていないので、両者をつなぐこともできません。

その結果、事業の側はITを足かせだと感じ、ITの側は事業を無謀だと感じる、という対立の構造が生まれます。

経営は、どれも「選ばなかった」

大事なのは、経営が誤った目的関数を選んだ、という話ではないことです。経営が下した最大の判断は、どれか一つを「選ばなかった」ことでした。

いつまで速度を優先するのか。どの段階で再現性に切り替えるのか。安定性をどこで主役にするのか。それを明示しないまま、すべてを同時に満たそうとしたのです。

分裂は、やがて組織に埋め込まれる

目的関数の分裂は、やがて組織の構造に埋め込まれます。事業部門は速度で評価され、IT組織は安定性で評価され、再現性は誰からも評価されない。こうして分裂は、個人の意識の問題ではなく、組織の前提条件になっていきます。

なぜ後から統合できなかったのか

分裂した目的関数を後から統合するのは、きわめて難しいことです。評価指標が違い、時間軸が違い、成功体験が違う。それぞれが、自分なりに正しく最適化してきたからです。

統合するには、誰かが「何を捨てるのか」「何を優先するのか」を決めなければなりません。それは、経営にしか引き取れない判断です。

分裂は失敗ではなく、警告だった

ここまで見ると、目的関数の分裂は失敗のように映るかもしれません。しかし本質的には、経営がITを主語にすべきタイミング、統合の判断を下すべき段階を知らせる警告でした。それを見過ごした結果、分裂は慢性化したのです。

ITの問題は、技術でも、人でも、組織でもありません。何を最適化するのかを、経営が一度も選ばなかったことです。これが第II章の結論です。次章では、この分裂した目的関数が事業推進の現場でどのように暴走していったのかを、事業レイヤーから検証していきます。