AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI

https://algomatic.connpass.com/event/401977/

こちらの登壇資料です。

Transcript

1. AIを上手に使っていこうとしたら 越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 2026.09.01 現場で効いたAI駆動開発の実践知 ― 越境を支える体制と仕組みづくり KDDIアジャイル開発センター 北浦 智也
2. 自己紹介 北浦 智也（@kitta0108） KDDIアジャイル開発センター リードSRE 勉強会の運営 JAWS-UG SRE支部 JAWS-UG コンテナ支部 NRUG SRE支部 Observability Conf Tokyo 著書 俺たちのSREとNew Relic KAG Tech Book Vol1 2
3. 今日のお話 2025年7月、Claude Code を全面導入してちょうど1年 AIをうまく使おうと試行錯誤していただけなのに、 気づいたらチームの動き方そのものも随分と変化しました 振り返れば自分たちの守備範囲も広がったように思います 本日の勉強会のテーマは 「越境を支える体制と仕組みづくり」 ですね 越境しようとしたのではなく、支える仕組みを作っていたら越境していた そのテーマに沿って、とあるバックエンドAPIサービスの開発チーム体験談をお話しします 3
4. 今日のゴール AI駆動開発が「良い文化」の醸成として機能した一例 として聞いていただけたらと思います 「これ、うちのチームでもやってみようか」 そう思って現場に持ち帰る動きにつながったら、いちばん嬉しいです 4
5. AI以前から、こんな構図がありました 5
6. よく見る光景 開発者 POさん、要件まだ出せませんか？ このアプリケーションを動かすインフラ考えてください インフラエンジニア バックエンド この障害、インフラは問題ありません 6
7. どれも同じ前提から出ている 「隣の工程は自分の仕事じゃない」 責務分離の観点、そして自分の守備範囲を守るという側面もある これ自体は自分の責任範囲を確実に全うするためという至極真っ当な思いで遂行されるもの 一方で、全体最適や何かの変革を行おうとする中では悪さをすることが多い 任せられた責務を全うしつつ、自分の範囲から脱することも求められているのでは 7
8. 例えば設計・実装だけ速くしても、 全体から見たデリバリーの貢献は薄い 要件定義 設計・実装 テスト AI導入前 デリバリー AIの力で AI導入後 デリバリー 太く早くした 短縮できたのは ここだけ 8
9. AI時代でも、ここにメスを入れないと大きな変化は期待で きない 構図を変えずにAIを入れても、非生産的なまま むしろ、一部の工程が高速化された今だからこそ 恩恵を受けた人は、隣の工程を手伝い、 より広い範囲に貢献できる 9
10. この状況の改善に寄与したと 考えられる2つの取り組み ① AI-DLC ― 開発プロセスの全体像 ② 仕様駆動開発 ― Construction の中身 10
11. 取り組み① AI-DLC 11
12. スクラムから移行した 開発プロセスそのものを、スクラムから AI-DLC に移行 Inception → Construction → Operation 作るものを決める 実装可能なレベルまで詰めて作る 運用する ※本日は Inception と Construction に絞って解説します AI-DLC Whitepaper：https://prod.d13rzhkk8cj2z0.amplifyapp.com/ 12
13. Inception ― 曖昧な要件を「作るもの」に変える 出発点は、まだ抽象度が高く曖昧な要件 「利用者にメールを送りたい」 これをシステムの振る舞いとして、 どのような条件で・どのような設計で実装するかまで整理し、 チーム内で合意する 13
14. Inception の位置づけ もともとスクラムのリファインメントで 整理していたものを、独立した一つのタスクとして切り出したもの リファインメントの時間でやっていた要件整理を、 一つのタスクにして、より多くの時間を使うようにした 「利用者にメールを送る要件のインセプション」これが一つのバックログチケットとして管理 される Tips：判断に必要な人が、その場に集まるようにしている PO やステークホルダーをモブに招き、AIを使って意思決定を行う。「待つ」から「呼ぶ」へ 14
15. Inception の設計は「大枠の叩き」 「この設計なら要求を叶えられるだろう」 というレベルまで Lambda を使う / SQS を使う DB は DynamoDB / ER はこんな形 アプリケーションのロジック、メモリ・CPU スペック、テスト戦略は Construction で詰める 15
16. Inception の成果物 Inception でまとめたドキュメント（md ファイル） drawio の構成図 OpenAPI 仕様書 Construction のバックログチケット バックログチケットは自分たちが実装しやすい粒度で整理し、 実装順もここで決める 16
17. ここまでで一度、全体像を ━━ Inception ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 曖昧で抽象度の高い要件 ↓ 優先度の高いものを【人間】が決める 作るものを決める ── 判断に必要な人が集まり【人間】が合意する ↓ 成果物：設計md / drawio / OpenAPI / バックログ（実装順つき） ━━ Construction ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ↓ プランニングで優先度の高いものから【人間】がアサイン 詳細設計 ───── 設計mdを参照し【人間】がAIと詰める ↓ 実装 ─────── 【AI】が実装する ↓ レビュー ───── 【人間】がレビューし、【AI】もレビューする ↓ テスト ────── 【AI】が各種テストを実行し、【人間】が監督する ↓ デリバリー この詳細設計の詰め方が、次に話す仕様駆動開発です 17
18. 取り組み② 仕様駆動開発 18
19. 基本姿勢 ― AIは「増幅器」である AIは与えられたものを増幅する装置であって、ゼロから正解を当てる装置ではない 増幅する元（目的・制約・仕様）がなければ、出力はギャンブルになる 出力がギャンブルだと、改善ができない だからこそ、正しく増幅させるもの＝仕様をしっかり作り込む 19
20. 認知を、実装より先に固定する 本来の開発は 認知（考える）→ 実装（書く） の順 AI時代はこれが 実装 → 認知 に逆転しがち AIが先に書き、人間が後から理解するという流れにしてしまうと 人間がハンドリングできなくなる 仕様駆動開発は、増幅の元になる 認知を実装より先に固定するプロセス 20
21. そこで起きたこと ― AIからWhyを問われた AIはHOWなら無限に出してくるが、WHYは一切持ってこない 受け入れ基準を1行書こうとすると、 「この機能は誰が、何のために使うのか」に答えないと手が止まる 答えられるのは、利用者目線を持っている人だけ このとき「越境しよう」とは誰も思っていない 目の前の仕様が書けないから、考えるしかなかった 21
22. 余談：良いシステム設計とは 不可逆な部分を、できるだけ小さく削り出す そこに手持ちの証拠（いま分かっている事実）を集中投下する 残りは、間違えても安く直せる形に整えておく そのためには、事業拡充の方向性やユーザーニーズを 正しく把握している必要がある 設計の話をしているつもりが、事業の話になる のは、 より本質的な議論ができている可能性が高い 22
23. 気づけば越境していた 23
24. この1年で越えた境界 開発者がPOの立場でものを考えるようになった 利用者にとってどういう機能であるべきか、を開発者が議論している PO やステークホルダーも、システムの振る舞いの議論に入ってきた 越境は開発者からの片側通行ではなかった 「そもそも作らない」判断が出るようになった やれることが増えた分、何をやらないかを決める必要が生まれた 非機能要件もWHYから決まるようになった 1,000tps を求められる機能と 10tps で十分な機能では、設計の正解が違う 未知のアーキテクチャを検討できるようになった 実装コストの大きさから取りづらかった選択肢が、現実的になった 24
25. まとめ 「隣の工程は自分の仕事じゃない」 を放置したまま AI を入れても、 一部の工程だけが速くなって、全体への貢献は薄い AI-DLC の Inception は、判断に必要な人を同じ場に集める仕組みとして機能する 仕様駆動開発 は、AI から Why を問われ続けるので、嫌でも越境しないと情報を埋めることができ ない 結果として、「越境しろ」と言われないまま、チームは越境していた AIを使うほど、ボトルネックは前や後ろに倒れる 隣の工程にどれだけ貢献できるかが、AI活用の成果を分ける 立ち上がれ！今こそ越境の時だ！ 25
26. 今日のゴール（再掲） AI駆動開発が「良い文化」の醸成として機能した一例 として聞いていただけたらと思います 「これ、うちのチームでもやってみようか」 そう思って現場に持ち帰る動きにつながったら、いちばん嬉しいです 話せていないことも多いので、懇親の場で声かけてください！！ 26