Book description
DevOpsには技術的な側面だけでなく、開発や運用をはじめとするさまざまな部門を繋げる組織文化を構築するという重要な側面があります。本書では、主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します。「DevOpsの4つの柱」としてコラボレーション、アフィニティ（親近感、一体感）、ツール、スケーリングを挙げ、さらに組織が変化するために「4つの柱」がどのように機能するかについても解説します。 組織の内側から変化を起こし、変化を促進して組織全体へとその影響を広げ、持続可能な組織を構築する方法を紹介します。
Table of contents
- 大扉
- 原書大扉
- クレジット
- 本書への推薦の言葉
- ジョン・アレスポウによる序文
- ニコール・フォースグレンによる序文
- 監訳者まえがき
- 謝辞
- はじめに
- 効果的なdevopsを導入するには
- Devops、devops、DevOps: どれがよいか
- 対象読者
- 本書の構成
- ケーススタディーの方法論
- 表記
- お問い合わせ
- 謝辞
- リンより
- ジェニファーより
- 第Ⅰ部 devopsとは何か
- 1章 大局を見る
- 1.1 devops文化のスナップショット
- 1.2 文化の発展の経緯
- 1.3 ストーリーの価値
- 1.4 リンのストーリー
- 1.5 ジェニファーのストーリー
- 1.6 devopsをストーリーで説明する
- 2章 devopsとは何か
- 2.1 文化のための処方箋
- 2.2 devopsの方程式
- 2.2.1 通俗モデルとしてのdevops
- 2.2.2 古い見方と新しい見方
- 2.2.3 devops共同体
- 3章 devopsの歴史
- 3.1 オペレーターとしての開発者
- 3.2 ソフトウェアエンジニアリングの始まり
- ソフトウェアの課題
- 3.3 プロプライエタリソフトウェアと標準化の登場
- 3.4 ネットワークの時代
- 3.5 グローバルなコミュニティの始まり
- 3.6 アプリケーションとウェブの時代
- 3.7 ソフトウェア開発手法の発展
- 3.8 オープンソースソフトウェアとプロプライエタリサービス
- 3.9 アジャイルインフラストラクチャー
- 3.10 DevOpsDaysの始まり
- 3.11 devopsの現状
- 3.12 まとめ
- 4章 基本的な用語と概念
- 4.1 ソフトウェア開発手法
- 4.1.1 ウォーターフォール
- 4.1.2 アジャイル
- 4.1.3 スクラム
- 4.2 運用手法
- 4.2.1 ITIL
- 4.2.2 COBIT
- 4.3 システム手法
- 4.3.1 リーン
- 4.4 開発、リリース、デプロイの諸概念
- 4.4.1 バージョン管理
- 4.4.2 テスト駆動開発
- 4.4.3 アプリケーションのデプロイ
- 4.4.4 継続的インテグレーション
- 4.4.5 継続的デリバリー
- 4.4.6 継続的デプロイ
- 4.4.7 MVP（実用最小限の製品）
- 4.5 インフラストラクチャーに関する概念
- 4.5.1 構成管理
- 4.5.2 クラウドコンピューティング
- 4.5.3 インフラストラクチャー自動化
- 4.5.4 アーティファクト管理
- 4.5.5 コンテナ
- 4.6 文化的な概念
- 4.6.1 レトロスペクティブ
- 4.6.2 ポストモーテム
- 4.6.3 非難のない文化
- 4.6.4 組織的な学習
- 4.7 まとめ
- 5章 devopsに対する誤解とアンチパターン
- 5.1 devopsに対するよくある誤解
- 5.1.1 devopsに関係があるのは開発者とシステム管理者だけだ
- 5.1.2 devopsはチームである
- 5.1.3 devopsは肩書だ
- 5.1.4 devopsはウェブ系のスタートアップだけの問題だ
- 5.1.5 devopsには認定資格が必要だ
- 5.1.6 devopsとは、半分の人員ですべての仕事をすることだ
- 5.1.7 devopsには「正しい方法」（または「間違った方法」）がある
- 5.1.8 devopsを取り入れるためにはX週間/Xか月かかる
- 5.1.9 devopsはツールの問題だ
- 5.1.10 devopsとは自動化のことだ
- 航空業界における初期の自動化
- 5.1.11 devopsは一時的な流行だ
- 5.2 devopsのアンチパターン
- 5.2.1 非難文化
- 5.2.2 サイロ
- 5.2.3 根本原因分析
- 5.2.4 ヒューマンエラー
- 5.3 まとめ
- 6章 効果的なdevopsのための4本柱
- 6.1 コラボレーション
- 6.2 アフィニティ
- 6.3 ツール
- 6.4 スケーリング
- 6.5 まとめ
- 第Ⅱ部 コラボレーション
- 7章 コラボレーション: ともに仕事をする個人たち
- 7.1 Sparkle Corpの週次プランニングミーティングにて
- 7.2 コラボレーションの定義
- 7.3 個人の違いと経歴、背景
- 7.3.1 職業人としての経歴
- 7.3.2 個人的な経歴
- 7.3.3 目標
- 7.3.4 認知スタイル
- 7.4 競争優位を得るためのチャンス
- 7.5 メンターシップ
- 7.5.1 上位者から下位者へのメンタリング
- 7.5.2 上位者同士のメンタリング
- 7.5.3 下位者から上位者へのメンタリング
- 7.5.4 下位者同士のメンタリング
- 7.6 マインドセット入門
- 7.6.1 正しいマインドセットを育てる
- 7.6.2 固定思考
- 7.6.3 成長思考
- 7.6.4 個人の成長
- 7.7 マインドセットと学習する組織
- 7.8 フィードバックの役割
- 7.9 評価とランキング
- 7.9.1 フィードバックの頻度
- 7.9.2 ランキングシステム
- 7.9.3 ロックスターやスーパーフロックの問題
- 7.9.4 チームにとっての社会関係資本の価値
- 7.10 コミュニケーションと対立の解決スタイル
- 7.10.1 効果的なコミュニケーション
- コミュニティ・オブ・プラクティスとコミュニティ・オブ・インタレスト
- 7.10.2 コミュニケーションの形
- 7.10.3 コミュニケーションのコンテキストと権力関係
- 7.11 共感と信頼
- 7.11.1 共感を育てる
- 7.11.2 信頼を育てる
- 7.12 人材配置と人事管理
- 7.12.1 勤務時間と健康
- 7.12.2 ワークライフバランス
- 7.12.3 チームの規模が与える影響
- 7.13 Sparkle Corpの効果的なコラボレーション
- 7.14 まとめ
- 8章 コラボレーション: 誤解と問題解決
- 8.1 コラボレーションの誤解
- 8.1.1 古くからのシステム管理者に新しい手法は教えられない
- 8.1.2 急成長したいときにはロックスターを採用しなければいけない
- 8.1.3 多様性に満ちたチームは効果的にコラボレーションできない
- 8.2 コラボレーションの問題解決
- 8.2.1 チームの誰かが持ち分をこなせていない
- 職務に対する期待
- 8.2.2 社員を辞めさせるかどうかを決めなければいけない
- 8.2.3 私は働きすぎだ、ストレスが溜まっている、燃え尽きた
- 8.2.4 チームのなかに軽く見られていると感じている人がいる
- 8.2.5 コミュニケーションが不十分な人がいる
- 8.2.6 社員（または候補者）に技術的には優れているけれども不愉快な人間がいる
- 8.2.7 現在のチーム/組織にいる限り自分のキャリアを先に進められる気がしない
- 8.2.8 （もう）誰も私の言うことを聞いてくれない
- 8.2.9 組織再編や人員整理を行ったばかりだ
- 第Ⅲ部 アフィニティ
- 9章 アフィニティ: 個人からチームへ
- 9.1 Sparkle Corpの開発デモの日
- 9.2 人のネットワーク
- 9.3 チームはどのように作られるか
- 9.3.1 チームが行う仕事
- 9.3.2 アフィニティの定義
- 9.3.3 チーム内の個人間の結び付き
- 9.3.4 チームの文化
- devopsのアンチパターン: 文化適合性
- 9.3.5 チームの団結力
- 9.3.6 多様性
- 9.3.7 多様性のメリット
- 9.3.8 多様性とインターセクショナリティの軸
- 無意識の偏見
- 9.3.9 採用時に考慮すべきこと
- 9.3.10 開放的な環境の維持
- ステレオタイプ脅威
- 9.4 チームと組織構造
- 9.5 チーム間で共通な地盤を見つける
- 9.5.1 競争から協調へ
- 9.5.2 チームの共感を築く
- 9.5.3 チームのコミュニケーションの改善
- 9.6 ケーススタディー：米国特許商標庁
- 9.6.1 背景と方向性
- 9.6.2 コラボレーションとアフィニティの奨励
- 9.6.3 複数の視点のバランスを取る
- 9.7 アフィニティ向上の効果
- 9.7.1 サイクルタイムの短縮
- 9.7.2 コミュニケーションの障害の除去
- 9.7.3 信頼
- 9.7.4 イノベーション
- 9.8 アフィニティのために必要なもの
- 9.8.1 遊び
- 9.8.2 明示的な目標と価値観
- 9.8.3 スペース
- 9.8.4 コラボレーションと協力
- 9.9 アフィニティの計測
- 9.9.1 社員のスキルと評価
- 9.9.2 チーム間の交渉
- 9.9.3 コミュニティへの返礼
- 9.10 Sparkle CorpのDevとOpsのアフィニティ
- 9.11 まとめ
- 10章 アフィニティ: 誤解と問題解決
- 10.1 アフィニティの誤解
- 10.1.1 運用エンジニアは企業にとって開発者ほど役に立たない
- 10.1.2 外部と共有しすぎると競争優位が弱まる
- 10.2 アフィニティの問題解決
- 10.2.1 ひとりまたは複数の個人がグループフローを妨害する
- 10.2.2 あるチームが別のチームの仕事を止めてしまう
- 10.2.3 一部のチームが評価されていないと感じる
- 10.2.4 互いに相手を信頼していないように見える
- 10.2.5 仕事の技術的な側面ばかり考えていて人間関係について考えていない
- 10.2.6 共同作業をしているチームが本当の意味で共同作業できるように見えない
- 10.2.7 過去の個人間の対立が現在のチーム間の対立の原因になっている
- 10.2.8 チームXがサイロに閉じこもりたがっているように見える
- 10.2.9 devopsの些細な過ちを強く非難する人がいる
- 第Ⅳ部 ツール
- 11章 ツール: エコシステムの概要
- 11.1 ソフトウェア開発
- 11.1.1 ローカル開発環境
- 11.1.2 バージョン管理
- 11.1.3 アーティファクト管理
- 11.2 自動化
- 11.2.1 サーバーのインストール
- 11.2.2 インフラストラクチャーの自動化
- 11.2.3 システムのプロビジョニング
- 11.2.4 テストとビルドの自動化
- イボンヌ・ラムによるテスト、モニタリング、診断の定義
- 11.3 モニタリング
- 11.3.1 メトリクス
- 11.3.2 ロギング
- 11.3.3 アラート
- 11.3.4 イベント
- 11.4 エコシステムの発展
- 11.5 まとめ
- 12章 ツール: 文化を加速させるもの
- 12.1 人間にとってのツールの意味
- 12.2 ツールとは何か
- 12.3 本当の問題に対応する適切なツール
- 12.4 オープンソースとの距離
- 12.5 ツールの標準化
- 12.6 一貫性のあるツール分析プロセス
- 12.7 標準化に対する例外
- 12.8 ツールの意味
- 12.8.1 ツールではなくプロセスの失敗
- 12.8.2 ツール選択におけるコンウェイの法則
- 12.9 ツールが文化に与える影響
- 12.9.1 コミュニケーションに影響を与えるツール
- ホリー・ケイ氏の「聴覚障害のある開発者であること」
- 12.9.2 さまざまな行動に影響を与えるツール
- 12.10 ツールの選定
- 12.10.1 製品の開発状況
- 12.10.2 コミュニティの健全性
- 12.10.3 内部でのカスタマイズの可能性
- 12.10.4 実例: バージョン管理システムの比較
- 12.10.5 実例: インフラストラクチャーの構成の自動化
- 12.11 ツールエコシステムの検証
- 12.12 ツールの削減
- 12.12.1 改善: 計画立案と変化の測定
- 12.13 ケーススタディー
- 12.14 DramaFeverの場合
- 12.14.1 既存技術の影響
- 12.14.2 新しい技術からの継続的な影響
- 12.14.3 アフィニティがプラクティスの浸透を促進する
- 12.14.4 DramaFeverのツール選択
- 12.15 Etsyの場合
- 12.15.1 明示的な文化と暗黙的な文化
- 12.15.2 思いやりの文化
- 感謝の重要性
- 12.15.3 非難のない文化
- 12.15.4 リモートフレンドリー
- 12.15.5 ツールによって取り組みを確かなものにする
- 12.15.6 買うか作るか
- 12.15.7 自動化についての考え方
- 12.15.8 成功の測定
- 12.16 モチベーションと意思決定の難しさ
- 12.17 Sparkle Corpの効果的なツール利用
- 12.18 まとめ
- 13章 ツール: 誤解と問題解決
- 13.1 ツールの誤解
- 13.1.1 技術Xから、他社にあわせて技術Yに移行しなければいけない
- 13.1.2 技術Xを使っているので、うちはdevopsを実践している
- 13.1.3 間違ったツールを選ばないように注意しなければいけない
- 13.1.4 devopsツール全部入りセットやdevops-as-a-serviceを買ってくればよい
- 13.2 ツールの問題解決
- 13.2.1 技術Xのベストプラクティスを見つけようと努力している
- 13.2.2 ひとつのツールにする合意が得られない
- 13.2.3 技術Xの採用（または廃止）を決めたが、社員がそれに抵抗している
- 第Ｖ部 スケーリング
- 14章 スケーリング: 変曲点
- 14.1 スケーリングの理解
- 14.2 大企業のdevopsについて考えるべきこと
- 14.2.1 devopsによる組織の戦略的拡大/縮小
- 14.2.2 意識的なスケーリングのために考えるべきこと
- 14.2.3 スケーリングのための準備
- 14.3 組織の構造
- 14.3.1 地域性
- 14.4 チームの柔軟性
- 官僚主義の横行？
- 14.5 組織のライフサイクル
- 14.5.1 吸血鬼プロジェクトやゾンビプロジェクトの整理
- 14.5.2 リリースサイクルの影響
- 14.6 複雑さと改革
- 14.7 チームのスケーリング
- 14.7.1 チームの成長: スケーリングとしての採用
- 14.7.2 社員の定着
- 燃え尽き
- 14.8 ケーススタディー：チームの成長とスケーリング
- 14.8.1 運用チームの構築と育成
- 強い意見と弱い執着
- 14.8.2 「英雄文化」の問題点
- 14.8.3 求人票と採用活動の問題点
- 14.8.4 個人とチームの育成
- 14.8.5 チームメンバーの育成と成長
- 14.9 チームのスケーリングと成長戦略
- 14.9.1 チームを小さく柔軟なものに保つ
- 14.9.2 コラボレーションを育てる
- 14.9.3 対立のマネジメント
- 14.10 組織のスケーリング
- 14.10.1 中央集権チームと臨時チーム
- 14.10.2 リーダーシップの構築
- 14.11 ケーススタディー：政府デジタルサービスgov.uk
- 14.11.1 明示的な文化
- 14.11.2 計画立案
- 14.11.3 抱えている難問
- 14.11.4 アフィニティの構築
- 14.12 ケーススタディー：Target
- 14.13 Targetの分析
- 14.13.1 望ましい結果から始める
- 14.13.2 大企業のなかでのアフィニティ
- 14.13.3 大企業のツールと技術
- devopsにおけるセキュリティの重要性
- 14.13.4 大企業における知識の共有
- 14.14 まとめ
- 15章 スケーリング: 誤解と問題解決
- 15.1 スケーリングの誤解
- 15.1.1 一部のチームは共同作業できない
- 15.1.2 改革を始めるためには経営陣の全面的な支持が必要だ
- 15.1.3 すぐには採用の予算が得られないのでdevopsを始められない
- 15.2 スケーリングのトラブルシューティング
- 15.2.1 上がXを続けることを主張し続け、devopsの価値を認めない
- 15.2.2 チームが忙しすぎる
- 15.2.3 よい判断が下せていない
- 15.2.4 ほしい人材を引きつけることができない
- 15.2.5 組織変更や人員削減のために士気が下がっている
- 15.2.6 Xのために独立したチームが必要かどうかわからない
- 第Ⅵ部 devops文化への架け橋
- 16章 devopsの4本柱を使って架け橋をつくる
- 16.1 ストーリーの重要性
- 16.1.1 明示的なストーリーと暗黙のストーリー
- New RelicのSREエンジニア、アリス・ゴールドフス
- 16.2 devopsの理論と現実
- 16.2.1 現実のケーススタディー：実践を示すストーリー
- 16.2.2 ストーリーから学ぶこと
- 16.2.3 ストーリーで結び付きを作る
- 16.3 まとめ
- 17章 devops文化への架け橋: ストーリーから学ぶ
- 17.1 ストーリーが文化について教えてくれること
- 17.1.1 価値観
- 17.1.2 禁止事項
- 17.1.3 神話
- 17.1.4 儀式
- 17.1.5 アイデアと知識
- 17.2 組織の壁を越えた交流
- 17.2.1 カンファレンスと出張
- 17.2.2 コミュニティのその他のイベント
- 17.2.3 エンジニア交換
- 17.3 組織の壁を越えたアフィニティ
- 17.3.1 固定思考を避ける
- 17.3.2 小さな変更から始める
- 17.4 まとめ
- 18章 devops文化への架け橋: 人と人のつながりを育てる
- 18.1 仕事をめぐる個々のストーリーとナラティブ
- 18.1.1 テイラー主義と個人のストーリーの価値
- ホリー・ケイのdevopsについての発言
- 18.1.2 大切にされる人
- エンタープライズフィールドソリューションアーキテクト、ニコール・ジョンソンの発言
- 18.1.3 リモート勤務
- 18.1.4 退職の形
- 18.2 文化的負債
- 18.3 システムの健全性
- 18.3.1 病んだシステムの分析
- 18.3.2 健全なシステムの構築
- 18.3.3 組織の健康と個人の健康
- 18.3.4 健全な文化と不健全な文化の見分け方
- 18.4 まとめ
- 19章 まとめ
- 19.1 次のステップ
- 19.2 効果的なdevopsを生み出すために
- 20章 さらに深く学習するために
- 20.1 devopsとは何か
- 20.2 コラボレーション: ともに仕事をする個人たち
- 20.3 アフィニティ: 個人からチームへ
- 20.4 ツール: 文化を加速させるもの
- 20.5 スケーリング: 変曲点
- 20.6 devops文化への架け橋
- 20.7 お薦めのカンファレンスとミートアップ
- 20.8 お薦めのPodcast
- 奥付
Product information
- Title: Effective DevOps ―4本柱による持続可能な組織文化の育て方
- Author(s):
- Release date: March 2018
- Publisher(s): O'Reilly Japan, Inc.
- ISBN: 9784873118352
You might also like
book
実践 Keycloak ―OpenID Connect、OAuth 2.0を利用したモダンアプリケーションのセキュリティー保護
Keycloakは、シングルページアプリケーション（SPA）、モバイルアプリケーション、REST APIなどのモダンなアプリケーションに焦点を当てた、オープンソースのIdentity and Access Management（IAM）ツールです。 小規模なウェブサイトから、数百万人のユーザーを抱える大企業まで、さまざまなシナリオの本番環境で使用されています。 本書は、開発コミュニティーのプロジェクトリーダーとコアディベロッパーが著した、Keycloakの包括的な解説書です。インストール方法から、管理コンソールやアカウントコンソールの使い方、本番環境での使用に備えた設定方法、ユーザーの管理、トークンとセッションの管理、SPIによるカスタマイズまでを詳しく解説しています。さらに、アプリケーションのセキュリティーを保護する方法や、OAuth 2.0とOpenID Connect（OIDC）を理解するための基礎知識も紹介します。さらに日本語版では補章として「クライアントポリシーによるセキュリティー保護」も収録しています。
book
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
本書は、はじめにInfrastructure as Codeの原則と考え方を説明し、次にダイナミックインフラストラクチャプラットフォーム、インフラストラクチャ定義ツール、サーバ構成ツール、インフラストラクチャサービスの4つにカテゴライズして解説します。その上で、プロビジョニングやサーバーテンプレート管理のパターンから、テスト、変更管理パイプライン、組織やワークフローのプラクティスまでを詳述しており、Infrastructure as Codeを網羅的に理解することができます。各ツールの使い方よりも、背景にあるコンセプトや考え方の説明に重点を置くことで、特定のツールに縛られることなく、Infrastructure as Codeを適切に実現することを目指します。
book
入門 Kubernetes
本書は、Kubernetesコンテナオーケストレータの核となるコンセプトから使い方までを解説するとともに、アプリケーションの開発やメンテナンスを改善するためにKubernetesとそのAPIがどのように役立つのかを説明します。はじめにKubernetesの概要と、Dockerなどのコンテナ技術を利用したアプリケーション開発の利点と使用方法について述べ、次にKubernetes自体をデプロイする方法を詳述します。そして、アプリケーションのライフサイクルに関係するDeploymentや、Kubernetesとストレージの統合について学び、実際に使われているアプリケーションをKubernetes上でデプロイする方法を紹介します。
book
Heroku Cloud Application Development
A comprehensive guide to help you build, deploy, and troubleshoot cloud applications seamlessly using Heroku In …
