目的関数が分裂した瞬間

はじめに

第II章では、成長速度を最優先したIT、再現性を設計しなかった経営判断、安定性だけを評価されたIT組織を個別に見てきました。本稿では、それらがどこかの時点で同時に成立し、引き返せなくなった瞬間、すなわち「ITの目的関数が分裂した瞬間」を扱います。

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

ITの目的関数はある日突然分裂したわけではありません。成長フェーズでは速度が選ばれ、拡張フェーズでは再現性が後回しにされ、運用フェーズでは安定性だけが残りました。それぞれはその時点では合理的な判断でした。問題は、フェーズが変わっても目的関数が更新されなかったことです。

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

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

成長速度を最適化するITは安定性を犠牲にし、安定性を最適化するITは変化への対応を拒みます。再現性が設計されていないため、両者は接続できません。結果として、事業側はITを足かせだと感じ、IT側は事業を無謀だと感じるという対立構造が生まれます。

重要なのは、経営が誤った目的関数を選んだことではありません。経営が行った最大の判断は、どれか一つを「選ばなかった」ことです。いつまで速度を優先するのか、どの段階で再現性に切り替えるのか、安定性をどこで主役にするのか。これらを明示しないまま、すべてを同時に満たそうとしました。

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

分裂した目的関数は後から統合することが極めて困難です。評価指標が違い、時間軸が違い、成功体験が違う。それぞれが自分なりに正しく最適化してきたからです。統合には、誰かが「何を捨てるのか」「何を優先するのか」を決める必要があり、これは経営しか引き取れない判断です。

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

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