要件定義を３つのフェーズで進める

• フェーズ１：空中戦を避けるために議論のベースを作る

  • トップダウンでLLMの出力の理解を助ける

  • LLMの出力をLLMの入力につなぐ

  • LLMの出力を見直し方向づける

  • 段階的に要求を追記し構造的に細かい指示につなげる

• フェーズ２：RDRAモデルの構造を使って要件を組立てる

• フェーズ３：整合性を合わせ、精度を向上させる

フェーズ１にRDRAZeroOneを活用し素早く議論のベースを作り、要件の組立はフェーズ２で従来通りのRDRAモデルで組立てる

LLMを使って素早くをRDRAを組立てるRDRAZeroOneツールを使い、議論のベースとなるたたき台を作成し、RDRASheetで直接要件を組立てる

フェーズ１

1. RDRAZeroOneでLLMを使ってRDRA定義のたたき台を作成

フェーズ２，３

2. RDRA定義（GoogleSheet）で要件を組立てる

要件として整合性、網羅性をRDRAのルールで組立てる

1. システム化対象の背景と業務の概要を入力

2. ３段階でLLMを実行し要件の方向性を持たせる

• システム化対象のビジネス全体像を明らかにする

• 業務を仕事に分解し、管理する情報と状態を洗い出す

• RDRA要素（UC、情報、状態～）を明らかにする

3. LLMで作成した要件をRDRAGraphで確認

4. RDRA（Spreadsheet）で要件を定義

5. RDRA分析で不整合を検査

6. RDRA分析からRDRAGraphで確認

文脈情報を与えて要件定義を開始し、LLMを活用し３ステップで詳細化する。各ステップでLLMの出力を手直しすることで、要件定義に方向性を持たせ、企業ごとの仕組みや独自性を与える。

1. ビジネスの外枠を固める

   • 議論に方向性を持たせるために、システム化の外枠を決める

   • 外枠となるアクター、外部システム、業務を見直し一旦決める

2. ビジネスの組立

   • 業務の詳細化に向けて仕事を洗い出し、仕事で必要な情報と状態を洗い出す

   • 仕事と情報と状態を見直し一旦決める

3. RDRA要素の抽出

   • 仕事からユースケースを導出する

   • 仕事にユースケースをアサインし、情報やアクターなどを出力し、ユースケースにつなぐ

LLMを使うためにOpenAIかGeminiのAPIキーを登録する

※現状はOpenAIとGeminiに対応している

• 　OpenAIのModel：”gpt-4o-mini”

• 　Gemini：”gemini-1.5-flash-latest”

要件を定義する対象の背景や業務の概要を記入する。

• ①システム名：「対象システムの名前」を入力。

  • ⇒　データを保存するときの識別して利用する

• ②最重要要求：「結局何が実現できればいいのか」を入力

  • 要件の方向性を与えるために利用する

• ③　A:ビジネスの背景

  • 背景やアクター、外部システム、要求、制約、ビジネスポリシーなどを入力

  • 上記項目は必須ではなく、わかっていることを入力し、徐々に精度を上げる

• ④　B：概要

  • システム化対象が行っていることを箇条書きで記述

  • 分類と業務の２階層で記述する

文脈理解を入力とし以下の要素をLLMが出力する

• アクター：システムに関係するアクターを出力する

• 外部システム：システムに関係する外部システムを出力する

• ビジネスポリシー：ビジネス全体を通した決まり事を明確にする

• ビジネスパラメータ：ビジネス上活用している区分や種別を洗い出す

• 業務：入力された業務概要から分類された説明付きの業務を出力する

  • 「概要」を２階層で整理して出力するとLLMもその階層を利用する

  • １階層目の先頭に「・」　２階層目の先頭に「- 」を付ける

⇒入力を使ってLLMの出力を限定する

※「ビジネスの背景」でアクターや外部システムなどを記述すると、LLMに出力が限定される

⇒LLMの反応をよくする

※LLMの反応をよくするためにRDRAの用語とは違う用語を使っている

　　業務はRDRAのBUCに対応　　　分類はRDRAの業務に対応

• 明らかに意図した内容でない場合、または欠けているものがあれば「文脈理解」の入力を見直し再実行する。

• 想定範囲の出力の場合は、不要な行を削除し、名称、説明を見直し再実行する

• 見直しポイント

  • アクター：ビジネスの背景にアクターを追加する

  • 外部システム：ビジネスの背景に外部システムを追加する

  • ビジネスポリシー：明らかに違うものを削除する

  • ビジネスパラメータ：明らかに違うものを削除する

  • 業務：不要な業務を削除し分類と業務名（BUCレベル）を見直す

※時間をかけて見直すのではなく、直感的におかしなところだけ見直す。文脈理解の入力を見直すために、LLMの出力を見直す

分類、業務、説明を見直し、さらに要求を追加し方向性を持たせる

• 要求：業務に対する要求も出力される。

  • 業務を仕事に分解するための方向性を要求として記述。

  • この段階では要求が思いつかない場合は、出力された要求をそのままにしておいてもよい

• 分類：概要で入力した分類が反映される

  • 「業務」を分類することで出力を理解する

• 業務：業務の名前（BUC）として適切か否かを確認する

  • 不要な業務を削除し、業務の名前を見直す

• 説明：業務の説明として妥当か否かを確認する

  • 以後のLLMの方向性を決めるために説明を見直す

ビジネスアイディアの出力がある程度妥当なものであれば、ビジネスデザインのLLMを実行する

• 業務で扱う情報、状態を洗い出す

• 業務を仕事に分割する

• アクターと外部システムを仕事に関連付ける

• 情報・状態モデルの見直しポイント

  • 情報：

    • 明らかに不要なものを削除し、欠けているものは追加する。また名前や説明の内容を見直す

    • 分類名を適切な名前に直す（RDRA上でコンテキストになる）

  • 状態モデル：

    • 明らかに不要（管理しない）な状態を削除し、欠けているものは追加する。また名前や説明の内容を見直す

ここで情報（分類）・状態モデルを一旦確定する

※ここで扱う業務と仕事はRDRAのBUCとアクティビティに対応する

• ビジネスの基本的な骨格を組立てる

• 仕事と関連の見直しポイント

  • 要求：業務を仕事に分解するための方向性を要求として記述。

  • 仕事：業務内の不要な仕事を削除し、欠けているものは追加する。

  • 操作情報：仕事に関わる情報を見直す

  • 関連アクター：仕事に関わるアクターを見直す

  • 関連外部システム：仕事に関わる外部システムを見直す

ここで業務と仕事を一旦確定する

この段階では要求が思いつかないことも多いので、出力された要求をそのままにしておいてもよい

※この段階ではまだ確かなことは決められないので、明らかに違うものを削除、欠けていると思われるものを追加し、内容の変更を行う。迷っているものは基本的に残していくようにする。

ビジネスデザインの出力がある程度妥当なものであればシステム化検討のLLMを実行し、RDRAに必要な要素を出力する

システム化検討では、情報、状態モデルを構造化し、条件、バリエーションを洗い出す。そして、仕事にユースケースを結びつけることで、システム化範囲を明らかにする。さらにユースケースに情報、アクター、外部システム、条件を結びつけてシステムが行うことを明らかにする

状態、条件、バリエーションは情報の分類（コンテキスト）に基づいて分類される

※意図したものが出力されない場合は出力結果を修正せずにLLMの再実行を行う

※この段階ではまだ確かなことは決められないので、明らかに違うものを削除、内容の変更を行い、迷っているものは基本的に残していくようにする

• 条件：コンテキストを見直し、不要なものを削除する

• バリエーション：分類を見直し、個々の項目はRDRA定義の参考にする

• 情報：分類の見直し、属性、関連（情報、状態モデル）を見直す

• 状態：分類の見直し、遷移させるユースケースを見直す

• ユースケース：不要な業務を削除し分類と業務名（BUCレベル）を見直す

※条件、バリエーションはRDRA上で定義する場合の参考にするために

※この段階の修正はRDRASheet上でも行えるので、グラフィカルに精度を確認するために分類と関連を中心に見直す（グラフィカルに確認するためにはコンテキスト、分類、業務などのグルーピング、ユースケースとの関係が重要になる）

※明らかにLLMの出力が妥当（想定しているものが出力されない）ではない場合は再度LLMを実行する。数回実行して出力されない場合は、後でRDRA定義（Google Sheet）を使って手直しする

• ↓文脈理解 ↓ビジネスアイディア ↓ビジネスデザイン ↓システム化検討

  • ナビゲーションとしてスクロールする

• LOAD：保存した定義を呼出す（保存データを全て削除する）

• SAVE：入力した定義を保存する

• CLEAR：表示内容をクリアする

• TO RDRA：Google Spreadsheetの「RDRA定義」を表示する

• TO GRAPH：定義内容を反映した「RDRAGraph」を表示する

• SAMPLE：文脈理解のサンプルを表示する

• REGISTER API：API Keyを登録する

ZeroOneではたたき台となるものを素早く作成することが重要

システム検討まで進めるとRDRAGraphやRDRASheetに出力できるようになる

• ToRDRA：RDRASheetに移行できるように定義内容をクリップボードにコピー

• ToGraph：RDRAGraphを表示

RDRAGraphで内容を確認し、必要なところに戻って再度LLM実行を行う

ある程度の精度になったところでToRDRAでRDRA定義のSpreadSheetで編集を始める

※ZeroOneだけで精度を上げようとしない、ある程度システムスコープの合意ができればRDRASheetを使って要件を組立てる

表形式だけでは出力の精度を理解するのは難しいので、RDRAGraphを使って定義内容をオブジェクトから逆引きして内容の精度を確認する

精度を確認するポイント

• アクター：任意のアクターの役割からつながる画面やユースケースの妥当性や偏りを見る

• 外部システム：任意の外部システムの役割からつながるイベントやユースケースの妥当性や偏りを見る

• 情報：情報につながるユースケースの妥当性を確認する

※妥当性はつながりの偏りから判断する。全くつながっていないもの、つながりの多いものなどから妥当性を確認する

ChatBotを使ってLLMに内容を確認する

• メニューChatBotを実行

• 表示されたBotに問合せを行う

• 「ダイアグラムの説明」表示されている内容を説明する

※RDRAGraphを参照

構造から要件の精度をチェックすることができる

• Ⓐ　コンテキストは業務によってつながるはず

  • コンテキストには情報、状態、条件が含まれ、業務にはBUC、UCが含まれる

  • UCと情報のつながりが俯瞰すると業務とコンテキストのつながりに反映する

  • 業務が複数のコンテキストをまたがることでシステムとしての整合性や一貫性を保持する

• Ⓑ　状態を変えるUCが情報につながっていない

  • 状態は情報に保持される

  • UCは情報を操作することで状態を遷移させる

各アイコンの意味のつながりから要件の精度をチェックする

• Ⓐ　ユースケースの名前と関わる情報、状態の関係性がおかしい

  • 「顧客ニーズを把握する」というUCが「販売代理店情報」を使い「販売管理」の状態を変えているが、UCの名前からすると違和感がある

• Ⓑ　サービス販売で受注に結び付いていないので、「販売完了」状態にするのはおかしい

  • 「サービスを提案する」というUCが「販売完了」状態にするのは違和感がある

• Ⓒ　状態モデルと情報が合っていない

  • 「販売代理店情報」と状態モデル「販売管理」につながるのは違和感がある