DevOpsの歴史、導入メリット、そして直面する障壁について詳しく解説します。CI/CD、自動化、文化変革に関心のある方向けの導入記事になります。例として「GitHubで見てみるDevOps」を作っています。

ご挨拶

こんにちは、久しぶりです。最近、ブログ以外の外部発信活動を整備している龍です。目に見える成果がないのが、少し辛いですね。

今回は、「DevOps」についてまとめていきます。インターネットで情報を探していると、たまに見かけますよね。私もふわっと理解するところから始めました。最近は文脈上でよく使うので、ここで歴史を含めてまとめたいと思います。

特別な前提知識は必要ありませんが、GitHubを使ってCI/CDを組んだことがある方にとっては、理解しやすい内容だと思います。「ウォーターフォール」・「アジャイル」・「MVP」などのプロジェクトの進め方に関しては、こちらの記事でまとめています。

それでは始めましょう。

歴史的背景

DevOpsがどのような経緯で生まれたのかについて説明する前に、まずその背景を紹介します。

アジャイル開発

アジャイル開発は、実装したい機能を細分化し、要件定義からリリースまでを一つのサイクル内で行う開発手法です。

– 「要件定義」を行い、機能ごとの小さな開発サイクルで開発する
– 「設計」を機能ごとに行うため、急な仕様変更に対応できる
– すべての機能開発が終了せずに基本機能のみ開発が終了すればリリースできる
– 頻繁なリリースによって迅速な機能追加・変更が可能

最大の特徴として、サイクル終了ごとにリリースが行われます。これにより、「ウォーターフォール開発」に比べて高頻度なリリースが可能となります。

メリット・デメリット

リリースがサイクルごとに行われるため、仕様変更に柔軟に対応することが可能です。アジャイル開発は広く実践され、そのキーワードは深く浸透しています。

アジャイル開発が適しているサービスとしては、「自社サービス」のように機能を細分化して開発を進められるものがあります。

アジャイル開発を支える技術としては、自動化というキーワードがあり、GitHubやCI/CDが挙げられます。

CI/CD

アジャイル開発を支える技術としてのCI/CDについて説明します。CI/CDは以下のような意味を持っています。

CDは二つの意味を持ち、どちらもリリースに関する内容です。CI/CDでは『自動化』が重視され、特にビルド・テスト・デプロイのステップの自動化が注目されています。

GitHubで見るCI/CD

開発体験としては、GitHubのソース管理も重要です。その流れを含めて、『GitHubで見るCI/CD』として図化します。

GitHubでCI/CDを実現する方法としては、GitHub Actionsを使用します。

Pull Request上でCIのみを実行し、特定のブランチにマージされた際にCI/CDを一緒に実行します。

CI/CDを実行するタイミングやレビューや開発者の取り組みは、ブランチ運用やテスト戦略の文脈と共に考える必要があります。これはプロジェクトごとの判断になるため、また別のブログで詳しく説明します。

この環境を整備することで、開発者やレビュワーがソースの変更を加えることで、リリースを行うことが可能となります。

アジャイルからDevOpsへのつながり

アジャイル開発からDevOpsが提唱された背景について説明します。アジャイル開発が広く浸透し、開発チームのコミュニケーションが促進され、プロジェクトのスピードが上がりました。

2008年のカンファレンスでは、プロジェクトを運用するインフラチームと開発チームとの確執について問題提起がなされました。開発チーム内でのコミュニケーションは向上しているものの、運用チームとのコミュニケーションがうまくいっていないという現場の声がまとめられています。

その後、2009年に運用チームと開発チームの連携を密に取ることを解決策として『DevOps』という単語が提唱されました。ここでは開発チームと運用チームが目指すゴールの違いに注目し、最終的なゴールはより良い体験をユーザーに提供することとしました。

このような背景から、『DevOps』には「アジャイル」的アプローチが根底にあり、開発チームと運用チームが協力してより良いプロジェクトを実現するという『概念』が生まれました。

• Agile2008 Conference「Agile Infrastructure & Operations」
• Velocity 2009「10+ Deploys per Day: Dev and Ops Cooperation at Flickr 」

DevOps

まず理解すべきは、「DevOps」は開発手法ではなく、運用チームと開発チームが協力し、より良いプロジェクトを目指すための考え方であるということです。まずその根本的な考え方を説明し、次に「DevOps」を実現する方法を解説します。

DevOpsの考え方

「DevOps」は上記のような図で表現されることが多いです。DevOpsでは、「開発チーム」と「運用チーム」の二つのチームを一つに統合し、同一のゴールを目指すことを提唱しています。

開発チームと運用チームはそれぞれ異なるゴールを目指していますが、DevOpsの考え方では、これらを統合し「プロジェクトの目的達成」という共通のゴールを追求する一つのDevOpsチームを形成します。

DevOpsに関する誤解
「DevOps」はツールを使って実現するという誤解がありますが、実際は、プロジェクトに関わる全ての人が円滑にプロジェクトに参加し、目的達成を目指すという考え方が根底にあります。この考え方を実現するためのツールが多く存在していますが、DevOps自体は考え方そのものです。

DevOpsの流れ

DevOpsの概念図は英語で表現されていますので、それを日本語に訳して図化します。

開発手法においては、「計画」から「デプロイ」までに焦点が当てられています。しかし、DevOpsでは「運用」から「継続的なフィードバック」までを統合し、一つのプロセスとして捉えます。「運用」や「監視」でプロジェクトの問題点を特定し、「継続的なフィードバック」でプロジェクトの変更点を「計画」に反映させていきます。

DevOpsで重要な「キーワード」

DevOpsを実現するために重要なキーワードは「自動化」と「DevOps Culture」です。

自動化は、DevOpsの基礎となるアジャイル開発手法からも理解しやすいです。顧客の要望が直接伝わる現場では、「ビルド」から「デプロイ」までをCI/CDで自動化することで、迅速な開発スピードを実現しつつ、「継続的なフィードバック」により要望を取り込むことが可能になります。

DevOps Cultureは、「Respect」「Trust」「Healthy attitude about failure」「Avoiding Blame」の四つのキーワードで構成されています。これらを日本語に訳すと、「尊敬」「信頼」「寛容」「責任の共有」となります。DevOpsの目的は、異なる目的を持つもの同士が一つのゴールを共に追求することです。これらのキーワードは、プロジェクト運用だけでなく、人生にも通じるものです。

DevOpsのメリット

DevOpsのメリットは以下の観点で考えられます。

人的ミスの防止

自動化プロセスにより手作業が減少し、標準化が推進されます。これにより、人的ミスが大幅に減少し、信頼性の高いシステム運用が可能となります。

生産性の向上

開発チームと運用チームの協力により、コミュニケーションが円滑になり、生産性が上がります。迅速な問題解決と効率的なタスクの進行が可能になります。

高品質かつ迅速な開発

頻繁なリリースとフィードバックサイクルを通じて、品質を保ちつつ迅速な開発を実現します。継続的なテストとデプロイにより、バグの早期発見と修正が可能です。

ランニングコストの削減

自動化と効率化により、開発と運用のコストが下がります。手作業の削減により人件費が減少し、システムのダウンタイムや障害対応のコストも軽減されます。

予定外の作業のスムーズな解決

継続的な監視とフィードバックにより、予想外の問題や変更に素早く対応できます。問題が発生した際も、自動化されたプロセスと迅速なコミュニケーションによりスムーズに解決できます。

DevOps導入の障壁

DevOpsにおける障壁としては、以下の観点が考えられます。

必要な知識の導入

効果的なDevOpsの導入には、開発者や運用担当者がCI/CD、インフラ管理、監視ツールなどの知識を身につける必要があります。これらの学習曲線は障害となることがあります。

企業やチームの文化

DevOpsの成功は、開発チームと運用チームの協力に依存しています。既存の文化や習慣を変えることは困難であり、特にセクショナリズムが根深い組織では抵抗が生じることがあります。

学習コスト

DevOpsのツールやプロセスを学ぶためには時間とリソースが必要です。新たなスキルの習得やトレーニングに関するコストは、導入の障壁となることがあります。

導入コスト

新しいツールやシステムの導入には初期投資が必要です。インフラの整備、ツールの購入、運用体制の構築には費用がかかり、特に小規模な組織には大きな負担となることがあります。

GitHubで見るDevOps

開発でよく使われるGitHubを例に、「GitHub機能で見るDevOps」をまとめてみます。

プロジェクトは「GitHub Project」で管理します。ここでは、プロジェクトの進行管理やタスクのチケット管理などを行います。実際のタスクは「issue」として起票し、開発者に割り当ててチケット管理を行います。運用を担当する人が「GitHub Project」に参加し、起票することで、全ての計画や要望が集約されます。

今回の図には含めていませんが、SlackやTeamsなどの「コミュニケーションツール」も重要な要素となります。GitHubと連携して通知をコミュニケーションツールに送ることで、関係者の見落としを防ぐことができます。どの程度の通知を実装するかは、重要な要素となります。通知が多すぎると、通知の意味がなくなることもあります（例えば、迷惑メールに埋もれる重要なメールなど）。

まとめ

今回の記事では、DevOpsという概念について、その起源と歴史的背景を深く掘り下げて解説しました。GitHubを使って、DevOpsの適用方法についてもまとめました。次回の記事では、プロジェクトを進める際に必要な仕様書に注目して解説します。