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をソフトウェア卓越性の究極の計画にしましょう。