260512 SDD導入して3ヶ月の所管とチームナレッジをSkillやAgentにしたい

2026/05/12(木) 第3回 Fukuoka MCP Community ～エージェントスキルの回～ にて発表した登壇資料。
https://fukuoka-mcp.connpass.com/event/390271/

Transcript

1. 2026.05.12 第3回 Fukuoka MCP Community ～エージェントスキルの回～ SDD導入して3ヶ月の所管と チームナレッジをSkillやAgentにしたい KDDIアジャイル開発センター株式会社 阿部拓海(あべたく) #fukuoka_mcp.3
2. 1 KDDI Agile Development Center Corporation $ whoami あべたく @east_takumi { 　"普段" : { 　　"会社": "KDDIアジャイル開発センター株式会社(KAG)", 　　"職種": "Webバックエンドエンジニア", 　　"最近": "ｸﾛｰﾄﾞｺｰﾄﾞ...ﾜｶﾝﾅｲ...ﾀｽｹﾃ..." 　 　}, 　"コミュニティ活動": [ 　　"JAWS-UG おおいた&福岡", 　　"福岡クラウドUG", 　　"AWS Community Builder(Serverless)" 　] } #lydmeet #kagile.fukuoka
3. 2 KDDI Agile Development Center Corporation 自分のチームであったことを元にお話しします！
4. 3 KDDI Agile Development Center Corporation アジェンダ 1 2 3 4 リポジトリの脆弱性対応から始まったモノガタr.... SDDとは何か? SDDがチーム開発で効いたところ 展望(SkillやCustom Agent)
5. 4 KDDI Agile Development Center Corporation 1. リポジトリの脆弱性対応から始まったモノガタr.... #lydmeet #kagile.fukuoka
6. 5 KDDI Agile Development Center Corporation 1. リポジトリの脆弱性対応から始まったモノガタr.... #lydmeet #kagile.fukuoka それ以外にも....
7. 6 KDDI Agile Development Center Corporation 1. リポジトリの脆弱性対応から始まったモノガタr.... #lydmeet #kagile.fukuoka 状況整理（ｴｯ...ﾁｮﾏｯt... • 改修頻度が少なく、試験書などが4年以上更新がない（知見がない ◦ →古いドキュメントを逐次確認 && 当時の担当者にヒアリング && コードを読んで逆引き • アサインされたのはメンバーはこのリポジトリ初見 • ライブラリの脆弱性対応だったのが... ◦ Node.jsがv16だった... ◦ UTがない... ◦ リグレッションテストが手動&&具体的なスクショ等なし... →「脆弱性対応のPBIです」のつもりで開けたら、想像以上の状態だったw
8. 7 KDDI Agile Development Center Corporation 1. リポジトリの脆弱性対応から始まったモノガタr.... #lydmeet #kagile.fukuoka そこでSDDを導入したことの 話をします！
9. 8 KDDI Agile Development Center Corporation 2. SDDとは何か? #lydmeet #kagile.fukuoka SDDって？ Spec-Driven Development コードを書く前に仕様を明文化し、その仕様を基準点として設計・実装・検証を進 める考え方 「仕様」→開発の基準点になるストーリーライン • 何を作るか • なぜ作るか • どこまでを対象にする • どう実現するか • どの順番で進めるか
10. 9 KDDI Agile Development Center Corporation 2. SDDとは何か? #lydmeet #kagile.fukuoka Planモードでもできないことはない...が... 観点 Planモード SDD（今回はSpecKit） 成果物 チャット内の計画になりやすい Spec / Plan / Tasksとして残しやすい 前提の扱い 会話の文脈に依存しやすい ドキュメントとして確認しやすい 計画の永続性 コンテキスト内で完結しやすい ファイルとして後から見返せる 実装中の整合性 AI任せになりやすい 仕様・設計・タスクとのズレを確認しやすい 向いている場面 シンプルな修正、局所的な変更 複雑な機能、継続的な開発、チームで確認したい変更 ※ Planモードが不要ではない、使い分けが重要
11. 10 KDDI Agile Development Center Corporation 2. SDDとは何か? #lydmeet #kagile.fukuoka つまりSDDがなぜ嬉しかった？ • 整理の型になる ◦ 今から作るものの解像度をあげていける • 要件→設計→タスクと段階的に詳細化 ◦ 今のストーリーラインが元々想定してたものに沿っているかの検証がで き、作り直しリスクの低減 →ドキュメントを残していくことが重要なのがポイント！
12. 11 KDDI Agile Development Center Corporation 3. SDDがチーム開発で効いたところ #lydmeet #kagile.fukuoka 改修影響が大きすぎた • コンテキストが肥大化しすぎる予感 ◦ →前提知識の読み込ませにコードの逆引きの可能性もあるが、読み込み を徹底させたかった ◦ →段階的なアウトプット&インプットを兼ねる場所が必要 • チームメンバーへの引き継ぎがしやすくなった ◦ 作業順が決まっているし、判断経緯がDocsになるので追いやすい →複雑なタスクや判断が求められる現場にはあっている（ﾄｵﾓｯﾃﾙ...
13. 12 KDDI Agile Development Center Corporation 3. SDDがチーム開発で効いたところ #lydmeet #kagile.fukuoka ただ問題も.... • Specのレビューが膨大になりやすい（SpecKitならでは説） ◦ 膨大なコンテキストになるものが、mdファイルになっただけ ◦ →小さい変更でもかなり多くのmdファイルを生成する • ブランチ戦略などを考える必要もあるかも（ツールによる • できたSpecをどう資産化するか？ ◦ 既存のConfluenceページとの統合や更新をどう組んでいくか... →Spec Kitを使えば、良いSpecが自動で出てくるわけではない！！
14. 13 KDDI Agile Development Center Corporation 4. 展望(SkillやCustom Agent) #lydmeet #kagile.fukuoka チームの観点を毎回伝えてられない Spec / Plan / Tasksにはチームの観点が表れる • 何を先に確認したか　　　　　　　→ このリポジトリではまずここを見る • どこまでを対象にしたか　　　　　→ 仕様書と実装がズレたら実装を起点に確認する • 何をやらないと決めたか　　　　　→ テストが薄い箇所は変更前に観測点を作る • どのリスクを重く見たか　　　　　→ 影響範囲が広がる変更は一度止める • どんな粒度でタスクにしたか　　　→ Tasksはレビュー可能な粒度まで分ける
15. 14 KDDI Agile Development Center Corporation 4. 展望(SkillやCustom Agent) #lydmeet #kagile.fukuoka ざっくりできるんじゃないか？と思うこと 手順 • 既存コード調査の進め方 • 仕様把握の流れ • テスト追加の判断手順 チェックリスト • Planレビュー観点 • Tasks分解の観点 • PRレビュー観点 チームルール • 変更範囲の考え方 • 既存仕様との向き合い方 • やらないことの決め方 他サービス利用や制約 • GitHub CLI使ったGit管理 • テスト戦略やコーディング規約 • できたSpecを元にDocs更新
16. 15 KDDI Agile Development Center Corporation 4. 展望(SkillやCustom Agent) #lydmeet #kagile.fukuoka Skillを育てるためのログ集めSkill
17. 16 KDDI Agile Development Center Corporation 4. 展望(SkillやCustom Agent) #lydmeet #kagile.fukuoka Docsレビュー用のCustom Agent specify / clarify / plan などで生成されたmdファイルをreviewするAgent →ConfluenceやReadmeなどを探索してドメイン知識/制約とのズレがないか？をチェッ クさせてる
18. 17 KDDI Agile Development Center Corporation まとめ 1. SDDはコードを書く前に基準点として設計・実装・検証を進める考え 方 2. チームの動き方やタスク粒度でPlanモード/SDDを使い分よう 3. AIとの会話をログに残しつつ、Skillを作っていきたい！！！ SDDはいいぞ〜〜（沼） #lydmeet #kagile.fukuoka
20. アジャイルに⼒を与え 共 に成⻑し続ける社会を創る