技術系RFP（ITシステム調達の提案依頼書）

RFP全般の目的は、発注側がやりたいことを示し、複数のベンダーから提案と見積もりを集めて比較できる状態をつくることにあります。技術系RFPはそのなかでも、システムの作り方や動かし方に関する条件を前面に出す点が特徴です。業務の困りごとだけを書いた依頼書だと、各社が前提をバラバラに置いて提案してくるため、後で比較ができなくなります。

技術系で書き分けたい軸は、次のようなものです。

• 対象範囲と接続先：新規に作る部分、既存システムを流用する部分、外部サービスと連携する部分を線引きします。ここが曖昧だと、ベンダーごとに守備範囲の解釈が変わります。
• 非機能要件：性能、可用性、セキュリティ、運用時間帯などを数値や条件で示します。機能一覧だけでは、止まってはいけない時間帯や想定アクセス量が伝わりません。
• 移行と運用保守：データ移行の有無、本番稼働後の保守体制、障害時の連絡経路までを範囲に含めるかを書きます。

プロジェクトマネージャー（PM）としては、この三つの軸を最初に決め、それに沿って本文を組み立てると、提案の比較表が後から作りやすくなります。

技術系RFPは、発注側のPMが単独で書き切れるものではなく、業務部門と情報システム部門、必要に応じて外部の支援役が関わります。進め方は、おおむね次の順番で整理できます。

1. 現状と課題の棚卸し：業務部門が今の困りごとと、新システムで実現したいことを言葉にします。ここで出た内容が、後の要求定義のもとになります。
2. 要求の技術条件への落とし込み：情報システム部門やPMが、業務要求を機能要件・非機能要件・制約条件に分けて書き直します。この段階の成果物が、RFP本体の中核です。
3. 評価基準の事前設計：提案を受け取る前に、価格・技術力・体制・保守の重みづけを決めておきます。受け取ってから基準を作ると、特定の提案に引きずられやすくなります。

成果物としては、RFP本文のほかに、要件一覧、現行システム構成の概要、質問受付と回答の窓口ルールがそろっていると、ベンダー側も提案を組みやすくなります。PMはこれらの整合を取り、業務部門の言葉と技術条件がずれていないかを確認する役回りを担います。

技術系RFPで提案の質が揃わなくなる失敗には、いくつか典型的な形があります。

• やりたいことと作り方を混ぜてしまう：特定の製品や構成を前提に書くと、提案の幅が狭まり、より適した方式を持つベンダーを取りこぼします。まず実現したいことを書き、技術の指定は必要な制約にとどめるほうが扱いやすくなります。
• 非機能要件の空欄：性能や可用性を書かずに機能だけを並べると、各社が安全側に見積もる会社と最小限で見積もる会社に分かれ、価格が比較できなくなります。
• 既存システムの情報不足：連携先の仕様や現行のデータ量が示されないと、ベンダーは前提を仮置きして提案します。稼働後に「聞いていない」という食い違いが起きやすい部分です。

もう一つ起きやすいのが、質問対応の不統一です。ある会社にだけ補足説明をしてしまうと、提案の公平性が崩れます。質問は窓口に集約し、回答を全社に共有する運用にしておくと、後から条件の差を問われにくくなります。PMはこうした進め方の抜けを早めに拾う立場にあります。

技術系RFPは、調達の一連の文書群のなかの一つです。前後にある文書との役割の違いを押さえておくと、どこまでをRFPに書くかの判断がしやすくなります。

• 情報提供依頼との違い：先に市場の実現可能性や概算感を集める段階では、提案依頼ほど詳細を固めず、情報収集を目的とした依頼を使うことがあります。RFPはそれより後、発注先を選ぶために具体的な提案を求める段階の文書です。
• 要件定義書との違い：RFPは提案を募るために「こうしたい」を伝える文書で、要件定義書は発注先が決まった後に「こう作る」を双方で確定させる文書です。両者は内容が重なる部分もありますが、確定度と目的が異なります。
• 見積もり依頼との違い：価格だけを求めるのではなく、技術方式や体制を含めた提案を求める点で、単純な見積もり依頼より範囲が広くなります。

この区別があいまいなまま進めると、提案段階で作り方まで固めすぎて後戻りが増えたり、逆に要件が曖昧なまま発注してしまったりします。PMは、今どの段階の文書を書いているのかを意識して範囲を調整すると進めやすくなります。

技術系RFPを扱えることは、プロジェクトマネージャーにとって、発注側の立場で調達を設計する力につながります。業務部門の要求を技術条件に翻訳し、評価基準を先に決め、質問対応の運用まで整える一連の動きは、要件定義や計画づくりの土台と重なります。この経験は、システム開発の発注側ポジションや、社内のシステム企画を担う役割を目指すときの説明材料になりやすい部分です。

職務経歴書に書くときは、RFPを書いた事実だけでなく、どの軸で提案を比較できるように設計したか、どんな食い違いを事前に防いだかまで具体で示すと、進め方を言語化できる人だと伝わりやすくなります。発注側と開発側の橋渡しに関心があるなら、調達とベンダーとの付き合い方の知識を合わせて押さえておくと、担える範囲を広げやすいと考えられます。

技術系RFPには、使う製品や技術をどこまで指定すべきですか。

まず実現したいことと満たすべき条件を書き、技術の指定は本当に外せない制約にとどめると扱いやすくなります。製品名まで固めすぎると提案の幅が狭まり、より適した方式を持つ会社を取りこぼすことがあります。既存システムとの連携など、動かせない前提だけを明記するのが現実的です。

非機能要件はRFPの段階で書く必要がありますか。

性能や可用性、セキュリティ、運用時間帯などは、提案を比較できる状態にするために早めに示しておくと役立ちます。空欄のまま機能だけを並べると、各社が安全側に見積もる会社と最小限で見積もる会社に分かれ、価格の比較が難しくなります。数値で出せない場合は、想定する条件を言葉で示すだけでも差が縮まります。

RFPと要件定義書はどう使い分けますか。

RFPは発注先を選ぶために提案を募る文書で、要件定義書は発注先が決まった後に作り方を双方で確定させる文書です。内容が重なる部分はありますが、確定度と目的が異なります。RFP段階で作り方まで固めすぎると後戻りが増えやすいため、提案を引き出すのに必要な範囲にとどめるのが無難です。