今さら聞けない!DevOpsについての解説!需要、今後の将来性と合わせてチェック!
近年はDevOpsという言葉が幅広く利用されています。皆さんもよく耳にするようになっているのではないでしょうか。
ただ、こちらの言葉は利用され始めてから10年以上経つものの、具体的に意味が理解されていない言葉でもあります。そこで今回は改めてDevOpsとはどのような意味であるのかをご説明します。
そもそもDevOpsとは
そもそもDevOpsとはどのようなものか理解できていない人は多いでしょう。まずは、DevOpsの意味を理解することから始めましょう。
DevOpsの意味
DevOpsは開発を意味する「Development」と運用を意味する「Operations」を繋げた言葉です。言葉では繋がっているだけですが、概念としてはそれぞれが協力しながらシステムの開発・運用をすることを指します。今まではそれぞれが独立して業務をこなしていましたが、DevOpsではそれぞれが協力しなければならないのです。
そもそも、DevOpsの概念は2009年に生まれました。この年にオライリー社主催の「Velocity2009」と呼ばれるイベントが開催され、その中で「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」と題されたプレゼンテーションが公開されました。直訳すると「1日10回以上のデプロイ」との意味で、1日あたりのデプロイ回数を増やすために、開発と運用がどう協力するべきであるかが説明されました。
ただ、このプレゼンテーションの中で解説されているのは、開発と運用が対立してしまう事実です。それぞれに慣れ親しんだやり方がありますので、協力するのではなく対立してしまうのです。これではデプロイの回数を増やすことは不可能です。
しかし、逆に互いに協力できる環境を作れば、この問題を解決できることも述べられています。それがDevOpsの基本的な考え方であり、昨今のシステム開発や運用でも注目されている内容です。
DevOpsとアジャイル開発
DevOpsと混同して利用される言葉にアジャイルが挙げられます。これらは全く同じ意味でも全く異なった意味でもありません。その点について以下で理解をしていきましょう。
そもそも、アジャイルはソフトウェアの開発モデルを指します。今まではウォーターフォールモデルがよく利用されていたのですが、新しいモデルとして生まれたのがアジャイルです。ソフトウェア開発に柔軟に対応できるように考えられた開発モデルであると考えておきましょう。
ここで理解してもらえるはずですが、アジャイルはあくまでも開発モデルの一つです。開発や運用の概念を示したDevOpsとは異なった意味や位置づけなのです。ただ、実際にはこれらが混同して利用される場合があります。その理由はどこにあるのでしょうか。
実はDevOpsをスムーズに運用するためには、アジャイルの考え方が必要になります。短時間で適切に方向を修正し、システム開発をしたり運用をしたりしなければならないからです。単純に開発と運用が協力をするだけでなく、短時間で方向修正をしながら開発と運用は協力する必要があります。
とはいえ、DevOpsとアジャイルが異なった意味であることには違いありません。間違って理解をしないように、正しくDevOpsとアジャイルの違いを押さえておきましょう。
なぜDevOpsが注目され重要が高まっているのか
なぜ近年はDevOpsが注目されているのでしょうか。DevOpsは何が重要なのでしょうか。この点について改めて考えていきましょう。
DevOpsの需要が高まっている背景
DevOpsの需要が高まっている背景には、世の中のシステムに対する期待が高まっていることがあると考えられます。昔に比べるとスマホなどの普及率が格段に上がり、最新のシステムがすぐに利用できなければ世の中の期待に応えられなくなっているのです。
DevOpsの実現に必要な取り組み例
DevOpsを実現するためには多くの取り組みが必要です。「これだけをしていればDevOpsが実現できている」とはならないのです。今回はDevOpsを実現するために、取り組んでもらいたい活動の例をご紹介します。
Infrastructure as Code
インフラの構成をコード化して管理する手法を指します。今までインフラは実際に利用する機器をバラバラの構成図などで表していましたが、Infrastructure as Codeではそのようなものは利用しません。
ただ、「Code」とはあるものの、これは必ずしもソースコードである必要はありません。ソースコードを利用して自動的にデプロイできるものも含みますが、ここでは一つにまとめられた手順書を指します。つまり、Infrastructure as Codeは、手順書さえ読めれば誰が操作しても同じようにインフラが構築できる環境を整える手法と言えます。
インフラは専門性の高い分野であることから、どうしても担当する人が限られます。一部の人にだけナレッジが貯まってしまい、異動や退職によってそのナレッジが失われてしまうケースが多々あります。それでは企業としてインフラを構築している意味がなくなってしまいます。
しかし、Infrastructure as Codeを導入できていれば、特定の人にだけナレッジが集約されることはなくなります。むしろ、ナレッジを持たない人でもナレッジを持っている人と同じようにインフラ構築ができるようになるのです。場合によっては自動化ツールでクリックするだけで、素人でもインフラ構築ができるようになります。
継続的インテグレーション
継続的インテグレーションは、日々開発しているソースコードなどを専用のツールにコミットし、そこからビルドやテストを自動化することを意味します。人間が自分でビルドやテストをするのではなく、DevOpsでは自動化が求められています。
これらの作業を自動化すると、バグの早期発見や予期せぬ動作の発見に繋がります。結果、ソフトウェアの品質が向上したり短時間でソフトウェアを公開したりできるようになるのです。
最近ではソフトウェアも複雑なものが増えているため、テストも複雑になり必要な工数も増大しています。その状況ではスムーズなソフトウェアリリースができません。継続的インテグレーションで、これらの問題を解決するのが理想なのです。
継続的デリバリー
継続的デリバリーは、継続的インテグレーションの上位に位置する考え方です。DevOpsらしくスピーディーなデプロイを実現する考え方です。
継続的インテグレーションとの違いは、継続的デリバリーでは本番リリース環境が常に用意されていることです。継続的インテグレーションはビルドとテストをする環境さえあれば良いですが、継続的デリバリーになるとこれでは不足してしまいます。実際にリリースして運用する本番環境が揃っていなければならないのです。
継続的インテグレーションを利用して自動的に実行されるのは、本番リリース直前のステージング環境までです。開発から自動的に運用に乗せるのではなく、あくまでも開発の中で完結します。
しかし、運用の仕事がないのかと問われるとそうではありません。DevOpsの考え方ですので、運用はいつでも本番リリースしてもらえるように環境の維持が必要です。既に本番リリースされている可能性も多々ありますので、その環境を運用しながら次なる本番を待たなければなりません。
なお、継続的デリバリーでは、本番環境にリリースするのは人間の作業です。そこまでは自動化されていません。DevOpsの考えに基づき、開発と運用が連携して適切なタイミングで本番リリースします。
継続的デプロイメント
継続的デプロイメントは継続的デリバリーの上位に位置する考え方です。DevOpsの考えをフルに利用したものであり、開発から本番リリースまでを自動化します。本番リリースするにあたり、人間がリリース処理などをする必要はありません。
冒頭でもご説明したとおり、現在は短時間で最新のソフトウェアが利用できる環境が求められています。利用者は開発が完了してから本番リリースするまでのラグも待ちたくないのです。継続的デリバリーではラグが発生してしまいますので、DevOpsの観点ではこれが少しネックになってしまいます。
しかし、継続的デプロイメントであれば、これらの問題を全て解決できます。テストまで完了した高品質なソフトウェアを、自動的にデプロイしてユーザーに利用してもらえるのです。DevOpsを最大限活用している状況だと考えられます。
なお、継続的デプロイメントを実現するためには、開発と運用の協力が必須です。人間を介さずに本番リリースされますので、運用側が受け入れできない状況を作ってはなりません。DevOpsらしく常に協力して受け入れられる体制づくりが必須なのです。
DevOpsとエンジニアの将来性
DevOpsの概要については理解してもらえたでしょう。またDevOpsを実現するためには、どのような取り組みをするべきか理解してもらえたはずです。続いてはこれらを踏まえ、DevOpsとエンジニアの将来性について解説します。
DevOpsは引き続き発展する
そもそもDevOpsの将来性について疑問を持つ人がいるかもしれません。確かに2009年の概念ですので、今となっては古いと考える人がいても不思議ではありません。
しかし、DevOpsは今現在も発展の続いている概念です。つまり、これからも引き続き発展することが期待されています。現に2009年に公開されたDevOpsの考え方と現在の考え方はやや異なっています。開発と運用が協力するという基本的な部分には変更がありませんが、時代に即した概念になるように日々進化しています。
特に現在はクラウドの発展などでDevOpsの実現が容易になっています。オンプレでシステムを運用していた時代と比較すると、格段にDevOpsが実現しやすいのです。概念の進化だけではなく実際に実装しやすくなっていますので、このことがDevOpsをさらに発展させています。
DevOps専門のエンジニアは生まれない
DevOpsが幅広く利用されるようになっているため「DevOpsエンジニア」が生まれるのではないかと考える人がいます。実際、求人やフリーランスエンジニアの自己紹介を見たりすると「DevOpsエンジニア」との記載が見受けられます。
しかし、上記でご説明したとおりDevOpsは開発と運用が協力して実現する概念です。つまり、一人のエンジニアによって実現するようなものではありません。そのため、「DevOpsエンジニア」というのは生まれません。開発に強みを持ったエンジニアと運用に強みを持ったエンジニアそれぞれが必要なのです。
ただ、DevOpsを推進するエンジニアが生まれているのは事実です。実際にDevOpsとして開発や運用をするのではなく、DevOpsが導入できていない企業などのサポートをするエンジニアです。このようなエンジニアは、DevOpsエンジニアではなく「ITコンサルタント」の立ち位置です。ITコンサルタントがいわゆるDevOpsエンジニアの役割を担っていると考えるべきです。
まとめ
DevOpsは2009年に生まれた概念ですので、現在は幅広く聞かれるようになっています。そのため、「今になってDevOpsを勉強しても大丈夫だろうか」と感じたかもしれません。しかし、ご説明したとおり、DevOpsは現在でも注目されている概念の一つです。
注意してもらいたいのは、DevOpsはあくまでも開発と運用が協力してデプロイを高速化するという一つの概念です。そのため「DevOpsエンジニア」などの職業はありません。開発か運用のどちらかの立場から、DevOpsに関わるエンジニアとなるのです。
クラウドの普及も後押しし、これからDevOpsはさらに広がると考えられます。今からでも遅くはありませんので、DevOpsを理解し導入できる部分には導入していきましょう。