仕様書駆動開発のすゝめ

Transcript

1. 仕様書駆動開発のすすめ — 認識ズレ・手戻りを減らして、開発速度を向上させよう — ラッコ株式会社 / 吉田雅也 　2026.02.24 1 / 12
2. 今日のゴール この15分で 3つのこと が分かる： なぜ仕様書駆動開発が必要なのか 1 ワークフローの全体像と「人間がやること」 2 今すぐ使い始める方法 3 2 / 12
3. こんな経験ありませんか？ 意図と違う方向に実装が進んでいた 途中で軌道修正したら、別の箇所が壊れた AIの実装を「見守る」時間が長い 完成したコードを読んで初めて「違う」と気づく 問題の根本：AIと人間の「認識合わせ」が不十分のまま実装が始まる 3 / 12
4. 仕様書駆動開発とは 「実装の前に、AIと人間で仕様書を作る」開発手法 従来のAI開発 いきなり実装 → レビュー → 手戻り多発 仕様書駆動開発 要件定義 → 設計 → 実装計画 → 実装 人間が承認してから次へ進む 仕様書 = AIと人間の共通認識 それがドキュメントとして残ることで様々なメリットがある 4 / 12
5. ワークフロー全体像 各仕様書で 人間の承認ゲート を通過してから次へ タスクソース：直接チャット / Backlog課題 / Linear課題 タスク取得 課題やチャットから 要件定義 req.md 作成 設計 design.md 作成 実装計画 impl.md 作成 実装・PR コード自動生成 5 / 12 1 2 3 4 5
6. 人間がやること / AIがやること Phase AIがやること 人間がやること 要件定義 req.md を作成 要件に漏れがないか確認 設計 design.md を作成 設計方針が妥当か確認 実装計画 impl.md を作成 手順・順序の問題を確認 実装 コードを書く （見守り不要） PR作成 PR自動作成 PRレビュー 人間の仕事 =「実装の監視」ではなく「仕様書のレビュー」 コードではなく、仕様書を見ることで実装の質を担保する（認知負荷軽減） 6 / 12
7. 生成される仕様書 docs/tmp/specs/{機能名}/ に3つのファイルを生成 req.md 機能概要 ユースケース 機能要件 非機能要件 受け入れ基準 design.md ファイル構成 各ファイルの責務 処理フロー エラーハンドリング アーキテクチャ準拠 impl.md 1: 型定義 2: ヘルパ実装 3: ドメインロジック ... N: 最終確認 設計書はコードを含まず自然言語で記述 → 他のレビュアーも自然言語で設計レビューができる 7 / 12
8. なぜ効果があるのか 認識ズレの防止 実装前に要件・設計を明 文化 →「完成してから違った」 がなくなる 手戻りの削減 各フェーズで承認ゲート を通過、 → 問題を早い段階で発見 と修正 レビュー負荷の軽 減 仕様書が残る、仕様書に 忠実にAIが実装 → 初見でもレビューしや すい、見守り不要 8 / 12
9. 使い方 インストール 1. /plugin 2. rakko-plugins マーケットプレイス 3. spec-driven-workflow を選択 4. 「Install for you」を選択 起動方法 以下で自動的にワークフロー開始： 「◦◦を実装して」 「ID-1234を実装して」 「KW-456を実装して」 あとはAIの質問に答えつつ、作成された仕様書をレビューするだけ 9 / 12
10. うまく使うコツ 小さいタスクから試す — 新規の小機能やバグ修正がおすすめ ✓ 要件定義をしっかり伝える — ここで認識が揃えば後工程はスムーズ ✓ レビューは「方向性」を見る — コードレベルはPRレビューで確認 ✓ 前の工程にロールバック — 実装が微妙なら設計が微妙な可能性大 ✓ 10 / 12
11. まとめ Next Action：小さいタスクで一度試してみてください！ 困ったら吉田（雅）やチームメンバーに気軽に相談を！ 仕様書駆動開発 = 実装前にAIと仕様書を作る開発手法 1 人間の役割は「仕様書のレビュー」 実装の見守りではなく、方向性の確認に集中 2 プラグインで誰でもすぐに実践可能 3 11 / 12
12. ありがとうございました ご質問があればお気軽にどうぞ 12 / 12