仕様駆動FWを使ってみての振り返り

Transcript

1. 2026.1.22 仕様駆動FWを使ってみての振り返り 服部 好晃 1
2. はじめに AI どれくらい使ってますか？ Copilot？ Claude Code？ いきなり書かせてる？ Plan モードは最低限使ってる？ Skill とかカスタマイズしてる？ 2
3. AI 任せきりにしたときの痛み コードが大量生成されがち ディレクトリ構造も独断で作られ、気づけば迷路 よほどのコードでない限り、指摘しづらい 動くコードなのでレビューも甘くなりがち 3
4. 今日のゴール / アジェンダ CC-SDD を触ってわかったこと プロセス上の課題 価値提供とのジレンマ 3つの構文の整理と CC-SDD との対応 アジャイル寄りにするアイデア 次に試したいこと 4
5. 触ってわかったこと 仕様・要件の作成力は高い その分野・技術に精通してないと仕様が正しいか分かりづらい 動くコードは出来上がるので余計にわからない わかる人からの指摘 → 実装で抜け漏れ → 手戻り 手戻りのたびに Claude のコンテキストが枯渇し、待ちが長い 5
6. プロセス上の課題 サブタスクが「設計→実装→動作確認→PR」など大粒になりがち 「テーブル作成」「ユーザー準備」「テスト作成」など細粒度に落とし込みにくい 開発フレームワーク（How）のためにバックログの作り方まで影響させたくない 6
7. 仕様駆動開発でプロダクトの価値は上がるのか？ 7
8. 価値ってなんだっけ スクラムの価値：動くソフトウェアを早く届けること 開発者のミッション：バックログを実現すること アジャイル宣言：「包括的なドキュメントよりも動くソフトウェアを」 感じているジレンマ CC-SDD は仕様設計が完成しないと実装に入れない バックログに価値があっても、設計待ちで開発が止まる 「包括的なドキュメント」を求める姿勢はアジャイルの精神に反する？ 価値提供のスピード vs 仕様の網羅性のトレードオフ 8
9. 3つの構文を整理する 項 目 ユーザーストーリー EARS Gherkin 視 点 ユーザー（人間） システム（仕様） シナリオ（振る舞い） 構 文 As a... / I want... / So that... When... / The system shall... Given... / When... / Then... 目 的 価値と背景の共有 仕様の曖昧さ排除 動作の検証・自動テスト化 役 割 なぜやるか？ 何をするか？ どう動くか？ 9
10. 要件・仕様・実装への分類 カテゴリ 構文 役割 要件 (Requirement) ユーザーストー リー 「何が欲しいか」「なぜか」に集中。ビジネス価 値やユーザーの願望を定義 仕様 (Specification) EARS 「どう動くべきか」を厳密に定義。システムの反 応条件や制約を論理的に整理 実装・検証 (Verification) Gherkin 「正しく動いているか」を確認。具体的なデータ で検証 10
11. CC-SDD との対応関係 11
12. CC-SDD の構造と構文の対応 CC-SDD のセクショ ン 推奨構文 カテゴ リ 目的 背景 (Context) ユーザーストーリ ー 要件 なぜ作るのか、誰が困っているの か 要件 (Requirement) EARS 仕様 システムが満たすべき振る舞いの 論理 戦略・設計 (Strategy) 自由形式 設計 技術的にどう解くか 検証 (Verification) Gherkin 検証 具体的なシナリオでの動作確認 12
13. 感じていた矛盾 疑問 CC-SDD の「要件」に EARS が使われている EARS は「システムの動作（仕様）」なのに、なぜ「要件」の場所に？ 解釈 一般的なスクラム：要件 ＝ ユーザーの願い（ストーリー） CC-SDD：要件 ＝ 満たすべき制約・システムの振る舞い → CC-SDD の「要件」は「システム要件」であり、ビジネス要件ではない 13
14. 矛盾を解消する運用 再解釈のポイント Context セクションに「ユーザーストーリー（WHO/WHAT/WHY）」を書く Requirement セクションには「EARS（システムの論理）」を書く 開発フローの整理 1. Context（Why） → ユーザーストーリー 2. Requirement（What/Logic） → EARS 3. Verification（How to test） → Gherkin 14
15. 仕様書は「出力」する時代じゃなかったのか コードから API ドキュメント生成（Swagger） UI コンポーネントからドキュメント生成（Storybook） Markdown からドキュメント生成（MkDocs） IaC から構成ドキュメント生成（Terraform Docs） 15
16. アジャイル寄りにするアイデア 発想の転換 仕様書は「開発の入力」ではなく「開発の出力」 開発過程：受け入れ条件（AC）ベースで進める 品質担保：BDD/TDD でテストを先に書く ワークフロー 1. バックログの AC からテストを作成 2. テストを満たす実装を AI で生成 3. テストが仕様の証拠となる 4. 最後にテストベースで仕様書を整備 16
17. FWを使わない選択肢 CLAUDE.md や Claude の機能（ルール、Hooks、コマンド、スキル）が充実 依存しない独自フレームワークを作る案もあり リポジトリを立てて試作し、よりアジャイルな使い方を探る 17