退職者アカウント削除前の「進行中発注」引き継ぎリスト— オープンPOと承認待ちの棚卸し

1. 引き継ぎリストの対象範囲

1-1. ステータス別の含め方

対象は①下書き〜発注確定前②発注済み・検収待ち③検収済み・支払前④承認ワークフロー滞留⑤係争・差戻し中の5帯です。
クローズ済み・キャンセル済みはリストから除外し、監査用エクスポートだけ別途保存します。

1-2. リスト1行の必須列

発注番号、取引先名、金額、起算日、支払期日、現ステータス、次アクション、引き継ぎ先ユーザーID、引き継ぎ完了日、備考の10列を固定します。
次アクションは「検収催促」「経理承認待ち」「書面再送」など動詞で書き、曖昧な「対応中」を禁止します。

1-3. ファイル回収との違い

DriveのPDF回収は証跡の所在確認であり、オープンPOの業務継続とは別問題です。
退職者フォルダの整理手順は退職者DriveからのPDF回収を参照し、本リストは台帳上の当事者と期日を引き継ぐ用途と切り分けます。

2. 削除前チェックリスト（順序固定）

2-1. 台帳エクスポート

退職予定日の5営業日前に、退職者を owner または approver に含む行をCSV出力します。
出力時点のハッシュを記録し、引き継ぎ後に件数が減っていないか再比較します。

2-2. 承認ルートの差し替え

ワークフロー上の「現在承認者」が退職者の案件は、代理承認者へ一括差し替えします。
差し替えログに旧承認者・新承認者・実行者・理由=退職引き継ぎを残します。

2-3. 通知先の更新

60日接近アラートや書面未交付通知の宛先から退職者メールを外し、引き継ぎ先を追加します。
期日管理の見え方は60日KPIダッシュボードで引き継ぎ後も欠損がないか確認します。

3. 引き継ぎ先の決め方

3-1. 原則と例外

原則は同一部門の上長1名へ集約し、案件ごとに実務担当を副担当列へ書きます。
部門横断案件は発注部門のマネージャーを primary、経理を secondary に固定します。

3-2. 高額・係争案件

500万円超または係争フラグ付き案件は、引き継ぎ先を2名必須にし、法務コピーを通知します。
引き継ぎ完了の定義は「次アクションの実行日が入った時点」とし、担当変更だけでは完了にしません。

3-3. 電子契約・通知の当事者

電子契約の送付者が退職者の場合、プラットフォーム側の代表ユーザーも差し替えます。
取適法の書面交付記録は電子契約通知の自動保管の保管先ユーザーが引き継ぎ先と一致している必要があります。

4. アカウント削除のゲート条件

4-1. 削除OKの定義

引き継ぎリストの全行で引き継ぎ先が入力済み、承認ルート差し替え完了、通知先更新完了、の3つが揃ったらITへ削除依頼可能です。
下書きだけ残っている行は、引き継ぎ先が引き受けるか破棄するかを明示的に選択し、破棄は監査ログに残します。

4-2. 削除後の幽霊行監視

削除後30日間は、退職者UIDを参照する行が新規作成されていないか日次バッチで検知します。
API連携で退職者メールが hard-coded されていると幽霊通知が出るため、設定ファイルも同時に洗います。

4-3. コンプラチェックとの接続

引き継ぎ漏れはコンプラ違反ではないですが、60日超過や書面未交付の間接原因になります。
月次レビューでは発注コンプライアンスチェックリストの「担当者明確化」行とセットで確認してください。

5. 引き継ぎリストテンプレ（列定義）

po_id, vendor_name, amount_ex_tax, status, order_date, receipt_date, payment_due, next_action, assignee_from, assignee_to, handoff_done_at, notes, escalation_flag。
next_action 期限列を追加し、退職日+3営業日を初期値にすると遅延が見えます。
トリカク（torikaku） 利用時は取引詳細の担当者変更履歴と po_id を突合し、リストと台帳の不一致を週次でゼロにします。

6. 人事・IT連携のタイムライン

6-1. 退職宣告から30日

D-30で引き継ぎリスト草案、D-14で承認ルート差し替え、D-5で最終エクスポート、D-1で削除依頼、退職日当日にアカウント停止、の順序を固定します。
順序を入れ替えると、通知だけ先に消えて案件が放置されるパターンが出ます。

6-2. 兼務アカウントの特例

退職者が兼務していた別部門の閲覧権限は、引き継ぎではなく剥奪リストを別紙にします。
剥奪漏れは情報漏えいリスクになるため、ITのグループメンバーシップ監査と同日実行します。

6-3. 再雇用・業務委託への転換

退職後に業務委託で関わる場合でも、旧社内アカウントは復活させず、外部アカウントで最小権限を付与します。
旧UIDを再利用すると、引き継ぎログと矛盾します。

7. 引き継ぎ完了報告書

7-1. 報告書の必須添付

引き継ぎリスト最終版CSV、承認ルート差し替えログ、通知先変更ログ、アカウント削除チケット番号を1つのPDFに束ねます。
人事ファイルとIT監査フォルダの両方へ同じ版を保存し、版ずれを防ぎます。

7-2. 未完了行のエスカレーション

引き継ぎ完了日が入らない行は退職日+5営業日で部門長へ自動エスカレーションします。
エスカレーション後も空白なら、案件を一時停止し取引先へ遅延連絡するテンプレを使います。

7-3. クラウド署名・捺印系

退職者名義の電子署名と書面交付設定が残っていないか、引き継ぎ報告書提出前に確認します。
署名者名だけ変わり、実体メールが退職者のまま、という漏れが典型です。

7-4. ベンダー窓口への通知

進行中POの担当変更は、取引先へメールで一覧通知し、返信確認をリストの完了条件に含めます。
社内だけ引き継いで外に知らせないと、検収メールが退職者アドレスに届き続けます。

よくある質問

Q. 退職者だけが知っている口頭約束はどうしますか

リストの備考へ「口頭確認要」と書き、引き継ぎ先が取引先へ確認した日を記録します。
口頭のまま支払う案件は係争リスクが高いため、優先度を上げて処理します。

Q. 代理ログインで残作業させられますか

セキュリティポリシー上禁止が多いです。
代理ではなく担当変更＋引き継ぎ先が操作する手順に寄せてください。

Q. 複数部門兼任の退職者は

部門ごとにリストを分割し、引き継ぎ先も部門単位で決めます。
1枚の表に混ぜると承認権限のない人が案件を引き受けてしまいます。

Q. 退職後に発覚した下書きは

幽霊行監視で検知したら、引き継ぎ先の上長が破棄か昇格かを48時間以内に決めます。
放置は「存在しない発注」として監査で問題になります。

Q. 外注先への連絡は誰がしますか

引き継ぎ先が primary 連絡者となり、退職者個人メールへの返信はテンプレで引き継ぎ先へ誘導します。
取引先マスタの窓口メールも同時に更新してください。

Q. 引き継ぎ先が既に退職予定の場合

二次引き継ぎ計画を同時に作り、リストに secondary_assignee 列を追加します。
連鎖退職で同じ案件が二度放置されるのを防ぐため、人事カレンダーと突合してください。

運用で詰まりやすい点

引き継ぎリストに「口頭だけ」の案件

チャット合意のみで台帳行が無い進行中発注は、リスト作成時点で仮番号を振り、書面追完の期限を後任に渡します。
アカウント削除後に「あれは山田さんが知っていた」で止まると復旧不能です。

共有メールボックス未設定

取引先からの納期変更メールが個人宛だけだと、削除後に届きません。
進行中案件の相手先には、引き継ぎ完了メールで新しい窓口を通知します。

まとめ

• 進行中POはPDF回収とは別に、台帳上の当事者と期日を引き継ぐ
• リスト10列と次アクション期限で曖昧な「対応中」を排除する
• 承認ルート・通知先・電子契約ユーザーを削除前に差し替える
• 削除OKは引き継ぎ完了の定義を満たしてから
• 削除後30日は幽霊行と hard-coded メールを監視する

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。