IT資産管理システムの発注は、資産と目的を整理し、発注形態を選び、RFPで条件をそろえ、複数社を比べる順に進めると、導入後のミスマッチを抑えられます。
発注前は資産情報を洗い出し、委託先は同じ条件で比べて選びます。全体像はIT資産管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・IT資産管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
IT資産管理システムの発注・外注の始め方
発注の準備では、Excel台帳、AD／Entra ID、MDMに分散した情報を棚卸しします。EDRや購買、会計に加えて、SaaSの情報も同じ作業の対象になります。
まず自社で「何を、どこまで管理したいか」を言語化してから、開発会社に声をかけます。管理対象と必要な情報を整理しておくと、各社の提案を同じ条件で比べやすくなります。
発注前に整理すべき現状情報
見積もりの前提がそろっていないと、各社が異なる条件で見積もることになります。確認する情報は、次の4つの区分です。
- 端末情報：台数、対象OS（Windows・macOS・iOS・Android）、拠点数
- 既存環境：AD／Entra ID、MDM、EDR、ITSM、SaaS、ネットワーク機器
- 管理要件：必須機能、データ保管方法、SLA、成果物、検収基準
- 運用条件：引き継ぎ方法と、SaaSアカウント数を含む棚卸し範囲
発注目的とKPIの設定
目標を数値にしてRFPに含めておくと、各社の提案を機能の一覧ではなく、目標の達成手段として比べられます。
- 棚卸し工数：50%削減が目標
- 端末管理：未管理端末ゼロを目指す
- パッチ適用：適用率98%が目標
- ライセンスとアカウント：未使用ライセンスの削減と、退職者アカウントの停止時間の短縮を測定
目的が曖昧なまま発注すると、稼働後に資産が見えるようになっただけで終わるおそれがあります。
社内の関係部門との早期の連携
発注の準備には、情報システム部門だけでなく、人事・総務、購買・経理、法務・コンプライアンスも関わります。
- 人事・総務：端末の貸与・返却、異動情報の確認
- 購買・経理：資産計上や減価償却の扱い
- 法務・コンプライアンス：ログの取得範囲と監視方針
RFPの初期段階で各部門に聞き取り、その結果を要件に反映しておくと、稼働後の手戻りを防げます。ログや位置情報の取得範囲は、労務部門と事前に調整し、従業員への説明責任に備えます。
発注形態の選び方（SaaS・パッケージ・スクラッチ・ハイブリッド）
発注形態によって、契約の中身が異なります。既製のクラウド製品を契約する形、パッケージへの追加開発を委託する形、統合台帳やハイブリッド構成を開発する形があります。
SaaS契約とパッケージ委託の違い
SaaSは短期間かつ低い初期費用で始められ、アップデートの対応も不要です。ただし、個別カスタマイズ、データ所在、API制約は、契約前に確認しておく必要があります。
パッケージやオンプレミスは、閉域ネットワークや既存の運用、細かな制御に適します。一方で、サーバーの更新や保守費が発生するため、保守契約の範囲を委託先に確認しておきます。
スクラッチ委託とハイブリッド構成の違い
スクラッチ開発では、購買・会計・IAM・CMDBまで独自の業務に合わせられます。一方で、エージェント開発、OS追随、セキュリティ更新を長く負担する契約になりやすいため、保守体制も発注時に決めておきます。
LANSCOPEやIntuneなどから端末情報を統合基盤に集め、台帳・契約・SBOMを扱うハイブリッド構成は、既存の投資を活かせます。さらに、市販の機能にない業務フローや統合台帳だけを開発すれば、納期と保守のリスクを抑えやすくなります。
RFP・要件整理の進め方
RFPを丁寧に作っておくと、開発会社やベンダーから具体的な提案を得やすくなり、比較の精度も上がります。そのうえで、2026年時点の制度動向も踏まえます。
RFPに記載すべき必須項目
対象や運用の前提をそろえるため、RFPには現状台帳や端末台数を記載します。加えて、対象OS、拠点数、既存ツールも含めます。
- 機能と環境：必須機能とデータ保管方法
- サービス条件：SLA、成果物、検収基準
- 運用：引き継ぎ範囲の明記
- 要件分類：「台帳」「ライフサイクル」「SAM」「パッチ／脆弱性」の区分
- 追加要件：「ログ」「連携」「権限」「監査」「非機能」の分類
各要件を必須、将来、不要に仕分けて示すと、提案の過不足を抑えられます。
PoCの合否基準の数値化
PoCは、感覚的な使いやすさよりも数値の基準で評価するほうが、稼働後のミスマッチを防ぎやすくなります。数値にしておくと、各社の結果を同じ基準で比べられます。
- 登録と台帳：全端末の登録率と台帳との差異
- 検知と処理：パッチ検出時間、退職者処理の所要時間
- アラート：対応時間の測定
- 環境：Windows／Mac／スマホ、社外端末、低帯域拠点
- シナリオ：退職、紛失、マルウェア検知の検証
公開されている事例には、約3か月の検証のあとにクラウド製品へ移行した例もあります（出典：エムオーテックス「トーセイ株式会社の導入事例」、2025年）。
RFPに含める非機能要件と監視設計
操作ログや位置情報が従業員監視にならないよう、取得目的と対象範囲をRFPに明記します。
- アクセス管理：権限とアクセス監査の方針
- データ管理：保存期間と本人通知の方針
IPAの中小企業向け指針は、一元管理とパッチ適用を整理しています。脆弱性管理や資産管理台帳も、同じ指針で扱われています（出典：IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」）。こうした公的な整理も、自社のRFPに反映できます。
委託先選定と見積比較のポイント
委託先は、価格だけでなく、契約条件や再委託の扱いも含めて比べます。
複数社の同条件での比較
候補は2〜3社に絞り、同じサンプルデータと業務シナリオを使って、デモまたはPoCを行います。
- 管理精度：棚卸しの自動化精度と対応OSの幅
- 連携：既存MDMやAD／Entra IDとの実績
- ログ：保存と閲覧の設計
- 導入支援：どこまでを支援対象とするか
製品ベンダーとSI導入会社では、役割が異なります。そのため、製品契約か、業務に合わせた開発委託かを明確にしてから相談すると、提案の質が上がります。
契約前に確認すべき委託条件
契約前には、委託先の対応範囲を契約書の条件として確認しておきます。個々の条件は、期限や担当が分かる形で書き込んでおく必要があります。
- 委託体制：再委託の有無とデータ移行の責任範囲
- 保守：脆弱性修正の方針と瑕疵対応の期間
- 終了時：データの返却形式
- 障害対応：連絡経路と復旧目標
- 継続運用：退職者停止や脆弱性是正の対応期限とエスカレーション先
見積書のチェックポイント
見積書では、作業ごとの金額と対象範囲を確認します。「一式」と書かれている場合は、件数も尋ねます。
- 費目：標準機能、設定、追加開発、移行、連携ごとの区分
- 導入作業：テスト、研修、保守を分けた提示
- SaaS標準導入：初期費用50万〜300万円、期間2〜8週間
- パッケージ連携：API・AD・MDM連携で300万〜1,000万円、2〜5か月
ここに示す費用は、BtoB管理システムや端末管理の類似案件から編集部が推定したレンジです。金額は、対象OS・台数・連携数によって変わります。
オンプレミス・スクラッチ委託の相場感
委託形態ごとの推定費用、期間、対象範囲を比べて、RFPの条件を絞り込みます。
- オンプレミス・閉域：周辺連携込みで800万〜2,000万円、4〜9か月程度
- インフラ範囲：サーバー、冗長化、バックアップ、ネットワーク、監査ログ、運用設計
- スクラッチMVP：800万〜1,500万円、6〜10か月程度。台帳、棚卸し、権限、基本API、最低限の画面・レポート
- 大規模委託：複数会社・海外拠点向けで2,000万〜5,000万円超、12〜18か月以上
- 対象機能：SAM、CMDB、脆弱性、ITSM、会計・購買・IAM連携、高可用性
対象を絞り、必須要件と将来要件を分けたRFPを渡せば、各社の見積もりを同じ前提で比べられます。
複数ベンダーに分割委託する場合の注意点
既製ツールの導入と統合台帳の開発を別の会社に委託する場合は、どこまでを誰が受け持つかという責任分界を契約前に文書で決めておきます。特に決めておきたいのは、端末情報の取得、API変更への対応、契約終了の影響の3点です。
- 端末情報：取得責任をどちらが担うか
- API変更：誰がいつまでに対応するか
- 契約終了：一方の契約終了が他方へ与える影響
複数社の体制は既存の投資を活かせる一方で、障害の切り分けに時間がかかりやすくなります。そのため、月次定例会や合同の障害訓練を運用ルールに含めます。
IT資産管理システムの発注・外注に関するよくある質問
発注準備の段階で特に質問されやすい点を取り上げます。
RFPはどのタイミングで作成すればよいですか？
現状資産の棚卸しと目的・KPIの整理が終わった段階で作成します。棚卸しが不十分だと、各社の前提がずれ、提案や見積もりを比べにくくなります。
棚卸しに時間がかかる場合は、対象を絞ったスモールスタートのRFPから始める方法もあります。
何社くらいに声をかければよいですか？
候補は2〜3社がおすすめです。社数が多いと比較の手間が増え、少ないと相場観をつかみにくくなります。
既製クラウド製品なら製品ベンダーや代理店、統合台帳の開発ならSI会社やシステム開発会社が候補です。両方を比べる場合は、製品導入と業務連携開発を分けて見積もる方法もあります。
契約後、運用フェーズで確認すべきことは何ですか？
契約後は、棚卸し責任者と月次レビューの体制、障害時の連絡経路、保守契約の範囲を確認します。
未適用パッチや未承認ソフトに加えて、シャドーITや退職者アカウントについても、是正の流れを定めておきます。さらに、課題を誰がいつまでに是正するかを明文化し、見える化だけで終わらない運用にします。
一部の業務だけを外注することもできますか？
部分的な委託も可能です。たとえば、台帳のデータクレンジングと移行を外注し、日々の棚卸しや是正対応は社内で担えます。
委託範囲は、社内IT人材の余力や、継続運用に割ける時間をもとに判断します。そのうえで、委託範囲と社内の担当範囲をRFPと契約書の両方に記し、責任の所在を明らかにします。
IT資産管理システムの発注・外注方法まとめ
発注は、現状資産の棚卸しと目的・KPIの整理から始めます。次に発注形態を選び、RFPに対象範囲、運用分担、非機能要件を記載して、複数社へ同じ条件で提案を依頼します。
PoCでは、全端末の登録率と台帳との差異を数値化します。加えて、パッチ検出時間や退職者処理、アラート対応時間も測ります。
契約前には、再委託とデータ移行の責任を確認します。さらに、脆弱性修正や契約終了時の返却条件も確かめます。
発注後は、棚卸し責任者と月次レビューを決め、検出課題の是正まで運用に組み込みます。端末台数や組織、新しいOS・SaaSの追加に応じて、委託範囲と契約条件も見直します。
最初から完璧な体制を求めるより、対象を絞って始めるほうが現実的です。そのうえで、棚卸し責任者と委託先が同じKPIを追い、段階的に運用を整えます。
▼全体ガイドの記事
・IT資産管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。