ソフトウェア品質基準は、アジャイル開発とDevOpsをより高いレベルに引き上げるのに役立ちます

[[211658]]

革新的なソフトウェア開発管理手法として始まったアジャイル開発は、現在では徐々にソフトウェア開発における新たな標準となりつつあります。アジャイル開発は、開発作業をより効率的にすることで、過去 10 年間にわたってその利点を示してきました。ユーザーと開発チームの両方が、作業目標をより迅速かつ適切に達成できるようになりました。

アジャイル開発と DevOps が自然にマッチする理由

DevOps の人気が高まるにつれて、アジャイル開発の魅力も高まっています。これらは同じではありませんが、常に互いに補完し合います。チームがアジャイル開発を一度も実践したことがない場合、DevOps をうまく実行することは困難であり、その逆も同様です。

DevOps は、確かにアジャイル開発原則の拡張として見ることができます。アジャイル開発の概念は DevOps よりも前に生まれましたが、DevOps 関連のプラクティスがあったからこそ、アジャイル開発はより大きな役割を果たすことができました。

アジャイル開発の概念は、運用やその他の非 IT 分野で繰り返し適用されてきました。近年、DevOps は開発チームの範囲を超えてその利点を発揮しており、エンタープライズ レベルのグローバル IT チームへの支援は依然として最も重要です。コンサルティング会社 Gartner は最近、IT 部門はイノベーションに注力するためにアジャイル開発手法を採用し、新しいソフトウェア リリースのセキュリティと安定性を確保するために DevOps を採用すべきであると推奨しました。

したがって、新世代のソフトウェアの拡張と応用においては、アジャイル開発と DevOps は切り離せないものとなります。

スピードとリスクのバランス

アジャイル開発と DevOps に共通する利点の 1 つは柔軟性です。これにより、開発者は絶えず変化するユーザーのニーズに対応でき、これは今日のデジタル社会では非常に価値があります。アジャイル開発により、新しい要件の生成から対応する新しい機能の提供までのサイクルが短縮されます。 DevOps により、より迅速な配信が可能になります。

ただし、アジャイル開発を実践するチームは、このような急速な更新は強固な IT 基盤と強固なソフトウェア構造によってサポートされる必要があることを常に念頭に置く必要があります。それだけでなく、俊敏性を維持するために、いつでも柔軟に調整および改善できる信頼性の高いアーキテクチャでソフトウェア開発を実行する必要もあります。

一見すると、アーキテクチャに対するこの厳格な要件は、アジャイル開発の原則と方法論に違反しているように見えますが、実際はそうではありません。合理的なアーキテクチャ (少なくともソフトウェア分野では) は静的なものではなく、継続的に進化する動的なプロセスです。ソフトウェアが開発の最初から完璧であることは不可能です。

開発チームがソフトウェア システム アーキテクチャを継続的に監視し、その効率性を評価し、問題のあるコンポーネントや潜在的なセキュリティの脆弱性を特定することが重要です。 DevOps プラクティスと関連ツールは、ソフトウェアを自動的にチェックし、関連するガイドラインに準拠しているかどうか、関連する更新によって追加のリスクや潜在的な副作用が生じていないかどうかを判断できます。開発チームがリスクを回避しながら迅速な目標を達成したい場合、ソフトウェア システム アーキテクチャは頻繁に更新され、簡単に生成できる必要があります。このようにして、毎日のソフトウェア更新と長期的な適応調整を適切にサポートできます。

ソフトウェア品質を保証するための標準

開発サイクルが短縮されるため、アジャイル開発ではニーズをより適切に満たすことができ、ソフトウェアを迅速に適応および調整できます。 DevOps は品質の向上に役立ち、ソフトウェアの自動化とフェイルファスト監視に最適な条件を提供します。

アジャイル開発と DevOps には上記のような多くの利点がありますが、ソフトウェアの品質やテクノロジへの依存度の低下を保証することはできません。よく知られている Fail-fast 方式ではソフトウェアの欠陥を迅速に発見できますが、IT 部門は障害による影響と損失を最小限に抑える必要があります。これを受動的に達成するのは困難です。

開発チームは、起こりうる問題を事前に回避するために、より積極的なアプローチを取り、関連ツールを使用して国際的に認められた品質基準と比較し、コードステートメント構造と設計構造をテストして、問題が発生する前に防止する必要があります。 Coalition for Software Quality (CISQ) によって開発された標準は良い選択です。 CISQ 標準は、ソフトウェアの全体的なアーキテクチャの青写真を考慮しており、コードとソフトウェア開発アーキテクチャの主要な問題を特定するためにアウトソーシングされた開発者を管理する契約で使用できます。

このような標準システムを採用することで、ソフトウェアの品質が保証され、チームはソフトウェアのリスクを特定できるようになります。これらのリスクはソフトウェア開発プロセス中に検出するのが難しいことが多く、一度発生するとシステムが突然クラッシュする原因になります。実際、開発チームが品質の問題に少し注意を払うだけで、長期的かつ安定したアプリケーション ソフトウェア アーキテクチャを実現できます。なぜそれをしないのですか?

古い技術の問題を解決する

ソフトウェアは大規模なアプリケーション システムの一部であることが多いため、開発チームは古いテクノロジーとアジャイル開発の間の矛盾のバランスを取る必要があることがよくあります。多くの場合、これらの古いソフトウェア テクノロジは、アジャイル開発に不慣れなチームによって保守されており、アジャイル開発や DevOps 向けに最適化されていません。同様に、アジャイル開発チームは、古いテクノロジーと連携する新しいコンポーネントを構築するときに、自らの限界をほとんど理解していません。

これにより、ワークフローの問題が発生しやすくなり、プロジェクトのリスクが大幅に増加する可能性があります。この問題を解決するために、多くのチームが Agile-DevOps アプローチを採用して古いテクノロジーを変革し、運用レベルでの制御を強化しています。

[[211659]]

開発チームは、アーキテクチャの観点から開始し、新しいコンポーネントと古いコンポーネント間のスムーズで効率的かつ明確な関係を確立する必要があります。このアプローチは、開発チームが古い文書化されていないコードに対処し、新しいフロントエンド サービスが古いバックエンド アプリケーションを不当にトリガーしないようにするのにも役立ちます。

今後の課題

2017 年に開発チームが直面する主な課題は、既存のアジャイル開発と DevOps プラクティスに包括的、アーキテクチャ的、システム レベルの視点をどのように統合するかです。おそらく、当面は新機能のマーケティングを脇に置いて、アジャイル開発と DevOps の潜在能力を最大限に発揮できるように、システムレベルの分析に重点を置くべきでしょう。

Fail-fast をシステムレベルの分析方法と組み合わせると、バグを迅速に解決し、大規模なアプリケーション ソフトウェアの障害を事前に防止できます。アジャイル開発と DevOps を実践しているチームが次のレベルに進みたい場合は、CISQ などのソフトウェア品質標準を採用して、ソフトウェア品質の向上、ソフトウェアのリスクとテクノロジへの依存の軽減のためのアイデアを身に付ける必要があります。これはプロジェクト自体とビジネスの成功にとって非常に重要です。