🌟
モデルベースで要件定義をやってみた
概要
2021/10/29に開催された下記勉強会のメモです
セッション
RDRAはどう形作られたか？
- RDRAの構造
- 4つのレイヤーと依存関係
- WhatとWhyを表現->要件定義ではこの2つを明確に
- Howは表現しない->Howを考えると手が止まる
- ビジネスユースケースでボリュームがわかる
- 打ち合わせの回数、時間など計画が立てられる
RDRA導入後の要件定義の変化
※公開資料見つかりませんでした
- 課題
- プロダクトの業務仕様管理
- 業務仕様の把握・管理の属人化が進行
- 変更差分で全体像が把握できない
- 要件定義プロセス
- そもそもよくわかっていない
- プロダクトの業務仕様管理
- RDRA導入
- RDRAモデルによるサービス仕様マスタの作成
- RDRAの要素を要件定義書フォーマットへ反映
- 改善事例
- ビジネスユースケース(BUC)の定義活用
- BUCをプロダクトの業務として定義、プロジェクトごとに共通単位として利用
- BUC視点で話すと伝わりやすくなった
- 状態モデルの定義活用
- 「状態」は齟齬を生みやすい
- 曖昧さを回避
- 文字でなく図で
- ビジネスユースケース(BUC)の定義活用
- RDRAを使った要件説明における課題
- 見た目のとっつきにくさ
- 特に非エンジニアから不評
- 地道な広報活動、体裁を整える、補足資料作成などで対策
- 用語、アイコンの不統一
- ルール整備（トライアル中）で対策
- プロダクト毎に体制を分けた時にまたいだモデルをどう作るか
- 記載範囲や接点表現を協議（トライアル中）で対策
- 見た目のとっつきにくさ
- まとめ
- プロダクト全体像把握の重要性
- 属人化脱却と網羅性が重要
- RDRAモデルによる業務管理は効果を期待できる
- 要件定義を取り巻く社内ステークホルダとの合意形成ツール
- 理解とモチベーションは不可欠
- 記法を統一することの価値
- プロダクト全体像把握の重要性
新規サービス開発で RDRA を使っている話
- 要件定義中、RDRAでAsIsを作成しToBe BUCを整理途中
- スプレッドシートでアウトプット
- システムスコープは忘れてアクターと扱う情報を洗い出し
- アクティビティ、UCの抽出粒度が業務の理解度で変わる（課題）
- ToBeを先に進めて必要な箇所はAsIsを詳細化する進め方にした
- 図の作成にmiroを使った
- 共同編集できるのでパワポよりよかった
- ToBeモデルを描き進めると自然とBUCが精査されていく
- 関連づけで精度があがる
RDRAと業務と私
- Googleスプレッドシートと紙だったのをIT化
- 業務の理解度が上がらないとヒアリングできず要件定義ができない
- 業務の観察や事細かな質問で業務が見えてきた
- 要件を言葉で伝えるのは難しく、作業する人の業務理解度が乏しいと何度も手直しが発生した
- 逆に言えば要件定義ができれば業務の理解度は上がっているはず
- RDRAは書かないと読めるようにならない
- エンジニア視点だと細かくなりすぎるのでユーザー視点で書く
- RDRAはユーザとシステムについての意思疎通するためのフレームワーク
- Figma + Instance Finder Plugin を試している
- EAは複数人で同時編集できない
- Miroはアイコン同士の関連がうまく表現できない
- RDRAで表現できないものもある
- 宿泊体験を改善するという業務目標など
- RDRAで開発はできるのか？
- RDRAで業務理解->コード書いてJIGで確認->RDRAで俯瞰的に見る
RDRA2.0を1年半つかって実感した効果
- RDRAを導入する前要件定義をどうしていたか思い出せないほどAfterがよくなった
- Befor
- 場当たり的に必要なものを作っていた
- After
- 頭の中がつながった
- 図と図がつながって精度が上がる感覚
- メンバーのRDRAへの理解が早い
- データ系モデルを作りやすい
- すでにある業務のモデルから情報モデルが出せる
- 複雑になってきた時に情報を整理しやすい
- 一枚で表せないようなケースでも分割した図で繋がっているので全体が俯瞰できる
- 見積もりの根拠がわかりやすい
- UC複合図で複雑な条件が絡み合っていると見積もりが高い
- 精度を上げる場合には詳細化
- ソフトウェア設計・実装にスムーズに入れる
- ICONIXとRDRAは相性がいい
- 要件定義を進めやすい
- 段階的詳細化
- RDRAは自由自在に広さと深さを行き来できる
- ユーザーストーリーマッピングでは難しい
- システムの規模によってはすごく大きい図になってしまう
- ユーザーストーリーマッピングでは難しい
- 頭の中がつながった
ドメイン駆動設計にRDRA2.0を活用する
- RDRAのアプローチ
- 視点を増やす
- 関係で考える
- ドメイン駆動設計で抑えておくところ
- 3章 モデルと実装を一致させる
- 10章 変更を楽で安全にする
- 15章 コアドメインに集中する
- ドメイン駆動設計の主活動
- 事業活動のモデルからビジネスルールを言語化しドメインモデルを実装する
- 要件のモデル(RDRA)は補完する活動
その他メモ
RDRAは成果物でなくコミュニケーションツール
Discussion