Techいつもコードのことばかり考えている人のために。DevOps」を読み始めた。一言でまとめれば、以下のツイートで全部かな。以下、章ごとの感想1章〜4章1章から4章までは歴史や概念の説明なので、少しでも最近の開発手法を知っていたり、それなりの経験がある人であれば後から読んでもいい気もするが、2.2.2だけは印象深いトピックが書かれていてぜひ開発組織に属する人であれば読んで欲しい内容(あとで5.2.1でも再度出てくるけど)。要はミスが起きた時に、個人の責とするか、組織の問題とするか、なのだけど、それを「ヒューマンエラーはトラブルの原因だ」と考える文化と、「ヒューマンエラーをシステムのもっと深いところにある問題の兆候」と考える文化という言い方で説明するところが凄くしっくりくる。現代的な開発手法やツールの発展を考えると、20年同じ手順を秘伝のタレ的な知見に基づいて続けていく(しかもその根拠は既に失われている)という現場は少なく、個人の責を問うにはあまりに学ぶべきことは多いし、変化も激しい。人もどんどん入れ替わっていくし、伝統的な先輩から後輩への伝達とも限らない(ある日突然アウトソーシング先が入札でガラっと変わることだってあり得る)。考えると個人を責めてもしょうがなくて、組織で考えていかないとトータルでは良くなって行かないよねって考え方は実に正しいなって。devopsのアンチパターン」から読み始めると良いかなって思った。5.2は一番最初に読んだ方が良い章。この章に対して納得感が有るか無いかで、この本から得られるものが有るか無いかははっきりすると思う。コラボレーションここは完全に組織で仕事をしていく上での普遍的な話にフォーカスしている。人材配置と人事管理これ、完全に組織論、人材論になっているってことがよく分かると思う。マインドセット入門」あたりが興味深かったけど、本当にこの章はdevopsに特化した内容ではなく、どうやってより良い組織を作っていくか?という話が続くので、ひょっとしたら人によってはガッカリしたり、意外な発見が有ったりするのでは、と思う箇所。冒頭のツイートに繋がるんだけど、ひょっとして開発プロセスや、ツールの使い方の本だと思ってこの本を読まないとしたら、本当にそれはもったいないって。開発チームのマネジメントを行う人、特にこれからリーダーになるような人はまず読んだ方が良い。5章と7章だけでも良いので読んで欲しい。以降はチームでの仕事をどうやってより良くしていくか?という話や、(概念的な意味での)ツール導入、devopsをスケールさせる話とかなので、一気に読むより少しずつ自分の状況に合わせて読み進める方が良いと感じた。おわりに全般を通して「これがdevopsだ!」というより、一貫して「良い開発組織であり続けるためには?」という話が続く所が良い本。上司にdevopsの導入を進言する時には使いづらいかもね:)300ページ超は、この手の本としてはそこまで大ボリュームではないけど、それでも全部を一気に読み切ろうとすると消化不良を起こしかねないような「考えさせられる」本であることは間違いないので、あまり慌てずゆっくり(できれば周りの人とディスカッションしたりしながら)読んだ方が良さそう。Type-Sを買った月別アーカイブはてなブログをはじめよう!magnoliakさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。