仕様駆動開発とどう向き合うか 導入の前に考えたいこと

Transcript

1. 2026.03.28 仕様駆動開発とどう向き合うか ── 導入の前に考えたいこと 服部 好晃 1
2. 仕様駆動開発とは AIを制御するための手法 バイブスコーディングをやめて、仕様でAIを導く フレームワーク: Kiro / CC-SDD / Speckit ドキュメントの重厚感 AIをきっちり操作するにはこれだけの文章量が必要という指標 「これだけ考えて議論してAIに投げた」という証跡になる 2
3. 前提: 仕様駆動の考え方自体は正しい バイブスコーディングよりずっと良い AIに意図を正しく伝えるために仕様を書く → 正しいアプローチ 重厚なドキュメントにも価値がある このスライドで問いたいこと フレームワークをそのまま導入するだけでいいのか？ 我々のチーム・組織に合った使い方とは？ 3
4. もっと軽くできるのでは？ 4
5. Opus 4.6の進化 重厚なプロンプトは不要になりつつある Opus 4.6は賢い → 計画モードの文章量で十分設計できる CC-SDDやSpeckitがやっていること（要件→設計→タスク）は Claude Codeのルールに書けばできる 計画モード + ルール設定 計画モードの出力品質はルールでカスタマイズ可能 フレームワークの形式に縛られず、チームに合った粒度で運用できる 5
6. 並列タスクの誘惑 バックログ5個を同時実行できてしまう AIの力でタスクを並列処理 → 一見すると生産性が爆上がり でも待ってほしい アジャイルで学んだこと: シングルタスクで小さくサイクルを回す フィードバックサイクルを回して開発する方が早い この十数年の学びを「AIならできるかも」で捨てていいのか 6
7. 先行者と後続者 先に飛び込んだ人たち 問題に気づいてやり方を改造する あるいは「これはやばい」と撤退し始めている 後から始める人たち 先行者の試行錯誤を知らずにそのまま導入 うまくいった話だけを聞いて始める 同じ落とし穴にハマるリスク 7
8. ナレッジ共有の壁 8
9. 鶏と卵問題 「AIを使ってどうしたいですか？」 何が起きるか知らないと、この質問に答えられない 体験したナレッジの共有が先に必要 共有すべきこと AIを使って何が起きたのか チームとして本当に良かったのか さらにこうすればより良くなるという展望があるか 9
10. スクラム導入期と同じ スクラム導入の頃を思い出してほしい 最初はバックログの切り方すらわからなかった それでも共有と改善を繰り返してチームに定着した 定着までにやったこと やってみて何が起きたかをふりかえった チームに合うやり方を模索した こうすればもっと良くなるという改善を重ねた 10
11. 今、同じことが起きている 「AIを使ってどうしたいですか？」 今また同じことが起きている やってみないとわからない。でもやらないと答えられない。 解像度を上げるサイクル ナレッジを共有し、議論し、改善する 組織の中でこのサイクルをどう回すか 熱はある。方向が見えていない。 11
12. まとめ 仕様駆動開発は手段の一つ フレームワークの形式に囚われすぎない AIの進化に合わせて手法もアップデートする 忘れてはいけないこと 1. アジャイルの教訓を捨てない 2. 先行者の失敗・改善から学ぶ 3. ナレッジを組織で共有するサイクルを作る 4. 熱量を正しい方向に解放する 12