DevOps モデルとは? DevOps の基礎となるプラクティスを探求する

DevOps モデルとは

DevOps モデルとは何かとよく聞かれますが、この質問は DevOps の論点から外れています。DevOps は開発ライフサイクル全体に関わるソフトウェア構築のアプローチです。これは、エンドユーザーに継続的に価値を提供することを目的としたプラクティス、文化、テクノロジーの組み合わせです。

つまり、DevOps には、全てのケースに適合する 1 つのアプローチはありません。導入は組織ごとに異なります。それでも、DevOps には全組織がさまざまな形態で活用するプラクティスのフレームワークがあります。

Proctor & Gamble がどのように DevOps で成功を収めたかを確認する

DevOps の導入はそれぞれ異なり、企業のビジネスニーズによって決まります。Proctor & Gamble がどのように DevOps をビジネスに活用したかをご覧ください。

詳細情報 >

DevOps の中核には、製品を担当する全員が統一されたチームとして協力すべきであるという考え方があります。開発、品質保証 (QA)、セキュリティ、運用の各サイロで別々に作業するのではなく、DevOps は、ソフトウェアの計画、構築、提供、改善に向けてエンドツーエンドの責任を担うユーザーを連携させます。

DevOps の仕組みは企業ごとに異なります。ただし、DevOps の導入に成功している組織には、3 つの核となるテーマがあります。

品質について全員が責任を負う

DevOps はソフトウェア開発チームに存在する分野間の障壁を排除します。実行者はサイロ化された段階的なプロジェクトを完了するのではなく、エンドツーエンドの製品の構築に集中する傾向があります。これは、製品の計画から構築、テスト、デプロイまで、ソフトウェア開発ライフサイクル全体にわたって同じ個人が協力することを意味します。

準備が整い次第コードを発送する

従来のソフトウェア開発プラクティスでは、多くの変更を大規模なリリースにバンドルすることがよくあります。つまり、顧客は通常、ソフトウェアのアップデートをより長い期間待つことになります。また、大規模なコード変更がもたらす影響を予測することが難しくなり、開発チームや運用チームに大きなプレッシャーをかけることになります。一方、DevOps では、ビルドとテストが容易で、準備が整い次第すぐに出荷できる、段階的なコード変更が好まれます。開発者がコード変更をプロジェクトにコミットすると、継続的インテグレーションと継続的デプロイ (CI/CD) ツールにより、自動テスト、アプリケーションのビルド、コードインテグレーションや問題の報告が促進されます。多くの DevOps 実行者は継続的な改善の概念を各自の作業にも適用し、時間をかけてプロセスを測定および調整します。

自動化によって品質と予測可能性が向上する

成功する DevOps プラクティスでは、自動化できるものは全て自動化します。これにより、人為的なミスのリスクが低減し、製品を拡張しやすくなります。ツールはインフラストラクチャの構成とデプロイを自動化するために使用され、静的分析ツールはセキュリティの脆弱性を見つけて示します。DevOps 実行者はあらゆるステージで反復タスクの自動化に努めています。

DevOps 運用モデルとは

プログラミングチームがコードを記述し、テストチームがバグを見つけて、運用チームがインフラストラクチャを担当するという従来の開発方法と比べると、DevOps は抜本的な変化のように感じるかもしれません。プラクティスとして、DevOps は基本的に SDLC のあらゆる部分にわたり従来はサイロ化されていたチームをまとめることによって組織の変革を目指しています。

困難に感じるかもしれませんが、小規模な変更から DevOps のジャーニーを開始できます。どこから始めるべきかを確認するために、DevOps の運用上の影響についていくつか見ていきましょう。

私たちの哲学は、将来の企業のために自動化と優れた DevOps をビルドすることです。

Adobe、シニア SCM エンジニア、Todd O'Connor 氏

文化

ツール導入は、多くの場合、DevOps の最も可視的な側面です。しかし、DevOps は、専門知識と責任についての考え方を変えることを意図した文化的な転換から始まります。

開発、テスト、運用などの従来のソフトウェア開発の役割を考慮します。この役割は、製品全体ではなく、狭い定義での責任とプロジェクトの観点から考えることを奨励しています。

たとえば、コードの記述とその実行が区別される場合、コードを記述するユーザーは自分の作業をどのようにデプロイしやすくするかや、需要の増加に合わせてより堅牢にするかを考える傾向が減少します。大規模な組織では、プログラミングチーム、QA チーム、運用チームがお互いを知らない可能性があります。

DevOps 文化では人と製品に重点が置かれます。製品を提供する責任を同等に共有する個人に明確な役割があり、そのソフトウェアで生産の問題が解決されるまで誰の仕事も終了しません。

DevOps 文化が発展するために、組織は次の 3 つの原則に従います。

自律性: チームメンバーを妨げずに誰もが自分の役割を遂行するために必要なものを備えています。
透明性 情報の流れが DevOps の通貨です。監視やインスツルメンテーションなどの自動化されたコミュニケーションと、問題提起の偏りの両方を通じて、DevOps 文化は非効率性を表面化して解決するのに役立つフィードバックループを構築します。
継続的改善と学習: DevOps 文化では、修正または機能はそれぞれ、より優れた作業方法を見つける機会であり、個人が成長する機会です。共有の文化は、時間とともに組織全体がより効果的になることを意味します。

プロセスよりも人を優先することで、DevOps は、可能な限り最良の製品を構築できるように、システムが個人のために機能する文化を作り出します。また、狭い専門分野だけでなく、開発ライフサイクルの各部分を実践的に理解することで、各要素が次の要素にどのように影響するかを理解できます。このインサイトはソフトウェア開発ライフサイクル全体の摩擦を減らし、より考えられた仕事につながります。

チームの構造

DevOps 以外の組織では、アーキテクトと開発者、開発者とテスターや運用の専門家が厳格な役割のサイロによって区別されています。ある週から翌週までいくつかのプロジェクトで作業したとしても、各自の作業が終了したときに行われる内容に関与することはありません。

DevOps はプロジェクトと役割から、製品と人に焦点を移行します。計画から開発、生産に至るまで、同じ個人やグループが製品を担当します。目標は、開発者と運用の専門家の間から障壁を取り除き、専門化が可能なエンドツーエンドの視点を持つ「エンジニア」に置き換えることです。肩書きは組織によって異なりますが、ソフトウェア製品を構築する環境が、明確に区分けされた作業の役割と一致することはほとんどない、というのが基本的な考え方です。

製品中心の視点を持つことで、DevOps は実行者を顧客のニーズに近づけ、コンテキスト切り替えの高いコストを節約し、問題を迅速に解決する俊敏性を提供します。

プロセス

DevOps では、継続的で協力的な改善を可能にするプラクティスが、従来のソフトウェア開発の慎重に練った計画、官僚主義、広範囲に及ぶリリースに取って代わります。

特に DevOps 組織は次を優先するプロセスとプラクティスに従います。

段階的な変更: DevOps チームは大規模な統合されたリリースではなく、小規模で頻繁な変更に取り組み、段階的な価値を本番環境に早期にプッシュし、計画、開発、テスト、デプロイをより簡単に行います。
継続的な改善: 段階的な変更は、手作業に頼るのではなく、テストに合格するとすぐに自動化によって統合、構築、デプロイされます。

ツール導入

ツール導入は DevOps 文化とプロセスの実践的な現れであり、ソフトウェア開発ライフサイクルのあらゆる部分に関連します。DevOps では、多くの場合ツールを使用して可能な限り自動化を採用し、フィードバックループを作成して、組織のリソースを解放します。

DevOps ツールは主に 4 つのカテゴリーに分けられます。

バージョン管理: ほとんどの開発チームは何らかの形でソースコード管理を使用しますが、DevOps では Git のようなバージョン管理ツールが基盤となっています。
継続的インテグレーションとデプロイ: GitHub Actions などの CI/CD ツールは、コード変更のビルド、テスト、デプロイの自動化に使用され、通常は Git コミットによってトリガーされます。
Infrastructure as Code: Azure ARM などのツールは、仮想マシン、コンテナ、サーバーレスコードの管理と拡張をプログラムで実行し、リアルタイムの需要に対応するために使用されます。
監視: テストツール、監視ツール、レポート作成ツールは、システムのパフォーマンスと稼働時間を把握し、フィードバックループを作成してサービスを改善するために使用されます。

DevOps モデルのメリットとデメリット

DevOps の価値は世界中の何千ものソフトウェア開発組織で証明されています。Microsoft の Enterprise DevOps Report によれば、DevOps のエリート組織は、他の組織よりも 4～5 倍速くコードを出荷しています。

しかし、組織で DevOps を導入する前に、そのメリットとデメリットの両方を理解しておく必要があります。

具体的には、製品、人、戦略目標に関連して、以下を考慮する必要があります。

DevOps を導入するための作業とそれによって得られるメリットとのトレードオフ
技術チームがどのように構成されて文化的に連携し合っているか
構築するソフトウェアの適合性 (たとえば、一部のアーキテクチャやテックスタックは他のアーキテクチャやテックスタックよりも DevOps に適合しやすい)

DevOps モデルのメリットとデメリットをもう少し詳しく見ていきましょう。

DevOps モデルのメリット

DevOps はソフトウェア開発ライフサイクルの各部分にわたり測定可能な改善を提供できます。これを実現するには、文化、プロセス、ツール導入を変える組織全体の協力的な取り組みが必要です。DevOps の導入に成功した組織は、一般的に次のようなメリットを実際に報告しています。

デリバリーの高速化: DevOps は、大規模なリリースではなく、段階的な改善に作業を分割し、準備が整い次第、コードの変更を本番環境にプッシュすることで、ユーザーへの迅速な価値提供を支援します。速度によっては、毎日複数のコードリリースを出荷する組織もあります。
多くの自動化: DevOps プラクティスは、ソフトウェア開発ライフサイクルの大部分に自動化を適用し、コードのテスト、構築、統合、デプロイを改善して標準化します。その結果、チームメンバーの反復タスクを減らして組織のコストを削減できます。開発者が反復タスクに費やす時間が減り、創造力を要する複雑な作業により集中できるため、デベロッパーエクスペリエンスにもメリットがあります。
品質向上: 同様に、テストやセキュリティ分析などのプロセスの自動化により、バグや脆弱性が本番環境に入り込むリスクを減らすことができます。
プロセスのスケーラビリティ向上: データドリブンプロセスと反復的な変化により、組織の成長する能力が向上します。自動化、明確に定義された文化、継続的な改善とともに、小規模なチームがより多くの価値を提供できるようになると同時に新しいチームメンバーのオンボーディングを容易にします。
より拡張可能な製品: 製品レベルでは、DevOps がインクリメンタルリリース向けに設定されているため、エンドユーザーからのリアルタイムのシステム需要に合わせた製品の拡張が容易になります。
耐障害性向上: 自動化された監視とレポート作成ツールでフィードバックループを促進することで、DevOps はチームがより堅牢なソフトウェアを構築するのを支援します。問題が発生した場合、DevOps の自動化とツールは、従来のソフトウェア開発プラクティスよりも迅速に本番環境に修正を適用するのに役立ちます。

DevOps モデルのデメリット

ほとんどの組織はゆっくり開始し、時間をかけて DevOps 文化を構築します。しかし、DevOps を部分的にしか導入せず、その結果、限られたメリットしか実現していない組織もあります。また、人々、戦略、製品の特定のニーズに合わせて調整せずに DevOps プロセスを導入している組織もあります。

では、不適切に設計された DevOps 戦略の場合、どのようなデメリットが考えられるのでしょうか

DevOps は継続的なプロセスであり、1 回限りの変更ではない: 成功している DevOps 組織では、DevOps は自然な作業方法です。人は製品という観点から考え、コラボレーションは介入なく行われ、誰もがプロセスの改善方法を探します。継続的な強化がなければ、その流れを維持するのは難しくなります。
ツールの不一致: DevOps プラクティスの最も可視的な側面として、DevOps ツールの導入を DevOps の導入と誤って捉えるのは簡単です。しかし、適切な文化やプラクティスがなければ、DevOps ツールによって既存のプロセスに摩擦が生じます。
導入が維持されない: 適切なツールとそれをサポートする広範なコンテキストがあったとしても、それらを単一の DevOps パイプラインに統合するには継続的なコミットメントが必要です。これがないと、プロセスとツールの間にギャップが生じ、手動の介入が必要になります。

DevOps 成熟度モデルについて

組織に DevOps を導入することは、製品デリバリーのさまざまなステージにわたり、さまざまなレベルで導入を行う継続的なジャーニーです。DevOps はビジネスニーズと同様に動的であり、その導入は組織ごとに異なります。

つまり、定義された DevOps 成熟度モデルは 1 つではないということです。GitHub では DevOps 成熟度モデルについてあまり説明しません。どの組織にも「DevOps」の実現に使用できるチェックリストが存在することを暗に示してしまうためです。これは正しくありません。基本的に DevOps は継続的プラクティスです。しかし、ビジネスには共通のステップと目指すべき成功の指標があります。

私たちの哲学は、将来の企業のために自動化と優れた DevOps をビルドすることです。

Adobe、シニア SCM エンジニア、Todd O'Connor 氏

たとえば、DevOps プラクティスの採用を検討している企業について考えてみましょう。スタート時点では、開発チームと運用チームはサイロ化し、それぞれの役割に集中している可能性があります。つまり、開発チームがコードをビルドすると、運用チームはそのコードに合わせて対応せざるを得なくなります。この組織の適切な最初のステップは、両チームが連携し、協力してコードの計画、ビルド、出荷を始めることです。

一方、SDLC 全体が自動化され、密接なコラボレーションを特徴とする組織があります。製品に特化したチームが協力し、各ステージで自動化と専用の DevOps ツールを使用し、継続的な改善を提供します。

組織ごとに DevOps 導入ジャーニーは異なりますが、これらは成功を示す重要な原則です。次の項目を行っている場合、DevOps を適切に行っていることになりますが、業界によっては、DevOps プラクティスに特別で必要な項目があります。

DevOps 導入ジャーニーの主要なステージ

実験的 DevOps	学習済み DevOps	事前対応型 DevOps	ネイティブ DevOps
1～2 チームが DevOps を検討しています。役割ベースのサイロがまだ大部分残っています。自動化で一部実験していますが各ステップで人間の介入が必要です。正式なプロセスはありません。	組織の一部でコラボレーションする製品チームを採用しています。これらのチームは DevOps ツールを効果的に使用していますが各チーム独自のアプローチがあります。プロセスは形成されており大部分は他の組織から学んだものです。	全ての新製品が DevOps モデルから始まっています。プロセスの有効性を監視し、改善につなげるための測定が実施されています。プロセスが組織のニーズに適応し始めています。組織の大半が DevOps ツールを使用しています。	DevOps は組織全体で導入されています。DevOps プロセスは組織のニーズに合わせて正確に調整され、状況の変化に応じて定期的に更新されています。テスト、ビルド、デプロイは DevOps ツールを使って自動化されています。全てのチームが製品に特化し、組織全体にわたりコミュニケーションとコラボレーションの流れを容易にしています。

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

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

料金プランを比較する >

計画から構築へ	開発の速度を上げる	全てを自動化	コード作成時のセキュリティを確保
プロジェクトと完全に統合した優れたプロジェクトボードとテーブルを使用して、コードベースのすぐ隣でロードマップ計画を作成し、チームメンバーにタスクをすばやく割り当てましょう。 GitHub Issues について	コミットまでの時間を短縮します。開発者の環境管理やコンテキストスイッチングをなくし、クラウドの安全なマネージドスペースにより、IT 調達とメンテナンスを簡素化しましょう。 Codespaces について知る	全てのソフトウェア開発ワークフローを自動化します。GitHub のフルマネージド型の強力な開発、テスト、自動化インフラストラクチャにより、信頼性と安全性を高めることができます。 GitHub Actions について	ソフトウェア開発ライフサイクル全体を通じて、コード、依存関係、トークン、極秘データのセキュリティを確保し、脆弱性を自動で解決します。 GitHub でどのようにセキュリティを確保できるかを知る

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