ユースケース図とは?書き方や注意点を初心者でも分かるように解説

システムの骨組みを決める要件定義フェーズ、専門用語の飛び交う中でついつい「分かったふり」をしていないでしょうか。

この記事では、ソフトウエアの標準設計手法である「ユースケース図」について解説していきます。

ユースケース図とは

ユースケース図とは?書き方や注意点を初心者でも分かるように解説

ユースケース図は、システムで何ができるかを「ユーザー目線で」表現する図解術です。「システムを利用する人の目線で」具体的にシステムを利用する場面を想定して、視覚的に図示することがユースケース図を使う目的です。

この「ユーザー目線で」、というのがポイントです。ユースケース図の特徴は「システムの内部構造のみならず、ユーザーの行動も仕様書内に明記される」「具体的なユーザーのアクションに対して、システムが実行する内部処理の流れを明記しているので理解しやすい」という点です。

こうした特徴上、ユースケース図はシステムの要件定義フェーズで使用されることが多いです。具体的なユーザーの行動を例に挙げて図解しているので、ITリテラシーが高くない方でも理解しやすいですがその分、要件定義フェーズでのユースケース図には分かりやすさが求められます。

ユースケース図のメリット

「開発者目線ではなく、ユーザー目線の視点を得られる」「作成するシステムに対する、イメージの明確化ができる」「できること・できないことの明確化ができる」「クライアントの認識の共有ができる」がユースケース図を使用するメリットです。

システム開発するときに、発注元であるクライアント自身も「具体的にこういうことができるシステムを作りたい」という明確なビジョンを持っていない場合が多いです。

しかし、成果物に求める機能の明確化なしにプロジェクトの成功はあり得ません。認識違いからの修正対応による工数増加を防ぐためにも、ユースケース図を使った徹底的な要件定義は重要です。

ユースケース図を使ってヒアリングをすれば、クライアントからのフィードバックや要望を早期に洗い出すことが可能です。また、事前に認識の共有を書面で提出すれば、エビデンスにもなります。

ユースケース図のデメリット

ユースケース図の作成にお金と時間がかかる点がデメリットといえます。特に、受注が確定しない段階だとユースケース図の作成コストがそのまま損失になってしまいます。

小規模なシステムでユースケースがシンプルである場合などは、ユースケース図を作成しないこともあります。

ただしメリットでも解説したとおり、ユースケース図を使用した要件定義フェーズでのヒアリングは有効なので、作成コストはかかりますが、それを補ってあまりあるメリットがあります。

ユースケース図の書き方

ユースケース図を作成する前に、まずは書き方のルールと手順を覚えましょう。

ユースケース図では、記述ルールである「構成要素」と「作成手順」が明確に決まっています。自分のやり方でUML図を作成しようとすると、保守性が低下したり認識の共有がうまくできなかったりするリスクが高まります。

記述ルールを世界共通にしたからこそのUML図(シーケンス図)なので、慣れないうちは特に気を付けながら作成してみましょう。

ユースケース図の構成要素

ユースケース図に登場する基本的な要素は「アクター(利用者またはシステム)」「ユースケース(命令内容)」「サブジェクト(複数のユースケースをまとめて1つの機能を実現したもの)」があります。

 

アクター(利用者またはシステム)アクター(利用者またはシステム)_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

ユースケース(命令内容)ユースケース(命令内容)_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

サブジェクト(複数のユースケースをまとめて1つの機能を実現したもの)サブジェクト(複数のユースケースをまとめて1つの機能を実現したもの)_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

上記要素を図で記述し、フローチャート形式で表現したものが「ユースケース図」になります。

ただし、これだけでは不十分です。実際のユースケース図では上記要素に加えて「パッケージ」「汎化」「包含」「拡張」「拡張ポイント」という記述方があります。

 

パッケージパッケージ_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

汎化汎化_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

包含包含_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

拡張拡張_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

拡張ポイント拡張ポイント_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

各要素の記述例

「パッケージ」はサブジェクトを再利用するときに使用します。

ECサイトのシステムをイメージしてみましょう。ユーザーが商品の注文から受け取りまでの機能をまとめたサブジェクトをパッケージ化すれば、何度でもECサイトでの注文システムを再利用することができます。

同じ機能を繰り返し実行するので表現を省略したい時にパッケージ化は有効です。

「汎化」はユースケースの内容をさらに抽象化した、新たなユースケースを作成することです。ECサイトの例で例えるなら、「セール品を注文する」と「お急ぎ便で注文する」の二つのユースケースは、どちらも「注文する」という一つのユースケースに汎化できます。

具体的な方法の上位概念として抽象的な方法を加えるといったイメージです。

「包含」は、あるユースケースはほかのユースケースの内容を含んでいるときに使用します。ECサイトの例で再びたとえると、「商品を出荷する」というユースケースには「配送先と時間を記載する」というユースケースを含んでいることを示します。

「拡張」は、ユースケースに対して機能追加する別のユースケースの関係を示します。たとえばECサイトのシステムで不具合のクレームを受けたときに、「不具合対応」というユースケースの「調査する」という時点で「不具合チェックシステムを使う」というユースケースを追加します。
ちなみに、この「調査する」という時点のことを「拡張ポイント」と言います。

ユースケース図を作るために必要なこと

ユースケース図について、ここまでで概要は理解できたかと思います。次は、実際にユースケース図を作成する手順を解説していきます。

アクターとユースケースを書き出すアクターとユースケースを書き出す_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

まずはアクターを明確にしましょう。アクターとは「システムを利用する人・組織」もしくは「関係する外部システム・ハード」を指します。関係する外部システムとは自動車など、人以外もアクターになります。

ユースケース図の上では、アクターはたとえ人以外であろうと「人型のオブジェクトと下部にアクター名」を記述するのがルールです。

最初はとにかくアクターを箇条書きで書き出すようにしましょう。どこまで細かく記載するかは、洗い出したあとに協議すれば問題ありません。

次にユースケースも洗い出しましょう。ユースケースとは「利用(use)」+「場面(case)」を繋げた言葉で、システムの利用例を表します。

たとえば人事担当者がアクターである場合、求められるユースケースは「社員の登録」「更新」「削除」「検索」などが挙げられます。ユースケースを洗い出す場合は、アクターごとに箇条書きで書き出しましょう。
アクターごとに箇条書き_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

クライアントへの説明用か、設計用に使うか決める

アクターとユースケースの洗い出しが完了したら、次はユースケース図の構成を決めましょう。構成を決めるときに考慮すべき点は、ユースケース図をクライアントに提出するかどうかです。

クライアントに提出もしくはプレゼンするときに粒度の細かいユースケース図を使用すると、かえってクライアントを混乱させてしまいます。

まずはクライアント向けに、大枠を作成したユースケース図を作成、のちに開発者向けの詳細ユースケース図を作成した方が効率がよいです。

検討結果をユースケース図に反映させよう検討結果をユースケース図に反映させる_ユースケース図とは?書き方や注意点を初心者でも分かるように解説

クライアントとの認識が共有できたら、あとは開発用のシーケンス図に詳細を落とし込むだけです。

「アクター」「ユースケース」「サブジェクト」を書きだし、必要に応じてパッケージ・汎化などでシーケンス図を発展させましょう。

もしユースケース図がシンプルすぎて誤解を生みそうな場合は「ユースケース記述」を作成しましょう。ユースケース記述は、ユースケース図の添付資料として詳細を表で簡潔にまとめたものです。ユースケース図の記述内容から誤解を産まないように、注意点を抑えておきましょう。

ユースケース図を実際に作ろう

ここまで理解すれば、ユースケース図を実際に作成する下準備は整いました。ユースケース図を上手につくるコツは、できるだけ多くのユースケース図に触れることです。頭で理解するだけなく、実際に手を動かして作成できるようになりましょう。

最後に、ユースケース図を実際に作るうえで注意すべき点と使用すべきシーンを紹介します。実務での利用シーンを想像しながら読んでみましょう。

ユースケース図を作るときの注意点

まずはシーケンス図の作成中にありがちな失敗ポイントについて紹介します。シーケンス図の目的を理解していれば起こらないことですが、実際に書き進めているとミスしがちなポイントです。

注意すべき点は「ユーザー目線で記述されているか」「表記ルールを守れているか」という2点です。最低限、この2点だけは守るように心がけてシーケンス図の作成にあたりましょう。

ユーザー目線で書かれているか

開発者の方にありがちな失敗として、つい詳細なシステムの構造までシーケンス図に盛り込んでしまうことがあります。

たとえば出退勤の管理システムをシーケンス図で表す場合、「社員の情報を入力する」「社員の出勤時間を入力する」「社員の退勤時間を入力する」と詳細も書き込みがちです。

しかし、クライアント向けにシーケンス図を作成するのであれば「社員の情報を管理する」のみで問題ありません。ましてや内部処理のロジックを書き込む必要はまったくありません。

シーケンス図はあくまでも「ユーザー目線でシステムの利用例を表現する」という点を忘れないようにしましょう。

表記ルールを守れているか

表記ルールを守ることで、誰が見ても同じように読み取れるユースケース図を作成することができ、図の保守性を高めることができます。

保守性を高めるポイントは、シーケンス図の表記ルール遵守はもちろんのこと、「表現を統一する」のもコツです。

たとえば「出力する」と「アウトプットする」という表現は同じ意味を指します。同じユースケース図の中で異音同義語を使用するとユーザーに混乱を与えかねません。

多少のルール違反や表記の乱れでも、保守性に大きな悪影響を及ぼします。せっかく「だれがみても分かりやすい」というユースケース図を作成するのです。細かいミスでユースケース図のメリットを損なわないようにしましょう。

ユースケース図の使用例

シーケンス図が完成した場合の使用例を考えてみましょう。

クライアント向けの説明資料

ユースケース図の作成は、非ITエンジニアでも理解しやすく、完成するシステムのイメージを明確に持てるので新規営業や要件定義の時に便利です。

その反面、シーケンス図は開発時には使わない場合もあります。クラス図やシーケンス図など、開発時にも使えるUML図はほかにもあります。あとで開発用にも使うから、とシーケンス図に余計なコストをかけず、クライアント向けの分かりやすい資料を作成するためだけに使うという方法もあります。

システム開発の資料用

もちろん、システム開発にもシーケンス図を活用することは可能です。クライアント向けの資料をもとに、より詳細なロジックの流れを記述すれば開発の参考用として活躍できるでしょう。

ただし、詳細なロジックの記述をするなら他のUML図のほうが適している場合が多いので、ユースケース図だけでなく、ほかのUML図を利用することをおすすめします。

ユースケース図はすべてのシステム開発プロジェクトで使用するべきか

結論を書くと、必ずしもすべてのプロジェクトでユースケース図を作成する必要はないです。

ITリテラシーが高くないクライアントと取引するのであれば有効ですが、クライアントがシステム部門をもっている場合はより詳細な記述ができるUML図を利用したほうが効率的だからです。

UML図はユースケース図のみではありません。時と場合に応じて柔軟に使い分けましょう。

ユースケース図は分かりやすさが命

エンジニア向けの設計書、というよりはクライアントへの説明資料としての側面が強いのがユースケース図です。

作成すべきかどうか、分かりやすい内容になっているかには気をつけて、効果的にユースケース図を活用していきましょう。

フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)


記事の監修
砂川 祐樹

Backlog開発チームで開発を担当する傍ら、プロジェクト管理について噛み砕いて解説する入門サイト、サル先生のプロジェクト管理入門サル先生のバグ管理入門の制作に携わった他、プロジェクト管理を楽しく学べるボードゲーム「プロジェクトテーマパーク」を制作。プロジェクト管理を身近なものとして広めるヌーラボの活動に関わっている。


記事の作成
Cacoo編集部

フローチャートやワイヤーフレームに関する情報を発信しています。お役に立てた情報がありましたら是非シェアをお願いします!
フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)
についてはこちら

オンライン コラボレーション作図ツール

250万ものユーザーがなぜ Cacoo を選んでいるのかご自身の目でお確かめください

無料トライアル