『Effective DevOps』読んだ: DevOpsという文化の作り方
目次
本書のターゲット
本書を「DevOpsの技術的解説書」と期待して読むと肩透かしを食う。本書はDevOpsを文化・価値観と捉えその文化を醸成するための考え方やアプローチについて解説する。
したがって本書のターゲットとなるのは現場でバリバリ働くエンジニアというよりは、より良い技術組織作りやチームビルディングに興味のあるリーダーやエンジニアマネージャーと言える。
Effective DevOpsの4本柱
『Effective DevOps』―本書の副題は「4本柱による持続可能な組織文化の育て方」となっている。ではここでいう4本柱とは何か？というと下記4つである。
- コラボレーション: チームをどう協調させるべきか
- アフィニティ: チームのコミュニケーションの質をどう上げて団結力を強めるべきか
- ツール: どんなツールを採用すべきか
- スケーリング: 組織をどう発展・成長させていくべきか
この4本柱でわかる通り、本書はほとんどがコミュニケーションの話であったり、考え方や振る舞い方の話であったりする。
3本目にツールの話があるように見えるが具体的なツール名を期待してはいけない。「ツールXを使っているからDevOpsだ」という言説は勘違いであり、どんなツールを使っているかは本質的にはDevOpsには関係ないからだ。
devopsアンチパターン
-
避難文化
- ミスが発生したときに人を避難し処罰することはやってはならない
- 避難文化があると人々が避難されるまいと情報を隠蔽してしまう
-
サイロ化
- 目的や責任を共有せずあそれぞれバラバラの役割を重視する状態
- サイロ化が進むと責任を他のチームになすりつけることになる
-
ヒューマンエラーを原因にしない
- ミスを犯した人間自体がエラーの原因だとする考え方
- ヒューマンエラーだと片付けない、そこからチームが学習することが大事
コラボレーションの例
コラボレーションの例としては下記のようなものが考えうる。
- 非同期でのコードレビュー
- ドキュメンテーション
- 問題のアップデートとバグレポート
- その週に進んだ内容のデモ
- 定期的な状況・進捗報告
- ペア作業（ペアプロ、モブプロ）
個人の成長のために
- 基本を学ぶ
- 自分に必要なスキルは何か、チームに必要なスキルは何か、誰が何をしているか基本を学ぶ
- 学習能力を高める
- 学習プロセスを見直す、学習能力を強化する
- 質の高い実践を心がける
- 学んでいるスキルを正しく使う
- 惰性的な習慣を見直し、使うツールやテクニックなど自分のスタイルを開発する
- 新しいスキルを学ぶ、既存のスキルを強化する
- 絶えず自分自身に課題を与え自分自身を向上させていく
コミュニケーションの手段
| コミュニケーション手段 | 即時性 | オーディエンス への浸透度 |
受け手 の負担 |
コンテキスト | 構成の 緻密さ |
|---|---|---|---|---|---|
| 電子メール | ✕ | ○ | 普通 | 多い | △ |
| 臨時会議（ビデオ会議） | ○ | ✕ | 普通 | 少ない | ✕ |
| チャット | △ | △ | 軽い | 多い | ✕ |
| 正式な会議 | ✕✕ | ○ | 重い | 少ない | ○ |
| Twitter（マイクロブログ） | ✕ | △ | 軽い | 多い | ✕ |
| GitHubのプルリクエスト | ✕ | △ | 普通 | 普通 | △ |
| 付箋紙のメモ | ✕✕ | △ | 軽い | 多い | ✕ |
| PagerDutyアラート | ○ | ○ | 重い | 普通 | ✕ |
| 書籍・ブログ記事 | ✕✕ | ✕ | 普通 | 普通 | ○ |
| 画像・グラフ | ✕ | ✕ | 軽い | 多い | ✕✕ |
- 即時性: コミュニケーションがどれだけ早く成立するか
- オーディエンスへの浸透度 : オーディエンスにメッセージを届けるためにどれくらい効果的か
- 負担: そのコミュニケーションに参加するための必要な時間と労力
- コンテキスト: 特定のコミュニケーション方法で必要とされるコンテキストがどれくらいあるか
- 構成の緻密さ: 伝えたいことがどれくらい緻密に構成されていなければいけないか
優れたリーダーの条件
- 周囲から最良のものを引き出す
- 自分自身や少数の「ロックスター」だけを重視してはならない。周りにいるすべてのひとたちから裁量のものを引き出せ
- 優秀な組織とそうでない組織の違いはこの能力の有無で出る
- メンバー個人のビジョンと企業やチームのビジョンを一致させるように支援する
- 規範たれ
- リーダーは自分が期待している行動の規範となるべき
- まわりのひとはリーダーの悪い行動も真似ることがあるので気をつけろ
- クソの傘たれ
- 上層部から強力（不条理）な指示があった場合にチームを守る
- メンバーの仕事の邪魔になるバカげたことをできる限りシャットアウト
- リーダーは「私」中心に考えない、「私たち」、つまりチームを中心に考える
対立のマネジメント
- 対立があること自体はチームの健全性を示す
- 対立はチームに新しい発想や視点をもたらす
- 個人・チーム・組織が成長するには健全な対立を解決するスキルが必要
- 対立の要因
- チームの目標と個人の目標の不一致
- 組織の目標と個人の目標の不一致
- インセンティブの不一致
- チーム外部との対立
- チームごとのモチベーション、目標の違いが原因
- 非現実的な期待
- マネジメント側の責任
新技術導入時の注意事項
- 新技術の既知のリスクはなにか？
- どんな未知の不確定要素にぶつかる可能性があるか？
- 既存の記述では解決できない、どんな問を題解決しようとしているのか？
その他の読書メモ
- ブリリアントジャークは採用の対象外にすべき p99
- 組織再編時に自問すべきこと p102
- なぜ行われているか
- タイミングは適切か
- 仕事は変わった？
- 後退局面ではないか？
- 人手不足に陥っていないか？
- 危機的状況時のコミュニケーションテクニック p133
- CUS
- Concerned
- Unsure
- Safety
- SBAR
- Situatonal
- Background
- Assessments
- Recommendation
- CUS
- 大がかりな文化的、技術的改革を成し遂げるためには共通のビジョン、目標、基準が必要 p136
- ハードスキルだけでなくソフトスキルの評価も必要 p142
- 技術だけでなく人間関係もケアしろ p155
- devops改革を成功させるためにトップダウンの支援も必要 p158
- ツールが文化に影響を与える p182
- 例: Slack導入が組織のコミュニケーション様式に影響を与える
- 思いやりの文化 p199
- 感謝の重要性
- 非難のない文化 p200
- ツールの合意を得ることは難しい、声のでかい人をどう判断するか p215
- 決定プロセスに参加させる p216
- チームの定着
- 報酬 p231
- 給料上げるためには転職が一番よい
- 特典 p233
- リモート
- 教育
- フレックス
- ワークライフバランス
- 有給休暇
- 退職金
- 健康保険
- カジュアルドレス
- 移動手段
- 性別不問のトイレ
- 託児所
- 報酬 p231
- 昇進のプロセスを可視化 p235
- 簡単ではないが実行可能なワークロードを与える p235
- 品質の定義 p253
- 価値観を伝える p292
- 相手に心の準備
- コミュニケーションスキルのレベルアップ
- 可能なら対面
- 記録して繰り返す
- 情報を可視化し共有する
- 退職を口止めするな p312
- 文化的負債 p314
まとめ
- 技術組織をリードする立場の人であれば『Effective DevOps』を読んでおいて損はなさそう
- DevOpsは文化そのものであり、自動化しているからdevops、高度なツールを導入しているからdevopsとかそういったものではない
- DevOpsの４本柱はコラボレーション、アフィニティ、ツール、スケーリング