さらに、Allspaw氏の考えるOpsでは、ビジネスが進化する上で求められるスピードで本番環境にどんな変更を加えても大丈夫なようにする責任があります。その大前提の下で、例えばDevが直接本番環境へのリリースを行うことで、リリース作業のしやすさに配慮することの重要性に気づくといった効果が生まれます。「コードを出荷してQAに渡したら自分の仕事は完了」というお役所仕事のカルチャーはEtsyにはない、としています。換言すると、従来のDevとOpsの既成概念や縄張りはご破算にして、進歩を遂げたテクノロジーに合うように自分たちの仕事のやり方を進化させていけばいい、すなわち“運用は枯れてなお運用”（図2）なのです。この2012年の出来事に先立つこと約5年、DevOpsはそのような大きな潮目の変化を予見した、先見性のある専門家たちにより2008年頃に問題提起され今日に至ります。
今日的なDevOpsの定義とデリバリー能力向上の方策
このような歴史を踏まえ、今日においてDevOpsとはいかに定義されるべきでしょうか。個人的に一番しっくりくるのは、2009年より続くカンファレンスDevOpsDaysにおいて長年アドバイザーとして貢献してきたPatrick Debois氏による、「Dev*Opsについて私の現在（2022年時点）の定義は、『サイロ化により引き起こされる摩擦を克服するために行うあらゆること…あとは全てエンジニアリング』」というものです。
この定義は、ここまで見てきた2つの要素、すなわち（1）技術革新による自動化（＝エンジニアリング）と、（2）これまでのDevとOpsの関係の解体と再構築です。
まず（1）「技術革新による自動化（＝エンジニアリング）」に関しては、DevOps黎明期においては前述の革命的ともいえる技術の進歩の影響が強かったこともあり、Debois氏の定義において「エンジニアリング」と表現される部分、つまり自動化がメインでした。自動化による効率化を通じ組織のスループット（単位時間当たりのアウトプットの量）を向上させることに心血が注がれたわけですが、能力が向上したかどうかを測定する上では、例えば、表1のような代表的な指標に対する組織のパフォーマンスを測定し、定点観測を行うことが必要です（表1）。
なお、どんな組織にも長年の運用を通じて蓄積された「秘伝のタレ」のような運用が存在します。それらのルールにはもちろん合理性があり、そしてそのルールに馴染んでいる現場のメンバーがいます。自動化と手作業が混在した運用で妥協することなく、難しいことを徹底的に抽象化して「ものづくり（＝エンジニアリング）」することが究極の目標と言えるでしょう。
さて、問題は（2）「これまでのDevとOpsの関係の解体と再構築」ですが、全てはカルチャーやレガシーを理由にした既存の常識を捨てるところから始まります。何か新しい取り組みを行う際、明確な理由もなく「それはここではムリだ」という発言を根絶すべく、それらに対して「何故（Why）?」と問いかけ、現状のやり方がなぜ問題なのかを関係者に理解してもらうのがリーダーの役割になってきます。その解決に際しては、イスラエルの物理学者Eliyahu Goldratt氏の有名な「制約条件の理論」（Theory of Constraints）などのフレームワークが有効です。
制約条件の理論の構造にのっとって構成され、2013年に上梓された「The Phoenix Project（邦訳：TheDevOps逆転だ！ 究極の継続的デリバリー）」は、筆者の拙い記憶では当時原文のKindle版が1ドル前後で読めたこともあり、北米を中心に通算2万件近いレビューが投稿されるほどの反響を呼びました。
制約条件の理論は、有名な理論ですので詳細は割愛しますが、ある一連の作業のスピードを上げるためにはまずボトルネックとなっている箇所を明らかにし、その箇所のスループットを向上させよと説いています。その手段としては、ボトルネック以外の箇所の要員をボトルネック部分に投入する、無関係な作業を止めて要員のビジー率を下げる、などいくつかの方法がありますが、その過程で従来のDevとOpsの境界線の見直しが不可避となります。なお、その結果としてボトルネックが解消されても「めでたし、めでたし」ではありません。最初のボトルネックが解消されたら、最初に戻って次のボトルネックを明らかにし、その解消を目指せ、そしてそれを繰り返せ、と同理論は説いています。さながら運用（Ops）の仕事が、システムが稼働し続ける限り続く「終わりなき日常」であることの隠喩のようです。
最後に、運用の仕事は今後どのように変わっていくのでしょうか。前述のNetflixのように「カオスエンジニアリング」の技術を通じ、自らシステムに野猿を放って修復能力を試すアプローチもあれば、Etsyのように、境界線を技術環境の変化に合わせて見直しつつ、お互いが対等の立場で顧客への価値提供の能力向上を図るアプローチもあります。どのような進化の過程をたどるにせよ、図2で見たような得手不得手が残り続けることを前提に、開発が単独で賄うことの難しい領域についてのナレッジや各種サービスを提供するコンサルテーションやイネーブラーとしての役割は、時代に合わせて変化しつつも今後も重要な要素として残り続けるものと考えられます。
- 岡本 修治（おかもと・しゅうじ）
- KPMGコンサルティング Technology Strategy & Architecture シニアマネジャー
- 外資系総合ITベンダーにおいて大規模SI開発をはじめ、ソフトウェア開発プロセス／ツール展開のグローバルチーム、コンサルティング部門などを経て現職。金融、製造、情報通信など業界を問わずITソリューション選定、開発プロセスのアセスメント（評価）と改善、BPR支援などさまざまな経験を有し、中でも不確実性の時代と親和性が高いアジャイルトランスフォーメーションを通じた意識改革、開発組織の能力向上支援をライフワークとし注力している。
