1. DevOps時代の アジャイルな組織作り 2013/7/13 Ryutaro YOSHIBA
2. 吉羽 龍太郎 Ryutaro YOSHIBA クラウド・DevOpsとかの コンサルタント http://www.ryuzee.com/ Twitter: @ryuzee
3. http://www.ryuzee.com/
4. 好評発売中! 定価：2520円 http://www.seshop.com/ product/detail/15395/ #scrumbcbook
6. 顧客が説明した要件 顧客が本当に必要 だった物
8. システムの機能の利用割合 Standishの2000年の調査より
9. http://bit.ly/olku51 6644%% の機能は、使われない
10. 価値を 高めない 各種現象や 結果を ムダと呼ぶ
11. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
12. コストの見積りは正しいか？ • 不確実性コーン
13. ウォーターフォール(V字) 要件定義 受け入れ試験 ぎ す り か 要 か は が 時間 来た頃に も そ 出 も 、 そ て 。 い 化詳細設計 な 変 求が あってい かる が 分 件 で 要 こ こ が こと 基本設計 製造・単体 総合試験 結合試験
14. よくみかける光景 要件定義は順調です ○○設計は順調です 開発は遅れていますが挽回可能です 多くのリスクが後半になって顕 在化する。顕在化した時点では 取り返しがつかない 結合試験で重大な問題が出ています 受入れ試験でニーズ不一致が判明 リリースできません。てへっ
15. アジャイルマニフェスト • 2001年に、ケント・ベック、マーティン・ファウラー、ケ ン・シュウェイバーら、17人によって採択された Agileソフトウェア開発の原則を指す。
16. アジャイルマニフェスト 顧客満足を最優先し、価値のあるソフトウェアを 早く継続的に提供します。
17. このプロダクトにはこんなに沢山の機能が あります。バグも少なくコードも綺麗です 顧客はいないけど http://www.flickr.com/photos/untitlism/2603959306/
18. • クソプロダクトを良い方法論で作ってもやっぱり クソはクソ http://www.flickr.com/photos/mobilestreetlife/6898757499/
19. • ビジネス・お金を稼ぐためにつくる • やってみないと分からないことが多い • 作ること自体は目的じゃない http://www.flickr.com/photos/lilcrabbygal/218495576/
20. マーケットに製品を 早期に投入して 投資を回収し 利益に結びつける 必要性がある
21. Developers Summit • MVPとフィードバックループ • ビジネスの成長とプロダクトの成長を同期させる • そして組織も成長が必要になる http://www.flickr.com/photos/pagedooley/2120528888/
22. 予測困難 という前提にたち 小さい成功を 繰り返す
23. フィーチャー駆動・ スコープ駆動から価 値駆動へ。ビジネス 価値を評価せよ
25. 毎日何回も本番環境にデプロイ できているか？顧客に頻繁に価 値を届けられているか？
27. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
29. フィーチャー単位で完了 フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ 性能 性能 性能 性能 性能 性能 性能 デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ
30. 継続的デリバリー http://bit.ly/tFrqbz ユーザーとプロジェクトチームの間に 固いフィードバックループを作る
31. 継続的デリバリー http://bit.ly/uLQaml 継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる
32. 継続的デリバリーの原則 1 • ソフトウェアのリ リースやデプロイの プロセスは繰り返し 可能であり信頼性が 高い必要がある。
33. 継続的デリバリーの原則 2 • 全てを自動化する
34. 継続的デリバリーの原則 3 • 難解なことや苦痛な ことを繰り返し行い 自動化の方法を考え る
35. 継続的デリバリーの原則 4 • 全てをソースコード 管理システムで管理 する
36. 継続的デリバリーの原則 5 • 完了は「リリースさ れたこと」を意味す る
37. 継続的デリバリーの原則 6 • 品質を作りこむ
38. 継続的デリバリーの原則 7 • すべての人にリリー スプロセスに対して の責任がある
39. 継続的デリバリーの原則 8 • 継続的に改善する
40. Developers Summit よくある光景 運用でなんとかすんのが あんたらの仕事だろ てめーもっとちゃん とアプリ作れ ビジネス 開発 http://www.flickr.com/photos/makitani/3940687822/ 運用 あの∼、ビジネスの こと考えてよ
41. 通常のリリース ü テストが完了してから リリースまで1日以内？ ü テストが完了してから リリースまで3日以内？ ü テストが完了してから リリースまで1週間以内？ ü それ以上かかる？ h"p://bit.ly/wo4eyD
42. 障害時のリリース ü テストが完了してからリリースまで1日以内？ ü テストが完了してからリリースまで3日以内？ ü テストが完了してからリリースまで1週間以内？ ü それ以上かかる？ h"p://bit.ly/zeFv2G
43. 障害時に11日でリリース できるのであれば、 今のリリースプロセスに は組織的な無駄がある
44. http://bit.ly/sygcE9 自分たちのプロセス は自分たちで進化さ せるしかない
45. 一日にしてならず http://bit.ly/vPmiFJ
46. No Silver Bullet http://bit.ly/vj0b0v
47. アジャイルな開発 してますか？ http://bit.ly/shZMnK
48. Agile 形容詞 11 敏捷な,, 機敏な,, すばしこい,, はしこい 22 活発な,, いきいきとした頭の切れる,, 頭の回転が早い 小学館『プログレッシブ英和中辞典 第44版』より http://www.flickr.com/photos/practicalowl/4098547561/
49. 形容詞 物事の 性質や 状態を 表す http://www.flickr.com/photos/tomroyal/107653935/
51. h"p://bit.ly/xKgVwh しカ てイ るゼ ？ン
52. Inspect and Adapt h"p://bit.ly/zkrl3t
53. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
55. 我社も(Agile¦Scrum¦XP¦DevOps¦ANY) やればうまくいく! (ﾟДﾟ)ﾊｧ?
56. Don't Do Agile, Be Agile
58. ツールやプラク ティスを導入�す るとアジャイル な開発になる というのは 幻想 http://bit.ly/pQrRmy
59. 守破離 http://bit.ly/qRvi51
60. チームの能力を 最大限に発揮する h"p://bit.ly/zLyLc0
61. Developers Summit • 製品そのものをAgileな状態に保つ • 技術的負債を少なく保つ http://www.flickr.com/photos/stuckincustoms/5094583941/
62. マージって何？ Excel台帳じゃ だめ？ コンフリクトするとつら いから動かなくてもコ ミットしますね！ http://www.flickr.com/photos/seanmolin/7028040701/
63. バージョン管理は 開発者のしつけ http://bit.ly/utD8aA
64. テスト自動化の必要性 小規模リリースのたびに手動でテストす るとコードベースが大きくなるにつれて テストコストが膨らむ • アジャイル開発においてはテスト自動化は必須 • アジャイルかどうかに関係なくソフトウェアのライフサイクル を考慮する必要がある。
65. 自動化されたテストの損益分岐点 テスト自動化にかかるコストよりも 手動テストのコストがすぐ高くなる ITアーキテクト「機能テストの自動化について考える」 より引用 http://www.itarchitect.jp/print/?menu3=24601
66. 問題は早めに解決する フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1日 • 早く見つけて速く直す
67. デプロイのたびに 人手でテストするのは無理
68. テストしていない ものを目を瞑って デプロイしてはい けない き 囁 の 悪魔 http://bit.ly/rAOG9h 設定ファイル1行だ し大丈夫だよね？
69. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
70. 完了の定義 • 完了の定義を作り、何をもって出荷可能かを 定める • 全部を短い間隔で出来れば頻繁にリリース可 能 コード レビュー チェックイン ユニット テスト カバレッジ 75% 結合テスト 受け入れ テスト クロス ブラウザ 静的解析 ドキュメント 性能 セキュリティ デプロイ
73. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
74. DevOpsとはDevとOps が協力しながら、 ビジネスのために継続的に 成果を出す、もしくは変化 に対応するためにアジリテ ィを向上させていくこと、 またはそれにかかわる活動 全般のこと
75. （⌒) ∧__∧ （~) （｡･ω･｡)( ) {￣￣￣￣} {~￣お_＿} {~￣茶_＿} {＿＿＿＿} ┗━━┛ ココらへんであ と20分は残っ ていないとピン チである
76. http://bit.ly/ndgMJ6 AGILEな組織 Agileな組織
77. 私が最も頻繁にされる質問の一 つにこういうのがある: 自分のくだらない組織にどう対 処すればいいでしょうか? 仕事 は好きなのですが、自社のマネ ジメントのやり方は好きではあ りません。 どうすればいいでしょう? (Jurgen Appelo)
78. 答えは簡単で、3 つの選択肢がある: 1. 無視する。組織を変えるのはとても大変なことだ。優れ たチェンジ・エージェントになる方法を学ぶだけの根 気がないなら、組織の悪いことに文句を言うのをやめ ることだ。組織のあるがままを受け入れて、あなたの 仕事の良い部分だけを楽しめばよい。 2. 仕事を辞める。悪い組織が存在している唯一の理由は、 みんながその仕事を辞めないからだ。 働くのによりよ い場所を見つけて、世の中のためになることをするこ と。そのために、そこで働くのを辞め、悪い組織を存 続できないようする。 3. チェンジ・マネジメントについて学習する。ほとんどの 人は他人に影響を与えたり組織を変化させたりするの がまったく得意ではない。しかし真剣になれば、より 効果的なチェンジ・ エージェントになる方法を学ぶこ とができる。
79. h"p://bit.ly/yFe3Za 組織における問題点
80. 組織規模の拡大 →問題の深刻化 h"p://bit.ly/xHSLfl
81. 組織分割における 顧客価値との不一致 h"p://www.flickr.com/photos/_suika/3913063515/
82. コンウェイの法則 “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” http://bit.ly/oIUrUI
83. h"p://www.youtube.com/watch?v=4u5N00ApR_k リリースは2週間に1回で、 かつ2週間前までに申請してく ださい。 規則で決まってるし、 忙しいんです。 もっと頻繁に すぐできないの？ ü 規則の意図が理理解されず、ただ制約化される ü 仕事のための仕事？？？
84. ピラミッド組織 ピラミッド 組織は、同質 なものを受け 入�れ、異質な ものを受け入� れられない。 http://bit.ly/qpntdu
85. 組織のマネー ジャや上級管 理職、経営者 の一部は変化 に踏み出せな い。 組織に対する背任 http://bit.ly/nMHv6P
86. 抵抗勢力は かならず発 生する http://bit.ly/paHrVi
87. 人は、有能な間は昇 進を続ける。 昇進して仕事が変化 した結果、無能にな ると昇進がとまる。 そのため、階層社会 の上の方には、無能 な人であふれ返る。
88. コマンドコントロール 上司の命令に 従っていれば 良い、という 価値観
89. コマンドコントロールの問題 ü メンバーはやらされ感を持つ ü 上司の指示を遵守したかどうかが 評価の観点に ü 人が育たない。通常は上司の劣化 コピーに…� ü 現状に不満をもつ優秀な人から順 に退職…�
90. チーム解体による 連続性の放棄� h"p://bit.ly/zjyVUl
91. 稼働率という名の幻想 h"p://bit.ly/AiGcma
93. チームを強く保つ h"p://bit.ly/ygbMSj
94. スクラムマスター ü スクラムプロセスをうまくまわす ü 外部の⼲干渉からチームを守りチームを集中させる ü 仕事を進める上での障害事項を解決する
95. ？ は 任 責 の OO PP 管理 ？ は 責任 の 職 ？ は 任 ？ 任は 責 責 SSMMの の ーム チ ？ 任は の責 者 経営 の責 人 個 ？ 任は 実行責任？ 説明責任？ 結果責任？ …�
97. チームの責任 チームが 「全力で選択したス トーリーをDDoonneeに しようとする」 ことをコミットメン トと呼ぶ これは チームの責任であり、 個人の責任ではない http://bit.ly/pKXeZh
98. 見積もりはコミッ トメントではない しかし多くの場合 見積もりがコミット メントとして扱われ る悪い習慣がある http://bit.ly/pOfAGO
99. 常に 改�善する 責任 http://bit.ly/mRLszj
100. プラクティス の採用理由を チームや 顧客や ステークホル ダーに 説明する責任
101. チームのルールに従う責任 ü デイリースクラムに出席する責任 ü 完了の定義に従って作業を行う責任 ü チームメンバーを助ける責任 ü チームメンバーを育てる責任 http://bit.ly/qFy4Aq
102. ⼈人材育成の責任 http://bit.ly/qb0Jd4 チームが人を育 てる OOJJTTによるマン ツーマンな人材 育成ではなく、 チーム全員が協 力しあってお互 いの能力を向�上 させる
105. 競争優位は個人と集 団の両方の継続的学 習から生まれる。 学習する組織とは 「チームが目的を達 成するための能力と 気づきの状態を高め 続ける組織」
106. ü メンタルモデル ü 自己マスタリー ü システム思考 ü 共有ビジョン ü チーム学習 // ダイアログ
107. メンタルモデル http://bit.ly/nRFmiT マインドセットやパラダイムを含め た「世の中や事象に関する前提」
108. 自己マスタリー http://bit.ly/q2RSEq 自分がどうあり たいか、何を作 り出したいかに ついて理解しつ つ、現実との差 を認識し、それ に向�かって行動 する
109. システム思考 http://bit.ly/nZTDdS 物事を一連の要 素のつながりと してとらえ、そ のつながりの相 互作用に注目す る。全体最適化 や複雑な問題解 決の手法として 用いる
110. 共有ビジョン 組織を構成する人のそ れぞれのビジョンを重 ねて、組織として共有 し浸透可能なビジョン を作るプロセス http://bit.ly/nvZhqo
111. http://bit.ly/p2KAjx 命令 説得 テスト 相談 協創
112. “リッツ・カールトンはお客様への心 のこもったおもてなしと快適さを提供す ることをもっとも大切な使命とこころ えています。 私たちは、お客様に心あたたまる、くつ ろいだそして洗練された雰囲気を常にお 楽しみいただくために最高のパーソナ ル・サービスと施設を提供することをお 約束します。” リッツカールトンのクレドより抜粋
113. “リッツ・カールトンではお客様へお約束した サービスを提供する上で、紳士・淑女こそが もっとも大切な資源です。 信頼、誠実、尊敬、高潔、決意を原則とし、 私たちは、個人と会社のためになるよう、持て る才能を育成し、最大限にのばします。 多様性を尊重し、充実した生活を深め、個人 のこころざしを実現し、リッツ・カールトン・ ミスティークを高める‥リッツ・カールトンは、 このような職場環境をはぐくみます。” リッツカールトンの従業員への約束より
115. チーム学習・ダイアログ お互いのメンタルモデルに対す る理解を深めること。集団での 気づきの状態を高める
116. 自己組織化 ü 上司は責任とチームで解消で きない問題の解決を担う ü 上司は後方支援、ファシリ テーター役になる ü チームを信じる http://bit.ly/r0Lc8F
117. http://bit.ly/ovenYk 自己組織化されたチームで仕事を できるようにするためには、 外部からのマイクロマネジメント を止める必要がある。
118. リーダーや管理理職の役割の変化 ü 従来の役割や振る舞い ü 求められる役割や振る舞い ü ピラミッド組織 ü ネットワーク型組織 ü コマンド・コントロール ü 自律・自発の支援 ü 権威的 ü 民主的 ü 流動性がない ü 流動性のある ü 答えをいう ü 導く ü 叱る ü 褒める ü 否定 ü 肯定 ü マイクロマネジメント ü チームの自主性に任せる
119. リーダーシップのモデル(SL理理論論) http://www.situational.com/ より図を引⽤用
120. 権限の7レベル ü 指示する ü 売り込む ü 相談する ü 同意する ü アドバイスする ü 問い合わせる ü 移譲する
122. http://bit.ly/pdq0xn 全てのアジャイルなプロセスはチームへの 権限移譲とチーム内での文化および規範の 確立を必要とする
123. 人事評価のやり方 http://bit.ly/r00mRp ü 個人単位の評価からチーム単位の評価 ü 単一の評価者からチームメンバーを含め た評価へ
124. アンチパターン アジャイルな開発における透明性を そのまま人事評価に利用する。 （こなしたタスク数など） http://bit.ly/px6oa1
125. 対応策 http://bit.ly/pUG9Gp 個人の評価はチーム全員から「チームへの貢献 度」「プロジェクトや顧客への貢献度」を中心に 収集する
127. キャリアパス http://bit.ly/mUtDl7 名選手名監督 にあらず。 開発のプロが 経営のプロと は限らない。 逆もまた然り
129. よくある問題 ü 固定化された企業イメージによって応募 者の属性が偏る ü 面接官個人の判断に左右される ü そのため似たタイプの人材が多くなる ü 数回の面接では能力の見極めは困難
131. http://bit.ly/qEBgGV 組織の多様性は強さ
132. • 失敗を責めたらどんどん勝負できなくなる • 失敗から学ぶことは必要 • 失敗は小さく早期から h"p://www.flickr.com/photos/lintmachine/2983771744
134. Developers Summit 組織のアジリティを高める • 変化しないとゆるやかに死ぬ • 自分たちで変えていく。できることは沢山あるはず！ http://www.flickr.com/photos/eole/4350200158/
135. 健闘を 祈ります h"p://bit.ly/zJczAB
