元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2018/04/30

「Effective DevOps - 4本柱による持続可能な組織文化の育て方」を読んだ


監訳者の@さんからご連絡いただき、出版社の方からご献本いただきました。いつもありがとうございます!

気になっていた書籍だったので、大変ありがたく拝読させていただきました。


Effective DevOps


DevOps」という単語を耳にしたのは、6〜7年前のことだったと記憶しています。

このブログで「DevOps」を検索してみたところ、「DevOps Days Tokyo 2012」でChefの話をしてきたので資料を公開しますのエントリでした。懐かしい。


で、本題に戻すと、当時からというか、今でもそうですが、「DevOpsって何?」と聞かれると、なんとなく説明できる文脈やキーワードは出てくるのですが、やっぱり自分で納得した言葉で話せてるか、と聞かれると正直自信が無い。


本書をめくり始めると冒頭に、「devopsはものの考え方であり、仕事の進め方である。ストーリーを共有し、共感を育み、効果的かつ永続的に力を出せるようにする。そのためのフレームワークだ。」とある。

「DevOps」は一言で表現するのも難しいが、個人的には「カルチャー(文化)」であると理解しているし、本書の副題にも「4本柱による持続可能な組織文化の育て方」とある。


私の今の立場は、事業会社の自社サービスにおける、サービス開発/運用組織のエンジニアリングマネージャーであるが、本書を読み進めていくと「DevOps」という単語は一旦置いておいて、前述したようなサービス開発&運用しながら改善を繰り返していく組織に携わる方々に、必ず読んでほしい内容の仕上がりとなっている。


本書は、そうした組織マネージメントの教科書的な位置づけであると思ってよい。所謂、DevOpsで成功した世界的な企業での具体的な実践例に基づいて、300ページ超のボリュームで書かれている。DevOpsを支える4本柱として、「コラボレーション」「アフィニティ」「ツール」「スケーリング」としているが、技術者がついついスポットを当てて話題に上げる「ツール」に関しても、基本的にはコードや製品名、機能面に依存した話題は無く、ツールが文化や組織にどのような影響を与えるか書かれている。ツールの選択は共通言語の選択である、との文になるほどなと思いました。


その他、書籍の内容については、出版社より目次が公開されており、下部にも引用させていただきますが、目次が詳細なためパラパラと眺めるとトピックは見えてくるかと思います。ソフトウェアやWebサービスの開発組織のマネージャーは一読の価値が必ずあるかと思いますので、テクノロジー文化な強いチーム・組織作りに興味のある方に、オススメな一冊です。


それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



おまけ:目次

本書への推薦の言葉
ジョン・アレスポウによる序文
ニコール・フォースグレンによる序文
監訳者まえがき
はじめに

第?部 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 チームの文化
        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の採用(または廃止)を決めたが、社員がそれに抵抗している

第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のために独立したチームが必要かどうかわからない

第?部 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

索引

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20180430/p1

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)