/note/tech

要件定義の精度を高めるための型と生成AIの活用

要約:

■ 1. 概要

  • 発表: BPStudy #224(2026年4月30日)
  • 発表者: 佐藤治夫(株式会社ビープラウド 代表取締役社長)
  • テーマ: 要件定義の精度を高めるための「型」と生成AIの活用
  • アジェンダ構成:
    • 01 再浮上する要件定義不要論
    • 02 エージェントによる開発と要件定義
    • 03 コンテキストエンジニアリングとRDRAの親和性
    • 04 モデルベース要件定義手法 RDRA とは
    • 05 RDRA Agent の価値
    • 06 エンジニアリングの重要性の高まり

■ 2. 再浮上する要件定義不要論

  • 時代背景:
    • 2025〜2026年にAI Agent時代が到来しつつある
    • コードを書く主体が「人間」から「エージェント」へ移行しつつある
    • 従来のSDLC(要件→設計→実装→テスト→レビュー→デプロイ→監視)が「意図→エージェント→コード+テスト+デプロイ→動作確認→出荷」へ変化しつつある
  • 要件定義不要論の背景にある思惑:
    • 作ってから直せばよい(フィードバックを元に直せるという前提)
    • 作ったものを見ないと要件はわからない(動く実物が要件を引き出すという考え方)
    • 動くものがあると進んでいるようで安心する(進捗報告がしやすい)
    • 早く開発したい(設計以降の作業の方が得意・楽しい)
    • 要件定義は不要だとイーロン・マスクも言っている
  • 要件定義を省略すると起こること:
    • 不要なものを必要以上に作ってしまう(本来不要な機能や仕様まで実装)
    • 要求の爆発(整理されないまま要求が雪だるま式に膨らむ)
    • 手戻り工数の増大(後工程ほど修正コストが指数的に上昇)
  • 後になるほど大変になるため「急がば回れ」の心構えが必要
  • アジャイル開発においても各スプリントが「開発対象スコープの要件定義」を内包する

■ 3. エージェントによる開発と要件定義

  • エージェント開発での問題の顕在化:
    • 不要なものを必要以上に作る → 工数を吟味せず開発してしまう
    • 要求の爆発 → Why/Whatが無いため優先順位付けが難しい
    • 手戻り工数の増大 → トークンのムダな消費
  • 大規模システムをエージェントだけで作るのは手戻りが大きくほぼ不可能
  • 「XXXシステムをつくりたい」だけをエージェントに渡しても意図と実装の差分が大きく失敗する
  • 対策: システムをユースケース・ストーリー単位に適切に分割する
  • ユースケース(ストーリー)がコンテキストとなるコンテキスト設計が有効
  • 要件定義の成果物がそのままコンテキストエンジニアリングの入力になる

■ 4. コンテキストエンジニアリングとRDRAの親和性

  • コンテキストの腐敗:
    • 入力コンテキストが増えるほど回答精度が低下する現象が存在する
    • 理想的な回答精度に対して実際の回答精度は入力量が増えるほど低下する
  • 自然言語ベースのユースケース記述やストーリーはコンテキストとして悪くはないが解像度が粗い:
    • 曖昧さが残りAIへの問い直しが多発する
    • AIとの往復が繰り返し発生しトークン消費・時間コストが嵩む
  • RDRAのユースケースは「画面・イベント・タイマー・情報・条件・バリエーション・状態(遷移)」と関係づけて記述する
  • RDRAの要素のつながりがコンテキストとして有効である(仮説)

■ 5. モデルベース要件定義手法 RDRA とは

  • RDRAの定義(Relationship Driven Requirement Analysis):
    • システム開発のための要件定義手法(現場で適用できる実装可能な方法論)
    • 要素同士の「関係(Relationship)」を定義する
    • モデルとして可視化する(俯瞰できるモデルを作る)
  • システムの定義:
    • 極めて多数の構成要素から成る集合体で各部分が有機的に連携して全体として一つの目的を持った仕事をするもの(新明解国語辞典 第7版)
  • 従来の要件定義手法の問題点:
    • 自然言語と断片的な図で記述することが多い
    • システムにとって重要な「要件(構成要素)間のつながり」を読み手が推測して理解する必要がある
    • 抜け漏れ・不整合が発生しやすく要件定義の精度が低下する
  • RDRAによる要件定義の優位性:
    • 要素のつながりを明示的に定義する
    • 推測不要(関係性が定義として書かれている)
    • 抜け漏れ・不整合を自動的に検出できる
    • 要件定義の精度・品質が上がる
  • RDRAの全体像(4層構造):
    • システム価値: 要求確認(システム・外部システム・要求)
    • システム外部環境: 業務要件定義(業務・BUC=Business Use Case)
    • システム境界: システム要件定義(UC=Use Case・画面・イベント・情報・条件・タイマー)
    • システム: コンテキスト・情報モデル・状態モデル・条件・バリエーション
  • RDRAの進め方:
    • RDRA定義・分析Sheet(Google Sheetsで要件を定義・分析・検証する)
    • RDRA Graph(ブラウザでモデルをビジュアルに確認する)
    • 「関連データ」シートからRDRA Graphを開く
  • 要素の定義と関連付けをシートで実施する構成要素:
    • アクター・外部システム(システム価値・外部環境)
    • BUC(システム外部環境・システム境界)
    • 情報・状態・条件・バリエーション(システム内部)
  • RDRAによる要件定義の3フェーズ:
    • Phase 1(枠組みを作る): 議論の土台作り(全体の構成要素を洗い出す)
    • Phase 2(要件を組み立てる): 要素を関連づけて骨格を組む(トップダウン+ボトムアップ)
    • Phase 3(整合性・網羅性を高める): 要件定義の仕上げと仕様化の準備(矛盾を解消し整合性を高める)

■ 6. RDRA Agent の価値

  • 従来の悩みどころ:
    • 土台を1から作るのが重い(0から構造を組み立てる工数が大きい)
    • 抜け漏れが出やすい(初期に観点を網羅しきれない)
  • RDRA ZeroOne / RDRA Agentの価値:
    • LLMを活用してモデルの叩きを0→1で自動生成する
    • テキストデータをクリップボードから読み込みRDRA Graphを開く
    • 「ZeroOne」シートにテキストを貼り付けRDRA定義・分析Sheetを生成する
    • 土台を自動生成することで議論から開始できる
  • 制約事項:
    • 整合性・精度向上フェーズ(Phase 2・Phase 3)は人による議論と合意が必須

■ 7. エンジニアリングの重要性の高まり

  • AIエージェントの二面性:
    • 業務の生産性や成果を劇的に高める「能力増幅装置」として機能する
    • 適切に管理されない場合はリスクを拡大させる装置にもなり得る
  • エンジニアリング原則(手戻りコストの影響を常に意識する):
    • ソフトウェア開発201の鉄則「鉄則41: 今すぐ要求仕様書の誤りを直せ」
    • 要求仕様書の誤りは発見が後になるほどコストが増大する
    • 設計まで残ったら修正に5倍のコスト
    • コーディングまで残ったら10倍のコスト
    • テスティングまで残ったら20倍のコスト
    • 納入時点まで残ったら200倍のコスト
    • 「後で修正すればいい」という考え方が最終的な納期とコストを破壊する
  • エンジニアリング原則(インサイドアウトで品質を高める):
    • プロセス品質(要件管理・設計基準・レビュー・早期テスト)
    • 内部品質(保守性・再利用性・テスト容易性)
    • 外部品質(機能・性能・セキュリティ)
    • 利用時の品質(目的の達成・価値の創出)
    • これらが連鎖することで品質+開発生産性の向上につながる
  • エンジニアリング原則(V字モデルを開発の地図として持つ):
    • 企画→業務要件定義→システム要件定義→基本設計→詳細設計→プログラミング(左下降)
    • コードレビュー→単体テスト→結合テスト→システムテスト→運用テスト→運用・評価(右上昇)
    • 効果的なエンジニアリングがAIの使用効率も高める
  • 弁証法的考察(螺旋階段モデル):
    • 世の中全ての物事の進歩や発展は右肩上がりに一直線に進歩・発展するのではない
    • あたかも「螺旋階段」を登るようにして進歩・発展していく(田坂広志『使える弁証法』より)
    • 正(テーゼ)→反(アンチテーゼ)→合(ジンテーゼ・アウフヘーベン=否定の否定)のサイクルで発展する
  • エンジニアリングの変遷(弁証法的な螺旋発展):
    • 2000年代: エンジニアリング重視(プロセス・モデリング・設計、オブジェクト指向設計、RUP・UML・PoEAA・アナリシスパターン)
    • 2010年代: アジャイル開発が台頭(プロセスを重視した開発へのアンチテーゼとして技術・実装重視へ)
    • 2025年以降: 新しいエンジニアリングの在り方(エンジニアリングと技術・実装が融合されたものへ)

■ 8. まとめ

  • 再浮上する要件定義不要論: 手を抜くと後ほど大変になる(不要なものを開発・要求の爆発・手戻り工数の増大)
  • エージェントによる開発と要件定義: 企画・要件定義の内容がコンテキストエンジニアリングにそのままつながる
  • コンテキストエンジニアリングとRDRAの親和性: RDRAの要素のつながりがコンテキストになる
  • モデルベース要件定義手法RDRA: システムを構成する要素同士の関係(Relationship)を定義することでモデルとして可視化する
  • RDRA Agentの価値: 叩きが生成されることでゼロからのスタートを回避できる
  • エンジニアリングの重要性の高まり: AIエージェントは「能力増幅装置」だからこそエンジニアリングが効く