ユーザーがRFPを書くのが基本
問題解決の基本は、ユーザー企業自身がRFPを書くことである。「無理だ」という声が聞こえそうだが、曖昧性を排除するには「最低でも主要パラメータを記述して欲しい」と名内氏は主張する。もちろんITベンダー側はユーザーが話す内容を解釈し、自分が想像した仕様を書き、「これでいいのか」と確認する。さらに「あるパッケージをベースにカスタマイズをしたらどうか」「A社で使っているシステムをベースにしたらどうか」などといった提案をすれば、そこから議論することもできるようになるだろう。
ここで忘れてはならないのが、システム規模の膨張によるコストの増加である。曖昧なままでスタートしたシステム開発への要求は限りなく増え続けるからだ。「ハードなら筐体に入らないなどとの理由から機能追加を諦めてくれるが、ソフトはそうはいかない。例えば当初は2時間でバッチ処理を終わらせる仕様だったのが、ある機能を盛り込むことで3時間になってしまう。それでもユーザーは“いいよ”となる。さらに、そこに別の機能追加が加わり、処理は翌日までかかる」（名内氏）となっていく。予算は増えるし、開発期間も長くなるというわけだ。
名内氏のこれまでの経験では、当初見積もりより10倍に膨れ上がったこともあるという。読者の方もそうだろうが、SEから開発コストが減ったという話を聞くことは少ないだろう。だからこそ、「予算は増える」ことをユーザーに説明し、理解してもらう必要がある。「例えば1億円の予算なら5000万円で実現できる仕様を一緒に考える。それでも最後は1億円になってしまう」（名内氏）。予算の半額で仕様を決めていくことも1つの手段かもしれない。
もう1つ重要な点は、システム開発の契約を最低でも2段階に分けることだ。具体的には、RFPを決めるまでの契約と請負開発の契約になる。それぞれの発注先が異なるケースもあるが、RFPがまとまらないうちに見積もり提出となれば、最後には赤字になる可能性は極めて大きい。ITベンダーは価格競争に陥ることを避けるためにも、ぜひとも2段階契約を実施すべきである、と名内氏は説く。
注）本記事は日経ソリューションビジネス2005年8月15日号「深層波」に加筆・修正したものです。
あなたのご意見をコメントやトラックバックでお寄せください
この連載のバックナンバー バックナンバー一覧へ 画面先頭に戻る
- SIビジネスの“3大病”を早急に治せ (2005/08/30)
- 低迷するITシステム販売、富士通ビジネスの復活への道のり (2005/08/23)
- 「不動産、PCショップからソフト会社」へと変身したソフトクリエイト (2005/08/09)
- 「もう一度、世界に羽ばたきたい」、プロサイドの椎名社長 (2005/08/02)
- システム運用が中国に移る日 (2005/07/26)