「The DevOps 逆転だ! 究極の継続的デリバリー」は、ITのデスマーチプロジェクトを舞台にした小説です。DevOpsという、開発(Development)と運用(Operation)が
一体となってシステムを開発導入していく手法が扱われています。
ザ・ゴールのIT部門版というとすっと入る方もいるかもしれません（実際にザ・ゴールの制約理論の話も出てきます）
関連記事：5分でわかる「ザ・ゴール」の要約まとめ！
本記事では、書籍で扱うDevOpsのエッセンスを簡潔に紹介します。巷のDevOps本は専門的で手が出しづらい、かといって「The DevOps 逆転だ」も気になってるものの分厚くてなかなか読む時間がとれない、という方が短時間でキャッチアップすることを目的に書いています。
過去に読んだもののあまり覚えていない方、読んだことがない方は最初に以下の問いを考えて読み進めてみて下さい。これらは主人公が師事するエリック・リードから受けたものです。
主人公がエリックから受ける問い
- IT運用の『仕事』の定義は？
- 3つの道とは何か？
- ブレントにあわせて仕事のテンポを刻む方法は？
- ビジネスの目的を達成するために必要なものは何か？
- 凍結プロジェクトを解除するにはどうすればいいか？
それぞれの問いに回答
IT運用の『仕事』の定義は、ビジネス・内部・変更・予定外の4タイプ
主人公のビルが即答したのはフェニックスを世に出さねばならないという仕事でした。
エリックは他に3つ仕事があることを見落としていると指摘しました。
ここに気づくまでは問題解決に必要な仕事の理解からはほど遠いと言います。そして工場現場を見せにいきます。
1つ目は企業のビジネス上の要請から遂行される「ビジネス・プロジェクト」。
ほかには、
2つ目、「内部プロジェクト」です。これについては主人公は、IT運用で抱えている100近いプロジェクトを棚卸しして見出しました。製品アップグレードや環境マイグレーションなどIT運用上必要な技術的仕事は必ず存在しています。
3つ目、「プログラム変更」です。これは、壁に貼り出した変更要求カードを見ながら気づきました。「今週やろうとしている437件の仕事…」それがプログラム変更だったのです。単一のプロジェクトとして扱うには小さいが無視できない仕事です。変更は、機能拡張や内部統制上の要請から発生します。
4つ目が、「予定外の仕事」です。予定された仕事を押し流す存在としての予定外の仕事です。当たり前すぎる結論です。しかし、エリックは最も破壊的なタイプの仕事を表現しました。他のタイプとは異なり、仕事でもなんでもないわけですから。エリックが「反仕事」という呼び方を勧めるのは、破壊的だが避けられるという性質を認識しておけるからです。
3つの道は、開発→運用、運用→開発、学習と改善
第1の道は、開発からIT運用への仕事の流れを速くするにはどうすればよいか。
第2の道は、運用から開発へのフィードバックループを短縮し強化する方法。すると、源のところで品質を上げ、やり直しが避けられる。
第3の道は、実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ることだ。
第1の道を実現するには、かんばんや変更ボードを用いてビジュアルに作業の流れを可視化します。全員でWIP（Work In Progress、仕掛作業）を見ることができます。ボトルネックを認識し流れを制御、バッチサイズを小さくすることです。
第2の道は、どのように設計に品質を組み込むかですが、予定外の仕事の源を叩き潰すのが目的です。プロセスの自動化と環境準備の柔軟性を確保します。
第3の道は、失敗したことを学習し、不都合なことを改善する努力を日頃から続けられる文化と習慣の確立があって初めて変化に即応できる企業になれるということです。
ブレントにあわせて仕事のテンポを刻む方法は、フェニックス以外の仕事を止めること
工場に積み上がった仕掛り在庫を減らすには、ジョブと原材料の投入を止めることが必要です。WIPが減り、納期遵守率が上がります。
これをIT現場にも応用するのが、最重要プロジェクトであるフェニックス以外の仕事を止めることでした。
IT運用の130人がただじっと座っているのは無駄なことに感じます。
物語ではこれを社長から全マネージャーへのメール発信によって徹底しました。
エリック・リーズのリーンスタートアップ。
ジェス・ハンブルの継続的デリバリー。
チーム開発実践入門。新卒の同期が書いた本で、読んだときの数年前の自分の運用現場そのものでした（アフターじゃなくてビフォーが）。考え方を理解する上では上記の本が必要だけど、IT現場でDevOps実践するにはこの1冊があれば十分な気もします。
