リスク1．実は他システムと連携して業務を支えている

　旧システムの利用状況を確認する際、ログインするユーザー数だけを見て「もうほとんど使われていない」と判断するのは危険だ。画面を操作するユーザーが少なくても、旧システムが他のシステムへデータを送り続けている可能性がある。

　例えば、旧システムが財務や人事、調達、顧客対応、分析、コンプライアンス、現場の業務システムへデータを渡しているケースだ。別のシステムからファイルを受け取り、商品コードや処理状況などの情報を追加した上で、後続システムへ送信している場合もある。

　後続システムが、旧システムによる加工や処理を前提に動いていれば、旧システムを停止した時点でデータ連携が途切れる。廃止計画で停止日を決めていても、周辺システムが旧システムなしで稼働できる準備を整えていなければ、実際には止められない。

　そこで情シスは、旧システムに接続する全てのインタフェースを洗い出し、少なくとも次の点を把握しておきたい。

• 現在も稼働している連携は何か
• 業務停止につながる重要な連携はどれか
• 連携先や管理部門が不明な処理はないか
• 下流工程を変更しなかったために残っている連携はないか
• 利用頻度は低くても、月末や年度末にだけ使われる処理はないか

　既存の連携を削除できるのか、新しいデータフローやAPI、イベント通知、ワークフロー、帳票作成プロセスなどに置き換える必要があるのかを判断する。

　廃止対象となる旧システムを、新システムが直接置き換えられるとは限らない。旧システムが複数のシステム間を仲介する役割を担っている場合、新システムへの移行とは別に、企業全体のデータ連携を設計し直す必要がある。

　自動化機能やAIツールを業務へ導入している企業は、さらに注意が必要だ。AIエージェントや自動処理が、旧システムを経由したデータを基に判断している可能性があるからだ。

　旧システムの停止によって、データの内容だけでなく、到着する時刻や形式、付与される文脈が変わることもある。その結果、AIや自動化ツールの判断精度、処理順序、例外判定に影響が及ぶ恐れがある。

　旧システムが属する業務領域と、廃止による問題が発生する業務領域が異なるケースもある。例えば、人事システムの停止が、財務部門の集計処理や、セキュリティ部門のアカウント管理に影響する可能性がある。

　レガシーシステムは、戦略的には時代遅れでも、運用上は重要であり得る。経営層がなくしたいと考えるリスクを、業務部門が依然として業務経路として利用していることが、廃止を難しくする。

リスク2．アクセス権限を消すべきか、残すべきか判断できない

　旧システムの廃止は、データやアプリケーションだけでなく、アクセス管理の問題でもある。

　長期間利用されたシステムには、ユーザーや管理者、サービスアカウントなどの権限が蓄積している。現在も業務上必要な権限がある一方、以前の役職やプロジェクト、担当地域、例外対応を理由に付与された権限が、そのまま残っていることもある。

　システム連携や定期処理、帳票作成に使用するサービスアカウントも見逃しやすい。担当者が異動または退職し、用途を説明できる人がいないまま、管理者権限を持つアカウントが残っている可能性もある。

　旧システムの権限を早く削除し過ぎれば、業務上必要な過去データへアクセスできなくなる。顧客からの問い合わせへの回答や、監査、税務、契約上の確認に必要な情報を取り出せなくなる恐れがある。

　一方、アクセス権限を長く残し過ぎれば、不要なセキュリティやプライバシー、コンプライアンス上のリスクを抱え続けることになる。特に、強い権限を持つアカウントが「PAM」（Privileged Access Management：特権アクセス管理）の対象外になっている場合は注意が必要だ。

　廃止計画では、「現在の業務上の必要性」と「過去から続く利便性」を分けて考えなければならない。正式なアクセス権限レビューを実施し、誰が、何のために、どのデータへアクセスしているかを確認する。

　具体的には、次のような問いに答えられる状態にする必要がある。

• 現在も旧システムへログインしているのは誰か
• ログインする目的は何か
• どのデータを閲覧、変更、出力できるのか
• 連携や帳票作成に使用している権限は何か
• 不要なまま残っているアカウントはないか
• 移行期間中だけアクセスが必要なユーザーは誰か
• 一時的なアクセスをいつ終了するのか
• 過去データを稼働中のシステムではなく、アーカイブへ移せないか

　旧システムを「参照専用」に変更しても、リスクがなくなるわけではない。ユーザーや管理者、サービスアカウントが、保存すべきでないデータや、本来は閲覧できない情報へアクセスできる状態が残れば、情報漏えいの原因になり得る。

　アクセス権限の整理には、技術的な対応だけでなく、ガバナンス上の判断が求められる。企業は、過去データを閲覧できる人、アクセスの例外を承認する人、一時的な権限の期限、データを削除またはアーカイブする条件を決める必要がある。

　アカウントの作成、変更、無効化、削除といったプロビジョニングとデプロビジョニングは、システムを停止した後に考える作業ではない。廃止計画の中に、権限を段階的に縮小する工程と、例外利用を終了させる条件を組み込むべきだ。

　これらを曖昧にしたままでは、旧システムは「管理された例外」として残る。やがて例外的なアクセスが通常運用となり、廃止計画そのものが形骸化する。

リスク3．新システムには責任者がいるが、旧システムの停止にはいない

　システム刷新プロジェクトには、通常、責任者が設定される。経営層のスポンサーやプロジェクトマネジャー、業務部門の担当者、ベンダーが参加し、予算やスケジュール、成果物を管理する。

　一方、旧システムの廃止は、誰の責任かが曖昧になりやすい。

　データを保管する、アクセスを停止する、連携を解除する、帳票を作り直す、ユーザーへ通知する、マニュアルを更新する、契約を終了する――。こうした作業は、新システムの稼働後に残った細かなタスクとして扱われがちだ。

　しかし、これらは単なる事務作業ではない。どのデータを残し、何を削除するかを決めるガバナンス業務であり、業務を停止してよいかを判断する経営上の意思決定でもある。

　例えば、データ廃棄では、次のような判断が必要になる。

• 法令や契約に基づいて保存すべきデータは何か
• 検索可能な状態で残すデータは何か
• アーカイブだけでよいデータは何か
• 個人情報など、保存せず削除すべきデータは何か
• 誰がデータの保持期間を承認するのか

　こうした判断を停止日の直前に始めれば、廃止は延期される。データ保持ポリシーやアーカイブ方針を、移行計画の段階から明確にしておく必要がある。

　新システムが安定するまで旧システムを残したい部門と、コストやセキュリティ上の理由から早く停止したい部門が対立することもある。その際、誰が両者の意見を調整し、最終的な判断を下すのかが明確でなければならない。

　廃止計画では、次の担当者を定めておく。

• 新システムが安定するまで旧システムを管理する
• 停止条件を定義する
• 条件を満たしたと判断する
• 部門間の意見対立を調整する
• 旧システムを維持するコストを把握する
• セキュリティやコンプライアンス上のリスクを監視する
• 例外的な延命措置が生じた場合に承認する

　担当者は、情シスや業務システム部門、財務部門、セキュリティ部門、データガバナンス部門、あるいは事業部門に置くことが考えられる。企業の組織体制によって適切な配置は異なる。

　重要なのは、全てを一人に任せることではなく、最終的な説明責任を負うオーナーを決めることだ。複数部門による共同管理であっても、誰が停止を判断し、誰が未完了の作業を追跡するかを明確にする。

　オーナーがいなければ、旧システムは部分的な連携や例外アクセス、未移行の帳票を残したまま稼働し続ける。新システムの導入プロジェクトは完了しても、旧システムの保守費用やライセンス費、インフラ費用は消えない。

　コストがなくなるのではなく、「廃止できていないシステムを維持する費用」として見えにくくなるだけだ。技術的負債は、開発上の問題だけではない。不要なシステムを止められず、組織が運用し続けるという経営上の問題でもある。

リスク4．「念のため」が旧システムを延命させる

　旧システムが残り続ける理由の1つに、ユーザーの心理がある。

　新システムが稼働した後も、ユーザーが旧システムの画面や帳票、履歴を確認し続けるといったケースだ。新システムの結果が正しいかどうかを、旧システムを使って照合する。新しい帳票が分かりにくいため、旧システムの帳票を併用する。トラブルが発生した際の予備として、旧システムへのアクセスを残すといった具合だ。

　「念のためのバックアップとして残している」「あと1四半期だけ使いたい」「新システムに問題が起きた際に戻れるようにしたい」といった主張を、旧システムへの執着として聞き流すのは避けたい。旧システムを確認し続ける理由が、新システムの機能不足やデータの不備、不完全なワークフローに起因する場合、現場に次の問題が隠れている可能性がある。

• 新システムへ移行されていない履歴データがある
• 帳票の数値や定義が旧システムと一致しない
• 例外処理に必要な機能が実装されていない
• 業務の進捗状況を確認できない
• 移行後のデータ品質に不安がある
• 現場が必要とする検索条件や画面がない

　この場合、旧システムへのフォールバックは、新環境が業務を十分に支えられていないことを示す。無理にアクセスを停止するのではなく、新システム側の問題を修正しなければならない。

　一方、旧システムを使い続ける理由が、「使い慣れているから」「新しい操作を覚えたくない」場合は注意が必要だ。旧システムを併用できる状態を長く残すほど、新システムを使うやる気は弱くなる。

　そこで廃止計画では、旧システムを予備として利用する目的と終了条件を明確にすることが重要だ。

• 旧システムの参照によって、どの問題を解決しているのか
• 利用は一時的なものか
• 誰が例外利用を承認するのか
• 例外利用の期限はいつか
• 何を確認できれば旧システムを使わなくて済むのか
• どの帳票やデータ、ワークフローを改善する必要があるのか

　「念のため」という説明だけで利用を認めれば、終了条件を設定できない。旧システムは残り続け、運用コストやセキュリティリスクは残る。

旧システムの廃止に必要なのは「希望」ではなく「証拠」

　旧システムの廃止は、新システムへの移行が終わった後に実施する後片付けではない。新しいシステムを導入することと、古いシステムを安全に停止することを合わせて、モダナイゼーションと捉える必要がある。

　新システムが本番稼働したという事実だけでは、旧システムを廃止できる証拠にはならない。

　旧システムを停止するには、必要なデータが適切な場所へ移行またはアーカイブされていること、他システムとの連携が削除または代替されていること、アクセス権限が整理されていることを確認する必要がある。

　帳票や業務フロー、自動化、AIツールが旧システムへ依存していないことも確かめなければならない。例外的に利用を継続する場合は、目的や責任者、終了条件を定める必要がある。

　廃止の可否を判断するオーナーが存在し、未完了の作業や延命コスト、残存リスクを追跡できる状態を作っておくことも欠かせない。問題が起きることを恐れて停止を先送りし続ければ、旧システムは例外運用として残り続ける。