事業推進ITは誰が止めるべきか

事業推進IT、つまり事業の成長を加速させるために導入するITシステムやSaaSは、現場の生産性を高め、市場の機会を逃さないためにあります。

ところが第III章で見てきたとおり、その事業推進ITが人手不足を生み、技術的負債をため込み、ツールの乱立と属人化を招き、最後には事業と経営の断絶を引き起こすことがあります。

では、それを「誰が、どこで、止めるべきだったのか」。この記事では、この問いを人や部門の責任論としてではなく、意思決定構造の問題として整理します。

現場は止められない

事業推進ITを最初に動かすのは、いつも現場です。今すぐ成果を出さなければならない。顧客対応は止められない。競合にも遅れたくない。そんな状況で「一度立ち止まろう」「設計を見直そう」と言える現場はありません。現場にとって、止める判断は事業を投げ出すのに近い行為だからです。

IT部門にも止める権限はない

IT部門は、技術的なリスクも、運用の限界も、将来の負債も見えています。それでも多くの場合、事業を止める権限はなく、投資の判断も下せず、最終責任も負えません。だからできることは、注意喚起や改善提案、ガイドラインの整備までにとどまります。

IT部門が止められないのは、能力が足りないからではありません。役割がそう設計されていないからです。

BizOpsも止められない

BizOps（ビジネスオペレーション）は、事業とITをつなぎ、判断を速め、混乱を吸収する役割を担います。しかし、判断を代わりに下す存在でも、最終決定をする立場でもありません。

むしろBizOpsが止めてしまえば、事業が回らなくなり、組織が混乱し、かえって責任を問われることになります。

ベンダーは止める立場にない

外部ベンダーの役割は、依頼されたものを作り、契約の範囲で責任を果たすことです。事業戦略や組織設計、長期的な経営判断までを引き取る存在ではありません。ベンダーに止める判断を期待すること自体が、責任の置き場所を取り違えています。

止められるのは経営だけ

ここまでを並べると、結論は一つです。事業推進ITを止められるのは、経営だけです。

成長の速度を落とす判断。短期の成果を犠牲にする判断。設計に時間を使う判断。どれも事業全体のリスクと引き換えにする判断です。このトレードオフを引き取れるのは、経営しかいません。

「止める」とは、やめることではない

ここで言う「止める」は、IT導入を中止することでも、現場の動きを抑え込むことでもありません。フェーズを切り替える。目的関数を更新する。役割を分離する。そうした設計上のブレーキをかけることを指しています。

なぜ経営は止めなかったのか

多くの企業で経営が止める判断を下せなかった理由ははっきりしています。事業は伸び、数字も出ていて、問題はまだ表に出ていなかった。だから「まだ止めるほどではない」「次のフェーズで考えよう」という判断が繰り返されたのです。

しかし、止めるべきタイミングは、問題が小さいうちにしか訪れません。

経営が先に決めておくべきだった3点

本来、経営がやるべきだったのは、次の3点をあらかじめ決めておくことでした。

• いつまでを実験とするのか
• どこからを基盤に切り替えるのか
• 誰がその切り替えを宣言するのか

止める判断は、問題が起きてからでは遅すぎます。うまくいっている間にしか、下せない判断なのです。

第III章の結論：止める判断を、誰も引き取らなかった

事業推進ITは、止めなかったから失敗したのではありません。止めるべきだという判断を、誰も引き取らなかったことが問題でした。

次章ではこの構造を前提に、情シス（情報システム部門）がなぜ「守りのIT」に閉じ込められたのかを扱い、視点を事業のレイヤーから運用のレイヤーへ移していきます。