RFPの基本情報
こんにちは、シニアソフトウェアエンジニアのriddleです。このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回はですね、SIRでよく用いられるRFPという話をしたいと思います。
これね、何かと言いますと、リクエストフォープロポーサーとの略でですね、SIRって、いわゆるお客さんからこういうシステム作ってほしいんだけど、という依頼を受けて
システムを納品するんですけれども、最初にお客さんがですね、こういうものを作ってほしいという依頼をくれるんですね。
この時に出してくれるのがリクエストフォープロポーサー、RFPってやつですね。でですね、これ何が書いてあるかというと、こういうシステムをこういう理由で作りたいです。
具体的な機能としてはこうこうこうで、満たしてほしい要件としてはこうこうこうで、みたいなことがバババーってスライドでね、
スライドとかExcelとかいろいろあるんですけども、書いてあるものになっていて、SIRとかベンダーはですね、その資料をもとに自社だとこれぐらいできますよっていう見積もりを提示するんですね。
で、その見積もりをお客さんが見て、じゃあここの会社にお願いしようかな、みたいなものを決めるという感じですね。
ちなみにRFIというですね、RFPの一個手前のものもあって、これはRFPを作るお手伝いをするために使う資料みたいなものですね。
RFPは基本情報でも出てくる用語だったりするので、知っている方も多いかもしれません。
私もですね、人生で何回かそのRFP対応ってことをやったことがありまして、簡単に言うとお客さんからRFPが届いて、それをみんなでね、
とっかかりながら、こういう構成がいいんじゃないかとか、ここの見積もり取らないと、みたいな感じで、突貫でね、仕上げてお客様に提出してプレゼンする、みたいなことをやっていました。
RFP対応の課題
でですね、このRFPっていうのがですね、なかなかクセモノというか、大変で、何が大変かというと、まずRFPって仕事のボリュームにもよるんですけど、
100ページぐらいのパワーポイントのスライドがいきなり送られてくるんですよ。いきなりかどうかわかんないけど、送られてくるんですよ。
そこにびっしり要件が書いてあるんですね。こうこうこうで、こうで、こうしたい、あーしたい、セキュリティーはこうで、とか、機器の要件はこうで、こうで、こうで、みたいな。
これ書くのめちゃくちゃ大変だったんだろうなー、みたいなものがね、めちゃくちゃ来るんですよ。はい、っていうのをいただいたらですね、我々はね、お仕事欲しいんで、そのRFPにお返事を出さないといけないんですよね。
お返事っていうのは見積もり書ですね。で、だいたいですね、締め切りが決まっていて、まあ1ヶ月後までに出してくださいと、で、プラスプレゼンもしてくださいという感じなんですよ。
で、そうなるとSIRで何が起こるかというと、まずRFP対応のためのチームがいきなり組まれるんですよね。で、それまではね、もともとプロジェクトとか何もなかったんですけど、まあそういうRFP対応ってのはいきなり降ってくるんで、そうするとまあそれに合わせてチームが編成されると。
で、内容にもよるんですけども、大きくはアプリケーションとインフラの複合のものが多いので、アプリの人間もインフラの人間も集められると。
しかもですね、RFP対応って難しいのは、こういうものを作りたいですっていう資料が飛んでくるんで、その集まった人たちの中でそれを実現するための方法とかをまずゼロから考えた上で、じゃあこういう技術が必要だよねとか、ここにはこれぐらい工数がかかりそうだよね、ざっくりみたいなものを見積もるんですよね。
そうなるとですね、技術的にもいろいろ知ってないといけないし、かつちゃんと見積もりもできないといけないということで、いわゆるサイヤーの中でもグレードが上の人が結構何人も取られるって感じなんですよ。
大変なのは、ちょっと会社にもよるかもしれないんですけど、私がいた会社ではこのRFP対応って別にお金もらってやってなかったんで、もうね大変なんですよ、お金もらってないんで。
もちろんこれが受注できて仕事につながればめっちゃいいですけど、こういうRFP対応ってお客さんはですね、複数社に投げてるんですね。
複数社に合意見積もりも取って、プレゼンしてもらって、その上で一番いい数字を出してきたところとか、一番いい設計とか考え方をしているところっていうものを最終的に一社だけ選んでですね、
そこの会社と取引を始めるので、やっても別に契約に結びつかないということはまあまああるわけですよ。
まあまああるにしては、その見積もりに対するコストがめちゃめちゃ高いんで、これはねなかなかしんどいですよね。
例えば私がやったやつだと、AWSを結構バリバリに使った案件でして、当時私はAWSそれなりに詳しかったので、
その結構なシステムをAWSで構築するためのシステムのアーキテクチャーズみたいなのを書いて、AWSさんにちょっとレビューしてもらったりとか、それに必要なコストとかも一個一個いろんなサービス動くんですけど、算出したりとか、
で、これちょっとなんかセキュリティ的にヤバそうだぞみたいなものは別のセキュリティ製品に突っ込んだりとかで、そうするとセキュリティ製品を突っ込むってことは、そのセキュリティ製品を扱っているベンダーに見積もり依頼をして、
で、見積もりを出してもらうみたいな感じがあるんですよね。で、当時いた会社はですね、マルチベンダーということで、いろんなベンダーさんとお付き合いがあったので結構自由に選べたんですよ。
というのは例えば、自社でセキュリティ製品を持っている会社だと、その会社の製品を使わないといけないみたいな制約もあったりするんですけども、私がいたところはそういう制約なかったので、自由に選べるんですね。
で、自由に選べると、今度はその中で何を選べばいいかっていうのがあるんですけど、大体の機能ってもう揃えてるんですよね、大体の製品は。
そうなると、その中から一番安く使えるとか、ディスカウント、値引き率をどれだけ引き出せるのかみたいな交渉を各ベンダーとしないといけなくて、
そうすると、ただシステム組み上げられるだけなのに、使うベンダーの数が増えれば増えるほど別個に調整していかないといけないみたいなとか、
営業さんがうまくディスカウント引き出してくれて、それを入れてとか、そういうことをやってるとめちゃくちゃ時間かかるんですよね。
しかも、ここでこの製品使いますって言っといて、後で蓋開けたら使いませんでしたってなるとしんどいしから、それもないようにいろいろ調査したりとかすると、
ビジネスにおけるRFPの影響
まあまあまあまあまあ、見積もりはね、ほんとめちゃくちゃ大変なんですよね。抜け漏れがないようなチェックとかね。
まあもちろんですね、これ出してくれるお客さんがもうつらくてですね、穴のないようにシステムの要求一覧みたいなものを作ったりしても相当しんどいと思うんで、
これはねやっぱり大規模なシステムを作るのはみんな大変なんだなということはよくわかりますね。
なんか大きいRFP作って、お客さんに見積もり投げて、取れるとねめっちゃ嬉しいんですけど、取れないとね、やっぱりあんなに頑張ってもダメだったのかな、持ってかれたなーみたいなことで落ち込んだりもしますね。
幸せなのは、それだけやりがいのあるRFPにぶつかれればいいんですけど、たまにね、受けたくない仕事とかもあるわけですよ。
ただ、お付き合い上ですね、RFP対応はやらないといけないみたいな、仕事としては欲しくないけど見積もりは出さないといけないみたいなシーンとかもあったりしてですね、
そうすると、なんか通常は値引きするようなものを全然値引きしなかったりとか、明らかにちょっとお高めにつけるとか、そういうことを各社やってるという話も聞いたことがあります。
お客さんからしたらたまったもんじゃないですけど、やっぱりビジネスやってる以上受けたくないものは受けたくないっていうのはね、どこもあると思いますので、そういうね、応酬があるというのがRFP対応でございます。
ある程度大きなエサイヤーだったらやってること多いんじゃないかなと思いますが、最近は結構なじみのところにそのまま頼んでしまうケースもあるかなと思うので、
なかなか大きいRFP対応に巡り合うことは少ないかもしれませんが、もし巡り合えたらですね、ちょっとラッキーということで、ぜひ頑張ってください。
はい、このポッドキャストはハッシュタグリルITで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますので、そちらからのご投稿も大歓迎です。ありがとうございました。
