給与計算システムのRFP/要件定義書/提案依頼書について

給与計算システムの発注は、現状・独自ルール・連携と移行・TCOと選定基準の順に要件化して進めます。要件をこの順で定めると、提案を同じ条件で比べられ、見積もり精度と適合度も高まります。発注企業がRFP・要件定義書・提案依頼書を実務で作るための要点を、この順で示します。

▼全体ガイドの記事
・給与計算システムの完全ガイド

RFP・提案依頼書に盛り込む構成要素

給与計算システムRFPの構成要素を4つのパネルで示す図。
条件をそろえるほど、提案各社を同じ前提で比べやすくなります。

RFP(提案依頼書)は、依頼内容と提案の前提をベンダーに伝える文書です。前提がそろっていないと、各社の提案を同じ条件で比べられません。給与計算システムのRFPには、最低限押さえるべき構成要素があります。

現状業務・課題・導入目的の冒頭での明記

まず、現在の給与計算業務と課題、導入後に達成したい状態をRFPの冒頭に記します。勤怠データの転記にかかる時間や、残業代の計算ミスと是正対応などを具体化します。

  • 現状と課題:工数や計算ミスを、数値や具体例で示す
  • 導入目的:達成したい業務の状態

たとえば、Excelと手計算で毎月処理しており、勤怠データの転記に1人月30分程度かかる状況や、残業代の計算ミスが散発する状況を記します。一次データでは、紙入力は時給3,000円換算で1人月約30分、約1,500円の工数とされています。数値で課題を示すと、ベンダーは改善効果を具体的につかめます。

また、導入目的は、勤怠連携による転記工数ゼロ化、年末調整の従業員セルフ申告化、複数法人の給与一元管理のように、具体的な状態で示します。目的が明確であれば、提案をその達成に結び付けて評価できます。一方で、目的が曖昧だと機能の網羅性だけで選ぶことになり、自社に重要な要件が埋もれるおそれがあります。

対象範囲・予算枠・スケジュールと前提条件の提示

対象業務や従業員の構成、予算、希望日程を示すと、各社が同じ条件で実現性を検討できます。

  • 業務範囲:給与計算や勤怠・労務・年末調整の対象
  • 規模と予算:従業員数、雇用形態、予算枠
  • 日程:本稼働時期と並行運用の期間

従業員数は月額の試算に直結します。たとえば、一次データでは、50〜99名は月14,500〜28,710円、100〜199名は月29,000〜57,710円で、規模によって費用が異なります。

正社員・パート・派遣・外国人など、雇用形態の内訳も記載します。雇用形態によって計算ルールの複雑さが変わるため、この内訳は欠かせません。

予算や日程に幅を持たせすぎず、実現性を判断できる前提を示します。導入時には、データ移行や初期設定が難航して1か月遅れ、安定稼働まで2か月かかったという声もあります。そこで、バッファを含む工程を共有しておくと、後の認識ずれを防げます。

機能要件と非機能要件を分けた記述

RFPの本体となる要件一覧は、システムの機能と品質条件を分けて整理します。分けておくと、機能の充足度と運用上の安全性を、それぞれ別の観点で比較できます。

  • 機能要件:システムに必要な処理や機能
  • 非機能要件:性能やセキュリティなどの品質条件

機能要件には、支給・控除の計算や勤怠連携、年末調整、明細発行などを含めます。そのうえで各機能に「必須」「あれば望ましい」といった優先度を付けると、各社の対応状況を点数で比べられます。

非機能要件には、性能・セキュリティ・可用性・権限管理・データ保存を含めます。給与情報は機密性が高いため、細かなアクセス制御や操作ログ、暗号化、バックアップも定義します。

退職者データの法定保存も定義します。機能だけを詳しくして非機能要件を曖昧にすると、セキュリティや保存の問題が生じます。両方の要件をバランスよく定めることが、堅牢なシステムの前提になります。

ポイント

RFPは、現状と目的、対象範囲、機能要件と非機能要件のそれぞれを、数値や具体例で書けているかを見直すとよいでしょう。曖昧な項目があれば、提案を比べる前に直しておきます。

独自就業規則の要件への落とし込み

要件定義の中心は、自社独自の就業規則や給与規程を言葉にすることです。内容が曖昧なままだと、選んだシステムで自社の計算を再現できないおそれがあります。

手当・割増・丸め処理のルールの計算式までの明文化

手当の支給条件、残業の割増率、端数処理は企業ごとに異なります。そのため要件では、金額や対象、計算単位、端数処理の方法まで具体的に示します。

  • 手当:役職や通勤などの支給条件と上限
  • 割増:法定率と自社独自の率
  • 丸め処理:時間の集計単位と端数処理

たとえば、課長級に役職手当を月3万円、通勤手当は実費で月5万円を上限とし、残業代は1分単位で計算して月の合計で円未満を切り捨てる、と記します。

深夜割増25%や法定休日割増35%などの法定率に加えて、法定を上回る自社独自の割増率も記載します。労働時間を1分単位か15分単位のどちらで集計するか、端数を切り上げるか切り捨てるかも明記します。ここを誤ると、支給額の差異につながり、法的な問題になり得ます。

一次データでも、勤怠の独自丸め処理を再現できるかが導入の成否を分けるとされています。そこで、実際の計算例を添え、勤務実績と支給額の組み合わせをテストケースとして用意します。提案各社にも、テストケースの再現可否を確かめてもらうと、選定の精度を高められます。

変形労働・複数法人・外国人雇用など特殊要件の整理

標準的な月給制以外の勤務形態や、法人・雇用上の個別条件がある場合は、それぞれを独立した要件として整理します。曖昧なままにせず、標準機能で対応できるかをひとつずつ確認します。

  • 勤務形態:変形労働時間制、フレックス、シフト、日雇い・単発雇用
  • 複数法人:法人ごとの締め日、支給日、計算ルール
  • 外国人雇用:明細の多言語表示、在留資格に紐づく就労時間管理

こうした要件は、パッケージSaaSでは「要確認」とされやすいため、先に明確にしておくとミスマッチを防げます。要件が複雑だと、パッケージの標準機能を超えることがあります。その場合は、フルスクラッチやノーコード受託も選択肢になります。

各社に、標準対応かカスタマイズが必要かを尋ねると、見積もりの前提がそろいます。一次データでは、追加カスタマイズ費が20万〜100万円超になる場合もあるため、費用の見通しも立てられます。

ポイント

特に、手当・割増・丸め処理が計算式まで書けているか、変形労働や複数法人の条件が標準機能で足りるかが、要件の出来を左右します。

連携・データ移行・並行運用の要件定義

給与計算システムを中心に、連携方式、データ移行範囲、並行運用、テストケースを配置した図。
切り替え前後の作業を一続きの要件として確認できます。

給与計算システムは前後のシステムと連携し、旧システムからデータを移します。費用や移行後の検証まで要件に含めると、予算超過や切り替え時の問題を防ぐことにつながります。一次データでは、給与計算連携費が10万〜50万円、データ移行費が5万〜30万円の隠れコストとして発生するとされています。

勤怠・会計との連携方式と連携項目の定義

連携元と連携先の製品名、方式、項目を具体的に示します。「連携できる」とだけ書かれていると、実際の手順やデータの受け渡し方を比べられません。

  • 製品と方式:勤怠・会計製品名、APIまたはCSV
  • 対象項目:給与計算に必要な勤怠データ
  • 運用条件:タイミング、方向、エラー検知

ジョブカンやKING OF TIMEを利用中であれば、その製品名を記し、確定データを月次でAPI連携したい、といった形で要件化します。項目には、出勤日数・労働時間・残業時間・深夜休日内訳・各種休暇取得日数などを含めます。

連携条件として、リアルタイムか月次バッチか、片方向か双方向か、エラーをどう検知するかも定義します。条件が曖昧だと、CSVを手動で取り込む半自動の仕組みを「連携」と呼ぶベンダーもあり得ます。会計への仕訳連携では、勘定科目と仕訳の粒度も示します。

データ移行範囲と並行運用期間の要件化

切り替えで給与額が狂わないよう、移行対象と保存方針、旧新システムを並行して動かす期間、責任分担を決めておきます。データを移した後に給与額を正しく再現できるかまで、確認します。

  • 移行範囲:対象データと移行する年数
  • 並行運用:給与計算サイクルと期間
  • 責任分担:ベンダーと自社の作業範囲
  • 検証:テストケースと確認手順

従業員マスタや過去の給与実績、年末調整データ、賃金台帳などから移行対象を選び、何年分を移すかを定義します。賃金台帳などには法定の保存義務があるため、退職者を含む過去データの移行・保持範囲も決めます。

クラウドSaaSでは、退職者アカウントへの課金が続く場合があります。そのため、移行後の保存方針まで要件に含めます。

並行運用では、同じ月の給与を旧新システムの両方で計算し、結果が一致することを確かめてから切り替えます。安定稼働まで2か月かかるという声もあるため、最低1〜2回の給与計算サイクルを充てる前提を示します。

テストでは、深夜・休日・時間外を含む勤務や、手当・控除が絡む典型例を用意します。そのうえで、勤務実績に対する支給額を示し、新システムで正しく再現できるかを検証します。

テストケースをRFP段階で示せば、提案各社に再現可否を確認でき、本稼働前の検証にも役立ちます。また、移行後に正しい金額が出ることを検証のゴールとし、手順を要件化して支給ミスを防ぎます。

ポイント

連携の製品名と方式、移行範囲、並行運用の期間が具体的に決まっていて、テストで給与額を再現できるかが判断の目安になります。

TCO評価軸とベンダー選定基準の言語化

5年TCO、サポート、法改正対応、導入実績を並べたベンダー選定基準の図。
費用と導入後の対応力をあわせて見渡せます。

最後に、提案を評価する基準を明文化します。月額だけで決めると、隠れコストや長期の総額を見落とすおそれがあるため、TCO(総保有コスト)とベンダーの対応力も評価軸に含めます。TCOの評価軸とベンダー選定基準をRFP段階で定めておくと、納得できる選定につながります。

5年TCOと隠れコストの評価

月額利用料以外の費用も内訳として提示してもらい、5年など一定期間の総額で比べます。人数の増加や運用工数も含めれば、将来の費用まで判断できます。

  • 初期・連携費:機器、移行、カスタマイズ、外部との接続
  • 運用工数:年間の作業量に換算して確認する
  • 5年TCO:現在と将来の人数を前提にした比較

一次データが挙げる隠れコストは5項目です。ICカードリーダーなどの機器が5万〜50万円、データ移行費が5万〜30万円、カスタマイズ費が20万〜100万円超です。

給与計算連携費は10万〜50万円、運用工数は年20万〜100万円換算です。各社に内訳を出してもらえば、月額の安さだけに左右されず比べられます。

クラウドSaaSは人数の増加で月額が上がり、退職者にも課金が続きます。一方、ノーコード受託は初期100万〜300万円、月額1万〜3万円の固定費型です。

一次データでは、50名以上の場合、ノーコード受託の5年TCOは約160万〜500万円で、SaaSより有利になると試算されています。現状人数と3〜5年後の想定人数を各社に示し、規模拡大を含めた5年TCOを出してもらいます。そうすると、現在だけでなく将来の費用も比べられます。

サポート体制・法改正対応・導入実績の選定基準への追加

給与のトラブルは従業員の信頼に関わるため、長期利用を支える対応も選定基準にします。

  • サポート:初期設定、導入支援、稼働後の担当者
  • 法改正対応:無償対応の範囲と迅速さ
  • 導入実績:自社に近い規模・業種・雇用形態

具体的には、初期設定の代行や導入時の伴走支援、稼働後の専任問い合わせ担当の有無を各社に尋ねます。法改正への無償対応が、どれほど迅速だったかも確認します。

自社に近い規模・業種・雇用形態での実績があれば、ベンダーが要件を理解し、提案の精度を高めやすくなります。評価軸には、コスト・機能適合・サポート・実績などの重みを設定します。各社の提案を点数化すれば、属人的な判断を避けられ、関係者も納得しやすくなります。

riplaは、フルスクラッチ受託とノーコード受託、国内開発の立場から、要件定義の壁打ちやRFP作成、提案評価までを支援します。

補助金活用と法改正追従の要件の提示

補助金の活用方針と法改正への追従方法を示しておくと、初期負担や長期運用を含めて提案を比べられます。対象経費や適用条件は、制度の公募要領で確認します。

  • 補助金:対象製品・構成と適用条件
  • 法令対応:対応する主体と方法

IT導入補助金の通常枠では、対象経費の2分の1、最大150万円未満が補助されます。令和6年10月から令和7年9月には、最低賃金未満の従業員が30%以上の事業者で、補助率が3分の2に上がる枠もあります。

各社の製品と構成が対象かを確かめれば、初期負担を抑える提案を得られます。公募要領は年度ごとに変わるため、最新の公募要領を前提にします。

社会保険料率や税率、働き方改革関連法などの改正に加えて、2026年10月施行の同一労働同一賃金ガイドライン改正への対応も定義します。対応の主体は、クラウドの自動アップデート、ベンダー保守、自社対応のいずれかを明記します。導入時の機能だけでなく、数年先までの法令や制度変更への追従を定義することが、後悔しない選定の条件になります。

ポイント

各社の提案を5年TCOで比べ、さらにサポート・法改正対応・補助金の扱いまで評価軸に入っているかが、選定の判断材料になります。

まとめ

給与計算システムのRFPは4つの柱で整理し、そのうえで計算条件や特殊要件も具体化します。中心になるのは、現状・課題・目的の明記と、独自就業規則の要件化です。残りの2つは、連携や移行をどこまで要件に含めるかと、長期の総額で提案を比べる軸に関わります。

  • 連携・移行・並行運用:勤怠・会計との連携方式と、データ移行の範囲
  • TCOと選定基準:長期の総額での比較と、提案を評価する軸

手当・割増・丸め処理や、変形労働・複数法人・外国人雇用の要件を漏れなく記すことが、適合度を高めます。

隠れコスト5項目や5年TCO、安定稼働まで2か月という一次データも、前提に含めておきます。そうすると、予算超過や移行失敗を防ぎやすくなります。

まず自社業務を正確に言語化し、その条件を満たせる手段を各社に提案してもらいます。riplaは要件の壁打ちから提案評価まで支援し、自社の就業規則を再現する給与計算基盤づくりに伴走します。

4つの柱をRFPの骨子にすれば、自社の提案依頼書を書き起こせます。全体像を確認する際は、給与計算システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・給与計算システムの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。