1. RFPの構成

RFPの書き方を解説する前に、まずはRFPに記載すべき情報の全体像を解説します。
RFPに記載する情報は、大きく「概要」「提案依頼要件」「選定の進め方」の３つに分かれています。

1.1. 概要

案件（プロジェクト）の全体像をIT企業（発注先）が理解できるよう整理した情報です。
主に以下の情報を記載します。

• 本書の目的：何のための提案依頼書なのか、本書の目的情報
• 背景：システム導入を行うことになった経営的背景などの情報
• 現在抱えている課題：現在抱えている解決したい課題情報
• プロジェクトの目的：プロジェクトの目的などの情報
• ゴール：品質、納期などの情報
• プロジェクトの範囲：システム導入の範囲（システムや調達機器、保守など）の情報
• 会社情報：会社の基本情報や組織図、システム利用者情報などの情報
• システム構成：現行の社内システムの情報
• 機器情報：現行PCやサーバなどの機器情報

1.2. 提案依頼内容

具体的にこういう情報を盛込んで提案書を作って下さいという情報です。「導入事例には必ず導入した企業の業種と規模を明記して下さい」など提案書に記載してもらう際の要件も掲載します。

• 会社組織情報（貴社情報）
• 提案システム概要
• システム構成
• プロジェクトスケジュール
• プロジェクト体制図
• プロジェクトマネジメント方法
• プロジェクトの進め方
• 運用保守内容
• サービスレベル
• 納品物一覧
• ドキュメントサンプル
• 概算費用
• 制約事項
• 導入事例
• 契約内容

1.3. 選考の進め方

どのように選定を進めるのかその情報を記載します。

• 選定スケジュール：提案書の提出期限、プレゼン日程、選考結果の連絡日などの情報
• 提案書提出先：担当者の氏名およびメールアドレスなど連絡先情報
• 評価方針：評価する際に重要視するポイント

ここではRFPに記載すべき情報について全体像を理解できるよう解説しました。思ったより情報が多くて大変そう…と感じた方も多いのではないでしょうか。
RFPは、簡易的なものでも5,000字程度のボリュームになります。作成期間も数日は必要となるでしょう。

しかし、RFPは数百万数千万というIT投資を成功させるために絶対作成すべき物です。
覚悟を決めてしっかり作成して下さい。IT投資を成功させる事が担当者の責務です。

2. RFPの書き方

ここからは、ITの専門知識を持たない方でもRFPの書き方を理解できるようにとことん優しく解説します。
※例に掲載している会社名やプロジェクト内容は架空のものです。

2.1. 概要

表紙

自社の会社名、システム名またはプロジェクト名としっかり「提案依頼書（RFP）」と記載しましょう。また、表紙の下部に何のための提案依頼書なのか記載しましょう。

本書の目的

ここに記載する情報は下図のような「定型文」になります。特に注意点はありませんので下図を参考に書いてみて下さい。

プロジェクトの背景

なぜこのプロジェクトを行うことになったのかその背景が分かるよう数行で記載します。長くなるようでしたら箇条書きにすると伝わりやすくなります。

現在抱えている主な課題

現在抱えている主な課題について記載します。長い文章になると伝わりにくくなるため、業務別や機能別に箇条書きにすると良いでしょう。Excelなどで細かい課題一覧を作成しておいて、別紙参照という形でも良いでしょう。

プロジェクトの目的

ここでは、何のためにプロジェクトを行うのか「明確な目的」を記載します。明確な目的を達成する手段として、「倉庫システムとの自動連携が必要」など分かっている事があればしっかり記載しましょう。

プロジェクトのゴール

プロジェクトのゴールは、「品質（Quality）」「費用（Cost）」「Delivery（納期）」ごとになるべく定量的なものを設定すると良いでしょう。プロジェクトのゴールは、プロジェクト終了後にプロジェクトの成果を評価する際にも使用します。定量的でないと評価が難しくなりますのでなるべく定量的なものを設定しましょう。ただし、定量的にする事が難しいものもありますので「なるべく」で大丈夫です。

費用については自社の予算を記載しないよう注意しましょう。
「初期費用1,000万円以内」など、自社の予算を明記すべきと解説している記事もありますが、私はRFPに自社の予算を書く必要はないと考えています。RFPに予算を書くと、もっと費用を抑えられるのにその予算に合せて提案を持ってこられますので注意が必要です。

プロジェクトの範囲

プロジェクトの範囲には、提案を依頼したい範囲を記載します。システム開発だけで良いのか、必要なIT機器の購入までやってもらいたいのかによって、提案してもらう範囲が異なりますのでしっかり明記しましょう。箇条書きでＯＫです。

プロジェクト方針

プロジェクト方針は、オンプレやSaaS型などのシステム構成や実現したい機能、ハードウェア構成などを記載します。提案依頼先に伝えたい要件は全て書きましょう。

会社情報

・基本情報
業種、取扱商品、年商、社員数、販売形態などの情報を記載します。自社の会社パンフレットがあれば、会社パンフレットを添付しても良いでしょう。

・組織図
システム上での権限管理や組織階層の管理が必要なケースがあるため、組織図情報も掲載しましょう。組織図がないようでしたら、箇条書きで部門名と部門情報を書いてもＯＫです。

・商品取扱数量（※小売や卸業の場合に掲載）
販売数量、在庫数量、品番数、SKU数などを記載します。小規模企業向け製品になると、品番数が多くなるとパフォーマンスが極端に悪化する製品もありますのでしっかり商品取扱数量を明記して「規模感」を教えましょう。

・店舗数
ブランドや屋号別に店舗数を記載します。箇条書きレベルで大丈夫です。全国展開している企業でしたら地区別にも店舗数を記載しましょう。地区によって店舗への機器設置費用が異なるケースがあり、見積費用が変わってくる可能性があります。

・システム利用者情報
システムを使用する使用者情報を記載します。ここでは本社の全部門にまとめていますが、一部の部門のみで使われるシステムであれば、対象部門名と利用者数を記載しましょう。

システム構成

現行システムの構成図と各システムとのデータ連携方法、システムパッケージ名などを記載します。システム構成図の作成が難しい場合、最低限使っているシステムパッケージ名を箇条書きで書くようにしましょう。

現行機器の構成

現行機器の構成にはには、社内で使用しているPCやサーバなど種類別に記載します。最低限PCの台数とスペックは書きましょう。システムによって推奨スペックが異なるため、場合によっては社内PCを入替なければならない可能性があります。しっかり明記しましょう。

2.2. 提案依頼内容

提案依頼内容に記載する情報は、具体的にこういう情報を盛込んで提案書を作って下さいという情報です。「導入事例には必ず導入した企業の業種と規模を明記して下さい」など提案書に記載してもらう際の要件も掲載します。

会社・組織情報

選定の際、会社の年商や従業員数などの規模や得意な業界・業種を見るのも重要な要素です。人数が少ない企業は、トラブル時のサポートが低くなりますし、自社と同じ業界の経験がない企業はシステム導入後に業務とシステムがマッチしないケースが発生する可能性が高くなります。しっかり会社・組織情報を提示してもらう必要があります。

提案システム概要

ここでは、提案してもらうシステムについて、どのような形で情報を提示してもらうかを指定します。IT的で書くのが難しければ下図をそのまま記載してしまっても大丈夫です。

システム構成

ここでは、提案してもらうシステムの構成について、どのような形で情報を提示してもらうかを指定します。IT的で書くのが難しければ下図をそのまま記載してしまっても大丈夫です。

プロジェクトスケジュール

プロジェクトスケジュールについては、週または月単位で全体像が見えるものを明示してもらいましょう。また、IT企業側のタスクだけでなく、自社で発生するタスクについても明示してもらう点がポイントです。

プロジェクト体制図

ここではプロジェクト体制とプロジェクトマネージャーの経歴を明示してもらいましょう。プロジェクト体制も大切ですが、それ以上にプロジェクトマネージャーの経歴の方が大切かもしれません。システム導入が成功するかどうかは様々な要素が関係しますが、プロジェクトマネージャーの手腕によると言っても過言ではありません。どちらも必ず明示してもらいましょう。

プロジェクトマネジメント方法

プロジェクトマネジメント方法と言っても、IT担当者がいない企業ではぴんとこないかもしれませんが、しっかりしたIT企業であれば会社でプロジェクトマネジメント方法が定められており、提案時に明示してくれます。明示されたプロジェクトマネジメント方法の中身も大事ですが、IT担当者がいない企業はまず「明示されるか」で評価しても良いでしょう。

会議体一覧

プロジェクトを進める上で発生する会議体を明示してもらうことで、プロジェクトに費やさなければならない時間が分かってきます。忘れず明示してもらいましょう。

サポート体制・運用体制・SLA

販売管理システムのような重要なシステムに障害が起こると最悪業務が止まってしまいます。そのような時にどのような対応をしてもらえるのかしっかり確認しましょう。

納品物一覧

納品物を予め明示してもらう事は非常に大切です。明確に定めておかないと、システムのマニュアルすら納品しない業者もいますのでしっかり明示してもらいましょう。あらかじめ納品してもらいたいドキュメントなどが決まっているのであればRFPに記載しても良いでしょう。

ドキュメントサンプル

納品物一覧を明示してもらうだけではまだまだ不十分です。納品物一覧で定められているものの、納品されてみるとまったく使えないドキュメントレベルだったという事も多くあります。そのような事態を防ぐためにあらかじめサンプルを提示してもらい納品物の品質を見ておくと良いでしょう。

概算費用

概算費用は、イニシャル費用（初期費用）とランニング費用（月額運用費用）別に明示してもらいましょう。それぞれ「内訳」を明確にしてもらう事がポイントです。内訳がない合計額だけだと費用の妥当性が判断できません。費用の妥当性が判断できなければ費用交渉も難しくなりますのでしっかり内訳まで明示してもらいましょう。

制約事項

制約事項を明示してもらう事も忘れてはなりません。例えば、製品によっては社員を2,000名までしか登録できない、商品マスタを100,000行までしか登録できないなど「制約」がある事があります。このような「制約」が、稼動直前に見つかると追加費用の発生やスケジュール遅延、最悪システムの再選定になりかねません。必ず明示してもらいましょう。

導入事例

同じ業種や同じ業種でかつ企業規模が近い企業に導入実績がある会社は評価ポイントが高くなります。逆に同じ業種や自社に近い企業への導入実績がない（少ない）企業は評価ポイントが低くなります。しっかり導入事例も明示してもらいましょう。

契約内容

契約内容と支払方法についてもしっかり明示してもらいましょう。規模が大きい企業であれば全て納品後の後払いにできる事もめずらしくありませんが、小規模企業であったり負債が多い会社は着手金が必要であったりリース契約できなかったりと制約が発生する可能性があります。しっかり明示してもらいましょう。

2.3. 選考の進め方

選考スケジュール

選考スケジュールについては、こちらが期待しているスケジュールを記載すれば大丈夫です。提案依頼後に多くの企業から選考スケジュール見直しが出た場合は再検討して下さい。通常、提案依頼書を配布してから提出期限まで2週間は必要です。大規模システムであればもっと掛かる事もあります。

提案書提出先

誰に、いつ、どのような方法で提案書を提出すれば良いのか記載します。

提案評価とその後について

選定時にどのような事を重視して評価するのかそのポイントを記載します。必ずしも書く必要はありませんが評価ポイントが分かっていればよりこちらの意図に沿った提案をもらえる可能性が高くなります。例えば「価格重視」と分かっていて足元を見て高い見積りを持ってくるIT企業はあまりいないでしょう。自社が重視する評価ポイントを記載して下さい。