20年チームのアジャイル開発

昨年のスクラム祭りの某セッションで言及された20年チームの一人です。
長らく同じプロダクトの開発には携われずにいましたが、昨年からこのチームでプロダクト開発を行う機会に恵まれました！
もちろんアジャイルな開発をしています。

最初はモブで開発を進めていましたが、ほどなくソロで作業するようになりました。
デイリースクラムもプランニングもなく、明確なプロダクトオーナーもスクラムマスターもいません。

私たちのチームについては昨年のセッションでも少し語られましたが、基本的にリモートで常時ビデオ接続の「大部屋」、軽量なかんばん、今週の「人生」を含めたふりかえり、みんなで解決するお題を議論する場「立ち止まり」といった独自のリズムで、開発を続けています。

このセッションでは、そんなチームの営みを具体的にお話ししたいと思います。
また、それによってどんな日々を送っているのか、20年近く一緒に仕事をやっていると、どのようになるのか、良い面も悪い面も含めて共有したいと思います。

Transcript

1. 20年チームのアジャイル開発 小川 慎 (watti) 2026/10/24 スクラム祭り 2026
2. 小川 慎 (watti/ogawatti) アジャイル開発伴走支援 テックリード 2
3. 20年チームとは 3
4. 今回の参考文献はこちら https://speakerdeck.com/chinmo 4
10. 翌営業日に専用チャンネル誕生！ 10
11. この1年間の開発を通して観測した 20年チームをご紹介します 11
12. もう少しおさらい プラクティスなど 12
16. 20年の関わりとそれを支える仕組みによって 雑談からハードなものまで いつでも気軽に話せる状態にある 16
17. 2025年10月 モブ開始 17
18. 開発初期 認識合わせや方向性の検討でコミュニケーションが多く発生する プロダクトの狙いや対象業務・課題の理解 システムの特性から運用・保守性等を検討 課題管理、開発言語・Webフレームワーク選定 リポジトリ構築、デプロイ環境構築、CI/CD設定 基本機能の仮実装、知見の共有 18
19. お手の物 みんな何度も通った道 大部屋で好きなタイミングで声を上げる 方向性がまとまったら作業 モブの時間割は、最低限そこは開発に充てましょうくらいの意 レビューしない 必要に応じて見たり聞いたり直したりする AIにはさせておく 19
20. モブ開発 久々の言語・フレームワークでの開発だったのでノリを思い出す 初めて使う機能やサービスの知見を共有しながら作業 みんなで決めながら設定する系など 20
21. 1ヶ月でベースが構築された プロダクトバックログがある程度カンバンに並ぶ CI設定や暫定のデプロイ先構築を済ませる 基本となる機能を実装・デプロイ ネックとなりそうな課題もクリアした上で フィードバックを得られる状況が整う 21
22. 2025年11月 22
23. AIモデルによる コーディングの転換点 23
24. モブ解散！！ 24
25. そもそもコーディングにおいて モブする必要はあまりなかった モブで指摘したり教え合うみたいなことは初期だけ AIに解説させれば十分になった 25
26. モブ時間を固定化しなくても 進むくらい整った 決めなきゃいけないことは大体決めた みんなそれぞれ都合の良い時間に進めたら良い 26
27. 大部屋で話し始めたら それはもうモブ モブプログラミングをやめただけ 画面共有したらよりモブっぽいけど そもそも旧来の環境が良くなかっただけかもしれない 27
28. 2025年11月以降 28
29. 明確な時間の縛りが一つ減っただけ 月曜午後イチの立ち止まり 金曜午後イチのふりかえり (人生) 読書会×2 29
30. そう、スクラムイベントやっていません スプリント スプリントプランニング スプリントレビュー ※スクラムの用語がチャンネルに一度も現れていない 30
31. スプリントレビュー 複数のプロダクトバックログを並列に 関係者と対話しながら素早く作って試してもらい 完成に近づけていくことができれば不要 こんなことやったねは「ふりかえり」で思い出している 31
32. スプリントプランニング 関係者と短いスパンで対話し続けていれば スプリントのプランニングに意味がなくなる それよりもいつまでに何がどんな風にできていたら良いか 現実的な落とし所を対話できる方が良い 立ち止まって方向性を考えるのは「立ち止まり」でやる 32
33. 立ち止まり みんなで解決するお題に週次で向き合う 「うーん」となること 個人・チームで解決できないこと まだ輪郭がぼやけている今後の話 スプリント内で決めきれていないこと 33
34. スプリント 残っているのはもはやタイムボックスとしての役割だけかもしれない リズムとして自分たちに合う1週間 ふりかえりと立ち止まりのサイクルが決まる スプリントゴールは設けていない スプリント毎よりも関係者と何をいつまでにが大事 AIで実装が早くなったことでスプリントの長さが合わなくなっていそう 34
35. デイリースクラム = 大部屋 ゴールは存在しないしプランニングもしていない、進捗の検査もない 長めのタイムスパンの中でバックログの整理が各自で行われている 常時大部屋にいて日々改善がなされている 共有も相談も雑談もモブ作業もすべてここで行われる デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速 な意思決定を促進する。その結果、他の会議を不要にする。 これを満たしている https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf 35
36. スプリントレトロスペクティブ 以前やっていたが、色々なふりかえり手法を試し時期があった 大部屋で改善がされていくのでふりかえりの場で新たな問題は上がらない でもリズムのために区切りとしてやりたい 「『人生』を取り戻したい」 36
37. スプリントレトロスペクティブ 「人生」 「タイムライン」+「感情グラフ」を 少しシンプルにしたもの あったことの共有に振り切っている 20年チームにとって必要なのは 最早"感じよく"いることだけで そのためにやっているのかもしれない https://hurikaeri.jp/catalog/ 37
38. スクラムの"型"は維持していない https://agilejourney.uzabase.com/entry/2026/06/18/103000 38
39. 関係者と繋いでもらい、後はメンバーが自律的に動く ご近所さん(関係者) 一例 エンドユーザー 既存業務に課題を抱える⼈ 関連システムの担当者 20年チーム 業務の専⾨家 UI/UX 有識者 39
40. ※社内プロダクトであることも大きい ユーザーは自分自身や顔の思い浮かぶ誰か いつまでに何をするのかイメージしやすい 関係者とのコミュニケーションが取りやすい フィードバックは率直な意見がもらえる 40
41. そんなやり方で本当に上手くいっているの？ 41
42. DORA’s software delivery performance metrics この1年間を計測してみた 42
43. 実測値 実感とのズレはないし良さそう 失敗デプロイからの復旧時間、変更失敗率は該当なし デプロイ手戻り率1件 リードタイムは最初のコミット〜mainマージ (本番デプロイは手動のため含まない) 43
44. DORAの区分と位置 AIによって加速されたので判断が難しい 作り始めたら試してもらえるようにするまで動く傾向は強い 他の業務を抱えて実働1人月程度ならこんなもの感 44
45. デプロイ頻度・月別 デプロイが多いのは機能開発が重なった、または複雑だったところ 継続的にデプロイできている (本番環境は6月から本格稼働) 45
46. リードタイムの分布 基本は24時間以内 数日以上のものは試作やリリースタイミングを見計らっているもの 46
47. リードタイム中央値の推移 リードタイムの分布と同様、作ってすぐ出すができていそう 徐々に試作が増えてデプロイまでが伸びている (それ自体はOK) 47
48. AIとの共著と人間どうしの共著 モブプログラミングをやめたことが現れている AIとの共同コミットの方が圧倒的に多い 48
49. 参考 : mainコミット数 貢献領域は綺麗に割れている 49
50. デプロイ手戻り(N=1) 再現方法が分からず苦戦 再現したことで原因が判明 原因判明から復旧まで1時間以内 原因判明までに時間がかかったが 素早く動けていそう 50
51. DORAメトリクス的にはまぁまぁ良さそう 51
52. 大事にしているところ と僕が思うもの 52
53. 自分で判断する フィードバックをそのまま受け取らない その意図や困りごとを深掘って仮説を立てて対応する AIに言われるがままにならない 今後人間に残されるところ 自分がなぜそうしたか語れるようにする 53
54. なるべくシンプルにする そういえば読書会でもシンプリシティ読んだ できるだけルールを設けない 書き過ぎ、作り過ぎ、分解し過ぎない 負債を作らないようにして認知負荷を下げる 問題となったらすぐに改善する 54
55. 動くもので試す 早く作って早く触ってもらえるようにする 最初から完璧を求めない、改善することを前提に作る 最悪作り直したら良い、のマインド 55
56. 書いていて今更気づいたけど これめっちゃアジャイル 56
57. https://agilemanifesto.org/iso/ja/manifesto.html 57
58. このスタイルの良し悪し 58
59. 良い面 めちゃくちゃアジャイル AIによって高速になった開発に適している 改善が週次を待たずその場で回る フィードバックが直接届く チームに対して圧倒的な安心感と信頼感 チームのことにあれこれ悩まない 59
60. 悪い面 大部屋は いなかった人にとって不透明 集中できないかもしれない メンバーが変わらない その上、人を選ぶ タックマンモデルの散会期が近い 60
61. 思ってたのと違ったこと 開発が難しくてもっと悩むと思っていた 実装面でコラボレーションがもっとあると思っていた AIの進化の速度が予想以上だった 自分達の開発スタイルやマインドを大きく変えた 61
62. まとめ 62
63. 20年チームの1年間をふりかえったら 早々にモブプロやめてた 63
64. スクラムとはいえない方法で回してるが 理に適ってそうだった 64
65. チームの状態は良さそうに見えた 65
66. ふりかえったら とてもアジャイルだった 66
67. でもこれで終わりで良いとは思ってない 67
68. おわり 68