仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える / AICon2026_hirakawa

Transcript

1. 2026/7/15 #RAKUSMeetup 仕様駆動開発、導⼊半年。 「本当に速くなってるの?」にデータで答える 株式会社ラクス © RAKUS Co., Ltd. 楽楽精算開発部 開発3課 平川裕多 1
2. チーム前提 • 楽楽精算の開発を担当（担当領域：iOSアプリとバックエンド） • アジャイル ∕ 2週間スプリント ∕ エンジニア6名 • マルチプラットフォーム： バックエンド ＋ iOS ＋ Android ＋ フロントエンド • SDDの仕様はプラットフォーム毎に作る。ただし設計のタイミングは揃う → その場でプラットフォーム間の認識合わせができる #RAKUSMeetup © RAKUS Co., Ltd. 2
3. 個⼈の実装は速くなった AI活⽤で、個⼈の実装スピードは 確かに劇的に上がった。 コードを書くスピードは、もう昔ほど⼤きなボトルネックにはならない。 #RAKUSMeetup © RAKUS Co., Ltd. 3
4. その裏で起きていたこと • 意図のよく分からないコードの混⼊ • レビュー負荷の偏り • テストフェーズで初めて「考慮漏れ」に気づく事故の多発 #RAKUSMeetup © RAKUS Co., Ltd. 4
5. 問い 「AIで速くなった」の裏で、 本当は何を払っていたのか? ― この問いを、最後まで追います #RAKUSMeetup © RAKUS Co., Ltd. 5
6. 気づきの種 AIへの「指⽰（プロンプト）」の質で、成果物の質が決まる でも、その指⽰の質は⼈によってブレる →「指⽰を、誰がやっても同じ質にできないか?」 #RAKUSMeetup © RAKUS Co., Ltd. 6
7. 最初の試み― いきなりSDDではなかった • 最初からSDDを狙っていたわけではない • AI設計テンプレート ⼿で書いていた設計を、AIに書かせて時短しようとしていた • 1ヶ⽉ほど、⼿探りで試⾏錯誤 #RAKUSMeetup © RAKUS Co., Ltd. 7
8. ⾶びつき ちょうどその頃、世の中で「SDD（仕様駆動開発）」 が流⾏り始めた 「...これじゃん！？」 ※ きれいに⽐較検討して選んだ、というより “⾶びついた” #RAKUSMeetup © RAKUS Co., Ltd. 8
9. ⾶びついた後の「答え合わせ」 なぜ結局これで腹落ちしたか Plan 便利だが結局エンジニア個⼈の能⼒に依存（＝直接指⽰と変わらない） TDD リファクタに強いが、「仕様」がブレるとテスト⾃体が空中分解 結論 すべての源流である「仕様」を中⼼に置くのが筋がいい ワークフロー OpenSpec（Markdownで構造化した⾃然⾔語の仕様書） 設計を先にPRマージ ∕ 実装を“作業化” #RAKUSMeetup © RAKUS Co., Ltd. 9
10. 突っ込まれる⽇々 上司 メンバー 「それ、本当に早くなってるの？」 「設計フェーズが、 ⼤変なんだけど」 → だから、本気で検証することにした #RAKUSMeetup © RAKUS Co., Ltd. 10
11. 検証してみたら 掘ってみたら、予想外だった SDDは品質のために入れたものではない（狙いは「実装の属人性をなくす」こと） なのに “狙っていなかったところ ” が、静かに変わっていた。 #RAKUSMeetup © RAKUS Co., Ltd. 11
12. 検証の前置き― 速さの“正体” • 条件を揃えるため、AIもアジャイルも定着した時期“以降”だけで⽐較 • 正直に⾔うと：実装は、速くなった が、その正体は ―― 次の3つの指標を⾒てください #RAKUSMeetup © RAKUS Co., Ltd. 12
13. 指標 ① 時間 上流（設計） 増↑ ＋ 下流（実装‧テスト） 減↓ ＝ 合計（総量） 変わらない → SDDは「時短策」ではない #RAKUSMeetup © RAKUS Co., Ltd. 13
14. 指標 ② レビュー 1PRあたりの他者レビュー でも、中⾝が変わった コメント数 １ • 実装PRでの“揉め”が減った • 議論が「仕様レビュー」へ前倒し 中央値はずっと横ばい → コードの場の仕様揉め → 仕様の場のレビューへ #RAKUSMeetup © RAKUS Co., Ltd. 14
15. 指標 ③ バグ（事故） 件数より、“振れ幅” が⼩さくなった 件数（中央値） 1件あたり対応時間 スプリント内 最⼤バグ数 8 → 6〜7 17h → 11h 24 → 8 ⼤きくは変わらない 出ても“軽い” ⼤爆発が消えた ＝ 事故の「総量」より、事故の「振れ幅」が⼩さくなった ※ テスト完⾛スプリントのみで集計∕サンプルは少なめ #RAKUSMeetup © RAKUS Co., Ltd. 15
16. ＜問い(再掲)＞ 「速くなった」の裏で、本当は何を払っていたのか? 払っていたのは“予測可能性”だった 3指標まとめ：時間＝移動／レビュー＝移動／バグ＝件数は横ばい、でも “振れ幅”が縮んだ 1年前、がむしゃらにやっていた頃と “ほぼ同じ” 実装スピードを予測可能に出せている。 #RAKUSMeetup © RAKUS Co., Ltd. 16
17. 「予測可能になる」とは • バグの“数”は劇的には減っていない。減ったのは“振れ幅” （最⼤24件 → 8件程度） • スプリント後半に、予定外の“⼤爆発”が落ちなくなった • 計画が、計画通りに動く → ユーザーに安定したペースで価値を届け続けられる（顧客貢献の⼟台） #RAKUSMeetup © RAKUS Co., Ltd. 17
18. まとめ • SDDは「時短策」ではなかった • 品質と予測可能性への“投資”だった • • 同じ速度を、“読める形”で出すための⼟台 でも、アジャイルは捨てない ― スプリントの中で“決める位置”を前にずらしただけ #RAKUSMeetup © RAKUS Co., Ltd. 18
19. 次の課題（積み残し） 1. 「移しただけで、減ってはいない」総量 （時間‧レビュー） → 次はこの総量をどう削るか 2. レビューが上流に寄った結果、仕様レビューが新たに混む（上流の渋滞） 3. 固まった仕様から、テスト作成を軽くしていく →AIに任せられる部分が増える #RAKUSMeetup © RAKUS Co., Ltd. 19
20. 設計フェーズを、どう軽くするか 出発点 メンバーの声「設計フェーズが⼤変」 処⽅箋 ― モブレビューの“前段”にループ∕ハーネスを当てる ⽣成役と検証役を分け、機械が拾える考慮漏れはモブの前に潰す ただし、モブそのものは残す ⼈を育てる場であり、テックリードが全部⾒なくてもメンバー間でレビューが回る場 → ⾃動化するのは「⽣成の負荷」、残すのは「⼈間の判断と育成」 #RAKUSMeetup © RAKUS Co., Ltd. 20
21. AI時代の役割 ― ループエンジニアリングへの接続 • 「ループエンジニアリング」：プロンプトを打つ“⼈”から降り、回す“仕組み”を 設計する （Boris Cherny ∕ Addy Osmani, 2026） • 提唱者いわく「楽になったのではなく、レバレッジの効く点が移っただけ」 • ループが回るには、先に「何が正解か（＝仕様）」が要る → ループの時代が来るほど、その前段＝“仕様を決める⼒”の価値が上がる （今後の展望）予測可能性＝AIに安全に任せられる範囲 → ループ範囲を広げ、⼈の介在を減らす → ボリューム拡⼤‧リードタイム短縮へ Build the loop. Stay the engineer.（ループを構築しろ。エンジニアであり続けろ。） #RAKUSMeetup © RAKUS Co., Ltd. 21