🤔

devopsってCI/CDとかでしょ？って思ってたけど違うらしい

2024/07/25に公開

CI/CD

DevOps

O'Reilly

tech

最近、転職をしまして、最終面接の際にCTOから「devopsって何かわかります？」と聞かれました。

「CI/CDとかの整備？とかですよね〜(あやふや) 🤔」と答えると

「これを読みやがれ！！！(っ'-')╮=͟͟͞͞ 　📘」ということでオライリーのEffective DevOpsを紹介されました。

この本を読んでみると、devopsって思ってたのと全然違うやんけ！！となったのでアウトプットしていこうと思います！

じゃあ、devopsってなによ

結論からいうと、「devops = 組織文化」 です。

もうちょい細かくいうと、devopsはCI/CDなどの効率化のための手段をさすものではなく、ビジネスが価値を実現するスピードを支援するためのより抽象度の高い概念や文化を指す言葉として紹介されています。

devopsを実現するためには、以下で紹介する4つの柱を中心に考えると良いとのことでした。
それらの紹介をする前に、個人的にこの本で面白かったところを紹介していきます。

この書籍の面白かったところ

技術的な内容ではなく、組織文化に焦点を当てている

書籍を読む前は「devopsってCI/CDとかでしょ？書籍にはそれ以外のツールとかがいっぱい書かれてる感じ？」って思ってたのですが、実際に読んでみると、

この書籍の主張は、徹頭徹尾「devopsは、CI/CDなどのツールを入れたから解決するようなもんじゃなくて、個人やチーム単位でdevopsの思想をインプットして行動していくことで実現すんだよ！！！」

というものでした。
技術的な内容は少なく、文化よりの話が大半であったのがイメージとのギャップで面白かったです。

精神論的なところ以外にも、具体的な事例が多く紹介されている

「組織文化に焦点を当てる = 精神論的な話が多い」と思われるかと思いますが、devopsを取り入れた具体的な事例や、あるあるの課題とそれに対する解決策などが多く紹介されているので、実践的な内容も多いです。

もっと従業員を大切にしようぜ！って感じが令和っぽかったw

従業員を大切にすると、結果的に組織にも還元されるぜ的な思想が、令和っぽかったです。

具体的には、多様性を重視してチームにはいろんなメンバーを入れるといいんだよ〜とか、業務の中で学習できる環境にした方がいいんだぜ〜(学習させたらもっと良い企業に引き抜かれるんじゃね？って考えは違うぜ)とか、、、etc

devopsの4つの柱

devopsは「コラボレーション」「アフィニティ」「ツール」「スケーリング」の4つの柱で成り立っています。

それぞれを一言で言うと、以下のような感じです。

devopsの4つの柱	概要
コラボレーション	devopsの成功のために一緒に働く人たちとリスペクトを持った良好なコミュニケーションを取る方法(個人にフォーカス)
アフィニティ	チーム間で協力して助け合うためのコミュニケーションを取る方法(コラボレーションのチームにフォーカスした版)
ツール	devopsを加速させるための道具 (CI/CDやIaCなど)
スケーリング	企業がフェーズや規模に応じて組織に合ったdevopsの施策を更新していくこと

個人的には、コラボレーションとアフィニティを重視しているように感じました。

以下では、それぞれの柱について個人的に特におもしろかった箇所を紹介していきます。

コラボレーション

コラボレーションは「お互いリスペクト持って尊重、協力しようぜ」ってやつです。

フィードバックの役割と制度

チーム全体で成長志向になる必要がある
- ❌ 固定思考 → 能力は生まれながらに一定、失敗は避けるべき
- ⭕️ 成長思考 → 大体のことは努力で変えられる、失敗は学びの機会
チーム全体を成長志向にするに、フィードバックの対象は"努力", "行動", "成果", "思考" の4つするべき
- ❌ 固定思考へ促すフィードバック : 生まれつきの性質や変更不能な事実を暗示
  - 「君は賢いね」
  - 「君は人付き合いが苦手だね」
- ⭕️ 成長思考へ促すフィードバック : 行動に着目し、将来すべきことに焦点を当てる
  - 「〇〇について努力してきたことが伝わる」
  - 「〇〇をすればもっと良くなると思う」
次のアクションに繋がるフィードバックは、頻繁に行った方が良い
- フィードバックもアジャイルに！！
- フィードバックを高速に回すことで、問題への対処も早くなる
- 逆に言えば、次に繋がらないFBはやらない方が良い

コラボレーションに対する誤解

❌ 急成長したい時には「人間性に問題はあるがスキルはすごい人」を採用しても良い
- 企業を軌道に乗せるにはチーム全体の成長が必要だが、人間性に問題がある人物はチーム全体の成長を阻害する(どんなにスキルがあってもダメ)
- 「信頼、共感、相互性がない企業は長期的には衰退する😱」
- NetflixのCEOも同じこと言ってたはず、たぶん。。。
❌ 多様性に満ちたチームは効果的にコラボレーションしない
- 短期的には対立が増えるが、長期的には創造性や問題解決能力が高くなる

アフィニティ

アフィニティは「同じ組織だから俺ら、違うチームだけど協力してこうぜ、目的は同じだろ？」ってやつです。

アフィニティに必要なもの

遊び(バッファ)
- 遊び(バッファ)は、ワークライフバランスと個人の健康維持に重要な意味を持っている
- 割り込みの仕事が多いチームではより多めに設定する必要がある
ソフトスキルに対する明示的な目標と価値観、評価
- スキルマトリックスなどには、ソフトスキルに対する評価基準も明示的に記載するべき
- 記載し、実際に評価対象に含めることで、ソフトスキルが評価される文化を醸成する
- ソフトスキルも評価対象に入る = スキルはあるが人間性に難があるタイプの人材は評価されにくくなり、結果として組織全体のアフィニティが向上する
スペース
- オフィスに共有の休憩スペースを設けることで、チーム間のコミュニケーションが増える
- ※ 共有スペースで、あるチームの方が他チームより優先されるようなことはNG
コラボレーションと協力
- アフィニティのすべてのメリットを享受したいなら、人間関係を構築するための仕事や行動を推進し評価する文化を持たなければならない

アフィニティを向上させるための具体例

指名運用エンジニア
- ※ある程度、運用チームの人数がいないと成り立たないので注意
- [ 目的 ] チーム間で共通な地盤を見つける
- 各PJに対して、運用チームから1人ずつ指名して担当をつける
- 指名されたエンジニアは、PJに関する会議などに出席し、定期的にコミュニケーションを取る
- [ メリット ]
  - 運用"チーム"に投げていた問題を担当(窓口)を設けることで、PJの問題やコンテキストの共有コストを削減
  - 定期的にコミュニケーションを取ることで問題になりそうな事象を早めにキャッチできる
    - ex) APIエンドポイントが追加される場合に、APIクラスタの負荷増加が見込まれるので早めに対処できる
  - チャットのみのやり取りでなく名前と顔が一致することで、コミュニケーションが円滑になり、お互いのチームへのリスペクトにつながる
  - 新しい知識を学習する機会が増え、それぞれのチーム間の垣根が薄れて行く

チームのコミュニケーションの改善

コミュニケーションは足りないよりは、多すぎる方が良い
- 情報が足りないと、チーム間の隔たりが強くなりやすい
危機状況下でのコミュニケーションテクニック
- Two Challenge ルール
  - 疑問に思うことは2回まで質問して良い
  - 特に危機状況では疑問を安心して発言できることが大切になる
- CUS
  - 下記の3つの場合は発言した方が良い！
    - C : Concern(懸念がある)
    - U : Unsure(不確実なことがある)
    - S : Safety(安全性に問題がある)
- SBAR
  - 下記のフォーマットで説明すると良い！
    - Situational(何が起きている？)
    - Background(それを理解するのに必要な背景)
    - Assessment(問題点はどこ？)
    - Recommendation(どうすればいい？かの提案)

ツール

ツールは「CI/CDなど、devopsを加速させるための道具」です。

この章では、「このツールを使うと良いよ！」って情報より、ツールに対する考え方などにフォーカスしている印象でした。

ツールはあくまでも手段であり、目的ではない。 って考えるのが大事らしいです。

ツールは評価するべき

ツールは定期的に評価し、必要に応じて変更する
- 組織のフェーズなどで使うべきツールは変化する
- 合わないツールを削減することによるメリット
  - ツール起因の不要なタスクの削減
  - コスト削減
必ずツールを評価する調達プロセスを入れるべき
- ツールを導入する際に、個人的な興味・関心で導入するのは良くない
- ツールを選ぶ際には、「ツールが組織のdevops文化にどう影響を与えるか？」 が重要
- それを必ず評価できるように、ツールの導入には調達プロセスを入れるべき
特定のツールを使いたい個人との対話では 「使いたがっているツールでもちゃんと問題を解決できるのか？」 を基準に判断するのが良い
ツールの評価は SMART に！
- S : Specific(具体的)
- M : Measurable(測定可能)
- A : Achievable(達成可能)
- R : Realistic(現実的)
- T : Time-bound(期限付き)
- SMARTに沿って、部品を細かく分解して評価することで、より評価しやすくなる
「ツールの導入に成功した(devops文化に良い影響を与えた)」の基準を作る際の観点
1. ツール選択についての意思決定の責任者は誰か？
  - amazonでも、責任者はバイネームで決めているらしい(聞いた話だが、たぶんそう)
2. ツールとその使い方を選択し評価する時、どの基準を使うか？
3. エンジニアの幸福と顧客の幸福の両方のために何を優先させるか？
大事なのはどのツールを選択したか？ではなく「このツールを選択する際、どのようなことを考え、どのようなトレードオフを秤にかけたか、使うツールについての判断をどのようにまとめたか？」
ツールの成功の測定には 「透明性」 と 「モニタリング」 が大事！！！
- 透明性
  - 計測したデータを誰でも閲覧できるようにすること
- モニタリング
  - システムレベルのパフォーマンスからビジネスレベルのメトリクスまで、可能な限りデータを継続的に収集すること
  - モニタリングしたデータを透明性を持って公開することで、プラットフォームを持続的な形で運営できる!
  - ポイントは一気に導入するのではなく、顧客にとって一番大きな影響を与える部分から計測していき、PDCAを回して自社に合う最適なモニタリングの形を目指すこと
    - 細かくアップデートを繰り返すことで、いつの間にか「なんでも測定する」習慣が身に付く

スケーリング

スケーリングは「組織フェーズによってdevopsのやり方は変わるから、柔軟に変更していこうぜ」ってやつです。
面白かったのは、"大企業のdevops"と"スタートアップのdevops"のように、devopsを二分できるほど単純じゃねぇよ？ってところでした。

組織が成功するには、必要に応じて組織を拡大/縮小することが重要 らしいです。

スケーリングするために意識すべきこと

銀の弾丸はないと理解すること
- ①システムをどのように動作させるか？, ②大局的に見て今大切なことは何か？ を理解することが重要
- ①,②を理解すれば、組織内で柔軟にして良い部分といけない部分を意識的に決めることができる
- ex) 「モノリスよりマイクロサービスが優れている」ではなく、今の組織やシステムにとってどちらが適しているかを考えることができる
タスクから属人性を排除する
- 属人性のあるタスクがあると、そのタスクが担当者に依存してしまいスケールが遅くなる

チームのスケーリングと成長戦略

チームを強化するための戦略
- チームを小さく柔軟なものに保つ
  - 組織全体でdevops共同体の有効性を保つために、チームの規模は小さく保つべき！
  - 知識が個人に偏っている状態は、ボトルネックになりやすい(チームを小さく保てていない兆候)
  - グループの最適な人数は4.6人(研究結果によるもの)
  - 「これ以上はチームの人数を増やすしかないよね」がチームを分割する際の基準
    - 基本的に同じ仕事をすると段々、効率は良くなる
    - これ以上、効率を良くできない(よくするには人を増やすしかない)状態 = 小さく保つメリットが最大である状態
    - これ以上増やすと、コミュニケーションコストの肥大化や、結束力の低下などデメリットの方が大きくなる
- コラボレーションを育てる
  - 生産的なチームは 「密接にコミュニケーションを取り合い、平等に参加し、空気を読むスキルを持っている」
  - 優秀で協調や協力を大切にするチームの特徴
    - 持ちつ持たれつの関係である(互いにGiveし合っている)
    - 個人とグループが説明責任を果たしている
      - 人は自由が与えられれば自分のベストを尽くしたいと思うもの
      - 全員が質の高い仕事をしていると思っている状態 = チーム全体が信頼、共通の価値観、結束力がある状態
      - この状態のチームは、問題発生から退所までの時間が短くなる
- 摩擦や対立をうまく捌く
  - 対立があるのは健全な組織である証拠
    - 対立がない組織 = メンバーが同一的で多様性がない
    - 大事なのは対立に対して適切に対処すること。対立が起きるのは悪くない。むしろ良いこと。
    - ハラスメントなどはNGだが、対立はOK
  - 個人が感じる対立は基本的には1on1で早期解決を図る
    - ※ ただし個人と組織全体の方向性が合わない場合は、割り切って組織を離れることを後押しする選択肢もあり
    - ※ 仕方ないことと割り切るのがお互いのため
  - チーム全体で感じる対立は、経営やマネジメントの責任
    - いつから起きていたか、チームに対する期待値は適切かを判断する責任がある