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