全2回　プロジェクト成功につながるRFP作成のポイント 《連載:第1回》 「ダメなRFP」を作成すると何が起こるのか？

IT担当者であれば、RFPという言葉を知らない方はほとんどいないでしょう。しかし、本当の意味で効果的なRFPを書けると言い切れる方は少ないのではないでしょうか。
DXの普及が進む現在もRFP作成スキルの重要性は変わっていません。今回は２回に渡ってその概要から作成ポイントまで紹介します。これから初めてRFPを書くという方はもちろん、これから新しいプロジェクトに臨む方も、ぜひお役立てください。

ITサービス運用でお困りなら、ITサービス管理ツール「SmartStageサービスデスク」へ

RFPの質は自社に跳ね返ってくる

そもそもRFPとは何であり、また何のために存在するのでしょうか？

RFP（Request For Proposal）とは、企業が主にシステムの構築/リプレイスを行う際に、ベンダーやSIerに提出する提案依頼書を指します。以前は大規模な情報システム開発の際に利用されるのが一般的でしたが、現在ではWeb制作やアプリ開発など比較的小規模な案件でも使われています。

RFPを使用する目的は、自社の要件や見積りに対して最適な提案をしてくれるベンダーを選び、プロジェクトを成功させること。あらかじめ決まったベンダーに提出することもあれば、複数の企業に提出し、提案内容や概算見積もりを比較して決定に至るケースもあります。

と、言葉で説明するのは簡単ですが、実際のRFPの質は企業や担当者によって様々です。いえ、率直に言わせていただくと、「質の高い＝良いRFP」を作成できる企業・担当者は少なく、世の中のRFPの多くは、（言葉は悪いですが）「質の低い＝ダメなRFP」であると言っても過言ではないのです。

「別にダメなRFPであっても、現状特に問題がなければ改善する必要はない」という意見もあるかもしれません。しかし、ダメなRFPが恐ろしいのは、以下のように目に見える損害だけでなく、見えないところでも自社に損害を与えている可能性があることなのです。

【ダメなRFPが発注者に与えるかもしれない影響】

提案内容への影響

• ベンダーから的確な提案がもらえない
• 見積りの精度が低くなる（金額が高くなりやすい）
• 複数のベンダーの提案を適切に評価できない（再提案が必要になり時間が掛かる）

プロジェクトへの影響

• 手間や手戻りが頻発する、プロジェクトが迷走する
• 予想外のコストが掛かる（赤字になる場合も）
• 契約トラブルが発生する（裁判になる場合も）

成果物への影響

• 想定と異なる、期待外れの成果物が納品される

まだまだ挙げていけばキリはありませんが、要はRFPの質は、そのまま自社にブーメランのように跳ね返ってくるというわけです。

もちろんダメなRFPを提出しても、付き合いの長い、あるいは新規でも親切丁寧なベンダーであれば、ヒアリングを重ねて内容を詰めてくれるでしょう。しかし、そうしたやりとりが続くと、どうしても提案にかける時間は減ってしまいますし、プロジェクトに対するモチベーションへの影響も避けられません。反対に最初からRFPの質が高ければ、自社では気づかなかった提案や、より詳細な見積りが返ってくることが期待できます。

「ダメなRPF」によくある無理難題な要求

ダメなRFPの条件の一つとして挙げられるのは、無理難題な要求が盛り込まれていることです。独立行政法人情報処理推進機構（IPA）が発行している『SEC journal 第51号（2017年12月1日発行）』に掲載された論文「提案依頼書に含まれる無理難題の分類」には、実際にRFPに記載されていた無理難題な要求が、事例とともに紹介されています。対象は自治体や政府機関、大学、病院など公的機関のRFPですが、民間企業も参考になるはずです。

以下、無理難題の種類別に、記載例と無理難題である理由を見ていきましょう。

【技術的な無理難題】

記載例

• ID・パスワードの漏洩が発生しない仕組みを用意する
• 永久保存データとして管理できること

無理難題である理由

• 現状ではあらゆる攻撃を想定して100％漏洩を防ぐことは不可能ですし、「永久」を保証できる完璧なセキュリティも存在しません。

【仕様に関する無理難題】

記載例

• 本業務において改修などを施す際には，既存システムのソフトウェア構成やシステム開発言語などを踏襲し拡張などにも対応できること

無理難題である理由

• 「踏襲」と書かれても、既存システムの開発を担当した企業でなければ、詳細な仕様が与えられていない限り妥当な見積もりは困難です。似たような要求として、システムの開発・運用基準に関する「弊社開発基準に準拠のこと」「弊社運用基準に準拠のこと」といった記載も挙げられますが、ベンダーとしては「まずは、その仕様や基準を教えてほしい」としか返すことができません。

【将来の課題に関する無理難題】

記載例

• 将来の機能などにおけるデータ移行時に特別な費用が発生しないこと
• 将来連合立病院になる5病院において連携できるシステムであること

無理難題である理由

• いずれもシステム発注に関わる費用を固定化したいという狙いの要求かと思われますが、そもそも「将来の改修や保守に費用がかかることは当然である」という認識のないことが問題です。

以上のような無理難題以外にも、表現が曖昧すぎたり（「迅速に」「柔軟に」など）、反対に細かすぎて仕様書なみの要件定義が書き込まれていたり、提案までの期間が短すぎたり……と、ダメなRFPの条件はまだまだ存在します。

とはいえ、先述の通り、ダメなRFPを作成して損害を被る可能性が高いのは発注側です。そうならないためにも、次回、精度の高いRFPを作成するためのポイントを紹介します。