システム担当者の退職・引き継ぎ｜辞めた後の対処も

「受発注や在庫のシステムを分かっているのが一人だけで、その人が来月で退職します」「担当者はもう辞めてしまい、サーバーがどこにあるのかも分かりません」「障害が起きたら誰も直せず、業務が止まるのではないかと不安です」。社内で作ったシステムや外注したシステムを一人の担当者に任せてきた企業から、こうした声が聞かれます。この記事では、退職が決まった段階で何から引き継ぐかの優先順位と、聞き取って記録する項目の確認表、すでに辞めてしまった後の進め方、作り直すかどうかの判断基準と再発防止の方法をお伝えします。

システムのブラックボックス化とは

経済産業省のレガシーシステムモダン化委員会総括レポートは、レガシーシステムの特徴の一つに「システムのブラックボックス化」を挙げています。仕様や設計のドキュメントが整備されておらず、運用維持保守が属人的な状態に陥り、障害が起きても原因をすぐに特定できない状態です。同じレポートは、古い技術から脱却済みのシステムでも、運用維持保守に問題があれば再びレガシー化する可能性があるとも述べています。

つまり、ブラックボックス化は古い大型システムだけの問題ではありません。Access や Excel VBA で作った受発注・在庫管理、社内で作ったWebシステム、外注して納品された顧客管理システムでも、分かっている人が一人しかいなければ同じことが起きます。

退職で困るのは「プログラム」より周辺の情報

担当者がいなくなって最初に困るのは、プログラムの中身よりも、その周りの情報であることが多くあります。

困ること	起きる場面
管理者のパスワードが分からないこと	サーバーやクラウドの設定を変えたい、障害を調べたい場合
契約やドメインが個人の名義になっていること	更新の案内が退職者のメールアドレスに届き、気づかないまま期限が切れる場合
定期実行の処理が何をしているか分からないこと	夜間の集計やデータ連携が止まっても、誰も気づかない場合
バックアップの有無と戻し方が分からないこと	故障や誤操作でデータが消えた場合
例外処理の理由が分からないこと	「この取引先だけ別の計算になる」理由を説明できず、直してよいか判断できない場合

プログラムは、時間をかければ外部の技術者が読み解けます。一方で、パスワードや契約の名義、例外処理の理由は、本人がいなくなると取り戻すのに手間がかかり、取り戻せないこともあります。引き継ぎの順番は、この「取り戻しにくさ」で決めます。

退職が決まったら：止まると困る順に引き継ぐ

退職までの期間は限られており、すべてを文書にする時間はありません。完璧な設計書を目指すより、止まると困るもの、取り戻しにくいものから順に押さえます。

優先	引き継ぐもの	理由
1	アカウント・パスワード・契約・名義	本人がいなくなると、取り戻すのに手間がかかります
2	定期実行の処理とバックアップ	止まると業務が止まり、データを失うおそれがあります
3	障害時の対応	起きたときに誰も動けないと、復旧が長引きます
4	日常の運用とよくある問い合わせ	後任が明日から困らないために必要です
5	ソースコードと改修の方法	後から外部の技術者が読み解ける部分もあるため、最後でよい場合があります

始める前に、引き継ぎを受ける人を決めておきます。社内に詳しい人がいなければ、引き継ぎを受ける社内の担当者を一人決め、技術的な内容は外部の技術者に同席してもらう形も現実的です。社内の担当者が「何がどこにあるか」を、外部の技術者が「技術的に何をしているか」を受け取ると、聞き漏らしが減ります。

聞き取りと記録の確認表

次の項目を、担当者に聞きながら一つずつ埋めていきます。表計算ソフトの一覧で十分です。IPA（情報処理推進機構）が公開している中小企業の情報セキュリティ対策ガイドラインには、付録として資産管理台帳のサンプルもあり、一覧の項目を考える際の参考になります。

1. 何が動いているかの一覧

システムの名前と、どの業務で誰が使っているか
動いている場所（社内のサーバー、担当者のパソコン、クラウド、レンタルサーバー）
使っているソフトと版（Access、Excel、データベース、OS など）
止まったときに困る度合い（その日のうちに困るか、月末まで待てるか）
すでに使われていない機能やファイル

担当者のパソコンの中だけで動いているマクロや、机の下に置かれたサーバーがないかも確認します。退職後にパソコンを初期化してしまうと、そこで動いていた処理ごと消えるためです。

2. アカウント・契約・名義

サーバー、クラウド、ドメイン、SSL証明書、各種SaaSの契約先と契約者の名義
支払い方法（会社のカードか、担当者個人の立て替えか）と更新日
管理者アカウントの一覧と、ログインに使うメールアドレス・電話番号
二段階認証の受け取り先（担当者個人のスマートフォンになっていないか）
パスワードの保管場所

二段階認証の受け取り先が個人のスマートフォンのままだと、パスワードが分かってもログインできません。在籍中に、会社で管理する端末やアドレスへ切り替えてもらいます。パスワードは引き継ぎの文書に直接書かず、会社で管理するパスワード管理の仕組みに移しておくと安全です。

3. 定期実行の処理とバックアップ

毎日・毎週・毎月動く処理の一覧（集計、データの取り込み、帳票の出力、メールの送信など）
処理が動く時刻と、正しく動いたかの確かめ方
バックアップの対象、取得の頻度、保存先
バックアップから戻す手順と、最後に戻せることを確かめた日

IPAの5分でできる！情報セキュリティ自社診断では、バックアップの対策例として、定期的に取得することに加え、バックアップしたデータを戻せるか定期的に確認することを挙げています。バックアップを取っているつもりでも、戻し方を知っているのが本人だけなら、いないときには使えません。在籍中に一度、本人の立ち会いのもとで戻す手順を試しておくと確実です。

4. 外部との連携

データをやり取りしている先（会計ソフト、ECサイト、取引先のシステム、銀行など）
やり取りの方法（ファイルの受け渡し、API、メール、手作業での取り込み）
連携先の窓口と連絡先
連携の形式が変わったときに直す場所

5. 障害時の対応

これまでに起きた障害と、そのときの直し方
止まったときに最初に確認すること（再起動してよいか、触ってはいけない所はどこか）
外部の保守業者や開発会社がいる場合の連絡先と契約の範囲
業務を手作業で続けるときの代わりの手順

6. ソースコードと変更の履歴

ソースコードやマクロの置き場所と、最新版がどれか
本番で動いているものと、手元のファイルが同じか
変更の履歴（いつ、何のために直したか）が残っている場所
開発や修正に使っている環境とツール

外注したシステムの場合は、ソースコードや設計書を受け取っているか、保守の契約がどうなっているかも確かめます。開発会社との契約が終わる場合の注意点は、開発ベンダーとの契約終了と引き継ぎで説明しています。

7. 日常の運用・問い合わせ・例外処理

利用者からよく来る問い合わせと、その答え
担当者が手作業で直しているデータや、月末だけの特別な作業
例外処理（特定の取引先・商品だけ扱いが違うなど）と、そうしている理由
業務の変更で今後直す予定だった箇所

例外処理の理由は、聞いておかないと後で誰にも分かりません。「なぜそうなっているか」が分かれば、作り直すときに残すか捨てるかを判断できます。

記録を残すときの工夫

退職までの短い期間で、文章だけで引き継ぐのは困難です。次のような工夫で、本人の負担を減らしながら情報を残せます。

操作の画面録画：日次や月次の作業、障害時の確認を、本人に画面を録画しながら説明してもらいます。文書を書くより短時間で済み、後任が何度でも見直せます。
後任が操作し、本人が横で見る：説明を聞くだけでなく、後任や外部の技術者が実際に操作し、本人が確認します。分かったつもりの箇所が見つかります。
一覧と手順を先に：設計書を一から書くより、確認表の一覧と、主な作業の手順書を優先します。細かい仕様は、後からソースコードを読んで補えます。
質問をまとめて聞く時間を取る：聞き取りを一度で終わらせず、記録を見直して出てきた疑問を、退職日の前に改めて聞く時間を確保します。

アカウントの扱いにも順番があります。IPAの自社診断では、従業員の異動や退職時には速やかに設定を変更（削除）することを対策例に挙げています。ただし、管理者権限や契約の名義を移す前に退職者のアカウントを止めると、設定を変えられなくなったり、更新の案内が届かなくなったりします。先に名義と管理者権限を会社側へ移し、そのうえで退職者のアカウントを止める順番にします。

すでに辞めてしまった後の進め方

担当者がすでに退職している場合も、慌てて作り直しを決める必要はありません。次の順で進めます。

1. 現状を棚卸しする

まず、何が動いているかを調べます。手がかりになるのは次のようなものです。

請求書やカードの明細（サーバー、ドメイン、クラウド、SaaSの契約先が分かります）
社内のサーバーやパソコンに入っているソフト、定期実行の設定
退職者の業務用メールに届いている更新の案内やエラーの通知
利用者への聞き取り（どの画面を、いつ、何のために使っているか）

確認表の項目のうち、分かったものから埋めていきます。分からない項目が残っていても構いません。何が分かっていないかが見えること自体に意味があります。

2. まず止めないための手を打つ

中身を理解する前に、止まったときの被害を小さくする手を打ちます。

今のデータとプログラムのバックアップを取り、別の場所に保管します
ドメインや証明書、サーバー契約の期限を確かめ、更新の案内が会社の誰かに届くようにします
定期実行の処理が動いたかを、毎日だれかが確かめるようにします
管理者権限が分からないサービスは、提供元の正規の手続きに沿って、会社としての権限を回復します

この段階では、プログラムの修正や設定の変更は最小限にします。仕組みが分からないまま触ると、別の場所が止まることがあるためです。

3. 外部の専門家に解析を頼む

社内に読み解ける人がいなければ、外部の技術者にソースコードや設定を調べてもらい、仕様を文書に起こします。先のレポートも、ブラックボックス化したシステムの仕様を復元・ドキュメント化することで属人性を排除し、担当者が代わってもナレッジを引き継げるとしています。

依頼するときは、「何が動いているかの一覧」「障害時の対応手順」「改修するときに直す場所」のように、作る文書の範囲を先に決めると、費用と期間を見積もりやすくなります。

4. 使い続けるか、作り直すかを決める

解析の結果を見て、次の章の基準で判断します。

作り直すか、今のまま使うかの判断基準

担当者がいなくなったことを機に、すぐ作り直すのが正解とは限りません。業務に合っていて、仕組みが単純なら、文書を整えて保守できる人を決めれば使い続けられます。

選択肢	向いている場合
文書を整えたうえでの継続利用	業務に合っていて、仕組みが単純で、外部の技術者が読み解ける場合
一部を直しながらの継続利用	全体は使えるが、障害の多い箇所や使われていない機能がはっきりしている場合
標準的なSaaSやパッケージへの置き換え	会計や勤怠など、他社と同じやり方で困らない業務の場合
必要な機能だけの作り直し	自社独自の業務の流れがあり、使う技術が古く保守できる人が見つからない場合

判断の材料になるのは、次の点です。

使っている技術（古い版のソフトやOS）を扱える人を、社内か社外で確保できるか
業務の変化に合わせて直す頻度が高いか
止まったときの影響がどこまで及ぶか
解析と保守にかかる費用と、作り直しの費用の比較

Access や Excel のマクロで回している業務を移すかどうかは、Excel管理の限界サインとシステム化の判断で詳しく扱っています。パッケージに追加開発を重ねたシステムで、仕様を知るのがベンダーだけになっている場合は、基幹システムの追加開発費用が高い理由と打ち手も参考になります。作り直すと決めた場合の進め方は、基幹システムリプレイスの進め方で説明しています。

作り直すときは、今のシステムの機能をそのまま写すのではなく、業務を棚卸しして必要な機能だけに絞ります。例外処理の理由を聞き取れていれば、ここで残すか捨てるかを判断できます。医療卸の基幹システム刷新では、業務を工程単位で棚卸しして再設計し、稼働後も保守運用と機能追加を続けて、業務の変化に合わせて拡張できる状態を保っています。

再発防止：一人に頼らない体制をつくる

引き継ぎが落ち着いたら、同じことを繰り返さない仕組みを整えます。

主担当と副担当の二人体制：日常の作業を交代で行い、障害対応にも二人が関わるようにします。社内で二人を確保できなければ、外部のエンジニアを副担当に置く方法もあります。
更新され続ける文書：確認表の一覧と手順書、操作の録画を共有の場所に置き、システムを直したら一緒に更新することを作業の手順に組み込みます。
アカウントと契約は会社の名義に：契約者は会社、連絡先は個人ではなく共有のアドレスにし、管理者権限は複数の人が持つようにします。
外部パートナーとの保守契約：障害時の対応と、定期的な点検を引き受けてもらいます。契約の範囲（何を、どの時間帯に、どこまで対応するか）を文書にしておきます。
標準的な仕組みへの置き換え：独自に作る必要のない業務は、標準的なSaaSやパッケージに移し、保守しなければならない範囲を小さくします。

先のレポートは、システムの仕様を可視化するなどのブラックボックス対策に取り組む企業ほど、内製化が進む傾向があるとしています。仕様が見えるようになると、社内で直すか外部に任せるかを選べるようになります。外部のエンジニアやPMを加えて体制を組む方法は、開発体制支援でご紹介しています。開発ベンダーとの契約終了に合わせて、社内にエンジニアがいない状態から開発組織を立ち上げた例も支援実績に載せています。

まとめ：退職前は「取り戻しにくいもの」から引き継ぐ

システムのブラックボックス化は、ドキュメントがなく運用が属人的で、障害の原因をすぐに特定できない状態です。古いシステムに限らず、Access や社内のWebシステムでも起きます。
退職が決まったら、アカウント・契約・名義、定期実行の処理とバックアップ、障害時の対応、日常の運用、ソースコードの順に引き継ぎます。
聞き取りは確認表で漏れを防ぎ、画面録画や後任による実演で、文章にしにくい操作を残します。退職者のアカウントは、名義と権限を移してから止めます。
すでに辞めてしまった場合は、棚卸し、止めないための手当て、外部の技術者による解析の順に進め、そのうえで使い続けるか作り直すかを決めます。
再発を防ぐには、二人体制、更新される文書、会社名義のアカウント、外部パートナーとの保守契約、標準的な仕組みへの置き換えを組み合わせます。

既存システムの現状調査や解析から、保守の引き受け、必要な機能だけの作り直しまでご相談いただけます。どこから手を付ければよいか分からない段階でも、システム開発の支援の内容をご覧のうえ、お気軽にお問い合わせください。