2026年9月30日

レガシーシステムは延命か転生か

はじめに

レガシーなシステムの担い手が去るとき、組織は何を問われるのか。
引継ぎの現場から見えてくる課題と選択肢について考える。

システムが“遺産”となる日

ある日、長年社内システムを一人で支えてきた開発担当者が急遽退職することになった。
実務部門はシステムを使って日々業務を行っている。
情報システム部門はシステムがどこで動いて何を入出力しているかを把握してる。
一見すると問題がなさそうだが、システムが「なぜそう動いているのか」を把握しているのは開発担当者のみだった。
つまり業務システムを理解している人間がいなくなる。
だが引継ぎ期間は限られ、資料は断片的、ソースコードと実行環境のみが“正”という状態。
このままでは“遺産”となってしまう。

“負の遺産”となる前に動かなければならない

弊社にもこうした“遺産”となったシステムをどうにかできないか相談が来る。
規模の大小があっても概ね状況は似たり寄ったり。

ソースコードはある、しかし全て揃っているかは分からない
設計資料はある、しかし最新化されているかは分からない
操作マニュアルはある、しかし実務者視点なので数字やデータがどう動くかは分からない
運用の記録はある、しかし事象と対応が中心で理由が分からない

「これで引き継げますか？」と問われる。
答えはいつも同じ。
「資料やソースコードは読めます。しかし、なぜそう書いたかは読めません。」

ソースコードや資料からプログラムの実装は読めるものの、業務にどう適合しているかは分からない。
業務フローを知らなければ、操作の順序も、入れるデータも、表示されているデータも、専門用語なラベルも何もかも理解できないし、エラーや異常データ出力など何か起きた時の対処の正解も分からない。
だから「なぜそう書いたかは読めません」という答えになってしまう。

ソースコードと資料さえ渡せばなんとかしてくれるだろうという期待を裏切ってしまって申し訳ないが、ここで安請け合いをすると双方不幸しかやってこない。
なのではっきりと伝えている。
それでも“遺産”となる日はやってくる。
何もしなければいつか業務を止める“負の遺産”となってしまうかもしれない。
現実を伝え、お互いに協力して乗り越えなければならないことを理解しあったところから、レガシーシステムの引継ぎが始まる。

まず情報の「棚卸」から始める

引き継ぎを受ける担当者が最初に直面するのは、何がどこにあるのか分からないという状況。

システムがどこに存在して何と連携しているのか
PCやファイルサーバに散在する命名規則もバラバラなファイル
どれが最新なのか分からないソースコード
どう使われているか分からないコミュニケーションツール
大量に蓄積された様々な記録

整理の前に、まず「棚卸し」が必要になる。

システムに必要な環境の確認（インフラ、ハード、ソフト、ミドルウェア、外部サービスなど）
ファイルの徹底的な収集（更新日が重要なので収集中は開かない）
稼働タイミングの把握（常時実行、定期実行、アドホック）
前任者が残したメモ、メール、チャットなどからの情報収集
コード内のコメントやソース管理ツールの更新日時を拾う

これらの情報を集め、種類を問わず時系列に並べる。
個別では見えていないことも複数の情報をまとめることで見えてくる。
こうした作業はAIが得意としているため、顧客と相談の上で使用するのもありだろう。

棚卸のための情報収集は実務部門や情報システム部門など関係先すべて。
システムに関わっている人々が「当たり前」と思っているところにも引継ぎに必要な知見があるかもしれない。

◆引継ぎ期間が残っているのなら
前任者に確認できる時間があるなら、仕様やソースの説明より「システム的に地雷な場所」を優先して聞くべき。
「この操作をするとエラーになりがち」「月末だけ動作が変わる」「この問い合わせのときはいつもこう作業している」などの経験から来る知見はドキュメントに残らない。
属人的な知見や経験則の収集が重要となる。

様々な場所と角度で情報を引き出し、時系列で情報の棚卸をするのが引継ぎの第一歩となる。

フェーズ1 延命－まず「止めない」ことが最優先

棚卸が終わったら次のゴールは明確で、「明日も動き続けること」になる。
このフェーズでは決して改修や改善をしてはいけない。
実務に合っていない動作があっても、明確にコードがおかしくても、現代では非効率な処理があっても、サポート期限切れのハードやソフトを使っていても、手を出す前に「今それをする必要があるか」を問うべき。
どうであれ業務が回っているシステムに手を出す理由はない。

ただ、動いているシステムは壊れる。
これは経験則であり、誇張でも脅しでもない。
何かが壊れたことすら理解できないうちに次が壊れることもある。
棚卸をした程度ではブラックボックスの中身は到底把握できてない。
この状態での修正や改善は予測できない副作用を生む。
まずは「触らない箇所」を明確化し、運用を回すことに集中する。

実行環境は可能な限り温存する（丸ごとバックアップ推奨）
正常動作時のI/Oをサンプルとして保存しておく（エラーI/Oほど残っていないはず）
「触らない箇所」と「触っていい箇所」を明文化する
異常時の対応手順から整備する（誰でも対応できる粒度）

とにかくできるだけ現状を温存し、運用を回す。
正常でも異常でもとにかく「見る」。
引継ぎ最初の棚卸で得た様々な知見がここで生きてくる。
そして異常時の対応に集中し、対応パターンを積み上げていく。

このフェーズは「諦め」ではなく「戦略的な停滞」である。
やることを取捨選択するのは「諦め」ではないのだ。
運用しながらコードを読み、資料との整合性を確かめ、業務とロジックの整合性を少しずつ解読していく。
顧客からも業務的な観点での説明を受け、理解を深めていく。
変えずに理解するための「戦略的な延命」なのだ。
動きが小さいため顧客も我々ももどかしい時間ではあるが、この時間は後のフェーズで必ず生きてくる。

フェーズ2 転生－業務を継続するために

コンバートは転生ではない

運用が安定し、関係者全体でシステムの全体像が共有されていくと「業務仕様はそのままで新環境に移したい」という話が出てくる。
この手の話のときは往々にしてサポートの切れたハードやソフトが使われていることが多く、最新化したいという話がセットで期待されがち。
システム自体も操作感や見た目を今風にしたいなど、フレームワーク以上のアップデートを期待されることも多い。

こうした期待されるパターンは多々あるが、要は「業務仕様に関わるところはそのままで、技術的なところを最新に更新したい」という希望に集約される。
いわゆる「コンバート」というアプローチの選択肢。
もちろん、コンバートによって得られるものがある。

保守性の向上：現代的な言語や開発環境への移行により開発者を確保しやすくなる
環境依存の解消：特定のOSやバージョンへの縛りから解放される
ユーザービリティの向上：UIや環境の世代が進むことでより使いやすく見やすくなる

特に情報システム部門から求められることが多い。
サポートが切れ故障した際に対応してもらえないものを抱えたくない気持ちは理解できる。
だが、コンバートでは得られないものもある。

仕様の正しさ：コードを単純に変換するだけでは業務的な正しさは検証されない

コンバート最大の落とし穴は「動くコードを移す」ことと「正しいシステムを作る」ことを混同しがちなところ。
業務仕様を破綻させないためにコードを忠実に移植すると、廃止された処理、誰も使っていない機能、古い設計のまま現在の業務に適合しない仕様など、すべてそのまま新しい環境に移ってくる。
これは「正しいシステムを作る」のではなく、「延命の延長」を行っているに過ぎない。
ただし「延命の延長」であることを理解し、その先も見据えているのであれば、中間地点での有効な選択肢となるため検討の余地は多分にある。

業務から問い直すことが転生

レガシーシステムの引継ぎを経験すると決まってある問いが浮かぶ。
「このシステムがなければ、今の業務とシステムはどう設計しただろうか」

長年動き続けたシステムには業務や時代の変化を吸収できずに蓄積した「ズレ」がある。
その意味も分からなくなったコードやファイル、念のためにと削除されないデータ、システムに格納できないからとExcelなどに分散した情報。
時代の進歩によってより良い方式が一般化したのに、取り込まれないままレガシーな手法を使い続けるなども含まれる。
こうした「誰も触れなかった部分」が引継ぎという機会に顔を出す。
無視して進んでもリスクの先送りに過ぎず、いつか「ズレ」から破綻が起きてしまう。

最もリスクが低いのは、実は「一度立ち止まって考え直す」こと。
改めて業務の棚卸しから始め、本当に必要な機能と不要になった機能を仕分けし、現在の業務フローに合ったシステムをゼロから設計する。
これが業務から問い直すという選択肢。
大規模なプロジェクトをいきなり立ち上げる必要はない。
「この画面が何のために存在するのか」「このジョブが出すファイルが何のために存在するのか」を関係者に聞いて回るだけでも、業務の実態が見えてくる。
引継ぎ最初の棚卸で得た様々な知見がここで生きてくる。
ここから設計が新たに始まり、システムは転生に向かう。

引継いで延命するだけではなく、転生を提案したい

ここまで「開発部分が属人化したレガシーシステム」の引継ぎ・延命・転生について書いてきた。
確かに属人化した部分の掘り起こしや引継ぎは大変な作業となる。
だがこれは個人の責任ではなく、記録し・共有し・引き継ぐ仕組みを作れなかった、あるいは仕組みを作る必要性を感じる機会がなかった組織の問題と考える。
その意味で、今回のような引継ぎは「失敗の後始末」ではなく、組織がシステムと業務の関係を問い直す、数少ない機会になるのではないだろうか。

「延命か転生か」という問いに対する答えは、最終的には「業務をどうしたいか」に行き着く。
システムはあくまで業務を回すための手段であり、目的ではない。
レガシーシステムが寿命を迎えたとき、それはシステムを作り直す機会ではなく、業務そのものを設計し直す機会だ、と考えるところから始めてはどうだろうか。

まとめ

レガシーシステムの引継ぎは苦難でも終点でもない。
システムは業務の写し鏡であり、組織の歴史そのもの。
業務とシステムの「ズレ」も、システムに対する優先順位の中で「今じゃない」と判断され続けた結果として積み上がったもの。
引継ぎはその清算であり、同時に次の設計への出発点でもある。

延命は現実的な選択だ。
コンバートも状況によっては有効な中間地点になる。
だが、どちらも「業務をどうしたいか」という問いを避けたまま進めば、同じ課題を別の形で先送りするだけになる。
レガシーシステムの引継ぎという、組織が否応なく立ち止まるそのタイミングこそ、問いに答える機会ではないだろうか。

弊社は引継いで動かし続けることだけを目標にするつもりはない。
業務とシステムの関係を問い直し、次の設計につなげることまでを、一緒にやりたいと思っている。

文責：ビジネスソリューション部東海林秀晃