Effective DevOps(Jennifer Davis, Ryn Daniels)

書籍情報

• 著者:Jennifer Davis(著), Ryn Daniels(著), 吉羽龍太郎(訳), 長尾高弘(訳)
• 発行日:2018-03-23
• ISBN:9784873118352
• URL:https://www.oreilly.co.jp/books/9784873118352/

書籍目次

• 本書への推薦の言葉
• ジョン・アレスポウによる序文
• ニコール・フォースグレンによる序文
• 監訳者まえがき
• はじめに
• 第I部 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 まとめ
• 第II部 コラボレーション
  • 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 組織再編や人員整理を行ったばかりだ
• 第III部 アフィニティ
  • 9章 アフィニティ:個人からチームへ
    • 9.1 Sparkle Corpの開発デモの日
    • 9.2 人のネットワーク
    • 9.3 チームはどのように作られるか
      • 9.3.1 チームが行う仕事
      • 9.3.2 アフィニティの定義
      • 9.3.3 チーム内の個人間の結び付き
      • 9.3.4 チームの文化
      • 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の些細な過ちを強く非難する人がいる
• 第IV部 ツール
  • 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の採用（または廃止）を決めたが、社員がそれに抵抗している
• 第V部 スケーリング
  • 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 大企業のツールと技術
      • 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のために独立したチームが必要かどうかわからない
• 第VI部 devops文化への架け橋
  • 16章 devopsの4本柱を使って架け橋をつくる
    • 16.1 ストーリーの重要性
      • 16.1.1 明示的なストーリーと暗黙のストーリー
    • 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 テイラー主義と個人のストーリーの価値
      • 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
• 索引