はじめに
クラウドサービスを効果的に利用するため、どのように導入を進め、活用の幅を広げればよいのかといった取り組みの指針を、具体的にイメージするのは難しいものです。こういった場合に役立つのが、ユーザ企業の社内担当者がクラウドサービスを運用するにあたって、開発がどのような考え方に基づいているのかについて理解を深めることです。
そこで本記事では、DevOpsという考え方についてご紹介します。DevOpsはソフトウェア開発の領域で生まれた概念ですが、ほかの分野でもDevOpsを基にした考え方が応用されており、基礎に触れておくことは多くの人にとって有用です。
目次
DevOpsとは
DevOpsとは開発（Development）と運用（Operations）を組み合わせた造語であり、スピーディーな開発を実現するために、開発チームと運用チームの連携を強化するという考え方です。
機能の追加や拡張を目指す開発と安定的な管理を目的とする運用は、利害が対立すると従来は考えられていました。しかし開発と運用は「ユーザの満足度を高めるため」に適切に行動するという大きな観点で協力できるため、DevOpsは部署ごとの最適ではなく全体的な最適解を目指すことで、開発と運用の連携を強化します。
DevOpsでは開発チームと運用チームが密に連携を取るために、全社的な業務のフローや意識改革が必要だと考えます。変革は企業文化の醸成から業務プロセスの改善、現場の情報共有を助けるツール導入までさまざまです。
DevOpsはソフトウェア開発分野で生まれましたが、「全体的な最適化を図るために、複数の部署や担当者が連携する」という考え方は汎用性が高く、他分野でも応用されています。近年では、開発（Development）と運用（Operations）に加え、ビジネス部門（Biz）とも連携するBizDevOpsや、データ活用に応用するDataOpsをはじめとした発展的な考え方も登場しています。
DevOpsまでのソフトウェア開発の変遷
DevOpsはソフトウェア開発の分野で生まれました。開発と運用の関係性に注目した理由は、DevOps登場前のアジャイル開発と、そのアジャイル開発以前のウォーターフォール開発について把握すると理解しやすいでしょう。
1970年代：ウォーターフォール開発によるソフトウェア開発方法の標準化
ソフトウェア開発の方法は1960年代まで確立されておらず、個々のエンジニアの知識や経験に依存していました。そのためプロジェクト企画段階で、ソフトウェア開発に必要な工数や成果物の品質を担保できないことが、最大の課題となっていました。
これを解決すべく1970年初頭に、「要件定義」「開発」「運用」といった作業工程を分割して滝から水が落ちるように段階的に進めていく、トップダウン型の「ウォーターフォールモデル（Waterfall model）」が登場します。
ウォーターフォールモデルはソフトウェア開発の手順を分かりやすく単純化し、その普及に大きく貢献しました。とくに、経験値の足りないエンジニアが多い黎明期には、非常に有用でした。ソフトウェア開発方法のデファクトスタンダートになり、現在でも品質を重視する際や大規模開発を中心に使用されています。
進捗状況やスケジュール管理を把握しやすいというメリット以外にも、工程を分割することが結果として分業につながるため、低スキル者が開発に携わりやすくなるのもメリットです。しかしソフトウェア開発は、ウォーターフォールモデルでは構造的に改善が難しい「開発の高速化」という課題に直面し、まったく別のアプローチを探すことになります。
2001年：アジャイルソフトウェア開発宣言
ソフトウェアに関するニーズが多様化して、適切な要件定義が難しくなるにつれて、ウォーターフォールモデルによる開発は長期化しやすくなりました。問題があった際に、要件定義のような上流工程まで戻って、大きくやり直す必要があるためです。この構造的な課題を解決するために新たな開発方法が世界中で模索されましたが、開発方法の主流が代わるような大きな動きは、2000年代に入るまで起こりませんでした。
2001年にパラダイムシフトが起こります。ウォーターフォールとは異なる開発手法を実践していた17名のソフトウェア開発者が議論し、「アジャイルソフトウェア開発宣言（Agile Manifesto）」をとりまとめて公開したのです。
宣言の中では、従来ウォーターフォール開発で重視されていた左の項目の価値を認めつつも、より右の項目に価値をおく、という以下のような4つの基本原則が掲げられています。
| プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を |
この宣言は、ウォーターフォールモデルではない開発方法を模索していたソフトウェア開発者に、重視すべきポイントを明解に示しました。以後、ソフトウェア開発の課題は「どのようにアジャイル開発を実践すればよいか」にシフトしていきます。
2000年代：アジャイル開発の課題
アジャイル開発の基本的な実践方法は、小さく部分的なリリースの繰り返しです。この方法はウォーターフォールモデルと比べて、不具合が発生した際に修正が必要となる規模が小さいため、全体の開発期間を短縮できます。またテストやリリースも段階的に進められるため、課題の発見に結びつきやすく、プロジェクト初期の要件定義に囚われすぎずに実用的な開発を進められます。
しかし、この小規模なサイクルを繰り返す際には、ウォーターフォールモデルでの開発で利用してきた社内規約や業務フローが、満足に機能しない場合が多くあります。アジャイル開発を活用するためには、全社的な仕組み自体を変える必要があり、その環境作りに大きなコストや時間がかかります。結果、アジャイル開発はロジックとして納得できるものの実践は簡単ではない、というのが実態でした。
2009年：DevOpsの登場
アジャイル開発は、ウォーターフォールモデルに代わる、ソフトウェア開発のスタンダードとして期待されつつも、すぐには普及しませんでした。転機は2009年、写真画像の共有Webサイト「Flickr」のエンジニアによるプレゼンテーションをきっかけとして、広く認知された「DevOps」という考え方の登場です。
DevOpsは、スピーディーな開発と運用を実現するために考案された、開発（Development）と運用（Operations）の連携を目指す考え方です。従来は対立するものだと思われていた、開発と運用の関係自体を変える新しい考え方であり、アジャイル開発に挑戦したものの思ったように開発を高速化できないと悩んでいたエンジニアに、示唆を与えました。
DevOpsとアジャイル開発の違い
「アジャイル開発」は開発の高速化を目的として生み出された概念であり、「DevOps」は素早い開発と運用の実現のために考案されました。両者は似ていますが、アジャイル開発の焦点はあくまでも開発であり、DevOpsは運用も含むため、より規模が大きい概念だといえます。
アジャイル開発とDevOpsは、ウォーターフォールモデルとアジャイル開発のように対立する概念ではありません。両方の要素を満たすアジャイルかつDevOpsな開発も実現可能です。
DevOps実践のポイント
DevOpsは企業文化の醸成から業務プロセスの改善、現場の情報共有を助けるツール導入までさまざまな要素を含むため、実践の際にはそれぞれの要素ごとに考えることが効果的です。
- DevOpsにマッチした体制と評価の確立
DevOpsを組織に根付かせるためには、縦割りではなく複数の部署やチームが連携しやすいように、組織の再編や業務フローの変更が欠かせません。
また、新たにDevOpsという考え方を学ぶ従業員のモチベーションを高めるため、しっかりと取り組みを評価する仕組みの構築も大事です。
- 組織文化としてのDevOpsの醸成
DevOpsの実践には、従業員の教育も重要です。「DevOpsという考え方の有用性」をしっかりと周知し、部署間のコミュニケーションや情報共有といった連携の価値をしっかりと共有する必要があります。
- 協力する他部署の業務に関する相互理解
DevOpsには、異なる業務に携わる従業員の連携が必要です。しかし互いの優先順位や気になる部分が分からなければ、適切な情報共有や効率的な打ち合わせは望むべくもありません。連携する相手への理解を深められるよう、基本的な業務フローや基礎知識を共有するとよいでしょう。
- ツールの導入と活用
単独でDevOpsを実践できるツールは存在しません。連携を取りやすくするためのコミュニケーションとコミュニケーションに時間を割くための業務自動化、2つの目的にあわせたツールを導入しましょう。とくにコミュニケーションやデータ共有のためのツール選びでは、全社やグループ企業、取引先など協力する多くの相手と連絡できるよう、注意が必要です。
ソフトウェア開発におけるDevOpsの発展
DevOpsは、部署間のコミュニケーション不足を解消して全体的な速度をアップさせる考え方と方法論です。そのため、対象を開発と運用だけでなく、ほかの要素に注目した応用的な概念も登場しています。
BizDevOps
BizDevOpsは、従来の「ビジネス部門から開発部門や運用部門に、顧客要求あるいはビジネス目的を伝える」というスキームではなく、3部門が連携して生産性を高めるという考え方です。
DevOpsにビジネス部門を加えることで、開発部門も運用部門も最初から「ビジネス目標」を共有して、より全社的な利益を意識して活動できるようになります。
DevSecOps
DevSecOpsとは、開発と運用にセキュリティを密に連携させ、DevOpsでは開発後に実施していたセキュリティ対策を初期段階から実施し、問題の早期発見と設計レベルでの対策を目指す取り組みです。
DevOpsの、セキュリティに関する取り組みのタイミングや責任が明示されておらず、脆弱性への早期対処が困難だという課題に対処しつつ、開発速度を維持できます。
クラウドサービス利用者にとってのDevOps
DevOpsを基にした考え方は、ソフトウェア開発者だけでなく、クラウドサービス利用者にとっても有用です。
もともとDevOpsという概念が誕生した欧米では当時、社内に自社システム開発に携わる部署が存在する割合が高く、企業内の「開発」と「運用」の連携を想定していました。クラウドサービス利用の場合について考える際、DevとOpsが実際に何を指すのかをしっかりと意識することが肝要です。
「Dev」は実際にソフトウェアを0から開発するベンダではなく、実装の際にソフトウェアとライセンスの選択やカスタマイズ、ソフトウェアと既存システムの連携といった業務の担当者を指します。一方で、「Ops」はソフトウェアの管理担当者を指します。企業によっては、情シス担当者が両方担当するという場合もありますが、連携は簡単ではありません。なぜなら、クラウドサービスのベンダと実際にソフトウェアを業務で利用するユーザ、どちらとも密な連携が必要になるためです。
扱うソフトウェアの仕様や自社にマッチした使い方についての知識を蓄積しつつ、社内のユーザのニーズを把握して社内教育を進め…と、エンジニアリングとコミュニケーションを同時にこなすのは難しいものです。そういった場合は、実装から定着までの管理や社内教育を外部のプロに任せるのも効果的でしょう。
システム運用に重点をおいたSRE（サイト信頼性エンジニアリング）
実際に「運用」に焦点をあててDevOpsを具体的に実践する方法も提案され、公開されています。グーグル社が提唱するSRE（Site Reliability Engineering）が、そのIT運用方法です。新機能のリリースと機能の信頼性のバランスを取るため、従来は手作業で行っていた業務を可能な範囲で標準化・自動化する手法であり、グーグル社以外にも取り入れられています。
まとめ
社内のシステム運用担当者が、クラウドサービス提供ベンダや社内ユーザとコミュニケーションを取り、必要な機能追加と安定した動作のバランスを取ることは、クラウドサービスの活用において重要です。しかし、社内担当者にエンジニアリングとコミュニケーションを両方任せると負荷が大きいため、クラウドサービスや社内システム運用の外部委託を検討している場合は、SREを実践できるプロを探すのも手段の1つです。
セラクはMicrosoft AzureやAWSといったクラウドサービスの活用支援に力を入れており、培ってきた支援ノウハウでさまざまな業種・業態、規模の生産性向上・競争力強化をサポートしています。デジタル化への取り組みを効率化させるため、プロフェッショナルの手を借りたい場合はセラクへご相談ください。
