今さら聞けない開発手法の違いと特徴（DevOps、アジャイル、ウォーターフォール他）

1970年代に手法が確立されたウォーターフォールは、長らくシステム開発の主流でした。しかし、2001年にアジャイル開発の草案とも言える「アジャイルソフトウェア開発宣言」が公表され、開発手法としてのアジャイルが世界中に浸透していきます。さらにスクラム、DevOpsなどシステム開発手法は多様化し、今ではプロジェクトに合わせた最適な開発手法を選択する時代と言えます。そこで、本記事では、それぞれの開発手法の違いと特徴をご紹介します。

アプリケーション開発における課題別の解決方法とは? 〜Azureを導入するメリットも紹介〜

「ウォーターフォール」システム開発の基本

システム開発における最も基本の開発手法がウォーターフォールです。滝の水が上から下へと流れる姿から命名された通り、上流工程と下流工程の関係がハッキリとしていて、プロジェクトの一連の流れで進みます。

システムの要件定義に始まり、概要設計、詳細設計、開発、テスト、運用という開発フェーズに分けられ、各フェーズには明確な成果物を設定し、品質を満たした時点で次のフェーズへと進みます。また、フェーズごとに作成すべきドキュメントも決まっているため、信頼性の高い開発手法として今でも活用されています。

ただし、滝の水が逆流しないことと同じく、ウォーターフォールもまた工程の後戻りを苦手としています。プロジェクトの途中でシステムの仕様・設計が変更になると、想像以上の手間とコストがかかってしまうため、プロジェクトが遅延するケースも少なくありません。

ウォーターフォールは、プロジェクトにかけられる時間と予算が決まっており、大規模かつリリース日までに開発しなければいけないような場合に最適です。

「アジャイル」素早い開発スタイルで対応力を向上

2001年から浸透し始めたアジャイルは「俊敏」という意味です。ただし、プロジェクトを短期的に完了できるわけではなく、システムの要件定義で決められた機能ごとに「イテレーション」と呼ばれる開発期間を区切り、その中で開発・テストを繰り返す開発手法になります。

アジャイルのメリットは、開発したモジュール（部品のように切り分けた機能）をいち早く確認できることと、プロジェクトの途中で仕様・設計の変更が生じても、要件ごとに区切った開発を行っているため比較的簡単に変更へ対応できることです。

現代的なスピードや変化の多い世界では必ずと言ってよいほど途中での仕様・設計変更が生じることがあります。それを前提に考える柔軟性を追求した開発手法、それがアジャイルです。昨今では、ウォーターフォールが持つ問題を解決するための開発手法として広まっており、すでにシステム開発現場の主流に代わっています。

ただし、アジャイルを使ったシステム開発には全体を統制できる経験豊富なシステムエンジニアと、チームとしてシステム開発に取り組める体制が必要になります。

「スクラム」固定のチームでコミュニケーションを重視

アジャイルの一種であり、ラグビーにおいて両チームの8人ずつのプレイヤーが肩を組みボールを奪い合う「スクラム」から命名されています。このため、スクラムはチームのコミュニケーションに重点を置いており、優先順位の高い要件から開発を繰り返すというのがポイントです。

スクラムチームはビジネス上の責任を持つプロダクトオーナー、スクラムの運用をサポートするスクラムマスター、それとプラダクトオーナーの要求を実装し作るべきものを作るチームから成っています。実際に開発を進める際のポイントは以下の4つです。

作成するシステムの優先順位を並べ替えてタスクを整理する「スプリント計画」
システム開発にあたって必要なものは何か、クライアントやユーザーに提供すべき価値は何か、システムに必要な要素は何か、優先すべき順位と作業コストを計画した「プロダクトバックログ」
1～4週間の期間で区切られた「スプリント」と呼ばれる開発サイクル
開発・まとめ・レビュー・調整で構成されるスプリントごとに実現すべきことをまとめた個別のタスクリストである「スプリントバックログ」

スクラムで最も重要なのは、メンバーが頻繁にコミュニケーションを取り、情報共有を活発に行ってプロジェクトの透明性を高めることです。プロジェクトの進捗を共有するためには日次でミーティングを行い、前日までの進捗と当日の予定、現時点での課題をチームで共有し、滞りなく開発を進めていきます。

「DevOps」開発と運用が連携したモダンスタイル

Development（開発）とOperations（運用）の頭文字を取った言葉がDevOpsであり、開発チームと運用チームが互いに連携して、システム開発要求に対して素早く柔軟に対応できる仕組みを作る開発手法です。

開発チームと運用チームが対立することは珍しくありません。近年のシステム開発現場では、アジャイルの台頭によって小さい開発サイクルを繰り返すことが多く、開発チームは常に改善と修正を繰り返しています。一方、運用チームはシステムの安定稼働が使命なので、システムに致命的な問題がなければ極力手を加えたくないのが心情です。その結果、開発チームと運用チームが対立しやすくなります。

しかし開発チームと運用チームは本来、「システムを通じてクライアントやユーザーのビジネス価値を高める」という共通目的を持っているので、協力こそしても対立すべきではありません。そこで注目されたのがDevOpsです。DevOpsは具体的な開発手法というよりも、開発チームと運用チームが互いに尊重できる組織文化を構築することと、情報共有の促進、テストやレビューを効率化するためのツール活用にフォーカスされています。

「SRE」Googleが提唱する信頼性重視の手法

「Site Reliability Engineering」の略であり、Googleが提唱しているシステム管理およびサービス運用における開発手法です。開発スピードのアップと安定性の向上という面ではDevOpsに通じるものがありますが。SREの本質は開発も可能な運用部隊という存在を重点に置いていることです。

一般手なSREはサイト・サービスの信頼性を高めるために積極的にコードを記述し、可能な限りシステムの自動化を行い、属人化を起こさないためのドキュメントを整備したり情報を共有したりすることが中心になります。クラウドサービスが台頭したことでインフラエンジニアがハードウェアの安定性を意識する必要が少なくなり、その分これまでのインフラに関する技術だけでなくシステム開発技術も求められるようになったのが背景としてあります。

どのシステム開発手法を選ぶか？

以上のシステム開発手法の中で、「どれが正解」ということはありません。それぞれに一長一短があり、プロジェクトに合わせた最適な開発手法を選ぶことが大切です。また、今までに使ったことのない開発手法をどんどん採り入れ、経験を積みながら自社や自チームに最適な開発手法を見極めることも重要でしょう。この機会に、各開発手法の特徴をより深く理解し、積極的に採り入れてみましょう。