公式資料
「デジタルオペレーションの現状」独自調査レポート
エンジニアの燃え尽きを防ぐ秘訣とは?
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説!→ PagerDutyの資料をみる(無料)
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。
しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。
また、「開発スピードが上がらない」「安定した運用が難しい」といった悩みを抱えたエンジニアがいるかもしれません。DevOpsは「開発担当者と運用担当者が密に連携することにより、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。
DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に解き明かしながら、DevOpsの考え方をご紹介します。
また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどについてDevOpsを実践する2社の事例を交えて解説します。
目次
「DevOps」は、開発(Development)と運用(Operations)という言葉の組み合わせによる造語で、「デブオプス」と読みます。
DevOpsという概念を端的に説明すると、システムやソフトウェアの開発・運用の両担当者が密に連携し柔軟でスピーディーな開発と運用を実現するという考え方やその方法論になります。
現代の市場におけるニーズの変化の激しさ、そしてお客様・ユーザーのデジタルサービスに対する期待度の高まりを背景に、それに即したスピードでの開発が求められます。例えば、企画からリリースまでに数年かかってしまうと、その間にユーザーのニーズは変化し市場に受け入れてもらえないリスクが上がります。
一方で、スピード重視で開発した結果、仕様の不備や問題点が多いようであれば、それもまたユーザーに受け入れてもらえないということが発生します。
つまり、開発するシステムやソフトウェアはユーザーが求めるレベルの高品質なサービスであることも重要です。こうしたスピード感のある開発と高品質なサービス提供を両立するために注目されているのが、DevOpsという考え方です。
システム開発における「スピードと品質の両立」と「開発部門と運用部門の一体化」がどのように関係するのか疑問に思ったり、アジャイル開発との違いが気になったりする方がいるかもしれません。
これらの疑問は、「DevOpsの誕生の歴史」や「その他開発手法との関係性」を知ることで理解が深まると思います。
2000年代以前は、システム開発工程を段階的に区切って一つずつ順番に進めていく「ウォーターフォール開発」が主流でした。
この方法はスケジュール管理がしやすく、工程ごとの品質管理で高品質な開発を実現しやすいことが特徴です。
しかしその後、著しい技術進歩やニーズの多様化が進むようになり、ユーザーのニーズはより短期間で変化する時代になります。そのため、ウォーターフォール開発における仕様変更の難しさや開発の長期化が大きな課題となっていました。
そこで、2000年代初頭に誕生したのが「アジャイル開発」という開発手法です。アジャイル開発では、実装とテストを小さな単位で繰り返して全体の開発期間を短縮し、プロダクト価値の最大化をめざします。
ところが、アジャイル開発でも期待したようなスピード開発には至らないケースが少なくありませんでした。開発チームが短期間のうちにコードを作成しても、品質を確保するために運用チームでのデプロイに時間を要してしまうからです。
この事態はITシステム業界における課題となり、さまざまな会議やコミュニティで議論が交わされました。そのなかでエンジニアたちは、開発チームと運用チームのサイロ化が問題であるととらえたのです。
そして、「スピーディーなシステム開発と運用の実現には、開発チームと運用チームの密な連携が必要だ」という認識が高まり始めます。この認識は、その後2009年にFlickrのエンジニアによるプレゼンテーションをきっかけにして、「DevOps」という用語とともに広く認知されるようになりました。
このように、「DevOps」と「アジャイル開発」は歴史的なつながりがあるものの、異なる概念を持ちます。DevOpsは「開発と運用の密な連携が重要だ」という点に重きを置いており、企業文化にも深く関わる思想の一つです。一方でアジャイル開発は、開発プロセスや方法を具体的に定めた開発手法の一種といえます。DevOpsの人気は現在も高まり続けており、中小企業やスタートアップから大企業まで規模や業種を問わず、さまざまな企業が導入を進めています。
DevOpsには画一的な方法論がなく、いざ企業が自社に取り入れようとした際に戸惑ってしまうかもしれません。ここでご紹介したいのが、DevOpsの考え方を実践するための指針となる4つの原則です。
1.ソフトウェア開発ライフサイクルの自動化
2.コラボレーションとコミュニケーション
3.継続的な改善と無駄の最小化
4.ユーザーニーズの重視とフィードバックループの最短化
この4つの原則について、1つずつみていきましょう。
DevOpsでは、自動化によって一日に何度もコードをリリースするようなレベルでの開発の高速化を可能とします。ここではDevOpsにおける代表的な自動化への取り組み内容を紹介します。
CIとは、プログラムの不具合を早期に発見して修復するために、クラスやモジュールなどすべての要素を対象としたテストを自動化する仕組みを指します。
これにより、新しいソースコードの変更が定期的に自動でビルドおよびテストが実施され、共通のリポジトリに統合されます。
CDとは、アプリケーションに変更があった際にも継続的にユーザーに提供できるように、検証済みのコードをリポジトリに自動でリリースする仕組みを指します。
コード変更のマージからビルドのデリバリーまで、それぞれの段階に必要なテストとコードリリースを自動化することで、運用チームがアプリケーションを本番環境にすぐにデプロイできるようにします。
IaCとは、サーバーをはじめとしたシステムのインフラ構築を、コードを用いて行なうことです。これにより、インフラ環境のインストールや設定を自動化できます。
DevOpsの実現は、開発担当者や運用担当者をはじめとしたチームが一体となり、協力できるかどうかが大きく影響します。
同じ企業において異なる目的や役割を持つ開発担当者と運用担当者とのコラボレーションを実現するために、既成概念にとらわれない考え方を受け入れる文化の醸成や、定期的にコミュニケーションを取る仕組みなどを整えることが大切です。
DevOpsでは、継続的に改善することや無駄を最小化することに注力します。そのためには、開発環境を定量的に評価できる環境を整えることが大切です。
KPIやそれに紐づく評価指標(パフォーマンスメトリクス)、例えばデプロイの頻度やリリース時間、変更障害率、平均復旧時間(MTTR)などを設定し、測定するようにします。これにより改善が必要な箇所を特定し、対策の効果を検証できます。
また、著しい技術進歩をはじめとした変化の激しい環境において、このような改善活動は一度実施すれば良いものではありません。継続な取り組みとして実施し続けることで、大きな成功に結びつきます。
DevOpsでは、ユーザーのニーズを中心に開発を進めます。しかし、ユーザーのニーズを的確にとらえて、心に響くサービスを提供するのは容易ではありません。
ユーザーのニーズやサービスへの反応を確認するためには、「ユーザーを開発プロセスの中に参加させること、すなわち、ユーザーの生の声を開発プロセスに積極的に取り入れること」が重要です。
また、収集したユーザーからのフィードバックを開発に取り入れることはもちろん、そのニーズが変化しないうちに提供する必要があります。そのためフィードバックループを短くすることが求められます。
現代は、デジタル化が急速に進みユーザーのニーズは短期間で絶え間なく変化するようになりました。
企業はユーザーのニーズに応えるため、その変化に対応し、サービスと価値をスピーディーにユーザーに届けることが求められています。
しかし、従来のような企業におけるサイロ化した組織構造では、コミュニケーションや意思決定、プロセスの推進に時間を要します。例えば、開発チームが品質をスピード重視で開発を進めた場合、運用チームにおける品質確保に時間がかかってしまいます。
どちらのチームも、本来は価値の高いサービス提供を目的としているにも関わらず、役割や責任範囲が異なることで対立構造のようになってしまいます。これでは、品質の高い高速開発は困難です。
そこで、DevOpsの開発チームと運用チームの一体化という考え方が重要になります。
DevOpsでは、同一のエンジニアまたはチームが、開発スピードと品質確保の両面の責任を負います。DevOpsの原則に従った取り組みは、高速開発のためでもあれば、バグを減少させてサービス運用を安定させるためでもあります。
これにより、個々の業務を超えて、サービスの立案から提供まで全体での最適化を図ります。このように、スピードと品質の両立が求められる現代において、それを実現し、大きなビジネス価値を迅速に提供できる考え方としてDevOpsが注目されています。
DevOpsを実践して開発や運用を行なう場合、大まかに8つのステップに分かれたプロセスにしたがってライフサイクルを回します。
DevOpsの実践とは、このライフサイクルを継続的に回して行くことです。ここではDevOpsのライフサイクルを構成する各ステップについて解説します。
計画は、DevOpsのライフサイクルにおける最初のステップです。開発プロジェクト全体の進め方を立案し、開発チームと運用チームが協力して要件定義を策定します。
その際、ユーザーや運用部門からのフィードバックなどを取り入れると製品の品質向上に対し大いに役立つでしょう。加えて、プロジェクト全体の進捗を管理し、常に情報を共有できる体制の整備も行ないます。
次に、計画段階で策定した要件定義に沿って、プログラマーがソースコードを作成します。作成したソースコードに対して、単体テストやコードレビューによって、何度も修正作業が発生します。
その際、複数人が同一のソースコードを別々に修正することもあるため、ソースコードのバージョン管理が非常に重要です。その解決策として、バージョン管理ツールなどを利用することが一般的です。
ソースコードのコーディングが完了したら、そのコードから実際に動作可能なアプリケーションを作成します。前述した継続的インテグレーション(CI)と継続的デリバリー(CD)によって、ビルドからテスト、リリースまでを自動的に実施することが可能です。
ビルドしたアプリケーションに不具合がないかを確認するためにテストを行ないます。実際にアプリケーションを動かしてバグや不具合を発見するたびに改修する「デバッグ」作業は、ツールを用いて自動化・省力化することが可能です。
自動テストで発見・改修できないバグや不具合は手動で対応するほか、セキュリティテストなども実施して品質を確保します。
作成したアプリケーションはいくつものテストを経て、新たなバージョンとして完成となります。この際、リリースを管理するツールを用いると、必要に応じて古いバージョンに戻すこと(ロールバック)が可能です。
リリース後に不具合が発見された場合には、ロールバックして改修したのち、再びテストを行なって不具合を解消します。
リリースされたアプリケーションを本番環境に移行することをデプロイと呼びます。先述したインフラのコード化(IaC)により、本番環境へアプリケーションをデプロイします。
これにより、ユーザーは実際に開発されたアプリケーションにアクセスすることが可能となり、本番環境でアプリケーションが実際に動作することの確認が重要です。
ビルドからデプロイまでの工程はツールを用いて自動化することにより、開発フェーズにかかる工数を短縮させることが可能です。
本番環境にデプロイされたアプリケーションが継続的に動作するように、サーバーやネットワークといったインフラストラクチャの保守・管理を行ないます。
また、サービスを利用するためのデバイスが正常に動作することの確認も欠かせません。この段階で問題が発生した場合には、保守チームが迅速にインシデントを特定し、改修やメンテナンスを実施してシステム全体への影響を最小限に抑えることが重要です。
アプリケーションやシステムが正常に稼働していることを常に監視してその動作状況や、ユーザーからの意見を収集して継続的にフィードバックします。
これにより、高品質なサービスレベルを維持することが可能です。監視を自動化して、異常が発生した場合には即座に通知することにより迅速な対応が可能となり、修正版をリリースするまでの時間を短縮することができます。
また、このフィードバックをもとに新たなリリースの計画を立てることによって、DevOpsのライフサイクルを継続的に回して行くことが可能です。
DevOpsの導入は、開発現場においてさまざまなメリットを期待できます。企業がDevOpsを導入することで得られる代表的なメリットを解説します。
DevOpsはアジャイル開発から派生した考え方であるため、多くの場合、アジャイル開発をベースとした開発の進め方をします。
DevOpsでは、開発担当者と運用担当者が一体となり協力することで、アジャイル開発の利点である開発スピードの向上をより実現しやすくなります。開発スピードの向上はユーザーへの迅速なサービス提供を実現するだけでなく、開発期間を短縮し開発コストの圧縮にもつながります。
DevOpsでは、原則にあるように無駄を省いて自動化を推進し、改善を続けます。また、利便性の高いツールなどを活用し、開発担当者と運用担当者の連携を推進します。このような一連の取り組みにより、業務効率化が進み生産性が向上します。
DevOpsの原則に沿った取り組みは、サービス品質の向上にもつながります。例えば、自動化の推進はヒューマンエラーのリスクを低減します。また各種テストの自動化は、勤務時間に依存せず常にテストを実施できる環境を整えバグの早期発見につながるでしょう。フィードバックループの最短化も、ユーザーからのサービスへの評価を早い段階で開発に取り入れることに役立つため、ニーズに対する理解を深めより適切な仕様検討に結びつきます。
さらに、DevOpsによるリリースサイクルの短縮化や継続的な学習によって、監視の自動化による不具合の早期発見や、迅速な対応による平均復旧時間の短縮化などが実現可能です。
このようにDevOpsにおける各種取り組みは、サービスにおける不具合を解消することを通じてユーザーにとってのサービスの魅力をより磨くことにつながります。
前述したように、DevOpsではIaC(インフラのコード化)と呼ばれる手法を用いて、インフラ環境をコードで構築し、ソフトウェアを使って管理します。
そのため、インフラを開発プロセスと統合して、整合性を取りながら効率的に管理・運用することが可能です。例えば、IaCではインフラストラクチャやサーバーが標準化され、迅速にデプロイできるようになります。
また、パッチの適用やバージョンの更新といった作業は自動化できるため、より簡単にシステム構築や管理ができるようになるといえます。
DevOpsで導入されるCI(継続的インテグレーション)では、ソフトウェアのコードが変更されるたびにビルドされ、テストが実施されます。その際、各種セキュリティ標準に基づいたチェックも行なわれます。
そのため、DevOpsは迅速なソフトウェア開発を可能としながらも、セキュリティをも確保できるような仕組みとなっています。
DevOpsには多くのメリットがあるものの、開発内容への向き不向きや導入のハードルもあります。ここでは、企業がDevOpsを取り入れる際に事前に知っておきたい注意点を解説します。
DevOpsは概念であるため、開発の方法が明確に定められているわけではありません。しかし、歴史的な背景からDevOpsは基本的にアジャイル開発と同様の手順を踏みます。
特に、少人数チームでの密なコミュニケーションの実施や柔軟性のあるスケジュール管理が前提となっている点に注意が必要です。
そのため、多数のエンジニアが参画し、厳密なスケジュール管理で多くの機能を一度に開発するような開発への導入には注意や工夫が必要です。
例えば、大規模開発には従来のウォーターフォール開発のほうが効率的な可能性もあります。開発内容や体制を考えて、最適な開発手法を選択しましょう。
多くの日本企業では、従来のウォーターフォール開発が中心となっており、DevOpsを導入する際には開発の進め方やチーム体制の変更をともなうことがあります。
しかし、開発の過程においてミスをしないことを重視する傾向から、新たな取り組みや技術を導入しにくいといった状況があることも事実です。
そのため、変化を受け入れづらい企業文化では導入への反発や非協力的な態度など、プロジェクトそのものの失敗につながるリスクを抱えやすい側面があります。DevOpsでは、開発におけるミスは継続的な学習の一環である、ととらえる姿勢が大事です。
ここまで見てきた点を踏まえて、DevOpsの導入や実践におけるポイントを2つご紹介します。
DevOpsは、一部の手法や関連するツールを取り入れれば簡単に実現できるというものではありません。部門のサイロ化を解消することが重要であり、そのためにはDevOpsの文化を企業の中で根付かせる必要があります。
そして、DevOps文化を根付かせるためには「トップダウンでの推進」と「ボトムアップでの取り組み」の双方を同時に行なうことが効果的です。例えば、組織体制の再編や運用プロセスの変更などをトップダウンで推進することで、DevOps導入のベースとなる環境整備を効率的に進められます。
また、プロジェクトチームを立ち上げて現場での実践的なノウハウを得ることは、その企業に合わせたDevOpsの導入と実現を考えるうえで役立つといえるでしょう。
DevOpsは、CI/CDやIaCといった手法を活用し、あらゆる面で自動化をめざすことから、自動化に向けたツールの導入・活用も欠かせません。
しかし、単独でDevOpsのすべての原則に対応できるようなツールはなく、またツールによって機能は異なります。開発のフェーズや体制などにおける自社の課題を明確にし、適切なツールを選びましょう。
ツールの導入においては、KPIや評価指標での評価が可能な環境を整えておくことも大切です。より効果的にツールを活用できるように、利用方法の改善へと継続的に取り組みましょう。
ここでは、DevOpsを実践するうえで役立つヒントを得られる国内外2社の事例を紹介します。
Netflixは動画配信サービスを提供し、世界的に成功を収めている現代を代表するテック企業の一つです。また、ご存知の方も多いかと思いますが、大規模にDevOpsを効果的に実践している企業でもあります。
Netflixでは、多様で変化の激しいユーザーの要求に対応しながら、数多くの動画コンテンツを遅延などの不具合なく世界中のユーザーに配信しています。これは当たり前のことのように感じるかもしれませんが、容易に実現できることではありません。
そして、こうした偉業を実現している背景にはDevOpsの存在があります。Netflixには、さまざまなDevOpsにおける取り組みがありますが、なかでも有名な取り組みの一つが「Chaos Monkey」です。
Chaos Monkeyとは、Netflixが独自に開発した人為的に障害を発生させるツールで、日々エンジニアの開発を邪魔します。エンジニアはこのツールによって、否応なしに障害対応に巻き込まれるのです。
その結果、エンジニアは開発に集中できる環境を取り戻すために、より障害に強いシステム開発に取り組んだといわれています。
また、この障害対応の訓練により、実際に大規模なシステムの再起動が必要になった際にも問題を乗り越えられたとされています。Netflixが実践するDevOpsの詳しい事例については、こちらの記事「先進的なDevOpsを実践する6社のケーススタディ」もぜひ参考にしてください。
株式会社NTTデータは、世界中でITサービスを提供する日本を代表する企業の一つです。同社のサービスの一つに、日本の決済シーンを支える決済サービスの事業があります。
現在はオンラインショッピングやコンビニなど、昼夜問わず買い物ができ支払いの瞬間が生じる時代です。そのため、決済サービスは生活に密接した事業であり、24時間365日の安定したサービス提供と正確な取引が求められます。
こうしたミッションクリティカルな事業における高い可用性と信頼性の実現のために、NTTデータはDevOps体制で決済サービスの開発に取り組んでいます。
そうしたDevOps体制に取り組むなか、同社では「システム障害につながりうるインシデント対応に時間がかかること」や「インシデント対応の質」が課題となっていました。
保守・運用の一環であるインシデント対応が非効率であれば、開発にかけられる時間が減ることにつながります。
そこで、インシデント管理ツールを導入してインシデント管理の半システム化・半自動化を進めた結果、インシデント対応の迅速化やヒューマンエラーの解消に成功しています。
インシデント対応をはじめとした運用・保守面での自動化の推進は、業務負荷や人件費削減だけでなく、運用に特化したチーム体制である必要性もなくします
。これは組織のサイロ化を解消し、DevOpsを実現するうえで重要なことといえます。NTTデータが取り組むDevOps体制に関する事例詳細については、PagerDutyの事例紹介ページ「NTTデータ様事例」を参照してください。
また、市場が激しく加速的に変化していくなかで、「変化に素早く適応し、磨き続ける能力」「新たな価値を創造し、確かに実現する能力」を新たに獲得すべく同社が取り組む「Digital CAFISによる変革プログラム」について、2023年に開催したPagerDuty Summit Japanでご紹介頂いた講演についても以下からご視聴いただけます。
「Digital CAFIS特区による組織・人材・ビジネスプロセス・システムの変革ストーリー」株式会社NTTデータ 加藤 大樹 氏 – PagerDuty Summit Japan 2023
ここまでご紹介してきましたように、DevOpsは開発チームと運用チームの一体化により、スピード感のあるビジネスの革新や価値の創造をめざす考え方といえます。そのため、DevOpsの実践においてエンジニアは開発と運用の両方の役割を担うことになります。
慣れない仕事を担うことになり、高い業務負荷を感じるエンジニアもいることでしょう。そのため、DevOpsの導入においてはエンジニアの負担軽減が欠かせません。
そうしたエンジニアへの負担とその影響として特に留意したいのが、システム障害などのトラブルが発生した際に保守作業で手が一杯になり、開発が滞ることです。
DevOpsの本来の目的を達成するためには、エンジニアを付加価値のあるビジネス開発に注力できるようにする必要があります。
そのため、DevOpsの実践においては保守作業の効率化も欠かせません。PagerDutyはインシデント対応やシステム障害対応といった保守作業を効率化し、開発に注力できる環境を実現するインシデント管理プラットフォームです。
ITSMツールやコラボレーションツールなど700を超えるツールと連携が可能であり、アラートノイズの低減や問題の自動診断と修正といった強力な機能で、多量のアラート通知や繰り返される手作業からエンジニアを開放します。
これらを通じて、PagerDutyを用いることでインシデント対応プロセスの効率化、そして企業のDevOpsを協力にご支援することが可能です。PagerDutyの活用や効果については、こちらの事例ページもご覧いただき、ご不明点があればぜひお気軽にお問い合わせください。
PagerDuty公式資料
独自調査レポート「デジタルオペレーションの現状」
エンジニアの燃え尽きを防ぐ秘訣とは?
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、最新の顧客アンケート調査結果と19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基に、システム運用の”今”を解説!
→ PagerDutyの資料をみる(無料)
ダウンロード資料
https://www.pagerduty.co.jp/resources/
14日間 無料トライアル
https://www.pagerduty.com/ja/sign-up/
エンジニアの燃え尽きを防ぐ秘訣とは?
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説!→ PagerDutyの資料をみる(無料)
目次