DevOps 導入を阻む 3 つの要因

いいえ、あなたではありません。 あなた。 経営陣は現場の人たちほど DevOps に夢中ではありませんが、その答えは次の 3 つの主要な懸念事項のいずれかに見つかるかもしれません。

優れた業績を上げている組織は、DevOps を採用しただけでなく、積極的に取り入れています。 Puppet Labs の画期的な State of DevOps レポートは、過去 2 年間にわたってこのことを示してきましたが、来年もこの関係がさらに強化されると思います。 数多くの業界調査や研究によると、組織は DevOps を採用しています。 しかし、過去にアジャイルでリーンなアプリ開発手法を採用したのと同様に、採用は必ずしも私たちが考えている意味と同じことを意味するわけではありません。 組織がアプリ開発に「アジャイルを採用する」ことで実際に意味しているのは、アジャイルを使用しているプロジェクトが比較的少数であるということであることが分かりました。 それは、彼らがあらゆるプロジェクトにそれを導入して、全力で極地へ飛び込んだという意味ではない。

DevOps についても同じことが言えるようです。回答者は熱心に導入し、成果を上げていますが、経営幹部は全体としてこのアプローチにまだ冷淡なようで、当社のアプリケーション配信の現状調査によると、「戦略的影響」は前年比でわずか 2 パーセント ポイントしか増加しておらず、2016 年の 15% から 2017 年の 17% となっています。 クラウド アーキテクトや自称「DevOps」の役割を担う人々は、DevOps イニシアチブに全力で取り組み、運用の枠を超えているかもしれませんが、経営幹部は依然としてこのアプローチの採用に遅れをとっています。 つまり、「組織」は必ずしも DevOps を全面的に採用しているわけではないということです。

IT 部門とビジネス部門のリーダーが DevOps を真に温かく歓迎できない原因となっている主な懸念事項が 3 つあります。

1. 時間。 従来型からクラウドへ、モノリスからマイクロサービスへ、手動から自動化へなど、移行の考え方を必要とするあらゆる種類の社内 IT プロジェクトは、時間の無駄になるだけの提案としか見なされないことがあります。 これらはビジネスの成長に直接貢献するものではないため、このようなプロジェクトに費やす時間は、ビジネス関係者にとってサポートが面倒になる可能性があります。 DevOps を支持する人々は、ビジネス リーダーに対して、このようなプロジェクトに着手することで得られる明確な目標と期待されるメリットを示す必要があります。 コスト削減であれ、IT の応答性の向上であれ、企業が投資に対する予想される投資回収を理解し、その取り組みに賛同してもらい、サポートしてもらうことが重要です。 節約した1ペニーは稼いだ1ペニーと同じかもしれませんが、投資した1ペニーは稼いだ10セントと同じになることがよくあります。 今 DevOps に投資すれば、組織は後でその恩恵を受けることができます。
    
2. 混乱。  IT リーダーは誰もビジネスの混乱の原因になりたくありません。 今 DevOps イニシアチブに投資すると、特に、スピードアップが必要であることが誰もがわかっているときに、生産パイプラインの速度低下を引き起こす場合は、混乱を招く可能性があります。 自動化とオーケストレーションのための生産を有効にすることは、日常業務を担当するシステムを変更することを意味することが多いため、それを必要とする取り組みは望ましくない混乱を引き起こす可能性があります。 現実には、システムのプロビジョニング、拡張、管理に時代遅れの手動の方法に頼ることは、今日でなくても明日には本当の混乱を引き起こす可能性があります。 摩擦のない生産環境の特徴の 1 つは、容量とサービスのニーズにオンデマンドで対応できることです。 デジタル変革の取り組みによって増大する需要の重圧に IT 部門が屈するにつれ、これを達成することはますます困難になっています。 リスクがなければ報酬もない。 今リスクを負うと、アプリケーション ポートフォリオが 2 倍以上に成長したときよりもリスクが低くなる可能性があります。
    
3. ロックイン。 IT リーダーが一般的に恐れるのは、選択によって「ロックイン」されてしまうことです。 幸いなことに、自動化とオーケストレーションをサポートするネットワーク デバイスとシステムの大部分は、HTTP、REST、JSON などのオープン スタンダード プロトコルと概念に基づいています。 ここで、API とテンプレートを最大限に活用するシステムの設計と構築に事前に費やした時間が、後で報われることになります。 CLI が発行したコマンドを API 経由で段階的に再現する必要があるデバイスまたはシステムと統合すると、ほぼ確実にロックインが発生します。 これはテンプレートの最大の利点の 1 つです。デバイスやシステム固有の API への依存を減らし、将来新しいシステムやアプリに簡単に移行できる少数のコマンドのみを公開することを制限します。  インフラストラクチャが REST ベースの API をサポートしていることを確認し、可能な場合はテンプレートを使用して、後でシステムや環境から簡単に抽出できるようにします。

もちろん、他にも懸念事項はありますが、主にこれら 3 つの主要な懸念事項は、テクノロジーと方法論の採用に関して、データ センター全体にわたって、また時間を超えて響き渡っています。 時間がかかり、混乱を招き、ロックインされる可能性も非常に高くなります。 デューデリジェンスと実装に対する思慮深いアプローチ、そして「今投資して後で利益を得る」という姿勢により、こうした懸念が軽減され、現在および将来のビジネスの成長に必要なデジタル変革を可能にするだけでなく、それを加速する、強固でありながら柔軟な基盤をうまく構築できる可能性が高まります。