認定スクラムマスター研修に行ってきました

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

1 / 99

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

2 / 99

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

3 / 99

本日の、私の目標　スクラムに興味を持ってもらえること　です

細かい説明はしませんので、Scrum自体の概要をしっかり知りたいという方は、あとで資料をご紹介します。

4 / 99

研修はどんな感じだったか

5 / 99


簡単にご紹介

6 / 99

日時 : 2014年 8月 7日 (木) - 8月 8日 (金)

場所 : 京都烏丸コンベンションホール

京都烏丸コンベンションホール Webページ

名前からの先入観で、すごく大きいところを想像していたのですが、以外にコンパクトでした。（駅員さんに訊いても知りませんでした）先入観で決めつけるのはいけないという教訓になりました。

参加者

半分が関東の方、半分が関西の方

7 / 99

http://karasuma.conventionhall.jp/

トレーナー : 江端一将さん

日本人で唯一のアジャイルトレーナー

かつて大規模プロジェクトのプロダクトオーナーを経験された

プロダクトオーナー・・・ Scrumの役割の一つROI最大化するために、プロダクト方向性を決める人

チーム・・・ Scrumの役割の一つ開発を進める主体である、人々。コストを安価に開発する責任が課せられている

スクラムマスター・・・ Scrumの役割の一つ開発が Scrum と呼べる状態にする人。

8 / 99

「体験する」「考える」ことを重視している内容でした

内容の例

本日の参加者で Scrum をどのぐらい知っているかについて、順番を付けてください

研修中のルールを皆さんで決めてください

ゲームやロールプレイ

現場で起こそうな雰囲気

色々『気づき』があり、刺激的でした

(私個人の感想です)

9 / 99

Scrum をやる機会がなかったとしても

新鮮な考え方が得られて有意義な研修だったと感じました。

10 / 99


11 / 99

おわり

12 / 99

本題に移ります

13 / 99

印象深かったポイント

14 / 99

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

15 / 99


失敗を減らしたり、

開発の効率を上げたり、

素早く開発できたり、

簡単に開発できたり、

品質を向上が期待できたり、

16 / 99

そういうことを

解決する

フレームワークでは

ありません誤解していました。。。

17 / 99

Scrum の重要なキー (Keys)

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

18 / 99



* Three Keys (Scrum のキーポイント。三本柱)

19 / 99




* 透明性 -- Transparency * 検証 -- Inspect * 適合 (検証に基づいた適合) -- Adapt

20 / 99




* 透明性 -- 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

「透明性 -- Transparency」

22 / 99

三本柱の中の「透明性 -- Transparency」を最も重要視しています

「say "It's done."」を撲滅する

「もう、ほとんどできてます。」「90%できた (?) 」っていうのはなくす

ガントチャートに、こういう状況、よく出てきませんか？

23 / 99

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

24 / 99

Ken Schwaber氏の談話の動画

スクラムは誰でも始められる・・・

1回目のスプリント結果が、チームの実力を教えてくれる

25 / 99




チームが、「優秀」か、「靴紐が結べないほどの間抜け」か

26 / 99





Scrum の特徴は

「軽量」、「理解が容易」、、、

27 / 99





Scrum の特徴は

「軽量」、「理解が容易」、、、「習得は非常に困難」

28 / 99


29 / 99


現状をあぶりだすフレームワーク

問題をあぶりだすフレームワーク

30 / 99


素晴らしいチームはより素晴らしく、

そうでないチームはそれなりに、

(Fフイルム風。知っている人は、かなりご年配。文責：柳川。)

31 / 99


良いところも、悪いところも、明らかにして

状況に適応していくことで

チームの力を、発揮させようとします

32 / 99

＞＞

33 / 99

自律的なチーム

34 / 99


チームがチームを管理する

スクラムマスターは管理者ではない

チーム・・・ Scrumの役割の一つ開発を進める主体である、人々。コストを安価に開発する責任が課せられている

スクラムマスター・・・ Scrumの役割の一つ開発が Scrum と呼べる状態にする人。

プロダクトオーナー・・・ Scrumの役割の一つROI最大化するために、プロダクト方向性を決める人

35 / 99


チームで方針を相談する

チームの進捗は、チームが管理する

チームの方針に沿い、個人が判断して作業する。 (0.1秒以内で判断して)

個人は、チームに結果をフィードバックする

36 / 99


スクラムマスターは

管理したり、直接手伝ったりしてはいけない

チームが困っているときに助言するチームの邪魔をしそうな「人」「もの」「イベント」「人と人とのトラブル」などの

あらゆる障害を取り除く

37 / 99


チームがチームを管理することによりチームは成長していきます。

チームのメンバーも成長していきます。

38 / 99


チームがチームを管理することによりチームは成長していきます。

チームのメンバーも成長していきます。

なんか、いいと思いませんか？

39 / 99

＞＞

40 / 99

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

41 / 99

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

実際の経験と既知に基づく判断によって知識が獲得できる

経験的プロセス制御の理論（経験主義）(注: 哲学、心理学の文脈ででてくる「経験主義」とは異なる模様)

42 / 99

具体的な例 (既知に基づく判断)

人間は将来を予測するのが下手

人間は絶対値の見積もりが下手

. 　　

では、上から順に。。。

43 / 99


より未来になればなるほど、予測があたらない

大事だとことも、大事でなくなる

44 / 99


こんな感じです。たぶん。。

↑予測はずれ率 │ | │ / │ | │ / │ / │ _/ │ __/ │ ___/ │ _____/ │ ______/ │ _______/ │ ________/ │ _________/ │ __________/ │/ 未来＋---------------------------------------------------------->

45 / 99


このため、

＝＝＞次のスプリントしか詳細に見積もりしない

反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う

スプリントScrumでは、1週間、や、2週間、など、期間を区切って開発する。スプリントはその、１つの期間のこと。

46 / 99


47 / 99


どちらが当てやすいか？ (誤差が小さいか?)

このペットボトルの黒い部分は何センチですか

このペットボトルの黒い部分は白い部分の何倍ですか

この紙は、何平方センチですか

この紙は、あの紙の何倍(何分の何)ですか

48 / 99


このため、

＝＝＞　相対的に見積る

相対的に見積もったほうが、誤差が小さい

見積もりの基準になる、項目を決めて、「何倍か？」という風に見積もる。

「プランニングポーカー」という手法が研修で紹介されました

(研修でカードももらいました。)

紹介しているサイトの一例(検索するといっぱい引っかかります)プランニングポーカー簡単ガイド作りました --http://d.hatena.ne.jp/wayaguchi/20120218/1329524230

49 / 99

http://d.hatena.ne.jp/wayaguchi/20120218/1329524230

http://d.hatena.ne.jp/wayaguchi/20120218/1329524230

＞＞

50 / 99

Scrumに適するプロジェクトは

51 / 99

Scrumに適するプロジェクトは要件が不明確

↑ └+ │ ｜カオス │ └+ │ ｜ │ └---+ │--┐ ｜ │ +---┐ └+----------------+ │ │ ｜ │ 複雑 +┐ └--------- │ +┐ │ │ 複合的に複雑 │ ┐ │ │ │ │ │--┐ │ │ +---┐ │ │ +--┐----------------┐ │ +-┐ ┐ │ 単純 │ 複雑 │ │ +┐ +┐ │ │ │ ＋----------------------------------------------------------> 技術が難しい・新しい 52 / 99


適するのは、単純なプロジェクト以外

単純なプロジェクトは不得意

実現する内容が単純明快やりたいこと(要件)が明らかやりたいこと(要件)が変更されない実現方法が分かっている。もしくは、決まっていて、失敗する可能性が小さい。

単純なプロジェクトであればあるほとは、「ウォータフォール」&「一括契約」がおすすめです。（なぜなら、変更されないことが「ウォータフォールの前提」だから）

53 / 99


採用例

ユーザー企業の内製プロジェクトに、採用例が多い模様。

内製プロダクトの場合、公表するメリットがなく公表されないことが多いとのこと。メディアには露出しにくい模様。

54 / 99


内製以外では工数精算

一括請負契約は不得意

55 / 99

感想

56 / 99

感想

ルールに厳格だけど、自由にルールを決められる

役割ごとの責任に厳しい

57 / 99

ルールに厳格だけど、自由にルールを決められる

Scrum自体のルールは、全部守る必要あり

Scrum のキーワード 19個 ... (2014年8月現在)一部だけ適用することは可能だが、それは、Scrum ではない別の何かScrumの要素を一部だけ適用して「Scrumうまくいかない」というのは的外れ

一方、チームが独自で決めるルールは。。。

制約少ない。柔軟開発コストを下げるためなら、あらゆる発送を駆使して、何を試みてもよい「チームが決めた」ことは守らないといけない

58 / 99


59 / 99


責任を果たしていない場合は追及する

60 / 99


責任を果たしていない場合は追及する

責任を奪ってはならない

では、順に。。。

61 / 99


プロダクトオーナーも、スクラムマスターも、管理者ではない。

チームとは対等。責任範囲を越境してはいけない

チームは「コストを最小にする」代案があれば、プロダクトマスターが選択できるようにしなくてはならない。プロダクトオーナーはビジョンを示さなければいけない。スクラムマスターは、チームが開発に専念できるようにしなければいけない。

プロダクトオーナーは優先順位を決定しなければいけ

ない。(優先度ではない)「チーム」に指示したり、命令したり、高圧的に選択を強

いたりして、委縮させるのはもっともダメ

など。。。62 / 99


ゴチャゴチャし過ぎました。

すいません

63 / 99

＞＞

64 / 99

最後に

65 / 99

私が考える SIer の

Agile や Scrumに対するお奨め戦略は

66 / 99



『Scrum なんて知らない』ふりをする

67 / 99



『Scrum なんて知らない』ふりをする

『Scrum が優秀』と思った顧客は内製開発してしまう

一括契約で Scrum を採用すのはイバラの道

68 / 99

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

69 / 99

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

せっかくですから

開発しましょう

(あるいは、する方向で前向きに)

70 / 99

注意点

契約形態は、工数型で

お客様いう Agile と Scrum の意味を確認しておく

本来の意味かもしれないしユニークな発想によるものかもしれません。どんな意図であったとしても、少なくとも、心構えができます。

71 / 99

社内開発に

ぜひ一度、

72 / 99

社内開発に

ぜひ一度、

採用おねがいします

73 / 99

社内開発に

自律的なチーム　

『人、と、組織、を成長させる』　

魅力的じゃないですか？

　

74 / 99

社内開発にScrum を使いこなすのは、容易ではないかもしれませんが、

有効なフレームワークだと思います。

75 / 99

社内開発にScrum を使いこなすのは、容易ではないかもしれませんが、

有効なフレームワークだと思います。

76 / 99

おわり

77 / 99

もっとスクラムについて知りたいかたは

スクラムガイド

http://www.scrumguides.org/download.html

Scrum Primer(日本語版)

http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf

78 / 99

http://www.scrumguides.org/download.html

http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf

おまけ

79 / 99

へー、って思ったこと

80 / 99

その１

81 / 99

Scrum のほうが Agile より歴史が古い

Scrumは、 1993年アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development)

2001年 17名の共通認識を宣言として発表。

82 / 99

その２

83 / 99

Agile アジャイルは状態

84 / 99


アジャイルは状態を表す言葉

Be Agile. Not Do Agile.

85 / 99

Agile という単語を、間違って使った会話の例

開発 Aさん

このプロジェクトは「アジャイルプロジェクトマネジメント」します。

顧客担当 Bさん

そうですね。「アジャイル開発」のほうがリスクが低そうですしね。

顧客課長 Cさん

A さん、しっかりチームを管理お願いしますね

86 / 99


アジャイルプロジェクトマネジメント

87 / 99


アジャイルプロジェクトマネジメント

というものはありません。

『出版時に、キャッチコピーとして、使っちゃったんですが、。。。失敗でした』ほんとは、「 Bussiness Fucilitation 」って呼ぼうと思ったんですが Agile のほうが、「キャッチ―でしょう。」って出版社がいうので。。。

とのこと

88 / 99

なので

89 / 99


アジャイル開発する

90 / 99


アジャイル開発する

できません。

Be Agile. Not Do Agile.

Agile は状態なので「する」ことはできません

「Scrumで開発したら、アジャイルな状態になれた。」という感じが、意図する意味合い

91 / 99


『Agile という単語は、「青春」という単語と同じような使い方をするとイメージするとよい』

(トレーナーの江端さん談)

92 / 99

「Agile」と「青春」の用例

あの時は、 Agile だったなー　あの時は、青春だったなーこんな風に、Agile という単語は青春という単語使い方が似ています。

93 / 99

「Agile」と「青春」の用例

Agile する　青春するするものじゃないので、両方変な感じになります。。。

「青春する」はコントのセリフならギリギリセーフです。。。

94 / 99

おまけ (その3)

95 / 99

アジャイルソフトウェア開発宣言で一番大事なこと

参考：アジャイルソフトウェア開発宣言の序文

「4つの価値」

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、

96 / 99

http://agilemanifesto.org/iso/ja/


参考：アジャイルソフトウェア開発宣言の序文

一番、重要なのは「4つの価値」だと思ってましたが、

もっと大事なものがありました。

97 / 99

http://agilemanifesto.org/iso/ja/


最初に書かれている序文が重要

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて。。。

最も重要なこと

始めること

助けること

98 / 99

おまけ

おわり

99 / 99