2010年11月9日火曜日

RFP入門のノート


序文


今までのRFP


RFPを受け取るベンダー側の評価



    要求がはっきりせず、何が必要かわからない。

    達成可能かわからない。

    求められている技術は使えないか、使うとかえってたいへｎ

    正しく見積もると、顧客の予算が少なすぎる

このような状況では、RFPを作成し、ベンダーを調達するフェーズで両社が想定外の時間と費用を費やすこととなる。

  _____  

今まで僕が診てきたRFPも、すでに発注先が決まっているコンサルティング会社が作るケースで「RFPそのもの」からは他社が要求が読み取れないものや、RFPに問題があったのか、RFP記載内容の理解度のリストを作表すると、各ベンダーともに評価が低くなってしまうケースがありました。これらはRFPを作成する側にも問題があったケースかと思われます。しかし、一方で、RFPをよく読まないで「えいや」見積もりで提案してくるベンダーがいることも確かです。こういったベンダーは「RFPの理解度」の観点から振り落とすべきでしょうか。


はじめに　


当書を貫く主要テーマ



    よい提案を得るためには、提示する情報の質が重要。要求が情報としてよい構成で完全なものでなければならない

    生産性的な提案を得るためには、RFPの表現と構造とまとめ方を整える必要がある。

    RFPは、製品を買うための依頼をはるかに超えるものである。RFPは共に働くチームを作り、ともに問題を解決する協力者を募るものである


RFPの限界


RFPは、プロジェクトの終わりでなく、始まりである。そのため、プロジェクト開始後に本当の要求が理解できていないとわかることが度々起こる。「私たちにできることは、森を通って道を切り開きながら通路を作っていくことだけである。システムの要求の多くは、システムを作成しながらやっとわかってくる。これは特に、複数の市販製品を利用するシステムにとって真実である。そこでは、製品の相互作用がシステムの最終設計に相当の影響を及ぼす「David J. Carney. "Quotations from Chairman David."Pittsburgh: Carnegie Mellon University,1998. アメリカ国防総省をスポンサーとする研究


注意の言葉


ベンダーの観点から見て公平か、あるいはあまりにも多くを求めすぎていないかを検討すること。とくに入札後は、ともに仕事をするパートナーとなることを忘れてはならない。公正さと相互尊重が基盤になければ成功するビジネス上の関係は築けない。おだてたり、すかしたりの値引き交渉はパートナーシップを損なう。パートナーは買ってくる物ではなく、育てる者。

  _____  

システム開発は単なる、お客様-業者という関係だけではなく、共に同じゴールを目指すパートナーとして仕事を進めていきます。そのため、RFP段階での理不尽な値引き交渉も含めプロジェクトを一貫してパートナーへの気配りは必要となるでしょう。ただ、私は20人月程度の見積で値下げ交渉をせずに発注したのに納期半年遅れで500件を超えるバグを受入テストで検出したことがあります。このときは、さすがにパートナーシップなどと言っておられず、感情的にシビレマシタ（笑）

私たちはRFP段階でベンダー側が私たちの要求を理解して見積もりを出しているか、また、その見積もりの背景にある開発体制を築けうるのかを見極めなければなりません。 この一件は、そのよい教訓となりました。


第１章RFPとは（その１）


この章の概要と用語の定義


この章では、当初で用いる用語の全般的な定義とITプロジェクトのなかでのRFPの位置づけ、RFPの構造や作成するための工程が概説される。

  • 購買者・・・ITサービスを調達する事業会社の担当部門
  • 供給者・・・ベンダー
  • RFP・・・提案依頼書。供給者に提案を競わせるために使うツール
  • RFI・・・情報提供依頼書（いわゆる引き合い状態での依頼文書)
  • 提案・・・の要求に対する供給者の解釈の現れ

RFPを利用するのに適した状況類似ソリューションの中での最良のものの選択購買者にとって未知のスキル、製品、専門知識、技術的能力の組み合わせを要求する最低価格が契約を決める決定基準ではなく、最終的な価格は供給者と交渉して請負契約を結ぶ

供給者が提案によってRFPに応えるとき、RFPと提案の両方がプロジェクトとパートナーシップのベースラインとなる

 

RFPの作成行程
購買者の内部から見れば、RFPを作成するためにはニーズを調べ、そのニーズを定量化(文書化)できる要求に翻訳することが必要。しかし、RFPを作る過程では、さまざまな利害関係者と折り合いをつけなければならない。RFPには技術的な要求やプロジェクト管理、契約に関することまで考慮しなければならない。これらを成功させるためには次の事を実行する必要がある。
プロジェクトにより解決できる現行業務の欠陥あるいはニーズを客観的に定義し、これらの社内コンセンサスを取る適切な供給者とソリューションの候補を明らかにするプロジェクトのリソース（人・金・時間）を明確にする

次のようなケースでは、あまり成功しない。

  • 要求があいまいか、過度に限定的で、供給者の考えを、前もって決められたソリューションに制限している
  • 購買者側が利用可能な技術について十分に教育されていない
  • 予算と納期が未検証で、合理的ではない

RFIとRFP

RFIは、プロジェクトのフィージビリティスタディの役割を持つと共に、供給者のふるいわけに使用できる。RFIの段階で、よいコミュニケーションを築けるかを見極め、RFP発行の候補を選定していく。

RFPは、供給者に提案を求める正式な仕様・要件の提示であり、契約の一部となる。RFPは、購買者側がソリューションに必要なリソースの一定の見解を示したものであり、提案は供給者側が一定の見解を示したものである。


なぜRFPを作るのか


RFPはプロジェクトが開始してから終了するまでの、要求と実装、それに費やされれるリソースをいかにコントロールしていくかについての基盤となる。

RFPを作るメリットは次のようなものである。

  • 購買者側がプロジェクトの課題や問題点を早期に発見できる
  • 供給者はRFPの要求に付加価値をつけて競争を行うようになる
  • 公平なルールと共通の尺度のもとでの競争・比較が可能となる


RFPの作成とその準備


RFPを作成するにあたっては、関連諸部門とRFP作成「プロジェクト」を立ち上げる。それほどにRFP作成にかかる労力と時間は大きい場合がある。RFPプロジェクトチームのメンバーは、次の３部門の中から均等にスキルバランスを取って選ぶ。

  • 業務部門・・・業務部門は操作要求や機能要求を作成できる人々
  • IT部門・・・購入製品が既存の技術インフラに適合するか、製品サポートや導入には何が必要かがわかる人々
  • 調達部門・・・提案の種類によりどのような契約を結べばよいかを理解している人々

RFPの計画フェーズでは次の重要項目を考慮する

  • RFPプロジェクトの要員、組織、スケジュール
  • 技術と供給者に関する教育予
  • 算の見積もりと作成、必要に応じたROIの算定
  • RFP作成提案の評価決定と契約
  • RFP発行後の作業、新システムのプロジェクト組成

RFPは共通の評価基準を定めて評価しなければならない

  • 技術要求管理要求価格照会先（提案内容の類似事例の紹介先）
  • 参加資格／類似プロジェクトの経験
  • Ｗｅｂサイト／口頭プレゼンテーション
  • 製品デモ
  • RFPへの回答
  • 全体供給者チームとの共同作業の可能性

ヒント
RFP内で、必須要求、あればよい程度の要求、単なる情報が見分けられるようにしておくこと

RFPのレビュー
RFPを供給者に発行する前に、RFPチームの主要メンバー以外の人々によってRFPをレビューすること。ここでは、次のような観点からチェックを行う。

  • 現行の稼働環境やネットワーク構造は最新で正確か基本的なアーキテクチャに問題はないか
  • 機能要求は明確かつ正確か
  • 見積明細の提示方法は社内基準を満たしているか
  • プロジェクト計画は達成可能か

  _____  

全体的に重厚長大なプロジェクトを前提としたRFP作成について記載されているようだ。また、業務部門が積極的にプロジェクトに参加し、RFPを作成することを前提としている。しかし、多くの中規模案件のケース（数千万円）では、業務部門はそれほど積極的にRFP作成には関与せず、購買部門はハンコをつくだけのケースが多いように思う。そもそも購買部門がない中堅企業の場合は、その役割をIT部門が担わなければならない。
ただし、全般的なチェックポイントや評価基準は網羅的で妥当であると思う。 もちろん、これらをどのようにチェックし、評価するかが問題となるのだが、それらは後続の章に記載されているものと思われる。


第１章RFPとは（その２）


RFPの構造


RFPは、購買者が供給者からさまざまな種類の製品やサービスを購入するときに使用するツールである。基本的なRFPは、おおまかに次の各章から構成されている。ただし、これらは一つのモデルであって、章だてはケースバイケースで変わりうる。

  1. 事務要求の章
    課題の概要・要約を記述する。また、提案期間中の    コミュニケーションルールなどのRFPに関する事務的な情報を記述する。
  2. 技術要求の章
    技術的な要求を記述する。供給者が問題を理解して提案を書けるだけの情報を提供する。
  3. 管理要求の章
    プロジェクト管理の条件を記述する。
  4. 供給者の参加資格と照会先の章
    供給者の参加資格（事業規模や実績）について説明し、自社の資格と、その照会先を記載するよう供給者に依頼する。
  5. 供給者の章
    RFP範囲外ではあるが、供給者が関連すると思う情報を入れるように勧める。
  6. 価格の章
    供給者が提案の中でどのように価格情報を伝えればいいか(見積明細など)を説明する。
  7. 契約書とライセンス契約の章
    購入契約、機密保持契約、その他法律関係の文書を入れる。
  8. 附録
    ネットワーク図や技術要求の検討結果、プロジェクト計画の概要など、量の多い関連情報を入れる。


1. 事務要求の章


この章の目的は、RFPに回答するルールを明確にし、それに従わない場合の不利益を供給者に知らしめることである。この章が不十分であると、熟練した供給者は購買者側の混乱や未熟さの表れと受け取るかもしれない。
この章では、まず企業概要を説明し、RFPを通して解決したい課題を記述する。課題は、RFP発行に到った業務上の課題と、課題に潜んでいるリスクがある技術的な問題を、供給者が理解できるように詳細に記述する。
事務要求に関しては次のような事項を定義する。

  • 提案の提出期限と提出先
  • 提案前RFP説明会を行う条件と日時
  • 調達に関連する日程
  • 提案作成要領
  • 提案の評価方法
  • RFP窓口担当者名と連絡先（メールアドレスなど)
  • その他必要な情報


2. 技術要求の章


この章には、供給者がRFPに回答するために必要なすべての情報と要求が入る。まずRFPの基になった問題や課題の要約を示し、現行の業務アプリケーションと技術環境（ハードウェア、ソフトウェア、通信）について触れる。この章は網羅的にMECE （mutually exclusive, collectively exhaustive）を心がけて記述する。
問題の記述に続けて、供給者が提案の中で対応すべき要求を記載する。ここには例えば次のような項目を入れる。

  • プロジェクトの目的と目標
  • 重要成功要因
  • 現行システムの機能仕様
  • 計画中のシステムの機能仕様
  • 性能要求
  • ハードウェア要求（必要に応じて）
  • ソフトウェア要求
  • 通信要求（必要に応じて）


3. 管理要求の章


この賞では、実装、導入、教育・訓練、保守、その他のプロジェクトの側面を網羅したプロジェクト計画を作成するために供給者が必要とする情報を提供する。供給者がプロジェクト要求を確実に満たすためには、この章は必須である。管理要求への対応が不十分な供給者は、製品開発に全リソースをつぎ込んでしまい、保守や教育、文書化をおざなりにしてしまうリスクがある。そうならないためにも、この章への対応を通して、供給者の管理能力を見極めるようにする。
プロジェクト計画は通常、次の項目を含む。

  • プロジェクト実行要求
  • 要因配置要求
  • 作業場所確保責任
  • 出荷と導入のスケジュールと計画
  • システム受け入れテスト要求
  • システム保守要求
  • システム教育要求
  • 文書化要求


4. 供給者の参加資格と照会先の章


この章では、自社の情報や財務状態、そして作成中の提案の紹介先として過去の顧客の名前を出すよう要求する。この章で要求する一般的な項目の例は次のとおりである。

  • 供給者の会社の簡単な沿革
  • 供給者の導入・保守提案と導入・保守能力
  • 供給者と各メーカーとの関係、およびその関係の継続期間
  • 供給者が契約を実行するために必要な技術力、技術スタッフ、財源を所有している証拠
  • 現在導入済みのシステム一覧
  • 類似の構成と業務をもち、照会に応えてくれる顧客名（連絡先や電話番号もつける）


5. 供給者の章


この章は、RFPや提案の中に潜んでいる想定外の問題や解決策を供給者が提供するための場所を確保するものである。これにより、供給者側で追加製品機能のデモを行いたいという提案やRFPに抜けていると思われる要求に関するコメント、そして予想もしていなかったユニークなソリューションが提案されることもある。
この章で提供されたアイデアには、必ず注意を向けるようにする。RFPで明らかにされた問題に対して、他の供給者が考え付かなかったソリューションを提案してくる供給者もいる。たとえ、この供給者自身とは契約しなかったとしても、問題とそのソリューションの候補は、契約を取った供給者に検討してもらう価値がある。


6. 価格の章


この章では、供給者が価格提案を作成する際に使用する詳細な書式を提供する。異なる供給者の価格提案を隔日に対等に比較できるようにするためには、わかりやすい書式を提示する必要がある。比較を用意にするためには次のように見積明細を分けたスプレッドシートのサンプルを提供するのもよいだろう。<

  • ハードウェア
  • システムソフトウェア
  • アプリケーションソフトウェア開発
  • 導入
  • 保守
  • 教育・訓練
  • 文書作成
  • プロジェクト管理
  • 独自のハードウェアまたはソフトウェアの統合
  • （継続中の）ライセンス料金

ここで注意しなければならないのは、「１回限りの費用」と「繰り返し費用」の対比である。システムの有効寿命を考慮するならば、「繰り返し費用」を明確にして見積を比較する必要がある。


7. 契約書とライセンス契約の章


この章は、契約や協定にどう対応すればよいかについて、供給者の基本的なガイダンスになるものである。この章により検収期間や瑕疵担保期間、著作権など、プロジェクト全体を止めかねない問題を未然に解決する。これらは提案期間中に十分に検討し、解決する必要がある。さもないと、契約書を受け入れられないような供給者を選択してしまうこともありうるからである。
契約書の中には、次のような項目が入る。

    購買同意書保守契約保証期間（瑕疵担保期間）ソフトウェアライセンス契約契約保証支払保証機密保持契約成果物の著作権成果物を規定した請負契約または、規定しない準委託契約の選択


8. 附録


RFP本体に入れるには長すぎる詳細情報を作成したときには、附録とする。附録の例には次のようなものがある。

  • ワークフロー図と検討資料
  • 統計情報が入ったスプレットシート
  • 通信ネットワーク図と計画
  • 現行機器の一覧
  • 企業内で使っている標準
  • 日付の入った仮プロジェクト計画

  _____  

全体として重厚長大なRFP向けの構成となっています。公共や金融のプロジェクト、産業系ならば数億円規模のプロジェクトでの構成のようです。このような構成のRFPが配布されるコンペでは、５社～１０数社が参加しているケースもままあり、事務要求や価格の章で記載される一律に各社とコミュニケーションを取り、提案内容を評価するための内容は重要になります。また、数千万円程度の中規模案件で、既存供給者を含む数社のコンペである場合は、作るべきモノの要件に焦点を当てた、より簡略なRFPでもいように思えます。


第１章RFPとは（その３）　


RFP発行に伴う実施事項


RFP発行前、発行時、発行後に分類し、そのチェックポイントをまとめる


RFP発行前の実施事項



RFP発行前に実施することは、妥当な供給者の候補を見極めることである。

  • ソリューションを提供しうる供給者のリストを作成すること
  • 供給者に案件の重要性を認識させ、提案に前向きにさせること
  • 供給者が妥当であるかを確認すること

とくに重要なことは、供給者が妥当であるかを確認することである。妥当であるかのチェックポイントは次のとおり。

  • 妥当な技術や製品を持っていること。また技術力を内部で保持しているのか再委託して調達するのか
  • プロジェクトを適切に管理・遂行できるだけのマンパワーがあるのか
  • 供給者のオフィスロケーションの観点から定期的な打ち合わせや保守作業をどのように行うのか
  • 供給者は今回の案件規模に見合う実績を持っているか
  • 財務的に健全であるか

これらを見極めるためには、案件の要旨を説明する文書を出して、情報を求めるとよい。状況に応じて打ち合わせを行い、製品やソリューションのデモ・説明を求める。また、RFPを発行する前にすべての供給者候補を集めて説明会を実施する。その際、NDAを結ぶ(※おざき私見)。最終的に供給者候補にFRPの発行時期を知らせる。

供給者の候補や情報を収集するためには、展示会やカンファレンスに参加するとよい。


RFP発行時の実施事項



RFPを書いて発行／説明するための実施事項を示す。

  • プロジェクトのRFP関連スケジュールを作成する
  • RFPを作成する発端となった課題を明瞭に記述し、ステークホルダーの合意を得る
  • RFP概要を作成し、RFP作成チームのレビューを受ける
  • レビュー結果から作成スケジュールの見直しを行う
  • 要求事項に対する提案評価基準を定める
  • 完成したRFPから予算の妥当性を検証する
  • RFP説明会を開く
  • RFPの内容に関する質問は文書化させる。回答は全供給者候補に公開する(※おざき経験）
  • RFP発行時は可能な限り供給者の役に立つよう努める。ただし、コミュニケーションルールを守らない供給者候補はそのむねを評価する


RFP発行後の実施事項


ここでは提案がでてきてから実施する事項を示す。

  1. 機械的な判定基準から提案書を評価する

    2. 期限遵守や重要な要求に不賛成を唱えていないかなど機械的な判定基準で提案書をふるいにかける
    選抜を行う
    他の供給者と上下50%の範囲を超えて著しく値段が異なるもの。要求に対応する提案が欠けているものを候補から落とす。こうして２，３社に絞り込む

    デモ/提案書説明を依頼する
    社内のステークホルダーに対してRFPの要求に応じたデモと提案書説明を依頼する。
    照会先を訪問する
    照会先に連絡し、訪問することで過去の実績を確かめる
    供給者候補を訪問する
    作業場所や本社を訪問して管理者たちと面談し、紙面上の内容の妥当性を確かめる
    最終見積もりを提示してもらう
    供給者候補が要求の影響範囲を過大評価していないか、実装期間が冗長でないかを検証し、必要に応じて再見積りを求める
    供給者を選ぶ
    事前に定めた要求に対する評価基準と上掲の評価による心証、見積もり内容から供給者を選ぶ
    選抜のプロセスを管理者とともにレビューする
    正式な内部文書を作成して、選ばれた供給者がなぜ勝ち残り、他の供給者はなぜ落とされたのかを説明する。
    選ばれなかった供給者に説明する
    選別から除外した理由を選ばれなかった供給者に説明する
    提案を整理し保管する
    選ばれた提案書だけではなく、全提案書を保管する。不採用の提案書の中にも有益な情報があり、これをプロジェクトに活かすことも可能だからである。また、最終版のRFP、提案書は契約のベースラインとなる資料であることから変更があった場合は変更履歴も含め、確実に保管する。

  _____  


著者はRFPをWebサイトで公開し、必要に応じて供給者にパスワードを発行して情報を共有することを奨めている。しかし、私見では情報セキュリティの観点からこの方法は取るべきではないと考える。また、RFP発行前にNDAを取り交わすこともチェックポイントにないのも不足点だろう。発行者のなかにはRFPを後日回収するところもある。著者の環境と私が経験してきた環境はだいぶ異なるようだ。


時刻:

0 件のコメント:

コメントを投稿