Close

DevOps 文化とは?

より統一された顧客重視の体制に向けて、DevOps 文化が人、プロセス、ツールの連携にどのように役立つのか

Tom Hall の顔写真
Tom Hall

DevOps アドボケート & 実践者


コラボレーション

DevOps は組織変革のアジャイル アプローチであり、従来のサイロ化されたチーム間の分断を橋渡ししてコラボレーションを促進する新しいプロセスを確立しようとするものです。DevOps は新しいツールとアジャイル エンジニアリング プラクティスによって可能になりますが、それだけでは DevOps のメリットを得るには不十分です。適正な考え方、決まり、文化がなければ、DevOps で見込まれるすべてを実現することは困難です。

DevOps の実装を成功させるために重要なのは、人と文化です。
- アトラシアン 2020 年 DevOps 動向調査

DevOps 文化とは?


本質的に、DevOps 文化には、より緊密なコラボレーションと、作成して保守する製品の開発と運用の責任を共有することが含まれます。これは、企業がより統一された顧客重視の体制に向けて人、プロセス、ツールを連携させるのに役立ちます。

これには、製品のライフサイクル全体について説明責任を負う分野横断的なチームの育成が含まれます。DevOps チームは自律的に作業してソフトウェア エンジニアリング文化、ワークフロー、ツールセットを受け入れ、運用要件をアーキテクチャ、設計、開発と同じレベルの重要度まで高めます。構築した開発者が実行もすれば、開発者はユーザーにより近くなるため、ユーザーの要件やニーズに対する理解が高まります。運用チームは開発プロセスへの関与が増すにつれて、より良い製品のための保守要件と顧客ニーズを増やせます。

DevOps 文化の中心は、従来はサイロ化されていたチーム間の透明性、コミュニケーション、コラボレーションの向上です。しかし、これらのチームをより緊密に結び付けるためには、重要な文化的な変化が起こらなければなりません。DevOps は、継続的な学習と継続的な改善を重視する組織文化の変化であり、特にチームの自律性、迅速なフィードバック、高い共感と信頼、チーム間のコラボレーションを通じて行われます。

マインドフル シンキングのロゴ
関連資料

顧客優先の考え方を受け入れる

トロフィーのロゴ
関連資料

DevOps のメリットに関する詳細

DevOps では責任の共有が伴います。開発スタッフと運用スタッフの両方が、製品の成功または失敗に責任を負う必要があります。開発者は単に構築して運用チームにハンドオフするだけでなく、「構築した者が運用する」という考え方に則り、製品のライフサイクル全体を通じて製品を監督する責任を共有することが求められています。開発者はソフトウェアのテストと運用を行い、QA と IT Ops とのコラボレーションをさらに進めます。運用チームが直面する問題を理解すれば、デプロイと保守を簡素化できる可能性が高くなります。同様に、運用チームがシステムのビジネス目標を理解すれば、開発者と協力してシステムの運用ニーズを定義し、自動化ツールを採用できます。

自律型チームは、DevOps のもう 1 つの重要な側面です。開発チームと運用チームが効果的にコラボレーションするには、面倒で時間のかかる承認プロセスを必要とせずに、意思決定を行って変更を実装する必要があります。これには、チームに責任を移譲すること、失敗を恐れずにすむ環境を確立することが含まれます。これらのチームは、顧客に対するリスクのレベルごとに、迅速かつ容易に意思決定を行うための適切なプロセスとツールを用意する必要があります。

たとえば、一般的な開発ワークフローでは、コードの変更をデプロイするために、異なるチームにいる複数の貢献者の関与が必要になる場合があります。開発者がコードを変更してソース管理リポジトリにプッシュし、構築エンジニアがコードを構築してテスト環境にデプロイし、プロダクト所有者が課題追跡ツールで作業のステータスをアップデートする、などです。自律型チームはこれらのプロセスを自動化するツールを活用するため、新しいコードをプッシュすると新しい機能の構築とテスト環境へのデプロイがトリガーされて、課題追跡ツールが自動でアップデートされます。

たとえば、チームにとって、新しい DNS エントリなど、些細なインフラストラクチャの変更でも別の運用チームにチケットをオープンしなければならないといった要件が負担になっています。この場合、数秒で完了すべきタスクが、数日または数週間もかかってしまいます。自律型チームは、適切なスキルと経験を持つ個人をチームに加えるか、セルフサービス ツールにアクセスすることで、このような変更を自ら実装できます。

DevOps チーム文化は、統合された開発および運用チームの継続的な改善に役立つ迅速なフィードバックを重視しています。開発チームと運用チームがサイロ化されて孤立している環境では、本番環境におけるアプリケーション ソフトウェアのパフォーマンスと安定性に関するフィードバックは、得られたとしても開発チームに渡すのが遅くなることがよくあります。DevOps は、アプリケーションの監視やレポート戦略を設計して実装する運用担当者間のコラボレーションを求めることで、開発者が迅速な反復によりアプリケーション コードを改善するのに必要な迅速なフィードバックを得ることを保証します。たとえば、十分な機能を備えた継続的インテグレーション ツールなら、新しいコード プッシュの自動構築とテストが可能になり、開発者はコードの品質に関するフィードバックを即座に得られます。

自動化は優れたコラボレーションを可能にしてリソースを解放するため、DevOps 文化にとって不可欠です。ソフトウェア開発チームと IT チーム間のプロセスの自動化と統合によって、ソフトウェアはより迅速かつ確実に構築、テスト、リリースできるようになります。

DevOps 文化のメリット


DevOps 文化を受け入れることで得られる最も明白でインパクトのあるメリットは、ソフトウェア リリースが合理化されて頻繁になり、品質が高められることです。これによって、企業の業績だけでなく従業員の満足度も向上します。

書籍『Accelerate: Building and Scaling High Performing Technology Organizations』によると、DevOps 文化は高いレベルの信頼とコラボレーションを促進し、その結果より質の高い意思決定をもたらし、仕事満足度をさらに高いレベルに引き上げます。

DevOps 文化を受け入れることは、従業員の満足度を犠牲にすることなく、高い実績を上げるエンジニアリング組織を構築するための鍵となります。従業員と組織の双方に利益があります。エンジニアにとって、安定した高性能ソフトウェアを頻繁かつ簡単にデプロイして実行し、ユーザーを満足させられるほど気分のいいことはありません。また、経営幹部にとっては、ビジネス成果が改善されれば満足できます。

問題は何か?


DevOps 文化を完全に受け入れるには個人やチームの仕事の方法を大幅に変更する必要があるため、組織の最高幹部からの賛同が必要です。

草の根の取り組みは、DevOps 変革のための賛同を管理者および経営幹部レベルから得るための重要な出発点になる可能性があります。多くの場合、実際にそうなっています。多くの場合、DevOps を広い範囲に導入するための議論は、少数の個人または小規模なチームが DevOps アプローチを採用して成功を実証し始めるときに、最も説得力があります。

DevOps 文化に見られる典型的な高いレベルの自律性と信頼性を培うことが難しいのは、関係する個人またはチーム間で対立の歴史がある場合です。DevOps アプローチを採用しようとする前にチームがサイロ化していればいるほど、つながりを構築するのが難しくなります。

変化は難しいものです。既存の個人とチームの間で高いレベルの調和がある環境であっても、変化のメリットがはっきりせずに明確に理解されていない場合、取り入れることを容認する気持ちや意欲を高めることは難しい可能性があります。

当然、エンジニアリングに関する考え方がしっかりしている組織は、ビジネス上の問題を解決するためのツールやテクノロジーをすぐに採り入れることが多いでしょう。もちろん、組織が DevOps アプローチに移行するのに役立つツールやテクノロジーは用意されています。しかし、文化を変えないままツールやテクノロジーを変えることは、基盤にある弱点に対処せずにうわべだけを変えることになるため「カーゴカルト DevOps」とよく呼ばれています。

DevOps 文化への移行に関する考慮事項


オープンなコミュニケーション

DevOps で対処しようとする最も基本的な問題の 1 つは、さまざまな組織単位における知識、経験、作業のサイロ化です。コードを記述するプログラマーと、それをデプロイして保守するシステム管理者がコミュニケーションを取らなければ、おそらく何の効果も得られません。

間違いを犯す能力

多くの組織、チーム、個人は、決して間違いをしないように、自分自身とお互いに異常なまでのプレッシャーをかけています。失敗が許されない場合、個人やチームは問題を解決したり、革新的な機能を開発したりするための新しいアプローチを試みようとしなくなります。

この考え方は、MTTR (平均復旧時間) よりも MTBF (平均故障間隔) の測定にこれまでこだわっていたことに反映されています。MTBF では「根本原因分析」などのツールを使用して障害の原因を特定し、障害が再発しないようにします。MTTR では、ソフトウェア アプリケーションを予測不能な方法で障害が発生しやすい複雑なシステムとして捉えて、障害が発生した場合も迅速な回復に重点を置いています。

「誰も責めないふりかえり」は DevOps 文化に浸透している姿勢の 1 つです。スプリントやプロジェクトの最後にチーム ミーティングを行って、何がうまくいったかと何が改善できるかをオープンで安全な環境で話し合うことで結果を改善できます。

失敗しても誰も責めない姿勢が非常に功を奏している理由の一部は、誤りは起こるものであると認めつつ、人も組織も学習、成長、改善できると仮定して行動するという成長思考を採用しているためです。
- 『Effective DevOps (4 本柱による持続可能な組織文化の育て方)』 Jennifer Davis、Ryn Daniels 著

新しい一連のプロセス

DevOps 文化を育むには、古い問題に対して新しいアプローチを開発する必要があります。DevOps では、プログラマーが記述したコードを運用チームに「丸投げ」して、運用チームがアプリケーションをデプロイして運用するというサイロ化されたプロセスを変更する必要があります。DevOps のアプローチでは、プロジェクトのライフサイクル全体を通じて開発と運用を連携させる必要があります。

継続的インテグレーションと継続的デリバリー (CI/CD) は、DevOps 文化に必要なものと一般的に考えられています。第 3 のプロセスである継続的デプロイは Netflix のような大規模な組織では受け入れられて推進されていますが、ほとんどの中小企業では一般的に採用されていません (または不要だとされています)。これは、新しい機能を本番環境に継続的にデプロイするには、新しいコードが詳細にテストされており、安全にデプロイできるという高い信頼性が求められるためです (例: 機能トグルの裏にあるコードなど)。したがって、組織が 1 日に何度もデプロイしない限り、このアプローチをサポートするプロセスに投資する価値はないかもしれません。

「トランクベース開発」の何らかのバリエーションを実行すると、ほとんどの場合は CI/CD の作業が大幅に簡素化されます。このモデルでは、チームは有効期間が長い機能ブランチを廃止して、コードの「トランク」ブランチを頻繁にコミットします。

トランクベース開発の重要な構成要素は、包括的な自動テスト (ユニット、統合、回帰) です。これによって、トランク ブランチに対するすべての新しいコミットがリポジトリにプッシュされたときに精査されます。

継続的インテグレーションは、ソフトウェア プロジェクトへの複数の貢献者によるコード変更を自動で統合するプロセスです。これは開発チームに留まらず、組織の他の部分にも及びます。たとえば、製品チームは、機能や修正プログラムを順次起動するタイミングと、どのチーム メンバーが担当するかを調整します。

継続的なデリバリー (CD) は、設計、製品、マーケティングなどのエンジニアリング チームと非エンジニアリング チームを結集して製品を提供する組織的な手法です。CD のない環境では「丸投げ」の姿勢が助長されて、開発者は基本的なユーザー エクスペリエンスでは QA チームに専念します。この手法では、リポジトリの「トランク」ブランチが常に「デプロイ可能」状態になります。

継続的デプロイによって、コードの変更は、機能フラグの裏で見えない形で行われた、少数の顧客へのデプロイとして行われた、あるいは簡単にロールバックできる形で行われた場合は、本番環境に自動でデプロイされます。これによって、チームは顧客からのフィードバックに反応して新機能を迅速にデプロイして検証できるため、変化する市場や顧客の需要により柔軟に対応できます。また、簡単にロールバックできるため、ビルドが壊れてチームが活動できなくなることはありません。

新しいアプリケーション機能が本番環境にデプロイされたときに表示されないように、または機能しないようにするために、機能フラグ、機能トグル、ダーク デプロイは一般的な方法ですが、最小限の労力でオンにできます。この戦略によって、ユーザーに悪影響を与えるリスクがほとんどなくなるため、継続的デプロイが可能になります。また、ユーザー ベースのサブセットに機能を制限することもよくあります。これは、地理的地域でユーザーをセグメント化して、または個別にサーバー インスタンスを実行してユーザーがアクセス可能な 1 つのサーバーのみに機能をリリースして実行します。

アップデートされたツールチェーン

ほとんどのソフトウェア開発チームは、少なくともある種のバージョン管理、問題追跡、アプリケーション監視の各ツールを使用しています。これらはすべて DevOps 文化をサポートする上で重要なツールですが、おそらく従来のツールセットに追加される最も重要な機能は CI/CD をサポートするソフトウェアです。コミット、テスト、デプロイを行う自動化されたワークフローを用意することは、DevOps 文化が必要とする迅速なフィードバックが得られる唯一の方法です。

DevOps - 結果を生み出す文化的シフト


開発者は何十年もの間、より少ない労力でよりバグの少ないソフトウェアをより頻繁に提供するという夢を追ってきました。今ここに、これを実現するためのツールとプラクティスがついに登場しました。

アトラシアンが DevOps を実践している組織を調査したところ、デプロイの頻度を増やして市場投入までの時間を短縮しながら (49%)、より質の高い成果物 (61%) をリリースしていることがわかりました。また、メリットを得ているのは組織だけではありません。実践者は「新しいスキルが身に付き (78%)、昇給を受けた (48%)」と回答しています。

DevOps 文化を育むことは簡単ではありませんが、開発者、マネージャー、顧客の満足度が一様に高まって得られる利益は、それだけの苦労をする甲斐があります。

DevOps 文化を向上させようと思っていますか? サービス チーム ヘルス モニターから始めましょう。また、DevOps 文化の構築に役立つ 4 つの主なプレイによって、同僚とのコミュニケーション、コラボレーション、ブレーンストーミングを練習しましょう。

Tom Hall
Tom Hall

Tom Hall は DevOps アドボケートかつ実践者であり、熱心な読書家、そしてアマチュア ピアニストでもあります。
過去 20 年間にわたる実績には、Novell、EMC、VMware、AWS の認定が含まれます。2016 年にアトランタで DevOpsDays の企画をサポートして以降、テキサス州オースティンの開催を何年もサポートしてきました。


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

シミュレーション ワークショップ

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up