1. アジャイルな開発から アジャイルな組織へ 〜～ 継 続 的 に 価 値 を 届 け る た め に 進 む べ き 道 〜～ 2012/3/16 Agile Japan 2012 h"p://bit.ly/wYu/U Ryutaro YOSHIBA
2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
3. http://www.ryuzee.com/
6. SSccrruumm BBoooott CCaammpp
7. 大阪開催決定！ 66//1166((土)) h"p://bit.ly/zp22Aw
8. 今年も1100 月後半頃に Scrum Gathering Tokyo を開催予定
9. 本⽇日の資料料は後⽇日公開します http://slideshare.net/ryuzee
11. アジェンダ ü 自己紹介 ü 企業のおかれた状況 ü AAggiilleeな開発 ü AAggiilleeな組織 ü まとめ・質疑応答 ※あくまで予定です… （55分） （1155分） （2255分） （2255分） （1100分）
13. http://bit.ly/ptKnqR 11.. 企業のおかれた状況
16. 以前の競争 http://bit.ly/rioQDZ
18. 迅速な 意思決定 が必要 http://bit.ly/pccwAN
19. 意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL
21. 変化への対応 “事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか？
22. 変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
23. 変化に対応できなければ マーケットから 見捨てられる
24. 価値がなくなれば滅びる http://bit.ly/qJg8EX
26. 顧客が説明した要件 顧客が本当に必要 だった物
27. 価値を 高めない 各種現象や 結果を ムダと呼ぶ
28. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
29. システムの機能の利利⽤用割合 いつも使う 77 %% よく使う 1133 %% 4455 %% たまに使う 1166 %% ほとんど使わない 1199 %% まったく使わない Standishの2000年年の調査より
30. http://bit.ly/olku51 6644%% の機能は、使われない
31. 顧客が説明した要件 顧客が本当に必要 だった物
32. 我々が解 決すべき 問題は何 なのか？ http://bit.ly/qgox0e
34. マーケットに製品 を早期に投入�して 投資を回収し利益 に結びつける必要 性がある
35. フィーチャー駆動・ スコープ駆動から価 値駆動へ。ビジネス 価値を評価せよ
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はリスクマネジメント リスク度度 ü ビジネス環境が変化するリスク ü 事前の予測が外れるリスク ü 必要なものが必要な時に出来上がらないリスク ü 無駄なコストが発⽣生するリスク 時間の経過
47. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
49. 毎日何回も本番環境にデプロイで きているか？((可能か？)) 顧客に頻繁に価値を届けられてい るか？
50. 通常のリリース ü テストが完了してから リリースまで1日以内？ ü テストが完了してから リリースまで3日以内？ ü テストが完了してから リリースまで1週間以内？ ü それ以上かかる？ h"p://bit.ly/wo4eyD
51. 障害時のリリース ü テストが完了してからリリースまで1日以内？ ü テストが完了してからリリースまで3日以内？ ü テストが完了してからリリースまで1週間以内？ ü それ以上かかる？ 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. NNoo SSiillvveerr BBuulllleett† http://bit.ly/vj0b0v
58. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9
59. ツールやプラク ティスを導入�す るとアジャイル な開発になる というのは 幻想 http://bit.ly/pQrRmy
60. アジャイルな開発の⼿手法 Scrum XP Lean Crystal FDD AUP他
61. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
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/
71. h"p://bit.ly/xKgVwh しカ てイ るゼ ？ン
72. Inspect and Adapt h"p://bit.ly/zkrl3t
74. 我社も(Agile Scrum XP)やればうまくいく! (ﾟДﾟ)ﾊｧ?
75. Don't Do Agile, Be Agile
77. 守破離 http://bit.ly/qRvi51
78. チームの能力を 最大限に発揮する h"p://bit.ly/zLyLc0
79. Enterprise Value Crea$on Adaptability / Agility Con$nuous Delivery ConOnuous Deploy ConOnuous IntegraOon IteraOve Development Strategic Impact
80. 製品そのものを AAggiilleeな状態に 保つ
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. http://bit.ly/ndgMJ6 AGILEな組織 33.. AAggiilleeな組織
89. Lean 経営者 Scrum マネージャ 企業活動⾃自体の 全体最適化 価値あるものから継続 的に製品を届ける XP 技術⾯面を⾼高め る チーム
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. ？ は 任 責 の OO PP 管理 ？ は 責任 の 職 ？ は 任 責 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. ⼈人材育成の責任 http://bit.ly/qb0Jd4 チームが人を育 てる OOJJTTによるマン ツーマンな人材 育成ではなく、 チーム全員が協 力しあってお互 いの能力を向�上 させる
116. http://bit.ly/nK3hBr ××してはいけない？
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 名選手名監督 にあらず。 開発のプロが 経営のプロと は限らない。 逆もまた然り
142. よくある問題 ü 固定化された企業イメージによって応募 者の属性が偏る ü 面接官個人の判断に左右される ü そのため似たタイプの人材が多くなる ü 数回の面接では能力の見極めは困難
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
