本連載は、ユーザー側、ベンダー側の双方にとって妥当なシステム開発プロジェクトの見積りを行うために必要な基礎知識やスキルについて解説している。これまで3回にわたりプロジェクトにおける見積りとリスクについて解説してきましたが、リスクはベンダーだけが抱えるものではないのです。

これまでに取り上げた見積りのリスクは、ベンダー側だけが把握、管理してもうまくいきません。ユーザーとベンダーが共有してお互いに管理するもの、ベンダーが主体となって管理するものの2つに大別できます(図1)。

図1 見積りのリスクはベンダーだけが把握するのではなく、ベンダーとユーザーで共有する

ユーザーとベンダーが共有すべきリスク

要求仕様の不確定要素に起因するリスクはユーザーとベンダー双方で共有すべきです。具体的には、ユーザーが提示した機能要件/非機能要件、ベンダーが補完した機能要件/非機能要件を指します。

特に新規案件の上流工程においては要求仕様がどのように落ち着くのか、ユーザーもベンダーもわからないケースがままあります。このような段階では、一定の費用を決めてしまうこと自体に無理があります。とはいえ、費用の目算を立てておかなければいけないのが現実です。プロジェクトをその費用に収めるには多くの前提条件があり、その前提条件が変われば当然費用も変わることを双方がリスクとして認識して要件をコントロールしていくことが、プロジェクトを成功に導くために一番大切なことなのです。

筆者はこれまで見積り誤りが原因とされるプロジェクトの失敗をたくさん見てきましたが、その一番の要因が要求仕様でした。要求仕様が不明確なままリソースを決定し、そのリソース内で収める取り組みがうまくいかずにリソース不足で破綻してしまうケースです。大きく崩れてしまうプロジェクトほど、その失敗は要求仕様に起因しています。

この問題に対する解決方法は、要件が明確になるまで正式な費用を決定しないことです。これは当たり前のことですが、実行しているプロジェクトは多くありません。そもそも無理なことが行われていることを業界として認識し、正していくことが必要な時期に来ていると思います。

ベンダーが主に管理するリスク

一方、ユーザーが出した要件を製品として実装・構築していく過程における不確定要素に起因するリスクは、ベンダーが管理します。

どのような製品を組み合わせたら最適なシステムを構築できるかという課題に対処するために、製品情報を蓄積して、その組み合わせを検証していくという活動はリスクを低減するために有効です。また、構築する製品に適した作業項目やスケジュール、そのために必要となる技術者のスキルを過去の開発実績から把握し、適切なリソースを投入できるよう体制を整えていくことはベンダーの仕事であり、それらに起因するリスクを把握して管理することこそが腕の見せ所となります。どのような処理方式で実装・構築するかということは、当然ユーザーとベンダー間で共有しますが、リスクの抽出や管理はベンダーが主体となって行うというわけです。

以上のように、ユーザーとベンダーが共同してリスクを管理としていく部分と、ベンダーが主体となってリスクを管理していく部分を区別し、それを見積りに反映していくことが、IT業界の成長のために必要不可欠だと思うのです。明るい未来を目指し、ユーザーとベンダーが一丸となって頑張っていきましょう。

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

執筆者プロフィール

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