開発現場の混乱、紛争はRFPで解決されない：闘うマネジャー（1/2 ページ）

市民権を得たような見えるRFPだが、発注者側が主体的に書くという状況が当たり前、ということではないようだ。

[島村秀世，ITmedia]

誰がRFPを書いてきたのか

　筆者の職場である長崎県庁では詳細な設計書を用意した上で入札を行っているが、世間一般ではRFP(Request For Proposal)に対する話題の方が多い。行政分野に限らず、随意契約が多かったり、完成後「あれを直せ。これも直せ!!」ということが一般的であったことを考えれば、RFPは明らかな前進だ。

　いわゆるIT用語辞典などによれば、RFPは「情報システムを導入するに当たって、ユーザが納入を希望するベンダに提供する、導入システムの概要や調達条件を記述した文書」とあるので、発注側が書いた「要件定義書」と同じだ。取り立てて新しい話というわけではない。「では、なんで急に？」となるのだが、理由は意外と簡単だ。2000年を迎えるころから、大量の資金・人材を投入したのにシステムが動かない、もしくは工期が大幅に遅れる案件が急増しているのだ。事実、2006年に行われた日本情報システム・ユーザー協会の調べでも「500人月以上の大規模プロジェクトでは、5割近くで工期遅れが発生している」となっている。ベンダー側では、かねてから「口約束や要件定義の曖昧さ」を問題視していたので、ここぞとばかりにRFPの必要性を訴え、今日のRFPブームに至ったということだ。

　開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに対処するのに必要なものがRFPだと用語をしらべると書いてあるのだが、筆者はどうもRFPが好きになれない。裏があるように思えて仕方がない。500人月を越えるような大きな案件とは、総額5億円を優に越える案件だ。このような大事業に対して、発注側が「要件定義」をしていないなんて、あるわけがない。そんな企業ならとっくに潰れている。そもそも、自らは専門家であるとして、発注側の要求をヒヤリングして「要件定義書」を作ってきたのはベンダーである。それなのにここに来て、「開発現場の混乱や紛争の発生」があるからRFPを作ってくれっていうのはおかしくはないだろうか。どうせ言うのなら「私たちはお客様のように業務の専門家ではないので、RFPを作ってくれませんか」ではないのだろうか。