失敗したシステムをやめられない理由｜費用と責任が撤退判断を遅らせる

現場で使われていないシステムに対し、「ここまで費用をかけたから」「あと一機能あれば使われる」と追加改修を続けることがあります。その間も旧Excelとの二重運用や保守費用が残ります。

過去の投資を無駄にしたくない気持ちは自然です。しかし、過去に使った費用と、これから続ける価値は分けて判断する必要があります。

過去の費用は将来の便益を保証しない

今後の判断で比較するのは次です。

継続した場合に、これから得られる便益
− 継続に、これから必要な費用・時間・リスク

すでに支払った開発費や、担当者が費やした時間は、どちらを選んでも戻らない場合があります。それでも意思決定では「無駄だったと認めたくない」という感情が入ります。

自分で決めた案件ほど追加投資しやすい

Stawはビジネス投資を模した実験で、悪い結果が出た場合でも、当初の意思決定に自分が責任を持つ条件では追加資源の投入が大きくなる傾向を示しました。Knee-deep in the Big Muddy

これはコミットメントのエスカレーションとして知られます。システム導入でも次の力が働きます。

• 自分の判断ミスだと思われたくない
• 経営へ失敗を説明しにくい
• 現場へ協力を求めた手前、撤回しにくい
• 契約や社内体制を作り直すのが大変
• 成功するまで続ければ失敗ではないと感じる

追加改修が妥当な場合もある

撤退だけが正解ではありません。次が明確なら改修に価値があります。

• 使われない原因が特定できている
• 改修後に変わる行動を説明できる
• 影響を受ける利用者が検証へ参加する
• 小さい範囲で効果を確認できる
• 期限と追加予算の上限がある
• 改修しても改善しない場合の停止条件がある

「機能不足だと思う」だけでは追加投資の根拠になりません。

継続・修正・撤退を同じ表で比較する

項目	継続	修正	撤退・置換
今後の費用
現場の追加負担
二重運用
データ移行
改善までの期間
失敗時の影響
社内で変更できる範囲

「撤退はゼロ、継続は現状維持」ではありません。継続にも保守費、確認時間、機会損失があります。

導入前に撤退条件を決める

• 試行期間
• 利用対象となる業務と件数
• 業務時間が減る最低条件
• 誤りや障害の許容範囲
• 旧運用を終了できる期限
• 追加改修の予算上限
• 判断日と判断者

失敗が見えた後では責任問題が強くなるため、導入前に決めます。

レビュー担当を導入担当と分ける

導入担当者を外す必要はありませんが、次の人を加えます。

• 実際の利用者
• 前後工程の担当者
• 費用と契約を確認する人
• 当初決定に直接関与していない人

導入時の説明ではなく、現在のログ、作業時間、二重入力、修正履歴を確認します。

撤退を失敗の隠蔽にしない

停止後に残すものがあります。

• 当初解決したかった問題
• 実際に使われなかった理由
• 有効だった機能とデータ
• 移行で判明した例外
• 次回の判断基準
• 再利用できる成果物

学習を残せば、すべてが無駄になるわけではありません。

まとめ

失敗したシステムをやめられないのは、過去の費用だけでなく、自分の判断を否定したくない気持ちや社内説明の難しさが関係します。

過去の投資と今後の判断を分け、継続・修正・撤退を同じ基準で比較します。導入前に期限、追加予算、停止条件、判断者を決めることが重要です。

旧運用との二重管理は新システム導入後もExcelが残る理由、AIの全件確認はAI導入後に確認作業が増える理由で解説しています。