1. リーダーにおくるDevOps実現のためのチームづくり 2017/5/23 株式会社アトラクタ 取締役最高技術責任者/アジャイルコーチ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 https://www.attractor.co.jp/
4. スライドは後で入手できますので、 スライドに書いてあることをメモする必要はありません。 写真撮影は構いませんがシャッター音はでないように。
5. 質問 ✤ みなさんDevOpsを実現したいですか？
6. 時価総額ランキング 2016 2006 1. アップル (6091億ドル) 1. エクソンモービル (4470億ドル) 2. アルファベット (5434億ドル) 2. GE (3840億ドル) 3. マイクロソフト (4487億ドル) 3. マイクロソフト (2940億ドル) 4. Amazon (3969億ドル) 4. CITIグループ (2730億ドル) 5. Facebook (3683億ドル) 5. ガスプロム (3680億ドル)
7. 現在のビジネス状況 ✤ ビジネスの変化がどんどんはやくなっている ✤ VUCA => Volatility (不安定) / Uncertainty (不確実) / Complexity (複 雑) / Ambiguity (曖昧) ✤ 多くのサービスがこの10年以内に登場し既存のビジネスモデルに影響を与 えたり、人の働き方を変えている。GitHub (2008), Dropbox (2008), Evernote (2008), Slack (2014), Airbnb (2008) , SORACOM (2015) ✤ ITはビジネス上の成果達成のための重要な要素に
8. 問題意識 ✤ 環境の変化についていけないと、ビジネスが頭打ちになる ✤ 売上が伸びないどころか、新たなサービスによってどんどん自分たちの顧 客が奪われていく ✤ こういう問題をなんとかしたい！ ✤ = マーケットや競合などの環境の変化に素早く対応し続け、顧客が必要と するプロダクトやサービスを出し続けられるようになりたい
10. やりたいこと ✤ リードタイムを短くする ✤ スループットを増やす ✤ もちろん必要となる品質は満たすことは前提 ✤ これらを持続可能なペースで続けたい
11. リードタイムとスループット ✤ リードタイムとは1つのプロセスに入ってからそれを出て次のプロセスに 届くまでの時間のこと ✤ 製品観点でのリードタイムは、要求の出現から顧客に届くまでの時間のこ とをさす ✤ ✤ これはビジネスの観点から短い方がよい（速い流れ） ✤ 短ければ、いつ届くのかを聞かれたり、催促されることが減る スループットは同時に届けられる量を示す
12. リードタイム削減・スループット向上に必要なもの ✤ リードタイム削減・スループット向上の実現を目指したいチームの存在 ✤ ✤ ✤ 心理的安全性・透明性に関する価値観の合意も必要 カイゼンへの持続的な取り組み ✤ プロダクトやプロセスや技術を始め、すべてはカイゼンの対象 ✤ これは機能するチーム抜きには語れない スポンサー（周りの理解と協力）
14. “実際のところ、ソフトウェア開発上の問題の多くは、 技術的というより社会学的なものである” –トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用
15. アプリとサーバをちゃんと動かすの がおまえの責任だろ。おれのせいに するな なんでアプリをもっとちゃんとした 品質で作らないんだよ。夜間コール がんがん受ける身にもなれよ
16. よくある話… ✤ このコードは僕が書いたんじゃないので分かりません ✤ このタスクは○○さん担当なので僕を責められても… ✤ これは規則で決まってるんです。なので従わなきゃいけません… ✤ 他の部門がいつも遅いんで、そのせいで遅れるんです… ✤ 他の仕事があるんで…
17. ここでの問題 ✤ チームとしての成果の観点ではなく、個人(を守ること)に関心が寄りすぎ ている ✤ 複数チームで仕事をしている場合、全体の成果より単一のチームの成果や チームを外から守ることに関心が寄っていることももちろんある
18. なぜそうなるのだろうか？ ✤ 自分たちがやっていることの価値が分からない ✤ 上司や外部からプレッシャーをかけられている ✤ 個人の成果に偏った評価制度・減点主義の評価制度 ✤ いままで色々言っても変わらなかったことへのあきらめ ✤ などなど…
19. 機能しないチーム ⑤結果への 無関心 ④説明責任の 回避 ③責任感の不足 ②衝突への恐怖 ①信頼の欠如
20. 心理的安全性をチームに備えよう ✤ ✤ 心理的安全性が担保されていないと ✤ 変化しない・挑戦しない方向にバイアスがかかる ✤ 自分を守ろうとして、都合の悪そうなことを隠す ✤ 他人のせいにする 安全になると透明性が向上する ✤ ✤ 安全じゃないのに透明にしようとすると、嘘が作られる 自分がコンサルティングする際、ことあるごとに「ここでの発言や振る舞 いは一切人事評価と関係ない」ことを強調し、上司にも表明してもらう
22. チームの形成ステージ タックマンモデル 形成期 混乱期 統一期 機能期 解散期 人が集まるがまだ独立 意見を言うようになる 一緒に活動し、異なる よく機能するチームと 目的を果たし、チーム しておりコミュニケー が、一方で自分と違う 意見を受け入れる。目 なる。チームには一体 が解散する時期 ションが少ない 意見に抵抗を示すよう 的や期待値などが一致 感がある。自立性が高 になる する い
23. チームのステージによるリーダーシップの違い • SL理論 => リーダーシップの形態はメンバー の成熟度によって変わるという理論 サポート行動 • S1からS4に向かってメンバーが成熟していく S1：指示型。意思決定はリーダーが行う S2：説得型。考えを説明し疑問に答える S3：参加型。意見を聞き意思決定を支援 situational.comから図を引用 指示的行動 S4：委任型。任せる
24. さまざまなレベルでの権限委譲を進める 1 指示する 管理者として意思決定をおこなう 2 売り込む 意思決定についてまわりを納得させる 3 相談する 決定する前にチームの意見を求める 4 同意する チームと一緒に意思決定を下す 5 助言する チームによる意思決定に影響を及ぼす 6 確認する チームによる意思決定後の確認を求める 7 移譲する 特に影響を及ぼさずチームに意思決定を任せる
25. (機能している)チームを壊さない ケース1 一度に半数の人を入れ替えた場合、 今まで築き上げたチームの文化や規 律は失われる覚悟が必要 ケース2 一度に1-2人を入れ替えた場合、新 たなメンバーは既存の文化に乗りつ つ慣れた段階で他のチームの文化や ノウハウを持ち込みやすい
26. よいチームは続けられる ビジネス上の 結果を出し続ける 変化に 対応し続ける 成長を 維持し続ける
27. クロスファンクション型チームの必要性 役割分担型 10 9 8 7 6 5 4 3 2 1 0 Day1 ✤ Day2 Day3 クロスファンクション型 Day4 Day5 10 9 8 7 6 5 4 3 2 1 0 Day1 Day2 Day3 Day4 Day5 コンポーネントや役割単位で分割すればするほどウォーターフォール型のように なり、最後まで何も完了しなかったり、追い込みせざるを得なくなる
28. すごいチームを作る：多様性は改善を加速する
29. “時間の4分の1以上が会議に費やされているならば、 組織構造に欠陥があると見てよい” –ピーター・F. ドラッカー
30. サイロによるオーバーヘッド ✤ 他の部門とのコミュニケーションにかなり多くの時間を使っている ✤ (もちろんコミュニケーションは重要だが、問題は中身が手続き論に終始 しがちなこと) ✤ 結果として顧客にとって直接的に価値になることに時間が使えていない ✤ リードタイムが長くなる原因の1つ
31. 原則 ✤ チームは他の部門に引き継ぎすることなくソフトウェアを直接顧客に届け られる能力を持っていた方がよい ✤ ✤ 受渡しが少ないほどリードタイムは短くなる 密結合な組織間の関係を疎結合にできた方がよい ✤ ただし、組織構造を変える前にできることはたくさんある ✤ いきなり大掛かりな変更をすると色々な問題が起こる可能性
32. Werner Vogels, CTO, amazon.com You build it, You run it
33. 2ピザルール チームのサイズを 2枚のピザでみんなが満腹になるサイズに保つ
34. コミュニケーションオーバーヘッドの削減 ✤ Amazonはamazon.com用のサーバを調達する手続きをAPIに置き換えた ✤ そうすることで、コミュニケーションオーバーヘッドを削減しプロビジョ ニングまでの時間を短縮
35. 組織構造はアーキテクチャに影響を与える ✤ コンウェイの法則 ✤ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations - M. Conway ✤ システムを設計するあらゆる組織は、必ずその組織のコミュニケーション 構造に倣った構造を持つ設計を生み出す ✤ Microservicesに関心があるかもしれないが、それを実現できるかどうか は自分の組織構造に大きく依存。過度な幻想を抱かないこと
36. 組織の比較 # 従来型組織 うまくいってる組織 複雑、職種で分割 シンプル、プロダクトに焦点 個人 チーム 予測型 要求に対応 製造 プッシュ型、バッチ、大きなロット プル型、流れ、小さなロット 保守 事後 事前 品質 検査と修正 予防 管理 報告、監督、非難 見える化、自律的、ゴールに焦点 組織 人 スケジュール
38. リーンシンキング ✤ 組織をまたがるバリューストリームに注目する ✤ もしチームがサイクルタイムを減らせたとしても必ずしも全体のリードタ イムが短くなるとは限らない ✤ ボトルネックが存在する可能性がある… ✤ 制約理論(ToC)を学ぶとよい
39. ケーススタディ(1)このプロセスの問題は？ 不具合… デプロイ拒否 修正待ち… 分析 開発 Dev テスト QA / デプロイ Ops $$$$
40. ケーススタディ(1) ✤ このケースでは全体のリードタイムがソフトウェアの低品質によって引き 起こされている。なのでデプロイを自動化してもデプロイできるフィー チャーの数は増えない
41. ケーススタディ(2) ボトルネックはどこ？ WIP: 2 2日/ WIP: 4 3日 / WIP: 6 2日/ WIP: 1 20日 / 機能 機能 機能 機能 分析 開発 テスト QA / デプロイ Dev Ops $$$$
42. ケーススタディ(2) ✤ このケースではリードタイムはとても長い。というのもQA/デプロイが20 日も占めているから。さらに同時に1つしかデプロイできないのでスルー プットも低い。ここでDevチームの生産性を向上させても全体のリードタ イムとスループットの向上はわずか
44. 見えないものは改善できない ✤ 効果を測定したり、改善すべき点を見つけるためには、現状を見えるように する必要がある ✤ データはいつでも誰もが簡単に見えないといけない（透明性） ✤ 以下のようなデータを測定することが多い ✤ 開発速度(ベロシティ)、不具合数、デプロイ回数、変更量、リードタイ ム、失敗したデプロイ回数、障害からの復旧時間(MTTR)、平均障害間 隔(MTBF)、チケット数、可用性、パフォーマンスデータ、リクエスト 数、ユーザー数、ユーザー増加数、機能別利用状況、売上… ✤ データで共通理解を持ち、プロセスや製品の改善に活用する
45. https://www.flickr.com/photos/intelfreepress/6675763157/
47. バリューストリームマッピング ✤ 価値創造に関係するプロセスの流れの可視化と共有、課題の共有
48. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
49. 継続的な改善を続ける ✤ 改善とは、自分たちの仕事を「安全」にする ✤ 改善とは、自分たちの仕事を「簡単」にする ✤ 強制的に立ち止まれる仕掛をつくる (人間は停止するのが苦手) ✤ 問題を防ぐところにいきなり効率は求めない (まず穴を塞ぐ)
51. ふりかえりで定期的に(強制的に)立ち止まる Token of Appreciation Timeline Happiness Radar Story of Story Star Fish ※Fun Retrospectivesより WWW
52. 春の大カイゼン運動 生産性 改善の数 90 67.5 45 「改善運動」ではなく「改善活動」を 22.5 0 1 2 3 4 5 6 7 8 9 10
54. トヨタ生産方式(TPS)では ✤ 前工程は神様 後工程はお客様 ✤ 前工程がきちんとした品質のものを届けてくれる(のに感謝) ✤ 顧客とは実際のエンドユーザーだけでなく、内部の後工程も指す ✤ 品質を作りこむ。不良を次工程に回さない (プロセスを逆流させない)
55. 品質 ✤ 100%良品(部品・作業)でなければならない ✤ ある工程が不良を出したらすぐに自動で知らせる仕組み。そしてすぐ前工 程に返す。再発防止を行う ✤ 不良が起こるのは標準化・合理化が不十分で、作業方法や作業時間にムダ・ ムラ・ムリが発生するから ✤ 品質保証のための検査と工程が不安定で仕方なくやる検査は違う
56. まず漏れを防ぐ! (各工程で要求品質にあわせる) 効率化はそのあと
57. 質問 ✤ ご自身の会社の会議室を思い出してください ✤ 書けないホワイトボードマーカーがある？ ✤ ホワイトボードが消されないまま残っている？
58. 規律 ✤ ✤ 以下が発生している組織は かなりの確率で問題がある ✤ 消されていないホワイトボード ✤ 書けないマーカーの放置 割れ窓理論
59. 5S (整理/整頓/清掃/清潔/しつけ) ✤ 整理：必要なものとそうじゃないものを分け不要なものは捨てる (いつか 使う？は使わない…) ✤ 整頓：必要なものをジャスト・イン・タイムで取り出せるようにする。人 の動きや利用頻度で場所を決める。定位置を定める ✤ 清掃：きれいに掃除する=予防 (その時間を業務に組み込む) ✤ 清潔：整理・整頓・清掃を維持する ✤ しつけ：これらのルールを守らせる
60. 品質と規律を担保した上で プロセスの流れをカイゼンする
61. カイゼンのパターン：工程をなくす(Eliminate) Before 工程A After 工程A 工程B 工程C 工程C
62. カイゼンのパターン：工程を統合する(Combine) Before After 工程A 工程B 工程A 工程C
63. カイゼンのパターン：順番を変える(Rearrange) 手戻り Before 工程A 工程B 工程C After 工程C 工程A 工程B
64. カイゼンのパターン：単純化する(Simplify) 工程B1 Before 工程A 工程B 工程C 工程B2 After 工程A 工程B 工程C
65. 改善パターンマップ(参考) ゆとり 個人スキ を作る ルの向上 セットベース スキルマトリ 小さな 対話 価値の流れ のマップ ひとつ 実験 づつ チームの チームの 標準 よいやり方 事実 やめる と意見 課題を 共有 設計 クスを作る チームの 他チームと 合意 一緒にやる 順番を変える メンタリ シンプルに ング 測定を 継続的 学習 設計する 動的な 不具合を 助けを 安定したプ 早く見つ 呼ぶ ロセス ける 見える化 品質を 不具合を 分析 作り込む 継続的 改善
66. リーダーシップとスポンサーシップが必要 ✤ 全員がリーダーであること ✤ そして周りからのスポンサーシップが必須 ✤ 自分のまわりを改善するだけでも効果はあるかもしれないが、システム全 体を改善するともっと大きな利益があるはず
