■ 1. AI活用の裏で払っていたもの
- 対象チームの体制:
- 楽楽精算のモバイルアプリをiOS、Android、バックエンド、フロントエンドの複数プラットフォームで開発
- エンジニア6名がアジャイルの2週間スプリントで開発
- 実装スピードの向上:
- ここ1〜2年でAI活用が本格化し、個人の実装スピードは体感としても数字としても向上
- コードを書く作業は以前ほど開発のボトルネックではない
- AI活用の裏で起きた3つの問題:
- 意図のよく分からないコードが混ざるようになった
- レビューの負荷に偏りが出るようになった
- テストフェーズになって初めて考慮漏れに気づく事故が多発した
- 後工程での発覚は高コスト:
- 設計段階で気づかず後工程で発覚するほど、修正のコストは高くつく
- 出発点となった問い:
- 早くはなったが、何か別のものを払っている感覚があった
- AIで早くなった裏で本当は何を払っていたのか、という問いが生まれた
■ 2. 仕様駆動開発の導入経緯
- 飛びついたのが実態:
- 慎重に比較検討して選んだというより、飛びついたという感覚の方が実態に近い
- 出発点はAI設計テンプレート:
- 手で書いていた設計書をAIに書かせて時短できないかという試みが最初
- 1ヶ月ほど地道に作り込んでいた
- ちょうどそこに仕様駆動開発という言葉が流行り始め、自分がやりたかったものだと認識
- Planモードを選ばない理由:
- AIがタスクを組んでくれる点は便利だが、結局は使うエンジニア個人の能力に依存する
- その点で直接指示と本質的に変わらない
- TDDを選ばない理由:
- リファクタリングには強いが、そもそも仕様がブレていればテスト自体が空中分解する
- 仕様を中心に据える理由:
- Planモードの質もTDDのテストの質も、たどっていくと結局は仕様に行き着く
- 一番上流の仕様そのものを中心に据えるのが筋が良い
- 具体的な運用:
- マークダウンで構造化した自然言語の仕様書を使用
- 設計そのものをPRとしてレビューする
- 自然言語成果物のコスト:
- コードのようなリンターもテストも効かない
- 問題ないと判断するにはしっかり読む必要があり、コストがかかる
- 仕様の構造化や重複削減という地味なチューニングを今も積み重ねている最中
■ 3. 検証に踏み切った理由
- 上司からのツッコミ:
- それは本当に早くなっているのか
- 設計に時間をかけている分、トータルで遅くなっているのではないか
- メンバーからのツッコミ:
- 設計フェーズが大変になった
- 一番頭を使う部分が重くなった
- 感覚では説得力がない:
- 感覚で早くなっていると返しても説得力がない
- 1年分のデータを本気で掘り返して検証することにした
- SDD導入の当初の狙い:
- 品質のために入れたわけではない
- 実装を誰がやっても同じ質にして属人性をなくすことが狙いだった
- 検証結果は当初の狙いとは別のところで驚きをもたらした
- 検証の前提:
- AIもアジャイルも定着した時期以降のデータに絞り、フェアな比較を心がけた
■ 4. 指標1: 時間
- 実装フェーズの数字は確かに速くなっていた
- 速さの正体:
- 後工程にあった意思決定の負荷が、設計フェーズに前倒しされただけ
- 具体例となる実装方針の選択:
- SDD以前は複数ある実装方針のどれを採用するかを実装しながら決めることもあった
- 現在はその判断を設計のタイミングで行う
- AIによる負荷軽減の限界:
- AIが選択肢を出してくれる分、考えるのが楽になった場面はある
- 最終的にどれにするかを人間が決め、レビューやステークホルダーの合意を得る必要がある点は変わらない
- SDD自体は時短策ではない
■ 5. 指標2: レビュー
- コメント数は横ばい:
- 1つのPRあたりの他者からのコメント数は中央値がずっと1でほぼ横ばい
- レビューの総量そのものは減っていない
- 中身の変化:
- 実装PRでこの仕様はどうなっているのかという揉め事が減った
- その議論が仕様レビューの場に前倒しされた
- 狙い通りだが楽ではない:
- レビューが純粋なコード品質チェックに近づいた意味では狙い通り
- 楽になったのではなく、議論する場所が移ったというのが実態に近い
■ 6. 指標3: バグ
- バグの発生件数そのものは劇的には変わっていない
- 対応時間の短縮:
- 1件あたりの対応時間が17時間から11時間に短縮
- 対応時間は着手からテスト完了までのリードタイムを指す
- 振れ幅の縮小:
- 以前は1スプリントで20件を超えるバグの大爆発が起きることがあった
- 現在は最大でも8件程度に収まる
- 事故の数ではなく、事故の振れ幅が小さくなった
- 数字の限界:
- 集計はテストまで完了したスプリントのみを対象としており、サンプル数はまだ多くない
- 断定ではなく傾向として見るべき
■ 7. SDDの本当の成果は予測可能性
- 3つの指標の共通点:
- 時間もレビューも内容が移っただけで総量は変わらない
- バグは件数こそ横ばいながら振れ幅が縮んだ
- 成果は速さではない:
- 開発そのもののスピードは、AIをガムシャラに使っていた1年前とほとんど変わらない
- 得られたのは予測可能性
- 以前ガムシャラに速度を出していた頃、代わりに払っていたのがこの予測可能性
- 怖いのは件数が読めないこと:
- バグ修正にかかる時間そのものより、何件出るか読めないことが怖い
- 計画が崩れる具体例:
- 2週間スプリントの7日目まで予定通り進み、残業もせず帰れていたとする
- テストでバグがたくさん出ると、残り数日で焦って対応するか別スプリントに送るかの判断に迫られる
- その結果、計画が崩れる
- 計画が計画として機能する:
- 仕様の検討が上流に寄った結果、予想外の大爆発が起きにくくなった
- 平均的な件数は大きく変わらなくても、最悪のケースが消えて振れ幅が縮んだ
- 顧客価値の土台:
- 事故で開発が止まらないことは、顧客に安定したペースで価値を届け続けられることを意味する
- 予測可能性は顧客への価値提供の土台でもある
■ 8. 速さの出方の変化
- SDDは時短の手法ではなく、決めごとの総量も変わらない
- 品質と予測可能性への投資:
- 実装スピードそのものは変わらなくても、速さの出方が変わった
- 昔は事故が起きるかどうか読めないまま勢いで速度を出していた
- 今は上流で足場を固めてから、同じ速度を読める形で出している
- アジャイルは維持:
- アジャイルを捨てたわけではない
- 2週間スプリントという枠のなかで決める位置を前にずらしただけ
■ 9. 残る課題
- 総量削減は宿題:
- 時間もレビューも総量は移っただけで減ってはいない
- 総量そのものをどう減らすかは未解決
- 新しいボトルネック:
- レビューを上流に寄せた結果、今度は仕様レビューの方が渋滞するようになった
- 設計フェーズの負荷の実体:
- 大変なのは仕様書を作ったあとのモブレビューではない
- 個人がローカルで仕様を練っている前段階が最も頭を使う
■ 10. 今後の打ち手
- テスト作成への接続:
- 仕様が設計段階で固まることで、そこからテストを作るのも楽になる
- 固まった仕様を起点にすれば、テスト設計やユニットテストを考える時間も減る
- AIに任せられる部分も増えるため、この接続を今まさに模索している
- ループとハーネスの適用:
- 個人が仕様を練る段階にループやハーネスといった仕組みを当てはめる
- 機械的に拾える考慮漏れはモブレビュー前に潰しておきたい
- モブレビューは残す:
- モブレビューは人を育てる場である
- テックリード一人がすべてをレビューしなくても、メンバー同士でレビューが回る効果がある
- 自動化の線引き:
- 自動化するのは生成の負荷にあたる部分
- 人間の判断や育成の機会は残す
■ 11. ループエンジニアリングと仕様を決める力
- ループエンジニアリング:
- 海外のAI開発ツールの責任者は、もうAIに指示は出しておらず自分の仕事はループを書くことだと語る
- レバレッジ点の移動:
- 提唱者とされる人物は、仕事が簡単になったのではなくレバレッジの効く点が移っただけだと釘を刺す
- これは決める場所が上流に移っただけという今回の検証結果と驚くほど重なる
- 全自動化の限界:
- 全部を自動ループに任せればプロダクトの品質は落ちる
- ループは何が正解かの判断までは代わってくれない
- 仕様を決める力の価値:
- 何が正解かを上流ではっきりさせるのがまさにSDD
- ループの時代が来るほど、その前段にある仕様を決める力の価値は上がる
- 開発をAIに委ねても、何が正解かを決めるカロリーだけは人間に残る
■ 12. 予測可能性は自動化の足場
- 任せられる範囲の可視化:
- 予測可能性が手に入ることは、AIに安全に任せられる範囲が見えてくることでもある
- 読めないものは任せられないが、振れ幅が小さく読めるものなら任せられる
- リードタイム短縮の展望:
- 任せる範囲を安全に広げていけば、いずれボリュームが増える
- トータルのリードタイムも縮んでいくはず
- 予測可能性の位置づけ:
- 手に入れた予測可能性は、その先の自動化を安全に広げるための足場
■ 13. 終わりに
- 時短にはなっておらず、新しいボトルネックも生まれた
- 数字と向き合う姿勢:
- 正直に数字と向き合う姿勢そのものが、AIネイティブな開発組織のリアル
- なんとなく速くなった気がするで終わらせず、データで自分たちの仮説を裏切る勇気を持てるかが問われる