Close

DevOps: 開発と運用を 1 つに

DevOps ループのイラスト

DevOps とは何か?

DevOps はソフトウェア開発と IT チーム間のプロセスを自動化および統合するプラクティスを 1 つにまとめたもので、より短時間かつ信頼性の高い形でソフトウェアの構築、テスト、リリースができるようになります。「DevOps」という用語は「development (開発)」と「operations (運用)」という 2 つの単語を組み合わせたもので、これまでそれぞれのサイロに分かれていた開発チームと運用チームの橋渡しをする文化的な転換を意味しています。

アトラシアン DevOps の無限大記号のイラスト

DevOps の本質とは、文化であり、ムーブメントであり、哲学です。

DevOps はマインドセットの転換、より良いコラボレーション、緊密な統合に重きを置く、開発と運用の強力な連携です。アジャイルgit継続的デリバリー、自動化などを 1 つにして、開発チームと運用チームの効率性改善、イノベーションの加速、企業と顧客に提供する価値の向上を実現します。


DevOps は個人で行うのではなく、全員で行うものです。

Christophe Capel
Jira Service Desk 主席プロダクトマネージャー

Chef.io のロゴ

DevOps を実践する

Chef は、DevOps ワークフロー向けの Chef Automate プラットフォームを開発している企業です。何万もの開発者が、Chef を使ってインフラストラクチャをテスト、自動化、管理しています。シアトルを拠点に DevOps の最先端を行くこの企業は、Chef、InSpec、Habitat、Chef Automate などの製品をリリースし、ソフトウェアやアプリケーションを開発、リリースする新しい方法を進化させてきました。独自の DevOps 社内プラクティスをテスト、改良するために、Chef はアトラシアンのプラットフォームを活用しています。

DevOps の歴史

DevOps ムーブメントがまとまりのある形になり始めたのは、IT 運用とソフトウェア開発の各コミュニティが、自分たちの感じていることが業界に深刻なレベルで機能不全をもたらしていると声を上げた 2007 年から 2008 年のことです。

彼らは、コードをデプロイ、サポートするのとは別の人物が、組織的かつ機能的なコードの記述を求められる従来型のソフトウェア開発モデルを激しく非難しました。

開発者と IT/ 運用のプロではそれぞれ異なる (そして対立することも多い) 目的、部門のリーダーシップ、評価基準となる主要業績指標があり、別々のフロアや建物で働いていることがほとんどでした。その結果、サイロ化されたチームが自分たちの領域内で長時間働き、リリースに失敗することで顧客の満足度が下がっていました。もっと良い方法があるはずだと彼らは言いました。そこで、その 2 つのコミュニティが集まって話を始めました。Patrick Dubois 氏や Gene Kim 氏、John Willis 氏といった人物が会話の中心になりました。

オンラインフォーラムと地元の集まりから始まったものが、今ではソフトウェア開発を考えるうえで大きなテーマになっており、皆さんがこのページをご覧になっているのもそのためかと思われます。皆さんと皆さんのチームは、社内でサイロ化されたチームや分断されたコミュニケーションに頭を悩ませていることでしょう。

プランニングと開発のためのアジャイル手法を使っていても、相変わらずさまざまな困難に直面しながらプロダクトをリリースしていることでしょう。DevOps に関することを小耳にはさみ、それがチームに魔法のような効果をもたらすように見えたのではないでしょうか。アトラシアンが 500 人の DevOps 担当者に行ったアンケートによると、ほぼすべて (99%) の DevOps チームが本番環境にリリースするコードの成功に自信を持っています。

しかし、DevOps は魔法ではなく、一夜にして変革が起こるわけでもありません。良いお知らせもあります。上層部が大規模なイニシアチブを展開するまで待つ必要がないのです。DevOps の価値を理解し、小さな変化を積み上げていくことで、すぐにでも DevOps ジャーニーに乗り出すことができます。では、DevOps のメリットをそれぞれ詳しく見ていきましょう。

"現場の" DevOps 担当者は、経営幹部に比べて DevOps の進捗と成功の影響を測定するのが難しいと答える割合が高くなっています (DevOps 担当者で 62%、経営幹部で 46%)。

DevOps 担当者に対するアトラシアンのアンケート

利点

人間のつながりを示すアイコン

コラボレーションと信頼

私たちが行ったアンケートによると、パフォーマンスが高い DevOps チームではコラボレーションが最も重要な役割を果たしていることが明らかになりました。責任の共有と透明性が実現され、スピーディーなフィードバックが行われる文化を形成することが、高いパフォーマンスを発揮する DevOps チームの基礎となります。私たちのアンケートでは、DevOps 文化を成功に導くために最も重要な要素としてコラボレーションと問題解決がランク付けされています。

サイロの中で働いているチームは、ほとんどの場合 DevOps が支持している「システム思考」を忠実に守っていません。「システム思考」とは、チームだけでなく、リリースプロセスに関わっている他のすべてのチームに自分の行動が与える影響を意識することです。チーム間の状況が見えず、共通のゴールがないと、依存関係のプランニングが不十分になり、優先順位付けにずれが生じ、責任のなすりつけ合いが起きます。さらに、「自分には関係ない」という考え方になり、ベロシティと品質の低下につながります。DevOps とは、開発プロセス全体を見て、開発と運用の壁を取り壊すようにマインドセットを変えることです。

スピードメーターのアイコン

リリースを加速してよりスマートに仕事を進める

スピードがすべて。DevOps を実践しているチームでは、より高い品質と安定性で頻繁にリリースを行っています。

テストサイクルとレビューサイクルが自動化されていないと、本番環境へのリリースが遅れ、インシデント対応に時間がかかることでベロシティとチームの自信が損なわれます。まとまりのないツールとプロセスによって運用コストが増えることで、処理が中断されてチームの勢いがそがれることになります。自動化と新しいプロセスを推進するツールを活用すると、チームの生産性を向上して障害の数を減らしながら、より高い頻度でリリースを行うことができます。

心拍数のアイコン

解決までの時間を短縮

成功するチームは、スピーディーなフィードバックループを導入しているチームです。すべてが見通せる透明性と、垣根のないコミュニケーションによって、DevOps チームはダウンタイムを最小限に抑えながら短時間で問題を解決できます。

重大な課題を迅速に解決できないと、顧客満足度が低下します。オープンなコミュニケーションがないと、重要な課題が見過ごされ、チーム内の緊張が高まり、不満が募ります。オープンなコミュニケーションがあれば、開発チームと運用チームは協力して課題に取り組み、インシデントを修正し、より早くリリースパイプラインの問題を解消できます。

ツールアイコン

計画外の仕事をよりスムーズに管理

予想外の作業は実際どのチームも直面します。そして、現実問題としてほとんどの場合、チームの生産性に影響を及ぼします。しっかりとしたプロセスと明確な優先順位付けによって、開発チームと運用チームは計画済みの作業に引き続き注力しながら計画外の作業をよりスムーズに管理できます。

異なるチームとシステム間で計画外の作業の移行と優先順位付けを行うのは効率が悪く、目の前の作業に集中できなくなります。しかし、視認性の向上と積極的なふりかえりによって、チームはより正確に計画外の作業を予測して共有できます。

DevOps 向けの CALMS フレームワーク

CALMS は、DevOps プロセスを導入する力を評価するとともに、DevOps の変革を行う中で成功を測定するための手段でもあります。「The DevOps (The DevOps ハンドブック: 理論・原則・実践のすべて)」の共著者である Jez Humble 氏によって作られた略語で、次の単語の略になっています。


ジャージのアイコン

文化 (Culture)

DevOps とは単なるプロセスや開発への異なるアプローチではなく、文化の変化です。そして、DevOps 文化で大きな役割を果たすのがコラボレーションです。

開発と IT/ 運用のプロたちが協力しないと、DevOps におけるツールの整備と自動化は何の役にも立ちません。DevOps ではツール関連の問題を解決することはできません。解決できるのは人間の問題です。

DevOps をアジャイルチームの進化だと考えてみてください。これまでと違うのは、運用がデフォルトで含まれていることです。部門に基づくチームではなく、プロジェクトやプロダクトの観点からチームを編成することが、成功への一歩になります。開発、QA、プロダクト管理、設計、運用、プロジェクト管理、そしてプロジェクトに必要なあらゆるスキルセットを含めるようにしましょう。1 つのチームですべてを行ったり、「DevOps のプロ」を雇ったりするのではなく、垣根を超えて協力できるプロジェクトベースのチームを構築することがより重要になります。

共通の目標の共有、その目標を一緒に達成するための計画立案などによってコラボレーションを促進できます。プロジェクトを念頭に置いたチームに突然切り替えるのはやりすぎかつ時期尚早な企業もあります。ですから、小さなことから始めていきましょう。開発チームが行っているスプリント計画セッションや毎日のスタンドアップ、スプリントデモに運用チームの適切なメンバーに参加してもらうことができます (そして、参加してもらうべきでしょう)。運用チームのミーティングには重要な役割を果たしている開発者を招待します。これが、お互いのプロジェクト、アイデア、苦労を把握する、アジャイルで有機的な方法です。

課題や、緊急事態でさえ DevOps 文化をテストする絶好の機会となります。開発者、運用チーム、およびカスタマーサポートは、課題に対して一丸となり、チームとして課題解決に当たっていますか? 責任のなすりつけ合いをするのではなく、プロセスの修正に重点を置いたインシデントの事後検証を行っていますか? 答えが「はい」ならば、DevOps 構造の中でチームが働けている良い兆候です。

成功している企業の大半は、すべての部門、そして組織図のすべてのレベルで DevOps 文化を導入しています。こうした企業では、開かれたコミュニケーションが行われていて、定期的に会話が交わされています。さらに、顧客を幸せにし続けることが、プロダクト管理チームと開発チーム両方の責任だと認識しています。そして、DevOps は 1 つのチームだけの仕事ではなく、全員で行うものだということを理解しています。

歯車のイラスト

自動化

自動化は反復的な手作業を排除し、反復可能なプロセスを生み出し、信頼性の高いシステムを作ります。

まだ自動化を実施していないチームでは通常、自動化の構築、テスト、デプロイ、プロビジョニングから始めることになります。開発者、テスター、運用担当者が協力する理由は、すべての人にメリットをもたらすシステムを構築する、ということだけで十分でしょう。

これまで自動化を行ったことのないチームは、継続的デリバリーから始めましょう。これは、多くの場合はクラウドベースのインフラストラクチャを使って、一連の自動化されたテストによって各コードの変更を行い、自動化されたデプロイでビルドをまとめて本番環境に進ませる手法です。

これを導入する理由は、人間よりもコンピューターの方がより厳密かつ忠実にテストを実行するからです。コンピューターによるテストでは、バグとセキュリティ上の不備をこれまでより早く検出できます。そして、デプロイの自動化によって環境間のサーバーの「ドリフト」を IT/ 運用に警告することで、リリース時に予想外のことが起きるのを軽減、または根絶します。

DevOps の大きなメリットして他にも「コードによる構成 (Configuration As Code)」があります。開発者は、信頼性が高く、メンテナンスもしやすいことから、モジュラー型で部品組み立て方式のアプリケーションを開発しようとしています。同じ考え方を、クラウドや企業の独自ネットワークでアプリケーションをホストするインフラストラクチャにも広げることができます。

DevOps の世界で起きている自動化は「コードによる構成」と「継続的デリバリー」だけではありませんが、開発チームと運用チームの壁を壊す存在であることから特にここで取り上げました。DevOps でデプロイを自動化して、共通のプロビジョニングが実施された環境に徹底的にテストされたコードを送信すれば、「自分のマシンでも問題なく動いた!」などという発言は意味のないものになります。

リーンな DevOps のアイコン

リーン (Lean)

ソフトウェアの話題で「リーン」という言葉を聞くと、通常は価値の低い活動を廃止して効率を向上し、強い決意のもとアジャイルを実践することを思い浮かべます。DevOps をより適切に表すのが、実験的なマインドセットの基礎となる、継続的な改善と失敗を受け入れるというコンセプトです。

DevOps のマインドセットでは、継続的な改善の機会がないか、あらゆる場所を見ています。目につきやすいところでは、チームのプロセスを改善する定期的なふりかえりなどがあります。もっとささやかな、プロダクトの新規ユーザーに対する異なるオンボーディングアプローチをする A/B テストなどもあります。

アジャイル開発のおかげで継続的な改善は主流の考え方になりました。アジャイル手法を初期の段階で取り入れた人たちによって、完璧なプログラムを届けるために顧客を 6 か月待たせるより、シンプルなプロダクトを今すぐ顧客に届けることの方に価値があることが証明されました。プロダクトを継続的に改善していけば、顧客が離れていくこともなくなります。

この取り組みを行う場合、失敗を避けて通ることはできません。そのため、チームが失敗を受け止めてそこから立ち直り、学びを得ることができるようにしましょう (これを「打たれ強くなること」と言う人もいます)。ほとんど失敗することがないと、アトラシアンでは懸命に取り組んでいないと見なされます。

DevOps の観点から見ると、失敗は罰に価するような違反ではありません。物事はどこかの時点で失敗する運命にあることをチームで想定しているため、早期に失敗を見つけて短時間で修正できるような開発の進め方をしています。事後分析では、コードに問題をもたらしたチームメンバーではなく、プロセスが失敗したポイントとそれを強化する方法に注目しましょう。どうしてでしょうか? それは、継続的な改善と失敗には密接な関係があるからです。

物差しのイラスト

測定 (Measurement)

継続的な改善の取り組みが実際に効果を発揮しているかをデータなしで証明することは困難です。ありがたいことに、ユーザーがプロダクトに費やした時間、ブログ投稿が売り上げを生み出したかどうか、ログに重要なアラートが出現する頻度などのパフォーマンスを測定するツールとテクノロジーがたくさんあります。

あらゆることを測定できますが、だからといってすべてを測定する必要はなく、推奨もされていません。アジャイル開発を参考にして、まずは基本的なことから始めましょう。

  • 開発からデプロイまでどれくらいかかりましたか。
  • 同じバグや失敗はどれくらいの頻度で起こっていますか。
  • システム障害から復旧までどれくらいかかりますか。
  • 現在自社製品を使っているユーザーはどれくらいいますか。
  • 今週のユーザー数の増減はどれくらいですか。

しっかりとした基盤を整えることで、フィーチャーの使用状況、カスタマージャーニー、サービスレベルアグリーメント (SLA) に関して洗練された指標をより簡単に得ることができます。ロードマップの作成と、次の大きな動きに向けた仕様の策定を行うときに、こうした情報が活躍することになります。

このような充実したデータは、チームの意思決定をサポートするだけでなく、特に他の部門のチームと共有したときにさらに強力な威力を発揮します。たとえば、マーケティングチームで販売できる、魅力的で新しいフィーチャーを求めているとします。一方で、プロダクトが技術的負債を多く抱えているために大量の顧客離れが起きています。ロードマップの支えとなるユーザーデータを提供することで (たとえフィーチャーより修正プログラムに重心を置いたものでも)、合意形成とステークホルダーからの同意の取り付けがしやすくなります。

メッセージの吹き出しのイラスト

共有 (Sharing)

開発チームとオペレーションチームの間に長年、軋轢があることの原因の大半は、共通の土台がないことです。責任を共有し、成功を分かち合うことが、分断を埋めるのに大きく役立ちます。開発者は、オペレーションの最大の重荷である "障害時の呼出" をサポートすることで、すぐに信頼を勝ち取ることができます。DevOps では、アプリケーションの構築を行った人間がリリースと実行にも関わるというアイデアを重視しています。

これは、開発者を雇って、彼らにそのまま優れた運用担当者になってもらうということではありません。アプリケーションライフサイクルの各フェーズで開発者と運用担当者が互いにタッグを組むということです。

多くの場合、DevOps を取り入れているチームでは、エンドユーザーが見つけた問題への対応を行いながらプロダクションの問題のトラブルシューティングも行う開発者の役割を持ち回りにしています。この役割では、顧客から報告があった緊急の問題への対応、必要時のパッチの作成、顧客から報告があった不具合のバックログの作業も行います。「サポート担当の開発者」はアプリケーションが実際にどのように使われているかについて多くのことを学ぶことになります。また、運用チームと深く関わることで、開発チームは信頼を勝ち取って互いに尊重し合うようになります。

すべてのチームを、高いパフォーマンスを発揮する DevOps チームに生まれ変わらせる魔法の杖があればよいのですが、実際のところ DevOps の変革にはさまざまなプラクティス、文化的な哲学、ツールが必要になります。しかし、これまでご紹介してきたとおり、開発と運用のサイロを取り壊すことには、信頼の向上、ソフトウェアリリースの迅速化、より信頼性の高いデプロイ、チームと顧客の間のフィードバックループの改善など、大きなメリットがあります。

DevOps の導入は簡単ではありません。しかし、適切なフレームワーク、取り組み、ツールがあれば、組織は大きなメリットをもたらす DevOps の変革を実現できます。

Cite Research と共同で実施したアンケートの詳細については press@atlassian.com までお問い合わせください。

DevOps のジャーニーを始める準備はできましたか?