社内SEの退職が決まったら？経営者が確認すべき引き継ぎチェックリスト

「来月で退職させてください」——社内のシステムを一手に担ってきた社内SEから、そう切り出された。その瞬間、多くの経営者が同じ不安に襲われます。「あのシステム、〇〇さんが抜けたあと、いったい誰がどう回すんだ？」

社員1人、あるいは少人数で業務システムやITインフラを支えてきた会社ほど、社内SEの退職は単なる欠員では済みません。下手をすれば、システムの中身が誰にも分からなくなり、ある日突然業務が止まる——そんな事態に直結します。

とはいえ、退職日までの時間は限られています。本記事では、社内SEの退職が決まったときに、経営者として「何を、どの順番で確認・回収すべきか」を引き継ぎチェックリストとして整理しました。技術に詳しくなくても、これを片手にSEへ確認していけば、最悪の事態は避けられます。

結論：技術がわからなくても、この順番で押さえれば大丈夫

引き継ぎ資料をゼロから完璧に作らせる時間は、まずありません。それでも、優先順位を間違えなければ大丈夫です。経営者として確認すべき順番は次のとおりです。

アカウントと管理者権限（システムの「鍵」）：会社側がこれを握れていないと、後任は何もできません。最優先で回収する。
障害が起きたときの連絡先と対応手順：止まったときに「誰に連絡し、どう直すか」。
定期的に発生する更新・運用作業：放置すると数か月後に事故るもの（ドメインやサーバー証明書の更新など）。
仕様書・構成図などのドキュメント：上の3つを押さえたうえで、時間の許す範囲で進める。

特に1番のアカウント権限だけは、何を差し置いても在職中に回収してください。ここを取り損ねると、お金でも解決できない事態になりかねません。

社内SEの退職を甘く見ると起きること

「今も動いているし、引き継ぎはほどほどでいいだろう」——この油断が、あとで一番高くつきます。実際に何が起きるのか、先に知っておきましょう。引き継ぎで何を優先すべきかが見えてきます。

システムの中身が誰にもわからなくなる（ブラックボックス化）

最も多いのが、システムのブラックボックス化です。プログラム本体（ソースコード）は残っていても、それが「どのサーバーで」「どんな仕組みで」動いているのかを書いた最新の資料がない、というケースは珍しくありません。

こうなると、エラーが出てもどこを直せばいいのか分からず、ちょっとした修正すら外部の業者に断られてしまいます。中身の読めないシステムは、プロでも手を出しにくいのです。

障害が起きても、誰も復旧できない

システムは「動いているから安全」ではありません。サーバーの停止、データベースの容量不足、連携先サービスの仕様変更など、運用中は常にトラブルの芽を抱えています。

引き継ぎが不十分なまま担当者が不在になると、いざ障害が起きたときに「誰に連絡すればいいのか」「どのアカウントで入って直すのか」すら分からず、業務が長期間止まりかねません。止まった時間は、そのまま売上の損失と顧客の信用低下になります。

セキュリティ対策が止まり、ある日事故が起きる

OSやプログラムの弱点（脆弱性）は日々見つかっています。専任の担当者がいなくなると、その修正（セキュリティパッチの適用）や、サポートが終了した古い環境への対応がぴたりと止まります。

放置された弱点は、ランサムウェアによる被害や情報漏えいの入り口になります。中小企業にとっては、これ一発で事業の継続が危うくなりかねない、最も避けたいシナリオです。

社内SE退職時の引き継ぎチェックリスト【経営者向け・網羅版】

ここからは具体的な確認項目です。技術用語が並びますが、すべてを理解する必要はありません。「これは引き継ぎ資料にありますか？」「会社のアカウントで入れますか？」とSEに一つずつ確認していくための一覧として使ってください。

1. アカウント・管理者権限の回収（最優先）

システムを動かすための「鍵」です。1つでも欠けると、後任は手も足も出せません。ポイントは、これらが個人ではなく会社の管理下にあるか。退職するSE個人のメールアドレスやスマホに紐づいていると、退職後はログインすらできなくなります。

サーバー（AWS、GCP、レンタルサーバーなど）の管理者アカウント
ドメイン管理サービスのアカウントと更新期限・支払い方法
SSL証明書（サイトURLの鍵マーク）の管理画面と更新期限
データベースの接続情報（ホスト名、ID、パスワード）
外部サービスや決済システムと連携するための認証キー
Microsoft 365、Google Workspace など社内で使うクラウドサービスの管理者権限
社内ネットワーク機器（ルーター、VPN、Wi-Fi）の管理パスワード
インターネット回線の契約情報

各種サービスがSE個人のメールアドレスや、本人のスマホの認証アプリで登録されていると、退職後はパスワードの再発行すらできなくなります。在職中に会社共有のアドレスへ管理者を移し、二段階認証の設定変更まで終わらせてください。「あとで」が一切効かない項目です。

2. 稼働システムとソースコードの所在

今動いているシステムが「どこに」「どんな形で」あるのかを明らかにします。設計図にあたるソースコードが、退職とともに行方不明になる事故は後を絶ちません。

本番環境・テスト環境のサーバー構成とIPアドレス
ソースコードの保管場所（GitHubなどのサービス、社内サーバーなど）と、会社がアクセスできるか
システムを更新（本番環境へ反映）する手順
毎日・毎月など自動で動いている処理（バッチ）の一覧と実行タイミング

3. バックアップと復旧手順

見落とされがちですが、ここはほぼ最重要です。「バックアップを取っています」という言葉を鵜呑みにせず、そこから本当に元に戻せるのかまで確認してください。

何を、どこに、どのくらいの頻度でバックアップしているか
障害時に元に戻す（復元する）具体的な手順
直近で一度でも「戻せること」を試した実績があるか

バックアップは「取れている」ことより「戻せる」ことが大事です。可能であれば退職前に、SEと後任（または外部業者）で一度、実際に復元を試しておくと安心です。本番のときに初めて「戻せなかった」と判明するのが最悪のパターンです。

4. 定期的な更新・運用作業

SEが「毎月なんとなくやっていた」作業ほど、引き継がれずに抜け落ちます。そして数か月後、誰も気づかないうちにドメインやサーバー証明書の期限が切れ、サイトが突然見られなくなる——よくある事故です。

毎日・毎週・毎月の定例作業（動作確認、容量チェック、月次処理との連動など）
ドメイン、SSL証明書、各種ライセンスの更新日（カレンダーに登録しておく）
障害の通知（アラート）がどこに届き、誰が対応するのか

5. 外部の取引先・契約情報

トラブルの多くは、社内ではなく外部の業者に連絡すれば片づきます。ところが、その連絡先や契約内容が、SEの頭の中にしかないことがほとんどです。

システムの開発・保守を委託している会社の連絡先と契約範囲
利用中のソフトやクラウドサービスの契約内容、更新日、支払い方法
各種サポート窓口、契約番号

6. 社内のIT業務（ヘルプデスク）

社内SEの仕事は、システム保守だけではありません。社員のPCトラブル対応やアカウント管理など、日々の「ちょっと困った」を一手に引き受けてきた業務も、立派な引き継ぎ対象です。

社員の入退社時のIT手続き（アカウントの発行・削除、PCの初期設定）
共有フォルダの構成とアクセス権限
プリンタ・複合機・電話・ネットワークのよくあるトラブル対応
社員からの「よくある問い合わせ」とその回答

7. 仕様書・構成図などのドキュメント

既存の資料があるか、そしてそれが最新の状態に保たれているかを確認します。何年も前に作られたまま放置された資料は、ないのと同じか、むしろ混乱のもとになります。

システム構成図、ネットワーク構成図
データベースの定義書（ER図、テーブル定義）
どの業務にどのシステムが対応しているかの一覧
障害対応マニュアル、よくあるエラーと解決手順
各サービスの管理者が誰なのかの一覧

8. 退職するSE本人のアクセス権の停止（最後に）

忘れがちな最後の手続きです。退職後もSE個人のアカウントやアクセス権が残っていると、セキュリティ事故の原因になったり、万一のときに疑いの目が向いたりと、双方にとってよくありません。

SE本人の管理者権限・各種アカウントを洗い出す
引き継ぎ完了後、確実に削除・無効化する
共有していた重要なパスワードは、退職後に変更する

「後任を採用すればいい」が危険な理由

「辞めるなら、急いで代わりのエンジニアを雇えばいい」——そう考えたくなりますが、ここに大きな落とし穴があります。

仕様書がなく、プログラムも複雑に絡み合ったシステムを、入社したばかりの後任にいきなり丸投げする。私たちはこうしたケースを何度も見てきましたが、結末はたいてい同じです。全体像のつかめないシステムを前に後任は疲弊し、プレッシャーに耐えきれず短期間で辞めてしまう。そして状況はさらに悪化します。

経験豊富なエンジニアであっても、資料のないシステムを引き継ぐのは骨の折れる作業です。まず手をつけるべきは「人を増やすこと」ではなく、「今のシステムが、第三者でも保守できる状態かどうか」を見極めることです。

仕様書がない・引き継ぎが間に合わない場合の対処法

SEがすでに退職してしまった。仕様書が一切残っていない。退職日まで時間がない——。こうなると、社内だけで解決するのは現実的ではありません。

そんなときは、ソースコードからシステムの構造を読み解ける外部の専門会社に引き継ぐ、という選択肢があります。社内に詳しい人が誰もいなくても、プログラムと稼働環境を調査し、足りないドキュメントを整備したうえで保守を引き継げます。一般的には、次のような段階で保守体制を立て直します。

診断・現状把握：ソースコードと稼働環境を調査し、システムの構造やセキュリティ上のリスクを洗い出し、必要なドキュメントを整える。
緊急性の高い改修：セキュリティの弱点や、サポートが終了した古いプログラム環境の更新など、放置できない部分を先に手当てする。
継続的な保守体制の構築：問い合わせ窓口を常設し、障害対応・軽微な改修から、将来のシステム刷新の計画までを一手に引き受ける。

システムを丸ごと作り直すには、多額の費用と時間がかかります。一方、今のシステムを「延命」させながら段階的に立て直す方法であれば、コストを抑えつつ、事業を止めない体制を整えられます。料金形態についても、月額固定だけでなく、実際に動いた時間に対してだけ請求する**実働ベース（従量課金）**を選べる会社が出てきています。引き継ぎ直後で稼働量が読みづらい時期ほど、固定費を抱えずに済む持ち方は相性がよいです。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/

よくある質問

Q. 社内SEの引き継ぎには、どれくらいの期間が必要ですか？

A. システムの規模と属人化の度合いによりますが、1人で複数のシステムを抱えていた場合は最低でも1か月、資料がほとんどない状態なら2か月以上を見ておきたいところです。退職を申し出られたら、まず引き継ぎのスケジュールをSEと一緒に組むことから始めてください。

Q. 技術がまったくわからなくても、引き継ぎを進められますか？

A. 進められます。経営者が自分で技術作業をする必要はありません。この記事のチェックリストを使って「これは引き継ぎ資料にあるか」「会社のアカウントで入れるか」をSEに一つずつ確認し、抜けを埋めさせることが役割です。判断に迷う部分は、外部の専門会社に相談する手もあります。

Q. 引き継ぎで、最低限これだけは押さえるべき項目は？

A. 「アカウント・管理者権限（システムの鍵）」「障害時の連絡先と対応手順」「バックアップの戻し方」の3つです。冒頭の優先順位の1〜2番にあたります。ここさえ会社側で確保できていれば、業務が完全に止まる事態は避けられます。

Q. 後任が見つからないまま、SEが辞めてしまいそうです。

A. 社内に引き継ぐ相手がいない場合は、外部の保守会社への引き継ぎを検討してください。SEが在職しているうちに一度システムを見てもらえれば、引き継ぎの精度が格段に上がります。退職後だと、元SEへの問い合わせという形で負担が戻ってきがちです。

Q. すでにSEが退職していて、何も資料が残っていません。手遅れでしょうか？

A. 手遅れではありません。ソースコードと稼働しているシステムさえ残っていれば、そこから構造を解析して保守を引き継ぐことは可能です。まずは現状を専門会社に診断してもらい、リスクの大きい部分から手当てしていくのが現実的です。

まとめ

社内SEの退職で本当に怖いのは、欠員そのものよりも、「その人の頭の中にしかない情報」が一緒に会社から失われることです。だからこそ引き継ぎは、資料の量より優先順位がすべてだと考えてください。

まずはシステムの「鍵」であるアカウントと管理者権限を会社側で確保する。次に、障害時の連絡先と対応手順、バックアップの戻し方を押さえる。残りは時間の許す範囲で進める。この順番さえ守れば、ある日突然業務が止まる事態は防げます。

そして、仕様書が残っていない、後任がいない、退職日まで時間がないといった不安があるなら、無理に自社だけで抱え込まないことです。動かしているシステムの将来に少しでも不安があれば、まずは状況のご相談からでもお気軽にお問い合わせください。弊社のシステムレスキューは月額固定ではなく、実際に動いた分だけ請求する実働ベース（従量課金）の保守です。使わない月は費用が発生しません。