RFPの書き方より先に、業務と現場の条件をそろえる

架空の場面から始めます。

ある製造業の会社が、生産管理のシステムを入れ替えることになりました。情報システムの担当者が一人で、RFP（提案依頼書）づくりを任されます。各部署に「必要な機能を挙げてください」と頼み、集まった要望を機能の一覧にまとめて、システム会社 3 社に送りました。

届いた提案は、金額も、範囲も、進め方もばらばらです。どれが自社に合うのか、比べる物差しがありません。社内で検討するうちに、各部署から「あの機能も要る」という声が追加で出てきます。

「機能の一覧が細かいほど、良い提案が来る」

こうしたとき、次のように考えたくなります。

• 機能の一覧をもっと細かくすれば、正確な提案と見積もりが来る。
• システム会社は専門家なのだから、要件は向こうが決めてくれる。
• 比べられないなら、いちばん安い提案か、いちばん機能の多い提案を選べばよい。

どれも一理あります。ただ、この場面でそろっていないのは、機能の一覧の細かさではありません。提案を比べるための条件です。

平拓では、この現象を「比べられない提案」と呼んでいます。目的や例外、守る品質といった条件が決まらないまま RFP を出したために、届いた提案を同じ物差しで並べられないことです。

見落としやすい条件

何のために入れ替えるのか。 機能の一覧は、「何ができればよいか」は伝えても、「なぜそれが要るのか」「どれがいちばん大事か」は伝えません。目的と優先順位が書かれていないと、提案は一覧の機能を満たすための見積もりに近づき、会社ごとの考え方の違いが比べにくくなります。

通常の業務と、例外。 特急品、仕様の変更、取引先ごとの条件の違い。例外の扱いが書かれていないと、後から追加の費用がかかるか、システムの外に手作業が残ります。例外は、頻度と一緒に挙げておくと判断の材料になります。

手順書と、実際のやり方の違い。 規程や手順書に書かれていることと、現場で実際に行われていることが違う場合があります。手順書だけを根拠に要件を書くと、使われないシステムになりかねません。

誰が決めるのか。 各部署の要望がぶつかったとき、最終的に決めるのは誰か。情報処理推進機構（IPA）は『ユーザのための要件定義ガイド 第2版』の公開にあたって、その背景として、システムの要件を定義する責任は、システムを使って事業に役立てる立場のユーザにあると言われていること、IT ベンダやシステム部門が中心の進め方から、業務部門のユーザが主体的に関わる進め方への変革が必要になっていることを挙げています。システム会社にも専門家としての役割がありますが、何を優先するかを決められるのは、発注する側だけです。

何をもって完成とするか。 受け入れの基準が決まっていないと、完成の手前で「思っていたのと違う」が起きます。

先にそろえておく六つの条件

RFP を書く前に、次の六つを社内でそろえておくと、提案を同じ物差しで比べられるようになります。

この六つは、発注する側のためだけの資料ではありません。受ける側のシステム会社にとっても、顧客の事情を早く正確に理解し、提案の前提をそろえるための共通の資料になります。システム会社が、自社の製品や過去に作った仕組みを活かして提案するのは、費用と期間を抑える合理的な方法です。大事なのは、それが自社の業務に合うかどうかを、双方が同じ資料で判断できることです。

自社で確かめる問い

• このシステムを入れ替えて、誰の、何が変われば成功ですか。一文で書けますか。
• 例外の業務を、頻度つきで挙げられますか。
• 手順書に書かれていることと、実際のやり方は同じですか。
• 各部署の要望がぶつかったとき、最終的に決めるのは誰ですか。
• 何ができたら「受け入れる」と言えますか。
• RFP を書き、提案を比べるための時間と人が、社内にありますか。

選択肢：RFPを書くことだけが入口ではない

条件をそろえる方法も、発注の進め方も、一つではありません。

• 社内で条件をそろえ、RFP を書いて、複数の会社から提案を受ける。 条件がそろっているなら、比較の効く進め方です。
• RFP の前に、RFI（情報提供依頼）で解き方を集める。 どんな製品や進め方があるのかが分からない段階で、選択肢の幅を知るために。
• RFP の前に、調査や要件定義を先に依頼する。 条件をそろえる仕事そのものを、外部と一緒に進める方法です。経済産業省がまとめたモデル契約書でも、要件定義の支援は、開発とは段階を分け、準委任型で契約する考え方が示されています。このモデルでは、要件定義でまとめた資料をもとに RFP を出し、開発の見積もりを受ける流れになっています。要件定義を依頼した会社と、開発を依頼する会社を分けることもできます。分ける場合は、開発を受ける会社が要件定義の資料を確かめる期間と、資料に誤りがあったときの責任の分け方を、先に決めておきます。
• 既製のパッケージやクラウドのサービスに、業務を合わせる。 業務の特殊さが小さいなら、作るより早く、安く済むこともあります。
• 入れ替えず、運用を変える。 今のシステムの使い方や、業務の流れを見直すことで足りる場合もあります。

どれが合うかは、規模、社内の体制、急ぎの度合い、業務の特殊さによって変わります。

関連する支援

平拓の診断では、事業の目的と現場の条件を確かめ、何を変えるべきか、何を変えないかを一緒に判断します。その結果は、発注先がどこであっても使える資料としてお渡しします。RFP を書く前の社内の整理にも、要件定義を先に外部へ依頼する場合の出発点にも使えます。

システム会社・開発会社の方からの、顧客の業務理解、要件定義、基本設計、RFP の作成補助のご相談も受けています。役割と範囲は、案件ごとにご相談のうえで決めます。詳しくはSIer（システム開発会社）の皆さまへをご覧ください。

参考

• 情報処理推進機構（IPA）『ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ』（2019年）
• 経済産業省『情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第一版〉』（2007年）
• 情報処理推進機構（IPA）・経済産業省『情報システム・モデル取引・契約書〈第二版〉』（2020年）

※本文のシステム入れ替えの場面は、説明のための架空の例です。