出張管理システムのRFP（提案依頼書）は、課題と目的を数値で示し、規程・連携・移行・費用・運用の条件を順に定義しておくと、提案を比べやすく、導入後も定着しやすくなります。
発注企業の立場から、RFP・要件定義書・提案依頼書の作り方を、要件定義に絞って解説します。
▼全体ガイドの記事
・出張管理システム（BTM）の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFP・提案依頼書に盛り込むべき項目
RFP（提案依頼書）は、自社の出張管理をどう改善したいかを各社に伝え、適切な提案と見積を得るための文書です。完成度が低いと、各社の提案は異なる前提で作られて比べられず、見積金額も信頼しにくくなります。そこで、出張業務特有の論点を漏れなく記載することが、よい提案を集める出発点になります。
現状の課題と導入目的の数値記述
RFPには、現状の課題とシステム導入の目的を記載します。課題の規模を示すには、次のような実数が役立ちます。
- 申請と精算の工数：Excel申請や紙精算にかかる処理工数
- 規程違反：承認時に防げていない出張規程の逸脱
- 費用把握：月次締めまで見えない出張費用
- 件数の実績：月約200件の申請や月20件の精算差し戻し
数値が具体的であるほど、ベンダーは改善の規模を見積もりやすくなります。さらに、導入目的をKPIとして定義しておくと、提案を評価する軸がぶれません。その軸に沿って、各社がKPIをどう実現するかを比べられます。
たとえば、1件あたりの処理時間を30分削減することや、電帳法・インボイス対応を自動化することが目標になります。また、部門別の出張費用をリアルタイムで見えるようにすることも、目標の一つです。
一次データの目安では、紙入力を時給3,000円に換算し、1人月約30分を約1,500円相当と見積もる考え方があります。費用対効果の根拠を示しておくと、社内稟議を説明しやすくなります。
対象範囲・予算・スケジュールの明示
RFPには、システムの対象範囲（スコープ）を明確に記載します。提案や見積の前提をそろえるため、次の条件を示します。
- 業務範囲：申請・承認、手配、精算、会計連携のどこまでか
- 出張地域：国内出張のみか、海外出張も含めるか
- 利用規模：対象ユーザー数と対象法人の数
範囲が曖昧なままだと各社の前提がずれ、「含まれていない」と後から追加費用が生じるおそれがあります。予算と導入時期も、現実的な提案に欠かせない条件です。
参考相場は、クラウドSaaSが1ユーザー月額300〜500円、ノーコード受託が初期100万〜300万円・月額1万〜3万円、ERP連携型が初期500万円〜です。そのうえで、自社の予算レンジを伝えると、規模に合う提案を得られます。
繁忙期や決算期を避けた希望時期を示すと、無理のない体制を組めます。
補助率は通常枠で1/2、要件を満たす場合は2/3で、上限規定もあります。補助金を活用する場合は、申請スケジュールも踏まえて計画します。
出張規程・承認フローの要件化
出張管理システムでは、出張規程（出張旅費規程）と承認フローが特に固有性の高い要件です。規程の条件が曖昧なままだと、リリース後に未対応が判明し、手戻りが必ず生じます。そこで、自社のルールを洗い出し、システムへの反映方法を要件として書き表すことが、成否を分けます。
宿泊費上限・日当・交通クラスのルールの棚卸し
宿泊費上限、日当、交通クラスなどの規程を、役職や地域別の違いも含めて漏れなく洗い出します。システムが判定するルールを把握するため、次の条件を確認します。
- 宿泊費：役職別や地域別の上限額
- 日当：役職などに応じた支給額
- 交通クラス：部長以上は新幹線グリーン車を利用できる、といった条件
- 暗黙の運用：特定の行先で慣習的に適用しているルール
洗い出しが不十分だと、システムで規程を正しく確認できず、人手によるチェックが残ります。また、発注側は、文書になっていない運用も要件定義の段階で言葉にしておきます。
複雑な規程は、システム化のコストを押し上げます。そこで、規程を見直す好機と捉えて簡素化すれば、開発と運用の負担を抑えられます。規程の棚卸しは、システム化の前提であり、業務改善の出発点でもあります。
承認ルートの分岐条件の明文化
承認者は、金額、出張先、所属部門によって変わるうえ、例外の扱いも加わります。そのため、誰がどの条件で承認するかを、例外の運用も含めて具体的に記述しておきます。
- 金額：一定額を超えた場合に役員承認を挟むか
- 出張先：海外出張で別の承認ルートにするか
- 所属部門：申請者の部門により承認者を変えるか
- 例外時：代理承認、取り下げ・修正、差し戻し後の再申請
条件分岐をパターン化しておけば、ベンダーはワークフロー機能の複雑さを正確に見積もれます。あわせて、組織変更への柔軟さも確認します。
とくに例外フローは、決めておかないと運用開始後に現場が混乱します。規程と実際の運用が食い違うこともあるため、関係者へのヒアリングが欠かせません。受注担当者、営業、経理に、申請や承認の実態を聞いておきます。
現状（AsIs）の業務を書き出し、あるべき姿（ToBe）を要件に反映させれば、現場の実態に合わない失敗を防げます。要件定義はベンダーに任せきりにせず、発注側が主体となって進める作業です。規程と承認フローの要件化は、出張管理システムの要件定義の中核です。
会計・給与連携とデータ移行の要件
出張管理システムは、会計・給与・経費精算などと連携して効果を発揮します。ただし、連携と移行は見落とされやすく、後から追加コストやトラブルになりがちな領域です。RFP・要件定義書で明確にし、隠れコストを防ぎます。
連携方式とマスタ整合の要件定義
連携後に手修正や想定外の開発が起きないよう、連携先ごとに次の条件を決めておきます。
- 連携方式：API連携かCSV連携か
- 連携データ：会計へ仕訳、給与へ立替金を渡すなど
- 実行タイミング：リアルタイム連携か日次バッチか
- コード整合：勘定科目、部門・プロジェクト・社員コードの対応
連携で最大の落とし穴は、マスタの不整合です。コード体系が異なると科目が合わず、手修正が発生します。そのため、両システムのコードを照合し、対応方法を設計しておきます。
連携方式が曖昧だと想定外の開発が生じ、費用が膨らみます。さらに、一次データでは給与計算連携費が10万〜50万円となるケースがあるため、費用を見込んでおく必要があります。
データ移行と並行運用の要件の見落とし防止
データ移行は、システム導入の失敗要因として上位に挙がります。そのため、移行対象・方法・移行後の検証手順を事前に要件として定めておきます。
切り替え後に業務が止まらないよう、移行で何を移し、どの順で確かめるかを決めておきます。既存データだけでなく、規程の設定や新旧の併用も移行の対象になるためです。
- 既存データ：過去の精算データと社員マスタ
- 規程設定：現在の出張規程やシステム設定
- 並行運用：新旧システムを併用し、データを確認してから完全移行
一次データでは移行費が5万〜30万円とされています。また、失敗統計の声として、移行が難航して1か月遅延し、安定稼働まで2か月かかったという例もあります。
全面移行では、トラブルが起きたときに業務が止まるリスクがあります。一方で、並行運用は二重入力の負担があるため、期間を短く区切る工夫も必要です。
移行と並行運用の要件を軽く扱わないことが、導入の失敗を避ける確実な方法です。
月額だけで選ばないTCO評価軸の要件化
出張管理システムには、月額利用料の裏に複数の隠れコストがあります。そこで、RFPでは5年総額のTCO（総保有コスト）を評価軸にし、月額単価の安さだけで判断しないようにします。
初期費用・連携費・運用工数を含む見積
月額表示だけでは把握しにくい初期設定やデータ移行、運用の負担も含めて、各社の見積内訳をそろえます。
- 初期設定・移行：「無料」サービスでも5万〜20万円の場合
- 移行・改修：移行費5万〜30万円、カスタマイズ費20万〜100万円超
- 連携・運用：給与連携費10万〜50万円、運用工数は年20万〜100万円換算
- 退職者データ：アカウント課金と法定期間の保存費用
出張・精算データには法定の保存義務があります。そのため、RFPで法定期間の保存方法と費用を明確に確認しておきます。
SaaSでは、退職者のアカウントを保持していると課金が続く場合があります。また、無料系は保存期間が数か月〜1年の場合もあります。月額だけで契約すると、退職者課金や保存対応の支出が想定より積み上がります。
人数規模に応じた5年TCOでの比較
人数規模と利用年数をそろえて試算を求めると、課金方式による違いを比較できます。評価時には、次の条件を含めます。
- 人数と期間：現在の規模を前提にした5年総額
- 従量課金：人数が増えた場合のクラウドSaaS費用
- 固定費型：ノーコード受託やフルスクラッチとの損益分岐
- 将来人数：増員後の5年TCOと補助金の活用可否
一次データの試算では、50名以上でノーコード受託の5年TCOが約160万〜500万円となり、SaaS従量課金より有利なケースがあります。
「想定人数が将来◯名に増えた場合の5年TCO」を条件にすると、各社の前提をそろえられます。人数の増減は出張管理に直結するため、数年後の規模も評価します。
補助金については、IT導入補助金は通常枠で1/2、要件次第で2/3となり、上限規定もあります。
TCOを要件に含め、月額だけで選ばないことが、長期的な投資判断につながります。
非機能要件とセキュリティ・運用保守の要件
RFP・要件定義書には、機能に加えて性能・セキュリティ・運用保守も盛り込みます。とくに、これらは目に見えにくく後回しにされがちです。出張管理システムは個人情報や経費データを扱うため、軽視すると重大なトラブルにつながります。そのため、非機能要件を定義しておくことが、安心して使えるシステムの前提になります。
個人情報保護と法定保存期間の要件
出張管理システムは、氏名・所属・行先・宿泊先・精算金額などの個人情報や機微なデータを扱います。そのため、次の保護要件を定義しておきます。
- アクセス管理：役割ごとの閲覧・編集権限
- 情報保護：通信の暗号化と操作ログの記録
- 権限変更：退職者や異動者の権限をどう扱うか
- 保存と検索：法定期間の保存方法と検索できる状態
海外出張者の所在情報は危機管理に関わるため、適切に保護しながら、必要なときに参照できる設計が求められます。
データの法定保存期間に関する要件も定めます。SaaSでは退職者アカウントの保持で課金が続く場合があり、無料系は保存期間が数か月〜1年の場合もあります。そのため、法定期間を満たせる仕組みを要件に盛り込みます。
電子帳簿保存法に沿った改ざん防止や検索性も定義します。そのうえで、必要な保存期間を満たす方法をRFPに明記します。
運用保守・サポート・法改正対応の要件
障害時の対応、保守作業、制度変更への追従は、長く使ううえで欠かせない条件です。RFPの段階で、各社の対応範囲をそろえて確認しておきます。
- 障害・問い合わせ：対応体制と窓口の有無
- 保守作業：バックアップ方法と改修依頼の手順
- 法改正：対応方針と費用負担
- 導入支援：定着を左右する初期設定代行や伴走支援を要件に明記
一次データでは、オンプレ・パッケージの年間保守が30万〜100万円、ERP連携型が20万〜100万円です。そのうえで、どこまでを誰が受け持つかを定めておくと、運用後のトラブルを防ぎやすくなります。
電子帳簿保存法、インボイス制度、同一労働同一賃金ガイドラインなどの改正が、システムに影響します。クラウドは自動更新で対応できます。
一方、自社開発では改正のたびに改修が必要です。そのため、追従方法と費用負担を要件定義で決めておき、将来の混乱を防ぎます。
まとめ
要点は、(1)課題と目的を数値で示し、範囲・予算・日程を明らかにすること、(2)規程と承認の分岐を要件として定めることです。
さらに、(3)連携のマスタ整合と移行・並行運用を確認し、(4)隠れコストを含めた5年TCOで比較します。これら四つが、要件定義・RFP作成の要点です。
出張規程は固有性が高く、曖昧なままでは必ず手戻りが発生します。そのため、自社業務を起点に条件を言語化すれば、提案を公平に比べられ、導入後のトラブルも防ぎやすくなります。
riplaは、フルスクラッチ受託とノーコード受託の両面から、出張業務の要件整理とRFP作成の段階から伴走し、現場に定着するシステムづくりを支援します。全体像は完全ガイドをご覧ください。
▼全体ガイドの記事
・出張管理システム（BTM）の完全ガイド
▼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を創業。