なぜDevOpsの導入は失敗することが多いのか（そしてどうすれば解決できるのか

この記事は以下のサイトに掲載されました。 DevOps.com.更新され、修正されています。

ブロックチェーン」、「ビッグデータ」、「デジタル・ディスラプション」などと同様に、「DevOps」という言葉も、現在、大企業のIT部門で飛び交っているバズワードの一つです。

多くの人が、ソフトウェア開発ライフサイクルの短縮化の必要性を（正しく）認識しています。ビジネス目標に密接に沿った、より正確なプロセスにより、開発チームと運用チームの間で明確なワークフローとコラボレーションが可能になります。DevOpsは本質的に「アジャイル」な開発であり、常に革新的で迅速な展開を行う現代のビジネスのニーズに対応するために成長したものです。セキュリティの専門家にとっても、DevOpsは素晴らしい取り組みです。プロセスにセキュリティを導入することで、バグ修正のコストを削減し、将来起こりうる大惨事を回避することができます。

問題は、DevOpsの導入で本当に成功している企業が少ないことです。ビジネス全体で適切なサポート、育成、理解が得られなければ、すぐに「白い象」のような存在になってしまいます。

では、何が問題なのでしょうか？これは興味深い議論ですが、DevOpsをより円滑に進めるためのアプローチ方法がいくつかあります。効果的なプログラムは、いくつかの派手な新しいツールや肩書き、チームミーティングを超えたものです。常に簡単というわけではありませんが、時間をかけて壊れた戦略を修正する（あるいは最初から正しい方法で導入する）ことは、長い目で見ればはるかに苦痛が少ないはずです。そして最終的には、より高品質で安全なソフトウェアを生み出すことになるでしょう。

それを分解してみましょう。

アジャイル」というエプロンの紐を手放してください。

組織はアジャイルかDevOpsのどちらかを選ばなければならず、どちらかの道に進み、後戻りはできないという誤解があります。実際には、両方を考慮し、1つのものとして実装したときに、開発プロセスは最もうまく機能します。DevOpsは、アジャイル開発の再発明ではなく、むしろその延長線上にあります。プロセスがアジャイルと全く同じであるか、アジャイルとは全く異なるものであるかという期待があると、歯車が狂いがちになります。

アジャイルは、デザイナー、テスター、開発者が最初から一緒に仕事をするクロスファンクショナルチームの原則を支持し、プロジェクト全体を通してオープンなコミュニケーションラインを約束します。アジャイルの目的は、サイロ化したデリバリーを止め、二重処理を減らすことですが、これはDevOpsプロセスの利点でもあります。しかし、DevOpsはさらに一歩進んで、システム、セキュリティ、オペレーションをミックスして、お客様に完全で機能的なソフトウェアを提供することを最終目標とした、堅牢でエンドツーエンドなスキルセットを提供します。

よりDevOpsを中心としたプロセスに移行する際に避けられない苦痛の中で、サイロ化した開発のリスクが再び浮上することがあります。元々のアジャイルチームが一緒に仕事をしていても、セキュリティやオペレーションの担当者がまだ機械の中に入っていないことがよくあります。

DevOpsは、明確に定義された目的、部門を超えたオンボーディング、すべての関係者との直接的なコミュニケーションなしには機能しません。慎重な変更管理を必要とする調整期間があるのは確かですが、DevOps機能がもたらす機能強化について全員が同じ見解を持つことは、戦いの半分です。

最近では（ありがたいことに）、DevOpsはプロセスの一部としてセキュリティのベストプラクティスを重視するようになってきており、このステップを解明し、セキュリティチームとその他の人々との間のギャップを埋めています。前にも述べたように、開発者が最初から安全なコードを書けるようにするには、まだまだ長い道のりがあります。しかし、DevOpsの方法論をうまく導入することは、開発チーム内でセキュリティ・スキルを構築するための優れた基盤となります。

自動化がすべてではありません（そして、最も安全ではありません）。

DevOpsのもう一つの特徴は、ソフトウェア開発プロセスをある程度自動化することです。継続的インテグレーションと継続的デリバリ（CI/CD）の原則は、このコンセプトの基礎であり、推測できるように、非常にツールに依存しています。

ツールは素晴らしいものです、本当に。ツールは、コードリポジトリ、テスト、メンテナンス、ストレージの各要素を比較的シームレスに管理することで、ソフトウェア開発プロセスにかつてないスピードをもたらします。

しかし、いつかはロボットが私たちの仕事を奪い、私たちを投獄するかもしれませんが、まだそこまでには至っていません。ツールや自動化への依存度が高いと、エラーの余地が大きくなります。スキャンやテストではすべてを発見できないかもしれませんし、コードがチェックされないかもしれません。そうなると、セキュリティはもちろんのこと、品質面でも大きな問題となります。攻撃者は、データを盗むためのバックドアを1つ開けさえすればいいのですから、品質とセキュリティの管理に人間の要素が欠けていると、悲惨な結果になりかねません。

ハッピーミディアム」とは、人とツールのバランスをとることです。ツールは、プロジェクトの目標を達成するために、信頼できるチームのアシスタントとしての役割を果たすべきです。そうすべきです。

• 選択したDevOpsツールチェーンに慣れるための十分な時間を確保する。
• 効果的なコラボレーションに焦点を当てる（ツールがどのようにそれをサポートするかについても
• スキルや知識、ツールなど、プロセス上のギャップを解消する。

要するに、ただ「道具をそろえる」だけではダメだということです。

DevOpsはバズワードではなく、文化です。あなたは自分の文化を育てていますか？

チェンジマネジメントは、最高の状態では困難です。

「DevOpsをやろう」と言ってオペレーションチームのデスクを移動させただけでは、魔法のようにプロセスを成功させることはできません。多くの人が混乱し、長く働いているメンバーは不満を感じているでしょう。期待されていることを伝えることは、"歩く "ことと同様に重要です。DevOpsは開発手法と同様に文化的なムーブメントであり、チームはクロスファンクショナルでコラボレイティブなマインドセットを実践しなければなりません。

優れたDevOps文化とはどのようなものでしょうか？

• リーダーだけでなく、個人にも専門知識を提供する権限が与えられている
• チーム間のオープンで、正直で、尊敬に満ちたコミュニケーション
• 開発プロセスに品質とセキュリティを組み込むという全体的な目的に対して、各担当者が責任を持つ
• ビジネスにおけるDevOpsの定義、ロードマップ、各人の役割のhow/what/whyについて、全員が同じ見解を持っています。

私は長年にわたり、開発チームにおいて積極的なセキュリティ文化を構築することの重要性を強調してきましたが、それはDevOpsも同様です。

セキュリティのベスト・プラクティスを達成し、発見された脆弱性を減少させ、データ保護の重要性にチームの目を向けさせるには、適切なツール、知識、サポートが不可欠です。DevOpsでは、ポジティブな変化のための文化的基盤を築く必要があります。つまり、全員が自分の役割、価値、期待、プロジェクト全体の目標、プロセスのステップを理解できるようにしなければなりません。

それはマスターしていますか？素晴らしいですね。次は、針を移動させ、セキュリティ面を強化して、DevSecOpsをソフトウェア・エクセレンスのための究極のプランにしましょう。