8ヶ月の仕様駆動開発を リバースエンジニアリングして、 Spec-Driven Scrum を定義した話

しゃけ.tech #1 / 2026.09.01 8ヶ月の仕様駆動開発を リバースエンジニアリングして、 Spec-Driven Scrum を定義した話 スクラムの上で、仕様駆動開発と改善を型にする。 YUKI IZUMOTO / KDDIアジャイル開発センター

Profile • Yuki Izumoto a.k.a 蜜葉 • @mitsuba_yu • Microsoft MVP for Developer Technologies (15th) • Designer / Developer / Photographer • スクラムマスター / サブマネージャー / CTO室 at KAG <- here !! • 洋酒と、カメラと、釣りと、ものづくりが好き。 • https://c-mitsuba.hatenablog.com

• http://c-mitsuba.hatenablog.com

Recently • 最近はInnerSourceやスクフェス、コミュニティのイベントで 組織文化形成や、仕様駆動開発とチーム ル ィン グ デ ビ の話をしています。 と育成、組織へのAIX適応

AGENDA / きょう話すこと 01 SDDで過ごした日々を分析してみた 02 分析結果から見つけた学びをスクラムに載せて型にした 02 / 32

TEAM / チーム構成 伴走支援開発です。 お客様のプロダクトを、お客様を交えたスクラムチームで作っています。 お客様 KAG PO ／ PO Assistant スクラムマスター ／ 開発者 4 プロダクトの在り方を策定して、PBIを作成する。 実装はこの4人。 同じコードベースを、複数人が並列でAIに実装する。 03 / 32

S TA C K 1 / 3 / プロダクトと環境 プロダクト 法令遵守系 申請承認業務のWebサービス 申請・承認のワークフローが中心。実装は ASP.net Core と React クラウド Azure WebApps, Static WebApps, Functions, SQL Service, Blob Storage, Application Insights etc… テスト Stryker.NET ／ StrykerJS AIが書くテストコードの正当性を担保するためのミューテーションテスト 04 / 32

S TA C K 2 / 3 / プロダクトと環境 エージェント Claude Code CodexやGitHub Copilotはなし フレームワーク GitHub Spec Kit /specify → /clarify → /plan → /tasks → /implement のコマンド群と、仕様書テンプレートを提供するOSS カスタマイズ grill-me Spec Kitの/clarify時に質問数を増やすために利用 05 / 32

S TA C K 3 / 3 / プロダクトと環境 チケット・リポジトリ Azure DevOps モノレポで運用。チケットもGitもPRもチームの予定も集約。公式MCPサーバーで接続可能。 MCPサーバー Serena コードベースの解析 MCP。アーキテクチャやドメインナレッジ、プロダクト概要や手順書もSerenaのmemory で管理。 その他の自作 スキル10本 ＋ スラッシュコマンド6本 スキルは全20本で、うち10本はSpec Kit標準。残りがチケットの下調べ・実機確認・スプリント集計など 06 / 32

FLOW / 開発の流れ PBI 人が書く › /specify 仕様書を書く › /clarify ＝ grill-me AIが質問する › /plan 設計 › /tasks › /implement 作業に分解 実装 › PR 人 + 別のAI 起動 clarifyだけ自作 PBIを /specify xxxx で開発をはじめる。 質問を、5問で打ち止めにしない /specify 1340 と打つと、スキルがMCP経由でチケットの本文と コメントを取ってきて、そのままSpec.mdを書き始めます。 Spec Kit標準の /clarify は1回につき、5問が上限。 上限なしにするためにgrill-meに置き換えてプロセスを拡張した。 1 PBI ＝ 1 spec ＝ 1 ブランチ ＝ 1 PRが基本。 最初から最後までひとつなぎにして、後から追跡できるようにする。 07 / 32

PREMISE / 最初は難しかったけど、慣れれば品質良くて速い 全体で8ヶ月、うち立ち上げに1ヶ月、実装が7ヶ月。 ２ヶ月目にはかなり慣れてきて、チームでプロセス整理を行ったり。 08 / 32

立ち上げ時にチームで整理した開発プロセス = 合意形成

３ヶ月経ったチームで整理した開発プロセス = より複雑になりつつ、個々人の工夫をチームに適応

PREMISE / とはいえスプリントを進めると歪はでる バグは、どこから来ていたのか。出どころを探したかった。 仮説 • 機能改善で 他の機能との整合性 が合わなくなってくるのでは？ • １機能でも、作ってみたものの やっぱり違うかも / もっとこうしたい で どんどん増築改修されて規模が複雑になるからでは？ （アジャイルの良さではあるものの…） 08 / 32

01 / 03 REVERSE ENGINEERING SPEC-DRIVEN DEVELOPMENT 8ヶ月を 1 プロダクトとリポジトリから振り返る できあがったプロダクトから、仕様駆動開発を逆回しして分析しました。

D ATA S O U R C E / 分析材料：8ヶ月の全量を洗い出してみる 426本 718件 772件 8,001件 1,281問 仕様書（spec.md） チケット プルリクエスト コミット AIが聞いてきた質問 53件 17.0万行 34.9万行 4.1万行 修正済みバグ（母数66件） フロント（手書き） バックエンド（手書き） 自動生成（型・APIクライアント） 10 / 32

HOW IT CONNECTS / 記録・材料は、すべてPBIに紐づいている /specify にPBI IDを渡した時点で、3つの記録がPBIに紐づきます。 ブランチと specs/<dir>/ は同じ名前で同時に作られ、対になります。 pbi_id specs/<dir>/ spec.md ／ tasks.md PBI ArtifactLink ブランチ 実装の単位 本文・コメント 変更履歴 Related work items PR・コミット 実際の差分 PBIから始めた以上、どの記録から入ってもPBIに紐づく 仕様駆動開発をエレガントに進めるにはPBIの品質が重要 12 / 32

REVERSE / 仕様駆動開発のプロセスを逆算する つくるとき PBI › 人が書く 今回やったこと AIが書いて人が判断 › テスト・実装 › 実装・コード AIが書く › Pull Request・CI › spec.md 人が判断してマージ › プロダクト 動いているもの 逆回し プロダクト 完成形 spec.md › Pull Request・CI どれだけ手がかかったか 結局どうなったか AIが何を聞き何を埋めたか › あるべきだったPBI 何が書かれていれば 良かったか 作る時は人が手を入れながら要件を形に仕上げていく。-> 全てAIに任せるにはどうすべきだったかを逆算で模索する。 ─ ─ 11 / 32

A N A LY S I S / やったこと：4通りの逆算 A バグから、入口まで遡る B AIの質問ログを、全量分類する C コードから、機能マップを逆生成する D 既存への変更とPR量を、機能種別ごとに集計する バグ53件を「コミット → 仕様書 → PBI」と辿り、1件ずつ原因を分類する 1,281問をカテゴリに割る 完成コードを正としてマップを復元し、着手前の計画と突き合わせる 変更108件を機能型×軸で、PR772件を粒度別で数える → 何が壊れたか → 何が書かれていなかったか → 何を計画し忘れたか → 何が変わりやすいか 13 / 32

FINDINGS / 数えてわかったことは、結局当たり前のことが多い。 • AIがよしなにやってくれると、どうしてもおざなりになってしまっていた。 • こんな当たり前のこと、手書きしていたころはちゃんと気にしていたのに…って思い出した。 62 % 逆算 A 4種 逆算 B 10 倍 逆算 A 逆算 C 25 % 原因の多くは、仕様の側だった AIが繰り返し聞いたのは4つ 既存に触る場所に、歪が集中 計画外の領域が、出どころ 記述不足21 ＋ 追従漏れ19 ＋ 非機能23 権限差・状態遷移 データ制約・スコープ境界 新規は60本でバグ1件 既存面はその10倍 設定・通知・出力・連携 108 件 逆算 D 3倍 逆算 D 逆算 A ρ=0.25 変わる場所は、だいたい同じ 大きいPBIは、PRも重い 直す回数で、品質は落ちない そのプロダクトの重要機能であるこ とが多い tasks 47超は、 tasks 15以下の3倍のコミット 改善回数に品質は依存しない 修正数： 一覧機能29回・状態遷移13回 フォーム10回 １度に実施する改善規模が 大きければ大きいほど、 バグが発生しやすい 14 / 32

02 / 03 MAKE IT NEW SCRUM スクラムへの適応 あるいは仕様駆動開発で拡張した新しいスクラムの形の１つとして 2

DEFINITION / KAG Spec-Driven Scrum とは AIが繰り返し聞いてきた4種類 — 権限差・状態遷移・データ制約・スコープ境界 — を、PBIに必ず書く「必須項目」と呼びます。 スクラムの検査・適応・透明性は変えません。AIでスクラムイベントを拡張します。 Spec-Driven Scrum イベント これまで リファインメント 認識を合わせて、見積もる プランニング 何を取るかを話し合う 必須項目が埋まっているかで判定する、 スプリントバックログに加える スプリント実行 人が実装する AIがSPEC作成から実装まで進める レビュー 開発した動くものを見せる レトロ ふりかえる AIがPBIの不明瞭点を洗い出し、 PO含めたスクラムチームで質問リストに答える 今まで通りのレビューとFBをもらう ＋ 実装済みの周辺機能で「影響なし」と判断し、変わっていないことも同時に見せる 実績データから、PBIの大きさ・書き方の基準を更新する 16 / 32

THE LOOP / 1スプリント リファインメント AIの質疑に答えて 必須項目を埋める スプリント実行 — この中を AI が回す プランニング › 着手ゲート 既存実装への 影響チェックを実施する › /specify /clarify 差し戻しゲート /plan /tasks レビュー /implement › 周辺機能に影響なし であることも見せる レトロ › PBIとゲートの 基準を更新する 分割ゲート PBIが不備や大きすぎのまま実装に進まないように、3つのゲートを用意した 着手ゲート プランニング 差し戻しゲート /clarify の後 分割ゲート /tasks の後 必須項目が埋まっていないPBIは、スプリントに入れない AIの質疑が７問（基準値）以下であれば、PBIが仕様として成立しているとみなす 累計８問(基準値)以上なら書き漏れが多いと判断し、リファインメントへ差し戻して、POとPBIを追記・修正 実装タスクが４６を超えたら、PBIを分割して/specifyからやり直す 17 / 32

REFINEMENT 1/3 / リファインメント：PBIをAIが解釈する仕様として満足させる リファインメント前にタスク リファインメントでやること リファインメント後の状態 リファインメントの準備として AIでPBIをチェック 質問リストに、 チームで答える 必須項目を埋めきって終える 荒い状態のPBIに対して、PBIの種類に合わせ たフォーマットを適用する。 POを含めたチームで質問リストに答え、その 場でPBIに書き込む。 フォーマットに合わせて、必須項目の欠けを AIが洗い出し、質問リストを作成する。 影響チェックの仮判定も、ここで確定する。 リファインメントの目的は 人の合意形成と共通理解だけでなく AIが過不足なく仕様を理解できるとして、 PBIを渡せる状態にすること。 既存に触るPBIなら、 影響チェックの下書きも作成する。 ここが済んだPBIだけが、 次のプランニングの候補対象になる。 18 / 32

REFINEMENT 2/3 / 必須項目：この4つが空なら、着手しない 01 02 03 04 権限差 状態遷移 データ制約 スコープ境界 必須・形式・桁。参照するマスタ。 今回やらないこと。 ユーザー入力やフォーム、DB設計 ここが空だと、AIは隣接する機能 など。 まで実装します。 誰に見えて、誰が操作できるのか。 ユーザー種類やシステムのデータ の見える範囲。 どの状態からどこへ、誰が動かせ るのか。戻れるのか。 逆に、画面の文言や並びはPBIに書きません。そこはspec化のときにAIと決めるのが適切だからです。 PBIを書きすぎるのも書かなさすぎるのも良くない。書かないものを決めるのが、同じくらい大事。 この4つは、見出しごと /specify が読み込みます。空のままだと、プランニングの着手ゲートで止められてしまう。 19 / 32

REFINEMENT 3/3 / 影響チェック：既存に触るPBIだけ、2つ問う 歪やバグが集中したのは既存の機能でした。 リファインメント前にSMがAIで下書きし、リファインメントでチームで確定します。 軸 1 — 読む側・READ・参照 軸 2 — 動かす側・WRITE・操作 同じデータを、 別の面から読んでいる所はどこか そのデータを駆動している、 別プロセス・別機能はどこか Ex) Ex) 一覧／詳細／検索・集計／レポート／通知／外部へ渡すデータ／キャッシュ 承認・確認／期限計算／バッチ／外部連携／権限判定／課金 etc… etc… 操作するまで変更反映されない機能は 画面表示される機能、箇所は、人もAIも変化に気付きやすい。 画面に出ないので、人もテストも気づきにくい。AIに頼りたい。 影響範囲はAIに調べさせます。ただしAIが探せるのは、この機能を「呼んでいる」コードまで。 呼ばれずに同じデータを「見ている」場所はコード上の繋がりが無く、型やテストも「挙動が無い」ことはエラーにできません。 （AI駆動ではなく、ORMやRepositoryパターンの導入など、ソフトウェア設計のアプローチで解決する領域であるべき） 2軸の固定リストを毎回当てて、全項目に「影響あり／影響なし（理由）」を書きます。 影響ありは機能改修の範囲として実装し、影響なしは理由と共にレビューにて確認と共有を行います。 20 / 32

PLANNING / スプリントプランニング：必須項目の記入をReadyとする 着 手 ゲー ト 必須項目4つが埋まっていないPBIは、入れない リファインメントで埋めた、権限差・状態遷移・データ制約・スコープ境界の4項目をここで確認します。 人の記憶ではなく、節が埋まっているかで機械的に判定できるので、「なんとなく行けそう」で入れることがなくなります。 残る2つのゲートは、スプリントに入ってから動きます。差し戻しゲートは /clarify の後、分割ゲートは /tasks の後。 タスクの実数はここで初めて出るので、プランニングの時点では分かりません。 プランニングでは ・PBIがAIにとってReadyになっているか / ゲートを満たすか、 ・優先順位 の２点を遵守して、スプリントバックログを作成します。 21 / 32

SPRINT / 計画・実装：/tasksが46を超えたら、その場で割り直す タスクの実数はここで初めて出ます。超えたPBIは仕切り直して、分割してから実装に入ります。 作業量複雑度 PR 1本あたりのコミット数（中央値） tasks 〜15 6コミット tasks 47超 19コミット 3倍 相関 ρ=+0.54 分割の理由を、感覚ではなく、コミット数 =「後のPRの重さ」で説明できます。 ※ tasks 16〜35 の圏では、変更23ファイルほどで収まっていました。 22 / 32

REVIEW / レビュー：FB + 周辺機能「影響なし」チェック 今スプリントのPBIと実装を以て 影響なしと判断した既存実装一覧を確認してもらう なぜ要るか 運用コスト 「影響なし」の判断フェーズがなく、 誰にも検証されない リファインメントにて殆どが準備済みのはず 変えた所しかデモに出ないので、間違っていても気づけません。 「影響なし（理由）」リストを、PBI実装後にAIで事実確認した結果でOK 見せる一覧は、リファインメントで用意した影響チェックで書いた 今回の案件では、後日バグとして発覚されることになった。 自分の判断は、自分では検算できない。PRレビューも同じ理由で、実装した本人のAIではなく別のチームメンバーのAIに見せます。 24 / 32

RETROSPECTIVE / レトロ：４つのマジックナンバー 着手ゲート 差し戻しゲート 分割ゲート 健全圏Task数 4項目 8問 46 16〜35 タスク数の分布の上位1割。 タスク数の分布の真ん中。 超えるとPRのコミットが3倍 見積りと振り返りの目安 PBIの必須項目。 AIの質問1,281問を分類したら、 4種類だった 質疑数の分布から。 9割のSPECが7問以内に収まる 型の決め打ちは、この4つだけです。 すべて私たちの実測値なので、レトロで自分たちの数字に引き直します。 25 / 32

R ERTERTO RSOPSEPCETCI T V IEV E / レトロ：PBIとゲートの基準を、実績で更新する SKILLとスクリプト3本（レトロ計器盤・CIで回す機械チェック・PR計器）で自動化済 計測集計分析 SKILLを回す SPECの質疑数・タスク数を自動集計 › 分布を見る › 真ん中5割＝健全 / 上位1割＝ゲート 基準を引き直す › 自チームの数字へ 超えたPBIを振り返る 書き方の問題か型の間違いか 書き方のルールは、決めただけでは守られない コミットに #チケットID・PRタイトルに種別・ブランチ名はspec名。この書き方のルールで、一連の開発過程が紐付けられます。 ちなみに、ルールがあってもPRタイトルの22%は守られず、ルールにしていなかったコミットのIDは35%しか付きませんでした。 チームがこなれてくるとなおさらAIに頼りがちになり、おざなりになっていました。 だからCIで機械チェックし、守られなくなったら文面ではなく仕組み（テンプレ・フック・CI）で担保します。 25 / 32

03 / 03 WRAP UP まとめ システマチックなプロセスと、人が介在する価値について 3

WRAP UP / AI時代のスクラムは システマチックなプロセスを、AIのために人が整備すること 計測から改善すること 実践はこれから 数字は実測 n=1 チームとAIの振る舞いを、AIを使って計測していく ことが大事。 1プロダクト・1チーム・8ヶ月の実践ログと得られた 知見を蒸留した結果できあがったプロセスであること。 今回は426本・53件・1,281問・PR772件の全量をデー タソースとして扱ってみた。 他にもフェーズごとのトークン数なども取得したい。 これが他のどんなチーム、どんな顧客にも有効なのかは これから検証していく。 29 / 32

WRAP UP / AIスクラムマスターは可能か？ このプロセスの全てをAIで構成し、 日々の議事録から要求を拾い上げるPO AIがいて、 AI DEVs に要求を引き渡し、 AI SMがゲートと分析改善を司れるなら 朝起きたら最高のアプリがインストールされている世界がくるかもしれない（夢） 29 / 32

WRAP UP / AIスクラムマスターは可能か？ それぐらい KAG Spec-Driven Scrum は、型に徹したスクラムです。 言い換えれば、チームに人が介在する以上、 メンバーの感情化やエンゲージメントが変数として発生します。 よりよいチームを目指すのSMが担う重要なポイントの１つであり、 SM は人がやるべき理由でもあり、人でチームを構成することこそが、 ビジネスや組織という広い目で、持続可能な価値創出ができると考えています。 29 / 32