システム発注時にはRFPを作る

2009年にも同様のエントリを書いていたw
見積依頼する前にRFPを作成しよう

昔も今も変わらないものがある

ソフトウェア業界は年々分野が増えて来ており、
開発の段取り的なことは同じ軸では語れません。

しかしながら、発注の一発目にやるべきことは、まったく変わっていません。
なにをやるかというと、RFPを作ること。
もちろん、作るのは発注者ですよw

RFPは全ての起点

RFP(あーるえふぴー)=Request For Proposal=提案依頼書

簡単に言うと、作ってほしいシステムの条件(要求)を書いたもの。

RFPを読んだベンダーがシステム提案書を作るのが王道の流れです。
ベンダーにまる投げではいいものなど出来ないわけです。

RFPを書くことで、要求仕様が明確になることに自ら気が付きます。
何が最優先事項なのかも重要です。
価格・機能・納期・品質・予算消化なのか?
発注者にも事情があるでしょうから、それらはベンダーに伝えるべきです。

これらが整理されていない状況でベンダ-を選ぶなど愚の骨頂です。
マッチしないベンダーと契約してからでは遅いのです。

見積依頼する前にRFPを作成しよう

すぐに見積もり依頼をしてはいけない

例えば、自社でサービスを始めたいと思ったとする。

インターネット通販、ホームページ制作、SNSやポータルサイト・・・・
手っ取り早く自分で無料ホームページやブログで作るのも「アリ」だけど、自分がお客だとして、そんなところを使いたい(買いたい)とは思わないよね。ビジネスとしてやるのであれば、プロ(業者)に任せるのが正しい。では業者(ベンダー)へ発注すると仮定しよう。

最初に何をすべきか?

「ネットでググって、2・3社に見積もり依頼すればいいんじゃないの」
うーん。間違ってはいないが、まだそれは早い。

最初にやるべきことは、RFP(Request For Proposal、アールエフピー)を作ること。

RFPとは

RFPとは日本語の意味でいうと、提案依頼書、提案要望書、見積依頼書、要求仕様書など。文字のとおりで、発注者が何を作ってほしいか仕様や基準、条件を決めておいてこれを元に、業者に見積書や提案書を作ってもらうのだ。

書面にすることのメリットは、
・作ってほしいものが具体的に「整理」される。
・「言った・言わない・忘れた」を防ぐことができる。
・相見積の際に同じ説明をする「手間」も省ける。
そして一番のメリットは、業者にここは「ちゃんとした会社」だからいい加減なことはできないなと思わせることなのだ。
なので面倒とは思わずにぜひRFPは作成することを勧めたい。

参考:発注までの流れ

発注者:RFP作成、NDA作成
発注者:見積参加の業者選定
業 者:見積書や提案書作成
発注者:RFPを元に見積・提案書を査定。業者決定
発注者:発注書、契約書作成
業 者:注文請け書作成
業 者:具体的な作業開始

[書評] IT業界のための工事進行基準完全ガイド

また仕事が増える人も・・・

来年度からプロジェクトマネージャやプロジェクトリーダーの人には避けては通れないハードル(テーマ)がある。

IT業界のための『工事進行基準』完全ガイド 基礎と事例と18の特効薬

2009年4月からのIT業界への「工事進行基準」の適用だ。

もともと、この業界は要件定義も決まらない状態での契約が多い。例えばまず予算ありきでその範囲内でどうにかするとかアバウトな要件定義(思いつき)と納期だけ決まっていたりとか、ハード一式のなかにソフト開発がおまけで含まれていたりなど。

これからはそういった契約は一切できなくなる。契約やシステムから曖昧さが少なくなるのはバラ色の未来が来るように思えるがそうとも言えない。だって、ユーザから現場まで工事進行基準の内容について知っている人間はまずいない(試しに回りの人に聞いてみたらわかる。実際私も深くわかっていないw)

だから、なにをどうしたらいいのか分からない。今だって忙しいのに、まだやることが増えるのか。いい加減にしてくれと・・・
つまり恐怖だけ先にくるのが今の感覚ではないだろうか。この本では工事進行基準について抑えるべきポイントが分かりやすく書かれている。また簡単なユーザ事例も載っているので理解し易い。来年以降に関連本が多数出版されるとは思うが今出ている本の中では、この本が一番だ。