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