Magnolia Tech

いつもコードのことばかり考えている人のために。

『システム運用アンチパターン ――エンジニアがDevOpsで解決する組織・自動化・コミュニケーション』は、誰が読み、実践すべきことが書かれているのか、その「誰」を考えながら読んでほしい1冊だった

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション

Amazon

いやー刺さりまくる名言のオンパレードみたいな1冊『システム運用アンチパターン 』。

この本で最初に出てくる具体的な事例が「パターナリスト症候群」という内容なんですけど、これまでの技術書にありがちな「作業品質向上や、効率化のため」というより、組織のアジリティを下げてしまう「重い承認プロセス」を排除するために自動化しましょう、と言っているところが良い。

なので、そもそも「承認プロセス」というのは何を軽減しようとして定義されているものか、という言語化がされていて、その要素の代替としての自動化をしましょう、という流れが素晴らしい。

第2章の内容を、組織として納得させられたら、価格分の元はとったも同然です。

ただ、興味深かったのは、それだけ「重い承認プロセス」は良くないと言っている反面、”こういったシステムは監査役がとても気に入ります”という記述が有って、監査という仕組みは必要である、という前提で書かれている点ですね。監査に耐えられるようにするためには記録のための重いプロセスが必要になってくるけど、本書では「Jiraみたいなツールでプロセスのログを取ろう！」とさらっと流されていたので、そこは受け入れるしかないっていう文化なんだなと理解しました。

引き続き、7章「空の道具箱」では、自動化には文化が必要であること、11章「命じられた文化」ではどうやって組織文化を作っていくかが語らられる。この11章を読んでどう現状を理解するか、どういう行動をするか、という所に本書の価値が有るんじゃないかっていうくらい大事なことが詰まった章。

本書のサブタイトルには「エンジニアがDevOpsで解決する組織・自動化・コミュニケーション」と書かれているが、経営層やマネジメント層の理解や、支援無しには絶対に上手くいかないことばかりであって、結局この本を「エンジニアだけが」読んで理解して共感しても意味が無くて、「組織をどうしたいの？組織からどんな価値を出していきたいの？」を考えるべき立場の人が読んで実際に行動しないと意味ないなーって。

あと、冒頭の2章の話に戻ると、重い承認プロセスを作りたい人と思って作っている人は居ないと思うけど、結局「説明責任」を誰が誰に果たすべきか？というところに尽きると思うですよね。

そして、方法論を受験勉強みたいに形式的に理解して、教科書通りに対応しようとしすぎると、こんな悲劇が起きるんだよなぁって。

www.itmedia.co.jp

具体的な方法論については、これまでいろいろなところで語られきた話の集大成といった趣なので、必ずしも本書で初めて知ることばかりではないし、別にその通りにやることが必ずしも正しい訳じゃないけど、どうやって発想や、文化を変えていくか？その考えるきっかけであり、会話をするための語彙を獲得するために読むのが良いと思いました。

「誰が、読むか」「誰と、読むか」ですね。