1. Effective DevOps 2018/4/25 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメイ ンモデリングなどが専門領域 https://www.attractor.co.jp/
5. スライドは後で入手できますので、 スライドに書いてあることをメモする必要はありません。 写真撮影は構いませんがシャッター音はでないように。
6. 今日の話はこちらです ✤ Effective DevOps 4本柱による持続可能な組織文化の育て方 ✤ 3/24 発売 ✤ オライリー 3,888円 ✤ ぜひよろしくお願いします!! ✤ http://bit.ly/EffectiveDevOps
10. ✤ DevOpsという単語を見かけない日がないくらいですね… ✤ ところで「DevOps」とは何なんでしょうか？
12. DevOpsの起源：前夜 ✤ 2007年：パトリック・デボアはベルギーでデータセンターマイグレーションプ ロジェクトに従事して、デスマーチ中だった ✤ 2008年8月4-8日：トロントのAgile 2008 カンファレンス ✤ パトリックが『Agile Operations and Infrastructure: How Infra-gile are You?』というタイトルで講演 ✤ アンドリュー・クレイ・シェーファーのアジャイルインフラストラクチャー のセッションは参加者が1人（パトリック）だったのでキャンセル ✤ パトリックは廊下でアンドリューを捕まえて議論
13. DevOpsの起源：始動 ✤ 2009年6月23日：サンノゼで行われたO'ReillyのVelocityカンファレンス
14. DevOpsの起源：10 Deploys per Day https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
15. DevOpsの起源：始動 ✤ 10 Deploys per Day: Dev and Ops Cooperation at Flickr ✤ 10+ Deployはビジネスニーズへの対応を続けてきた結果であり、これに 注目しすぎるとミスリード ✤ ポール・ハーモンド（開発部門のマネージャー）とジョン・アレスポウ（運 用部門のマネージャー）が協力しあって仕事をしたことの成果 ✤ パトリックは直接参加できずストリーミングを見ていた。残念がってTweet していた
16. DevOpsの起源：ハッシュタグ初登場 ただ「ノー」と言ってはいけない。それでは他の人の問題を尊重していないことになる ...... (アンドリュー・クレイ・シェーファー)
17. DevOpsの起源：コミュニティ始動 ヨーロッパにも話を広げていかないといけない。 オープンスペースがいいかな、カンファレンスがいいかな Opsの一般的なトピックにしようか、それともdevopsにフォーカスしようか
18. DevOpsの起源：仮イベント名 なんか良いイベントタイトルない？
20. DevOpsの起源：最初のDevOpsDays
21. DevOpsの起源：最初のDevOpsDays ✤ ✤ タイトル邦訳 ✤ 非機能要求で、ユーザーストーリーは役に立つか ✤ Flapjack クラウド上でのモニタリングを再考する ✤ Puppetによるアジャイルなインフラ構築 ✤ Opsにカンバンを導入する ✤ 継続的インテグレーション、パイプライン、デプロイメント ✤ 開発チームのためのopenQRM Cloudユースケース 雑多感がある…
22. DevOpsの起源：#devops[days]定着 ✤ 2009年10月末ころから、Twitterで#devopsdaysと#devopsのハッシュタグ が活発に使われるようになった ✤ 2009年11月15日 パトリックのブログ (http://bit.ly/debois-devopsdays) ✤ 「正直に言うと、ここ数年、アジャイルのカンファレンスに行くたびに、 砂漠のなかで祈るような気分だった。ほとんど諦めかけていた。こんな考 え方はたぶんまともじゃない。 DevとOpsが一緒に仕事をするなんて。し かし、今や火は広がりつつある!! 」
23. 結局DevOpsって何だろう？ ✤ コミュニティ駆動で生まれたムーブメント ✤ サイロに分割されて現状に不満を感じていた人たちによる試行錯誤から得られ たうまくいく仕事の進め方と思考の方法 ✤ 個人や組織が成功に向かっていかに協力しあうかがテーマ ✤ アジャイルマニフェストのような公式の定義はない
24. 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
25. 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
26. 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
27. DevOpsとは(みんなに聞いてみた) ✤ 開発者が開発から運用の自動化までを行う ✤ 組織の壁を低くする作業 ✤ DevとOpsが同じ仕組みでライフサイクルを回すこと ✤ ビジネスや課題に対して、組織論ではなく、チームとして取り組んでいく活動 ✤ DevとOpsのセクショナリズムより、お互い協力して顧客に価値を届け続ける ✤ アジャイルや継続的改善が開発チームだけでなく外に広がったもの ✤ 分断されていた組織やチームを1つにして、提供できる価値の最大化を目指すこと ✤ プロダクトを迅速・タイムリーにリリースするために、関係者全員が協力し合う組織と仕組み ✤ 組織として付加価値を継続的に素早くリリースしていくための取り組み ✤ 個人ではなく多様性をもったチームで問題に対応していく方法 ✤ ビジネスの達成にために開発と運用が互いに敬意・信頼をし合い協力すること ✤ みんなでつくる「作り方」
28. つまり… ✤ DevOpsとは何なのかの定義は多種多様 ✤ 文化、コラボレーション、テクノロジーから構成されると考えると良さそう… ✤ それぞれは相互に絡み合っている ✤ 定義がない以上、DevOpsを「する？」ための唯一の正しい方法はない ✤ そもそも全部が分からないので、全部入りのDevOpsなどというものもない ✤ 認定試験は何を認定するのだろうか？という疑問
29. 通俗モデル ✤ 通俗モデル = 議論の対象となっている本当のテーマよりも理解しやすい抽象的 な考え方のこと ✤ 本当のテーマの代用物になっていることが多い ✤ 異なるグループが「異なる意図で同じ用語を使う」と問題が起こる ✤ アジャイル開発でさえ、定義があるにも関わらず問題が起こっている
30. DevOpsの通俗モデル化 ✤ 本当に議論したいことよりも、DevOpsとはどのような意味か、つまり何の通 俗モデルとしてDevOpsという用語を使っているかを議論するために多くの時 間を費やしているのが現状 ✤ 一部の人は「DevOps」という単語を使うのを止めている ✤ DevOpsが何なのかを定義するという問題を避けて、本質的に役に立つ議論が 必要になる
31. 正しそうな問題にアプローチする ✤ 全ての組織はそれぞれ違う ✤ あなたの組織にとって正しいことや求める結果は何か？ が重要になる ✤ ✤ 異なる道筋を通って異なる問題や対立を解決する 「DevOpsをやりたい？」は正しい問題設定なのか？ ✤ 「アジャイルをやりたい」もよく見た
32. Opinion vs Fact (意見か事実か) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) DevOps導入したい!! 設計
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. テスラ(イーロン・マスクCEO) テスラにいる全員が、誰にメールしても会話しても構わないし、またすべきなので す。企業全体の利益のために、自分が考える最速の解決方法をとるべきです。上司の 許可なく上司の上司に相談しても構わないし、別の部門のトップに直接相談してもい いし、私に相談してもらっても構わない。誰かと話すことに誰かの許可は要らないの です。さらに、問題が解決されるまで、自分にその義務があると考えるべきです。こ の狙いは、手当たり次第に世間話をすることではなく、超高速で確実に実行すること です。我々が大手自動車企業と規模で競争できないことは明らかなので、我々は知性 と機敏さで勝負しないといけない。 最後に1つ言っておきたいのは、管理職が注力すべきなのは、企業にサイロが生まれ ないようにすることです。サイロは他者との間に精神的な壁を作り出し、コミュニ ケーションを阻害するのです。残念なことに、サイロができるのは自然な流れなの で、積極的に戦う必要があります。 部門間に障壁を立てたり、会社全体ではなく組織内の相対的な成功を重視したりする ことが、どうしてテスラのためになるでしょうか。我々全員、同じボートに乗ってい ます。自分の部署ではなく、会社の利益のために働くことをつねに意識してくださ い。 訳文は東洋経済オンラインより引用し一部改変 https://toyokeizai.net/articles/-/212417
66. コラボレーションの誤解 ✤ 古くからのシステム管理者に新しい手法は教えられない ✤ 急成長したいときにはロックスターを採用しなければいけない ✤ 多様性に満ちたチームは効果的にコラボレーションできない
67. コラボレーションの問題解決 ✤ チームの誰かが持ち分をこなせていない ✤ 社員を辞めさせるかどうかを決めなければいけない ✤ 私は働きすぎだ、ストレスが溜まっている、燃え尽きた ✤ チームのなかに軽く見られていると感じている人がいる ✤ コミュニケーションが不十分な人がいる ✤ 社員(または候補者)に技術的には優れているけれども不愉快な人間がいる ✤ 現在のチーム / 組織にいる限り自分のキャリアを先に進められる気がしない ✤ 誰も私の言うことを聞いてくれない ✤ 組織再編や人員整理を行ったばかりだ
68. DevOpsに関するよくある誤解 ✤ DevOpsに関係があるのは開発者とシステム管理者だけだ ✤ DevOpsはチームである ✤ DevOpsは肩書だ ✤ DevOpsはウェブ系のスタートアップだけの問題だ ✤ DevOpsには認定資格が必要だ ✤ DevOpsとは、半分の人員ですべての仕事をすることだ ✤ DevOpsには「正しい方法」(または「間違った方法」)がある ✤ DevOpsを取り入れるためにはX週間/Xか月かかる ✤ DevOpsはツールの問題だ ✤ DevOpsとは自動化のことだ ✤ DevOpsは一時的な流行だ
70. あなたの DevOps は役に立ってますか？
