システム選定において、RFP（提案依頼書）という言葉は、普通に会話に出てくるようになりました。
ですが、RFPを実際に作成したり、目にしたりしたことがある方は、まだ少数派なのではないかと思います。実際にRFPを作成することになったとしても、何を書けばいいのか、どのように記載すればいいのかで悩んでしまう方も少なくないようです。
今回は、RFPの重要な要素の一つである「要件」の記載方法について考えてみたいと思います。
RFP（提案依頼書）に記載する要件の種類
まず、RFPに記載する要件について確認しておきたいと思います。
RFPには、提案を依頼したベンダーに向けて、「要件」を様々な観点から記載します。
一番代表的なのは、機能要件です。システムに求める機能にはどのようなものがあるかを記載します。
例えばですが、
・システムで電子承認できること
・前年同月比が見られる損益計算書を印刷できること
といった内容となります。
それ以外にも、
非機能要件
システムの利用環境（サーバーの性能やOSなど）や性能（処理スピードなど）に関する要件
導入要件
システムの導入作業（スケジュール、体制、作業報告方法など）に関する要件
運用・保守要件
運用保守サポートの内容（サポート対応時間、問い合わせ方法など）に関する要件
インターフェース要件
システム間のデータインターフェース構築（データの種類、頻度、構築体制など）に関する要件
データ移行要件
データ移行が必要となるデータの種類や期間に関する要件
などが挙げられます。
簡単に言うと、システムを導入し、運用するにあたって実現してほしいこと（必須の条件）を記載したのが「要件」です。
※RFPの記載内容についてはこちらのブログもご覧ください。
RFP作成のポイント～RFPへの記載内容とは～
要件の記載例～機能要件～
ここからは、要件の記載例を確認しながら、書き方の良し悪しについて考えていきたいと思います。
まずは、要件の中でも中核となる「機能要件」を取り上げます。
＜機能要件の記載例＞
◆販売管理システム
(1)受注管理
①受注入力：受注データをシステムに入力することができる。
②ＡＢＣ受注入力：ＡＢＣ受注については、過去の取引を参照して入力できる。
③受注承認：受注データをシステム内で承認することができる。
・・・
(2)出荷管理
①出荷入力：出荷データを入力できる。受注データを複製した入力も可能である。
②出荷承認：出荷データをシステム内で承認することができる。
・・・
＜機能要件の記載時のポイント＞
まず、全体に共通して言えるのは、曖昧な表現を極力なくすということです。
読み手によって解釈が異なってしまうような文章であれば、ベンダーの提案も、それぞれ独自の解釈に基づくものになってしまいます。
１項目に対して１つの解釈、１つの要件になるように記載するのが原則です。
「曖昧な表現を無くすこと」を踏まえて、各要件例を見ていきたいと思います。
まず、(1)②に「ABC受注」と書かれていますが、これでは第三者には何のことか伝わりません。
RFPには固有名詞や自社内でしか使われていない呼称・専門用語は使わないほうが良いです。（別途、用語集を付けて補足するという方法も考えられます。）
次に、(1)③、(2)②で、ともに承認を取り上げていることに着目します。
仮にパッケージシステムを選ぶ場合は、同じような機能でも、システムや処理が異なると実現できないことも多々あります。
誤解を防ぐためにも、同じような機能要件であっても必要なモジュール・必要な処理毎に要件として記載したほうが無難です。
最後に、(2)①ですが、1つの要件に2つの意味を持たせてしまっています。
あるベンダーの回答が「一方は簡単に対応できるが一方は難しい」だった場合に、回答が曖昧になったり複雑になったりする恐れがあります。
余計な混乱を招かずに済むように1項目には1つの要件にすることが望ましいです。
要件の記載例～導入要件～
次に導入要件の記載例を見ていきたいと思います。
＜導入要件の記載例＞
◆システム導入要件
(1)導入体制
①プロジェクトリーダーは、弊社と同じ建設業において、今回提案システムの導入実績を持っていること。
※プロジェクトリーダーの略歴や有資格についてご提示ください。
②プロジェクトリーダーは、要件定義フェーズにおける各種打ち合わせに参加し、かつ全成果物レビューを行うなど、プロジェクトに継続して中心的に参画すること。
・・・
<導入要件の記載時のポイント＞
ベンダーからの提案書を見る際、システムの機能や金額に注目が行きがちですが、多くの場合、それらと同等以上に大切なのがシステム導入能力です。
各ベンダーの能力を比較するためにも、システム導入において求めるべきことがあれば明記しておくことが大切です。
上記の例は、導入体制のプロジェクトリーダー部分を抜粋したものです。
システム構築において、プロジェクトリーダーが重要だと考えている場合は、そのプロジェクトリーダーに求める要件を明記して、それに対して回答を得られるようにする必要があります。
(1)①では、要件を記載すると同時に、ベンダーから経歴の提出も求め、より詳細な情報を得られるようにしています。
(1)②では、リーダーに求める役割を明記しています。
提案段階では前面に出ていた方が、プロジェクトが始まるとぱったり来なくなった、というのも良く聞く話です。
組織として対応してくれればよい、というスタンスであればそこまでこだわる必要はありませんが、「うちは人を重視してベンダーを選ぶ」という企業様であれば、役割まで定義し、名ばかりのリーダーに惑わされないようにしておきたいところです。
プロジェクトリーダーの要件を例に取り上げましたが、成果物やスケジュール、プロジェクトの会議体、報告方法など、ベンダーに求める要件があればRFPに明記し、また、必要な情報があればRFPを通じて提示を求めることをお勧めします。
要件記載時の留意点
以上、要件の記載例を取り上げてまいりました。
最後に、要件を記載するうえでの留意点について、記載したいと思います。
今回はシンプルかつ明解な要件を例示しましたが、要件自体をがっちり固めて記載するのではなく、要件は最低限の記述に留め、ベンダーから提案を受けて考えたい、という企業様もあるかと思います。
受注で例を挙げると、
「受注情報の登録から承認をシステム上で処理できる。」
といった書き方が一例です。
それも一つの方法です。間違いでは決してありません。
システム選定方針や調達するシステムへの理解状況等によって、要件の書き方は自ずと変わってきます。
ですが、RFPの記載方法に関わらずに共通して言えるのは、RFPを作成するにあたっては、「要件からは曖昧さを排除する」ということです。
要件が曖昧であれば、ベンダーの提案も曖昧になり、そこに誤解が生まれます。
また、ベンダーの提案を横に並べて比較するのも難しくなってしまいます。
そうなっては、RFPを作成するメリットも薄れてしまいます。
くどいようですが、RFPの要件では、
・曖昧さを排除する
・誰が読んでも同じ解釈になるようにする
を守るようにすることが、良いベンダーの選定への第一歩と言えるのではないかと思います。
まとめ
RFP（提案依頼書）に記載する要件の種類
☑機能要件
☑非機能要件
☑導入要件
☑運用・保守要件
☑インターフェース要件
☑データ移行要件 など
要件の記載例~機能要件～
☑固有名詞や専門用語は使わない（使う場合は説明を付ける）
☑同じ様な機能要件でもモジュール・機能ごとに記載する
☑一つの項目には一つの要件とする
要件の記載例~導入要件～
☑機能以外でも必要なことは要件として明記
要件記載時の留意点
☑システム選定方針や調達するシステムへの理解状況等によって書き方は変わる
☑曖昧さを排除する
☑誰が読んでも同じ解釈になるようにする
