システム開発に関連して耳にするようになってきた「DevOps」。迅速かつ効率的なシステム開発・運用におけるDevOpsの考え方に基づき、現場で実施されている「アジャイル開発」とは？従来の「ウォーターフォール開発」との違いも交えて説明します。

DevOpsという、開発現場のトレンド

「DevOpsツール」や「DevOpsセミナー」など、最近よく見かけるようになりました。DevOpsとは、「Development（開発者）」と「Operations（運用者）」をくっつけた言葉です。そこまではわかっていても、実際にどういうことなのかうろ覚えだという人も多いのではないでしょうか。
「DevOps」とは、開発者と運用者が連携してシステム開発・運用をしていくという、その『協力体制をとること』の概念なのです。DevOpsは、スマホアプリやWebサービスのシステム開発と相性がよいため、そうした開発現場で多く取り入れられています。
Webサービス開発の現場などでは「走りながら考える」という言葉を聞くことがありますが、まさにこれがDevOpsなのかもしれません。

『DevOpsの協力体制をとると言っても、今までもそれなりに連携しているけど……』と思う人もいるかもしれません。今までの開発の取り組みと何が違うのか、従来の開発モデルであるウォーターフォールでの課題を確認しながら見ていくことにしましょう。

おさらい：ウォーターフォールとは、一方向の開発モデル

ウォーターフォールモデルは長年使われてきたシステム開発手法です。ウォーターフォールモデルでは、一般的に以下のように開発工程が分けられ、上流から下流へと一方向に進んでいきます。

ウォーターフォールモデルのメリットは、「高品質を担保しやすい」「工程の作業範囲が明確に定められていて外注がしやすい」ことです。
各設計・製造工程を段階的に試験するという図のようなV字構造により、工程ごとに不具合が持ち越されることなく高品質な開発を行うことができるのです。

また、それぞれの工程ごとに作業範囲・インプット・アウトプットがきっちり決まっているため、ベンダーやパートナー企業に外注するときに工程が切り取りやすくなります。

システムは、ユーザーに合わせて変化することが求められるように

ウォーターフォールモデルは、大規模システム開発や仕様が明確に定められたシステムに適した開発手法で、圧倒的大多数のベンダーがこの手法を採用していました。
しかし、2010年頃からWebサービスやスマホアプリ等の『ユーザーの求めに合わせて随時更新すること』が求められるシステムが普及してくると、リリースサイクルの短縮という点ではこのモデルでは対応しづらくなるケースが出てきました。

開発している最中でも、ユーザーのニーズは移り変わります。世の中に新しいサービスがどんどん登場し、好ましいとされるトレンドや悪しき仕様などの情報も速いペースで更新されていくのです。開発中の製品にそうしたトレンドの反映をすることは、システムをより効果的なものにするためにもはや必須なこととなっています。
しかしながら、ウォーターフォールモデルは開発着手からリリースまでに時間がかかり、途中での仕様変更が難しい手法でもあります。
開発中に仕様変更があれば、設計段階からやり直しとなってしまいさらに期間がかかります。そして運用に入った後も変更には少なからず抵抗があります。
システムのアップデートがあれば、細かくテストして安定して稼働している状態が崩れてしまうことにもなりかねず、システムを直したい開発者（Dev）と安定稼働を続けたい運用者（Ops）が対立してしまうのです。

サイクル型の開発モデル、「アジャイル」

世の中の変化のスピードに追い付くために、より迅速に開発を行えるアジャイルと呼ばれるサイクル型の開発モデルが登場しました。ウォーターフォールのような工程分けをせず、ざっくりとしたリリース計画を基に小さな要件（機能）単位ですぐに実装してリリースし、それを続けて全体の開発を行っていくというモデルです。

リリースまでの期間が短くて済み、仕様変更に対応しやすいことがメリットです。この小さな開発のサイクルは「イテレーション」と呼ばれます。
実際のリリース物を見てユーザーが新たな要求を出してきたとしても、新しいイテレーションを回して対応することで、仕様をその都度柔軟に変更することができます。

アジャイルではウォーターフォールよりもずっと速いスピードでリリースすることになり、小さな変更にも敏感な運用者でも、その頻繁なリリースを受け入れて運用をしていくことになります。
開発者と運用者が連携してシステムを育てていかなければサービスの向上、引いてはそのビジネス全体としての成長がストップしてしまいます。これが開発者と運用者が協力し合う土壌となり、この土壌から生まれたのがDevOpsです。

DevOpsとは、もともと2009年に発表されたFlickrのJohn Allspaw氏とPaul Hammond氏による「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（1日10回以上のデプロイ：Flickrにおける開発と運用の協力）」というプレゼンテーションが元だとされています。ウォーターフォールのときのようにDev V.S. Opsとなる構図から脱却し、開発者と運用者が協力し合ってシステム開発運用を行っていくという方式です。

DevとOPSの連携を助けるDevOpsツール

ウォーターフォール開発でも、もちろん開発者ら運用者へ、仕様書やオペレーションマニュアルなどの引継ぎがありました。しかしながら、実際のコミュニケーションはあまりとられていませんでした。開発ベンダーと保守ベンダーが異なる会社であり、面識もないというケースも多かったのです。
DevOpsではそうした部門間のへだたりを解消する必要があります。
では具体的にどうするのかというと、例えば環境構築の自動化やバージョン管理の可視化、情報共有などのツールを用いて、開発者と運用者のそれぞれの業務を協力しやすいように管理しています。
頻繁なシステム変更の中でも安定稼働を助けるためのツールが、以下のような「DevOpsツール」です。

・バージョン管理ツール
バージョン管理を開発者と運用者で共有し、バージョン戻りを防ぎ最新管理を行います。Git、subversionなど。Redmineなどのチケット管理ツールとの連携も行うことで修正情報をわかりやすく管理できます。

・構成管理ツール
インフラ構築を自動化し、手作業による構築ミスを防ぎます。AnsibleやChefなど。

・CIツール
ビルドから単体テストまでを迅速に行うことを目的とした継続的インテグレーション（Continuous Integration, CI）のためのツール。自動的にビルドとテストを行うことができます。JenkinsやCircle CIなど。

・CDツール
ソースコード変更後の本番環境リリースまでを迅速に行うことを目的とした継続的デリバリー（Continuous Delivery, CD）ツール。Docker、Ansible、Chefなど。

・環境情報共有ツール
Botにより環境へのデプロイ結果などを情報共有します。Slackなど。

特に、小さな変更が多く発生するDevOpsでは、正しいバージョン管理が肝となります。

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

DevOpsでは、ツールによる自動化と開発者：Devと運用者：Opsが協調し合い連携するというやり方で、スピーディな開発を行うことができます。小さな開発を何度も行うことで開発工程を繰り返し経験できフィードバックを得られるため、開発者のスキルアップが期待できます。また、ユーザーの意見や要求をすぐに取り入れることができるのでよりよい運用、またはサービス自体の満足度向上につながります。

しかしながら、DevOpsにもデメリットはあります。工程ごとのスケジュール管理をしないので、全体の規模やスケジュールを厳密に管理したいニーズには向いていません。また、多くの機能を一度に開発する必要がある大規模開発にはやはり従来のウォーターフォールが向いています。

それぞれの向き・不向きを表しやすいのが、ガートナー社の提唱する「SoR/SoE」というシステム分類です。要求仕様が確定していて信頼性を求めるタイプのシステムであるSoRにはウォーターフォールが合っています。ユーザーとの親和性を重視するタイプのシステムであるSoEにはまさにDevOpsのやり方が良いといえるでしょう。（参考記事：使える! 情シス三段用語辞典77「SoR（モード1）／SoE（モード2）」）

 

以上をふまえ、ウォーターフォールモデル前提の開発とアジャイルを前提とするDevOpsの開発の違いを整理すると、以下の表のようになります。

依然として残るコミュニケーション課題

DevOpsでは、開発者と運用者の連携・コミュニケーションが基礎となってサイクルが進められていきます。しかしながら、そうしたチーム間のコミュニケーションに課題が残されているというのが現状のようです。
2019年8月22日にトレンドマイクロの発表した調査「DevOpsに関する実態調査 2019」では、世界各国のDevOpsを取り入れている企業へのアンケートで、「開発者と運用者の部門間コミュニケーションに改善が必要だと感じている割合」が89%以上であることがわかりました。日本国内においては、95%にもなります。多数の企業が、DevOpsにおいてもコミュニケーションに課題があると考えているのです。

（画像出展：トレンドマイクロ）

また、DevOps計画時に連携を取るべき部門に「セキュリティ部門」が含められていないという指摘もあります。

（画像出展：トレンドマイクロ）

DevOpsでは開発と運用の距離が近く、開発時からしっかりしたセキュリティ対策が必要です。そのため、DevとOpsに加え、セキュリティ部門も連携すべきと提言されています。

なお、システムのエンドユーザーの意見を取り入れるため、営業などのユーザー対応を行う部門との連携も必要で、実際にはさまざまな部門間での連携となります。DevOpsは、そうした企業内のコミュニケーション改革の呼び水ともなるでしょう。

最後に

2019年の現在、デジタルトランスフォーメーションやIoT、AIの台頭などITを取り巻く環境が劇的に変わりつつあります。DevOpsとはそうした変化の中で誕生してきた考え方です。時代の求めに応じた新しいやり方であるDevOpsを知ることは、新しい技術への挑戦の幕開けでもあるのです。

 

【執筆：編集Gp　星野 美緒】