資産管理システムのRFP/要件定義書/提案依頼書について

資産管理システムの要件定義は、管理対象の棚卸し、現状(AsIs)の可視化、機能と運用の要件整理の順に進めます。この順なら、見積りの比較と予算超過の防止につながります。

要望が漠然としたままだと、提案条件や金額がばらつき、横並びで比べられません。全体像は資産管理システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・資産管理システムの完全ガイド

管理対象の棚卸しとAsIsの可視化

要件定義は、欲しい機能のリストアップから始めてはいけません。管理対象の棚卸しと現状(AsIs)の可視化が出発点です。

まず決めたいのは管理対象の範囲です。対象の線引きが曖昧なままだと、後から追加が頻発し、要件が膨らんで費用や工期が崩れます。

社内では、固定資産に加えてIT機器やソフトウェアライセンス、リース資産、少額備品を対象に含めるかを、先に決めておきます。

管理対象資産の範囲と粒度の定義

範囲が曖昧なままだと、ベンダーは必要なデータ件数や項目数を見積もれないため、管理する資産の範囲と、資産ごとの属性の粒度を先に決めておきます。

  • 会計上の資産:取得価額10万円以上に限るか、一括償却資産や少額減価償却資産も含めるかを決めます。
  • IT・備品:消耗品扱いの備品やハード、ソフトウェアライセンス、クラウドサブスクリプションから対象を選びます。
  • 属性:取得日・取得価額・耐用年数・場所・部門・利用者に、種別ごとの固有項目を加えた構成にします。

IT機器にはOSやIPアドレス、車両には車検満了日、リース資産には契約満了日といった種別ごとの項目を設定します。

属性の設計は、検索・集計・アラートの実用性を左右します。

対象が広いほど整備の負荷と複雑さが増すため、効果の大きい領域に絞る判断も重要です。

将来必要になる項目も、要件定義の段階で整理しておきます。

フルスクラッチ開発であれば、自社の管理ニーズに合わせて属性を自由に設計できます。

現状のExcel管理(AsIs)の可視化

対象資産を決めたら、次は現状(AsIs)の管理実態を可視化します。この確認が、要件の漏れを防ぐ土台になります。

  • 管理者と台帳:誰がどのファイルを更新し、どの頻度で棚卸しするかを押さえます。
  • 業務手順:減価償却をどのシートで計算しているかを、関係部署から聞き取ります。
  • データ品質:現状のデータの汚れを把握し、重複・表記ゆれ・欠損・現物との乖離を洗い出します。

固定資産台帳・備品台帳・IT機器管理簿が部署ごとのExcelに分かれていると、資産の二重登録や廃棄漏れが起きることがあります。

聞き取りの相手には、経理や情報システム、総務、現場の担当者を含めます。

データの整備には、全体予算の2〜3割が一般的に必要です。これを軽視すると、初年度に30〜40%超過することがあります。

発注側は、AsIsの段階でデータ品質を直視し、自社で整備する範囲とベンダーに委託する範囲を要件に含めておくと、現実的な計画につながります。

ポイント

管理対象の範囲は、属性の粒度と合わせて先に決めておきます。現状のExcel管理は関係部署への聞き取りで把握し、データの重複や欠損も洗い出しておくと、見積りの前提がそろいます。

機能要件と非機能要件の整理

機能要件を必須、優先、将来の3段階に分けた図解
初期リリースの範囲は、優先度を基準に整理できます。

管理対象とAsIsを整理したら、要件定義書の核となる機能要件と非機能要件を決めます。機能要件は「何ができるか」を、非機能要件は「どの品質で動くか」を定めます。

台帳や償却だけでなく、機微な資産情報を扱い、多くの社員が使うための品質も必要です。

機能要件の必須・優先・将来による分類

機能要件は、並べるだけでなく優先度を付けて分類します。

  • 必須:資産台帳の登録/移動・除却履歴や減価償却の自動計算など、業務に欠かせない機能です。
  • 優先:バーコード棚卸し、会計連携、ライセンス管理。
  • 将来:RFID対応、ダッシュボード、モバイル対応。

機能を増やすほど費用は膨らむため、優先度の付け方が予算管理の要になります。すべてを必須にすると、予算超過時に削れず、頓挫しかねません。

優先度が明確であれば、予算超過時に初期リリースから外す機能を冷静に選べます。

まず必須機能で稼働させ、効果を見てから優先機能を追加する進め方もあります。

機能要件の分類は、投資判断に直結します。

各機能が何を解決するかについては、機能を扱った関連記事もご覧ください。

非機能要件(性能・セキュリティ・可用性)

性能、セキュリティ、可用性を、資産数や利用者、業務上の重要度に照らして具体的な要件にします。

  • 性能:大量の資産を検索・集計し、棚卸し時の同時アクセスにも対応します。
  • セキュリティ:役職・部門別の権限、操作ログ、IdP(IDプロバイダー)連携によるシングルサインオンを定めます。
  • 可用性:繁忙期の稼働率目標とバックアップ体制を定めます。

数千〜数万点の資産を高速に検索・集計し、棚卸し時に多数が同時接続しても遅くならない性能を明記します。想定する資産件数と同時利用者数を示せば、ベンダーは適切なインフラを見積もれます。

性能が不足して画面が固まると、現場で使われず、システムが形骸化します。

簿価や利用者の所属を扱うため、誰がいつ何を変更したかを記録する監査ログは、内部統制やJ-SOX対応にも欠かせません。

棚卸しや決算の繁忙期にシステムが止まると、業務に直接響きます。

要件が曖昧なままだと、遅い、漏れる、止まるといった問題が起き、現場の信頼を失います。

ポイント

機能は必須・優先・将来に分け、予算超過時に外す機能を先に決めておきます。非機能要件は、想定する資産件数と同時利用者数を示して具体化すると、ベンダーが適切な構成を見積もれます。

会計連携・データ移行という見落としがちな要件

償却費のCSV連携からAPI連携、双方向同期へ進む流れの図解
連携範囲を段階的に広げる進め方を示しています。

機能要件と非機能要件のなかでも、見積りを左右し、見落とされやすいのが会計システム連携と既存データ移行です。

どちらも見えにくい工程ですが、費用と工期を押し上げます。要件を詰めきれないと、追加費用が生じて予算超過につながります。

会計システム・ERP連携の要件化

既存の会計システムやERPを確認し、償却費と除却損を会計側へ渡す条件を決めます。

  • 連携方式:CSVエクスポートかAPIリアルタイム連携かを決めます。
  • 連携時期:月次バッチにするか、都度連携にするか。
  • 方向と対応表:一方向か双方向か、勘定科目・部門コードの対応を定めます。

既存システムの連携可能なインターフェースを事前に把握しないと、ベンダーは見積りを出せません。

連携は効果を高めますが、技術的な難易度が高く、費用もかさみます。そこで、範囲を欲張らず、効果の大きい部分から段階的に広げます。

まず償却費のCSV連携から始め、運用が安定してからAPI連携や双方向同期へ拡張する計画なら、初期費用を抑えつつ拡張の余地を残せます。

連携要件の精度は、見積りの精度と妥当性判断を左右します。

データ移行・クレンジングの要件化

Excel台帳から新システムへのデータ移行は、要件定義で必ず扱います。重複や表記ゆれ、欠損、現物との乖離を、どこまで直すかを決めておきます。

  • 移行範囲:対象件数とクレンジングの範囲を示します。
  • 責任分担:社内とベンダーの作業分担を決めます。
  • 検証方法:移行後の確認方法と、初期棚卸しの要否。

データ収集・クレンジングには全体予算の2〜3割が一般的に必要です。ベンダー任せにすると、見積りに含まれない追加費用が生じます。

汚れた台帳をそのまま移すと、新システムの信頼性を損ないます。そこで、移行時に初期棚卸しを行い、台帳と現物を合わせるかも検討します。

企業の85%がコストを10%以上見誤り、初年度に30〜40%超過するというデータがあります。データ整備の過小評価も一因です。

発注側は、見積りに30〜40%のバッファを持たせ、データ移行とクレンジングの工数を要件に含めます。

ポイント

会計連携とデータ移行は費用と工期を押し上げるため、見積りを依頼する前に、連携方式と移行範囲、責任分担を決めておきます。社内とベンダーのどちらが何を担うかも、あわせて明確にします。

RFPに盛り込む項目と見積りの妥当性判断

目的と対象、要件、連携と移行、計画と運用を並べたRFP項目の図解
項目ごとの前提が揃うと、提案内容を横並びで見やすくなります。

要件定義書を基にRFP(提案依頼書)を作り、複数のベンダーに提案を依頼します。

RFPが曖昧だと、返ってくる見積りも曖昧になり、横並びで比べられません。管理対象と連携範囲で費用幅が変わるため、条件を揃えることが妥当性判断の前提になります。

RFPに必ず盛り込む項目

RFPには、ベンダーが同じ前提で提案できるよう、最低限の情報を盛り込みます。

  • 目的と対象:KGI、管理対象資産の範囲と件数、AsIsとToBe。
  • 要件:機能要件は必須・優先・将来に分類し、性能・セキュリティ・可用性も定めます。
  • 連携と移行:会計連携、データ移行・クレンジングの範囲と分担。
  • 計画と運用:予算・日程の目安、保守・運用体制の要求。

KGIには、棚卸し工数の削減や保有コストの抑え方などを記します。会計連携とデータ移行を明示しないと、見積りがばらつきます。

見落としがちですが、保守・運用の体制も要件に含めます。税制改正への対応、属性の追加、運用サポートは、導入後も継続して必要になります。

TCO(総保有コスト)の約80%は運用・教育で、初期費用は全体の約20%にすぎないという「80%ルール」があります。このルールを踏まえ、ベンダーには年間保守費、サポート範囲、税制改正対応を明示してもらい、運用時の総額と体制を確認します。

特に、プレゼンの印象だけで選ばないよう、運用を含む総額と体制を確かめる項目をRFPに盛り込んでおくことが、選定の防衛策になります。

見積りの妥当性を判断する軸

見積りは、費目と工数の根拠、初期費用の後の運用負担を確かめて比べます。

  • 内訳:「テスト・デバッグ費」「ディレクション費」が一式なら明細を求めます。
  • 工数と単価:機能や工程ごとに確認し、追加要件の単価も決めます。
  • TCO:保守費、税制改正対応、運用費を含めた数年単位の総額。

データ移行・クレンジングと会計連携の工数が明示されているかは、見積りの誠実さを測る材料になります。

一式で曖昧な項目は、後から追加請求が膨らむおそれがあります。内訳が分かれば、費用の所在を把握できます。

初期費用が安くても、保守費が高かったり、税制改正対応が別料金だったりすると、数年単位で割高になることもあります。

80%ルールに照らし、初期費用に比べて保守・運用費が極端に小さい見積りは、運用の想定を確認します。

詳細な要件定義書とRFPは、精緻な見積りを促し、費用の不透明さを確かめやすくします。

riplaはフルスクラッチ受託と国内開発の立場から、要件の整理、見積り内訳、TCOを明示する進め方を重視しています。

要件定義の精度は、見積りの妥当性をどこまで確かめられるかを左右します。

ポイント

RFPには目的や連携、運用の条件を揃えて書き、見積りは内訳と数年単位の総額で比べます。初期費用の安さだけで判断せず、保守費や税制改正対応の扱いを確かめることが大切です。

運用設計とToBe・スケジュールの要件化

機能を決めるだけでなく、導入後の運用を設計して要件に織り込めるかが、成否を分けます。

運用ルールがないと、台帳と現物が再びずれて形骸化します。ToBe、運用設計、現実的な日程を要件に含めると、未利用を防ぎます。

ToBeと運用ルールの要件化

AsIsを可視化したら、導入後のあるべき業務であるToBeを描き、資産のライフサイクルを設計します。

  • 取得:誰がいつ資産を登録するかを決めます。
  • 移動と棚卸し:部署間移動の更新方法、棚卸しの頻度と手順。
  • 除却・廃棄:処理方法と担当者を定めます。

機能が整っていても、業務がつながらず更新が滞れば、台帳と現物がずれて形骸化します。

運用の責任は、取得、移動、除却ごとに明記します。購買や総務、情報システム、現場のどこが、いつどう登録するかを業務フローに落とし込みます。

「機器を買ったら必ず登録する」業務が定着するかどうかが、台帳の鮮度を左右します。ルールと責任分担を固めることが、継続利用の前提です。

段階リリースとスケジュールの要件化

スケジュールとリリース計画を明確にし、効果の大きい領域から段階的に稼働させます。

  • 初期リリース:固定資産台帳やIT資産管理を稼働させます。
  • 追加機能:効果を確かめてから、バーコード棚卸し、会計連携、ダッシュボードを足します。

一度に作ると、開発が長期化し、データ整備も集中して破綻しやすくなります。そのため、段階リリースでリスクを分散します。

日程を組む際は、検証に区切りを設ける規律も必要です。AI連携や全社統合を含むと、検証だけが続く「PoC死」の恐れがあります。

計画では、検証を3ヶ月で結論を出すと区切り、本番運用しながら効果を確かめます。

データ移行と初期棚卸しの工数も、日程に見込みます。運用やToBe、段階リリース、日程まで要件に含めると、成功に向けた設計図になります。

ポイント

取得・移動・除却の運用ルールと責任分担を決めて初めて、台帳は使われ続けます。初期リリースは固定資産台帳やIT資産管理に絞り、データ移行や初期棚卸しの工数も日程に含めます。

まとめ

資産管理システムの要件定義は、管理対象の棚卸しと、現状のExcel管理の可視化から始めます。

機能は必須・優先・将来に分け、性能・セキュリティ・可用性も定めます。会計連携とデータ移行・クレンジングも、要件に含めます。

データ整備は全体予算の2〜3割、TCOでは運用が約80%を占めます。RFPに目的、移行範囲、保守体制を記しておくと、提案を比べやすくなります。

企業の85%がコストを10%以上見誤り、初年度に30〜40%超過するというデータがあります。見積りに30〜40%のバッファを持たせ、データ整備を軽視しないことが防衛策です。

riplaは、フルスクラッチ受託と国内開発を組み合わせ、管理対象の整理やAsIsの可視化、会計連携・データ移行、RFP作成を発注企業とともに支援しています。全体像は完全ガイドをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。