Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RDRA 越境アジャイルin大阪

638 views

Published on

5/20 越境アジャイル プレゼン資料

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

RDRA 越境アジャイルin大阪

  1. 1. RDRA for 越境アジャイル 短期間にシステムの全体像をつかむ 2017/5/20 1
  2. 2. わたしは…  ㈱バリューソース  代表取締役 社長  神崎 善司  zkanzaki@vsa.co.jp  要件定義の散歩道:https://www.facebook.com/youkennotsubo  twitter:@zenzengood  要件定義手法の開発  RDRA Relationship driven requirement analysis  普段は  システム企画・要件定義などの支援  既存システムの可視化支援  セミナー開催(要件定義、モデリング)  要件定義用ツールの開発 2
  3. 3. なんでこうなるのか? RDRAができた背景 XXX XXXX XXXXX XXXXX XXXX XXXXX XXXXX XXXXX AAAAA AAAAA AAAAA AAAAA AAAAA 日付 担当者A 担当者B 担当者B 担当者A タスク 担当者 この方向に圧縮 する思考になる 変更の影 響が大きい 早い段階から個人 ワークが始まる 辻褄が合っていない 大量のドキュメント 誰も説明 できない 要件を変えたくて もどこに影響が出 るか分からない 要件定義の途中 から要件が変え られなくなる 経験したいくつものプロジェクトで…
  4. 4. RDRAとは RDRA:Relationship driven requirement analysis 要件定義の仕組み 4
  5. 5. 要件定義には何を定義すればいいのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 RDRAでは「要件定義の対象をシステムとシス テムを取り巻く環境」と考える システムを 取り巻く環境 システ ム 要件 定義書 5
  6. 6. 要件定義では何が定義されないといけないのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 •その機能が使用するデータは? •システムに必要な機能は? •その時の入出力情報は? •システムとの接点は? •どのようにシステムは使われるのか? •どのような人、外部システムと関わるのか? •このシステムの目的(価値)は? 6
  7. 7. もの サービス システム価値 もの サービス 利害関係者 ユーザ 要件定義の構造を定義する システム外部環境 外部システム システム 機能 データ 機能 機能 利害関係者 ユーザ 外部システム システム システム境界 機能 データ 機能 •システム価値 •システム外部環境 •システム境界 •システム 要件定義の構造 7
  8. 8. システム価値 もの サービス 利害関係者 ユーザ 要求 価値 外部システム 要件分析の枠組み 構成要素 1.【システムの価値】を捉える •対象業務に関わる人を洗い出す •関係する外部システムを洗い出す •要求を捉える 2.【システム外部環境】を捉える •対象業務の流れを捉える •対象業務に関わる概念を明らかにする •システムの利用シーンを明らかにする 3.【システム境界】を捉える •ユーザインターフェースを明らかにする •外部システムとのインターフェースを明 らかにする 4.【システム】を定義する •機能を明らかにする •データを明らかにする •ドメインの構造を把握する システム外部環境 システム 機能 データ 機能 システム境界 利用 シーン 8
  9. 9. システム価値 システム外部環境 システム境界 システム UC:ユーケース 全ての情報をつなげる コンテキスト 利用シーン 業務 イベント ユースケース概念 画面・帳表 機能 データ 要求 機能複合 モデル 利用シーン &UC 業務&UC 状態 UC&画面 UC&機能 プロトコル 9
  10. 10. 各要素がつなげる 10 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 関係が整合性、網羅性を確保する RDRAの構成要素とつながり 利用シーン 限定された要素でつながりを表現する ことでコミュニケーションを促進する
  11. 11. 要件定義を越境する RDRAで行うということは… 11
  12. 12. 何を変えるのか 12 情報のつながりで詳細を語る 成果物作成よりも合意を重視 一覧と詳細 ユース ケース 画面 データ イベント 情報の関係性を語る 一人で考え一人で作成 成果物作成が目的 要件を明らかにするのが目的 ドキュメントではなく要件を組立てる 複数視点の構造がWhyを語る 詳細化に関心 複数視点の関係に関心 みんなで考えその場で作成 What Why Howに向きやすい
  13. 13. 越境アジャイルの道具立て 13 RDRA for DDD
  14. 14. RDRA for DDD 14
  15. 15. 要求側と開発側でのモデルイメージ 15  要求側:広く浅く分析するためのモデル ⇒ RDRA for DDD  開発側:深く分析するためのモデル 要件定義 受入テスト 開発計画 プロト プロト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト プロト ドメインロバストネス図 機能連携図 UC 状態 状態遷移図 コンテキスト 業務フロー 要求 利用シーン ビジネスルール XXXXX XXXXXX XXXXXX XXXXX XXXXXX XXXXXX シナリオ XXXXX XXXXXX XXXXXX XXXXX XXXXXX XXXXXX シナリオ 要求側 開発側 ビジネス ルール
  16. 16. システム価値 システム外部環境 システム境界 システム UC:ユーケース RDRA for DDD コンテキスト 利用シーン 業務フロー イベント UC複合モデル 要求 状態 プロトコル オプション オプション UC 情報 or 情報 画面 イベント 「システム境界」の詳細化と「システ ムの分析」は開発側に任す 16 RDRAの役割は安定したユー スケースを素早く洗い出す
  17. 17. RDRA for DDD システム地図 要件としての整合性、網羅性を確保する システム地図の構成要素 17 画面 ユースケース 情報 外部システム イベント 利用シーン 業務フロー
  18. 18. RDRAとドメインモデルの関係  RDRAは本来開発方法を選ばない Howは扱わない  RDRA for DDDのスタンス  深い分析は開発側(ドメインの分析)に任せ、RDRAは整合のとれた要件を定義することに徹する  RDRA 広く浅く分析  ドメイン分析 深く分析 ガツンと中心となる概念 をつかんで、育てていく RDRA Domain RDRAが外から攻め ドメインモデルが中核から攻める ドメインモデル RDRA 広く網を張り徐々に固めていく 18
  19. 19. 変化に耐えられる軸  軸があれば変化してもぶれない  要件定義 軸:RDRA 広く浅い分析  開発 軸:ドメインモデル コンテキスト単位の深い分析 要件定義の軸 開発の軸 19
  20. 20. 要件と開発の両輪でまわす  要件定義と開発の両輪で回す  要求側 ⇒ システムの主要な構成要素を洗い出し、分類する  開発側 ⇒ 中核となる概念を中心に深い分析を行う  2つのチームが外側と内側から並行して進める 開発 要件定義 計画 プロト プロト 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト 継続的インテグレーション 要求側 (情シス) 開発側 20 RDRA ドメインモデル フィードバックによる洗練化 先行開発 主要な 構成要素
  21. 21. まとめ RDRA for DDDの構成要素 メンバーの頭の中を可視化し、 統一した要件としてまとめる 21 RDRAとは様々な要素で構成されるシステム を限定された情報で表現する 画面 ユースケース 情報 外部システム イベント 利用シーン 業務フロー

×