ソフトウェア開発をめぐる現在の考え方は、ステークホルダー間のコミュニケーションを大幅に増やし、変化に迅速に対応できる方向へと進化してきた。従来のウォーターフォール型アプローチが硬直的で非効率だったのに対し、今日のDevOpsとアジャイルの方法論は、より高い柔軟性と最終的に優れた成果をもたらす。
ただし、この2つのアプローチにはそれぞれ固有のユースケースがあり、ソフトウェアチームの業務改善に役立つ。チームを成功に導くには、アジャイルとDevOpsの違いを理解することが重要だ。
アジャイルとは？
アジャイルの概要を説明する最善の方法は、その4つの中核的価値を紹介することだ。これらの中核的価値は、いわゆるアジャイルマニフェストに示されている。
アジャイルのアプローチでは、より大きなプロジェクトを小さな単位で段階的に開発・テストし、少しずつ成果を積み上げていく。これにより効率が高まり、変化にその場で対応できるため、開発段階でエラーをより迅速に見つけられる。
アジャイルのソフトウェア開発プロセスでは、作業を管理しやすい小単位に分け、2週間の期間を目安に、一つひとつへ集中的に取り組む。この間、開発チームは特定の機能が期待どおりになるまで、テストと改善に注力する。
個々の機能に取り組む期間は、スプリントと呼ばれる。1つのスプリントが終わると、チームはすぐに次のスプリントへ移る。機能の開発中、チームは定期的に会議を開き、フィードバックの共有や作業のレビューを行う。
Developer.comでさらに読む：アジャイルソフトウェア開発入門
アジャイルの中核原則
アジャイルの方法論では、プロセスやツールよりも個人と相互作用を、包括的なドキュメントよりも動作するソフトウェアを、契約交渉よりも顧客との協働を、計画に従うことよりも変化への対応を優先する。
プロセスやツールよりも個人と相互作用
この中核的価値は、チームメンバー同士のコミュニケーションの重要性を強調する。これにより、すべてのステークホルダーが関与し、価値を認められていると感じられる、より前向きな職場環境が生まれる。
効率を高めるため、アジャイルのアプローチではチームメンバー間の継続的なコミュニケーションを優先し、促進する。これにより、全員がプロジェクトに価値あるフィードバックを提供できる。
包括的なドキュメントよりも動作するソフトウェア
ウォーターフォール方式では、ドキュメント作成が開発プロセスの大きな部分を占めていた。しかし、それが必要な変更の実施を妨げることもある。
アジャイルのソフトウェア開発は、まさに機能するソフトウェアを開発し、できるだけ迅速にデプロイすることに重点を置く。製品に必要な改訂を加えた後であれば、ドキュメント作成は後回しにできる。
契約交渉よりも顧客との協働
開発に着手する前に顧客と契約を交渉しておくと、プロジェクトの範囲が変わった際に問題が生じる可能性がある。そのためアジャイルのプロジェクトでは、プロジェクトの要件は変化するものと考え、継続的な協働と柔軟性を優先する。
プロジェクトに必要な変更を加えるには、顧客とのコミュニケーションを維持することが欠かせない。これにより顧客は詳細なフィードバックを提供でき、ソフトウェアチームは長期間作業した末に変更点が大量に残る事態を避けられる。
計画に従うことよりも変化への対応
同様に、ソフトウェアの最終的な目標を達成するには、プロジェクトの途中で変更が必要になることもある。そのため、チームはそうした変更をいとわない姿勢を持つ必要がある。
静的なソフトウェア開発計画に固執するのではなく、アジャイルのプロジェクトでは動的なロードマップを用いる。これは四半期または月次で評価し、長期的な製品ビジョンに向けて正しい道筋を示しているかを確認する。
CIO Insightでさらに読む：ソフトウェア開発におけるアジャイルのベストプラクティス5選
DevOpsとは？
DevOpsとは、ソフトウェアが運用段階に入った後の開発プロセスを指す。DevOpsでは、ソフトウェアが円滑に動作し、顧客のニーズとともに進化していくよう、開発チームと運用チームが一体となって協働することを目指す。
DevOpsはアジャイル開発に取って代わるものではない。長期的にアジャイルプロセスの生産性と効率を補完することを目的としている。
DevOpsの中核原則
実際のDevOpsフレームワークでは、自動化、協働、継続的なデプロイと改善、そして顧客中心の活動を優先する。
自動化
DevOpsのベストプラクティスでは、構成、デプロイ、保守、テストのプロセスを可能な限り自動化することが重要な優先事項となる。これによりスタッフは、反復的な手作業ではなく、より重要な課題に集中できる。結果として時間を節約し、チームの業務効率を高め、製品品質を向上させられる。
協働
DevOpsは、フィードバックを容易に共有できる協働環境を生み出す。コミュニケーションがオープンで、フィードバックが頻繁に共有されれば、DevOpsチームはアップデートを迅速にリリースし、ダウンタイムを最小限に抑えられる。
継続的インテグレーションとデリバリー
DevOpsチームは、大きな混乱を避けるため、ソフトウェアのアップデートを継続的に段階導入する。これは継続的インテグレーションとデリバリー（CI/CD）と呼ばれるプロセスだ。DevOpsチームのメンバーは、1日に何度も共有リポジトリへコードを統合する。コードを小さな単位に分けることで、ソフトウェアの競合やバグをより迅速に検出しやすくなる。
顧客中心の活動
アジャイルの方法論と同様に、DevOpsはプロセス上の制約よりも顧客満足を重視する。アップデートの頻繁なデプロイ、新機能のテスト、フィードバックの反映、エラーの追跡を繰り返すことで、製品の機能と顧客のニーズとの隔たりを最小限に抑える。
TechRepublicでさらに読む：DevOps：チートシート
アジャイルとDevOpsの共通点
アジャイルとDevOpsはいずれも、チームメンバー間の協働を促進し、バグの少ない、より優れたソフトウェアにつなげる。その他の共通点には、次のようなものがある。
- ビジネス重視：両方の方法論は顧客にとっての価値を高めることに重点を置いており、最終的にはビジネスの収益を押し上げる。
- 協働：協働を重視することで、コミュニケーションが改善し、期待値が明確になる。これは最終的に、より効率的に優れたソフトウェアを生み出すという、DevOpsとアジャイルに共通する目標の達成を後押しする。
- 継続的なリリースサイクル：アジャイルとDevOpsはいずれも、ソフトウェア製品の小さな部分を継続的に開発し、より大きなプロジェクトの完成部分を常にリリースする。
- 柔軟性：アジャイルとDevOpsはいずれも、厳密に従わなければならない規則ではなく、プロジェクト固有のニーズに合わせて適応できる方法論だ。
アジャイルとDevOpsの違い
この2つの方法論には、次のような違いがある。
- ソフトウェアの作成とデプロイ：アジャイルの目標がソフトウェアの作成であるのに対し、DevOpsはソフトウェアのデプロイにより重点を置く。
- 専門性の度合い：アジャイルでは、チームメンバーはより汎用的で、必要なあらゆる役割を担える。一方、DevOpsの環境では、開発と運用を別々のチームが担当する。ただし、両チームは定期的にコミュニケーションを取る。
- コミュニケーション：アジャイルチームでは通常、毎日ミーティングを行うが、DevOpsチームは毎日集まる必要がない。
- ドキュメント：アジャイルはドキュメント作成を重視しない。一方、DevOpsではドキュメントを非常に重視する。
- プロセスの自動化：アジャイルは自動化を優先しないが、DevOpsのフレームワークでは生産性向上を可能にする重要な優先事項となる。
- スケジュール：アジャイルチームは、スプリントと呼ばれる短い期間（通常は2週間）で成果を測定する。これに対し、DevOpsはより長い作業単位を重視する。
- チーム規模：アジャイルのチーム規模は通常非常に小さいのに対し、DevOpsチームは通常、複数のより大規模なチームで構成される。
アジャイルとDevOpsはどのように連携できるか？
アジャイルとDevOpsは異なる方法論だが、組み合わせて利用できる。アジャイルはソフトウェアの作成に適している一方、DevOpsは継続的なソフトウェアのデプロイと運用に適している。
2つの方法論を組み合わせることで、企業はソフトウェアを迅速にリリースし、長期にわたって一貫性のある高価値な製品を維持できる。
TechRepublicでさらに読む：より強固なエンタープライズ環境に向けたIT運用部門横断の協働