Amazonアフィリンク
DevOps的な考え方・業務の回し方を、DevOpsがもてはやされる前から実践してきた人たちが、今一度立ち戻りDevOpsとは何なのかを、これから実践する人向けに解説した本。具体的な会社での導入事例を豊富に取り入れて解説に付け加えているのが特徴になっている。
手放しに喜べるような万能の手法ではない、と前置きをしながらも、どうしてもこのアメリカ的な文章のせいで、手放しに喜ぶようなノリの文章になってしまっているのが少し気がかりだった。そもそもこの本の解説から理解するなら、DevOpsって手法のことじゃなくて、単に業務の回し方に対する考え方でしかないように思えてしまう。そう、技術の話じゃなくて、業務プロセスの話。
変更を反映させるまでのデプロイのチェーンに問題があった場合はその解決にみなで協力して当たる、というのが正しい方法だという記載がある。ただ実際には、現場は作業の細分化が進んでいて各々は自分の担当の業務に手いっぱい、直接は担当じゃないとこの問題にまで手を伸ばせる余裕のある人は少なく、結局いつも臨機応変に手を伸ばせる器用で全体もよく見えている人ばかりが対処する。そういう役回りの人が消耗していき、特に上から評価もされない場合は成果とみなされず給与にも反映されず、そして去っていく、というような姿になってしまうというのが欧米では多くなるんじゃないかと思う。
本を読んでいて気に止まった点をいくつか
11.3 まとめより、「燃え尽き症候群になる率は低いのだ。」アメリカでも燃え尽き症候群みたいな話はあるのね。まぁあっちだと離職して少し休みその後転職というのはよくある話なのに対し、日本だと一度ドロップしてしまうとなかなか戻れないという違いはありそう。
17.2 機能テストにはA/Bテストを組み込むより、「価値を産まない機能を機能を1つ作るよりも、チーム全体に休暇を与えたほうが会社や顧客のためになる」、お、おう。そこまで割り切れる会社は日本にはほとんどないだろうなぁ。
19.6 回復力と学習を生み出すために本番環境にエラーを注入するより、Netflixが意図的に本番環境に擬似的な障害を起こして訓練にする話は今は結構有名になったのかな。Chaos Monkeyでググるとたしかに結構ヒットする。本番環境に手を加えるなんて、日本の大企業じゃ絶対にやらないよねぇ。
20.1 チャットルームとチャットボットで組織的な知識を自動的にキャッチするより。チャットルームにオペレーション状況をリアルタイムに全員に流す話と特定の人にだけ情報を届ける電子メールとの対比がある。チーム規模にもよるけど、情報をあえて一部の人にのみ開示してコントロールするのがマネジメントだと信じる人も少なくないので、やっぱこういう話は大企業ほど抵抗があるだろうなぁ。
個人的な意見かもしれないけど、やっぱDevOpsって技術の話じゃないと思う。コードを変更してからそれを反映した本番環境を作るとこまでを自動化・効率化・高速化する、なんて話は当たり前にしか感じない。組み込みの世界だと、ビルド用PCのセットアップ・各種ツールのインストール・ソースコードのチェックアウト・ワンストップなビルドシステム・ターゲットイメージの生成・ターゲット実機への確実なイメージの書き込み・標準化された自動テスト、あたりはソフトウェ開発者ならワンストップでとまでは言わないまでも手順化・自動化しているのは当たり前だと思う。
と、DevOpsそのものに否定的な意見の内容になってしまったけど、DevOpsを知るという意味では丁寧にかつ全体を追って書かれた本なので安心して読める。
