1. Effective DevOps 2018/6/5 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメイ ンモデリングなどが専門領域 https://www.attractor.co.jp/
4. 今日の話はこちらです ✤ Effective DevOps 4本柱による持続可能な組織文化の育て方 ✤ 3/24 発売 ✤ オライリー 3,888円 ✤ ぜひよろしくお願いします!! ✤ http://bit.ly/EffectiveDevOps
8. ✤ DevOpsという単語を見かけない日がないくらいですね… ✤ ところで「DevOps」とは何なんでしょうか？
10. DevOpsの起源：前夜 ✤ 2007年：パトリック・デボアはベルギーでデータセンターマイグレーションプロジェ クトに従事して、デスマーチ中だった ✤ 2008年8月4-8日：トロントのAgile 2008 カンファレンス ✤ パトリックが『Agile Operations and Infrastructure: How Infra-gile are You?』というタイトルで講演 ✤ アンドリュー・クレイ・シェーファーのアジャイルインフラストラクチャーのセッショ ンは参加者が1人（パトリック）だったのでキャンセル ✤ パトリックは廊下でアンドリューを捕まえて議論
11. DevOpsの起源：始動 ✤ 2009年6月23日：サンノゼで行われたO'ReillyのVelocityカンファレンス
12. DevOpsの起源：10 Deploys per Day https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
13. DevOpsの起源：始動 ✤ 10 Deploys per Day: Dev and Ops Cooperation at Flickr ✤ 10 Deployはビジネスニーズへの対応を続けてきた結果であり、これに注目し すぎるとミスリード ✤ ポール・ハーモンド（開発部門のマネージャー）とジョン・アレスポウ（運用部門 のマネージャー）が協力しあって仕事をしたことの成果 ✤ パトリックは直接参加できずストリーミングを見ていた。残念がってTweetして いた
14. DevOpsの起源：ハッシュタグ初登場 ただ「ノー」と言ってはいけない。それでは他の人の問題を尊重していないことになる ...... (アンドリュー・クレイ・シェーファー)
15. DevOpsの起源：コミュニティ始動 ヨーロッパにも話を広げていかないといけない。 オープンスペースがいいかな、カンファレンスがいいかな Opsの一般的なトピックにしようか、それともdevopsにフォーカスしようか
16. DevOpsの起源：仮イベント名 なんか良いイベントタイトルない？
18. DevOpsの起源：最初のDevOpsDays
19. DevOpsの起源：最初のDevOpsDays ✤ ✤ タイトル邦訳 ✤ 非機能要求で、ユーザーストーリーは役に立つか ✤ Flapjack クラウド上でのモニタリングを再考する ✤ Puppetによるアジャイルなインフラ構築 ✤ Opsにカンバンを導入する ✤ 継続的インテグレーション、パイプライン、デプロイメント ✤ 開発チームのためのopenQRM Cloudユースケース 雑多感がある…
20. DevOpsの起源：#devops[days]定着 ✤ 2009年10月末ころから、Twitterで#devopsdaysと#devopsのハッシュタグが活 発に使われるようになった ✤ 2009年11月15日 パトリックのブログ (http://bit.ly/debois-devopsdays) ✤ 「正直に言うと、ここ数年、アジャイルのカンファレンスに行くたびに、砂漠のな かで祈るような気分だった。ほとんど諦めかけていた。こんな考え方はたぶん まともじゃない。 DevとOpsが一緒に仕事をするなんて。しかし、今や火は広が りつつある!! 」
21. 結局DevOpsって何だろう？ ✤ コミュニティ駆動で生まれたムーブメント ✤ サイロに分割されて現状に不満を感じていた人たちによる試行錯誤から得られたう まくいく仕事の進め方と思考の方法 ✤ 個人や組織が成功に向かっていかに協力しあうかがテーマ ✤ アジャイルマニフェストのような公式の定義はない
22. DevOpsとは (Gartner) ✤ DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective. ✤ DevOpsは人や文化に焦点をあててコラボレーションの改善を追求する。DevOpsを 実現する上ではテクノロジーを活用する https://www.gartner.com/it-glossary/devops
23. DevOpsとは (AWS) ✤ DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market. ✤ DevOpsは文化的な哲学とプラクティス、ツールの組み合わせである https://aws.amazon.com/devops/what-is-devops/?nc1=h_ls
24. DevOpsとは (Atlassian) ✤ DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative silos. ✤ DevOpsはプロセスを自動化するプラクティスの集まりであり、コラボレーションの文 化の上に成り立つものである https://www.atlassian.com/devops
25. DevOpsとは(みんなに聞いてみた) ✤ 開発者が開発から運用の自動化までを行う ✤ 組織の壁を低くする作業 ✤ DevとOpsが同じ仕組みでライフサイクルを回すこと ✤ ビジネスや課題に対して、組織論ではなく、チームとして取り組んでいく活動 ✤ DevとOpsのセクショナリズムより、お互い協力して顧客に価値を届け続ける ✤ アジャイルや継続的改善が開発チームだけでなく外に広がったもの ✤ 分断されていた組織やチームを1つにして、提供できる価値の最大化を目指すこと ✤ プロダクトを迅速・タイムリーにリリースするために、関係者全員が協力し合う組織と仕組み ✤ 組織として付加価値を継続的に素早くリリースしていくための取り組み ✤ 個人ではなく多様性をもったチームで問題に対応していく方法 ✤ ビジネスの達成にために開発と運用が互いに敬意・信頼をし合い協力すること ✤ みんなでつくる「作り方」
26. つまり… ✤ DevOpsとは何なのかの定義は多種多様 ✤ 文化、コラボレーション、テクノロジーから構成されると考えると良さそう… ✤ それぞれは相互に絡み合っている ✤ 定義がない以上、DevOpsを「する？」ための唯一の正しい方法はない ✤ そもそも全部が分からないので、全部入りのDevOpsなどというものもない ✤ 認定試験は何を認定するのだろうか？という疑問
27. 通俗モデル ✤ 通俗モデル = 議論の対象となっている本当のテーマよりも理解しやすい抽象的な 考え方のこと ✤ 本当のテーマの代用物になっていることが多い ✤ 異なるグループが「異なる意図で同じ用語を使う」と問題が起こる ✤ アジャイル開発でさえ、定義があるにも関わらず問題が起こっている
28. DevOpsの通俗モデル化 ✤ 本当に議論したいことよりも、DevOpsとはどのような意味か、つまり何の通俗モデル としてDevOpsという用語を使っているかを議論するために多くの時間を費やしてい るのが現状 ✤ 一部の人は「DevOps」という単語を使うのを止めている ✤ DevOpsが何なのかを定義するという問題を避けて、本質的に役に立つ議論が必要 になる
29. DevOpsによってどんな効果が出た？という質問 12th Annual State of Agile Survey
30. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) DevOps導入してみた!! どんな成果がでるかな？ デプロイ 仮説 Opinion (意見) DevOps導入したい!! 設計
31. 正しそうな問題にアプローチする ✤ 全ての組織はそれぞれ違う ✤ 自分の組織にとって正しそうなことや求める結果は何か？ が重要になる ✤ ✤ 異なる道筋を通って異なる問題や対立を解決する 「DevOpsをやりたい？」は正しそうな問題設定なのか ✤ 「アジャイルをやりたい」もよく見た ✤ 「正しい」は無理なので「正しそう」 ✤ 優先順位は必要（プロダクトバックログと同じ）
32. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
33. 筆者は、何年もかかる旅に出た。開発手法を変革する 旅だ。ビジネス目標は、イノベーションのためにキャパ シティを解放することだ。変革が終われば、ファーム ウェアが新製品出荷のボトルネックになることはない。 このように明確な目標は、方向性を定め、作業に優先 順位をつける際に本当に役に立った。 どれだけ「DevOpsできてる？アジャイルできてる？」とい うベンチマークを探しにカンファレンスに参加する。改善 は感じられるし、目にも見える。しかし、最終収益の向上 というビジネス成果をCFOに示せてはいないので、マネ ジメントチームは苦労している
34. ✤ そんな中でもDevOpsというのであれば…
35. フォーカスするとよい4つのテーマ ✤ 効果的なDevOpsのための4本柱 ✤ コラボレーション ✤ アフィニティ ✤ ツール ✤ スケーリング ✤ 4本柱を組み合わせることで組織の文化的側面と技術的側面の両方に対応可能 ✤ 文化、価値観、個人間のコミュニケーションといったものが土台となる ✤ 一度にすべてをやろうとしない
36. 1. コラボレーション ✤ チーム内のそれぞれのメンバーが協力しあって仕事を進める ✤ 同じ目標に向かって働き、成功に対する責任を共有する ✤ これができていないチームが、他のチームとうまく協力しあうことはできない ✤ それぞれの人たちが以前よりも効果的に共同作業を進められるようにすることが DevOpsの成功の大部分に寄与する
37. 2. アフィニティ ✤ それぞれ別の目標をもった顔の見えない他の組織の人たちと、どうやって最大の成 果を出せるというのか？ ✤ チーム間や組織間の関係を作る ✤ 組織の共通目標の達成のために、個々のチームの目標の違いを乗り越える ✤ お互いが共感し、他のチームからも学習し続ける
38. 3. ツール ✤ 加速装置 ✤ 現在の文化と向かう先を踏まえて、変化を推進する ✤ ツールが既存の環境にどのような影響を与えているのか理解する必要 ✤ ツール単独では壊れた文化や機能しないコミュニケーションを解決しない ✤ ツールが「重要ではない」という意味ではない
39. 4. スケーリング ✤ ここまでの話を組織全体に如何に適用していくか ✤ 組織の成長にあわせて他の3つの柱をどう適用するかを考える
41. 高いパフォーマンスのチームの特徴 ✤ 高いパフォーマンスを示す賢いチームには以下 のような特徴があった (2015/1 New York Times, アニータ・ウーリー) ✤ 平等な参加 ✤ 心の理論 ✤ コミュニケーション
42. プロジェクトアリストテレス ✤ Googleが2012年に開始した労働生産性向上計画プロジェクト ✤ 生産性の高いチームの共通点の洗い出しと成功要因の分析を実施 ✤ 結果や知見をre:Workで公開（https://rework.withgoogle.com/） ✤ NewYork Timesなどでも記事が
45. うまくいっているチームに共通する要素の仮説 ✤ 仕事以外のプライベートでも親しい ✤ 頻繁に飲食をともにしている ✤ 内向的な人同士や外向的な人同士など似た特性の人でチームを構成している ✤ 興味や関心が似ている ✤ 圧倒的なリーダーシップやカリスマ性がある ✤ ボーナスや報酬によるモチベーション ✤ 共通の趣味 ✤ 共通の学歴
47. チームのルールやふるまいに注目 ✤ 個人の能力の合計とチームの能力はイコールではなかった ✤ 個々に対するアプローチより集団に対するアプローチが効果がある ✤ 成果を出したチームにほかのことをやらせても成功するが、失敗するチームは何を やっても失敗する現象 ✤ よい集団規範の有無が及ぼす影響が大きい ✤ ✤ 不文律・習慣・行動基準（明文化の有無は関係ない） 均等な発言機会と共感力・他者理解力があると成功しやすかった ✤ ＝心理的安全性
48. ✤ 医療チームの成績に対する無作為の影響に ついて ✤ https://bit.ly/2oO96jW ✤ イスラエルの病院での実験で、医療スタッフ に過去のパフォーマンスや質に対して無礼 な発言を伝えた場合とそうでない場合の結 果を比較 ✤ 無礼な対応を受けたチームは、情報の共有 を進んで行わず、メンバー間で助けを求め るのをやめた ✤ 心理的安全性の欠如はマイナス
49. 個人の違いを受け入れる ✤ それぞれの文化的背景、キャリアなどによってお互いの仕事の仕方に影響を与える ✤ 仕事上のキャリア（大企業、スタートアップ、異業種…、技術力、職種の階層、こ の仕事に就くきっかけ、経験年数） ✤ 個人の特性、性別、性的指向、宗教、人種、階級、母国語、能力、教育レベル ✤ つまり多様であることを受け入れる ✤ 対立を緩和するために期待値やプロセス、行動規範等を調整する ✤ 人を尊重し、人を排除せず、安心できる環境を作る
50. 認知スタイルも人ごとに多様 ✤ ✤ 認知スタイルとは個人の情報処理の仕方 ✤ 内向・外向・両向 ✤ 質問と推測 ✤ スターターとフィニッシャー ✤ 分析思考・批判的思考・水平思考 ✤ 純粋主義者と現実主義者 特定の認知スタイルをよいものとしないような環境にしていく ✤ スタイルの違いはコミュニケーションによって解決するしかない
51. 原田騎郎 (Harada Kiro) 永瀬美穂 (Nagase Miho) 吉羽龍太郎 (Yoshiba Ryutaro)
52. 2つのマインドセット ✤ 固定思考：スキルは生まれつきのもので変わらない。他の人に自分のことを証明し ないといけない。失敗は愚かさ・無能さの証明だと考える。そのため失敗から距離を 置こうとする。つまり不確実性を避けたがる ✤ 成長思考：学習と学習環境に身を委ねる。スキルや知識は時間とともに変化する。今 は知識がなくても獲得すれば構わない。人に教えて貰って練習すればよい。失敗は 個人の本質的な欠陥ではなく、学習プロセスの一部と考える ✤ これらは個人のマインドセットであると同時にチームや組織にもあてはまる ✤ 変化の速度や競争の激しい今の時代に必要なのはどちらか？ ✤ 失敗しないことが成功を意味しない
53. 成長思考を育むためにどうするか ✤ チームとして自分の役割として必要なスキルを学ぶ ✤ ニッチな領域を見つける ✤ 自分の得意なことを知り、それを伸ばす ✤ 学んだことを実践に投入する ✤ 自分の作業スタイルを確立して改善する ✤ チームみんなが足並みを揃えて協力できる仕事の仕方をみつける ✤ これらをするには時間的な余裕が必須（焼畑農業をしない）
54. 成長思考はどう作られるか ✤ 質の高いフィードバックを継続的に受ける ✤ その人が「どういう人なのか」ではなく、「その人がどんなことができるのか」に 注目する ✤ 持って生まれた資質や変更不能なことにフォーカスしない ✤ 行動に着目し、過去にやったこと、将来すべきことにフォーカスする
55. フィードバックの方法 ✤ 定期的な1:1 (毎週〜隔週30分など) ✤ 期待値のすり合わせ、キャリア開発、メンタリング、コーチング、業績改善 ✤ ネガティブなフィードバックも必要 ✤ ✤ 個人攻撃ととられないように ✤ 個人攻撃とはとらない あなた vs わたし ではなく、問題 vs わたしたち ✤ ✤ I messageを使う 360度評価
56. 非難文化 ✤ ミスが発生したときに、個人や組織を非難し処罰する傾向のこと ✤ ポストモーテムやレトロスペクティブで犯人探しが行われる ✤ 人を固定思考で見ている（ミスした人は賢くない、問題があるという思考） ✤ 透明性を尊重せず分断された環境でよく見られる ✤ 自分が犯人にされないように他人や他のチームに非難が向くようにする ✤ 非難されないように情報を隠す ✤ コラボレーションとは正反対の文化 ✤ 心理的安全性の欠如
57. 非難のない文化 ✤ ミスを、システムのどこかにある問題の兆候と捉える ✤ つまりミスは個人のものではなく、構造的な問題と考える ✤ ミスを学習の機会だと考える ✤ 人を成長思考で見る ✤ 透明性が尊重され、他人からのフィードバックを受けやすくなる ✤ コラボレーションの実現の土台となる ✤ 継続的改善を支える
58. 評価システム ✤ 文化や思考方法は評価システムの影響を大きく受ける ✤ 過度に結果にフォーカスすると個人は学習より成果を重視してしまう ✤ チームや組織の成果より個人の成果を優先してしまう ✤ 非難文化と減点法の評価では問題は隠す方向に向かう ✤ 自身の成果を達成するのが最重要となりコラボレーションは阻害される ✤ 年に1-2度の評価ではフィードバックサイクルが長い
59. https://bit.ly/2HgFVnE スーパーフロック問題
60. (似非)スーパースターの弊害 ✤ 単に技術力や知性の寄せ集めでは最良の結果は出ない ✤ 技術力に過度にフォーカスして、無礼な振る舞いをしたり規律にしたがわない人を雇 うと、却って信頼関係が損なわれ、結果がでなくなる ✤ 「確かに彼はいわゆるクソ野郎なんですけど......」 みたいな場合は技術力があろう が採用しない ✤ 信頼関係は築くには長い時間がかかり、壊れるのは一瞬
61. モダンアジャイル https://www.industriallogic.com/blog/modern-agile/
63. コラボレーションとコミュニケーション ✤ ✤ チームの中では考え方の違いによって摩擦や対立が起こる ✤ 何を優先するのか、どれくらいの時間を使うのか、この先どうするのか ✤ 対立そのものは健全 意見の違いを解決したり、交渉して落とし所を探っていく必要がある ✤ 共通の理解を作る ✤ 共通のビジョンや目的を作る ✤ そのためには効果的なコミュニケーションが必要 ✤ 効果的なコミュニケーションによって信頼と共感の度合いが高まる ✤ Trust and Verify (信頼するのと丸投げするのは別。まず信頼し、あとから妥当かを確認)
65. 理解・行動するまで伝える ✤ 自分の意見や考えが伝わらないのは発信元の責任 ✤ 一度言ったくらいでは伝わらない、分からない ✤ 相手が理解するだろう、行動するだろう、ではなく、分かるまで伝える
66. テスラ(イーロン・マスクCEO) テスラにいる全員が、誰にメールしても会話しても構わないし、またすべきなのです。企業 全体の利益のために、自分が考える最速の解決方法をとるべきです。上司の許可なく上司 の上司に相談しても構わないし、別の部門のトップに直接相談してもいいし、私に相談して もらっても構わない。誰かと話すことに誰かの許可は要らないのです。さらに、問題が解決 されるまで、自分にその義務があると考えるべきです。この狙いは、手当たり次第に世間話 をすることではなく、超高速で確実に実行することです。我々が大手自動車企業と規模で 競争できないことは明らかなので、我々は知性と機敏さで勝負しないといけない。 最後に1つ言っておきたいのは、管理職が注力すべきなのは、企業にサイロが生まれない ようにすることです。サイロは他者との間に精神的な壁を作り出し、コミュニケーションを 阻害するのです。残念なことに、サイロができるのは自然な流れなので、積極的に戦う必 要があります。 部門間に障壁を立てたり、会社全体ではなく組織内の相対的な成功を重視したりすること が、どうしてテスラのためになるでしょうか。我々全員、同じボートに乗っています。自分の 部署ではなく、会社の利益のために働くことをつねに意識してください。 訳文は東洋経済オンラインより引用し一部改変 https://toyokeizai.net/articles/-/212417
67. コラボレーションの誤解 ✤ 古くからのシステム管理者に新しい手法は教えられない ✤ ✤ 急成長したいときにはスーパースターを採用しなければいけない ✤ ✤ 成長志向、時間や必要なリソースを与える 企業を成長させたかったらチームも育てないといけない。最初の人たちが企業 文化を決める 多様性に満ちたチームは効果的にコラボレーションできない ✤ 短期的には対立が増えるが、長期的には創造性や問題解決能力は高くなる
69. あなたの“DevOps”は効果が出てますか？
