出口戦略のないITは、必ずブラック化する──肥大化システムからの3つの脱出路

あなたの会社のシステムは、10年後も動いていますか？
10年後、それを作った人はもういません。
保守できる人は、残っていますか？

最近のWindowsの動きに、どこか「破綻の匂い」を感じる。
それは”壊れた”のではなく、“統合しすぎて重くなった”という違和感だ。

新機能が追加されるたびに、複雑さは増していく。
後方互換性という「成功の呪い」が、身動きを奪っていく。
これは、Windowsだけの問題ではない。

何十年も稼働し続けている基幹システム。
止めることも、変えることもできない業務アプリ。
誰も全体像を把握していない、巨大な技術的負債──。

成功したシステムほど、終わらせ方が設計されていない。
延命すればするほど、現場はブラック化していく。

サポート終了を宣言してからの10年は、
儲からない、評価されない、セキュリティだけが重い、という地獄になる。
誰もやりたがらない。でも誰かがやらなければならない。

ベンダーは出口を用意しない。
だから、ユーザーが「降りる意思」を持たなければ、一緒に沈む。
泥船はゆっくり沈むからこそ、降りるタイミングが難しい。

本記事では、肥大化したシステムがなぜ破綻するのか、
そして、ユーザー側がとるべき出口戦略の3類型を提示する。

凍結・隔離型（触らない）
分離・再実装型（価値だけ救う）
終了・割り切り型（やめる）

この3つの選択肢を知ることで、あなたの組織は、
「今までと同じ」という一番危険な道から降りることができる。

出口戦略とは、技術の問題ではなく、経営判断の問題だ。
そして、「終わらせる勇気」を持てる組織だけが、次の成長を設計できる。

第1章｜肥大化したシステムはなぜ”破綻”へ向かうのか

「このシステム、あと何年動きますか？」
「保守できる人、あと何年残っていますか？」

この問いに、自信を持って答えられる組織は少ない。

何十年も稼働し続けているシステムは、過去の資産を引きずる宿命を負っている。
20年前のVBAマクロ、独自実装の業務ロジック、ベンダー固有のドライバ──。
これらを「捨てる」という選択は、顧客への裏切りと見なされる。

成功したシステムほど、過去資産を捨てられない。
なぜなら、顧客が求めているのは「昨日と同じように動くこと」だからだ。

後方互換性という「成功の呪い」

後方互換性は、成功の証だ。
多くのユーザーに使われ、多くの資産が蓄積され、簡単には移行できない──。
これは、システムが社会インフラになったことを意味する。

しかし同時に、それは呪いでもある。

変更は、リスクになる。
新機能を追加すれば、既存の何かが壊れるかもしれない。
仕様を変えれば、顧客が離れるかもしれない。
だから、「触らない」「変えない」「積み上げる」という方向に進んでいく。

レイヤーが積み重なる。
例外処理が増える。
誰も全体像を把握できなくなる。

修正すると、予期しない副作用が出る。
テストは、膨大になる。
リリースは、恐怖になる。

「壊さないための複雑化」が破綻要因になる逆説

ここで起きているのは、静かな逆説だ。

「壊れないように複雑にする」
→ 「複雑になったから壊れやすくなる」

システムを守るために積み上げた複雑さが、新たな破綻要因を生む。
これは、技術的な問題ではなく、構造的な問題だ。

原発の制御システム。
送電網の管理システム。
官庁の基幹システム。
そして、Windows。

規模が大きくなればなるほど、この逆説は強まる。

破綻は突然ではなく、“俊敏さの喪失”として現れる

破綻は、爆発のようには起きない。
ゆっくりと、静かに、俊敏さを失っていく。

新機能が追加できない
セキュリティ対応が後手に回る
若手が育たない（触れない）
ベテランしか理解できない
そのベテランも、全体は把握していない

システムは動いている。
でも、身動きが取れない。

これが、肥大化したシステムの末期症状だ。

「壊れないが、成長しない」
「止まらないが、進まない」
「動いているが、生きていない」

自壊はしない。
しかし、時代に取り残される。

巨大化したシステムが辿る典型パターン

この構造は、どの分野でも同じだ。

メインフレーム末期の企業システム。
レガシーコードで身動きが取れないアプリケーション。
技術的負債が積み上がったプロジェクト。

そして、今のWindows。

Windowsは壊れていない。
ただ、重すぎるのだ。

第2章｜Windowsは「価値を壊さない装置」になった

第1章で示した肥大化の構造を、最も象徴的に体現しているのがWindowsだ。

では、企業や個人は、Windowsに何を求めているのか？

企業が求めるのは「昨日と同じ」

企業がWindowsに期待しているのは、ただ一つ。

「昨日まで動いていたアプリが、今日も動くこと」

20年前に作った業務システム
VBAで組まれたExcelマクロ
ベンダー固有の業務ソフト
専用ドライバでしか動かない機器

これらが「壊れないこと」。
それ以上でも、それ以下でもない。

新しいUI？
新機能？
パフォーマンス改善？

それらは、二の次だ。
いや、正確に言えば「余計なもの」ですらある。

なぜなら、新しいものは「壊す」リスクを伴うからだ。

企業のIT部門が本当に恐れているのは、
「アップデートしたら業務が止まった」という事態だ。

個人が求めるのは「Officeが使えること」

個人ユーザーにとってのWindowsは、もっとシンプルだ。

Officeが普通に使える
ファイルが開く
印刷できる
他人とやり取りできる

OSそのものは、ほとんど意識されていない。
Windowsは「床」のような存在だ。

普段は気にしない。
でも、床が抜けたら困る。

UI刷新？
ストアアプリ？
AIアシスタント？

「別にいらない」
「今までと同じでいい」

これが、大多数のユーザーの本音だ。

価値の変化：「生む装置」から「壊さない装置」へ

かつてのWindowsは、「価値を生む装置」だった。

Windows 95は、個人にパソコンを普及させた。
Windows XPは、企業の業務を変えた。
新しいことができる、という期待があった。

しかし、今は違う。

今のWindowsに求められているのは、
**「価値を壊さないこと」**だ。

新しいことができる < 今までが壊れない
ユ��ザーが求めるのは「Windows体験」ではなく「困らないこと」
OSは主役ではなく、見えない土台

社会インフラ化した技術の宿命

これは、技術が社会インフラになった証だ。

社会インフラには、共通した特徴がある。

良くしても感謝されない
壊れると激怒される
成功の定義は「何も起きないこと」

電力、水道、道路。
そして、Windows。

誰も電力会社に「もっと革新��な電気を」とは言わない。
ただ、安定して供給されることを求める。

Windowsも、同じ位置に到達した。

アップデートは「必要悪」。
新機能は「余計なもの」。
安定こそが、唯一の価値。

OSが主役から「土台」へ

これは、悲観すべきことだろうか？

いや、むしろ成熟の証だ。

OSが「意識されない」ことこそ、本来あるべき姿かもしれない。
ユーザーが意識すべきは、OSではなく、その上で動くアプリケーションだ。

しかし、ここには構造的な問題がある。

価値を壊さない装置として機能するには、
過去のすべてを背負い続けなければならない。

その重さは、年々増していく。
複雑さは、積み上がっていく。

そして、いつか──
「壊さない」ことすら、困難になる。

第3章｜長期サポートという名の地獄

「あと10年でサポート終了します」

この宣言をした瞬間、本当の地獄が始まる。

サポート終了を宣言してからの10年は、
儲からない、評価されない、セキュリティだけが重い、という悪夢になる。

誰もやりたがらない。
でも、誰かがやらなければならない。

これは、技術の問題ではない。
構造の問題だ。

評価の非対称性：成功の定義が存在しない仕事

長期サポートの仕事には、成功がない。

何も起きなければ「当たり前」
1件起きれば「なぜ防げなかった」

つまり、どう転んでも評価されない。

新機能を作れば評価される？
そんなものは、ない。

パフォーマンスを改善すれば喜ばれる？
触ること自体がリスクだ。

やっていることは、ただ一つ。

「動かないように、動かす」

これは、エンジニアとしての成長も誇りも削られる仕事だ。

技術的後退：新しいことは何もできない

長期サポート期間中は、技術的に後退し続ける。

新技術は使えない（リスクがある）
変更は最小限（触るほど壊れる）
テストは膨大（副作用を恐れる）

10年前の設計で、10年後の脅威に対処する。

これは、建て増しを繰り返した古い家を、
耐震基準を満たしたまま維持するようなものだ。

若手は配置できない。
なぜなら、これはキャリアにならないからだ。

ベテランは消耗する。
新しいスキルは身につかず、市場価値は下がっていく。

マネージャは責任だけが増える。
予算は削られ、人は減り、でも事故は許されない。

結果として、「逃げられない人が残る」。

経済的問題：収益性ゼロ × 責任最大

長期サポートは、経済的にも地獄だ。

新機能なし → 価格は上げられない
でもコストは増える（セキュリティ対応、人件費）
顧客は言う：「サポートされて当然ですよね？」

つまり、収益性ゼロ × 責任最大。

ベンダーにとって、これほど割に合わない仕事はない。

でも、やらなければブランドが毀損される。
契約上の責任もある。
だから、やらざるを得ない。

そして、最もコストを削れるのは「人件費」だ。

最低限の人数で、最大限の責任を背負わせる。
これが、長期サポートの現実だ。

セキュリティという最大の化け物

そして、最大の化け物が立ちはだかる。

セキュリティだ。

脆弱性は、毎月出る。
攻撃手法は、日々進化する。

しかし、守る側はどうか？

攻撃者は最新技術を使う。
守る側は、10年前の設計で戦う。

これは、非対称戦争だ。

古い設計ほど、穴は深い。
直そうとすると、副作用が出る。
テストは膨大になる。
でも、時間はない。

パッチを当てる。
また脆弱性が見つかる。
また当てる。

終わりのない、モグラたたき。

そして、いつか必ず──
「対応できません」という日が来る。

ブラックIT企業と同じ構造

ここまで読んで、気づいた方もいるだろう。

これは、日本のブラックIT企業がやっていることと、まったく同じ構造だ。

古いシステムを、期限を切らずに延命
人を入れ替えながら、事故が起きない限り継続
利益はほぼ出ない
でも止める判断もできない
現場は全員わかってる：無理、割に合わない、将来性ない

違いは、規模と責任の重さだけだ。

Microsoftレベルの企業でさえ、
長期サポートという構造に入れば、ブラック化する。

いや、正確に言えば──

ブラック化しているのは人ではなく、「構造」だ。

問題の本質：「終わらせ方」が設計されていない

では、なぜこうなるのか？

答えは、シンプルだ。

「終わらせ方」が、設計されていないからだ。

ベンダーは、入口（導入）と延命（サポート延長）は提供する。
しかし、出口（終了の道筋）は提供しない。

なぜなら、出口を提供することは、
「いずれ終わる」と認めることだからだ。

それはブランド毀損になる。
契約上の責任問題になる。
株価に影響する。

だから、誰も出口を設計しない。

その結果、延命しか選択肢がなくなる。
延命は地獄への片道切符だが、他に道がない。

これが、長期サポートという名の地獄の正体だ。

第4章｜出口戦略はユーザーの責任──3つの脱出路

長期サポートという地獄から抜け出す道は、あるのか？

答えは、ある。
ただし、ベンダーは用意してくれない。

ユーザー自らが、出口を設計しなければならない。

なぜベンダーは出口を作れないのか

Microsoftは、「Windowsを捨ててください」とは言えない。

それは、契約上の責任問題になる。
ブランドの毀損になる。
株価に影響する。

だから、ベンダーが提供するのは「入口」と「延命」だけだ。

入口：新バージョンへの移行パス
延命：延長サポート（有償）

しかし、「出口」──つまり、降りる道筋──は提供されない。

ユーザー側の典型的な失敗ルート

出口戦略を持たない組織は、こう辿る。

「まだ動いてるから大丈夫」
「Microsoftが何とかしてくれる」
「次のOSでも互換あるでしょ」
セキュリティ要件だけが厳しくなる
ある日、更新できない／人がいない
時間も予算も人も足りない
→ ブラックIT化の完成

泥船の比喩

泥船の怖さは、ゆっくり沈むことだ。

まだ浮いているように見える。
だから、降りる決断が一番遅れる。

気づいた時には、手遅れ。

だからこそ、ユーザー側が「降りる意思」を持たなければならない。
ベンダーと一緒に沈むのではなく、自ら出口を設計する。

ユーザー側の現実的な出口戦略・3類型

出口戦略は、大きく3つに類型化できる。

凍結・隔離型（触らない）
分離・再実装型（価値だけ救う）
終了・割り切り型（やめる）

重要なのは、全部を最新化しようとしないことだ。
それが一番危険で、一番失敗する。

現実解は、この3つを組み合わせることだ。

類型①｜凍結・隔離型（触らない）

基本方針

「もう触らない。安全に閉じ込める」

古いシステム環境を、仮想化・オフライン化・ネットワーク分離で凍結する。
機能追加・改修は一切しない。
セキュリティは「境界防御」に全振りする。

これは、延命ではある。
しかし、地獄ではない延命だ。

具体的な手法

仮想マシン化（VMware、Hyper-V等）
スタンドアロン化（ネットワークから切り離し）
セグメント分離（VLANで隔離）
スナップショット取得（いつでも戻せる状態に）

向いているケース

自社開発の業務アプリで、作り直しコストが数億円
利用範囲が限定されている（特定部署のみ等）
法令対応等で「動く状態」を保持する必要がある
すでにブラックボックス化している

判断チェックリスト

以下に当てはまるなら、この戦略が有効：

[　] システムの利用頻度は低いか？（週1回以下）
[　] 外部との通信は最小限か？
[　] 業務クリティカル度は低いか？（止まっても数日は耐えられる）
[　] 作り直しコストが極端に高いか？（数億円以上）

メリット

すぐできる（数週間〜数ヶ月）
コスト最小（数十万〜数百万円）
人を消耗させない
技術的リスクが低い

デメリット

延命であって未来ではない
いつか必ず終わる
若手が触れない（ノウハウが継承されない）
「動いている」という理由で永久に残るリスク

想定コスト感

初期：50万〜300万円（仮想化・隔離構築）
運用：年間30万〜100万円（監視・保守）

よくある失敗パターン

「凍結」のはずが、結局ちょこちょこ触る
セキュリティ対応の例外申請が常態化
隔離したはずが、「便利だから」とネットワークに穴を開ける

類型②｜分離・再実装型（価値だけ救う）

基本方針

「価値のある部分だけを救い出す」

業務ロジック（価値のある部分）をAPI・Web・バッチに切り出す。
UIや帳票だけを段階的に刷新する。
OS依存を削っていく。

これは、段階的な脱出だ。

具体的な手法

ストラングラーパターン（徐々に置き換え）
APIラッピング（既存ロジックをAPI化）
画面のWeb化（バックエンドは既存を利用）
データ移行の段階的実施

向いているケース

業務そのものに価値がある（コアビジネス）
人がまだ残っている（内製または協力ベンダー）
5〜10年スパンで移行可能
経営の覚悟がある

判断チェックリスト

以下に当てはまるなら、この戦略を検討すべき：

[　] このシステムは10年後も必要か？
[　] 業務を理解している人材がいるか？
[　] 段階的移行に耐えられる業務か？（一気に切り替えなくてもいいか）
[　] 経営層の理解とコミットがあるか？

メリット

徐々に身軽になる
OSに縛られなくなる
人材育成につながる
未来がある

デメリット

判断力が必要（どこまで救うか、何を捨てるか）
中途半端だと二重地獄（新旧両方のメンテ）
経営の覚悟が要る（数年がかり）
失敗すると投資が無駄になる

想定コスト感

初期：500万〜5000万円（規模による）
期間：3〜10年
年間：数百万〜数千万円

よくある失敗パターン

「全部作り直し」を目指して頓挫
段階的移行のはずが、いつまでも旧システムが残る
新旧の整合性管理で疲弊
途中で予算・人が切れる

成功のポイント

「全部」ではなく「価値のある部分だけ」
- 80%の業務は20%の機能で回っている
- その20%だけを救う
短いサイクルで成果を出す（3-6ヶ月単位）
- 小さな成功を積み重ねる
- 経営層への信頼を維持
旧システムの「終了日」を先に決める
- 終わりを決めないと、永遠に残る
- 「この日までに移行完了」を宣言

類型③｜終了・割り切り型（やめる）

基本方針

「それ、本当に要りますか？」

システムを終わらせる。
業務を手作業・外部SaaS・業務統合で代替する。
データだけ保存（参照用）。

これは、一番勇気がいるが、一番健全だ。

具体的な手法

SaaS移行（kintone、Salesforce等）
業務フロー見直し（本当に必要か再検討）
手作業への回帰（一時的に）
データのアーカイブ化（検索可能な形で保存）

向いているケース

利用頻度が低い（月1回未満等）
担当者しか価値を知らない
業務が形骸化している
止めても会社が死なない

判断チェックリスト

以下の問いに答えられないなら、終了を検討すべき：

[　] このシステム、止めたら誰が困るか？（具体的に）
[　] 過去3ヶ月の利用ログは？（誰が、何回使ったか）
[　] 代替手段はあるか？
[　] データさえ残れば良いか？

メリット

一番安い
一番健全
技術的負債が完全に消える
人的リソースが解放される

デメリット

心理的抵抗が大きい（「もったいない」）
「前例がない」と言われる
決断する人が嫌われる
後から「やっぱり必要だった」リスク

想定コスト感

データ移行・アーカイブ：50万〜300万円
SaaS移行の場合：月額数万〜数十万円
業務フロー見直し：コンサル費用等

よくある失敗パターン

「念のため残す」で結局延命
データ移行が不完全で後でトラブル
業務影響の見積もりが甘い

成功のポイント

「止める」ではなく「卒業する」という言い方
- ネガティブではなく、前向きに
経営層を巻き込む
- IT部門だけでは決められない
小さいシステムから実績を作る
- いきなり基幹系は無理
「データは残す」で心理的抵抗を下げる
- 完全に消すわけではない

3類型の使い分け（超重要）

全部を最新化しようとするのが、一番危険だ。

現実では、1つに決めないのが正解。

判断フロー

複合戦略の実例

ある製造業の事例：

基幹生産管理：② 分離・再実装（5年計画）
設備管理：① 凍結・隔離（仮想化で延命）
個人開発ツール群：③ 終了（SaaS移行）

→ 全部②にしようとすると、予算も人も破綻する。

出口戦略は経営判断

ここまで読んで、気づいただろうか。

出口戦略は、技術の問題ではない。
経営判断の問題だ。

何を残すか
何を捨てるか
いつ降りるか

これらは、すべて経営判断だ。

IT部門だけでは決められない。
経営層を巻き込まなければ、実行できない。

そして、出口戦略を持たない組織は、必ずブラック化する。

第5章｜なぜ出口戦略を設計しないのか

第4章で、出口戦略の3類型を示した。

凍結・隔離型
分離・再実装型
終了・割り切り型

どれも、現実的で実行可能な戦略だ。

では、なぜ多くの組織は、出口戦略を設計しないのか？

人は「今までと同じ」が続くと錯覚する

理由は、シンプルだ。

人間は、「今までと同じ」が続くと錯覚するようにできている。

これは、怠慢ではない。
人間の仕様だ。

日々の仕事は、「回す」ので精一杯。
昨日と同じやり方は、コストが低い。
変えるには、説明・摩擦・失敗が要る。

だから、「変えないこと」が最適解に見える。

実際、短期的には正しい。
明日も、明後日も、来月も、来年も──
おそらく、同じように動くだろう。

しかし、時間軸を入れた瞬間、この前提は崩れる。

時間軸を入れると見えてくるもの

10年後を想像してみよう。

自分は老いる
若者が意思決定層になる
技術は前提を変える
過去の成功体験は文脈を失う

「今までと同じ」は、いつか必ず終わる。

人は老い、世代は交代し、技術は進化する。
その時、過去の資産は──文脈を失って、負債へ反転する。

「このコード、なぜこうなってるんですか？」
「作った人、もういないんだよね」
「仕様書？ないよ」

これが、10年後の現実だ。

製品ライフサイクル（PLC）を理解していない

出口戦略を設計しない根本原因は、もう一つある。

製品ライフサイクル（PLC）という概念の欠如だ。

すべての技術には、ライフサイクルがある。

導入期：尖っている／不安定／自由
成長期：標準化／普及／改善
成熟期：安定／互換性／インフラ化
衰退期：延命／縮退／出口設計

導入期には、投資し、実験し、失敗を許容する。
成長期には、拡大し、標準化し、人を増やす。
成熟期には、安定させ、保守し、リスクを避ける。

では、衰退期には？

縮退し、隔離し、終了を設計する。

しかし、多くの組織は、これをやらない。
成熟期のノリで、衰退期を運用しようとする。

その結果、延命しか選択肢がなくなる。

Windowsは今、どこにいるのか

Windowsは、成熟期の終盤〜衰退期の入口にいる。

価値は「新しさ」ではない
価値は「壊れないこと」
変えるほどリスクが高まる
サポートはコストセンター

これは、衰退ではない。
成熟の証だ。

しかし、成熟した技術には、成熟した扱い方が必要だ。

導入期の技術（AIなど）を、成熟期の技術（Windows）に混ぜると、
位相差で事故が起きる。

成熟期の技術を、成長期のノリで運用しようとすると、
現場が疲弊する。

PLCを理解していないと、正しい判断ができない。

馬車の比喩：便利だったものは手放せない

もう一つ、出口を設計できない理由がある。

便利だったものほど、手放すのは難しい。

馬車が最高だった時代がある。

100年以上使われた技術。
インフラも人材も揃っていた。
「これ以上何が必要？」

しかし、汽車が登場した。

馬車業界は否定的だった。
「汽車なんて、一時的な流行だ」
「既存インフラへの投資が無駄になる」
「馬車で十分」

でも、結果はどうなったか？

馬車に依存し続けた者は、汽車への切り替えが遅れた。
次の自動車にも、乗り遅れた。
技術の世代交代から、取り残された。

今、あなたの会社の「馬車」は何だろうか？

Windows（成熟期後半）
オンプレミス（成熟期）
メインフレーム（衰退期）
そして──「あのシステム」

便利だった。
今も動いている。
でも、10年後は？

組織的な先送り構造

そして、最も厄介なのが、組織的な先送り構造だ。

経営層：現場を知らない
現場：決裁権がない
IT部門：責任を取りたくない

誰も決められない。

「今はまだ大丈夫」
「来年考えよう」
「予算がついてから」

泥船は、ゆっくり沈む。
だから、降りる決断が一番難しい。

そして、「いつか破綻する」という前提を無視すると──
別の形で破綻を招く。

選択肢がない状態で、強制終了。
それが、ブラックIT化だ。

出口戦略を設計する、ということ

出口戦略を設計するということは、こういうことだ。

「今までと同じ」は続かないと認める
PLCを理解し、現在地を見極める
便利だったものを手放す勇気を持つ
組織として、降りる決断をする

これは、技術論ではない。
経営論だ。

そして、「終わらせる勇気」を持てる組織だけが、
次の成長を設計できる。

第6章｜成長とは「断ち切り」のことだった

ここまで読んで、気づいた方もいるだろう。

この記事は、ITの話をしているようで、
実は、もっと普遍的な話をしている。

成長が止まる本当の理由

成長が止まるのは、なぜか？

技術が古くなったから？
若者が優秀だから？
予算がないから？

いや、違う。

成長が止まるのは、「断ち切る判断」を誰もしなくなったときだ。

古い資産を守ることが、目的になる。
継続そのものが、価値になる。
PLCを、「見ない」ようになる。

この瞬間から、組織も個人も、緩やかに老化していく。

成長するPLCは「断絶型」

多くの人が、成長をこう誤解している。

成熟したら → また成長に戻る（循環）

しかし、現実は違う。

本当に成長するPLCは、こうだ。

成熟したら → 終わらせる
終わらせたら → 空白を作る
空白に → 新しい導入期を置く

断ち切りを挟まないPLCは、成長しない。

これは、技術だけの話ではない。

技術・組織・個人に共通する原理

技術のPLC

古い技術に固執すると、新しい技術に乗り遅れる。

馬車 → 汽車 → 自動車。
メインフレーム → C/S → Web → クラウド。

馬車を手放せなかった者は、汽車に乗れなかった。
汽車を手放せなかった者は、自動車に乗れなかった。

組織のPLC

古い事業に固執すると、新しい事業が育たない。

ブラックIT化した組織は、新規事業を生めない。
なぜなら、延命に人もカネもリソースも奪われるからだ。

出口戦略を持たない組織は、次を設計できない。

個人のPLC

古いスキルに固執すると、新しいスキルが身につかない。

人のライフサイクルは、こうだ。

学習 → 実践 → 熟練 → 固着

「熟練」に安住した瞬間、成長は止まる。

そして、技術は次の導入期に入っている。
気づいた時には、取り残されている。

過去の資産が負債に反転する瞬間

過去の資産は、いつ負債になるのか？

それは、文脈を失った瞬間だ。

「これは資産か、思い出か？」
「自分がいなくなっても、意味は残るか？」
「10年後の若者は、これを誇りに思うか？」
「今ゼロから作るなら、同じ形にするか？」

1つでも「NO」なら、それはもうPLCの終盤だ。

文脈を失った資産は、負債に変わる。

保守コスト
機会損失
人材の拘束

そして、次の世代に──負の遺産として引き継がれる。

PLCを見る目

PLCに対する態度は、3つに分かれる。

① PLCを見ない人は、消耗する

「なぜこんなに大変なのか」がわからない。
延命に追われる。
燃え尽きる。

② PLCが見えていて無視する人は、固着する

「わかってるけど、変えられない」
「前例がない」
「上が決めない」

組織を腐らせる。
若者の未来を奪う。

③ PLCが見えていて設計できる人だけが、次を作る

終わらせる勇気。
空白を作る覚悟。
次を設計する力。

これが、成長する人だ。

「今までと同じ」を疑う

この記事のタイトルを、もう一度見てほしい。

「出口戦略のないITは、必ずブラック化する」

これは、警告ではない。
構造の話だ。

終わらせ方を設計しないシステムは、
延命しか選択肢がなくなる。

延命は、現場を消耗させる。
若手を遠ざける。
ベテランを疲弊させる。

これがブラック化の正体だ。

逆に言えば──

出口戦略を持つ組織は、ブラック化しない。

なぜなら、終わらせることができるからだ。
終わらせられるから、次を始められる。

読者への問い

最後に、3つの問いを残したい。

あなたの組織は、何を終わらせるべきですか？
あなた自身は、何を手放すべきですか？
今ゼロから設計するなら、同じ形にしますか？

この問いに答えられる人だけが、次を設計できる。

「今までと同じ」を疑える人だけが、次を設計できる。

出口戦略とは、未来の人に選択肢を残すこと。

成長とは、積み上げではなく、断ち切ることだった。

あなたは、何を終わらせますか？

おわりに

出口戦略は、技術の問題ではない。
経営判断の問題だ。

そして、「終わらせる勇気」を持てる組織だけが、次の成長を設計できる。

この記事では、肥大化したシステムがなぜ破綻するのか、
そして、ユーザー側がとるべき出口戦略の3類型を提示した。

凍結・隔離型（触らない）
分離・再実装型（価値だけ救う）
終了・割り切り型（やめる）

しかし、この記事が本当に伝えたかったのは、戦略そのものではない。

「何を終わらせるべきか」という問いを、
組織として持てるかどうか。

この問いを持てる組織は、ブラック化しない。
なぜなら、終わらせることができるからだ。

終わらせられるから、次を始められる。

「今までと同じ」を疑える人だけが、次を設計できる。

出口戦略とは、未来の人に選択肢を残すこと。

あなたは、何を終わらせますか？

お問い合わせ

ＩＴクオリティ株式会社はこちら。ご相談もこちらからどうぞ。

https://www.itq.co.jp/