前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること

先週まで隣の席にいた前任者が、ある日突然辞めた。あるいは、他部署に異動になった。引き継ぎ資料は「机の中を見ればわかるから」の一言だけ。パスワードが書かれたメモは見つかったが、それがどのシステムのものかは分からない。取引先から「いつもの発注データの件で」と電話がかかってきても、何のことか見当がつかない。

これは決して珍しい話ではありません。中小企業の多くは情シス専任者を置けず、総務や経理の担当者が「なんとなく詳しいから」という理由でシステム管理を任され、そのまま属人化した状態で何年も運用されているケースが大半です。そして属人化した担当者が抜けると、引き継ぎは驚くほど雑になります。

こうした状況に置かれる人には、いくつか共通する特徴があります。経理や総務がもともとの本業で、ITは「詳しそうだから」という理由で片手間に任されている。エクセルやパソコンの基本操作はできても、サーバーやドメイン、アカウント権限といった専門用語には馴染みがない。そして何より、「聞ける相手がいない」という孤独感を抱えている。この記事は、まさにそういう状況にいる人のために書きました。何をどの順番で確認すればよいのか、最初の1週間でやるべきことを具体的に整理します。専門知識がなくても、順番に潰していけば「最低限、業務が止まらない状態」までは持っていけます。

この記事で分かること

前任者が引き継ぎ資料を残さずに退職・異動した状況で、最初の1週間に何を確認し、何を後回しにしてよいかを時系列で解説します。初日にやるべき「止血」の作業、3日目までに終えたい全体像の把握、1週間で仕上げたい最低限の管理体制づくりまでを順に扱います。

先に結論を言うと、最初の1週間でやることは大きく3つです。

• 止血: 業務が止まる・情報が漏れる最悪の事態を防ぐ
• 可視化: 何がどこで動いているかを一覧にする
• 応急の体制: 誰に何を聞けばよいか、緊急連絡先を確保する

完璧な引き継ぎを1週間で終わらせる必要はありません。むしろ「完璧を目指して動けなくなる」ことのほうが危険です。

まず深呼吸する。パニックで壊すものが一番怖い

引き継ぎがない状態を任されると、多くの人が「何か大変なことをしでかしてしまうのではないか」という恐怖から、手当たり次第にシステムを触り始めてしまいます。これが実は一番危険です。

分からないまま管理画面をいじって設定を変更したり、「これは使っていないだろう」と判断してアカウントやサーバーを止めてしまったりすると、取り返しのつかないトラブルに発展します。実際に、何年も前に構築されて誰も仕組みを覚えていないレガシーシステムほど、一見動いていないように見える部分が実は裏で重要な処理をしている、ということが珍しくありません。

最初の1週間でやるべきことは「触ること」ではなく「知ること」です。以下の順番を守ってください。

1. 何が動いているかを調べる(触らない)
2. 誰が何を管理しているかを調べる(触らない)
3. 緊急連絡先を確保する(触らない)
4. ここまで終えてから、必要最小限の操作をする

焦って何かを止めたり削除したりする前に、まず全体像をつかむ。これが引き継ぎ不在からの立て直しにおける大原則です。

初日にやること(1) 引き出しとパソコンの中の紙・データを回収する

前任者が完全にゼロから何も残していない、ということは実はあまりありません。多くの場合、断片的な情報が机の引き出し、共有ドライブの奥、個人のパソコンのデスクトップなどに散らばっています。

まず確認すべき場所を挙げます。

• 前任者のデスクの引き出し(契約書控え、名刺、メモ用紙)
• 前任者が使っていたパソコンのデスクトップ・ドキュメントフォルダ
• 共有ドライブ内の「システム」「IT」「情シス」といった名前のフォルダ
• 経理部門が持っている支払い明細(サブスクリプション費用の引き落とし記録から、契約しているサービスが分かることがあります)
• 過去のメールの「送信済み」フォルダ(ベンダーとのやり取りが残っている可能性)

実務上のコツ: 経理の支払い明細は、実は最も確実な手がかりになることが多いです。口座振替やクレジットカード明細に残る「〇〇株式会社」「△△クラウド」といった項目名から、契約中のサービスを逆引きできます。前任者の記憶よりも、お金の流れのほうが正直です。

この段階では「整理して台帳を作る」ところまではまだやりません。とにかく手がかりになりそうな紙・データをかき集める、それだけに専念してください。

初日にやること(2) 前任者本人への連絡を試みる

退職・異動の理由や状況にもよりますが、可能であれば前任者本人に連絡を取ることを検討してください。円満退職であれば、意外と協力的に答えてくれることも多いです。

連絡する際に聞くべきことをあらかじめリスト化しておくと、限られた時間を無駄にしません。

• 社内で動いているシステム・サービスの一覧(思いつく範囲でよいので)
• 管理者アカウントのID・パスワードの保管場所
• 契約している開発会社・ベンダーの連絡先
• 「これだけは絶対に触るな」というものがあるか
• 定期的に発生する作業(月末処理、年次更新など)があるか

ただし、退職者への連絡には注意点もあります。会社を離れた人に業務上の情報を無償で依頼し続けることは、相手にとって負担になりますし、円満退職でない場合はそもそも連絡が取れない、あるいは協力を得られないこともあります。1〜2回の問い合わせで区切りをつけ、それ以上は自力で調べる前提に切り替えるのが現実的です。

初日にやること(3) 最低限のセキュリティリスクを塞ぐ

前任者の退職に伴って最優先で確認すべきなのが、アカウントの取り扱いです。ここを放置すると、情報漏えいや不正アクセスの直接的な原因になります。

IPAが公表している「情報セキュリティ10大脅威」では、組織向けの脅威の一つとして内部不正による情報漏えいが継続的に挙げられています。退職者のアカウントが有効なまま放置されることは、この種のリスクに直結します。

初日〜2日目のうちに、以下を確認してください。

ここで注意したいのは「アカウントをいきなり完全削除しない」ことです。削除すると、そのアカウントに紐づくデータ(メール履歴、ファイルの所有権など)ごと消えてしまう場合があります。まずは無効化(ログインできない状態)にとどめ、業務への影響がないことを確認してから、後日あらためて削除を検討してください。

個人情報を扱う体制については、個人情報保護法において、事業者は従業員に対する必要かつ適切な監督を行う義務があると定められています。退職者のアカウント管理もこの監督義務の一環として捉えておくと、社内で説明しやすくなります。

2〜3日目 動いているシステムを全部洗い出す

止血が済んだら、次は「何が動いているか」の可視化に着手します。ここで作るのがシステム管理台帳の叩き台です。

いきなり完璧な台帳を作ろうとせず、まずは分かる範囲で列挙することを優先してください。項目は最低限、次の4つで十分です。

• システム名・サービス名(会計ソフト、勤怠管理、社内ポータルなど)
• URL・アクセス方法
• 契約している会社(ベンダー)の名前と連絡先
• 管理者アカウントの有無と保管場所

洗い出しの手がかりは複数あります。

1. 社内の各部署に「日常業務で使っているシステム・ツールは何か」を聞いて回る
2. 会社のメールドメインでログインできるサービス一覧をGoogle WorkspaceやMicrosoft 365の管理画面から確認する(契約していれば)
3. 経理の支払い明細から月額・年額で引き落とされているサービスを洗い出す
4. 社内ネットワークに接続されているサーバー・複合機・NASなどの機器を物理的に確認する

この段階でよくあるのが、現場の一部の部署だけが独自に契約しているクラウドサービスの存在です。情シス担当や総務が把握していないところで、営業部がSFAツールを、製造部が独自の生産管理システムを契約している、といったケースが典型です。こうした未把握のシステムはシャドーITと呼ばれ、セキュリティ管理の盲点になりやすいので、聞き取りの際は「情シスが管理しているもの」だけでなく「各部署が個別に契約しているもの」も必ず聞いてください。

サーバー・パソコンの現物を確認する

クラウドサービスだけでなく、社内に物理的に設置されているサーバーやパソコンの現状も確認する必要があります。特に注意したいのが、サポートが切れかけている、あるいは既に切れている機器です。

古いWindows ServerやWindowsパソコンをそのまま使い続けている会社は少なくありません。マイクロソフトは製品ごとにサポート期限を公表しており、期限(EOL（サポート終了）)を過ぎると新たな脆弱性が発見されても修正プログラムが提供されなくなります。たとえばWindows Server 2012および2012 R2は2023年10月にサポートが終了しており、追加費用を払って延長セキュリティ更新プログラムを購入しない限り、脆弱性が放置された状態で稼働し続けることになります。

初日〜3日目の間に、以下を目視で確認してください。

• サーバー本体にOS名・バージョンが分かるラベルやドキュメントが貼られていないか
• 起動画面やコントロールパネルからOSバージョンを確認する
• 型番をメーカーサイトで検索し、サポート状況を調べる

もし古いOSのまま稼働している機器が見つかっても、この段階で慌てて入れ替えたり停止したりする必要はありません。まずは「リスクとして認識し、記録する」ことが目的です。対応の優先順位付けは、全体像が見えてから改めて検討します。

更新プログラムが止まっていないかも合わせて見る

OSそのもののEOLとは別に、日常的なセキュリティ更新プログラム(Windows Updateなど)がきちんと適用され続けているかどうかも、この段階で確認しておきたいポイントです。EOLを迎えていない現行のOSであっても、パッチマネジメントが止まっていれば、既知の脆弱性が塞がれないまま放置されることになります。

前任者が更新作業を手動で行っていた場合、担当者不在の期間に更新が止まっている可能性があります。以下を確認してください。

• Windows Updateの「最終更新日」がどれくらい前か
• 自動更新の設定になっているか、手動更新の運用になっているか
• サーバー機器についても同様に、最終適用日を確認する

もし更新が長期間止まっていることが分かっても、この場で慌てて一斉更新をかける必要はありません。業務時間中の更新は再起動を伴うことが多く、予告なく実行すると別のトラブルを招きます。まずは「止まっている事実」を記録し、業務に影響のないタイミングでの計画的な適用に回してください。

3日目 契約書・見積書をかき集めて「誰が保守しているか」を特定する

社内システムの多くは、外部の開発会社やベンダーが保守を担っていることが一般的です。誰がどのシステムの保守を担当しているのかが分からないと、障害が起きたときに連絡すべき相手すら分かりません。

契約書・見積書・請求書から確認すべき項目は次の通りです。

• 契約している会社名・担当者名・連絡先
• 契約形態(保守契約の有無)
• 対応時間・対応範囲(無償対応の範囲はどこまでか)
• 契約更新のタイミング(自動更新か、都度更新か)

引き継ぎがない状態でよく起きる失敗: 保守契約を結んでいる会社の存在を知らないまま数ヶ月が経過し、いざ障害が起きたときに「どこにも連絡できない」と気づくパターンです。契約書を見つけたら、すぐに一度、担当者宛に「ご挨拶とシステム引き継ぎのご連絡」というメールを送っておくことを強くおすすめします。相手も「担当者が変わったが連絡がない」状態を不審に思っているケースが多く、早めの連絡は双方にとって安心材料になります。

保守契約が見当たらない、あるいは既に切れている場合は、次の一手をどうするか(自社対応にするのか、新しくベンダーを探すのか)を検討する材料として、まず「保守契約が存在しない」という事実を記録しておいてください。

4〜5日目 パスワード・アカウント情報を安全な場所に集約する

散らばっていたパスワードやアカウント情報が集まってきたら、これらを一箇所に安全に集約する作業に入ります。付箋やExcelファイルに平文で書き散らかす運用は、前任者の代からの負の遺産を引き継ぐだけなので、この機会に見直すことをおすすめします。

最低限、以下は避けてください。

• パスワードを平文のExcelファイルでメール送付・共有ドライブに放置
• 付箋にパスワードを書いてモニターに貼る
• 全社共通のパスワードを使い回す

代わりに検討したいのが、パスワード管理専用のツールの導入です。専任の情シスがいない会社でも、法人向けのパスワード管理ツールは月額数百円〜1,000円台のプランから提供されていることが多く(提供元によって価格・機能は異なるため、必ず各社の公式サイトで最新の料金を確認してください)、Excel管理からの移行先として現実的な選択肢です。

あわせて、ログイン時に確認できる箇所には多要素認証（MFA）の設定状況もチェックしてください。パスワードだけに頼らない認証の仕組みが入っているかどうかで、アカウント漏えい時の被害の広がり方が大きく変わります。

パスワード管理ツールを選ぶ際は、いきなり多機能な製品を探す必要はありません。最低限、次の3つの機能が揃っていれば、Excel平文管理からの移行としては十分な効果があります。

• チーム・組織単位でパスワードを共有できる(個人ごとにバラバラに管理しない)
• 退職時にアカウントへのアクセス権限だけを剥奪できる(パスワードそのものを教える必要がない)
• 操作ログが残る(誰がいつアクセスしたかが分かる)

逆に言えば、この3つが備わっていれば、無料プランや安価なプランからのスタートでも構いません。まずは「平文でどこかに書き散らかされている」状態から脱することが最優先です。

意外と見落とされる「Access」「Excelマクロ」の存在

中小企業の社内システムを調査していると、想定外の場所から重要な業務プロセスが見つかることがあります。特に多いのが、Access（データベースソフト）やVBAマクロで組まれた自作の業務システムです。

前任者が個人的なスキルで作り上げた在庫管理表、受発注管理ファイル、勤怠集計マクロなどが、実は会社の業務の一部を静かに支えている、というケースは珍しくありません。これらは公式な「システム」として認識されておらず、引き継ぎ資料にも載っていないことがほとんどです。

見つけ方のヒントを挙げます。

• 共有ドライブ内の.accdb(Accessデータベース)ファイルを検索する
• Excelファイルを開いたときに「マクロを有効にする」という警告が出るファイルをリストアップする
• 各部署に「毎日・毎月使っている謎のExcelファイルはないか」を聞く

もしこうしたファイルが見つかった場合、中身を今すぐ理解する必要はありません。「存在を知っている」状態にしておくだけで十分です。中身の解読や後継システムへの移行は、1週間を過ぎてから腰を据えて取り組むべき別のテーマです。

5〜6日目 最低限の管理台帳を形にする

ここまで集めてきた情報を、簡易的な一覧表としてまとめます。完璧な様式にこだわる必要はなく、まずはExcelやスプレッドシート1枚で構いません。

最低限、次の列を用意してください。

1. システム・サービス名
2. 用途(何のための仕組みか)
3. 管理者アカウントの保管場所
4. 契約会社・連絡先
5. 契約更新月
6. 気づいたリスク・懸念点(EOL間近、保守契約なし、など)

この一覧表があるだけで、次に何かトラブルが起きたときの初動が劇的に速くなります。逆に言えば、前任者がこの一覧を残していなかったからこそ、今回のような苦労が発生したとも言えます。自分の代で同じ苦労を次の担当者にさせないためにも、この段階でひとまず形にしておく価値は大きいです。

台帳を作る際によくある迷いとして「どこまで細かく書けばよいか」という問題があります。目安としては、次のように考えるとよいでしょう。

• 停止すると業務が止まるもの → 詳しく書く(緊急連絡先、復旧手順の有無まで)
• 停止しても大きな影響がないもの → システム名と契約先だけで十分
• 判断がつかないもの → とりあえず「要調査」として一覧に載せておく

単一障害点になっている仕組みがないかを意識する

台帳を作りながら、あわせて意識しておきたいのが単一障害点（SPOF）の有無です。特定のサーバー1台に複数の重要な業務が同居していたり、特定の担当者(つまり今のあなた)しか動かし方を知らない仕組みがあったりすると、そこが止まった瞬間に会社全体の業務が止まってしまいます。

この段階では対策を打つ必要はありません。台帳の「気づいたリスク・懸念点」欄に、単一障害点になっていそうな箇所をメモしておくだけで十分です。たとえば「経理システムがこの1台のサーバーでしか動いていない」「このサーバーの管理方法を知っているのは自分だけ」といった気づきを、忘れないうちに書き留めておいてください。

6〜7日目 緊急連絡網と「困ったときの相談先」を確保する

1週間の締めくくりとして、自分自身が今後困ったときに頼れる先を確保しておきます。前任者という頼れる存在がいなくなった以上、複数の相談先を持っておくことが、これからの安心材料になります。

確保しておきたい相談先の例です。

• 各システムの保守契約先(既に連絡が取れる状態にあるか再確認)
• 同業他社・同じ業界団体の情シス担当者(横のつながりがあれば心強い相談相手になります)
• IT導入時に付き合いのあった商工会議所・自治体の相談窓口
• 社内の経営層(判断が必要な場面で、費用や方針の決定権を持つ人)

特に経営層への報告は、この1週間の締めくくりとして必ず行ってください。「前任者からの引き継ぎがなかったこと」「1週間かけて分かった範囲」「まだ分かっていないリスク」を、隠さず正直に共有することが重要です。ここで無理に「大丈夫です、全部把握しました」と背伸びをすると、後になって問題が起きたときに「なぜ早く言わなかったのか」という余計なトラブルに発展しかねません。

報告の型: 「①今分かっていること」「②まだ分からないこと・調査中のこと」「③助けてほしいこと(予算・人手・専門家への相談など)」の3つに分けて話すと、非エンジニアの経営層にも状況が伝わりやすくなります。

1週間で「やらなくてよい」こと

ここまで数多くのタスクを挙げてきましたが、最初の1週間で無理に手を出さなくてよいこともはっきりさせておきます。焦って手を広げすぎると、かえって重要な確認がおろそかになります。

• 古いシステムの入れ替え・移行の実行: リスクとして記録するだけにとどめ、実行の判断は後回しでよい
• すべてのマクロ・カスタムシステムの中身の完全な解読: 存在を把握するだけで十分。中身の解読は落ち着いてから
• 保守契約の見直し・乗り換え交渉: まずは現状の契約先と連絡が取れる状態を作ることが優先
• 社内規程やマニュアルの整備: 台帳がある程度形になってから着手する

1週間はあくまで「何が起きても最悪の事態にならない状態」を作るための期間です。恒久的な立て直しは、ここから数ヶ月かけて取り組むテーマだと捉えてください。

この後の1ヶ月でやるべきこと(先の見通し)

最初の1週間を乗り切ったあと、多くの人が次に直面するのが「これで本当に大丈夫なのか」という漠然とした不安です。以下のような論点が、次のステップとして待っています。

• 台帳に書き出した「要調査」項目を、優先度順に一つずつ潰していく
• EOLが近い、あるいは既に過ぎているシステムの対応方針を検討する
• 保守契約が存在しない、または内容が不明瞭なシステムについて、契約の見直しや新規発注を検討する
• 属人化した業務(自分しか分からない状態)を、後任のために言語化・マニュアル化していく

これらは1週間で片付くテーマではなく、腰を据えて取り組むべき中長期の課題です。焦らず、優先順位をつけながら進めてください。

一人で抱え込まないという選択肢

最後に、心構えの話を一つ加えておきます。前任者の不在という状況は、あなたの責任ではありません。それにもかかわらず、「自分が何とかしなければ」というプレッシャーから、一人で全てを抱え込んでしまう人が少なくありません。

社内システムの調査・立て直しは、必ずしも自社の人員だけで完結させる必要はありません。次のような外部の力を借りる選択肢も、頭の片隅に置いておいてください。

• 既存の保守契約先に、通常の保守範囲を超えた「現状調査」を別途依頼できないか相談する
• IT導入時に付き合いのあった開発会社以外にも、セカンドオピニオン的に現状を見てもらえる会社がないか探す
• 商工会議所や自治体のIT相談窓口を、契約前の一次相談として活用する

外部に相談する際は、ここまでの1週間で作った台帳や資料が大きな武器になります。「何が分からないか」を言葉にできているだけで、相手も的確なアドバイスをしやすくなります。逆に「全部分かりません」という丸投げの相談では、相手も何を優先して見ればよいか判断できません。この記事の手順を踏んでおくこと自体が、次に誰かへ相談するときの準備にもなっています。

まとめではなく、次に読んでほしい記事について

この記事では「前任者不在からの最初の1週間」に絞って手順を解説しました。ここから先、具体的な論点ごとに深掘りした記事を別途用意しています。台帳の作り方をもう一段詳しく知りたい方、EOLが迫ったシステムの判断基準を知りたい方、保守契約の内容確認の仕方を知りたい方は、それぞれ以下のテーマのカテゴリ記事もあわせてご覧ください。

• 「保守崩壊・引き継ぎ」カテゴリの他の記事(属人化したExcelマクロの読み解き方、レガシーシステムを延命するか作り直すかの判断基準など)
• 「ひとり情シス実務」カテゴリの記事(IT資産管理台帳の作り方、パッチ適用の運用ルールなど)
• 「開発会社とのつきあいかた」カテゴリの記事(保守契約の内容確認、緊急時のエスカレーション体制の作り方など)

退職者名義でドメインやサーバーが契約されたままになっているケースは、退職者名義のドメイン・サーバー契約を取り戻す手順で具体的な手順を解説しています。「動いているから触るな」と言われているシステムに手を入れる必要が出てきた場合は、「動いているから触るな」と言われるシステムの安全な改修手順を、そして今日から引き継ぎ書代わりの記録を始めたい場合は引き継ぎ書がない会社が今日から始めるシステム記録術を参考にしてください。最初の1週間で「社内Wi-Fiが不安定」という相談が来た場合の切り分け手順は社内Wi-Fiが不安定なときの調査手順に、総務兼任で情シスを任されたばかりの方がこの先1ヶ月で取り組むべきことの全体像は総務兼任で情シスを任されたら最初の1ヶ月でやることリストにまとめています。

現時点でこれらの記事はカテゴリ内に順次追加されていく予定です。まずはこの記事の手順に沿って、目の前の1週間を乗り切ることを最優先にしてください。全体像さえ見えれば、そこから先の対応は落ち着いて進められるようになります。