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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介髙橋直規（幡ヶ谷亭直吉） x:@asagayanaoki 出身：神奈川 / 居住：東京エンジニア歴：18年9ヶ月役割：PjM、PdE 出身大学のある街：表参道思い出の映画館：ヒューマントラストシネマ渋谷好きなレコード屋：ハイファイ・レコード・ストア（神宮前）好きなバー：B.Y.G（道玄坂）土日の過ごし方：6歳の娘ととにかく遊ぶ

Slide 3

Slide 3 text

本日お話すること • 短納期・PO多忙・解散前提の開発でも「意味のあるスクラム」ができるのか • AI駆動開発を “育てていく”という適応 • コミュニティの可能性

Slide 4

Slide 4 text

アジェンダ • STEP1：制約の多い新規プロダクト開発 • STEP2：転換 • STEP3：適応の実践 • まとめ

Slide 5

Slide 5 text

STEP1: 制約の多い新規プロダクト開発

Slide 6

Slide 6 text

この話はどんな開発現場の話かスクラムで進めているプロダクトの開発チームから離れ、新しいチームで新規プロダクトのための開発がスタート。 STEP1：制約の多い新規プロダクト開発

Slide 7

Slide 7 text

この話はどんな開発現場の話かスクラムで進めているプロダクトの開発チームから離れ、新しいチームで新規プロダクトのための開発がスタート。短納期、PO多忙、解散前提という制約条件にスクラムでの開発を進めるべきか悩んでいた。 STEP1：制約の多い新規プロダクト開発

Slide 8

Slide 8 text

この話はどんな開発現場の話かスクラムで進めているプロダクトの開発チームから離れ、新しいチームで新規プロダクトのための開発がスタート。短納期、PO多忙、解散前提という制約条件にスクラムでの開発を進めるべきか悩んでいた。開発チームが組成される前から画面デザインは検討され、 AI駆動開発で従来開発より生産性が高いことの証明も求められていた。 STEP1：制約の多い新規プロダクト開発

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

STEP1：制約の多い新規プロダクト開発

Slide 12

Slide 12 text

STEP1：制約の多い新規プロダクト開発いっそウォーターフォールでフィーチャーファクトリーにふりきった方がいいんじゃ…

Slide 13

Slide 13 text

STEP1：制約の多い新規プロダクト開発

Slide 14

Slide 14 text

STEP2：転換

Slide 15

Slide 15 text

10/8 渋谷アジャイル #15 参加悩みを抱える中、渋谷アジャイル#15に参加。いつもは気後れしてOSTでテーマを出したことがなかったが、悩みを解消したくて、「短納期 PO多忙リリース後解散スクラム？」というテーマを提出。 STEP2：転換

Slide 16

Slide 16 text

10/8 渋谷アジャイル #15 参加悩みを抱える中、渋谷アジャイル#15に参加。いつもは気後れしてOSTでテーマを出したことがなかったが、悩みを解消したくて、「短納期 PO多忙リリース後解散スクラム？」というテーマを提出。自分の悩みを言語化することで、改めて自分のもやもやを整理できた。 STEP2：転換

Slide 17

Slide 17 text

10/8 渋谷アジャイル #15 参加悩みを抱える中、渋谷アジャイル#15に参加。いつもは気後れしてOSTでテーマを出したことがなかったが、悩みを解消したくて、「短納期 PO多忙リリース後解散スクラム？」というテーマを提出。自分の悩みを言語化することで、改めて自分のもやもやを整理できた。少なくない方たちが悩みを聞いてくださり、当初想定していなかった気づきに着地できた。 STEP2：転換

Slide 18

Slide 18 text

STEP2：転換私がスクラムで進めるにあたり抱えていたもやもや • PO多忙 • リリース後解散 • 短納期

Slide 19

Slide 19 text

STEP2：転換・PO多忙 ✓作りたい画面が先に決まっている ✓デザイナーさんの方が作りたいシステムを知ってる ✓開発者はそれを実現する役割になる不安 ✓POと一緒にどう作るか考える時間があるか不安 ☞プロダクト視点でスクラムに目的意識が持てない

Slide 20

Slide 20 text

STEP2：転換・リリース後解散 ✓近い将来に解散が見えてるチームの成長は必要？ ✓作るものが決まってる中で認知を合わせる？ ✓リリース後受け取るチームに丸投げにならないか ☞チーム視点でスクラムに目的意識が持てない

Slide 21

Slide 21 text

STEP2：転換・短納期 ✓スクラムはイベントに時間がかかる ✓その時間はプロダクトやチームのためと思ってる ✓果たしてスクラムが最適解なのか ☞ウォーターフォールの方が適してる気がする

Slide 22

Slide 22 text

STEP2：転換 PO多忙リリース後解散短納期プロダクト視点の不安チーム視点の不安スクラムへの不安

Slide 23

Slide 23 text

STEP2：転換 OSTでいただいた言葉 • AI駆動のプロセスそのものを育てていくのはどうか ✓AIだからこそ言語化が必要 ✓言語化したドキュメントを残していける ✓ドキュメントごとの要不要は人の判断が重要になる ✓人に依存せずAI駆動を持続可能にするのはどうか ☞AI駆動開発を持続可能にするためのスクラム

Slide 24

Slide 24 text

STEP2：転換プロダクトチームプロセスプロダクトの持続的な成長を実現できる人に依存しない AI駆動開発を実現していくチームが解散しても継続して安定した開発を進めていける

Slide 25

Slide 25 text

STEP2：転換プロダクトチームプロセスプロダクトの持続的成長を実現できる人に依存しない AI駆動開発を実現していくチームが解散しても継続して安定した開発を進めていける再現性の高いAI駆動開発を育てることにスクラムの目的を再定義できた

Slide 26

Slide 26 text

STEP2：転換いっそウォーターフォールでフィーチャーファクトリーにふりきった方がいいんじゃ…

Slide 27

Slide 27 text

STEP2：転換

Slide 28

Slide 28 text

STEP2：転換まだまだスクラムにオーナーシップが持てる！！

Slide 29

Slide 29 text

STEP3：適応の実践

Slide 30

Slide 30 text

STEP3：適応の実践 SP1 SP2 SP3 組織横断の協力・勉強会現在現在4スプリント目突入（プロジェクト中盤）プロジェクト開始以来、AI駆動開発を使いこなすための施策を実施。 SP4 テスト仕様書の自動生成複雑な機能に対する前準備仕様共有会 AI実践共有

Slide 31

Slide 31 text

STEP3：適応の実践 AI駆動開発を始めるにあたり行ったこと。・組織横断の協力・勉強会 AI駆動開発に知見のある別組織との連携を開始。今まで出来ていなかった案件・組織を越えた課題や知見を共有できる場を実現。・テスト仕様書の自動生成チームのテスト仕様書作成の学習コストを低減するために、結合テスト・業務シナリオテスト仕様書の自動生成を実現。短時間で7割程度の完成度の仕様書の作成を実現。

Slide 32

Slide 32 text

STEP3：適応の実践 AI駆動開発の速さを継続するために始めたこと。・複雑な機能に対する前準備システム間で連携する機能や、複雑なデータ制御が必要な機能は、開発がスムーズに進行できるように、前もって仕様策定を実施。検討した仕様が属人化や自チームだけの知識にとどまらないようすりあわせを重視。

Slide 33

Slide 33 text

STEP3：適応の実践 AI駆動開発にオーナーシップを持つために始めたこと。・仕様共有会 AIが実装した機能でも人間がオーナーシップを持てるために、開発完了後に担当者が機能の紹介とデモをするミーティングを開催。早期の認識のズレの検知も実現。・AI実践共有 AIを使いうまくいったこと／いかなかったことをSlackで随時共有。特にうまくいかなかったことを改善の余地として重視。その内容から適宜AIの使い方を改善できるように推進。

Slide 34

Slide 34 text

STEP3：適応の実践検査人に主軸を置いた開発の進め方や成果の定期確認 ✓仕様共有会の実施 ✓AI実践共有 ✓複雑な機能に対する前準備透明性 AI駆動開発のプロセス・成果をオープンに共有 ✓仕様共有会の実施 ✓AI実践共有適応 AIの速度に合わせたプロセスや取り組みの刷新 ✓組織横断の協力・勉強会 ✓テスト仕様書の自動生成 ✓複雑な機能に対する前準備新しい実践はスクラムの3本柱に繋がっていた。

Slide 35

Slide 35 text

STEP3：適応の実践 AI駆動開発に対する新たな課題も見えてきている。・開発速度による理解負債の増加の懸念細かいコードレベルでの理解が追いつきにくい。開発時は他メンバーとの会話より、AIとの会話が多いため属人化も懸念。・スピードゆえの「やりたいこと」の取りこぼし速く進む開発ゆえに、チャレンジの機会を失う速度も速い。エンジニア成長のための挑戦機会を見失いがち。・機能実装に偏重しがちアウトプットの出しやすさによって機能実装に意識が偏る。予定より早く実装が終わると次の実装に手を付ける傾向。

Slide 36

Slide 36 text

STEP3：適応の実践そうした新しい課題にも適応できると思っている。・開発速度による理解負債の増加の懸念重要機能はAI駆動での開発は行わず、仕様策定までをKiro、実装はCopilotとの伴走型での開発など切り替える。・スピードゆえの「やりたいこと」の取りこぼしアウトプット量の増加を目的にせず、各メンバーの成長の価値を重視できる文化を作る。・機能実装に偏重しがち敢えてスプリントごとのアウトプットの上限を作り、機能実装以外の価値に繋がる行動を採択できるようにする。

Slide 37

Slide 37 text

STEP3：適応の実践そうした新しい課題にも適応できると思っている。・開発速度による理解負債の増加の懸念重要機能はAI駆動での開発は行わず、仕様策定までをKiro、実装はCopilotとの伴奏型での開発など切り替える。・スピードゆえの「やりたいこと」の取りこぼしアウトプット量の増加を目的にせず、各メンバーの成長の価値を重視できる文化を作る。・機能実装に偏重しがち敢えてスプリント毎のアウトプットの上限を作り、機能実装以外の価値に繋がる行動を採択できるようにする。新しい課題にもスクラムで適応していける

Slide 38

Slide 38 text

STEP3：適応の実践当初自分が頭を抱えていた課題はどうなったのか。 PO多忙解散前提短納期 ✓忙しいけど会話はできる ✓プロダクトの姿は見直していける ✓個々人の成長に繋がる発見はある ✓チームは能動的に成長していく ✓AI駆動開発の速さで考えると短くない ✓人間がコントロールしていくことが重要

Slide 39

Slide 39 text

STEP3：適応の実践当初自分が頭を抱えていた課題はどうなったのか。 PO多忙解散前提短納期 ✓忙しいけど会話はできる ✓プロダクトの姿は見直していける ✓個々人の成長に繋がる発見はある ✓チームは能動的に成長していく ✓AI駆動開発の速さで考えると短くない ✓人間がコントロールしていくことが重要自分たちの開発にオーナーシップを持って取り組めているからこそ気づけた

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめこれまでは、スクラムの目的を「プロダクトの価値実現」や「チーム成長」を対象に考えていました。ただ、AI駆動開発のプロセスを磨いていくこと自体が、長期的なプロダクト価値の向上や、組織としての変化への適応力の向上につながることに気がつきました。プロダクトの価値チーム成長プロセス成熟／適応力

Slide 42

Slide 42 text

まとめこうした視点の転換や気づきは、自分の環境だけでは得られなかったかもしれません。今回、渋谷アジャイルでの対話のおかげで気づくことができました。コミュニティの重要性を改めて実感しました。

Slide 43

Slide 43 text

No content