Coworkで退職者オフボーディングをチェックリスト化する

退職者のオフボーディングは、アカウント無効化申請・貸与品回収・引き継ぎ資料作成という定型の3工程に、担当部署をまたいだ確認作業が重なる業務です。Coworkは、この3工程のうちチケット起票と現状把握をFreshserviceとの接続で自動化し、複数フォルダに散らばった引き継ぎ材料の洗い出しをファイル横断で受け持てます。ただし退職者のアカウント権限に触れる操作は取り消しにくいため、Approval Gatesで人の確認を挟む設計が前提になります。

始める前に確認しておくこと

Freshserviceコネクタはサインインが必要な種類のコネクタで、利用にはCoworkのConnectors設定で有効化し、Freshservice側の認証情報で接続しておく必要があります。組織がTeam・Enterpriseプランの場合、管理者側の設定によってはコネクタの実行が「常に許可」にならず、都度の確認を求められることがあるため、本記事の指示文をそのまま流用する前に自分の組織の設定を確認してください。

オフボーディングの3工程とCoworkの役割分担

退職者対応の一般的な3点セットは、①アカウント無効化申請②貸与品回収③引き継ぎ資料作成です。Coworkが得意なのは、この3工程それぞれの起票・洗い出し・下書きであり、実際の承認や無効化の実行そのものではありません。

3工程とも、Coworkの出力は最終成果物ではなく下書きです。退職者本人のアカウント情報や社内システムへのアクセス権限に関わる操作は、後戻りしにくい性質を持つため、Approval Gatesの設計次第で自動化の範囲が変わります。承認ゲートを業務の性質で分類する4つの判断軸はCowork Approval Gatesを部門ごとに設計する考え方にまとめています。

アカウント無効化申請をFreshserviceで起票する

CoworkのFreshserviceコネクタには、createOffboardingRequest(オフボーディングリクエストの作成)とfetchOffboardingRequests(既存リクエストの取得)という専用ツールが用意されています。これは一般的なチケット作成ツールとは別に、オフボーディングという業務そのものを対象にしたツールです。同じコネクタには対になるcreateOnboardingRequest・fetchOnboardingRequestFormもあり、入社と退職の両方をFreshservice側の業務フローとして扱える設計になっています。

{taishoku_meibo.csv}(退職者一覧: 氏名, 社員番号, 最終出社日,
所属部署, 貸与PC番号)から、{taishoku_taisho} さんの
オフボーディングリクエストをFreshserviceに起票してください。
 
- リクエストには最終出社日とアカウント無効化の希望日を含める
- 所属部署のシステム管理者を承認者に指定する
- 起票前に内容を提示し、私が確認してから実行する
- 起票後、リクエストIDを報告する

最後の「起票前に内容を提示し、私が確認してから実行する」という一文が要です。Freshserviceへの書き込みはCoworkの承認モード(Manual・Auto・Skip)とコネクタ側のツール権限の掛け合わせで挙動が決まり、初めて使うツールや対象が退職者のアカウントのような取り消しにくい操作では、Manualに寄せて毎回確認する設計が妥当です。公式の安全ガイドも、新しいツールを初めて使う場面と、間違いを元に戻しにくい場面ではManual承認への切り替えを勧めています。

貸与品回収は台帳と本人記録の突き合わせで洗い出す

貸与品回収は、何を回収すべきかの一覧を作る作業と、実際の回収そのものを分けて考えると扱いやすくなります。Coworkが受け持てるのは前者です。資産台帳と退職者の貸与記録を突き合わせ、回収対象を漏れなくリスト化する作業は、繰り返しに強い定型作業にあたります。

{asset_master.csv}(資産台帳: 資産番号, 種別, 貸与者社員番号,
貸与日)から、社員番号 {emp_id} に紐づく貸与品を
すべて抽出してください。
 
- 出力: 資産番号・種別・貸与日を回収予定日順に並べた表
- 台帳に記載のない口頭貸与の資産は対象に含められないため、
  「台帳外の可能性」として注記を残す
- 資産番号が重複している行は「要確認」に分類する

FreshserviceのfetchAssets・fetchAgentのようなツールを使えば、台帳データそのものをFreshservice側から直接取得することもできます。ただし社内の資産管理が別システム(Excel台帳やGoogleスプレッドシート)に残っているケースも多く、その場合はCoworkのファイル横断でCSVやスプレッドシートを直接読ませる形になります。台帳が2系統に分かれている組織では、どちらを正とするかを先に決めておかないと、突き合わせの結果が食い違う原因になります。

FreshserviceのコネクタにはcreateTicket・fetchTicket・fetchTickets・updateTicketという汎用のチケット操作ツールも含まれます。オフボーディング専用ツールがカバーするのはFreshservice本体の業務フローに限られるため、Freshservice以外のSaaSアカウント(社内Wiki、開発ツール、社外向けSaaSなど)の権限剥奪は、これらの汎用チケットツールで個別に起票する組み方ができます。オフボーディングリクエスト1件に対して、対象システムの数だけ子チケットを起票する構成にしておくと、どこまで処理が終わったかを1つのリクエストIDから追えます。

3工程のどこをManual承認に固定すべきか

3工程のうち、アカウント無効化申請の起票と貸与品回収リストの作成は、実行結果を後から取り消しやすい作業です。誤ったリクエストを起票しても、キャンセルして起票し直せます。一方で、実際にアカウントを無効化する操作そのものや、引き継ぎ資料に機微な情報を含めて共有してしまう操作は、取り消しにくい部類に入ります。

この振り分けは、取り消しにくさを判定基準にした一般的な考え方に沿っています。判定の視点そのものはCoworkの取り消せない操作をどう見極めるかで扱っているので、オフボーディング以外の業務にも応用できます。

引き継ぎ資料はファイル横断で候補を洗い出してから絞る

引き継ぎ資料作成は、退職者が関わったファイルを一から探す作業が最も時間を取られる部分です。Coworkは接続済みのフォルダやコネクタを横断して、退職者が過去に編集・作成したファイルの候補を洗い出せます。ここでの役割は「候補の洗い出し」までで、実際に何を引き継ぎ資料に残すかの取捨選択は後任や上長が行います。

Google DriveとNotionの中から、{taisho_name} さんが過去6か月に
編集または作成したファイル・ページを洗い出してください。
 
- 出力: ファイル名、最終編集日、格納場所のリンクを一覧化した表
- 進行中の案件に関わるものと、完了済み案件のものを分けて表示する
- 個人用の下書きフォルダは対象から除外する
- 洗い出した一覧そのものであり、引き継ぎ資料の本文は作成しない

「洗い出した一覧そのものであり、引き継ぎ資料の本文は作成しない」という指定を入れているのは、候補一覧と引き継ぎ資料を混同しないためです。洗い出した候補の中から後任が実際に必要な情報を選び、その内容の草稿作成を別途Coworkに依頼する、という2段階に分けたほうが、成果物の性格がぶれません。退職者本人が関わっていた機微な情報(人事評価、給与関連のやり取りなど)が候補に混ざる場合は、洗い出しの時点で除外条件に含めておく必要があります。データの扱い方の全体像はCoworkセキュリティにまとめています。

退職予定者の一覧を定期的に洗い出す

複数人が同時期に退職するタイミングでは、誰の処理がどこまで進んでいるかを見失いやすくなります。Scheduled Tasksで「毎週月曜に、最終出社日が2週間以内の退職予定者と、その人のオフボーディングリクエストの進捗を一覧化する」タスクを組んでおくと、対応漏れに早く気づけます。

{taishoku_meibo.csv} と Freshserviceの
オフボーディングリクエスト一覧を突き合わせてください。
 
- 出力: 退職者ごとに、最終出社日・リクエスト起票の有無・
  ステータスを一覧化した表
- 最終出社日まで2週間を切っているのにリクエスト未起票の人を
  最上段に表示する
- 実行結果は要約せず、表をそのまま出力する

公式の安全ガイドは、Scheduled Tasksについて機微データや取り消しにくい操作を避けるよう注意しています。退職者名簿CSVは個人データそのものなので、この注意はそのまま当てはまります。Autoモードでの定期実行を前提にするのではなく、タスクに読ませる列を氏名・最終出社日・リクエスト状況など必要最小限に絞り、実行のたびに出力を確認する運用にしてください。また、Scheduled Tasksはリモート環境で実行されるため、手元のフォルダに置いたCSVをそのまま参照させることはできません。ローカルのファイルを読ませる必要があるタスクは、Scheduled Tasksではなくローカルでの実行に留める必要があります。実行が失敗した場合の気づき方や復旧の手順はCoworkでタスク失敗をリカバリするにまとめています。

処理完了の確認は子チケットの状態で締める

オフボーディングリクエストを起票した時点で作業が終わったと見なすと、システムごとの権限剥奪が漏れたまま放置される事故につながります。FreshserviceのfetchOffboardingRequestTicketsを使えば、1件のオフボーディングリクエストに紐づく子チケットの状態を一括で取得できます。

リクエストID {request_id} のオフボーディングリクエストに紐づく
子チケットの状態を一覧化してください。
 
- 出力: チケット名・担当システム・現在のステータスの表
- 未クローズのチケットを最上段に表示する
- すべてクローズ済みなら「完了確認済み」と明記する

この確認を退職日の1〜2週間後に改めて実行すると、権限剥奪の作業自体は完了していても、確認漏れのまま塩漬けになっているチケットに気づけます。

よくあるつまずき

退職者本人のアカウントで接続したコネクタが切れる

Freshserviceなどのコネクタは、接続したアカウントの権限で動きます。退職処理の一部を退職者本人のアカウント権限で接続していた場合、アカウントが無効化された時点でその接続も切れます。オフボーディング関連の接続は、システム管理者など継続して在籍するアカウントで組んでおく必要があります。

貸与品台帳とFreshserviceの資産情報が食い違う

台帳更新が手作業のまま放置されている組織では、Freshservice側の資産情報と実際の貸与記録がずれていることがあります。突き合わせの結果に大きな抜けや重複が出た場合は、自動化の設計より先に台帳の運用そのものを見直す必要があります。

引き継ぎ資料の洗い出しが個人用フォルダまで広げてしまう

指示文で除外条件を明示しないと、退職者の個人用下書きフォルダや、業務に無関係な個人的なメモまで候補に含まれることがあります。除外条件は毎回書くよりGlobal Instructionsに寄せておくと、依頼のたびに書き直す手間が省けます。設定の階層ごとの使い分けはClaude Coworkカスタマイズにまとめています。

よくある質問

Freshserviceを導入していない場合、この仕組みは使えないか

Freshserviceの専用ツールが使えないだけで、考え方自体は流用できます。オフボーディングの起票先が別のITSMツールやメール・チャットでの依頼であっても、Coworkはそのツールに対応するConnectorがあれば同じように起票・確認を任せられますし、Connectorがないツールでもブラウザー操作で画面から起票する形は取れます。重要なのは特定のツールへの依存ではなく、①起票前に内容を人が確認する②処理完了を子チケット単位で確認する、という2つの手順を組み込むことです。

退職者本人がCoworkのScheduled Tasksを設定していた場合はどうなるか

退職者本人が自分のアカウントで作成したScheduled Tasksは、本人のアカウントに紐づいたまま残ります。無効化後にそのタスクがどうなるかは断定できないため、無効化前に「Scheduled」ページで本人名義のタスクを棚卸しします。続けて必要なタスクがあれば、後任が自分のアカウントで同じ内容のタスクを作り直す形にします。この確認を引き継ぎ資料の洗い出しと合わせて項目に含めておくと、退職後に「誰も知らないタスクが動いていた」という事態を避けられます。

まとめ

Coworkによるオフボーディングの自動化は、アカウント無効化申請の起票、貸与品回収リストの作成、引き継ぎ資料候補の洗い出しという3つの下ごしらえに絞ると扱いやすくなります。FreshserviceのcreateOffboardingRequestのような専用ツールを使えば起票作業は大きく減らせますが、アカウント権限に関わる取り消しにくい操作は必ずManual承認を挟み、内容を人が確認してから実行する設計を崩さないことが安全に運用する条件です。採用から入社手続きまでの前工程はCowork人事の実務で扱っているので、入社時と退職時の両方でCoworkの役割分担を揃えておくと、人事フロー全体の設計に一貫性が生まれます。