公開日05 Apr 2023
最小読み取り時間
Views
DevOpsが注目されている。世界が堅牢なソフトウェア駆動型の未来に向かうにつれて、DevOpsプロジェクトの数とスコープが増加しているのを目の当たりにしている。 これには、組織レベルでの大規模な実装から、継続的インテグレーションと継続的デリバリー（CI/CD）の課題に対処するためのテクノロジーやソリューションまで、幅広い活動が含まれる。
さまざまなシナリオがあるように見えるが、すべてのDevOpsプロジェクトに共通するのは、変革の旅路における文化的側面とリーダーシップの側面である。
そして、DevOpsはまさに旅なのだ。
DevOpsは、特定された課題を解決するために開発チームと運用チームを組み合わせたり、統合したりするだけのものだという誤った見方がある。実際、DevOpsはCI/CDのためのツール以上のものだ。文化的な変化、新しい仕事の進め方、そして活性化したリーダーシップが、チームの変革のカギを握っているのだ。
ここでは、グローバルに展開する大手顧客がIT開発と運用の現状を把握し、DevOps変革の旅を再定義するのを支援した経験から得た学びと教訓を紹介する。
それはどのようなものだったのか？
顧客のリーダーシップと話す中で、ITサービスをビジネスに提供できないことが原因で、組織が生産性、収益性、市場シェアを失っていることが明らかになりました。IT部門は、ソフトウェアの納期を守るという約束を守ることができませんでした。私たちは、ソフトウェアデリバリーとオペレーション（SDO）のパフォーマンス全体にわたって、以下のようないくつかの懸念を特定しました：
- ビジネスへの機能提供のリードタイムが長い、
- 開発段階でのビジネス関与の欠如、
- 後工程での品質問題による納期遅れ、
- 自動化の欠如と手作業による引き継ぎの多さ。
- 開発チームとオペレーション・チーム間のサイロ化したアプローチ。
この困難なシナリオを念頭に置きながら、我々がどのように彼らのDevOpsパラダイムを再構築したかを見てみよう。
まず、 DevOpsリーダーシップの提供- これがDevOps導入の成功の鍵です。私たちは、変革の取り組みが不十分なために、いくつかの変革プロジェクトが失敗することに気づきました。 これには以下が含まれる：
- DevOps実装の「なぜ」 の部分を定義していない、
- DevOpsの必要性に関する緊急性の欠如、
- DevOpsトランスフォーメーションに対する不十分な戦略、
- 利害関係者との明確で大きなコミュニケーションが取れていない、
- ビジョンの欠如と最終的なゴールが見えない。
- 文化的な変革に考えが及んでいない
私たちは協力してこれらの問題に対処し、リーダーシップの全面的な支持を確保し、「過剰なコミュニケーション」を通じて変革プランを組織に伝えました（私を信じてください - まさに医者の指示です！）。
私たちのチームは、適切な知識と適切なツールを使って、適切な文化を生み出すことができるように支援した。
したがって、活性化されたDevOpsの旅は、現在のビジネスと開発オペレーション、そしてデリバリープラクティスの初期評価（デューデリジェンス）から始まった。私たちは、顧客のリーダーシップ・チームとともに、この旅を最大限に活用するための優れたDevOps変革ロードマップの作成を支援した。
第二に、 文化的な変革とアジャイルの推進- DevOpsはまさに人材に関するものです。組織はしばしば、チーム間のコミュニケーションの凍結、サイロ化した階層構造、製品開発のエンドツーエンドのビジョンの喪失をもたらすコミュニケーションの障壁に悩まされている。したがって、最大の課題の1つは、文化的な必要性を測定し、強固で効果的な変革プランを設計することである。
アジャイル変革は、チームの習慣を変え、新しい仕事のやり方や考え方を採用するための鍵である。私たちの変革手法の結果、分隊と呼ばれる約25のアジャイルチームが、特定の製品ベースのポートフォリオの価値の流れに組織された。スモールバッチ、作業の流れの可視化、頻繁なデリバリー、フィードバックが、分隊のマインドセットに変化をもたらした。
マインドセットとデリバリー・プロセスの完全な変化を確実にするために、文化改革ドライブ、トレーニング・キャンプ、アジャイル会議が手配された。
次の段階は、CI/CDプラクティスの組織全体への導入である。
CI/CDの導入 - 私たちのチームは、お客様が組織全体で整然と継続的デリバリーを導入できるよう支援しました。私たちはパイロットプロジェクトを実施し、ソフトウェアのデプロイ方法を自動化・標準化することで、各ビジネスラインとテクノロジーにおける成功を測定しました。
この変革の間、リリースプロセスを合理化するための段階的な改善が行われた。その結果、主要な配備リスクと痛みが特定され、リリース・プロセスが反復され、継続的な改善を通じてさらなる安全性が確保された。図2（下図）は、典型的な継続的デリバリーのパイプライン（ソース、ビルド、テスト、本番）を示しています。
図2：典型的な継続的デリバリーのパイプライン - ソース、ビルド、テスト、本番環境
DevOpsは、一般的に言われるように、継続的な旅である。しかし、その成果は最初から明らかだ。
先にお話ししたインスタンスでは、エンタープライズレベルの実装がまだ進行中ですが、私たちは励みになる結果を観察し始めています：
- 欠陥が50％減少し、納品された製品の品質が向上した、
- 従業員のエンゲージメントが向上し、開発者が満足している、
- パイプラインの改善、強化、拡張、
- UATのためのステージング環境への新しい統合、
- 納品頻度の20%増加
- 従来の手作業による引き継ぎを自動化することで、リードタイムを90日から60日以下に短縮。
この結果は、DevOpsの実装アーキテクチャー・プロセスをより深く変革するために、サイトの信頼性プラクティスと観察に取り組む私たちを鼓舞してくれます。パイプラインの効率化、アプリケーション・アーキテクチャの近代化、作業方法、考え方、行動を改善することで、すべての利害関係者の利益のために、この旅は強化されるだけである。
カスタマイズされた内部DevOpsプラットフォーム（IDP）は、DevOpsエンジニアとITオペレータの負担となっている複雑さの大部分を取り除くことができ、ここでのゲームチェンジャーとなることが証明できる。このアイデアは、顧客/開発者がDevOpsツールチェーンを作成するために必要なライセンスを使用して、好みのツールを構成できるようにすることである。これによって、開発者は継続的な学習と実験を経験し、DevOpsの旅全体の成果を最大化し、プロセスの共同成功を強調することができる。
変化が起きたとき、それは静かでありながら強力なものになるだろう。結局のところ、最も深い革命は最も静かなものであることが多いからだ。
