要求定義フェーズでよく使われるユースケース図。先輩に書けと言われたけど、「そもそもユースケース図って何？」「必要性は？」「どう書けば良いの？」と困っている方も多いのではないでしょうか。
若手SEなど難しいイメージを持っている方も多いですが、実はけして難しいものではありません。この記事で解説している基礎知識を抑えてしまえば、たった５つのステップで作成できてしまいます。
この記事では、ユースケース図の基礎知識から５つの作成ステップまで、エンジニアが抑えておくべきユースケース図の全知識を徹底的に分かりやすく解説します。
この記事を読み終えたとき、若手エンジニアもユースケース図を書けるようになっているでしょう。この記事を参考に、ユースケース図を書いてみましょう。
Contents
１．ユースケース図とは
ユースケース図とは、「ユーザーの視点でシステムの利用例を表現する図解術」です。
海外では「Use Case Diagrams」と呼ばれています。
下図のようにとてもシンプルな図であり、一目でシステムの機能やシステム範囲（できること・できないこと）を理解することができます。要求定義フェーズで主に使われています。
要求定義フェーズでは、顧客の要求を分析しユースケース図などを使い視覚化します。そして、顧客と要求を明確化していきます。ユースケース図は、ユーザーの視点でシステムの動作やシステム範囲を見ることができるため、顧客とのコミュニケーションで大いに活躍します。
逆にいうと、要求定義フェーズのドキュメントは、IT知識の高くない顧客でも100%理解できるものでなければ成り立ちません。
また、ユースケース図は、オブジェクト指向のソフトウェア標準設計手法群である「UML（統一モデリング言語）」の１つで、UMLの中では「振る舞い図」に位置づけられてます。「振る舞い」とは、システムがどのように動作するか という意味です。
２．ユースケース図のメリット
顧客の要求を明確化できる
システム開発では、顧客（システムを導入・利用する企業）自身が要求を明確にできていないケースがほとんどです。ユースケース図を活用することで、顧客の要求を視覚化したり、隠れた要求を引き出したりすることができます。口頭や文章だけでは認識に齟齬が必ず出ます。
齟齬を減らすためにもユースケース図はとても役立ちます。
システムの範囲（できること・できないこと）を明確化できる
顧客の要求は、優先度の高いものから低いものまで、混ざった状態で提示されるケースがほとんどです。顧客自身優先度付けできていないケースも多くあります。要求定義を進める過程で、要求がどんどん膨れることも珍しくありません。このような中、システムで実現することを顧客と合意していかなくてはなりません。
ユースケース図では、システムの範囲と境界が明確に表現されます。つまり、システムでできること・できないことを共通認識することができます。
これらのメリットを得ることを目的にユースケース図は作成されます。
ユースケース図は顧客の要求を明確化し合意していく過程で大いに役立ちます。
IT知識の高くない顧客でも理解できるシンプルな図解術だからこそ、要求定義フェーズで活躍するのです。
３．ユースケース図のデメリット
ユースケース図を作成するデメリットは特にありません。あえて言えば、作成する工数（お金と時間）が発生することです。受注が確定していない段階で作成すると内部コストの無駄遣いになります。
また、納期重視の場合や既存システムのリプレイス、小規模システムの導入などでは作らないケースも多くあります。エンドユーザーの方針や開発手法によってケースバイケースです。
４．ユースケース図の基本ルール
ユースケース図は、「アクター」と呼ばれる人型のオブジェクトや楕円で表現される「ユースケース」、アクターとユースケースをつなげる「関連」などのオブジェクトを組合せて書きます。
この章では、ユースケース図を構成するオブジェクトの基本ルールついて解説します。世界共通のルールですのでしっかり理解しておきましょう。
４．１．アクター
 |
「アクター」とは、システムを利用する人や組織、関係する外部システムなどを意味します。 |
４．２．ユースケース
 |
「ユースケース」とは、その名のとおりシステムの利用例です。 |
４．３．オブジェクト間の関係
関連
 |
「関連」とは、アクターとユースケースをつなげるときに使用する線です。 |
汎化（Generalization）
 |
「汎化」とは、オブジェクト間で「汎化関係」が成り立つときに使用する線です。 |
包含（Include）
 |
「包含」とは、オブジェクト間で「包含関係」が成り立つときに使用する線です。 |
拡張（Extend）
 |
「拡張」とは、拡張するユースケース（機能）を表現する際に使用する線です。 |
４．４．サブジェクト（システム境界）
 |
「サブジェクト」とは、システムの境界線を表現する時に使用する枠線です。 |
４．５．パッケージ
 |
「パッケージ」とは、サブジェクト内で複数のユースケースをまとめて表現する際に使用する枠線です。パッケージ名を上部に記述して使います。 |
４．６．ノート
 |
「ノート」はユースケース図にメモ書きする際に使用します。 |
この章ではユースケース図の基本ルールについて解説しました。ユースケース図は基本ルールを組合せて書くものです。次は、書く前に抑えておくべき注意点について解説します。
５．ユースケース図を書く前に押えておくべき６つの注意点
ここでは、ユースケース図を書く前に絶対に押えておくべき注意点について解説します。
このポイントを抑えておかないと、まったく役に立たないユースケース図ができてしまいます。
特に若手SEが忘れがちなポイントでもあるので、ユースケース図を書く前にしっかり理解しておきましょう。
５．１．システム利用者（アクター）視点で書く
ユースケース図は、システム利用者（アクター）視点で書きます。
ユースケース図は、「ユーザーの視点でシステムの利用例を表現する図解術」ということを絶対に忘れないで下さい。開発者向けのものではありません。
５．２．シンプルに書く
ユースケース図は、「誰が、何をできるのか」と「システムの境界」をシンプルに書くものです。分岐条件やシステム内部のロジックなどは書きません。シンプルすぎるかなと心配になる位でOKです。
５．３．機能分割しない
繰り返しになりますが、ユースケース図は「ユーザーの視点でシステムの利用例を表現する図解術」です。システム利用例の概観を表すものであり、詳細な機能を表現するものではありません。
例えば、「社員を登録する」というユースケースは、「CSVから社員を登録する」「画面から社員を登録する」の様に機能分割できます。しかし、ユースケース図ではこれは誤りです。
機能仕様書ではないことを覚えておきましょう。
５．４．ユースケースの粒度を統一する
ユースケースの粒度を統一しましょう。
下図のように、ユースケースは様々な粒度で書くことができます。
「社員情報を管理する」というユースケースは、粒度を下げると「社員情報を登録する」「社員情報を更新する」「社員情報を削除する」という粒度でも表現できます。さらに小さい粒度で表現することもできます。
大きい粒度のユースケース
粒度を下げたユースケース
重要なのは、顧客が理解でき、かつ顧客の要求を明確にできる粒度で書くことです。
粒度が大きすぎると要求の認識漏れが出ますし、粒度が小さすぎると要求定義フェーズに合いません。大枠表現用の粒度の大きいユースケース図と、詳細表現用の粒度を下げたユースケース図を作るのも良いでしょう。
また、１枚のユースケース図の中に粒度がばらばらのユースケースが混ざらないよう注意しましょう。
５．５．表現を統一する
同じ意味のユースケースは表現を必ず統一しましょう。
例えば、「入力する」と「インプットする」という表現は、しばしば異音同義語として使われます。同じユースケースにも関わらず表現が異なると、異なるユースケースとして捉えられます。同じものはしっかり表現を統一しましょう。
５．６．ユースケース記述も一緒に作成する
ユースケース記述も同時に作成しましょう。ユースケース図はシンプルで分かりやすいという特徴がありますが、逆に言うと概観すぎて誤解を生むリスクもあります。
誤解を生むリスクを避けるために、同時に簡易的なユースケース記述も作成すると良いでしょう。
〈ユースケース記述簡易版〉
ユースケース記述はもっと詳細に書くこともできますが、ユースケース図の添付資料として書く際は上図のレベルで良いでしょう。要件定義フェーズなど、先のフェーズで使う際はもっと詳細なユースケース記述を作成します。
この章では、ユースケース図を作成する前に抑えておくべき６つの注意点について詳しく解説しました。若手SEなど、誤ったユースケース図を作ってしまいがちです。しっかり注意点を抑えておきましょう。
６．ユースケース図の書き方－５つの作成ステップ－
いよいよユースケース図の作成ステップです。
この章では、ユースケース図の書き方を５つのステップで優しく解説します。特に最初の３ステップを踏むことがとても重要です。しっかり作成ステップを学びましょう。
６．１．アクターを洗い出す
まずはユースケース図に登場するアクターを洗い出しましょう。
粒度を意識すると難しくなるので、最初はとにかく箇条書きで書き出すことから始めましょう。粒度については洗い出してから協議して決めます。
６．２．アクター別のユースケースを洗い出す
次にアクター別のユースケースを洗い出しましょう。
ユースケースは「○○を○○する」という、シンプルな書き方が良いと前述しました。このことを意識して洗い出しましょう。エクセルなどで箇条書きにすると頭が整理されます。
６．３．ユースケース図の構成と粒度を決める
次に、ここまでで洗い出したアクターとユースケースをもとに、ユースケース図の構成と粒度を決めます。
顧客が理解しやすいように、粒度が大きい大枠のユースケース図と粒度をブレイクダウンした詳細ユースケース図の２種類で構成するのがおすすめです。
６．４．ユースケース図に落とし込む
ここまでくれば後はユースケース図に落とし込むだけです。手を動かしてユースケース図を書いていきます。「アクター」、「ユースケース」、「関連線」、「サブジェクト（システム境界）」を書きましょう。
大枠ユースケース図
大枠ユースケースは、パッケージを使って表現しても良いです。
詳細ユースケース図
発展系
必要に応じて「汎化」、「包含」、「拡張」、「パッケージ」、「ノート」を駆使してユースケース図を発展させましょう。「汎化」、「包含」、「拡張」、「パッケージ」まで書くと、ユースケース図が複雑化したり、顧客が理解できなくなったりすることがあります。ケースに応じて書くか判断しましょう。ユースケース記述に書くのも手です。
６．５．ユースケース記述を作成する
ユースケース図はシンプルで分かりやすいという特徴がありますが、逆に言うと概観すぎて誤解を生むリスクもあります。誤解を生むリスクを避けるために、ユースケース記述もしっかり作成しましょう。
この章では、ユースケース図の作成ステップについて解説してきました。５章までの基本知識さえ抑えれば、たった５つのステップでユースケース図が作成できることが理解できたと思います。
いきなりユースケース図を書き始めるのではなく、最初の３ステップを踏むだけで品質の高いユースケース図を書くことができます。作成工数も大幅に減らすことができます。この作成ステップをしっかり覚えておきましょう。
７．まとめ
この記事では、ユースケース図の基礎知識から５つの作成ステップまで、エンジニアが抑えておくべきユースケース図の全知識を徹底的に分かりやすく解説してきました。ユースケース図の理解が進んだのではないでしょうか。次は、この記事を参考にユースケース図を書いてみましょう。
