「DevOps」とは？　アジャイル開発と運用を支える組織力

システムが生みだす価値を最大化するための「DevOps」

デジタルトランスフォーメーション（DX）を目指す企業が知っておくべき、新しいプロセスやテクノロジーについて解説する本連載。第2回のテーマは「DevOps」です。

「DevOps」とは、端的に言えば「ITシステムが生みだすビジネス上の価値を高め、その価値を確実にエンドユーザーに届けられるようにするために、開発チーム（Development）と運用チーム（Operations）が継続的に連携し、組織文化を一体化していく取り組み」を指します。この取り組みの中では、システム開発手法としての「アジャイル」と同様、Continuous Integration（CI、継続的開発）と、Continuous Delivery（CD、継続的導入）が基本的な考え方となり、開発だけでなく運用の領域でも、さまざまなツールや手法を活用して「自動化」を推進していきます。

企業がビジネスを展開する上で不可欠な存在となってから、ITシステムは既に数十年が経過しており、その重要性は現在進行形で高まり続けています。ビジネスにとって、ITシステムは「あれば便利」なものから「なくてはならない」ものになり、今では、その使い方の巧拙が「企業の競争力」を直接左右するものになっていると言えます。

DXは、最新のテクノロジーやシステムをうまく使いこなしながら、変化するビジネス環境へ対応し、市場に新しい価値を提供し続けられるよう、組織を変革していく取り組みです。そこで多くの企業は、DXの推進に十分な人材や予算を充てられないという問題に直面しています。経済産業省の「DXレポート」でも、IT人材が社会的に不足している中、多くの企業では、既存システムを維持するための保守や運用に、膨大なリソースが投入されており、それが貴重なIT人材の“浪費”につながっていると指摘されています。

その状況を変えるために必要なのは、生みだすビジネス価値が相対的に低い既存システムの維持からIT人材を解放し、経営に寄与する価値を生むDX領域へとシフトさせていくことです。企業のIT組織が「DevOps」を実践できるようにしていくことは、DX領域に投入できるIT人材を増やすという観点でも、メリットがあると言えます。

「DevとOps」に分断したプロセスは何が問題なのか

前提として、従来のシステム開発・運用のやり方に、どのような問題が出てきているのかを整理しておきましょう。従来の一般的なシステム開発・運用プロセスは、設計／開発／テストを行う「Dev（開発）」と、システム運用を行う「Ops（運用）」に分かれます。この「Dev」と「Ops」は、完全に分断されています。そのため、開発が完了すると開発チーム（Dev）は、成果物や運用手順書を運用チーム（Ops）に渡し、運用チームは「受け入れ判定」を行って、そこをDevとOpsの「責任分解点」としていました。

このやり方において、運用チームに求められるのは、開発チームから提供された手順書に忠実に従って運用作業をすることです。そのため、運用チーム自身は、開発されたシステムに対する判断が行えず、不具合対応やエンハンスのための修正が必要になった場合には、開発チームに作業依頼を行う必要があります。そして、その修正は、やはり設計／開発／テストのプロセス後に「受け入れ判定」を行うことで適用されるため、結果として、リリースされるまでの時間が長くなってしまいます。

従来の大規模システムのように、初期リリース後、短期間で修正や改善を行うことを前提としないシステムでは、こうしたやり方での開発運用でも大きな問題にはなりません。しかし、技術の進歩や市場環境の変化が加速するに従い、この方法ではユーザーニーズやビジネスニーズの変化にITシステム側が対応していくことが難しくなります。ユーザーやビジネスの要求は短期間で変化することを前提に、より短期間で継続的にITシステムの修正や改善を行うための開発・運用のやり方として「DevOps」が求められるようになってきているのです。

• 従来の一般的な開発・運用プロセスの問題点（出典元 Ridgelinez）

なぜ「Dev」と「Ops」は別れたのか－業界的な事情

では、そもそもなぜ、従来は「Dev」と「Ops」が分断された状態になっていたのでしょうか。それは、金融システムのようにミッションクリティカル性が極めて高く、リリース時点で完全な機能と運用を要求され、ミスが許されないようなシステムの開発・運用に成功した体験が、多くの開発会社で踏襲されてきたことが大きいと考えます。

このやり方を他のシステムでも踏襲し、品質と機能が過剰な「完全な」システムと運用手順書を運用チームに引き渡すといったことが続けられてきた結果、「開発人材」と「運用人材」に求められるスキルセットが異なる状況が成立しました。

要件を実現するための設計およびコードやロジックを試行錯誤し、検討することが求められる「開発人材」に対し、運用人材には「定められた手順に従うこと」が、第一に求められてきました。また、勤務条件（トラブル時のデータセンターアクセスを視野に入れた地理的制約、深夜／休日勤務等）が開発人材とは異なり、求められるスキルセットも違うことから、開発人材との相対的な賃金格差も発生します。結果として、運用については「外部発注」を行うことが、特に大手のITベンダーでは主流となっています。

こうした背景もあり、運用を主に担うチームでは、最先端のデジタル技術を扱える人材が育ちづらく、運用改善のモチベーションも上がりにくいといった状況が多く見られます。その結果、技術的負債（※注1）の保守・運用にリソースを割かざるを得なくなり、ITベンダーの多くはシステム運用に伴う「人月商売」の受託型業務から脱却できない事態にもつながっています。

（※注1）技術的負債（Technical debt）：短期的な観点で開発したシステムが陳腐化し、結果として、長期的に保守・運用の負担が増大する状態。

新興サービス提供事業者から多くの企業に広がる「DevOps」

前述のとおり、「Dev」と「Ops」が分かれた体制においては、専任の運用チームを抱え、24時間365日の対応体制を確保し、手順書ベースのマニュアルオペレーションでシステム運用を行うというスタイルが主流になっていました。

しかし、創業時からネットサービスを中核事業とするような、いわゆる「ネットベンチャー」などと呼ばれる新興サービス提供業者では状況が違っていました。創業直後で潤沢な資金や人材がそろっていない彼らは、専任の運用体制を確保することも困難です。とはいえ、サービス品質を低下させるわけにはいきません。

新興サービス提供業者の多くでは、開発者が運用者を兼任しています。そして、夜間休日対応の負荷や運用にかかるコストを削減すべく試行錯誤した結果、徹底的な「自動化」を取り入れることで、コストの圧縮と利益率の向上を実現しています。

新興サービス提供業者では、開発者が運用もケアするため、開発者にシステム全体を俯瞰した観点やスキルが求められます。必然的に「フルスタックエンジニア」となり、先端IT人材の育成が進むことにもつながっています。

加えて現在、より多くの企業で「DevOps」の採用が進んでいる背景には、ITシステムのインフラが、技術の進歩によって「物理」から「仮想」へ転換していることも理由に挙げられます。オンプレミス主流の時代における「運用」は、物理サーバが設置されたデータセンターでの作業が必須であり、地理的制約を受ける形で運用チームを構成する必要がありました。しかし、仮想化技術をベースとした「クラウド」のようなITインフラの活用が一般的になるのに従い、地理的制約を受けずにAPI（Application Programming Interface）ベースでのオペレーションが可能です。これに関連して、運用手順書をプログラムの「コード」に置きかえ、運用プロセスの属人化を避けながら自動化を進める「Infrastructure as Code」のようなコンセプトも発展してきています。このような技術的な変化も、DevOps促進の一助になっていると考えられます。

DevOpsとの「相性が良い」アジャイル

それでは、ITシステムの開発・運用が「Dev」と「Ops」に分かれているIT組織は、すぐに「DevOps」に移行すれば良いのかといえば、必ずしもそうではありません。

「DevOps」と相性が良いのは、「市場や環境の変化が多く、それらに対応するために頻繁なリリースが必要になることが見込まれるシステム」です。こうしたシステムにDevOpsを適用することで、システムのリリース後も、求められる追加要件を、迅速にシステムに取り込み、運用も柔軟に適合させていくことができます。このことは、とりもなおさず、変更を柔軟に取り込むことができる開発手法である「アジャイル」が必要になることを意味します。具体的な例としては、消費者や顧客とのコミュニケーションや購買のチャネルとなるようなアプリケーション、業務現場で日常業務やワークフローの効率化ために使われるようなアプリケーションなどが挙げられるかもしれません。

一方で、「最初から作るべきものが決まっている」かつ「市場や環境の変化に影響を受けず、一度リリースした後は、ほぼ改善や拡張の必要性が見込まれない」システムは、従来の「Dev」と「Ops」に分かれた体制の方が良いと言えます。運用後のシステムに手が入らず、開発へのフィードバック頻度も低い。つまり、「Dev」と「Ops」が連携すべき機会が少ないシステムであれば、「DevOps」の必要もないわけです。

• 図２ 従来の一般的な開発・運用プロセスの問題点（出典元 Ridgelinez）

以前であれば「極めて高いミッションクリティカル性が求められる基幹システム」などが、こうしたシステムの例として挙げることができたのですが、その状況も変わってきています。現実問題として「市場や環境の変化に影響を受けないシステム」というものは、今後、存在しなくなると思われます。各業種や業界の基本的なビジネスモデルのような「変わらない」とされてきたものが、デジタル技術によって破壊される「デジタルディスラプション」は、現在、さまざまな領域で進行しています。不確実性が高い「VUCA」（※注2）が恒常的になっている世の中では、どのようなシステムであっても「変化」を前提とした開発・運用のあり方が重要になると考えられます。

（※注2）VUCA：「Volatility（ボラティリティ：変動性）」「Uncertainty（アンサートゥンティ：不確実性）」「Complexity（コムプレクシティ：複雑性）」「Ambiguity（アムビギュイティ：曖昧性）」の頭文字を並べた略語。ビジネスにおいて、不確実性が高く将来予測が困難な状況であることを示す。

マネジメント視点での推進 が「DevOps」導入をうまく進めるポイント

ここまでで「DevOps」が、「ITシステムの生みだすビジネス価値を最大化し、確実にユーザーに届けるため、変化へ柔軟に対応できる開発・運用のプロセスを作っていく取り組み」であることがお分かりいただけたかと思います。これはマネジメントの視点から見れば、IT組織に新しい体制と文化を作っていく、組織変革の取り組みでもあります。決して、何らかの「DevOpsツール」を導入することで、即座に実現できるものではありません。

これを理解した上で、DevOpsを導入していこうとしている企業に必要なのが、ITベンダーとの契約やプロジェクトの推進方法についての精査です。「Dev」と「Ops」が分断された体制で、費用を抑え、あらかじめ定義されたオペレーションのみを実施するような人月方式の受託型業務を行うITベンダーからは、DevOps実践の提案は期待できません。それは、そのベンダー自身のこれまでのエコシステムを破壊することになるからです。

このため、委託する企業側からも、ITベンダーに対してDevOpsを実践できるような変化を促し、そうした変化を受け入れるITベンダーをパートナーに選定していくことが重要です。そして、ITベンダーにすべてを丸投げするのではなく、自社に配置したIT人材で、パートナーとの関係をうまくドライブしていくことが必要になります。

DXを本格的に展開するためには、DXの基盤として、変化に迅速に対応できるITシステムが必要不可欠です。「DevOps」を通じて、迅速に高頻度なシステムリリースを行い、市場への価値提供を継続させることが求められます。

経営層は、そのための取り組みを、ビジネスにおける新規顧客の獲得や機会損失抑止に寄与するものと捉え、既存システムの保守業務から最先端のIT技術分野に人材と資金をシフトさせることを目的とした、人材投資を進めていくべきでしょう。

DXの推進や、その重要な構成要素である「DevOps」の導入を、現場のIT部門だけに任せず、人材投資の必要性を経営課題として認識すること。自社人材の育成に加えて、外部からの高度先端IT人材の採用も含めて戦略的な施策として計画、投資を進めることが、組織の変化を促すための大切なポイントになります。