システム内製をやめる判断はいつ行いますか？

担当者の退職や障害が起きてからでは遅い。利用部門が得る価値、保守できる人、未解決障害、変更待ち、データを取り出せるかを定期的に確認し、継続条件を満たさない時点で縮小・移管・停止を比較する。

内製システムをすぐ停止できない場合はどうしますか？

機能を重要業務と補助機能へ分ける。重要業務だけを保守対象に固定し、新規開発を止め、データ出力、手順書、権限、依存サービスを整えてから移管または代替へ進む。

外部移管に必要なものは何ですか？

ソースだけでは足りない。目的、利用者、業務フロー、データ定義、環境、権限、外部連携、監視、障害履歴、未決事項、受入条件を引き継ぐ。移管先が再現できるかを受入テストで確認する。

システム内製をやめる判断基準｜継続・縮小・外部移管・停止の出口設計

内製システムは、作り始めた時点より、動き始めてからやめにくくなる。利用者とデータが載り、業務がその画面を前提に変わるからだ。担当者の負担が増えても、止めた影響を説明できず、追加開発だけが続く。

これから内製か外注かを選ぶ段階は業務改善の外注と内製の比較が扱う。この記事は、すでに稼働している内製システムを継続、縮小、外部移管、停止のどれへ進めるかに限定する。

出口判断を「担当者が限界」まで遅らせない

担当者が疲弊していることは重要な信号だが、それだけで停止可否は決まらない。業務価値、保守可能性、データの持ち出し、代替手順を同時に見る。人の問題とシステムの価値を分けると、担当を替えて継続するのか、機能を減らすのかを選べる。

ゲート	確認する事実	未達時の選択
利用価値	誰が何の業務で使い、何を減らしたか	縮小・停止
保守能力	障害、変更、権限を複数人で扱えるか	移管・保守固定
データ可搬性	業務データを意味付きで出力できるか	出口整備を優先
代替可能性	止めた際の手順と責任者があるか	段階停止

利用価値は機能数ではなく、業務結果で見る

画面や自動処理が多くても、使う部門が限られ、結果を別表へ転記しているなら価値は小さいかもしれない。逆に機能が少なくても、受注や請求など止められない工程の正本なら、停止影響は大きい。

システムがないと止まる業務と、代替できる業務
利用者、利用場面、入力件数ではなく完了する仕事
システム外へ残る転記、照合、承認、例外処理
導入前に困っていたことが現在も減っているか
今後も変えたい業務か、維持だけでよい業務か

効果の測り方に迷う場合は業務改善の費用対効果を使い、確認、手戻り、停止影響を置く。過去の開発費を取り戻すためではなく、今後の保守と変更へ資源を使う価値があるかで判断する。

属人性を「ソースが読める人の数」だけで測らない

コードを読める人が複数いても、業務上の例外、データ修正、障害時の優先順位を一人しか知らなければ属人化している。反対に、技術担当が一人でも、変更を止め、監視と復旧を外部へ移し、業務手順が共有されていれば縮小運用は選べる。

知識	最低限残すもの	再現確認
業務	対象、例外、完了条件、責任者	別担当が一件処理
データ	項目定義、正本、修正手順	出力と復元
環境	構成、権限、依存サービス	別担当が起動
運用	監視、障害、変更、連絡	模擬障害で確認

四つの出口を同じ表で比較する

継続か停止かの二択にすると判断できない。新規開発を止めて保守だけにする縮小、特定機能だけ既製品へ移す分離、保守運用を外部へ渡す移管も含める。

出口	選ぶ条件	先に整えること
継続	価値があり、変更能力も維持できる	責任者、計画、評価指標
縮小	中核機能は必要だが開発余力がない	保守範囲、変更凍結、例外窓口
外部移管	価値はあるが社内保守を続けられない	成果物、権限、受入条件
停止	価値が薄く、代替手順を用意できる	データ退避、利用停止、依存解除

縮小は「何も変えない」ではない

保守だけにする場合、変更要求を受け付けない範囲と、障害・制度・外部仕様変更への対応範囲を分ける。利用部門からの要望をため続けると、いつか再開する前提が残り、担当者の判断が終わらない。

維持する機能と終了する機能
受け付ける障害と、仕様として扱う事象
権限追加、マスタ変更、データ訂正の窓口
外部サービス更新に追従する責任者
縮小状態を再評価する日と、継続条件

外部移管は契約前に受入可能性を確認する

IPAの「情報システム・モデル取引・契約書」は、ユーザ企業とITベンダが仕様、プロジェクト管理、検収などを共通理解のもとで対話することを期待し、受託開発や保守運用、パッケージ・SaaS活用の文書を公開している。ページは2025年6月に更新されている（IPA公式資料）。

モデル契約をそのまま使えば移管できるという話ではない。契約の前に、移管先が環境を再現し、データを読み、障害を切り分け、変更を受け入れられるかを確認する。再現できない部分は、追加調査、社内残置、停止のどれにするか決める。

停止計画は利用者・データ・連携・権限の順で作る

利用者と利用業務を一覧にし、代替手順と開始日を決める。
業務データを意味付きで出力し、参照方法と保存責任者を決める。
入力元・出力先・通知など外部連携を止め、代替先へ切り替える。
利用権限、機械用アカウント、外部サービス契約を無効化する。
停止後の問い合わせ、訂正、監査対応の窓口を残す。

停止後も旧画面を参照専用で残す場合は、期限、閲覧者、データ訂正の可否を決める。無期限の参照環境は、保守されない第二の本番になる。

依存関係マップで停止順を決める

内製システム単体の画面だけを見て停止すると、表からの取込、別システムへの出力、通知、月次集計が後から見つかる。入力元、出力先、利用部門、外部サービス、定期処理を一枚にし、各接続を残す・置き換える・終了するへ分ける。

依存	確認項目	出口作業
入力	人、ファイル、API、定期取込	受付先と形式を変更
出力	帳票、通知、他システム連携	代替先と完了確認
認証	利用者、管理者、機械アカウント	移管または無効化
基盤	ホスティング、ドメイン、証明書、監視	契約・更新を終了

依存先の担当者が「使っていない」と答えても、定期処理や繁忙期だけの利用が残ることがある。実際の入出力記録、運用カレンダー、障害連絡を確認し、推測と実見を分ける。

出口判断会議は未決事項を持ち帰らない

会議では、継続・縮小・移管・停止の各案について、未達ゲート、業務影響、先に整える成果物、決定期限を並べる。技術担当は実現可能性、業務責任者は停止影響、管理責任者は契約とデータ、経営者は資源配分を判断する。

選べない理由を「情報不足」と「決定権不足」に分ける
情報不足には回収担当と確認方法を付ける
決定権不足は論点を絞って決定者へ渡す
現状維持を選ぶ場合も継続条件と再判定日を置く
担当者の善意だけに残る暫定対応を承認しない

出口を決めた後は、新規要望の受付方法も切り替える。停止予定の機能へ追加開発を続けたり、移管前に独自変更を増やしたりすると、出口準備が後退する。決定と日々の依頼窓口を同時に変える。

出口台帳を四半期ではなく判断時点で更新する

担当者変更、重大障害、利用部門の縮小、外部サービス終了、業務手順の変更が起きたら出口台帳を更新する。台帳には現在の出口候補、未達ゲート、整える成果物、決定者、再判定条件を置く。

内製をやめることは失敗の宣言ではない。現在の事業に合う運用へ責任と資源を戻す判断だ。継続条件を満たすなら続け、価値はあるが保守できないなら移管し、価値が薄いなら安全に止める。出口を選べる状態そのものが、内製の健全性になる。

出口判断の途中で重大な障害が起きた場合も、場当たり的な全面刷新へ飛ばない。重要業務の復旧、データ保全、再発防止、出口案の再評価を分ける。緊急復旧で加えた暫定処理には終了条件を付け、継続判断の根拠へ混ぜない。

新しい責任者へ引き継ぐ際は、台帳を読んでもらうだけでなく、障害対応、データ出力、権限変更のいずれかを実行してもらう。手順があっても再現できない箇所は、属人性が残る証拠として出口整備へ戻す。