チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。
「これがDevOpsと何の関係があるの？」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。
では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか？
PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。
避けられない変化を認識する
今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。
しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。
あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。
DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。
ビジョンへの賛同を得る
トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。
小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。
- アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。
- この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。
開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。
インセンティブの変化を理解する
PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか？
従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。
DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。
オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。
DevOpsを自分のものにする
チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。
DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。
このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。
指標を理解する
DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。
- 新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか？
- デプロイの頻度は？
- バグのトラブルシューティングにはどのくらいの時間がかかるか？
- 四半期ごとのダウンタイムはどのくらいか？
これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。
理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間（MTTA）と解決する平均時間（MTTR）に注目しますが、重要な指標はこれだけではありません。
これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。
カテゴリー ：DevOps
