読書メモ。2025年13冊目。
『The DevOps ハンドブック 理論・原則・実践のすべて』を読んでの感想となります。（2025/2/11記載）
本の概要
DevOps改革を「迅速に・確実に・安全に」実践するための必読書です。
システムの開発と運用を一体化するDevOpsの理論と実践を徹底解説。
ビジネス成果に結びつく考え方・導入・実践・事例を網羅した決定版です。
事例については、Google、Facebook、Twitter、LinkedIn、Netflix、Target、Etsy、Pivotalなどの実例を当事者のコメントやポイントともに紹介しています。(本書で詳述する)「3つの道」はDevOpsの大原則であり、DevOpsを理解・実践するための大きな着眼点であるととらえればよい。第1の道はITバリューストリームのスピードアップであり、開発から運用を経て顧客接点のビジネスまでのスムーズな展開、第2の道はその逆方向でのフィードバックプロセスの有効化と迅速化、第3の道はこうした展開の安定と継続のなかで組織的に学習していくプロセスを表している。第1章の図5に示されているシンプルな矢印の重ね合わせこそが大原則なのである。
本書の構成はこの「3つの道」を中心の部として配置し、そのなかにトピックごとの章立てがなされている。まずは「3つの道」の概念をしっかりと理解、頭に入れた上で読み進めるのがよいだろう。
(監修者あとがきより)
引用：
動機
・DevOpsの実態を知らないままDevOpsって言ってる。
・DevがOpsもやることな気はするけど本当か分からないしそれだと大変な気がする。
・プロジェクトを越えたプロダクトとの付き合いをするにはDevOpsを知る必要がある気がする。
感想
日本では2017年に翻訳版が発売されたそうですが、もっと早く読むべき１冊でした。
DevがOpsをやることは主目的ではなく、職能別のチーム体制を避けることで、開発物のリリースまでの速度を速めたり、開発がもっと本番環境に向き合えるようになったり、その結果フィードバックを直接享受できるようになったり、そうした目的のためのDevOpsであると理解しました。
なんだったらDevOpsチームには開発者と運用者が一緒にいてもいい。
そして、機能を開発する人間が、システム利用者のフィードバックをそのまま受けることができるための取り組みが、DevOpsという文脈でここまで語られていることを今になって知ったのを恥ずかしく思いました。
DevOpsは開発者が運用監視もすることではなく、IaCでインフラをコード化することでもない。
それは手段であって目的は機能型チームとしてより濃度高くプロダクト開発に取り組める方法であると理解しました。
ただ、500頁もあって細部は覚えきれないので、随時必要な個所を読み直したい。
忘れたくないメモ
■組織的な対立構造が及ぼす競争優位性に対する影響
あらゆる組織が競争優位を得るために、市場投入までの早さ、サービスレベルの高さ、実験の繰り返しによる販促仮説の検証が必要とされる。IT部門のなかに根深く慢性的な対立がある組織は非常に不利になる。
■根深く慢性的な対立
ほとんどすべてのIT組織では、開発とIT運用の間に根深い対立があり、それが悪循環を引き起こして、新製品、新機能の市場投入がどんどん遅れ、品質が劣化の一途をたどり、アウデージが増えている。
IT組織は、競争地図の急速な変化への対応し顧客に対し、安定して信頼できるセキュアなサービスを提供する、という大きな責務を負っている。
別々のサイロに散らばっている組織の行動要因と効果測定が矛盾を起こし、組織全体の目標達成が阻害されることを「根深く慢性的な対立(core, chronic conflict)」と呼ぶ。
この矛盾が作り出す悪循環は非常に強力であり、IT組織の内外でビジネスの目標達成を阻害する。
■IT組織の悪循環は三幕構成
・第1幕
IT運用の目標は、アプリケーションとインフラストラクチャを動かし続け、会社が顧客に価値を届けられるようにすることである。但し、アプリケーションとインフラストラクチャには技術的負債が溜まり、日常業務における問題を引き起こす。結果、逃げ道前提の仕事や、いつもいつかやるといった守られない約束が常態化する状況を起こす。
・第2幕
ITに何ができて何ができないか、何が失敗の要因になったかの蓄積がないまま構築された機能により技術的負債が増える。
・第3幕
技術的負債により、チームは前提作業に対する待機時間が増え品質は低下し続ける。
顧客に影響を与えるアウテージの数が増え、運用部門の疲弊を生む。
結果、技術的負債を返済する運用の能力はさらに低下し、本番デリバリーのサイクルは遅くなり続ける。
あらゆる作業に対するフィードバックは遅くなり、 シグナルが劣化する。
競争地図の変化に敏速に反応できなくなり、安定した信頼できるサービス提供もできず、市場での競争に敗れる。
■悪循環の原因
悪循環がどこでも起きるのは、第1にすべてのIT組織は2つの相反する目標を持っており、第2にすべての企業はIT企業でありITの変更が1つも必要にならない経営判断はない。このような悪循環は特に開発の下流部門の人々に、無力感、疲労感、シニシズム、絶望感さえ引き起こし、燃え尽きてしまう人も多い。結果、将来同じ問題が起きるのを回避する行動を起こす気にならず、起こす能力もなくなる。現在の仕事の進め方では、このような人的な損失を生むだけではなく、 ムダなコストのために本来作れたはずの価値さえ失ってしまう。
■小さなバッチサイズと漸進的なリリース
リーンの原則は、目標の一貫性を確立し、科学的思考を取り入れ、フローとプルを生み出し、上流で品質を確保し、謙虚さを保ちながらリードし、すべての個人を尊重するというシステム思考に基づいて、顧客のために価値を生み出すにはどうすればよいかを追求すること。リーンには2つの大きな基本原則があり、1つは、品質、顧客満足度、従業員幸福度を引き上げるために、原材料を最終製品に変えるまでの製造リードタイムを短縮すること。もう1つは、リードタイムを短縮するために仕事のバッチサイズを小さくすることである。
■ITバリューストリームでの高速なフローと高品質の実現
ITバリューストリームでは、サービスが本番環境で実行されてから価値が生み出されるため、設計/開発と同時にテスト/運用を行い、高速なフローと高品質を実現することを目標とする。
■プロセス改善のポイント
バリューストリームのパフォーマンスを測定するためにリードタイムとプロセスタイムの2つの指標がある。リードタイムは顧客が要求をしたときからその要求が満たされるまでの間であり、プロセスタイムは測定の開始時が顧客の要求のための仕事を始めた時となる。プロセス改善はリードタイムに注目する。
■3つの道: DevOpsを支える原則
・第1の道
開発→運用→顧客のワークフローの高速化。フローを最大限に引き上げるために、仕事を可視化し、バッチサイズと作業のインターバルを削減し、品質を組み込み、下流のワークセンターに不良品を渡さないようにして、全体の目標のために絶えず改善を進める。
・第2の道
バリューストリームのあらゆるステージで、すばやくコンスタントな右から左へのフィードバックフローを実現する。発生と同時に問題と向き合い、効果的な対策が打てるまで一丸となって解決に当たることにより、フィードバックループを継続的に短縮、強化する。
・第3の道
ダイナミックで統制が取れた科学的なアプローチに基づく実験とリスクテイクを支持し、成功と失敗の両方から組織として学習し教訓を得ていく生産的な高信頼マネジメントの企業文化を生み出す。フィードバックループの継続的な短縮、強化により、安全な作業システムを作ると、リスクテイクと実験がしやすくなり、競合他社よりも早く学んで競争に勝ちやすくなる。
チーム内の発見を全社的な改善につなげるために、新しい知識の効果を大きく膨らませる作業システムも生み出す。どこで働いていても、社員は組織全体の集合的な経験の蓄積に支えられて働けるようになる。
■フローの原則
顧客にすばやく価値を送り届けるために、開発から運用への作業の流れを速くスムーズにする。作業が順調に流れているのはどこか、作業が停滞したり止まったりしているのはどこかを少しでも把握するために、できる限り作業の状況を可視化する。
マルチタスクは、作業効率が大きく下がる。WIPを制限すると、作業の完成を妨げている問題も見えやすくなる。WIPを制限し誰かほかの人の仕事を待つ場合、遅れの原因を見つけ出して、その問題の解決を手伝うことが他タスクを進めるよりはるかによい。
リードタイムを短縮し、品質を向上させるためには、パッチサイズの縮小のために絶えず努力しなければならない。バッチサイズの理論的な下限はシングルピースフローであり、個々の作業は1度に1単位ずつ行われる。
ソフトウェア開発のバリューストリームのムダと苦痛とは、結果に影響を及ぼさずに省略できる工程など、顧客への価値の提供が遅れる原因になるあらゆるものである。
システムの制約条件を明らかにし、その能力を最大限に引き出す方法を決める。ほかのすべてのことをその決定に従属させ、システムの制約条件を最大限に尊重する。今までのステップで制約条件が制約条件でなくなったら、新たな制約条件を明らかにする。
新しい仕事の開始を禁止することにより、ITバリューストリームのシングルピースフローである継続的インテグレーション及び継続的デプロイが成立する。継続的ビルドとインテグレーションテストに合格した変更は、すべて本番環境にデプロイされる。そして、変更がテストのどれかで不合格になったときには、アンドンの紐が引かれ、組織が一丸となって解決に当たる。
■作業受け渡しによるコンテキスト喪失
どんなによい状況でも、作業を受け渡しすると必然的に失われる情報がある。受け渡しの数が一定数を越えると、解決しようとしている問題や、近づこうと努力している組織的な目標のコンテキストが失われる。
■デベロッパーが成功や失敗から学ぶフィードバック
仕事が行われている現場から意思決定を引き離せば引き離すほど、承認プロセスの効果は下がっていく。
それは、意思決定の質を下げるだけではなく、サイクルタイムを引き延ばし、原因と結果の間のフィードバックの力を弱め、成功や失敗から学ぶ能力を衰えさせる。
デベロッパーに自分が構築しているシステムの品質の責任を共有させると、作られるものが改善されるだけではなく、学習が加速される。これは、顧客からもっとも遠くに引き離されているデベロッパーにとって特に重要なこと。
ITバリューストリームで下流のワークセンターのために最適な出力を提供するということは、運用のために最適な設計をするということ。
運用の非機能要件に、ユーザー機能と同程度の高い優先順位を与える。こうすることにより、上流で高い品質を確保し、構築するすべてのサービスに一連の体系化された非機能要件を積極的に組み込めるようになる。
■継続的でダイナミックな学習システム
パフォーマンスの高い生産現場は、学習を必要とし、学習を積極的に奨励している。
作業を厳密に定義したりせず、作業システムはダイナミックで、ラインの作業者は新しい改善のために日常業務の一部として実験を行う。
私たちが日常業務でリスクを引き受けなければならない「生涯学習者」だということを強調して、高信頼マネジメントの文化を作り上げることだ。
継続的でダイナミックな学習システムを作り上げれば、チームは変化する環境にすばやく自動的に適応する能力を身につけ、究極的に市場で勝ち残るために役立つ力になる。
それを実現するためにも、安全な作業システムを作るための基盤が重要となる。
■継続的な学習と実験の文化の効用
継続的な学習と実験の文化を育てるためのフローとフィードバック向上のためには、状態目標の枠組みを作り、そこに到達するために役立つ仮説を文章化し、実験を考えて実施し、結果を評価するという反復的で科学的なアプローチが必要とされる。
結果、パフォーマンスの向上だけではなく、回復力の強化、仕事に対する満足感の増大、組織の適応力の向上といった効果も得られる。
■市場の変化に合わせるための変革
現在のプロセスを維持し、守るために使われるテクニックは、現体制を守るためにはよいのだが、企業には市場の変化に合わせて仕事のあり方を変えなければならなくなることがよくある。
変化への対応には、破壊とイノベーションが必要になるが、それは現在の日常業務を進め、社内の官僚主義を守る人々との間で当然矛盾を生じる。そして、ほとんどかならず守旧派の勝利となる。
■機能別組織
サービスチームに各種のスキルを持ったエンジニア(たとえば、運用、QA、情報セキュリティ)を配置したり、自動化されたセルフサービスプラットフォームを通じてチームに運用、QA等の職能を提供したりする。こうすれば、個々のサービスチームは、IT運用、QA、情報セキュリティなどのほかのグループの作業に頼らず、独力で顧客に価値を送り届けられるようになる。
■デプロイとリリースの分離
デプロイとリリースを混同すると、結果を成功に導くための貴任があいまいになる。２つを切り離すと、開発と運用には早くて頻繁なデプロイを成功させる責任を負わせ、製品オーナーには、ビジネスとしての機能の構築、リリースがIT部門で時間を使っただけの意味があることに対しての責任を負わせることができる。
■UX観察
顧客の苦労を直接デベロッパーたちが見れば、もっとしっかりとした情報を得た状態で日常業務の判断を下せるようになる。UX観察は、源流の部分で品質を高めることにつながる。また、上流のメンバーがバリューストリームに属するほかのチームメンバーの思いをそれまでよりもずっと強く考えるようにもなる。非機能要件を体系化し、共通の作業課題とするときに、UX観察を活用することで、UX観察の結果を構築するすべてのサービスに積極的に反映させられるようになる。
■私たちの取り組みの効果測定
構築した機能の2/3は、会社にとってまったく意味がないか逆効果になる。しかも、それらの機能はコードベースを複雑化し、時間とともにメンテナンスコストを引き上げていき、ソフトウェアを変更しにくくしていく。そして、これらの機能は、価値を生むはずの機能を犠牲にして作られることが多い。（機会費用）
機能の設計、実装、テスト、デプロイにA/Bテストを組み込むことが対策となる。意味のあるユーザーリサーチと実験を実行することで、私たちの取り組みが顧客と会社の目標達成のために役立ち、市場で勝利をつかむために効果があるものだということを確かめられる。
■組織の自己治癒能力
複雑なシステムのなかで安全に仕事を進めるためには、自己診断と自己改善の能力を引き上げなければならない。すると、自分たちの誤りを理解し、再発の防止に役立つ行動に置き換えられるダイナミックな学習システムが形成される。自己回復力を持つ組織には自己治癒能力がある。危機対応は特別な仕事ではなく、いつも行っていることであり、信頼性の源泉はこのような反応のよさにある。
■組織的な学習
誤りを犯したときに、その詳細を話しても安全だと感じるようなら、エンジニアたちは進んで説明責任を果たすだけでなく、社内のほかの人々が将来同じ過ちを繰り返さないようにするための取り組みに熱心に力を傾ける。これが組織的な学習を生み出す。
一方、そのエンジニアを罰するなら、障害のメカニズム、病理、仕組みを理解するために必要な詳細信報を誰も提供しようとしなくなるだろう。そうすると、同じ過ちは間違いになく繰り返されることになる。
■リスクテイクの文化
組織の構造は一般に2つのモデルのなかのどちらかであると論じている。1つは標準モデルで、タイムラインと予算の遵守をはじめとして、ルーチンとシステムがすべてを支配している。もう1つは実験モデルで、すべての訓練、演習とすべての情報が研究所と似た文化のなかで毎日評価、議論される。
ITの仕事は、完全に標準化されたものとしてプロセスの遵守を至上命題にしてアプローチしてはならない。システムの理解を深め、うまくコントロールするために、倦まず弛まずより弱い失敗の兆候を見つけることを心がけなければならない。
学習と計算されたリスクテイクの文化を強固なものにするためには、誰もが失敗を表面化し、失敗から学ぶことを恐れず、むしろそのことに責任感を持つ方向にリーダーが絶えず誘導していかなければならない。
