DevOps のカルチャの詳細

• 7 分

カルチャは DevOps にとって不可欠な基盤です。成功を収めるには、成長と継続的な学習の考え方が必要なためです。 リーダーシップのサポートは、その成功にとって重要な要素の 1 つです。

DevOps のカルチャがどのようなものかを説明する前に、DevOps を採用する組織の能力におけるカルチャの役割について考えてみましょう。 Gartner 社によると:

カルチャ的な抵抗と低レベルのプロセス規範により、DevOps イニシアチブの失敗率は非常に高くなります。

『Phoenix Project and DevOps Handbook (フェニックス プロジェクトと DevOps ハンドブック)』の著者である Gene Kim は、次のように述べています。

DevOps は課題だらけの過程です。こうした課題の原因が間違ったテクノロジや間違ったプロセスだけの場合はほとんどありません。 実際、最大かつ最も困難な障害はカルチャである傾向があります。 そして、カルチャを間違えた場合、他のすべてが正しいとしても、イライラ、追加コスト、そして失敗につながる可能性が高くなります。

カルチャとは

ここでの目的として、カルチャとは、あるグループが持つ社会的遺産です。 これは、メンバー間、およびメンバーとその環境間の相互作用から生じる問題を処理するグループの履歴の中で、発見、発展、または考案された応答のパターンです。

カルチャによって、次のことが決まります。

• 何が許容できるか、許容できないか。
• 重要なものか、重要ではないものか。
• 何が正しいか、間違っているか。
• 何を実行できるか、実行できないか。
• 誰を雇用するか、解雇するか、昇進させるか。

DevOps イニシアチブが失敗する理由

Gartner 社の調査によると、リーダーが使用する管理アプローチの制限が原因で、2023 年までに DevOps イニシアチブの 90% が失敗することが示されています。

クリエイティブな仕事をしている人には、やる気を出すために "休憩室でビール" は必要ありません。 そうではなく、クリエイティブな人に必要なものは、専門的技能、自律性、そして目的です。

Microsoft の成功の中で最も重要な部分は何かと問われたら、ビジョン、戦略、それとも実行でしょうか。 Microsoft の CEO である Satya Nadella は、それらすべてが重要であると述べました。最終的に、それが目的と成長の考え方になりました。

DevOps の考え方を示す 12 個の例

ここでは、アクティビティの考え方ではなく、DevOps の考え方を示す 12 個の例 (リーダーシップの考え方、顧客重視、リーン思考、システム思考、無駄の排除、制約の理論、連携と自律性、シフトレフト テスト、セキュリティの考え方、仮説駆動型開発、ライブサイト、測定結果) を紹介します。

リーダーシップの考え方

Gartner 社は次のことを推奨しています。

• DevOps イニシアチブを主導するために必要な特定の行動特性に優先順位を付け、技術的スキルセットにあまり重点を置かずに、変革のリーダーを特定する。
• 失敗を学習の機会として受け入れることにより、変革のリーダーを育成する。
• 勘で推測することなく判断を下せるように、明確な目標と主要な指標を用意することで、変革のリーダーを管理する。

DevOps は革新的なものなので、インフラストラクチャと運用 (I&O) のリーダーは、先見の明があり、適応力があり、人の意欲を引き出し、人に自信を与え、説明責任を果たす候補者を特定する必要があります。

顧客重視の考え方

顧客重視とはどういう意味でしょうか。

• 顧客の声に耳を傾け、コミュニケーションをとる
• 重要なことを測定する
• 運用環境の赤信号を受け入れる
• 構築、測定、学習
• 適切な展開のために機能の切り替えを使用する
• 広範に、ただし慎重にデータを収集する

リーン思考の考え方

価値: リーン思考の考え方は、顧客が製品やサービスにどのような価値を割り当てているかを詳しく把握することから始まります。 組織は、顧客が期待する価値を最高レベルの収益性で提供できるように、無駄を排除することに重点を置いています。

バリュー ストリームには、原材料から顧客の使用、そして最終的な製品の廃棄まで、製品のライフサイクル全体が含まれます。 リーンの最終的な目標である無駄の排除には、バリュー ストリームを正確かつ完全に理解する必要があります。

フロー: 無駄をなくすには、フローを理解することが不可欠です。 どこかの時点でバリュー ストリームが前に進まなくなった場合、無駄は避けられない副産物です。 リーン生産方式のフローの原則は、生産プロセスを中断することなく、各アクティビティの歩調を互いに合わせてバリュー チェーンを作成することです。

プル: プルのリーン原則は、事前に何も作らないようにすることでフローを確保するために役立ちます。これにより、仕掛品の在庫が蓄積され、同期されたフローが止まることを防ぎます。 プル アプローチは、予測とスケジュールに基づいて作業を進めるという従来の米国の製造アプローチを使用するのではなく、顧客が注文するまで何も行わないように指示するものです。

完璧: リーンの実行者は完璧を実現するために努力します。 継続的改善によって品質の問題と生産廃棄物の根本原因が解決されるにつれて、完璧なプロセスに向かって前進します。 完璧さの絶え間ない追求は、競合相手よりも深く掘り下げ、より多くの測定を行い、より頻繁に変更するようにこのアプローチの使用者を駆り立てるものです。

システム思考の考え方

システム思考の考え方は、特定のサイロの仕事や部門のパフォーマンスではなく、システム全体のパフォーマンスを重視します。

IT によって実現されるすべてのビジネス バリュー ストリームを重視します。 つまり、ビジネスや IT によって要件が特定されたときから始まり、開発で構築され、IT 運用に移行し、その価値がサービスとして顧客に提供されるまでです。

無駄の排除の考え方

リーンの考え方は、顧客にとって価値のない 7 つの致命的な無駄を特定して取り除くことに重点を置いています。

• 部分的に完了した作業
• 余分なプロセス
• 余分な機能
• タスクの切り替え
• 待機中
• モーション
• 欠陥

制約の思考理論

制約の理論は、スループットを制限する制約 (ボトルネックとも呼ばれます) を特定して排除するための方法論です。 実行する場合、目標達成を阻む最も重要な要因を特定することから始めます。 その要因を、制限するものではなくなるまで、最小限に抑えるように取り組みます。

連携と自律性のバランスを取るという考え方

連携と自律性のバランスを取る必要があります。 連携が過度になると、イノベーション、モチベーション、コラボレーションが低下します。 自律性が過度になると、混沌、混乱、衝突が増え、一貫性も低下します。

シフトレフト テストの考え方

シフトレフト テストは、テスト プロセスを開発サイクルの早い時点に動かすことにより、ソフトウェアのテストを高速化し、開発を容易にするために使用されるアプローチです。 左にシフトとは、タイムライン上で左にテストを動かすことを指します。 これにより、早期の品質向上や問題特定が可能になり、手戻りの無駄を減らすことができます。

開発サイクルの後半まで待つ従来のテスト モデルは、開発のボトルネックになる可能性があるため、シフトレフト テストは、高速レーン開発に適したモデルとして設計されています。

セキュリティの考え方

セキュリティの考え方を達成するには、チームで以下を行う必要があります。

• 意識を高める。
• 原則を定義する。
• 原則に基づいて行動する。

仮説駆動型開発の考え方

リーン製品アプローチを利用して短いサイクルで開発を行い、仮説駆動型開発を利用することで、小規模な実験を作成し、顧客からのフィードバックを受けて、データに基づいて判断を下せるようになります。

仮説駆動型開発のアプローチ:

• 仮定 (証拠なしで真実として受け入れられるもの) から始める
• テスト対象の仮説を明確にする
• 実験とテストを実行する
• 証拠 (結果のインジケーター) を検証する

ライブサイトの考え方

DevOps チームにとって、運用環境のような場所はありません。 すべての仕事は、顧客のエクスペリエンスをより良いものにすることです。

安定したハイ パフォーマンスなサイトを作成するには、継続的運用のベスト プラクティスを規律正しく継続的に適用し、サイトの正常性を維持します。

ライブサイト カルチャの主な要素は次のとおりです。

• 顧客が苦痛を感じる前に検出する
• データを利用する
• 根本原因が重要
• コードとして構成する
• 存続のために自動化する
• 率直になり、学ぶ

アクティビティの考え方ではなく、結果を測定する

人をどのように評価するかによって、人がどのように行動するかが変わります。 コードの行数、チームのバーンダウン、発見されたバグの数ではなく、使用量、速度、ライブ サイトの正常性を測定する必要があります。