# 端末調達の標準業務フロー｜需要確認から受入・支払・資産登録まで迷わず進める

端末調達は「申請を受けて見積もりを取り、安い販売者へ発注する」だけでは完結しません。既存在庫を確認せずに新品を買う、必須仕様が評価途中で変わる、発注者自身が検品と支払承認まで行う、納品された代替品を口頭で受け入れる、といった運用は、過剰在庫、情報漏えい、請求誤り、不正、監査証跡の欠落につながります。

本記事は、総務、情報システム、購買、セキュリティ、経理、利用部門、内部統制の担当者向けに、端末調達を需要受付から事後評価まで一つの案件として管理する標準業務フローを示します。新品・中古・リースのどれを選ぶ場合でも使えるよう、各工程の入力、判断、出力、責任者、停止条件と、分納・仕様変更・緊急調達の分岐を具体化します。

最初に案件IDと責任分界を固定する

メールやチャットだけで調達を進めると、見積書、仕様変更、承認、納品、請求が分散します。依頼を受けた時点で案件IDを発行し、関連資料と意思決定を一か所へ集約します。

案件台帳の必須項目

  • •案件ID、申請日、希望納期、利用開始日
  • •申請部門、利用責任者、費用負担部門
  • •端末種別、予定数量、利用目的、利用期間
  • •取扱データ、持出し、通信、管理方式
  • •予算、購入・リース・中古の許容範囲
  • •申請、仕様、セキュリティ、評価、承認、発注、受入、支払の担当者
  • •見積書、評価表、契約、注文、納品、検品、請求への参照
  • •現在工程、保留理由、次の期限、例外の有無

一人が複数の役割を兼ねる小規模組織でも、申請者が自分の申請を最終承認しない、発注者が単独で受入と支払を確定しない、振込先変更は別担当が確認する、という最低限の職務分離を設けます。

需要受付で「欲しい機種」から「必要な業務能力」へ変換する

申請者が指定したモデルをそのまま要件にすると、過剰性能や標準外端末が増えます。受付担当は、利用目的、必要性能、セキュリティ、納期、期間を聞き取り、モデル名ではなく満たすべき状態へ変換します。

受付時の質問

  • •誰が、どの業務で、いつからいつまで使うか
  • •必須アプリ、CPU・メモリー・容量、画面・重量の要件は何か
  • •個人情報・機密情報を保存するか、社外へ持ち出すか
  • •MDM、EDR、認証、暗号化、ゼロタッチ登録が必要か
  • •通信方式、SIM、周辺機器、海外利用の条件はあるか
  • •故障時に業務を何時間まで停止できるか
  • •新品でなければ満たせない理由があるか
  • •利用終了後に再配布、返却、売却できるか

希望納期が短い場合も、日付だけを記録せず、遅れた場合の業務影響と暫定代替を確認します。緊急性は承認省略の理由ではなく、どの統制を簡略化し、いつ補完するかを決める材料です。

既存在庫・回収予定・修理可能性を先に確認する

外部調達の前に、保管在庫、退職・異動による回収予定、修理中端末、短期利用の返却予定を確認します。台帳上の在庫だけでなく、実物、状態、ロック、管理登録、利用可能日を確かめます。

再利用判定

  1. 必須仕様とOSサポートを満たす
  2. 所有者・保管場所・個体番号が一致する
  3. データ消去または再設定の証跡がある
  4. バッテリー、外観、主要機能が基準内である
  5. MDM・アカウント・通信契約を再割当てできる
  6. 設定・物流を含めても希望日に間に合う

再利用できる場合は購入回避額を記録します。利用できない場合は、「在庫なし」だけでなく、性能不足、修理費過大、サポート終了、回収遅延など理由を残し、次回の需要計画に返します。

要求仕様と受入基準を同時に作る

見積依頼時の仕様と納品時の検査基準が別物だと、受入担当が合否を判断できません。要求仕様を作る段階で、各項目の確認方法と不適合時の処置を定めます。

要求仕様書の構造

  • •必須条件：満たさなければ不採用となる項目
  • •評価条件：満たすほど加点する項目
  • •許容範囲：後継機、色、容量、外観差など変更可能な範囲
  • •証拠：仕様書、写真、個体一覧、検査記録、証明書
  • •受入方法：全数、抜取、システム照合、動作確認
  • •不一致処置：保留、交換、返品、減額、再検査

中古端末では、モデル・容量・地域仕様、外観ランク、バッテリー、アクティベーション・ネットワーク・MDMロック、修理・非純正部品、データ消去、保証、返品期限を具体化します。「良品」「動作品」だけでは受入基準になりません。

セキュリティ審査を見積依頼の前に通す

価格比較後にセキュリティ要件を追加すると、候補の入替えや再見積もりが発生します。製品と運用のリスクに応じ、暗号化、認証、更新、管理、修理、終了時処理を要求仕様へ組み込みます。

審査する情報

  • •OS・ファームウェアの更新方針とサポート終了予定
  • •セキュアブート、ストレージ暗号化、鍵保護、認証
  • •MDM・EDR・IdP・証明書との互換性
  • •初期設定、不要サービス、遠隔管理、ログ
  • •脆弱性通知、修正、重大事故時の連絡
  • •修理・交換時の端末、記憶媒体、データの取扱い
  • •クラウド連携、外部送信、データ保存場所
  • •廃棄・返却・売却時の消去方式と証跡

IPAのIT製品の調達におけるセキュリティ要件リストは、製品分野別の脅威と要件を整理する材料になります。項目を無条件に全件適用せず、業務で扱う情報と利用環境に対応付け、適用・非適用の理由を記録します。

販売者の適格性と供給網を審査する

安い見積もりでも、仕入経路、所有権、品質管理、事故対応が不明なら、納品後の損失が大きくなります。新規販売者、大口案件、異常に安い条件、海外経路、中古ロットは審査を強化します。

販売者審査の確認項目

  • •法人情報、所在地、代表・契約責任者、振込先名義
  • •許認可、正規流通・仕入経路、所有権の確認方法
  • •在庫量、供給能力、分納計画、代替調達先
  • •品質検査、個体管理、データ消去、返品・保証
  • •情報セキュリティ、個人情報、事故・脆弱性対応
  • •物流、修理、消去、処分の再委託先
  • •財務・事業継続、製品終了・供給停止時の対応
  • •過去の納期、誤納、初期不良、請求不一致、是正実績

NISTのSP 800-161 Rev.1は、製品・サービスの供給網リスクを組織全体で管理する考え方を示しています。販売者一社の審査で終えず、製造、流通、更新、修理、クラウド、廃棄までの依存と代替可能性を確認します。

RFI・RFQで同じ条件の回答を集める

市場情報が不足する案件は、価格を求めるRFQの前にRFIを行い、供給可能な仕様、数量、納期、サービスを把握します。RFQでは全候補へ同じ締切・様式・質疑回答を提供します。

見積回答で揃える項目

  • •モデル、構成、個体条件、数量、単価、税
  • •送料、設定、管理登録、保証、修理、交換費
  • •納期、分納日、最低数量、価格有効期限
  • •新品・中古区分、外観・機能・バッテリー基準
  • •付属品、梱包、輸送、納品場所
  • •返品、取消、代替品、供給不能時の条件
  • •支払、所有権・危険負担の移転時点
  • •回収、消去、下取り・売却の費用と条件

候補ごとに条件が違う場合、回答をそのまま比較せず、同じ数量、利用期間、保証水準、物流範囲へ正規化します。質疑によって重要条件を変えた場合は全候補へ通知し、特定候補だけへ有利な情報を与えません。

必須条件・TCO・リスクを分けて評価する

最初に必須条件の適合を確認し、不適合案を価格点で救済しません。次に、同じ利用期間のTCOと、品質・納期・セキュリティ・供給網・循環性を評価します。

評価の順序

  1. 必須仕様、法令、セキュリティ、所有権の適合判定
  2. 見積条件を同一範囲へ補正
  3. 本体、設定、保守、停止、回収、残存価値を含むTCO計算
  4. 品質、納期、保証、販売者、供給網リスクの採点
  5. 重みと採点根拠のレビュー
  6. 感度分析と最終候補の選定

例えば購入価格が一台1万円安くても、故障交換、短いサポート期間、設定工数、返却費が一台1.5万円多ければ総額は逆転します。数量、故障率、利用年数、回収価値を変えた場合にも順位が変わらないか確認します。

承認は「金額」だけでなく変更点と残存リスクを見る

承認者へ見積書だけを渡さず、需要根拠、候補比較、推奨理由、予算差、例外、残存リスクを一枚にまとめます。

承認パッケージ

  • •必要性、数量根拠、既存在庫を使えない理由
  • •要求仕様、受入基準、セキュリティ審査結果
  • •候補、適合性、TCO、リスク、販売者審査
  • •推奨案と次点案、選定・除外理由
  • •予算、費用負担、支払条件、残存価値
  • •標準外、随意契約、緊急、単一供給元などの例外
  • •契約上の未解決事項と残存リスクの受容者

承認後に数量、モデル、単価、保証、販売者、納期が重要な範囲を超えて変わった場合は、元の承認を流用せず差分承認へ戻します。変更閾値は金額率だけでなく、必須条件・安全性・販売者変更を含めます。

契約・注文書で合意条件を固定する

口頭や見積書だけで発注せず、契約・注文書へ仕様、数量、価格、納期、受入、不一致対応を反映します。

発注前ゲート

  • •法人名、振込先、税、通貨、支払条件が承認内容と一致する
  • •モデル、数量、品質、個体情報、付属品が明記される
  • •納期、分納、納品場所、物流責任が明記される
  • •検査資料、消去証跡、保証、返品条件が明記される
  • •所有権、盗難・偽造・権利侵害への責任が明記される
  • •脆弱性・事故・リコール・製品終了時の通知が明記される
  • •仕様変更と代替品は事前の書面承認が必要とされる

注文番号を請求書・納品書へ記載させ、案件IDと結び付けます。発注後の変更は元注文を上書きせず、変更番号、理由、差額、承認者、発効日を残します。

納期・分納・代替品を変更管理する

納期遅延や欠品時に、担当者同士の会話だけで別モデルを受け入れると、互換性やセキュリティが崩れます。

分岐ルール

  • •分納：各便の数量、日付、受入、請求上限を分ける
  • •納期遅延：業務影響、暫定代替、違約・取消条件を判断する
  • •数量不足：不足分を未納として残し、全量請求を認めない
  • •過納：承認なく在庫化せず、返送または追加承認を行う
  • •代替品：必須仕様、MDM、周辺機器、保証、TCOを再評価する
  • •価格変更：有効期限と契約条件を確認し、差分承認を得る
  • •販売者変更：新規審査と契約・振込先確認をやり直す

代替品が上位モデルでも自動承認しません。消費電力、重量、ポート、OS、管理登録、修理、標準イメージへの影響を確認します。

受入検品で注文・現物・証跡を照合する

受入担当は納品書への押印だけでなく、注文条件と現物を確認します。大量ロットでは全数照合すべき項目と、統計的に抜取可能な項目を分けます。

全数で確認する項目

  • •数量、モデル、容量、地域・通信仕様
  • •シリアル番号・IMEIと個体一覧の一致、重複
  • •起動、アクティベーション、MDM・企業登録・盗難ロック
  • •重大破損、禁止構成、必要付属品
  • •データ消去・所有権など個体証跡の紐付け

基準に基づき機能検査する項目

  • •画面、カメラ、マイク、スピーカー、端子、通信、センサー
  • •バッテリー状態、充電、発熱
  • •外観ランク、修理・非純正部品、液体侵入の兆候
  • •OS更新、暗号化、管理登録、業務アプリの動作

合格、保留、不合格を個体単位で記録し、不合格品を利用可能在庫へ混ぜません。返品・交換期限、販売者回答期限、再検査日を案件台帳で追跡します。

三点照合後に支払承認と資産登録を行う

支払前に注文、受入、請求の三点を照合します。分納時は受入済み数量を上限とし、未納分や不合格分を支払いません。

三点照合

  • •注文番号、販売者、品目、数量、単価、税、送料
  • •受入済み数量、保留・返品・交換中の数量
  • •請求書番号、請求日、支払期限、振込先
  • •値引き、返品、前払、分納、為替差の処理
  • •承認済み変更注文との一致

支払承認と並行して、資産ID、個体番号、モデル、取得日、取得価額、利用者、場所、費用部門、保証期限、管理状態を資産台帳へ登録します。キッティング・貸与が完了した日も記録し、購入数と稼働数を区別します。

緊急調達は最小統制と事後レビューで管理する

重大障害、災害、供給停止では通常工程を短縮できますが、案件ID、必要性、数量、販売者、金額、最低限の所有権・セキュリティ・受入確認は省略しません。

緊急経路

  1. 緊急性と業務停止影響を記録する
  2. 省略する工程と代替確認を指定する
  3. 期限付きで権限者が承認する
  4. 最低限の注文条件を文書化する
  5. 到着時に通常と同じ受入・個体確認を行う
  6. 所定日までに販売者審査、契約、証跡を補完する
  7. 価格、品質、分割発注、再発防止を事後レビューする

「少額だから」「いつもの販売者だから」は緊急理由にしません。緊急購入が繰り返される場合は、安全在庫、承認所要時間、標準機、供給契約の設計不良として改善します。

完了判定と事後評価を次の調達へ戻す

発注・支払で案件を閉じず、未納、返品、貸与、請求、台帳登録が完了したことを確認します。

完了条件

  • •注文数量が合格・返品・取消のいずれかで確定した
  • •不合格・交換・減額・返金が解決した
  • •請求と支払が受入実績に一致した
  • •全個体が資産台帳と管理システムへ登録された
  • •契約、評価、承認、注文、検品、請求の証跡が保存された
  • •利用部門へ引渡し、利用開始、保証窓口が通知された
  • •再利用・返却・売却の予定日が登録された

30日・90日などの時点で、納期、初期不良、設定工数、問合せ、性能、販売者対応を評価します。予測TCOと実績差、在庫の余剰、標準外端末の増加も確認し、標準仕様、販売者ランク、契約条件、安全在庫へ反映します。

標準フローの実務チェックリスト

  • •[ ] 案件IDと責任者・承認者を登録した
  • •[ ] 業務能力、利用期間、データリスクを確認した
  • •[ ] 既存在庫、回収予定、修理・再利用を確認した
  • •[ ] 要求仕様と受入基準を同時に作成した
  • •[ ] セキュリティ要件を見積前に審査した
  • •[ ] 販売者と供給網の適格性を確認した
  • •[ ] 全候補へ同じRFQ条件と質疑回答を提供した
  • •[ ] 必須条件、TCO、リスクを分けて評価した
  • •[ ] 需要根拠、例外、残存リスクを含め承認した
  • •[ ] 契約・注文に仕様、受入、変更条件を反映した
  • •[ ] 分納、遅延、代替品を差分承認した
  • •[ ] 注文・現物・個体証跡を受入時に照合した
  • •[ ] 注文・受入・請求の三点照合後に支払った
  • •[ ] 全個体を資産台帳・MDMへ登録した
  • •[ ] 緊急調達の省略工程を期限内に補完した
  • •[ ] 不良、TCO、販売者実績を次の調達へ反映した

まとめ：各工程の「入力・判断・出力・停止条件」を明文化する

端末調達の標準化で重要なのは、手順書を長くすることではありません。需要、在庫、仕様、セキュリティ、販売者、見積、承認、契約、受入、支払、資産登録を一つの案件でつなぎ、各工程で何がそろえば進めるか、何が起きれば止めるかを明確にすることです。

候補端末の残存価値をTCOへ入れる場合は、同じモデル・容量・状態・時点で[中古端末の買取相場を確認する](/kaitori-search)と自社の売却実績を確認し、検品、消去、物流、手数料を引いた純回収額で比較します。最初の改善では、直近一件の調達を案件受付から支払まで時系列に並べ、口頭判断、重複入力、待ち時間、責任者不明、証跡欠落を特定してください。