![HiPro [ハイプロ]](/themes/custom/persol_hipro/logo.svg){kind=logo}
テクノロジーを駆使した新たなサービス開発が求められる中で、スピーディかつ柔軟な開発を実現するワードとして、「DevOps」が着目されています。
当コラムでは、DevOpsの導入にあたり、概要やメリット、混同されやすいアジャイル開発との違いなどをご紹介します。
DevOpsとは？
はじめに、DevOpsとはどのようなものなのか、基本的な情報をご紹介します。
「DevOps」の概要
DevOps（デブオプス）は、システム（およびソフトウェア）の開発において、提唱された概念です。
具体的には、開発担当と運用担当が相互連携によって開発・運用を行い、システムの価値を、継続的に向上させることを指します。また、単にツールやテクニックといった技術的観点に留まらず、組織文化の醸成も含めた手法論ともいえます。
「Development（開発）」と「Operation（運用）」のワードを組み合わせ、「DevOps」という名称がつけられました。
DevOpsの誕生背景と重要性
DevOpsの原点となる考え方がはじめて提唱されたのは、2009年頃と言われています。
その当時、開発手法として「ウォーターフォール型（設計→テスト→運用…と、開発工程を段階的に分け、順序に沿ってシステムをつくる手法）」が主流だった中、DevOpsはより変化に対応できる画期的な考え方だとして、注目を浴びるようになりました。
「ウォーターフォール型」の特性と、特性によって生じる「対立構造」の切り口から、DevOpsが根付いた背景をもう少し詳しく見ていきましょう。
ウォーターフォール型の弱点
ウォーターフォール型は、開発からリリースまで段階的に工程を踏むため、各工程を同時進行で進めることができません。そのため、修正の規模や仕様変更によっては、工程の手戻りが大きく、莫大な時間をロスしてしまうリスクもあります。
開発側と運用側の対立構造
そもそも、ユーザーにシステムを提供するうえで重要視される事項は、「品質の高いシステムを、スピーディかつコンスタントに届けること」です。
しかし、この重要事項を達成しようと考えたとき、開発側と運用側では、担う方向性が大きく異なります（開発側の方向性は「システムに新たな機能を追加すること」、運用側の方向性は「システムを安定稼働させること」となる）。
新機能追加は、運用側にとって安定稼働をおびやかすリスクともなり得ます（例：新たなバグの発生など）。加えて先述の通り、有事の際工程の手戻りが難しい点から、運用側は新機能追加時、こと慎重にならざるを得ませんでした。そこで、有事のリスクを減らすため、安定稼働のための要件を十分に満たしているかを開発側に強く要求する構造が根付いていました。
しかし、この構造は結果として、先述の重要事項（品質の高いシステムを、スピーディかつコンスタントに届けること）の停滞にもつながる事態を招いていたため、従来のシステム開発における課題として認識されていたのです。
今後より早くビジネスの価値を高めるうえでは、開発と運用の連携および改善活動を行うことで解消できるのではないかとされ、DevOpsが提唱されました。
DevOpsのメリット・デメリット
メリット
開発スピードの向上
DevOpsは開発側と運用側のコミュニケーションを取りやすくするための組織づくりや、ツールによる作業効率化など、強固な連携体制・仕組みづくりに注力します。そのため、開発スピードが大いに向上するといえます。あわせて、ユーザーのニーズにも柔軟かつスピーディに対応できるメリットもあります。
システム安定性の向上
DevOpsは短いサイクルで繰り返し開発を行うため、不具合を見つけやすくなるメリットがあります。また、ツールなどの作業自動化によって、ヒューマンエラーを防げる点もメリットです。結果として、作業を着実に進行でき、システムの安定稼働にもつながります。
生産性の向上
DevOpsによって、ユーザーからのフィードバックを迅速に得られ、スムーズな仕様の改善につながります。また、開発側と運用側の連携が密になることで、より精度高くコミュニケーションを取ることができ、結果として無駄な作業の削減につながります。
ビジネス競争力の向上
DevOpsの体制によって、上述したメリットが生み出されますが、これらが間接的にビジネス競争力を生み出しているともいえます。とりわけ、ニーズの変容が早く、サービスの在り方にもスピーディな変化が求められる昨今、他企業に後れを取らないための手段としてDevOpsは有効的といえるでしょう。
デメリット
DevOpsは短期間での改修によって、迅速な開発を行う反面、スケジュールも流動的です。そのため、全体規模で厳密なスケジュール設計および管理を行うことが難しくなります。
アジャイル開発との違い
DevOpsの「短期間で開発サイクルをスピーディに回す」という特徴において、似たようなワードに「アジャイル開発」を連想される方もいらっしゃるのではないでしょうか。双方はたしかに似た特徴を備えていますが、そもそもの前提から相違しています。
先述の通り、DevOpsは、テクニックやツールなどの技術的観点に留まらない「概念（考え方）」を指します。一方、アジャイル開発はあくまでも、スピーディに開発を進めるための「開発モデル（技術的な手法）」です。
したがって、DevOpsとアジャイルは開発同環境下で両立し得るワードとなります。実際、DevOpsを導入するうえでアジャイル開発を導入しているケースも少なくありません。
DevOpsの導入方法
4つの文化を理解する
繰り返しとなりますが、DevOpsを浸透させるうえでは、組織の文化醸成も対象範囲のひとつとなります。DevOpsにおける文化の構成要素として、以下4つが重要視されています。
- Respect（尊重する）
- Trust（信頼する）
- Healthy attitude about failure（失敗に対して健全な態度を取る）
- Avoiding Blame（非難しない）
ヒューマンスキルとしても非常に基本的なこれらの要素は、開発側と運用側、相互のマインドに求められます。
開発手法を知る
・継続的インテグレーション
システムやアプリケーションの変更時、常時自動でテストすることを、継続的インテグレーション（CI：Continuous Integration）と呼びます。通常であれば、開発時のコーディング完了後、手動でテストを行うことが一般的ですが、ツールによって自動化することで、1日の内で何度も自動的なテストが可能となります。コードの不具合を素早く見つけることができ、スピーディかつ質の高いシステム開発を促進します。
・継続的デリバリー
コード変更が行われる度、自動的に本番環境へのリリース準備が実行される仕組みを、継続的デリバリー（CD：Continuous Delivery）と呼びます。こちらも手作業の工数を減らすことで、スピーディな開発促進と、確実性の高いソフトウェアのリリースを実現します。
・継続的デプロイ
最新の情報を自動的に本番環境へ反映する仕組みを、継続的デプロイ（CD：Continuous Deployment）と呼びます。継続的デリバリーと類似していますが、運用環境への更新時、手動で承認が必要か否かに違いがあります。継続的デプロイの場合、明示的な承認は行われず、自動的に本番環境へと反映されます。
・継続的フィードバック
後回しにしてしまいがちなフィードバック対応ですが、スピーディに改善を図るのであれば、工程として継続的に組み込むことは重要です。アンケートやSNSでのコメントなど、コンスタントにエンドユーザーの声を拾いながら、定例会で振り返りやアクション検討などを行うのも、方法のひとつです。
・継続的モニタリング
システムに不具合がないか、継続的に監視する仕組みを指します。本番環境のモニタリングに使用するツールと同ツールを開発環境にも導入し、本番前にパフォーマンスの問題を検出します。
役立つツール例
仮想化ツール
ソフトウェアによって複数のハードウェアを統合し、1台のサーバーを複数のサーバーのように使用できるツールです。
インフラ管理ツール
インフラの構築や運用監視作業などを自動化できるツールです。
CI／CDツール
先述のCI、CDを自動化できるツールです。
タスク管理ツール
DevOpsの対象となるメンバーの各種タスクについて、進捗確認や割り振りなどを可視化・一元管理するツールです。
コミュニケーションツール
チャットツールなど、メンバー間で迅速なコミュニケーションを促すツールです。
バージョン管理ツール
データの作成者や変更者、変更日時などの基本的な情報確認や、過去の状態を復元するツールです。
まとめ
DevOpsは開発スピードを加速させる考え方であり、バズワードとなっているDXの推進にも役立つといえます。有用性はたしかなものである一方で、組織の在り方そのものを問いかける必要があるため、メンバーへの理解を求めることも必要となります。その観点でも、DevOpsを浸透させる際は「何のためにDevOpsを実行するのか」と、目的を共有しながら進めることが重要といえるでしょう。
