「今日もまたシステム障害の対応で1日が終わった」「開発と運用の連携が取れず、リリースが常に遅延する」。
こうしたIT現場特有の「火消し状態」や「部署間の壁」に直面しているなら、書籍「The DevOps逆転だ！究極の継続的デリバリー」は現状を打破する明確な指針となります。
本書は単なるDevOpsの技術書ではなく、架空の製造・小売企業「パーツ・アンリミテッド社」を舞台にした小説です。
主人公ビルが直面する生々しいトラブルの数々は、多くのIT従事者にとって自身の職場を鏡で見ているかのようなリアリティがあります。
物語のあらすじを紹介するとともに、「制約理論」や「3つの道」といった作中の核心的な概念を紐解き、あなたの組織のボトルネックを特定して解消するための具体的なステップを解説します。
IT現場のリアルを描く「フェニックスプロジェクト」のあらすじ
「The DevOps逆転だ！究極の継続的デリバリー」という書籍名で販売されていますが、原題は「The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win」です。
ビジネスを勝利に導くための物語というタイトルの通り、著者であるジーン・キム自身の開発現場での実務経験・研究をもとに、現場を改善するためのお話として書いています。本書からDevOpsという単語に火が付きました。
破綻寸前のプロジェクトと終わらない「火消し」
主人公のビルは、年商40億ドルの企業のIT運用担当VP（副社長）に突如として抜擢されます。
彼に課せられたミッションは、企業の存亡をかけた巨大プロジェクト「フェニックス」を成功に導くことでした。
しかし、現実は過酷です。電話は鳴り止まず、各部門から「システムが止まった」「メールが使えない」というクレームが押し寄せます。
ビルと彼のチームは、日常の運用保守という「火消し」に追われ、フェニックスプロジェクトの要件はスケジュールから大きく遅延しています。
システム障害が発生し、原因究明と復旧に追われ、やっと解決したと思ったら数日後にまた別の重大インシデントが発生する。
この「終わらない火消し」は、企業の規模や業界を問わず、多くのIT部門が直面する現実です。
開発・運用・セキュリティ部門の対立構造
もう一つの大きな壁が、部門間の対立です。
マーケティング部門のサラは自部門の利益を優先してIT部門に無理難題を押し付け、開発部門は「コードを書いたから後はよろしく」と運用部門にソフトウェアを丸投げします。
さらに、情報セキュリティ担当のジョンは、リリースの直前になって「セキュリティ要件を満たしていない」とプロジェクトにストップをかけます。
誰もが自分の職務を全うしているつもりでも、組織全体としては完全に機能不全に陥っています。
この状況は、各部門が局所最適を求めた結果、全体最適が損なわれる典型的なサイロ化の弊害です。
ビルは、「謎の男」エリックの助言を得ながら、リーン生産方式やアジャイル、DevOpsの概念を取り入れ、このカオスを生き抜くための改革を推し進めていきます。
現場のボトルネックを特定する3つの判断基準
判断基準1｜「属人化（バス係数）」の進行
現場の危機的状況を把握するための最初の基準は、「バス係数（Bus Factor）」です。
これは、「特定のプロジェクトにおいて、何人のメンバーがバスに轢かれたら（突然離脱したら）プロジェクトが立ち行かなくなるか」を示す指標です。
作中では、優秀なエンジニアであるブレントがこの状態に陥っています。
あらゆる複雑な問題解決がブレント1人に依存しているため、彼が他の作業にかかりきりになると、IT部門全体の業務が停止します。
自組織の特定のエンジニアの稼働率が常に90%を超えており、かつ彼らがいなければ解決できないインシデントが週に1回以上発生している場合、組織は極めて脆弱な状態にあります。
この状態での新規プロジェクトの追加は、100%の確率でスケジュールの遅延を引き起こします。
判断基準2｜形骸化・過剰な承認待ち
本書ではITシステムにおけるダウンタイムの最大80%は、構成の変更に起因して発生しすると言われています。
1つのチームがシステムAを変更し、同時に別のチームがシステムBを変更した結果、予期せぬ障害が発生するのは運用現場の日常茶飯事です。
ここで多くの企業が陥る失敗例が、「承認プロセスの複雑化」です。
障害を防ぐために4ページにわたる変更申請書を導入し、数週間先までの変更スケジュールを固定するアプローチは、ビジネスの機動力を致命的に低下させます。
月に1回のリリースしかできない体制で、毎日新しいコードを書いても意味がありません。
標準的な変更は事前承認とし、ビジネスへの影響が極めて大きい変更にのみレビューの時間を割くという、リスクベースのトリアージが実行できているかが2つ目の判断基準です。
判断基準3｜後回しにされるセキュリティ
「リリース直前のセキュリティ監査で致命的な脆弱性が発見され、数週間の手戻りが発生する」。これが3つ目の判断基準です。
開発プロセスの初期段階でセキュリティ要件を組み込まず、最終フェーズで検査を行うというウォーターフォール型のセキュリティチェックは、手戻りコストを最大化させます。
一般的な市場データに基づくと、リリース直前の修正コストは、設計段階での修正コストの10倍から30倍に跳ね上がります。
よくある誤解として、「セキュリティ部門はプロジェクトの進行を妨げる邪魔者である」という認識があります。
彼らはデータ漏洩という致命的なビジネスリスクを防ぐ役割を担っています。
セキュリティ担当者を開発の初期段階（スプリントの計画段階など）から参加させているかどうかが、組織の成熟度を測る指標となります。
組織を変えるDevOps「3つの道」の実践
本書で語られる「3つの道（The Three Ways）」は、IT業務の管理手法として提唱されていますが、根本的な基盤は「制約理論（TOC）」「リーン生産方式（トヨタ生産方式）」「総合的品質管理（TQM）」といった製造業の管理理論にあります。
製造業が数十年かけて培ってきた「ムダの排除」「品質の作り込み」「継続的改善」の哲学を、目に見えないITのシステム開発・運用プロセスに見事に適応させています。
Amazonで「トヨタ生産方式」を確認。
第1の道｜可視化し「流れ（フロー）」を速くする
作中のビルが最初に取り組んだのは、カンバンボードを用いた「業務の可視化」と「WIP（Work In Progress：仕掛品）の制限」です。
IT部門が抱えるすべての作業（障害対応、内部プロジェクト、ビジネス部門からの依頼など）を可視化し、同時に進行する作業数を物理的に制限します。
WIPを制限する理由は明確です。
10個のプロジェクトを同時に進めてすべてを1年後に完成させるより、3個のプロジェクトに集中して3ヶ月で完成させ、次の3個に着手する方が、ビジネスに対して圧倒的に早く価値を提供できるからです。
第2の道｜フィードバックループの構築
第2の道は、右（運用・顧客）から左（開発・ビジネス）へのフィードバックループを構築し、サイクルを短縮することです。
フェニックスプロジェクトの失敗は、巨大な要件を数ヶ月かけて開発し、一気にリリース（ビッグバンリリース）したことに起因します。
その後、主人公たちはより短いイテレーション（反復）で開発を行う手法に切り替えます。
ビルドからテスト、デプロイまでの手順を標準化・自動化することで、人的ミスを排除し、問題が発生した際にも即座に検知して修正できる体制を構築します。
これにより、変更のバッチサイズ（1回あたりのリリース量）が小さくなり、障害の影響範囲も極小化されます。
第3の道｜継続的学習と実験の文化
第3の道は、失敗を恐れずに実験を繰り返し、そこから学習する文化の醸成です。
DevOpsは単なるツールの導入ではなく、組織文化の変革を伴います。
セキュリティ担当のジョンは、かつての「監査役」から脱却し、開発部門のビルドプロセスにセキュリティテストを自動で組み込むという実験を行います。
また、QA（品質保証）部門と同じテストプロセスを共有することで、部門の壁を越えた連携を実現します。
「失敗＝個人の責任」として追及する文化のままでは、誰もリスクを取らなくなります。
インシデントが発生した際は、非難なきポストモーテム（事後検証）を実施し、「どのプロセスに欠陥があったか」をシステムレベルで改善する仕組みが必要です。
自組織の状況に合わせて選ぶ改善の第一歩
キーマン依存の解消策
特定の個人（ブレントのような存在）に業務が集中している場合、ツールの自動化やプロセスの改善は後回しにする必要があります。
最初のステップは、そのキーマンの頭の中にある暗黙知を組織の形式知に変えることです。
具体的には、新規の作業依頼がキーマンに直接届く経路を遮断し、すべての作業をチケット化します。
そして、例外なく他のメンバーとペアを組ませて作業を実施させ（ペアオペレーション）、作業手順をドキュメント化させます。
この施策により、初期段階では一時的に作業効率が低下しますが、3ヶ月後には対応可能なメンバーが増加し、キーマンのボトルネックが解消されます。
部門対立を解消する仕組み
開発と運用、あるいはIT部門とビジネス部門の間で対立がある場合は、共通の目標（KPI）が設定されていないことが原因です。
開発部門のKPIが「新機能のリリース数」、運用部門のKPIが「システムの安定稼働（無停止）」である場合、両者は構造的に対立します。
この状況を打破するには、両部門の共通KPIとして「リードタイム（要求から提供までの時間）」と「変更障害率」を設定します。
さらに、作中のビジネス部門担当者マギーがIT部門のスタンドアップミーティングに参加したように、部門を横断したミーティングを実施します。
関係者全員が同じ進捗とリスクを共有することで、「誰の責任か」ではなく「どう解決するか」に焦点が当たるようになります。
手作業デプロイの自動化
ソフトウェアのリリース時に毎回異なる手作業が発生し、リリースエンジニアの順番待ちが起きている場合は、ＣＩ/ＣＤ（継続的インテグレーション/継続的デプロイ）の導入に着手します。
ここでよくある誤解が、「一気にすべてを自動化しようとする」ことです。
これは高確率で失敗します。まずは現状の手作業のプロセスを1文字の省略もなくドキュメント化し、標準手順を確立します。
その後、テスト環境へのデプロイなど、リスクの低い部分から段階的に自動化スクリプトを導入します。
手動による介入を少しずつ減らしていくことで、最終的にボタン1つで本番環境へ安全にデプロイできるパイプラインが完成します。
最後に
書籍「The DevOps逆転だ！究極の継続的デリバリー」内で語られる「フェニックスプロジェクト」が示す最大の教訓は、ITは孤立した機能ではなく、ビジネスを駆動する中核的な能力であるという事実です。
自組織の現在のボトルネックが「人」「プロセス」「技術」のどこにあるのかを上記3つの状況から判定し、最初の行動を開始して下さい。
より詳しく知りたい方は、ぜひ書籍をご一読下さい。
