あのシステムを触れるのは社内で1人だけ。その人が来年で定年を迎える、あるいは転職の意思を伝えてきた。設計書は残っておらず、改修はその人の頭の中にある手順で回してきた。刷新の予算はすぐには取れない。この状況で何から手を付ければいいのか、というところで止まっている方に向けて書きます。
先にお伝えすると、打ち手は残り期間で決まります。1か月しかないなら情報を残すことだけに集中する、半年あるなら外部への引き渡しを設計できる、1年以上あるなら刷新も選択肢に入る。全部やろうとすると全部が中途半端になります。この記事では、残り期間ごとの打ち手、引き継ぎ・外部委託・刷新の選び分け、人が抜ける前に社内で確定させる情報、そして外に出すときの範囲と契約までを整理します。保守料の相場や刷新の進め方そのものは別の記事に譲ります。
この記事のポイント
- 打ち手は残り期間で決まる。1か月・半年・1年以上で取れる選択肢が違う
- 引き継ぎ・外部委託・刷新は三択で、予算と業務の変更予定で選び分ける
- 本人がいるうちに確定させるのは手順書ではなく「なぜそうなっているか」の理由
- 古い環境は外部に断られることがある。断られた前提の打ち手も用意しておく
目次
レガシーシステムの人材不足で先に決めること
最初にやるのは、外注先を探すことでも刷新の計画を立てることでもありません。あと何か月あるのかを確認し、それに合わせて狙いを1つに絞ることです。ここを曖昧にしたまま並行して動かすと、引き継ぎも外注検討も刷新計画も全部が浅くなります。
残り期間で取れる手は変わる
まず現実的な話として、退職までの期間で選べる打ち手はかなり違います。目安を整理すると次のようになります。
| 残り期間 | 狙うこと | 現実的でないこと |
|---|---|---|
| 1か月以内 | 情報を本人から取り出して残す | 外注先の選定・刷新の検討 |
| 3〜6か月 | 情報を残し、保守の引き渡し先を決める | 全面刷新の着手 |
| 1年以上 | 引き渡しに加えて刷新の判断まで進める | ー |
1か月しかない場合、外注先を探しても間に合いません。候補を集めて話を聞き、範囲を決めて契約するだけで通常1〜2か月はかかります。この期間なら、本人が在職しているうちに情報を取り出すことに全振りしたほうが、結果的に後の選択肢が広がります。
逆に1年以上あるなら、引き継ぎと並行して刷新の判断まで進められます。ただしこの場合も、最初の3か月は情報の取り出しに使ってください。現行が分からないまま刷新を検討しても、開発会社から出てくる見積もりの前提が揃わないからです。
ちなみにこれは自社だけの問題ではありません。IPAが公開しているDX動向2024では、人材不足はIT企業よりも事業会社のほうで深刻化していると指摘されています。発注する側に人が足りないのは構造的な問題なので、社内で育て直すより外の力を借りる前提で考えたほうが現実的です。
引き継ぎ・外部委託・刷新の選び分け
打ち手は大きく3つあります。社内の別の人に引き継ぐ、保守を外部の会社に出す、この機会に刷新する。どれか1つを選ぶというより、組み合わせが決まります。
社内で引き継げるのは、後任にできる人がいて、かつシステムの改修頻度が低い場合です。年に数回の軽微な変更で済んでいるなら、手順を残して別の担当が回すことは可能です。ただし「PCに詳しい若手」に任せるのは避けたほうがいいです。触れることと、なぜその処理になっているかを判断できることは別物なので、業務を知らない人に渡すと止まったときに動けません。
外部に出すのが向くのは、改修が定期的に発生していて、業務のやり方を当面変える予定がない場合です。逆に、2〜3年以内に業務そのものを変える構想があるなら、保守を延命するより刷新に予算を寄せたほうが総額では安くなることがあります。その場合はレガシーシステムの刷新は誰に頼む？開発会社の選び方のほうを先に見ていただくと、依頼先の探し方から入れます。
実務でよくあるのは、外部委託と刷新を組み合わせる形です。まず保守を外に出して止まらない状態を作り、そのうえで1〜2年かけて刷新を検討する。人が抜けるタイミングと刷新の準備期間はふつう合わないので、間をつなぐ手を用意しておくと判断に余裕が生まれます。
人が抜ける前に確定させる情報
ここが本記事で一番お伝えしたい部分です。引き継ぎというと操作手順書を作ってもらうことを想像しがちですが、手順書は本人がいなくなった後でも画面を見れば分かります。本人がいるうちにしか取れないのは「なぜそうなっているか」の理由のほうです。
本人がいるうちに確定させること
- 年に1回しか動かない処理はどれで、いつ・誰のために動かすのか
- 例外処理が入っている箇所と、そう作った理由（どの取引先・どの業務の都合か）
- 触ってはいけない設定と、その理由
- 外部とつないでいる先の一覧と、担当者の連絡先
- 過去に起きた障害と、そのときの対処方法
- 本人が「これは自分しか分からない」と感じている箇所
最後の項目は、本人に直接聞くのが早いです。「引き継ぎで一番心配なところはどこですか」と尋ねると、本人はたいてい即答できます。網羅的なドキュメントを求めるより、この一問のほうが実りが大きいことが多いです。
社内でこの棚卸しをする時間が取れない場合は、外部に調査だけを頼む方法もあります。本人が在職しているうちに調査会社を入れると、ヒアリングができるぶん精度が上がって費用も抑えられます。どこまで調べれば足りるかはレガシーシステムの解析はどこまで必要？費用と頼み方で整理しています。
口頭説明ではなく現物で残す
引き継ぎが失敗する典型が、会議室で口頭説明を受けて終わるパターンです。聞いているときは分かった気になりますが、いざ本番で作業するとどこを押すのかで詰まります。
有効なのは、本人に実際に操作してもらいながら画面を録画することです。月次の締め処理や年次の切り替えのように、頻度が低くて重要な作業ほど効きます。文章に起こす手間もかからず、後任は同じ画面を見ながら再現できます。加えて、実行後に出力される帳票やログの現物を保管しておくと、次に動かしたときの答え合わせに使えます。
もうひとつ、意外に効くのが「本人が困ったときにどこを見ていたか」を記録することです。特定のログファイル、古いメール、手書きのメモ。属人化しているシステムほど、正式な資料ではないところに答えが眠っています。退職時にそれらが処分されてしまうと、後から取り戻せません。
レガシーシステムの人材不足を外部で補う進め方
ここからは外に出す場合の実務です。「保守をお願いします」とだけ伝えると、断られるか、高い見積もりが返ってくるかのどちらかになりがちです。範囲を切り分けて渡すのがコツになります。
保守を外に出す範囲の決め方
保守と一言でいっても、中身は分かれています。動いているかを見る監視、止まったときに直す障害対応、業務の変更に合わせて手を入れる改修。この3つは必要なスキルも費用も違うので、まとめて出す必要はありません。
実務で現実的なのは、監視と障害対応を先に出し、改修は当面自社で抱えるか、都度見積もりにする形です。監視と障害対応は手順が決まっていれば引き受けやすく、古い環境でも対応してくれる会社が見つかります。一方で改修は、中身を理解する時間が必要になるため単価も上がりますし、引き受け自体を渋られることがあります。
費用の目安や、いま払っている保守料が妥当かどうかを確かめたい場合は、基幹システムの保守料は妥当？相場の見方と保守切れの対応のほうで相場の見方を整理しています。
引き受けてもらえないと言われたら
古い環境では、実際に断られることがあります。技術者がいない、部品の調達ができない、責任を負えない。これは相手の都合なので、粘っても変わりません。断られた前提で用意しておきたい打ち手が3つあります。
1つ目は、現行を作ったベンダーに範囲を絞って残ってもらうことです。全面的な保守は無理でも、障害時のスポット対応だけなら受けてくれることがあります。年間契約ではなく、発生時に時間単価で払う形にすると相手も引き受けやすくなります。
2つ目は、その言語や環境を専門にしている会社を探すことです。COBOLやオフコンのように扱える会社が限られる領域では、大手より中小の専業会社のほうが対応できることがあります。3つ目は、保守で粘らず刷新の前倒しに切り替える判断です。保守の引き受け手がいないという事実は、それ自体が刷新のタイミングを示すサインでもあります。
契約で決めておく3点
引き受けてもらえることになったら、契約で次の3点を決めておくと後が楽になります。どれも曖昧なまま始めると、揉める箇所です。
1つ目は対応時間です。平日日中のみか、夜間や休日も含むか。基幹系で夜間バッチが動いているなら、止まったときに誰がいつ動くのかを決めておかないと、朝まで放置ということが起こります。2つ目は調査費用の扱いです。原因が分からない障害を調べる時間を、保守料に含めるのか別途請求にするのか。古いシステムほど調査に時間がかかるので、ここは金額に直結します。
3つ目は撤退の条件です。相手が保守をやめる場合に何か月前に通告してもらうか、そのときにどの資料を引き渡してもらうか。1社に頼らざるを得ない状況だからこそ、抜けるときの条件を先に決めておく価値があります。
外に出しても社内に残る役割
最後に、外部に任せても自社側に必ず残る仕事があります。ここを空席にすると、契約したのに回らないという状態になります。
残るのは、業務側の判断です。この改修は必要か、いつまでに反映するか、優先順位はどうするか。外部の会社は「どう作るか」は決められますが、「やるかどうか」は決められません。加えて、現場からの問い合わせを受けて外部に渡す窓口も社内に要ります。専任である必要はありませんが、担当者は決めておいてください。
保守の引き受け先を複数社から探す段階に入るなら、各社に同じ前提で情報提供を求めると比較しやすくなります。RFI（情報提供依頼書）テンプレートを使うと、対応可能な範囲や体制を同じ様式で聞けます。
レガシーシステムの人材不足についてよくある質問
- Q. 退職まで1か月しかない場合、何を優先すべきですか？
- A. 情報の取り出しに絞ってください。外注先の選定は候補集めから契約まで1〜2か月かかるので、この期間では間に合いません。年1回しか動かない処理、例外処理を入れた理由、触ってはいけない設定、外部連携先の連絡先。この4つを本人から聞き取り、可能なら操作を録画してください。外部への引き渡しは、その情報が残っていれば後からでも進められます。
- Q. 社内の若手に引き継がせるのは無理がありますか？
- A. 改修頻度が低ければ可能です。ただし操作できることと、なぜその処理になっているかを判断できることは別です。業務を知らない人に渡すと、想定外のことが起きたときに動けません。引き継ぐなら、その業務を分かっている人を選び、判断が必要な場面では外部に相談できる先を確保しておくのが現実的です。
- Q. 保守を引き受けてくれる会社が見つからない場合は？
- A. 範囲を狭めて聞き直してください。全面的な保守は断られても、障害時のスポット対応だけなら受けてもらえることがあります。現行を作ったベンダーに時間単価で残ってもらう形も有効です。それでも見つからない場合、引き受け手がいないという事実自体が刷新すべきタイミングを示しているので、保守で粘るより刷新の前倒しを検討したほうが安全です。
- Q. 退職者に再委託や顧問契約で残ってもらうのはどうですか？
- A. つなぎとしては有効ですが、期限を切って使ってください。無期限にすると属人化がそのまま続き、結局いつか同じ問題が起きます。契約する場合は「この期間内に外部委託先へ引き渡す」「この資料を作成する」といった成果物を決めたうえで、6か月から1年程度の区切りにするのが現実的です。
- Q. 引き継ぎ資料はどこまで作ってもらうべきですか？
- A. 網羅的な設計書を求めると、退職までに終わりません。優先度は「なぜそうなっているかの理由」が最も高く、次が例外処理と外部連携の一覧、操作手順は最後です。手順は画面を見れば後から分かりますが、理由は本人がいなくなると誰にも復元できません。限られた時間は理由の記録に使ってください。
