「これは大作ですね…」と思わず筆者はうなってしまった。本当にRFP（提案依頼書）として作られたものなのか？とにかく分厚い。内容を見ると業務フロー図がその大半を占めている。一つ，質問をした。「この業務フローは誰が作成したのですか？」「エンドユーザー数人に作らせました」と情報システム部のマネージャA氏は回答した。それで筆者は合点がいった。
ある中堅企業B社でのことだ。現行業務システムの陳腐化が目立ち，再構築が必要という判断が下った。情報システム部を中心にRFPを作成することになった。そこでA氏を中心としたRFP作成チームが編成され，RFPを作成した。だが，ベンダー数社を呼んで提案依頼を行ったところ，すべてのベンダーから提案に対して積極的な姿勢を示してもらえなかったのである。
「提案したいが，これはちょっと…」というのが共通した態度であったらしい。その後，どうせ再構築するなら別の業務システムも対象としたらどうかという意見が社内で出て，それではその別業務に関してもRFPを作ろうかという話になった途端に，エンドユーザーから「もう作りたくない」と総スカンを食ってしまったのである。
そこで，専門家に入ってもらったほうがよかろうということで筆者に声が掛かったというのが，冒頭の話に至る経緯である。問題はこの分厚いRFPである。 RFPは業務要求や運用要求が詳細に洗い出され整理されていることが望ましい。だから大作であることそのものを否定しているわけではない。その大作RFP を作る労力と，得られるメリットを比較すれば，あまりに労力過多であると思われたのだ。
まず，B社はパッケージ・ソフトの利用を考えていた。呼ばれたベンダーは皆パッケージ・ベンダーであった。詳細な新業務フローを提示されて「この通りやりたい」と言われてしまうと，パッケージ・ベンダーはつらい。腰が引けるのも当然である。
さらに，業務フローは業務に精通したエンドユーザーが書くべきだという持論から，A氏はエンドユーザーを指導して膨大な業務フローを書かせた。エンドユーザーは日常業務を抱えながら業務フローを作成せねばならず，残業どころか休日出勤までしていた。
パッケージ導入が前提であることなどを勘案すると，RFPに必要な業務フローはせいぜい1/5程度でしかなかった。8割近くは無駄な労力だったわけだ。これではエンドユーザーが「二度とやりたくない」と逃げるのも無理はない。まさに「過ぎたるは及ばざるがごとし」の状況であった。
なぜこのような状況になったのか。A氏やエンドユーザーと話をしているうちにその原因がA氏のキャリアに関係することが分かった。A氏は中途入社。前職はソフトウエア会社のSEで，受託開発をいくつもこなしたベテランである。要件定義があいまいなままシステム開発を行い，痛い思いを何度も経験してきた。その苦い経験から，エンドユーザーの協力を得ながらRFPの段階で業務要求をできる限り詳細にまとめ，業務フローという形式で表現しようと考えたのである。この考え自体は間違いではない。むしろ正論であり，理想論でもある。
ただ，ここで注意したいのは，RFPの目的を勘違いしてはいけないということだ。RFPの目的はあくまでもベンダーから良い提案と見積もりを得ることである。要件定義や基本設計が直接的にプログラム開発のために存在するのとは異なるのである。
目的を混同してはいけない。調達に必要なものと，開発に必要なものは分別しなければならない。筆者の指摘に対してA氏は驚いたものの，すぐに調達の視点というものを理解してくれた。またエンドユーザーにもやり方を変えることで負荷が減ることを理解してもらい協力を得た。以後は，ベンダー選定までスムーズに進んだ。
