DevOpsの基礎知識:歴史、利点、導入時の障壁とは?

DevOpsの基礎知識:歴史、利点、導入時の障壁とは?
◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください
【6/19開催】Kong Community Japan Meetup #4
本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定!参加無料です!!
https://column.api-ecosystem.sios.jp/connect/kong/1081/

【6/21開催】開発者目線でのSBOMとの向き合い方
SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法(デモ)を紹介します。SBOMを全く知らない人から、開発との統合までを紹介するので様々なレベルの方に学びがあるライブとなる予定です!
https://tech-lab.connpass.com/event/321422/

【7/19開催】現場で役立つAzure神小技10+α 〜生成AI,RAG,コスト削減など旬な技術満載のLT大会〜
Azureの最新技術や実用的な小技を紹介する特別なライトニングトーク大会を開催します!
https://tech-lab.connpass.com/event/319077/

【7/26開催】最適なIaCツールを選ぼう
プロジェクトでのツール選びに困らないための重要な観点をご説明します!
https://tech-lab.connpass.com/event/319532/

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

ご挨拶

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

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

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

それでは始めましょう。

歴史的背景

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

アジャイル開発

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

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

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

メリット・デメリット

アジャイル
メリット
仕様変更に準何位対応できる
リリース頻度が高く、高い開発スピード  デメリット
メンバー全員に設計からテストのスキルが必要
スケジュール管理が難しい  向いているプロジェクト
自社サービス

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

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

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

CI/CD

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

継続的インテグレーション(CI)継続的なビルドとテストの自動実行継続的デプロイ(CD)リリースの自動化継続的デリバリー(CD)リリース作業のステップの自動化

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

GitHubで見るCI/CD

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

GitHubで見てみるCI/CD

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

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

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

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

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

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

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

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

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

DevOps

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

DevOpsの考え方

DevOps概念図

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

開発:Dev
品質やサービス向上  運用:Ops
システムの安定稼働  共通の目的
プロジェクトの目的達成

開発チームと運用チームはそれぞれ異なるゴールを目指していますが、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で見てみるDevOps

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

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

まとめ

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

アバター画像
About 龍:Ryu 109 Articles
2022年入社で主にフロントエンドの業務でTailwindと遊ぶ日々。お酒とうまいご飯が好きで、運動がちょっと嫌いなエンジニアです。しゃべれるエンジニアを目指しておしゃべりとブログ執筆に注力中(業務もね)//
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる