DevOpsの実装が失敗することが多い理由（およびその修正方法）

この記事は最初に公開されました DevOps.com。更新および修正されました。

「ブロックチェーン」、「ビッグデータ」、「デジタルディスラプション」と同様に、「DevOps」という用語は、現在大規模組織のIT部門で使われているもう一つの流行語です。

多くの企業は、ビジネス目標と密接に連携した、より正確なプロセスであるソフトウェア開発ライフサイクルの必要性を（正しく）認識しています。このライフサイクルは、より明確なワークフローと、開発チームと運用ベースのチーム間のコラボレーションを可能にします。DevOpsは本質的に「アジャイル」開発であり、全員が成長し、絶えず革新され、急速に展開される現代のビジネスのニーズに応える準備ができています。セキュリティ専門家にとって、これは素晴らしい取り組みです。はるかに早い段階でセキュリティをプロセスに組み込めるため、バグ修正のコストを削減し、将来起こりうる大惨事を回避できます。

問題は、DevOpsの実装に本当に成功している企業はほとんどないということです。ビジネス全体で適切なサポート、育成、理解がなければ、あっという間に白紙の状態になってしまいます。ご存知のように、「戦争は言うまでもない」プロジェクトの一つです。

それで、何が問題なの？これは興味深い議論です。DevOps へのアプローチ方法には、はるかにスムーズな移行に役立つと私が信じている方法がいくつかあります。効果的なプログラムとは、いくつかの派手な新しいツール、タイトル、チームミーティングだけでは不十分です。必ずしも簡単なことではありませんが、時間をかけて失敗した戦略を修正する（あるいは最初から正しい方法で実行する）ことで、長期的にははるかに苦痛が軽減されます。そして最終的には、より高品質で安全なソフトウェアが生まれるでしょう。

分解してみましょう：

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

組織はアジャイルかDevOpsのどちらかを選び、どちらかの道を切り開き、決して振り返らないようにしなければならないという誤解があります。

重要なのは、開発プロセスは、両方を1つにまとめて検討し、実装するときに最もうまく機能することです。DevOpsはアジャイル開発の再発明ではありません。むしろ、アジャイル開発の延長です。プロセスに期待すると、車輪が外れてしまいがちです。まったく同じアジャイルから、あるいはまったく異なるアジャイルへと。

アジャイルは、デザイナー、テスター、開発者を最初から結びつけ、プロジェクト全体を通してオープンなコミュニケーションラインを約束する、クロスファンクショナルチームの原則をサポートしています。その目的は、サイロ化されたデリバリーを止め、二重処理を減らすことであり、どちらもDevOpsプロセスの利点でもあります。しかし、DevOps はさらに一歩進んで、システム、セキュリティ、および運用を組み合わせて、完全で機能的なソフトウェアを顧客に提供することを最終目標とする、堅牢でエンドツーエンドのスキルセットを提供します。

DevOps中心のプロセスへの移行という避けられない課題の中で、サイロ化された開発のリスクが再び高まる可能性があります。多くの場合、元のアジャイルチームが協力して、セキュリティと運用の追加がまだ組織に浸透している状態で、どのように組み込むべきか、何をすべきか、そして全体的な目標について誰も確信を持てません。

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

DevOpsは、プロセスの一環としてセキュリティのベストプラクティスにも重点を置くようになり、そのステップをわかりやすく説明し、セキュリティチームと他の全員との間のギャップを埋めるようになっています（ありがたいことです）。前に述べたように、開発者が最初から安全にコーディングできるようにするにはまだ長い道のりがありますが、DevOps方法論の実装が成功することは、開発チーム内でセキュリティスキルを構築するための優れた基盤となります。

自動化がすべてではありません（また、最も安全というわけでもありません）。

DevOps方法論のもう1つの特徴は、ソフトウェア開発プロセスにある程度の自動化を導入することです。継続的インテグレーションと継続的デリバリー（CI/CD）の原則はこの概念の基盤であり、ご想像の通り、ツールに大きく依存しています。

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

しかし、ロボットがいつの日か私たちの仕事をすべて奪い、私たちを投獄するかもしれないという可能性は否定できませんが、現時点ではまだ実現していません。ツールと自動化に大きく依存していると、エラーの可能性が大きく広がります。スキャンやテストですべてが検出されるわけではなく、コードがチェックされないままになることもあり、その結果、品質（言うまでもなく、セキュリティ） に多大な問題が生じます。攻撃者がデータを盗むために悪用するために必要なバックドアは1つだけです。品質管理やセキュリティ管理における人的要素を見逃すと、悲惨な結果を招く可能性があります。

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

• 選択したDevOpsツールチェーンに慣れるのに十分な時間を確保してください
• 効果的なコラボレーション（およびツールがそれをどのようにサポートできるか）に焦点を当てる
• スキルや知識に基づくものであれ、ツールに基づくものであれ、プロセスのあらゆるギャップに対処します。

要するに、「ツールアップ」して最善の結果を期待するだけではいけません。

DevOpsは流行語ではなく、文化です。自社の成長は進んでいますか？

変更管理は最良の時期でも難しいものです。未知への恐れは、最も優秀なチームメンバーでさえもスキルを磨き、視野を広げることを妨げることがあります。

ほら、単に「DevOps をやろう」と言って運用チームにデスクを移動させるだけでは、魔法のようにプロセスを成功させることはできません。多くの人が混乱し、長年勤務してきたチームメンバーは不満を感じるでしょう。期待を伝えることは不可欠であり、「歩みを進める」ことも重要です。DevOps は開発方法論であると同時に文化的なムーブメントでもあります。チームは部門横断的で協調的な考え方を貫くべきです。

優れたDevOpsカルチャーとはどのようなものでしょうか？

• リーダーだけでなく、個人が自身の専門知識をプロセスに活かす権限を与えられる
• チーム間のオープンで誠実で敬意のあるコミュニケーション
• 開発プロセスに品質とセキュリティを組み込むという全体的な目標については、各自が責任を負います。
• ビジネスにおけるDevOpsの定義、ロードマップ、各人の役割の方法・内容・理由について、全員が同じ認識を持っています。

私は長年、開発チームにおいてポジティブなセキュリティ文化を構築することの重要性を強調してきましたが、DevOpsも例外ではありません。

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

それをマスターしたの？素晴らしい。それでは、方針を転換して、セキュリティ面をさらに強化して、DevSecOpsをソフトウェア・エクセレンスの究極の計画にしましょう。