本連載では、ユーザー側も開発側もたくさんの問題を抱えている見積りに関する問題を解決するためのヒントを提供します。第2回目は、見積りを難しくしている要因の1つである「古い商習慣」を変えるための方法について考えてみたいと思います。

進化に追いつかない古い商習慣

もう1つの大きな要因として、システムの見積りを出す時期が早すぎるという、ソフトウェア業界の商習慣が挙げられます。

超上流工程における要望によって概算で出した見積り枠の中で、その後のシステム開発のリソースが決まってしまうケースが散見されます。でも、そもそも要求が不明瞭な段階での見積りですから、実際の金額とのズレが多発するのは当然のことです。

今まで誰も作ったことがない業界初のシステムに対して、「いくらかかるか今すぐ出してくれ」と言われることも少なくないと思いますが、これは「アマゾンの奥地へ行くのに何時間かかるか今すぐ答えてほしい」と言われているようなものです。見積りというよりは、むしろ占いや予言に近いとすら思うこともあります。

オープン化に伴ってソフトウェアは付帯サービスではなく、ハードウェアやネットワークと組み合わせた製品として要求されるようになりました。加えて、システムはユーザー企業にとってエンドユーザーへ提供するサービスの根幹を担うようになり、要求仕様は日々多様化しています。

昨今ではSaaS(Software as a Service)のように、ソフトウェアの機能そのものをサービスとして提供する形態も現れてきました。しかしながら、ソフトウェア業界の商習慣はこの進化に追いついていないのです。

フェージング契約へのシフト

現在の商習慣を変える1つの手段としては、フェージング契約へのシフトが考えられます。これは、システム開発の契約方式を2段階に分ける方法です(図2)。

1段階目ではユーザーとベンダーがシステムデザイン契約を結び、コンサルティングによってシステム開発のグランドデザインや要求仕様を決定します。2段階目で実際の開発請負契約を行います。建築業界では従来この方式で契約が実施されています。

そのためにはユーザー側、ベンダー側が何を決めなければいけないか、共通認識が必要になります。IPA(独立行政法人 情報処理推進機構)内に設立されたSEC(ソフトウェア・エンジニアリング・センター)の発行している「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」では、コンピュータシステムの構築に際して、ユーザーやベンダーが何を認識し、決定しなければいけないのかがわかりやすく解説されているので、一読されてはいかがでしょうか。

図1　フェージング契約の仕組み

執筆者プロフィール

藤貫美佐(Misa Fujinuki)
株式会社NTTデータ SIコンピテンシー本部 SEPG 設計積算推進担当 課長。IFPUG Certified Function Point Specialist。日本ファンクションポイントユーザー会の事務局長を務める。

『出典:システム開発ジャーナル Vol.1(2007年11月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。