なぜ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をソフトウェア開発の究極の指針へと高めていきましょう。