発注側が1on1ツールのRFP（提案依頼書）と要件定義書を作るときは、目的とKPI、機能と運用、既存システムとの連携、SaaSかカスタムかの順に論点を整理します。
費用相場や製品全体像をまだ把握していない方は、まず1on1ツールの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・1on1ツールの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
導入目的とKPIを定義する要件整理
RFPの出発点は、機能を並べることではなく、なぜ1on1ツールを導入するのかを明らかにすることです。
発注側は、離職を防ぎたいのか、評価の納得感を高めたいのか、マネジメント力を底上げしたいのか、まずどれを狙うのかを決めます。
目的が曖昧なまま製品を選ぶと、導入後に効果を測れず、運用が形骸化します。
要件定義の最初の一歩は、目的とそれを測るKPIを言葉にすることです。
解決したい課題を一つに絞り込む要件定義
要件定義でありがちな失敗は、あれもこれもと目的を盛り込みすぎることです。
離職防止もエンゲージメント向上も評価連携も、すべてを狙うと要件が膨らみ、製品選定の軸がぶれてしまいます。
まずは自社にとってもっとも切実な課題を一つに絞り込み、それを中心に据えるのが現実的です。
タレントマネジメント導入では課題の発生率が62.1%にのぼるという調査もあり、欲張った要件は定着失敗の温床になります。
課題を絞り込むには、現場のマネージャーや部下にヒアリングし、今の1on1運用の何に困っているかを具体化することが有効です。
現場から出る「記録が残らず前回の続きにならない」「上司によって質に差がある」「面談が後回しにされる」といった生の声は、要件の優先順位を決める材料になります。
RFPには、最優先で解決したい課題を冒頭に明記します。
ベンダーに、その課題にどう応えるかを提案で問うと、的を射た比較ができます。
- 困りごとの書き方：場面と頻度を添えると、要件の具体性が上がる
- 冒頭の書き方：課題を一文で言い切り、各社の回答を比べる軸にする
先行指標と成果指標の設定
KPIを決めるときは、効果が表れるまでの時間軸を踏まえて、先行指標と成果指標を分けて考えることが大切です。離職率の低下やエンゲージメントの向上といった成果指標は、データが蓄積し施策が回り始めてから表れるため、半年から一年ほどかかります。
導入初期は、「面談の実施率」「記録の入力率」「サーベイの回答率」といった先行指標で進捗を測ると、運用が軌道に乗っているかを早めに判断できます。
このKPI設計をRFPに明記しておくと、ベンダーが提案するレポート機能やダッシュボードが、自社の測りたい指標に対応しているかを確認できます。先行指標を可視化できないツールでは、運用状況を把握できず、改善のサイクルも回りません。
要件定義の段階で「どの指標を、どの粒度で、どの頻度で見たいか」を決めておくことは、導入後のPDCAを支える土台になります。効果が出るまでの時間軸の考え方は、完全ガイドでも整理しています。
- 指標の粒度：どの単位で数値を見るかを、ベンダーへの要件に含めておく
- レポートの対応：提案されたダッシュボードで、決めた指標を実際に表示できるかを見る
現状の1on1運用の棚卸しと要件への反映
目的とKPIを決めたら、次に欠かせないのが現状の1on1運用の棚卸し、つまり今どう回っているかの確認です。すでに紙やExcelで面談を行っているなら、その頻度や記録方法、困りごとを洗い出します。
まだ仕組みがない場合は、現場のマネージャーが面談に何を期待し、何に不安を感じているかをヒアリングします。この現状把握が抜けると、要件が現場の実態から離れ、導入後にミスマッチを招きます。
棚卸しで見えた課題は、そのまま要件の優先順位に直結します。たとえば、「上司によって面談の質に差がある」ことが最大の課題なら、テンプレートやコーチング支援を上位の要件に据えるべきです。また、「記録が散逸している」ことが課題なら、記録の蓄積と引き継ぎを重視します。
タレントマネジメント導入では、性能より運用準備が成否を分けるとされています。だからこそ、現場の実態から逆算した要件が、形骸化しない導入の出発点になります。
- 現行の記録：面談の記録が、どの形で、どの人の手元に残っているかを確かめる
- 現場の期待：マネージャーが面談に求めることを、要件と照らし合わせる
機能要件と運用要件の整理
目的とKPIが定まったら、それを実現するための機能要件と運用要件を整理します。機能要件は「ツールに何ができてほしいか」、運用要件は「どんな体制でどう運用するか」です。
両方を区別して定義することで、製品の機能だけでなく、自社の運用準備も含めて導入の現実性を見極められます。
必須機能と任意機能の切り分け
機能要件では、面談記録・アジェンダ管理・閲覧権限制御といった基本機能を必須として定めます。一方で、パルスサーベイやテンプレート、コーチング支援のほか、評価連携も任意機能として、優先度をつけて整理します。
すべてを必須にすると候補製品が絞られすぎ、価格も跳ね上がります。そこで、RFPでは「Must（必須）」と「Want（あれば望ましい）」を明示します。
RFPでは、各要件にどこまで対応できるかをベンダーが回答できる形式にすると、横並びの比較がしやすくなります。
とくに権限管理は、1on1の本音を守る根幹なので、必須要件に含めるべきです。本人、上司、人事がそれぞれ何を見られるか、プライベートメモを分けられるかといった粒度まで要件にしておくと、導入後の認識のずれを防げます。
サーベイの分析軸や、面談履歴の引き継ぎ可否なども、自社の運用イメージに照らして必要かどうかを判断し、機能要件リストに落とし込んでいきます。要件が具体的であるほど、ベンダーの提案も具体的になります。
- 必須の候補：なくなると面談を回せない機能から、優先して選ぶ
- 任意の扱い：優先度を付けたうえで、提案の比較表に並べて見る
運用体制と担当者工数の見積もり
機能要件と同じくらい重要なのが、運用要件です。1on1ツールは導入して終わりではなく、運用ルールづくりやテンプレートの整備、サーベイ結果のモニタリングを継続して行う必要があります。現場への利用促進も、そこに含まれます。
これを誰が担うのか、専任を置くのか兼任で回すのかを要件として定めておかないと、導入後に運用が宙に浮きます。タレントマネジメント領域でも、性能より「運用準備」が成否を分けると指摘されています。
とくに兼任の人事担当者が運用する場合は、メンテナンスや利用促進にどれだけの工数を割けるかを、現実的に見積もる必要があります。さらに、現場の管理職が記録入力やサーベイ確認にどれだけ時間を取られるかも、運用要件として把握しておくべきです。
この工数を過小評価すると、「忙しくて記録が更新されず、情報が古くなる」という失敗に陥ります。これは、調査でも課題の上位に挙がっている失敗パターンです。
RFPには、ベンダーに導入支援や運用伴走の体制を問う項目も加えると、自社の弱い部分を補えます。
- 担当の分け方：運用ルール、モニタリング、利用促進を、誰が受け持つかを決める
- 工数の見積もり先：兼任の人事担当者と、現場の管理職を分けて書き出す
運用要件を整理するときは、導入直後の立ち上げ期と、安定運用に入った後の定常期で必要な工数が異なる点も意識します。立ち上げ期はテンプレートの整備や利用促進に手間がかかり、定常期はモニタリングと改善が中心になります。
それぞれのフェーズで誰がどれだけ関わるかを描いておくと、運用が一時的に重くなる時期に人を割けず頓挫する事態を避けられます。
運用要件は、静的な体制図ではなく、時間軸を伴った計画として描くことが望まれます。
既存システム連携とデータ移行の要件
1on1ツールは単独で使うこともできますが、人事情報を活かすには既存システムとの連携が鍵になります。
社員マスタや組織情報、評価・目標管理のデータ、給与・勤怠システムなどと、どうつなぐかを要件にしておくと、後の手戻りを防げます。連携要件は、RFPの中でも費用と実現性に直結する論点です。
社員マスタ・給与・勤怠とのAPI連携要件
連携要件でまず定義すべきは、社員マスタや組織情報をどう同期するかです。入社・異動・退職のたびに手作業でアカウントを更新するのは現実的ではないため、人事システムや社員データベースと連携して、組織変更を自動で反映できる仕組みが望まれます。
給与や勤怠システムとのAPI連携が必要な場合は、その開発費もコストに上乗せされる点を、要件に見込んでおく必要があります。なお、API連携の開発費の相場や、各システムが公開しているAPIの仕様は、ベンダーや製品によって異なります。
RFPには「どのシステムと、どの方向に、どの頻度でデータを連携したいか」を明記します。そのうえで、ベンダーに連携方式と概算費用を提示してもらうと、総コストを正しく比較できます。
発注側は、既製SaaSが自社の連携要件を満たせない場合に、フルスクラッチで連携を含めて作り込む選択肢も視野に入れると、長期的な拡張性を確保できます。
- 連携先の一覧：つなぐシステムを挙げ、それぞれの役割を書き添える
- 連携の方式：データを送る方向と頻度を、ベンダーに説明させる
データ移行と将来の乗り換えを見据えた要件
見落とされがちですが、既存の面談記録や過去のサーベイデータを、どう移行するかも要件に含めるべきです。これまでExcelや別ツールで運用してきた記録を、新しいツールに取り込めるかを確かめておきます。
また、どこまでの履歴を移行するかを決めておかないと、導入後に「過去の経緯が分からない」という断絶が生じます。データ移行の可否と費用は、製品によって対応に差があります。
発注側は、将来そのツールから別のツールへ乗り換える可能性も見据えて、データの取り出しやすさを要件にしておくと、後々の選択肢を残せます。
蓄積した面談記録やサーベイデータを標準的な形式で書き出せるかを確認しておかないと、特定のベンダーに縛られる「ロックイン」の状態に陥りかねません。
タレントマネジメント領域でも、乗り換え時のデータの取り出しやすさやベンダーロックインのリスクは、見落とされやすい論点です。出口戦略まで要件に織り込むことが、賢明な要件定義といえます。
- 移行する範囲：面談記録とサーベイデータを、どこまでさかのぼって移すかを決める
- 書き出しの形式：取り出しに使う形式を、提案の段階で確かめる
SaaSとカスタム開発の選定基準
要件が整理できたら、既製のSaaSで満たすのか、カスタム開発やフルスクラッチで作り込むのかを選定します。
多くの企業はまずSaaSを検討しますが、自社の評価制度や運用が独特な場合、既製品に業務を合わせる無理が生じることがあります。
RFPの段階で、SaaSとカスタムの両方を視野に入れて選定基準を持っておくことが大切です。
自社制度への適合度で見るSaaSの選定
SaaSの最大の利点は、初期費用を抑えて短期間で導入でき、保守やアップデートをベンダーに任せられる点です。要件への適合度が高ければ、コストと導入スピードの両面で合理的な選択になります。
費用は製品によって幅があり、月額1名あたり数百円から始められるものもあれば、統合型のタレントマネジメントとして初期数十万円・月額数万円規模になるものもあります。
ただし、無料プランや安価なプランからスモールスタートする場合は、利用人数の増加や機能拡張のタイミングで、上位プランへの移行制約に直面することがあります。スモールスタートからの拡張時の壁は、タレントマネジメント領域でも見落とされやすい論点です。
RFPでは、現状の要件を満たすかだけでなく、将来の拡張時にプランや費用がどう変わるかも確認し、長期の視点で選定することが重要です。無料トライアルで、実際の操作感や自社制度への適合を確かめることも欠かせません。
- 上位プランの条件：利用人数や機能を増やす時期に、移行の制約がないかを確かめる
- トライアルの確認点：操作のしやすさと、評価制度への合わせやすさを見る
カスタム・スクラッチを選ぶ判断基準
一方で、独自の評価制度や複雑な連携要件があり、既製SaaSでは業務に合わない場合は、カスタム開発やフルスクラッチが選択肢になります。自社の運用に合わせてゼロから設計できるため、現場が本当に使う仕組みを作り込めるのが利点です。
初期投資はかかりますが、ベンダーロックインを避け、既存システムとの連携を自由に設計できる点は、長期運用では大きな価値になります。
カスタムを選ぶ判断基準は、自社の1on1運用や評価制度がどれだけ独自か、既存システムとの連携がどれだけ重要か、そして長期的にデータをどう活用したいかにあります。
RFPでは、SaaSベンダーとカスタム開発ベンダーの双方に提案を求め、機能適合度と総コストを横並びで比べるのが理想です。拡張性や運用支援体制も、同じ軸で比べると判断しやすくなります。
riplaはフルスクラッチ受託の立場から、自社制度に合わせた1on1の仕組みについて、要件整理から既存システム連携を含む設計・開発までを支援します。
SaaSとカスタムのどちらが適するかの判断は、要件の独自性と将来像から逆算するのが王道です。
- 独自性の確認：評価制度や連携要件のうち、既製品に収まらない部分を洗い出す
- 将来像の整理：データを何年後にどう使いたいかを、要件と一緒に書いておく
セキュリティ・権限と非機能要件の整理
機能や連携の要件と並んで、見落とされがちながら重要なのが、セキュリティや権限、可用性といった非機能要件です。
1on1ツールは部下の機微な本音を扱うため、これらの要件を曖昧にしたまま導入すると、情報漏えいや不正閲覧といった深刻なリスクを抱えることになります。
RFPには、機能だけでなく非機能要件もきちんと盛り込むことが求められます。
閲覧権限とセキュリティの要件定義
権限要件では、本人・直属の上司・人事・経営層のそれぞれが、何を閲覧でき、何を編集できるかを細かく定義します。
本人だけのプライベートメモを分けられるか、人事が全社のサーベイ傾向だけを匿名で見られるかといった粒度まで要件にしておくと、現場が安心して本音を記録できます。
権限設計が甘いと、部下が当たり障りのない記録しか残さなくなり、1on1の価値そのものが損なわれます。
セキュリティ要件としては、通信やデータの暗号化、アクセスログの取得と監査、シングルサインオンへの対応を定義します。データの保管場所も、あわせて明記しておきます。
自社のセキュリティポリシーや業界の規制要件に照らして、満たすべき水準を明記しておくことが欠かせません。
これらの要件をRFPに盛り込めば、ベンダーがどこまで対応できるかを比べられ、後から「想定したセキュリティ水準を満たせない」という事態も避けられます。
機微情報を扱うツールだからこそ、セキュリティ要件は妥協できない論点です。
- ログの確認：誰がいつ記録を見たかを、後から追えるかを聞いておく
- 保管先の回答：データを置く場所について、ベンダーの回答を具体的に求める
可用性・サポート体制を含む非機能要件
非機能要件には、可用性やサポート体制も含めて定義します。ツールが頻繁に止まれば現場の信頼を失い、運用が続かなくなります。
サービスの稼働率やサポートの対応時間、障害時の連絡体制といった要件を明記しておくと、安定して使い続けられるかを見極められます。
導入後の運用を支えるサポートの手厚さは、製品選定で軽視されがちです。しかし、定着を左右する要素でもあります。
導入支援や運用伴走をどこまでベンダーに期待するかも要件にしておくと、自社の運用体制の弱点を補えます。初期設定の代行、テンプレートの整備支援、利用促進のノウハウ提供などを受けられるかは、とくに兼任で運用する企業にとっては確かめる価値があります。
タレントマネジメント領域では、初期設定代行やデータ移行、運用コンサルが「隠れコスト」として予算オーバーの要因になるとも指摘されています。
そのため、サポート範囲と費用を要件で明確にすることが、想定外の出費を防ぎます。riplaはフルスクラッチ受託に加え、こうした非機能要件の整理から運用伴走までを支援します。
- 障害時の対応：連絡の手順と、復旧までの見込みを、ベンダーに説明してもらう
- 費用の内訳：サポートに含まれる範囲と、別料金になる範囲を分けて提示してもらう
まとめ
1on1ツールのRFPや要件定義は、導入目的とKPIを明確にすることから始まります。続いて、機能要件と運用要件を整理し、既存システムとの連携やデータ移行を定めたうえで、SaaSとカスタム開発の選定基準へと進みます。
解決したい課題を一つに絞り、効果が表れる時間軸を踏まえて先行指標と成果指標を分けます。そのうえで、運用を誰がどれだけの工数で担うかまで言葉にしておくことが、形骸化しない導入の前提になります。
連携やデータ移行、将来の乗り換えまで要件に織り込めば、ベンダーロックインや拡張時の壁といった後悔を避けられます。
要件定義で大切なのは、製品の機能から逆算するのではなく、自社の課題と運用の現実から要件を組み立てることです。
既製SaaSが自社制度に合えばコストとスピードで合理的ですが、独自性が高ければカスタムやフルスクラッチが現場定着の近道になります。
riplaは、フルスクラッチ受託と運用伴走の立場から、要件整理やRFP作成の支援を行い、既存システム連携を含む設計・開発・定着までを一貫して支援します。
費用相場や製品比較の全体像は、あらためて完全ガイドでご確認ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。