※2012年12月1日より新ブログに移行しました。自分で言うのもおこがましいですが、20代の頃に書いた本ブログよりも、30代に入ってから書いている現行ブログの方がはるかに中身が濃く、内容が多岐にわたり、面白いと思いますので、是非ご覧いただけるとありがたいです!
>>>現行ブログ free to write WHATEVER I like
May 14, 2011

研修のRFP(提案依頼書)の雛形に関する素案(ITのRFPを参考に)(1)

拍手してくれたら嬉しいな⇒
永井 昭弘
日経BP社
2005-07
おすすめ平均:
永久保存版RFP本
とてもわかりやすいRFP指南書
RFP入門者向け
posted by Amazon360

 IT業界は自らを建設業界と比較して、業界の未熟さを嘆くことがある。IT業界の方々からは、「建築だと工数の見積がかなり正確にできるのに、ITではスケジュールの見積が甘い」とか、「プラントや工場の建設では投資対効果を算出するロジックが確立されているのに、ITの投資対効果をちゃんと算出しているベンダーは少ない」といった話をよく聞く。本書も、「建設業界ではRFP(提案依頼書)の決まった形式が存在するが、IT業界にはそういうものがない」という問題提起から始まっている。

 私は、研修業界はIT業界とよく似た業界であると思っており、さらにIT業界よりも深刻な問題を多数抱えていると感じる。研修のRFPをちゃんと出して、研修ベンダー向けに説明会をやってくれる企業は、本当に一部の大企業に限られる。たいていのケースではRFPなんて見たことがないし、まして業界全体で標準的に使われている雛形なんぞあるはずもない。

 研修とITでは投資規模が違うし、最初にしっかりと仕様を決めておかないと後になってプロジェクトが炎上しやすいITに比べれば、研修なんて実施の直前まで中身の修正がきくから、RFPなど必要ないという意見もあるだろう。だが、金額に関して言えば、本書の中で「数百万円程度の小規模なIT導入でも、RFPは作成すべきだ」と述べられている。研修業界でも数百万円の案件ならざらにあるし、研修対象者が多くて同じ研修を何十回もやるケースでは数千万単位になる。個人的に、金額の多寡がRFPの要不要を決めるとは思わない。

 また、確かに研修の直前まで中身を修正することは可能ではあるが、とはいえやはり、早い段階で中身がきちんと決まるに越したことはない。それをせずに、研修ベンダーと顧客企業の間で会議を重ねながら、徐々に中身を擦り合わせていこうとすると、途中で「言った、言わない」の押し問答になりやすい。そういう意味でも、最初に「どういう研修をやりたいのか?」をRFPという形で文書化しておくことは重要だと思うのである。そして、研修ベンダーはRFPに書かれている要求を十分に理解し、さらに行間を読んで最適な提案を行う、というのが理想的な姿ではないだろうか??

 ちなみに、本書で提案されているRFPの雛形はこんな感じ(太字は本書の用語、補足説明は私がつけた)。
(1)趣旨
 システム導入の「目的」を明示する。「業務効率化をしたい」、「システムの操作性を高めたい」という業務・ITレベルの話ではなく、「新しいシステムの導入を通じて、どういう事業・ビジネスを目指したいのか?」という経営レベルの方向性を述べる。

(2)業務要求
 システム導入によって実現させる業務の内容を記述する。これは、(1)の「将来的な事業・ビジネスの方向性」を実現するために、「自社の社員は具体的にどのような仕事・動き方をしなければならないのか?」という問いに答える形で記述するとよい。例えば、「顧客囲い込み型のビジネス」という方向性を掲げたならば、

 ・ロイヤルティの高い顧客を識別するターゲティングの実施
 ・顧客の優先順位に基づく営業担当者のきめ細かいフォロー
 ・メールを活用した自社HPへの効果的な誘導
 ・購買履歴を活用したおすすめ製品・サービスの紹介
 ・定期的な顧客満足度の実施(定量・定性の両方)

などが業務要求となるだろう。

(3)技術要求
 ここはシステム的な要件を書くところ。例えば、「当社が指定するハードウェア、ソフトウェア、OSを使ってほしい」とか、「Webの検索レスポンスは○○秒以内にしてほしい」とか、「パート、アルバイトの方でもすぐに使えるように、画面インターフェースは簡単なものにしてほしい」といった技術面の要望が入る。

(4)運用要求
 システム稼動後の運用・保守に関する要求。「24時間365日のサポートを希望するのか、ビジネスアワーだけのサポートだけで十分なのか?」、「自社で運用・保守できるように保守要員のトレーニングまでお願いしたいのか、運用・保守はベンダーに全てアウトソーシングしたいのか?」など。

(5)予算
 想定している予算。システム導入時にかかるイニシャルコスト(ソフトウェア、ハードウェア、SE、コンサルタントの費用など)と、導入後のランニングコスト(ソフトウェア、ハードウェアのライセンス更新料、運用・保守コストなど)に分けて、大まかな金額を載せる(予算を載せるかどうかは意見が分かれるところだが、本書では駆け引きなしに予算を素直に載せた方がトラブルが少なくて済む、とされている)。

(6)プロジェクト期間
 プロジェクトのキックオフから要求定義、設計、開発、テスト、リリースに至るまでのスケジュールを記載する。

(7)特記事項
 提案書に盛り込んでほしい内容、提案書の提出〆切、提案書提出以降のスケジュール、RFPに関する問合せ窓口などを記述する。
 上記の雛形を参考に研修版のRFPの雛形を考えてみたので、次回はそれについて書くとしよう(今日の記事は前置きだけで終わってしまった、汗)

 (続く)

おススメの書籍

トラックバックURL

このエントリーのトラックバックURL:

コメントする