ウォーターフォールとアジャイルの違いは？開発手法とオフショアでの考え方！

新型コロナは収束に向かっていますが、依然として非対面型・非接触型ビジネスモデルへの転換が求められています。

これらの新たなビジネスモデルを展開してくには、ITの活用は不可欠なものとなります。

完全な対面型からのビジネスモデルの転換には大規模なシステム開発も必要となりますが、そうした開発では開発手法の選択が重要となります。

前回、オフショア開発の失敗を限りなく減らす！外注にあたってのチームの考え方！で開発手法についても簡単に言及しました。

今回はウォーターフォールとアジャイルの二つの開発手法を中心に開発手法について掘り下げて解説します。

1. ウォーターフォール型開発

ウォーターフォール型開発とは

ウォーターフォール型開発は、1970年ごとに初めて誕生した最も古い開発手法の一つです。

古典的な開発手法ではありますが、今でもその活用が広がっています。

日本では工程毎に異なる企業が開発を行うというIT業界の構造上、特に広く受け入れられています。

ウォーターフォールを日本語に直訳すると、「滝」という意味です。

ウォーターフォール型開発は滝のように「要件定義」、「基本設計」、「詳細設計」、「実装」、「テスト」、「運用」という流れを段階毎に完了させます。

段階毎の成果物を確認し、前の工程に戻らないことを前提とすることがウォーターフォール型開発の特徴です。

ウォーターフォール型開発のメリット

①計画の余裕を持たせやすい

ウォーターフォール型開発では、要件を確定してから、開発に着手します。

そのため、開発内容や作業全体を考慮して、スケジュールを決めることができます。

無理がないようにタスクを割り振り、進行計画に余裕をつけるケースも多いです。

②予算と人員の計画が立てすい

ウォーターフォール型開発では、工程毎に明確に作業が定義されるため、プロジェクト開始前に「各段階で何が必要か」、「その時、何人必要か」が明確に定まります。

そのため、プロジェクト開始前の準備時間でチームメンバーを工程に合わせて手配できます。

また、工程毎に明確に作業が定義されるため、人員の入れ替えが発生しても簡単に引き継げるため、プロジェクトの進捗に影響を与えずに柔軟に対応することも可能です。

③設計が上手くいけば、不具合を防げる

ウォーターフォール型開発では、開発開始前にシステム全体の機能を設計してから順次に開発を進めていきます。

ソフトウェア開発では途中で追加する機能が既にある機能と矛盾し、不具合を起こすことも少なくありません。

ウォーターフォール型開発では、全体の機能設計を固めてから開発するため、設計の段階で不具合を考慮することが可能です。

ウォーターフォール型開発のデメリット

①準備時間が長い

要件定義や設計が完了しないと開発に進めないことがウォーターフォール型開発の特徴です。

これらが完了して、はじめて具体的な機能が定まり、タスクに落とすことができます。

そのため、実際にプロジェクトを開始するまでの準備時間は必然的に長くなります。

②柔軟性が足りない

ウォーターフォール型開発は、仕様変更や工程戻りが起こらないことが前提です。

しかし、どんな周到な計画でも全ての問題を予測しきれません。

プロジェクト実施時に想定外の問題が発生して、仕様変更や手戻りが起こると計画全体を見直す必要があります。

また、問題は起きずとも、ユーザーの要望、アイディアが途中で変わることも起きえます。

そのため、ウォーターフォール型開発では、開発途中での仕様変更や追加対応が難しいことを考慮する必要があります。

③成果物の確認がしにくい

上記でも述べた通り、ウォーターフォール型開発では各工程が順次進められるます。

そのため、イメージしていたものと実際の動くもののがずれているかどうかは、全ての工程が完了した後となります。

最悪の場合、ユーザーが求めるものと全く異なり、一からやり直さなければなりません。

そうすると追加費用と開発期間の延期でトラブルになることもあります。

ウォーターフォールが向いているシステム

NTQは下記3点の条件を満たすケースでウォーターフォール型開発をおすすめしています。

・要件が明確

・予算の制約が厳しい

・スケジュールのズレが許せない

ウォーターフォール型開発は工程の手戻りが許されないため、特に一つ目の条件が重要です。

社内の基幹システム、業務システムなどは既存の業務にのっとってつくられることで要件が整理しやすいため、また予算の制約が大きくスケジュールを厳格に定める必要がある大規模な開発となるため、ウォーターフォール型開発に向いています。

業界としては適切な人員の手配、綿密な管理が求められる金融、メーカー系のお客様が良くウォーターフォール型開発を活用しています。

また、レガシーシステムをマイグレーションする場合、すでに必要な機能が明確に決まっていますので、ウォーターフォール型開発を活用することで最適な予算で進行できます。

2. アジャイル型開発

アジャイル型開発とは

アジャイル型開発は2001年にアメリカで生まれました。

17名の技術者やプログラマーに提唱されたアジャイル型開発は現在、アメリカでは主流の開発手法となります。

アジャイルという単語の意味は「素早い」「機敏な」「頭の回転が速い」です。

その意味の通り、アジャイル型開発は計画、設計、実装、テストという開発工程を短いサイクルで何度も繰り返して開発を進め、短期間でリリースを目指します。

機能毎に小さいサイクルで開発を繰り返し、開発したものを最後に統合して、1つのシステムを形成します。

そのため、優先度が高い重要な機能から着手し、途中で柔軟に仕様変更ができます。

アジャイル型開発のメリット

①高い柔軟性

アジャイル型開発では、計画からテストまでの工程を短期間で何度も繰り返すため、計画段階で綿密な仕様を決めなくても開発に着手できます。

開発途中でユーザーとコミュニケーションをとりながら、仕様変更にコスト負担なく対応できます。

そのため、ユーザーのニーズと合致したシステムになりやすく、ユーザーの満足度が高いシステムの開発がしやすくなります。

②開発期間の短縮可能

アジャイル型開発は、短期間で実際に動く機能をつくりながら開発を繰り返すため、要件がおおまかにしか決まっていない段階でも開発が開始できます。

また、アジャイル型開発では、1週間から4週間を目途に１つの機能をリリースするため、すぐにシステムのユーザーの確認が取れます。

開発の途中でユーザーのフィードバックに基づいて修正することもでき、後戻りが少なくなります。

アジャイル型開発のデメリット

①開発の方向性がブレやすい

アジャイル型開発では、全体の仕様を完全に固めずにフィードバックを得て修正を繰り返すことを前提とします。

そのため、改善、変更、追加のフィードバックを大量にさばくことになる可能性が高いです。

大量のフィードバックを受けるなかで、当初の計画からズレていく可能性があります。

②納期遅延がしやすい

アジャイル型開発は全体の詳細計画を設定せず、開発チームのペースで開発を進めることになることも多々あります。

そのため、進捗の管理がしにくくなり、納期に遅れる可能性もあります。

納期遅延を防ぐためには、ある程度、厳密な進行スケジュールを設定したほうがいいでしょう。

アジャイル型開発の向いているシステム(NTQの事例)

アジャイル開発は、要件が曖昧なプロジェクト、または開発の途中で仕様の変更や追加が予想されるプロジェクトに向いている手法です。

例えば、モバイルアプリ、WEBアプリなどユーザーの反応を確認しながら、改善していくシステムはアジャイル型開発が向いています。

弊社でWEBアプリ、モバイルアプリ、SNSアプリ、ECサイト等の開発を行う場合、お客様からの要望も受け、多くの場合はアジャイル型開発を活用します。

また、アジャイル型開発はDXでもベストな開発方式として評価されています。

DXは元来、新たなビジネスモデルへの転換を意味するため、要件をシステム開発開始前に決めることが難しいです。

実際に動くものを見てみないと上手くいくか判断しづらいビジネスアイデアもあります。

これらの特性から、短期間で実際に動く機能を見ながら修正を繰り返していくアジャイル型開発がマッチすると評価されています。

3. その他の開発手法

ここまででウォーターフォール型開発とアジャイル型開発という2つの主要な開発手法について、解説しました。

これら2つの手法ほど名前を聞くことはないものの、他にもいくつか開発手法があります。

ここからは、その他の開発手法をご紹介します。

プロトタイピング型開発

ソフトウェア製品の試作を使って検証や改善を繰り返す手法です。

商品のUI/UXの検証を目的としてプロダクト、サービスなどの開発やデザインの段階で使われ、プロトタイプをユーザー視点で評価し、機能や仕様を洗練していきます。

スパイラル型開発

システムを機能ごとに分けて開発工程を反復するル開発手法です。

一見、アジャイル開発と混乱されやすいですが、スパイラル開発はより品質を重視します。

不明確な要件でプロトタイプを作成した後、ビジネスの観点から改良を繰り返して要件を具体化しながら、機能を完成させます。

DevOps

DevOpsはDevelopment and Operationsの略語で、日本語にすると「開発と運用」という意味になります。

システムの価値を継続的に向上させるために、開発担当者と運用担当者が協力し合える関係を作り出し、運用側から開発側へのフィードバックを繰り返すことでシステムを改善していく手法です。

MVCモデル

MVCはModel、View、Controllerの頭文字です。

Model、View、Controllerのそれぞれに役割を分担してコーディングを行うモデルです。

Webフレームワークのアプリケーション設定に使われることが多いです。

 4. オフショア開発に向いている開発手法は？

請負型ならウォーターフォール型開発

請負型開発は仕様要件書を基に開発し、成果物を納期までにリリースする契約形態です。

そのため、請負型開発はその特性上、要求が明確であるため、ウォーターフォール型開発が向いています。

詳細な要件定義書があれば、成果物と責任範囲が明確になるため、オフショア開発会社に依頼しやすくなり、日本側の管理負担も少なくてすみます。

ラボ型ならアジャイル開発

ラボ型開発はお客様の専任チームを形成し、そのチームを一定期間お貸しする契約形態です。

要件定義をせずに時間単位で確保した優秀なエンジニアに任せることで、ユーザーのフィードバックを反映しながら柔軟に対応できるため、アジャイル開発を活用することが多いです。

特にUI/UXを重視するWEBアプリ、モバイルアプリと特に相性が良く、NTQも含め、多くのオフショア会社はこの手法を得意とします。

5. まとめ

ここまで特に普及しているウォーターフォール型開発とアジャイル型開発をそれぞれのメリットとデメリットを解説し、あわせて他の手法についても簡単に触れました。

また、オフショア開発に向いている開発手法についても言及しました。

開発手法の選択の仕方でオフショア開発のメリットを活用し、デメリットをおさえることも可能です。

開発手法の選択も含め、オフショア開発でお悩みのことがあれば、お気軽にお問い合わせください。

・「お問合せ」ページ