開発体制

DevOpsとアジャイルの違い

今回はDevOpsとアジャイル(開発)の違いについてご紹介します。DevOpsもアジャイルも情報システム界隈ではよく耳にする言葉です。しかし、その意味を混同してしまったり正確に理解していないことで、DevOpsもアジャイルも上手くいかないといった状況が少なくありません。

本稿を読まれている皆さんの中にも、DevOpsとアジャイルの違いを詳しく知って正しく取り組みたいという方が多いのではないでしょうか?それぞれの違いや概要について詳しく解説するので、ぜひ参考にしてください。

DevOpsとは?アジャイルとは?

最初にDevOpsについて説明します。DevOpsは「Development」と「Operations」を略したもので、開発チームと運用チームを表しています。システム会社では製品に新しいサービスを開発・追加する開発チームと、安定したサービスを提供するための運用チームが存在します。もちろん「うちは開発も運用も同部署でやってるよ」という企業もあるかと思います。ただし自然と開発チーム・運用チームになんとなく分かれていることも多いでしょう。

DevOpsとはこの開発チームと運用チームが協力関係を築き、製品のビジネス価値を高めたりユーザーの利便性を高めるための取り組みのことです。

新しいサービスを続々と開発してリリースさせたい開発チームと、製品の安定稼働を目指して日々パフォーマンスを調整する運用チームではその役割が大きく違います。サービスが多くリリースされるほどパフォーマンスは不安定になるので、「開発は運用のことを分かっていない」「運用はサービスリリースの重要性を分かっていない」と対立関係に置かれることが多いでしょう。

しかし製品のビジネス価値とユーザーの利便性を高めるという目標は一致しているので、本来は協力すべき間柄です。こうした開発チームと運用チームの当たり前を覆したのが、2009年にオライリー(米国のメディア企業)が主催した「Velocity 2009」というカンファレンスでのFlickr(写真共有サービス)によるセッションです。

このセッションでは「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(1日に10回のデプロイ:Flickrにて開発とオペレーションの協力)」というスライドと共に、Flickrの開発チームと運用チームが協力体制を取り、1日に10回以上のデプロイを行っている事例について紹介しています。

セッションを担当したFlickrのエンジニアはDevOpsを実現するための組織文化や導入ツールに触れ、開発チームと運用チームが協力体制を取ることが如何に大切かを説きました。

では、アジャイルとは何でしょうか?これは開発・リリース・改善を「イテレーション(反復)」という単位の短い開発期間をもって繰り返していく開発手法です。アジャイルには「俊敏な」という意味があり、文字通り俊敏な開発・リリース・改善を行うことでシステム構築やサービス改善を行っていきます。

なぜDevOpsとアジャイルを混同してしまうことが多いかというと、DevOpsは基本的にアジャイルを取り入れることが完成するからです。Flickrの1日10回以上のデプロイという事例を見ても、アジャイルのように短い開発期間でサービスを開発・リリースしていかないと不可能です。もちろん綿密な計画があったわけではなく、「継続的に改善していこう」という考えがあってのことでしょう。

そのためアジャイルは時として開発遅延を生んでしまいます。細かい開発スケジュールは立案せず、開発と改善を短いサイクルで回してくので全体のコントロールが難しくなるという特徴があるからです。

DevOpsを成功させるためには?

DevOpsは製品の質を高めていくために有効な開発手法ですが、日本企業のDevOps導入では失敗が相次いでいるようです。その大きな原因が組織文化に着目していないことだとされています。

日本企業の多くはDevOpsを実現するための共有ツールさえあればよいと考え、新しい組織文化という観点が抜けがちです。共有ツールがあっても開発チームと運用チームが協力する環境は整いません。DevOpsを実現するにはFlickrが提示した次のような組織文化が必要です。

  • 互いを尊重する…尊重するとは役割は違えど一緒に働いている相手を心から思いやること。さらに、一人ひとりの能力や功績を評価して皆が優秀な人間と認めること。
  • 互いを信頼する…「自分以外の皆はすべて優秀」と認めることで信頼が生まれ、仕事を任せることができます。これは、問題を一人で抱え込まないことにも繋がり、各人の心的負担が大きく軽減することにも寄与します。
  • 失敗を責めない…新しいことに挑戦すると最初のうちは失敗の連続です。しかしその失敗を責めてはいけません。それが他者のチャレンジ精神を潰すことになり、チャレンジも無ければ成功も無くなってしまうからです。
  • 一緒に考える…何か問題が起こったときはその当事者を非難するのではなく、同じ問題が起こらないためにどうすればよいのか一緒になって考えること。それが建設的な組織文化を生み出します。

こうした組織文化を作ることで初めて開発チームと運用チームが協力できる環境が整います。加えてDevOpsに欠かせないツールとして、以下6つのツールにも着目しましょう。

  • インフラ自動化ツール…AnsibleやCheなどインフラ構築を自動化する
  • バージョン管理ツール…GitやMercurialなど同じバージョン管理ツールを共有する
  • ビルド&デプロイ自動化ツール…JenkinsやCapistranoはどビルド&デプロイを自動化するツール
  • フィーチャーフラグ…機能の有効無効を設定ファイルによって変更するテクニック
  • メトリクス共有ツール…New RelicやApplication Insightsなど取得したメトリクスの結果をダッシュボードで共有する
  • チャットツール…SlackやHipChatなどにビルドおよびデプロイのログやアラートを表示するbotを作成する

これらのツールをすべて導入する必要はありませんが、必要に応じて複数のツールを組み合わせることでDevOpsの組織文化を実現することができます。

DevOpsに超高速開発ツールを

皆さんの会社では、DevOpsやアジャイルを既に取り組んでいるでしょうか?インテリジェントモデルが提供する「ODIP」は、GUIを用いたモデル行動のシステムによって開発期間を大幅に短縮することができます。DevOpsを実現する上で欠かせないアジャイルにおいて、迅速かつ標準化されたシステム開発を支援する製品です。これからDevOpsとアジャイルに取り組む、あるいは既に取り組んでいるがなかなか成果が上がらないという企業は、「ODIP」による開発期間短縮にぜひご注目ください。

10人月分の作業も数分で完了可能なバッチシステムとは

10人月分の作業も数分で完了可能なバッチシステムとは
大規模バッチ処理システムに課題を抱える企業は少なくありません。特にシステムの肥大化による開発生産性の低下は大きな問題です。それを解消するのが、インテリジェント・モデルの開発支援ソリューション「ODIP(オーディップ)」です。

大規模バッチ処理システム開発に求められる「飛躍的な生産性の向上」「システムの肥大化防止」「見える化」「高品質、高性能」という4つの要件に対応し、すでに大手金融機関のミッションクリティカルなシステムにも採用されています。

ダウンロード

ODIP Enterprise Solution

こちらの記事もおすすめです

基幹システムと業務システムの違いブログトップへ戻る