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

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

リスク3:要件を実装するための方法「処理方式」

機能要件、非機能要件を仕様補完したら、次にそれらをシステムへ実装するための処理方式を検討します。ハードウェア、ネットワーク、OS、ミドルウェア、使用言語、フレームワークなど、これらを満たすために最適な処理方式を検討します。ここまでで構築する製品の仕様が明確になります。

リスク4:製品を構築するための計画「構築方法」

製品の仕様が決まったら、製品をどのようにして構築するかという計画を立案します。具体的には、スケジュール、作業項目、開発体制、構築環境の4点を検討します。

スケジュール、作業項目、開発体制は影響を及ぼしあうので、それぞれのバランスを考慮して立案することが重要となります。また、スケジュールは納期から逆算されるものではなく、その製品の構築に必要な期間を見極めることが大切です。また、作業項目や開発体制は適用する処理方式などを考慮して必要となる要員スキルや作業を吟味します。

以上、前回と今回にわたり紹介した4つの情報が見積りの入力情報となり、いわば、見積りにおけるリスクの発生源となるわけです。これらにおける不確定要素の影響を見積りにおいて予測して加味することが、リスクの見積りとなります。見積りを行う際は、不確定要素によってリスクが顕在化した場合に生じる損失の予想額と発生確率を考慮します。

ここで重要なのが、どの要因に対し、どの程度の予備費をリスクとして見込んだのかを明確にすることです。安全係数として規模や工数を1.2倍にしておくなどの処置がよく取られますが、これではどこが不確定要素だったのか、何を監視すれば1.2倍以内に収まるのかが不明です。各情報に対する不確定要素とその影響度合いを明らかにすることこそが見積りのベースラインを設定することと同義であり、その後のリスクを管理していく上での必要不可欠な事項なのです。

なお、この要求仕様、仕様補完、処理方式、構築方法、見積りの関係は工程が進んでも基本的には変わりませんが、各情報の不確定要素、要求仕様に対する仕様補完の比率が減少していきます。したがって、上流工程において各情報間のつながりと見積りへの流れを整理して見積りのベースラインを作っておくと、その後の変動要素の変化によってどのように見積りを調節していくべきか判断しやすくなります。

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