 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| RFPとは何か | ||||||||||
|
最近、多くの企業でシステム開発のための提案依頼書（RFP：Request for Proposal）が作成されはじめています。RFPとは文字通り、提案を依頼するために依頼先に提示されるドキュメントのことです。 本連載は、システム開発におけるRFPについて、その作成方法を解説します。その中でも開発の要件定義前に提案を依頼し、その開発に着手するかどうかを判断するために、RFPとはどのように作るべきなのかに焦点をあて、筆者の経験とデータ総研で開発したRFP作成方法論「PLAN-RFP」に基づき、解説していきます。 なお、本連載において要件定義前に焦点を絞ったのは、このRFPが一番難しいからです。また、近年の企業では投資判断をはやくするために、要件定義前のRFPが要求されることが増えていることも理由としてあげられます。  図1：本連載で取り扱うRFP （画像をクリックすると別ウィンドウに拡大図を表示します） 要件定義後であれば、「要件定義書＋α」の内容をRFPとして提示すればよく、また設計以降の工程についても同様に「設計書＋α」を提示すればよいことは比較的容易に想像できるでしょう。 しかし要件定義にも着手していない段階のRFPは、どのように作成すればよいのかと問われると、なかなか難しいのです。 |
||||||||||
| なぜRFPが作られるようになってきたのか | ||||||||||
|
なぜ最近になって、多くの企業でRFPを作成することをはじめたのでしょうか。まずは、その背景を整理していきましょう。 これまでのシステム開発では、「ユーザからA業務のB画面を使いやすくしてほしいという要望が提出されているので、一度ユーザに話を聞いて、対応してやって欲しい」などという比較的ラフな依頼に基づいて、従来からシステム開発を依頼していたベンダーが対応するというやり方が多かったのではないでしょうか。 この方法だと、もともとのシステムを開発したベンダーが直接ユーザにヒアリングして開発も実施するため、比較的簡単にすばやくできるというメリットがありました。しかし、逆に依頼元である情報システム部門（以下、IT部門）は、何のためにその改修を実施するのかが不明確になり、その対応費用が高いのか、それとも安いのかを評価できないというデメリットがありました。 この状況は、近年の企業に求められているコストダウンという命題によって、IT部門の人数を減らし、単なるIT関連の調達部門になってしまっている企業では顕著なようです。費用が評価できないということは、つまり投資の可否判断ができないということを意味します。これは近年の企業経営では、致命的ともいえるでしょう。 このような背景から、IT投資を適正かつ効果的に実施するためには、RFPの作成が必要だと考えられるようになってきています。すでに、RFPの作成は発注者として当然の義務だということもできるでしょう。 |
||||||||||
| RFP作成の目的 | ||||||||||
|
先ほど説明した通り、企業でRFPを作成するのは提案を依頼するためです。では、提案とは一体何なのでしょうか。 単純に考えれば、提案というものは依頼主が何らかのビジネス上の課題を持っていて、それに対する対応策の案を答えるのが提案です。またビジネス上の課題への解答も加わるため、その対応策に費用がいくらかかるのかという点も重要な要素になります。よって表1のように考えることで、提案に備えるべき要件が見えてきます。
表1：提案の備えるべき要件 表1のように考えてみると、RFPの備えるべき条件が明らかになります。
表2：RFPの備えるべき条件 開発におけるクリアしたい課題というのは、ITシステムを利用して業務をAのように変え、Bのような効果を得たいというものでしょう。これを明確に伝え、どのような方法で開発し、費用がいくらなのかを提案してもらうという流れが本連載で取り上げる「RFPの目的」になります。 では、どのような内容を伝える必要があるのでしょうか。以降では、この点について解説していきます。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
