提案依頼書とは
提案依頼書は「RFP（Request For Proposal）」ともいい、発注企業が受託企業に対し、提案して欲しい内容を記載した資料です。
受注側の企業は、提案依頼書をもとに、提案書を作成します。
ただ、発注する側として、いくつかの疑問があるのではないでしょうか？
「なぜ、お金を払う側の企業が説明資料を作らないといけないのか」
しかし、提案依頼書の作成は、発注側と受注側の双方にメリットがあります。
提案依頼書を作らないでプロジェクトを進めると、次のような弊害が生まれてしまいます。
提案依頼書を作成しないとどうなる？
発注側のデメリット
提案して欲しい内容をあらかじめ明確化しておかないと、発注企業の中で内容の認識の違いが出てくることがあります。
また、チーム全員が内容について共有しきれていないと、プロジェクト途中での抜け漏れの原因にもなります。
受注側のデメリット
内容によっては複雑化するプロジェクトにおいて、全ての要件を口頭で把握することは、非常にリスクが高くなります。
また、実際に作業するプログラマーに誤った情報が伝わってしまえば、内部の混乱は避けられません。
このように、それぞれの立場で不具合が生じる可能性を防ぐためにも、提案依頼書の形でまとめておくのが最善だといえるでしょう。
提案依頼書（RFP）の作成例
では、提案依頼書にはどのような事項を盛り込めばいいのでしょうか。
提案依頼書に盛り込む内容は、プロジェクトの案件や規模、予算によって様々ですが、
今回は基本的に必要とされる項目を紹介します。
あくまでも一例ですので、
プロジェクト内容によっては下記に挙げた事項以外にも記載すべき項目が出てくる場合があります。
提案依頼書の内容をきちんとチーム内で精査し、意思統一をした上で、発注先に提示するようにしましょう。
１．RFPの構成
RFPの書き方を解説する前に、まずはRFPに記載すべき情報の全体像を解説します。
RFPに記載する情報は、大きく「概要」「提案依頼要件」「選定の進め方」の３つに分かれています。
１．１．概要
案件（プロジェクト）の全体像をIT企業（発注先）が理解できるよう整理した情報です。
主に以下の情報を記載します。
・本書の目的：何のための提案依頼書なのか、本書の目的情報
・背景：システム導入を行うことになった経営的背景などの情報
・現在抱えている課題：現在抱えている解決したい課題情報
・プロジェクトの目的：プロジェクトの目的などの情報
・ゴール：品質、納期などの情報
・プロジェクトの範囲：システム導入の範囲（システムや調達機器、保守など）の情報
・会社情報：会社の基本情報や組織図、システム利用者情報などの情報
・システム構成：現行の社内システムの情報
・機器情報：現行PCやサーバなどの機器情報
１．２．提案依頼内容
具体的にこういう情報を盛込んで提案書を作って下さいという情報です。
「導入事例には必ず導入した企業の業種と規模を明記して下さい」など提案書に記載してもらう際の要件も掲載します。
・会社組織情報（貴社情報）
・提案システム概要
・システム構成
・プロジェクトスケジュール
・プロジェクト体制図
・プロジェクトマネジメント方法
・プロジェクトの進め方
・運用保守内容
・サービスレベル
・納品物一覧
・ドキュメントサンプル
・概算費用
・制約事項
・導入事例
・契約内容
１．３．選考の進め方
どのように選定を進めるのかその情報を記載します。
・選定スケジュール：提案書の提出期限、プレゼン日程、選考結果の連絡日などの情報
・提案書提出先：担当者の氏名およびメールアドレスなど連絡先情報
・評価方針：評価する際に重要視するポイント
RFPは、簡易的なものでも5,000字程度のボリュームになります。作成期間も数日は必要となるでしょう。
しかし、RFPは数百万数千万というIT投資を成功させるために絶対作成すべき物です。
担当者としては、IT投資を成功させる事が最大の目的となり、大きな責務となります。
２．RFPの書き方
２．１．概要
表紙
自社の会社名、システム名またはプロジェクト名としっかり「提案依頼書（RFP）」と記載しましょう。
また、表紙の下部に何のための提案依頼書なのか記載しましょう。
本書の目的
本書の目的を簡素に記載しておけば問題ありません。
プロジェクトの背景
なぜこのプロジェクトを行うことになったのかその背景が分かるよう数行で記載します。
箇条書きにすると伝わりやすくなります。
現在抱えている主な課題
現在抱えている主な課題について記載します。
長い文章になると伝わりにくくなるため、業務別や機能別に箇条書きにすると良いでしょう。
Excelなどで細かい課題一覧を作成しておいて、別紙参照という形でも良いでしょう。
プロジェクトの目的
ここでは、何のためにプロジェクトを行うのか「明確な目的」を記載します。
明確な目的を達成する手段として、「倉庫システムとの自動連携が必要」など分かっている事があればしっかり記載しましょう。
プロジェクトのゴール
プロジェクトのゴールは、「品質（Quality）」「費用（Cost）」「Delivery（納期）」ごとになるべく定量的なものを設定すると良いでしょう。
プロジェクトのゴールは、プロジェクト終了後にプロジェクトの成果を評価する際にも使用します。
定量的でないと評価が難しくなりますのでなるべく定量的なものを設定しましょう。
プロジェクトの範囲
プロジェクトの範囲には、提案を依頼したい範囲を記載します。
システム開発だけで良いのか、必要なIT機器の購入までやってもらいたいのかによって、提案してもらう範囲が異なりますのでしっかり明記しましょう。
プロジェクト方針
プロジェクト方針は、オンプレやSaaS型などのシステム構成や実現したい機能、ハードウェア構成などを記載します。
提案依頼先に伝えたい要件は全て書きましょう。
会社情報
・基本情報
業種、取扱商品、年商、社員数、販売形態などの情報を記載します。
自社の会社パンフレットがあれば、会社パンフレットを添付しても良いでしょう。
・組織図
システム上での権限管理や組織階層の管理が必要なケースがあるため、組織図情報も掲載しましょう。
組織図がないようでしたら、箇条書きで部門名と部門情報を書いても大丈夫です。
・商品取扱数量（※小売や卸業の場合に掲載）
販売数量、在庫数量、品番数、SKU数などを記載します。
小規模企業向け製品になると、品番数が多くなるとパフォーマンスが極端に悪化する製品もありますのでしっかり商品取扱数量を明記して「規模感」を教えましょう。
・店舗数
ブランドや屋号別に店舗数を記載します。
箇条書きレベルで問題ないでしょう。
全国展開している企業でしたら地区別にも店舗数を記載しましょう。
地区によって店舗への機器設置費用が異なるケースがあり、見積費用が変わってくる可能性があります。
・システム利用者情報
システムを使用する使用者情報を記載します。
一部の部門のみで使われるシステムであれば、対象部門名と利用者数を記載しましょう。
システム構成
現行システムの構成図と各システムとのデータ連携方法、システムパッケージ名などを記載します。
システム構成図の作成が難しい場合、最低限使っているシステムパッケージ名を箇条書きで書くようにしましょう。
現行機器の構成
現行機器の構成にはには、社内で使用しているPCやサーバなど種類別に記載します。
最低限PCの台数とスペックは書きましょう。
システムによって推奨スペックが異なるため、場合によっては社内PCを入替なければならない可能性があります。
しっかり明記しましょう。
２．２．提案依頼内容
提案依頼内容に記載する情報は、具体的にこういう情報を盛込んで提案書を作って下さいという情報です。
「導入事例には必ず導入した企業の業種と規模を明記して下さい」など提案書に記載してもらう際の要件も掲載します。
会社・組織情報
選定の際、会社の年商や従業員数などの規模や得意な業界・業種を見るのも重要な要素です。
人数が少ない企業は、トラブル時のサポートが低くなりますし、自社と同じ業界の経験がない企業はシステム導入後に業務とシステムがマッチしないケースが発生する可能性が高くなります。
しっかり会社・組織情報を提示してもらう必要があります。
提案システム概要
提案してもらうシステムについて、どのような形で情報を提示してもらうかを指定します。
システム構成
提案してもらうシステムの構成について、どのような形で情報を提示してもらうかを指定します。
プロジェクトスケジュール
プロジェクトスケジュールについては、週または月単位で全体像が見えるものを明示してもらいましょう。
また、IT企業側のタスクだけでなく、自社で発生するタスクについても明示してもらう点がポイントです。
プロジェクト体制図
ここではプロジェクト体制とプロジェクトマネージャーの経歴を明示してもらいましょう。
プロジェクト体制も大切ですが、それ以上にプロジェクトマネージャーの経歴の方が大切かもしれません。
システム導入が成功するかどうかは様々な要素が関係しますが、プロジェクトマネージャーの手腕によると言っても過言ではありません。
どちらも必ず明示してもらいましょう。
プロジェクトマネジメント方法
プロジェクトマネジメント方法と言っても、IT担当者がいない企業ではぴんとこないかもしれませんが、しっかりしたIT企業であれば会社でプロジェクト
マネジメント方法が定められており、提案時に明示してくれます。
明示されたプロジェクトマネジメント方法の中身も大事ですが、IT担当者がいない企業はまず「明示されるか」で評価しても良いでしょう。
会議体一覧
プロジェクトを進める上で発生する会議体を明示してもらうことで、プロジェクトに費やさなければならない時間が分かってきます。
サポート体制・運用体制・SLA
販売管理システムのような重要なシステムに障害が起こると最悪業務が止まってしまいます。
そのような時にどのような対応をしてもらえるのかしっかり確認しましょう。
納品物一覧
納品物を予め明示してもらう事は非常に大切です。
明確に定めておかないと、システムのマニュアルすら納品しない業者もいますのでしっかり明示してもらいましょう。
あらかじめ納品してもらいたいドキュメントなどが決まっているのであればRFPに記載しても良いでしょう。
ドキュメントサンプル
納品物一覧を明示してもらうだけではまだまだ不十分です。
納品物一覧で定められているものの、納品されてみるとまったく使えないドキュメントレベルだったという事も多くあります。
そのような事態を防ぐためにあらかじめサンプルを提示してもらい納品物の品質を見ておくと良いでしょう。
概算費用
概算費用は、イニシャル費用（初期費用）とランニング費用（月額運用費用）別に明示してもらいましょう。
それぞれ「内訳」を明確にしてもらう事がポイントです。内訳がない合計額だけだと費用の妥当性が判断できません。
費用の妥当性が判断できなければ費用交渉も難しくなりますのでしっかり内訳まで明示してもらいましょう。
制約事項
制約事項を明示してもらう事も忘れてはなりません。
このような「制約」が、稼動直前に見つかると追加費用の発生やスケジュール遅延、最悪システムの再選定になりかねません。
導入事例
同じ業種や同じ業種でかつ企業規模が近い企業に導入実績がある会社は評価ポイントが高くなります。
逆に同じ業種や自社に近い企業への導入実績がない（少ない）企業は評価ポイントが低くなります。
契約内容
契約内容と支払方法についてもしっかり明記します。
規模が大きい企業であれば全て納品後の後払いにできる事もめずらしくありませんが、小規模企業であったり負債が多い会社は着手金が必要であったり
リース契約できなかったりと制約が発生する可能性があります。
２．３．選考の進め方
選考スケジュール
選考スケジュールについては、こちらが期待しているスケジュールを記載すれば大丈夫です。
提案依頼後に多くの企業から選考スケジュール見直しが出た場合は再検討して下さい。
通常、提案依頼書を配布してから提出期限まで2週間は必要です。大
提案書提出先
誰に、いつ、どのような方法で提案書を提出すれば良いのか記載します。
提案評価とその後について
選定時にどのような事を重視して評価するのかそのポイントを記載します。
必ずしも書く必要はありませんが評価ポイントが分かっていればよりこちらの意図に沿った提案をもらえる可能性が高くなります。
自社が重視する評価ポイントを記載して下さい。
３．まとめ
この記事では、ITの専門知識を持たない人でもRFPの書き方を理解し、RFPを書けるようRFPの書き方について徹底的に優しく解説してきました。
RFPの書き方について理解が進んだのではないでしょうか。
RFPはシステム導入を成功させるための第一歩です。
RFPを書かないことは、成功を最初から捨てているに等しくなります。
システム選定の際は、必ずRFPを作成することが、システム導入の成功への近道となり、
必須であると考えた方が良いでしょう。
RFP・要件定義に関するおススメ書籍
