##前置き
本記事はインフラエンジニアをやっている視点からThe DevOps HANDBOOKを読んだので書評となります。
今後のインフラエンジニアもこういった知識が必要となると思いインフラエンジニアの方にも本書を勧めたい（DevOpsに関わらなくてもちょっとした運用改善活動等のヒントも記載されているため）と思い書評を書いてみました。
※アプリケーション開発の経験はほぼないため、インフラエンジニア視点で記事を書いているので、そこはご了承頂ければと思います。
DevOpsHandBookを読もうと思った理由
インフラエンジニアをやりながらAnsible等のツールを利用して、基盤のオーケストレーションを実施した経験から、こういった今更ながらにDevOpsの成り立ちや、考え方を整理したかったため。
こんな人に読んでほしい
・DevOpsについてしりたい！というエンジニア
・これからアジャイル開発を行おうかなと思っているエンジニア
・現場である程度実務経験があるエンジニア
・Infrastructure As Codeを実践しているエンジニア
・現場のエンジニアから管理職、組織のTOPの考え方も入っているため、役職等関係なくDevOps文化を学びたい人
構成
DevOpsを実践してシステム開発における悪循環を断ち切り、顧客への素早いサービス価値の提供するための一つの方法論が記載されています。
#####1.DevOpsを支える原則について
本書全体の概要が記載されていて、作業の単位を小さく、作業のキューを個人が溜め込まないや組織一丸（開発から運用まで）となったシステム開発。開発結果からのフィードバックによる改善、継続的な学習・改善活動の実施。如何に顧客へのサービス価値の提供を早くするかといった内容で、ここを読むだけでも改めて考えさせられるものがある。
#####2.DevOpsを始めるために
DevOpsにおいて組織内の文化の形成（チームビルディング）。アーキテクチャのあり方（システムを疎結合に作る）について記載されている。
ここでの考え方や手法は、今後チームリーダーとなったときに役に立つなと思う。
#####3.実際にどのようにフローを改善するのか
実際にシステムを構築していく中で、素早いサービス提供を実現するために、継続的インテグレーションを実践や信頼性工場のためのテスト、マイクロサービスアーキテクチャについて触れられていて、インフラエンジニアの目線から見ても、システム構築時に役に立つことが書かれている。
#####4.フィードバック文化
特に目新しかったのがA/Bテストを業務フローに盛り込むことで
ユーザフィードバックをより早くシステムに組み込んで、より良いシステムをリリースしようという内容が記載されていて
そんな考え方はなかったと驚いた。
#####5.継続的学習文化について
組織内で学習のための土壌作りについて記載されている。
システムエラーから学ぶことや、組織内で教え合う文化について触れられており
組織の学習レベルのベースアップのためのことが書かれている。
#####6.セキュリティ・コンプライアンス
デプロイラインにセキュリティテスト、コードに対しての整合性・セキュリティ、承認プロセスといったシステムを運用していく上では欠かせない、セキュリティ・コンプライアンスを守るための手法が書かれている。
全体的に、過去にあった実例等を用いて説明されていてわかりやすい印象です。
割と細かく章立てされていて内容が章ごとにコンパクトにまとまっており、文章全体で冗長な部分がなく読みやすい文章でした。
※本書は、著者が海外の方のため日本語訳されています。
原文を読んだわけではないのではっきりとは言えませんが、訳もそこまで違和感のあるものではなく読みやすかったです。
まとめ・感想
イントロダクションとして過去から現在におけるアプリケーション開発の中で
DevOpsがどのように出てきたのかというところから始まり、過去と現在での一つの機能をリリースするスピードの違い（過去は数ヶ月～数年、現在では分単位）
そしてその違いはどこから生まれてきて、そういった素早い機能のリリースはどのようにすれば生まれてくるのか、といったメソッドが記載されている書籍です。
個人的には9章.デプロイパイプラインの構築～第11章.継続的インテグレーションの実現と実践は、インフラエンジニアとして携わっていた部分でもありました。
環境をオンデマンドですぐに構築する仕組みから始まり、機能のデプロイ、そしてテストといった機能をある程度沿った形で実装した経験していました。その時の思考や手法を本書と比較しながら読み、あそこはダメここは良かったと改めて自分の中で振り返りができました。
また、ある程度実務を経験してきた方だと、本書内の過去事例（問題プロジェクトがDevOpsを導入してどのように改善されたか）が、エンジニアからするとあるあるなネタのため、あ～似たようなことあったな・・・と
自分の過去事例と比較しながら、どのような改善が行われたか、また自分だったらどうしたかを比較しながら読めるので、頭に入りやすいと思います。
そういった意味では、本書はある程度現場で経験を積んだ人のほうが、理解しやすいかもしれないなと印象を受けました。