多少なりとも開発行為が伴うIT化プロジェクトの場合、どうしても最初に「要件定義」の作業が必要となります。要件定義・・・あまり一般的な言葉ではありませんね。どうしてこのような言葉を使うようになったのか、私は詳しく調べていませんが、要するに「どのような機能や性能が要求されているのか明確化する」という作業になります。こう一言でまとめてしまうと気抜けされてしまいますが、この要件定義で実に多くの企業やプロジェクトが、投資規模の肥大化を招いているのです。その理由は実に簡単です。ITを導入する企業にとってみれば、その要件定義作業のためにIT企業からプロジェクトマネージャーやシステムエンジニアがヒアリングに来てくれるので「機能や性能」について思いっきり語ります。多くの場合、「制約なく話をしてください」と言われてヒアリングスタートしますので、導入者側の企業としては「あれも欲しい、これも欲しい、できればこうしたい」という形に発言していきます。その結果、「単なる在庫の数を管理するだけの仕組みがほしかった」のに、「受注・発注・在庫推移シミュレーションができるようにしたい」という「希望」の部分まで話をしてしまうことになりがちです。制約なく話をすることによって、夢までをも語ってしまう訳ですね。これは人間誰しも致し方のないことですね。
ところが、こうしたヒアリングを何回か繰り返して出来上がった要件定義書を見るとびっくりです。たいていの場合、「夢」として語っていたはずの機能まで含めて「要求機能」として記述されていることが多いからです。こうなると、このプロジェクトの規模は大きく肥大化し、予算も日程も巨大なものになってしまいます。このような事態は、どのプロジェクトにも、どの会社にも起きることであり、要件定義から始まるプロジェクトの宿命でもあります。

ではそれを避ける方法はあるのか？ですが、完全に避けることはできなくとも、かなり「肥大化のリスク」を極小化できる方法があります。それが「提案依頼書」の準備です。
提案依頼書（RFP:Request for proposal）は以下の内容を含みます。

目的・期待効果
要求する機能とその優先順位
プロジェクトの進め方に対する要求
日程
社内体制
等・・・

これ以外にも書かねばならないことは多くありますが、注目していただきたい重要な部分は「要求する機能とその優先順位」です。ここは「自社や職場がどうしても必要としていることと、できれば実現したいこと」を層別して明らかにすることが目的です。
さらに、「RFPはIT業者に作ってもらうものではなく、自分たちでまとめるもの」なのだ、ということにご注意ください。要するに、「自分たちの手で、どのような機能がどのような優先順位で必要とされているのか、IT業者に示せるようにする」ということが一番重要なのです。
当然、技術的なことを理解せずに書くことも多いため、プロジェクトの肥大化を１００％防いでくれるものではありませんが、RFPを丹念に作ることでかなりリスクを避けることができる効果を期待できます。また、RFPが無い状態で複数の会社に見積をしてもらうと、見積書ごとに数倍の開きができてしまうこともあります。これも「要求している機能が判然としないことによる金額のブレ」です。
システムのように形の無いものを買うときに、自分の要求していることが達成できるのか、きちんと証明してもらいながら見積をしてもらう、ことは鉄則だと思います。RFPが無いまま開発スタートしてしまい、途中で規模の肥大化を招くといった大きな事故もよくみかけます。是非RFPもしくはRFPに準拠するような情報を社内で作り込み、それをベースに提案してもらうようにして肥大化を防いでください。「こんなはずではなかった」とならないために。