1.この記事で達成したいこと

2.前提

本題に入る前に、前提として僕のDevOps周りの背景知識について触れようと思う。

2-1.僕のDevOps周りの背景知識

  • これまで以下の経験をしており、多少なりともDevOpsとはなんぞやという点は抑えているつもりだった。。
    • toBのWebサービスの運用と開発
    • Gitlab RunnerとArgo CDを使ったGitOpsなパイプラインの設計と構築
    • Django制の社内システムの開発
  • 以下のpodcastを聞いたことがあり、Circle CIはまさにDevOpsを体現していると思っている
  • ※ 本書を読み進めるまでは、DevOpsとは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けることだと思っていた
    • しかし、本書を読み進めていくうちに、DevOpsを推し進めるには、それだけで足りないと考えを改めることになる

3.目次

第1部 3つの道
第1章 アジャイル、継続的デリバリー、そして3つの道
第2章 第1の道:フローの原則　ほか

第2部 スタートのための糸口
第5章 最初に手を付けるバリューストリームの選択方法
第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる　ほか

第3部 第1の道:フロー改善の技術的実践
第9章 デプロイパイプラインの基礎の構築
第10章 高速で信頼性の高い自動テストの実現　ほか

第4部 第2の道:フィードバックの技術的実践
第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す
第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす　ほか

第5部 第3の道:継続的な学習と実験の技術的実践
第19章 日常業務での学習の実現と日常業務への学習の注入
第20章 一部門の発見を全社的な進歩につなげる　ほか

第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践
第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける
第23章 デプロイパイプラインを防御する

4.感想や学び

  • DevOpsとは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けるという方法論だけを説いているのではない。
    • ソフトウェアの変更を早く、安く、正確にプロダクション環境に反映させるという目標がまずあり、その目標を達成するためにIaCを始めとする方法論などの話題が出てくる。
    • 本書で言うリードタイムとプロセスタイムの違いに意識するという点もその一例。
  • DevOpsはUnix哲学の考え が随所に表れているという印象を持った。
    • 例えば、DevOpsを推し進める上で重要なこととして、リリースやデプロイのサイクルを早くするためにバッチサイズを小さくしたり、受け渡しの数を少なくすること（フローの原則）を挙げている。
    • このようなリリース対象を小さくすること、あるいはパイプラインの簡素化はまさにUnix哲学でいう"Small is beautiful"や"Make each program do one thing well"だと感じた。
  • DevOpsを推し進める上で重要なことはフローの原則以外に以下の2つを挙げている。
    • フィードバックの原則。
    • 継続的な学習と実験の原則。
  • フィードバックの原則と継続的な学習どちらも大事なことだと思うが、ここではフィードバックの原則に関連して今月弊社に転職して驚いたことがあったので書き残しておきたい。
    • それは 「フィードバックをし、またそれを受け入れている光景」 をいたるところで見かけるということ。
      • 例えば、情シスなどいろんな部署が主催するオンボーディング研修に参加すると、都度zoomで質問やコメントをしあっている。
      • また、kintoneのアプリ（チャット）上でも、そういったやりとりがテキストベースでされている。
  • なお、これは余談だが、情報量が多い様子を「情報の海」と言うこともあり笑。

5.本書で何度も読み返したいところ

  • 『6.3 専任の変革チームを編成する』

    • DevOpsという従来とは異なるやり方を導入する際、進めずらさに行き当たることがあるという。

    • 本書ではこの進めづらさから解放されるためにDevOpsを推し進める専任のチームを設け、既存のやり方との衝突を避けるために物理的空間を与えることことも推奨している。

    • 「あれ？これデンソー社も似たようなことやっていなかっけ？」と思い出し、ググって見つけた記事を貼っておく。

    • また、事務所を愛知県刈谷市の本社ではなく新横浜に設けたことも大きく寄与しているという。

      小泉氏は“出島”と表現していたが、適度に本社から離れた環境のため、他部署の眼を気にせず働ける。スクラム開発に必要な人材を惜しみなく投入し、環境についても同様に十分な投資を行う。 デンソーが、ソフトウェア開発に対してどれだけ本気であるかが伺える。

    • 参考：生き残りを賭けた「デンソー流アジャイル」成功の秘訣―“人間力”を核とした組織力 | TECH+

  • 『7.9 疎結合なアーキテクチャによりデベロッパーの生産性と安全を向上させる』

    • アーキテクチャを疎結合とすることにより、システムに変更が入ったときの影響範囲は限定的というメリットを紹介している
      • e.g. 変更のリードタイムの短縮
    • また疎結合なアーキテクチャな具体例として、サービス指向アーキテクチャ（Service-Oriented-Architecture, SOA）を挙げている。
    • これについてはO’Reilly Japan - 進化的アーキテクチャに詳しく解説がされていた印象があるので、以前書いた読書メモを貼っておく。

6.本書を読んで深堀したいと感じたこと

  • サービスのフェーズやチームメンバーの構成によって妥協するべきことはあるか？
  • DevOps戦略はフェーズやメンバーの変遷によってどのように変わるのか？

※8章以降が読み切れていない。。骨太だけど読んでおいて損はない一冊だと思う。

P.S. Twitterもやってるのでフォローしていただけると泣いて喜びます:)

@gkzvoice