アイオス コーポレートブログ
ユースケースポイント法で工数を見積もる
皆さん、こんにちは。技術開発グループのn-ozawanです。
チョコレートの原料であるカカオ豆は、昔はその貴重さから貨幣としても使われていました。1545年に書かれた記録では、野ウサギ1匹あたり、カカオ豆100粒で取引されていたそうです。
本題です。
前回、ユースケースでそのシステムの振る舞いを整理するお話をしました。そのユースケースを元に開発に必要な工数を見積もる手法「ユースケースポイント法」があります。今回はユースケースポイント法のやり方についてのお話です。
目次
ユースケースポイント法
概要
ユースケースポイント法は、ユースケースを元にシステムの規模を計測し、工数を求める手法です。ユースケースポイント法に必要なインプットはユースケースのみですので、まだドメインモデルがない状態でも見積もれるのが強みと言えます。
ユースケースポイント法は以下に対して重み付けを行い、そこから得られた結果からシステムの規模 (UCP) を計測します。そして計測したUCPから工数を求めます。
- ユースケース (UUCW)
- アクター (UAW)
- 技術要因 (TCF)
- 環境要因 (EF)
やり方
UUCW （ユースケースへの重み付け）
ユースケースのトランザクション数をカウントして、そのユースケースの重み付けを行います。トランザクションとは、そのユースケースの基本経路と代替経路のステップの総数です。全てのユースケースに対して重み付けを行い、それらすべてを合計したのがUUCW (Unadjusted Use Case Weight)となります。
例えば、基本経路が以下の場合、トランザクション数は３とカウントして重みは５となります。もし該当のユースケースに代替経路がある場合は4以上となり重みは１０（もしくは１５）となります。
①システムは購入可能な商品を提示する。
②アクターは商品を選択して購入する。
③システムは購入結果（代金や消費税など）を提示する。
| 複雑度 | トランザクション数 | 重み |
|---|---|---|
| 単純 | 1～3 | 5 |
| 平均 | 4～7 | 10 |
| 複雑 | 8～ | 15 |
UAW （アクターへの重み付け）
アクターに対して重み付けをします。厳密にはアクターとシステム間でのやり取りの方法に対しての重み付けとなります。ユースケースごとにアクターの重み付けを行い、それらすべてを合計したのがUAW (Unadjusted Actor Weight)となります。
例えば、そのユースケースが単に関数コールで行われるのであれば、重みは１となります。もし、そのユースケースが画面操作で行われるのであれば、重みは３となります。
| 複雑度 | 例 | 重み |
|---|---|---|
| 単純 | プログラム同士のやり取り 関数呼び出し等 | 1 |
| 平均 | プロトコルを介したやり取り WebAPI等 | 2 |
| 複雑 | 画面操作によるやり取り | 3 |
TCF （技術要因への重み付け）
そのプロジェクトにおける技術要因に対して重み付けを行い、TCF (Technical Complexity Factor)を求めます。以下の各要因に対して、0～5の6段階（0は無関係、3は平均的、5は非常に重要）で評価します。
TFactor = 各要因を「重み × 評価」で計算した合計
TCF = 0.6 + (0.01 × TFactor)
| 番号 | 要因 | 重み |
|---|---|---|
| T1 | 分散システムで構築するのか | 2 |
| T2 | 高いパフォーマンスを要求されているか | 2 |
| T3 | オンラインで効率的に使えるようにする必要があるか | 1 |
| T4 | 内部構造が複雑か | 1 |
| T5 | コードの再利用を求められているか | 1 |
| T6 | インストール（構築）のし易さを求められているか | 0.5 |
| T7 | 高い使用性（使い勝手の良さ、高いUX）を要求されているか | 0.5 |
| T8 | 高い移植性を要求されているか | 2 |
| T9 | 変更のしやすさを求められているか | 1 |
| T10 | 同時使用を想定する必要があるのか | 1 |
| T11 | セキュリティに特別な配慮が必要か | 1 |
| T12 | サードパーティからAPIが利用されることを想定する必要があるか | 1 |
| T13 | ユーザーの特別なトレーニングが必要か | 1 |
EF （環境要因への重み付け）
そのプロジェクトにおける環境要因に対して重み付けを行い、EF (Environmental Factor)を求めます。以下の各要因に対して、0～5の6段階（0は無関係、3は平均的、5は非常に重要）で評価します。
EFactor = 各要因を「重み × 評価」で計算した合計
EF = 1.4 + (-0.03 × EFactor)
| 番号 | 要因 | 重み |
|---|---|---|
| E1 | 参画するメンバーが、採用するプロセス（工程）に慣れているか | 1.5 |
| E2 | アプリケーション開発の経験があるか | 0.5 |
| E3 | 採用する方法論に慣れているか | 1 |
| E4 | リーダーの能力が十分か | 0.5 |
| E5 | メンバーのモチベーションが十分か | 1 |
| E6 | 仕様が安定しているか | 2 |
| E7 | メンバーに外注もしくはアルバイトが含まれているか | -1 |
| E8 | 難しいプログラミング言語を採用しているか | -1 |
UCP （ユースケースポイント値の算出）
UUCW、UAW、TCF、EFからUCPを求めます。
UCP = (UUCW + UAW) * TCF * EF
工数算出
ユースケースポイント法では二通りの計算方法が提唱されています。１つは「1UCP = 20時間」で計算することです。例えば300UCPの場合、開発に必要な工数は 300 × 20 で 6000人時（37.5人月）となります。
もう１つは、環境要因の評価から判断する方法です。E1～E6までの環境要因の評価が3より少ない数と、E7～E8の環境要因の評価が3より多い数を合計して、2個以下の場合は「1UCP = 20時間」、3～4個の場合は「1UCP = 28時間」、5個以上の場合はリスクが大きすぎると判断して開発を保留にします。
ただし、ユースケースポイント法では上記の計算方法はあくまで参考程度とし、1UCPを何時間とするかは過去の実績から各々のプロジェクトで決定した方が良いとされています。
おわりに
ユースケースポイント法は、ユースケースさえあれば工数が求められる手軽さがある一方、データ構造などのその他の要素を考慮していないため、その精度に懸念はあります。個人的には超概算見積もりとして利用するのが良いかと思います。
ではまた。
