要求を伝えるための情報は，「何を書くか」と「どう書くか」に分けて考える。まず，書くべき内容を見ていこう良いRFPの条件，すなわちベンダーから質の高い提案や精度の高い見積もりを引き出すために必要な情報は2点。「今後どうしたいか」と「現状どうなっているか」である。
まずは，RFPの全体像を見てみよう。図4は，東京都民銀行が情報系システム基盤の開発に際して，実際に作成したRFPの目次である。案件によって項目の追加や省略はあるが，多くの案件で共通に挙げられる項目がほぼ網羅されている。
ITコーディネータであるフライの井門良貴氏（常務 エグゼクティブコンサルタント）は「RFPには，大きく3つの情報を入れる。(1)要求を伝えるための情報，(2)ベンダーを選ぶための情報，(3)トラブルを避けるための情報だ」とRFPの内容を説明する。
図4に当てはめると，(1)が「1 概要」「5 システム化の内容に関して」「7 運用について」「8 体制と環境」「9 保証要件」「10 添付資料」，(2)が「6 提案依頼事項について」，(3)が「3 規約・条件」「4 契約に関する条件」に相当する。以下，それぞれの項目に沿って，チェックポイントを見ていこう。
|
|
|
図4●RFPの目次 東京都民銀行が作成した「情報系システム基盤」のRFPの目次。提案に必要な項目が網羅されている。他システムに流用する際は，必要に応じて項目を削ったり，「予算」などの項目を追加したりする [画像のクリックで拡大表示] |
要求に何を書く？ 「今後」と「現状」を書く
要求を伝えるための情報は，「何を書くか」と「どう書くか」に分けて考える。まず，書くべき内容を見ていこう。
良いRFPの条件，すなわちベンダーから質の高い提案や精度の高い見積もりを引き出すために必要な情報は2点。「今後どうしたいか」と「現状どうなっているか」である。
「今後どうしたいか」というのは，いわゆる要求仕様のことである。数々のベンダー選定を支援してきたアイ・ティ・イノベーション 取締役 能登原伸二氏は「RFPを作成する前に，システム化の目的を含め経営層からの要求や利用者からの改善要望はヒアリングしてまとめておく。成果物として，できれば簡単なDFDやE-R図くらいは作っておきたい」と指摘する。
東京農業大学が開発した研究情報公開システムのRFPから，要求仕様の一部を抜粋して見てみよう。
＊ ＊ ＊
システムの機能的要件
（1）公開研究情報
・研究情報の検索、表示、登録
・画面構成と処理の流れ、および項目構成については、別紙1に準拠すること
・農大HPを経由して検索できること農大のホームページから利用した場合は、農大研究者の研究情報のみ検索対象とすること（他大学と混ざらない）
・研究者が自分でも入力可能なようにする（当初は内部システムから登録し、使用しない）
・公開研究情報を利用して必要とする企業へ宣伝する枠組みの提供
…
＊ ＊ ＊
別紙1にはHTMLで作成した画面イメージが添付されている。他に，システム利用者の種類と数，同時アクセス件数などの情報，OSの指定，データセンター利用の指定，管理作業の内容などきめ細かく記載してある。
ここまで作るために「学長室や庶務課，教務課など関係各部門の担当者7人で，チームを作った。そこで大学の顧客の定義，顧客ごとに提供すべきサービスの内容，IT化すべきもの，その効果を検討し，ドキュメントにまとめた。それをベースにRFPを作成した」（東京農業大学 AIMS開発プロジェクトオフィス プロジェクトマネージャー 田中晋氏）。
既存システムの情報を漏らさない
「現状のシステムや業務の情報は，よく抜け落ちている」（永和システムマネジメント 中村氏）。既存システムからのリプレースであれば，そこで使われているマスターDBの項目やトランザクションの量は，新システムの規模や性能を考える際の参考になる。他システムとの連携を想定しているなら，そのインタフェースにかかわる情報も欠かせない。既存システムが存在しない場合でも，現行の業務が分かるような資料は添付したい。
京進では，RFP本体に加えて，既存システムに関するドキュメントのコピーを一式ベンダーに渡した。内容は「主要マスタデータ一覧」と「関係テーブル一覧」。帳票のコピーや教室のパンフレットなども添付した（図5）。
プロジェクトの規模やシステムの性格にもよるが，一般的にすべてに目を通してほしいRFP本体はA4で20～40ページ程度にまとめるケースが多い。一方，取捨選択してもらえばいい添付資料はいくら多くても構わない。
このほか，プロジェクトの中で，ユーザーが用意できる「人」や「物」などのリソース情報もあれば，それも開示する。人とは，利用部門と情報システム部門の体制。これがあると，ベンダー側もそれに応じた体制を作りやすい。物とは，開発・検証マシンやソフトウエア，それらを設置するロケーションなど。これらは見積もりの前提となる。前提が変わると見積もりも変わってしまう。図4で言うと「8 体制と環境」がそれに該当する。
|
|
|
図5●提出する資料の一覧 京進がRFP説明会時にベンダーに渡した資料6点セットの内容。提案や見積もりの参考になると思われる資料をすべて用意した [画像のクリックで拡大表示] |
予算の記載は意見が分かれる
RFPに予算を記載すべきかどうかは，意見が分かれる。
予算を記載しないメリットは，金額面での競争原理が働きやすいことに加え，制約の無い状態での提案が期待できること。「要求した機能をすべて実現した場合にいくら必要か知りたい。予算を記載すると，それが制約になってしまって，機能や信頼性が削られた提案をされてしまう可能性がある」（JALUX 企画部システム企画チーム 担当部長 マネージャー 呉服正博氏）。 予算を記載しないデメリットは，提案の金額に開きが生じてしまうことだ。2～3倍の格差が出ることは珍しくなく，基幹システムを刷新したJALUXの場合は「10億～40億円まで（4倍も）差があった」（呉服氏）と言う。
逆に，予算を記載するメリットは，すべての提案が予算を大きく上回ってしまうリスクを回避できること。また，同じような金額の提案が並ぶことにより，提案内容に集中して比較しやすくなることが挙げられる。
日経BP社が運営するWebサイト「IT Pro」（http://itpro.nikkeibp.co.jp/）上で，この4～5月に予算の記載についてアンケートを実施した。結果は真っ二つに割れた。「RFPに予算を記載すべきだ」が44％，「記載すべきでない」が47％，残りが「その他」（有効回答290件）。どちらのメリットを重視するかで，判断すればいいだろう。
