The Rational Edge

Dr.ユースケースの “ユースケース人生相談”
ファンクションポイントとユースケースには
どんな関係があるんですか？

by Leslee Probasco
Rational Software Canada

2002/10/19

---

Dear Dr.ユースケース 　先日、ある顧客から「もしユースケースの機能面の複雑性を予測できるなら（例：困難、普通、容易）、そのユースケースが持つファンクションポイントの数を予測する方法はあるか？ 」という質問を受けました。 　私はこの質問への回答に多少苦慮しました。私の直感では、ユースケースとファンクションポイントは同じ土俵に乗せて考えるものではありません（少なくとも、これらは「別々の使い方を持っている」のです）。いままでこの問題について考えたことがありますか？ ラショナルソフトウェアにはファンクションポイントとユースケースの使用に関する資料はありますか？ 　どうか適切なご指導をお願いいたします。 ユースケースで迷える子羊より

Dr.ユースケースの回答

迷える子羊さんへ

　われわれはユースケースを使うことで機能の詳細化を避けるべく作業します。私が思うに、ユースケースの複雑性を予測することと、そのユースケースの持つファンクションポイントの数を予測することはまったく別の作業のように思えます。

　そもそも、ファンクションポイントとは、システムの物理的レイアウト（例えば、テーブルやフィールドの数など）に大きく依存しており、大部分はデータ駆動型になっています。とはいえ、ユースケースとファンクションポイントには、ユーザーの視点から定義されるといった明らかな類似点がありますし、International Function Point Users' Group（IFPUG）では、ファンクションポイントを「機能あるいはユーザーの視点から判断し、アプリケーション開発で用いるコンピュータ言語、開発方法論、技術、もしくはプロジェクトチームの能力には依存しない」と、ユースケースの定義とかなり似通った定義をしています。

　しかし、似ているのはここまでであり、これら2つの手法を直接比較する場合は、IFPUG標準のようにテーブルやファンクションなどの数に基づいてユースケースを格付けしなくてはなりません。

　Rational Unified Process（RUP）には、John Smith氏による「The Estimation of Effort and Size Based on Use Cases」（ユースケースに基づく効果と規模の予測）という論文が含まれており、これは開発労力の予測に関する重要なテクニックについて考察するほか、ユースケースに基づく予測フレームワークについても書かれています。このフレームワークでは異なるカテゴリのシステム向けにユースケースのレベル、規模、および複雑性の概念を考慮しています。ここでは、ほかの各種アプローチとともにFunction Point Analysis（FPA）に基づくUse-Case Point（UCP）手法についても考察しています。Gustav Karner氏は、1993年にこの話題について書いた理学修士論文（Ivar Jacobson氏の部下としてObjectory AB在籍中にKarner氏が書いたもの）を引用しています。

Karner氏による予測技術の利用

　ラショナルでは複数の人間がすでに何年も前からKarner氏の予測技術を利用しており、素晴らしい結果を得ています。サン・マイクロシステムズとIBMも自社でこのテクニックを利用していることを公表し、それぞれの経験から「補正係数」を修正しています。さらに、このテクニックについては、複数の書籍でも言及されています。この技術の最大の利点は、ユースケースごとのシナリオ数がだいたい分かっているとの前提で、ユースケースが書かれる前であっても（ライフサイクルのごく初期の段階であまり正確ではない）ユースケースモデル調査を使って頭の中で実行できる点です（私がユースケースを略述する際は、常に重要なシナリオの一覧を含めている）。

　基本的に、Karner氏の予測技術は以下の点においてファンクションポイント手法と同じものです。

1. 要件定義の重要な局面数を数え、また未補正のポイント数を数える
   
2. 自分のチームとその環境に関する問題集を利用して補正係数を準備する
   
3. 元の計算に補正係数を掛けて補正済みのポイント数を計算し、これをLOE（Level of Effort：労力レベル）の予測値に換算する
   

　Karner氏はやや異なる荷重を使い、ファンクションポイント手法と非常によく似た形で補正係数セットを利用することを提案しており、LOEの予測に20人時間／UCPを提案しています。入力としてActor（実行者）とユースケースを考察することにより、ポイント数は次のように求めることができます。

　（1）Actorをシンプル（1ポイント）、平均（2ポイント）、複雑（3ポイント）に分類する

• シンプル：プログラマブルAPIを持つマシン
  
• 平均：コマンドラインインターフェイスと人間もしくは何らかのプロトコル経由のマシン（APIの用意なし）
  
• 複雑：GUIと人間
  

　（2）ユースケースをシンプル（5ポイント）、平均（10ポイント）、複雑（15ポイント）に分類する

• シンプル：ユースケースの重要なシナリオもしくは実行パスが4つ未満
  
• 平均：重要なシナリオが4つ以上8つ未満
  
• 複雑：重要なシナリオが8つ以上
  

　（3）未補正のユースケースポイント（UUCP）数、補正係数、そして補正後のユースケースポイント（AUCP）数を計算する

　（4）監視されるシステムでは、ポイントをすべて合計して未補正数（UUCP）を算出する

　次に、技術的および環境的補正係数を掛けて補正済み数（AUCP）を算出します。

メモ：これらのステップはCOCOMO（*1）と似ていることにお気付きでしょうか。COCOMOを使って、このアプローチを利用する場合は未補正数（or UUCP）を使います（UUCPはCOCOMOに取り込まれる未補正ファンクションポイントと同じ荷重を持つとの主張に基づく）。

　（5）ステップ3で導かれた合計を、自分のチーム／組織の補正に基づいてLOE概算値に変換する。最初は20人時／AUCPを使う

メモ：サンの技術者によると、経験上、この比率は30人時／AUCPに近づけた方がよいといいます。私はその中間がよいのではと思っていますが、これは組織ごとに大きく異なるものでしょう。

　上のステップ（1）ではActorの格付けを分かりやすく定義していますが、ユースケース（ステップ（2））では、識別をしなくては「重要なシナリオ」の構成要素を判断できません。この場合の重要なシナリオは、ユースケースのインスタンスを実行する際にメインとなる方法を示します。これは大抵の場合、主な代替フローと一致しますが、必ずそうなるわけではありません。複数の代替フローが組み合わされて重要なシナリオとなるか、特定の例外フローが非常に複雑で、これが重要なシナリオの一部となる場合もあります。ステップ（2）の指示でもユースケースがほかのプロジェクト同様（詳細レベルに関して）平均化されていると仮定しています。

　RUPでも言及されているように、10人程度の開発者が6〜8カ月間従事する中規模プロジェクトには約30のユースケースがあるはずです。これは、平均的なユースケースには12のUCPがあり、各UCPには20〜30時間が必要だとの概念が当てはまります。つまり、ユースケース当たりの合計では240〜360人時の作業になるのです。すると、30ユースケースではおよそ9000人時（10人の開発者で6カ月）となります。しかし、100人のスタッフが20カ月かけて進めるような非常に大きな規模のプロジェクトでは問題のレベルが違うため、最初から（それに比例する）1000ユースケースがあるわけではないことに注意しましょう。

　ユースケースはあまり細分化しないようにすることが重要であり、レベルを高く設定しすぎないようにすることも同様に重要です。ビジネスユースケースではなく、確実にシステムユースケースを扱うようにすることです。私ならテストとして、「その重要なシナリオは7±2クラスのコラボレーションで実現可能か？ 」などと自問するでしょう。これは分析レベルに当てはまります。完全かつ入念なデザインレベルのコラボレーションを調べると、あといくつクラスが出てくるか分かりません。クラスの数が一気に増え始め、クラスをサブシステムへと集約するようになる場合は、ユースケースのレベルが違っているのかもしれません。ユースケースの数が大きく異なると、結果が何かにつけ歪曲されるかもしれませんが、組織の各スタイルに配慮するため、手法は前述のように（予測値を同様に平均化されたユースケースを再適用する）構成し直すことができます。

シンプルなシステムと複雑なシステムの予測

　Karner氏のテクニックを使ってシンプルなシステムと複雑なシステムの作業を予測すると、ユースケース当たり約150〜350時間のRUPで得られる経験値と深く関連するさまざまな値が導き出されてきます。

シンプルなシステム	人間がコマンドラインインターフェイスでシンプルなユースケースを立ち上げるもの（Actorランク= 2）を最もシンプルなシステム（ユースケースランク= 5）とします。前述のステップ（3）で示された式に基づくと、これは2 + 5 = 7ポイントのUUCPカウントになります。ステップ（4）の式を使うと、UCP当たり20人時では、これが約140人時となります
複雑なシステム	人間が複雑なGUI駆動式のユースケースを立ち上げるもの（Actorランク= 3）を複雑なシステム（ユースケースランク= 15）とします。これは最大18UUCPもしくは約360人時となります

メモ：新チームの典型的な補正係数には10〜20％を作業予測に加えます。

自分の頭の中で考える

　お分かりでしょうが、このテクニックはプロジェクトを開始しようか、というときに自分の頭の中で適用することができます。これは厄介なプロジェクトに突然投げ込まれたときなど、特に便利だと思っています。そういうときには、チームに何人必要なのか、スケジュールのどこに到達していなければならないのかを、素早く頭の中でチェックできます。

　ほかでも、このテクニックを自分のチーム用に調整してとても良い結果を出している企業があります（サンやIBMのデベロッパサイトを検索すればUCPの利用に関する資料を見ることができます）。しかし重要なポイントは、このテクニックを使えばあまり労力をかけずにかなり早い段階で概算を出せる点です。しかも、それはプロジェクトの初期段階で利用可能なほかの手法と同程度正確（あるいは不正確）なもの、になるのです。

　このテクニックを使う場合は、簡単な計算をしてから自分のチームと一緒に実質的な作業をし、実際にかかった時間を調べるなど、より効果的な概算予測へと進むのが最善の方法です。これらの結果を加味して当初の予測を調整し、先へと進めながら洗練させていくことができます。

テクニックの不足部分を補う

　Karner氏のUCPテクニックを理解および適用するに当たって私が目にした問題の大半は、ユースケースの複雑性評価という、より重要なシナリオの定義を中心に展開しています。例えば、CRUD（作成、交換、更新、削除）を実行できるユースケースは、4つの重要なシナリオを持つ1つのユースケースと考えるべきか、それともほかのシナリオが似通っているので実際には1つの重要なシナリオを持つ1つのユースケースなのかというものです。このような疑問が出た場合、私はLarry Constantine氏の「必須のユースケース」という概念をよりどころにしています。同氏によると、“必須”とはシステムの中の重要なユースケースを意味しているわけではなく、各ユースケースについて定義する本質を意味しています。ユースケースを見ることで、それを構成する部品の1つ1つではなく、真の本質を形成するのがどのシナリオなのかを判断できなくてはならないのです（必須ユースケースの構成に関する詳細はLarry Constantine氏とLucy A.D. Lockwood氏の共著、『Software for Use』（*2）を参照）。

　UCPテクニックに関して私が抱えるもう1つの疑問が、出てくるユースケースの数と、それをどこまで詳細に詰めるべきかが漠然としている点です。ユースケースの構成要素や、それをどこまで絞り込むべきかについてはさまざまな議論があります。適切なユースケース数は、私は通常「第六感」や数年に及ぶ経験によって養った平均値、そして自分やほかの人々の経験に頼っています。RUPでは、約6〜8カ月と10〜15人のスタッフを投入する平均的なITプロジェクト（技術的なものではなくビジネスのもの）は約30ユースケースになるとされており、私も実際に立証しています。私が関与した最大のプロジェクトの1つは、4年と300人を投入した約280ユースケースからなるプロジェクトでした（このプロジェクトのファンクションポイントの概算は約9000〜1万4000にもなります！）。

　ユースケースの密度に関する問題についていうと、私が目にした中で最も規模が小さく有用なユースケースはページ半分の長さしかなく、最大のものは120ページ以上もありました。誤解のないようにいっておくと、この巨大なユースケースは実際には非常にシンプルなもので、メインのフローは2ページしかなく、50もあった代替フローは最初と最後が一緒でした。基本的に、このユースケースは就業規則などの管理を記述したもので、ユーザーが選べるルールの種類は50程度ありましたが、校閲担当者は2ページのフローを見て関心のある2種類のルールを選んでいたのです。開発中はルールがタイプごとに優先順位付けされ、毎回新しいルールタイプが追加されました（実際、優先順位の低いルールがインプリメントされることはありませんでした）。

　プロジェクトのタイプによって予測が変わると考える私にとって、Karner氏のテクニックを受け入れがたい点がもう1つあります。例えば、WebアプリケーションのGUIが原因で、関与するActorがコマンド＆コントロール（C2）プロジェクトの地理マッピングGUIと同じように複雑であると格付けされてしまうことです。Webアプリケーションの内部は有名なコンポーネントインフラ（.NETやJ2EEなど）をベースにしているため、そのインプリメンテーションは非常に複雑なC2システムの内部の動きと比べれば取るに足らないとの主張もできます。この状況においてはさまざまな要因がかかわってくるのです。Webアプリケーションに比べれば、C2システムにはもっと多くのユースケースがあり、これらはそれぞれがWebアプリケーションのユースケースよりも多くの重要なシナリオを持つ傾向にあります。そのためC2システムのUCPが増えるのです。さらに、技術的、環境的なC2システムの複雑性はプロジェクトの補正係数を大幅に拡大し、対応するWebアプリケーションのそれよりもはるかに大きくしてしまうのです。

初期予測以上を目指す

　このテクニックを利用することで得られる初期予測は作業を開始するに当たってはよいのですが、最も重要なこととして、これらが概算にすぎないということも覚えておく必要があります。そこで、プロジェクトの進行に合わせて次のようなことが必要になってきます。

• これらのテクニックに自分の経験を加味する
  
• 情報が増えたらすぐに自分の数字の精度を引き上げる
  

　Analysis Modelが得られたら、バウンダリ、コントロール、そしてエンテイティの各クラス、そしてさらにうまくすればデザインサブシステムを特定することが可能になります。これのインプリメントに必要な作業は、過去のプロジェクトの似たような数値を使って予測することができるのです（*3）。（ここまで詳細な分析では、米RationalのJohn Smith氏の書いた「The Estimation of Effort Based on Use Cases」（*4）という論文の中で紹介されているテクニックの採用を開始したり、COCOMO II（*5）にあるような有名なテクニックを採用してもよいでしょう）。

　その一方で、プロジェクトを開始する前にコストを確定する方法を考え出すよりも、まずは早まった予測をしないよう組織やチームの基本姿勢を変えることに力を注ぐべきかもしれません。早まった予測は、マネージャがチームに非現実的な予算を割り当ててしまうことにつながります。その後わき起こる危険極まりない状況の中、プロジェクト参加者全員が神経質になり、リソースは完成前に使い果たされてしまい、要件定義は半分しか満たされなくなってしまうことにつながります。しかし、自分の予測に伴う誤差の範囲を認識しているとの前提であれば、どの時点でも予測を行うことは可能であり、潜在的に有益です。さらに、プロジェクトマネージャは（予算を予測しなくてはならないならば）不測の事態に備えるか、予算に合わせて余分な機能を排除する管理体制を整えるべきです。

　このような回答でいかがでしょうか。

お役に立つことをお祈りして。

Dr.ユースケース

メモ：本稿は「chat_rupフォーラム」でのQ&Aの要約です。Davyd Norris氏、Pan-Wei Ng氏、そしてJohn Smith氏の各氏に感謝をいたします。

IT Architect 連載記事一覧

---

（*1）　COCOMOは当初Barry Boehm博士によって開発された「Constructive Cost Model」の略で、同博士の名著である『Software Engineering Economics』（1981年、Prentice-Hall刊）に説明があります。

（*2）　Larry L Constantine氏とLucy A. D. Lockwood共著。『Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design』（1999年Addison Wesley刊）

（*3）　The Rational Edgeの2002年5月号に掲載されたJoe Marasco氏の「Commitment」に関する記事参照。

（*4）　http://www.rational.com/products/whitepapers/finalTP171.jspで参照可。

（*5）　http://sunset.usc.edu/research/COCOMOII/参照。

本記事は「The Rational Edge」に掲載された「Dear Dr. Use Case: What About Function Points and Use Cases?」をアットマーク・アイティが翻訳したものです。