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

資産管理システムの導入で、機能や費用の比較以上にプロジェクトの成否を左右するのが、RFP（提案依頼書）と要件定義書の質です。「固定資産を管理したい」「棚卸しを楽にしたい」という漠然とした要望のままベンダーに相談すると、各社からバラバラの前提・バラバラの金額で提案が返ってきて、横並びの比較ができません。逆に、自社が何をどの粒度で管理し、既存の会計システムとどう連携し、誰がどの情報を見るのかを要件として整理できていれば、ベンダーは精緻な見積りを出さざるを得ず、こちらも妥当性を判断できます。要件定義は、発注企業がプロジェクトの主導権を握るための最重要工程なのです。

本記事は、資産管理システムのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。管理対象資産の棚卸しと現状（AsIs）の可視化、機能要件と非機能要件の整理、会計連携・権限管理・データ移行といった見落としがちな要件、そしてRFPに盛り込む項目と見積りの妥当性判断まで、実務に即して掘り下げます。なお、資産管理システム全体の費用相場や進め方をまだ把握していない方は、まず資産管理システムの完全ガイドから読むことをおすすめします。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。

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

管理対象の棚卸しとAsIsの可視化から始める

資産管理システムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、自社が何を「資産」として管理すべきかの棚卸しと、今その資産をどう管理しているか（AsIs）の可視化です。固定資産だけなのか、IT機器やソフトウェアライセンスも含むのか、リース資産や少額の備品まで対象にするのか。この管理対象の線引きが曖昧なまま進めると、後から「あの資産も入れたい」という追加が頻発し、要件が膨張して費用も工期も崩れます。

最初に決めるべきは、管理対象とする資産の範囲と、管理する粒度です。会計上の固定資産（取得価額10万円以上など）に限るのか、一括償却資産や少額減価償却資産、消耗品扱いの備品まで含めるのか。IT資産であれば、PC・サーバといったハードだけでなく、ソフトウェアライセンスやクラウドサブスクリプションまで管理するのか。これらを明確にしないと、ベンダーは管理すべきデータ件数も項目数も見積もれません。管理対象が広いほど初期データ整備の負荷とシステムの複雑さが増すため、まずは効果の大きい領域に絞る判断も重要です。

あわせて、資産ごとにどんな属性を管理したいかを洗い出します。取得日・取得価額・耐用年数・設置場所・管理部門・利用者といった共通項目に加え、IT機器ならOSやIPアドレス、車両なら車検満了日、リース資産なら契約満了日といった、資産種別ごとの固有項目を定義します。この属性設計が、後の検索・集計・アラートの実用性を決めます。フルスクラッチで開発する場合は、この属性を自社の管理ニーズに合わせて自由に設計できる点が強みになるため、要件定義の段階で「将来管理したくなる項目」まで見据えて整理しておくことが大切です。

管理対象を定めたら、次に行うのが現状（AsIs）の管理実態の可視化です。多くの企業では、固定資産台帳・備品台帳・IT機器管理簿が部署ごとに別々のExcelで管理され、同じ資産が二重に載っていたり、廃棄済みの資産が残り続けていたりします。誰が・どのファイルで・どの頻度で更新しているか、棚卸しはどう実施しているか、減価償却はどのシートで計算しているかを、関係部署（経理・情報システム・総務・現場）にヒアリングして洗い出します。この地道な作業が、要件の漏れを防ぐ土台になります。

AsIsの可視化で特に重要なのが、「現状のデータがどれだけ汚れているか」を把握することです。台帳の重複、表記ゆれ、欠損項目、現物との乖離は、システム導入時のデータ移行で必ず問題になります。後述するように、社内データの収集・クレンジングには全体予算の2〜3割を要するのが一般的で、ここを軽視すると初年度に30〜40%の予算超過を招きます。AsIsの段階で現状データの品質を直視し、「どこまで自社で整備し、どこからベンダーに任せるか」の線引きを要件に織り込んでおくことが、現実的なプロジェクト計画につながります。

機能要件と非機能要件を整理する

管理対象とAsIsが整理できたら、要件定義書の核となる機能要件と非機能要件を整理します。機能要件は「何ができるか」、非機能要件は「どれだけの品質で動くか」を定めるものです。資産管理システムでは台帳や償却といった機能要件に目が行きがちですが、機微な資産情報を扱い、全社の多くのユーザーが使うがゆえに、非機能要件もおろそかにできません。

機能要件は、ただ列挙するのではなく、優先度を付けて分類することが重要です。「これがないと業務が回らない」必須機能（資産台帳・登録/移動・除却の履歴管理/減価償却の自動計算）、「効果は大きいが初期になくても運用できる」優先機能（バーコード棚卸し/会計連携/ライセンス管理）、「将来追加でよい」機能（RFID対応/ダッシュボード/モバイル対応）の三段階に分けます。資産管理システムは機能を盛り込むほど費用が膨らむため、この優先度付けが予算管理の生命線になります。

優先度を付けておくと、見積りが予算を超えた場合に、どの機能を初期リリースから外すかを冷静に判断できます。すべてを必須にしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。逆に優先度が明確なら、まず必須機能でリリースし、効果を見ながら優先機能を追加する段階的なリリース計画が立てられます。機能要件の分類は、要件定義書の中でも特に投資判断に直結する部分です。各機能が具体的に何を解決するかは、機能を扱った関連記事もあわせてご覧ください。

非機能要件では、性能・セキュリティ・可用性を定義します。性能は、資産が数千〜数万点に及ぶ企業で重要です。大量の資産を高速に検索・集計でき、棚卸し時に多数の現場担当者が同時にアクセスしても遅くならない、という性能要件を明記します。想定する資産件数・同時利用者数を要件に書くことで、ベンダーは適切なインフラ構成を見積もれます。画面が固まるようでは現場は使ってくれず、せっかくのシステムが形骸化します。

セキュリティは、資産の簿価や利用者の所属といった機微な情報を扱う資産管理システムで極めて重要です。役職・部門に応じた閲覧・編集権限の制御、操作ログの記録、IdP（IDプロバイダー）連携によるシングルサインオンなどを要件化します。内部統制やJ-SOX対応の観点で、誰がいつどの資産情報を変更したかの監査ログは欠かせません。可用性については、棚卸しや決算といった繁忙期に止まると業務に直撃するため、稼働率の目標やバックアップ体制を定めます。非機能要件を曖昧にすると、リリース後に「遅い」「漏れる」「止まる」というトラブルが起き、現場の信頼を一気に失います。

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

機能要件・非機能要件の中でも、見積りを大きく左右しながら見落とされやすいのが、会計システムとの連携要件と、既存データの移行要件です。この二つは「見えにくい工程」でありながら費用と工期を押し上げる主因であり、要件定義で詰めきれていないと、後から大幅な追加費用が発生します。ここを精緻に要件化できるかが、予算超過を防ぐ分かれ目になります。

会計連携の要件化では、既存の会計システムやERPが何か、資産管理システムで計算した償却費・除却損を、どの粒度で・どの方式（CSVエクスポートかAPIリアルタイム連携か）で・どのタイミング（月次バッチか都度か）で会計側へ渡すかを定義します。連携の方向（資産管理から会計へ一方向か、双方向か）や、勘定科目・部門コードのマッピングルールも要件に明記します。既存システムの連携可能なインターフェースを事前に把握しておかないと、ベンダーは見積りを出せません。

連携は資産管理システムの効果を最大化する一方、技術的難易度が高く費用もかさみます。だからこそ、連携範囲を欲張らず、効果の大きいところから段階的に広げる設計が堅実です。まずは償却費のCSV連携から始め、運用が安定してからAPI連携や双方向同期に拡張する、といった段階計画を要件に織り込むと、初期費用を抑えつつ将来の拡張余地も確保できます。連携要件の精度が、見積りの精度と妥当性判断を大きく左右することを意識してください。

既存のExcel台帳から新システムへのデータ移行は、要件定義で必ず扱うべき項目です。現状の台帳がどれだけ汚れているか（重複・表記ゆれ・欠損・現物との乖離）を把握し、それをどこまでクレンジングして移行するかを要件に書きます。社内データの収集・クレンジングには全体予算の2〜3割を要するのが一般的で、ここを「ベンダーがやってくれるだろう」と曖昧にしておくと、見積りに含まれず後から大きな追加費用になります。移行対象の件数、クレンジングの責任分担、移行後の検証方法までを明記することが重要です。

あわせて、データ移行を機に現物棚卸しを行い、台帳と現物を一致させる「初期棚卸し」を計画に組み込むかも検討します。汚れた台帳をそのまま移行しても、現物と合っていなければシステムの信頼性は最初から損なわれます。企業の85%がコストを10%以上見誤り、初年度に30〜40%の予算超過に陥るというデータがありますが、その主因の一つがこのデータ整備の過小評価です。見積りには30〜40%のバッファを持たせ、データ移行・クレンジングの工数を正面から要件化することが、現実的なプロジェクト運営の鍵になります。

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

要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。資産管理システムは管理対象と連携範囲で費用幅が大きいため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。

RFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI（棚卸し工数の削減や保有コストの最適化など）、管理対象資産の範囲と件数、現状（AsIs）と目指す姿（ToBe）、機能要件（必須・優先・将来の分類付き）、非機能要件（性能・セキュリティ・可用性）、会計システムとの連携要件、データ移行・クレンジングの範囲と責任分担、予算とスケジュールの目安、保守・運用の体制要求です。とくに会計連携とデータ移行は、RFPで明示しないとベンダーが前提を勝手に置いてしまい、見積りがバラつく原因になります。

見落とされがちなのが、保守・運用の体制要求です。資産管理システムは導入して終わりではなく、税制改正への追従、属性追加、運用サポートといった保守が継続的に必要です。TCO（総保有コスト）の約80%は運用・教育が占め、初期費用は全体の約20%にすぎないという「80%ルール」を踏まえ、RFPでは初期費用だけでなく、年間の保守費・サポート範囲・税制改正対応の扱いまで明示を求めます。プレゼンの上手さではなく、運用フェーズまで含めた総額と体制を確認できる項目をRFPに盛り込むことが、後悔しないベンダー選定の防衛策になります。

集まった見積りの妥当性を判断するには、内訳の精査が欠かせません。「テスト・デバッグ費」「ディレクション費」が一式でまとめられている場合は、内訳の開示を求めます。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件が発生したときの単価ルールも事前に取り決められます。とくにデータ移行・クレンジングの工数と、会計連携の開発工数が明示されているかは、見積りの誠実さを測る試金石です。これらが一式でぼかされている見積りは、後から追加請求が膨らむリスクがあります。

初期費用だけで判断せず、TCOで比較することも重要です。初期費用が安くても、保守費が高い、税制改正対応が別料金、というケースでは、数年単位で見ると割高になることがあります。前述の80%ルールに照らし、初期費用に対して保守・運用費が極端に小さい見積りは、運用フェーズの想定が甘い可能性を疑います。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と、見積り内訳・TCOを明示する進め方を重視しています。要件定義の精度が、見積りの妥当性判断の精度を決めるのです。

運用設計とToBe・スケジュールを要件に組み込む

要件定義というと機能の定義に意識が向きがちですが、資産管理システムで成否を分けるのは、導入後の運用をどう設計し、それを要件に織り込めるかです。台帳と現物が再び乖離して形骸化する失敗の多くは、運用ルールを要件段階で考えなかったことに起因します。あるべき業務の姿（ToBe）と、それを支える運用設計、そして現実的なスケジュールを要件に組み込むことで、「作ったのに使われない」を未然に防げます。

AsIsを可視化したら、次に描くのが「システム導入後のあるべき業務の姿」であるToBeです。資産を取得したら誰がいつ登録するか、部署間で移動したらどう更新するか、棚卸しはどの頻度でどう実施するか、除却・廃棄はどう処理するかという、資産のライフサイクル全体の新しい運用フローを設計します。このToBeを描かずに機能だけ決めると、機能はあっても業務がつながらず、更新が滞って台帳と現物が乖離する、という典型的な形骸化に陥ります。

とくに重要なのが、運用の責任分担を要件に明記することです。資産の取得・移動・除却の各イベントで、購買・総務・情報システム・現場の誰が、どのタイミングで、どう登録するかを業務フローに落とし込み、システムの操作をその業務に組み込みます。「機器を買ったら必ず登録する」を業務の一部にできるかが、定着を左右します。運用ルールと責任分担を要件段階で固めておくことが、稼働後に台帳の鮮度を保ち、システムを「使われ続けるもの」にする前提条件になります。

要件定義では、スケジュールとリリース計画も明確にします。とくに有効なのが、効果の大きい領域から段階的にリリースする計画を要件に織り込むことです。まず固定資産台帳やIT資産管理を初期リリースで稼働させ、効果を確認してから、バーコード棚卸し・会計連携・ダッシュボードといった優先機能を順次追加します。一度にすべてを作ろうとすると、開発が長期化し、データ整備も一気に発生して破綻しやすくなります。段階リリースを前提に要件を整理することで、リスクを分散できます。

スケジュールを引くときは、検証を区切る規律も意識します。AI連携や全社統合といった野心的な構想を含む場合、検証だけが延々と続いて本番に至らない「PoC死」のリスクがあります。検証は3ヶ月で結論を出すと区切り、本番運用しながら効果を確かめる進め方を要件・計画に反映すると、構想倒れを防げます。あわせて、データ移行・初期棚卸しの工数をスケジュールに正しく見込むことが、稼働直前の遅延を避ける鍵です。運用設計・ToBe・段階リリース・スケジュールまでを要件に組み込むことで、要件定義は「機能の仕様書」から「プロジェクト成功の設計図」へと格上げされます。

まとめ

資産管理システムのRFP・要件定義書・提案依頼書は、機能の列挙からではなく、管理対象資産の棚卸しと、現状（AsIs）のExcel管理の可視化から始めるのが鉄則です。そのうえで、機能要件を必須・優先・将来で分類し、性能・セキュリティ・可用性といった非機能要件も詰め、見落とされやすい会計連携とデータ移行・クレンジング（全体予算の2〜3割）を正面から要件化します。これらをRFPに目的・連携要件・データ移行範囲・保守体制まで明記すれば、ベンダーの提案を横並びで比較でき、TCO（運用が約80%）に照らして見積りの妥当性も判断できます。

企業の85%がコストを10%以上見誤り、初年度に30〜40%の予算超過に陥るというデータが示す通り、要件定義の質はそのままプロジェクトの予算と成否に直結します。見積りには30〜40%のバッファを持たせ、データ整備を軽視しないことが現実的な防衛策です。riplaはフルスクラッチ受託と国内開発を組み合わせ、管理対象の整理からAsIs可視化、会計連携・データ移行の要件化、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。