■ 1. 発表者の背景と取り組み
- 発表者はVALUソースという会社を経営している
- 要件定義とシステムの可視化を行っている
- 最近はAIを使った要件定義に注力している
- いかにして要件定義をAIでやらせるかを毎日取り組んでいる
■ 2. AIで要件定義を行う際の前提条件と課題
- 前提条件:
- AIは個別の企業のことを何も知らない
- 3つの課題:
- LLMの出力をいかに理解するか（最も大きな問題である）
- ある程度少量のデータで大量に出てくるため、どうやって理解するかが問題である
- AIに適切なコンテキストをどうやって用意するか
- 中規模から大規模なシステムでは最初の入力だけではどうにもならないため、軌道修正しながら最終的な要件に組み立てていく必要がある
- 軌道修正をどうするかについて一つの形が見えてきている
■ 3. 課題解決のアプローチ
- 初期要望の入力:
- ビジネスの背景や概要などの初期要望を入れてAIに要件定義させる
- 要件のビジュアライズ:
- 文章だけではなかなか理解できないため、様々なものの繋がりをビジュアライズする
- 画面の確認:
- 画面を中心に話をすると要件的にも進みやすい
- LLMが出した出力から各アクター別にどんな画面になるのかをすぐに確認できるようにする
- LLMが出したものがどういうものなのかということを理解するために用意している
- 要件の妥当性検証:
- AIが出してきたものが本当に現場に適用できるのかを検証する
- 環境を入力してそれで妥当性検証を行う
- 論理データモデルの活用:
- 論理データモデルを出して、論理データモデルから要件を突き上げて正しいのか判断する
- 中心となるモデル:
- 要件定義における要件には構造があると定義している
- その定義に従ってAIを作業させる
- モデルの周りにビジュアライズ、画面出力、論理データモデル作成などが付随している
- 最終的にAIが出した要件を確認していく
■ 4. 入力サンプルの内容
- システムの概要を入力する:
- サンプルとして訪問介護のシステムを使用している
- どんな背景なのか、要求、ビジネスポリシーなどを記述する
- ビジネスパラメーター（介護会員のランク、サービススタッフの働き方の種別など）を記述する
- 業務概要を記述する
■ 5. 実装方法の変遷
- 昨年の実装:
- プログラムでAIを使って要件定義させることをトライしていた
- プログラムからAIのAPIを呼んで要件定義させて保存するという流れを何フェーズかに分けて実行していた
- 現在の実装:
- 昨年の暮れからエージェントがすごいことになり出した
- プログラム作成では全然追いつかないと判断した
- 要件を定義することに関しては全てエージェントにやらせることに方針転換した
- 動作環境:
- カーサーを使用している（クロードコードやCLIツールでも可能）
- フェーズが4つあり、フェーズごとに出力される
- 徐々に出力を厚くしていくやり方をしている
- 実際の出力には2〜3分かかる（デモは10倍速）
- 現在の能力:
- モデルがかなり賢くなっているため、ほぼほぼ全てAIで要件定義できるレベルになっている
■ 6. ビジュアライズ機能
- 全体俯瞰:
- AIで出したものをビジュアルに表現している
- 業務とコンテキストが表示される
- コンテキストを選ぶとその中にどんな情報があって、どのケースと繋がっているのかが出てくる
- 情報の表現:
- IDを中心としてある程度具体的なエンティティを出す
- 細かいものは出さず、ビジネスで認識しているIDを情報という形で出している
- この関係付けもAIが行っている
- 様々な視点からの確認:
- 訪問介護スタッフを選ぶと、その訪問介護スタッフを中心にどういう画面を使っていて、その画面はどのケースに繋がっていて、そのユースケースはどの業務でどのアクティビティなのかが全部俯瞰して見える
- 1つのアクターに多数の画面がついている場合、ロールが足りていないことが分かる
- 1つのロールでそんなに多くの画面を扱うことは普通ないため、ロール見直しの必要性が判断できる
- 画面が多すぎる場合、システム化する必要がないのではないかという議論もできる
- 状態遷移の確認:
- 状態遷移があり、この状態遷移に関わるユースケースは何があるのかが見える
- この状態は本当に役に立っているのか、この状態を実現するための情報は何なのかという話もできる
- 活用方法:
- 1回AIでガーっと出すとこのビューを使って様々に分析しながら本当にこの要件でいいのかを考えていく
- AIに引きずられているような感じになるが、AI要件定義そのものはもうAIでできることが分かったため、いかに理解するかが重要になっている
■ 7. 画面イメージの生成
- アクター別の画面を作成する:
- 具体的にその画面でどういうことが行われているのかが分かるように、AIにアクター別の画面を作らせる
- 介護スタッフを選ぶと介護スタッフの使う画面が見える
- イメージではあるが、この介護スタッフはどういう業務でどういうビジネスケースでこの画面を使うのかをイメージしながら要件定義をしていく
- アクターごとに確認しながら使っていく
■ 8. VGモデルによる妥当性検証
- 左側（要件生成）:
- フェーズ1234の4つのフェーズでAIが出力したものを作成する
- 右側（妥当性検証）:
- 本当にその要件が妥当なのか、このままシステムとして導入して役に立つのかを検証する
- 検証方法:
- 対象システムの拠点やアクターにどういう制約があるのかを入力する
- この制約と組み立てた要件をぶつけて妥当性を検証する
- ある程度その環境を入力することによってAIが生成した要件が妥当なのかどうなのかを判断する
- 検証結果:
- 色々と出てくるが、感覚的には60点ぐらいである
- 重要度や改善提案がやたらに出てくるが本当かなというものもある
- ただし出力された要件を見直すという意味においては、VGモデルの右側からどういう環境にシステムを入れるのかを入力するのは結構有効である
- そもそもこの入力を作るという行為そのものがかなり重要であり、これで現場というものを強く意識できる
■ 9. 論理データモデルとビジネスルールの生成
- ビジネスルールの叩き台:
- 要件として出されたビジネスルールの叩き台を作る（正式なものではない）
- ラドラという手法では条件という名前のものがビジネスルールを表す
- スキルマッチング条件があった場合、それはどのケースから呼ばれていて、その条件はどういうサービス種別やスキルレベルなどのバリエーションに繋がっているかが書かれている
- この条件からビジネスルールを作ってくれとAIに言うと叩き台が出てくる
- 実際の仕様においては、仕様化の時にこの形式で本当にいいのか、もうちょっと違った形でビジネスルールをきちっと書いていく
- 叩き台があるだけでかなり見通しは良くなる
- 論理データモデル:
- 要件から論理データモデルを作ってというとそこそこの論理データモデルが出てくる
- データモデルの得意な人はデータモデルを見るとかなり業務が分かる
- こちら側から今回の要件が妥当なのか、ピントがボケているなどが判断できる
- 論理データモデルが読めない・苦手という方は、エンティティの役割と他のエンティティとの関係からこの論理データモデルのできることや役割を分かりやすく説明してとAIに訊ねると、それなりに説明してくれる
- 分かりにくい場合はさらに質問すれば分かってくる
■ 10. 適切なコンテキストの提供
- 重要性:
- コンテキストとして生成したものを積み上げていくことが大事である
- 4つのフェーズの構成:
- AIが要件をどう組み立てていけばいいのかというナレッジをあらかじめ入れている
- IDEではラドラナレッジというところに各々フォルダーを切ってその中に様々なプロンプトなどが入っている
- 人が行うこと:
- 基本的に人が行うことは初期の要望を書くことである
- それでフェーズごとに実行して出力された内容を見直して、また次のフェーズに行くことを繰り返していって洗練化する
- 軌道修正:
- AIが出した出力を人間が見直して軌道修正する
- 細かく見て直すというのは人間にとってかなり負荷が高いため、明らかに違うということだけ直す
- いらないものを基本削除するという方向で修正していく
- 実際の運用:
- 最初に初期要望を入れて1回動かすと解像度が悪い感じになるため、この初期要望を見直す
- ある程度こんな感じかなと思ったら次からどんどん次に行く
- 当初はフェーズ1見直したらフェーズ2、フェーズ3と思ったが、人間の負荷から言うとフェーズごとに見直すのはかなり耐えられない
- 今は初期要望と最初のフェーズを繰り返したらあとは一気に最後まで行くという感じである
- 一気に最後まで行って要件として組み立てたら、その後でビジュアライズしたもので色々な角度で見直して再度生成し直す
- その方が楽である
- 最終確定:
- AIで出されたものはどこまでも叩き台である
- 最終的にはラドラという手法の形式で出して人間が最終的に要件を確定するというやり方をしている
■ 11. モデルベースのアプローチ
- ラドラという手法の構造:
- 要件には形がある、構造があると規定している
- 4つのレイヤーがあり、各々要素があって、その要素が全部繋がっている
- 右から左に依存するという構造を持っている
- 右の要素は左の要素がホワイトになっている
- 左の要素がこうだから右の要素はこうだという考え方である
- クラス図による表現:
- この構造をクラスで表すことができる
- この構造に従って要件を定義させるので連続的に要件が定義できる
- 段階的なモデル構築:
- 最終形に持っていくために段階的にモデルを組み立てる
- 徐々にオブジェクトを増やして関係付けすることを内部で行っている
- AIで出力されるのは表形式だが、内部ではこれらが全部完全に繋がり合っていてオブジェクト構造として持たれている
- 詳細なレベルから俯瞰したレベルまで見ることができる
- 画面生成の仕組み:
- このオブジェクト構造があるため、定義されたオブジェクト構造から画面用のアクター、画面、項目という構造に変換する
- 当初これをエージェントで変換していたが、こんな決まりきったことをエージェントでやるのはトークンが無駄だと判断した
- エージェントにプログラムを作らせるようにしている
- この構造のものをこっちの構造にしてくれという構造変換のプログラムを作らせる
- プログラム変換させたものをJSONとして出してこのJSONを画面が読んで生成されたものの画面をアクター別に出す
- モデルの言語化:
- クラス図の1個1個のクラスと関係を言葉で定義している
- アクターとはこうだ、業務とはこうだということを書いて言語化している
- これを食わせている
- 実際には表形式で出ているため、表形式はダイアグラムの関係性を表として再現できるようにしている
- この表の構造も全部言語化して、こういう繋がりはこういう表で出力してくれということを全部書くことによって出力される
■ 12. まとめと提供サービス
- IDEの活用:
- IDEの中であらかじめナレッジをモデルベースで入れておく
- 初期の要望をファイルに入れて実行すると要件定義が生成される
- 複雑なタスクへの対応:
- 要件定義みたいな複雑なものはまずフェーズに分ける
- フェーズごとのナレッジを作る
- フェーズごとの成果物のフォルダーを用意する
- 成果物のフォルダーがAIに渡すコンテキスト情報になるため、それを見直すことによって軌道修正してちゃんと辻褄の合った要件定義に持っていく
- 無料相談の提供:
- 要件定義や家の設計など創造的で難しいところをどうやったらAIでやれるのかを悩んでいる方向けに無料相談を提供している
- XのアカウントにてDMで相談を受け付けている