ゆーすけーす

ユースケース

システム利用者がシステムを使ってどのような目的を達成するかを、利用者とシステムの相互作用として定義したものです。

詳しい説明

ユースケースとは、システムを利用するユーザーが、システムを使ってどのような目的を達成するかを、利用者とシステムの相互作用として定義したものです。「利用者がどのようなシナリオでシステムを使うか」を記述します。

システム開発において、何ができるシステムなのかを明らかにするために用います。文章だけでなく、ユースケース図という形で図解して整理することが一般的で、開発側と顧客側の認識の齟齬を防ぐために重要な役割を果たします。

ユースケース記述では、主役であるアクター（利用者や外部システム）と、システムが提供する機能のやり取りをステップバイステップで書き出します。正常系（期待通りに進む場合）だけでなく、異常系（入力エラーなどで中断する場合）のシナリオも含めて記述するのがルールです。

ユースケース図では、アクターを棒人間のようなアイコン、システムを枠で囲み、それらを線で結んで機能を表します。さらに「包含関係」や「拡張関係」といったルールを用いることで、機能の共通化や例外処理の複雑な関係性まで整理して表現できます。

ITパスポート試験では、UML（統一モデリング言語）の一種として登場します。システムが提供すべき機能を、利用者から見た「何ができるか」の観点で整理する手法として問われます。図の書き方そのものよりも、システムの外部から見た振る舞いを明確にする役割が重要です。

基本情報技術者試験では、オブジェクト指向設計の文脈で詳細に問われます。クラス図など他のUML図との関係性や、ユースケース図を元にクラス図を起こす設計の手順が頻出します。また、アクターが人だけでなく外部システムである可能性にも注意が必要です。

ユーザーストーリーとは視点が異なります。ユーザーストーリーは「誰が何の価値を得るか」という目的重視の簡潔な記述ですが、ユースケースは「システムとどうやり取りして目的を達成するか」という手順重視の構造的な記述です。

機能要件定義とも違います。機能要件定義はシステムに必要な機能の網羅的なリストですが、ユースケースはその中の特定のシナリオを掘り下げて描いた物語のようなものです。機能の全体像と、個別の利用手順という使い分けが必要です。

銀行のATMを例にすると、ユースケースは「預金を引き出す」という一連の行動です。アクターは利用者です。システムは「暗証番号の確認」「残高の確認」「紙幣の払出」という処理を行い、最後に結果を返します。

このとき、もし残高不足であれば「エラーメッセージを表示する」という別ルートを通ります。このように、一つの目的のためにシステムがどう反応するかを描き出すことで、プログラマーは「エラーの時にはこう動くべきだ」という仕様を正しく実装できるのです。