開発手法の多様化により、これまでの見積もり手法が通用しないケースが増えてきた。再調整のための見積もりには、精度とスピードが欠かせない。アジャイル開発のプラクティスを参考に、適した見積もりのタイミングや手法を紹介する。

今回のポイント
  • 工程や要件の確定度、見積もりをする人の状況に合わせて精度の高い見積もり手法を使い分ける。

  • 要件の追加や変更に対応する見積もりは、開発チームのメンバーの感覚で素早く精度の高い見積もりをする。

  • スコープを再調整する際の見積もりには、「反復」「イテレーション計画」「チームで見積もり」「優先度付けしたプロダクトバックログ」というプラクティスを利用できる。

 本連載は、ウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。前回までは、主に要件定義におけるプラクティスの活用方法を解説した。今回は、システムエンジニアの立場からソフトウエア開発におけるハイブリッドアジャイルの見積もり方法を解説する。

見積もり精度は後工程ほど正確になる

 ユーザーの示す要件が曖昧な場合、システムエンジニアはソフトウエアの規模や開発に必要な工数を正確に見積もれない。しかし、見積もりができなければ、予算を立てられずプロジェクトは進まない。その結果、システムエンジニアはユーザーの示す要件仕様から要件の曖昧な部分を推測し、コストに余裕を持たせた見積もりにする。

 見積もったコストが想定範囲内に収まればよい。問題になるのは、曖昧な要件のまま開発に着手してしまい、開発コストが当初の数倍に膨れ上がってしまったという場合だ。失敗プロジェクトの典型例とも言える。このようなリスクを避けるには、見積もりの精度を上げて、正確なコストを算出しなければならない。

 システムの完成までにかかるコストを見積もる際、図1を参考にするとよいだろう。これは、バリー・ベーム氏が1981年に発表した「ソフトウエアコストの見積もり精度と工程」のグラフである。システムの完成までに要した実績コストが、見積もり時の何倍であったかを示すものだ。例えば、要件定義確定時に見積もったコストは、完成までに0.67 ~ 1.5倍に変動する可能性があると示唆している。つまり、要件定義の確定時に見積もったコストは、完成までに最大1.5倍に膨らむ可能性があるということだ。

図1 見積もり精度は後工程ほど正確になる
(出所:Software Engineering Economics(Barry W.Boehm氏)の論文を基に筆者が作成)
[画像のクリックで拡大表示]

 グラフでは、工程が進むにつれて見積もり精度も高くなっていく。仕様の曖昧な部分がより明確になるからだ。ウォーターフォール型の開発であれば、基本設計を終えてから開発工数を見積もれば、最大でも実績コストは見積もり時の1.25倍に収まる。これでも開発するシステムエンジニア側から見れば、コストが上振れするリスクになるが、その主な要因は要件の曖昧さというよりも開発側の問題が大きいだろう。

 アジャイル開発の場合は、ウォーターフォール型の開発よりもコストの上振れリスクが高いと言える。アジャイル開発では、図1の操作概念確定と同様の状態で開発を始めるからだ。つまり、実績コストは見積もり時の最大2倍になる可能性があるわけだ。

 バリー・ベーム氏が論文を発表してから30年以上たつが、このグラフの値は現在の見積もりにも十分通用すると感じる。

従来の見積もり方法では難しい案件が増える

 一般的にウォーターフォール型の開発現場でよく使われる見積もり手法には、SLOC(Source Lines Of Code)法やFP(Function Point)法、タスク法などがある。SLOC法やFP法は、ソフトウエアの規模を測定して、社内に蓄積された生産効率のデータを基に開発に必要な工数を見積もる工学的な手法である。タスク法は、全体の開発工数を細かく分解して、それぞれの工数にかかる作業量を足し合わせて見積もる手法だ。今までは、このような手法を使って、見積もり精度を向上できた。

 ところが最近では、上記に挙げた見積もり手法では対応できない案件が増えている。それは、(1)新技術や新言語を採用する案件が増えていること、(2)開発技術が多様化していること、(3)詳細な要件が不明、または要件の変更が予想される案件が増えていること、といった理由からだ。

 (1)の例は、社内で初めて採用するプログラミング言語でシステムを開発するような場合である。SLOC法やFP法では、ソフトウエア規模を見積もった後に工数を換算する。これには、過去の実績から生産効率を算出し、それを係数として工数を計算しなければならない。しかし、新たなプログラミング言語などの新技術を採用すると、社内に実績となるデータがなく、工数を見積もるための係数が存在しない。ソフトウエア規模は見積もれても、工数に換算するための情報がないのだ。このため、うまく工数を見積もるのが難しくなる。

 (2)は、これまでと同じプログラミング言語を使っていても、フレームワークや流用するライブラリ、自動生成ツールなどが従来とは異なる案件で発生する。このような場合は、採用する開発技術によって開発するソフトウエアの規模が異なったり、工数の見積もりに適切なデータがなかったりすることがある。これでは、従来の手法による見積もりは難しくなってしまう。

 (3)は、最近アジャイル開発手法が注目されている理由でもある。開発してみないとその効果や成果が分からないような案件では、最初から工数を見積もるのは難しい。しかし、このような案件でも見積もりはしなければならない。そこで、要件が不明、または変更が予測される場合でも見積もりできる手法に変更しなければならない。

 ここで挙げた例のように、開発手法や開発技術の多様化によって、従来の見積もり手法では通用しない案件が増えているのが現状だ。このような案件では、従来のウォーターフォール型の開発に比べて、要件の追加や変更が発生する可能性が高い。そこで、ハイブリッドアジャイルの利用をお勧めしたい。

 ハイブリッドアジャイルは、ユーザーとシステムエンジニアの認識の食い違いを早期に発見したり、開発の効率を向上させたりするために、ウォーターフォール型の開発プロセスにアジャイルのプラクティスを取り入れた手法である。様々なパターンが考えられるが、基本パターンは基本設計の工程までとテスト工程以降をウォーターフォールで行い、詳細設計と製造に相当する工程をアジャイル開発する。

 ウォーターフォール型で基本設計までを進めるので、開発が進んでから大きな要件の追加や変更は発生しないだろう。先ほど紹介した図1によれば、実績コストも見積もり時の1.25倍程度に収められる可能性が高まると言える。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら