要件定義の中心にモデルを置きLLMが出力した要件に責任をもつ

RDRA手法を使ってAIに要件定義させるために取り組んだ以下の課題の説明

前提：AIは個別の企業のことを何もしらない

【課題】
・LLMの出力をいかに理解するか
・どうやって適切なコンテキストを用意するか
・LLMの出力をどのように軌道修正するか

Transcript

1. 要件定義の中心にモデルを置き LLMが出力した要件に責任をもつ
2. • ㈱バリューソース • 神崎 善司 • twitter：@zenzengood • RDRA：https://www.rdra.jp/ • 著作 • モデルベース要件定義テクニック • RDRA2.0ハンドブック • RDRA3.0ハンドブック • 仕事 • RDRA導入支援 • 要件定義支援 • 既存システムの可視化支援 • 好きな事 • システムの可視化 • モデリング • 表形式でのモデリング • LLMの活用 2 https://www.rdra.jp/
3. LLMを使う上での課題感 •AIは個別の企業のことを何もしらない •課題 • LLMの出力をいかに理解するか • どうやって適切なコンテキストを用意するか • LLMの出力をどのように軌道修正するか 3
4. 今日お話しすること 初期要望 AIに作業を行わせるためにモデルを中心に置く 【３】 アクター別の画面イメー ジで要件の精度を高める 【１】 ビジネスの背景と概要を記述 し、AIに要件を定義させる 【５】 論理データから要 件の精度を確認 要件妥当性検証結果 検証概要 本検証は、訪問介護管理システムのRDRA定義につい て、「RDRA説明.md」に記載されたストーリーを基 に、3つの視点（BUC視点、アクター/外部システム 視点、情報視点）から妥当性を評価したものです。 検証日: 2025-11-07 検証結果サマリー 本検証では、RDRA定義と説明書の整合性を確認し、 定義の欠落、矛盾、制約違反により現状では実現不 能な項目（判定：不可）、および未確定要素や外部 依存があり前提が満たされれば実現可能な項目（判 定：要確認）を抽出しました。 判定基準OKの項目は本結果には含まれておりません。 【４】 要件の妥当性を検証させる 【２】 要件をビジュアライズ 4
5. AIにビジネス概要を入力 # 訪問介護システム要求 ## 背景 介護業界では、介護会員の要望に合わせ、様々な法規の中でサービススタッフの多様な働き方でスケジュールを調整 する必要がある ## 要求 ・サービススタッフの柔軟な働き方に対応しかつ介護会員の要望に合わせたスケジュール調整を行える仕組みを持つ ## ビジネスポリシー ・各サービススタッフの要望に合わせたスケジュール管理を行う ・訪問介護事業で小規模事業社を複数持つので、そこを一元管理を行う事業所をもつ ・サービススタッフの働き方は出来るだけ自由に設定できる ・サービススタッフのスキル別に出来る仕事を適切に配分する ・介護会員の要望に合わせたスケジュール調整を行う ・ビジネスパラメータの組合せに柔軟に対応できる業務形態にする ## ビジネスパラメータ ・介護会員とサービススタッフの自由度を保つために介護施設を分類できる ・サービススタッフの自由度を保つために働き方を細かく分類する ・介護会員の状況を細かく分類できる ## 業務概要 ・介護会員の管理（名前、連絡先などの様々な属性を管理） ・効率的な訪問介護の計画 ・訪問介護の実施記録を管理する ・新しいサービススタッフの教育 ・介護費用の計算と請求及び回収 5
6. AIを使い段階的に要件を定義させる 6 RDRAZeroOne 【１】 プログラムでAIをコン トロールする 2024 【２】 Agentで要件を組立てる 2025
7. Demo 要件妥当性検証結果 検証概要 本検証は、訪問介護管理システムのRDRA定義について、「RDRA説明.md」に記載され たストーリーを基に、3つの視点（BUC視点、アクター/外部システム視点、情報視 点）から妥当性を評価したものです。 検証日: 2025-11-07 検証結果サマリー 本検証では、RDRA定義と説明書の整合性を確認し、定義の欠落、矛盾、制約違反に より現状では実現不能な項目（判定：不可）、および未確定要素や外部依存があり前 提が満たされれば実現可能な項目（判定：要確認）を抽出しました。 判定基準OKの項目は本結果には含まれておりません。 7
8. 段階的に生成を検証しながら進める Phase1 Phase2 Phase3 Phase4 要件（RDRA） 論理データ モデル 要件の妥当 性検証 仕様の妥当 性検証 妥当性検証環境.csv 初期要望 【１】初期の要望を入力する Agent 【２】Agentが成果物を出力 要件妥当性検証結果 検証概要 本検証は、訪問介護管理システムのRDRA定 義について、「RDRA説明.md」に記載され たストーリーを基に、3つの視点（BUC視点、 アクター/外部システム視点、情報視点）か ら妥当性を評価したものです。 検証日: 2025-11-07 検証結果サマリー 本検証では、RDRA定義と説明書の整合性を 確認し、定義の欠落、矛盾、制約違反によ り現状では実現不能な項目（判定：不可）、 および未確定要素や外部依存があり前提が 満たされれば実現可能な項目（判定：要確 認）を抽出しました。 判定基準OKの項目は本結果には含まれてお りません。 論理データモデル 【６】 論理データから要件の 確からしさを把握する 【４】 要件を検証するためにシステム の導入環境を入力 【３】 Agentの出力を次の Agentの入力にする V字モデルを左と右から同時に進める 【５】要件を検証 Agent 8 ビジネスルール
9. 論理データモデ ルの説明 @論理データモデル.md の各 Entityの役割と他のEntityとの関 係から、この論理データのでき ることと役割を一つのわかりや すい文章で説明してください AIに論理データモデルに ついて聞く 9
10. 多段に人とLLMがキャッチボール Prompt knowledge Prompt knowledge Prompt knowledge LLM 出力 出力 出力 初期要望 Prompt knowledge 出力 ４つのフェーズでコンテキストを膨らませ軌道修正する フェーズ１ フェーズ２ フェーズ３ フェーズ４ 10 RDRA 【４】LLMの出力を見直し、次のフェーズの入力とする 段階的な詳細化で要件を軌道修正しながら組み立てる 【２】 Prompt入力に 悩ませない 【１】 要件を定義す るナレッジ 【３】 要件に集中する Phase1 Phase2 Phase3 Phase4
11. 段階的なフェーズ分けとナレッジ化 11 【１】要件の組立てをフェーズに分割する 【２】フェーズ毎の組立方をナレッジ化する 【３】 フェーズ毎の組立方を ナレッジ化する
12. 要件の構造とAIのコンテキスト 12
13. RDRA構成要素 依存 システム価値 システム境界 システム 外部システム 要求 アクター システム外部環境 業務フロー アクティ ビティ ユースケース 状態 遷移 Why Why Why 条件 バリエー ション 業務 ビジネス ユースケース 情報 状態モデル 画面 イベント コンテキスト タイマー アクター群 外部システム群 画面 13 RDRAは要件として決めるべき要素とその関係を明らかにする 【１】 ４つのレイヤーで依存 関係を明らかにする 【２】 レイヤー毎に決めるべ き要素を決めている 【３】要素は全てつながり依存関係を生む
14. 要件の構造をモデル化する コンテキスト 状態モデル 条件 バリエーション 状態 外部システム群 外部システム アクター群 アクター イベント 画面 タイマー 業務 BUC アクティビティ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ UC メールなどの通知 外部システムが提供する画面 外部システム との連携 人が画面を使う ビジネス上 の区切りを 表す UCが状態を変える ある状態の時に UCが実行できる システムを使う仕 事はUCとつながる 外部システムが提供する画面を使う UCが提供する画面 UCが情報を 操作する UCが条件に従う 情報に従属する バリエーションがある 情報 【１】 概念をモデル化する 14
15. アクター 役割 外部システム 役割 業 務 BUC アクティビ ティ UC 情 報 条 件 アク ター 外部シス テム 説 明 アクター群 アクター 説明 外部システム群 外部システム 説明 情報 属性 関連情報 活用法 コンテキスト 状態モデ ル 遷移前状 態 遷移後 状態 説明 バリエーション 値 説明 条件 説明 コンテキ スト 情報 属性 関連情 報 状態モデ ル バリエー ション コンテキスト バリエーション 値 説明 コンテキスト 条件 説明 ビジネスポリシー 説明 ビジネスパラメータ 説明 情報 説明 業務 BUC 説明 状態モデル 説明 シ ス テ ム ビ ジ ネ ス 状態モデル 遷移前状態 遷移後状態 説明 ビ ジ ネ ス ル ー ル 業務 BUC アクティビティ UC 説明 コンテキ スト 条件 条件の 説明 バリエー ション 状態モデ ル コンテキスト 情報 属性 関連情報 活用法 コンテキ スト 状態モデル 状態 遷移UC 遷移元状態 説明 業 務 B U C アクティ ビティ UC 関連モ デル1 関連オブジェ クト1 関連モデ ル1 関連オブ ジェクト1 説 明 外部システム アクター 業務 BUC ＊ 状態モデル 情報 業務 BUC アクティビティ ＊ ＊ UC 条件 バリエーション 状態モデル 状態 ＊ 外部システム群 外部システム アクター群 アクター ＊ ＊ コンテキスト 状態モデル 条件 バリエーション 状態 情報 ＊ ＊ ＊ ＊ ＊ 業務 BUC アクティビティ ＊ ＊ UC 外部システム群 外部システム アクター群 アクター ＊ ＊ コンテキスト 状態モデル 条件 バリエーション 状態 情報 ＊ ＊ ＊ ＊ ＊ 業務 BUC アクティビティ ＊ ＊ UC 画面 イベント 段階的にオブジェクト組立てる フェーズ１ フェーズ２ フェーズ３ フェーズ４ 【１】 単純な表形式でフェーズ 毎の生成物を定義する 【２】モデルとして整合性を担保する 15
16. アクター別の画面に構造変換する コンテキスト 状態モデル 条件 バリエーション 状態 情報 外部システム群 外部システム アクター群 アクター イベント 画面 タイマー 業務 BUC アクティビティ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ UC 業務 BUC アクター 画面 項目 UC アクティビティ 【１】 モデルを使ってデータ構造を変換 するプログラムをAgentに作らせる 構造変換 プログラム 【２】 モデルでオブジェクトを規定する ことでプログラム化可能になる 16
17. 定義：RDRAとは # RDRA構造の説明 ・「アクター」：システムに関わる人の役割を表す ・「アクター群」：同じような役割を持つ「アクター」をまとめ、組織の役割を 示す場合もある ・「外部システム」：システムと連携する外部のシステムを表す ～ # モデル間のつながりの規則 ・「業務」は複数の「BUC」を配下にもつ ・「BUC」は複数の「アクティビティ」を配下にもつ ・「アクティビティ」(仕事)を行う「アクター」がつながる ～ # 定義内容は各モデルのオブジェクトとして定義する 以下に例を示す 「会員」：モデルがアクター、オブジェクトが「会員」になる 「受注」：モデルが情報、オブジェクトが「受注」になる 「受注を登録する」：モデルがUC、オブジェクトが「受注を登録する」になる RDRA.md 【１】モデル構造を言語化しブレを無くす 17
18. 定義：RDRA定義のフォーマット定義 # 表形式のRDRAモデリング RDRASheetは表形式で要件定義を行うための形式です 要件定義はシステムの可視化と同じです ファイル内では階層構造を表すために空白セルは上位のセ ルの値を引き継ぐことで階層構造を表現する ## 定義ファイルの特徴とメリット ### 1. 表形式のメリットと表現方法 - **表形式によるシステム可視化** 表形式では、同じ行に並ぶ項目同士が関連しているとみな すため、ダイアグラムでの配置や線による関係性の明示よ りも、要件の定義に集中できるというメリットがあります。 これにより、最初は大まかなアイディアを素早く全ファイ ルに記入し、後から関連性を洗練させていくことが容易に なります。 ～～ ## 各ファイルの構造 表形式のRDRA定義は以下の５つのファイルで定義を行う。 ・「アクター」ファイル ・「外部システム」ファイル ・「BUC」ファイル ～～ RDRASheet.md 【１】RDRA構造に基づき表形式で表現 【３】表形式はLLMの入力と出力にそのまま使える 【４】モデル上の言葉を使って表形式を言語化する 【２】表形式をタブ区切りのTSVファイルとして扱う TSVファイル 18
19. まとめ • 複雑な成果物を作るためには段階的 （フェーズ）にナレッジを用意する • フェーズ毎の成果物フォルダーを用意 • フェーズ毎にナレッジを用意 • ナレッジはモデルを使って整合させる • ------- • 要件定義や設計などの創造的な言語化の無 料相談も受け付けています • X(tweeter)：@zenzengood 生成された成果物 （テキスト）を編集 フェーズ別 生成物フォ ルダー フェーズ別 ナレッジ 19