入社・退職で発生する申請と回収の設計

入社が決まると、情シスと総務には同時に複数の依頼が飛んできます。アカウントを作ってほしい、ライセンスを割り当ててほしい、PCを用意してほしい、机と椅子を発注してほしい——。それぞれ申請ルートも承認者もリードタイムも違うのに、期日だけは「入社日」で共通しています。

退職はその逆回しですが、難易度は上がります。渡したものの一覧が、どこにも残っていないことが多いからです。

本記事では、入退社で発生する申請と回収を1つの業務として設計する方法を整理します。端末そのものの制御（リモートロック、データ消去）はMDMとは｜端末管理の仕組みと導入手順で扱っているので、ここでは申請と回収の側に絞ります。

この記事の要点

• 入社時に走るのはアカウント・ライセンス・端末・備品の4種類。承認者もリードタイムも違うので、同じ扱いにすると必ずどれかが間に合わない。名刺・社員証・入館カードは入社日が確定しないと発注できず、発行の待ち時間も入る。
• 逆算すべきは入社日ではなく、最も納期の長いものの発注期限。実務ではPCがそれに当たることが多い。
• 回収漏れは担当者の注意不足ではなく、「誰に何を渡したか」が記録されていない構造から生じる。
• 見落とされやすい4つ目が承認者・代理者の設定。退職者が承認ルートに残っていると、本人がいなくなった後に申請が止まる。
• チェックリストは作った直後から実態とずれる。貸与データから自動生成できる状態を目指すほうが続く。

入社時に走る4種類の申請

「入社対応」とひとまとめにされがちですが、中身は性質の違う4つです。

種類	例	承認する人	リードタイムの性質
アカウント	社内システム、SSO、共有フォルダの権限	情シス＋利用部門の責任者	即日〜数日。ただし権限設計の確認が入ると延びる
ライセンス	Microsoft 365、業務SaaS	情シス（予算枠による）	在庫があれば即日、追加購入が要ると発注が挟まる
端末	PC、スマートフォン、周辺機器	情シス＋予算承認	最も長い。調達＋キッティングで数週間
備品	机・椅子・ロッカー、名刺・社員証・入館カード	総務＋予算承認	在庫があれば数日。名刺・社員証は印刷／発行の待ち時間が入る

4つを同じ扱いにすると、たいてい端末が間に合いません。逆算の起点は入社日ではなく、最も納期の長いものの発注期限です。

権限は「誰が承認するか」で詰まる

アカウント申請で時間がかかるのは、作業そのものではなくどの権限を付けてよいかの判断です。情シスは付与作業はできても、その人が見てよい範囲は判断できません。利用部門の責任者が承認者に入っていない設計だと、情シスが個別に確認して回る時間が発生します。

SSO利用申請まわりの標準機能でどこまで回せるかはMicrosoft 365 SSO申請承認、標準機能の限界と解決策で整理しています。

名刺・社員証・入館カードは、発行の待ち時間を見落としやすい

机や椅子と同じ「備品」にまとめられがちですが、この3つは性質が違います。入社日が確定しないと発注できない（氏名・所属・顔写真が要る）のに、印刷や発行そのものに数日から1週間かかるためです。入社日の直前に配属が変わると、名刺と社員証だけが間に合わないという形で表面化します。

さらに入館カードは、発行と同時にどのエリアに入れるかという権限の話になります。総務が発行し、権限の範囲は拠点の管理者が決める、という二段構えになっている組織では、承認者を先に決めておかないと発行が止まります。退職時の回収対象としても漏れやすい区分なので、誰に何番のカードを渡したかは発行の時点で記録に残してください。

端末は「承認してから調達」では間に合わない

PCの調達は、承認が下りてから発注し、届いてからキッティングするという直列の工程です。内定から入社まで1か月を切っている場合、ここが最大のボトルネックになります。

対策は2つです。在庫を持つか、承認から発注までの時間を詰めるか。在庫を持つ場合は遊休資産のコストが発生するので、月あたりの入社人数が読める組織でないと過剰になります。承認から発注までを詰める考え方は備品購入の稟議はいくらから？金額基準と書き方の金額基準の設計と同じです。

退職時に回収するもの

回収の対象は、入社時に渡したものと入社後に増えたものの合計です。後者が記録されていないことが、回収漏れの主因になります。

物理的なもの（端末・備品・カード類）

PCとスマートフォンは意識されますが、漏れやすいのは後から追加で渡したものです。予備のモニター、出張先で買った変換アダプタ、再発行した入館カード、法人カード。渡した時点で台帳に載っていなければ、退職時に思い出す手段がありません。

台帳の作り方については備品管理システム比較7選｜選定の進め方にまとめていますが、重要なのは製品選定よりも登録のタイミングです。購買や貸与が発生した時点で自動的に台帳へ載る構成でないと、記録は必ず実態からずれていきます。

アカウントと権限

アカウントの停止は退職日に行われますが、漏れやすいのは個別に付与した権限です。共有フォルダ、外部SaaS、購買サイトのアカウント。情シスが一括で管理しているものは止められますが、部門が独自に契約したSaaSは把握できていないことがあります。

購買サイトのアカウントを誰が持っているかという論点はオフィス用品通販6社比較｜主要サイトの違いと選び方でも扱っています。

見落とされやすい4つ目：承認者・代理者の設定

物と権限に意識が向きがちですが、承認ルートに残った退職者が後から効いてきます。承認依頼は作成できるのに誰も操作できない、という形で表面化し、原因の特定に時間がかかります。

退職処理の手順に「承認者マスタと代理設定の棚卸し」を組み込んでください。設計側の話は承認者マスタの設計｜組織改編で壊れない承認ルートと代理承認の設計｜承認者不在で止めない、証跡を壊さないで扱っています。

チェックリストは、作った直後からずれ始める

入退社対応の改善というと、まずチェックリストの整備に向かいます。有効ですが、単体では続きません。理由は2つです。

1. 貸与するものが増える：新しいSaaS、新しい周辺機器。リストの更新は誰の担当でもないまま放置される
2. 人によって渡すものが違う：職種・拠点・役職で構成が変わり、共通リストでは網羅できない

続く形にするには、リストを人が書くのではなく、その人に何を渡したかの記録から生成することです。購買・貸与が発生した時点で台帳に載っていれば、退職時の回収リストは「その人に紐づく貸与レコードの一覧」として自動的に出せます。

つまり、退職時の課題に見えているものの大半は、入社時とその後の記録のとり方の問題です。

進め方（3段階）

1. いま渡しているものを棚卸しする — 職種ごとに、入社日に必要なものを書き出す。この時点でリストが職種ごとに違うことが見えます
2. 発注期限から逆算した期日を決める — 最も納期の長いもの（多くはPC）を起点に、いつまでに申請が上がっていればよいかを確定させる
3. 貸与の記録を購買側に寄せる — 新しく渡すものは、購買・貸与のタイミングで記録に載せる。既存分は棚卸しのときにまとめて登録する

3を先にやろうとすると、過去分の登録作業で止まります。新規分から記録に載せ始めて、過去分は追いかける順序が現実的です。

1Approvalでの実現方法

1Approvalでは、購買が承認・実行された時点で、その内容が購買データとして残ります。誰の申請で、何を、いくらで買ったかが記録されるため、貸与台帳を別途手で作る必要がありません。

入社時の端末・備品の調達は、承認と同時に発注が実行される仕組みのため、承認待ちで発注が止まる時間を減らせます。入社日から逆算したスケジュールで最も読みにくいのがこの部分なので、ここが短くなるとリードタイム全体が安定します。

法人決済を前提とした仕組みのため、入社時の備品を担当者が立て替える運用も不要です。立替精算そのものを減らす考え方は立替精算をなくす方法｜法人カード・一括請求の違いで整理しています。

機能の詳細は1Approval 消耗品・購買のページをご覧ください。

よくある質問（FAQ）

入社準備はいつから始めるべきですか？

最も納期の長いものの発注期限から逆算してください。PCの調達とキッティングに数週間かかる組織であれば、入社日の3〜4週間前には申請が上がっている必要があります。逆算の起点を入社日にすると、端末だけが間に合わないという状態になります。

退職時の回収漏れを防ぐ一番効果的な方法は何ですか？

渡した時点で記録することです。回収時にリストを作ろうとすると、記憶と推測に頼ることになります。購買や貸与が発生したタイミングで台帳に載る構成にしておけば、回収リストはその人に紐づくレコードとして出せます。

部門が独自に契約したSaaSはどう把握すればよいですか？

購買・契約の申請ルートを1本に集約するのが原則です。部門が独自に決済できる状態のままでは、情シスが把握する手段がありません。金額基準を設けて一定額以上は申請を必須にし、少額でも支払手段を法人側に寄せると、記録が残ります。

入退社のチェックリストは職種ごとに分けるべきですか？

分けたほうが実態に合いますが、数が増えると更新されなくなります。職種ごとの差が大きいなら、リストを固定で持つのではなく、貸与の記録から生成する形に切り替えるほうが続きます。

退職者が承認者に設定されたままだと何が起きますか？

承認依頼は作成できるのに誰も操作できない状態になり、申請が止まります。原因がアカウント側にあるため、フローを見ても分からず特定に時間がかかります。退職処理の手順に承認者・代理者設定の棚卸しを組み込んでください。

まとめ｜退職時の問題は、入社時の記録で決まる

入退社対応は、4種類の申請が同時に走り、期日だけが共通しているという構造を持っています。ここで最初に決めるべきは、最も納期の長いものから逆算した申請期限です。

そして退職時の回収漏れは、担当者の注意力ではなく記録の有無で決まります。渡した時点で記録に載る構成になっていれば、回収リストは自動的に出せます。退職の課題に見えているものの大半は、入社時とその後の記録のとり方の問題です。

まずは直近に退職した数名について、渡したものを全部言えるかを確かめてみてください。言えない項目があれば、そこが記録に載っていない領域です。