退職や異動の連絡は、たいてい引継ぎの準備が整う前にやってきます。とくにVBAやPython、GASで作られた自動化ツールは、作った本人の頭の中にしか情報がないことが多く、限られた期間での受け渡しが難しくなりがちです。この記事では、残り2週間を前提に「何を」「誰から誰へ」「いつまでに」渡すかを決める手順を整理します。
- 自動化ツールの棚卸し 稼働中のものを一覧にする
- 優先順位の決定 止められるもの・残すものを分ける
- 6分類で中身を揃える 基本情報から改修履歴まで
- 版を固定する 仕様とコードの対応を確定させる
- 受け手との読み合わせ 実際に動かして確認記録を残す
- 引継ぎ後の相談先を決める 誰に聞くかを明文化する
まず「何本あるか」を数えるところから
引継ぎが失敗する典型は、退職者が覚えている範囲だけを説明し、本人も忘れていたツールが後から出てくるパターンです。最初の1〜2日は、説明ではなく棚卸しに使います。
洗い出しの手がかりは次のあたりです。
- 共有フォルダに置かれたマクロ付きExcelファイル
- タスクスケジューラや定期実行の設定
- スプレッドシートのGASトリガー
- 自分のPCにしかないスクリプト
- 他部署から「毎月お願いしている」と言われている処理
ここで重要なのは、完成度や重要度を判断せずに、まず全部並べることです。判断は次の工程で行います。
引継ぎの初日は説明ではなく、稼働中の自動化ツールを漏れなく一覧にすることに充てます。
2週間しかないなら、全部は引き継がない
一覧ができたら、すべてを同じ密度で引き継ぐのは現実的ではありません。次の基準で3つに仕分けます。
| 区分 | 判断の目安 | 2週間での扱い |
|---|---|---|
| 継続必須 | 止まると他部署の業務や締め日に影響する | 6分類すべてを揃える |
| 継続希望 | あると便利だが、手作業で代替できる | 基本情報・動かし方に加え、権限・依存先・停止と復旧の手順を揃える |
| 停止候補 | 直近数か月使われていない、代替手段がある | 利用部門と影響を確認し、責任者の承認・保全・停止記録を残す |
渡す中身を6分類で決める
継続必須と判断したツールは、渡す情報を次の6つに分けて揃えます。分類を決めておくと、何が足りないかが一目で分かります。
基本情報
ツール名、目的、誰のどの業務で使うか、実行タイミング、関係する部署。受け手が最初に読む部分です。
仕様
入力は何で、出力は何か。処理の前提条件、想定外のデータが来たときの挙動。細かいロジックより「何をするものか」を先に書きます。
資料
操作手順、画面の説明、参照しているマスタや外部サービスの情報、秘密情報を除いた設定値の一覧を残します。パスワード・APIキー・トークンは資料やコード、チャットに貼り付けず、会社が承認した安全な保管先で管理し、資料には保管先と管理責任者、必要な権限を記載します。案件URLも、必要な相手だけが閲覧できる権限で共有してください。
コード
本体のソースと、動作に必要なファイル、保管場所を揃えます。OS・言語・ライブラリのバージョン、実行PC、外部サービスへの接続、定期実行の所有者も記録します。個人アカウントに依存する処理は、管理者の承認を得て組織管理のアカウント等へ移す計画を立てます。GASのインストール型トリガーなど、ファイルの共有や所有者変更だけでは実行者が切り替わらないものもあるため、後任側の権限と実行設定を確認してください（Google公式：インストール可能なトリガー）。
会話
「なぜこの仕様にしたか」が残る部分です。依頼者とのやり取り、仕様を変えた理由、見送った要望。ここが抜けると、受け手は改修のたびに判断に迷います。
改修履歴
いつ何を直したか。同じ不具合を繰り返さないための記録です。
自動化案件をこの6分類で整理する仕組みとしてPoxiiがあります。VBA・Python・GASなどの案件を基本情報・仕様・資料・コード・会話・改修履歴に分けて格納し、案件URLで管理・引継ぎができます。分類の器が先にあると、「何を書けばいいか分からない」という手が止まる時間を減らせます。
版を固定して、確認記録を残す
引継ぎ期間中もツールは動き続け、退職者が最後の修正を入れることもあります。ここで起きやすいのが、渡した資料と実際に動いているコードがずれる問題です。
対策は単純で、ある時点で仕様とコードの版を固定し、「この版を引き継ぐ」と決めることです。固定後に修正が必要になったら、新しい版として記録し、影響する手順とテスト結果も更新します。
Poxiiでは仕様とコードの版を固定し、確認記録を残す運用ができます。受け手が「読んだ」「動かした」という記録が残ると、引継ぎ完了の線引きが口頭の約束に頼らなくなります。
引継ぎのずれは、仕様とコードの版を固定し、確認した記録を残すことで防ぎます。
安全に実行を確認する
動作確認は、原則として検証環境とテスト用データで行います。メール送信、請求処理、データ更新・削除などの外部への影響を洗い出し、本番の定期実行とテストが重ならないようにしてください。本番での確認が必要なら、責任者が対象・時間・実行者を承認し、バックアップ、復旧方法、二重実行の防止策を準備します。
後任のアカウントと実行環境で、正常時だけでなく失敗時の通知・停止・復旧も確認します。退職者のアクセス権限を終了した後も動作できるか、管理者と確認し、必要な権限移管と認証情報の更新を会社の手順で実施します。退職者のアカウントを残し続けることを代替策にしないでください。
2週間の日程の組み方
この進め方の要点は、8〜9日目に受け手が自力で動かす時間を確保していることです。説明を聞いただけでは、資料の抜けは見つかりません。退職者がまだ在籍しているうちに一度詰まることが、資料の品質確認になります。
この日程は目安です。ツールの数や影響の大きさによっては2週間で完了しないため、継続範囲・暫定運用・停止の判断を責任者と決めます。相談先は社内の担当者や契約済みの保守先から選び、退職者が退職後も無償で対応する前提にはしません。
受け手が決まっていない場合
後任が未定でも、6分類の中身を揃える作業は先に進められます。案件URLで整理しておけば、後任が決まった時点で参照先を渡すだけで出発点が揃います。暫定的に上長や近い業務の担当者を「一時的な預かり先」として決め、連絡を受ける窓口だけ空白にしないことが大切です。
よくある質問
Q: 退職者が多忙で引継ぎ資料を書く時間がありません。優先順位はどう付けますか。
A: まず稼働中ツールの一覧と影響を受ける部署、運用責任者・相談先を確認してください。継続するツールは、コードと実行環境、権限、停止・復旧方法も最低限揃えます。一覧と連絡先だけで安全に継続できるとは限りません。そのうえで継続必須のものに絞り、基本情報と仕様から埋めていく順序が現実的です。コードの細かい解説は後回しでかまいません。
Q: コードを渡せば引継ぎは足りるのではないでしょうか。
A: コードだけでは「なぜその処理になっているか」が分かりません。特例処理や除外条件は、依頼者とのやり取りの中で決まっていることが多く、背景を知らずに改修すると別の部署の業務に影響が出ます。会話や改修履歴を含めて残す意味はここにあります。
Q: 引継ぎが完了したと判断する基準は何ですか。
A: 受け手が退職者の助けなしに一通り実行でき、想定される例外時の対応も説明できる状態です。口頭の「分かりました」ではなく、実際に動かした記録と残課題の一覧が揃っているかで判断してください。残課題には影響・対応担当・期限・暫定対策を記載し、責任者が受入可否を判断します。情報漏えい・誤送信・データ破損などにつながる重大な問題は、記載だけで完了扱いにせず、解消または安全な代替運用・停止を決めてください。
まとめ
限られた期間の引継ぎでは、全部を伝えようとするほど肝心な部分が抜けます。稼働中のツールを数え、残すものを絞り、基本情報・仕様・資料・コード・会話・改修履歴の6分類で中身を決める。この順序で進めると、何が足りないかが途中で見えるようになります。
版を固定して確認記録を残すこと、受け手が自力で動かす時間を在籍中に確保することの2点を押さえれば、退職後に「聞ける人がいない」状態は避けやすくなります。Poxiiのように6分類と案件URLで受け渡し状態を見える形にしておくと、次の異動のときにも同じ手順が使えます。
