スクラムで身についていた動き方を、XPで捉え直してみた

Transcript

1. XP祭り2026 スクラムで身についていた動き方を、 XPで捉え直してみた 株式会社コドモン プロダクト開発部 塚原 彰仁 2026年09月05日
2. 自己紹介 塚原 彰仁 つかはら あきと 経歴 子どもを取りまく環境をもっと良くしたいという想いからコドモンの ミッションに共感し入社。これまでスクラム開発、スクラムマスター を経験、今の組織で初めてXPを体験。 1児と1匹のトイプーのパパです。 2025.11 コドモンにソフトウェアエンジニアとして入社 2026.09 XP祭りに初参戦！ 2
3. 自己紹介 スクラムの現場で開発、スクラムマスターも経験 1年弱前にXPの現場へ転職してきました 今日は「スクラムからXPにやってきた人の目線(n=1)」で アジャイルをアンラーンしようとしたお話です 3
4. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 4
5. こんな人におすすめ • スクラムからXPの現場にきた人 • XP歴は長いが、独自のプラクティスが増えてきた人 • 自分のやり方が、「当たり前」になっている人 • チームにXPビギナーをお迎えする人 • XP祭りを楽しみにしていた人 5
6. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 6
7. うまくいった方法を、型にしていた • 業務の知見を「型」として文書化する文化 • 認識と行動が揃う / 新しいメンバーのオンボーディングになる •実際に、うまく機能していた これがチームの勝ちパターンだ！ 7
8. XPの現場に移る 全員同席 / ペアプログラミング / テストファーストプログラミング / 継続的インテグレーション / インクリメンタルな設計 プラクティスがいくつもあるけど、 勝ちパターンは普遍的でしょ？ 8
9. 噛み合っていないかも？ チームの動きを型化できたら、 動きやすくなるよね？ いや、チームは常に変化していくべき。 型にすると、チームが考える機会を 無くしてしまうよ 既存のルールすら疑い続けて行かないと 9
10. 当時の自分にとって 型は、ガードレールだった 目の前の開発に集中するために、不確実性を下げるための仕組み 10
11. 当時の自分にとって ガードレールを外して 走れるのか？ 11
12. ３つの転換 分かってから動く 動くから分かる 事前に計画を固める 書きながら設計する 一人で完結させる チームで進める どれも、前の環境では当たり前だった動き方 XPの文脈では、推奨されない動き方に感じられる 12
13. 当時の自分の仮説 スクラムとXPが違うからだろう とは言いつつも... 本当に、スクラムとXPの違いなのか？自分の持ち込んだ型は正しいのか？ →スクラムガイドを読み直してみる 13
14. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 14
15. スクラムガイド、拡張パックを読み直した スクラムガイド2020 スクラムの公式ガイド 迷ったら、ここに立ち返る スクラムガイド拡張パック ガイドを置き換えるものではなく、 背景の考え方を掘り下げた補足資料 読み直して、認識のずれを２つ発見した 15
16. スクラムガイド拡張パック「経験主義」（引用） 約束を守ることや、間違ったステークホルダーに 仕えることよりも、検査と適応に価値を置くべきである スクラムガイド拡張パック「経験主義」（日本語版 v2025.6） 自分の型は「約束を守るための仕組み」だった 16
17. スクラムガイド拡張パック「創発」（引用） 重要なのは、スクラムの構造が、すべての詳細を定義するのではなく、 チームが自己管理し、新しいソリューションを創発するのに十分なガイ ダンスを提供することである スクラムガイド拡張パック「創発」（日本語版 v2025.6） 自分の型は「詳細を定義する」ものだった 17
18. 違う方法論だと思っていたが スクラムの三本柱 XPの価値 XPの原則 XPの主要プラクティス 透明性 コミュニケーション ー 情報満載のワークスペース 全員同席 検査 フィードバック ふりかえり 失敗 テストファーストプログラミング 継続的インテグレーション 適応 勇気 シンプリシティ ベイビーステップ 改善 インクリメンタルな設計 週次サイクル どちらもフィードバックを得て、 見直し続けることに価値をおいている 18
19. どうやら勘違いをしていたようだ Cfpを出した時点では、 XPとスクラムの違いを 整理する想定だった タイトルの解釈が少しずれるか？ 19
20. XP祭り2026 スクラムで身についていた動き方を、 改め！ XPで捉え直してみた 株式会社コドモン プロダクト開発部 塚原 彰仁 2026年09月05日
21. XP祭り2026 XPへもう一歩踏み出すために、 自分の当たり前をアンラーンする 株式会社コドモン プロダクト開発部 塚原 彰仁 2026年09月05日
22. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 22
23. 当時の型を思い出してみる • タスクの着手前にDoDを定義し、テストで担保する • 同時に持つタスクは、１つに絞る（WIP制限） • 初回レビューのあとは、ペア作業で修正ラリーを減らす • DoD・ユーザーストーリーに納得がなければ、着手しない • 不確実性の高い設計方針は、ADRやSpikeチケットで小さく検証し下げる • PJリーダーが、不確実性を先にPdMと解消しておく 23
24. スクラムチーム時代の「型」を仕分ける 分類 型の例 XPの原則 どちらでも 通用する DoD + テスト / WIP制限 ADR・Spikeで不確実性を下げる 「小さく動いて確かめる」に近い XPでは 前提ごと消える 初回レビュー後はペアで修正 チケットのステータスで状況を表明 常時ペアでは「レビュー待ち」 「非同期の状況共有」という前提がない 不確実性を動く前に解消する （着手の受け入れ条件・リーダーの事前見積もり） XPでは動きながら不確実性を減らす （ベイビーステップ・週次サイクル・ペア） XPのプラクティスと 衝突する 24
25. 通用する型には、共通点がありそう DoD + テスト 想定仕様がズレれば、テストが落ちて教えてくれる ADR・Spike 止まって考え込むのではなく、小さく動きながら解消する WIP制限 流れの詰まりが、すぐに見える フィードバックを、早く受け取れること →XPの価値に適応している 25
26. XPでは、動き方がプラクティスになっている 全員同席 / ペアプログラミング / テストファーストプログラミング / 継続的インテグレーション / インクリメンタルな設計 型が、XPのプラクティスと被っている 26
27. たとえば、チケットに着手するとき 現チームで試している進め方 ペアでテストを１つ書く すぐに仕様の穴が見つかる 前職で定着していた進め方 納得できるまで、 POと仕様を詰め、 合意を得る ここで、 テストを書く 同じ仕様の穴が ここで見つかる フィードバックを得るまでの時間が延びてしまう 27
28. なぜ同じ型が、XPでは機能しなかったのか 複雑な領域 やってみないと、正解が分からない仕事 →試して学ぶのが正攻法 秩序だった領域 正解のやり方が、分かっている仕事 →標準化するのが正攻法 仕事は、この２つの領域を行き来する ２つの領域の整理は、クネビンフレームワーク（スクラムガイド拡張パック 別冊 Complexity）より 28
29. 型化は、その時の文脈では合理的だった 成功パターンを標準化＝型化（その文脈では有効） 複雑な領域 秩序だった領域 ルールを緩め、創発に備える＝型を手放す（欠けていた） クネビンフレームワーク（スクラムガイド拡張パック 別冊 Complexity）より 29
30. XPのプラクティスが、常にベターとも限らない 環境によって、最適な進め方は変わる • エンジニアの人数、チームの成熟度 • 開発スタイル • ドメインや、プロダクトの性質 環境が違えば、最適も違う 30
31. 欠けていた、もう一つのもの いま、どちらの領域にいるのか？ 転職は、領域が変わる最大級のイベント しかし、型（勝ちパターン）をそのまま持ち込んでいた 31
32. 転職して、チームが変わって、型にはじめて検査が起きた 前の現場では コンテキストが変わらなかったので、 型を検査するきっかけが生まれなかった 転職をして 「当たり前」になっていた型が、 はじめて検査することができた 型を検査できたことで、 自分の中での当たり前をアンラーンできた 32
33. アンラーンしたことで得た学び 勝ちパターンはどこでも通用する アジャイルなら、大体同じ スクラムではなく、型でもなく、 アンラーンすべきは、この思い込みだった 33
34. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 34
35. 自分の仮説を証明しようとして、ここまで来ました • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す →「XPとスクラムは違う」説 • 型を仕分ける →「型化をすること自体が良くなかった」説 • XPを捉え直す • まとめ 35
36. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 36
37. 白本の1章の冒頭にある一文 XPはソーシャルチェンジである。 XPとは、以前はうまくいっていたかもしれないが、 今では最高の仕事の邪魔になっている習慣やパターンを手放すことだ。 XPとは、これまで自分たちを守ってきてくれたが、 今では生産性の妨げになっているものを捨て去ることだ エクストリームプログラミング 1章「XPとは何か」 37
38. 白本の1章の冒頭にある一文 XPはソーシャルチェンジである。 XPとは、以前はうまくいっていたかもしれないが、 今では最高の仕事の邪魔になっている習慣やパターンを手放すことだ。 この一文に集約されていた XPとは、これまで自分たちを守ってきてくれたが、 XPの入り口にアンラーンが 今では生産性の妨げになっているものを捨て去ることだ エクストリームプログラミング 1章「XPとは何か」 38
39. これまでの型を手放すことに抵抗は？ XPでは、チームで価値観を揃えていくほど、 プラクティスが機能しやすくなる。 このチームで働きたい。ゴールを一緒に目指したい。 そう思うほど、 「手放す」は当たり前の一歩になった 39
40. これまでの型を手放すことに抵抗は？ XPでは、チームで価値観を揃えていくほど、 プラクティスが機能しやすくなる。 このチームで働きたい。ゴールを一緒に目指したい。 そう思うほど、 「手放す」は当たり前の一歩になった 40
41. 自分の型は何だったのか？ Steering without movement provides little to no value 意訳：舵取りは、動いていなければ、ほとんど意味を持たない。 Gregor Hohpe “Before you can steer, you first have to move” 止まったままでは、舵は効かない →自分の型は動き始める前から舵を取っているようなもの 41
42. 自分の「型」はどうだったのか？ 衝突した型 動く前に、答えを求める型 通用した型 動きながら、確かめる型 その型は、動きを助けるのか？ それとも、動く前に、動き方を決めてしまうのか 42
43. 有効かどうかは、何で決まるのか 価値 プラクティスに目的を与える。機械的な作業になることを防ぐ 原則 価値とプラクティスの橋渡し。 プラクティスの存在意義に迷ったとき、ギャップを埋めてくれる プラクティス XPチームが日常的に行うもの、（ただし、状況に依存する） プラクティスは、価値への説明責任を負っている 43
44. 捉え直し①：動くから分かる 持ち込んだ解釈のまま 「迷いは、消してから外に出すもの」 曖昧なコードをアウトプットすることに気まずさがあった 解釈を手放したら フィードバック 迷っている時こそ、フィードバックを受けられる機会 曖昧なコードをアウトプットすることへの抵抗感が無くなった 44
45. 捉え直し②：書きながら設計する 持ち込んだ解釈のまま 「不確実性は、書く前に潰すもの」 テストは、実装後に仕様を満たすことの動作証明でしかなかった 解釈を手放したら フィードバック コミュニケーション テストを書くことが、最速で不確実性を減らせる テストから始めることで、ペアの設計認識を合わせることもできる 45
46. 捉え直し③：チームで進める 持ち込んだ解釈のまま 「任されたタスクは、自分の持ち物」 誰かがリードした方が、スムーズに進むのでは？ 解釈を手放したら 勇気 タスクをチームで取り組むことで挑戦できる スピードはトレードオフかもしれないが、技術負債やリファクタリングも一緒にできる 46
47. XPのプラクティスが、変わったわけではない 思い込みを手放したら、 プラクティスが、さらに機能してきた 見えていたXPの解像度が上がった XPを捉え直すことで、自分の動きも良くなってきた 47
48. 「見直す」は、誰の仕事なのか スクラム スクラムマスターが、検査と適応を支援する（チームの自立を目指す） XP 特定の役割ではなく、チーム全員がプラクティスを担う （XP）自分から XPでは、自分から変化を引き起こすつもりがあることが前提 見直す視点は、役割ではなく、 全員で、そして自分から。 48
49. 「型」の捉え方が、変わった これまでの型 変化を防ぎ、不確実性を消すための「守りのルール」 これからの型 価値に目的を与えられた、チームのプラクティス • どの価値に、説明責任を果たすのか • 存在に迷ったら、原則でギャップを埋められるか • 定期的に検査し、必要なら適応し、手放す 型を否定するのではなく、この枠の中で見直し続ける 49
50. 目次 • 型を作っていた頃と、XPでの違和感 • スクラムガイド、拡張パックを読み直す • 型を仕分ける • XPを捉え直す • まとめ 50
51. まとめ 文脈が変わった（スクラム → XP） 「どこでも通用する」と思い込み、型をそのまま持ち込んだ 型はプラクティスと重複し、考え方にずれができていた 違和感から、検査が始まった 適応するは、型ではなく 「思い込み」 51
52. まとめ アンラーンしたのは、型ではなく 「自分の思い込み」だった 自分の解釈は、価値への説明責任を果たして、 はじめてプラクティスになる そのためには、検査・適応（アンラーン） 52
53. 開発手法 XP(エクストリーム・プログラミング)に則り、 アジャイルなチームを目指す 価値 • コミュニケーション • シンプルさ • フィードバック • 勇気 • リスペクト 原則 • 人間性：みんなが自分らしくいられるチームで • ふりかえり：起きたことから学んで、再現性を ハンドリング • ベイビーステップ：小さく始める、小さく進める など プラクティス • 受け入れテスト • 持続可能なペース • TDD • ペアプログラミング など 価値・原則を意識しながらプラクティスを実行することで、「価値を体現できている状態」へ 参考：コドモンがXPを取り入れている理由 53
54. 一緒にアンラーンし続けてくれる 仲間を募集しています！ 54
55. コドモンでは一緒に働きたい仲間を募集しています！ コドモン採用ページ 開発チームX 55
56. ご清聴ありがとうございました！ 56
57. Appendix 57
58. 参考文献 • スクラムガイド 2020（日本語版） • スクラムガイド拡張パック • Kent Beck「エクストリームプログラミング」 • Kent Beck「テスト駆動開発」 • Martin Fowler “Flaccid Scrum”（2009）── martinfowler.com • Gregor Hohpe “Before you can steer, you first have to move”（2017・LinkedIn） • Dave Thomas『simplicity』（島田浩二 訳、2026） • Snowden & Boone “A Leader’s Framework for Decision Making”（HBR, 2007） • 拙記事「スクラムガイド拡張パックで、自分のスクラム理解を棚卸しした」（Zenn, 2026) 58
59. クネビンフレームワークの全体像 • 明白（Clear）── 因果が自明。ベストプラクティスが機能する • 煩雑（Complicated）── 分析と専門知で解ける。グッドプラクティス • 複雑（Complex）── やってみないと分からない。試して学ぶ（創発） • 混沌（Chaotic）── まず行動して安定させる • 無秩序（Disorder）── どの領域か分からない状態 59
60. クネビンフレームワークの全体像 60
61. 白本のプラクティス設計 主要プラクティス 単独でも、安全に始められる 随伴プラクティス 前提が整ってから、慎重に プラクティスの追加は制限していない。 ただし、状況によって有効性は変わる。 61
62. XPのプラクティスも、型化からできている（自論） はじめに 「本書は、良いソフトウェア開発チームの共通点を抽出したもの」 →うまくいったことの抽出。XPも「型化」から生まれた 第2版への序文 「XPのパラダイム（注意して、適応して、変更する）をXPそのものに適用している」 →Kent Beck自身も、第1版から2版出版時の5年後に自分の型を見直している うまくいったことの抽出。 XPも、型化から生まれている。 62