経費精算システムのRFP/要件定義書/提案依頼書について

経費精算システムをスクラッチや本格的なカスタマイズで導入しようとするとき、避けて通れないのが要件定義とRFP（提案依頼書）の作成です。「何を作りたいか」を発注側が明確に言語化できていないと、ベンダーは正確な見積もりも提案もできず、結果として「思っていたものと違う」「想定外の追加費用が発生した」というトラブルに直結します。経費精算は、自社固有の費目区分・出張旅費規程・承認ルート・既存システム連携といった要件が複雑に絡むため、要件定義とRFPの質が成否を大きく左右する領域です。

本記事は、経費精算システムのRFP・要件定義書・提案依頼書を、発注側がどう作り込むべきかを体系的に整理する「要件定義特化」の解説です。自社規程と業務フローの要件化、システム連携とデータ移行の要件化、TCO評価軸とRFPの選定基準、要件定義を成功させる進め方、という4つの観点を、一次データとあわせて具体的に解説します。経費精算システム導入の全体像をまだ把握していない方は、まず経費精算システムの完全ガイドから読むことをおすすめします。読み終えるころには、ベンダーに渡すRFPに盛り込むべき要素が整理できるはずです。

▼全体ガイドの記事
・経費精算システムの完全ガイド

自社規程と業務フローを要件化する

経費精算システムの要件定義で最初に取り組むべきが、自社の経費精算規程と業務フローを言語化することです。多くの企業では、経費精算のルールが規程と慣行の両方に分散し、文書化されていない暗黙のルールが現場に存在します。これを棚卸しせずにシステム化を進めると、現場の実態とシステムが噛み合わず、定着しません。要件化とは、この暗黙知を明文化する作業でもあります。

要件定義では、まず自社で扱う費目とその区分を網羅的に洗い出します。交通費・出張旅費・宿泊費・接待交際費・備品購入・立替金など、どの費目をシステムで扱うか、各費目にどんな入力項目や添付ルールが必要かを定義します。とくに出張旅費は、役職別の日当や宿泊費の上限など、規程で細かく定められていることが多く、これをシステムのルールにどう落とし込むかが要件の核心になります。役職別・地域別の上限額をマスタで管理するのか、固定で持つのかといった粒度まで決めておくと、後の手戻りが減ります。

注意したいのは、独自の丸め処理や特殊なルールです。勤怠領域で変形労働・フレックス・独自の丸め処理の再現性が成否を分けるのと同様に、経費精算でも「1円未満の端数処理」「定期区間の控除ルール」「概算払いと精算の差額処理」といった独自ルールの再現が、現場の納得感を左右します。これらを要件定義書に明記しておかないと、ベンダーは標準機能の範囲でしか作らず、リリース後に「自社のルールが再現できない」という問題が噴出します。暗黙のルールこそ、要件として書き出すことが重要です。

承認ワークフローは、経費精算システムで最も企業ごとに差が出る部分であり、要件定義で丁寧に詰めるべき領域です。誰が申請し、誰が一次承認・二次承認をし、どの金額帯でルートが分岐し、経理の最終チェックがどこに入るのか。組織図と権限規程を参照しながら、承認フローを図に起こすことが第一歩です。代理承認や差し戻し、承認後の修正可否といった例外フローも、要件として漏らさず定義します。

このとき、現状（AsIs）の承認フローをそのまま再現するのか、この機会に業務を見直してあるべき姿（ToBe）に改めるのかを意思決定することが大切です。複雑すぎる承認ルートは滞留の原因になるため、システム化を機にフローを簡素化する判断も選択肢になります。要件定義書には、AsIsとToBeの両方を記載し、「なぜこの承認設計にするのか」の意図まで残すと、ベンダーとの認識齟齬が減ります。承認ルートの要件化は、システムの使い勝手と内部統制を両立させる設計の起点です。

システム連携とデータ移行を要件化する

経費精算システムは単独で完結せず、会計システム・給与システム・人事システムと連携してこそ効果を発揮します。そのため、要件定義では連携要件を具体的に書き出すことが欠かせません。あわせて、旧システムやExcelからのデータ移行も、見積もりに大きく影響する要件です。これらを曖昧にしたままRFPを出すと、ベンダー間で見積もりの前提がそろわず、適正な比較ができなくなります。

連携要件では、まず連携先のシステム名とバージョン、連携したいデータの種類（仕訳データ・振込データ・従業員マスタ等）、連携の方向（片方向か双方向か）、連携の方式（API・CSV・手動取込）を明記します。経費精算で確定した仕訳を会計システムへ、立替金を給与システムへ連携する、というように、データの流れを図にして要件化すると、ベンダーは実装難易度を正確に見積もれます。一次データの隠れコストでも、給与・会計ソフトの連携費は10万〜50万円と見込まれており、連携要件の精度が見積もりの精度に直結します。

連携の品質要件も忘れてはいけません。研究データでは、システム間の連携不具合により「給与支給が3日遅れた」「残業代計算で月10万円の差異が出た」という事例が報告されています。経費精算でも、連携のタイミングやエラー時の挙動を要件として定義しておかないと、本番運用で支払遅延や金額ズレを招きます。連携が失敗したときにどう検知し、どうリカバリーするかまで要件に含めることが、堅牢なシステムへの近道です。

経費精算システムの導入で失敗の上位を占めるのが、データ移行の難航です。一次データでは、データ移行・初期設定の難航により「スケジュール遅延1か月」「安定稼働まで2か月」という声が報告されています。にもかかわらず、移行要件は「ベンダーに確認しましょう」で済まされがちな空白地帯です。だからこそ、要件定義の段階で、何を・どこから・どの形式で移行するのかを明確にしておくことが、トラブル回避の鍵になります。

具体的には、過去の経費データ・従業員マスタ・規程マスタのうち、どこまでを移行対象とするか、過去何年分を移行するか、移行データのクレンジングは誰が行うか、を要件に書き出します。さらに、旧運用と新システムをどの期間並行稼働させるか、並行運用中の二重入力をどう扱うかも、要件として定義しておくと安心です。データ移行費の隠れコストは5万〜30万円と見込まれており、移行範囲を要件で絞り込むことが、予算オーバーの防止にもつながります。移行・並行運用の要件化は、地味ですが投資の成否を分ける重要工程です。

TCO評価軸とRFPの選定基準を設計する

RFP（提案依頼書）は、要件を整理してベンダーに提案を求める文書であると同時に、複数の提案を公平に比較するための物差しでもあります。ここで評価軸を月額や初期費用だけに置くと、長期的に損をする選択をしかねません。経費精算の選定では、TCO（総保有コスト）を軸にした評価設計が重要になります。

RFPの評価軸を設計するときは、初期費用・月額（ユーザー数連動）・カスタマイズ費・連携費・データ移行費・運用工数を合算した5年TCOで比較するのが鉄則です。クラウドSaaSは1ユーザー月額300〜500円がボリュームゾーンで、企業規模別では50〜99名で月14,500〜28,710円、100〜199名で29,000〜57,710円が目安です。これが5年積み上がると相応の金額になります。一方、ノーコード受託は初期100万〜300万円・月額1万〜3万円のユーザー無制限固定費で、50名以上では5年TCO約160万〜500万円とSaaSより有利になりうる、と試算されています。

RFPには、この5年TCOを各ベンダーに明示的に提示させる項目を設けましょう。さらに、(1)ハードウェア5万〜50万円、(2)データ移行5万〜30万円、(3)カスタマイズ20万〜100万円超、(4)連携10万〜50万円、(5)運用工数の年20万〜100万円換算という5つの隠れコストを、提案に必ず含めるよう求めます。これらを明示させることで、表面的な月額の安さに惑わされず、総額で公平に比較できます。月額だけで選ぶと人数増で逆転するリスクがあるという視点を、評価設計に組み込むことが要件定義の質を高めます。

実務的なRFPには、プロジェクトの背景と目的、対象業務範囲、機能要件、非機能要件（性能・セキュリティ・可用性）、連携・データ移行要件、スケジュール、予算感、評価基準、提案書に記載してほしい項目を盛り込みます。経費精算特有の項目として、電帳法・インボイス対応、承認ワークフローの柔軟性、退職者を含むデータの保存方針を明記すると、提案の精度が上がります。

サポート要件も、RFPで明確にすべき重要項目です。初期設定代行の有無、伴走支援の範囲、法改正への対応方針、トラブル時の問い合わせ窓口とレスポンス時間などを求めます。一次データでも、初期費用は「無料」を掲げつつ実際は初期設定代行・データ移行で5万〜20万円かかる企業が多いとされており、サポートの範囲と費用を曖昧にすると後で揉めます。RFPでサポート要件まで言語化しておくことが、導入後の安心につながります。補助金を活用する場合は、IT導入補助金（通常枠で1/2、最大150万円未満等）の要件とスケジュールも考慮に入れておくとよいでしょう。

要件定義を成功させる進め方

要件定義書やRFPは、一人の担当者が机上で書けるものではありません。経費精算は申請者・承認者・経理という複数の立場が関わるため、関係者を巻き込んで現場の実態を吸い上げる進め方が、要件の質を決めます。ここを丁寧に進めるかどうかが、システムが現場に定着するかどうかの分岐点になります。

要件定義の出発点は、申請者・承認者・経理それぞれへのヒアリングです。「実際にどう申請しているか」「どこで差し戻しが起きるか」「月次締めのどこに時間がかかるか」を細かく聞き取り、現状（AsIs）の業務フローを可視化します。経理の視点だけで要件を作ると、申請者の入力負担が見落とされ、定着しないシステムになりがちです。三者の立場をすべて拾うことが、使われるシステムの前提条件になります。

ヒアリングで集めた不満や手戻りは、そのまま要件の優先順位づけの材料になります。「ここが一番つらい」という現場の声が集中する箇所こそ、システム化の効果が大きいポイントです。AsIsを可視化したうえで、あるべき姿（ToBe）を描き、その差分を埋めるのが要件定義の本質です。riplaはフルスクラッチ・国内開発の立場から、この「現場の業務から逆算してToBeを描く」要件整理を一貫して重視しています。

要件定義でやってはいけないのが、現場の要望をすべて「必須」として盛り込んでしまうことです。要件が膨張すると、開発費が跳ね上がり、カスタマイズ費の予算オーバー（一次データでは20万円超の声も）につながります。だからこそ、各要件を「必須（Must）」「あれば良い（Want）」「不要（Won’t）」に分類し、優先順位を明確にすることが重要です。この切り分けが、予算内で最大の効果を出す設計の鍵になります。

優先順位づけのときは、その要件が「効率化や法令対応にどれだけ寄与するか」を基準にします。電帳法・インボイス対応のような法令要件は必須、特定の少数部署だけが望む細かなカスタマイズは後回し、というように判断します。標準機能で満たせる要件と、自社開発でなければ実現できない要件を切り分けることで、SaaSで足りるのか自社開発が必要なのかの判断もクリアになります。要件の優先順位づけは、RFPの説得力と、導入後の満足度を同時に高める、要件定義の総仕上げです。

優先順位づけのもう一つの効用は、フェーズ分けの判断材料になることです。すべての要件を一度に実装しようとすると、開発期間も費用も膨らみますが、必須要件を第一フェーズ、あれば良い要件を第二フェーズ以降と分ければ、効果の大きい部分から早く稼働させられます。段階的に機能を足していくこの進め方は、初期投資を抑えつつ、現場の反応を見ながら改善できる点でも合理的です。要件の優先順位は、予算配分とリリース計画の両方を支える、実務的な意思決定の軸になります。

非機能要件と法令・保存要件を定義する

要件定義というと機能要件に目が向きがちですが、経費精算システムでは非機能要件と法令・保存要件の定義も同じく重要です。これらを曖昧にしたまま開発を進めると、性能不足やコンプライアンス上の不備となって運用後に顕在化します。地味ですが、システムの品質を支える土台となる要件群です。

非機能要件では、性能・セキュリティ・可用性を定義します。性能面では、月末に申請が集中しても画面が快適に動くか、想定する同時利用者数や申請件数に耐えられるかを要件化します。月次締めの時期に処理が重くなって使えない、という事態は避けなければなりません。利用人数と申請ピークの見込みを示し、その負荷に耐える性能をベンダーに保証させることが重要です。

セキュリティ面では、経費データに個人の機微な情報が含まれることを踏まえ、アクセス権限の制御、通信の暗号化、操作ログの保持といった要件を定義します。可用性面では、システムが止まると申請・承認・支払が滞るため、稼働率の目標やバックアップ・障害時の復旧方針を要件に含めます。これらの非機能要件は、見積もりにも品質にも影響するため、機能要件と同じ熱量で定義することが、堅牢なシステムの前提になります。

経費精算特有の要件として外せないのが、電子帳簿保存法とインボイス制度への対応、そして退職者データの保存です。電帳法対応では、タイムスタンプの付与、訂正・削除履歴の保持、日付・金額・取引先での検索といった要件を明記します。インボイス対応では、適格請求書の判定、登録番号の管理、税率区分の処理を要件化します。これらは法令で求められるため、対応の有無ではなく対応の質を要件として定義することが大切です。

退職者データの保存要件も、要件定義で明確にすべき項目です。法定の保存義務がある一方、ユーザー課金型のSaaSでは退職者アカウントの保持で課金が続き、無料系では保存期間が数ヶ月〜1年と短いというジレンマがあります。だからこそ、「退職者のデータを何年保存するか」「保存方法と課金がどうなるか」を要件として書き出し、ベンダーに対応方針を示させる必要があります。データを自社で保有する自社開発を選べば、保存期間も課金構造も自社で設計でき、このジレンマを構造的に回避できます。法令・保存要件の精度が、運用後のコンプライアンスとコストの両方を左右します。

まとめ

経費精算システムのRFP・要件定義書を作り込むときの要点は、(1)費目区分・出張旅費規程・承認ルートといった自社規程と業務フローの明文化、(2)会計・給与システム連携とデータ移行・並行運用の要件化、(3)月額だけでなく5年TCOと5つの隠れコストを含めた評価軸の設計、(4)関係者ヒアリングでAsIsを可視化し必須要件とあれば良い要件を切り分ける進め方、という4点に集約されます。とくにデータ移行は失敗の上位を占めるため、要件化の段階で範囲と並行運用を決めておくことが、スケジュール遅延と予算オーバーを防ぎます。

要件定義で大切なのは、「ベンダーに丸投げしない」という姿勢です。発注側が自社の業務と要件を言語化できて初めて、ベンダーは正確な見積もりと提案を返せます。自社の費目・承認ルート・既存システム・法令対応の必要度を棚卸しし、必須要件を優先順位づけしたうえでRFPに落とし込んでください。riplaはフルスクラッチ・ノーコード受託の立場から、現場の業務から逆算した要件整理と、TCOを踏まえた最適な手段選びを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。