経費精算システムの要件定義は、自社の規程と業務フローの洗い出し、連携と移行の条件の明文化、関係者間の優先順位づけの順に進めると、見積もりのずれを抑えやすくなります。
全体像は、経費精算システムの完全ガイドにまとめています。
▼全体ガイドの記事
・経費精算システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自社規程と業務フローの要件化
要件定義では、自社の経費精算規程と業務フローを言葉にして整理します。規程と慣行に分散した暗黙のルールを洗い出さないまま進めると、現場の実態とシステムが合わず、定着しません。また、要件化は、現場にある暗黙知を明文化する作業でもあります。
費目区分と出張旅費規程の明文化
まず、自社で扱う費目と区分を洗い出し、各費目に必要な入力項目や添付ルールを整理します。
- 対象費目：交通費、出張旅費、宿泊費、接待交際費、備品購入、立替金
- 旅費規程：役職別の日当や宿泊費の上限
- 独自ルール：1円未満の端数処理、定期区間の控除、概算払いと精算の差額処理
出張旅費の上限額を、マスタで管理するか固定値にするかまで決めておくと、後の手戻りを減らせます。役職別・地域別の上限額や端数処理を正しく再現できるかが、現場の納得感を左右します。
さらに、勤怠領域でも、変形労働・フレックス・独自の丸め処理が成否を分けます。要件定義書に明記しないと、ベンダーは標準機能の範囲で作ってしまい、リリース後に自社ルールを再現できない問題が起きます。そのため、暗黙のルールも要件として書き出します。
承認ルートと権限の要件定義
承認ワークフローは、経費精算システムの中で企業ごとの差が最も出る領域です。そのため、組織図と権限規程を参照しながら、丁寧に要件化します。
- 基本フロー：申請者、一次・二次の承認者、金額帯による分岐、経理の最終確認
- 例外フロー：代理承認、差し戻し、承認後の修正の可否
- 承認設計：現状（AsIs）の再現か、あるべき姿（ToBe）への見直しか
複雑な承認ルートは滞留の原因となるため、システム化を機に簡素化する方法もあります。また、要件定義書にAsIsとToBeの両方と設計意図を記載すると、ベンダーとの認識の食い違いを減らせます。承認ルートの要件化は、使いやすさと内部統制を両立させる設計の出発点になります。
システム連携とデータ移行の要件化
経費精算システムは、会計・給与・人事システムと連携して効果を発揮します。そのため、連携要件を具体的に書き出すことが欠かせません。
旧システムやExcelからのデータ移行も見積もりに影響するため、移行条件を具体化します。また、要件が曖昧なままRFPを出すと、ベンダーごとに見積もりの前提が異なり、公平に比較できません。
会計・給与システムとの連携要件
連携要件は、対象のシステムとデータ、連携の方向と方式、データの流れ、品質条件に分けて整理します。
- 連携先とデータ：システム名とバージョン、仕訳データ・振込データ・従業員マスタなどの連携対象
- 連携方向・方式：片方向か双方向か、API・CSV・手動取込のいずれか
- データの流れ：仕訳を会計システムへ、立替金を給与システムへ連携
- 品質条件：連携のタイミング、エラーの検知、リカバリー手順
一次データでは、給与・会計ソフトの連携費は10万〜50万円と見込まれています。特に、連携要件の精度は見積もりの精度に直結します。
たとえば、研究データでは、連携不具合で給与支給が3日遅れた事例や、残業代計算に月10万円の差異が出た事例があります。経費精算でも、連携への対応が不十分だと、支払遅延や金額のずれを招きます。
データ移行と並行運用の要件
導入失敗の上位には、データ移行の難航があります。そこで、要件定義の段階で移行範囲や並行運用を具体化します。
- 移行対象：経費データ、従業員マスタ、規程マスタの範囲と過去何年分か
- データ整備：移行元と形式、データをクレンジングする担当者
- 並行運用：旧運用と新システムを並行する期間、二重入力の扱い
移行要件は「ベンダーに確認する」で済まされがちです。一方で、事前に決めておくと、トラブルを避けやすくなります。
一次データでは、移行・初期設定の難航によるスケジュール遅延が1か月、安定稼働まで2か月という声が報告されています。また、移行費は5万〜30万円と見込まれており、移行範囲を明確にしておくと、予算超過の防止にもつながります。移行と並行運用の要件化は、投資の成否を分ける重要な工程です。
TCO評価軸とRFPの選定基準
RFP（提案依頼書）は、要件を示して提案を求め、複数案を公平に比べるための物差しです。
月額や初期費用だけで評価すると、長期的に不利な選択をしかねません。そのため、TCO（総保有コスト）を基準に評価を組み立てます。
月額だけに頼らない5年TCO評価
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を提示させ、次の費用も提案に含めるよう求めます。
- ハードウェア：5万〜50万円
- データ移行：5万〜30万円
- カスタマイズ：20万〜100万円超
- システム連携：10万〜50万円
- 運用工数：年20万〜100万円換算
これらの費用を明示させると、月額だけでなく総額で比べられます。さらに、人数増で月額の安さが逆転するリスクもあり、その点を評価に含めることが要件定義の質を高めます。
RFPに盛り込むべき項目とサポート要件
RFPに載せる内容は、提案の前提、システム要件、サポート条件、補助金利用時の4つに分けると、ベンダーの回答を同じ軸で比べやすくなります。
- 提案の前提：プロジェクトの背景・目的、対象業務範囲、スケジュール、予算感、評価基準、提案書に求める項目
- システム要件：機能要件、性能・セキュリティ・可用性の非機能要件、連携・移行、電帳法・インボイス、承認の柔軟性、退職者データ保存
- サポート条件：初期設定代行、伴走支援、法改正対応、問い合わせ窓口と回答時間
- 補助金利用時：IT導入補助金の要件とスケジュール
一次データでは、初期費用無料を掲げても、設定代行や移行に5万〜20万円かかる企業が多いとされています。サポートの範囲と費用を曖昧にすると、後で問題になります。
そのため、支援の内容を要件として記載しておくと、導入後に確認できます。また、IT導入補助金の通常枠では、1/2や最大150万円未満などの要件があります。
要件定義の進め方
要件定義書やRFPは、担当者一人の机上では作れません。そのため、関係者を巻き込みながら丁寧に進めることが、システムの現場定着を左右します。
関係者ヒアリングによるAsIsの把握
申請者・承認者・経理へのヒアリングで、現状（AsIs）の業務フローを明らかにします。
- 申請者：実際の申請方法と入力負担
- 承認者：差し戻しが起きる箇所
- 経理：月次締めで時間がかかる作業
- 現場全体：不満や手戻りが集中する箇所
経理だけで要件を作ると、申請者の入力負担を見落としやすく、定着しないシステムになりがちです。そのため、申請者・承認者・経理それぞれの立場の声を拾うことが、使われるシステムの前提になります。
特に、声が集中する箇所はシステム化の効果が大きく、要件の優先順位づけに使えます。そのうえで、AsIsを踏まえてあるべき姿（ToBe）を描き、その差分を埋めます。
riplaは、フルスクラッチと国内開発の立場から、現場の業務を出発点にToBeを描く要件整理を重視しています。
必須要件とあれば良い要件の切り分け
現場の要望をすべて必須にすると、要件が膨らみ、開発費やカスタマイズ費が増えます。一次データには、カスタマイズ費が20万円を超えたという声もあります。
- 優先度の分類：「必須（Must）」「あれば良い（Want）」「不要（Won’t）」の区分
- 判断基準：効率化や法令対応への寄与
- 実現方法：標準機能で満たす要件と、自社開発が必要な要件の区分
- 実装時期：必須要件は第一フェーズ、あれば良い要件は第二フェーズ以降
たとえば、電帳法・インボイス対応は必須とし、特定の少数部署だけが望む細かなカスタマイズは後回しにする判断をすることもあります。
この切り分けは、予算内で効果を出す設計の鍵です。また、SaaSで足りるか、自社開発が必要かも見極めやすくなります。
段階的に実装すれば、効果の大きい部分から早く稼働でき、初期投資を抑えながら現場の反応を見て改善できます。優先順位づけは、予算配分も支えます。
優先順位づけは、フェーズ分けの判断材料にもなります。さらに、RFPの説得力と導入後の満足度を高めることにもつながります。
非機能要件と法令・保存要件の定義
要件定義では、機能要件に目が向きがちです。しかし、非機能要件や法令・保存要件も重要です。
これらはシステム品質を支える要素で、曖昧なまま進めると、性能不足やコンプライアンス上の不備が運用後に表面化します。
性能・セキュリティ・可用性の非機能要件
非機能要件は、性能・セキュリティ・可用性の観点で定義します。
- 性能：月末の申請集中時にも画面が快適に動き、想定する同時利用者数や申請件数に耐える処理能力
- セキュリティ：アクセス権限、通信の暗号化、操作ログの保持
- 可用性：稼働率の目標、バックアップ、障害時の復旧方針
利用人数と申請のピークをベンダーに示し、必要な性能を保証させます。月次締めに処理が重くなって使えない事態を避けるため、事前の確認が欠かせません。
経費データには個人の機微な情報が含まれるため、セキュリティを要件として定める必要があります。また、システムが止まると申請・承認・支払が滞るため、可用性も定めます。
非機能要件は、見積もりと品質の両方に影響します。そのため、機能要件と同じように定義しておくことが、堅牢なシステムの前提になります。
電帳法・インボイスと退職者データ保存の要件
経費精算では、電子帳簿保存法とインボイス制度に加えて、退職者データの保存も扱います。そのため、保存の条件も要件定義で明確にしておきます。
- 電子帳簿保存法：タイムスタンプ、訂正・削除履歴、日付・金額・取引先による検索
- インボイス制度：適格請求書の判定、登録番号の管理、税率区分の処理
- 退職者データ：保存年数・方法・課金と、ベンダーの対応方針
法令対応は、有無だけでなく、その対応の質も要件として定めます。たとえば、法定の保存義務がある一方、ユーザー課金型のSaaSでは退職者アカウントの保持に課金が続きます。無料系では、保存期間が数ヶ月〜1年と短い場合もあります。
これに対して、自社開発であればデータを自社で保有し、保存期間と課金の構造を自社で設計できます。そのため、このジレンマを構造的に避けられます。要件の精度が、運用後のコンプライアンスとコストを左右します。
まとめ
経費精算システムのRFP・要件定義書では、(1)費目・旅費規程・承認ルートの明文化、(2)会計・給与連携と移行・並行運用の要件化を行います。
あわせて、(3)5年TCOと5つの隠れコストの評価、(4)関係者ヒアリングによるAsIsの把握と、必須・希望要件の切り分けが要点です。
データ移行の難航は、導入失敗の上位要因です。そのため、移行の範囲と並行運用を先に決めておくと、遅延や予算超過を防ぎやすくなります。
要件定義では「ベンダーに丸投げしない」姿勢が大切です。発注側が業務と要件を言語化して初めて、正確な見積もりと提案を得られます。
費目と承認ルート、既存システムを洗い出し、法令対応の必要度も確かめたうえで、必須要件を優先してRFPに記載します。
riplaはフルスクラッチ・ノーコード受託の立場から、現場の業務を起点にした要件整理と、TCOを踏まえた手段選びを支援します。全体像は完全ガイドをご覧ください。
▼全体ガイドの記事
・経費精算システムの完全ガイド
▼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を創業。