こんにちは。エンジニアデータバンク です。
システム開発の世界では、効率的で高品質な成果を生むために、さまざまな開発手法が存在します。
その中でも特に代表的なものが「ウォーターフォール」と「アジャイル」という2つの手法です。
特に日本では多くの企業・プロジェクトでウォーターフォールにおける開発が主流ですが、アジャイル手法を採用する企業の割合が年々増加しています。
特に、DX(デジタル・トランスフォーメーション)が叫ばれている昨今においては、「素早く開発し、顧客に提供する」ということが重視され始めています。
その結果、「ウォーターフォールでは開発開始から提供までが長すぎる」という意見が増えており、徐々にアジャイル開発へのシフトが進んでいます。
とはいえ、両手法にはそれぞれ適した用途があるため、すべての開発がアジャイルに移行するわけではありません。
本記事では、これらの手法について詳しく解説し、それぞれの特徴や使い分けについて考察します。
なお「SEの副業に興味がある!」という方は、以下記事でSEの方におすすめの案件や仕事の探し方について解説しているので、ぜひ読んでみてください。
(準備中)
それでは解説していきます。
まずは、システム開発を進めるために必要なシステム開発の「工程」について解説していきます。
システム開発工程とは、ソフトウェアやシステムを構築する際の一連の流れを指します。
個人開発などの場合は、自分で作るべきものを考えて自分で開発を進めるため、プログラミングの比率が非常に高いです。
しかし、企業におけるシステム開発は、開発を進める中でプログラミング以外にもすべきことが多く存在します。
これは、複数人で開発することが前提になっていることや、システムの仕様やビジョンといったビジネス面を考えるメンバーと開発するメンバーが異なることから、メンバー間のコミュニケーションや認識齟齬といった問題を回避するために必要なものと考えると良いでしょう。
一般的に、要件定義から運用・保守に至るプロセスがこのシステム開発工程に含まれます。
これらの工程を明確にすることで、開発の効率化や品質向上を図ります。
一般的な開発工程の名称と内容について解説します。
要件定義
要件定義では、クライアントやビジネス部門の要望を明確にし、システムに必要な機能や条件を定義します。
具体的には、要件定義書、ユーザーストーリー、機能要件リストといったドキュメントを作成し、「どのようなシステムを開発するのか」ということを明確にします。
基本設計
基本設計では、要件定義をもとに、システム全体の構造や設計方針を策定します。
基本設計では、主に非エンジニアに対して説明する資料や、システムの画面や動作といったシステムの基本的な動きについて設計を行います。
このフェーズでは、画面設計書、ER図、システム構成図といった設計書を作成します。
詳細設計
基本設計をさらに具体化し、各プログラムやモジュールの仕様を定義するのが詳細設計です。
プログラムのコードを書くための準備段階であり、基本設計は非エンジニアにも理解できる内容が多かったのに対し、詳細設計ではエンジニアのための設計をする、と考えると良いでしょう。
詳細設計書、テーブル定義書、クラス図などのER図などを作成します。
コーディング
詳細設計を基にプログラムを実装します。
コーディング規約に従いながら、品質を考慮した開発を行います。実際にプログラミング言語を使用するのは、実はこのフェーズのみとなります。
テスト
開発したプログラムが設計通りに動作するか確認します。
テストは小さい単位から始めていき、プログラムが単体で動作するのかを確認する単体テストからはじまり、プログラム同士を繋げた結合テスト、システムが全体として正しく動作するのかをテストするシステムテスト、の順で行います。
テストは闇雲にテストをするのではなく、どのようにテストをするのかを定めた「テストシナリオ」を作成し、そこからテストケースを作成し実施します。
また、企業におけるシステム開発では、正常にテストが終わったという証明をするためにテスト結果報告書や発生したバグや問題を記載した障害報告書などを作成してまとめます。
システム移行
新しいシステムを本番環境に導入します。
既存システムからのデータ移行や、ユーザー向けトレーニングもこのフェーズに含まれます。
企業の基幹システムなど、影響範囲が企業全体や他社にも関わるシステムの導入においては、システム移行が失敗すると大きな損害を与える可能性があります。
そのため、事前にシステムの移行計画書や移行チェックリストを作成し、問題が起きないように準備します。
とはいえ、何も問題が起きずにシステム移行が完了するということは稀です。
移行計画の中には、問題が起きたときのリカバリープランもしっかりと定めておく必要があります。
運用・保守
稼働したシステムを監視・維持し、必要に応じて改修や障害対応を行います。
ユーザーからの問い合わせ対応も重要な業務です。そのほか、システムを運用する際に発見されたバグや、小さな機能改修なども実施します。
ここからは、開発手法として大きく異なる「ウォーターフォール」と「アジャイル」の違いについて解説します。
システム開発を進める方法として「ウォーターフォール」と「アジャイル」があります。
これらは開発の進行方法や管理手法に大きな違いがあります。
まずは、簡単に違いから紹介していきます。
| 項目 | ウォーターフォール | アジャイル |
| 進め方 | 一括で各工程を順次進める | 小さな単位で繰り返し開発する |
| マネジメント | 明確なスケジュールと計画が必要 | 柔軟性を重視し、計画は変更可能 |
| 柔軟性 | 低い | 高い |
| テストの考え方 | システム全体で正常に動作することを目的に総合的なテストを後から実施 バグを残さないように網羅する | 継続的にテストを行い、 発見したバグはそのタイミングで修正して即時リリース |
| コミュニケーション | 工程間でのドキュメント中心 | チーム内外での対話を重視 |
ウォーターフォールは、開発工程を明確な段階に分けて順序立てて進める手法で、すべての工程が完了して初めてリリースされます。
ウォーターフォールでは、大きく3つの特徴を持ちます。
工程の順序性
原則として、各工程が完了しない限り次の工程に進むことができません。
このため、全体の進捗を把握し、計画に基づいた管理をすることが求められます。
文書化の重視
各工程で詳細な文書が作成されるため、成果物が明確に定義されます。これにより、プロジェクトメンバー間での認識の共有がしやすくなります。
予測可能性
初期段階で要件が確定し、その後の変更が最小限に抑えられるため、スケジュールや予算の見通しが立てやすいです。
ウォーターフォールのメリット
ウォーターフォールのデメリット・注意点
アジャイルは、短いサイクル(スプリント)で反復的に開発・リリースを繰り返す手法です。
柔軟性を重視し、変化に対応しやすい特徴があります。
短いサイクルでの反復的な開発
開発を小さな単位に分割し、それぞれを短期間で完成させ、継続的にソフトウェアをリリースします。これにより、継続的な改善が可能になります。
顧客・ビジネス部門との協調
開発を続ける中で、常に顧客やビジネス部門と密接に連携し、要件の変更や新しい要望に迅速に対応します。
自己組織化チームの形成
チームメンバーが自主的に役割を分担し、協力して開発を進める文化を重視します。
アジャイルのメリット
アジャイルのデメリット・注意点
アジャイル開発には、目的やプロジェクトの体系などにあわせていくつもの手法が存在します。
ここでは、採用例の多い手法をいくつか紹介します。
スプリントと呼ばれる短期間(通常2〜4週間)の反復的な開発サイクルを中心に進める手法です。
スクラムマスターがチームを支援し、プロダクトオーナーが顧客の要件を調整します。
スクラムは、アジャイル開発の手法の中でも有名で、アジャイル=スクラムと考えている人も少なくありません。
カンバンは、タスクの進行状況を視覚化するためのボードを使用し、タスクの優先順位や進捗を管理する手法です。
製造業から派生した方法で、継続的な改善を重視します。
プログラミングの実践に特化したアジャイル手法で、ペアプログラミングやテスト駆動開発(TDD)などの技法を取り入れています。
コードの品質向上と顧客満足度の向上を目指します。
ウォーターフォールとアジャイルのどちらを選ぶかは、プロジェクトの性質や目的によって決まります。
たとえば、ウォーターフォールは明確な要件定義が可能で、計画的に進めたい大規模プロジェクトに適しています。
一方、アジャイルは柔軟性が求められるプロジェクトや、顧客の要望が開発中に変化する可能性がある場合に適しています。
以下で詳しく解説します。
ウォーターフォールが選ばれるケースとして、以下のようなプロジェクトが挙げられます。
| 要件が明確で変更が少ないプロジェクト | 開発開始前に仕様が固まっているプロジェクトは、ウォーターフォールの計画的な進行が適しています。 |
| 規模が大きく、文書化が重要なプロジェクト | 官公庁や金融系のプロジェクトといった、安全性が求められるシステムなどでは、詳細な文書化が信頼性を高めます。 |
一方で、アジャイルが適しているプロジェクトの特徴には以下が含まれます。
| 要件が不明確で変更が頻繁にあるプロジェクト | 開発中に顧客のニーズが変化する可能性がある場合、アジャイルの柔軟性が役立ちます。一般向けのソフトウェアなど、ユーザーの利用状況やニーズを加味して開発を進めることが必要になります。 |
| 小規模で迅速な開発が求められるプロジェクト | スタートアップや短期間でのリリースが必要なプロジェクトでは、スプリントごとの開発が有効です。また、チームや顧客とのコミュニケーションが重視されるプロジェクトでは、アジャイルの対話重視の進め方が適しています。 |
ウォーターフォールとアジャイルの利点を組み合わせた「ハイブリッド開発」は、プロジェクトの性質に応じて柔軟に進めることができる手法です。
たとえば、大規模な基幹システム開発では、初期の要件定義や設計段階をウォーターフォールで進め、開発後の改修や一部機能の追加をアジャイルで行うケースがあります。
適用例1: ECサイトの開発
ECサイトの構築では、ウォーターフォールで基本設計やインフラ構築を進める一方で、商品検索やおすすめ機能のようなユーザー体験を重視する部分をアジャイルで繰り返し改善することが可能です。
適用例2: 医療システムの導入
医療システムは厳密な要件定義とテストが求められるため、基本部分はウォーターフォールで進めます。しかし、運用開始後のユーザーインターフェースの改善や、新たな規制への対応などはアジャイルを用いることで柔軟に対応できます。
適用例3: モバイルアプリの開発
モバイルアプリの開発では、バックエンドAPIの設計と構築をウォーターフォールで進めつつ、ユーザーインターフェースや新機能の追加はアジャイルで進めることで、リリース後も迅速に市場のニーズに対応できます。
このように、ハイブリッド開発は、プロジェクトの特性やスケジュールに応じて柔軟に手法を選択する点が強みです。
前述のとおり、現在はウォーターフォールとアジャイルの両方にメリットがあるため、両方の開発手法を理解することが必要です。
しかし、特に日本においてはウォーターフォールによる開発の方が多く、アジャイル開発の適用例はまだ少なく、今後増えていくことが予想されます。
アジャイルに関する知識を身に着けることで、今後の案件獲得に役立つことでしょう。
ここでは、有用なアジャイルに関する資格を紹介します。
アジャイルソフトウェア開発技術者検定試験コンソーシアムが開催している検定試験で、アジャイル開発の基本的な知識と、実践的な内容が問われます。
アジャイルの基本的な知識や、どのように開発を進めるのかという基本的な問題が出題されますので、アジャイルの基本的な知識を身に着けるのに最適な視覚です。
アジャイル開発チームのメンバーとして必要な高度な知識と実践的なスキルが身についているかが問われる試験です。
前述のLv1では基本的な知識が求められるのに対し、Lv2では「実際にどのように行動するのか」といった内容が出題されます。
より実践的な内容が出題されますので、アジャイル開発の開発メンバーとして活躍できる証明になります。
Scrum Allianceが実施している資格で、アジャイルの開発手法である「スクラム」開発をリードする「スクラムマスター」という立場として活躍できるスキルを証明するための試験です。
スクラムマスターは、スクラムを進めるうえで重要な存在であり、スクラム開発をする上では必須のポジションです。
この試験では、スクラムの基本的な理論から実践まで、スクラムマスターとして必要な知識とスキルが問われますので、これからスクラムマスターを目指すような人に最適な試験です。
CSMの上位資格であり、実践的なスキルやチームのコーチング能力、組織内でのスクラム導入推進力などが出題されます。
この資格があると、「スクラムマスターとして即戦力である」という証明になると言っても過言ではないでしょう。
スクラムマスターとしての高度な専門性を証明する資格であり、スクラム開発を進めるための知識に限らず、リーダーシップ、プロセス改善、組織変革の推進力などの総合的な知識が問われます。
上級認定スクラムマスターのさらに上位資格として存在する資格であり、より高度な内容が出題されます。
以上、ウォーターフォールとアジャイルについてそれぞれの特徴や違いについて解説してきました。
それぞれの手法には一長一短があり、プロジェクトの特性やチームの状況に応じて適切な手法を選ぶ必要があります。
日本においては開発案件の大半をウォーターフォール開発が占めていますが、今後アジャイル開発の案件割合はどんどん増えていくことでしょう。
開発手法に応じて適切な行動を取ることがクライアントへの信頼強化にもつながりますので、違いを正しく理解して行動すると良いでしょう。
エンジニアとしての転職や独立をお考えの方には、エンジニアデータバンクがおすすめです。
エンジニアデータバンクには、副業案件からフリーランス、転職求人が多数掲載されています。
エンジニアデータバンク