脱・ベンダー任せ!! "見積力"養成塾(24) 見積りで考慮すべき4つのリスク(1)

本連載は、ユーザー側、ベンダー側の双方にとって妥当なシステム開発プロジェクトの見積りを行うために必要な基礎知識やスキルについて解説している。前回はプロジェクトの成功に必要不可欠なリスクと見積りの関係性を整理したが、今回は見積りで考慮すべき4つのリスクのうち、2点紹介しましょう。

一口にリスクと言っても様々ですが、見積りにおいては、見積り作成時に必要な入力情報における不確定要素に対するリスクを考慮すればよいのです。図1に示した通り、見積りはいくつかの段階に分けて行われます。この段階ごとに、どのような情報が必要となるのかを考えてみましょう。

図1　3段階に分けられる見積りの作業

リスク1:.核となる「要求仕様」

出発点となるのは、ユーザーが要求しているシステムの条件を表した「要求仕様」です。要求仕様に記述される内容は、機能要件、非機能要件、制約条件の3つに大別できます。機能要件とは、画面や帳票、外部接続などの入出力機能に対する要件を指します。また非機能要件とは、目に見える入出力機能以外の要件を指します。例えば、セキュリティなどに対する要求仕様が非機能要件となります。制約条件とは、機能要件と非機能要件を除いたそのシステムを構築するための条件全般を指します。例えば、ユーザーが提示する納期やユーザーとベンダーとの役割分担などが該当します。

このような要求仕様は、ユーザーが提案依頼書(RFP)として文書化してベンダーに提示する場合もありますが、注意しなければいけないのは口頭で示された場合です。口頭では情報伝達が曖昧になって共通認識が得られず、ユーザーとベンダーの間で齟齬が発生するおそれがあります。したがって、ユーザーからの要求は必ず文書化し、双方にて確認を取ることが大切です。

リスク2:ベンダーの腕の見せ所「仕様補完」

要求仕様の不明確な部分を補うのが「仕様補完」です。要求仕様が明確で詳細に記述されていれば仕様補完は不要ですが、上流工程では往々にして要求仕様が粗いため、仕様補完が必要になります。仕様補完を行う対象は、要求仕様と同様に、機能要件、非機能要件、制約条件の3点です。

仕様補完を行う際には過去の開発経験や業務ノウハウが必要であり、うまく仕様補完できるかどうかはベンダーのテクニック次第です。また、仕様補完においても文書化しておくことが大切です。どこまでがユーザーの要求仕様で、どこからベンダーが補完したのかを明示しておくことが、双方の認識を合わせるために必要不可欠だからです。そうでないと、設計が進んでから、ユーザー側は「行間を読んでほしかった」、ベンダー側は「そんなことは予想できなかった」と主張しあう水掛け論になりかねません。また、要求仕様が粗く、仕様補完をどの程度すればよいか迷う場合は、複数の案を出して比較検討することも有効な手段となります。

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