Effective DevOps
動機
割と古き良き文化の職場で働いているので、 何をどー変えたらいいかうまくいくのか、みたいなヒントを探すために。
概要
「本書では、主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します。」
きっちり本の紹介に書いてあるのだが、実はこれに気づいたのは半ば読み終わったあたりのこと。
概要とか目次は大事です。
感想
アジャイルとかなんだの調べていくと、共通する言葉が並べられていくことに気づく。
その多くは文化とか精神性についてのことだ。
本書はそこにフォーカスしている。
関連する用語として、CI/CDだの自動化だのといった言葉は紹介されるが、
それにしても、それらを導入したりするときの基準とか考え方など、個々の技術によった話は一切ない。
つまるところ、本書はDevOps(書内ではdevopsとしているが、表紙ではこちらなのでそのまま使用する)における、最上位の概念についてこんこんと説くものだ。
なので、他のそういった類の書籍をすでに読破している人にとっては、目新しいことは大分少ないのではないかと思う。
自分が読んだ中で内容が似た書籍としては「エクストリームプログラミング」が挙がる。
ただ、開発プロセス本は基本的にチームの中でアジャイルすることが主眼になるが、
本書はチームを超えて組織全体を見た話が多い。
DevOpsの文脈が元々Develop(開発)とOperations(運用)という、目的の対立しがちなチームの協調に関する話なので、主題からしてそれは当然である。
そして、本書が数あるアジャイル開発プロセス系の本と異なるのは、そこだと思われる。
スクラムでもスクラムオブスクラムという複数チームが協調して運用するための枠組みはあるが、
基本的に開発プロセスと銘打つと1つのチームの話になりがちである。
それが不足しているとか間違っているということではなく、単に切り口とスコープが異なるというだけである。
この本を読んでから個々の開発プロセスやツールを学んでもいいし、スクラムなどを学んでからこちらを読んでもいいと思う。
教訓みたいなことも多いので、1度読んでそれっきりというよりは必要になったら該当する箇所を読み返すという使い方になりそうである。
代わりに、本書を読んで劇的に何か変わるとか実践できるとかそういうものでもないことは承知しておく必要がある。
文化や精神性といったものは、個人にしても急に変わるものでもないし、多人数が関わって醸成されるものだからだ。
現場の一エンジニアが実践を始めてどうにかなるのか？と思ってしまうところもあるし、実際関われない部分も多い。
(例えば、多様性を高めるために採用に口を出す、とかは難しい人も多いだろう)
とはいえ、文化とは複数人が関わる以上、相互に影響するものだ。
最近読んだブログでは、「1人アジャイル」から始めた話が記載されていてとても励みになった。(はてなの企画なのかな？)
なにごとも少しずつ、フィードバックを繰り返して進んでいくこと。
批判的に効果を測定し、非難を持ち込まないこと。
失敗から学び、学習すること。
みずからの行動をふりかえって、少しずつ反映していきたいと思う。
