Slide 1

Slide 1 text

SDDで⾒える、AIコーディングの"内訳" -*/&Ϡϑʔ%FWFMPQNFOUXJUI"HFOUT.FFUVQ

Slide 2

Slide 2 text

˜-:$PSQPSBUJPO *OUFSOBM6TF0OMZ િా ஌໵ 4PEB5PNPZB -*/&Ϡϑʔגࣜձࣾ ϩʔΧϧɾ6($4#6։ൃϢχοτ։ൃσΟϏδϣϯ  ۀ຿಺༰  ϚοϓΞϓϦͷ#&։ൃ  0SDIFTUSBUJPO(VJMEϝϯόʔ ˜-:$PSQPSBUJPO

Slide 3

Slide 3 text

01 "*ίʔσΟϯάͷ଎͞ͷ಺༁͕ݟ͑ͳ͍ 02 4%%πʔϧΛ࢖ͬͨ։ൃ͸ΰϧϑʹࣅ͍ͯΔ 03 4%%πʔϧΛ࢖ͬͨ։ൃΛϲ݄΍ͬͯΈͯݟ͑ͨ΋ͷ Agenda

Slide 4

Slide 4 text

01. AIコーディングの速さの"内訳"が⾒えない

Slide 5

Slide 5 text

体感として、明らかに変わった $MBVEF$PEFΛ࢖͏Α͏ʹͳͬͯɺ࣮૷εϐʔυ্͕͕ͬͨ εϓϦϯτͰ͜ͳͤΔλεΫ΋ɺࣗવͱ૿͑ͨ 少なくとも、「遅くなった」とは感じない AIで、開発は確かに速くなった

Slide 6

Slide 6 text

⾒えていないコストがある ࣮૷தͷ⼿戻り ࣮૷લͷAIとの相談時間(プランモード) ˠίϛοτʹ΋޻਺ʹ΋ݱΕͳ͍ 開発スピードは上がっている WT ⾒えないコストも増えている ⇒ 「速くなった気がする」状態 本当に速くなっているのか?

Slide 7

Slide 7 text

Claudeのセッション履歴を手掛かりにできる しかし ਓ΍13͝ͱʹਐΊํ͕ҧ͏ͱɺ⽐較も集計もできない ·ͣ͸プロセスを揃える͜ͱ͕ඞཁ SDDツールなら、プロセスを揃えることが可能 "⾒える化"するための"構造化"

Slide 8

Slide 8 text

「要件 → 設計 → 実装」をフェーズで明⽰的に進める開発スタイル 実装に⼊る前に要件・設計をしっかり固める Spec-Driven Development(仕様駆動開発)

Slide 9

Slide 9 text

同じ思想のツールが、いくつも出てきている spec-kit cc-sdd OpenSpec 世の中のSDDツール

Slide 10

Slide 10 text

SDDツールを使ったワークフロー(スキルを使う順番)の例  /requirements ཁ݅ɾड͚ೖΕ৚݅࡞੒  /design طଘίʔυΛࢀরͯ͠ઃܭ࡞੒  /tasks ઃܭΛλεΫʹ෼ղ  /impl λεΫ͝ͱʹ࣮૷ ⽣成物が、ドキュメントとして残る SDDツールの典型的なフロー 各フェーズで使うスキルが定められている

Slide 11

Slide 11 text

本来の狙い ཁ݅ɾઃܭɾ࣮૷͕ɺ明⽰的に積み上がる ࢓༷ΛઌʹݻΊΔ͔Βɺ"*ͷ࣮૷͕意図通りになりやすい υΩϡϝϯτ͕࢒Δ͔Βɺチームで共有・検証しやすい 副産物として、こんなメリットも SDDツールΛ࢖͑͹ɺεΩϧ͕౷Ұ͞ΕΔͷͰプロセスの計測が可能になる 今⽇は、この副産物の話 SDDで、何が変わるか

Slide 12

Slide 12 text

どのツールも、各フェーズのスキルが⽤意されている ツール 計画(要件・設計・タスク) 実装 spec-kit /specify ˠ /plan ˠ /tasks /implement cc-sdd /requirements ˠ /design ˠ /tasks /impl OpenSpec /openspec:proposal ʢҰׅੜ੒ʣ /openspec:apply チームで導⼊すれば、全員が同じスキルで同じフェーズを踏む ˠϓϩηε͕ଗ͏͔Βɺログとして集計・⽐較できるΑ͏ʹͳΔ なぜSDDツールならプロセスの計測ができるのか

Slide 13

Slide 13 text

SDDツールでスキルを揃えた結果、以下が計測になる 要件作成  設計作成  実装開始 ˠ଎͞ͷ಺༁͕ɺ13͝ͱʹ時刻として並ぶ セッションログから、このような表が作れる

Slide 14

Slide 14 text

02. SDDは ゴルフに似ている

Slide 15

Slide 15 text

⾵を読む Ͳ͜ʹɺͲ͏ଧ͔ͭ ˠཁ݅ɾ࢓༷ΛݻΊΔ ショット ଧͭ ˠ"*͕࣮૷͢Δ カップイン ΧοϓʹೖΔ ˠ׬੒ɾϚʔδ SDDのプロセスは、ゴルフの3ステップに似ている

Slide 16

Slide 16 text

⾵を読む ཁ݅֬ೝ Ϣʔεέʔε੔ཧͳͲ ઃܭ֬ೝ Τϥʔϋϯυϧํ਑ σʔλϞσϧઃܭ طଘίʔυௐࠪͳͲ ςετํ਑ ショット ࣮૷मਖ਼ カップイン Ϛʔδ ⾵読みのほうが、やることが多い 各ステップで何をしているか

Slide 17

Slide 17 text

AIが実装したコードが、⼿直しなしで⼀発マージOK ͜Ε͕ى͖Δͷ͸ɺ⾵読み(要件・仕様)が正確だった証拠 ホールインワンを打てる頻度こそ、「開発速度の向上」を示す1つの指標 理想は、ホールインワン

Slide 18

Slide 18 text

Կ౓΋ඍमਖ਼͕ඞཁ 🏌🏌🏌 ख௚͠ͷటপԽ 🐪 ॏཁͳલఏ΍੍໿Λݟམͱͯ͠ഁ୼ 💦 ઃܭҙਤͱҧ͏ํ޲ʹਐΉ 🌲🌲 どれも、⾵読みの精度が原因かもしれない ࢓༷ͷᐆດ͞͸ɺͦͷ··ίʔυͷᐆດ͞ʹͳΔ 起きがちな失敗パターン

Slide 19

Slide 19 text

今の⼿戻りには、2つの要因が混ざっている --.ࣗମͷγϯϓϧͳ࣮૷ϛε ཁ݅ɾ࢓༷Λɺਖ਼͘͠఻͑ΒΕ͍ͯͳ͍ લऀ͸ɺਐԽͰݮΔՄೳੑ͕͋Δɻ ͕ࠩͭ͘ͷ͸ɺޙऀͷʮཁ݅ɾ࢓༷Λ఻͑Δྗʯ෩ΛಡΉྗ LLMが進化したら、何が残る?

Slide 20

Slide 20 text

03. 2ヶ⽉やってみて⾒えたもの

Slide 21

Slide 21 text

チームメンバー全員のセッションログを解析して、可視化するツール ֤ϝϯόʔͷηογϣϯϩάΛղੳͯ͠1箇所に集約 13͝ͱʹʮどのスキルが・どの順で・何回ʯݺ͹Ε͔ͨ 4QSJOU୯ҐͰɺチーム全体ͷ܏޲͕ݟ͑Δ 4%%πʔϧͰεΩϧ͕౷Ұ͞Ε͍ͯΕ͹ɺ͜͏ͨ͠ूܭͷ࢓૊Έ͕؆୯ʹ࡞ΕΔ 各メンバーのプロセスを可視化するためのツールを作った

Slide 22

Slide 22 text

෩ΛಡΜͩ࣌ؒ ଧͪ௚࣌ؒ͠ ฏۉଧͪ௚͠ճ਺ Λ4QSJOU͝ͱൺֱ 「Sprint毎に上がったか・減ったか」を計測している ① サマリ ― Sprint推移のKPI

Slide 23

Slide 23 text

PRごとに、フェーズの時刻が表で並ぶ First commit / 要件作成 / 設計作成 / 実装開始 / Merge / 風読み / 打ち直し 13୯ҐͰʮいつ・何を・どれだけʯ΍͔͕ͬͨݟ͑Δ ② 時間計測 ― PRごとのマイルストーン

Slide 24

Slide 24 text

PRごとに、スキル発⽕・コミット・チャットをタイムラインで並べる εϜʔζʹਐΜͩ13ɺటপԽͨ͠13͕Ұ໨ྎવ ③ スキル履歴 ― 時系列で⾒える

Slide 25

Slide 25 text

指標 SPRINT 1 SPRINT 2 SPRINT 3 ⾵を読んだ時間 ¹ I I I 打ち直し時間 ² I I I 打ち直し回数 ³ ճ ճ ճ pSTUDPNNJUˠ࣮૷ணखʗ࠷ޙͷJNQMൃಈˠNFSHFʗžJNQMεΩϧݺͼग़͠ͷฏۉճ਺ 4QSJOUɿ4%%ಋೖ௚ޙʢֶशظؒʣ 4QSJOUɿճ਺11.0ʢଟΊʣʗ࣌ؒ11.2 hʢ୹͍ʣ 4QSJOUɿճ਺9.5ʢগͳΊʣʗ࣌ؒ13.0 hʢ௕͍ʣ ˠ4QSJOU͸ଧͪ௚͕͠ଟ͍͕ɺ͔͔ͬͨ࣌ؒ͸গͳ͍ɻドキュメントよりコードで詰 める΄͏͕ૣ͍ՄೳੑΛ͍ࣔࠦͯ͠Δ ⾒える指標 ― 3つの数字を並べて⾒る

Slide 26

Slide 26 text

打ち直し回数の推移 = 要件・仕様決めの精度がそのまま出る ݮΒ͚ͨ͠Ε͹ɺ⾵の読み⽅Λຏ͘ でも、打ち直しは悪じゃない ΤϯδχΞ͸ドキュメントよりコードで詰める΄͏͕ૣ͍͜ͱ΋ 学び① ― 打ち直しの回数に「⾵読みの精度」が映る

Slide 27

Slide 27 text

結局大事なのはPR全体の時間( first commit → merge ) ͜Εࣗମ͸ɺ(JU)VCͰ؆୯ʹܭଌͰ͖Δ਺ࣈ SDDツールの副産物の価値は、その時間の内訳が⾒えること ෩ΛಡΜͩ࣌ؒ ଧͪ௚࣌ؒ͠ ଧͪ௚͠ճ਺ 内訳が⾒えるから、「どこに時間がかかっているか」を数字で語れる 学び② ― ゴールはPR時間。その"内訳"が⾒えるのがSDDツール

Slide 28

Slide 28 text

جຊ͸ɺ⾵読みの精度を⾼める Ͱ΋ɺコードで詰めるほうが早い৔໘΋͋Δ ⾵読みの時間を場⾯に応じて調整して、ベストルートを選ぶ 結論 ― ⾵読みの時間を、場⾯で調整する

Slide 29

Slide 29 text

今⽇お伝えしたかったこと SDDツールͰɺϓϩηεͷ内訳͕ݟ͑Δ SDDをゴルフに例えることで、共通イメージを持って振り返りやすくなる ෩ಡΈͷ時間Λ৔໘Ͱௐ੔ͯ͠ɺベストルートΛબͿ まとめ

Slide 30

Slide 30 text

Thank You