SDDで⾒える、AIコーディングの"内訳"

2026年5月8日に開催された「LINEヤフー Development with Agents Meetup #3」の登壇資料です。
https://lycorptech-jp.connpass.com/event/388828/

Transcript

1. SDDで⾒える、AIコーディングの"内訳" -*/&Ϡϑʔ
   %FWFMPQNFOU
   XJUI
   "HFOUT
   .FFUVQ
   
2. ˜
   -:
   $PSQPSBUJPO *OUFSOBM
   6TF
   0OMZ િా ஌໵ 4PEB
   5PNPZB -*/&Ϡϑʔגࣜձࣾ ϩʔΧϧɾ6($
   4#6
   ։ൃϢχοτ
   ։ൃσΟϏδϣϯ  ۀ຿಺༰  ϚοϓΞϓϦͷ#&։ൃ  0SDIFTUSBUJPO
   (VJMEϝϯόʔ ˜
   -:
   $PSQPSBUJPO
3. 01 "*ίʔσΟϯάͷ଎͞ͷ಺༁͕ݟ͑ͳ͍ 02 4%%πʔϧΛ࢖ͬͨ։ൃ͸ΰϧϑʹࣅ͍ͯΔ 03 4%%πʔϧΛ࢖ͬͨ։ൃΛϲ݄΍ͬͯΈͯݟ͑ͨ΋ͷ Agenda
4. 01. AIコーディングの速さの"内訳"が⾒えない
5. 体感として、明らかに変わった $MBVEF
   $PEFΛ࢖͏Α͏ʹͳͬͯɺ࣮૷εϐʔυ্͕͕ͬͨ εϓϦϯτͰ͜ͳͤΔλεΫ΋ɺࣗવͱ૿͑ͨ 少なくとも、「遅くなった」とは感じない AIで、開発は確かに速くなった
6. ⾒えていないコストがある ࣮૷தͷ⼿戻り ࣮૷લͷAIとの相談時間（プランモード） ˠ
   ίϛοτʹ΋޻਺ʹ΋ݱΕͳ͍ 開発スピードは上がっている WT ⾒えないコストも増えている ⇒ 「速くなった気がする」状態 本当に速くなっているのか？
7. Claudeのセッション履歴を手掛かりにできる しかし ਓ΍13͝ͱʹਐΊํ͕ҧ͏ͱɺ⽐較も集計もできない ·ͣ͸プロセスを揃える͜ͱ͕ඞཁ SDDツールなら、プロセスを揃えることが可能 "⾒える化"するための"構造化"
8. 「要件 → 設計 → 実装」をフェーズで明⽰的に進める開発スタイル 実装に⼊る前に要件・設計をしっかり固める Spec-Driven Development（仕様駆動開発）
9. 同じ思想のツールが、いくつも出てきている spec-kit cc-sdd OpenSpec 世の中のSDDツール
10. SDDツールを使ったワークフロー(スキルを使う順番)の例 
    /requirements ཁ݅ɾड͚ೖΕ৚݅࡞੒ 
    /design طଘίʔυΛࢀরͯ͠ઃܭ࡞੒ 
    /tasks ઃܭΛλεΫʹ෼ղ 
    /impl λεΫ͝ͱʹ࣮૷ ⽣成物が、ドキュメントとして残る SDDツールの典型的なフロー 各フェーズで使うスキルが定められている
11. 本来の狙い ཁ݅ɾઃܭɾ࣮૷͕ɺ明⽰的に積み上がる ࢓༷ΛઌʹݻΊΔ͔Βɺ"*ͷ࣮૷͕意図通りになりやすい υΩϡϝϯτ͕࢒Δ͔Βɺチームで共有・検証しやすい 副産物として、こんなメリットも SDDツールΛ࢖͑͹ɺεΩϧ͕౷Ұ͞ΕΔͷͰプロセスの計測が可能になる 今⽇は、この副産物の話 SDDで、何が変わるか
12. どのツールも、各フェーズのスキルが⽤意されている ツール 計画（要件・設計・タスク） 実装 spec-kit /specify ˠ /plan ˠ /tasks /implement cc-sdd /requirements ˠ /design ˠ /tasks /impl OpenSpec /openspec:proposal ʢҰׅੜ੒ʣ /openspec:apply チームで導⼊すれば、全員が同じスキルで同じフェーズを踏む ˠ
    ϓϩηε͕ଗ͏͔Βɺログとして集計・⽐較できるΑ͏ʹͳΔ なぜSDDツールならプロセスの計測ができるのか
13. SDDツールでスキルを揃えた結果、以下が計測になる 要件作成 
    設計作成 
    実装開始 ˠ
    ଎͞ͷ಺༁͕ɺ13͝ͱʹ時刻として並ぶ セッションログから、このような表が作れる
14. 02. SDDは ゴルフに似ている
15. ⾵を読む Ͳ͜ʹɺͲ͏ଧ͔ͭ ˠཁ݅ɾ࢓༷ΛݻΊΔ ショット ଧͭ ˠ"*͕࣮૷͢Δ カップイン ΧοϓʹೖΔ ˠ׬੒ɾϚʔδ SDDのプロセスは、ゴルフの3ステップに似ている
16. ⾵を読む ཁ݅֬ೝ Ϣʔεέʔε੔ཧͳͲ ઃܭ֬ೝ Τϥʔϋϯυϧํ਑ σʔλϞσϧઃܭ طଘίʔυௐࠪͳͲ ςετํ਑ ショット ࣮૷मਖ਼ カップイン Ϛʔδ ⾵読みのほうが、やることが多い 各ステップで何をしているか
17. AIが実装したコードが、⼿直しなしで⼀発マージOK ͜Ε͕ى͖Δͷ͸ɺ⾵読み（要件・仕様）が正確だった証拠 ホールインワンを打てる頻度こそ、「開発速度の向上」を示す1つの指標 理想は、ホールインワン
18. Կ౓΋ඍमਖ਼͕ඞཁ 🏌🏌🏌 ख௚͠ͷటপԽ 🐪 ॏཁͳલఏ΍੍໿Λݟམͱͯ͠ഁ୼ 💦 ઃܭҙਤͱҧ͏ํ޲ʹਐΉ 🌲🌲 どれも、⾵読みの精度が原因かもしれない ࢓༷ͷᐆດ͞͸ɺͦͷ··ίʔυͷᐆດ͞ʹͳΔ 起きがちな失敗パターン
19. 今の⼿戻りには、2つの要因が混ざっている --.ࣗମͷγϯϓϧͳ࣮૷ϛε ཁ݅ɾ࢓༷Λɺਖ਼͘͠఻͑ΒΕ͍ͯͳ͍ લऀ͸ɺਐԽͰݮΔՄೳੑ͕͋Δɻ ͕ࠩͭ͘ͷ͸ɺޙऀͷʮཁ݅ɾ࢓༷Λ఻͑Δྗʯ
    
    ෩ΛಡΉྗ LLMが進化したら、何が残る？
20. 03. 2ヶ⽉やってみて⾒えたもの
21. チームメンバー全員のセッションログを解析して、可視化するツール ֤ϝϯόʔͷηογϣϯϩάΛղੳͯ͠
    1箇所に集約 13͝ͱʹʮどのスキルが・どの順で・何回ʯݺ͹Ε͔ͨ 4QSJOU୯ҐͰɺチーム全体ͷ܏޲͕ݟ͑Δ 4%%πʔϧͰεΩϧ͕౷Ұ͞Ε͍ͯΕ͹ɺ͜͏ͨ͠ूܭͷ࢓૊Έ͕؆୯ʹ࡞ΕΔ 各メンバーのプロセスを可視化するためのツールを作った
22. ෩ΛಡΜͩ࣌ؒ 
    ଧͪ௚࣌ؒ͠ 
    ฏۉଧͪ௚͠ճ਺ Λ4QSJOU͝ͱൺֱ 「Sprint毎に上がったか・減ったか」を計測している ① サマリ ― Sprint推移のKPI
23. PRごとに、フェーズの時刻が表で並ぶ First commit / 要件作成 / 設計作成 / 実装開始 / Merge / 風読み / 打ち直し 13୯ҐͰʮいつ・何を・どれだけʯ΍͔͕ͬͨݟ͑Δ ② 時間計測 ― PRごとのマイルストーン
24. PRごとに、スキル発⽕・コミット・チャットをタイムラインで並べる εϜʔζʹਐΜͩ13ɺటপԽͨ͠13͕Ұ໨ྎવ ③ スキル履歴 ― 時系列で⾒える
25. 指標 SPRINT 1 SPRINT 2 SPRINT 3 ⾵を読んだ時間 ¹ 
    I 
    I 
    I 打ち直し時間 ² 
    I 
    I 
    I 打ち直し回数 ³ 
    ճ 
    ճ 
    ճ
    pSTU
    DPNNJU
    ˠ
    ࣮૷ணख
    ʗ
    
    ࠷ޙͷJNQMൃಈ
    ˠ
    NFSHF
    ʗ
    ž
    JNQMεΩϧݺͼग़͠ͷฏۉճ਺ 4QSJOU
    ɿ
    4%%
    ಋೖ௚ޙʢֶशظؒʣ 4QSJOU
    ɿ
    ճ਺
    11.0ʢଟΊʣʗ
    ࣌ؒ
    11.2 hʢ୹͍ʣ 4QSJOU
    ɿ
    ճ਺
    9.5ʢগͳΊʣʗ
    ࣌ؒ
    13.0 hʢ௕͍ʣ ˠ
    4QSJOU͸ଧͪ௚͕͠ଟ͍͕ɺ͔͔ͬͨ࣌ؒ͸গͳ͍ɻドキュメントよりコードで詰 める΄͏͕ૣ͍ՄೳੑΛ͍ࣔࠦͯ͠Δ ⾒える指標 ― 3つの数字を並べて⾒る
26. 打ち直し回数の推移 = 要件・仕様決めの精度がそのまま出る ݮΒ͚ͨ͠Ε͹ɺ⾵の読み⽅Λຏ͘ でも、打ち直しは悪じゃない ΤϯδχΞ͸ドキュメントよりコードで詰める΄͏͕ૣ͍͜ͱ΋ 学び① ― 打ち直しの回数に「⾵読みの精度」が映る
27. 結局大事なのはPR全体の時間（ first commit → merge ） ͜Εࣗମ͸ɺ(JU)VCͰ؆୯ʹܭଌͰ͖Δ਺ࣈ SDDツールの副産物の価値は、その時間の内訳が⾒えること ෩ΛಡΜͩ࣌ؒ ଧͪ௚࣌ؒ͠ ଧͪ௚͠ճ਺ 内訳が⾒えるから、「どこに時間がかかっているか」を数字で語れる 学び② ― ゴールはPR時間。その"内訳"が⾒えるのがSDDツール
28. جຊ͸ɺ⾵読みの精度を⾼める Ͱ΋ɺコードで詰めるほうが早い৔໘΋͋Δ ⾵読みの時間を場⾯に応じて調整して、ベストルートを選ぶ 結論 ― ⾵読みの時間を、場⾯で調整する
29. 今⽇お伝えしたかったこと 
    SDDツールͰɺϓϩηεͷ内訳͕ݟ͑Δ 
    SDDをゴルフに例えることで、共通イメージを持って振り返りやすくなる 
    ෩ಡΈͷ時間Λ৔໘Ͱௐ੔ͯ͠ɺベストルートΛબͿ まとめ
30. Thank You