BPStudy#145〜進化する要件定義(RDRA meets DDD)に行ってきました(第1部)

RDRA2.0とは

資料

神崎善司様(@zenzengood)

感想

神崎様のRDRA2.0のお話はRDRA2.0の紹介と体験ワークショップに参加させていただいた際に伺ったことがあったのですが、数ヶ月経ち実際に業務で使ていくうちに浮かんだ疑問が今回の発表で解消されました。

業務で使っていている中で浮かんだ疑問点とそれに対する解決策は以下です。

  • 既存の案件に適用した際に依存の外側から順番に書いていこうとすると、既に開発してきていて合意が取れている部分についても作図していく必要があり今フォーカスしたい部分に注力できない。
  • ユースケースレベルの粒度で洗い出せれば良いところを情報/状態モデルまで作図する必要があると感じてしまう(これに関してはその時点で必要ないものについては書かなければよかったのですが、熟練しない内には型を破りたくないという私の趣向もあります)。

→ 外側のレイヤーから説明しているが必ずしもその説明した順番で記述する必要もなく、あくまでRDRAでは合意というのを大切にしているので合意が取れているのであれば必要のない図をわざわざ書く必要もなさそう

  • 概算見積もりにRDRAを適用していくイメージがつかめていなかった。

→ 重要なアクターに紐づくユースケースへと落とし込み、そのユースケースの数で概算見積もりを出す。より精度の高い見積もりが必要な場合はユースケース毎に画面等のブレークダウンした図を作成していき算出する。

また、前回の発表では一度に理解しきれなかった部分についても改めて聞くことで学び直しになり勉強になりました。

神崎様、ありがとうございましたm( )m

以下メモ

RDRAで解決したい世界

  • コンサルで苦労した要件定義をスムーズに進めたいのがモチベーション
  • 従来の要件定義では要件を決める人とその要件をまとめる人が分かれていて、要件を決める人が出したAsIsの資料をもとに要件をまとめ、レビュアーにレビューしてもらうで要件の決定がなされる。また、従来の要件定義にあるガントチャートについてはガントチャートを書く→計画どおりに行かないので人数を増やしてスケールさせる→するといきなり並行作業が始まって全体をわかっている人がいなくなりがちという問題がある。
  • アジャイル開発においても、最初は重なる部分が少ないがスムーズに開発が進んでいるように見えるが、結合が始まる中盤以降で手戻りが多くなってきて新規開発にリソースを割けなくなりバックログが減らなくなるという問題がある。
  • 保守開発においても品質の悪化が見られる。それは要求を出す人と実装する人が分かれているので影響度分析ができなく、また頼りになるドキュメントがなく頭の中の記憶が頼りになるため。システムの可視化を管理者がしたくても最新の状態をドキュメントとして維持できない。

上記の問題を解決することがRDRAのモチベーション

システム化に関わる要素

  • システムからシステム価値の方向へ依存している。 例) 画面のいるいらないはどうシステムを使おうと思っているのかがわからないと検討のしようがない

  • RDRAって何かを端的に理解するにはRDRAレイヤーのスライド一枚を参照する。

アイコンの関係

  • 文章ではなくアイコン間の線のつながりでWhyを表す。
  • システムの外部環境には業務フローと利用シーン、ビジネスユースケースが含まれる。業務フローで表現できない場合は利用シーンとして箇条書きで表す。商品のカテゴリ、取引先のカテゴリがあってある取引先に対するあるカテゴリの商品は1%割引のような組み合わせ間の条件をビジネスルールとして表で表す。
  • システム境界におけるイベントはファイルやり取りでもAPIでもOK。 なぜなら RDRAではHowを取り扱わない。WhatとWhyだけ 。 なぜHowを取り扱わないかというとHowを扱い出すと手が止まるから。

→ RDRAではスピード感のある合意を大切にしている

  • 情報モデルはビジネスを駆動する用語。
  • 状態モデルも情報モデル同様ビジネスを駆動する用語ではあるが、なんらかの動作を伴った結果。

ダイアグラム

  • システムコンテキスト→要求モデル→ビジネスコンテキスト→ビジネスユースケース→業務フロー利用シーンバリエーション→情報状態モデル→UC複合図 の順番で説明しているが、 必ずしもこの順番ではなく必要もなく、必要のないものは書かない
  • 一覧はRDRAのモデルを使えば後から生成できるので最初から一覧は作らない。合意の前に一覧にするということは色々先に決めてしまっていることが多いので注意。
  • 文章からではなくモデルのつながりで表現していく(文章と同じような表現力がある)
  • みんながドキュメント書き始めると関係がわけがわからなくなるのでみんなで図を書く。RDRAでは基本的に文章は書かない。最初から文章で書くと後から時間がなくて直さなくなり、いらない機能を作ることになりがち。
  • プロジェクトの特性に応じて使い分ける。 全部のプロジェクトで全部の図を書くわけではないアジャイル開発等ではある程度図を書いたら開発に入ったほうが良い。
  • システムの今を見られるので、保守開発とかで担当者ごとにバラバラのことを言っているのを防ぐことができる。
  • ブレークダウンしていく際は、ビジネスコンテキストの業務→ビジネスユースケース→業務フローという順番。これらをつくるとシステムの大体のスコープがわかるので概算見積もりを出せる。ただこれだけだと精度がわるいのでユースケースごとに画面とかを考えていくと精度を上げられる。

ダイアグラムの関係

  • システムコンテキストについては要件定義メンバー全員で認識合わせ。ただこれに時間かけてもしょうがないので30分程度でぱぱっと作る。
  • 要求モデルについては重要なステークホルダーと紐付いた要求リストを洗い出す。重要じゃないステークホルダーに紐づく要求は一旦切り捨てる(本当に重要ならまた話に上がってくるはず)
  • 1個1個の図を丁寧に作るのではなく、作れなかったらさっさと次に行く。現時点でわかることをできるだけ図に起こしていき、わからないことは一旦おいて次に行くイメージ。ヒアリングした要望がどこのモデルに属するのかを識別して書いていく。
  • 状態を変えるのはユースケースなので状態はユースケースにつなぐ
  • システムコンテキストは最初から書けない。色々な図を書いていく上で見えてくる。
  • 要求モデルもきちんとやろうするとすごい時間かかる。重要な要求を10個くらい整理していつでも見れるようにする。一覧100個もあるようなリストを作るとかやりがちだけど全部拾おうとしたらダメ。重要なもののみ救う。
  • 要求モデルは必ず作るわけではなくエクセルの一覧とかあるならそれにアクターくっつけて大事なもののみ拾う。
  • ビジネスコンテキストはリッチピクチャーよりちょっと引いて俯瞰してみたもの
  • システムの肥大化はビジネスユースケースでコントロールできる。何でもってビジネスユースケースを分けるかが大事。どのようなものを使っていてビジネスを回していて、 ビジネスユースケースが異なるということは何の差があるのかがわかるものを紐付ける ←これがビジネス要素
  • ユースケースに関わる画面や状態等を集めてきて結び付けているのがUC複合図
  • 状態モデルのユースケースこそ整合性の観点で重要。照会だけするユースケースとかは状態モデルに出てこなく、整合性という観点のみでいえばそんなに大事じゃない。ユースケース、情報、状態は繋がっている。ただ毎回やるのは大変なので毎回やるわけではない。 本当に精度が欲しいときだけあってユースケースさえ出れば良い時はやらない
  • 入出力、状態、バリエーションがビジネスでよく変わる。データ変えろってことはあんまりない。そこが変わるとどのユースケースにどういう影響が出るかを追跡できる。

RDRAが目指すもの

  • アイコン間のつながりが妥当かどうかで整合性が取れているか否かを判断する。

例)魚屋で寿司屋くれっていったらん?ってなるけどまぁなくもなさそう。ただ自転車くれって言ったら明らかに変なのでその温度感で業務に対しておかしいかどうかをつながりから判断する。

網羅性はアクターからはいってアクターに出ていくかどうかをみる。

  • 整合性も網羅性もつながりで説明できることで担保する。
  • 既存システムの可視化という観点では、1つの図を見て認識を合わせる。ドキュメントかっちり作るということではなくてある程度の粒度でもってコミュニケーションできる図をつくりましょうという話

ドメインモデルとの関係

  • RDRA的にはDDDと繋げてもつなげなくでもどっちでも良い。Howを取り扱わないので。
  • RDRAは外側から枠組み固めていくイメージ。DDDは内側から育てていくイメージ。タイムボックスで両方回していくのが良いのでは。