タレントマネジメントシステムのRFP/要件定義書/提案依頼書について

タレントマネジメントシステムの発注は、自社要件の整理、RFP(提案依頼書)作成、提案比較の順に進めると、導入後の手戻りを防げます。

発注企業は、RFP・要件定義書で方式と評価制度、連携、料金の要件を整理します。全体像は完全ガイドもご覧ください。

▼全体ガイドの記事
・タレントマネジメントシステムの完全ガイド

SaaSかカスタム/スクラッチかを定める要件

標準機能で8割を賄える場合から独自開発まで、要件の区分を3枚のパネルで示した図解。
標準機能で賄える範囲が方式選定の分かれ目になります。

RFPを作る前に、既製SaaSを採用するか、自社向けにカスタム/スクラッチで構築するかを決めておきます。

方針が曖昧なままRFPを出すと、SaaSベンダーと開発会社の見積もりが集まり、比較の軸が揃わず判断に迷います。そのため、自社要件の特殊性を見極め、どちらで進めるかを先に決めることが要件定義の出発点になります。

自社要件の特殊性を見極める基準

SaaSかカスタムかは、自社の要件が標準からどれほど外れるかで判断します。一般的な評価制度や人材管理なら、既製SaaSで十分にカバーできます。既製SaaSの料金は、たとえばカオナビが初期15〜75万円・月数万円〜、タレントパレットが初期30〜55万円・月10万円〜、HRBrainが初期20万円〜・月7万円〜です。

一方、独自の複雑な評価ロジック、業界特有の人材要件、既存業務との深い結合が必要な場合は、既製ツールに業務を合わせるのが難しくなります。そのうえで、要件定義書では各要件を次の区分に仕分けます。

  • 標準機能:製品のままで満たせる要件
  • 設定・カスタマイズ:製品の設定を変えたり手を加えたりして対応する要件
  • 独自開発:既製品では対応できず、新たに作り込む要件

仕分けがあると、ベンダーは製品で対応できるかを判断しやすくなり、ミスマッチな提案も減らせます。目安としては、標準機能で8割を賄えるならSaaS、独自要件が中核ならカスタム/スクラッチです。

ロックイン回避とデータ取り出しの要件

評価履歴やスキル情報は、長年蓄積するほど価値の高いデータになります。そのため、将来の乗り換えに備えて、ベンダーロックインを避けられるよう、契約終了時のデータ取り出し条件をRFPに盛り込みます。

  • 出力形式:全データをCSVなどの汎用形式で取り出せること
  • 契約終了時の扱い:データ返却と削除の手順が明示されていること

この条件がないと、乗り換え時にデータを取り出しにくくなります。高額な移行費用やベンダーへの依存が生じるため、入口の要件定義で、長期的なコスト管理につなげます。

ポイント

SaaSかカスタムかは、要件のうち既製品の標準機能で賄える割合で判断します。大半を標準機能で賄えるならSaaS、独自要件が中核ならカスタム/スクラッチを候補にします。

自社評価制度への適合要件の定義

自社評価制度を中央に置き、評価ロジック、評価シート、権限の範囲、自社特有の評価フローを周囲に配置した図解。
評価の設計と運用ルールを一体で整理できます。

評価制度は企業ごとに哲学と仕組みが異なり、システムが合わないと現場で使われず形骸化するため、要件定義では自社の評価制度に適合する条件を丁寧に詰めます。そのうえで、RFPには自社制度の構造を具体的に書き、それをシステムでどう表現するかを要件として整理します。

評価ロジック・評価シートの要件

評価制度をシステムで再現するため、評価ロジックと評価シートの要件を次のとおり整理します。

  • 評価ロジック:方式、項目、重み付け、点数化、ランク付け
  • 評価シート:表示順、入力形式、コメント欄、職種別の使い分け

評価方式は、MBOやOKR、コンピテンシー評価などから自社に当たるものを示します。たとえば、目標達成度を5段階で評価し、行動評価との合算で総合ランクを算出する自社ロジックを記載します。

システムがロジックを正確に再現できるかが導入の成否を分けます。そのため、この要件を既製SaaSの標準評価フォーマットと照らし、自社制度に合うかを判断します。

職種や階層で評価基準が大きく異なる企業には、複数の評価シートを柔軟に設定できることが必須です。既製ツールで足りない場合は、カスタマイズやスクラッチでの作り込みを検討します。

riplaはフルスクラッチ受託の立場から、自社の評価哲学をシステムに落とし込む設計を支援しています。

権限管理・ワークフローの要件

権限管理と承認フローでは、閲覧や編集ができる人と、各段階で承認する人を決めておく必要があります。

  • 権限の範囲:役割ごとに閲覧・編集できる情報
  • 自社特有の評価フロー:一次・二次評価、評価調整会議、最終承認をシステム上で表現する方法

たとえば、人事部は全社データ、管理職は自部署のメンバー、本人は自分の情報のみを扱う設計があります。評価情報は機微なデータのため、権限の要件は慎重に詰めます。

また、ワークフローでは、自社の評価プロセスをシステム上で再現できるようにします。差し戻しや再評価、評価期間中の異動への対応も要件に含めておくと、開始後の例外処理に困らずに済みます。一方で、曖昧なままだと、リリース後に自社のフローを回せない問題が起こります。

ポイント

評価ロジックは既製SaaSの標準評価フォーマットと照らし、合わなければカスタマイズやスクラッチを検討します。権限や承認フローは、自社の評価の流れを回せるかで見極めます。

既存システム連携とデータ移行の要件

連携先と項目、連携方式、データ移行・名寄せの3項目をカードで示した図解。
連携の条件と移行するデータを分けると、見積もり範囲が明確になります。

RFPの見積もり精度を左右するのは、既存システムとの連携要件とデータ移行要件です。連携と移行の内容を具体的に書くことで、手戻りとコスト超過を防げます。

タレマネ導入で課題が発生した上位要因の一つは、「既存の人事システムと併用してデータが分散した」ことです。そのため、連携の設計を怠ると、導入後に深刻な混乱を招きます。

給与・勤怠とのAPI連携要件

連携条件は、次のとおり整理します。

  • 連携先と項目:給与計算・勤怠管理のシステム、連携対象情報
  • 連携方式:同期方向、頻度、リアルタイムかバッチか

従業員の基本情報は、どのシステムを正(マスタ)として管理し、他のシステムへ同期するかを決めておきます。API連携には開発費用がかかるため、範囲が曖昧だと見積もりが膨らみます。

連携対象システムの種類とバージョン、連携項目を要件定義書に明記します。これにより、ベンダーが工数を正確に見積もれます。

たとえば、SmartHRのように労務管理を起点に従業員データを集約する製品と連携する方法もあります。SmartHRは、初期費用とサポートが原則無料で、月額のみです。

また、既存の給与・勤怠システムは残したまま、タレマネ側に必要な情報だけを流す方法もあります。どちらを選ぶかは、自社のシステム構成によって変わります。

連携先が古くAPIを提供していない場合は、CSV連携やRPAでの自動化も代替手段として検討します。連携要件は技術的な詳細に踏み込むため、情報システム部門を交えて定義します。

データ移行・名寄せの要件

移行対象は、既存のExcelや旧システムの従業員情報と過去の評価履歴から決めます。そのうえで、表記ゆれや欠損の修正、時期と手順を定めることで、品質低下による古く不正確なデータの引継ぎを防ぎます。

複数のシステムやExcelの情報を統合する際は、社員番号や氏名の表記ゆれ、退職者と現職者の区別を踏まえて、同一人物を突き合わせます。名寄せのルールがないと、重複や混在が生じます。

移行と名寄せは見えにくい隠れコストで、予算超過の要因になりやすいため、RFPでは工数を見積もりに含めるよう求めます。

ポイント

連携とデータ移行は、範囲が曖昧だと見積もりが膨らむため、連携先と移行対象を具体的に決めます。連携先にAPIがない場合は、CSV連携やRPAも候補になります。

規模別の料金体系と予算の要件

RFPには、予算の前提と希望する料金体系を示します。料金相場は初期費用が20万〜50万円で、月額は従業員1人あたり300円〜1,000円、または月額固定5万円〜が一つの目安です。従業員規模に応じて、従量制・定額制・段階制のどれを選ぶかで、コストが変わります。

従量制・定額制・段階制の選択要件

料金体系は企業規模に応じて選び、小規模から大企業まで、人数に合う課金方法を要件に反映します。

  • 小規模(1〜99名):従量制や無料プランで始める
  • 中規模(100〜999名):段階制を検討する
  • 大企業(1,000名以上):定額制で規模拡大の利点を得る

人事評価システムの調査では、中堅企業で段階制の利用が最多です。自社の規模と人員増加の見通しを踏まえ、中長期で有利になる体系を要件に示します。

人事評価システムの課金モデル市場シェアは、定額制(全社固定)33.3%、従量制(1ユーザー)30.3%、段階制(レンジ別)28.7%です。つまり、各体系はほぼ均等に分かれ、いずれも一定の支持があります。

選ぶ際は、将来の人員規模を見据える必要があります。たとえば、従量制は小規模では安価ですが、人員が増えると割高になります。

一方、定額制は小規模では割高でも、大規模になると利点が出ます。そこで、RFPで複数の体系の見積もりを求め、成長シナリオに照らして比べます。

隠れコストと補助金を見据えた要件

予算は、月額以外の費用も含めて検討します。また、補助金の利用可否も確かめ、導入時の負担を把握します。

  • 月額外の費用:初期設定代行、データ移行、運用コンサルティング、連携開発
  • 補助金:IT導入補助金の対象可否と申請時期

こうした費用は月額料金とは別にかかり、予算超過の要因になります。月額だけで契約すると、後から積み上がって想定を超える事態につながります。そのため、RFPでは総額(TCO、総所有コスト)の見積もりを求め、月額外の費用も管理します。

IT導入補助金は、導入費用の1/2〜2/3が補助対象になる場合があります。また、利用率は中堅企業(100〜999名)で最も高くなっています。

約40%の企業が何らかの補助金を活用する一方、約4割は利用していない、または制度を知らない状態です。このため、要件定義の段階で活用の可否を確かめ、対象であれば申請を前提に日程を組むと、実質的な負担を軽減できます。

riplaはフルスクラッチ受託と国内開発の立場から、予算設計と要件整理を含めて支援しています。

ポイント

料金体系は、従業員規模と人員増加の見通しで選び、月額以外の費用も含めた総額で比べます。小規模は従量制や無料プラン、中規模は段階制、大企業は定額制が候補です。

まとめ

RFP・要件定義書の核は、方式と評価制度、連携とデータ移行、料金と予算です。まず自社要件から方式を定め、次に評価ロジックや権限、ワークフローを具体化します。

さらに、給与・勤怠との連携や、データ移行と名寄せも明確にしておきます。隠れコストや補助金を含めた総額で見積もりを求めておくことが、課題発生率62.1%という現実を避ける備えになります。

要件定義では、製品機能を並べる前に、自社の制度・業務・将来像から実現したいことを言語化します。曖昧な要件は、提案のぶれや導入後の手戻り、コスト超過につながります。

riplaは、フルスクラッチ受託と国内開発を組み合わせ、評価制度や既存システムを踏まえた要件整理を支援しています。また、ロックインを避ける設計や、補助金を見据えた予算計画にも対応します。

全体像は完全ガイドをご覧ください。

会社紹介

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

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

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

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

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

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