RFI/RFP の考え方 – 社内で何を握り、外部に何を任せるか

RFI / RFP は、ベンダーに依頼を出すためだけの文書ではありません。

システム導入やサービス選定、更改案件では、RFI は情報提供依頼、RFP は提案依頼として扱われます。一般的には、RFI はベンダーから情報を集めるためのもの、RFP はベンダーに具体的な提案を依頼するためのものとして説明されます。

もちろん、その説明は間違っていません。しかし、RFI / RFP の意味をそれだけで捉えると、少し表面的だと思います。

RFI / RFP は、外部に何かを依頼する前に、社内で何を握り、外部に何を任せるのかを整理するための道具でもあります。

システム導入や更改では、すべてを社内で抱え込めばよいわけではありません。一方で、外部ベンダーに任せればすべて解決するわけでもありません。

重要なのは、作業そのものを誰が行うかだけではありません。何を実現したいのか、どこまでを対象とするのか、どの基準で評価するのか、といった判断の前提を誰が整理するかです。

この前提が曖昧なままでは、ベンダーに依頼しても、提案を受け取っても、最終的な判断ができません。

文書	表面的な役割	社内側の本当の役割
RFI	ベンダーから情報を集める	自分たちが何を分かっていないのかを可視化する
RFP	ベンダーに提案を依頼する	評価軸を外部に提示し、提案を比較可能にする

作業を任せることと、判断を手放すことは違います

日本には多くの IT ベンダーが存在します。もちろん、すべてのベンダーが同じ品質で対応できるわけではありません。技術力、得意領域、対応範囲には差があります。

それでも、標準的な製品導入や、ある程度パターン化された設定作業、一般的な構築支援であれば、対応できる会社は少なくありません。たとえば、SaaS の標準的な導入支援、監視ツールの初期構築、エージェントのセットアップ、機器設定の定型投入、既存製品の一般的な更改作業などです。

これらの作業は重要です。雑に扱ってよいという話ではありません。しかし、重要であることと、すべてを社内で実施すべきことは同じではありません。

作業内容が標準化されており、外部の専門業者でも十分に対応可能であるなら、そこに社内リソースを使いすぎるのは効率が悪くなります。社内のエンジニアリングリソースは有限です。だからこそ、何を自分たちで行い、何を外部に任せるかは、組織として設計すべき対象になります。

ただし、外部に任せることと、判断を手放すことは違います。

作業は外部に任せられます。しかし、その作業が何のために必要なのか、どこまでを対象とするのか、何をもって成功とするのかは、社内で握っておく必要があります。

ここを曖昧にしたまま外部に依頼すると、ベンダー活用ではなく、単なる丸投げに近づいてしまいます。

社内で握るべきもの

社内で握るべきものは、個別の作業手順そのものではありません。むしろ、以下のような判断の前提です。

• 何を実現したいのか
• 何が本当の課題なのか
• どこまでを対象範囲とするのか
• どの制約を前提にするのか
• どの基準で提案や成果物を評価するのか
• 導入後に誰がどの責任を持つのか

これらが曖昧なままでは、ベンダーに依頼してもよい結果にはなりにくいです。なぜなら、ベンダーは依頼された範囲で最適化するからです。

こちら側が目的や制約を整理できていなければ、ベンダーの提案は表面的には整っていても、実際には比較しにくいものになります。その結果、価格だけで比較したり、資料の見栄えで判断したり、声の大きいベンダーに流されたりします。

良いベンダー活用とは、こちら側が判断の前提を持った上で、具体的な作業や実装を任せることです。丸投げとは、こちら側が何をしたいのかも曖昧なまま、ベンダーに答えを作らせることです。

この違いは大きいです。前者では、ベンダーは実行力として機能します。後者では、ベンダーは責任の置き場所になります。そして後者の場合、導入後に問題が出やすくなります。

「思っていたものと違う」となる。運用に乗せてから制約に気づく。障害時の責任範囲が曖昧になる。追加費用が発生する。最終的に、社内で誰も判断できない状態になる。

これは、ベンダーの問題というより、依頼側の設計不足である場合が多いです。

RFI は、分からないことを明確にするために使います

RFI は、単なる製品紹介を依頼するためのものではありません。前述した「社内で握るべきもの」のうち、まだ十分に見えていない部分を明らかにするために使うものだと思います。

たとえば、ある製品やサービスを導入する場合、最初からすべての要件が固まっているとは限りません。その製品で何ができるのか。どこまでが標準機能なのか。どこからが個別対応なのか。性能や運用上の制約はどこにあるのか。保守範囲はどこまでなのか。

こうした情報は、カタログや Web サイトだけでは分からないことが多いです。

だからこそ、RFI では、ベンダーに都合のよい説明をしてもらうだけでは不十分です。こちらが判断するために必要な情報を引き出す必要があります。

特に重要なのは、できることだけではなく、できないことや条件付きになることを確認することです。

「対応可能です」という回答だけでは判断できません。どの構成なら対応できるのか。どの規模まで実績があるのか。どの条件では個別対応になるのか。将来的な拡張時にどこが制約になるのか。

こうした情報が見えてくると、社内で考えるべき論点も明確になります。つまり RFI は、ベンダーを選ぶ前の段階で、自分たちが何を分かっていないのかを可視化するための手段でもあります。

RFP は、評価軸を外部に提示するために使います

RFP は、単に「提案してください」と依頼するための文書ではありません。RFI によって不明点を整理し、社内で握るべき判断の前提がある程度見えてきた後、それを外部に提示するためのものだと考えた方がよいです。

RFP で重要なのは、複数のベンダーから出てくる提案を比較可能にすることです。そのためには、背景、目的、対象範囲、必須要件、希望要件、非機能要件、運用条件、検証方法、受入基準、見積条件などを整理しておく必要があります。

これらが曖昧なままでは、各社の提案はバラバラになります。あるベンダーは高機能な構成を提案する。別のベンダーは安価な構成を提案する。また別のベンダーは運用支援を厚く含める。

それぞれの提案自体は間違っていなくても、前提が違えば比較はできません。比較できない提案を並べても、判断の質は上がりません。むしろ、判断が感覚的になります。

その意味で、RFP の役割は、提案を受け取ることだけではありません。社内で整理した評価軸を外部に提示し、比較可能な状態を作ることにあります。

社内エンジニアリングの価値は、判断可能な構造を作ることにあります

社内エンジニアが本当に注力すべきなのは、すべての作業を自分で実施することではありません。もちろん、手を動かせることは重要です。実作業を知らないまま設計や判断だけを行うと、机上の空論になりやすいからです。

しかし、だからといって、あらゆる作業を社内で抱え込めばよいわけではありません。重要なのは、作業を実施することそのものではなく、組織として正しく判断できる構造を作ることです。

• 何を自分たちで行うのか
• 何を外部に任せるのか
• 何を自動化するのか
• 何を標準化するのか
• 何を将来に向けて設計するのか

この切り分けができていないと、社内は作業に追われます。外部ベンダーは都度呼ばれます。判断基準は蓄積されません。案件ごとに同じような確認が繰り返されます。

逆に、判断の前提や評価基準が整理されていれば、外部ベンダーを使う場合でも、社内に知見が残ります。次回以降の案件でも再利用できます。提案の比較もしやすくなります。導入後の運用責任も明確になります。

これは単なる作業効率化ではありません。組織としての技術判断を蓄積するということです。

まとめ

RFI / RFP は、単なるベンダー向けの依頼文書ではありません。それは、社内で何を握り、外部に何を任せるのかを整理するための道具でもあります。

標準的なもの、手順化できるもの、外部の専門業者に任せた方が効率的なものは、適切に任せればよいです。ただし、そのためには、社内で判断の前提を整理しておく必要があります。

何を実現したいのか。どこまでを対象とするのか。どの基準で評価するのか。導入後に誰が責任を持つのか。こうした点を曖昧にしたまま外部に依頼しても、うまくいきません。

外部に任せることは、責任を放棄することではありません。むしろ、責任を明確にするために、何を社内で握るかを整理する必要があります。

RFI は、分からないことを明確にするために使います。RFP は、評価軸を外部に提示し、提案を比較可能にするために使います。

作業を抱え込むことではなく、判断可能な構造を作ること。そこに、RFI / RFP を使う意味があると思います。

関連する記事