オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。
|
オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。
そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified Process）」に沿うものとする。
本題に入る前に，反復型開発のプロセスを簡単に紹介しておこう。プロセスは4つのフェーズから成る。すなわち，開発範囲やアーキテクチャの候補を決定する「方向付け」，アーキテクチャを決定し重大なリスクを軽減する「推敲」，アーキテクチャをベースにしてアプリケーションの最初の実用可能なバージョンをリリースする「作成」，ユーザー教育を行い，最終的にアプリケーションを稼働させる「移行」――である。
アーキテクチャとは様々な意味で使われるが，ここではアプリケーションの共通基盤を指す。具体的には，アプリケーションを開発するにあたって守るべき構造（フレームワーク，共通メカニズム，共通コンポーネント，レイヤー構造，パッケージ構造など）のことだ。
（表1）に，反復型開発の各フェーズの作業内容を示した。ウォーターフォール型の開発では，フェーズを「要件定義」，「基本設計」，「詳細設計」，「実装」，「テスト」と大きく分けているが，反復型開発ではこれらをひとまとまり（「基本ワークフロー」と呼ぶ＊1にし，各フェーズの中で目的に応じて各作業に重みを付けて繰り返していく。
| |
|
表1●反復型開発の各フェーズの作業内容とフェーズごとに行う見積もりの特徴 反復型開発における見積もりは段階的に実施する。具体的には，方向付けフェーズでプロジェクト全体に対する概算見積もりと推敲フェーズの詳細見積もりを行い，推敲フェーズで作成フェーズ以降の精度の高い見積もりを行う [画像のクリックで拡大表示] |
「機能」からユースケースへ
見積もりを行う際は，まず方向付けフェーズでプロジェクト全体の概要，つまり工数と総コスト，期間を算出する＊2。工数と総コストを見積もる法としては，米国の研究者であるグスタフ・カーナー氏が提唱した「ユースケース・ポイント法」を用いるのが一般的だ。
反復型開発の大きな特徴の1つとして，システムに求められる機能を「ユースケース」で表現し，分析，設計，開発といった作業をすべて，ユースケースに基づいて進めていくことが挙げられる。そこで，従来のウォーターフォール型開発では「機能」が見積もりのベースになっていたのに対し，反復型開発ではユースケースを見積もりのベースとする。
ユースケース・ポイント法ではLOC（Line of Code）法やファンクション・ポイント法などと同様に，特定の係数を用いてシステムの規模を算出し，生産性係数をかけて工数を算出する。
「粒度」の統一がカギ
ユースケース・ポイント法による見積もりの手順は，大きく8つのステップから成る（図1）。図に沿って説明していこう。
| |
|
図1●ユースケース・ポイント法に基づく見積もり手順 ユースケース・ポイント法は，LOC法やFP法などと同様に，係数モデル見積もりの一般的な手順を踏む。この中で最も重要なのは，「アクター」と「ユースケース」の抽出を行う!)のステップである。その際，正確な見積もりを行うために，ユースケースの粒度が揃うよう抽出しなければならない |
最初のステップは，見積もりの基礎となる「ユースケース」と「アクター」の洗い出しである。ユースケースは，ユーザーの要求の単位を表し，見積もりにおいて「機能」として扱われる。アクターはそれらの機能と結びつく人やシステムを指す。
このとき最も気を付けなければならないのは，各ユースケースの「粒度」をある程度統一することである。ユースケースの粒度がばらつくと，規模の算出に大きな影響が出るほか，精度の高い工数への展開も難しい。
アジャイル開発プロセスで著名なアリスター・コバーン氏は，図2に示したように，ユースケースの3つの粒度のレベルを定義している。1つは，業務全体を指す「要約レベル」，2つ目が1人の担当者が行う1回の作業を指す「ユーザー目的レベル」，3つ目がシステム面から見た機能を表す「サブ機能レベル」――である。
| |
|
図2●ユースケースの3つの粒度 ユースケース・ポイント法によって正しく見積もりを行うには，ユースケースの粒度を統一することが重要である。ユースケースには大きく3つの粒度があり，このうち「ユーザー目的レベル」のユースケースを見積もりに使う |
この中で最も重要なのは，「ユーザー目的レベル」だ。ユーザー目的レベルは，「1人の作業者が中断なく行え，それを実行したあとに満足して立ち去れる作業単位」と定義されている。なぜユーザー目的レベルのユースケースをベースとするかというと，このレベルが本来のユースケースの定義に最も近いからだ。
では，ユーザー目的レベルのユースケースは，実際にどうやって洗い出せばよいのか。お勧めするのが，業務フローをアクティビティ図で作成し，各アクティビティの中で開発対象システムを利用するアクティビティをユースケースとする方法だ。
図3を見ていただきたい。これは，請求処理における注文担当者と請求担当者の業務フローを表したアクティビティ図である。この中で，「送り状を作成する」や「送り状を送付する」というアクティビティが，ユーザー目的レベルのユースケースとほぼ同じ粒度になる。つまり，このアクティビティをユースケース・ポイント法の基礎となるユースケースとすればよい。
| |
|
図3●アクティビティ図を使った「ユーザー目的レベル」の抽出 アクティビティ図では，1つのアクティビティがほぼユーザー目的レベルのユースケースと同じ内容・粒度になる。そのため作業担当者別に業務フローを記述していくアクティビティ図を描くと，ユーザ－目的レベルのユースケースの抽出が容易になる |
|
