スクラムを実践していた私がXPの現場に来て感じたこと

XP祭り2021 で発表したスライドです

イベント
https://xpjug.connpass.com/event/218516/

https://confengine.com/conferences/xp2021/proposal/15825/xp

Transcript

1. スクラムを実践していた私が
 XPの現場に来て感じたこと
 2021/09/18 XP祭り 2021 #xpjug Jun Nakajima
2. 自己紹介
 なかじま（@jnuank_）
 • 前職でスクラムを実践
 • UZABASEにJoinしてからXPを実践してます
 • モブプロ/ペアプロ/DDD/TDD/アジャイル好き
 ◦ 主にDDD-Comunity-JPで活動してます
 • 前職から日々の開発のカイゼンを率先してやってた
 • 社内でKAIZEN BOZU / OSHO と呼ばれることがあります
 2
3. 発表しようと思ったきっかけ
 3 スクラムとXPって 何がどう違うんです か？ 3年前の私
4. スクラムとXPの
 違いがわからなかった

5. XPとスクラムが目指すものは一緒
 • XPもスクラムも、アジャイルソフトウェア開発宣言に書いてあ る状態になることを目指している
 • スクラムとXP、どちらが優れているのかではなくて、ただアプ ローチが違うだけ
 5
6. スクラムはフレームワーク

7. スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、 ⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークで ある
 7 『スクラムガイド』 P.4 スクラムの定義

8. XPは？

9. エクストリームプログラミング（XP）はソーシャルチェンジである
 9 『エクストリームプログラミング』p.1

10. XPとは、効果のない技術的／社会的な古い習慣を捨て、効果のある新 しい習慣を選ぶことである。
 XPとは、自分が今日やるべきことを十分に理解することである。XPと は、明日をよりよくしようとすることである。
 XPとは、チームのゴールに貢献した自分を評価することである。
 XPとは、ソフトウェア開発で人間としての欲求を満たすことである。
 
 10 『エクストリームプログラミング』p.6

11. よくわからなかった
 XPをやる前の私
12. 実際に現場で経験した感想

13. XPはエンジニアの生活習慣
 と呼べるのではないか？

14. 1.　3つのプロジェクトの話
 14 2.　XPは生活習慣、スクラムはフレームワーク
 今日お伝えしたいこと
 3.　まとめ

15. 1.　3つのプロジェクトの話
 15 2.　XPは生活習慣、スクラムはフレームワーク
 今日お伝えしたいこと
 3.　まとめ

16. 3つのプロジェクトの話

17. 17 自分がアジャイルを学んでいる過程
 2017年 2018年 2019年 2020年 2021年 XP祭り参加 スクラム、XPなにも わからん 念願の スクラム開発 XPを経験して カルチャーショック を受ける アジャイル以前 ウォーターフォール開 発 理 解 し た と い う 自 信 違和感はありつつ いろいろプラクティ ス試してみる
18. 18 自分がアジャイルを学んでいる過程
 2017年 2018年 2019年 2020年 2021年 XP祭り参加 スクラム、XPなにも わからん 念願の スクラム開発 XPを経験して カルチャーショック を受ける アジャイル以前 ウォーターフォール開 発 理 解 し た と い う 自 信 違和感はありつつ いろいろプラクティ ス試してみる
19. アジャイル以前

20. 1つ目：ウォーターフォール開発
 • 巨大なレガシーシステムのマイグレーションプロジェクトに参 加
 • 100人規模のウォーターフォール開発
 • 年単位掛かるプロジェクトで、設計フェーズだけで6ヶ月以上 掛かる計画
 20
21. 21 当初の計画
 要件定義 設計 開発 計画 xxヶ月 xxヶ月 テスト リ リ 丨 ス xxヶ月 xxヶ月 xxヶ月 xxヶ月 よく見るフェーズ区切りの計画

22. 22 実際はこうだった
 フェーズで区切れず情報入り乱れ戦場になった
 要件定義 設計 開発 6ヶ月 3ヶ月… 計画 PJ中止 xxヶ月 xxヶ月 設計やり直 し 要件変更 要件追加 テスト
23. プロジェクト炎上→解散

24. この時学んだこと
 • 計画、設計、実装…とフェーズ区切りするやり方は、計画通 りに物事が進むことが前提
 • だけど計画通りには進まない
 • せっかく設計書を大量に書いても、コード書かずにPJ中止に なった
 • しっかり書いても無駄なのではないか
 24
25. アジャイル開発を知る
 • もっと良い開発方法はないか調べて、アジャイル開発とメ ジャーだったスクラムを知る
 • 毎週開発をしてリリースし、ユーザーのフィードバックを貰う やり方はとても良さそうに感じた
 25
26. 26 自分がアジャイルを学んでいる過程
 2017年 2018年 2019年 2020年 2021年 XP祭り参加 スクラム、XPなにも わからん 念願の スクラム開発 XPを経験して カルチャーショック を受ける アジャイル以前 ウォーターフォール開 発 理 解 し た と い う 自 信 違和感はありつつ いろいろプラクティ ス試してみる
27. ウォーターフォール → スクラム

28. 2つ目：スクラム開発
 28 私たちの チーム プロダクトオーナー 別チームA 子会社 別チームB 親会社 ユーザー
29. プロジェクト開始時
 29 プロダクト オーナー リーダー メンバー この△△システムの開 発をやって欲しい
30. プロジェクト開始時
 30 リーダー メンバー 今スプリントは 要件定義のドキュメント作 成しましょう！
31. 1スプリント後
 31 リーダー メンバー 要件定義が終わらなかっ たので、次のスプリントも やりましょう
32. 3スプリント後…
 32 リーダー メンバー 要件定義が終わったので、次 のスプリントでは設計書を作り ましょう
33. ここまでやって、違和感

34. 34 私たちがやろうとしていたこと
 要件定義 設計 開発 テスト 3スプリント 2スプリント 6スプリント 2スプリント リ リ 丨 ス 1スプリント ※ここでの1スプリント＝1週間 計 画 1スプリント
35. これって、
 ウォーターフォールっぽい

36. 当時思っていたこと
 36 ドキュメントばかり 作ってたら遅くなる し、そんなに書きたく ない 当時の私
37. カイゼンをしてみた

38. ドキュメントを減らすアプローチ
 • ユーザーストーリーマッピングで図で要件の合意を取る
 • API仕様書を手書きだったのをコードから生成する
 • PRを待つ時間の削減と知見共有のためにモブプロ・ペアプ ロを始める
 38
39. 結果

40. 40 各フェーズが効率的になった
 テスト リ リ 丨 ス 計 画 要件 定義 設計 開発 カイゼンしたよ、やったね！

41. 当時の私はアジャイルになれたと思っていた
 • 当時の私はアジャイルになれたと思っていた
 • 各フェーズが短くなった
 • 必要十分以上のドキュメントも作られなくなった
 • 言うことなし！　最高！！
 41
42. リリース後
 42 ユーザー リーダー メンバー この◦◦機能って何であるの？ 別に要らないんだけど
43. 無駄な機能を作ってたことが
 リリース後に発覚

44. 当時思っていたこと
 44 事前にデザインのレ ビューや機能確認し たはずなのに 当時の私 なんでこんなことにな るんだろう…？
45. 45 あらためて、私たちがやったこと
 テスト リ リ 丨 ス 計 画 要件 定義 設計 開発
46. 46 あらためて、私たちがやったこと
 テスト リ リ 丨 ス 計 画 要件 定義 設計 開発
47. 1回しかリリースを
 していない

48. 開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可 能なインクリメントのあらゆる側⾯を作成することを確約する。
 48 『スクラムガイド』p.6

49. 利用可能なインクリメント＝
 動くソフトウェア

50. 50 理想はこうだったのでは
 要件定義 1 スプリント ※ここでの1スプリント＝1週間 設計 コーディング テスト リ リ 丨 ス 計 画 要件定義 1 スプリント 設計 コーディング テスト リ リ 丨 ス 計 画 要件定義 1 スプリント 設計 コーディング テスト リ リ 丨 ス 計 画
51. どうしてできなかった

52. なぜ1回しかリリースしてなかったのか
 • 当時の私たちはリリース＝プロジェクトのゴールと捉えてい た
 • 毎スプリントのインクリメント
 ◦ ドキュメント、(リリースしてない)コード
 ◦ 動くソフトウェアをリリースすると
 ならなかった
 52
53. この時学んだこと
 • 開発者もユーザーも、実際に動くソフトウェアを触ってみない と気づかないことが多い
 • 頻繁にリリースをして、ユーザーからのフィードバックを得た いと思った
 53
54. 54 自分がアジャイルを学んでいる過程
 2017年 2018年 2019年 2020年 2021年 XP祭り参加 スクラム、XPなにも わからん 念願の スクラム開発 XPを経験して カルチャーショック を受ける アジャイル以前 ウォーターフォール開 発 理 解 し た と い う 自 信 違和感はありつつ いろいろプラクティ ス試してみる
55. スクラム → XP

56. 3つ目：XPチーム
 56 　エンジニアを2チームに分けて開発 1イテレーションごとにメンバーシャッフルする
57. 驚いたこと

58. 58 要件定義 1 イテレーション ※ここでの1スプリント(イテレーション)＝1週間 設計 コーディング テスト 計 画 1 イテレーション 1 イテレーション リリース 要件定義 設計 コーディング テスト 計 画 リリース 要件定義 設計 コーディング テスト 計 画 リリース XPチームのサイクル

59. イテレーションごとに
 リリースができている

60. 同時に全てができている
 • テストを書くと同時にAPIパス・メソッド名やパラメータなどの 設計と実装をする
 • WebE2Eテストを書く時に要件が曖昧で書けない場合、他の エンジニアやPdMと話して要件を確認する
 • 1つのストーリーが終わったらパイプラインを動かしてすぐリ リースしている
 60
61. XPのプラクティス
 61 『Clean Agile』p.47

62. XPのプラクティスを
 全部実践している

63. 実践している例
 • 就業時間中、ずっとペアプロをする
 ◦ 1時間経ったらペアチェンジする
 • TDDの徹底、受け入れテスト、継続インテグレーション
 • リファクタリングはタスクとして作らず、常に行なう
 • チーム全体
 ◦ 月イチでチームシャッフルして継続性を高める
 63
64. これがみんな自然にできている

65. 自然にできている一例
 65 ◦◦画面で不正な文字列を入力 できるようになってる 私 メンバーたち
66. 自然にできている一例
 66 私 メンバーたち では直しますか まずはバグを再現するテストを書 いてからバグ修正しましょう
67. 自然にできている一例
 67 私 メンバーたち ですねー 了解ー
68. TDDをやることが当たり前
 になっている

69. TDDをやることが当たり前になっている
 • バグを直すときでも、TDDを選択する
 • そこに対してチームの誰もが異論を挟まない
 • TDDをやることが当たり前だと思っている
 69
70. なぜXPがみんな自然にできるのか
 • 純粋にXPについて知見があるメンバーが多い
 ◦ 加えてXP・アジャイルのスキルを他に伝えられる人も多 い
 ◦ ちょっとXPのプラクティスから外れても、誰かが疑義を投 げかけて修正ができている
 70
71. なぜXPがみんな自然にできるのか
 • メンバーがコミュニケーションを嫌がらない
 ◦ 2〜3分考えてわからなければ、聞きに行く文化
 ◦ 聞いたり教え合ったりする中でXPに対する知見を各メン バーが深めていっている
 71
72. 1.　3つのプロジェクトの話
 72 2.　XPは生活習慣、スクラムはフレームワーク
 今日お伝えしたいこと
 3.　まとめ

73. スクラムはフレームワーク

74. 74 (再掲)2つ目のスクラムチームのサイクル
 テスト リ リ 丨 ス 計 画 要件 定義 設計 開発
75. 毎スプリントリリースをするには
 • 動くソフトウェアを毎スプリント、リリースできていないことが1 つ問題だとわかった
 • 上記を実現するためには、どんなプラクティスが必要か
 75
76. 毎スプリントリリースをするには
 • 特に関連の強いプラクティス
 ◦ 受け入れテスト、テスト駆動開発、シンプルな設計、リ ファクタリング、継続インテグレーション
 • これらについてスクラム自体には特に記述はない
 76
77. スクラムはプロジェクトをマネジメントするためのフレームワークだ。
 プロジェクトをマネジメントする方法は語っているが、エンジニアリング の話はほとんどない
 77 『スクラム現場ガイド』p.39

78. スクラムは、動くソフトウェアを顧客に届けるのを助けるフレームワーク にすぎない。どんな問題でも解いてしまう魔法の粉ではないよ。問題を 見つけやすくして、人びとを問題解決に集中させる。それが、スクラム の素晴らしいところだ。
 78 『スクラム現場ガイド』p.352

79. スクラムはあくまで問題検知のフレームワーク
 • スクラム自体は、問題を素早く検知するためのフレームワー クである
 • スプリントごとに動くソフトウェアをリリースするなど、技術的 な問題にはテクニカルプラクティスが必要になってくる
 79
80. XPはエンジニアの生活習慣

81. (再掲)XPのプラクティス
 81 『Clean Agile』p.47 

82. プラクティスとは
 

83. プラクティスは日常的な取り組みである。
 83 『エクストリームプログラミング』p.11

84. プラクティス＝日常的な取り組み
 

85. 日常的な取り組み＝習慣
 

86. XPは日常的な取り組み＝習慣
 を集めたもの

87. 習慣とは、自動的に行なうまで何度も繰りかえす行動のことである
 87 『ジェームズ・クリアー式 複利で伸びる 1つの習慣』 p.59

88. XPのプラクティスが
 自動的になるまで何度も繰りかえす

89. 自然になるまでプラクティスを繰り返してた
 • バグを直すときでもTDDを当たり前のように実践した
 • 普段の開発でTDDを徹底して、何度も繰り返したからこそ、 バグを直すときに自然とその行動が取れた
 89
90. プラクティスを
 ただ繰りかえせばいいのか

91. 価値を明確にすることが重要だ。価値がなければ、プラクティスはすぐに機 械的な作業になってしまう。活動そのものが目的となり、本来の目的や方向 性が失われてしまう。
 
 91 『エクストリームプログラミング』p.12

92. XPの価値

93. XPの価値
 • コミュニケーション
 • シンプリシティ
 • フィードバック
 • 勇気
 • リスペクト
 93
94. 価値が失われたプラクティス
 • ペアプログラミングで、文字通りペアになるだけ
 • 一人がコードを書いているのを、もう一人が横でじっと眺め ている
 ◦ 会話をしない
 ◦ ドライバーを交代しない
 94
95. 価値が失われたプラクティス
 • ペアプログラミングで、文字通りペアになるだけ
 • 一人がコードを書いているのを、もう一人が横でじっと眺め ている
 ◦ 会話をしない
 ◦ ドライバーを交代しない
 • 最終的に形骸化してやらなくなる
 95
96. プラクティスの背後にある価値
 を意識することが大事である

97. XPはよりアジャイルになる為の生活習慣
 • XPのプラクティスは日常的に取り組むもの
 • 繰り返し実践することで習慣形成されて、自然とできるように なっていく
 ◦ それがXPの価値を体現し続けることに繋がる
 • XPの価値を意識せずに、ただ機械的にやり続けても、それ はXPとは言えないし、習慣が身につかなくなる
 97
98. 1.　3つのプロジェクトの話
 98 2.　XPは生活習慣、スクラムはフレームワーク
 今日お伝えしたいこと
 3.　まとめ

99. 行動の背後にある価値を意識する

100. 100 『アジャイルソフトウェア開発宣言』

101. スクラムもXPも目指すべき価値は一緒
 • アジャイルソフトウェア開発宣言に書かれている価値を体現 するために、スクラムはフレームワーク、XPは良い生活習 慣、を実践し続けるアプローチを取っている
 • 1つ1つのやり方も大事だが、それに固執せずに、
 何の価値を目指すべきかを意識して、日々実践し続けること がどちらも大事です
 101
102. 参考文献
 • Kent Beck, Cynthia Andres(著), 角 征典(訳) (2015) 『エクストリーム・プログラミング』オーム社 
 • Mitch Lacey (著), 安井 力, 近藤 寛喜, 原田 騎郎(訳) (2016) 『スクラム現場ガイド』マイナビ出版 
 • Robert C. Martin(著), 角 征典, 角谷信太郎(訳) (2020)『Clean Agile 基本に立ち戻れ』ドワンゴ 
 • ジェームズ・クリアー (著), 牛原眞弓 (訳) (2019)『ジェームズ・クリアー式 複利で伸びる1つの習慣』 
 • Ken Schwaber & Jeff Sutherland『スクラムガイド』 
 <https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf >
 • 『アジャイルソフトウェア開発宣言』 
 <https://agilemanifesto.org/iso/ja/manifesto.html >
 
 102
103. Thank you! 103