オブジェクト指向技術の浸透や,反復型開発の広がりなど,システム開発を巡る状況が大きく変化している。見積もり方法も,従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や,ユースケース・ポイント法の活用手順について解説する。

岸 俊行(きし としゆき)
豆蔵 BS事業部 チーフアーキテクト

 オブジェクト指向開発の普及に伴い,ソフトウエアを段階的に繰り返して開発していく「反復型開発(イタラティブ開発)」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため,従来型の見積もり技法を適合できない面がある。

 そこで第4部では,反復型開発における見積もりの基本的な考え方と,現在,一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお,システム開発のプロセスは反復型開発において最も標準的な「統一プロセス(Unified Process)」に沿うものとする。

 本題に入る前に,反復型開発のプロセスを簡単に紹介しておこう。プロセスは4つのフェーズから成る。すなわち,開発範囲やアーキテクチャの候補を決定する「方向付け」,アーキテクチャを決定し重大なリスクを軽減する「推敲」,アーキテクチャをベースにしてアプリケーションの最初の実用可能なバージョンをリリースする「作成」,ユーザー教育を行い,最終的にアプリケーションを稼働させる「移行」――である。

 アーキテクチャとは様々な意味で使われるが,ここではアプリケーションの共通基盤を指す。具体的には,アプリケーションを開発するにあたって守るべき構造(フレームワーク,共通メカニズム,共通コンポーネント,レイヤー構造,パッケージ構造など)のことだ。

 (表1)に,反復型開発の各フェーズの作業内容を示した。ウォーターフォール型の開発では,フェーズを「要件定義」,「基本設計」,「詳細設計」,「実装」,「テスト」と大きく分けているが,反復型開発ではこれらをひとまとまり(「基本ワークフロー」と呼ぶ*1にし,各フェーズの中で目的に応じて各作業に重みを付けて繰り返していく。

表1●反復型開発の各フェーズの作業内容とフェーズごとに行う見積もりの特徴
表1●反復型開発の各フェーズの作業内容とフェーズごとに行う見積もりの特徴
反復型開発における見積もりは段階的に実施する。具体的には,方向付けフェーズでプロジェクト全体に対する概算見積もりと推敲フェーズの詳細見積もりを行い,推敲フェーズで作成フェーズ以降の精度の高い見積もりを行う
[画像のクリックで拡大表示]

「機能」からユースケースへ

 見積もりを行う際は,まず方向付けフェーズでプロジェクト全体の概要,つまり工数と総コスト,期間を算出する*2。工数と総コストを見積もる法としては,米国の研究者であるグスタフ・カーナー氏が提唱した「ユースケース・ポイント法」を用いるのが一般的だ。

 反復型開発の大きな特徴の1つとして,システムに求められる機能を「ユースケース」で表現し,分析,設計,開発といった作業をすべて,ユースケースに基づいて進めていくことが挙げられる。そこで,従来のウォーターフォール型開発では「機能」が見積もりのベースになっていたのに対し,反復型開発ではユースケースを見積もりのベースとする。

 ユースケース・ポイント法ではLOC(Line of Code)法やファンクション・ポイント法などと同様に,特定の係数を用いてシステムの規模を算出し,生産性係数をかけて工数を算出する。

「粒度」の統一がカギ

 ユースケース・ポイント法による見積もりの手順は,大きく8つのステップから成る(図1)。図に沿って説明していこう。

図1●ユースケース・ポイント法に基づく見積もり手順
図1●ユースケース・ポイント法に基づく見積もり手順
ユースケース・ポイント法は,LOC法やFP法などと同様に,係数モデル見積もりの一般的な手順を踏む。この中で最も重要なのは,「アクター」と「ユースケース」の抽出を行う!)のステップである。その際,正確な見積もりを行うために,ユースケースの粒度が揃うよう抽出しなければならない

 最初のステップは,見積もりの基礎となる「ユースケース」と「アクター」の洗い出しである。ユースケースは,ユーザーの要求の単位を表し,見積もりにおいて「機能」として扱われる。アクターはそれらの機能と結びつく人やシステムを指す。

 このとき最も気を付けなければならないのは,各ユースケースの「粒度」をある程度統一することである。ユースケースの粒度がばらつくと,規模の算出に大きな影響が出るほか,精度の高い工数への展開も難しい。

 アジャイル開発プロセスで著名なアリスター・コバーン氏は,図2に示したように,ユースケースの3つの粒度のレベルを定義している。1つは,業務全体を指す「要約レベル」,2つ目が1人の担当者が行う1回の作業を指す「ユーザー目的レベル」,3つ目がシステム面から見た機能を表す「サブ機能レベル」――である。

図2●ユースケースの3つの粒度
図2●ユースケースの3つの粒度
ユースケース・ポイント法によって正しく見積もりを行うには,ユースケースの粒度を統一することが重要である。ユースケースには大きく3つの粒度があり,このうち「ユーザー目的レベル」のユースケースを見積もりに使う

 この中で最も重要なのは,「ユーザー目的レベル」だ。ユーザー目的レベルは,「1人の作業者が中断なく行え,それを実行したあとに満足して立ち去れる作業単位」と定義されている。なぜユーザー目的レベルのユースケースをベースとするかというと,このレベルが本来のユースケースの定義に最も近いからだ。

 では,ユーザー目的レベルのユースケースは,実際にどうやって洗い出せばよいのか。お勧めするのが,業務フローをアクティビティ図で作成し,各アクティビティの中で開発対象システムを利用するアクティビティをユースケースとする方法だ。

 図3を見ていただきたい。これは,請求処理における注文担当者と請求担当者の業務フローを表したアクティビティ図である。この中で,「送り状を作成する」や「送り状を送付する」というアクティビティが,ユーザー目的レベルのユースケースとほぼ同じ粒度になる。つまり,このアクティビティをユースケース・ポイント法の基礎となるユースケースとすればよい。

図3●アクティビティ図を使った「ユーザー目的レベル」の抽出
図3●アクティビティ図を使った「ユーザー目的レベル」の抽出
アクティビティ図では,1つのアクティビティがほぼユーザー目的レベルのユースケースと同じ内容・粒度になる。そのため作業担当者別に業務フローを記述していくアクティビティ図を描くと,ユーザ-目的レベルのユースケースの抽出が容易になる


アーキテクチャの開発工数を見積もる

 反復型開発の大きな特徴として,「アーキテクチャ中心」の考え方がある。

 従来の開発プロセスでは,アーキテクチャを構築する作業を,アプリケーション構築作業の一環として考えていた。一方,反復型開発では,アーキテクチャを確立させるまでの作業を「方向付けフェーズ」,「推敲フェーズ」としてして定義し,アプリケーションを開発する「作成フェーズ」「移行,フェーズ」とは性質の異なるものとして位置付けている。

 アーキテクチャを確立させる作業は,アプリケーションの開発作業とは,複雑さや必要なスキルなどの面において明らかな違いがある。そのため見積もりにおいても,本来はアーキテクチャを確立するコストと,アプリケーションを開発するコストを分けて考えることが望ましい。

 「RUP」の提唱者の1人であるウォーカー・ロイス氏は,ソフトウエア開発の次世代のコストモデルとして,開発フェーズをアーキテクチャ確立までの「エンジニアリング・ステージ」と,アプリケーションの開発のための「製造ステージ」とに分けることを提唱している。反復型開発プロセスでは,方向付けと推敲フェーズがエンジニアリング・ステージに相当し,作成と移行フェーズが製造ステージに相当する。

 ロイス氏は,アーキテクチャの設計,作成,テスト,保守にかかるコストは,規模,品質,複雑度,開発プロセス,チームのスキルの関数で算出できるとしている。

 だが残念ながら,アーキテクチャそのものの規模を見積もる現実的な方法は,まだ確立されていないのが実状である。開発工数を高い精度で見積もれる方法の確立が望まれるが,実現は難しい。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が12月末まで無料!

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