スクラム経験者がXPを学んでの気付き

Transcript

1. スクラム経験者がXPを学んで の気付き 2026/02/20 城戸
2. 目次 1. UB入社前 2. UB入社後の挫折 3. XPに触れて気づいた「ガチアジャイル」の条件 4. 元はスクラム好きだった僕が、スクラムに対して懐疑的になってしまった理由 5. XPがやれる条件・破綻する条件 6. XPとスクラム 7. アジャイルに向かえているか？僕なりのチェックリスト
3. 1. UB入社前 前職でスクラムマスターとかやってたし、ア ジャイルの理解や立ち振る舞いもある程度 は身についているハズ。 まあXPもイケるやろ！
4. 1. UB入社前 …と、思っていたが…
5. 2. UB入社後の挫折 こんなに密にコミュニケーション取るんか？ 一日8時間ずっ と喋り続けてるぞ 🤯 こんなに計画変更するんか！？？ 🤯 周囲のスピードというか変化への対応力にキャッチアップ するだけで必死や… 今までに使った事のない筋肉を使っている感じがある。短 距離走でやってきた人が長距離走に挑戦するような 今までの経験は何やったんや … 最初、全然ついて行けませんでした
6. 2. UB入社後の挫折 ※今になって思うこと： 当時の自分は「ルール」や「仕組み」によって「プロセス」を改善していこうと いうメンタルモデルだったと思います。 前職の時がそうでした。 例：コードレビュー時の観点のルール化、定例会議を設ける、工程管理を キチンとするetc… でも、このメンタルモデルは XPとは合わない。 即時FBとコミュニケーションによる、個人間連携プレーの最大化 がXPの本質 という理解です。間違ってたらスミマセン… 最初、全然ついて行けませんでした
7. 3. XPに触れて気づいた「ガチアジャイル」の条件 まだちゃんと言語化できてないけど、 結局は「アジャイルの価値・原則に沿っ た行動が出来ているか？ 」に終始する 気がするなあ… 頻繁にリリースして FBを得ていること？そのた めに血眼になれている事？ 得たFBから、即座に計画を頻繁に見直してい る事？
8. 4. 元はスクラム好きだった僕が、スクラムに対して懐疑的になってしまった理由 スクラムについて知らない人のために1分でサマります： 引用元： https://u-tanick.hatenablog.com/entry/2019/04/01/205911
9. 4. 元はスクラム好きだった僕が、スクラムに対して懐疑的になってしまった理由 当時はこれがイイと思っていた。が…
10. 4. 元はスクラム好きだった僕が、スクラムに対して懐疑的になってしまった理由 XPに触れた今となっては懐疑的に 1. スクラムでは明確に役割を定義する。スクラムマスターという役割がいるが、やもすれ ばチームの改善をその人に依存する事になる a. 要は自己組織化に向かっていない 気がした b. XPだと、「全員がスクラムマスター」みたいなもの 2. スプリントの途中での計画変更を許容しない a. イテレーションの途中で事情が変わったら、「次スプリントで反映しよう」というス タンス 3. 「何を作るか」を「プロダクトオーナーに一任」してしまい、「一緒に考える」というマインド を持てていない開発チームが多い。「アウトカム」より「アウトプット」に意識が向かいが ち 4. 技術面での言及が無い a. 現実問題として「毎イテレーションのリリース」を実現するには TDDや継続的イ ンテグレーション等のテクニカルスキルが必要になる筈 スクラムはあくまで「 問題検知のフレームワーク 」。 そうである以上、 「素直にスクラムをやると」、アジャイルの価値・原則に反する部分も出てく るなあと思いました。
11. 5. XPがやれる条件・破綻する条件 じゃあ、どんな組織でも 「アジャイル開発を始めるなら XPをやれば イイんだ！！」
12. 5. XPがやれる条件・破綻する条件 じゃあ、どんな組織でも 「アジャイル開発を始めるなら XPをやれば イイんだ！！」 とはならない
13. 5. XPがやれる条件・破綻する条件 現実的に、XPがやれる条件というものはある - 技術的規律がちゃんとしている - テストコードが信用できる - 即時に実装からFBを得られる - 同期コミュニケーションの練度。 XPのプラクティスでいう「全員同席」 - これが守れなければ、いわゆる「コードレビュー」というプロセスが必要となり、即時 FB が受けられなくなる - 開発している機能の複雑度・認知負荷が高すぎない事 - これが守れなければ、いわゆる「ドキュメント」や「定例会議」が必要となってしまう - そもそも「ネガティブ・ケイパビリティの高い人材」のみで組織を構成できている。 - 「決断を先送りする。変化を許容する」マインドは開発チームのみが持っていていてもダ メで、ビジネスサイドも持ち合わせていないと意味が無い 「アジャイル経営」が全社に浸透している UBに感謝 🙏
14. 5. XPがやれる条件・破綻する条件 結構ハードル高くないです！？？🤯 - いわゆる「巨大モノリス」でXPをできるイメージは沸かない - SPEEDAはマイクロサービスで、現在開発中のAPIはそこまで複雑度が高くない から出来ている - いわゆる「コードレビュー」「QA」といったプロセスが必要になると、XPでは「脆す ぎる」 - 「フロントエンド」「バックエンド」「モバイル」といったように、工程毎にチームが分 かれている時も制約が多い - 開発中の機能それ自体の複雑さにも依存する 要は「コミュニケーション」や「シンプルさ」による問題解決が出来ず、「仕組み」「プロセ ス」で解決せざるを得ないような時に XPでは脆くなると考えました。
15. 6. XPとスクラム 今まで思っていた疑問： - Q: より「アジャイルの価値・原則」に忠実なのはXPなのに、大半の企業ではス クラムが採択されているのは何故なのだろう？ - A (現時点での私見): - 今まで見てきたような原因が積み重なり、「コミュニケーション」よりも「仕 組み」の方の重要性が高くなった企業では「理想はXP・現実はスクラム 」 となるのでは？🤔 - 常時判断を求められるXPよりも、スクラムの方が「人間に優しい 」 - プランニングやリファインメントといった場に判断を切り出せるため
16. 今までの話を踏まえての「XPとして脆くなっていないか？」の僕なりのチェックリスト - 「定例会議増やしませんか？」といった話が出る - FBを受けるまでの時間が長くなってる - 技術面でもコミュニケーション面でも - 計画を長い間変更していない - 「役割分担」を決めようとする - 「何を作るか」をPdMに一任してしまい、「一緒に考える」事ができてない これらの兆候が出始めたら、何かを疑ってもいいかもと思いました 7. アジャイルに向かえているか？僕なりのチェックリスト ※ 「アジャイルかどうか」のチェックリストは皆様の頭の中に既にあると思うのですが、 何か1つでも気付きを与えるものがあれば嬉しいです 🙏
17. ご清聴ありがとうございました！ (重要！！！) マサカリは優しく投げてください…強く投げられたら泣いちゃう 😇