Agile Japan '12 Agileな開発からAgileな組織へ

2012年3月に実施されたAgile Japanメイン会場でのセッション資料です。質問等は@ryuzeeにお願いします。
http://www.ryuzee.com/

Transcript

1. アジャイルな開発から アジャイルな組織へ 〜～継続的に価値を届けるために進むべき道〜～ h"p://bit.ly/wYu/U 2012/3/16  Agile  Japan  2012 Ryutaro  YOSHIBA
2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
3. http://www.ryuzee.com/
4. @ryuzee
6. SSccrruumm BBoooott CCaammpp
7. h"p://bit.ly/zp22Aw 大阪開催決定！ 66//1166((土))
8. 今年も1100 月後半頃に Scrum Gathering Tokyo を開催予定
9. 本⽇日の資料料は後⽇日公開します http://slideshare.net/ryuzee
10. よろしく お願いします
11. アジェンダ ü 自己紹介 （55分） ü 企業のおかれた状況 （1155分） ü AAggiilleeな開発 （2255分） ü AAggiilleeな組織 （2255分） ü まとめ・質疑応答 （1100分） ※あくまで予定です…
12. http://bit.ly/vj0b0v
13. 11.. 企業のおかれた状況 http://bit.ly/ptKnqR
14. ビジネスをとりまく 環境の変化
15. IITT投資は業務効率化 から戦略実現へ
16. 以前の競争 http://bit.ly/rioQDZ
17. 現在の競争 競争の速度の変化
18. 迅速な 意思決定 が必要 http://bit.ly/pccwAN
19. 意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL
20. ビジネスモデルの賞味期限が短縮
21. 変化への対応 “事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか？
22. 変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
23. 変化に対応できなければ マーケットから 見捨てられる
24. 価値がなくなれば滅びる http://bit.ly/qJg8EX
26. 顧客が説明した要件 顧客が本当に必要 だった物
27. 価値を 高めない 各種現象や 結果を ムダと呼ぶ
28. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
29. システムの機能の利利⽤用割合 4455 %% 1199 %% 1166 %% 1133 %% 77 %% Standishの2000年年の調査より   いつも使う よく使う たまに使う ほとんど使わない まったく使わない
30. 6644%% の機能は、使われない http://bit.ly/olku51
31. 顧客が説明した要件 顧客が本当に必要 だった物
32. 我々が解 決すべき 問題は何 なのか？ http://bit.ly/qgox0e
33. h"p://bit.ly/x6Mznh
34. マーケットに製品 を早期に投入�して 投資を回収し利益 に結びつける必要 性がある
35. フィーチャー駆動・ スコープ駆動から価 値駆動へ。ビジネス 価値を評価せよ
36. 22.. AAggiilleeな開発
37. AAggiilleeな開発 してますか？ http://bit.ly/shZMnK
38. WWFFは長編映画 http://bit.ly/z0f0eo
39. AAggiilleeはTTVVドラマ http://bit.ly/wlJQzm
40. 計画づくりの頻度度と 計画の粒粒度度が、AgileとWF では異異なる
41. ソフトウェアの不不確実性 ü 不不確実性コーン From  10  Deadly  Sins  of  Software  Estimation  by  Steve  McConnell,  ©2002-‐‑‒2007
42. 納期の確率率率分布 ü ソフトウェアの納期予測は確率率率分布である ⼀一般的にプロジェクトマネージャがリリース可能⽇日を設定する場合、 最もリリースできる確率率率が⾼高い⽇日を選ぶが、その⽇日にリリースできな い可能性の⽅方が⾼高い
43. 予測困難 という前提にたち 小さい成功を 繰り返す
44. Agileはリスクマネジメント ü ビジネス環境が変化するリスク ü 事前の予測が外れるリスク ü 必要なものが必要な時に出来上がらないリスク ü 無駄なコストが発⽣生するリスク 時間の経過 リスク度度
45. 基本コンセプトはAgileマニフェスト
46. 1122個の原則
47. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
49. 毎日何回も本番環境にデプロイで きているか？((可能か？)) 顧客に頻繁に価値を届けられてい るか？
50. 通常のリリース ü ςετ͕׬͔ྃͯ͠Β
    ϦϦʔε·Ͱ೔Ҏ಺ʁ
    ü ςετ͕׬͔ྃͯ͠Β
    ϦϦʔε·Ͱ೔Ҏ಺ʁ
    ü ςετ͕׬͔ྃͯ͠Β
    ϦϦʔε·ͰिؒҎ಺ʁ
    ü ͦΕҎ্͔͔Δʁ
    h"p://bit.ly/wo4eyD
51. 障害時のリリース ü ςετ͕׬͔ྃͯ͠ΒϦϦʔε·Ͱ೔Ҏ಺ʁ
    
    ü ςετ͕׬͔ྃͯ͠ΒϦϦʔε·Ͱ೔Ҏ಺ʁ
    
    ü ςετ͕׬͔ྃͯ͠ΒϦϦʔε·ͰिؒҎ಺ʁ
    
    ü ͦΕҎ্͔͔Δʁ
    h"p://bit.ly/zeFv2G
52. 障害時に11日でリリース できるのであれば、 今のリリースプロセスに は組織的な無駄がある
53. 継続的デリバリーとは何か？ 継続的デリバリーとはリリースのスケジュール をIITT部門が握るのではなく、ビジネス部門が 握るということだ。継続的デリバリを実装する ということは、全体のライフサイクルを通じて 常にソフトウェアが本番環境にリリース可能で あるということを意味する。すなわちどのビル ドもボタン一発で、完全に自動化されたリリー スプロセスを通じて、秒とか分の時間で利用者 にリリース可能である、ということだ。 JJeezz HHuummbbllee
54. http://bit.ly/tFrqbz 継続的デリバリー ユーザーとプロジェクトチームの間に 固いフィードバックループを作る
55. 継続的デリバリー 継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる http://bit.ly/uLQaml
56. http://bit.ly/vPmiFJ 一日にしてならず
57. http://bit.ly/vj0b0v NNoo SSiillvveerr BBuulllleett† 
58. http://bit.ly/sygcE9 自分たちのプロセス は自分たちで進化さ せるしかない！
59. ツールやプラク ティスを導入�す るとアジャイル な開発になる というのは 幻想 http://bit.ly/pQrRmy
60. アジャイルな開発の⼿手法  　 　 　 　 　 　 　 　 　 　 　 　 Scrum XP Lean FDD Crystal AUP他
61. プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム  (7±2⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす Doneの定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり
62. 2〜～4週間に 区切切って 繰り返す http://www.flickr.com/photos/tonivc/2283676770/
63. Doneの定義 何ができたら 完了了なのかを 決める
64. ふりかえり 　 　 　 　 　 　 　 　 　 　 ü  短い間隔でうまくいったこと、うまく⾏行行かな かったことを確認する ü  次はもっと良良くする(できることから)
65. プラクティスの話  　 　 　 　 　 　 　 　 　 　 　 　 •  朝会 •  プロダクトバックログ •  スプリント •  振り返り •  ペアプログラミング •  継続的インテグレーション •  ストーリーカード •  全員同席 •  コードの共同所有 •  テストファースト •  リファクタリング •  リリース計画 このプラクティスはやってない ウチではこうやってる ベストプラクティスはこうだ…� 話が盛り上がる！
66. しかし 手法は 目的を実現するための 道具に過ぎない
67. 目 的 重 要　　　　　 http://www.flickr.com/photos/alwaysbecool/2796977195/
68. Agile  　 　 　 　 　 　 　 　 　 　 　 　 　 　 形容詞 　11 敏捷な,, 機敏な,, すばしこい,, はしこい 　22 活発な,, いきいきとした頭の切れる,, 頭の回転が早い 　　　小学館『プログレッシブ英和中辞典 第44版』より http://www.flickr.com/photos/practicalowl/4098547561/
69. 形容詞  　 　 　 　 　 　 　 　 　 　 　 　 物事の 性質や 状態を 表す http://www.flickr.com/photos/tomroyal/107653935/
70. h"p://bit.ly/yo7Fo7
71. h"p://bit.ly/xKgVwh カ イ ゼ ン し て る ？
72. h"p://bit.ly/zkrl3t Inspect and Adapt
74. 我社も(Agile|Scrum|XP)やればうまくいく! (ﾟДﾟ)ﾊｧ?
75. Don't Do Agile, Be Agile
77. 守破離 http://bit.ly/qRvi51
78. h"p://bit.ly/zLyLc0 チームの能力を 最大限に発揮する
79. IteraOve   Development ConOnuous   IntegraOon ConOnuous   Deploy Con$nuous  Delivery Enterprise  Value  Crea$on Strategic  Impact Adaptability  /  Agility
80. 製品そのものを AAggiilleeな状態に 保つ
81. 技術的負債を 少なく保つ
82. 品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく（＝価値への投資が減少）
85. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
87. AAggiilleeな開発 してますか？ http://bit.ly/shZMnK
88. AGILEな組織 33.. AAggiilleeな組織 http://bit.ly/ndgMJ6
89. XP 技術⾯面を⾼高め る Scrum 価値あるものから継続 的に製品を届ける Lean 企業活動⾃自体の 全体最適化 チーム マネージャ 経営者
90. 組織における問題点 h"p://bit.ly/yFe3Za
91. 組織規模の拡大 →問題の深刻化 h"p://bit.ly/xHSLfl
92. h"p://www.flickr.com/photos/_suika/3913063515/ 組織分割における 顧客価値との不一致
93. コンウェイの法則 “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” http://bit.ly/oIUrUI
94. ü 規則の意図が理理解されず、ただ制約化される ü 仕事のための仕事？？？ h"p://www.youtube.com/watch?v=4u5N00ApR_k リリースは2週間に1回で、 かつ2週間前までに申請してく ださい。 もっと頻繁に すぐできないの？ 規則で決まってるし、 忙しいんです。
95. ピラミッド組織 ピラミッド 組織は、同質 なものを受け 入�れ、異質な ものを受け入� れられない。 http://bit.ly/qpntdu
96. 組織のマネー ジャや上級管 理職、経営者 の一部は変化 に踏み出せな い。 組織に対する背任 http://bit.ly/nMHv6P
97. http://bit.ly/paHrVi 抵抗勢力は かならず発 生する
98. 人は、有能な間は昇 進を続ける。 昇進して仕事が変化 した結果、無能にな ると昇進がとまる。 そのため、階層社会 の上の方には、無能 な人であふれ返る。
99. コマンドコントロール 上司の命令に 従っていれば 良い、という 価値観
100. コマンドコントロールの問題 ü メンバーはやらされ感を持つ ü 上司の指示を遵守したかどうかが 評価の観点に ü 人が育たない。通常は上司の劣化 コピーに…� ü 現状に不満をもつ優秀な人から順 に退職…�
101. h"p://bit.ly/zjyVUl チーム解体による 連続性の放棄�
102. 稼働率という名の幻想 h"p://bit.ly/AiGcma
104. チームを強く保つ h"p://bit.ly/ygbMSj
105. スクラムマスター ü  スクラムプロセスをうまくまわす ü  外部の⼲干渉からチームを守りチームを集中させる ü  仕事を進める上での障害事項を解決する
106. 実行責任？ 説明責任？ 結果責任？ …� PPOOの責任は？ SSMMの責任は？ チームの責任は？ 管理職の責任は？ 経営者の責任は？ 個人の責任は？
107. http://bit.ly/mRCCGH
108. チームの責任 チームが 「全力で選択したス トーリーをDDoonneeに しようとする」 ことをコミットメン トと呼ぶ これは チームの責任であり、 個人の責任ではない http://bit.ly/pKXeZh
109. 見積もりはコミッ トメントではない しかし多くの場合 見積もりがコミット メントとして扱われ る悪い習慣がある http://bit.ly/pOfAGO
110. 常に 改�善する 責任 http://bit.ly/mRLszj
111. プラクティス の採用理由を チームや 顧客や ステークホル ダーに 説明する責任
112. チームのルールに従う責任 ü デイリースクラムに出席する責任 ü 完了の定義に従って作業を行う責任 ü チームメンバーを助ける責任 ü チームメンバーを育てる責任 http://bit.ly/qFy4Aq
113. ⼈人材育成の責任 チームが人を育 てる OOJJTTによるマン ツーマンな人材 育成ではなく、 チーム全員が協 力しあってお互 いの能力を向�上 させる http://bit.ly/qb0Jd4
114. ふりかえりによる改善
116. http://bit.ly/nK3hBr ××してはいけない？
117. ◦◦しよう！！
118. 競争優位は個人と集 団の両方の継続的学 習から生まれる。 学習する組織とは 「チームが目的を達 成するための能力と 気づきの状態を高め 続ける組織」
119. ü メンタルモデル ü 自己マスタリー ü システム思考 ü 共有ビジョン ü チーム学習 // ダイアログ
120. メンタルモデル マインドセットやパラダイムを含め た「世の中や事象に関する前提」 http://bit.ly/nRFmiT
121. ⾃自⼰己マスタリー 自分がどうあり たいか、何を作 り出したいかに ついて理解しつ つ、現実との差 を認識し、それ に向�かって行動 する http://bit.ly/q2RSEq
122. システム思考 物事を一連の要 素のつながりと してとらえ、そ のつながりの相 互作用に注目す る。全体最適化 や複雑な問題解 決の手法として 用いる http://bit.ly/nZTDdS
123. 共有ビジョン 組織を構成する人のそ れぞれのビジョンを重 ねて、組織として共有 し浸透可能なビジョン を作るプロセス http://bit.ly/nvZhqo
124. 命令 説得 テスト 相談 協創 http://bit.ly/p2KAjx
125. “リッツ・カールトンはお客様への心 のこもったおもてなしと快適さを提供す ることをもっとも大切な使命とこころ えています。 私たちは、お客様に心あたたまる、くつ ろいだそして洗練された雰囲気を常にお 楽しみいただくために最高のパーソナ ル・サービスと施設を提供することをお 約束します。” リッツカールトンのクレドより抜粋
126. “リッツ・カールトンではお客様へお約束した サービスを提供する上で、紳士・淑女こそが もっとも大切な資源です。 　信頼、誠実、尊敬、高潔、決意を原則とし、 私たちは、個人と会社のためになるよう、持て る才能を育成し、最大限にのばします。 　多様性を尊重し、充実した生活を深め、個人 のこころざしを実現し、リッツ・カールトン・ ミスティークを高める‥リッツ・カールトンは、 このような職場環境をはぐくみます。” リッツカールトンの従業員への約束より
128. チーム学習・ダイアログ お互いのメンタルモデルに対す る理解を深めること。集団での 気づきの状態を高める
129. ⾃自⼰己組織化 ü 上司は責任とチームで解消で きない問題の解決を担う ü 上司は後方支援、ファシリ テーター役になる ü チームを信じる http://bit.ly/r0Lc8F
130. 自己組織化されたチームで仕事を できるようにするためには、 外部からのマイクロマネジメント を止める必要がある。 http://bit.ly/ovenYk
131. リーダーや管理理職の役割の変化 ü  従来の役割や振る舞い ü ピラミッド組織 ü コマンド・コントロール ü 権威的 ü 流動性がない ü 答えをいう ü 叱る ü 否定 ü マイクロマネジメント ü  求められる役割や振る舞い ü ネットワーク型組織 ü 自律・自発の支援 ü 民主的 ü 流動性のある ü 導く ü 褒める ü 肯定 ü チームの自主性に任せる
132. リーダーシップのモデル(SL理理論論) http://www.situational.com/ 　より図を引⽤用
133. 権限の7レベル ü 指示する ü 売り込む ü 相談する ü 同意する ü アドバイスする ü 問い合わせる ü 移譲する
135. 全てのアジャイルなプロセスはチームへの 権限移譲とチーム内での文化および規範の 確立を必要とする http://bit.ly/pdq0xn
136. ⼈人事評価のやり⽅方 ü 個人単位の評価からチーム単位の評価 ü 単一の評価者からチームメンバーを含め た評価へ http://bit.ly/r00mRp
137. アンチパターン アジャイルな開発における透明性を そのまま人事評価に利用する。 （こなしたタスク数など） http://bit.ly/px6oa1
138. 個人の評価はチーム全員から「チームへの貢献 度」「プロジェクトや顧客への貢献度」を中心に 収集する http://bit.ly/pUG9Gp 対応策
140. キャリアパス 名選手名監督 にあらず。 開発のプロが 経営のプロと は限らない。 逆もまた然り http://bit.ly/mUtDl7
141. 採⽤用プロセス
142. よくある問題 ü 固定化された企業イメージによって応募 者の属性が偏る ü 面接官個人の判断に左右される ü そのため似たタイプの人材が多くなる ü 数回の面接では能力の見極めは困難
143. h"p://bit.ly/ywESRI
145. 組織の多様性は強さ http://bit.ly/qEBgGV
148. “Scrum is a framework for surfacing organizational dysfunction.” Tobias Mayer SSccrruummは組織の機能不全を明るみに 出すためのフレームワークである
149. スクラムマスターは 解雇されて一人前！ h"p://bit.ly/xnoOUO
150. 健闘を 祈ります h"p://bit.ly/zJczAB