LoginSignup
6
11

More than 3 years have passed since last update.

[Doc] RFPの書き方と読み方

Last updated at Posted at 2019-03-06

はじめに

開発コンペに参加されている開発会社の皆様、RFPの書き方を勉強して読み方も知ろうというのが今日です。

RFPとは

RFPとはRequest For Proposal、日本語で言うと提案依頼書です。これを読んで私たちに提案をしてください、ということです。

なので、ちゃんとRFPを読み込まないといい提案ができません。

どうやったらRFPを読めるようになるのか

どうやって読み込めるようになるのか?
それは作ってみると読めるようになります、作るプロになると読むプロにもなれます。 ということで早速作ってみましょう。

目的

RFPが何か?これはもう説明しましたね。

では、なぜRFPを書く必要があるのか。 RFPはよい提案をいただく為にあるのですが、よい提案をしていただくためには、正確かつ確実 に情報を開発会社渡す必要があります。その手法がRFPなのです。

さらに言うと、複数の開発会社さんに 正確かつ確実 に情報を伝えるためにドキュメント化する必要があります。

何度も同じことを説明していると説明が雑になったり、前日飲みすぎたため説明がうまくされなかったりと、正確かつ確実 に伝えられない可能性をドキュメント化することによって軽減することができます。

ステップ 1 概要

開発の目的、目標、予算、スケジュールを記載します。

開発の目的

なんで開発することになったのかを記載します。開発会社はこの目的をベースに隙間を埋めて提案してます。

目標

どの領域でいつまでにどうなっていればいいのか。重要、この設定がしっかりできていないプロジェクトは高い確率で失敗します。

予算

上限?決まっていなければ予算の考え方を記載します。初期でどれぐらい?保守運用でどれぐらい?予算に含まれるもの、含まれていないものは何か具体的に記載します。

スケジュール

いつまでに提案してほしいか、いつまでに決めるのか、いつまでに開始する必要があり終わる必要があるのかを記載します。 ( 開発側の心叫び:無理なスケジュールはやめましょう、そして検討期間を短く、作業時間とテスト時間にできるだけ時間を当てましょう。)

規模

開発の規模がわかる定量的な情報があればここに記載します。

提案前提条件

提案するにあたっての条件を記載します。例えばISMSもってないとダメ、こういう実績がないとダメ、など。提案はよかったけど最後条件満たしていませんでした・・は大きな悲しみと時間の無駄を生みます。

ステップ 2 スコープ

具体的に提案をしてほしい範囲、役割、機能、運用・保守内容、成果物を記載します。

スコープ

提案してほしい範囲・スコープを記載。何をお願いしたいのかここに具体的に記載します。ここでは認識の違いが生まれないように、具体的かつ分かりやすく記載しましょう。

機能

必要な機能一覧を記載します。 必須、あればよし、あったらいいな、のようなグレードに分けると、いい選定ができるかもしれません。 必須に関してはどうして必須なのか、補足されているともっと効率のいい代替案が提案されるかもしれません。(ヒント)

非機能

機能ではないが、必要なものを記載。セキュリティー、品質などなどを記載します。

運用・保守・教育

必要な運用体制、保守体制、教育体制を記載します。

成果物

最後に納品されるべきもの一式を記載します。

体制

自社の体制、開発会社に求める体制を記載します。開発会社さん(私たちも)は基本提案は1軍が来ます、実行部隊まで1軍である必要があるか、どんな体制を求めているか記載します。自社の体制もしっかり伝えましょう。自社に体制が構築できないのであれば、それを補う体制が提案されるかもしれません(されないかもしれません・・)特にプロジェクトマネージャーとなるの必須条件などを記載します。

ステップ 3 検討事項の記載

検討事項、まだ決まってない・悩んでる・提案の段階で相談したい内容などを記載します。開発会社としては、該当項目がRFPになく、決まっていないのか、漏れているのかによって提案内容も異なります。

ステップ 4 提案方法の記載

複数のベンダーに提案してもらう為にも公平な環境と条件を用意する必要があります。提案書はどこにいつまでに、地球が何回回ったら出すのか、どのように出すのかを記載します。

サンプル

こちらにサンプルRFPがありますので、ご参考までに
https://www.itc.or.jp/foritc/useful/rfpsla/rfpsla_doui.html

フォーマットは読みやすい+わかりやすければ拘る必要はありません。

最後に

RFPをいただく側の人は不明な点やわからない点があればすぐに聞きましょう。そしてRFPを出す側の方は、その時点で追加する情報は全ベンダーに教えてあげましょう。

書き方読み方、これでわかったでしょうか。正確かつ確実に要件は伝えられましたでしょうか、そして正確かつ確実に伝わりましたでしょうか。

ではでは。

6
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
11