目的関数を定義し直すという経営責任

ITがうまく機能しなかったのは、技術の選び方を誤ったからでも、現場の努力が足りなかったからでもありません。経営が「何を最適化するのか」を定義してこなかったからです。

では、ITの目的関数を定義し直すことは、なぜ経営の責任であり、ほかの誰にも委ねられないのか。本稿ではその理由を整理します。

目的関数を定義するとは、判断の軸を固定すること

目的関数を定義するとは、何を成功とみなすのか、何を犠牲にしてよいのか、どの判断を優先するのかをはっきりさせることです。単なる目標設定ではありません。組織全体がどの軸で判断するのかを固定する行為です。

IT戦略に置き換えれば、たとえば「成長速度を最優先するのか」「再現性を重視するのか」「安定性を守るのか」を選び、その選択に責任を持つということです。

現場には、組織全体のトレードオフを選べない

現場は、目の前の成果や与えられたKPI、現実的な制約の中で判断します。だからこそ、何を捨てるのか、どこまで割り切るのか、将来のために今を犠牲にするのかといった、組織全体に響くトレードオフを現場に委ねることはできません。目的関数の定義は、経営にしか引き取れない判断です。

IT部門に任せれば、経営判断が組織の外へ追い出される

IT部門の役割は、技術的に可能な選択肢を示し、リスクを説明し、実装の方法を検討することです。どの事業に賭けるのか、どの速度で成長するのか、どのリスクを受け入れるのかを決める権限は持っていません。

ITの目的関数をIT部門に委ねることは、経営判断を組織の外へ追い出すことにほかなりません。

定義しなかったことで、何が起きたか

目的関数が定義されないままIT投資やシステム導入が進むと、次のような状態が生まれます。

• 部門ごとに最適化の軸が異なり、統合が難しくなる
• 投資判断が場当たり的になり、リターンが見えなくなる
• 成功も失敗も検証できない

これは誰かの能力不足ではありません。定義をしなかったという経営判断の帰結です。

目的関数は、決めたあとも更新し続ける

目的関数は、一度決めれば終わりではありません。事業フェーズ、組織の規模、市場環境によって、最適化すべき対象は変わります。経営の責任とは、「いつ」「どの目的関数に切り替えるのか」を、明示的に更新し続けることです。

数式ではなく、言葉で組織に共有する

目的関数を定義するといっても、数式を書くわけではありません。なぜ今は速度を優先するのか。どの段階から再現性を重視するのか。安定性を主軸に戻す条件は何か。それを言葉にして組織と共有することです。

この言語化がない限り、ITは「便利な道具」「コスト」「管理対象」へと引き戻され、DX（デジタルトランスフォーメーション）の本質から遠ざかっていきます。

経営責任とは、決め続けること

ここでいう経営責任とは、失敗したときに責任を取ることではありません。何を最適化するのかを決め、その判断を組織に示し、環境の変化に応じて更新し続けることです。ITの目的関数を定義し直すことは、その中核にある行為です。

ITを再び経営の武器にするために要るのは、新しいIT戦略でも最新のSaaSツールでもありません。まず必要なのは、経営が目的関数を引き取るという覚悟です。次章では、この覚悟がなかった結果、事業推進の現場でITがどのように暴走していったのかを、事業レイヤーから具体的に見ていきます。