ばっくり担当の北川です
―なんでわざわざRFPという文書が必要なんですか？打ち合わせすればいいだけでは？
北川：そりゃ、言った言わないになるからですよ。誰が見ても、きちんとした条件がある、というのがないと。
―そこはRFPは絶対で、チェック項目みたいにシステマティックに確認していく？
北川：そうそう。
―RFPに書かれたことに加えて、プラスアルファの提案はあるんですか？
北川：それはあったほうがよいでしょう。ベンダー次第ですけども。プラスアルファするから1000万高いっていうのは、「その分はいらない」って言われてもいいリスクですよ。「そこまでやれるんだったら、じゃあ、それも含めてやろうか」っていってくれるところもありますし。だけど、基本的には、スコープっていうのがあって。
―スコープ。
北川：たとえば、「インフラ構築」っていうスコープと、「アプリケーションの構築」っていうのと、「BIツールの導入」っていうスコープがあったとします。このスコープから外れることを、アドオンで提案したとしても、そりゃもうなんか、この提案とは関係ないよねっていう世界です。ただし、ここに「アプリケーションの構築」っていう項目があります、で、「①と②っていう既存のやつをそのまま使えるようにしてほしいよ」っていう要件があります。なんだけど、その回答を出しておきながら、第2案として統合案をつけるのは自由ですよ、と。なぜなら、提案しているBIツールは統合案も実現できるから、みたいな。で、「統合案は、①と②を移行するんじゃなくて、実現したい処理をヒアリングしてイチから作るから、①と②の移行に関してのテストや互換性に関してのテストがない分、統合案は安くなります」っていうと、第2案が選ばれる可能性もあります。
―スコープの範囲内であれば、ある程度自由度はある、と。
北川：ゼロではないです。でも、オンプレミスでのインフラ構築、アプリケーションの構築、BIの導入って書いてあるのに、「クラウドにしましょう」っていう提案はNGです。
―傾向としては、RFPっていうのはばっくりしているほうが多いんですか？
北川：むずかしい質問だなあ。僕は提案するロールではなくて、社内では「Product Marketing Manager」と分類されるロールなんですよ。もちろん、お客様の要望にお応えするために、製品説明とか、ロードマップの説明とか行いますが、どっちかっていうと提案するより、製品をどのように訴求するか、マーケティングプランを考えたりとかすることが主なわけですよ。
―そうだったんですか…。
北川：そうなんですよ！その僕のところにまわりまわってやってくるものは、正しいロールの人が対応しずらかったりするものだったりするので、ばくっとしているものが…。だから、僕に質問されると「ばっくりが多い」という答えになるんだけれども、それは特殊な環境によるもので。コンサルタントが自前で対応するものって、もっと厳密に定義されているものが多くて、厳密に定義されていると「こんなことできるって言ってもいいですかね？」とはならないので、僕が目にする機会はあまりなくなる…
―じゃあ、ある意味、ばくっとしているから北川さんのところに回ってくるってことですかね。
北川：はい。僕のところに回ってくるっていうことは、製品の将来性とか、要は評価しづらい何かが入っていることですよね。
―じゃあ、ばくっとした部分の余白感、いいじゃないですか。ちからの見せ所というか。
北川：いやいやいやいや、余白感がどう判断されるかわかんないですよね。データ増えますっていってるけれど、2倍になるのか3倍になるのか4倍になるのか回答ない、と。そこで、「うちSSDアプライアンスなんで、データ3倍だろうが4倍だろうが大した時間かからないっす。しかもキューブつくっちゃうし、キューブに対しての分析クエリだと高速ですから！」っていう、ばっくりとした答えを…。
―ばっくり担当。
北川：ばっくりしてなくてよければ、コンサルタントがPoCとかやって済ませればいいじゃないですか。そのばくっとした話に、たとえば僕がいってばくっと答えて、某社から誰かが行って、いや XXX だから大丈夫ですよってばくっと答えて、また別の会社の誰かが、ばくっと答えて、…。その「ばくっとした複数の回答」は、一体どれがいいの？
―（笑）。おもしろいですねえ。
北川：おもしろくないよ！
「やだな」の部分を書いてほしい！
―そろそろまとめさせてください！RFPのレスポンスとして、提案書があるわけですよね。提案書って誰が書くんですか？
北川：SIerさんですね。マイクロソフトとして書くときもあるけど。たとえばこう、デモしたとき、デモの構成をルールに則って書くわけですよ、ピヨピヨピヨって。
―ピヨピヨピヨって。
北川：デモをしろっていう要件に答えるためのものですけどね。「デモをしろ」って要件の中に書いてあるわけですよ。デモをしろって。
―そんなに何度も言わなくても（笑）。基本的には、北川さんは、RFPを書くわけでもない、提案書を書くわけでもないのに、両方に深く関わっているんですね。
北川：読み解いていく。こういう項目が入っているからこんなことしましょうとか、このばくっとしたところはこういう風に答えていきましょうとかってやるんですよ。経営戦略とか、ばくっとしてますからね。たとえば、「増収増益」。
―ばくっとしてますね！
北川：増収増益のためには、新規顧客の増加と営業ひとりあたりの担当顧客を増やさないといけない。ってことは、営業さん1人当たり何社対応しているとか、どれくらい客を増やしたかとかね、見えないといけませんよね、とかね。システムを知らなくても、読み取れる範囲があるじゃないですか。
―おお、すばらしい。
北川：たとえば、先ほどのサンプルにも「多品種小ロットの顧客ニーズに対応する」とか書いてあるから。顧客情報を管理・分析する。顧客情報をちゃんと見れないとだめだな、とか。トレースできるように、連携できる仕組みを持たせないといけないのねとか。この記事のお手本は細かくていいですね。
―ありがとうございます。
北川：こいつを刷新しまーす、で、運用経費も含めた削減を狙います、と。ただコスト削減したいですじゃなくてね。これをやりたいです、で、中期目標こうです、多分スケジュールもひいてあるでしょうね、解決したい課題が入っているじゃないですか。
―でも、何が自分たちに必要かって、むずかしいですよ。これを自分たちで書く、つまり、自分たちで何を欲しているかを明確にするのってすごくむずかしいとおもいます。RFPは結局、誰ががんばればいいんでしょうか？コンサル？ユーザー企業の情シス担当？
北川：困ってるのはだれかって話ですよ。たとえばそのシステムが古くて保守が受けられないことが原因なだけで、そのシステムは、実は現状、誰もが満足して使ってるんだったら、刷新しなくてもいいじゃないですか。そのままアップグレードしてくれればいいじゃないですか。だけど、たぶんそのままアップグレードするのもどうなの？って思ってるから、システム更改計画っていうのが起きるわけですよね。数社にRFP出してもらったりするわけですよね。今のままでいいなら今やってるベンダーのところにアップグレードしてよっていえばいい。状況を知っている会社がいちばんお手軽にやってくれるだろうし。それを、あらたにやりたいってことは、ほかにやりたいことや期待することがあるんでしょ？と。
―なんかよくわかんないけど、現状じゃ満足できてないってことですよね。このシステムで本当にこのままいっていいのかなっていう疑問がわいたとか。
北川：じゃあその疑問ってなんなの？たとえば、この製品って、このまま使ってても大丈夫なんだっけとか、ランニング高いよ、とか、保守高いよ、とか、なにかあるからこれじゃやだなって思ったはずで、その「やだな」の部分を書いてほしい！
―そんな思いがRFPに現れればいいのに、現れないと。そこには「唯ぼんやりした不安」だけが…
北川：いやなことだけでも書いておいてくれればいいんです。今のシステムで満足していないことをバーっと書いてもらって、高い、ランニングがむかつくだとか、遅い、とか、自由度がない、とか、自由に書いてもらって。で、その満足していないことを解決する新システムを提案しやがれ、みたいな。実際には既存のシステムを提案している SIer さんもいるわけで、難しいとは思いますが…。
「今やってるオペレーションは全てこれまで通りにできないといけないけど、画面とツールは変わってもいいよ」、とかね。そういう妥協案を、もっとオープンにつくったほうが早いんじゃないのって思わないでもない、思わないでもないっていうか、思います。
―RFPのフォーマットが思考停止の原因ではないですかね？人の思考を阻害している気がします。
北川：そうなんですよ。中途半端なRFPを作ってみんなに出してもらうとかっていうより、コンサル入れて、各社にRFP、提案依頼のための打ち合わせの場を設ける。で、こういう問題があります、こういう問題があります、これを解決したいです、って、したいことや困ってることを集める。外せないこと、外せること、柔軟にできることも出して、それに合致したこと提案して…それでいいんじゃないかな、と。
―現行のRFPからは、嫌なこと、やりたいこと、解決したいこと、外せないこと、外してもいいことって読み取りづらいですよねえ。
北川：わかりづらい。まあ、いちおうこれでわかるんですけどね。細かく書いてあれば。ほんとうはそうなんですよ。
あたらしいRFPテンプレは俺がつくる！（→あえなく却下）
―なるほど。よくわかりました。ほかに、何か言い足りないことは？
北川：ありますが、僕が話すのはスーパーおこがましい感じです。
―え、なんでですか？
北川：だって最終的にシステムを構築する会社の人じゃないから。
―でも、この立ち位置だからこそ、わかること、言えることもあるのでは？
北川：さっきの記事に載っていたような、テンプレを見て作ってるんだとおもいますよ、みんな。「レスポンス3秒以内」とか。
―ハッ…。要はあれだ、ああいいうテンプレを見たひとが、適当に編集して大事なところを端折っているのでは？それが問題なのでは？
北川：コピペしてるじゃんっていう！？
―コピペするならちゃんと全部コピペしてよ！…って、そうか、なるほど、なぜこの記事のPVがいいのかわかってきました。北川さん、あたらしいRFPのテンプレを作ったらいいじゃないですか！それで今度からこちらをテンプレにしてくださいっていえば、数年後に世界が変わるかも…
北川：なんで僕が！っていうかさ、RFPももっと自由な形式でいいんじゃないかと。こういうことやりたいんだけどって。今こういうので困ってて、こういうことしたいんだけど、最低限押さえておきたいのはこれ、みたいな。
―あたらしいRFP。北川さんが今この記事であたらしいRFPのあり方を啓蒙することで今後のRFPの潮流になんらかの変化が…
北川：やだよ！こいつむかつくって思われるだけだよ！
―そんなことないです！
北川：パワポでいいんですよ。
―じゃあ、パワポのテンプレ作ってくださいよ！
北川：いや、真面目な話、これくらいのことが書いてあれば提案できるよねっていう必要最小限でよくね？っていう話もあるんですよ。新システムを作るときはいいんですよ。元がないから。だけど、たいていは、刷新刷新じゃないですか。刷新するときに、前のシステムはこんな画面でしたとかね、そういうことをあんまり入れられると、「んー別にそんな作りこみしなくてもエクセルに今その機能あるよ」って思うけど、「前のシステムにはそれ用のボタンがあったから新しいシステムでもボタンつけなきゃいけません」とかね。でも、それは結局、コスト増なんですよね。で、なんでこの更新ボタンってつけたんだっけ？」ってなる。「メニューからリフレッシュでいいじゃん」みたいなときに、「いや、お客さんの画面に更新ボタンついてたんで、更新ボタンないとユーザビリティが変わったって言われるから」って。「いや、それは更新はこうですってトレーニングすればいいんじゃないの？」「いや、トレーニングって項目入ってなかったんでー」みたいな。「マニュアル作る項目も入ってなかったんでー」みたいな。
―誰と誰の会話ですか！
北川：あらまほしきRFPっていうのが、SIerさんと話せばできそうな気がしますけどね！
―あ、SIerさんにさりげなく振ろうとしている！
北川：いや、ほら、まあ、ちょっとなんか。
―仲良しのSIerさんとかいないんですか？次回、その人を交えて、具体的な成果物を・・・
北川：今日のは危険球すぎるな。一発退場ですよ。
―書きますけどね。今日は貴重なお話をありがとうございました。この世のすべての受発注という関係に通用する話かと思いました!
ありがとうございます、北川さん(デモをしています）
