スクラムの適応の可能性 AI駆動開発にオーナーシップを持つ / 20251210 Naoki Takahashi

2025/12/10 渋谷アジャイル@スタートアップ#17
https://shibuyagile.connpass.com/event/372160/

株式会社SHIFT
製造ソリューションサービス部
髙橋 直規

Transcript

1. スクラムの適応の可能性 AI駆動開発にオーナーシップを持つ #shibuyagile 髙橋直規 株式会社SHIFT 2025.12.10 渋谷アジャイル@スタートアップ#17 Copyright SHIFT Inc, All Rights Reserved.
2. 自己紹介 髙橋直規（幡ヶ谷亭直吉） x:@asagayanaoki 出身：神奈川 / 居住：東京 エンジニア歴：18年9ヶ月 役割：PjM、PdE 出身大学のある街：表参道 思い出の映画館：ヒューマントラストシネマ渋谷 好きなレコード屋：ハイファイ・レコード・ストア（神宮前） 好きなバー：B.Y.G（道玄坂） 土日の過ごし方：6歳の娘ととにかく遊ぶ
3. 本日お話すること • 短納期・PO多忙・解散前提の開発でも「意味のあるスクラム」ができるのか • AI駆動開発を “育てていく”という適応 • コミュニティの可能性
4. アジェンダ • STEP1：制約の多い新規プロダクト開発 • STEP2：転換 • STEP3：適応の実践 • まとめ
5. STEP1: 制約の多い新規プロダクト開発
6. この話はどんな開発現場の話か スクラムで進めているプロダクトの開発チームから離れ、 新しいチームで新規プロダクトのための開発がスタート。 STEP1：制約の多い新規プロダクト開発
7. この話はどんな開発現場の話か スクラムで進めているプロダクトの開発チームから離れ、 新しいチームで新規プロダクトのための開発がスタート。 短納期、PO多忙、解散前提という制約条件に スクラムでの開発を進めるべきか悩んでいた。 STEP1：制約の多い新規プロダクト開発
8. この話はどんな開発現場の話か スクラムで進めているプロダクトの開発チームから離れ、 新しいチームで新規プロダクトのための開発がスタート。 短納期、PO多忙、解散前提という制約条件に スクラムでの開発を進めるべきか悩んでいた。 開発チームが組成される前から画面デザインは検討され、 AI駆動開発で従来開発より生産性が高いことの証明も求められていた。 STEP1：制約の多い新規プロダクト開発
9. この話はどんな開発現場の話か スクラムで進めているプロダクトの開発チームから離れ、 新しいチームで新規プロダクトのための開発がスタート。 短納期、PO多忙、解散前提という制約条件に スクラムでの開発を進めるべきか悩んでいた。 開発チームが組成される前から画面デザインは検討され、 AI駆動開発で従来開発より生産性が高いことの証明も求められていた。 ChatGPTに悩みを打ち明けても想定の答えが返ってくるだけだった。 STEP1：制約の多い新規プロダクト開発
10. この話はどんな開発現場の話か スクラムで進めているプロダクトの開発チームから離れ、 新しいチームで新規プロダクトのための開発がスタート。 短納期、PO多忙、解散前提という制約条件に スクラムでの開発を進めるべきか悩んでいた。 開発チームが組成される前から画面デザインは検討され、 AI駆動開発で従来開発より生産性が高いことの証明も求められていた。 ChatGPTに悩みを打ち明けても想定の答えが返ってくるだけだった。 STEP1：制約の多い新規プロダクト開発
11. STEP1：制約の多い新規プロダクト開発
12. STEP1：制約の多い新規プロダクト開発 いっそウォーターフォールで フィーチャーファクトリーに ふりきった方がいいんじゃ…
13. STEP1：制約の多い新規プロダクト開発
14. STEP2：転換
15. 10/8 渋谷アジャイル #15 参加 悩みを抱える中、渋谷アジャイル#15に参加。 いつもは気後れしてOSTでテーマを出したことがなかったが、 悩みを解消したくて、 「短納期 PO多忙 リリース後解散 スクラム？」というテーマを提出。 STEP2：転換
16. 10/8 渋谷アジャイル #15 参加 悩みを抱える中、渋谷アジャイル#15に参加。 いつもは気後れしてOSTでテーマを出したことがなかったが、 悩みを解消したくて、 「短納期 PO多忙 リリース後解散 スクラム？」というテーマを提出。 自分の悩みを言語化することで、 改めて自分のもやもやを整理できた。 STEP2：転換
17. 10/8 渋谷アジャイル #15 参加 悩みを抱える中、渋谷アジャイル#15に参加。 いつもは気後れしてOSTでテーマを出したことがなかったが、 悩みを解消したくて、 「短納期 PO多忙 リリース後解散 スクラム？」というテーマを提出。 自分の悩みを言語化することで、 改めて自分のもやもやを整理できた。 少なくない方たちが悩みを聞いてくださり、 当初想定していなかった気づきに着地できた。 STEP2：転換
18. STEP2：転換 私がスクラムで進めるにあたり抱えていたもやもや • PO多忙 • リリース後解散 • 短納期
19. STEP2：転換 ・PO多忙 ✓作りたい画面が先に決まっている ✓デザイナーさんの方が作りたいシステムを知ってる ✓開発者はそれを実現する役割になる不安 ✓POと一緒にどう作るか考える時間があるか不安 ☞プロダクト視点でスクラムに目的意識が持てない
20. STEP2：転換 ・リリース後解散 ✓近い将来に解散が見えてるチームの成長は必要？ ✓作るものが決まってる中で認知を合わせる？ ✓リリース後受け取るチームに丸投げにならないか ☞チーム視点でスクラムに目的意識が持てない
21. STEP2：転換 ・短納期 ✓スクラムはイベントに時間がかかる ✓その時間はプロダクトやチームのためと思ってる ✓果たしてスクラムが最適解なのか ☞ウォーターフォールの方が適してる気がする
22. STEP2：転換 PO多忙 リリース後解散 短納期 プロダクト視点 の不安 チーム視点 の不安 スクラムへの 不安
23. STEP2：転換 OSTでいただいた言葉 • AI駆動のプロセスそのものを育てていくのはどうか ✓AIだからこそ言語化が必要 ✓言語化したドキュメントを残していける ✓ドキュメントごとの要不要は人の判断が重要になる ✓人に依存せずAI駆動を持続可能にするのはどうか ☞AI駆動開発を持続可能にするためのスクラム
24. STEP2：転換 プロダクト チーム プロセス プロダクトの 持続的な成長を 実現できる 人に依存しない AI駆動開発 を実現していく チームが解散しても 継続して安定した 開発を進めていける
25. STEP2：転換 プロダクト チーム プロセス プロダクトの 持続的成長を 実現できる 人に依存しない AI駆動開発 を実現していく チームが解散しても 継続して安定した 開発を進めていける 再現性の高いAI駆動開発を 育てることに スクラムの目的を再定義できた
26. STEP2：転換 いっそウォーターフォールで フィーチャーファクトリーに ふりきった方がいいんじゃ…
27. STEP2：転換
28. STEP2：転換 まだまだスクラムに オーナーシップが 持てる！！
29. STEP3：適応の実践
30. STEP3：適応の実践 SP1 SP2 SP3 組織横断の協力・勉強会 現在 現在4スプリント目突入（プロジェクト中盤） プロジェクト開始以来、AI駆動開発を使いこなすための施策を実施。 SP4 テスト仕様書の自動生成 複雑な機能に対する前準備 仕様共有会 AI実践共有
31. STEP3：適応の実践 AI駆動開発を始めるにあたり行ったこと。 ・組織横断の協力・勉強会 AI駆動開発に知見のある別組織との連携を開始。 今まで出来ていなかった案件・組織を越えた 課題や知見を共有できる場を実現。 ・テスト仕様書の自動生成 チームのテスト仕様書作成の学習コストを低減するために、 結合テスト・業務シナリオテスト仕様書の自動生成を実現。 短時間で7割程度の完成度の仕様書の作成を実現。
32. STEP3：適応の実践 AI駆動開発の速さを継続するために始めたこと。 ・複雑な機能に対する前準備 システム間で連携する機能や、複雑なデータ制御が必要な機能は、 開発がスムーズに進行できるように、前もって仕様策定を実施。 検討した仕様が属人化や自チームだけの知識にとどまらないよう すりあわせを重視。
33. STEP3：適応の実践 AI駆動開発にオーナーシップを持つために始めたこと。 ・仕様共有会 AIが実装した機能でも人間がオーナーシップを持てるために、 開発完了後に担当者が機能の紹介とデモをするミーティングを開催。 早期の認識のズレの検知も実現。 ・AI実践共有 AIを使いうまくいったこと／いかなかったことをSlackで随時共有。 特にうまくいかなかったことを改善の余地として重視。 その内容から適宜AIの使い方を改善できるように推進。
34. STEP3：適応の実践 検査 人に主軸を置いた開発の 進め方や成果の定期確認 ✓仕様共有会の実施 ✓AI実践共有 ✓複雑な機能に対する 前準備 透明性 AI駆動開発のプロセス ・成果をオープンに共有 ✓仕様共有会の実施 ✓AI実践共有 適応 AIの速度に合わせた プロセスや取り組みの刷新 ✓組織横断の協力・勉強会 ✓テスト仕様書の自動生成 ✓複雑な機能に対する 前準備 新しい実践はスクラムの3本柱に繋がっていた。
35. STEP3：適応の実践 AI駆動開発に対する新たな課題も見えてきている。 ・開発速度による理解負債の増加の懸念 細かいコードレベルでの理解が追いつきにくい。 開発時は他メンバーとの会話より、AIとの会話が多いため属人化も懸念。 ・スピードゆえの「やりたいこと」の取りこぼし 速く進む開発ゆえに、チャレンジの機会を失う速度も速い。 エンジニア成長のための挑戦機会を見失いがち。 ・機能実装に偏重しがち アウトプットの出しやすさによって機能実装に意識が偏る。 予定より早く実装が終わると次の実装に手を付ける傾向。
36. STEP3：適応の実践 そうした新しい課題にも適応できると思っている。 ・開発速度による理解負債の増加の懸念 重要機能はAI駆動での開発は行わず、 仕様策定までをKiro、実装はCopilotとの伴走型での開発など切り替える。 ・スピードゆえの「やりたいこと」の取りこぼし アウトプット量の増加を目的にせず、 各メンバーの成長の価値を重視できる文化を作る。 ・機能実装に偏重しがち 敢えてスプリントごとのアウトプットの上限を作り、 機能実装以外の価値に繋がる行動を採択できるようにする。
37. STEP3：適応の実践 そうした新しい課題にも適応できると思っている。 ・開発速度による理解負債の増加の懸念 重要機能はAI駆動での開発は行わず、 仕様策定までをKiro、実装はCopilotとの伴奏型での開発など切り替える。 ・スピードゆえの「やりたいこと」の取りこぼし アウトプット量の増加を目的にせず、 各メンバーの成長の価値を重視できる文化を作る。 ・機能実装に偏重しがち 敢えてスプリント毎のアウトプットの上限を作り、 機能実装以外の価値に繋がる行動を採択できるようにする。 新しい課題にも スクラムで適応していける
38. STEP3：適応の実践 当初自分が頭を抱えていた課題はどうなったのか。 PO多忙 解散前提 短納期 ✓忙しいけど会話は できる ✓プロダクトの姿は 見直していける ✓個々人の成長に 繋がる発見はある ✓チームは能動的に 成長していく ✓AI駆動開発の速さで 考えると短くない ✓人間がコントロール していくことが重要
39. STEP3：適応の実践 当初自分が頭を抱えていた課題はどうなったのか。 PO多忙 解散前提 短納期 ✓忙しいけど会話は できる ✓プロダクトの姿は 見直していける ✓個々人の成長に 繋がる発見はある ✓チームは能動的に 成長していく ✓AI駆動開発の速さで 考えると短くない ✓人間がコントロール していくことが重要 自分たちの開発に オーナーシップを持って 取り組めているからこそ気づけた
40. まとめ
41. まとめ これまでは、スクラムの目的を 「プロダクトの価値実現」や「チーム成長」を対象に考えていました。 ただ、AI駆動開発のプロセスを磨いていくこと自体が、 長期的なプロダクト価値の向上や、 組織としての変化への適応力の向上につながることに気がつきました。 プロダクト の価値 チーム成長 プロセス成熟 ／適応力
42. まとめ こうした視点の転換や気づきは、 自分の環境だけでは得られなかったかもしれません。 今回、渋谷アジャイルでの対話のおかげで気づくことができました。 コミュニティの重要性を改めて実感しました。