人事システムのRFPとは？書き方・必須項目・作成手順を実例付きで解説 |人事管理システム業務効率化ナビ

人事システムのRFPには、導入目的や対象業務だけでなく、機能・非機能要件、データ移行、外部連携、費用、導入支援、評価方法まで記載します。

重要なのは、いきなり必要機能を並べるのではなく、現行業務と課題を棚卸しし、要件に優先順位を付けることです。

本記事では、各社の提案を同じ条件で比較できるRFPの作成手順と必須項目、記載例を解説します。

人事システムのRFPは提案条件をそろえて比較するための文書

RFPとは「Request for Proposal」の略で、日本語では「提案依頼書」と呼ばれます。システムの導入を検討する企業が、候補となるベンダーに対して自社の目的や要件、予算、スケジュールなどを提示し、具体的な提案を依頼する文書です。

人事システムを選ぶ際、口頭で希望を伝えるだけでは、ベンダーごとに前提の異なる提案が届く可能性があります。

例えば、あるベンダーの見積もりにはデータ移行費が含まれ、別のベンダーでは含まれていない場合、見積金額だけでは適切に比較できません。RFPで依頼内容と回答形式を統一しておけば、機能、費用、運用負担、セキュリティ、導入支援などを同じ条件で比較しやすくなります。

IPA（独立行政法人情報処理推進機構）も、RFPにはシステム導入の目的や要件を、ベンダーが理解できるように記載する必要があると説明しています。また、要件を「業務要件」「システム機能要件」「非機能要件」などに分けて整理しています。

参考：IPA「ストーリーで学ぶ要件定義実践入門」

RFP・RFI・要件定義書・仕様書の違い

RFPと混同されやすい文書に、RFI、要件定義書、仕様書があります。

文書	主な目的	作成・利用する時期	主な内容
RFI	市場や製品、ベンダーに関する情報を集める	候補製品を絞り込む前	製品概要、対応範囲、概算費用、導入実績
要件定義書	自社が実現したい業務や必要条件を整理する	RFP作成前または導入プロジェクトの初期	業務要件、機能要件、非機能要件
RFP	複数のベンダーへ具体的な提案を依頼する	比較・選定段階	導入目的、要件、予算、日程、提案依頼事項
仕様書	システムが満たすべき仕様を明確にする	発注・設計・契約前後	機能、性能、構成、納品物、検収条件

実務上の名称や使い分けは企業・プロジェクトによって異なります。大切なのは文書名ではなく、情報収集、要件整理、提案依頼、契約という各段階で何を確定させるかを明確にすることです。

SaaS選定のRFPでは実現方法を固定しすぎない

クラウド型の人事システムを選ぶ場合、必要な業務結果は具体的に示しつつ、実現方法まで細かく指定しすぎないことがポイントです。

例えば、「現在使用しているExcelと同じ画面を作る」と指定するのではなく、次のように目的と条件を伝えます。

従業員本人が住所変更を申請し、上長と人事担当者の承認後に従業員情報へ反映できること。承認経路、反映方法、変更履歴の確認方法を提案してください。

SaaSには、あらかじめ用意された標準機能や運用方法があります。現行業務の再現を細かく求めすぎると、個別対応や追加費用が増えたり、より簡単な標準運用を採用できなくなったりする可能性があります。

RFPの回答欄では、各要件について次の区分を示してもらうと比較しやすくなります。

標準機能で対応
設定変更で対応
オプションで対応
外部システムとの連携で対応
個別開発で対応
運用による代替が必要
対応不可

RFPを書く前に目的・業務・データ・関係者を整理する

RFPの作成は、必要機能を列挙する作業ではありません。まず、現在の業務と課題を明らかにし、システム導入後にどのような状態を実現したいかを整理します。

IPAも、導入するシステムを検討する前に「何のために、いつ、誰が、どのような業務や判断をするか」を整理することが重要だとしています。

導入目的は機能ではなく、解決したい業務課題で示す

「人事情報をクラウド化する」「ワークフロー機能を導入する」といった表現は、導入手段の説明にとどまります。RFPでは、その手段によって何を解決したいのかを示しましょう。

導入目的は、次の順番で整理すると伝わりやすくなります。

現在の業務
発生している問題
実現したい状態
対象となる業務範囲
導入後の確認方法

記載例は次のとおりです。

現在、従業員情報を複数のExcelファイルと紙の申請書で管理しているため、同じ情報の重複入力や更新漏れが発生している。従業員情報と変更履歴を一元管理し、申請・承認から情報更新までの運用を統一したい。対象業務は従業員情報管理、組織管理、各種申請とし、給与計算業務は今回の対象外とする。

「人事業務を効率化したい」のような抽象的な目的だけでは、ベンダーが提案範囲を判断できません。現状、対象、目指す状態をセットで記載することが重要です。

関係部門ごとの確認範囲を決める

人事システムのRFPを人事部門だけで完成させようとすると、セキュリティ、契約、予算、外部連携などの要件が不足する可能性があります。

関係者	主な確認範囲
人事・労務部門	現行業務、機能要件、利用者、帳票、承認経路
情報システム部門	システム構成、認証、権限、ログ、外部連携、障害対応
法務・個人情報保護担当	利用規約、委託条件、再委託、データの取扱い
経理・購買部門	予算、費用内訳、支払条件、契約期間、解約条件
部門管理者・利用部門	操作性、閲覧範囲、承認業務、現場運用
経営・決裁者	導入目的、投資範囲、優先順位、意思決定

全員がすべての項目を書く必要はありません。誰が作成し、誰が確認し、誰が最終承認するかを最初に決めておきましょう。

人事システムのRFPに記載する12項目

人事システムのRFPには、少なくとも次の項目を含めます。

項目	主な記載内容
1. 会社・プロジェクト概要	会社概要、従業員規模、拠点、導入背景
2. 導入目的・対象範囲	解決したい課題、対象業務、対象外業務
3. 現行業務・システム	業務フロー、利用中のシステム、課題
4. 機能要件	従業員管理、組織管理、評価、申請など
5. 非機能・セキュリティ要件	性能、可用性、認証、権限、ログなど
6. データ移行要件	対象データ、形式、件数、移行方法
7. 外部システム連携要件	連携先、対象データ、頻度、方式
8. 導入・運用・サポート要件	初期設定、研修、問い合わせ、障害対応
9. スケジュール・実施体制	提案期限、選定、移行、稼働予定
10. 費用・契約条件	初期費用、月額費用、追加費用、契約期間
11. 提案書の回答形式	適合状況、実現方法、制約、費用
12. 評価基準・選定方法	必須条件、評価項目、配点、選定手順

1．会社・プロジェクト概要

ベンダーが提案の前提を理解できるよう、次の情報を記載します。

事業概要
従業員数と利用予定者数
拠点数
雇用区分
グループ会社の有無
人事部門の体制
プロジェクトの背景
現行システムの利用期間
新規導入かリプレイスか

従業員数は、料金や処理性能、導入支援の規模を見積もる際の前提になります。将来の増員やグループ会社への展開を予定している場合は、その見込みも記載します。

2．導入目的・対象業務・期待する状態

「何を導入するか」だけでなく、「なぜ導入するか」を明確にします。

対象業務と対象外業務は、次のように区別して示しましょう。

対象業務：従業員情報管理、組織管理、申請・承認、人事評価
対象外業務：給与計算、勤怠集計、社会保険手続き
ただし、対象外システムとのデータ連携は提案範囲に含める。

対象外の業務も明示しておけば、提案範囲や見積もりの認識違いを防ぎやすくなります。

3．現行システムと業務フロー

現行システムについては、製品名だけでなく、実際にどのような業務で使用しているかを整理します。

システム名・ツール名
管理している情報
利用部門・利用者
データの入力者
入力・更新の頻度
他システムとの受け渡し
紙やExcelで残っている作業
二重入力や手作業が発生している箇所
現行システムの契約終了時期

業務フロー図やシステム連携図を添付すると、ベンダーが提案範囲を把握しやすくなります。

4．機能要件

機能要件では、業務ごとに必要な処理や確認事項を整理します。

人事システムでは、主に次の領域が対象になります。

従業員基本情報の登録・更新
自社独自項目の管理
雇用区分や所属、役職の管理
組織図の作成・閲覧
組織・所属情報の履歴管理
入社、異動、休職、退職などの履歴管理
人事異動の検討
従業員本人による情報変更申請
申請・承認ワークフロー
人事評価シートの作成・配布・回収
給与明細などの電子交付
人事情報の検索・集計・出力
閲覧・編集権限の設定
アラート・お知らせ
外部システムとのデータ連携

必要な機能名だけを書くのではなく、誰が、どの場面で、何をできる必要があるかを記載します。

悪い例：

組織図機能があること。

改善例：

指定した基準日時点の組織と所属従業員を確認できること。過去の組織構成を確認できるか、将来の組織案を作成・保存できるか、利用権限をどのように設定できるかを回答すること。

5．非機能・セキュリティ要件

非機能要件とは、機能そのものではなく、システムの性能、安定性、安全性、運用性などに関する条件です。

主な確認項目は次のとおりです。

利用可能時間
メンテナンス時間
想定利用者数と同時アクセス
応答性能
バックアップの取得方法・頻度
障害発生時の復旧方針
データセンター・クラウド基盤
通信・保存データの暗号化
パスワードポリシー
多要素認証
接続元IPアドレス制限
ユーザー・組織単位の権限設定
操作ログ・変更履歴
脆弱性対応
インシデント発生時の連絡
第三者認証の取得状況
データ保管場所
再委託の有無と管理方法
契約終了時のデータ返却・削除

人事システムでは、従業員の住所、家族情報、給与関連情報、評価情報など、慎重な取扱いが必要な個人データを扱います。

個人情報保護委員会は、人事労務管理クラウドについて、サービス提供者と利用企業の双方が安全管理措置や委託先の監督を適切に行う必要があると注意喚起しています。RFPでは機能の有無だけでなく、契約内容、再委託、データの取扱状況を利用企業が把握できるかも確認しましょう。

参考：

個別の法的判断が必要な場合は、社内法務、個人情報保護担当者、弁護士などへ確認してください。

6．データ移行要件

データ移行の対象と役割が曖昧だと、導入段階で追加費用やスケジュール変更が発生する可能性があります。

RFPには次の事項を記載します。

移行対象となるデータ
データの保存形式
対象件数・ファイル数
移行する履歴の期間
添付ファイルの有無
重複・欠損・表記揺れの状況
データの整理・変換担当
移行回数
テスト移行の有無
移行後の確認方法
不備があった場合の対応
旧システムのデータ削除・返却方法

例えば、「従業員データを移行する」とだけ書くのではなく、次のように具体化します。

在籍者約500名、退職者約300名の基本情報、所属・役職履歴、研修履歴をCSV形式で移行する。添付ファイルは約2,000件。移行用データの作成、変換、テスト移行、本番移行、移行結果の検証について、発注者とベンダーの作業分担および費用を提示すること。

件数は自社の実データを調査して記載し、概算の場合は概算であることを示します。

7．外部システム連携要件

人事システムは、勤怠、給与計算、採用管理、労務手続き、電子契約などのシステムと連携する場合があります。

連携要件では次の情報を整理します。

連携対象システム
連携するデータ項目
データを送る方向
連携頻度
リアルタイムか定期処理か
API、CSVなどの連携方式
初期設定・開発費用
月額費用
エラー発生時の確認・再処理方法
連携仕様変更時の対応

「連携可能」という説明だけでは、自社が必要とするデータを自動連携できるとは限りません。対象項目、方向、頻度、追加費用まで確認する必要があります。

8．導入・運用・サポート要件

システムの初期設定やデータ登録をどこまで自社で行うかによって、導入期間と費用が変わります。

導入計画の作成
要件確認
初期設定
データ登録・移行
操作研修
管理者向けマニュアル
従業員向けマニュアル
社内説明会
問い合わせ方法
対応時間
障害時の連絡方法
定期的な運用支援
制度・組織変更時の設定支援

サポートの有無だけでなく、標準料金に含まれる範囲と有償になる範囲を分けて回答してもらいましょう。

9．スケジュールと実施体制

RFPには、提案依頼から本番稼働までの予定を示します。

RFP送付日
質問受付期限
質問回答日
提案書・見積書の提出期限
製品デモ・プレゼンテーション
評価・選定
契約予定日
要件確認・初期設定
テスト移行
操作研修
本番移行
運用開始

希望日だけを示すのではなく、実現可能性や必要な準備期間を提案してもらう方法もあります。

10．費用と契約条件

見積もりは、少なくとも次の区分に分けて提示してもらいます。

初期費用
基本利用料
従業員数・利用者数に応じた料金
オプション費用
データ移行費用
外部連携費用
初期設定・導入支援費用
研修・マニュアル作成費用
個別対応・開発費用
保守・サポート費用
契約更新時の費用
解約時のデータ出力・返却費用

あわせて、最低利用人数、最低契約期間、更新方法、料金改定、解約期限、データ保管・削除などの契約条件も確認します。

11．提案書の回答形式

自由形式の提案書だけでは、ベンダーごとに回答場所や粒度が異なり、比較に時間がかかります。

RFP本体とは別に要件一覧表を用意し、各要件に対して次の内容を回答してもらいましょう。

回答項目	内容
適合状況	対応、条件付き対応、対応不可
実現方法	標準、設定、オプション、連携、個別対応、運用代替
提供時期	現在提供中、提供予定、未定
前提・制約	利用条件、件数上限、対応ブラウザなど
追加費用	初期費用、月額費用、個別見積もり
根拠	マニュアル、仕様書、デモで確認可能か

将来の開発予定は、現在利用できる機能と分けて回答してもらいます。

12．評価基準と選定方法

RFPを送付する前に、評価基準を決めておきます。提案を受けてから基準を変えると、特定の製品に有利な評価になったり、社内の合意形成が難しくなったりするためです。

主な評価項目は次のとおりです。

導入目的との適合性
必須機能への対応
操作性・管理のしやすさ
セキュリティ
データ移行
外部システム連携
導入・運用支援
導入スケジュール
初期費用
継続費用
契約条件
ベンダーの実施体制

必須要件を満たさなければ選定対象外とするのか、代替提案を認めるのかも事前に決めます。

人事システムのRFPは7ステップで作成する

ここからは、RFPの作成手順を7つのステップで説明します。

ステップ1．導入目的と意思決定者を決める

最初に、システム導入で解決したい課題と最終的な意思決定者を明確にします。

導入目的に複数の候補がある場合は、優先順位を付けます。例えば「情報の一元管理」を第一目的、「申請業務のペーパーレス化」を第二目的とするなど、判断の軸を決めておきましょう。

ステップ2．現行業務・システム・データを棚卸しする

現行業務について、誰が、何を使い、どのような順番で処理しているかを整理します。

特に確認したいのは次の点です。

同じ情報を複数回入力している業務
紙やメールで受け付けている申請
Excelで行っている集計
特定の担当者しか対応できない作業
最新情報の所在が分かりにくい項目
システム間で手作業による転記がある箇所
更新履歴を確認できない情報
データの重複、欠損、表記揺れ

現行業務をそのままシステム化するのではなく、不要な作業を廃止できないか、業務を統合・簡素化できないかも検討します。

ステップ3．対象範囲と要件を洗い出す

棚卸しした課題をもとに、対象業務と必要条件を整理します。

要件は、管理者の視点だけでなく、従業員、上長、人事担当者、経営者など、利用者ごとに確認すると抜け漏れを減らせます。

例えば、住所変更業務では次の要件が考えられます。

従業員が自分で変更を申請できる
必要な添付書類を提出できる
所属や申請内容に応じて承認経路を変えられる
人事担当者が内容を確認できる
承認後の情報を従業員データへ反映できる
変更前後の情報と処理履歴を確認できる
給与計算などの関連システムへ変更情報を渡せる

ステップ4．要件を「必須・希望・提案希望」に分ける

すべての要件を必須にすると、候補製品が極端に少なくなったり、個別対応の費用が増えたりする可能性があります。

優先度	判断基準
必須	対応できなければ対象業務を運用できない
希望	対応できれば効果が高いが、代替運用も可能
提案希望	最適な方法をベンダーから提案してほしい
対象外	今回の導入範囲には含めない

「今まで使っていたから」という理由だけで必須にせず、導入目的に必要かどうかで判断します。

ステップ5．提案条件・費用内訳・回答様式を統一する

各社に同じ要件一覧表と見積もり様式を渡します。

例えば、3年間または5年間の総費用を比較したい場合は、想定従業員数、利用機能、支援範囲、契約期間を統一します。条件が異なる見積もりを単純比較しないよう注意しましょう。

ステップ6．関係部門によるレビューを行う

RFPの初稿ができたら、人事部門以外の関係者にも確認してもらいます。

業務要件に漏れがないか
要件同士に矛盾がないか
必須条件が多すぎないか
予算とスケジュールが現実的か
セキュリティ基準を満たしているか
契約・個人情報の確認事項が含まれているか
回答を比較できる形式になっているか

レビューで修正した場合は、版番号や更新日を付けて管理します。

ステップ7．候補ベンダーへ提示し、質問回答を共有する

RFPを送付した後は、質問の受付方法と期限を統一します。

同じRFPを受け取ったベンダー間で情報量に差が出ないよう、回答が提案条件に影響する質問については、必要に応じて全候補へ同じ内容を共有します。

提出後に製品デモを実施する場合も、確認シナリオを統一しましょう。例えば、各社に同じ従業員情報の更新、組織変更、申請承認、集計などを実演してもらうと比較しやすくなります。

要件表は「適合状況・実現方法・追加費用」を回答できる形にする

人事システムの要件一覧表は、次のような列で作成できます。

要件ID	業務	要件	優先度	ベンダー回答	実現方法	追加費用	制約・備考
EMP-01	従業員管理	自社独自の管理項目を追加できること	必須
ORG-01	組織管理	指定日時点の組織構成を確認できること	希望
WF-01	申請	申請内容に応じて承認経路を設定できること	必須
SEC-01	認証	多要素認証に対応できること	必須
MIG-01	移行	所属・役職の過去5年分の履歴を移行すること	希望

これは記入形式の一例です。優先度や回答区分は、自社の選定方針に合わせて変更してください。

「対応可能」という回答だけでは、標準料金で使えるのか、追加設定や個別開発が必要なのか分かりません。実現方法、費用、制約をセットで回答してもらうことが重要です。

RFP作成でよくある6つの失敗と防止策

1．導入目的が抽象的

「DXを推進する」「業務を効率化する」だけでは、提案の判断基準が定まりません。

現行業務の問題、対象業務、実現したい状態を具体的に示しましょう。

2．現行業務をそのまま再現しようとする

現在の帳票やExcelをそのまま再現することを必須にすると、SaaSの標準機能を活用できない可能性があります。

残すべき業務要件と、変更できる運用を分けて整理します。

3．すべての要件を必須にする

要望をすべて必須にすると、候補製品を不必要に除外することがあります。

法令、社内統制、事業継続などの観点から本当に外せない要件と、代替運用が可能な要件を区別します。

4．曖昧な表現を使う

「柔軟に設定できる」「簡単に集計できる」といった表現は、人によって解釈が異なります。

設定できる項目、操作する利用者、必要な出力形式など、判断できる条件へ置き換えましょう。

5．見積もりに含める範囲が統一されていない

基本料金だけを比較すると、オプション、移行、連携、導入支援などを含めた総費用を判断できません。

同じ利用人数、機能、契約期間、支援範囲を前提として費用を回答してもらいます。

6．提案後に評価基準を決める

提案を見てから評価基準を決めると、評価が担当者の好みに左右されやすくなります。

必須条件、評価項目、配点、評価者をRFP送付前に決めておきましょう。

RFP送付前のチェックリスト

導入目的を業務課題と結び付けて説明している
対象業務と対象外業務を明記している
従業員数、拠点、雇用区分、利用者を示している
現行業務とシステム構成を整理している
要件に「必須・希望・提案希望」などの優先度がある
権限、履歴、ログに関する要件がある
移行対象、件数、形式、役割分担を示している
外部連携の対象データ、方向、頻度を示している
初期費用、月額費用、追加費用の回答区分を統一している
標準、設定、オプション、個別対応を分けて回答できる
セキュリティと委託先監督の確認事項がある
導入支援と運用サポートの範囲を確認できる
質問、提案、デモ、選定の日程を示している
評価基準を提案依頼前に決めている
関係部門によるレビューが完了している

RFPへの回答は機能数だけでなく自社業務との適合性で評価する

人事システムは、機能数が多い製品ほど自社に適しているとは限りません。

提案を評価する際は、次の順番で確認します。

必須要件を満たしているか
標準機能で実現できる範囲はどこか
自社の業務を標準機能へ合わせられるか
オプションや個別対応が必要な要件は何か
導入後に発生する管理・運用作業は何か
データ移行と外部連携を実行できるか
セキュリティと契約条件を満たしているか
初期費用と継続費用を含む総費用はいくらか

画面デザインや短時間のデモだけで判断せず、実際の業務シナリオに沿って操作と運用を確認しましょう。

人事情報の一元管理を検討する場合はサイレコの公式情報も確認する

「サイレコ」は、組織人事の情報を蓄積し、経営情報としての活用を支援するクラウド型人事管理システムです。

公式サイトでは、従業員管理、管理項目のカスタマイズ、組織図、組織構成の履歴検索、申請承認管理、ワークフロー、給与明細、アラートなどが案内されています。

また、評価機能による目標設定から評価調整までの業務効率化や、採用管理、勤怠管理、給与計算、労務手続きなどの関連サービスとの連携も紹介されています。必要な連携先、連携方式、対象データ、費用は個別に確認してください。

セキュリティについては、SSLによる暗号化通信、パスワードポリシー設定などが標準仕様として案内されています。公式料金ページでは、接続元IPアドレス制限と二要素認証、評価機能などにオプション表記があるため、RFPとの照合では標準機能とオプションを分けて確認する必要があります。

導入支援については、導入プランに応じて項目設定、情報登録、運用設計などを専任のサポートチームが支援すると案内されています。具体的な支援範囲、費用、導入期間は、自社の対象業務やデータ量を示したうえで確認しましょう。

人事システムのRFPに関するよくある質問

人事システムの導入では必ずRFPを作る必要がありますか？

RFPの作成が法令上必須とは限りません。ただし、複数のベンダーから同じ条件で提案や見積もりを受け、自社の要件に合う製品を比較する場合には有効です。

小規模な導入でRFPを簡略化する場合も、導入目的、必須要件、費用範囲、スケジュール、評価基準は文書で共有したほうがよいでしょう。

RFPは人事部門と情報システム部門のどちらが作成しますか？

業務要件は人事部門、システム構成やセキュリティ要件は情報システム部門を中心に作成するのが基本です。

さらに、費用・契約は経理や購買、個人情報の取扱いは法務・個人情報保護担当など、項目に応じて関係者が参加します。

要件はどこまで細かく書けばよいですか？

ベンダーが対応可否と費用を判断でき、提案を比較できる程度まで具体化します。

ただし、SaaSを選ぶ場合は実現方法まで固定しすぎず、達成したい業務結果と必要条件を示したうえで、標準機能や代替運用を提案してもらう方法があります。

RFPを送付する前に製品デモを受けてもよいですか？

問題ありません。RFIや製品デモで市場の標準的な機能を把握してから、RFPの要件を調整する方法もあります。

ただし、特定製品の画面や仕様をそのまま必須条件にすると、ほかの実現方法を不必要に除外する可能性があります。導入目的に必要な条件かどうかを確認しましょう。

まとめ｜RFPは要件の多さより比較できる条件と優先順位が重要

人事システムのRFPは、複数のベンダーから同じ条件で提案を受け、自社の目的に合う製品を選ぶための文書です。

作成時は、最初に現行業務、システム、データを棚卸しし、解決したい課題と対象範囲を明確にします。そのうえで、機能、非機能、セキュリティ、移行、連携、支援、費用などの要件を整理し、「必須・希望・提案希望」などの優先順位を付けましょう。

要件の数を増やすことが目的ではありません。各社が適合状況、実現方法、追加費用、制約を同じ形式で回答できるRFPにすることが、適切な比較につながります。

作成したRFPの要件と照らし合わせるために、サイレコの対応機能や料金、導入支援の内容を公式資料でご確認ください。実際の画面や運用イメージを確認したい場合は、公式サイトで案内されている14日間の無料トライアルも利用できます。

人事システムのRFPとは？書き方・必須項目・作成手順を実例付きで解説