仕様駆動開発を新卒が チームに持ち込んだ話

【25卒】技術で尊敬される先輩にならNight (https://25-graduate.connpass.com/event/389112/) 登壇資料

Transcript

1. @sknow_snow 仕様駆動開発を新卒が チームに持ち込んだ話 〜 Claude Code 時代に書き換えた1点 〜 ／ 2026-05-15 · 榎本佑希
2. 榎本 佑希 / Yuki Enomoto 25卒 リフォーム会社 × ユーザーの マッチングサービスを担当 いまやっていること インフラ / バックエンド がメイン Claude の部内利用推進 チームの 開発環境の整備 EM（エンジニアリングマネージャー） に興味あり 2 自己紹介 @sknow_snow
3. AWS AgentCore で AI コ ールセンターを構築 一人で書き進め、仕様が 頭の中だけ に 新アーキを採用するほ ど、引き継ぎコストが跳 ね上がる → 手に取った本: 　 『仕様駆動開発 実践入門』 3 「自分が抜けたら、誰も触れない」 @sknow_snow
4. 4つの原則 + 7つの工程 仕様をどこに置き、誰が承認し、 どう変更するかを 共通言語 にする → コアは SSOT 　 「コード」ではなく 「仕様」 に置く ひと⽬でわかる 仕様駆動開発の全体像 7つの⼯程 実践プロセス 具体的な進め⽅ 4つの原則 開発の⽅針 守るべき考え⽅ 3つの技術要素 開発の基盤 仕様を扱う技術 ① 原則決定 Constitution ② 企画・要件定義 Specify ③ 設計計画 Plan ④ タスク分割 Tasks ⑤ 実装 Implement ⑥ 検証・受⼊ Verify / Accept ⑦ 移⾏・運⽤ Migration / Operation ① 仕様は ⽣きた ドキュメント ② 仕様は 信頼できる 唯⼀の情報源 ③ 仕様は 変更と反復が 前提 ④ AIで コストを 抑える Markdown で仕様を書く Git / GitHub で管理 AI / AIエディタ で仕様を活⽤ 4 仕様駆動開発（SDD）の骨格 @sknow_snow
5. 本書の前提 人間の隣で実装を支援する 「副操縦士」 GitHub + Cursor 僕たちの現場 複数ファイル編集・コミット・PR まで自律する 「自律して走る開発者」 Claude Code 5 AIに任せる粒度が違っていた @sknow_snow
6. 仕様に書く Why — なぜ作るか What — 何を満たせば成功か 守るべき制約 — 絶対に破ってはいけない境 界 仕様に閉じ込めない How — 実装の手順 → agent に任せる 6 仕様 = 人への説明書 → agentへの契約書 @sknow_snow
7. 全体ルール AGENTS.md CLAUDE.md チーム共通の振る舞い 繰り返す作業 Skill 反復可能な手順 ドメインごとの意思決定 Domain Doc ADR 文脈と決定の履歴 7 契約の置き場は3つ @sknow_snow
8. agent に「外部APIの仕様書を作って」と任せた こちらが確認すべき前提を渡さないまま 依頼 agent は それらしい仕様 を組み立てて提出 一見ちゃんとしているけど、信じて進めたら 当然動かない → agent は 前提を疑うように設計しない限り、それっぽい前提のまま進めてしまう → 仕様 = 契約として、人間が固定する 境界 が必要 8 Why/What を固定しないと、こうなる @sknow_snow
9. 1ドメイン先行 → 効果と失敗を計測 → 横展開 Jira に 「Claude展開」ワークストリーム を作成 勉強会・改善チケットも見える化 1人の頑張りにせず、組織のレールに乗せる これが、新卒主導でも続けられたポイント 9 チームへの広げ方 @sknow_snow
10. 必要なのは、 適切な「インプット」と、 前提に合わせた「アウトプット」 。 皆さんのチームにも、 書き換えられる 違和感 や 負債 が、 きっとあるはずです。 10 新卒でも、開発環境はより良くできる @sknow_snow