SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

EnterpriseZine(エンタープライズジン)

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

マイクロソフト北川さんとお話

「RFPの書き方はすごく大事!」という話―この世の受発注にかかわる、すべての方に


RFP―提案依頼書。ユーザーがベンダーに「こういう風に提案してくださいね」とお願いする文書です。書き方も読み方も、捉え方も、いろいろあるようです。今回はデータベースのRFPの話ですが、あらゆる受発注関係における普遍的な話のようでもあり…

 

RFPとはどのようなものなのだろう

 ―今日のテーマはRFPです!どうぞ!

 北川:RFPの話は、結構言いたいことがたくさんあるというか、お客さんが作っていないケースもありますしね、結構つらいよね。っていうか、弊社にも相談してほしい!率直に言うと作らせてほしい。

 ―つらいとは?作らせてほしいとは?

 北川:はい。話したいことはいろいろあるんですけど。僕も作りたい。

 ―あれは誰が作ってるんですか?

 北川:え、基本的にはお客さんが作るんですよ。

 ―「基本的には」・・・?

 北川:基本的には…。だけど、なんていうか、時として、うん・・・こう、RFP作成のフェーズで、何か意見を反映させる、機会を、いただけたりなんかする場合があって、あの…何気に自社製品の、優位性をアピールできるような…ポイントを…したりなんか…したかったりしたりするので…

 ―なんでそんなにたどたどしいんですか!!ところで、最初に確認ですが、REPは、お客さんが作って、それを複数のベンダーに渡すものなんですか?ベンダーごとにRFPの内容が違ったりすることもあるんですか?

 北川:なるほど、まず、そこからですね。その前に、まずRFI (Request For Information)っていうのがあるんです。これは、お客さんからですね「こんなことをしたいんだけど、どうやったらできる?」みたいなことがあるじゃないですか。

 ―こんなことってどんなことですか?

 北川:こんなことってたとえば、なんだろう、貯めたログを分析して・・・いや、分析って曖昧ですね、貯めた売上データを分析したり、売上に影響を与えた要因、ソーシャルメディア等の要因を分析したりしたいんだけどどうやったらできる?とか。あと、この製品ってこんなことができるんだよね?とか、そんなのがあるんですよ。ちゃんと、定義もされていて、RFIを検索エンジンで調べてみると、オルタナブログとかにもよく書いてあるの。

 ―あ、ではRFIについてはそれで。

 北川:こんなことできますか、とか。このオルタナブログによれば、「この製品の実績ってどうなの?」とか。

 ―パンフレットに書いてあるようなことですね。

 北川:ざっくりと。そのあと、REPっていう、ええと何の略だ、Requestほにゃららっていう。

 ―ほにゃららって。

 北川:Request for Proposalだ。要は、こんな風に提案してねっていう文書です。提案依頼書っていいます。

 ―提案依頼書って言葉だけだと、スっと頭に入ってこないですね・・・

 北川:提案してほしい会社にお客さんが出すというのが前提です。そこには、提案のための、提案に必要な情報が書かれている。

 ―うちのウェブサイトにもサンプルが掲載されています。

 北川:要は、今回の目的はこうで、概要があって、提案があって、提案手続きがあって、選定方法とかがあって、作業に関する条件とか、何かしてくれるかとか、保証ってこうだよ、とか契約形態ってこうだよ、とか書いてあります、と。で、古くなったからやります、とか、そんなことが書いてあります。で、目的要件で、こんなことやりたいんですって。

 ―それは、ユーザー企業の情シス部門の人が書いている?

 北川:そうそう。基本的に発注する人が書きます。で、まれに「バックアップについては、フルバックアップで一旦見積もりお願いします」とかばっくりとした要件が書いてあって。でも、こういうのが危険で!

 ―危険?

 北川:「一旦見積もりお願いします」っていうあたりが!プラットフォームを明示的に指定しないのも危険です。「弊社にとってメリットのあるご提案を」というのも危険です。

 ―何が危険なんですか?

 北川:漠としている!で、こんなスケジュールでやりますよ、と。でも「一旦見積りお願いします」なので、今後どこかで多分高い確率で見直しがくる。見直し入ってしまうと、当然提案も変わってくるはずなんですが、プロジェクトが進んでいると、大幅に変更できなくなってたりして…。

ばっくりとは。

 ―つまり、漠としていることが危険なんですね。

 北川で、漠としてて厳しいのが、「現行の処理が実現できること」っていう要件ですよ。これを言われると、じゃあ、変えなくてもいいじゃん、って思ってしまうじゃないですか。今やっていることができればいいのであって、その他は任意要件になってしまうように見える。多く満たしたほうが勝ちなのか、任意だからどうでもいいのかがわからない。全体的に要求が漠としている。

 ―漠としていて、どこを優先したらいいのかわからない?

 北川:そう。RFPを読み解いて、行間の期待しているところを考えたうえで、がんばって、みたいな。あ、だけど、この記事に掲載されている見本はいい見本だと思いますよ。

 ―ありがとうございます!この記事なんですけど、いまだによく読まれている人気のページなんですよ。それで、ああ、RFPって大事なんだなあって思ったわけなんですけども。

 北川:大事なんですよ!ものすごく大事なんですよ!

 ―大事感が、わかるような、わからないような。

 北川:なんて言ったらいいのか、こう、RFPといっても、細かく書いて定義してくるところと、ばっくりしたものがあるんですね。

 ―ばっくり。

 北川:ばっくり。漠として、ざっくり、ですよ。あるところに、ばっくりしたRFPがあるとしましょう。このRFPはなにを言わんとしているのか?

 ―ばっくりと提案依頼します、ということ?

 北川:それはそうなんですが、つまり、どういうことかっていうと、この、ばっくりさにちゃんと付き合ってくれて、誠心誠意やってくれたら…。みたいな。

 ―なるほど!ってわかるような、わからないような。要は、融通きくところと付き合うわ、あたし!みたいな感じでしょうか。

 北川:これに対して、僕らとしても、提案の際には、「ある程度変更が発生しても、それをカバーできるスケジュールや費用を加味したうえで…」っていう、こう、不明瞭さを含めてばっくり感満載の提案になったりならなかったり…。

 ―ばっくり感。

 北川:逆にね、細かくきちっと定義するところは、ドライに判断するんで、「ばくっとやりますから!安心してください!」っていったところで採用してもらえないわけですよ。細かく書いてあるところに、ばくっとやるっていってもしょうがなくて、さっきみたいにばくっと書いてあるところに対して、ばくっとやりまっす!みたいな。もう人間系でがんばりますから!みたいな。

 ―ばくっと。

 北川:細かいところには細かく!ばくっときたところにはばくっと!

 ―それは、RFPを読んで判断するわけですね。

 北川:弊社のケースだと、共同提案いただけるパートナー様と相談したり。

 ―「これは、ばくっときてますよ!」みたいな?最初はお試しで、うまくやってくれたらしばらく付き合うわよ?みたいな?

 北川:まあ、なんとなくそんな感じなのかもしれませんね…。

あらまほしきRFPのすがた

 ―どっちのほうがやりやすいんですか?細かいのと、ばっくりとだと。

 北川:細かく決まっている方に決まってるじゃないですか!

 ―そうなんですか。

 北川:たとえば、ばっくりしたほうなんですけどね。まずは、要件ですよ、要件。要件っていうのはね、ないといけないってことですよ。「BIツールが必要」と、あったとしましょう。で、その中の帳票作成の項目とかで「開発生産性が向上できることが望ましい」と。で、「開発生産性とはなにか」っていうのは定義されていなかったりするんですよ。ね?

 ―何をもって開発生産性が向上したというのか、と。

 北川:そうそうそうそうそう!何をもって僕らは開発生産性が向上しますって主張すればいいのか。あと、「データ量の増加が予想されるため、スモールスタートで、拡張できるのが望ましい」とあったとしましょう。これは、どれくらい拡張できるのが望ましいのか?「効率よく移行できるのが望ましい」・・・いや、効率よくってどういうこと?修飾詞が多いんですよ!

 ―修飾するとなんかこう、伝わりそうな気がするじゃないですか。良かれと思って・・・

 北川:あと「このサーバーを変えましょう、あとアプリケーションも改修してください。」って依頼がある。で、RFPには「移行には考慮が必要」と書いてある。考慮?考慮???何を考慮すればいいの?って、なるわけです。たとえば「新しいアプリケーションの説明書と移行のトレーニングを提供」することで「考慮した」ことになるのか、とか。

 「アプリケーションの改修も」の中には、現在利用されている「アプリケーション①」と「アプリケーション②」があったりする。で、改修するときに「今やってることと、まったくおんなじ操作」を重視するのか、重複する機能があったりする場合には、統合したりしないんだっけ?とか。「現行の処理が実現できること」だったりすると「今やってることと同じことがあたらしいツールでできればいいぜ」っていうことかと。いやいや、効率化って、ゆったじゃん!とすると「今やってることと同じでいいの?」って思うわけです。あと、クライアントは新しくしないんだ?とか、既存のアプリケーションは継続とします、とかね、いろいろあるわけですよ。

 ―おまえら変える気あるんかい、と。本当は何も変えたくないんじゃないでしょうか。変えたいけど変えたくない…人間には誰しもそんな側面があるのではないでしょうか。

 北川:もう、どうしたのものかと。もちろん「新旧システムが混在することを考慮」という要件が入ってくることもある。なのに、要件で定義していない特殊運用が発生しないように設計してね、と。いやいやいやいや、要件の中で運用の定義、「バックアップはフルバックアップ」ぐらいしか定義されてなかったけど?とかね。ばっくりしてたら、もうよくわかんないんですよ。

 ―そこは察してほしいんですよ!

 北川:で、たとえば、要件のところになにも書いてなかったのに、突如として保証要件で「拠点におけるレスポンスタイムは3秒以内」とかでてくるわけです。ということは、3秒以内に返ってこないといけないのか、全部3秒かと。さすがに全部 3秒を保障するのは難しいでしょう。

 ―その他詳細は後ほど取り決めしましょう、みたいな感じですよね。

 北川:全部3秒っていうのは、すごく雑なんですよ。たとえば、こんな画面でクエリを実行します。そのとき、このクエリが何秒以内とかだったらわかるんだけど、全部3秒はないでしょう。たとえば、日付範囲を広く設定して、大量のデータが返ってくるようなクエリにしたら、画面表示まで含めて3秒では終わらないかもしれないじゃないですか。だから本当は、あらまほしきは、現行こういうことをしていて、これと同じ処理を実現してくれればよくて、その処理は何秒以内に終わって欲しいですとかね。それが、こう、画面ごとにあるとか。そうであってほしい。

 ―RFPもらったら、もらったほうは、言われたとおりに提案するしかないんですか?

 北川:その要件を外さず提案するんですよ。

 ―RFPがばっくりしていると提案もばっくりするんですか?それとも、ばっくりした提案にたいして、細かく提案する?

 北川:うーん…って、やっぱり、この話だめですよ!記事にならないですよ!

 ―書きますけどね。

 北川:だってね、これね、RFP出しますと言ったときににね、たとえば、小泉さんが、僕と西脇さんにRFPを出しましたとしましょう。しかも、おもいっきりばくっとしたRFPを出したとしましょう。西脇さんは、「あ!これで大丈夫です!やります!」という。一方の僕は「小泉さん、これ信頼性ってどれくらいの信頼性だったらいいんですか?1日1回落ちたらだめですか?それとも1ヶ月に1回ならいいすか?」とかいろいろ、聞いてくるとする。小泉さんは、コイツめんどくせえなあと思いながら「いやあ、1年間に3日くらいとまってもいいよ」って答える。これに対して僕が、「1年間に3日間は、72時間じゃないですか、72時間を毎月に分割すると12で割るから、1ヶ月あたり6時間止まっていいわけじゃないですか、1ヶ月あたり6時間あたりとめて、メンテするような提案でもいいんですか」と…

 ―めんどくさいです。

 北川:「1ヶ月に6時間止まっていいなら、月例パッチあてて再起動してもいいから、安くするためにフェイルオーバーできるような構成にしなくてもいいですよねえ?」とかきいてきたりして。

 ―めんどくさいので、おひきとりください。

 北川:でしょう!?「うざー」ってなるじゃないですか!だから、ばくっと出してきた人にいろんなこまかく質問したところで、ねぇ…。

 ―なるほどなるほど。実際やるとしたら、細かいことを詰めていかなければいけないけど、そのことはさておき、レスポンスとして、ですね。アティテュードとしての、ばっくり、ですね。

 北川:そう、ばくっと答えるしかないんですよ。そのときに、将来、小泉株式会社は合併する予定があってデータ量が増える予定です、と言われたとしても、「合併するときってデータ量2倍になりますか?3倍になりますか?」なんて聞いちゃいけないんですよ。さすがに将来の話は予見できないでしょうし。

 ―もぉー、増えるっつってんじゃん!(イライラ)、みたいな流れに。

 北川:でしょ?そこで、「現状のデータサイズ、どうなってるかご存じですか?」とかいちいち聞かれても。そうすると、「あいつナシ」って思うか、「ばくっとでいいよ、ばくっとで!」ってなるでしょ。そうすると、じゃあばくっと、コストって書いてあったから、高いと採用してもらえないかもしんないから、まあ、データ増えるっていっても2倍以内でしょう、くらいのね、勝手にこう、シミュレーションをするわけです。たとえば、1年あたり3日はダウンタイムを認めるっていったから、均すと1ヶ月あたり6時間で、それだったら、パッチ当てて再起動したりとかしてもいいかな。いいのかな?

 ―いいんじゃないですか。

 北川:しかもね、むずかしいのは、1ヶ月あたり6時間をならしたら、1日あたり何分って考え方もあるし、1ヶ月あたり6時間落としていいんだから、毎月第2火曜日の月例パッチがあるときに、夜中にドコーンと6時間メンテナンス作業してもいいねって思ってるかもしれないじゃないですか。っていう齟齬が発生してきて、むこうからしたら、「なんだよ、これ1ヶ月に1回6時間もダウンタイム発生するの?」みたいな。

 ―こっちからしたら、「おまえが落ちていいって言ったんじゃん!(裏声)」ってなりますよね!

 北川:合併してみたら、2倍と見積もっていたデータが4倍になっちゃいました、とかね。「データ増やせるようにしといてって言っといたよね?」「え、無理っすよ、2倍までしか想定してません」なんてことになる。それで、「3秒でかえってこないじゃん!」「2倍までなら3秒でかえってくるんですけど、4倍だったら80秒くらいかかります」みたいになっちゃうかもしんないじゃないですか!だからRFPって大事なんですよ!

 ―はい!なんだか大事だという勢いだけは伝わりました!

 *つづく

北川さん(撮影:加山恵美さん)
この記事だけだと若干偏りがあるので、
会見中のすごくまともな北川さんの写真(撮影:加山恵美さん)

 

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
マイクロソフト北川さんとお話連載記事一覧

もっと読む

この記事の著者

小泉 真由子(編集部)(コイズミ マユコ)

情報セキュリティ専門誌編集を経て、2006年翔泳社に入社。エンタープライズITをテーマにイベント・ウェブコンテンツなどの企画制作を担当。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/4844 2013/05/28 12:44

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング