はじめに
本記事は、経験の浅いエンジニアを対象とした記事になります。
今回は、ユースケース分析についての紹介です。
下記観点からの理解につながれば幸いです。
- What ユースケース分析ってなに？
- When ユースケース分析は、どのタイミングでやるのか
- Why なぜユースケース分析をやるのか
- How ユースケース分析のやり方（ユースケース分析をやってみよう！）
目次
| 章 | タイトル | 概要 |
|---|---|---|
| 1 | ユースケース分析ってなに？ | ユースケース分析の基本的な考え方について紹介します。 |
| 2 | ユースケース分析は、どのタイミングでやるのか? | アプリケーション開発のどの段階で、実施するのか紹介します。 |
| 3 | なぜユースケース分析をやるのか | ユースケース分析の目的や意義について紹介します。 |
| 4 | ユースケース分析をやってみよう！ | 実際にユースケースをやりながら、実施していく際のポイントを紹介します。 |
1.ユースケース分析ってなに？
まず最初に、ユースケースとはなにか？、についてですが
結論、ユースケースは、システムの利用者や、そのシステムと連携する外部システムに対するシステムの振る舞いを、表現したものになります。
例えば、飲食店や小売店などで使われる会計システムの振る舞いについて考えてみましょう。
会計システムは、店員さんがお客様の注文データを入力して、それを元に金額を表示する機能を持っています。
そうなった場合、「店員さんが注文データの入力をする→システムが入力データを元に金額を表示する」が１つの振る舞いであり、ユースケースです。
このユースケースを洗い出す上で必要な視点が、
「店員さん、システム、外部システムの立ち位置を把握して、その三者の間でどのようなやり取りが行われているのか」ということを見る視点が必要になります。
先ほど例で挙げた会計システムのユースケースを表で記述すると、下記のようになります。
※ユースケース表の記載項目の説明に関しては、後述します。
ここまでのユースケースの説明を踏まえて、ユースケース分析とは何かというと、
「あるシステムのユースケースを洗い出して、そのシステムが持つ役割、使われ方を把握しようね」といった考え方、もしくは「開発するシステム内に実装する機能の内容を把握しようね」といった考え方になります。
2.ユースケース分析は、どのタイミングでやるのか？
結論、要件定義のフェーズもしくは、外部設計のフェーズでやります。
※プロジェクトによって、要件定義でやったり、外部設計でやったりと分かれますが、外部設計でやることが多いです。
3.なぜユースケース分析をやるのか。
結論、下記のようなメリットがあります。
・ 要件の粒度や表記方法に統一感ができる。
・ 見積もりの判断材料になる。
・ ユーザー企業との認識のずれを抑えることに繋がる。
・ プロジェクトメンバーのシステム理解や認識すり合わせに役立ち、開発工数削減に繋がる。
・ 開発後の運用で、プロジェクトのメンバーが変わっても、開発時と近い認識でプロジェクトに携わることができる。
以上のようなメリットを踏まえると、ユースケース分析はアプリケーション開発の上流の工程だけでなく、後続の下流の工程や開発後の運用にまで渡って活きる便利な考え方であると言えそうです。
そもそも、設計は現実世界にあるさまざまな「抽象的な」「フワフワした」「不明瞭な」課題や問題を、「具象的な」「ガチッとした」「明瞭な」ものに置き換えて、システムの世界で表現できるように持っていく作業だと思います。
そんな大変難しい作業の中で、「ユーザー企業やユーザーが求めるシステムを作り上げる」といったゴールに近づけていくためには、
段階的に少しずつフワフワした「もの」や「こと」を定義していき、線引きを増やし、認識のずれを抑え、形にしていくことが大切だと思います。
ですので、システム開発において認識のずれを抑えることに役立つユースケース分析は、アプリケーション開発の最初の段階で行う必要なプロセスであるとして、実際にプロジェクトで実施する方は多いのではないでしょうか。
4.ユースケース分析をやってみよう！
では実際にユースケース分析をやってみましょう！
まずユースケース分析をやる際に作成する代表的なドキュメントについて紹介します。
・ユースケース一覧表
・ビジネスルール一覧表
ユースケース一覧表とは、[ユースケース名,主アクター,主シナリオ,拡張シナリオ]の内容が書かれたユースケースをまとめた表です。
ユースケース名・・・そのユースケースのシナリオがどういった内容か推測できるような名前（例：注文を登録する、商品を配送する ）
主アクター・・・システムとやり取りする登場人物や外部システム（例：店員、会員、配送担当者 ）
主シナリオ・・・システムとのやり取りを表す文章。やり取りをステップに分けて、各ステップに順番に番号をふる（例：1.店員さんが注文データの入力をする 2.システムが入力データを元に金額を表示する ）
拡張シナリオ・・・主シナリオ内で考えられるまたは起こりうる別シナリオ（例:システムは決済エラーを表示する ）
※上記以外の項目で、[作成者,作成日,事前条件,成功時保証]などの項目を設ける場合もありますが、
今回は割愛します。
ビジネスルール一覧表とは、[ビジネスルール名,内容]が書かれたビジネスルールをまとめた表です。
ビジネスルール名・・・ユースケースから参照するときに使用する名前
内容・・・ユーザー企業がユースケースの主シナリオに書かれた業務をする上で、従わなければならない内容。
今回は、大手ECサイトの楽天市場を例に,ユースケース分析を行ってみました。
今回行ったユースケース分析はシステムのごく一部ですが、実際はあらゆる観点から洗い出した、たくさんのユースケースを元に分析する必要があるかと思います。
そこでユースケース分析の終了の目安なんですが、下記視点で不足がないか確認します。
・ある目的を実現するためのユースケースが足りているか
・あるアクターのライフサイクルからユースケースが足りているか
・全てのトリガーに対するユースケースが洗い出せているか
・関係者による承認を得ているか
上記の視点で振り返りながらユースケースの作成を進め、作成後は、ユースケース一覧表やビジネスルール一覧表を元にユーザー企業の方、プロジェクト参画メンバーと認識のすり合わせを十分に行うことが重要だと思います。
まとめ
ユースケース分析についての紹介は以上になります。
ユースケース分析は、「プロジェクト関係者との認識すり合わせ」から「開発」、「運用」までと幅広い工程で使える便利な考え方ですので、設計をする機会が今後出てきたら、積極的に上手く活用していきたいものです。
また今回、紹介したユースケース分析はあくまで一例にすぎず、明確なルールなどはありません。
参画するプロジェクトによって細かいやり方やルールは変わりますので、ご注意ください。
今回学習の参考にした書籍は下記になります。
設計の基本を知らなくても理解できる内容になっております。
次の記事は、「概念モデリング」についての執筆を予定しています。
拙文最後までお読みいただきありがとうございます。
Discussion