『フェニックスプロジェクト』(2013年)は、企業のIT部門における開発チームとIT運用チームを統合することで、コミュニケーションが改善され、ワークフローが加速し、価値が向上する過程を探求する書籍です。架空のストーリーを通じて、実在のよくある課題を詳しく説明し、DevOpsアプローチが組織を俊敏にし、突然の変化やアップデート、市場圧力にも柔軟に対応できるようになることを示しています。
あなたに得られるものは？ DevOpsが企業価値を高める方法を発見しよう。
自動車部品の製造・小売企業であるパーツ・アンリミテッドは、新たなIT施策を立ち上げました。それは「フェニックスプロジェクト」と呼ばれ、同社の小売チャネルとECチャネルをシームレスに統合することを目指しています。これにより、パーツ社は競争力を高め、顧客基盤を拡大できるはずです。フェニックスは会社の成功に欠かせません。しかし、そのプロジェクトは大幅に遅延し、予算も超過しています。
CEOはこの混乱を立て直す責任者を探しています。与えられた期間は90日間。失敗すればIT部門全体が職を失います。この後に続くストーリーはフィクションですが、描かれる問題と解決策は非常に現実的であり、IT関係者ならすぐに理解できるものです。この要約では、開発とIT運用の間の根深い対立が、IT部門だけでなく企業全体の失敗を招く様子を示します。そして、DevOpsという一連の手法が、驚異的な効率性、最先端のパフォーマンス、価値向上、そして多くの頭痛の種からの解放をもたらすことを明らかにします。この要約で学べることは：
- ITと製造工場の意外な共通点
- IT作業の4つのタイプ
- 繰り返される失敗が成功の秘訣である理由
IT部門の混乱は会社全体の失敗を招く
火曜日の朝、ビルは仕事に遅れそうになっていた。高速道路を飛ばしていると電話が鳴り、出社次第すぐにCEOのスティーブのところへ来るようにと言われる。「やばい、クビになるかも」とビルは思う。
驚くことではないかもしれない。パーツ・アンリミテッドの中規模テクノロジーグループの責任者として、ビルは常に自分の仕事をきちんとこなすことに誇りを持っていた。元海兵隊員として、信頼でき、効率的で、率直だという評判を築いてきた。しかしパーツ社は大いに苦戦している。ビルが入ろうとしている駐車場はほとんど空だ。競合他社は絶えず革新を続け、パーツ社ははるか後方に取り残されているように見える。
過去数年間のレイオフで、ビルの部署はより少ないリソースでより多くのことをこなさざるを得なくなっていた。だがスティーブはビルをクビにしようとしているのではない。「昇進」させるのだ。新しいIT運用担当副社長として、ビルはスティーブ直属となり、目前に迫ったフェニックスプロジェクトの展開を成功させる役割を担う。会社の未来はフェニックスにかかっているとスティーブは言う。ビルも分かっているだろう？ 顧客がオンラインでも実店舗でもパーツから買い物できるようにしなければならないのだ。
さもなければ、すぐに顧客はいなくなり、会社は消滅してしまうだろう。ここでのポイントは：IT部門の混乱は会社全体の失敗を招く。ビルはその昇進を受けたくない。それは実質的に、巨大なITの配管修理を任される清掃員の役割を引き受けることになるからだ。しかし気がつくと、自分がスティーブの手を握り同意していることに愕然とする。一体どこから手をつければいいのか？ ITインフラ全体が全くの無秩序状態なのだ。
情報セキュリティ部門のジョンは、度々SEV1（最重要障害）を引き起こしている。監査対応のために自分が重要だと判断した開発変更を、適切なクリアランス手順を無視して押し通すからだ。もちろん、運用チームはそれらの変更を事前にテストすることができない。テスト環境がないのは予算がないからだ。一方、ITサービスサポート部長のパティは、変更が全く文書化されていないとビルに伝える。誰も使いにくい変更管理ツールを使いたがらず、毎週のCAB（変更諮問委員会）ミーティングにも出席しない。どうやって誰が状況を把握しているのか？ ビルが気づいた答えは：誰も把握していない、ということだ。
事態が悲惨なのも無理はない。ビルは自分の机を見る。古いラップトップはブルースクリーンになってしまい、代わりに支給されたのは、少なくとも10年前の代物——かさばって重い、まるで恐竜のようなマシン。文字の半分は消えかかり、バッテリーはテープで留められている。これは宇宙からの何かのメッセージなのだろうかと思わずにいられない。
IT運用は工場運用と同様に「制約の理論」に支配されている
フェニックスは10日後に展開予定だった。しかし、プロジェクトの最終タスク12個のうち、完了したのはわずか3つ。IT部門が緊急対応に追われていたからだ。より正確には、リードエンジニアのブレントがそれらを一手に引き受けていた。かわいそうなブレント。ビルは、たった一人の男がどうやって組織全体を支えているのか理解できなかった。
彼は直面するあらゆる問題を解決する天才だ。だからこそ、あらゆる問題が彼に集中する。ここでのポイントは：IT運用は工場運用と同様に「制約の理論」に支配されている。ビルが新しい責任に取り組み始めた矢先、エリックという人物に会えと言われる。将来の役員候補で、どうやらテクノロジー界の大物らしい。だが、会議室に着くと、そこにいたのはヨレヨレのズボンにデニムシャツを着たドーナツ配達員だけだった。「へえ」とビルは思いながら、自分の皿にドーナツを山盛りにし始める。
配達してくれるとは知らなかったよ。すると突然、その配達員が振り返り、手を差し出してこう言った。「私がエリックです」。そしてすぐに、パーツ社のIT運用のあらゆる問題点をビルにまくし立て始める。ITは純粋な知識労働だという神話がある、とエリックは言う。人々はITが標準化や文書化とは無縁だと思い込んでいる。しかし、ITは工場運用から多くを学べるのだ。
その主張を証明するため、エリックはビルに荷物を持ってついてくるよう言う。5分後、彼らはパーツ社の製造工場の一つに到着した。工場内を見渡しながら、エリックは制約の理論を説明する。ほとんどの工場では、システム全体のアウトプットを決定づける少数のリソース（材料、機械、人）が存在する。これらがボトルネック、すなわち制約だ。効率を最大化するには、まず制約を特定する。制約がどこか分からなければ、改善をどこに集中すべきか分からない。
そして、制約以外の場所での改善は無意味である。ライン上で考えてみよう。制約の後で改善を行えば、待ち時間が増えるだけ。ボトルネックの前で行えば、仕掛在庫が積み上がるだけだ。第二のステップは制約を徹底活用すること。制約は決して遊ばせてはいけないし、他のリソースを待たせてもいけない。常に最も優先度の高いコミットメントに取り組むべきだ。最後に、制約に従属させる。
最も歩くのが遅いボーイスカウトが一行全体の行進ペースを決める。だからそのスカウトを列の先頭に移動させる。言い換えれば、すべての仕事は、制約が処理できる速度に基づいて投入するのだ。ブレントだ、とビルは気づく。あらゆる人の問題を解決してしまうエンジニア。そうか！彼こそが制約だ。たった30分で終わるはずの変更が、ブレントに渡ると完了までに数週間かかっていたのはそのためだ。
彼は常に100％以上で稼働させられているため、渡された仕事は緊急時以外はキューに溜まるだけだ。すべてが理にかなっている。ビルは仕事のペースをブレントに合わせる方法を見つけなければならない。ITの仕事が工場運営に似ているとは誰が想像しただろう？
IT作業の4つのタイプを理解すれば、コミットメントを果たせるようになる
フェニックス展開の数日前、プロジェクト管理会議はうまくいっていなかった。ビルが時間の延長を求めているにもかかわらず、小売部門のサラは計画通りのローンチを強く求めていた。彼女がIT運用チームが手を抜いていると非難すると、ビルは深呼吸をする。彼はこの映画を以前にも見たことがある。
プロジェクトの出荷は、顧客やウォール街への約束のために遅らせられない。開発者がスケジュールを乗っ取り、運用テストの時間がまったく残されなくなる。その結果、とんでもない近道が取られ、最終的なソフトウェア製品は不安定か、もしくは使い物にならなくなる。粗末なコードを補うために、誰が一晩中サーバーを再起動し、比喩的なバンドエイドを貼り続けなければならないのか？ IT運用だ。ビルはため息をつく。
彼はエリックが言っていたことをずっと考え込んでいた：仕事の4つのタイプ。厳格さと規律だけでは限界がある、とエリックは言っていた。IT運用の「仕事」が実際何であるかを理解するまでは、プロジェクトの成果物、障害、コンプライアンスにうまく対処できないのだ。ここでのポイントは：IT作業の4つのタイプを理解すれば、コミットメントを果たせるようになる。フェニックスを展開するのが仕事だと、ビルはエリックに言っていた。しかしエリックは感心しなかった。
公式の会社イニシアチブ、つまりビジネスプロジェクトは、仕事の一つのカテゴリーにすぎないと彼は言った。そこでビルは必死に考える。他のカテゴリーとは何だろう？ 突然、ひらめく。二つ目の仕事のタイプは内部ITプロジェクトだ。これらはビジネスプロジェクトが生み出すインフラやIT運用プロジェクトであり、展開の自動化や新しい環境の作成といった改善施策も含まれる。
内部プロジェクトはしばしば一元的に追跡されず、ワークフローの制御が難しくなる。変更は三つ目の仕事で、主にビジネスプロジェクトと内部プロジェクトから生じ、提供中のサービスに影響を与える可能性のあるあらゆる活動だ。IT運用と開発の変更は別々のシステムで追跡されるため、ミスや時間の無駄が多く、特に引き継ぎの際に発生しやすい。最後に、そして決して忘れてはならないのが、計画外の仕事だ。計画外の仕事は消防活動のようなもの。他の三種類の仕事によって引き起こされたインシデントや緊急事態全てに対処することである。
そしてこれが常に計画された仕事のコミットメントを妨げる——それがフェニックスのローンチを危うくしている。計画外の仕事は目標達成を阻害する。その意味で、それは「アンチワーク」であり、どんな手段を使ってでも排除すべきだ。人生は完璧ではない。物事は壊れ、計画外の仕事は常に発生する。重要なのは、それを効率的に処理できること。それにはまず、どこから来ているのかを突き止めることから始まる。
多くの場合、それは技術的負債から生じる。手軽だが結局は愚かな近道によって生じる負債だ。金銭的負債と同様に、技術的負債は時間と共に複利で増大する。負債を返済しなければ、全エネルギーが利子の支払い、すなわち計画外の仕事という形で消費されてしまうのだ。
優れたチームは、信頼、コミュニケーション、コミットメント、説明責任、そして共通の成功を重視する
ビルはエリックの教えを実践しようとする。しかしCEOのスティーブが介入し、従来のやり方で不可能なスケジュール通りに進めるよう主張する。予想通り、フェニックスのローンチは大失敗に終わる。ビルは動じない。
むしろ、彼は辞職する。彼がいなくなると、プロジェクトはさらに急降下する。IT運用、開発、ビジネス——各部門は必死に混乱から秩序を生み出そうとする。しかし、彼らは互いに常に対立し、責任を熱いジャガイモのようになすりつけ合う。彼らにはビルが必要だ。そこで少しの説得と魅力的なボーナスで、ビルは戻ってくる。
ここでのポイントは：優れたチームは、信頼、コミュニケーション、コミットメント、説明責任、そして共通の成功を重視する。ビルが会議室に入ると、スティーブが自分の子供時代について話していた。家族はとても貧しかった、と彼は言う。夏は兄弟と一緒に綿花を摘み、家族で初めて大学に進学した。「うっ」とビルは思う。こんな感傷的な話は嫌いだ。
しかし、この悪循環を断ち切らなければ、パーツ・アンリミテッドは終わってしまう。そこで全部門長が一堂に会し、スティーブが愛読する本、『チームの5つの機能不全』について話し合う。信頼こそがチームワークの基盤だとスティーブは言う。もちろん、複雑なビジネス問題を解決するにはチームワークが必要だ。したがって、信頼の欠如がチームの第一の機能不全である。リーダーは、信頼がないだけで対立や慢性的な不振に陥る。そしてそれが組織全体に波及する。リーダー同士が信頼しなければ、チームも信頼しなくなる。
では、どうやって信頼を育むのか？ それは脆弱性を受け入れることから始まる。だからこそスティーブはパーソナルヒストリーの演習をリードしている。自分がどこから来て、何に突き動かされているかを共有することで、脆弱性の模範を示す。そしてグループの各人に同じことをするよう求めるのだ。衝突への恐怖が第二の機能不全だ。建設的で熱のこもった議論よりも、偽りの調和を選ぶことは、どこへも通じない道である。
意見の対立する問題について率直に話し合うのは難しい。リーダーやチームが染みついた行動を克服する必要がある。しかし、衝突を受け入れることが進歩を促す。第三の機能不全はコミットメントの欠如だ。特にグループでの決定において、形だけの賛同は社内に曖昧さと無関心をもたらす。
説明責任の回避は第四の機能不全である。責任を取らず、また仲間の逆効果な行動を指摘しないことは、いずれも基準を低くする。最後に、結果への無関心がある。チームの成功よりも、自分の利益や地位、エゴを優先するなら、それは決して双方にとって望ましい状況ではない。
第一の方法：開発からIT運用、そして顧客への仕事の流れ
リーダーシップミーティングですべてが解決したわけではない——しかしそれがポイントではない。ビルには、チームが今手にしているものはさらに優れていることが分かる。それは、解決に向けて進む中での共通のビジョンだ。全員が協力する時が来た。エリックが言う、DevOpsの時だと。これはソフトウェア開発（Dev）とIT運用（Ops）を統合する一連の手法である。
今日、DevOpsはITに対して、産業革命が製造業に果たしたのと同じ役割を果たしつつある。原材料を完成品に変えるプロセスを最適化する代わりに、DevOpsはITの価値の流れをアップグレードする方法を示す。つまり、市場投入までの時間を短縮し、より柔軟で回復力のあるシステムを構築し、潜在的なイノベーションを素早く検証するテストを組み込むのだ。DevOpsの作業パターンの背後にあるビジネス原則は、製造業のそれを反映している。エリックはそれらを「3つの方法」と呼び、その第一はワークフローに関わるものだ。ここでのポイントは：第一の方法は、開発からIT運用、そして顧客への仕事の流れに関わる。第一の方法の重要な部分は、開発とIT運用を通じた仕事の速い流れを作り出すことだ。
毎週のエグゼクティブレビューでToDoリストを整理し、コミットメントの優先順位を付け直すような時間の無駄をやめ、かんばんボードを導入する。かんばんボードとは、進行中のITプロジェクトを可視化したものだ。すべてのプロジェクトを一箇所にまとめることで、チームの誰もが、いつでもどれだけの仕事が進行中で、何が行われるべきかを一目で把握できる。断片的なメールやテキストメッセージ、電話を仕分けたり追跡したりする必要はない。かんばんボードを作るには、壁に「Ready（準備完了）」「Doing（進行中）」「Done（完了）」の三つの列を作る。進行中のすべての作業内容をインデックスカードに記入し、それぞれの列に配置する。そしてここが肝心だ：仕掛かり中の作業（WIP）を、一度に4〜5枚までに制限する。
第一の方法の重要な要素は、可動部分の数を減らすことだ。これにより、チームは少数のタスクに集中し、素早く完了させてから次に進むことができる。タスクが完了したら、カードを新しい場所に移動させる。たとえば、タスクを開始したら、そのカードを「Ready」から「Doing」へ移す。
エリックの第一の方法は、特定の部門やサイロ化された仕事ではなく、システム全体の成功に焦点を当てる。WIPを減らすだけでなく、かんばんボードは、企業全体のパフォーマンスにとって最も重要なことを強調することで、チームが適切な仕事——そして適切な量の仕事——にコミットするのを助ける。肝心なのは、コードが本番環境にデプロイされるまでは、実際には何の価値も生み出されていないということだ。だからシステムから不要な仕事を取り除くことは、新しい仕事を追加するよりも重要であることが多い。そして、コミットメントにノーと言えることが極めて重要だ。覚えておこう：WIPが少なければ少ないほど、あなたはより効果的になる！
第二の方法：手戻りを防ぐために品質を源流で修正する
2007年式スズキ・ハヤブサのドラッグスターバイクは、まさに美の結晶だとエリックは言う。速度は230mphを超え、6速コンスタントメッシュギアボックスと#532チェーンドライブを搭載している。ただ、ついていないのはリバースギアだ。
彼はある主張をしようとしている。その高速バイクのように、ITのワークフローにもリバースギアがあってはならない。欠陥や曖昧さによって後戻りする仕事は、まさに無駄そのものだ。理想的には、仕事の流れは一方向、すなわち前進のみであるべきだ。車の比喩を続けるなら、予防的なオイル交換や車両整備こそが第二の方法の本質である。ここでのポイントは：第二の方法は、手戻りを防ぐために品質を源流で修正すること。
現在、フェニックスプロジェクトのリリース間隔は9ヶ月だ。しかし、ビルが初期段階で製品に品質を組み込み、前進する流れを確保したいなら、それはあまりに長すぎる。彼には、顧客やIT運用から開発へと戻る、より速く増幅されたフィードバックループが必要だ。あるいは、エリックが言うように、「南北戦争時代の大砲のことは忘れろ。対空砲を考えろ」。目標は単品流し（シングルピースフロー）、つまり、一つの製品単位が異なる工程間を流れていくことである。
言い換えれば、一度に一つの部品に取り組む。工程間の待ち時間を排除することで、スループットを最大化し、WIPを制限し、エラーを最小限に抑える。製造業の例を挙げよう。トヨタの悪名高い「シングル段取り」（シングル・ミニッツ・エクスチェンジ・オブ・ダイ）。この用語は、一連の改善を通じて単品流しを達成し、ボンネットのプレス段取り替え時間を3日間から10分未満に短縮したことを表している。ITにおいて、単品流しは継続的デリバリーアプローチによって達成できる。これは三つのことを重視する。第一は、小さなバッチサイズだ。
小さなバッチで作業することで、素早くフィードバックループを適用し、必要に応じて軌道修正できる。第二は、問題が発生したら生産ラインを止めること。つまり、ビルド、テスト、デプロイメントに失敗した場合、新たな作業を一切引き受けないということだ。第三に、コードが常にデプロイ可能な状態であることを保証する、高速な自動テストスイートを作成する。覚えておこう。コードは、開発がコーディングを終えた時点で「完了」なのではない。テストされ、設計通りに動作していることを確認できた時点で完了だ。エリックはフェニックスのリリース間隔に小さな変更を提案する。
9ヶ月に一度のデプロイではなく、ビルは1日10回のデプロイを目指すべきだと。不可能だ、とビルは思う。しかし、2009年にFlickrがまさにそれを成し遂げた。当時、ほとんどのIT組織は四半期または年単位のデプロイを行っていた。
開発と運用がビジネスと協力し、第二の方法の手法を実践することで、Flickrはワンステップの環境構築・デプロイ手順を作り上げ、1日に10回のデプロイを可能にしたのだ！ それは同時代のどの企業よりも千倍速い。今日、その数字はさらに高くなっている。Amazon、Netflix、Google——DevOpsのプロセスと文化的慣行を採用している組織のほんの一部だが、彼らは今や日常的に何千もの本番環境への変更を展開しながら、卓越した安定性とセキュリティを提供している。
第三の方法：継続的な実験、失敗、改善の文化を創り出す
ビルは自分の真新しいラップトップをじっと見つめている。アプリケーションもデータもすべてそこにあり、メールも正常に動き、すべてが完全だ——つまり、完璧に機能する。ビルの古いラップトップがパーツ・アンリミテッドの何もかもが間違っていたことの比喩だったなら、この新しいラップトップは、過去数ヶ月で彼のチームが共に成し遂げたすべてを象徴している。SEV1障害は3分の2減少し、インシデントの復旧時間は半減した。
チケットシステムからは不要な作業が一掃された。開発と運用の同期を保ち、ばらつきを排除するための標準化された環境構築プロセス——つまりビルド手順——が確立された。開発者はセキュリティ部門と協力して、デプロイ後にセキュリティ対策を施す代わりに、予防的なプロジェクトを作成している。監査人も納得し、セキュリティ関連の作業は75％削減され、労力を他に振り向けられるようになった。これらすべてが意味するのは、プロジェクトの流れが加速したということだ。フェニックスは順調に稼働している。
人々は自分のタスクが何かを明確に理解し、仕事を全うできることに充実感と喜びを感じている。そして第三の方法を通じて、彼らはかつてないほどイノベーションを起こしている。ここでのポイントは：第三の方法は、継続的な実験、失敗、改善の文化を創り出すこと。第三の方法によれば、良くなっていなければ、悪くなっているのだ。これには三つの部分がある。第一は実験だ。
競争相手に打ち勝つには、彼らを上回る実験を繰り返さなければならない。だからこそ、イノベーションとリスクテイクを奨励することが重要だ。パーツ社では、「ユニコーン」と呼ばれるイノベーションに特化した新しいプロジェクトがある。フェニックスからコピーしたデータと環境を使って、エンジニアたちは全く同一だが完全に分離されたデータベースを作成し、本番アプリケーションを妨げることなく、顧客ターゲットのプロモーションなどを継続的に開発・テストできるようにした。第二の部分は失敗についてだ。そのために、パーツ社は「シミアン・アーミー・カオス・モンキー」プロジェクトを立ち上げた。その任務は？
プロセスやサーバー全体を強制終了させる壊滅的なバグを生み出すこと。当初は大混乱で、テストインフラが繰り返しクラッシュした。しかし、開発とIT運用が協力してコードとインフラをより堅牢にするにつれ、ITサービスは障害に対して耐性を持つようになった。第三の側面は、日々の作業そのものよりも改善を優先することだ。パーツ社では、すべての管理職が2週間ごとに何か——どんなことでもいいから——改善しなければならない。このいわゆる改善の型（カタ）サイクルが、システムに絶え間ない圧力をかけ、前進を強制する。
武道において、型とは動作パターンを練習して第二の天性にする行為だ。習慣こそが熟達につながる。研究によれば、週に1度3時間練習するよりも、毎日5分間練習する方が効果的だという。つまり、習慣をより頻繁に実践するほど良いのだ。今日のテクノロジー主導の世界において、ITは単なる部門ではない。
読み書きの能力と同じで、ITはスキルなのだ。ビジネスマネージャーは、計算されたリスクを取るためにそのスキルを身につける必要がある。そしてそのリスクが、競合に打ち勝つために不可欠なのだ。ビジネスとITが本質的に不可分であることを理解し、DevOpsの原則と実践を導入するとき、組織全体が勝利を手にする。
最終的なまとめ
この要約の中心的なメッセージは：今日のテクノロジー主導の環境では、IT部門が企業の屋台骨を形成することが多い。したがって、開発チームとIT運用チームの間のコミュニケーションとワークフローがずれていると、それは経営トップにまで影響を及ぼす。 しかし、社内の混乱が常態である必要はない。 DevOpsの出番だ。これは「3つの方法」を中心とした統一IT戦略である。
これらのビジネス原則は、短いフィードバックループ、合理化されたコミュニケーション、そして実験、反復、実践の文化を重視する。 これらのプロセスを実装することで、あなたのIT組織——そして企業全体を——かつてない高みへと導くことができる。 そして、さらに実践的なアドバイスを：パーソナルなかんばんボードを作ろう。 組織レベルでの作業の詰まりを防ぎ生産性を高めることに加え、かんばんボードは個人レベルでも、適切な仕事量にコミットし進捗を可視化することで効率を向上させることができる。
だから、詳細で文脈に依存したToDoリストをやめて、白い壁とポストイットに置き換えてみよう。やるべき作業をすべて「Ready」「Doing」「Done」の3列に分類する。WIPを常に4〜5項目に制限し、さあ取りかかろう！ 進行に伴って、それらのカードは左から右へと移動し、おそらくこれまでよりずっと早く目標を達成できるだろう。
