はじめに
初めてシステム設計を経験した際、見本として提供された膨大なドキュメントに驚かされました。
なぜその順番で行い、なぜそこまで厳密に定義しなくてはいけないのか、最初はさっぱりわかりませんでした。
そこで、自分にとって最も区別のつけにくかった「ユースケース」と「機能」の違いについてまとめてみました。
対象
これからシステム設計を始める方、わからないことでつまずいている方
目次
システム設計に必要なもの
システム設計とは、プログラムソースに着手する前に設計書を作ることを指します。
その設計書（ドキュメント）を完全に再現することが、コードを書く上で重要なこととなります。
システム設計は、以下のような段階を経て完了します。（プロジェクトによって差異があります）
- 要件定義
- ユースケース図
- 外部設計
- 機能一覧
- 画面構成設計
- データフロー図
- 内部設計
- システム定数
- API一覧
- プログラムソース構成図
- インターフェース設計図
- テーブル定義
今回はこのうち、「ユースケース図→機能一覧へステップアップする際に何が変わるのか？」という点について考えてみます。
ユースケース図と機能一覧ってどんなの？
タスクを管理するアプリを作るという前提で、実際の設計書を見てみましょう。
ユースケース図
ユースケース図は、人とユースケース（行動）を繋げたものです。
これから制作するシステムによって達成したい目的に向けて、ユーザーがどんなことを出来るかを定めます。
機能一覧
機能一覧は、ユースケースを具体的にどうやって実現するかを定めたものです。
基本的に、機能一覧によって定義されたものとプログラムが果たす機能は一致するようになっているため、厳密な定義が必要です。
上記の例から、ユースケース→機能一覧は具体性を増していることがわかります。
システム設計においては、段階が進むにつれて粒度を高めていくため自然な流れではあります。
では、実際どういう風に具体性を増しているのでしょうか？
ユースケースと機能の違い
結論からいうと、以下の通りに考えると良いです
ユースケースはユーザーが「できる」こと
機能はユースケースを達成する「方法」
上記の例を見ると
- 目的: タスク管理
- ユースケース: タスクの新規作成
- 機能: タスク名、タスク内容を入力して新規作成ボタンを押す
となっています。
これを、以下のように変えることもできます。
- 目的: タスク管理
- ユースケース: タスクの新規作成
- 機能: タスク名、タスク内容をプルダウンで選択して「OK」ボタンを押す
つまりユースケースを決める時点で、タスクを新規作成する方法までは問わないわけです。
そもそも要件を考えて掘り下げていくための工程なので、最初に粒度の低いユースケースを考えた上で、「どんな機能として実装していこうか？」と考えていきます。
身近な例でも考えてみましょう。
- 目的: カレー作り
- ユースケース: 玉ねぎを切る
- 機能: 包丁で一口大に切る
ユースケースとしては玉ねぎさえ切れればいいので、以下のようにも書けます。
- 目的: カレー作り
- ユースケース: 玉ねぎを切る
- 機能: 包丁で大まかに切ったあと、野菜カッターに入れてみじん切りにする
このように、ユーザーにとってのユースケースは「必ずできること」の定義であり、機能はそれを達成する何らかの方法ということになります。
なお、どこまでをユースケースとするかは目的によって変わるでしょう。
例えば、料理教室だった場合は調理方法を厳密にしないといけないので、ユースケースを「包丁で一口大に切る」に設定する必要がありますね。
その場合の機能は、「子ども用包丁で」だったり、「１cm以下の薄さに」など、もっと細かい部分を決めていくことになるでしょう。
まとめ
- ユースケースより機能の方が具体性が高い
- ユースケースは「ユーザーが必ずできること」、機能は「ユースケースの具体的な実現方法」
システム設計のゴールは、プログラムを書くための要件を厳密に、すべて定義することです。
そのための一つの手段として、ユースケース図→機能一覧という流れに沿って要件を洗い出していく方法を用います。
調べてみたところによると、ユースケースや機能は、解説する人によってその定義が若干異なります。
なので、厳密に必ずこうであるという形式にこだわるのではなく、ユーザーのやりたいことを掘り下げるための一種の方法としてこんなものがある、と覚えておくのが良いと思います。
初めての記事ですが、誰かの参考になれば幸いです。