サイトマップ
事業推進ITは誰が止めるべきか
事業推進ITは成長を加速させ、現場の生産性を高め、市場機会を逃さないために導入されます。しかし、人手不足を生み、技術的負債を蓄積し、ツール乱立と属人化を招き、最終的には事業と経営の断絶を引き起こします。
誰が、どこで、止めるべきだったのか
この事業推進ITを誰が、どこで、止めるべきだったのか。本稿では、この問いを人や部門の責任論ではなく、意思決定構造の問題として整理します。
現場の視点
今すぐ成果を出す必要がある
IT部門の視点
技術的リスクを認識している
経営の視点
全体最適の判断が必要
現場は止められない
事業推進ITを最初に動かすのは、常に現場です。今すぐ成果を出す必要があり、顧客対応を止められず、競合に遅れたくないという状況で、「一度立ち止まろう」「設計を見直そう」と判断することは、現場にはできません。
現場にとって、止める判断は事業放棄に近い行為だからです。
現場の制約
  • 成果を出す必要性
  • 顧客対応の継続
  • 競合への対応
IT部門にも止める権限はない
IT部門は、技術的リスク、運用上の限界、将来の負債を認識しています。しかし多くの場合、事業を止める権限がなく、投資判断を下せず、最終責任を負えないため、注意喚起、改善提案、ガイドライン整備に留まります。
01
リスク認識
技術的な問題を把握
02
提案活動
改善策を提示
03
限界到達
権限不足で実行不可
IT部門が止められないのは、能力不足ではなく、役割設計の問題です。
BizOpsも止められない
BizOpsの役割
BizOpsは、事業とITの間をつなぎ、判断を高速化し、混乱を吸収する役割として機能します。
しかしBizOpsは、判断を代行する存在ではなく、判断を最終決定する立場でもないため、止める判断を下すことはできません。

BizOpsが止めてしまえば、事業が回らなくなり、組織が混乱し、かえって責任を問われます。
ベンダーは止める立場にない
外部ベンダーは、依頼されたものを作り、契約範囲で責任を果たす立場です。事業戦略、組織設計、長期的な経営判断まで引き取る存在ではありません。
ベンダーの役割範囲
  • 依頼された開発の実行
  • 契約範囲内での責任
  • 技術的な助言提供
範囲外の領域
  • 事業戦略の決定
  • 組織設計の判断
  • 長期的な経営判断
ベンダーに止める判断を期待すること自体が、責任の所在を誤っています。
止められるのは「経営」だけである
経営だけが止められる
事業推進ITを止められるのは、経営だけです。なぜなら、成長速度を落とす判断、短期成果を犠牲にする判断、設計に時間を使う判断は、事業全体のリスクと引き換えだからです。
成長速度の調整
短期と長期の均衡
設計への投資
このトレードオフを引き取れるのは、経営しか存在しません。
「止める」の真の意味
ここで言う「止める」とは、IT導入を中止する、現場の動きを抑圧することではありません。意味するのは、フェーズを切り替える、目的関数を更新する、役割を分離するという、設計上のブレーキです。
フェーズの切り替え
実験から基盤へ移行
目的関数の更新
評価軸を再定義
役割の分離
責任範囲を明確化
止める判断が行われなかった理由
見過ごされた理由
多くの企業で、経営が止める判断を下せなかった理由は明確です。事業が伸びていた、数字が出ていた、問題が表面化していなかったため、「まだ止めるほどではない」「次のフェーズで考えよう」という判断が繰り返されました。
止めるべきタイミングは、問題が小さいときにしか訪れません。
経営判断として必要だったのは、いつまでを実験とするのか、どこからを基盤に切り替えるのか、誰がその切り替えを宣言するのかを、事前に決めておくことです。
1
実験フェーズ
事前に期限を設定
2
切り替え判断
責任者を明確化
3
基盤構築
長期視点で設計
第III章の結論
事業推進ITは、止めなかったから失敗したのではありません。止めるべき判断を、誰も引き取らなかったことが問題でした。
構造的問題
意思決定の仕組みに欠陥があった
責任の所在
誰も最終判断を引き取らなかった
次章への展開
情シスが「守りのIT」に閉じ込められた理由へ
次章では、この構造を前提に、情シスはなぜ「守りのIT」に閉じ込められたのかを扱い、事業レイヤーから運用レイヤーへと視点を移していきます。