見出し画像

「BPStudy#207〜LLMと要件定義」に参加してきました

Jimmy

2024/11/27（水）に開催された「【BPStudy#207〜LLMと要件定義」に参加してきたので、その内容と学んだことを共有したいと思います。


おことわり

  • この内容は非公式なものであり、自分なりに整理したものです。

  • 本記事には誤りが含まれる可能性があります。

    • 間違っている部分などがあれば、コメントいただけると助かります。<(_ _)>

本イベントについて

LLMを使ったRDRAモデル作成支援を紹介する会でした。

AIの進化がビジネスの現場に大きな変革をもたらす中、LLM（Large Language Models：大規模言語モデル）の技術は、今やシステム開発においても新たな可能性を切り開いています。特に、GitHub Copilotをはじめとするプログラミング支援にとどまらず、要件定義といったプロジェクトの初期フェーズでも、LLMが高い効率化効果を発揮し始めています。

従来、手作業で行われていた要件定義の作業が、LLMの活用によって大幅に工数を削減できると期待されています。プロジェクトの初期段階で潜在リスクや要件漏れの洗い出しが可能となり、プロジェクトの質と精度が飛躍的に向上するメリットが見込まれます。

今回のBPStudyでは、モデルベースの要件定義手法であるRDRA（Relationship Driven Requirement Analysis：ラドラ）とLLMを融合し、要件定義プロセスを再構築することに挑む神崎善司氏をお招きし、具体的な手法とその成果について共有していただきます。神崎氏はRDRAの提唱者であり、長年にわたるシステム開発と要件定義の専門家です。LLMを実際に活用した事例に基づき、具体的な効果とノウハウをご説明いただきます。

このセッションは、システム開発における要件定義の効率化やAI活用の最新アプローチに関心のある方にとって、実務に直結する貴重な機会です。神崎氏の豊富な知見と経験を通じ、LLMの実践的な活用方法とその効果を学び、システム開発の未来を垣間見る場となるでしょう。ぜひご参加ください。

BPStudy#207〜LLMと要件定義のイベントの説明

講演メモ

RDRA概要とRDRAモデルについて

RDRAはシステムの全体像をすばやくかつ整合性を保ちながら明確にするモデルベース要件定義手法です。
システム価値（システムを作る目的）～ システム（システムが持つべき情報、状態やビジネスルール）をつなげて表現（RDRAモデル）します。

RDRAモデルは各RDRAレイヤーで表現される要素を組み合わせて、ソフトウェア要件の全体像を表現したものです。
RDRAレイヤーはシステム価値、システム外部環境、システム境界、システムの4つで構成しています。
システムからシステム価値にかけて、whyの依存関係があります。

RDRAレイヤーとRDRA要素
RDRA要素一覧

LLMの活用場所

RDRA公式ページでは、要件定義の進め方として以下の3フェーズを定義しています。

＜要件定義の3フェーズ＞
【フェーズ1】議論のベースを作る
精度は無視して、RDRAモデルの大枠を作る

【フェーズ2】要件を組み立てる
フェーズ1をベースにRDRAの要素のつながりを利用して、論理的に要件を組み立てる

【フェーズ3】ビジネスルールで仕様化可能にする
条件やバリエーションなどの仕様に直結するビジネスルールで、ユースケースを補完し精度を上げ、仕様化につなげる

その中で【フェーズ1】をLLM（RDRAZeroOne（※1））を使って支援します。

（※1）2025年1月ごろに公開予定

LLMでRDRAモデルを作成する

以下のステップでRDRAモデルを作成します。

【ステップ1】ビジネスアイデアを組み立てる
LLMはプロジェクトの課題も状況も何も知らないため、背景情報を入力し、ビジネスの大枠を出力します。

＜入力情報＞

  • システム名

  • ビジネス背景（かかわっている人、システムや業務全体のルール）

  • 最重要要求（システムで一番実現したいこと）

  • 概要（システムで行うこと）

＜出力情報＞

  • アクター

  • 外部システム

  • ビジネスポリシー

    • ビジネス全体を通した決まり事

  • ビジネスパラメータ

    • 多様な状況に対応するための可変性

  • 業務

【ステップ2】ビジネスデザインを組み立てる
ステップ1で出力した情報を確認し、必要に応じて修正します。
ステップ1の入力情報を修正した情報を基に以下を出力します。

＜出力情報＞

  • 仕事（≒RDRAモデルで言うと、アクティビティ部分）

  • 情報

  • 状態

【ステップ3】システムデザインを組み立てる
ステップ2の出力情報を確認し、再度修正を行います。
そしてステップ1およびステップ2の入力情報と修正した情報を基に以下を出力します。

＜出力情報＞

  • 条件・バリエーション

  • 情報の分類と関連性

  • 状態の分類と状態遷移

  • UCと仕事の関連

【ステップ1】~【ステップ3】で出力した情報をRDRAGraphで表現することで、RDRAモデルを確認できます。
このRDRAZeroOneはRDRAモデル作成以外にも要件定義のヒアリング項目としても活用できます。

質疑応答

Q1：LLMが出力された内容から変更すべき点に気づくためのコツはありますか？

  • RDRAGraphで逆引きする（※2）と気づきやすくなる

    • 単独て浮いているものがあったり、紐付きが明らかに少ないものなど

    • アクター、外部システム、情報から調べる野も1つ

（※2）RDRA要素から紐づいている要素を確認すること

Q2：RDRAのアンチテーゼは文章のみ？

  • 構造化されてない表形式も含まれる

Q3：資料P.20で、「文脈理解」「ビジネスアイデア」「ビジネスデザイン」「システムデザイン」と4つの階層がありますが、一度「システムデザイン」までLLMで出力した後、「文脈理解」を修正することになった場合は、LLMを全部やりなおして、微修正する、ということを繰り返すのでしょうか。

  • その通り、前提が変わると、後ろも変わるため、やり直す

  • そのため、いったん最後までやってみて、何度も洗練していくことをおすすめする

Q4：仕事≒アクティビティのこと？

  • 上記の通り

    • LLMではアクティビティよりも仕事の方が読み取りがいいので、そっちを使っている

Q5：資料P.32のイテレーションは何回繰り返す？

  • お客様と1,2回打ち合わせしたら、あとはRDRAシートでやることが多い

Q6：RDRAスプレッドシートにある機能要求や非機能要求はどのタイミングで出てくる？

  • RDRAZeroOneでは出力されない

    • メモとして、RDRAスプレッドシートに記録するだけ

  • 先に業務の全体像が固めてから要求を扱った方が効率が良い

Q7：RDRAZeroOneの活用シーンでASISの洗い出しにも活用できると記載してあったが、その部分ももう少し詳細に説明してほしいです。

  • 現存の資料は中途半端なものが多い（とても細かい or とても粗い）

  • 実際に入力する際は推測しながら入力し、残りはLLMとヒアリングで埋めていく

所感

RDRAZeroOneでは出力内容を変更して、その内容を基に段階的に出力することで精度があがる点とツールによって初期情報収集により注力できる（工数を注ぎ込める）点はとても魅力的だなと感じました。
ツールの公開が楽しみです。

いいなと思ったら応援しよう！

この記事が参加している募集

#イベントレポ

29,168件