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