システムの骨組みを決める要件定義フェーズ、専門用語の飛び交う中でついつい「分かったふり」をしていないでしょうか。
この記事では、ソフトウエアの標準設計手法である「ユースケース図」について解説していきます。
目次
ユースケース図とは
ユースケース図は、システムで何ができるかを「ユーザー目線で」表現する図解術です。「システムを利用する人の目線で」具体的にシステムを利用する場面を想定して、視覚的に図示することがユースケース図を使う目的です。
この「ユーザー目線で」、というのがポイントです。ユースケース図の特徴は「システムの内部構造のみならず、ユーザーの行動も仕様書内に明記される」「具体的なユーザーのアクションに対して、システムが実行する内部処理の流れを明記しているので理解しやすい」という点です。
こうした特徴上、ユースケース図はシステムの要件定義フェーズで使用されることが多いです。具体的なユーザーの行動を例に挙げて図解しているので、ITリテラシーが高くない方でも理解しやすいですがその分、要件定義フェーズでのユースケース図には分かりやすさが求められます。
ユースケース図のメリット
「開発者目線ではなく、ユーザー目線の視点を得られる」「作成するシステムに対する、イメージの明確化ができる」「できること・できないことの明確化ができる」「クライアントの認識の共有ができる」がユースケース図を使用するメリットです。
システム開発するときに、発注元であるクライアント自身も「具体的にこういうことができるシステムを作りたい」という明確なビジョンを持っていない場合が多いです。
しかし、成果物に求める機能の明確化なしにプロジェクトの成功はあり得ません。認識違いからの修正対応による工数増加を防ぐためにも、ユースケース図を使った徹底的な要件定義は重要です。
ユースケース図を使ってヒアリングをすれば、クライアントからのフィードバックや要望を早期に洗い出すことが可能です。また、事前に認識の共有を書面で提出すれば、エビデンスにもなります。
ユースケース図のデメリット
ユースケース図の作成にお金と時間がかかる点がデメリットといえます。特に、受注が確定しない段階だとユースケース図の作成コストがそのまま損失になってしまいます。
小規模なシステムでユースケースがシンプルである場合などは、ユースケース図を作成しないこともあります。
ただしメリットでも解説したとおり、ユースケース図を使用した要件定義フェーズでのヒアリングは有効なので、作成コストはかかりますが、それを補ってあまりあるメリットがあります。
ユースケース図の書き方
ユースケース図を作成する前に、まずは書き方のルールと手順を覚えましょう。
ユースケース図では、記述ルールである「構成要素」と「作成手順」が明確に決まっています。自分のやり方でUML図を作成しようとすると、保守性が低下したり認識の共有がうまくできなかったりするリスクが高まります。
記述ルールを世界共通にしたからこそのUML図なので、慣れないうちは特に気を付けながら作成してみましょう。
ユースケース図の構成要素
ユースケース図に登場する基本的な要素は「アクター（利用者またはシステム）」「ユースケース（命令内容）」「サブジェクト（複数のユースケースをまとめて1つの機能を実現したもの）」があります。
アクター（利用者またはシステム）
ユースケース（命令内容）
サブジェクト（複数のユースケースをまとめて1つの機能を実現したもの）
上記要素を図で記述し、フローチャート形式で表現したものが「ユースケース図」になります。
ただし、これだけでは不十分です。実際のユースケース図では上記要素に加えて「パッケージ」「汎化」「包含」「拡張」「拡張ポイント」という記述方があります。
パッケージ
汎化
包含
拡張
拡張ポイント
各要素の記述例
「パッケージ」はサブジェクトを再利用するときに使用します。
ECサイトのシステムをイメージしてみましょう。ユーザーが商品の注文から受け取りまでの機能をまとめたサブジェクトをパッケージ化すれば、何度でもECサイトでの注文システムを再利用することができます。
同じ機能を繰り返し実行するので表現を省略したい時にパッケージ化は有効です。
「汎化」はユースケースの内容をさらに抽象化した、新たなユースケースを作成することです。ECサイトの例で例えるなら、「セール品を注文する」と「お急ぎ便で注文する」の二つのユースケースは、どちらも「注文する」という一つのユースケースに汎化できます。
具体的な方法の上位概念として抽象的な方法を加えるといったイメージです。
「包含」は、あるユースケースはほかのユースケースの内容を含んでいるときに使用します。ECサイトの例で再びたとえると、「商品を出荷する」というユースケースには「配送先と時間を記載する」というユースケースを含んでいることを示します。
「拡張」は、ユースケースに対して機能追加する別のユースケースの関係を示します。たとえばECサイトのシステムで不具合のクレームを受けたときに、「不具合対応」というユースケースの「調査する」という時点で「不具合チェックシステムを使う」というユースケースを追加します。
ちなみに、この「調査する」という時点のことを「拡張ポイント」と言います。
ユースケース図を作るために必要なこと
ユースケース図について、ここまでで概要は理解できたかと思います。次は、実際にユースケース図を作成する手順を解説していきます。
アクターとユースケースを書き出す
まずはアクターを明確にしましょう。アクターとは「システムを利用する人・組織」もしくは「関係する外部システム・ハード」を指します。関係する外部システムとは自動車など、人以外もアクターになります。
ユースケース図の上では、アクターはたとえ人以外であろうと「人型のオブジェクトと下部にアクター名」を記述するのがルールです。
最初はとにかくアクターを箇条書きで書き出すようにしましょう。どこまで細かく記載するかは、洗い出したあとに協議すれば問題ありません。
次にユースケースも洗い出しましょう。ユースケースとは「利用(use)」+「場面（case）」を繋げた言葉で、システムの利用例を表します。
たとえば人事担当者がアクターである場合、求められるユースケースは「社員の登録」「更新」「削除」「検索」などが挙げられます。ユースケースを洗い出す場合は、アクターごとに箇条書きで書き出しましょう。
クライアントへの説明用か、設計用に使うか決める
アクターとユースケースの洗い出しが完了したら、次はユースケース図の構成を決めましょう。構成を決めるときに考慮すべき点は、ユースケース図をクライアントに提出するかどうかです。
クライアントに提出もしくはプレゼンするときに粒度の細かいユースケース図を使用すると、かえってクライアントを混乱させてしまいます。
まずはクライアント向けに、大枠を作成したユースケース図を作成、のちに開発者向けの詳細ユースケース図を作成した方が効率がよいです。
検討結果をユースケース図に反映させよう
クライアントとの認識が共有できたら、あとは開発用のユースケース図に詳細を落とし込むだけです。
「アクター」「ユースケース」「サブジェクト」を書きだし、必要に応じてパッケージ・汎化などでユースケース図を発展させましょう。
もしユースケース図がシンプルすぎて誤解を生みそうな場合は「ユースケース記述」を作成しましょう。ユースケース記述は、ユースケース図の添付資料として詳細を表で簡潔にまとめたものです。ユースケース図の記述内容から誤解を産まないように、注意点を抑えておきましょう。
ユースケース図を実際に作ろう
ここまで理解すれば、ユースケース図を実際に作成する下準備は整いました。ユースケース図を上手につくるコツは、できるだけ多くのユースケース図に触れることです。頭で理解するだけなく、実際に手を動かして作成できるようになりましょう。
最後に、ユースケース図を実際に作るうえで注意すべき点と使用すべきシーンを紹介します。実務での利用シーンを想像しながら読んでみましょう。
ユースケース図を作るときの注意点
まずはユースケース図の作成中にありがちな失敗ポイントについて紹介します。ユースケース図の目的を理解していれば起こらないことですが、実際に書き進めているとミスしがちなポイントです。
注意すべき点は「ユーザー目線で記述されているか」「表記ルールを守れているか」という2点です。最低限、この2点だけは守るように心がけてユースケース図の作成にあたりましょう。
ユーザー目線で書かれているか
開発者の方にありがちな失敗として、つい詳細なシステムの構造までユースケース図に盛り込んでしまうことがあります。
たとえば出退勤の管理システムをユースケース図で表す場合、「社員の情報を入力する」「社員の出勤時間を入力する」「社員の退勤時間を入力する」と詳細も書き込みがちです。
しかし、クライアント向けにユースケース図を作成するのであれば「社員の情報を管理する」のみで問題ありません。ましてや内部処理のロジックを書き込む必要はまったくありません。
ユースケース図はあくまでも「ユーザー目線でシステムの利用例を表現する」という点を忘れないようにしましょう。
表記ルールを守れているか
表記ルールを守ることで、誰が見ても同じように読み取れるユースケース図を作成することができ、図の保守性を高めることができます。
保守性を高めるポイントは、ユースケース図の表記ルール遵守はもちろんのこと、「表現を統一する」のもコツです。
たとえば「出力する」と「アウトプットする」という表現は同じ意味を指します。同じユースケース図の中で異音同義語を使用するとユーザーに混乱を与えかねません。
多少のルール違反や表記の乱れでも、保守性に大きな悪影響を及ぼします。せっかく「だれがみても分かりやすい」というユースケース図を作成するのです。細かいミスでユースケース図のメリットを損なわないようにしましょう。
ユースケース図の使用例
ユースケース図が完成した場合の使用例を考えてみましょう。
クライアント向けの説明資料
ユースケース図の作成は、非ITエンジニアでも理解しやすく、完成するシステムのイメージを明確に持てるので新規営業や要件定義の時に便利です。
その反面、ユースケース図は開発時には使わない場合もあります。クラス図やシーケンス図など、開発時にも使えるUML図はほかにもあります。あとで開発用にも使うから、とユースケース図に余計なコストをかけず、クライアント向けの分かりやすい資料を作成するためだけに使うという方法もあります。
システム開発の資料用
もちろん、システム開発にもユースケース図を活用することは可能です。クライアント向けの資料をもとに、より詳細なロジックの流れを記述すれば開発の参考用として活躍できるでしょう。
ただし、詳細なロジックの記述をするなら他のUML図のほうが適している場合が多いので、ユースケース図だけでなく、ほかのUML図を利用することをおすすめします。
ユースケース図はすべてのシステム開発プロジェクトで使用するべきか
結論を書くと、必ずしもすべてのプロジェクトでユースケース図を作成する必要はないです。
ITリテラシーが高くないクライアントと取引するのであれば有効ですが、クライアントがシステム部門をもっている場合はより詳細な記述ができるUML図を利用したほうが効率的だからです。
UML図はユースケース図のみではありません。時と場合に応じて柔軟に使い分けましょう。
ユースケース図は分かりやすさが命
エンジニア向けの設計書、というよりはクライアントへの説明資料としての側面が強いのがユースケース図です。
作成すべきかどうか、分かりやすい内容になっているかには気をつけて、効果的にユースケース図を活用していきましょう。
