XPJUG 2014祭り　オレ流XP入門

2. オレ流：XPとは
 良いソフトウェア開発するためのカタログ
 カテゴリは２つ
 良いソースコードを継続的に書くためのもの
 良いチーム活動を継続するためのもの
 利用ガイド
 価値（value）＝判断するための基準
 プラクティス（practice）＝技法
 原則（principle）＝ある領域の指針
2

3. 例：お菓子を作る
 価値：判断基準を決める
 家族がおいしいというお菓子を作る
 家族の要望を聞く（コミュニケーション）
 家族の意見を受け入れる（フィードバッグ）
3

4. 例：お菓子を作る技法
 技法（お菓子作り用）
 レシピは、「簡単」「失敗しない」をキーワードで選ぶ
 レシピの注意点はしっかり守る
 ツールなどは100円ショップで買う
 専用のツールを使う
 手順を明確にする
 ツールと材料を準備する
 最初に、材料は全部計る
 片付けをする
 作りながら、片付ける
 材料を少し変えて、バリエーション
4

5. 例：お菓子を作る原則
 原則（ＸＰそのまま）
 Humanity(人間性)
 安全性、達成感、成長、親密さ
 Economics(経済)
 価値がある、目標を達成している、要件に合っている
 Mutual Benefit(相互利益)
 家族のみんなが喜ぶ（利益になる）
 Self-Similarity(自己相似性)
 レシピ（パターン）を利用する
 Improvement(改善)
 繰り返すことで上手になる
 Diversity(多様性)
 様々なスキル（作る、片づける）が良い結果
5

6. 例：お菓子を作る原則
 原則（ＸＰそのまま）
 Reflection(ふりかえり)
 上手く行った理由、失敗した理由を考え、分析する
 Flow(絶え間なく)
 作ると片づけるを同時に行う
 Opportunity(機会)
 失敗は学習と上手くなる機会
 Quality(質)
 品質は犠牲にしてはならない
 Baby Steps(ほんのちょっとづつ)
 少しずつステップアップ
 Accepted Responsibility(責任の受け入れ)
 結果の責任を受け入れる
6

7. 例：お菓子を作るポイント
 大切なこと
 コンテクスト（Context）
 状況をはっきり認識する（やりたいこと、できること）
 状況（自分の習熟度）に合わせて、価値・技法・原則を
選んだり、追加したりする
 変化を受け入れる
 状況も、対象や時間で変わる
 練習
 最初は練習として、やってみる（失敗する）
 少しずつ、新しいことに挑戦
7

8. オレ流：XPのまとめ
 プロジェクトごとに、「価値・原則・プラクティス」
マップを作成し、目的を共有する
 状況を考えることが大切
 ＸＰは目的ではありません、カタログです
 ＸＰと直接関係ありませんが
8
「成せば為る成さねば為らぬ何事
も
為らぬは人の成さぬなりけり」
上杉鷹山

9. ＸＰ入門
 目次
 目標
 焦点と内容
 定義
 価値、原則、プラクティス
 まとめ
9

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

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

12. 定義（他の方法論との違い）
 短期の開発サイクル
 インクリメンタルな開発手法
 ビジネス要件の変更にともなう、柔軟なスケジューリ
ング
 信頼性の高い自動テスト
 コミュニケーション、テスト、ソースコードに対する信
頼
 継続する発展的な設計プロセス
 メンバー間の協調関係に対する信頼
 チームメンバーの短期的な要求とプロジェクトの長期
的な利益の両方に対応するプラクティス
12

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

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

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

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

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

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

19. 詳細
 ＸＰ第2版（変化を受け入れる）紹介
 まえがき
 XPとは
 運転の心得
 価値、原則、プラクティス
 結論
 書籍紹介
19

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

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

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

23. XPとは定義（他の方法論との違い）
 短期の開発サイクル
 インクリメンタルな開発手法
 ビジネス要件の変更にともなう、柔軟なスケジューリ
ング
 信頼性の高い自動テスト
 コミュニケーション、テスト、ソースコードに対する信
頼
 継続する発展的な設計プロセス
 メンバー間の協調関係に対する信頼
 チームメンバーの短期的な要求とプロジェクトの長期
的な利益の両方に対応するプラクティス
23

24. XPとは定義（第２版での追加項目）
 軽量である
 多くの荷物を持っては俊敏に動けない
 ソフトウェア開発における制約への対処方法
に基づく方法論である
 どのような規模のチームにも適応できる
 規模によってプラクティスの選択や追加が必要
 曖昧で変化しやすい要求仕様に適合する
24

25. XPとはリスクへの対処
 プロジェクトの遅延、ビジネスの変化、ビジネ
スの誤解
 短いリリースサイクル
 プロジェクトのキャンセル、誤った機能強化
 ビジネスの価値に基づいたリリース計画
 システムの陳腐化
 自動テストによる、変更への対応
 欠陥率
 様々な視点からのテスト（プログラマやユーザ）
25

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

27. 運転の心得XPのパラダイム
 XPのパラダイム
 常に注意を払う
 状況に適応する
 変更する
 ソフトウェアのすべての要素は変化する
 要素
 要件、設計
 ビジネス、テクノロジー
 チーム、チームのメンバー
 問題は
 変化に対処できないこと
27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

42. 原則改善（カイゼン）
 ソフトウェア開発に完全なプロセスはない
 「完全」は動詞である
 カイゼンの繰り返しによって、洗練する
 インクリメンタルな設計
 設計を洗練するためには、カイゼンが必要
 理想と現実を近づけるためには、カイゼンする
42

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

65. 書籍紹介
 XPエクストリーム・プログラミング入門
 変化を受け入れる第2版
 ISBN4-89471-685-2
 この資料の内容は、前半の一部です
 書籍には、さまざまなアイデアが満載です
 ぜひお手に取って熟読ください
65