モデルベースで要件定義をやってみた に行ってきた #現場で役立つモデル駆動設計

モデルベースで要件定義をやってみた に参加しました。簡単に所感をまとめます。

modeling-how-to-learn.connpass.com

所感

途中で言ってたけど、ステークホルダが RDRA のモデルでコミュニケーションできるようになるのは理想の世界かもしれない。で、そのためには非エンジニアでも読みやすいように RDRA のモデルを工夫して書く必要があるようです。Figma + Instance Finder はよさそう。ただ、個人の思考ツールとして使うならそこまで作り込む必要はないんだろうけど。

業務の本質は RDRA で表現しにくいっていうのは興味深い視点。あと、RDRA は広さと深さを自由自在に行き来できるっていうのがいいポイント。

以下、メモから抜粋。

RDRAはどう形作られたか?

www.slideshare.net

  • 要件を決められない
  • 要件定義の精度が悪い
    • 暫定仕様が増え続ける
    • システムに近いところの機能を定義している
  • 精度を高める
    • 整合性は合っているか, 網羅しているか
  • 見積もり根拠
  • 要件を容易に変更したい
  • 全体の共通認識を得たい
  • What と Why を表現する
    • How は表現しない
  • ビジネうルールを表現する
    • 業務フローの単位を決める
  • 精度の高い要件 = 仕様の足場
  • ビジネスルールは条件 → 状態モデルで表現する
  • ビジネスユースケースを洗い出す
    • BUCがわかると全体のボリュームがわかり計画が立てられる

RDRA導入後の要件定義の変化

www.slideshare.net

  • 業務設計チーム
    • 企画と開発の橋渡し
    • プロダクトマネージャー?
  • 改修案件のQCDを上げたい
  • RDRAモデルをマスタにする
    • 改修案件でマスタから引用する
    • マスタにフィードバックする
  • BUCをプロダクトの業務として定義する
    • プロジェクトごとの業務フローの粒度をズレを防ぐ
  • 業務フロー, 状態モデル
    • 日本語による曖昧さを回避する
  • 非エンジニアでもRDRAモデルが読みやすくなるように工夫する
    • 記法の統一, 可読性の改善, 補助資料, ...
  • ステークホルダとの合意形成ツール

新規サービス開発で RDRA を使っている話

  • spreadsheet
  • アクター, 外部システム, 情報の洗い出し
  • ユースケース洗い出し
    • アクティビティ, UC の抽出粒度が難しい
    • 業務の理解度によって粒度が変わりそう
    • ヒアリング
  • 業務とアクターの分析
    • 誰がどのような業務をやっているか
    • 抜け漏れが見つけられる
  • 情報/状態の構造化
    • 情報の関連を引く
    • バリエーションのリストアップ
  • 要求の洗い出し
    • 業務要求/非機能要求を整理する
  • IT要求の解像度を上げる
  • ToBe の全体イメージを早めに付ける
    • 必要に応じて AsIs を詳細化する
  • 情報モデルの検討
    • オブジェクトモデルがあるとよい
  • アクター, BUC 洗い出し
    • ユースケースを細かくしていくと状態やバリエーションが見つかる
    • RDRAモデルで別の形で表現できたり
  • 状態モデルの検討
  • ToBe モデルを書き進めると自然と BUC が精査されていく
  • 粒度が粗いところは理解が不足しているかもしれない
    • 現状分析が必要

RDRAと業務と私

  • ヒアリング/観察
  • 業務を理解することで要件定義ができるように
  • チームの業務理解度を上げる
  • 書かないと読めるようにならない
  • ユーザーがシステムを触っている目線で書く
    • エンジニア視点だと細かくなりがち
  • ユーザーと一緒にRDRAを書く (モブプロ)
  • Enterprise Architect
  • Figma + Instance Finder
  • RDRA + JIG
  • 業務の本質はRDRAで表現しにくい

RDRA2.0を1年半つかって実感した効果

  • RDRAでそれぞれの関係性が整理できる
  • データ系モデルが作りやすい
  • 見積もりの精度をあげるときは仕様化/設計する
  • 設計/実装にスムーズに入れる
  • 段階的詳細化
    • 抽象 → 具体
  • 広さと深さを自由自在に行き来できる
    • 広さ (要件のリスト)
    • 深さ (要件の詳細化)
  • ユーザーストーリーマッピングは広さを担保するのが大変
    • 1つのマップを深堀りするため

ドメイン駆動設計にRDRA2.0を活用する

  • ユースケースをちゃんと洗い出せているか → RDRA
  • 視点を増やす
  • ユースケース ← 業務フロー ← ビジネスユースケース (業務バリエーション)
  • 関係で考える
  • 事業活動のモデル (ビジネスコンテキスト)
    • 業務のバリエーション
    • ビジネスルールを漏れなく見つける
  • それぞれは完全に洗い出せていなくても、それぞれの関係から考えることで抜け漏れを見つけられる
  • ビジネスルールとドメインモデルを固める
  • 共通認識のツールとしてRDRAのモデルを仕上げる

その他

  • クロスリファレンスできるツールが欲しくなる
  • spreadsheet はみんなでやるときに早くていい
  • ビジネスユースケースの粒度を合わせたい
  • 他のモデルを書いていくと粒度が合っていく
    • 理解が進んでバランスが取れていく
  • ピクト図解
  • 非機能要件 > 要求モデル図に書く
  • モジュラーモノリスで作る
    • コンテキストが明確になってから切り出した方がよさそう
  • BUCは早く出す
    • アクティビティを洗い出す
    • グルーピングして名前を付けてBUCを出した方がよさそう
  • RDRA
    • 個人の思考ツールとして使う
      • 実装に移行して以降は JIG で見る
    • マスタとして使う
  • revise しやすく保つためには軽くしておくとよさそう