なぜ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を卓越したソフトウェア実現の究極の計画としましょう。