はじめに
事業推進IT（事業成長を加速させるためのITシステムやSaaSの導入）は、現場の生産性を高め、市場機会を逃さないために導入されます。しかし、第III章で見てきた通り、それは人手不足を生み、技術的負債を蓄積し、ツール乱立と属人化を招き、最終的には事業と経営の断絶を引き起こす可能性があります。本稿では、この事業推進ITを「誰が、どこで、止めるべきだったのか」という問いを、人や部門の責任論ではなく、意思決定構造の問題として整理します。
現場は止められない
事業推進ITを最初に動かすのは常に現場です。今すぐ成果を出す必要があり、顧客対応を止められず、競合に遅れたくない状況では、「一度立ち止まろう」や「設計を見直そう」と判断することはできません。現場にとって、止める判断は事業放棄に近い行為だからです。
IT部門にも止める権限はない
IT部門は技術的リスクや運用上の限界、将来の負債を認識しています。しかし、多くの場合、事業を止める権限がなく、投資判断を下せず、最終責任を負えないため、注意喚起や改善提案、ガイドライン整備に留まります。IT部門が止められないのは能力不足ではなく、役割設計の問題です。
BizOpsも止められない
BizOps（ビジネスオペレーション）は、事業とITの間をつなぎ、判断を高速化し、混乱を吸収する役割として機能します。しかし、BizOpsは判断を代行する存在ではなく、最終決定する立場でもないため、止める判断を下すことはできません。BizOpsが止めてしまえば事業が回らなくなり、組織が混乱して、かえって責任を問われる立場にあります。
ベンダーは止める立場にない
外部ベンダーは、依頼されたものを作り、契約範囲で責任を果たす立場です。事業戦略や組織設計、長期的な経営判断まで引き取る存在ではありません。ベンダーに止める判断を期待すること自体が、責任の所在を誤っています。
止められるのは「経営」だけである
ここまでの整理から導かれる結論は一つです。事業推進ITを止められるのは、経営だけです。なぜなら、成長速度を落とす判断、短期成果を犠牲にする判断、設計に時間を使う判断は、いずれも事業全体のリスクと引き換えだからです。このトレードオフを引き取れるのは経営しか存在しません。
「止める」とは、やめることではない
ここで言う「止める」とは、IT導入を中止したり現場の動きを抑圧したりすることではありません。意味するのは、「フェーズを切り替える」「目的関数を更新する」「役割を分離する」という、設計上のブレーキをかける行為です。
止める判断が行われなかった理由
多くの企業で経営が止める判断を下せなかった理由は明確です。事業が伸びて数字が出ており、問題が表面化していなかったため、「まだ止めるほどではない」「次のフェーズで考えよう」という判断が繰り返されました。しかし、止めるべきタイミングは、問題が小さいときにしか訪れないという性質を持っています。
経営判断として何が必要だったのか
本来、経営が行うべきだったのは、以下の3点を事前に決めておくことです。
- いつまでを実験とするのか
- どこからを基盤に切り替えるのか
- 誰がその切り替えを宣言するのか
止める判断は、問題が起きた後では遅く、成功している間にしかできないという性質を持っています。
第III章の結論
事業推進ITは、止めなかったから失敗したのではありません。止めるべき判断を誰も引き取らなかったことが問題でした。次章では、この構造を前提に、情シス（情報システム部門）はなぜ「守りのIT」に閉じ込められたのかを扱い、事業レイヤーから運用レイヤーへと視点を移していきます。
