DevOps は「手法」か？

DevOps は手法と言われることもありますが、「継続的な価値の提供」という共通の哲学に基づいたプラクティス、考え方、方法論のセットと捉えるほうが適切です。分かりやすく言えば、DevOps に汎用的なアプローチはなく、どのような状態になれば DevOps が成功したと言えるかは組織によって大きく異なります。

GitHub は、DevOps 組織向けのツールを設計し、一流のチームや企業と仕事をしています。その中で GitHub は、DevOps を導入するときに経験する一般的な問題をいくつか特定しました。

このガイドでは以下の質問に回答を提供します。

DevOps は手法ですか、それともプロセスですか。
DevOps の目的は何ですか。
組織はなぜ DevOps を導入しているのですか。
どうすれば上手く DevOps に移行できますか？
DevSecOps も導入している企業がありますが、なぜですか。

DevOps は手法か、それともプロセスか

10 人の人に DevOps とは何かと尋ねれば、異なる答えが少なくとも 5 つは返ってくるでしょう。DevOps の実践的な実装である継続的インテグレーション/継続的デプロイやテストの自動化などを根拠に、DevOps はプロセスだと言う人もいるかも知れません。DevOps は、首尾一貫した原理に基づき連携する一連のプロセスを伴う手法だと言う人もいるかも知れません。

GitHub の DevOps の定義を確認する >

しかし、上記の定義はどちらも大事なポイントを見落としています。DevOps は、導入する企業に応じて調整できる一連のプラクティスで構成されているという点です。

GitHub では、DevOps は、ソフトウェアを通じてどのように価値を提供するかを検討するためのフレームワークとして理解したほうがよいと考えています。DevOps は、単なる一つの手法でもプロセスの寄せ集めでもありません。DevOps は基本的にプラクティスのセットであり、文化的なプラクティスと技術的なプラクティスの両方が含まれています。それでは、詳しく見ていきましょう。

DevOps をフレームワークとして理解する

何十年にもわたり、ソフトウェア開発ライフサイクルのそれぞれの段階の機能を細かく定義した概念が広く支持されてきました。しかし、優れた理論に見えても、実際にはなかなかそのとおりにはならないものです。なぜなら、組織はそれぞれに違うからです。

DevOps はこの点を認識しています。DevOps は、細部まで規定するのではなく、一連のプラクティス、文化的な考え方、ツールを統合し、特定のチームや組織のニーズに応じて変更可能なフレームワークに沿って運用します。

原則として DevOps では、より質の高いソフトウェアをできる限り迅速にエンドユーザーの手に届けることを目指します。継続的に価値を届けるという目標は、組織が DevOps を成功させるうえで欠かせないものであり、次の 3 つの方法で達成されます。

継続的な改善: 小さな変更はより簡単に管理できるうえ、時間がかかりがちな大規模なリリースよりも迅速にユーザーに価値を提供できます。DevOps のプラクティスでは、継続的な改善とは、反復的な変更を迅速にリリースすることを意味します。さらに、将来の変更を通じて基盤となるソフトウェアを改善する方法や、ソフトウェア開発ライフサイクルそのものを改善して迅速な価値の提供を支援する方法を模索することも意味します。
** 当事者意識の共有:** 製品に携わる全ての人が、自身の専門分野だけでなく、製品とその品質についても説明責任を分担します。これはつまり、エンドユーザーに提供する最終製品について、全員が説明責任と当事者意識を共有することを意味します。
自動化: DevOps プラクティスでは、自動化できるものはすべて、ソフトウェア開発ライフサイクル全体にわたって自動化し、新しいリリースを通じてエンドユーザーにより迅速に価値を届けます。自動化は、ヒューマンエラーが起こる可能性を最小限に抑えながら、製品構築のための時間を最大化するのにも役立ちます。

DevOps とアジャイルなど他の手法との違い

アジャイルやエクストリームプログラミングなどの開発手法は、従来のプログラミングとウェブ経由のソフトウェア配信との衝突を解消しようとした動きでした。

これらの考え方が普及する以前に最もよく使われた開発手法の一つが、極めて逐次的なウォーターフォール手法です。ウォーターフォール手法では、一つのステップが完了するまで次のステップに進めませんでした。つまり、多くの事務処理を行い、綿密に計画を立ててからでなければ、一行のコードすら書けなかったのです。

McKesson では、16 か月で、30 以上のサイロ化したソフトウェアエンジニアリンググループが、全体で広く団結した 1 つのチームになりました。

McKesson デベロッパーサービス & テクノロジーラボ、バイスプレジデント Denis Canty 氏

アジャイルソフトウェア開発の原則の考案者は、過度な計画策定はソフトウェア開発者の創造性を削いでしまうこと、稼働するコードなしには、計画が適切かどうかさえ誰にも分からないことを認識していました。「アジャイルソフトウェア開発宣言」ではたとえば、動くソフトウェアのほうが過剰な文書化よりも重要だと述べています。変化に迅速に対処することのほうが、計画に固執することよりも価値があったのです。

実際、「アジャイルソフトウェア開発宣言」の背後にある概念は画期的でした。顧客のニーズを理解し、それに応える最良の手段は、動くコードであると認識していたのです。しかし、コードに焦点を当てるということは、ソフトウェア開発ライフサイクルの他の側面にはあまり触れていないということでもありました。

アジャイルを古い慣習への反動とするならば、DevOps はアジャイルの中核的な概念を発展させたものであり、それらの概念をソフトウェア開発ライフサイクル全体に適用したものです。事実、2010 年代初めには DevOps はアジャイルの第 2 の 10 年とも呼ばれていました。

DevOps とアジャイルの違いは、中核となる考え方を比較すると理解しやすくなります。

フェイルファスト vs. 継続的改善: アジャイルでは小規模で迅速なイテレーションが重視され、失敗はプロセスが機能している証拠であるため容認されます。DevOps では、リリースの速度とソフトウェアの品質を向上させるため、ソフトウェア開発ライフサイクル全体にわたりイテレーション、自動化、密接な共同作業が重視されます。
開発者中心 vs. チーム中心: アジャイルでは、どうすればソフトウェア開発者が顧客のニーズに最適に応えられるかに焦点が置かれますが、コードのテスト、デプロイ、メンテナンスの方法についてはほとんど検討されません。一方、DevOps では、ソフトウェア開発ライフサイクルに携わる全ての人が協力し合い、エンドユーザーに価値を届けるための責任を全員で共有します。
機能 vs. システム思考: アジャイルでは特定の機能の「現在の状態」に着目するのに対し、DevOps ではソフトウェアをシステムとして総合的に捉えます。
プロジェクト重視 vs. 製品重視: アジャイルは、ソフトウェア開発によりプロジェクト重視のアプローチを採用し、大規模なリリースを実行可能な小さな作業単位に分割します。一方、DevOps では、ソフトウェアをより製品中心の視点から捉えます。個々のプロジェクトから全体的な製品に焦点を移し、すべの意思決定において、その決定が長期的なシステム全体に及ぼす影響を考慮します。

DevOps の目的

DevOps の目的は、ソフトウェアの開発方法をクラウドでのソフトウェアの使われ方に合ったものにすることです。クラウドの登場によって、個別のサーバー、ソフトウェアのリリース日、役割別のサイロといった障壁の時代は終わり、ソフトウェアにどこからでもアクセスできるオープンな世界が訪れました。

これまで、ソフトウェア開発には明確に区別されたステージが存在し、工場の生産ラインのように最終製品が存在しました。これは一理ありました。物理メディアの時代には、ソフトウェア開発ははるかに厳格で直線的なプロセスだったからです。結局のところ、最終的なリリースは実際ある意味、終点でした。アップデートを配布するということは、直線的な生産プロセスの振り出しに戻ることを意味したからです。

しかし、今日のソフトウェア開発ライフサイクルは生産ラインではありません。クラウドベースのテクノロジーやプラットフォームにおける SaaS (サービスとしてのソフトウェア) などの技術革新によって、明確な個別のリリースはパンチカードや部屋サイズの計算機と同じくらい時代遅れになりました。

それでは、DevOps はどのようにしてソフトウェア開発ライフサイクルをクラウドで求められる常に稼働、常に最新という状態に近づけるのでしょうか。

ソフトウェア開発ライフサイクル全体を通した共同作業: 単発のプロジェクトの観点から考えるのではなく、DevOps ではソフトウェア開発ライフサイクル全体にわたって包括的な製品中心の視点を採用します。具体的には、従来のソフトウェア開発の厳密な役割分担を排除し、代わりに製品の成功に対し継続的に責任を負う部門横断型のチームを優先するということです。全ての人が自身の専門領域にかかわらず、ソフトウェアの品質、セキュリティなどの側面について説明責任を負います。
ソフトウェアの品質の向上: DevOps のどの側面も、その目的はより質の高いソフトウェアを作ることです。自動テストとセキュリティチェックは、問題を本番環境に持ち込まないようにするのに役立ちます。継続的改善と継続的インテグレーション/継続的デプロイなどのプラクティスは、バグ修正などのアップデートがエンドユーザーに迅速に届けられることを保証します。マイクロサービスなどのアーキテクチャを採用すれば、特定のサービスにおける問題の影響を最小限に抑えながら、リアルタイムの需要に迅速に対応できる分散システムを容易に構築できます。
より迅速なソフトウェアリリース: DevOps では、すばやく構築でき、コーディングが簡単で、テストの対象範囲が狭く、本番との開きが小さく、デプロイ時に意図しない結果を招くことの少ない、小規模で反復的な変更が奨励されます。これはアーキテクチャの選択にも影響する場合があり、マイクロサービスアーキテクチャを採用することで、システムを部分的にアップデートする際のリスクを制限する組織もあります。

DevOps が必要な理由

かつて、ソフトウェアを公開するということは物理的なメディアを配布することでした。市販のパッケージソフトを使うにせよ、オフィスの端末を一つひとつシステム管理者がアップデートするにせよ、ソフトウェアリリースには事前の計画が欠かせませんでした。

製造スケジュールや発売日に基づきソフトウェアが開発されていた時代には、ウォーターフォールのような逐次的な手法が当然適していました。しかし、そうした手法の厳格さには代償が伴いました。リリース日が決まっているため、納期に間に合わなければ製造は開始されず、出荷もされず、小売店の棚は他社の製品で穴埋めされることになりました。ソフトウェアメーカーは高いコストをかけて質の高いソフトウェアをゆっくりリリースするか、納期に間に合うように品質を犠牲にするかのどちらかしかありませんでした。

GitHub を採用して、何もかも劇的に変わりました。共同作業、共有、コミュニティ——すべて GitHub のおかげです」

Autodesk Build プラットフォーム部門シニアディレクター、George Swan 氏

Web ベースの配信に移行したことで、チームはそうしたジレンマから解放されたはずです。しかし多くの企業や技術チームは、固定のリリース日を想定して組織されており、ツールやプロセス、チーム構造も従来のソフトウェア開発リリースモデル向けのものでした。品質を高め、ユーザーにより迅速に価値を届けるチャンスを逃していたのです。

しかし、ウェブがもたらした変化はそれだけではありません。突如として、セキュリティがこれまでになく重視されるようになったのです。品質とは、もはや単にバグを発見することではなく、インターネット経由のあらゆる悪意のある攻撃者からデータを保護することも意味するようになりました。

ソフトウェア開発は変革を余儀なくされました。DevOps に行きつくまでの過程は、ウェブ経由のソフトウェア配布と、ソフトウェアの作られ方との間に生じた摩擦への反動でした。

DevOps は、最新のクラウドアプリケーションの特性に合ったソフトウェア開発のフレームワークを提供します。もはやスピードやコストと引き換えに品質を犠牲にする必要はありません。

組織が DevOps を導入する理由

世界中の組織が DevOps を導入しているのは、より信頼性の高いソフトウェアをより迅速にリリースできるからです。DevOps の成功は、その柔軟性によるところが大きいです。DevOps は抜本的な改革を押し付けるのではなく、それぞれの組織の事情に応じた調整が可能であり必要でもある、さまざまな文化的プラクティスや技術的プラクティスを提供します。

しかし、個々の実装が企業によって異なるとしても、DevOps の導入に成功した組織は、多くの共通の恩恵を享受しています。これらには以下が含まれます。

共同作業によって品質が向上する: DevOps 環境で働くメンバーは、全員が製品の成功に対し利害関係を共有しています。個人の仕事は、担当するタスクが完了した時点で終わるのではなく、コードが本番環境で稼働してはじめて終わります。そしてその時点でも、コードをどう改善するか検討する余地があります。つまり全員が、ソフトウェア開発ライフサイクル全体を通して継続的に協力し合い、いかにして品質を継続的に改善し、エンドユーザーにより速く価値を提供するかを考えています。
自動化によって不確実性が減る: DevOps ではできる限り自動化することが促されます。その結果、ソフトウェアとソフトウェアを実行するインフラストラクチャの構築や改善に、より多くの時間を費やせるようになります。また、コード変更の統合やリリースの自動化を可能にする継続的インテグレーション/継続的デプロイなどの主要なプラクティスによって、デリバリーパイプラインの高速化も支援します。
継続的な測定によって継続的な改善が促進される: DevOps 環境では、多くの場合、ツールを用いてソフトウェア開発ライフサイクルの各ステージを測定、監視し、システムの状態、リアルタイムの需要、個々の変更の影響について迅速にフィードバックを提供します。DevOps 実行者は、その情報をもとにプロセスを改善したり、データに基づき変更を加えたりします。
品質の向上: DevOps 実行者は、リリースするソフトウェアの品質の改善に継続的に努めます。この取り組みは、部分的には自動化によって達成され、その結果テストやセキュリティチェックの一貫性が向上します。また、予期せぬ結果が生じるリスクを減らしつつ、簡単に構築、配信、管理できる反復的なリリースやコード変更によっても達成されます。また、開発と運用など、これまでサイロ化されていたチームによるソフトウェア開発ライフサイクル全体を通した共同作業も、DevOps プラクティスにおいてソフトウェア品質を高めるうえで重要です。
より迅速なリリースサイクル: DevOps は、より迅速に作成、テスト、デプロイできる小さなコード変更を優先することによって、組織がより高い品質で、より迅速に運用環境に価値を投入できるように支援します。また DevOps は、ソフトウェア開発ライフサイクル全体で自動化を使用し、計画の策定からコーディング、テスト、本番稼動へと価値を導く CI/CD パイプラインを作成することを奨励しています。

DevOps を組織に導入するには

DevOps の導入を成功させるには、いくつかの大きな変化が必要になる場合もあります。しかし、一夜で全てのプロセスやツールを作り直すわけではなく、比較的小さなステップから始めることができます。その際には、開発チームがコードを統合する頻度に文化的な変更を加えたり、組織のソフトウェア開発ライフサイクルの細かい部分を自動化したりする必要があるかも知れません。

DevOps の取り組みのどの段階にあるかに関わらず、DevOps の導入を成功させるためは 6 つの重要なステップを実行する必要があります。

文化を変える: DevOps の成功は、製品の構築、テスト、運用、リリースを担当する全ての人が緊密に連携することから始まります。そのためにはまず、ソフトウェア開発ライフサイクルの全てのステージにおいて、全員が団結し、協力し合うようにしなければなりません。これは、異なるチーム間に役割ベースのサイロが存在する組織にとっては大きな変化かも知れません。DevOps プラクティスでは、より質の高いソフトウェアをより迅速に顧客に提供するために全員が一丸となります。そのためには、さまざまな人が緊密に協力し合い、運用環境での稼働用にコードが最適化され、ソフトウェアの実行用に運用環境が最適化されるよう徹底しなければなりません。
インクリメンタルな構築に重点を置く: DevOps では、顧客に迅速に提供できる小さな変更が好まれます。これは機能を分解して、簡単にテストでき、バグの影響を最小限に抑え、運用環境にできるだけ迅速にリリースできる小さな塊にすることを意味します。DevOps では、開発者が新しいコードを 1 日に何度統合すべきかについて厳格なルールは存在しません。しかし、高い成果をあげている DevOps プラクティスでは 1 日に複数回コード変更を統合し、リリースしています。
適切なツールを採用する: DevOps では、ツール導入に万能なアプローチは存在しません。事実、「DevOps ツール」はちょっとした総称であり、数多くの製品やプラットフォームがこのカテゴリーに分類されます。適切なツールを選び、適切な DevOps ツールチェインを構築するには、まず、解決したい問題と投資の必要な DevOps 機能を特定する必要があります。しかし、一般的にツール導入が必要となる領域は数多く存在します。これには、次のステップが参考になります。
可能な部分はすべて自動化する: 最も優秀な DevOps 環境では、ソフトウェア開発ライフサイクルを批判的な目で評価し、コードの統合、テスト、パッケージ化のような反復的なタスクなど、自動化を適用して人間の介入の必要性を排除できる部分を探します。反復的なタスクを自動化することで、より有効に時間を使えるようにしたり、ヒューマンエラー (テストを実行し忘れる、正しいライブラリをインポートし損ねる、など) のリスクを減らしたりします。一般的な経験則として、DevOps プラクティスでは、自動化できるものはすべて自動化すべきです。

私たちのチームにはこんなスローガンがあります。「人間に機械の仕事をさせるな。そのためには GitHub を活用せよ」。

Blue Yonder チーフソフトウェアエンジニア、Gabriel Kohen 氏

CI/CD パイプラインを構築する: DevOps 自動化の最も一般的な例の一つ、継続的インテグレーション/継続的デプロイは、ソフトウェア開発ライフサイクルの各ステップに自動化を適用し、より質の高いソフトウェアをより迅速にエンドユーザーに提供できるよう支援します。たとえば、開発者がプルリクエストを出すと、メインのブランチに問題が持ち込まれないように一連の自動テストがトリガーされる場合もあります。このプルリクエストがマージされた場合、CI/CD パイプラインは自動化を活用し、新しいソフトウェアバージョンの構築プロセスを開始するかも知れません。CI/CD パイプラインは、組織のニーズに応じてそれぞれ異なったものになるでしょう。しかしその目的は、ソフトウェア開発ライフサイクルにできる限り自動化を適用して、ソフトウェアの品質を向上し、デプロイまでの時間を短縮することです。
測定と調整: 成功する DevOps 文化では改善の機会を探し求めます。非効率なプロセスを特定するには、ソフトウェア開発ライフサイクルのスピードだけでなく、アプリケーションとシステムの両方のパフォーマンスを監視することが極めて重要です。優れたメトリクスは、製品に携わる一人ひとりが自身の仕事をより大きな全体の一部として捉え、自身の加えた変更が他の部分にどのような影響を及ぼすかをより簡単にイメージできるようにします。

DevOps 導入時の一般的な課題

DevOps への移行を開始する前に、移行の際に組織が直面する一般的な課題を認識しておく必要があります。これらには以下が含まれます。

ツールのみで文化が欠落している: ツール導入は、多くの場合、DevOps の最も可視的な側面です。しかし、共同作業、説明責任の共有、継続的な改善を重視する文化を取り入れなければ、ツールの効果が限定的なものになってしまう可能性があります。
古いサイロを新しいサイロと入れ替えただけ: 最も優れた DevOps 環境は、役割ベースのチームを緊密な部門横断型の共同作業に置き換えます。よくある失敗は、DevOps のツール、プラクティス、プロセスの管理者として機能する DevOps 専門チームを作ることです。このやり方は、古い障壁を新しい障壁に置き換えてしまう危険性があります。
レガシーシステムが DevOps モデルに合わない: 古いシステムやアーキテクチャと新しいツールの統合には、高いコストがかかる場合があります。たとえば、旧式のモノリスシステムの構築時間は、1 日に何度も構築を繰り返すことになる継続的インテグレーション/継続的デプロイシステムにとっては非現実的かも知れません。

DevOps の導入は少数の小さな変更から始まり、ソフトウェア開発ライフサイクルの全てのステージが DevOps フレームワークに適合するまで発展を続けます。その後も、改善の機会は常にあります。

DevSecOps への移行

DevOps は一連のプラクティスとして常に進化しています。現在最も明白な進化の一つが、DevSecOps への移行を通じて起こっています。DevOps は本来、本番環境でのコードの動作について説明責任を共有することを目的としていましたが、DevSecOps はそれを発展させ、コードのセキュリティについて全員が責任を負うことを目指します。

ネットワークで接続されたこの世界では、ソフトウェアセキュリティが不可欠です。DevSecOps は、ソフトウェア開発ライフサイクルの全てのステップにセキュリティを組み込むための堅牢なプロセスを確立します。DevSecOps は、DevOps の継続的改善の概念を応用し、セキュリティの改善を、ソフトウェア開発ライフサイクルのできるだけ早い段階に開始される継続的なプロセスに変えます。

DevSecOps は、セキュリティをソフトウェア開発ライフサイクルが左から右に流れる中で、その開始点のできる限り近くまで——つまりできる限り左に——前倒しします。セキュリティは設計ステージから始まり、コードが本番環境に一切デプロイされないうちから、静的アプリケーションセキュリティテストなどのツールによって脆弱性の有無が自動的にチェックされます。ソフトウェア開発ライフサイクルの早い段階でセキュリティを考慮するというこの考え方は、しばしばシフトレフトと呼ばれます。

詳細は、DevSecOps、シフトレフト、GitOps のガイドをご覧ください >

GitHub で DevOps プラクティスを構築する

GitHub は、集中的な開発者体験と強力なフルマネージド型の開発、自動化、テスト用インフラストラクチャを一体化させ、アイディアから計画、構築、本番稼動まで一貫して支援する統合プラットフォームです。

料金プランを比較する >

DevOps ソリューションを比較する >

既存のツールとすぐにインテグレーションできるのが、GitHub の大きな魅力です。GitHub は DevOps の実現を強力に後押しします。

P&G アジャイル & DevOps リード、Danilo Suntal 氏

計画から構築へ	開発の速度を上げる
プロジェクトと完全に統合した優れたプロジェクトボードとテーブルを使用して、コードベースのすぐ隣でロードマップ計画を作成し、チームメンバーにタスクをすばやく割り当てましょう。 GitHub Issues について知る >	コミットまでの時間を短縮しましょう。開発者の環境管理やコンテキストスイッチングをなくし、クラウドの安全なマネージドスペースにより、IT 調達とメンテナンスを簡素化しましょう。 Codespaces について知る >

すべてを自動化	コード作成時のセキュリティを確保
----------	----------
GitHub Actions で全てのソフトウェア開発ワークフローを自動化しましょう。GitHub のフルマネージド型の強力な開発、テスト、自動化インフラストラクチャにより、信頼性と安全性を高めることができます。 GitHub Actions について詳しく知る >	ソフトウェア開発ライフサイクル全体を通じて、コード、依存関係、トークン、極秘データのセキュリティを確保し、脆弱性を自動で解決します。 GitHub でどのようにセキュリティを確保できるかを知る >