ブログ記事
ITと事業の断絶を物語で描く：Gene Kim ら『The DevOps 逆転だ！』
ITプロジェクトが炎上するとき、技術的な問題よりも組織的・構造的な問題が根本原因であることは多い。Gene Kim、Kevin Behr、George Spafford の共著『The DevOps 逆転だ！究極の勝利へ導く3つの道』は、この問題をビジネス小説という形式で描いた一冊だ。
1. 小説という形式が明らかにする問題
本書の舞台は架空のメーカーの情報システム部門だ。基幹システムのリリースが遅れ、セキュリティ違反が発覚し、プロジェクトが次々と炎上する組織に、主人公は突然VP of ITとして就任する。
小説の形式を選んだことで、「IT部門 vs 事業部門」「開発 vs 運用」という組織の断絶が、会話やシーンとして具体的に描かれる。技術書の記述として読むより、読者が「これはうちの会社だ」と感じやすい構造になっている。
主人公が直面する問題——デプロイのたびに障害が発生する、変更の影響が読めない、誰も全体像を把握していない——は、多くのIT組織が抱える現実と重なる。
2. 三つの道：DevOpsの思想的基盤
本書の後半で提示される「三つの道」は、DevOpsの実践を支える思想的な枠組みだ。
第一の道（フロー）: 開発から運用、ユーザーへの価値の流れを最大化する。ボトルネックを特定し、バッチサイズを小さくし、作業の流れを可視化する。
第二の道（フィードバック）: 下流から上流へのフィードバックを速くする。テスト自動化、モニタリング、本番からの学習によって、問題を早期に検出し修正する。
第三の道（継続的学習）: 個人と組織の継続的な実験と学習の文化を育てる。失敗を罰するのではなく、システム改善のための情報として活用する。
flowchart LR
DEV["開発\n（Dev）"] -->|"第一の道：フロー\n価値を速く届ける"| OPS["運用\n（Ops）"]
OPS -->|"第二の道：フィードバック\n問題を早期に検出"| DEV
LOOP["第三の道：継続的学習\n実験 → 失敗 → 学習 → 改善"] --> DEV
LOOP --> OPS
style DEV fill:#e8f4fd,stroke:#4a9eda
style OPS fill:#e8f8e8,stroke:#4caf50
style LOOP fill:#fff8e1,stroke:#f5a623
3. 作業の流れを可視化する
本書で頻出するのが製造業の「制約理論（Theory of Constraints）」の引用だ。
工場の生産ラインにボトルネックが一つあれば、そこ以外の作業速度を上げても全体のスループットは改善しない——この原則をIT開発に適用すると、優先すべきは最も詰まっている箇所の解消だということになる。
可視化されていない作業（隠れた仕事）は管理できない。本書では作業をカンバンボードに並べ、「計画外作業」がどれだけ発生しているかを数値化することが、改善の出発点として描かれる。
4. 技術的負債はビジネスリスク
本書が示す視点として印象的なのは、技術的負債をエンジニアリングの問題ではなくビジネスリスクとして経営層に提示するくだりだ。
「システムが壊れているのに動かせる」状態は一時的な問題ではなく、事業継続性への脅威だ。技術的負債の解消をコスト計上として説明するフレームは、IT投資の意思決定者に対してエンジニアが持てる有力な論拠になる。
技術的な解決策の前に、組織とコミュニケーションの問題を解く必要がある——その順序感が本書の価値だ。
5. この本が解決できる具体的な状況
「IT部門として頑張っているのに、事業部門から評価されない」「デプロイのたびに不具合が出るが、何から直せばいいかわからない」「チームが忙しすぎて改善の時間が取れない」——これらは技術の問題ではなく構造の問題だ。
本書の価値は、この「構造の問題」を技術書の記述ではなくストーリーで体験させる点にある。主人公が直面する状況が実感を伴って描かれるため、自分の組織の問題が言語化されやすくなる。
6. 向いている人・向いていない人
向いている人：
- チーム・組織の問題に悩むエンジニア・マネージャー
- 開発と運用の断絶を感じており、DevOps の思想から理解したい人
- 技術的負債や改善提案を経営層に説明する必要があるエンジニア
向いていない人：
- CI/CD パイプラインの具体的な構築方法（GitHub Actions・ArgoCD 等）をすぐに学びたい人（本書は思想書であり実装書ではない）
- 小説形式が読みにくい人（ページ数が多く、技術的な仕様書は少ない）
7. 読み終えた後のステップ
本書で DevOps の思想（三つの道）を得たら、次のステップとして「DevOps ハンドブック」に進むと、具体的な実践方法と測定指標に繋がる。本書が「なぜ変える必要があるか」を語るなら、DevOps ハンドブックは「どう変えるか」を語る。
物語としてもう一歩踏み込みたいなら、同じ Gene Kim による姉妹編『The DevOps 勝利をつかめ！（The Unicorn Project）』に進む道もある（読み分けは次節で詳しく扱う）。運用視点で描かれた本書に対し、続編は同じ事件を開発者の視点から描き直しており、物語を楽しみながらもう一つの切り口を掘り下げられる。
8. 姉妹編『The Unicorn Project』との読み分け
本書が運用・IT 部門の視点から組織の混乱を描くのに対し、同じ Gene Kim による続編『The DevOps 勝利をつかめ！（Unicornプロジェクト）』は、同じ事件を開発者マキシーンの視点から描き直す。片方は「なぜ組織が詰まるのか」を運用側から、もう片方は「現場のエンジニアが壁とどう戦うか」を開発側から見せる関係だ。
まず読むなら本書でよい。物語で DevOps の問題意識を掴んだうえで、開発生産性や技術的卓越性というもう一つの切り口を味わいたくなったら、姉妹編へ進むと同じ世界を立体的に捉えられる。続編は必須の前提ではないので、実践へ急ぐなら本書のあと実装書（DevOps ハンドブック）へ直接向かってもかまわない。
筆者の体験から
テックリードとして、リリースのたびに本番で不具合が出てはお詫び対応に追われていた時期に本書を開いた。開発は早く出したい、運用は壊されたくない、間に立つ身としてはどちらの言い分もわかるだけにしんどかった。制約理論をそのままカンバンボードに持ち込み、計画外作業がどれだけ発生しているか可視化してみると、想像以上にリリース対応や緊急対応に時間が取られていることが数字で見えてきた。
ある時、リリース作業がいつも同じ場面で詰まる原因を辿ると、担当者が「最終確認は自分がやらないと不安だ」と一人で抱え込んでいたことがわかった。悪気はなく責任感の裏返しだったが、手順を分解してレビュー基準を明文化し、他のメンバーでも代替できるようにした。頻度は上がったが、当人には仕事を取られたように映った面もあり、可視化とスピードだけでなく気持ちのケアも要るのだと痛感した。小説形式は移動時間に読むには向いていたが、後半は展開が読めてしまい、何度か飛ばし読みしたのも正直なところだ。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有