IT資産台帳の標準業務フロー｜申請から回収・消去・処分まで迷わず引き継ぐ

IT資産台帳の項目を整えても、現場の更新が遅れれば実物と記録はすぐにずれます。発注担当は納品を知っているのに情報システムへ連絡されない、退職日は人事だけが知っている、回収担当は端末を受け取ったが経理は除却できない、といった「部門間の待ち時間」が主な原因です。

本記事では、総務・情報システム・購買・人事・経理・セキュリティ担当者が同じ順序で処理できるよう、IT資産の申請、発注、受入、設定、貸与、変更、修理、回収、データ消去、再配布、売却・返却・廃棄までを一つの標準業務フローとして設計します。各工程の開始条件、完了条件、担当、証拠、標準時間、差戻し条件を具体化し、担当者が休んでも案件が止まらない運用を目指します。

標準フローは「作業手順」ではなく引継ぎ契約である

「端末を設定する」「台帳を更新する」とだけ書いた手順書では、どこまで終えれば次の担当へ渡せるか分かりません。標準フローは、前工程から何を受け取り、何を確認し、どの成果物を添えて、次工程へ渡すかを定めた引継ぎ契約です。

各工程には最低限、次の六つを持たせます。

• 開始条件：作業を始めてよい条件
• 入力情報：申請、現物、契約、利用者など必要な情報
• 実施内容：確認、設定、承認、記録の具体的な作業
• 完了条件：次工程へ渡してよい客観的な基準
• 証拠：申請番号、検品記録、受領確認、証明書など
• 期限と例外：標準処理時間、期限超過時の連絡先、差戻し条件

担当部署だけでなく、キューの所有者を決めます。「情報システムが担当」ではなく、「受入待ちキューは端末管理チームが毎営業日10時と16時に確認」のように、誰がいつ未処理を拾うかまで定めます。

全体フローを一つの案件番号でつなぐ

発注番号、資産ID、貸与申請番号、修理番号、処分依頼番号が別々に存在すると、端末の履歴を人手で探すことになります。最初の申請でライフサイクル案件IDを発行し、個体確定後は資産IDを軸にすべての記録を関連付けます。

標準フローは次の順序です。

1. 調達・貸与申請
2. 承認・発注
3. 納品・受入検品
4. 資産登録・初期設定
5. 引渡し・利用開始
6. 利用中の変更・点検
7. 異動・退職・更新に伴う回収
8. 回収検品・データ消去
9. 再配布・売却・返却・廃棄の判定
10. 引渡し・会計・契約処理
11. 証跡確認・案件終了

工程を飛ばす必要がある緊急貸与などは、通常フローを曖昧に変えるのではなく、期限付きの例外フローとして記録します。

工程1：調達・貸与申請で必要性を確定する

申請時点で端末の個体は未定でも、利用目的、必要日、利用者、費用負担、データの重要度は決められます。ここで情報が不足すると、過剰な仕様、重複購入、セキュリティ設定漏れ、納期遅延につながります。

開始条件と入力情報

• 利用部門と申請者が特定されている
• 新規入社、増員、故障交換、更新、プロジェクトなど理由が選択されている
• 利用者または共有設備の責任者が決まっている
• 必要日、利用期間、利用場所が入力されている
• 扱う情報区分と必要なアプリ・権限が申告されている
• 標準機で対応できない場合は仕様理由が添付されている

完了条件

在庫の再利用可否を先に確認し、新規購入、既存在庫の貸与、リース追加のいずれかを決めます。承認者は必要性、予算、情報セキュリティ基準、納期を確認します。差戻し時は「情報不足」ではなく、不足項目と再提出期限を示します。

標準処理時間の例は、通常申請2営業日、特別仕様5営業日です。必要日が標準納期より短い場合は、自動的に緊急例外として責任者へ通知します。

工程2：承認・発注で契約情報を正本化する

承認後、購買担当は見積書、注文、契約を確定し、台帳の予定情報へ連携します。注文書をメールに埋もれさせず、案件IDへ紐付けます。

発注時の確認事項

• 承認済みの品目、数量、単価、費用部門と一致する
• 購入、リース、レンタルの区分が明確である
• 納品先、希望納期、検収条件が明確である
• 保証、保守、通信、返却条件が記録されている
• 初期設定や資産ラベル貼付を仕入先へ委託する範囲が明確である
• 中古端末の場合、品質条件、バッテリー、ロック、付属品の基準がある

発注済みになった時点で、納品予定件数を「受入予定キュー」に作成します。納期変更や分納は元注文を上書きせず、変更履歴と残数を残します。注文取消しは予定資産を削除するのではなく、取消理由を付けて終了します。

工程3：納品・受入検品で現物と注文を照合する

受入は、箱が届いたことではなく、会社が管理責任を引き受けられる状態を確認する工程です。納品書だけで数量を確定せず、現物の個体識別情報を読み取ります。

受入担当が行う作業

1. 案件ID、発注番号、納品書を照合する
2. 箱数と端末数を数え、分納・過納・不足を記録する
3. メーカー、型番、容量、色など注文条件を確認する
4. シリアル番号やIMEIをスキャンし、重複を検査する
5. 外観破損、起動、ロック状態、付属品を基準に沿って確認する
6. リースや借用品の場合は所有者ラベルを確認する
7. 合格、不合格、保留を個体単位で登録する
8. 合格品へ資産IDを発行し、保管場所を記録する

差戻し条件

• 発注と型番・数量が一致しない
• 個体識別番号が読めない、または既存資産と重複する
• 破損、起動不良、アクティベーションロックがある
• 注文条件に含まれる付属品や証明書がない
• 所有・契約区分を確認できない

不合格品を合格在庫と同じ棚へ置かず、物理的にも「受入保留」区画へ分けます。保留のまま一定日数を超えた場合は購買責任者へエスカレーションします。

工程4：資産登録と初期設定を同時に完了させる

受入後、情報システムは台帳へ個体を登録し、利用可能な標準状態へ設定します。資産登録だけ先に完了扱いすると、未設定端末が貸与可能に見えるため、設定結果を状態遷移の条件にします。

初期設定の標準項目

• OSとファームウェアを承認バージョンへ更新する
• ストレージ暗号化を有効にする
• MDM、EDR、資産検出ツールへ登録する
• ローカル管理者、初期パスワード、回復キーを規程どおり管理する
• 必要な業務アプリと構成プロファイルを適用する
• 不要な初期アカウント、試用ソフト、外部接続を無効化する
• 自動ロック、バックアップ、ログ、遠隔消去を確認する
• 資産ラベルと画面上の識別情報が一致するか再確認する

自動設定が成功しても、台帳へのチェック結果が届かなければ「設定完了」にしません。失敗端末は原因コード、再処理担当、期限を記録します。標準設定から外れる例外は、利用目的、リスク、代替策、承認者、失効日を必須にします。

工程5：引渡しで利用者と管理責任を結び付ける

机へ置いた、宅配便で送っただけでは貸与完了ではありません。利用者が現物を受け取り、個体と付属品を確認し、利用上の責任を認識した時点で貸与中へ移します。

引渡し記録に含めるもの

• 資産ID、シリアル番号、端末名
• 利用者ID、所属、管理責任者
• 引渡日、利用開始日、返却予定日
• 利用場所、社外持出しの有無
• 充電器、ケーブル、ケースなど付属品
• 引渡し時の外観、バッテリー、動作状態
• 利用規程への同意、受領確認
• 問合せ先、紛失・故障時の連絡方法

宅配の場合は配送完了だけでなく、本人の受領確認を取ります。未受領、宛先不明、代理受領は別状態にし、端末が誰の管理下にあるかを明確にします。共有端末は個人の代わりに設置場所と業務責任者を設定します。

工程6：利用中の変更をイベントで更新する

台帳を月末にまとめて更新すると、異動や修理の間に所在が分からなくなります。利用中の変更は、発生イベントを起点に即時または日次で更新します。

更新を発生させるイベント

• 部署異動、勤務地変更、氏名・雇用区分変更
• 端末交換、増設、付属品追加
• 一時持出し、長期出張、海外利用
• 故障、修理、メーカー交換、代替機貸与
• OS基準違反、MDM未接続、セキュリティ例外
• 利用終了、休職、退職、委託契約終了
• 紛失、盗難、所在確認不能

人事情報は、人事システムを正本として予定日付きで連携します。異動の場合、端末を継続利用するか、費用部門・管理責任者を変更するかを異動日前に判断します。修理では元端末と代替機を別資産として扱い、修理受付番号で関連付けます。

工程7：回収は期限から逆算して開始する

退職日当日に初めて回収を依頼すると、在宅勤務者や長期休暇者から回収できません。人事イベントの確定後、端末一覧を自動抽出し、最終勤務日や契約終了日から逆算して回収します。

回収の標準タイムライン例

• 退職確定日：対象資産と付属品を自動抽出する
• 最終勤務日の10営業日前：本人と上長へ返却案内を送る
• 5営業日前：返却方法、返却先、宅配資材を確定する
• 最終勤務日：対面返却または発送確認を行う
• 翌営業日：未返却を上長・人事へエスカレーションする
• 3営業日後：アクセス停止状況と配送追跡を確認する
• 期限超過：事故・債権・法務対応の要否を判断する

回収依頼時に、利用者へ割り当てられた全資産を一覧で示します。PCだけでなく、スマートフォン、SIM、認証トークン、ドック、入館証なども確認します。利用者の申告だけで完了せず、現物を受け取った担当者が個体識別番号を確認します。

工程8：回収検品とデータ消去を分離する

回収済み端末は、返却時の状態を確定してからデータ消去へ渡します。この二つを同時に扱うと、破損や付属品不足が消去作業後に判明し、責任や費用の判断が難しくなります。

回収検品

• 資産ID、個体識別番号、利用者を照合する
• 外観、画面、カメラ、端子、起動状態を記録する
• パスコード、アクティベーションロック、管理プロファイルを確認する
• 付属品の有無と状態を確認する
• 故障、破損、膨張、水濡れなど安全上の問題を隔離する
• 端末内の記録媒体やSIMを確認する

データ消去

• 資産とデータ区分に合う消去方式を選ぶ
• 消去前に必要な業務データの移行承認を確認する
• 消去ツール、実施者、開始・終了日時、結果を記録する
• 失敗時は再処理し、成功品と物理的に分ける
• 個体別または処理単位の証跡を台帳へ紐付ける
• MDM、IdP、通信、ライセンスから登録を解除する

個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）では、機器や電子媒体の廃棄時に復元できない手段で削除し、委託した場合には実施を確認することが安全管理措置の例として示されています。消去作業を委託しても、完了証跡を確認する社内担当は残します。

工程9：再利用・売却・返却・廃棄を判定する

消去後、端末を自動的に廃棄へ送らず、残存価値、性能、故障、安全性、契約条件、再利用需要を比較します。判定基準がなければ、保管棚に端末が滞留します。

判定の順序

1. 安全上の問題がなく、再設定可能か
2. 社内標準のOS・性能・保証条件を満たすか
3. 近い将来の貸与需要があり、保管期間内に再利用できるか
4. リース・レンタル契約上、返却義務があるか
5. 売却見込み額が検品・消去・物流・保管コストを上回るか
6. 売却できない場合、部品利用または適正廃棄が可能か

判定者と承認者を分け、理由コードを選択します。「古いから廃棄」ではなく、OSサポート外、修理費超過、再利用需要なし、契約返却、売却対象など、後から集計できる形にします。

工程10：社外引渡しと会計・契約処理を閉じる

売却・返却・廃棄では、端末を搬出した日だけで完了にしません。物理、情報、会計、契約の四つの面が揃った時点で終了します。

売却・返却・廃棄の共通確認

• 承認済みの対象一覧と実際の搬出台数が一致する
• 個体識別番号と梱包・引渡し単位が一致する
• 消去・破壊の証跡が対象個体へ紐付いている
• 引渡先、運送会社、日時、受領者を記録している
• 売却代金または処分費用を契約・請求と照合している
• 固定資産除却、リース返却、回線・保守解約を処理している
• 受領書、返却確認、廃棄証明などを受領している

一括処理では、台帳50台、搬出50台、証明書50台、売却明細50台という四つの件数だけでなく、個体IDの集合が一致するか確認します。件数が同じでも別の端末が混ざる可能性があるためです。

工程11：終了判定と事後照合を行う

案件の終了は、担当者が「終わった」と判断するのではなく、完了条件を自動または別担当者が確認します。未回収証跡や会計未処理があれば、端末状態が売却済みでも案件は開いたままにします。

終了ゲート

• 全対象資産が最終状態に到達している
• 未処理、保留、差戻し、消去失敗がゼロである
• 必須証跡が対象資産と一致している
• 会計・契約・回線・ライセンス処理が完了している
• 差異がある場合、例外承認と解消期限がある
• 実行者とは別の確認者が終了を承認している

終了後も変更履歴と証跡は保存期間に従って保持します。訂正が必要な場合は案件を無言で書き換えず、再開理由と承認者を記録します。

SLAと滞留管理でフローを止めない

標準時間は担当者を急かすためではなく、滞留を発見するために設けます。工程ごとの受付時刻、着手時刻、完了時刻を記録し、処理時間と待ち時間を分けます。

管理する指標

• 申請から承認までの中央値と90パーセンタイル
• 納品から受入完了までの時間
• 受入から貸与可能までの時間
• 貸与可能在庫の長期滞留台数
• 回収依頼から現物受領までの日数
• 回収期限超過件数と超過日数
• 回収から消去証跡確定までの日数
• 消去後から再配布・処分までの滞留日数
• 差戻し率と主な不足項目
• 工程別の手作業再入力件数

平均だけでは少数の長期滞留が隠れるため、期限超過件数と最長日数を併記します。担当者別の競争にせず、入力不足、承認待ち、連携失敗、委託先待ちなど原因別に改善します。

差戻し・例外・障害時の逃げ道を設計する

標準フローに合わない案件は必ず発生します。担当者の判断で項目を空欄にしたり、状態を飛ばしたりさせず、公式な例外経路を用意します。

例外申請に必要な情報

• 標準フローを守れない理由
• 対象資産、利用者、期間
• 発生するリスクと影響
• 一時的な代替策
• 解消条件と失効日
• 承認者と再確認日

システム障害で台帳を更新できない場合は、承認済みの一時記録様式を使い、復旧後に案件IDと元記録を紐付けて登録します。口頭や個人のメモだけで貸与・回収を進めないことが重要です。

IPAの中小企業の情報セキュリティ対策ガイドラインは、組織的対策や資産管理台帳を含む実務資料を提供しています。また、IPAの組織における内部不正防止ガイドラインは、基本方針、資産管理、職場環境、事後対策などの観点を整理しています。標準フローには、平常時の効率だけでなく、権限分離、例外期限、証跡、事故時の連携を組み込みます。

100台の退職回収を処理する具体例

月末に退職者30人、契約終了者20人、更新交換対象50人があり、合計100台を回収するとします。各人へ一件ずつメールを送るのではなく、人事イベントから回収案件を作り、資産ID、付属品、最終勤務日、返却方法を一覧化します。

回収結果が、期限内85台、配送中5台、本人確認待ち3台、未発送4台、紛失申告1台、資産割当誤り2台だった場合、単純な回収率は85%ではありません。配送中は管理下が移動中、未発送は利用者管理下、紛失は事故対応、割当誤りは台帳品質問題です。それぞれの次作業と期限を分けます。

翌週、配送中5台が到着、本人確認待ち3台が解消、未発送4台のうち3台が到着、1台が期限超過なら、現物回収は96台です。紛失1台、割当誤り2台、期限超過1台の計4台は、理由の異なる未完了案件として残します。回収済み96台も、検品96台、消去成功94台、消去失敗2台なら、処分判定へ進めるのは94台だけです。

このように、件数を工程ごとの集合として追跡すれば、総数は合うのに対象端末が違うという事故を防げます。

現場用チェックリスト

フロー設計時

• 各工程の開始条件と完了条件が文章化されている
• 入力、実施内容、成果物、証拠が定義されている
• キューを確認する担当グループと頻度が決まっている
• 資産IDと案件IDですべての記録を追跡できる
• 差戻し理由が選択式で、再提出期限が付く
• 緊急対応やシステム障害の例外経路がある

日々の運用時

• 未処理キューを毎営業日確認している
• 前工程の完了条件を満たさない案件を受け取っていない
• 現物と台帳の個体識別番号を工程ごとに照合している
• 状態変更と同時に担当、日時、証拠を記録している
• 期限超過を担当者だけで抱えず、責任者へ通知している
• 例外には理由、代替策、承認、失効日がある

月次レビュー時

• 工程別の滞留件数と最長日数を確認している
• 差戻しが多い入力項目を申請画面や教育へ反映している
• 人事・購買・MDM・会計との不一致を解消している
• 回収済み、消去済み、処分済みの対象集合を照合している
• 消去証跡、受領書、会計処理の未完了を抽出している
• 例外期限切れを通常状態へ戻すか再承認している

まとめ：担当者が迷わないフローは完了条件が明確である

IT資産管理の標準化では、作業項目を長く並べるだけでは不十分です。申請から終了までを一つの案件としてつなぎ、各工程に開始条件、完了条件、責任者、期限、証拠、差戻し条件を置くことで、部門間の受け渡しが安定します。特に、回収済みと消去済み、処分済みと会計終了を分けることが、情報漏えいと台帳不一致の両方を防ぎます。

再利用せず売却する端末は、消去と契約処理の完了後に価値を比較します。中古端末の買取相場を確認すると、端末ごとの状態、数量、物流・検品費を合わせて記録すれば、処分方法の根拠を残せます。まずは現在の業務から「誰かの連絡待ち」で止まっている工程を三つ抽出し、その工程の完了条件とエスカレーション期限を決めるところから始めてください。