RDRA3.0とは（AIを使ってRDRA定義する）

RDRAの基本的な考え方と、Graphを使ってビジュアルに表示する
またAIを使って段階的なRDRAの組立の考え方を示す

Transcript

1. RDRA3.0とは
2. • ㈱バリューソース • 神崎 善司 • twitter：@zenzengood • RDRA：https://www.rdra.jp/ • 著作 • モデルベース要件定義テクニック • RDRA2.0ハンドブック • RDRA3.0ハンドブック • 仕事 • RDRA導入支援 • 要件定義支援 • 既存システムの可視化支援 • 好きな事 • システムの可視化 • モデリング • 表形式でのモデリング • LLMの活用 2 https://www.rdra.jp/
3. RDRAを作った動機 • システム全体を説明できない • 簡単な概要は説明できるが、そこからいきなり個別の機能の話しかできない • 機能中心で業務とシステムが乖離している • 業務の価値とシステムを結びつけられない • 関係者が共通に話ができる土台がない • 結合テスト時点で認識があっていなかったことが分かる • 停滞するアジャイル開発 • 手戻りばかりで新規の開発が停滞する • 要件を決められない • 要件定義に時間がかかりすぎ、要件が見切り発車になる 3 シス テム 業務 概要 機能 企画 営業 開発 サポート RDRAはこれらを解決 するために考えられた
4. RDRAとは 表形式でRDRA定義を行う 4
5. RDRAレイヤー システム価値 システム外部環境 システム境界 システム Why Why Why アイコン アイコン アイコン アイコン システム化の 価値 システムの使われ方 を示す システムの入出力 を明らかにする システムで管理 する情報、状態、 ビジネスルール 依存 RDRAがフォーカスするのは ⇒ 役に立つシステムを作るためにはどのように要件定義すればいいのか 5
6. RDRA構成要素 依存 システム価値 システム境界 システム 外部システム 要求 アクター システム外部環境 業務フロー アクティ ビティ ユースケース 状態 遷移 Why Why Why 条件 バリエー ション 業務 ビジネス ユースケース 情報 状態モデル 画面 イベント コンテキスト タイマー アクター群 外部システム群 画面 6
7. ドメイン 全UC：ダイアグラム RDRAレイヤー システム境界とシステムの関係 7
8. RDRASheet 表形式でRDRA定義を行う 8
9. 条件 バリエーション 状態 機能要求 非機能要求 アクター 外部システム 情報 業務・BUC・アクティビティ・UC 情報 画面 アクター イベント 外部システム タイマー 表形式の RDRA 9
10. 非機能要求シート 機能要求シート アクターシート 外部システムシート 情報シート 状態シート BUCシート 画面 イベント タイマー バリエーション シート 条件シート 業務 BUC アクティ ビティ UC 情報 条件 条件 状態 モデル バリエー ション 状態モデル UC バリエーション アクター 外部システム アクター 外部システム 情報 バリエーション 状態モデル 参照 参照 非機能要求 機能要求 参照 参照 参照 参照 参照 定義 定義 定義 定義 定義 定義 定義 定義 定義 定義 定義 定義 シート間 の関係 10
11. 表形式で構造化する BUC アクティビティ・UCにつながるオブジェクト定義 条件 外部システム アクター 状態モデル アクティビティにアクターが関わる 外部システムが提供する画面を使う システムの画面をアクターが使う システムが外部システムとイベントで連携する UCが情報を操作する 業務フロー アクティビティ ユースケース 業務 BUC 画面 イベント 状態モデル 条件 バリエーション UC タイマー UCが決められた時間に実行する 情報 11 始点 終点 同一行にあるものは関連 しているとみなす 階層構造を表す 階層構造を表す 階層構造を表す
12. サンプル https://docs.google.com/spreadsheets/d/1_71mDEJVvbuILjLWQca_QXSsfOnFMkHgdL0cXEQPvrc/edit?usp=sharing https://docs.google.com/spreadsheets/d/1_ 71mDEJVvbuILjLWQca_QXSsfOnFMkHgdL0c XEQPvrc/edit?usp=sharing 上 記 リ ン ク を コ ピ ー フ ァ イ ル / コ ピ ー 作 成 自 分 の Google Drive に セ ー ブ 以 下 の シ ー ト を 確 認 ア ク タ ー 外 部 シ ス テ ム 情 報 状 態 BUC 条 件 バ リ エ ー シ ョ ン • 上記リンクをコピー • ファイル/コピー作成 • 自分のGoogle Driveにセーブ • 以下のシートを確認 • アクター • 外部システム • 情報 • 状態 • BUC • 条件 • バリエーション 12
13. RDRA分析 UC_PIVOT 13 UC_PIVOT 情 報 ア ク タ ー 外 部 シ ス テ ム 業務/BUC/UC
14. RDRA分析 不整合シート 14 RDRA定義 RDRA分析 RDRA定義を参照し 不整合を検出する エラーの意味は コメントを確認 以下の不整合を検出する ・定義されたが参照されていない ・参照されているが定義されていない
15. RDRAGraph 要件をビジュアルに可視化する 15
16. 表形式からGraph構造へ 表形式からグラフ構造へ コピー ビジュアル化 3.RDRA分析_V0.98 「関連データ」シート A1:D41(最終行)までをコ ピー データ／関連データ取込 システム名を入力 データをペースト 16 https://vsa.co.jp/rdratool/v0.93/index.html?init
17. 個別のアイコン から関係を表示 アイコンをクリックすること で、そのアイコンを中心とし たダイアグラムを表示 要件を可視化し矛盾や問題点を探す 17
18. 俯瞰した視点から不整合を見極める コンテキストは業 務でつながるはず コンテキスト 業務 コンテキストが 業務でつながる 18
19. 可視化例：トップダウン 19
20. 可視化例：アクター視点 20
21. RDRAAgent LLMでRDRA定義のたたき台を作成する 21
22. AIにビジネス概要を入力 # 訪問介護システム要求 ## 背景 介護業界では、介護会員の要望に合わせ、様々な法規の中でサービススタッフの多様な働き方でスケジュールを調整 する必要がある ## 要求 ・サービススタッフの柔軟な働き方に対応しかつ介護会員の要望に合わせたスケジュール調整を行える仕組みを持つ ## ビジネスポリシー ・各サービススタッフの要望に合わせたスケジュール管理を行う ・訪問介護事業で小規模事業社を複数持つので、そこを一元管理を行う事業所をもつ ・サービススタッフの働き方は出来るだけ自由に設定できる ・サービススタッフのスキル別に出来る仕事を適切に配分する ・介護会員の要望に合わせたスケジュール調整を行う ・ビジネスパラメータの組合せに柔軟に対応できる業務形態にする ## ビジネスパラメータ ・介護会員とサービススタッフの自由度を保つために介護施設を分類できる ・サービススタッフの自由度を保つために働き方を細かく分類する ・介護会員の状況を細かく分類できる ## 業務概要 ・介護会員の管理（名前、連絡先などの様々な属性を管理） ・効率的な訪問介護の計画 ・訪問介護の実施記録を管理する ・新しいサービススタッフの教育 ・介護費用の計算と請求及び回収 22
23. AIを使い段階的に要件を定義させる 23 RDRAZeroOne 【１】 プログラムでAIをコン トロールする 2024 【２】 Agentで要件を組立てる 2025
24. 段階的に生成を検証しながら進める Phase1 Phase2 Phase3 Phase4 要件（RDRA） 論理データ モデル 要件の妥当 性検証 仕様の妥当 性検証 妥当性検証環境.csv 初期要望 【１】初期の要望を入力する Agent 【２】Agentが成果物を出力 要件妥当性検証結果 検証概要 本検証は、訪問介護管理システムのRDRA定 義について、「RDRA説明.md」に記載され たストーリーを基に、3つの視点（BUC視点、 アクター/外部システム視点、情報視点）か ら妥当性を評価したものです。 検証日: 2025-11-07 検証結果サマリー 本検証では、RDRA定義と説明書の整合性を 確認し、定義の欠落、矛盾、制約違反によ り現状では実現不能な項目（判定：不可）、 および未確定要素や外部依存があり前提が 満たされれば実現可能な項目（判定：要確 認）を抽出しました。 判定基準OKの項目は本結果には含まれてお りません。 論理データモデル 【６】 論理データから要件の 確からしさを把握する 【４】 要件を検証するためにシステム の導入環境を入力 【３】 Agentの出力を次の Agentの入力にする V字モデルを左と右から同時に進める 【５】要件を検証 Agent 24 ビジネスルール
25. 論理データモデ ルの説明 @論理データモデル.md の各 Entityの役割と他のEntityとの関 係から、この論理データのでき ることと役割を一つのわかりや すい文章で説明してください AIに論理データモデルに ついて聞く 25
26. 多段に人とLLMがキャッチボール Prompt knowledge Prompt knowledge Prompt knowledge LLM 出力 出力 出力 初期要望 Prompt knowledge 出力 ４つのフェーズでコンテキストを膨らませ軌道修正する フェーズ１ フェーズ２ フェーズ３ フェーズ４ 26 RDRA 【４】LLMの出力を見直し、次のフェーズの入力とする 段階的な詳細化で要件を軌道修正しながら組み立てる 【２】 Prompt入力 に悩ませない 【１】 要件を定義す るナレッジ 【３】 要件に集中する Phase1 Phase2 Phase3 Phase4
27. ホームページからAIで業務を可視化 カスタマーサクセス業務 情報 AI RDRA 27 NotebookLM
28. 統合基盤管理 28
29. 統合基盤管理 29
30. Demo 要件妥当性検証結果 検証概要 本検証は、訪問介護管理システムのRDRA定義について、「RDRA説明.md」に 記載されたストーリーを基に、3つの視点（BUC視点、アクター/外部システム 視点、情報視点）から妥当性を評価したものです。 検証日: 2025-11-07 検証結果サマリー 本検証では、RDRA定義と説明書の整合性を確認し、定義の欠落、矛盾、制約 違反により現状では実現不能な項目（判定：不可）、および未確定要素や外部 依存があり前提が満たされれば実現可能な項目（判定：要確認）を抽出しまし た。 判定基準OKの項目は本結果には含まれておりません。 30
31. まとめ RDRAは何を変えるのか 31 物事のつながり で詳細を語る 成果物作成より も合意を重視 一覧と詳細 ユース ケース 画面 情報 イベント 物事の関係性を語る 一人で考え一人で作成 一つ一つを完成させる 徐々に洗練化する 成果物ではなく 要件を組立てる 構造が要件を組 み立てる 文書で意味を伝える 関係で意味を伝える みんなで考えその場で作成 What Why 文書では関わり が分かりづらい 粒度の細か い定義 粒度の細 かい定義 粒度の 粗い 定義 Xx x Xx x Xx x Xx x Xx x Xx x 詳細化を目指す 次工程で扱い やすくする 要件を決める仕組み がない 要件を決める仕組 みがある 依存 レイヤー 依存関係が要件 を決める 粒度を揃え る