ベンダーとの交渉② 【 RFPの作り方 ・サンプル】

どうも、木谷です

今回はRFPの作り方について見ていきましょう！

RFPの枠組み

まずは、フォーマットから固めていきましょう

ちなみに、RFPって何？ ベンダー交渉にはどうしたらいい？ って方はこちらをお読みください！

ベンダーとの交渉① 【 はじめにやっておくべきこと 】どうも、木谷です では、さっそくベンダーとの交渉編にいきましょう！ RFPを書く 〜 プロジェクト前に 〜 では、企画の段階が...

では、以下の３ステップでRFPの枠組みを作っていきましょう

1. 情報を集める
2. 要求事項・自社紹介・契約条件の３つに分類
3. 構成を考える

それぞれご説明しますね！

① ベンダーがほしい情報を集める

RFPの目的をあらためて確認しましょう

つまりベンダーが知りたいことをまとめることになります

ではベンダーはどんな情報を求めているのでしょうか？

• 背景（なぜするのか）
• 目的（何をしたいか）
• 現状の問題点など
• 全体の流れ（導入先と関連する業務などのフロー）
• 短期または長期の事業計画（会社の方針）
• 担当人員
• 契約条件（予算・期間などから細かい所まで）

この７つの情報さえ盛り込めば、基本的に大丈夫です

詳しい分類については、実際にRFPを作成する場面でみていきましょう

② 情報を３つに分類する

では、先ほど得た情報を要求事項・自己紹介・契約条件に分類します

特に、自己紹介と契約条件のところは一度自社のフォーマットをつくってしまえば、それ以降ほとんど変えるる必要がない部分になるので、最初のIT導入なら踏ん張りどころと思ってがんばりましょう

要求事項

こちらの要求事項は、目的・課題・要件機能・スケジュールなどを盛り込みます

ただ、ずばり「IT導入企画書」とまったく同じ内容になります

なので、今回新しく作るべきことはなにもありません

自社紹介

やはりベンダーとしても相手の企業がなにをしているかを把握していたほうが、より的確なアドバイスがしやすいのです

自社の紹介をしっかり行うことは、自社のためにもなるのです

「ITベンダーはそれほど自社のことに興味はないだろう」という風に考えずに、ぜひ積極的にベンダーに自社のことを伝えていきましょう

具体的にどのようなものかというと、

• 事業内容
• 組織構成
• 業務フロー
• 現状システムの概要（あれば）

以上の４つになります

契約条件

契約については、特にベンダーと揉めないためにつくっておくべきものです

• 検収条件
• 瑕疵担保責任
• 著作権
• 損害賠償金
• 個別契約の区切り方

以上５つがあればよいでしょう

③ 構成を考える

まず大前提として、RFPは「本編＋別紙」の２部で構成します

そして、なんといってもRFPでITベンダーから適切な提案を引き出すことができればよいのです

ここで覚えておくべきことが有ります

本編のほうは枚数をできるだけ少なくしてベンダーが読みやすいようにし、別紙で必要な情報をとにかくまとめます

本編のほうで情報をすべて書こうとすると、かなりの枚数になってしまいます

量が大きすぎると関係者が目を通してくれなくなるので、お互いにとってデメリットになります

別紙ではプロジェクトの固有部分を表現します

RFP本編で書く内容

RFPの本編と別紙の目次さえ決めてしまえば、あとはスムーズにいくはずでしょう

1	はじめに	守秘義務の提示が目的です。 RFPでは自社の事業内容をさらけだすため、競合他社に流出することのないように約束事を書きます。
2	システム再構築の概要	企画書の内容をコピーしましょう。
3	現行システム概要	RFP本編に現行システムの詳細を描く必要はありません。 「別紙をご覧ください」と簡潔に終わらせましょう。
4-1	要求機能一覧	こちらも「別紙をご覧ください」と簡潔に終わらせましょう。
4-2	前提条件	企画書の内容をコピーしましょう。
4-3	新システムの利用者	利用者だけでなく、利用人数も入れましょう。 完成品の性能に大きく影響する場合があります。
4-4	システム構成	ベンダーから最適な提案を引き出すため、自社からは仕様ではなく要望にとどめます。 クラウドやスマホ活用などの要望があればここに記載します。 なお、社内で標準ブラウザが定められている場合は必ず明記しましょう。 他にも導入システムに関わる社内で決まっているものがあればIT部門と相談して記しておきましょう。
4-5	品質・性能条件	品質と性能について、明確に提案を要求します。 ただし、「システム品質保証基準」と内容が重複するためここでは詳細は記しません。
4-6	運用条件	この項目はRFP本編で重要な項目となります。 「利用時間」は、常に稼働しないといけないシステムの場合は「原則として３６５日２４時間稼働」を明記します。 また「データの保持期間」を業務上１年前まで遡る必要があれば「１３ヶ月保持」を明記します。
4-7	納品条件とスケジュール	スケジュールも大事な項目です。 企画書からのコピーもしくは、「別紙参照」のどちらでも構いません。
4-8	納品条件	納品物は必ず指定します。 ベンダーは必要に迫られない限り自らの工程を圧迫する納品物を積極的に作ることはありません。 「設計書」や「操作説明書」は当然ですが、「テスト結果報告書」や「システム品質報告書」等はこだわりたい部分です。 事前に納品物として要求することで、ベンダーにしっかりテストを行うことを暗黙的に伝えます。
4-9	定例報告およびレビュー	「進捗報告会」や「レビュー」、「工程終了判定会」はプロジェクト管理において必要な会議体であり、RFPに明記します。 ベンダーと契約後に申請しても「契約外です」と断られることもあります。 特に「工程終了判定会」はきちんと実施されているプロジェクトは少ないですが、厳しい品質が求められるシステムであれば必ず盛り込むべきです。
4-10	開発推進体制	提案書にベンダーの開発体制を明記するよう依頼します。 お約束の文言であり、サンプルをそのままコピーして問題ありません。
4-11	開発管理・手法・言語	具体的な開発方法については、細かい指定はせずにベンダーの提案を依頼します。なお、将来的な保守べンダーチェンジを考慮し、開発言語は 「一般的なものを希望」と添えておきます。
4-12	移行方法	データ移行はベンダーの見積りに直接影響するため、明記します。マスターデータやトランザクションデータの移行有無、アプリケーションの移行、移行制約など、システムや業務の特性に応じて記載します。 また、現行システムと新システムの「並行稼働」要件がある場合は、ここに明記します。特に失敗が許されないシステムの場合は、リスク対策として並行稼働は極めて有効な手段です。
4-13	教育訓練	教育訓練は大きく「業務」と「システム」に分かれます。「業務」に関する教育は自社が自ら行わなければなりませんが、「システム」のマニュアル作りや研修はベンダーに依頼できます。プロジェクト後半にお いて、自社は極めて多忙であり、ベンダーと分担することで自社の負担が軽減できます。
4-14	保守条件	保守はベンダーごとに違いが出にくい部分です。組かく指定せずに、ベンダーの提案を期待する姿勢で同題ありません。
4-15	費用見積	ベンダーごとに見積もりルールやフォーマットが異なるため、ひとまずは細かく指定しなくても問題ありません。
4-16	貴社情報	大半は形式的なものですが、唯一重要な項目は「導入実績」です。求める分野の「システム構築経験」があるかどうか、これはシステムの品質に直接関わります。ベンダー選定の判断材料として、実績は必須項目です。
5-1	提案手続き・スケジュール	提案の手続きとスケジュールを提示します。日付以外は毎回固定文言です。
5-2	低廉依頼書に対する対応窓口	プロジェクトの連絡先を提示します。一般的にはプロジェクトマネージャーまたはブロジェクトリーダーが窓口となります。
6	開発に関する条件	作業場所やPCの準備などは企業によって異なります。自社としての条件を設定します。
7-1	システム品質保証基準	高性能が要求されるシステムにおいては、画面やバッチ処理の基準を明記します。特にこだわりがないとしても「画面のレスポンスタイム」だけは必ず指定します。どんなに完壁な仕様でバグがなく動いていたと しても、「画面を開くまでに30秒かかる」では話になりません。「画面は3秒以内」は固定文言と言えるかもしれません。
7-2	セキュリティ	セキュリティはどこのベンダーもしっかり対応するようになったため、ベンダーに提案を求める姿勢で問題ありません。
8-1	発注者	一般的にはプロジェクトオーナーを記載します。
8-2	発注形態	フェーズの区切りと発注形態を提示します
8-3	検収	形式的な文言であり、毎回変更はありません。
8-4	支払案件	形式的な文言であり、毎回変更はありません。
8-5	保証年数（瑕疵担保責任期間）	一般的に環棄担保責任期間は「6か月」または「1年」のどちらかです。期間が短いほどユーザーには不利益な条件となります。まずは「1年」と明記し、もしベンダー側がどうしても難色を示した場合は、調整 を検討します。
8-6	機密保持	形式的な文言であり、毎回変更はありません。
8-7	著作権等	特別な事情がない限り、著作権は自社帰属で必ず指定します。後でベンダーと採めることが多いので、最初に明記しておきます。なお、スクラッチ開発の場合はプログラム全てが自社著作権の対象になりますが、 パッケージシステムの場合はカスタマイズ部分のみが対象となります。
8-8	その他	RFPにおける最後の決まり文句です。形式的な文言であり、毎回変更はありません。

RFP本編での注意点

では、目次で大まかな枠組みはわかったと思うので次はRFP本編の書き方を解説していきます

抽象度を高めに

RFPは細かく書けばいいということではありません

特に、「手段」ではなく「何をしたいか」をベンダーに伝えることが大事になってきます

というのも、ITベンダーの考える手段とクライアント側が考える手段の選択肢が違うからです

ITベンダーはやはりITの知識と実績はあるので、クライアント側が提案する手段よりも効率のよい方法を提示してくれます

よくあるのが、クライアントが一からすべて作ろうとするのに対し、既存テンプレートをつかったり、既存システムを使ったりすることができるということです

なので様々なベンダーから最適な提案を引き出すために抽象的な「何をしたいか」を伝えるとよいでしょう

ただ、自社のIT部門が〇〇というプログラミング言語に特化しているので、〇〇を使って欲しいという「手段」を伝えるべきというところに注意してください

事前の要求は必須

ベンダーと揉める一番の原因は、プロジェクトの途中で要求を追加することです

ベンダーからしたら、いきなり追加をされると大幅にその他の関連部分を変えなければいけないこともあり、ベンダーにとってかなりの負担になります

また見積もりも当然追加前の仕様でしているので、追加料金を求められることもしばしばあります

これはお互いにとって無駄でしかありません

「こんなこと言わなくてもわかるだろう」とふと思った瞬間が命取りになります

ここはIT部門と連携してしっかり作るようにしてください

これでも見落としがちなのは「性能要求」です

あるプロジェクトでは受入テストで起動に１０秒かかることが判明し、ベンダーに即時改善を求めました

しかし、ベンダーからしたら仕様通りということで追加費用を求めてきたのです

１０秒も起動にかかるシステムが使えるわけないじゃないか、と思われるかも知れませんが、この性能の部分をしっかり記すことがいかに大事か分かって頂けたら幸いです

RFP別紙で書く内容

RFP別紙は本編で書くまでもない内容のものを詰め込みます

その分、自社それぞれで柔軟に伝える必要があります

ポイントは、「ベンダーが質問しなくても別紙を参照したら見つかる」ことです

構成要素

別紙でよく添付される基本要素をまとめました

業務概要	現行	業務概要は REP本編に記載欄がありますが、そこでは簡潔な記載に留めます。本編には「別紙業務概要をご覧ください」などを記載し関連付けを行います。
要求定義一覧	新	企画書で作成した資料をそのまま添付します。ヘッダーを変えるぐらいでほぼ無加工で問題ありません。「要求機能一覧」はベンダー見積もりの元となる最も重要な資料です。
システム関連図（As-Is）	現行	ベンダーはまず、視覚情報である「現行システム関連図」からイメージを膨らませます。特にシステム連携については、仕様を考える上でも見積もりを行う上でも、大きく影響が出ます。ベンダーと会話をする上では、この資料は外せません。
システム関連図（To-Be)	新	システム導入後のシステム関連図を示します。システム導入範囲(スコープ)を視覚的に表す資料としても有効です。
業務イベント	現行	社内では当たり前の業務イベント (業務スケジュール)も、ベンダーにとっては全く知らない情報です。運用マニュアル等に記載があれば、流用できます。
業務フロー	現行	ベンダーに業務イメージを伝える上では非常に有効な資料です。また社内においても、当事者以外は知らない人も多く、社内で認識共有する上でも役に立ちます。
現行システム出力一覧	現行	現行の設計書をそのまま添付します。出力画面や出力帳票は見積もりに直結する情報となります。「システム出力一覧」以外にも連携した方がよい設計書があれば「必要な人だけ読んで」というスタンスで積極的に追加します。

要求定義一覧の作り方

システム関連図の作り方

業務概要・業務イベント・業務フローの作り方

現行システム出力一覧については、もし現在使われているシステムがある場合に、そのシステム設計書を添付すれば大丈夫です

RFP別紙は寄せ集め

ベンダーに見て欲しい資料があるが、RFP本編のフォーマットに落としこむのは手間という資料があります

またベンダーにとっても見るべき内容が大量になってしまうので、無理に追加するのはよくないでしょう

そこで効果的な方法が「RFP別紙」です

RFP別紙では、本編のようにフォーマットに囚われる必要はなく、PowerPointやExcelといったファイル形式をそのまま一緒に添付すればよいのです

すでにある資料からコピーして貼り付けるだけの作業になります