DevOps導入が失敗に終わる理由（そしてその解決策）

この記事はもともと DevOps.comに掲載されました。更新および修正が加えられています。

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

多くの人が（正しく）ソフトウェア開発ライフサイクルの迅速化の必要性を認識しています。ビジネス目標と緊密に連携したより精密なプロセスにより、開発チームと運用ベースのチーム間のワークフローとコラボレーションが明確化されます。 DevOpsの本質は、絶え間ない革新と迅速な展開を求められる現代企業のニーズに対応するために進化した「アジャイル」開発です。セキュリティ専門家にとってこれは素晴らしい取り組みです。プロセスにセキュリティを早期に組み込むことで、欠陥修正コストを削減し、将来的な重大な被害を未然に防げるからです。

問題は、DevOpsの導入に真に成功している企業がほとんどないことです。企業全体での適切な支援、愛情、理解がなければ、その企業はすぐに底なしの穴と化す可能性があります…つまり、いわゆる「戦争の話はタブー」とされるプロジェクトの一つになってしまうのです。

では、問題は何でしょうか？これは興味深い議論であり、DevOpsに取り組むいくつかの方法が、その航海をはるかにスムーズにすると思います。効果的なプログラムは、いくつかの新しい洗練されたツールや役職、チームミーティングを超えるものです。 常に容易とは限りませんが、機能しない戦略を修正する（あるいは最初から正しく導入する）ための時間を割くことは、長期的にははるかに苦痛が少ないでしょう。そして最終的には、より安全で高品質なソフトウェアへとつながります。

では、詳しく見ていきましょう：

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

組織はアジャイルかDevOpsかの二者択一を迫られ、一方の道を選んだら後戻りできないという誤解が一部にある。

問題は、開発プロセスが両者を一体として考慮し実装する際に最も効果を発揮する点にある。DevOpsはアジャイル開発の再発明ではなく、むしろその拡張である。プロセスがアジャイルと完全に同一か、あるいは全く異なる形で実行されることを期待すると、車輪が外れがちになる。

アジャイルは、設計者、テスター、開発者を初期段階から集結させ、プロジェクト全体を通じてコミュニケーションラインを開くことに注力するため、クロスファンクショナルチームの原則を支持します。 その目的は、サイロ化されたデリバリーを止め、二重管理を削減することであり、これらはDevOpsプロセスの利点でもあります。しかしDevOpsはさらに一歩進み、システム、セキュリティ、運用を統合することで、強固かつ包括的なスキルセットを提供し、最終的に顧客に完全かつ機能的なソフトウェアを提供することを目指しています。

DevOps中心のプロセスへの移行に伴う避けられない課題の中で、孤立した開発のリスクが再び浮上する可能性がある。多くの場合、元のアジャイルチームは協働する一方で、セキュリティや運用部門の参入は依然として組織内で居場所を探している状態だ。彼らをどう組み込むべきか、何を担うべきか、そして全体的な目標が何かについて、誰も明確に把握できていない。

DevOpsは、明確に定義された目標、部門横断的な連携、そして関係者全員との直接的なコミュニケーションなしには機能しません。適応期間が必要であり、変化を慎重に管理しなければならないことは間違いありませんが、DevOpsの機能性によってもたらされる改善点について全員の合意を得ることができれば、それは戦いの半分を制したも同然です。

DevOpsは（ありがたいことに）プロセスの一部としてセキュリティのベストプラクティスにもますます重点を置くようになり、そのステップの神秘性を解き明かし、セキュリティチームと、まあ、他のすべてのチームとの間の隔たりを縮めています。 以前も述べたように、開発者が最初から安全にプログラミングできるようになるにはまだ長い道のりがありますが、DevOps手法の成功した導入は、開発チームのセキュリティスキルを育成するための優れた基盤となります。

自動化がすべてではない（そして最も安全でもない）。

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

ツールは本当に素晴らしいものです。コードリポジトリ、テスト、メンテナンス、ストレージ要素を比較的スムーズに管理するため、ソフトウェアデリバリープロセスに前例のない速度をもたらすことができます。

しかし、ロボットがいつか私たちの仕事を奪い、私たちを監禁するかもしれないとはいえ、現時点ではまだそうなっていない。ツールや自動化への過度の依存は、エラーの発生余地を残している。スキャンやテストですべてを検出できない可能性があり、コードが検証されないことで将来的に重大な品質問題（セキュリティ問題は言うまでもなく）が生じる恐れがある。 攻撃者はバックドアを一つ見つければそれを悪用してデータを盗み出せる。品質管理やセキュリティから人的要素を排除することは、壊滅的な結果を招きかねない。

「中庸」とは、人とツールのバランスを保つことです。ツールは、プロジェクトの目標達成を信頼できるチームが遂行するための補助として機能すべきです。あなたは以下を行うべきです：

• 選択したDevOpsツールチェーンに人々が慣れるのに十分な時間を確保してください
• 効果的な協働に焦点を当て（そしてツールがそれをどのように支援できるかに）
• プロセス上のあらゆるギャップに対処してください。それがスキルや知識に基づくものであれ、ツールに基づくものであれ。

要するに、ただ「準備する」だけで最善を待つだけではいけない。

DevOpsは流行語ではなく、文化です。あなたはそれを育んでいますか？

変化の管理は、最良のケースでも困難です。未知への恐怖は、チームで最も優秀なメンバーでさえ、スキルを伸ばし視野を広げることを妨げかねません。

つまり、「DevOpsをやろう」と宣言し、運用チームのデスクを移動させるだけでは、魔法のように成功するプロセスが実現するわけではないのです。 多くのメンバーは混乱し、長年働いてきたチームメンバーは不満を感じるでしょう。期待値の明確な伝達と「自ら率先して行動する」姿勢が極めて重要です。DevOpsは開発手法であると同時に文化的な変革であり、チームは部門横断的で協働的なマインドセットを体現し、実践しなければなりません。

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

• 人々はプロセスに自らの経験を貢献する力を持っている。それはリーダーだけのものではない。
• チーム間のオープンで誠実かつ敬意あるコミュニケーション
• 各人は、開発プロセスに品質と安全性を組み込むという全体目標に対する責任を負う。
• 社内のDevOpsの定義、ロードマップ、そして各人の役割の「どのように」「何を」「なぜ」については、全員が合意しています。

長年にわたり、開発チームにおいて積極的な安全文化を構築することの重要性を強調してきたが、DevOpsも例外ではない。

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

これをマスターしましたか？素晴らしい。 では視点を切り替え、セキュリティの側面を組み込み、DevSecOpsをソフトウェア卓越性の究極の計画としましょう。