認定スクラムマスター研修(CSM)参加した結果として、社内発表した資料

1. 認定スクラムマスター研修 京都
に行ってきました
1 / 99

2.
認定スクラムマスター研修
(CSM研修)
に参加してきました。
2 / 99

3.
個人的に、印象深かった
トピックをお話します。
3 / 99

4. 本日の、私の目標
スクラムに
興味を持ってもらえること
です
細かい説明はしませんので、
Scrum自体の概要 をしっかり知りたいという方は、あとで資料をご紹介します。
4 / 99

5. 研修はどんな感じだったか
5 / 99

6. 研修はどんな感じだったか
簡単にご紹介
6 / 99

7. 日時 : 2014年 8月 7日 (木) - 8月 8日 (金)
場所 : 京都烏丸コンベンションホール
京都烏丸コンベンションホール Webページ
名前からの先入観で、すごく大きいところを想像していたのですが、
以外にコンパクトでした。 （駅員さんに訊いても知りませんでした）
先入観で決めつけるのはいけないという教訓になりました。
参加者
半分が関東の方、半分が関西の方
7 / 99

8. トレーナー : 江端 一将 さん
日本人で唯一のアジャイルトレーナー
かつて大規模プロジェクトのプロダクトオーナーを
経験された
プロダクトオーナー ・・・ Scrumの役割の一つ
ROI最大化するために、プロダクト方向性を決める人
チーム ・・・ Scrumの役割の一つ
開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい
る
スクラムマスター ・・・ Scrumの役割の一つ
開発が Scrum と呼べる状態にする人。
8 / 99

9. 「体験する」「考える」ことを重視してい
る内容でした
内容の例
本日の参加者で Scrum をどのぐらい知っているかについて、順番を付けてください
研修中のルールを皆さんで決めてください
ゲームやロールプレイ
現場で起こそうな雰囲気
色々『気づき』があり、刺激的でした
(私個人の感想です)
9 / 99

10. Scrum をやる機会がなかったとしても
新鮮な考え方が
得られて有意義な研修だったと感じました。
10 / 99

11. 研修はどんな感じだったか
11 / 99

12. おわり
12 / 99

13. 本題に移ります
13 / 99

14. 印象深かったポイント
14 / 99

15. Scrum は何を解決するためのフレ
ームワークか？
15 / 99

16. Scrum は何を解決するためのフレ
ームワークか？
失敗を減らしたり、
開発の効率を上げたり、
素早く開発できたり、
簡単に開発できたり、
品質を向上が期待できたり、
16 / 99

17. そういうことを
解決する
フレームワークでは
ありません
誤解していました。。。
17 / 99

18. Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。
全部遵守する必要あり。
18 / 99

19. Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。
全部遵守する必要あり。
* Three Keys (Scrum のキーポイント。三本柱)
19 / 99

20. Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。
全部遵守する必要あり。
* Three Keys (Scrum のキーポイント。三本柱)
* 透明性 -- Transparency
* 検証 -- Inspect
* 適合 (検証に基づいた適合) -- Adapt
20 / 99

21. Scrum の重要なキー (Keys)
Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。
全部遵守する必要あり。
* Three Keys (Scrum のキーポイント。三本柱)
* 透明性 -- Transparency
* 検証 -- Inspect
* 適合 (検証に基づいた適合) -- Adapt
* Scrum Roles -- 役割
* Product Owner -- プロダクトオーナー
* ScrumMaster -- スクラムマスター
* The Team -- チーム
* Artifact アーチファクト (参考:日本語訳)人工物、工芸品＾、芸術品
* Product Backlog -- プロダクトバックログ
* Sprint Backlog -- スプリントバックログ
* Impediment List -- インピディメントリスト
* Ceremonies -- セレモニー
* Sprint Planning -- スプリントプランニング
* Daily Scrum -- デイリースクラム
* Product Backlog Refinement -- プロダクトバックログリファインメント
* Sprint Review -- スプリントレビュー
* Sprint retrospective -- スプリントレトロスペクション
* Sprint -- スプリント
* Stop -- 製品開発と途中でやめる
* Acceptance Criteria -- 受け入れ基準
* Done -- 製品が完了する
* Potentially shippable product increment -- 出荷可能な製品をリリースする
21 / 99

22. 「透明性 -- Transparency」
22 / 99

23. 三本柱の中の「透明性 -- Transparency」 を
最も重要視しています
「say "It's done."」 を撲滅する
「もう、ほとんどできてます。」
「90%できた (?) 」
っていうのはなくす
ガントチャートに、こういう状況、よく出てきませんか？
23 / 99

24. Ken Schwaber氏が Scrum について象徴的な説明をして
いる動画を見せてもらいました。
24 / 99

25. Ken Schwaber氏の談話の動画
スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて
くれる
25 / 99

26. Ken Schwaber氏の談話の動画
スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて
くれる
チームが、「優秀」か、「靴紐が結べないほどの間
抜け」か
26 / 99

27. Ken Schwaber氏の談話の動画
スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて
くれる
チームが、「優秀」か、「靴紐が結べないほどの間
抜け」か
Scrum の特徴は
「軽量」、 「理解が容易」、、、
27 / 99

28. Ken Schwaber氏の談話の動画
スクラムは誰でも始められる・・・
1回目のスプリント結果が、チームの実力を教えて
くれる
チームが、「優秀」か、「靴紐が結べないほどの間
抜け」か
Scrum の特徴は
「軽量」、 「理解が容易」、、、 「 習得は非常に困難」
28 / 99

29. Scrum は何を解決するためのフレ
ームワークか？
29 / 99

30. Scrum は何を解決するためのフレ
ームワークか？
現状をあぶりだすフレームワーク
問題をあぶりだすフレームワーク
30 / 99

31. Scrum は何を解決するためのフレ
ームワークか？
素晴らしいチームはより素晴らしく、
そうでないチームはそれなりに、
(Fフイルム風。 知っている人は、かなりご年配。 文責：柳川。)
31 / 99

32. Scrum は何を解決するためのフレ
ームワークか？
良いところも、悪いところも、明らかにし
て
状況に適応していくことで
チームの力を、発揮させようとします
32 / 99

33. ＞＞
33 / 99

34. 自律的なチーム
34 / 99

35. 自律的なチーム
チームがチームを管理する
スクラムマスターは管理者ではない
チーム ・・・ Scrumの役割の一つ
開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい
る
スクラムマスター ・・・ Scrumの役割の一つ
開発が Scrum と呼べる状態にする人。
プロダクトオーナー ・・・ Scrumの役割の一つ
ROI最大化するために、プロダクト方向性を決める人
35 / 99

36. 自律的なチーム
チームで方針を相談する
チームの進捗は、チームが管理する
チームの方針に沿い、
個人が判断して作業する。 (0.1秒以内で判断して)
個人は、チームに結果をフィードバックする
36 / 99

37. 自律的なチーム
スクラムマスターは
管理したり、直接手伝ったりしてはいけない
チームが困っているときに助言する
チームの邪魔をしそうな「人」「もの」「イベント」「人と人とのトラブル」などの
あらゆる障害を取り除く
37 / 99

38. 自律的なチーム
チームがチームを管理することにより
チームは成長していきます。
チームのメンバーも成長していきます。
38 / 99

39. 自律的なチーム
チームがチームを管理することにより
チームは成長していきます。
チームのメンバーも成長していきます。
なんか、いいと思いませんか？
39 / 99

40. ＞＞
40 / 99

41. ソフトウエア開発に抽象的な解
決方法はない
41 / 99

42. ソフトウエア開発に抽象的な解
決方法はない
実際の経験 と 既知に基づく判断によって知識が
獲得できる
経験的プロセス制御の理論（経験主義）
(注: 哲学、心理学の文脈ででてくる「経験主義」とは異なる模様)
42 / 99

43. 具体的な例 (既知に基づく判断)
人間は将来を予測するのが下手
人間は絶対値の見積もりが下手
.
では、上から順に。。。
43 / 99

44. 人間は将来を予測するのが下手
より未来になればなるほど、予測があたらない
大事だとことも、大事でなくなる
44 / 99

45. 人間は将来を予測するのが下手
こんな感じです。たぶん。。
↑予測はずれ率
│ |
│ /
│ |
│ /
│ /
│ _/
│ __/
│ ___/
│ _____/
│ ______/
│ _______/
│ ________/
│ _________/
│ __________/
│/ 未来
＋---------------------------------------------------------->
45 / 99

46. 人間は将来を予測するのが下手
このため、
＝＝＞ 次のスプリントしか詳細に見積もりしない
反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う
スプリント
Scrumでは、1週間、や、2週間、など、期間を区切って開発する。
スプリントはその、１つの期間のこと。
46 / 99

47. 人間は絶対値の見積もりが下手
47 / 99

48. 人間は絶対値の見積もりが下手
どちらが当てやすいか？ (誤差が小さいか?)
このペットボトルの
黒い部分は何セン
チですか
このペットボトルの黒い
部分は白い部分の何
倍ですか
この紙は、何平方
センチですか
この紙は、あの紙の何
倍(何分の何)ですか
48 / 99

49. 人間は絶対値の見積もりが下手
このため、
＝＝＞ 相対的に見積る
相対的に見積もったほうが、誤差が小さい
見積もりの基準になる、項目を決めて、
「何倍か？」という風に見積もる。
「プランニングポーカー」という手法が研修で紹介されました
(研修でカードももらいました。)
紹介しているサイトの一例(検索するといっぱい引っかかります)
プランニングポーカー簡単ガイド作りました --
http://d.hatena.ne.jp/wayaguchi/20120218/1329524230
49 / 99

50. ＞＞
50 / 99

51. Scrumに適するプロジェクトは
51 / 99

52. Scrumに適するプロジェクトは
要件が不明確
↑ └+
│ ｜ カオス
│ └+
│ ｜
│ └---+
│--┐ ｜
│ +---┐ └+----------------+
│ │ ｜
│ 複雑 +┐ └---------
│ +┐
│ │ 複合的に複雑
│ ┐
│ │
│ │
│--┐ │
│ +---┐ │
│ +--┐----------------┐
│ +-┐ ┐
│ 単純 │ 複雑 │
│ +┐ +┐
│ │ │
＋---------------------------------------------------------->
技術が難しい・新しい52 / 99

53. Scrumに適するプロジェクトは
適するのは、単純なプロジェクト以外
単純なプロジェクトは不得意
実現する内容が単純明快
やりたいこと(要件)が明らか
やりたいこと(要件)が変更されない
実現方法が分かっている。もしくは、決まっていて、失敗する可能性が小さい。
単純なプロジェクトであればあるほとは、「ウォータフォール」&「一括契約」
がおすすめです。（なぜなら、変更されないことが「ウォータフォールの前提」だから）
53 / 99

54. Scrumに適するプロジェクトは
採用例
ユーザー企業の内製プロジェクトに、採用例が多
い模様。
内製プロダクトの場合、公表するメリットがなく公表されないことが多いとのこと。
メディアには露出しにくい模様。
54 / 99

55. Scrumに適するプロジェクトは
内製以外では工数精算
一括請負契約は不得意
55 / 99

56. 感想
56 / 99

57. 感想
ルールに厳格だけど、自由にルールを決められる
役割ごとの責任に厳しい
57 / 99

58. ルールに厳格だけど、自由にル
ールを決められる
Scrum自体のルールは、全部守る必要あり
Scrum のキーワード 19個 ... (2014年8月現在)
一部だけ適用することは可能だが、それは、Scrum ではない別の何か
Scrumの要素を一部だけ適用して「Scrumうまくいかない」というのは的外れ
一方、チームが独自で決めるルールは。。。
制約少ない。柔軟
開発コストを下げるためなら、あらゆる発送を駆使して、何を試みてもよい
「チームが決めた」ことは守らないといけない
58 / 99

59. 役割ごとの責任に厳しい
59 / 99

60. 役割ごとの責任に厳しい
責任を果たしていない場合は追及する
60 / 99

61. 役割ごとの責任に厳しい
責任を果たしていない場合は追及する
責任を奪ってはならない
では、順に。。。
61 / 99

62. 役割ごとの責任に厳しい
プロダクトオーナーも、スクラムマスターも、管理者では
ない。
チームとは 対等。 責任範囲を越境してはいけない
チームは「コストを最小にする」代案 があれば、プロ
ダクトマスターが選択できるようにしなくてはならない。
プロダクトオーナーはビジョンを示さなければいけない。
スクラムマスターは、チームが開発に専念できるようにし
なければいけない。
プロダクトオーナーは 優先順位 を決定しなければいけ
ない。(優先度ではない)
「チーム」に指示したり、命令したり、 高圧的に選択を強
いたりして、委縮させるのはもっともダメ
など。。。
62 / 99

63. 役割ごとの責任に厳しい
ゴチャゴチャし過ぎました。
すいません
63 / 99

64. ＞＞
64 / 99

65. 最後に
65 / 99

66. 私が考える SIer の
Agile や Scrumに対するお奨め戦
略は
66 / 99

67. 私が考える SIer の
Agile や Scrumに対するお奨め戦
略は
『Scrum なんて知らない』ふりをする
67 / 99

68. 私が考える SIer の
Agile や Scrumに対するお奨め戦
略は
『Scrum なんて知らない』ふりをする
『Scrum が優秀』と思った顧客は内製開発してしまう
一括契約で Scrum を採用すのはイバラの道
68 / 99

69. でも、 Agile とか Scrum とか言うキーワードで仕事の
お話がある場合は
69 / 99

70. でも、 Agile とか Scrum とか言うキーワードで仕事の
お話がある場合は
せっかくですから
開発しましょう
(あるいは、する方向で前向きに)
70 / 99

71. 注意点
契約形態は、工数型で
お客様いう Agile と Scrum の意味を確認しておく
本来の意味かもしれないし
ユニークな発想によるものかもしれません。
どんな意図であったとしても、少なくとも、心構えができます。
71 / 99

72. 社内開発に
ぜひ一度、
72 / 99

73. 社内開発に
ぜひ一度、
採用おねがいします
73 / 99

74. 社内開発に
自律的なチーム
『人、と、組織、を成長させる』
魅力的じゃないですか？
74 / 99

75. 社内開発に
Scrum を使いこなすのは、容易ではないかもしれませんが、
有効なフレームワークだと思います。
75 / 99

76. 社内開発に
Scrum を使いこなすのは、容易ではないかもしれませんが、
有効なフレームワークだと思います。
76 / 99

77. おわり
77 / 99

78. もっとスクラムについて知りたい
かたは
スクラムガイド
http://www.scrumguides.org/download.html
Scrum Primer(日本語版)
http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf
78 / 99

79. おまけ
79 / 99

80. へー、って思ったこと
80 / 99

81. その１
81 / 99

82. Scrum のほうが Agile より歴史が古
い
Scrumは、 1993年
アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development)
2001年 17名の共通認識を宣言として発表。
82 / 99

83. その２
83 / 99

84. Agile アジャイルは状態
84 / 99

85. Agile アジャイルは状態
アジャイルは状態を表す言葉
Be Agile. Not Do Agile.
85 / 99

86. Agile という単語を、間違って使っ
た会話の例
開発 Aさん
このプロジェクトは 「アジャイルプロジェクトマネジメン
ト」します。
顧客担当 Bさん
そうですね。 「アジャイル開発」のほうがリスクが低そうですしね。
顧客課長 Cさん
A さん、しっかり チームを管理お願いしますね
86 / 99

87. Agile アジャイルは状態
アジャイルプロジェクトマネジメント
87 / 99

88. Agile アジャイルは状態
アジャイルプロジェクトマネジメント
というものはありません。
『出版時に、キャッチコピーとして、使っちゃったんですが、。。。
失敗でした 』
ほんとは、「 Bussiness Fucilitation 」って呼ぼうと思ったんですが Agile のほうが、「キ
ャッチ―でしょう。」って出版社がいうので。。。
とのこと
88 / 99

89. なので
89 / 99

90. Agile アジャイルは状態
アジャイル開発する
90 / 99

91. Agile アジャイルは状態
アジャイル開発する
できません。
Be Agile. Not Do Agile.
Agile は状態なので「する」ことはできません
「Scrumで開発したら、アジャイルな状態になれた。」 という感じが、意図する意味合い
91 / 99

92. Agile アジャイルは状態
『Agile という単語は、「青春」という単語
と同じような使い方をするとイメージす
るとよい』
(トレーナーの江端さん 談)
92 / 99

93. 「Agile」 と 「青春」の用例
あの時は、 Agile だったなー
あの時は、青春だったなー
こんな風に、Agile という単語は 青春 という単語使い方が似ています。
93 / 99

94. 「Agile」 と 「青春」の用例
Agile する
青春する
するものじゃないので、両方変な感じになります。。。
「青春する」はコントのセリフならギリギリセーフです。。。
94 / 99

95. おまけ (その3)
95 / 99

96. アジャイルソフトウェア開発宣言
で一番大事なこと
参考：アジャイルソフトウェア開発宣言 の序文
「4つの価値」
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
96 / 99

97. アジャイルソフトウェア開発宣言
で一番大事なこと
参考：アジャイルソフトウェア開発宣言 の序文
一番、重要なのは「4つの価値」だと思
ってましたが、
もっと大事なものがありました。
97 / 99

98. アジャイルソフトウェア開発宣言
で一番大事なこと
最初に書かれている序文が重要
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて。。。
最も重要なこと
始めること
助けること
98 / 99

99. おまけ
おわり
99 / 99