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

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

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

多くの人が（正しく）ソフトウェア開発ライフサイクルの加速化が必要だと認識しています。ビジネス目標と緊密に連携した、より精緻なプロセスにより、開発チームと運用チーム間の明確なワークフローと協業が可能になります。DevOpsは本質的に「アジャイル」な開発手法であり、現代企業が求める絶え間ない革新と迅速なデプロイメントのニーズに対応できるよう設計されています。 セキュリティ専門家にとって、これは素晴らしい取り組みです。セキュリティをプロセスに早期に組み込むことで、バグ修正コストを削減し、途中の潜在的な大惨事を回避できるからです。

問題は、DevOpsを実際に導入できる企業が少ないことです。社内の適切な支援、奨励、理解がなければ、DevOpsはすぐに「象の骨」状態に陥ります…つまり、誰もが口をつぐむ「タブー」プロジェクトの一つになってしまうのです。

では、問題は何でしょうか？これは興味深い議論であり、DevOpsに取り組む方法はいくつか存在します。それらは、方向性を定める上で役立つと私は考えています。 効果的なプログラムは、新しいツールや肩書き、洗練されたチームミーティングだけで成り立つものではありません。常に容易とは限りませんが、欠陥のある戦略を修正する（あるいは最初から適切な方法で導入する）ための時間を割くことは、長期的にははるかに苦痛が少ないでしょう。最終的には、より高品質で安全なソフトウェアへとつながります。

分解してみましょう：

「アジャイル」というエプロンの紐を解け。

アジャイルかDevOpsかの二者択一を迫られ、一方の道を選択したら二度と戻れないという誤解が存在する。

実際のところ、開発プロセスは両者を一体として捉え、実装する際に最も効果を発揮します。DevOpsはアジャイル開発の再発明ではなく、むしろその拡張です。プロセスがアジャイルと全く同じであること、あるいはアジャイルとは完全に異なるものであることを期待すると、車輪が外れる傾向があります。

アジャイルは、設計者、テスター、開発者を初期段階から集結させ、プロジェクト全体を通じてコミュニケーションラインを開くことに注力することで、クロスファンクショナルチームの原則を支持します。その目的は、部門間の壁による納品と二重管理を終わらせることです。これらはDevOpsプロセスの二つの利点です。 しかしDevOpsはさらに一歩進み、システム、セキュリティ、運用を統合することで、堅牢なエンドツーエンドのスキルセットを提供します。その究極の目的は、顧客に完全かつ機能的なソフトウェアを届けることにあります。

DevOps中心のプロセスへの移行に伴う避けられない困難の中で、開発が分断されるリスクが再燃する可能性があります。多くの場合、元のアジャイルチームは協働する一方で、セキュリティや運用に関連する追加要素は依然として組織内に位置づけられていません。誰がそれらをどう組み込むべきか、何をすべきか、そして全体的な目標が何であるかを、誰も本当に理解していないのです。

DevOpsは、明確に定義された目標、部門横断的な連携、そして関係者全員との直接的なコミュニケーションなしには機能しません。もちろん、変化を慎重に管理する必要がある適応期間が存在しますが、DevOps機能による改善を通じて全員の認識を統一することが、成功の半分を占めるのです。

幸いなことに、DevOpsはプロセスの一環としてセキュリティのベストプラクティスにも重点を置くようになってきており、この段階の神秘性を解き明かし、セキュリティチームと他のチームとの間の隔たりを埋めています。 繰り返しになりますが、開発者が最初から安全にコーディングできるようになるにはまだ長い道のりがありますが、DevOps手法の成功した導入は、開発チーム内でセキュリティスキルを強化するための優れた基盤となります。

自動化がすべてではない（そして最も確実な解決策でもない）。

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

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

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

「適切なバランス」とは、人とツールの調和を確保することです。ツールは、プロジェクト目標達成のために信頼できるチームを支援する手段として機能すべきです。以下の点を実践してください：

• ユーザーが選択したDevOpsツールチェーンに慣れるのに十分な時間を確保してください
• 効果的なコラボレーションに焦点を当ててください（そしてツールがどのように貢献できるかについても）
• プロセス上のあらゆる不足を補ってください。それがスキル、知識、ツールのいずれに関連しているものであっても。

要するに、単に「道具を揃える」だけで、すべてがうまくいくことを期待するだけではいけません。

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

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

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

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

• 個人は、指導者だけでなく、プロセスに専門知識を提供することが認められている。
• チーム間のオープンで誠実かつ敬意あるコミュニケーション
• 各人は、開発プロセスに品質と安全性を組み込むという全体目標に対する責任を負う。
• 企業におけるDevOpsの定義、ロードマップ、そして各役割の「どのように」「何を」「なぜ」については、全員が同じ認識を共有している。

開発チーム内で積極的な安全文化を構築することの重要性を、私は長年強調してきました。DevOpsも例外ではありません。

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

これをマスターしましたか？素晴らしい。それでは、状況を変え、セキュリティ面を強化し、DevSecOpsをソフトウェアエクセレンスの究極の計画にしましょう。