■ 1. SDDにおける「仕様」の定義と限界
- SDDツールの定義:
- Martin Fowlerの定義: ソフトウェア機能を表現し、AIコーディングエージェントへのガイダンスとなる構造化・振る舞い指向の成果物
- Kiro: requirements.md（EARS記法によるユーザーストーリーと要件）→ design.md（アーキテクチャと技術判断）→ tasks.md（実装タスク）の順に記述
- OpenSpec: 変更ごとにproposal.md（変更理由）、specs/（要件とシナリオ）、design.md、tasks.md を生成
- SDDのカバー範囲と限界:
- SDDが主に扱うのは「要件→仕様→設計」のレイヤー
- Kiroのrequirements.mdに書くべき内容の導出方法はKiroのスコープ外
- OpenSpecのproposal.mdが扱う「Why」は機能変更レベルに留まり、事業・業務レベルのWhyを構造的に分析するフレームワークではない
- プラットフォーム領域では、チームリーダーですら要求を言語化できていないケースが多く、requirements.mdを書き始められないギャップが存在する
- ソフトウェア開発の階層と要求分析の位置づけ:
- 「要望→要求→要件→仕様→設計」という階層が存在
- 要望: ステークホルダーの「あったらいいな」という希望（表層化されたもの）
- 要求: Who/Why/Whatを明確化したもの（「顧客は、○○を解決するため、△△したい」）
- 要件: 主語をシステムに置き換えたもの（「システムは、○○しなければならない」）
- 要求分析（「要望→要求→要件」を落とし込む作業）はSDDと補完関係にあり、要件レイヤーで接続する
■ 2. 要求分析が抜けた場合の問題
- 具体例として契約管理システムとID基盤の同期システム開発を挙げる:
- 誰のためにシステムを同期するのかが不明確
- どのタイミングで誰が利用するかが不明
- 書き込み失敗時の通知先・通知方式が不明
- 一括処理か個別処理かの判断基準が不明
- 同期システムとコンフリクトする業務の有無が不明
- 業務理解なき開発の結果:
- いびつな業務フローが生まれ、顧客や関係チームの運用コストが増大
- 多くの場合そのまま運用が開始され、高コストシステムを使い続けることになる
- チームが本来向き合いたかった目標達成の時間が奪われる
- いびつな運用プロセスが固着する
- SDDへの示唆:
- 業務理解が誤っていれば、丁寧に書いた仕様でも意味がない
- 仕様の前に要求があり、各要求が満たされることで誰にどんな価値が届くかを考える必要がある
■ 3. なぜRDRAを選ぶのか
- RDRAの特徴:
- 要求を4つのレイヤー（システム価値/外部環境/システム境界/システム）で構造化
- 各要素を表形式（Markdownのテーブル）で表現
- アクター・ゴール・要求・ユースケースにIDを付与し、参照関係を明示
- ゴール→要求→業務→ユースケースというWhyの依存チェーンを形成
- コーディングエージェントとの相性:
- Markdownの表形式はそのまま構造化データとして扱える
- イベントストーミング（FigJam/Miroで付箋を空間的に配置する手法）との比較:
- イベントストーミング: 付箋の位置関係・グルーピング境界・矢印の意味がテキスト変換時に欠落しやすく、エージェントがセクション境界を正しく読み取れないことが多い
- RDRA: 最初から構造化テキストのため変換不要、エージェントが依存関係をそのまま追跡できる
- RDRAの成果物の例:
- アクター一覧: ID・アクター名・種別・説明
- ゴール一覧: ID・ゴール内容・主なステークホルダー
- 要求一覧: ID・内容・関連ゴール（Traces to）
- ビジネスユースケース一覧: ID・ユースケース名・主なアクター・内容・関連要求
■ 4. 成果物の管理構造
- 規模拡大時の課題:
- ゴール10個・要求50個・ユースケース30個ともなると1ページでの管理が困難
- Confluenceでの共同編集時にコンフリクトが頻発
- 推奨するページ分離の構造:
- インデックスページ: IDと概要の一覧のみ掲載、依存関係の全体像を俯瞰可能にする
- 詳細ページ: 個別のゴール・要求ごとに背景・議論の経緯・受け入れ条件を記述
- Confluenceのページツリー例:
- プロジェクトX 要求分析
- インデックス（ゴール・要求・ユースケース一覧と依存関係）
- ゴール（各GOAL-XXX）
- 要求（グループ分けして管理）
- ビジネスユースケース（グループ分けして管理）
- 業務フロー（プロセス別）
- エージェント活用の方針:
- インデックスページのみ読み込めば依存関係の全体像を把握可能
- 特定の要求を深掘りする場合のみ詳細ページを参照させる
■ 5. Claude CodeとRDRAの実践ワークフロー
- Step 1: スコープ把握:
- エンジニア数名がインセプションデッキや関連チームの業務マニュアルを読む
- エージェントがConfluence・Notion・Slackを検索し、関連するアクターや外部システムの仮説を提示
- エンジニアが仮説にフィードバックを返し、エージェントがRDRA形式で整理
- 仮説の存在が対話のきっかけとなり、エンジニアの暗黙知を引き出す
- Step 2: 業務フロー生成:
- コンテキスト特定後、エージェントが各コンテキストのas-is業務フローをMermaidシーケンス図で生成
- 各業務プロセスでの課題仮説も同時に提示
- 人間のレビューにより、ドキュメント外の業務の実態（暗黙知）を反映
- as-is業務フロー確定後、to-be候補を複数提案し、ゴール・要求との紐づけを明示
- Step 3: 非同期の仮説検証ループ:
- エージェントの処理待ち時間が人間の思考時間になる
- エージェントが案を生成している間に、エンジニアは別のドキュメント調査や運用チームへのSlack確認・モニタリングダッシュボードの調査が可能
- 人間とエージェントが非同期に仮説を検証し合うリズムが生まれる
- Step 4: 成果物の共有（配置先の選択）:
- GitHubの課題: ライセンスコストが高く、非エンジニアのリテラシー壁が組織スケールのボトルネックになる
- Confluenceの利点: リアルタイム共同編集が可能、ミーティング中に全員が同時に要求を修正できる
- Confluenceの課題: Claude CodeへのデータP転送に工夫が必要（自作Confluence CLI、MCPサーバーなど）
- チームの実態（リテラシー・コスト・規模）に合わせて配置先を選択することが重要
■ 6. まとめ
- SDDと要求分析の関係:
- 両者は対立せず補完関係にある
- SDDは「仕様を書いてからコードを生成する」アプローチ
- その前工程として「なぜこのシステムを作るのか、誰のどんな業務課題を解決するのか」を構造化する要求分析が必要
- RDRAを選ぶ理由:
- 表形式はコーディングエージェントとの相性がよい
- ビジュアル手法では構造化しにくい情報をエージェントが読み書きしやすいフォーマットで表現できる
- 依存関係の明示により「なぜこのタスクが必要か」をゴールまで一気通貫で遡れる
- 成果物の配置:
- チームの実態に合わせて配置先を選択する
- GitHubが常にベストとは限らない
- 非エンジニアが気軽に書き込み、議論しながら育てられるツールと連携することで、要求分析がチーム全体の営みになる