新しいソフトウェア開発プロジェクトを開始するかどうかの意思決定をする際、コストの予測は重要な部分を占めます。システム・アナリストやプロジェクト・マネージャー、ソフトウェア・エンジニアは、開発コストの見積もりに何十年も頭を悩ませてきました。最初の関門は、プロジェクトのスコープを正確に把握することです。そのシステムでは、何ができる必要があるのでしょうか。ユースケースを使用して機能要件を把握すると、ユーザーや他の領域の専門家が理解しやすい形になり、要件を議論しやすくなります。プロジェクトの初期段階でユースケース・モデルを作成し、このモデルの中に、システムのすべてのアクター (ユーザーまたは外部システム) とユース･ケースの一覧、それらの名前、および簡単な説明を含めます。これらの情報を把握すると、プロジェクトの初期段階でシステムの規模について合意しやすくなります。

以下で説明するユースケース・ポイント法は、要件をユースケースで記述する方法にうまく適合する有望な見積もり方法です。ユースケース・ポイント法の基礎として、規模を測定する最小単位であるユースケース・トランザクションの概念があります。残念ながら、ユースケース・トランザクションの概念の捉え方には、さまざまな思い込みが存在します。

この記事では、そうした捉え方のいくつかを取り上げ、それらが実際にどのくらいうまく機能するかについて説明します。最初にユースケース・ポイント法について簡単に説明し、次に、ユースケース・トランザクションをどのように定義すると最も効果を発揮するかについて調べます。また、ユースケース・トランザクションが、ユースケースに関する他の概念と、どのように関連しているかについても説明します。そして最後に、ユースケース・トランザクションをカウントする方法 (そしてカウントしない方法) を説明します。

ユースケース・ポイント

ユースケース・ポイント法は、ソフトウェア開発作業を見積もる方法であり、多くの資料で解説されています¹ 。どのような見積もり方法であれ、その方法を単独で使用すべきではなく、他の方法も併用する必要があります² が、この記事では、ユースケース・ポイント法に焦点を絞ります。図 1 にユースケース・ポイント法の主要概念を示します³。ユースケース・ポイント法の基礎にはユースケース・モデルがあり、このモデルはアクターとユースケースで構成されています。いわゆる未調整のユースケース・ポイントを計算するには、特定のユースケースの数と重みが、最も重要な要因となります。システムの規模は、システムの技術的特性を考慮して得られる技術要因を使用して、未調整のユースケース・ポイントを調整することにより計算されます。

システム規模の見積もりが終わると、作業量の計算を始めることができます。そのためには、チームの資質などの環境による影響から、環境要因 (EF) を計算します。非常に重要な環境要因として、要件の安定性があります。また、1 つのユースケース・ポイントに対して何時間 (H) 必要かも調べる必要があります。最後に、プロジェクト管理にかかる時間や統合テストなど、ユースケース・ポイント・モデルの中に考慮されていない補助的作業 (SE) を追加すると、作業量の見積もりは完了します。

図 1: ユースケース・ポイント法の主要概念

ユースケースの重みは、作成されるシステムとアクターとのやり取りの中で実行される異なるユースケース・トランザクションの数で決まります。

ユースケース・ポイント法の場合、以下の基準でユースケースに重みを割り当てます。

• 単純なユースケース -- トランザクション数が 1 から 3 の場合、重み = 5
• 平均的なユースケース -- トランザクション数が 4 から 7 の場合、重み = 10
• 複雑なユースケース -- トランザクション数が 8 以上の場合、重み = 15

以上からわかるように、トランザクションの性質、およびトランザクションのカウント方法をどう想定するかが、見積もり結果に大きく影響します。

上に戻る

ユースケース・トランザクションとは何か

ユースケース・トランザクションの概念を的確に理解すると、ユースケースの記述によくみられる長さや簡潔さのばらつきに対応することができます。ユースケース仕様は簡潔に記述することも、冗長、詳細に記述することもできますが、それは使用されるユースケース・テンプレートや、使用される手法、関係するビジネス・コンテキスト、要件定義者の個人的嗜好などに依存します。ユースケース・フローのステップ数は、アクターとシステムの間のやり取りを表しますが、このステップ数もまた、シナリオ間とシナリオ内の両方で、非常に大きくばらつく可能性があります。「規模が同じかどうか」をテストするためには、ユースケース仕様に含まれるユースケース・トランザクションを検出してカウントします。2 つのユースケース仕様の中に含まれている一意のトランザクションの数が同じであれば、その 2 つのユースケースの規模は同じです。

ユースケース・トランザクションは「往復」である

ユースケースを考案した Ivar Jacobson は、ユースケース・トランザクションとは、ユーザーからシステムへ、そしてユーザーへと戻る「往復」であると述べています。トランザクションは、システムが新たな入力刺激を待つ状態になると終了します⁴。言い換えると、1 つのトランザクションの中で、アクターが何らかのアクションを実行すると、このアクションがシステムの入力になり、システムが反応します。つまり、システムは入力を処理し、結果をアクターに返します。アクターがその結果に反応すると、それがまたシステムの入力になり、新しいトランザクションが開始されます。

ユースケース・トランザクションは必ずしもユースケース・ステップとは限らない

Jacobson は、ユースケース・トランザクションは必ずしも「ユースケース・フローの中の 1 つのステップ」として定義されるのではないとも述べています。ユースケース・フローの中の 1 つのステップ自体が 1 つの「往復」で構成されている場合のみ、そのステップはユースケース・トランザクションなのです。ユースケースの作成に関する一部の手法では、ユースケース・フローのステップをユースケース・トランザクションだと説明していますが、それは決して標準的な方法ではありません⁵。

ユースケース・トランザクションそれ自体は「刺激」ではない

ユースケース・トランザクションについて、「アクターによって実行される刺激の存在により、トランザクションが定義される」⁶ と説明されることがあります。確かにトランザクションは刺激 (システムへのトリガーとなる、アクターの何らかの行動) によって開始されますが、刺激自体は完全なトランザクションではありません。例えば、ユースケースが以下のように記述されているとします。

(1) ユーザーが X を選択します。
...

(n) ユーザーが送信します。
...

この記述では、システムがステップ (1) とステップ (n) の両方の刺激に対して 1 回のみ反応するのか、あるいはステップ (1) とステップ (n) に対して別々に反応するのかが、明確ではありません。従って、2 つの刺激によって構成されるトランザクションは、1 つの場合も 2 つの場合もあります。これは刺激に依存するのではなく、刺激と応答の組み合わせに依存します。

ユースケース・トランザクションはデータベース・アクティビティーではない

Web 上の多くの議論では、ユースケース・トランザクションが、「完全に実行されるか、あるいはまったく実行されない、一連のアクティビティー」と定義されている場合があります⁷。このように定義すると、データベース管理システムのトランザクション・メカニズムの定義のように聞こえてしまいます (データベース管理システムのトランザクションでは、適切に実行されなかったステップをロールバックすることができます)。私たちの経験では、ユースケースの記述の中で、一部のコンテンツをその他の部分から取り出すのは適切ではありません。この定義では、データベースを読み書きするアクションとトランザクションが何らかの形で関連しているかのように思われてしまう可能性があります。しかし、往復の中で、システムがデータベースとやり取りする必要がまったくない場合も十分あり得ます。さらには、関係するデータベースが存在しない場合や、データをシステムの外部から取得する場合もあります。このように、ユースケース・トランザクションがデータベースのトランザクションと当然結びついている、と結論することは適切ではありません。

ユースケース・トランザクションはシステム・ステップではない

ユースケース・トランザクションでのシステムの応答が、1 つのステップとして作成される場合があります。表面的に見ると、ユースケース・トランザクションはまさにシステム・ステップだと思うかもしれません。しかし、システム・ステップは、ユースケース・トランザクションを表すためのベースとして適切ではありません。なぜなら、システム・ステップは、ステップ数をカウントする対象のフローの記述の粒度に依存するからです。また、アクターとシステムの間のやり取りに関する詳細を、システム・ステップだけで記述することもできません。つまり、見積もりは「往復」であるトランザクションに基づくべきであり、システム・ステップに基づくべきではありません。

例: 複雑なユーザー・インターフェース

ユースケース・トランザクションを「往復」として捉える方法は、ユーザー・インターフェースの複雑さを見積もる場合に真価を発揮します。これから説明する例は、求人検索マシンを設計するジョブ・ポータル・プロジェクトを想定したものです。ユースケース・モデル (調査) に基づく初期の見積もりでは、求人検索インターフェースは単純だと考えられていました。ユーザーはいくつかのドロップダウン・メニューから検索項目を選択し、そして選択した項目を検索すると想定されていたのです。しかし、ユースケース仕様を作成するために行われたユーザー・セッションにおいて、既に選択されている項目にシステムが反応して、それ以降に表示されるドロップダウン・メニューの内容を変更できると、アプリケーションのユーザビリティーが向上することが明らかになりました。つまり、1 つのトランザクションと考えられていたものが 2 つのトランザクションだとわかったのです。

ユースケース仕様の最初の案は以下のとおりです。

このテキストは以下のように拡張されました。

これを見ると、2 つの「往復」があることが明確にわかります。ユースケース仕様を根拠とすることで、最初の見積もりを調整した理由が容易に理解できるようになりました。

ユースケース・トランザクションを適切なレベルに保つ

ユースケース・トランザクションとは刺激とそれに対するシステムの応答なのであれば、ほとんどすべてのものをトランザクションとしてカウントできるのではないでしょうか。例えば、「K」という文字をキーボードで入力すると、この入力は刺激であり、システムはその刺激に応答し、「K」として認識可能な数個のピクセルが画面上に表示されます。つまり、この記事で推奨してきた定義は狭すぎるのではないでしょうか。

そんなことはありません。このように否定する理由は、ユースケース自体を解釈するレベルと同じレベルでユースケース・トランザクションを解釈する必要があるからです。最近では、文字を入力するとその文字が画面上のどこかに現れるという現象が関心の対象となることはありません。それは当然のことであり、その結果を実現するために、システムの中に何かを作成する必要はありません。ただし、キーボード・モジュールとグラフィカル・レンダラーとのやり取りを記述するコンテキストの場合には、キーボードへの文字入力というユースケース・トランザクションは十分に意味を成します。

上に戻る

トランザクションのカウント方法

何がユースケース・トランザクションであり、何がユースケース・トランザクションではないかを明確に判断できるようになったので、次に、ユースケースの中でトランザクションをカウントする上での難題をいくつか検証してみましょう。前述したように、ユースケースの重みは、そのユースケースに含まれるユースケース・トランザクションの数によって決まります。しかし、ある刺激に対するシステムの反応が、異なる反応としてカウントされるのは、具体的にどんな場合なのでしょう。

ユースケース・トランザクションとフロー

まず、前述のジョブ・ポータルの検索フローの検証から始めましょう。アクターが「Java」カテゴリーの仕事を検索する場合、アクターは Java を選択し、システムはデータベース内の Java カテゴリーの仕事をすべて検索します。アクターが「.Net」カテゴリーの仕事を検索する場合、アクターは .Net を選択し、そしてシステムはデータベース内の .Net カテゴリーの仕事をすべて検索します。この 2 つは異なるトランザクションなのでしょうか。異なるトランザクションではないことは明らかです。検索語句が異なってもフローが異なるわけではないという意味で、ユースケース仕様自体は抽象的、あるいは包括的です。この例はインスタンス化の違いにすぎません。ただし、例えば定義済みのカテゴリーやフリー・フォーマットのテキスト検索を使った検索の場合には、異なるフローと考えられるでしょう。

一方、例外処理はグレー・ゾーンです。例えば、入力画面に 7 つのフィールドがあり、どのフィールドも制約が異なるとします。日付フィールド、郵便番号フィールド、および別フィールドの内容に応じて入力の条件が変化するフィールド等があります。各フィールドのチェックは別のフローとして記述され、従ってチェックごとに少なくとも 1 つのトランザクションとしてカウントされるかもしれません。あるいは、汎用の例外フローが提供されるかもしれません。この汎用の例外フローは、複数の例外タイプを容易に処理できるフレームワークがあることを前提としています。この場合は、例外フローを 1 つのトランザクションとしてカウントする必要があります。

ユースケース・トランザクションは往復であるため、ユースケースのどこにでも存在するはずです。ユースケース仕様には少なくとも 1 つの基本フローがあるため、トランザクションも少なくとも 1 つは含まれています。トランザクションを持たないフローは意味を成しません。そうしたフローでは、システムは刺激がなくても何かを実行するか、あるいはシステムの反応を明確に予測できない 1 つ以上の刺激をアクターが提供するのかもしれません。

例外処理を記述するフロー (そのため、「例外フロー」と呼ばれる) は、ほとんど必ずと言ってよいほど存在します。すべての例外フローに、少なくとも 1 つのトランザクションが含まれています。代替フローにも同じことが言えます。つまり、代替フローにも、少なくとも 1 つのトランザクションが含まれています。代替フローの中にあるトランザクションの刺激を調べるために、基本フローを調べる必要があるかもしれませんが、それはユースケースを詳細に記述する特定のガイドラインに依存します。

このことから、ユースケース仕様の中にあるユースケース・トランザクションの最小数がわかります。つまり、少なくともフローの数と同じ数だけトランザクションがあるのです ⁸。

表示と (非) カウント

ユースケース・トランザクションを特定できるようになっても、すべてのトランザクションを平等に、重要なものとして扱う必要があるのでしょうか。私たちの戦略では、(特定可能な) トランザクションをすべて表示しますが、場合によっては重みにはカウントしません。トランザクションが「軽すぎる」と思える場合、そのトランザクションを単純に無視してしまうよりも、重みにカウントしない方法の方がよりわかりやすくなります。また、必要ならば、最初の見積もりをより簡単に調整することもできます。

この方法では、フレームワークの真価を発揮することができます。あるユースケースでカウントされた 10 個のトランザクションの内、作業が必要なトランザクションは 7 つだけであり、残りの 3 つはフレームワークで「処理」できる場合、このユースケースは複雑ではなく、平均的です。表 1 に例を示します。

多くのシステム・ステップがある場合、新しいユースケースの可能性が高い

1 つのユースケース・トランザクションを意味する多くのシステム・ステップと、単なる 1 つのシステム・ステップとの違いに対処する方法はないのでしょうか。直感的に、6 つのシステム・ステップを作成する方が、1 つのシステム・ステップを作成するよりも多くの作業を必要とすることがわかります。もちろん、まったく同感です。ただし、この小さなパズルを解決しようとして、システム・ステップをトランザクションとしてカウントしてはいけません。むしろ、そうした余分なシステム・ステップに含まれる機能を分離することで解決する必要があります。明確に一連の機能として認められる場合、それはおそらく、その一連の機能自体がユースケースです。しかし、単純に一連の機能すべてを「ユースケース」の地位に格上げするのではなく (これは機能分割です)、ユースケースの候補には必ず明確な目標があり、少なくとも 1 つの利害関係者 (必ずしもアクターと同じではありません) の利益と一致している必要がある⁹、というルールを適用するようにします。

一例として、「年次貸借対照表の生成」というユースケースを考えてみましょう。このユースケースの中では、いくつかのレポートが生成され、各レポートは特定の利害関係者の利益になっています。各レポートの生成には、いくつかのシステム・ステップが含まれます。レポートごとにユースケースを定義することで、適切な利害関係者を見つけることが容易になり、他の利害関係者を煩わせることがなくなります。この方法に従うことで、より詳細な見積もりを提供することができます。

バッチ・ジョブ

ユーザーとのやり取りがない場合にもユースケースを使う必要があるのならば (実際、ユーザーとのやり取りがない場合でもユースケースを使用した経験があります)、トランザクションは往復であるという概念をどう適用すればよいのでしょう。正直に言うなら、この場合には往復の概念は適用されません。そうしたユースケースの重みを見積もるためには、他の方法が必要です。ほとんどの場合、この見積もりは専門家によって行われます。表 2 は、それを表にして示したものです。

バッチ・ジョブが、複雑なユースケースよりも明らかに規模が大きい場合、そのバッチ・ジョブには複数の目標が含まれている可能性があります。従って、そのジョブを複数のユースケースに分解する必要があるかもしれません。各ユースケースは、少なくとも 1 つの利害関係者の利益である独自の目標を持つ必要があります。このメカニズムは、一般的には「複雑」とみなされるユースケースよりも著しく複雑と思えるユースケースすべてに適用することができます (表 2)。バッチ・ジョブを分割する十分な理由が見つけられない場合には、図 1 で説明した「補助的作業」のカテゴリーにそのバッチ・ジョブを戻すことができます。

非常に複雑なユースケース

例えば 8 つのトランザクションから成る複雑なユースケースと 16 のトランザクションから成る複雑なユースケースとを区別できないという理由で、ユースケース・ポイント法が困難であると指摘されることがあります。私たちの経験では、12 を超えるトランザクションから成るユースケースには複数の目標が含まれています。つまり、そうしたユースケースは、ユースケース・モデルとして問題があることを示しています。言い換えれば、あるユースケースのトランザクションの数が 12 を超えた時点で、新しいユースケースを検討する価値があるということです¹⁰。

プロジェクトの初期段階でユースケース・トランザクションをカウントする

ユースケース仕様がすべて作成されていれば、トランザクションは容易にカウントできますが、見積もりはむしろプロジェクトの初期段階で期待されています。プロジェクトの初期段階では、各ユースケースの簡単な説明が付いたユースケース・モデルしかありません。ユースケースを構成するフローや、フローに含まれるユースケース・トランザクションを想定するには、経験が必要です。皆さんにその経験がない場合には、似たようなシステムや状況で作業した経験のある同僚に遠慮なく相談してみることです。まず、表 2 のようなスプレッドシートを作成し、想定されるトランザクションを書き入れます。それがユースケースのスコープ管理の基礎になり、顧客の当初予測よりも多くのトランザクションを含むユースケースがどれなのかを詳細に説明することもできるようになります。

上に戻る

まとめ

ユースケース・ポイント法を適用してソフトウェア作業を見積もるためには、ユースケース・ポイントの基本的な構成要素を理解することが重要です。そうした構成要素の 1 つがユースケース・トランザクションの概念であり、ユースケース・トランザクションは、アクターによって開始される刺激からシステムによる応答までの往復として捉えるのが最適です。ユースケース・トランザクションは、システムが新たな刺激を待つ状態になると終了します。

この記事では、ユースケース・トランザクションの概念を説明しながら、いつ、どのようにトランザクションをカウントすべきかに関して、いくつかの助言を行いました。トランザクションのカウントは実際には科学というよりもむしろ芸術ですが、この記事で紹介した推奨事項を常識や経験と組み合わせることで、プロジェクトの初期段階で、作業量やコストをより正確に見積もることができるようになるでしょう。

上に戻る

参考文献

[1] Ivar Jacobson らの共著、『オブジェクト指向ソフトウェア工学 OOSE―use‐case によるアプローチ』改訂版、トッパン、1993年刊

[2] Alistair Cockburn 著、『ユースケース実践ガイド―効果的なユースケースの書き方』、ウルシステムズ株式会社、2001年刊

[3] 2001年、オスロ大学 (University of Oslo) Kirsten Ribu 著の修士論文、「Estimating Object-Oriented Software Projects with Use Cases」、http://www.bfpug.com.br/Artigos/UCP/Ribu-Estimating_O-O_SW_Projects_with_Use_Cases.pdf からダウンロード可能

[4] Gunnar Övergaard と Karin Palmkvist の共著、『Use Cases: Patterns and Blueprints』、Addison- Wesley 2005年刊

[5] Parastoo Mohagheghi、Bente Anda、Reidar Conradi の共著、「Effort estimation of Use Cases for incremental large-scale software development」、2005年、International Conference on Software Engineering (ICSE) 資料、303 -- 31 ページ

[6] Linda M Laird と M. Carol Brennan の共著、『演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法』、日経 BP 社、2006年刊

[7] Gabriela Robiolo と Ricardo Orosco の共著「Employing Use Cases to early estimate effort with simpler metrics」、Innovations in Systems and Software Engineering, Volume 4, Number 1、2008年4月、31-43ページ

[8] Ayman Issa、Mohammed Odeh、David Coward の共著「Software Cost Estimation Using Use-Case Models: a Critical Evaluation」、2006年、Information and Communication Technologies (ICTTA '06) 資料、2^nd Volume 2、2766-2771 ページ

[9] Kevin Vinsen、Diane Jamieson、Guy Callender の共著「Use Case Estimation -- The Devil is in the Detail」、2004年、第 12 回 IEEE International Requirements Engineering Conference (RE'04) 資料、10-15 ページ

[10] Marcio Rodrigo Braz と Silvia Regina Vergilio の共著「Software Effort Estimation Based on Use Cases」、2006年、第 30 回 Annual International Computer Software and Applications Conference (COMPSAC '06) 資料、221-228 ページ

[11] Sergey Diev 著「Use cases modeling and software estimation: Applying Use Case Points」、ACM Software Engineering Notes, Volume 31、2006年11月

[12] Bente Anda、Endre Angelvik、Kirsten Ribu の共著、「Improving Estimation Practices by Applying Use Case Models」、Profes 2002 資料、LNCS 2259、383-397 ページ

[13] Kurt Bittner と Ian Spence の共著、『Use Case Modeling』、Pearson Education 2003年刊

[14] Kusumoto Shinji らの共著、「Estimating Effort by Use Case Points: Method, Tool and Case Study」、2004年、第 10 回 International Symposium on Software Metrics (METRICS'04) 資料

[15] Shivprasad Koirala 著、「How to Prepare Quotation Using Use Case Points」、The Code Project、2004年12月

[16] Leslee Probasco 著、「Dr. ユースケースの “ユースケース人生相談”: ファンクションポイントとユースケースにはどんな関係があるんですか？」、The Rational Edge、2002年8月

上に戻る

注記

1. 詳細な説明、スプレッドシート、ツールは、インターネットや [6]、[3]、[12] などの公開資料から入手することができます。
2. 見積もり方法の概要については [6] を参照。
3. Diev の著書 [11] に見られる同様の図から引用。
4. [1] の 127 ページ。また [2] の 93-94 ページと比較のこと。
5. [2] の 119-127 ページ。
6. [7] の 35 ページ。
7. [3] の 20 ページ、[14] のセクション 2.1、[15]。
8. Diev [11] は 1 つのユースケース・トランザクションに 2 つ (またはそれ以上) のユースケース・シナリオがありうると考えています。彼は、「『金融商品を購入する』というユースケース・トランザクションには、購入の成功という 1 つのシナリオと、購入の失敗という、もう 1 つのシナリオを含む可能性があります」という趣旨のことを言っていますが、その考え方は適切ではないと思います。それを認めると、トランザクションとシナリオとの間の関係が不明確になるからです。「購入の成功」というシナリオは、少なくとも 1 つの刺激と 1 つの応答で構成されます。「購入の失敗」というシナリオは、成功のシナリオと同じ刺激で構成されますが、システムの応答は異なります。従ってこれは 2 つのトランザクションとみなされ、1 つのトランザクションとはみなされません。
9. [4] の 36-37 ページを参照。
10. Robiolo と Orosco は、非常に複雑なユースケースをどうカウントするかという問題を完全に解消しようとしています。彼らはユースケース・トランザクションをユースケースの複雑さに関連付けるのではなく、ユースケースの中に見つかるすべてのトランザクションを単純に加え合わせ、トランザクションの量からアプリケーションのサイズを直接計算します ([7] の 35 ページ)。これは有望に思えますが、私たちの知る限り、どのようなルールを適用するのかについての本格的な研究がなされていません。現状では、私たちはユースケース・ポイント法を使いたいと思います。また、ユースケース・ポイントについていくつか変更が提案されていますが、相互運用性を維持するためにもユースケース・ポイントの基本は変更したくありません。提案されている変更としては、例えばトランザクションと複雑さの比の変更 ([5] の表 3)、ユースケースへの追加 (ユースケース・サイズ・ポイント、ファジー・ユースケース・サイズ・ポイント [10])、「キー・シナリオ」に対するトランザクションの変更 [16] などがあります。

参考文献

• ディスカッション・フォーラムに参加してください。
  
  
• Rational Edge の記事専用に新しいフォーラムが作成されています。このフォーラムを利用することで、この記事や、最新刊やアーカイブ中にある他の記事に関して、皆さんの意見を共有することができます。また、世界中の皆さんの仲間達の意見を知ることができたり、皆さん自身が議論を開始することができたり、あるいは現在行われている議論に参加したりすることもできます。まず手始めに、ここをクリックしてください。
  
  
• Global Rational User Group Community
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ユースケース・ポイント
• ユースケース・トランザクションとは何か
• トランザクションのカウント方法
• まとめ
• 参考文献
• 注記
• 参考文献
• 著者について
• コメント