こんにちは、Hです。
2020年のオリンピック開催都市が「東京」になりましたね！
今後、盛り上がりが長い期間にわたって続いていくこととなり
皆さんの心にもいろいろな楽しみが生まれるんじゃないでしょうか？
プロマネの立場からは開催都市になるまでのプロジェクト、
どんな風に進めていったんだろう？ということや
開催に向けてどんなプロジェクトにしていくんだろうということも興味があります。
話変わってITのプロジェクト。最近では開発の提案に際して、
RFPと呼ばれるユーザからの依頼書・要望書が出されることが多いです。
つい先日、そのRFP作成セミナーを受けてきました。
そのセミナーを受けてRFPの作成や読み取る際のポイントをまとめてみました。
またなぜそのようなセミナーを受けようと思ったのか？
ベンダー側のプロジェクトマネージャの立場として記載してみましたので良ければご覧ください。
受講したセミナーの紹介
受講してきたセミナーは下記のセミナーです。
分かりやすい書籍を出している有名な方が講師です。
一日がかりのセミナーで午前中はRFPに関する基本的な知識の説明、
午後はRFP作成のワークショップとRFP作成プロジェクトの肝のお話がありました。
有料なものだけに中身の濃いものだったと思います。今回は自分のために受けてきたので
自腹で払ったというのも中身を濃くした要因かもしれませんね。（笑）
RFPの目的って？
そのRFP、Request for Proposalと言って、提案に対する依頼書となります。
提案に際してシステム開発の目的や背景、各種要求事項や予算・スケジュールなどを
記述しますが、どうしてこれらを用意するのでしょうか？
何年か前まではシステム開発の営業さんが足しげくユーザに通って情報を仕入れて
それからヒアリングをしてSEとともに提案書を作成する。
そんな流れが一般的ではなかったのでしょうか？
そんなお話がありました。
答えは「ユーザがより良い調達をするため」なんですね。
提案するベンダー側の立場に立てば、ユーザが何をしたいのか？またどうしてそれをしたいのか？
いつ、どれぐらいのコストをかけてしようとしているのか？
そういった内容が明示的に提示されることでベンダー内で各立場の人が集まって
提案方針・内容をより精査に検討することができます。
またプロジェクトそのものにどれぐらいリスクがありそうかを検討することもできます。
ユーザ側についてもRFPをまとめていく過程で自社（自部門）はどんなシステムを望んでいるのか？
どのような計画でやろうとしているのか？
そういった内容を検討、共有、承認を得るというフローを経ることで
自社内でのプロジェクトを認知してもらうことができます。
上手く関係者を巻き込んでいくことでプロジェクトの推進も生まれます。
そして同じ条件に対する提案が揃うことで比較・評価も指針を持って臨むことができます。
結果としてユーザにとってはより適切な調達先を選定することができるわけです。
そういった効果が期待できるRFP。
最近は様々なユーザ企業がRFPを作成して、提案依頼をするのも頷けます。
RFPってどんなことを記述する？
ではそのRFP、どんなことを記述するのでしょうか？
皆さんもいろいろなRFPをもらったことがあると思います。
箇条書きベースのものや既存システムの参考資料を添付でいただいたりとか
プロジェクト計画書とともに綿密に準備されたRFPをいただいたりとか。
セミナーではその内容を読み解いていくと下記のような内容に集約できると紹介されていました。
そう、結局「何をいくらでいつまでにしたいか」を表しているんですね。
またこのRFPはユーザからベンダー側の企業に提示して、相手からその回答をもらいます。
すなわち法人同士のコミュニケーションになるわけです。
ですのでまずは「挨拶」から始まり、今回のシステム開発の「趣旨」を伝えます。
「趣旨」では目的や背景、システム開発による狙いを伝えていきます。
その内容如何で実現方法も変わるからですね。
そしてメインは要求事項。
業務を推進していくための要求事項、技術面や運用面からの要求事項です。
「業務要求」では業務のフローや機能に対する要求に加えて、データに関すること、
画面・帳票に関する要求をまとめていきます。
「技術要求」ではOS・ミドルウェア・ハードウェア、ネットワークなどのインフラ要求や
パフォーマンス、セキュリティ、障害対策といった非機能に関する要求事項がまとめられます。
セミナーでは他システムとの連携に関しては他の要求と違って企業固有のものが多いので、
きちんとRFPに記載することと強調されていました。
「予算」はそのユーザ側のポリシーによることも多いのですが
提示することのメリットを伝えていました。
同じ金額で提案を募ることで内容を純粋にはかることができるからです。
そして「スケジュール」。プロジェクトマネジメントでは
よく「スケジュールありき」が多いですよね。
「要求内容」と「コスト」と「スケジュール」のバランスが適切か、
きちんと提示することでベンダー側にもそれらを実現するための提案の余地が広がります。
セミナーではより細かく説明があったり、事例を踏まえて説明をしたり、
ワークショップを通じて考えさせたりとより深い内容になっています。
もしさらに興味ある方はこのセミナーを受けられてみてはいかがでしょうか？
RFPでは要求が網羅されていること、そしてヒアリングがとても重要
ワークショップを実施していると、「あれ、この項目はどこに記述するのだろう？」
と迷うことがありました。
でもRFPでは要求が網羅されていることが重要だといいます。
要求が網羅されていれば、ベンダー側からの提案で考慮されますが、
そもそも要求が漏れてしまっていては提案から外れてしまい、
後でコスト追加という事態になります。
それをさけるためにも要求の記載場所にこだわりすぎず、
網羅的に記述されていることに意識を当ててほしいと言っていました。
確かにそうですね、要求が記載されていればきちんと検討しますが
記載されていない場合、自分たちが気づかなかったら
提案には入れられないですもんね。
冒頭で述べたとおり、RFPの目的は「より良い調達をするため」です。
そのためにも要求を漏らさず記述するということが大切なんですね。
そして要求を漏らさないためにもユーザへのヒアリングがとても重要になります。
セミナーではあらかじめインタビューした内容が添付されているので
そちらを読みながらRFPを作成していきました。
当たり前かもしれませんが、ユーザは協力的でかつ要求を網羅的に語ってくれていました。
でも実際の場合はどうでしょうか、、そんなにすんなりヒアリングについて
回答してくれるとも思いません。
非協力的というよりはそもそもそこまで考えていないですということが多いように思います。
ですのでヒアリングに関するテクニックや進め方が大事なんだなと思いました。
そのあたりもセミナーではいくつかの方法を紹介してくれていました。
根回し、承認、役員会など泥臭さはやはり大切
どうにかこうにかしてまとめたRFP。
これを社内で認知させること、プロジェクトの成功のためには避けて通れません。
エンドユーザーの発言権が強い人が「そんなの聞いてないよ？これじゃ業務回らないよ」といった
発言でちゃぶ台返しを食らった人も多いと思います。
最近はやりのドラマであれば「やられたらやりかえす、倍返しだ！いや10倍返しだ！！」
と言いたいところですがそうはいかないのが現実ですよね。
ベンダー側と追加コスト・スケジュールの話をしたり、再稟議をかけたり、、、
出戻り作業は枚挙にいとまがありません。
そんなことを避けるためにも発言権の強い人、権力のあるトップ、プロジェクトオーナー、
役員会の決裁などなど「企業内で企画を通すために必要なこと」は
外してはいけないのですね。
この辺りは事例含めてお話をいただき、説明に重みを感じながら聞いていました。
みなさんはいかがでしょうか？
そういった稟議のフロー、きちんと押さえているでしょうか？
最後に~セミナーをどうして受けたのか？~
さてこのセミナー、ユーザ側でRFPを作成する上でのポイントを丁寧に教えてくれるセミナーでした。
ただ私はベンダー側のプロジェクトマネージャです。普段はRFPや要求書をいただいて
それをもとに提案や見積もりを作成する立場です。
ではどうしてこのセミナーを受けようと考えたのか、、、
それは「ベンダーの都合でなく、ユーザにより良い提案をするために
RFP作成時にどんなことを考えて記載するのか」を知りたかったからです。
私も会社員の一員です。
ですので提案時には自社の都合や利益を考えます。
でもそれが必ずしもユーザ企業の利益とは一致しないんですね。
「ユーザが実現したいことは何か？またどうしたらユーザの利益になるか？」
プロジェクトマネージャとしてはまずこのことを考えて踏まえたのち
自社の都合や利益を考慮した提案にしたいわけです。
だから自腹でこのセミナー受けてきたわけです。
そして受けてよかったと思っています。
新しい気持ちで次の提案・見積もりに臨んでいけます。
お土産に講師の方の著書もいただきました。
これはゆっくり読ませていただこうと思います。
