XP入門XP祭り2025　XP祭りの前説の資料。エクストリームプログラミングの資料です。

XP祭りの前説資料

1. ＸＰＪＵＧスタッフ 小井土 亨 「 XP エクストリーム・プログラミング入門 変化を受け入れる　第２版」 XP 祭り２０２５

2. XP eXtreme Programming 1999 年に、 Kent Beck が提唱した アジャイルソフトウェア開発手法 2

3. Tidy First?( まずは整理整頓？ ) Kent Beck 新刊 経験に基づいた、 ソフトウェア設計の為の パーソナル・エクササイズ 小規模な作業の「リファクタリング」 「 Tidying 」 日々の片付け が大切 3 https://www.oreilly.com/library/view/tidy-first/9781098151232/

4. KentBeck 来日 開発生産性 Conference 2025.7.3 グッドハートの法則（ Goodhart's law ） ある指標が目標になると、その時点でその指標は“良い指標”ではなくなる 指標を測定することは問題ないが、目標とした時点で、様々な問題を誘発する 指標は ユーザーにどれだけ価値を 提供したか！ 測るのは簡単ではない。 4

5. 概要 目標 焦点と内容 定義 価値、原則、プラクティス まとめ 5

6. 目標 XP の目標 優れた ソフトウェア開発 を行うこと 現在の多くのソフトウェア開発はカイゼンできる 低コスト 少ない欠陥 高い生産性 投資回収率 ソフトウェア開発 良い方法と悪い方法がある 優れたチームは、同じような方法が採用されている 優れたソフトウェア開発チームの 共通点 ソフトウェア開発チームのパタン・ランゲージ 6 必要なものを必要になったときに作る （作らないことも選択肢）

7. 焦点 と内容 焦点 プログラミング技術 明確なコミュニケーション チームワーク 内容 価値 （理念） コミュニケーション フィードバック シンプルさ 勇気 尊重（リスペクト） 原則 プラクティス 互いに補足 補完的な原則 共有するコミュニティ 7 技術 と 人 にフォーカス

8. 対象とするソフトウェア開発 短い開発サイクル インクリメンタルな開発手法 ビジネスを成功に導く価値のあるソフトウェア ビジネス要件の変更にともなう、柔軟なスケジューリング 信頼性の高い自動テスト コミュニケーション、テスト、ソースコードに対する信頼 継続する発展的な設計プロセス メンバー間の協調関係に対する信頼 チームメンバーの短期的な要求とプロジェクトの長期的な利益の両方に対応するプラクティス 8

9. 価値、原則、プラクティス 　プラクティス、価値 プラクティス（ practice ） 新しいソフトウェア開発を実行するための技術 技術レベル の知識と理解 価値（ value ） 新しいソフトウェア開発を実行するための全体を捉える力 判断レベル の知識と理解 ある状況で何が望ましいか、望ましくないかの根拠 判断するための大まかな基準 価値は普遍的なものである 9

10. 価値、原則、プラクティス 　価値とプラクティスの関係 結びつけることが必要 結びつくことが、 プラクティスを実践する正当な理由 価値が、プラクティスの目的を明確にする プラクティスが価値を証明する 10 価値によって プラクティスが目的を得る

11. 価値、原則、プラクティス 　原則と３つの関係　 原則（ principle ） 価値とプラクティスとの隔たりを埋めるもの 特定の領域の変わることがない指針 11 価値 プラクティス 原則は橋

12. 原則 人間性 経済性（コスト） 相互利益 （関係者全員の利益） 自己 相似性（パターン ） 改善 （最良は、十分の敵である） 多様性 反省 フロー 機会 冗長性 失敗 （失敗することの価値） 品質 小さなステップ 責任の受け入れ （責任と権限） 12

13. XP とは　 XP の真髄　 社会的な変革（ social change ） 障害となる慣習やパターンを取り除く 自己改革 子供じみた自己 他の誰よりも知っている 1 人にしてくれれば、素晴らしい結果が出せる 成熟した自己 ビジネスや仕事のコミュニティで自分の場所を見つける 手順 最も良い自己になるためのプロセス 良いプロセスで開発者として最善を尽くす 実際にビジネスで利用できるコードを作成する 信頼関係 成功するためには技術と信頼関係が必要 13

14. 「 XP とは？」という疑問に対する回答 　社会的な変革（ social change ）とは 役に立たない技術的習慣や社会的な習慣を捨てて、 機能する新しい習慣 を行う 今日全力を尽くすことに対して 自分自身を評価 する 明日には、より良い結果を得られるように努力する チームの共通の目標に対する 貢献度 で自分自身を評価する ソフトウェア開発の中で人間的な要求がある程度満たされるように求める 14 チームと個人の二つの側面はどちらも重要

15. まとめ　 XP とは 自分自身を最初に改善しなければ、何の改善もない 自分の価値を考えて、その価値と調和した生活を意識的に選択する 調和した中で生き、優れた仕事を行う 15 ＸＰとは、 理想に対する考え方と振る舞い方

16. 詳細 価値 原則 プラクティス 16

17. 価値　目的と役割 目的 チーム（組織）の成功 役割 開発の指針 チーム（組織）内で個人がどのように振舞うべきか 17 コミュニケーション シンプルさ フィードバック 勇気 尊重（尊敬） ５つの価値

18. 価値　コミュニケーション、シンプルさ コミュニケーション 最も重要 チーム意識と効果的な協力関係 ほとんどの開発の問題は、誰かが解決策を知っている シンプルさ 最も知的 今日の問題を解決できるようにシステムをシンプルにする 動作させるための最もシンプルなことは何か シンプルさは状況によって異なる 18

19. 価値　フィードバック 方針は、長期に渡って一定ではない ソフトウェア開発の詳細、システムの要件やアーキテクチャ 最初から正しく（変化を予測した） 開発ができない理由 「正しく」行う方法を知らない 今日は正しくても、明日は正しくない場合がある 正しい方法で実装するために時間がかかる 状況が変わるため、正しく行う前に無効になってしまう 目的を達成するためには フィードバックを使用するカイゼンによって目的に近づける 早いフィードバックがカイゼンを早くする 19

20. 価値　勇気 勇気とは 恐怖を前にしたときに有効な手段 恐怖への対処なしに、効率的な作業はない 真実を伝える勇気 コミュニケーションと信頼が生まれる 新しい解答を探す勇気 フィードバックを生む 20

21. 価値　尊重（リスペクト） 4 つの価値の背景に尊重が存在する 尊重の意味と役割 チームの人と人間としての価値は同じ チームがチームであるためには尊重が必要 人間性と生産性を同時に改善する チームへの個人の貢献が尊重されるべき 21

22. 価値　５つの価値以外の価値 各組織やチームに応じた、さまざまな価値がある 必要に応じて、新しい価値を選択する その他の価値の例 安全性 セキュリティ 予測可能性 生活の質 22

23. 原則　 原則とは ソフトウェア開発の具体的な指針 プラクティスの指針 紹介する原則について ソフトウェア開発の唯一の原則ではない 他に必要となる原則がある場合もある X Ｐの指針となる原則 23

24. 原則　人間性 ソフトウェアは人が開発するもの 人間の弱さを意識し、長所を利用する 優れた開発者に必要なこと 必要最低限の安全性 達成感 所属意識 成長 親密さ 24

25. 原則　経済性 経済性とは ビジネス価値がある ビジネス目標を達成している ビジネス要件に合っている XP での対処法 ビジネス価値の高い要件から提供する ソフトウェアとチームの価値を高める 25

26. 原則　相互利益 全ての活動は、関係者全員の利益とならなければいけない XP では、最も重要な原則だが、順守は困難 XP の相互利益とは 現在の自分、将来の自分、顧客にとって利益があるプラクティスを選ぶ（探す）こと 26

27. 原則　自己相似性 自己相似性とは 役立つ形（パターン）を探し、解決策として利用する 適応範囲 パターンは、状況によって機能する場合としない場合がある パターンは、異なる規模でも利用できる場合がある 27

28. 原則　改善（カイゼン） ソフトウェア開発に完全なプロセスはない 「完全」は動詞である カイゼンの繰り返しによって、洗練する インクリメンタルな設計 設計を洗練するためには、カイゼンが必要 理想と現実を近づけるためには、カイゼンする 28 最良は、十分の敵である （完全な状態だけを求めると、十分になる機会を失うことになる）

29. 原則　改善を妨げるもの 無駄の増加の原因 開発組織の硬直化 社会構造の専門化 無駄を抑制するためには 新しい技術的な効率性を用いて、効果的で新しい社会的な関係を可能にする 完全性を求めずに、カイゼンを作業に盛り込む 29

30. 原則　多様性 チーム員が同じでは、効率的ではない 多様性 様々なスキルや姿勢が解決策を発見する 多様性がチームには必要 多様性は衝突を生む 衝突の意味 解決策が複数ある状態 衝突の解決 個々の意見を尊重し、チーム全体として解決を行う 30

31. 原則　反省 優れたチーム 作業を行い、作業方法と理由を考える 成功した理由、失敗した理由を分析する 誤りを公表し、学習する 反省する時期 作業を行ってから反省する 反省だけ行っていては、前に進まない 実行しながら反省を行う 31

32. 原則　フロー、機会 フロー 開発をフェーズに分けずに、全ての活動を同時に行う 活動を連続したフローとする 機会 問題を変更の機会と捉える 問題を学習とカイゼンの機会と捉える 問題を解決するプラクティスを採用する 32

33. 原則　冗長性、失敗 冗長性 困難な問題に対しては、さまざまな方法で対処しなければならない プラクティスは、冗長性を持つものがある 冗長性が単なる無駄にならずに、問題を解決することがある 失敗 成功することが困難な場合は、失敗する 失敗することの価値 失敗によって知識を得る場合 複数の選択肢の決定に、失敗を利用する 失敗することが成功への最短で確実な道になる 33

34. 原則　品質 品質を犠牲にしてはならない 品質を犠牲にしても、プロジェクトは早くならない 品質を向上させる かえって、早い納品につながる 生産性、有効性といった特性の改善になる 高い品質が仕事に誇りを生む できる範囲で、最善の方法を行う 品質がプロジェクトを安定させる 34

35. 原則　小さなステップ 大きなステップ 大きなステップで、大きな変更を行うことは高いリスクを伴う 小さなステップ 正しい方向に進んでいるとわかる最も小さいステップを考える 確実に、目標に近づける 35

36. 原則　責任の受け入れ 責任とは 責任は割り当てることはできない 責任は受け入れることができるだけ 責任と権限 責任を持つことは、権限を持つことになる 責任と権限のずれは感情的な負担となる 36

37. 原則　結論 原則を理解し、目的にあったプラクティスを見つける 原則がアイデアを生む 原則を理解することで、有効な新しいプラクティスを作成する 37

38. プラクティス プラクティスとは チームが日々行うこと プラクティスの実行 価値によって目的を意識して実行する 複数のプラクティスが相互作用を生む 複数の使用によって、劇的に改善される プラクティスの選択 状況に合わせて選択する 38

39. 基礎プラクティス 　全員同席、チーム全体 全員同席 チーム全体が入る空間を確保する コミュニケーションを向上させる チーム全体 チームとは 一員である 共に取り組んでいる お互いの作業、成長、学習をサポート チームの構成は、動的に変化する 39

40. 基礎プラクティス 　情報豊富な作業空間、活気のある仕事 情報豊富な作業空間 作業が明確にわかる状態にする １５秒間でプロジェクトの見通しが把握できる 活気のある仕事 高い生産性を維持できる空間で仕事をする ソフトウェアにはアイデアが必要である 40

41. 基礎プラクティス 　ペアプログラミング　 　ペアプログラミングと個人の空間 ペアプログラミング ２人で、プログラミング（分析、設計、テスト）を行う ペアプログラマが行う内容 お互いに集中する 意見を出し合う アイデアを明確にする パートナーの問題を共に解決する プラクティスに対する責任を負う 一人で考える必要があれば、ペアを解消する 個人の空間を尊重しなければならい 41

42. 基礎プラクティス 　ストーリー 顧客の見える単位で計画する ストーリーと要件のちがい 要件には、絶対かつ不変な意味合いがある 変更の受入れを抑制する ストーリーで重要なことは、早期の見積り ビジネスの観点と技術的な観点に相互作用の機会 見積りを前提に、スコープの分割、結合、拡張を行う ストーリーと見積りの制約を把握する 42

43. 基礎プラクティス 　１週間サイクル、四半期サイクル 1 週間単位で作業を計画する 短時間で正しい計画できる単位で計画する 計画を立てる行為自体には価値がない 四半期単位で作業を計画する 四半期ごとに、進捗や目標との調整を行う 四半期ごとの計画 テーマの計画、テーマに対するストーリーの選択 ボトルネックの特定、修正 プロジェクトが組織に適合していることを確認する 43

44. 基礎プラクティス 　ゆとり 責務を果たすことの重要性 オーバーコミットによって無駄が発生する 管理不能な欠陥 士気の低下 人間関係の対立 控え目であっても、責務を果たすことで信頼は生まれる 計画のゆとり 遅れが生じたときにカットできる重要でないタスクを盛り込む 44

45. 基礎プラクティス 　 10 分ビルド、常時結合 １０分間でシステム全体をビルドし、テストを実行する 自動ビルドは、手作業のビルドよりもはるかに役に立つ 常時結合 ２～３時間以内に結合とテストを行う 結合までの時間が長いほど、費用は大きくなり、予測できなくなる 45

46. 基礎プラクティス 　テストファーストプログラミング コードを変更する前に失敗する自動テストを作成 効果 仕様（スコープ）の拡大 結合度と凝集度 設計を良くする 信頼 動作するシステムが信頼を生む 効率的なリズム テスト　→　コード　→　リファクタリング 46

47. 基礎プラクティス 　インクリメンタル設計 システムの設計に毎日投資を行う 変更の準備 変更による費用が増えないような状況を維持する 常に設計に注意を払う 設計投資期間を短くするのではなく、設計投資を必要に応じて行う 設計の指針 重複のない設計を行う 作業が進んで理解が進んでから設計を行う 47

48. 応用プラクティス 応用プラクティス 基礎プラクティスを理解してから、必要に応じて採用するプラクティス 実顧客の参加 インクリメンタル配置、日次配置 チームの継続、チーム数の縮小 根本原因の分析 コードの共有、コードとテスト、単一のコードベース 協議されたスコープ契約、利用分払い 48

49. プラクティス　結論 ソフトウェア開発を成功させることに必要なのは、プラクティスだけではない 価値や原則を見直して、個々のチームにあった解決策を考える 49 プラクティスは、優れた開発チームを 形成するための中核

50. 結論 自分自身を最初に改善しなければ、何の改善もない 自分の価値を考えて、その価値と調和した生活を意識的に選択する 調和した中で生き、優れた仕事を行う 50 ＸＰとは、 理想に対する考え方と振る舞い方

51. 書籍紹介 XP エクストリーム プログラミング Kent Beck ・ Cynthia Andres 共著 角　征典　訳 ISBN978-4-274-21762-3 この資料の内容は、前半の一部です 書籍には、さまざまなアイデアが満載です ぜひお手に取って熟読ください 51