BETA

社内システム導入における RFP(Request for proposal) を書く技術

投稿日:2019-10-29
最終更新:2019-10-29

社内SEをしていると、外部の SIer さんなどにシステムの開発やインフラ構築を発注することがあります。いくつかの SIer さんに提案をしてもらって、内容を吟味し、発注をするわけですが、SIer さんに提案をしてもらうための提案依頼書、RFP(Request for proposal) を書いている SE の方も少なくないんじゃないかな、と思います。

僕も以前1度だけ RFP を書いたことがあるんですが、身近に参考になりそうなドキュメントもなく、どういったものを書いたらよいかわからず、結構苦労しました。
そこで今回は、実際に僕が書いた RFP をベースに、盛り込んでおくと良いことやそのポイントを書いてみたいと思います。

前提

ここで書いた RFP が正解ではありません。不要な項目や、RFPではなくプロジェクト憲章などの他のドキュメントに記載したほうがいいことも書いているかもしれません。

あくまで参考程度にしてもらえたらと思います。

RFP の目次について

どのドキュメントにも共通しますが、最初に目次を書くことをオススメします。
ドキュメントで書こうとすることが俯瞰でき、項目の抜け漏れ、重複に気づくことができます。

目次

  1. 本書の目的
  2. プロジェクトの背景
  3. 現在抱えている主な課題
  4. プロジェクトの目的
  5. プロジェクトのゴール
  6. プロジェクトの範囲
  7. プロジェクト方針
    • 全体的な方針
    • 実現したい機能
    • ハードウェア構成
    • プロジェクトスケジュール
  8. 会社情報
  9. 提案依頼内容
    • 会社、組織情報
    • 提案システム概要
    • システム構成
      • ハードウェア要件
      • ソフトウェア要件
      • 保守要件
    • プロジェクトスケジュール
    • プロジェクト体制図
    • プロジェクトマネジメント方法
    • 会議体一覧
    • サポート体制・運用方法・SLA
    • 納品物一覧
    • ドキュメントサンプル
    • 教育研修
    • 概算費用
    • 制約事項
    • 導入事例
    • 契約内容
  10. 選考スケジュール
  11. 提案書提出先

この目次に沿って、各項目で何を書いていくかを詳しく説明していきたいと思います。

1. 本書の目的
なぜ RFP を作るに至ったか、この RFP で何をするのかを書きます。
RFP に限らずですが、そのドキュメントの目的が書かれていないドキュメントを結構目にします。
何を意図して作られたドキュメントなのか分からなければ、そのドキュメントの再利用性が損なわれ、そのドキュメントが生む価値が総じて低くなります。可能な限りドキュメントの目的を書くことをオススメします。

RFP の場合例えば、SIer が提案をするために必要な、課題や自社の情報などを提供します、とか、RFP によって提案された内容をもとに、発注先を選定します。などを記載します。

2. プロジェクトの背景
どういった背景で始まったプロジェクトなのかを書きます。プロジェクトの背景を SIer と共有しておいたほうが、より良い提案があると思います(私見)。

3. 現在抱えている主な課題
そのプロジェクトで解決したい課題を具体的に書きます。ここで気をつけたいのは「XX を導入する」といった手段を書いてしまわないことです。手段が目的化したプロジェクトは、結果的に何も解決しないプロジェクトになったり、泥沼にハマる可能性が高くなります。

4. プロジェクトの目的
現在抱えている主な課題を踏まえて、このプロジェクトでどういったことを実現したいかを書きます。

5. プロジェクトのゴール
プロジェクトの目的と混同しやすいですが、目的を達成するために何ができていないといけないのかを書きます。
僕の場合は、QCD(品質、コスト、納期)の観点で書きました。
見積もりの金額以内でプロジェクトを終えること、YYYY/MM/DD までに稼働させることなどですね。

6. プロジェクトの範囲
プロジェクトのスコープを書きます。(提案を希望する範囲という名前のほうが適切かも・・・)
要件定義から運用設計まで提案してもらいたい、管理者教育まで含めて提案してほしい、といった感じですね。

7. プロジェクト方針
いくつかの小項目に切り出して、プロジェクトの方針、希望する進め方などを記載します。

  • 全体的な方針
    プロジェクト全体における方針です。例えば XXX の改正案の施行の兼ね合いから、改正案に対応したシステムは納期を厳守する必要がある。とかですかね。

  • 実現したい機能
    要望を書きます。最低限実装されているべき機能となります。

  • ハードウェア構成
     希望するハードウェアの構成があれば書きます。
     オンプレミスの構築案件でなければ余り書くことはないかもですね。

  • ソフトウェア構成
     こちらも同様に希望するソフトウェアの構成があれば書きます。

  • プロジェクトスケジュール
    スケジュールの概要を説明します。
    MM/DDまでにリリースする必要があるため、MM/DD に開発を完了、検収を実施とか、現時点で想定されるスケジュールについて書きます。

8. 会社情報
自社の情報を書きます。
自社のHPで公開されている情報で十分だと思いますが、プロジェクトのスコープとして、地方の拠点や、海外の拠点が含まれる場合は、それぞれの拠点の地理的な情報も明記しておいたほうが良いと思います。

9. 提案依頼内容
SIer さんにはこの章で述べられた項目を提案書に盛り込んでもらいます。
これまでは長い前フリで、RFP の骨子はこの章といっていいでしょう。

(1) 会社、組織情報
SIer さんの会社やプロジェクトを担当するチームについて、現時点で提供できる情報を提供してもらいます。プロジェクトに参画するメンバーで再委託等がある場合には、委託会社や委託内容を明記してもらいます。

(2) 提案システム概要
提案するシステムについて、全体が分かる資料を提出してもらいます。また、自社に対して今後の拡張性を踏まえた点や、他社の同等製品と比べた際の優位性など、Sier さんにとって「推し」のポイントがあればそれを明記してもらいます。

(3) システム構成
この小項目に続く、各種要件を満たす構成を提案することを求めます。
例えば、ハードウェア要件、ソフトウェア要件、運用・保守要件などがあれば列挙し、これらの要件を満たすシステムの構成を提案してもらうようにします。

(4) プロジェクトスケジュール
Sier さんにスケジュールを提案してもらいます。また、各工程のタスクの担当者(自社タスク or Sierタスク)や、自社がやらなければならない作業もできる限り網羅してスケジュールを提案してもらえれば良いと思います。

(5) プロジェクト体制図
プロジェクトに参画する全メンバーと役割を提案してもらいます。未確定の役割があるようであれば、それでも OK としておくと良いと思います。

(6) プロジェクトマネジメント方法
コミュニケーション方法、マネジメント手法(ウォーターフォール、アジャイルなど)どういった方法でプロジェクトを管理していくかを提案してもらいます。

ここで重点的に提案してもらいたいことは次の2点です。

  • プロジェクト全体の品質、スケジュール、リスクのマネジメントのための具体的施策の明示
  • トラブルを未然に防ぐ施策と、品質欠陥、納期遅延が発生した場合の具体的な体制と対応方法

プロジェクトにトラブルや遅延はつきものなので、事前にリスクが浮き彫りになったときの具体的な対策を練ってもらい、提案してもらうことをオススメします。

(7) 会議体一覧
定例会を設定するようであれば、それの頻度や実施内容等を予め明記してもらいます。

(8) サポート体制・運用方法・SLA
本稼働後のサポート体制やSLA、障害発生時のフローなどを提案してもらいます。リリースしたらはいサヨナラとならないようにするためですね。

(9) 納品物一覧
設計書や議事録、マニュアルなど、どういったものを納品物として提供するのか、また、どのような媒体(紙、DVD、USBメモリなど)を明記してもらいます。

(10) ドキュメントサンプル
納品物のサンプルがあれば提供してもらいます。
コレジャナイドキュメントもしばしばあるので、ある程度の品質のドキュメントを希望するようであれば、その希望を伝えます。

(11) 教育研修
管理者、ユーザー教育を希望するようであれば提案してもらいます。
その際に、教育のスタイル(座学、ウェビナー、ハンズオン)や所要時間、使う資料のサンプルが事前にもらえるかなど、明記します。

(12) 概算費用
おおよその金額を提示してもらいます。
イニシャルとランニングである程度の内訳がわかるようにしてもらうのがベターかと思います。

  • イニシャル費:システム開発費、機器購入費用、ミドルウェア購入費用、ユーザ教育費用など
  • ランニング費:システム保守費用、ヘルプデスク費用など

(13) 制約事項
現時点で明らかな制約事項やリスクがあれば明記してもらいます。

(14) 導入事例
自社と同じ規模の会社での導入事例や、同様のシステムの事例等があれば紹介してもらいます。

(15) 契約内容
契約内容や支払い方法について明記してもらいます。
複数回に分けて支払いする、項目で支払い方法が違うなどがあれば明示してもらいます。

10. 選考スケジュール
提案書の提出締め切りからプロジェクト開始までの各イベントと、そのスケジュールを明記します。

11. 提案書提出先
そのままのとおりですね。提案資料の送付先です。
メールアドレス、担当者名が書かれていれば問題ないでしょう。

まとめ

書いてみてわかったんですが、RFP のフォーマットや盛り込まれている内容に正解はなく、プロジェクトを通して解決したい課題や、そのプロジェクトの制約、プロジェクトの背景などが SIer さんに伝われば良いのかな、と思いました。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@toyocyの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!