こんにちわ、んだです
今回のテーマは「ユースケース」です
読んだきっかけ
きっかけとなったのは、業務でユースケース駆動開発の手法を取り入れながら開発したことです。
やってみて作るものに対する情報整理の方法、情報整理したものが実装にスムーズに繋がっていく点などなど、ユースケース駆動開発が非常に有効なアプローチであることを実感しました。
この経験を通じて、ユースケース駆動開発についてより深く学びたいと考え、ユースケースと名のつく本を探していました。
その時に、『ユースケース駆動開発実践ガイド』の著者であるダグ・ローゼンバーグが書いた本書を見つけ、興味を持って読んでみることにしました。
読んでみて
『ユースケース入門』は、『ユースケース駆動開発実践ガイド』よりも情報量は少ないものの、その分読みやすく概要を掴むのに最適な本だなと感じました。
『ユースケース駆動開発実践ガイド』も非常に良い本ではありますが、その分量が多く、全体像を把握するのに苦労することがあります。
それに対して、本書はページ数が少ないにも関わらず、アプローチの要点や「やってはいけないこと」や「陥りがちなアンチパターン」などが各プロセスごとにまとめられており、分かりやすい内容となっています。
例えば、ドメインモデリングのフェーズでは時間をかけすぎず、2～3時間程度で区切りましょうなどなど。
各プロセスごとに、注意点やプロセスの目指す地点などが明確に書かれてます。
ただし、この本を読んで実践に使えるレベルまで学べるかというと、それは必ずしもそうではありません。やはり、『ユースケース駆動開発実践ガイド』を読むことで、より深い理解と実践力を身につけることかなと思いました。
とはいえ、ICONIX統一オブジェクトモデリングのアプローチとはどんなものなのかを知るためには、本書は非常に適していると思います。
学びになったポイント
ここからは学びになったポイントについて、ピックアップしてお届けします
1. 方法論にとりつかれるな
2. ICONIXアプローチは、イテレーション、インクリメンタル、トレース性
3. ユースケースと要求と機能の違い
順にお話しさせていただきます。
方法論にとりつかれるな
本書の最初の方に、方法論についてという章があるのですが、その章のなかで
方法論が宗教になってしまうと、望んだ結果を導いてくれるどころか、大きな問題が発生しプロジェクトが失敗してしまいます
とあります。
方法論はプロジェクトを成功へ導く指針となるものですが、それを宗教のように熱心に信じてしまうことは避けるべきだということですね。
ICONIXアプローチに限った話ではありませんが、なんらの方法論を学び実践する時には常に意識していきたい熱いメッセージです。
「方法論にとりつかれるな」というメッセージを受けて、僕は
方法論がなぜ生まれてきたかという背景や課題感を理解しておくこと
方法を用いて解決したい課題と望んでいる結果は合致しているか
が大切だなと思いました。
例えばなんですが、すべてのユースケースについてロバストネス図を作成する必要があるか？ということを考えてみます。
僕は、ユースケースの複雑度合いによっては省いてもありだなと考えています。
そこの判断は、ユースケースの複雑さによるでしょうし、程度にもよりますが、ロバストネス分析がなくとも、実装フェーズで困らないユースケースもあるかもしれません。
なぜ、そう思うかというと、ロバストネス分析は、設計と実装の橋渡しをしたいというニーズから考案されたツールだからです。そのため、ある程度実装の想像がついてしまうのであれば、作成を省く、もしくは大雑把なものでもよしとするなどもアリではと思います。
ということで 、ICONIXアプローチの各プロセスが生まれた背景やどのような課題を解決するために生まれてきたツールであるのか を理解しておくことが、より上手に道具をつかいこなせるようになるのだと思いました。
イテレーション、インクリメンタル
本書では、ICONIXアプローチの特色として、
* イテレーション、インクリメンタル
* トレース性
* UMLの合理的な使用法
の３つを挙げています。
この中で、特に押さえておきたいのが、イテレーションとインクリメンタルの部分です。
具体的に説明していきます
ICONIXアプローチの設計フェーズは、以下のように進んでいきます。
1. ドメインモデリング
2. ユースケースモデリング
3. ロバストネス分析
この設計フェーズでは、
最初から完璧を目指す必要はなく、ユースケース、ロバストネス分析、ドメインモデリングを行ったり来たりしながら洗練させていこうよ
というスタンスで書かれています。
これを、イテレーションとインクリメンタルという表現で説明しています。
この点を意識して、チームでこのフェーズに取り組むことが非常に重要であると感じました。
つまり、時間をかけながらチーム内で認識を深めていけばいいのだ、と。この点は、この意識は設計フェーズだけでなく、プロジェクト全体を通じて持ち続けるべきだなとも思いました。
また、具体的にユースケースモデリングを行なっていく際にも、イテレーションとインクリメンタルという意識を持っておくことで、問題領域への理解を徐々に深めていくのだという気持ちにもつながり、良きですなと思いました
ユースケースと要求と機能の違い
最後は、ユースケースと要求と機能の違いです。
ユースケース、要求、機能は、並べてみると似たような感じですが、厳密には違います。
そして、この違いを理解することで、ICONIXアプローチと仲良くなれる気がします
以下にそれぞれの定義を示します。
ユースケース：一単位の振る舞いを説明する
要求：その振る舞いを管理するルールを説明する
機能：振る舞いの中で起こる個々のアクション
そして、要求には5つのカテゴリがあります。
機能要求：システムが提供する機能やサービス
データ要求：システムが扱うデータの種類や形式
実行要求：システムの性能や可用性に関する要求
容量要求：システムが対応するべき規模やストレージ容量
テスト要求：システムのテストや検証に関する要求
具体例を通じて、解説していきます。
例として、あるオンラインショッピングサイトを考えましょう。
このサイトでは、どのECカートにもあるように、ユーザーが商品をカートに追加し、注文を確定できる機能があります。
たとえば、商品の購入というユースケースを考えてみましょう。
要求とは、「その振る舞いを管理するルールを説明する」でした。商品の購入といっても、当然ですが、購入できればOKではなく、そこには様々な要求が絡みます。
機能要求：ユーザーが商品を購入できなければならない
データ要求：システムは各商品の在庫情報を管理すべきである
実行要求：注文の処理速度は一定の基準を満たさなければならない
容量要求：システムは同時に複数のユーザーの注文を処理できなければいけない
テスト要求：システムは注文処理の正確さを確認するためのテストケースを実行する
そして、最後、機能とは「振る舞いの中で起こる個々のアクション」でした。
商品の購入というユースケースの機能＝個々のアクションは、
- 商品を検索する
- 商品をカートに追加する
- カートの中身を確認・編集する
- お届け先情報を入力する
- 支払方法を選択する
- 注文内容を確認し、確定する
こんな流れでしょう。
この例からわかるように、ユースケースは一単位の振る舞いを説明し、要求はその振る舞いを管理するルールを説明し、機能は振る舞いの中で起こる個々のアクションを示しています。
ユースケースと要求と機能の違いを理解すると、ユースケースとして何を切り出すべきかが見えてきますし、そのユースケースに課されている要求についても考えながら作業を進めていく必要があることがわかります。
この内容は最終章に近い７章に登場するのですが、ボク的には考えが整理されてハッとしてグッときました
まとめ
この本の初版が2001年。そして、ICONIXアプローチが登場したのは1993年。 なんと歴史ある問題意識でしょう、そして現在でも十分に使える考え方だなと改めて凄さを感じます
まだまだ、理解を深めていきたいと思いました
僕から以上。あったかくして寝ろよ
