🗂
ユースケース駆動開発をやってみた
概要
2021/12/08に開催された下記勉強会のメモです
セッション
①僕がユースケース駆動開発をする理由
ユースケース駆動開発を実践するモチベーションについての話
プログラムを書こう
- よりよいシステムを作りたい
- システム開発の難しさ
- 何を作ればよいのか -> わかってないのがほとんど
- どう作ればよいのか -> 開発者はこちらに目が行きがち
- 目的と作り方を同時に意識したい
プログラム=ユースケース
- 何ができて、どういうやり取りで実現するか
- ユースケースを中心としてシステムを考えると、「何を」と「どうやって」を常に分離せずに考えられる
ユースケースはできないことを明確にする
- 書かれてないことができない
トークの中で出てきた「要はバランスおじさん」についてまとめ記事を紹介してくださった方がいて面白かったのでメモ
②ユースケース駆動開発のワークショップやってみた！
こちらの本を読んでICONIXプロセスについてまとめた記事
UMLに含まれないロバストネス図を使うのが特徴
ICONIX経験者を指南役にメンバーの中からドメインエキスパートを決めてワークショップを実施
以下のICONIXプロセスの流れに沿うことで理解が深まった
->前プロセスの成果物に足りないものが判明して修正していった
- ドメインモデリング
- ユースケース図
- ユースケース記述
- 基本コースと代替コース
- ロバストネス分析
- ワイヤーフレーム作成
③ユースケース駆動開発で自社プロダクトを作ってみた！
自社ブロダクトをユースケース駆動で開発した話
全員がドメインエキスパート・プロダクトオーナー
- ロバストネス図はユースケースと詳細設計のギャップを埋めるもの
- ユースケースの見直し、詳細設計時に考慮すべき点を洗い出せる
- 機能一覧・画面使用・DB提議書を作成する基本設計から脱却できそう
- ユースケース図、ロバストネス図を書けるようになるだけで設計スキルはあがる
④分析・設計・テストで活きる ユースケースシナリオの書き方と使い方
コーバーン流ユースケースシナリオ
- ユースケースのレベルは3つ（粒度）
- 要約
- ユーザ目的
- サブ機能
- ユースケースシナリオはユーザー目的レベルにフォーカス
- 終わった後にコーヒーを飲みに行けるか
- いくつ終わらせるかで仕事の成果が変わるか
- 連続した時間内に完了するか
- シナリオ記述のポイント
- アクターの意図を書く
- 事前条件を書いて副シナリオを減らす
- ユースケースは参照可能な共有体験
- プロダクトオーナーとユースケースをともに作り理解のギャップを埋める
- ユースケースは分析でなく確認（バリデーション）ツール
- ドメインモデルの構造と振る舞いを検証
- ユースケースシナリオはそのままの形で受け入れテストに使える
- ユースケースを構造化しておけば次のプロジェクトで役立つ（かもしれない）
- NotionでRDRAの例
⑤コード中心からモデル駆動設計へ
- 炎上プロジェクトから、ICONIXとの出会い
- ユースケースどうやって見つけるの？
- よい設計・良いモデルを求めて
- モデルベース要件定義
- ドメインモデル
- システム関連系
- イミュータブルデータモデル
- 契約による設計
- 現在の取り組み
- モデル駆動設計の主活動
- 補完する活動
Discussion