目標管理システムの導入を本格的に進めるとき、避けて通れないのが要件定義とRFP（提案依頼書）の作成です。いきなりベンダーや製品を比較し始めても、自社が何を実現したいのかが言語化できていなければ、各社の提案を正しく評価できず、結局は営業トークの巧みさやデモの印象で選んでしまいます。要件定義書とRFPを丁寧に作り込むことが、自社の評価制度に本当に合うシステムを選び、導入後の手戻りや形骸化を防ぐ最大の保険になります。
本記事は、目標管理システムのRFP・要件定義書・提案依頼書を、発注する企業の視点から実務的に解説する「要件定義特化」の記事です。SaaSとカスタム/スクラッチの選定基準、自社の評価制度を要件に落とし込む手順、給与・勤怠連携やデータ移行といった非機能要件、そしてRFPに盛り込むべき項目と相見積もりの進め方まで、具体的に掘り下げます。読み終えるころには、自社のRFP作成の骨組みが描けるはずです。なお、目標管理システムの全体像をまだ把握していない方は、まず目標管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・目標管理システムの完全ガイド
SaaSとカスタム/スクラッチの選定基準
要件定義の出発点として、まず方式選定の軸を持つことが重要です。目標管理システムは、既製のSaaSを使うか、SaaSをカスタマイズするか、フルスクラッチで開発するかという選択肢があります。この方式の違いが費用・期間・自由度を大きく左右するため、自社の評価制度の独自性と予算に照らして、最初に方向性を定めておく必要があります。
SaaS・カスタム・スクラッチの費用と適合度
既製のSaaSは、初期費用が抑えられスピーディに導入できるのが利点です。一次データでは、人事評価・タレントマネジメント領域のSaaSは初期費用30万〜100万円未満、月額1名あたり500〜999円が相場とされています。製品ごとに見ると、カオナビは初期15〜75万円・月数万円から、HRBrainは初期20万円から・月7万円から、といった価格帯です。標準機能が自社の運用に合うなら、SaaSがもっとも合理的な選択になります。
一方で、自社の評価制度が独特で標準機能に収まらない場合は、SaaSのカスタマイズかフルスクラッチが選択肢になります。オンプレ型や独自開発では、初期数百万円から数千万円規模になり、保守も年で初期費用の10〜20%程度がかかります。費用は大きく跳ね上がりますが、自社制度に完全に合ったシステムを持てる利点があります。要件定義の段階で「標準機能で何割が満たせるか」を見極め、満たせない要件の重要度に応じて方式を選ぶことが、過剰投資も妥協も避ける鍵になります。
企業規模と料金体系を踏まえた選択
方式選定とあわせて、料金体系の選択も要件として整理しておきましょう。一次データによれば、料金体系は従量制（1ユーザー課金）、定額制（全社固定）、段階制（人数レンジ別）の3種があり、人事評価領域ではほぼ均等に分布しています。小規模企業は従量制や定額制でスモールスタート、中堅企業は段階制が最多、大企業は定額制でスケールメリットを得る傾向があります。
自社の従業員数と今後の増減見込みを踏まえ、どの料金体系がコスト効率に優れるかを要件定義で試算しておくと、提案を受けたときの比較がしやすくなります。たとえば従量制は人数が少ないうちは安くても、急成長で人数が増えると割高になることがあります。逆に定額制は小規模では割高でも、規模が大きくなれば1名あたり単価が下がります。規模別のコストシミュレーションをRFPに含めて各社に提示を求めれば、長期の総コストで比較できます。
自社の評価制度を要件に落とし込む手順
要件定義の核心は、自社の評価制度と目標管理の運用を、システムの要件として言語化することです。ここを曖昧にしたままRFPを出すと、ベンダーは自社の運用を理解できず、的外れな提案が返ってきます。現状の運用を棚卸しし、あるべき姿を描いたうえで、必要な要件を機能ごとに整理する手順を踏むことが欠かせません。
現状の運用棚卸しとToBeの設計
要件定義の最初の一歩は、現状（AsIs）の目標管理・評価運用の棚卸しです。期初に誰が何を入力し、誰がいつ承認し、期末にどう評価を集計し、それがどう昇給・賞与に反映されるか。この一連の流れを、評価者・被評価者・人事それぞれの視点で可視化します。現状を直視すると、「評価者ごとに甘辛がバラバラ」「集計に毎回数十時間かかる」といった、システム化で解決すべき課題が浮かび上がります。
次に、その課題を解消したあるべき姿（ToBe）を描きます。ここで重要なのは、現状の非効率な運用をそのままデジタル化しないことです。システム導入は評価制度そのものを見直す好機であり、ToBeを描く過程で「そもそもこの評価項目は必要か」「この承認段階は減らせないか」といった制度の問い直しが生まれます。AsIsとToBeを明確にしてから要件に落とすことが、形骸化しないシステムの土台になります。一次データでも、課題発生率は62.1%と高く、その多くが運用設計の甘さに起因しています。
機能要件への分解とMust/Wantの仕分け
ToBeが描けたら、それを実現するための機能要件に分解します。目標のツリー構造、MBO/OKRの管理、評価ワークフローの段階数、評価分布の可視化、1on1記録、ダッシュボードといった機能を、自社の運用に必要なレベルで具体化します。「評価ワークフローが必要」では曖昧で、「自己評価→一次評価→二次評価の3段階で、部門により評価者数が変わる」というレベルまで詳細に書くことで、ベンダーが正しく見積もれます。
分解した要件は、Must（必須）とWant（あると望ましい）に仕分けします。すべてを必須にすると、対応できるベンダーが限られ費用も膨らみます。一方で必須を絞りすぎると、肝心の運用が回りません。自社の評価制度の根幹に関わる要件はMust、運用を便利にする要件はWantと整理することで、提案を「必須をどれだけ満たすか」で公平に評価できます。この仕分けが、後の製品比較とコスト判断の物差しになります。
連携・移行・非機能要件の整理
機能要件と並んで見落とせないのが、連携・移行・セキュリティといった非機能要件です。これらは画面に見えにくいため要件定義で軽視されがちですが、運用が始まってから「他システムとつながらない」「移行でデータが欠落した」というトラブルに直結します。RFPの段階で明確に要件化しておくことが、後のスイッチングコストやロックインを避ける鍵になります。
給与・勤怠連携とAPI要件の定義
目標管理システムは単独では完結しません。評価結果は昇給・賞与に反映されるため給与計算システムと、従業員情報は人事管理システムやタレントマネジメントシステムと連携する必要があります。要件定義では、どのシステムと、どのデータを、どの頻度で連携するかを具体的に定義します。API連携が可能か、CSVの入出力で代替するか、リアルタイム連携か日次バッチかといった粒度まで詰めておくと、ベンダーの提案が比較しやすくなります。
連携の開発費は見積もりに大きく影響します。既存システムとのAPI連携を新規開発する場合、その費用が想定外に膨らむことがあり、これが予算オーバーの隠れた要因になります。RFPで連携対象システムの仕様を明示し、連携部分の見積もりを切り分けて提示してもらうことで、後の「言った言わない」を防げます。連携要件は、システムの寿命と運用コストを左右する重要な非機能要件です。
データ移行・セキュリティ・乗り換え要件
既存のExcelや旧システムから新システムへ移行する場合、データ移行の要件を定めておく必要があります。過去の目標・評価データをどこまで移行するか、従業員マスタの名寄せをどう行うか、移行時のデータ精度をどう担保するかを要件化します。移行範囲を欲張ると費用が膨らむため、「直近2年分の評価データのみ移行」といった割り切りも要件定義で判断します。あわせて、人事情報という機微なデータを扱うため、アクセス権限の制御や個人情報保護に関するセキュリティ要件も明記します。
意外と忘れられがちなのが、将来の乗り換えを見据えた「データの取り出しやすさ」の要件です。導入時はそのシステムを長く使うつもりでも、数年後に乗り換える可能性は常にあります。そのとき、自社のデータを標準形式で出力できないと、移行コストが膨らみベンダーロックインに陥ります。RFPに「契約終了時のデータエクスポート方法」を明記して各社に提示を求めることで、ロックインのリスクを事前に把握できます。riplaはフルスクラッチ受託の立場から、こうした連携・移行・ロックイン回避の要件整理を、自社制度の理解とあわせて支援しています。
RFPの記載項目と相見積もりの進め方
整理した要件を、ベンダーに伝わる形でまとめたものがRFP（提案依頼書）です。RFPの質が、返ってくる提案の質と比較のしやすさを決めます。何を盛り込み、どう各社に提案を求め、どう評価するかという一連の流れを設計しておくことが、納得感のある選定につながります。
RFPに盛り込むべき必須項目
RFPには、最低限以下を盛り込みます。プロジェクトの背景と目的（なぜ目標管理システムを導入するのか）、現状の課題、実現したいToBe、Must/Wantに仕分けた機能要件、連携・移行・セキュリティの非機能要件、想定する企業規模と利用人数、予算感とスケジュール、そして提案してほしい内容（機能対応表・費用内訳・導入スケジュール・サポート体制）です。とくに機能要件は、各要件に対して「標準対応／カスタマイズで対応／対応不可」を回答してもらう形式にすると、製品の適合度が一覧で比較できます。
費用については、初期費用・月額費用に加えて、初期設定代行、データ移行、運用コンサル、連携開発といった項目を分けて提示してもらいます。一次データでは、こうした「隠れコスト」が予算オーバーの主因とされています。RFPで費用の内訳を明示的に求めることで、後から想定外の追加費用が発生するリスクを減らせます。サポート体制や運用定着の支援内容も、課題発生率62.1%という実態を踏まえれば、提案を求めるべき重要項目です。
相見積もりと無料トライアルの活用
RFPは複数のベンダーに送り、相見積もりを取るのが基本です。同じRFPを複数社に提示することで、費用と提案内容を同じ土俵で比較でき、1社の言い値で決めてしまうリスクを避けられます。提案を受けたら、Must要件の充足度、費用、サポート体制、自社制度への理解度といった観点で評価表を作り、定量的に比較します。営業の印象ではなく、要件への適合という事実で選ぶことが、後悔のない選定につながります。
提案で有力な候補に絞ったら、無料トライアルや実機デモで操作性を必ず確認してください。一次データでも、課題の最上位は「操作性が悪く浸透しなかった」であり、これは現場が実際に触らないと分かりません。評価者・被評価者の双方が、自社の運用を想定して操作してみることが大切です。なお、自社の評価制度が独特で標準機能では満たせないことが見えてきた場合は、SaaSのカスタマイズやスクラッチ開発という選択肢も検討すべきです。riplaはフルスクラッチ受託と国内開発の立場から、要件定義からRFP作成、製品選定の伴走、そして自社制度に合わせたカスタム開発までを一貫して支援しています。
まとめ
目標管理システムのRFP・要件定義は、SaaSとカスタム/スクラッチの方式選定、自社の評価制度の要件への落とし込み、連携・移行・非機能要件の整理、そしてRFPの記載項目と相見積もりの設計という流れで進めます。方式と料金体系を最初に方向づけ、AsIsとToBeを描いて機能要件をMust/Wantに仕分け、連携・移行・ロックイン回避の非機能要件を明記し、費用内訳とサポート体制まで提案を求めることで、自社に本当に合うシステムを公平に選べます。
要件定義で大切なのは、「製品から考える」のではなく「自社の運用とToBeから考える」という順序です。要件を曖昧にしたまま製品を比較すると、デモの印象で選んで後悔します。一次データが示す課題発生率62.1%の多くは、この要件定義の甘さに起因します。自社の評価制度を丁寧に言語化し、隠れコストやロックインまで要件化してから選定に進んでください。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を創業。