人事評価システムの導入を成功させられるかどうかは、ベンダー選定の前段にある「要件定義」と「RFP（提案依頼書）」の質で、その大半が決まります。自社の評価制度や運用フローを言語化しないままベンダーに相談すると、各社からバラバラの前提で見積もりが返ってきて比較できず、導入後に「この計算ロジックは標準では再現できない」といった手戻りに直面します。逆に、要件とRFPを丁寧に整えれば、提案の質が揃い、見積もりの妥当性も判断しやすくなります。
本記事は、人事評価システムのRFP・要件定義書・提案依頼書の作り方を、発注側の視点で実務に落とし込む「要件定義特化」の解説です。要件定義で最初に固めるべき評価制度の整理、RFPに必ず盛り込むべき機能・非機能要件、SaaS導入とスクラッチ開発で異なる要件の立て方、そして見積もり比較とベンダー選定の進め方まで、一次データとあわせて具体的に解説します。読み終えるころには、自社のRFPの骨格を描けるようになるはずです。なお、費用相場や全体の進め方をまだ把握していない方は、まず人事評価システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・人事評価システムの完全ガイド
要件定義で最初に固める評価制度の整理
人事評価システムの要件定義は、機能の話から入ってはいけません。最初に固めるべきは「自社の評価制度そのもの」です。等級制度、評価項目、評価の計算ロジック、評価スケジュールといった制度の中身が言語化されていないと、どんなシステムが必要かも定まりません。要件定義の第一歩は、現行制度の棚卸しと、あるべき制度の整理です。
等級制度・評価ロジック・計算式の棚卸し
まず、自社の等級制度と評価ロジックを文書化します。何段階の等級があり、等級ごとにどんな評価項目があり、定量目標と定性評価をどんな比率で組み合わせ、最終的にどんな計算式で評価ランクが決まるのか。これらを曖昧なまま進めると、SaaSの標準機能で再現できるかの判断ができず、導入後に「うちの計算式は表現できない」という致命的なミスマッチを起こします。
特に注意すべきは、Excelに埋め込まれた複雑な計算式や、人事担当者の頭の中にある暗黙の調整ルールです。これらは制度として明文化されていないことが多く、要件定義の段階で掘り起こさないと、システム化のときに抜け落ちます。職種別に評価シートが異なる、評価軸ごとに重み付けがある、といった自社特有のロジックを洗い出し、文書として整理することが、後の手戻りを防ぐ最大の予防策になります。この棚卸しは、SaaSで足りるかスクラッチが必要かの判断材料にもなります。
現状（AsIs）と理想（ToBe）の業務フロー可視化
制度の棚卸しと並行して、評価業務の現状フロー（AsIs）を可視化します。誰がいつ評価シートを配り、どう回収し、どこで集計し、どんな調整を経て確定するのか。この一連の業務フローを図にすると、どこに無駄や手戻りがあり、システム化で何を改善すべきかが見えてきます。現状を直視せずに理想だけを描くと、現場で使われないシステムになりがちです。
そのうえで、システム導入後のあるべき業務フロー（ToBe）を描きます。この AsIs と ToBe のギャップこそが、システムに求める要件の正体です。riplaがフルスクラッチ受託の立場から一貫して重視しているのも、この「現場の業務から逆算してToBeを描く」進め方です。要件定義を機能の羅列ではなく業務フローの再設計として捉えることで、現場に定着し、かつ過剰投資にならないシステムの輪郭が見えてきます。制度と業務フローの整理は、RFPを書く前提となる最重要工程です。
RFPに盛り込むべき機能・非機能要件
制度と業務フローが整理できたら、それをRFP（提案依頼書）に落とし込みます。RFPは、ベンダーに「自社が何を求めているか」を正確に伝え、各社から比較可能な提案を引き出すための文書です。機能要件だけでなく、セキュリティや可用性といった非機能要件まで網羅することで、提案の質が揃い、見積もりの妥当性も判断しやすくなります。
評価ワークフロー・目標管理・連携の機能要件
機能要件には、自社が必要とする機能を具体的に記述します。評価シートのテンプレート設計、多段階の承認フロー、目標管理（MBO・OKR）、1on1記録、多面評価、レポート・分析といった機能を、「必須」「推奨」「任意」のように優先度を付けて整理すると、ベンダーが提案しやすくなります。優先度を付けずに全機能を必須にすると、見積もりが膨らみ、本来不要な機能にコストを払うことになります。
特に重要なのが、既存システムとの連携要件です。給与計算・勤怠管理・人事管理システムと、どのデータを、どの方向に、どんな頻度で連携するのかを明記します。API連携かCSV連携か、リアルタイムかバッチか、といった条件で連携開発の難易度と費用は大きく変わります。リサーチでも、既存の人事システムと併用してデータが分散したことが導入課題の上位に挙がっており、連携要件の精度がシステム全体の成否を左右します。曖昧なまま進めず、連携の仕様をRFPで明確に問うことが大切です。
セキュリティ・権限・可用性の非機能要件
評価情報は極めて機微な個人情報であるため、非機能要件、とりわけセキュリティと権限管理の要件は妥協できません。アクセス権限を役割ごとにどう制御するか、通信やデータの暗号化、アクセスログの保持、不正アクセス対策など、自社のセキュリティポリシーに沿った要件をRFPに明記します。これらを後回しにすると、導入後に追加対応が発生し、コストと時間を浪費します。
可用性や保守の要件も重要です。評価期に集中するアクセスに耐えられるか、障害時のサポート体制やSLA（サービス品質保証）はどうか、データのバックアップとリストアの方針はどうかを問います。クラウド型なら提供事業者の運用に依存しますが、オンプレ型やスクラッチ開発なら保守費用が年で初期費用の10〜20％程度かかるのが一般的で、この運用コストまで含めてRFPで確認することが、総保有コストを見誤らないための要点です。非機能要件をきちんと書けるかどうかが、発注側の成熟度を示します。
SaaS導入とスクラッチ開発で異なる要件の立て方
人事評価システムの実現手段は、大きくSaaS（クラウドサービス）の導入と、スクラッチ（個別開発）の二つに分かれます。どちらを選ぶかで、要件定義とRFPの立て方は大きく変わります。自社の制度の独自性と、求める柔軟性の度合いに応じて、どちらの路線で要件を組むかを早い段階で見極めることが大切です。
SaaSは「自社制度をどこまで再現できるか」を要件にする
SaaSを導入する場合、要件定義の主眼は「自社の評価制度を、その製品でどこまで再現できるか」の検証になります。SaaSは標準機能の範囲が決まっているため、独自の計算ロジックや職種別シートが標準で表現できるか、できない場合はカスタマイズ枠でどこまで対応できるかを、RFPで具体的に問います。製品の機能一覧を眺めるだけでは判断できないため、自社の実際の評価シートと計算式を提示して再現可否を確認することが重要です。
費用面では、SaaSは初期費用と月額で構成され、人事評価・タレマネ領域の相場は初期「30万〜100万円未満」が最多、月額は1名あたり「500〜999円」が最多というデータがあります。課金モデルは、定額制（全社固定）が33.3％、従量制（1ユーザー）が30.3％、段階制（レンジ別）が28.7％とほぼ均等で、自社の人数規模に応じてどのモデルが有利かを試算したうえで要件に織り込むとよいでしょう。無料トライアルで自社制度の再現を実機検証することを、RFPの選定プロセスに組み込むことをおすすめします。
スクラッチは「制度を忠実に再現する」要件を詳細に書く
評価制度の独自性が強く、SaaSでは表現しきれない場合は、スクラッチ開発が選択肢になります。この場合の要件定義は、自社の制度・計算ロジック・業務フローを、システムが忠実に再現できるよう詳細に記述することが求められます。SaaSのように既製機能に合わせるのではなく、ゼロから自社専用に作るため、要件の精度がそのまま品質と費用に直結します。
スクラッチ開発は初期費用が高く、オンプレ型なら初期数百万〜数千万円、保守も年で初期費用の10〜20％が目安となります。それでもスクラッチを選ぶ価値があるのは、評価制度を曲げずにそのままシステム化でき、将来の制度変更にも柔軟に対応できるからです。riplaはフルスクラッチ受託と国内開発の立場から、自社制度を起点に要件を詳細化し、SaaSで足りる部分とカスタムが必要な部分を切り分ける進め方を支援しています。SaaSとスクラッチのどちらに振るかは、RFPの設計段階で見極めるべき最重要の分岐点です。
見積もり比較とベンダー選定の進め方
RFPを各ベンダーに提示したら、返ってきた提案と見積もりを比較し、ベンダーを選定します。ここで判断を誤ると、安く見えた見積もりが後から膨らんだり、自社制度に合わない製品を選んでしまったりします。見積もりの構造を理解し、隠れコストまで見抜く目を持つことが、選定の精度を高めます。
初期設定・データ移行など隠れコストの見抜き方
見積もりを比較するとき、表面上の初期費用と月額だけを見てはいけません。初期設定の代行費、既存データの移行費、運用コンサルティング費といった「隠れコスト」が、予算オーバーの主因になります。RFPの段階で、これらの付帯費用を含めた総額を提示するよう求めておくと、各社の見積もりを同じ土俵で比較できます。相見積もりを取り、項目ごとに突き合わせることが、妥当性を見極める基本です。
費用負担を抑える手段として、IT導入補助金の活用も検討に値します。リサーチでは、約40％の企業が何らかの補助金を活用しており、特に中堅企業（100〜999名）でIT導入補助金の利用率が高いというデータがあります。導入費の一部が補助される可能性があるため、選定の早い段階で対象になるかを確認し、要件と見積もりに織り込んでおくと、稟議も通りやすくなります。隠れコストを見抜き、使える制度を活用する目が、賢い発注の条件です。
データ移行性・ロックイン回避を選定軸に入れる
ベンダー選定では、導入時の使い勝手だけでなく、将来の乗り換えやすさも選定軸に入れるべきです。評価データを自社の手でエクスポートできるか、他システムへ移行する際のデータの取り出しやすさはどうか、といったスイッチングコストの観点は、見落とされがちですが重要です。特定ベンダーに過度に依存するロックインのリスクを避けるためにも、データの可搬性をRFPで問うておくと安心です。
選定の最終局面では、無料トライアルや実機デモで、自社の評価制度を実際のデータで再現できるかを必ず確認します。提案書の機能一覧と、実際の使い勝手には差があるからです。riplaはフルスクラッチ受託と運用伴走の立場から、要件定義からベンダー選定、導入後の定着までを一貫して伴走し、自社制度に合うシステム化を支援しています。RFPと要件定義に時間をかけることは遠回りに見えて、結果的に最短で失敗のない導入にたどり着く道筋です。
価格以外の評価軸でベンダーを総合判断する
ベンダー選定では、価格の安さだけで決めると失敗します。自社の評価制度への適合度、導入支援や運用支援の手厚さ、サポート体制やレスポンスの速さ、人事領域の知見や実績といった、価格以外の評価軸を総合的に見ることが大切です。これらを項目ごとに点数化し、各社を横並びで比較する評価表を作ると、感覚ではなく根拠に基づいた選定ができます。
特に重視したいのが、導入後に伴走してくれるかどうかです。リサーチでも、性能より運用準備が成否を分けると指摘されており、システムを納品して終わりのベンダーより、定着まで支援してくれるベンダーのほうが、結果的に投資を成果につなげやすくなります。安さに惹かれて支援の薄いベンダーを選び、導入後に現場が使いこなせず形骸化する、というのはよくある失敗です。RFPの段階で、導入後の支援内容や体制まで提案を求め、価格と支援のバランスで総合判断することが、後悔のない選定につながります。要件定義からベンダー選定までを一気通貫で設計する姿勢が、導入成功の土台になります。
データ移行・導入体制・スケジュールの要件
機能要件と非機能要件を整理したら、見落とされがちな「移行」「体制」「スケジュール」の要件を固めます。これらは機能の話に隠れて軽視されやすいものの、導入をスムーズに進められるかどうかを左右する実務的な要件です。RFPにこれらを明記しておくと、ベンダーの提案の現実味が増し、導入後のトラブルを未然に防げます。
既存データの移行・名寄せの要件整理
新しいシステムを導入する際、過去の評価履歴や社員情報をどこまで移行するかは、要件として明確にすべき重要事項です。Excelや旧システムに蓄積された評価データを新システムへ取り込む場合、データの形式変換や、複数の台帳に分散した社員情報の名寄せが必要になります。この移行作業の難易度と工数を見積もらないまま進めると、想定外の費用と時間がかかります。
移行要件では、「何年分の評価履歴を移行するか」「どのデータを移行対象とし、どれを移行しないか」を切り分けることが大切です。すべての過去データを移行しようとすると工数が膨らむため、意思決定に本当に必要なデータに絞る判断も必要です。また、初期設定の代行費やデータ移行費は隠れコストの代表格であり、RFPでこれらの費用を明示するよう求めておくことが、予算オーバーを防ぐ要点になります。移行は導入の最初の関門であり、要件として軽視できません。
導入体制・定着支援・スケジュールの要件
導入を成功させるには、自社側の推進体制も要件として明確にしておく必要があります。誰がプロジェクトを主導し、人事・情報システム・現場の代表をどう巻き込むかを決めておかないと、要件の意思決定が滞り、導入が長引きます。あわせて、ベンダー側にどこまでの導入支援や運用支援を求めるかも、RFPに明記します。導入して終わりではなく、現場に定着するまでの支援が得られるかは、形骸化を防ぐうえで重要です。
スケジュール要件では、評価期に間に合わせる必要があるため、いつまでに稼働させたいかという期限から逆算して、要件定義・開発・データ移行・テスト・研修の各工程に必要な期間を見積もります。リサーチでも、性能より「運用準備」が成否を分けると指摘されており、研修や利用促進の期間をスケジュールに織り込むことが定着の鍵になります。riplaはフルスクラッチ受託と運用伴走の立場から、移行・体制・スケジュールまで含めた要件整理と、導入後に定着するまでの支援を一貫して行っています。これらの実務要件まで丁寧に詰めることが、要件定義を絵に描いた餅で終わらせないための仕上げになります。
まとめ
人事評価システムのRFP・要件定義を振り返ると、成否は「機能から入らず、自社の評価制度と業務フローを起点に要件を組み立てる」という一点に集約されます。等級制度・評価ロジック・計算式の棚卸しと、AsIs・ToBeの業務フロー可視化が出発点となり、それを機能要件・非機能要件としてRFPに落とし込みます。SaaSなら「自社制度をどこまで再現できるか」、スクラッチなら「制度を忠実に再現する要件」を詳細に書き分け、見積もりは隠れコストと補助金、データの可搬性まで含めて比較することが、賢い選定につながります。
RFPと要件定義に手を抜かないことが、導入後の手戻りと形骸化を防ぐ最大の保険です。自社の制度を言語化し、現場の業務から逆算してToBeを描くことから始めてください。riplaはフルスクラッチ受託と運用伴走を組み合わせ、要件定義からベンダー選定、導入後の定着までを一貫して支援します。費用相場や全体の進め方は、あらためて完全ガイドでご確認ください。
株式会社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を創業。