2025-07-07 17:17

第45回「RFPってなに?見積に必要なの?」

spotify apple_podcasts

第45回目のテーマは「RFPってなに?見積に必要なの?」です。

今回は、システム開発を検討している企業の担当者なら一度は聞いたことがある「RFP」についてです。

「RFPってそもそも何?」「どういう内容を含めればいいの?」

そんな疑問に、システム会社の視点からわかりやすくお話ししています!ぜひお聴きください!

------------------------------------------------------

▼ホスト:島田徹

▼MC :鴨志田怜

▼ゲスト:辰巳純基

------------------------------------------------------

▼お便りメール

メッセージをお待ちしております!

Googleフォーム: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://forms.gle/DCema6crfoux1ZAR9⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

------------------------------------------------------

▼株式会社プラムザ のホームページ

 システム開発などでお困りの事があればお問合せ下さい。

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.plumsa.co.jp/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

------------------------------------------------------

▼𝕏アカウント

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠♯ふてはな⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ 』で番組の感想、ご意見、質問など、ポストしてくれた投稿には返信することもあるのでぜひフォローお願いします!

 ・番組𝕏: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@futehana⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ 

------------------------------------------------------

サマリー

今回のエピソードでは、RFP(提案依頼書)についての基本的な理解や、その必要性について議論されています。また、RFPがシステム開発においてどのように活用され、クライアントとのコミュニケーションを円滑にするのかが解説されています。このエピソードでは、RFP(要求定義書)と要件定義書の違いや、見積もりを取る際の重要性についても論じられています。さらに、RFPが見積もりを依頼する際にどのように活用されるべきかについても触れられています。

RFPの基本理解
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
さて今回のタイトルですが、RFPって何?見積りに必要なの?というタイトルになります。
なかなか僕もこの業界に携わるまでRFPというのをなかなか聞いたことがなくてですね、あんまり一般的にも知られている言葉ではないのかなと思うんですが、開発を依頼しようという段階になると、ちょっとネットとかで見るのかなというようなイメージなんですが、
まずすみません辰巳さん、RFPというものはどういうもので、どういったときに使っているものなのかとお伺いしてもよろしいでしょうか。
僕もこの業界に入ってからやっぱり知りました。RFPですね。リクエストフォープロポーザルというふうに正式名称は言われていまして、日本語だと提案依頼書だとか要求定義書とかいろいろな言い方されますけど、
要はこのシステムをこういうふうに作ってほしいと、お客さんからベンダー向けにお送りする書類の内容ですね。
じゃあ実際にどういうことが書いているかというと、予算これぐらいがいいですだとか、あとは何でしょう、このぐらいまで必要ですとかっていうのをざっくり書かれたりしますよね。
僕らが使っているプロにあいみつ案件の詳細ページみたいなところもそれに近い状態ですね。
それが過剰書きになっているのか、ドキュメンテーション形式になっているのかだけの違いであって、そういったものに類すると思いますね。
確かにいろんな案件が見れると、プロニーさんだけではなくいろんなサイトあると思うんですが、見る限りだいたいこれは言うよねみたいなところは決まっているような気はするんですけど、
具体的にRFPっていったらこれを書きましょうみたいなテンプレみたいなものは会社ごとにあるかもしれないですけど、基本はないと思っておいていいんですかね。
基本フリーフォーマットですよね。別にこういうわかりやすく言うと履歴書みたいなものみたいなフォーマットは当然ないですし、書き方なんてセンサー番別ですけれども、
でも最低限やっぱりさっき言っていた予算も書いてない人ももしかしたらいるかもしれないですね。
もっと言うとRFPという概念すらない状態でお問い合わせを全然されるっていうお客さんもいらっしゃると思うんですよね。
それはそれで我々としてはもう問題ないですし、ただそこのヒアリングから入りますよというだけのステップの違いかなというふうに思っています。
なるほど。いずれにせよ、基本的にRFP、要求定義書というものは開発するにあたって必要で、それを用意してくるクライアントさんもいれば、
特にそういった言葉もまず把握しないというお客さんであっても、ヒアリングして結局は詰めていく内容のものっていうところですかね。
そうですね。そもそもそういったことをRFPだと理解しないで送られることの方が多分多いんじゃないかなと思ってるんですね。
これが実際のRFPですって言ってドキュメンテーション原始できっちり送られるお客様の方が逆に少ないとお見受けします。
RFP作成のポイント
それが別にないことが悪いというわけではないですけれども、ここはたぶんお客様の方で前段階で決まっていると認識のズレがなくなりやすかったり、
我々の提案のスピードも結構速かったりするので、あってより良い提案だったりコミュニケーションのスピードが保たれるんじゃないかなと思っています。
なるほど。ありがとうございます。これちょっと個人的にも気になったんですけど、これ島田さん開発されて長いと思うんですけど、これ開発当初からあるものなんですか?RFPみたいな言葉とか。
RFPですね。昔はそんなこと聞いてなかったかな。
へー、そうなんですね。
このスクリプトも15年、20年くらいは聞いてなってたかな。
ない時であっても同じようなことはしていたような気がするんですが、そんな感じだったんですか?
それはもちろんね、お客さん何やりたいのかとか、いつまでに欲しいのかとかっていうのをまとめておいてくれると話は早いですよね。
それですよね。それがちゃんとまとまっているものがRFPであって、まとまっていないとそれをヒアリングしながら引き出していくみたいな。そんなことありますよね。
なるほど、ありがとうございます。特に用意してくださっているのであれば話が早い部分もありますが、結局そんなことをわかっていなくても話し合いとかヒアリングの中で詰めていきますよというところだと認識しておりますが、
RFP要求定義書を具体的にどういったことを聞いていくのか。先ほど辰巳さんから予算、あとスケジュールって話がありましたかね。
そうですね。
あと他には大体どういったことはまず前提として聞くっていうところをちょっとここでお伝えできればあらかじめそんなこと聞かれるんだなとか、あらかじめまとめておくってことがクライアントさんもしやすいのかなと思いますので、
ちょっとここでいろいろお伺いしていければと思います。まず予算とスケジュールとあとどういったものが辰巳さんありそうですか。
そうですね。ざっくりここは聞くよねっていうのをちょっとつらつら話していこうかなと思ってるんですが、やっぱりこの5W1Hってあると思うんですけど、
いつ誰が何をなぜどうやるのみたいなって話があると思うんですけど、基本それに関係図終始するのかなと思っていて、
じゃあユーザーは誰が使うんですかと、いつ使うんですかと、どのようなシーンでどうやって何を使うんですか、どういったデータとかを取り扱うんですかとか、
それはなぜ必要なんですかっていうところが見えてくると、イコールそれがシステムの開発におけるゴールなのかなと思っていて、
そうなってくると、それを実現するためにどういう機能が必要なのかっていうことだったりとか、そこはちょっと我々とすり合わせしながらになってくると思うんですけど、
その上で全体像が5W1Hで見えてくると思うんですよね。そうなってきたら納期とか予算感とかが多分それで初めて見えてくると思うんですね。
コミュニケーションの重要性
なるほど。あくまでこの5W1Hで大きな枠というか、全体像みたいな思想も含めて把握した上で、その中から予算スケジュールに下ろしていくみたいなイメージですかね。
そうですそうです。すごい極端な話ですけれども、1日の中で1時間も使わないようなシステムだったら、じゃあそれってスケールものすごい小さいものだと思いますし、
それなりの日中で1時間も使うけれども、ユーザーが100万人いるとかそういう話だったら、とてつもないスケールの話になってくるじゃないですか。
だからそこら辺の5W1Hの何かしらの項目が抜けてたりすると、そういうイメージがしにくいので、そこら辺は片びつヒアリングをしていくという感じですよね。
確かに全くわからない業界とか、すごくニッチな業界とかで、業界内では当然みたいなことの認識みたいなものが、5W1Hをちゃんと聞いていくことによって共有されるとか取り逃さないという場合ですかね。
把握に漏れがなさそうな気はしますね。
それを逆に聞いてしまえばある程度ことは足りるのかなと思っていて、あとは細かい話になってきて、ユーザーはいるとして、管理者サイトとかユーザーサイトとかあるよねって話だったりだとか、
これってWebアプリですかとかスマホアプリなんですかってところだったりだとか、スマホアプリじゃなくてWebでやる場合はレスポンシブ対応っていって、
スマホだったりタブレットのサイズに合わせて画面の動きとか見た目を変える必要があるかとか、
外部で例えばLINEを使ったログインしますかとかそういう話になってくると思いますし、
それが機能のものが生まれてくる要求っていうのが具体化されたタイミングで、先方の予算と納期の希望と、
我々聞きながらだいたいもう工数とか予算観とか納期観とかも見えてくるんですけど、そこに返りがないのかっていうところを確認した上で、
たぶん最後に僕がいつも聞いているのが優先順位というか温度観というところで、
例えば前ないとーさんの話でもあったと思うんですけど、じゃあ納期を優先するのか、予算を下げてクオリティだとかスコープっていうのを限定化するのか、
っていうところの擦り合わせを最後にした上で提案の準備を持っていくのかなという感じです。
なるほど、今辰巳さんの話を聞いていて、僕も全く同じことを思い出していて、聞きながら資料を引っ張り出していたんですけども、
ないとーさんの話でお金、時間、品質、スコープっていうものがあって、それに優先順位をつけていくと、
どこを大事にするかっていうのを定めていくって、そこからずれないみたいな話がちょうど思い出して、なるほどと思って聞いてました。
これだいたいRFPを作るというか、ヒアリングするっていうのは島田さんも同じような形でやっていくものなんですけど、
もっと島田さん自然な形でやっているようなイメージがあるんですけど、どうなんでしょう。
自然派。
なんとも言葉が難しいんですけど。
基本的には今マッチングサイトの話を聞くときも、自由に話してもらうようにしている。
あんまりこのぐらいヒアリングしているというよりは、今回掲載されていた案件どんなもんですかねっていう感じで話をしてもらって、
でもやっぱり辰巳さんが言ってることは気にしていて、話を聞きながら登場人物誰なのかなって常に考えていて、
お客さんの方はあんまり意識していなくても、これ別の人出てきたみたいなね。
同じユーザーっていう言葉を使っているけど、これ別物だよねみたいな。
この間もスタッフがログインして使うって言うんだけど、よく聞いていると配送の業者だよねみたいな。
出てきたと思ったらすぐメモして、一人登場人物増えたなみたいなことを考えておくと。
最後にそれをまとめて、結局これ使う人って4種類いますよねとか、確認するみたいなね。
RFPと要件定義書の理解
使うタイミングとか、何のために使うのかとか、何が見えるのかとかっていうのはやっぱり気にしないといけないですよね。
なるほど。
澄さんも島田さんも抑えるところは、コンポン511Hからの棚下ろしって形だと思うんですけど、
僕結構個人的にすごいなって島田さんの話を聞いていて思ったのが、こういうのはワークフローで考えればいいんだよみたいなことを
昔言っていたことを思い出しまして。
というのもこの倫義を通すっていうものが具体的にどういうフェーズだったりとか、
納品から発注をするのが具体的にどうなのかっていうのを、ちゃんとワークフローとか図にして考えたらいいよみたいなことを
言っていたのは今話を聞いていて思い出しまして。
確かにそれであれば自然にそういった形になるし疑問も浮いてくるよなっていうふうに思ったんですけど、
島田さんはあまりそれ意識されず自然にやられてるのかなっていうのを聞いていて思いましたが、
いかがでしょうか。
あれはたぶん、その話をしたのはかなり複雑なワークフローがあるやつなんでね、
そういうシステムってあんまりないんだけど、そのたぶん富士山さんと話したときはすごい複雑なやつで、
あれは一個一個業務をやるたびにですね、一つのUMLっていう図みたいなものでね、
図を起こして誰が何をやるみたいなね、
それを作って抜けがないかみたいなことをお客さんに確認しておかないとやばいなと思ったんで、
あれはRFPというよりはその次のフェーズの要件定義をするときにそれをやったっていう感じですね。
ああなるほど。
あれは要件定義だからね。
うんうん。
あれはお客さんがとても作れるもんじゃないので、
うんうん。
あれを作るためにヒアリング段階でお話を聞いてるっていうことですね。
なるほど。
うん。
同時にはですね、最初にこの業界に携わらせてもらったときに、
RFP、要求定義書と要件定義書の違いがほぼ同意義だと思っていたことを思い出しましたね。
うんうん。
そう、だからお客さんの中でね、要件定義書はないんですっていうお客さんも結構いるんだけど、
いや要件定義書はプロが作るものなんで。
うんうん。
まあでもそれも言葉としたりとか携わってないとたぶん知らないと思うんですよね。
うんうん。
なんとなくどちらかというと、なんとなく要求定義書のほうが聞く頻度みたいなものが高い気がしていて、
うん。
なかなかRFPとか要求定義書っていうのは聞かないなっていうところも改めて今思い出しましたね。
見積もりの重要性
要件定義のほうよく聞くんだよね。
そうそう。
要件定義のほうが聞きますね。
うん。
要求定義、要求しようって言うけども、それはあんまり聞かないけど、
さっきの前半のほうの話で要求定義かなんで作るかっていうと、
はい。
複数の業者に見積もりを取るときにですね、
業者が自分勝手な提案をつけて見積もってくると、どこが安いのかわからないんだよね。
うーん、なるほど。確かに。
そう。だからそういうものをしっかりとこれだけは実現しなきゃいけないとか、
農機とかもね、デバイスとかもそうだけど、それをちゃんとまとめておいて、
その範囲でちゃんと見積もってきてほしいって言わないと、
いろいろと勝手なオプションをつけられて見積もってくると、
ちょっと何がいいのかわからなくなってしまうんでね。
うんうんうん。
それで言うと、最初のお客さんには何もRFPがない状態で見積もりをもらって、
それをベンチマークに他社さんにあいめつ取るみたいなこともやったりしますよね。
うんうんうん。
それであればですね、素直にRFPだけまとめてほしいっていう依頼とかのほうが良さそうな気がしますけどね。
それ一つまとめてもらって、他にも見積もりを取っていくっていう形も、何でしょうか、
こう整併っていうんですかね。
そうですね。
ただやっぱり作っていただいたRFPも、それがそのまま見積もりを出せる状態のものになったりかっていうのは、
ベンダーがチェックを入れたほうが良い気がしますね。
いいほど長年SIer(エスアイヤー)にいらっしゃった方で、今上資して、
そういったシステムとかサービスを立ち上げるためのRFPっていうのはかなり信頼性あると思うんですけど、
そうなってくるとちょっと話は違いますけれども、
基本的には一度問い合わせいただいたタイミングでRFPを見せていただいて、
っていうところは必ず我々のチェックは入れたほうが良いんじゃないかなと思いますね。
ありがとうございます。
そろそろこんなところかなと思うんですが、何か最後に他あったりしますでしょうか。
私は個人的にはコンサルの仕事もやっているので、
RFPだけ作ってほしいとかっていうのを受けられますので、
ご存じいただければと思います。
そうですね。
完全にその要件定義書も含めて、
何が何だかよくわからないけどこういうのが欲しいっていう方とかでもあっても全然大丈夫なんですかね。
大丈夫ですよ。どこまでやるかにもよりますので、
RFPだけ作ってもらいたいっていう方もあるでしょうし、
RFPで業者からの見積もりを集めて選定してもらいたいっていうこともあるでしょうし、
うちもその中に一緒に入らせてもらって作ってもらいたいっていうのもあるでしょうし、
いろいろできますんでね。
ありがとうございます。ぜひお気軽にご相談いただければと思います。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
17:17

コメント

スクロール