システム開発の委託先を選定する際、発注企業がベンダーに提示するのが「RFP(提案依頼書)」です。RFPはベンダーの提案内容を左右する重要な文書ですが「何を書けばよいかわからない」「書き方がわからない」という声も聞かれます。
本記事では、RFPの作成手順や記載項目、書き方のポイントについて解説します。
RFP(提案依頼書)とは
RFP(Request for Proposal)とは「提案依頼書」のことです。システムの開発・導入やリプレイスを検討している企業が、発注先候補となるベンダー(システム会社)に向けて作成する文書を指します。
RFPでは「どのようなシステムを・いつまでに・いくらで構築したいのか」といった要件を整理し、ベンダーはRFPの内容に基づいて提案書や見積書を作成します。
なぜRFPが必要なのか
RFPを作成する目的は、発注企業の依頼内容をベンダーに明確に提示し、自社にとって最適な提案をベンダーから引き出すことです。
RFPを作成せずに簡易的な依頼書や口頭での説明にとどめてしまうと、認識のズレや要件の抜け漏れが起こりやすくなり、ベンダーから的確な提案が受けられなくなってしまいます。
その点、RFPを作成すれば自社の現状・課題や今後の方針についてベンダーと共通認識を持てるため、システム開発や導入をスムーズに進めることが可能です。他にも、複数のベンダーの提案を比較・評価しやすくなる、認識のズレに起因したトラブルを未然に防ぐ、といったメリットもあります。
RFP作成の流れ
一般的に、RFPは以下のような流れで作成します。
1.課題の洗い出し / 開発目的の明確化
まず、現状発生している課題を洗い出し、「どの業務を・どのように改善するのか」といった開発目的を明確にします。システム化をする業務に関わる部署・担当者にヒアリングを行い、解決したい課題やシステムに期待する効果等を整理しましょう。
課題や目的を整理する際は、あらかじめ現行業務を洗い出して一覧表にまとめておくことをおすすめします。ヒアリング内容だけではなく、業務マニュアルやシステム仕様書、帳票一覧等、社内のあらゆる資料をチェックしておくと抜け漏れを防げます。
2.ベンダーの情報収集・発注先候補の選定
次に、発注先となるベンダーの情報を収集し、候補を絞り込みましょう。情報収集はベンダーへのヒアリングやRFI(Request For Information:情報提供依頼書)を通して行います。
RFIとは、発注企業がベンダーに保有技術や製品、実績等の情報提示を依頼する文書のことです。
自社と似た条件(業種、従業員数、グループ会社数)への導入実績、自社のセキュリティ方針への合致度合、欠かすことのできない機能要件への対応可否等、ベンダーの実力や信頼性をざっくり評価するための項目を記載し、回答内容に応じてRFPを配布するベンダーを絞り込みます。
▼収集情報例
【実績】※自社と似た他社への導入実績の確認
・製造業(弊社と同業)における最大規模の導入実績をご回答ください
・10社を超えるグループ会社を含む直近導入実績をご回答ください
・直近対応法改正内容と、法改正対応におけるサポート内容をご回答ください
【セキュリティ情報】※自社のセキュリティ方針におおむね合致するかの確認
・貴社の認証取得状況、定期的な外部監査実施有無についてご回答ください
・貴社の個人情報の管理、情報漏洩対策についてご回答ください
【製品情報】※現状の課題感や今後の変化等を踏まえ、欠かせない要件を抜粋して確認
・入社手続き、年末調整、給与明細を貴社システム1つに集約できますか
・グループ会社ごとに異なる権限を設定することは可能ですか
・独自の申請フローや項目をユーザー側で追加できますか
3.RFPの作成・提出
ベンダー選定が終わったら、RFPを作成・提出します。提出後は候補先に対してRFPの内容を説明するオリエンテーションを行うのが一般的です。RFPを受けてベンダーから提出される提案書や見積書を比較検討し、発注先を決定します。
選考をスムーズに進めるために、RFPを作成する段階でベンダーの評価基準を設定しておくことをおすすめします。
RFPに記載する項目・書き方
RFPの書き方に決まりはありませんが、一般的には下記3つの要素で構成されます。
・プロジェクトの概要
・提案依頼内容
・ベンダー選定の進め方
本章では、3つの基本構成に沿って具体的な記載項目を紹介します。
プロジェクトの概要
システム導入の背景や現状の課題、ゴール等、プロジェクトの全体像が把握できる情報を記載します。
<主な項目>
本書の目的 | 何のためのRFPなのか、システム導入によって目指したい姿についてを簡潔にまとめる |
依頼の背景 | システムを導入することになった背景や経緯 |
現状の課題 | システム導入によって解決したい業務上の課題 |
納期 | システムを稼働させたいタイミング 例:制度変更や現在利用しているシステムの保守期限等、確定している日付がある場合には具体的に記載する |
発注企業の会社情報 | 自社の会社概要(業種・事業内容・従業員数等) ※グループ会社も含めた導入の場合、グループ会社の情報も含む |
システムの使用者情報 | 新システムの使用者や運用管理者に関する情報 (改修やリプレイスの場合は既存システムについても記載する) |
提案依頼スコープと現行のシステム構成 | 現在使用しているシステム情報、そのうち提案依頼をする範囲 例:システム構成図、ソフトウェア、各システムの保守期限等 |
機器情報 | 現在使用しているPCやサーバー等のスペック情報 |
上記の主な項目のうち、今回はグループ会社で人事システムを統合するケースを想定した記載例をいくつかご紹介します。
簡潔にわかりやすく記載するために、箇条書きや図表を利用するのもよいでしょう。
依頼の背景
株式会社〇〇では、グループでシステム統合をし、業務を集約することで、将来的な人材・コストの適正化を実施したいと考えております。その手段として、複数会社での利用および大規模処理に耐えうるシステムを検討中です。
また、昨今の働き方改革等に起因する度重なる法令改正や社内の制度変更も必要となり、人事情報の管理やシステム面の対応において、迅速な対応ができているとは言い難い状況です。
上記の観点から、グループ全体でのシステム統合とアドオンやカスタマイズ発生の極小化により、時代の変化にスピーディに追従できる新人事システムを導入したいと考えております。
現状の課題
■業務集約
・グループ会社ごとに異なる業務システム、フローを持っており、グループ全体での業務集約がされていない
■業務効率化
・機能不足/システム外作業の発生によって業務オペレーションの負荷が高い
・入社手続き、年末調整、給与明細等のシステムがバラバラであるため連携に負荷がかかっている
■データ管理、データ利活用
・データベースが統合されておらず、情報が散在しているためグループ間での情報検索やアウトプットが困難である
・紙、Excelで管理している情報がありデータ集約ができていない
■法改正対応
・法改正のたびにシステム改修コストとリードタイムが発生しており、迅速な対応が困難である
■変化への柔軟性
・システムの改修やバージョンアップによって費用が発生する
・グループ会社の追加や制度改正等の変化に迅速に対応することが難しい
提案依頼内容
提案依頼内容には、ベンダーが作成する提案書に盛り込んで欲しい情報を記載します。
<主な項目>
ベンダーの会社情報 | ベンダーの会社概要や組織に関する情報 |
提案システムの概要・構成 | ベンダーがシステムを提案する際の情報提示の方法 例:システム構成図、機能一覧等 |
機能要件 | システムに実装して欲しい機能 |
非機能要件 | システムの拡張性、保守サポート時間・内容、インシデント対応、セキュリティ等、機能以外の要件 |
教育要件 | 新システムの担当者向けの教育・研修に関する要望 |
スケジュール | 要件定義から設計、開発、リリースまでの期間・スケジュール |
プロジェクト体制 | プロジェクトに参画するメンバーの役割や体制図 |
納品物 | 納品して欲しい作成物の一覧 例:設計書、運用マニュアル等 |
サポート体制 | システム納品後のサポート体制や緊急時の対応フロー等 |
見積もり(概算費用) | 開発費用や機器購入費用、システム保守費用等の概算費用と内訳 例:【導入費用】追加開発費用・人件費等 【保守費用】バージョンアップ費用・法改正対応費用 |
制約事項 | 現時点で判明しているシステムの制約事項 例:同時アクセス数やデータベース登録数の制限等 |
契約内容 | 著作権や機密保持、検収条件等に関する取り決めや支払方法 |
具体的な機能要件等は、下記資料をご覧ください。
ベンダー選定の進め方
各社から提案書を受領後、発注先をどのような手順および評価基準で選定するのかを記載します。
<主な項目>
選定スケジュール | 提案書の提出期限やプレゼン日程、選考結果の通知日、連絡方法等 |
提案書の提出先 | 提出先の住所、担当者氏名、連絡先 |
評価基準 | 選定において重視する評価のポイント 例:要件に対する適合性、開発実績、費用の妥当性等 |
選定スケジュール
現在の想定スケジュールは以下の通りとなります。
20XX年6月:RFP発出
20XX年7月末:提案期限
20XX年8月:比較選定、プレゼン実施
20XX年8月末:結果通知(結果は20XX年XX月XX日までにメールにてご連絡いたします。)
20XX年9月:契約
20XX年10月:導入開始
RFPを作成する際のポイント・注意点
RFPはシステム開発の指針となる重要な文書です。不足している情報や誤りがあるとベンダーの提案の精度が落ちてしまうため、適切に作成する必要があります。
本章では、RFPを作成する際に特に意識したいポイントを3つ紹介します。
幅広い関係者にヒアリングを行う
「RFP作成の流れ」でも触れましたが、RFPの作成にあたってはシステム化を行う業務の関係者にヒアリングを行い、課題やニーズを幅広く収集することが重要です。
たとえば人事システムの大規模改修を行う場合、システム部門と人事部門だけで話し合って方針を決めると、現場の使用実態にそぐわない仕様になる可能性があります。
すべての関係者にとって満足度の高いシステムを構築するために、RFPを作成する際は経営層や現システムを使用している各部署の管理職、実務担当者等、様々な立場の人から意見を募りましょう。
曖昧な表現をしない
システム開発には多くの人が関わるため、RFPは誰が見ても同じ解釈になるような明快な書き方を心がけてください。人によって解釈が変わるような曖昧な表現を使うと、意図とは異なる仕様になるリスクがあります。
不要なトラブルを招かないためにも、RFPを作成する際は形容詞的な曖昧な表現を避け、客観的な数値や指標を用いながらできる限り具体的に記載しましょう。主語や目的語がわかりづらい書き方や、社内用語の多用も要注意です。
作成後は、解釈がわかれそうな箇所や全体を通して矛盾点はないかをチェックします。発注企業の意図をベンダーが正確に理解することは、提案の精度を高めるうえでも重要です。
RFP提出後の要件の変更・追加は基本的にNG
RFPを提出後に抜け漏れが発覚して要件を追加した場合、プロジェクトの進行に大きな支障が出る可能性があります。ベンダーはRFPを基に工数や人員体制、費用を見積もったうえで提案・受注しているからです。
予定外の要件が後から追加されると、改めて工程や見積もり等を検討し直す必要があり、スケジュールの遅延や追加コストの発生にも繋がります。
微細な変更であれば影響は少ないかもしれませんが、プロジェクトの規模が大きいほど、変更の影響が広範囲におよぶことがあるため注意が必要です。基本的にRFP提出後の変更や追加の要求はできないと考え、提出前に抜け漏れがないか社内で慎重に確認しましょう。
RFPを作成して質の高い提案を引き出そう
新しいシステムの導入を成功させる鍵は、発注企業が作成するRFPにあると言っても過言ではありません。RFPはシステム開発の方向性を決める土台となるため、ベンダーからよりよい提案を引き出すためにも、自社の現状や要望をRFPに抜け漏れなく明快に記載することが肝要です。
とはいえ、RFPは記載すべき項目が多いうえ、様々な関係者の意見を考慮しながらわかりやすくまとめる必要があるため、不慣れな方は難しく感じるかもしれません。RFPの書き方がわからない場合は、実績豊富なベンダーに相談しながら作成するのも一案です。
人事領域のシステム開発や改修をご検討の企業様は、ぜひ当社にご相談ください。約1,200法人グループの人事システム導入を手がけてきた経験と知見を基に、現状調査(As-Is)や要件策定(To-Be)、機能要件一覧の作成等をご支援いたします。