１　DevOps誕生の背景

時代が平成から令和にかわりオリンピックイヤーを迎えた2020年。国内では景気回復の兆しはあるものの、消費増税などの影響で内需は冷え込み、モノやサービスが思うように売れない時代。海外でも米中貿易摩擦、新型コロナウイルスの出現による今後の世界経済への影響は計り知れず、先行きの不透明感は増すばかりである。

そんな情勢の中、チャールズ・ダーウィンが残した「生き残るのは変化に適応したものである」の言葉通り、企業はあらゆる変化を柔軟に受け入れ、素早く対応できる能力を備えることを求められている。市場での競争力を確保するためにはIoTやAI、ロボティクス技術導入などのDX対応を急ぎ、ITを競合他社との差別化の切り札、競争力の源泉として有効活用することが重要となっている。

総務省「令和元年版情報通信白書」によると企業の情報化設備投資額も年々増加の傾向にある。2017年は前年比+5.4％増の12.6兆円に達しており、リーマンショック以前の高水準に迫る勢いである。設備投資全体に対する情報化投資比率も15.1％を占め、これに近年普及が著しいクラウドサービスの利用を含めると、実質投資額はさらに高い数値になると推測される。

これらの現実を踏まえたとき、企業のIT部門が担う使命が極めて重大であることはもはや言うまでもない。経営層はIT部門に対し、他社に先駆けて新サービスをリリースできる柔軟性とスピード感を備えることを強く期待する。日々刻々と変化する顧客のニーズに対し、企業ITは従来よりもはるかに短いサイクルで新サービスを開発し、リリースする仕組みを備えねばならない。

リリース速度を上げるためには開発期間の短縮、本番リリースの高速化が必要だが、ここで問題になるのが開発部門（Dev）と運用部門（Ops）の対立である。新サービスを少しでも早く世に送りたい開発部門とシステム安定稼働を最優先に考える運用部門。両者が求める理想の姿はトレードオフの関係にある。

この問題を解決する概念がDevOpsである。DevOpsという言葉は2009年にカリフォルニア州サンノゼで開催されたVelocity2009のイベント会場で初めて用いられた。DevOpsはソフトウエア開発に革新をもたらす開発手法ではなく、開発ツールの総称でもない。開発者と運用担当者が共通の目標を定め、その目標に向かってお互いに協力することでサービスリリースの柔軟性とスピードアップを実現するためのフレームワークである。

どのような方法で開発（Dev）と運用（Ops）が相互理解を深め、トレードオフの関係を解消し、開発のスピードを生み出すのか。DevOpsの詳細について以降で詳しく説明する。

２　DevOpsの概要

A）DevOps導入の目的

DevOpsが関心を集め始めた当初は開発現場主導による導入事例が多かったため、開発と運用の連携による"開発プロセスの効率化"が導入目的とされることが多かった。DevOpsは単なる開発スピードアップのためのツールと認識され、ツールの導入が目的化しているケースも多く見受けられた。

後に長い歳月を経て、DevOpsに対する認識は大きく変化し、目的を明確にした導入事例も徐々に増えている。私はDevOps導入の本来の目的を次の３点と捉えている。
・開発への顧客ニーズのフィードバック
・迅速なサービス提供、ビジネスの差別化
・市場での競争力の確保

DevOpsが有効に機能し、本来の目的を成し遂げるには、DevOpsの技術的概念やツール、および文化的概念について理解し、組織の関係者がそれを実践していくための環境を整備する必要がある。

B）Devops実現のための技術的概念

DevOpsを実現するための様々な技術的概念が存在するが、ここでは一般的な六つの概念について取り上げる。

（1）アジャイル開発

ウォーターフォール開発に代表される従来型開発手法よりも軽量でフレキシブルな開発が可能。ユーザとの対話を重視し、ドキュメントよりも実際に動くソフトウエアに価値を置いている。アジャイル開発を発展させたものがDevOpsであり、DevOps実現にアジャイル開発は不可欠な技術的要素である。

（2）マイクロサービス

マイクロサービスは2014年に米国のマーチン・ファウラー氏によって提唱された。
従来型サービスは一枚岩の巨大なアーキテクチャとして構成されているため、些細な変更に対しても影響範囲が大きくなる。これに対してマイクロサービスは小さなサービスの組み合わせで全体が構成されるため、影響が局所化され、ミニマムかつスピーディな開発を可能とする。

（3）継続的インテグレーション（CI）

開発者が新たに書いたフィーチャーコードをマスターコードに頻繁に統合する仕組み。
一度のマージ量を少なくし頻繁に統合することで、マスターコードは常に最新化され、問題が起きた時の原因の切り分けも容易になる。CIシステムはコード統合の際、自動的に一連のテストも実施するため、問題箇所の早期発見も可能となる。

（4）継続的デリバリー（CD）

CIによるテスト自動化をさらに発展化させて、ソフトウエアを常に本番リリース可能な状態に管理するための仕組み。
類似する言葉として継続的デプロイ（CD）がある。継続的デリバリーが本番リリース可能な状態を維持するのに対し、継続的デプロイは本番リリース完了状態を維持する。この二つの概念に明確な区分けはなく、同義として扱われることも多い。

（5）インフラストラクチャー自動化

DevOps実現にあたってはインフラも同様に短期構築・リリースが求められる。インフラ構成管理、構築や運用における日常的タスクを自動化することで人為的ミスが回避され、インフラサービスの安定運用が可能となる。
従来は機械操作で行っていたインフラ作業をプログラムコード化することで、ソフトウエア的な発想でインフラの管理を行うことも可能となる。これをIaC（Infrastructure as Code）と呼ぶ。

（6）コンテナ

一つのOS上で隔離された複数個のアプリケーション環境を構築する技術。サーバ仮想化と似ているが、仮想化は仮想マシン単位でOSを立ち上げるため、資源をより多く消費する。コンテナは仮想マシンと比較して資源消費が少なく、無駄なオーバーヘッドもかからないため、高速起動が可能となる。
コンテナを使うことで、運用管理者はバージョンの異なる複数の開発環境を極めて容易に構築することができる。

以上、Devopsの六つの技術的概念について取り上げたが、ポイントとなるキーワードについて図でも整理しておく。（図表1）

【図表1：変化のスピードに対応したITの進化】

C）Devops実現のためのツール

DevOpsの実現をサポートする様々なツールが存在する。要件に合ったツールを選定してうまく活用すれば、DevOps導入の本来の目的
・開発への顧客ニーズのフィードバック
・迅速なサービス提供、ビジネスの差別化
・市場での競争力の確保
を達成するための強い味方となる。

DevOpsツールはシステムのライフサイクル全般で利用されている。主に利用されているツールについて簡単に説明する。

（1）ビルド：BUILD

ソースコードや開発成果物のバージョンを管理するツール、発生バグの修正から解決までを管理するツールなど。

（2）インテグレーション：INTEGRATION

継続的インテグレーション（CI）を実現するツール（プロビジョニング機能を装備した構成管理ツール、自動テストツール）など。

（3）デプロイ：DEPLOY

継続的デプロイ（CD）を実現するためのツール（リリースダッシュボード、自動デプロイツール）など。

（4）オペレーション：OPERATION

サーバおよびアプリケーションの稼働監視ツール、インシデント管理ツール、運用状況共有ツールなど。

（5）フィードバック：FEEDBACK

エンドユーザからのフィードバック情報を収集し、サービスの改善に結び付けるためのツールなど。
これ以外に開発と運用の関係者間でのCHATコミュニケーションツールも、DevOpsツールとしてよく利用されている。
DevOpsでツール活用は不可欠だが、ツールの導入がゴールとなり、本来の目的を見失うことのないよう注意が必要である。

３　DevOpsの文化的概念

A）重要なのは組織文化の形成

最後にDevOpsの文化的概念について説明を行う。DevOps導入における失敗やミスリードは多くの場合、"開発部門と運用部門の問題だ""DevOpsは自動化ツールだ"などのような残念な誤解から生まれるケースが多い。DevOpsの技術的な側面を深く理解し、ツールを使いこなしたとしても、組織の壁の撤廃や本番リリースの高速化は容易には達成できない。

最も重要なのはサービスリリースに関わるすべての関係者（ソフトウエアの品質管理部門やサービス企画・開発部門など）を巻き込んだコミュニケーション強化だ。全ての関係者がお互いの仕事を尊重し、相手を深く信頼し、ミスに対して非難をしないような組織文化を作り上げる。これがDevOpsを成功に導く秘策であり、同時に大きなハードルでもある。

B）DevOps導入時の留意点

DevOps導入に際して、失敗やミスリードを極力起こさないよう、留意すべき事項は次の３点である。

（1）ステークホルダの巻き込み

開発と運用だけに限らず、サービス開発には様々な部門が様々な立場で関わっている。
ソフトウエアが超高速リリースを繰り返すことに対し、品質・セキュリティ管理部門は決して無関係ではいられない。企画部門や営業部門も含めて、サービス開発に関わるすべてのステークホルダを巻き込んでコミュニケーションを図る必要がある。

また最近のトレンドとしてソフトウエアの脆弱性検査がリリース高速化の足かせとならないよう、開発（Dev）と運用（Ops）にセキュリティ部門（Sec）を加えた"DevSecOps"の概念も主流になりつつある。従来は後工程で実施していた脆弱性検査を自動化し、DevOpsに組み込むことでセキュリティ検査後に発生する大幅手戻りの抑止を狙いとするものである。

（2）導入目的の共有

開発の現場主導でDevOpsの導入を進めると、その主たる目的が"現場業務の効率化"に傾倒し単なるツール導入に終始してしまう場合が多い。これを避けるには"サービスリリース高速化による顧客価値創出"などのように導入目的を明確に定義し、ステークホルダも含めた関係者全員でその目的と目標達成度合いを共有しながら進めていくことが重要だ。

特にステークホルダが多い場合は取り組みが道半ばで終わらないよう経営陣も巻き込んだ推進体制を構築し、コミットメントを得ながら進めていくのが望ましい。

（3）互いを尊重しあう組織文化

DevOpsの導入は従来の業務を大きく変える革新的な試みである。作業の不慣れからミスを起こしてしまう可能性も高い。

開発（Dev）と運用（Ops）が互いに協力し合わなければ、DevOpsを成功させることは到底難しい。お互いに些細なミスや誤りがあっても寛大に受け入れ、決して非難をしないことが大切である。これは開発と運用だけの問題ではなく組織全体が"非難のない文化"を創り出すことの重要性にもつながる。

顧客にビジネス価値を提供するために、組織が一丸となって改革を進める。DevOpsの本質的な価値は、そこに存在している。

#論文#運用#開発

この記事をシェアする

この記事はいかがでしたか？