アジャイル開発とは、開発対象のシステムを小さな機能単位に分割し、機能ごとに「計画→設計→実装→テスト→リリース」のサイクルを繰り返しながら開発を進めていくソフトウェア開発手法で、従来のウォーターフォール開発の欠点を補うために誕生した手法です。
昨今では、DX（デジタルトランスフォーメーション）の実現を進めるために「アジャイル開発が必要」という話をよく耳にするようになり、多くの企業から注目を集めています。
今回は、近年システム開発の現場で主流となりつつある「アジャイル開発」について、ウォーターフォール開発との違いやメリット・デメリット、代表的な5つの手法などを詳しく解説します。
目次
１．アジャイル開発とは？
アジャイル開発とは、近年主流になっているシステム・ソフトウェア開発手法の1つで、「計画」→「設計」→「テスト」→「リリース」という開発プロセスを、機能ごとの小さな単位で何度も繰り返しながら、短期間でスピーディーに開発を進めていく手法です。
アジャイル（Agile）には、英語で「素早い」「機敏な」「迅速な」という意味があり、最初から厳密な計画は立てずに、「途中で仕様や設計の変更があること」を前提として、その時々の顧客ニーズに合うように柔軟に開発を行う点が特徴となっています。
不確実性が高く正解の見えない中、手探り状態でDX（デジタルトランスフォーメーション）に取り組むことが必要とされる今の時代において、急な仕様変更にも対応しやすいアジャイル開発は応用が利きやすく、DXと非常に親和性が高いといえます。
「アジャイルソフトウェア開発宣言」とは？
アジャイル開発という概念が生まれたのは2001年のことで、アメリカ・ユタ州に集まった17人の技術者・プログラマーによって提唱されたのが始まりと言われています。
彼らがより良い開発手法について議論する中でまとめられたのが、以下の「アジャイルソフトウェア開発宣言」です。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
アジャイルソフトウェア開発宣言は、「ソフトウェア開発においてどこに重きを置くか」という具体的な価値観を示したもので、「個人との対話」「実際に動くソフトウェア」「顧客との協調」「変化への対応」の4つを特に重視すると述べられており、現在もアジャイル開発の公式文書として広く知られています。
「アジャイルソフトウェア開発宣言の背後にある12の原則」とは？
アジャイルソフトウェア開発宣言には、中核となる上記4つの価値観を支える「12種類の原則」も存在します。
- 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供する。
- 要求の変更は、たとえ開発の後期であっても歓迎する。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。
- 意欲に満ちた人々を集めてプロジェクトを構成する。環境と支援を与え、仕事が無事終わるまで彼らを信頼する。
- 情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすること。
- 動くソフトウェアこそが進捗の最も重要な尺度。
- アジャイル･プロセスは持続可能な開発を促進する。一定のペースを継続的に維持する。
- 技術や設計をレベルアップさせる意識が、俊敏（アジャイル）さを高める。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質。
- 自己組織化したチームのメンバーが協調して動く方が、パフォーマンスが高い。
- 定期的な「振り返り」により、開発チームのパフォーマンスをより高めるようにする。
この原則によれば、アジャイル開発では、
- 顧客ニーズを最優先に考え、顧客にとって価値の高いソフトウェアを素早く開発すること
- 開発後期に仕様変更の要望が出ても受け入れること
- 各機能をできるだけ短いサイクルでリリースし続けること
など、「開発途中に発生する変化を積極的に受け入れる姿勢」が歓迎されます。
また、プロジェクトを進めるにあたって、ユーザーと開発者が綿密なコミュニケーションを取ることの重要性についても示されています。
従来のウォーターフォール開発との違い
システム・ソフトウェア開発でよく使用される代表的な開発手法としては、「アジャイル開発」のほかに「ウォーターフォール開発」があります。
2000年代初頭にアジャイル開発が台頭するまでは、この「ウォーターフォール開発」が主流でした。
「ウォーターフォール開発」は、1970年頃に誕生した比較的古い歴史をもつ開発手法で、その名の通り水が上から下へと流れ落ちるように、「要件定義→設計→開発→テスト」と1つ1つの工程を確実に完了させながら進めていく方法のことです。
最初から厳密に計画を立てて、システムに必要な要件をじっくりと固めてから、当初の計画に忠実にしたがって開発を進めていく方法を取るため、「スケジュールや進捗の管理がしやすい」「予算や人員計画が立てやすい」というメリットがあります。
一方で、「各工程が終わるまでは次には進まず、かつ前の工程には戻らない」ことを前提としているため、開発途中の仕様変更や追加対応は困難というデメリットがあり、前の工程に不備があって手戻りが発生した場合は、コスト増加・プロジェクト遅延などを招くリスクもあります。
機能ごとに細かい開発サイクルを繰り返し、仕様変更を前提としながら短期間で素早く開発を進めていく「アジャイル開発」との違いを整理すると、次のようになります。
２．アジャイル開発のメリット
アジャイル開発のメリットとしては、次の5点が挙げられます。
- 仕様変更に強い
- 手戻りの工数を抑えられる
- 開発スピードが速い
- 顧客のニーズを反映しやすい
- 開発者の成長を促しやすい
仕様変更に強い
アジャイル開発では、最初の計画段階で細かな仕様を決めずに、大まかな方向性だけを決めてから開発をスタートさせるため、開発途中であっても仕様変更・追加に柔軟に対応できる点が最大のメリットといえます。
「開発中に仕様変更があることは当然」という前提でシステム開発が進むため、当初の仕様から変更があったとしても、ウォーターフォール開発に比べれば、金銭的コストやかかる時間を大幅に節約できます。
手戻りの工数を抑えられる
アジャイル開発では、機能ごとの小さな単位で「設計→開発→テスト→修正」という開発サイクルを繰り返しながらシステムを作り上げていきます。
そのため、テストで不具合が発覚したとしても、他の機能に大きな影響を及ぼすことなく、手戻り工数を最小限に抑えながら、迅速に修正対応を行うことができます。
開発スピードが速い
アジャイル開発の場合、大まかな仕様や方向性が決まれば素早く開発に着手でき、小単位に切り分けた機能ごとに開発を進め、開発が完了した機能から順次リリースが可能であるため、全体的に開発スピードを速めることができます。
ウォーターフォール開発のように、最初に仕様をかっちりと固めなくても、大枠が決まった時点で重要な機能から開発に取りかかることができるので、スピーディーに成果物をユーザーへ提供できるというメリットがあります。
顧客のニーズを反映しやすい
アジャイル開発では、1つの機能が完成するたびに顧客からのフィードバックが得られるため、その都度上がってくる要望や改善点をシステム開発過程へ柔軟に取り入れることで、顧客のニーズに対し最大限に応えることが可能です。
顧客と何度もコミュニケーションを密に取りながら開発を進めていくため、後になって「想定していた成果物と違う」などのトラブルが発生しにくい傾向にあり、顧客満足度を高めやすいのもメリットです。
開発者の成長を促しやすい
アジャイル開発では、ウォーターフォール開発とは異なり、「設計者」「プログラマー」「テスター」と各工程で役割が決まっているわけではないため、開発者は多様な作業を複数回にわたって経験できます。
短期間のサイクルで一連の開発工程を繰り返すことから、開発者1人ひとりのスキル向上につながりやすいほか、開発プロセスにおいて課題発見や課題解決の機会も多く、チーム全体の成長も促進できます。
３．アジャイル開発のデメリット
アジャイル開発のデメリットとしては、次の3点が挙げられます。
- 開発の方向性がブレやすい
- システムの全体像を把握しにくい
- スケジュールのコントロールが難しい
開発の方向性がブレやすい
アジャイル開発のデメリットとしては、顧客のニーズに合わせて柔軟な仕様変更が可能であるが故に、かえって場当たり的な開発に陥ってしまい、プロジェクト全体の方向性がブレやすいことが挙げられます。
最初に定めたプロジェクトの「目的」を常に意識し、無駄に工期を引き延ばすことのないよう、開発の方向性をしっかりとコントロールすることが求められます。
システムの全体像を把握しにくい
アジャイル開発は、各機能の開発を個別に進めていく性質上、「他の機能との関連性が分かりにくい」「システム全体がどのような姿になっているのかイメージしにくい」というデメリットもあります。
反面、ウォーターフォール開発であれば、最初の段階ですべての仕様を詳細に決定するため、開発の全体像が明確であり、システムの完成形についてプロジェクトの関係者全員が共通認識を持ちやすいといえます。
スケジュールのコントロールが難しい
アジャイル開発では、機能ごとに小単位で開発を繰り返すため、個々の単位であればスケジュール感や進捗状況は把握しやすいものの、全体スケジュールのコントロールは難しい傾向にあります。
全体的なスケジュールを把握しきれず、場合によっては最終的なリリース日に間に合わなかったり、予算オーバーとなったりするリスクもあるため、納期が厳密に定められている場合は、ウォーターフォール開発のほうが適しているといえます。
４．アジャイル開発の流れ・進め方
アジャイル開発は、主に次の2ステップに沿って進められます。
- リリース計画を立てる
- イテレーション（短いスパンでの開発）を実施する
リリース計画を立てる
アジャイル開発を行う場合、まずは「いつまでにどの機能をリリースするか」というおおよその計画（＝リリース計画）を立てます。
従来のウォーターフォール開発とは異なり、アジャイル開発は「プロジェクト中に仕様や設計の変更は頻繫に発生する」という前提に基づいているため、リリース計画はあくまでもおおよその計画であり、状況に応じて継続的に修正していく必要があります。
リリース計画を立てる際には、以下の項目を最低限決めておく必要があります。
- プロジェクトのゴール
- イテレーションの長さ
- ベロシティの算出
- ユーザーストーリーの優先順位や工数
プロジェクトのゴール
このプロジェクトで何を実現したいのか、目標・ゴールを明確にします。
イテレーションの長さ
イテレーション（iteration）とは、「反復・繰り返し」という意味で、アジャイル開発においては「計画→設計→開発→テスト→リリース」という1つ1つの開発サイクルの単位を表します。
イテレーションの期間は各プロジェクトによって異なりますが、通常は1～4週間程度で設定され、イテレーションごとに機能をリリースするのが基本です。
ちなみに、アジャイル開発の手法の1つである「スクラム開発」においては、イテレーションのことを「スプリント（sprint）」と呼びます。
ベロシティの算出
ベロシティとは、1回のイテレーションにおいてチームがどのくらい開発を行えるのか、作業を進める「速度」や「作業量」を数値化したものです。
簡単に言えば、チームが1スプリント内で完了できる平均的な作業量を表す指標になります。
次のイテレーションで対応可能な作業量や、すべての開発が完了する見込み時期を予測する際に活用され、またチームの成長度合いを把握する際にもベロシティが役立ちます。
ユーザーストーリーの優先順位と工数
ユーザーストーリーとは、「ユーザーがどのような目的で、何を実現したいのか」（意図・要求）を文章で簡潔にまとめたものです。
（例：「ユーザーが気になる商品をお気に入り登録できる」など）
アジャイル開発では、従来の「要件」に代わる概念としてよく用いられます。
リリース計画では、プロジェクトの目標・ゴールに基づいてユーザーストーリーに優先順位を付けていき、それぞれどれくらいの工数が必要となるのかを見積ります。
イテレーション（短いスパンでの開発）を実施する
リリース計画がまとまったら、いよいよ機能ごとに「イテレーション1」「イテレーション2」「イテレーション3」・・・とサイクルを繰り返し、開発を進めていきます。
1回のイテレーションごとに成果物を作成・リリースし、次のイテレーションへ活かすためにチームで開発の振り返りを行ったり、顧客からフィードバックを受けたりしながら、システム全体の完成度を高めていきます。
各イテレーションは「計画」「設計」「開発」「テスト」「改善」「リリース」から構成され、これら一連の工程を1～4週間の短いスパンで繰り返していくのが、アジャイル開発の基本的な流れとなります。
- 計画
目標やスケジュールなどを定義し、考えられるリスクを洗い出して対策を講じます。
- 設計
アーキテクチャ設計やプログラム設計を行います。
- 開発
設計に基づいて、ソフトウェアをプログラミングで開発します。
- テスト
単体テストや結合テストを行い、開発したソフトウェアが仕様どおり動作することを確認します。
- 改善
テストでバグや不具合が発覚したり、改善の余地が見つかった場合は、随時改善を加えます。
イテレーションの期間内であれば何回でも改善が可能です。
- リリース
成果物をリリースします。これで1つのイテレーションが完了です。
1つのイテレーションが終わるごとに、結果や課題についてチームで振り返り、次のイテレーションに活かします。
５．アジャイル開発の手法
アジャイル開発における代表的な開発手法としては、次の5つが挙げられます。
- スクラム開発
- エクストリーム・プログラミング（XP）
- ユーザー機能駆動開発（FDD）
- リーンソフトウェア開発（LSD）
- 適応型ソフトウェア開発（ASD）
スクラム開発
スクラム開発とは、アジャイル開発において最もよく使われている代表的な手法です。
ラグビーで肩を組み、チーム一丸となってぶつかり合うフォーメーションを指す「スクラム」が語源となっており、その名が示す通り、開発チーム内のコミュニケーションを非常に重視する点が特徴です。
スクラム開発では、メンバー自身がイテレーションごとに各々開発計画を立てて、設計・開発を進めていきます。
その際、イテレーションのたびに進捗状況の確認や制作物の動作検証を行うため、メンバー同士のコミュニケーションが不足していると、
「リリースに間に合わない」
「リリースした機能が正常に動作しない」
「ユーザーから要求された通りの機能になっていない」
など、開発の遅れや品質の低下といった問題が起こりやすくなります。
スクラム開発を成功させるためには、日々のミーティングや定期的な振り返りなどを通じて、進捗状況や課題を密に連携しながら、メンバー全員が一致団結して共通の目的に向かって挑む姿勢が求められます。
なお、アジャイル開発では、1チームあたりの人数を10名以下とすることが推奨されており、スクラムのチームも3～10人程度が理想的とされています。
スプリント
スクラム開発では、イテレーションのことを「スプリント」と呼び、機能ごとに短期間で「計画→設計→開発→テスト→リリース」のサイクルを繰り返しながら開発を進めていきます。
スプリントの期間は、1～4週間の間で任意の期間が設定され、チームメンバーは各スプリントにつき最低1つ以上の成果物をリリースできるよう、最善を尽くします。
なお、一般的にスクラム開発では、「いったんスプリントが始まったら、そのスプリントが終了するまでは、機能の追加・変更・削除が認めらない」という制約があります。
チーム構成
役割分担が明確な点も、スクラム開発の特徴の1つです。
- ゴールへの方向性を決定する「プロダクトオーナー」
- 進捗管理を主導する「スクラムマスター」
- 各開発タスクをこなす「開発者」
と、それぞれの果たすべき役割が明確に分かれており、各メンバーが自身の役割に専念しつつ、チーム全員で活発にコミュニケーションを取りながら、効率良く開発を進めていきます。
プロダクトオーナー（PO）
開発プロジェクトの最高責任者。
システム開発の方向性を定め、プロダクト（＝成果物）の価値を最大化することに対して、最終的な決定権と責任を持つ人です。
顧客ニーズをもとに、開発が必要な機能や要件に優先順位を付けてリスト化した「プロダクトバックログ」の内容を、常に最新の状態に保つ役割を担います。
スクラムマスター（SM）
プロジェクト全体の調整役。
スクラムチーム全体の管理やサポートを行い、プロジェクトを円滑に進めることに責任を持つ人です。
チームメンバーに対し適切なアドバイスや指導を行ったり、各メンバーが自分のタスクに集中できるように障害を取り除くなど、チームの自律的な行動を引き出し、成果を最大限に高める役割を担います。
ステークホルダー
資金提供を行うスポンサー、社内の上司、他部門など、プロダクトに対して利害関係を持つスクラムチーム以外の人々。
開発には直接従事しないものの発言権があり、機能の構築や要件の変更に対する意見を仰ぐこともあります。
開発者
実際に開発作業を行うメンバー。システムエンジニアやデザイナー、プログラマーなど。
ウォーターフォール開発と違い、役割ごとに担当する業務が分かれておらず、どの工程のタスクも担当する可能性があるため、専門外の分野であっても積極的に知識やスキルを身につけようとする前向きな姿勢が求められます。
スクラム開発の流れ
スクラム開発における各スプリントの流れは、次のようになります。
- プロダクトバックログの作成
- スプリント計画
- スプリントの開始・デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ（振り返り）
STEP1：プロダクトバックログの作成
プロダクトバックログとは、顧客がシステムに対して何を求めているかを整理した「ユーザーストーリー」に基づき、開発が必要な機能や要件に優先順位を付けてリスト化したものを指します。
優先順位を付けることで、今回のスプリント内で開発する機能を明確にし、チーム全体で目標を達成するための方向性を整理できます。
STEP2：スプリント計画
スプリント計画は、プロダクトバックログをもとに、スクラムチーム全体でスプリントの作業計画を立てることです。
今回のスプリント内で開発したい機能は何か（＝スプリントゴール）を定め、その目標達成に向けて各メンバーが取り組むべき具体的なタスクを整理し、「スプリントバックログ」と呼ばれる計画書を作成します。
いったんスプリントが始まると、途中での仕様変更などは基本的に認められないので、スプリント計画の際は十分な検討を行う必要があります。
STEP3：スプリントの開始・デイリースクラム
スプリント計画が完了したら、スプリントバックログをもとに開発を進めていきます。
スプリント期間中は、「デイリースクラム」と呼ばれる短時間のミーティングを毎日行い、メンバー1人1人が今までの作業状況や本日の作業予定、現状の課題などを共有します。
これにより、メンバー全員がチーム全体の進捗状況を把握し、問題がある場合は迅速に対応できるようになります。
なお、デイリースクラムの実施にあたっては、「毎日同じ時間・場所で行う」「実施時間は15分以内にする」などのルールを厳守する必要があります。
STEP4：スプリントレビュー
スプリントレビューとは、スプリント終了後にスクラムチームが達成した成果を振り返るために行われる会議です。
開発メンバーだけでなく、顧客やステークホルダーも立ち会って、スプリント期間内に完成したシステムの動作検証を行い、期待した通りのものになっているかどうかフィードバックを受けます。
スプリントレビューを通して開発の方向性が正しいか確認し、もし問題や改善点が見つかった場合は、次のスプリントで解決するなどの対策を講じます。
STEP5：スプリントレトロスペクティブ（振り返り）
スプリントレトロスペクティブは、各スプリントを締めくくるために開発チーム内で行われる振り返りミーティングのことです。
スプリントレビューの後に続いて行われることが多く、今回のスプリントで良かった点や反省点、次回のスプリントに向けた改善点などを話し合います。
スプリントレトロスペクティブが終わったら、次のスプリントへ向けてプロダクトバックログの見直しを行い、また最初の手順から繰り返して開発を続けていきます。
エクストリーム・プログラミング（XP）
エクストリーム・プログラミング（Extreme Programming）とは、顧客の要望が変化することを前提として、事前に細かな計画を立てるよりも、開発途中の仕様変更へ柔軟に対応することを強く意識したアジャイル開発の手法の1つです。
略称である「XP」と表記されることもあります。
最初に綿密な計画を立てず、顧客の要望をこまめに確認しながら開発を進め、動作するソフトウェアを頻繁にリリースするのが特徴です。
XPでは、次の5つの価値を重視し、チーム内で共有しながら開発を進めていきます。
- コミュニケーション：開発メンバー同士や顧客との積極的なコミュニケーションを重視する
- シンプル：本当に必要な機能を優先したシンプルな設計を行う
- フィードバック：テストをこまめに行い、顧客からのフィードバックを重視する
- 勇気：仕様や設計の変更に立ち向かう勇気を持つ
- 尊重：顧客やチームの仲間の意見を尊重する姿勢を示す
また、XPでよく利用されるプラクティス（＝ソフトウェア開発における問題発生のリスクを低減する具体的かつ経験則的な活動）としては、「ペアプログラミング」が代表的です。
ペアプログラミングは、プログラマーが2人1組のペアになり、1人がコードを記述し、もう1人がすぐにレビューしながら共同で開発を進めていく方法で、それぞれ異なる視点からコードを確認できるため、問題点を発見しやすいなど多くのメリットがあります。
ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（Feature Driven Development／FDD）は、顧客目線に立ち、顧客にとっての機能価値（＝フィーチャー）を重視して進めるアジャイル開発手法です。
顧客のビジネスモデルを深く理解したうえで、必要と思われる機能をリストアップし、ビジネスにおける適切なタイミングで、顧客が求める機能を繰り返し開発・リリースしていきます。
「ソフトウェアの各機能に対して、顧客が本当に求めるものは何か」という顧客の根本的な要望を重視して開発を進めるため、高品質なシステムを作りやすい手法と言われています。
さらに、機能ごとにチームを分けて計画・設計・構築を進めていくことから、大規模なプロジェクトにも対応しやすいメリットがあるほか、チーム内外でのコミュニケーションは「ドキュメント」でのやり取りを重視する点も特徴的です。
リーンソフトウェア開発（LSD）
リーンソフトウェア開発（Lean Software Development／LSD）とは、製造の工程から徹底的に無駄をなくすことを重視する「リーン生産方式」の考え方を、ソフトウェア開発の分野に応用した手法です。
「リーン（lean）」は「痩せた」「無駄のない」という意味を表しており、リーン生産方式は「必要なものを、必要なときに、必要な分だけ生産する」という「トヨタ生産方式」の考え方がベースになっています。
リーンソフトウェア開発には、決まったノウハウやフレームワークはありませんが、以下の7原則に基づいて開発を進めることが特徴です。
- 無駄をなくす
- 不具合を未然に防ぎ、品質を高める
- フィードバックから得た知識を蓄積・活用する
- 重要な意思決定を急がない
- ソフトウェアを迅速にリリースする
- メンバーを尊重する
- 開発プロセス全体を見て最適化する
適応型ソフトウェア開発（ASD）
適応的ソフトウェア開発（Adaptive Software Development／ASD）とは、継続的な仕様変化に適応することを重視したアジャイル開発手法の1つで、複雑で状況変化の激しいシステムを開発する場合に適した手法です。
「思索」「協調」「学習」という3つのサイクルを繰り返しながら、短期集中で開発を進めていくのが特徴です。
思索（スペキュレーション）
- どのような機能を開発するか検討する
- 未確定の部分は、サイクルの反復の中で決めていく
協調（コラボレ―ション）
- 「思索」で決めた計画に沿って、実際に開発作業を行う
- チーム内で開発に必要な知識の共有を積極的に行い、密接にコミュニケーションを取りながら進める
学習（ラーニング）
- 完成した成果物の品質レビューを行う
- ユーザー視点や開発者視点など、さまざまな視点からフィードバックを受け、より良いシステムへと改善する
６．アジャイル開発に向いているプロジェクト
アジャイル開発は、次に挙げるようなプロジェクトに適しています。
要件の全体像がはっきりしていない
アジャイル開発は、顧客の要件が固まっておらず、ニーズが漠然としていて開発内容の全体像が明確でない場合に向いています。
開発途中の仕様変更や追加対応を前提としているアジャイル開発では、開発の方向性さえ7割程度定まっていれば、残り3割の要件は開発を進めながら決めることができるためです。
システムを小さな単位で部分的に作り、実際に動かしてみてから不明瞭だった部分を決められるので、顧客自身も気付いていない潜在的なニーズまで反映して完成度を高めていくことができます。
ニーズが漠然としているケースの例
- 独自システムを作る場合などで、必要な機能を具体化しづらい
- 新規事業で前例がなく、部分的に使ってみないと何の機能が必要かよく分からない
- ソフトウェア開発を依頼するのが初めてで、ニーズが上手く表現できない
開発途中で優先度が変化する可能性が高い
市場ニーズの変化によって、開発する機能の優先順位が変わったり、頻繫に仕様変更が想定される場合にも、アジャイル開発が向いています。
特に、Webサービス（EC、SNSなど）やスマートフォンアプリ、ゲームなど、トレンドやニーズの移り変わりが激しく、新技術が次々と登場するような分野では、最初から仕様を完全に固めるウォーターフォール開発より、開発途中でも少ない手戻りで仕様の変更ができるアジャイル開発のほうが、コストを最小限に抑えられます。
状況変化が想定されるケースの例
- 流行の移り変わりが激しい分野で、開発途中で市場ニーズが変わる可能性がある
- 新規プロジェクトのため、今後の状況によって開発する機能の優先度が変わりそう
顧客が積極的に開発プロセスに関わってくれる
ユーザー（発注側）が開発の全工程に関わり、チームの一員として積極的に意見を出してくれるようなケースでも、アジャイル開発を採用することで、開発の質を大幅に上げることが可能です。
アジャイル開発は、顧客からのフィードバックを最大限汲み取りながら、継続的にプロダクトの改善を行っていく手法のため、顧客がベンダー側に開発を丸投げするような状態では開発スピードが落ちてしまい、せっかくのアジャイル開発の強みを活かせないので注意が必要です。
ユーザー（発注側）が積極的に開発プロセスに関わるケースの例
- こだわりを多く詰め込んだシステムをユーザーが開発したい場合
７．ウォーターフォール開発に向いているプロジェクト
反対に、ウォーターフォール開発には、次に挙げるようなプロジェクトが適しています。
対面で円滑なコミュニケーションを取りづらい
開発チームのメンバー同士や顧客との間で、対面での円滑なコミュニケーションが取りにくいと想定される場合は、アジャイル開発には向いていません。
アジャイル開発では、開発過程でメンバーと積極的に意見交換することによって、仕様の細部を決めたり開発のクオリティを上げていきます。
そのため、チームで対面でのコミュニケーション機会が不足すると、顧客のニーズを反映させた開発を行うことが難しくなったり、開発がなかなか進まずに余計な時間やコストがかかるといったリスクが生じます。
厳格なスケジュール管理が求められている
リリースまでの期限が明確に決まっており、厳格なスケジュール管理が求められているケースも、アジャイル開発に適していません。
アジャイル開発では、顧客のニーズに合わせて都度対応していくため、開発期間が延びやすい傾向にあり、全体の進捗状況やスケジュールを厳密に管理するのは困難といえます。
開発スケジュールに余裕があり、多少納期に遅れても支障がない場合に、アジャイル開発を採用するようにしましょう。
正確性や安定性を重視し、仕様変更の可能性が少ない
既存の社内システムをリプレイスする場合など、現在の仕様が固まっており、開発途中で仕様変更が発生するとは考えにくいプロジェクトについては、小単位で開発を繰り返すアジャイル開発はかえって非効率的であり、従来のウォーターフォール開発のほうが適しているといえます。
また、金融システムやインフラなど、何よりも安定性・信頼性が重視され、誤作動やバグが一切許されない分野についても、手間と時間をかけてでも厳密な要件定義・設計を行い、確実に正しく動くシステムを開発することが求められるため、アジャイル開発よりウォーターフォール開発のほうが適しています。
８．両者の良いとこ取りをした「ハイブリッド開発」も
なお、アジャイル開発とウォーターフォール開発の両者のメリットを取り入れた「ハイブリッド開発」という手法もあり、主に次のような特徴があります。
- 要件定義、基本設計、総合テストなど、ウォーターフォール開発が得意とする上流工程や下流工程はウォーターフォール開発で行う
- 詳細設計、開発、単体テストなど、アジャイル開発が得意とする中流工程はアジャイル開発で行う
ウォーターフォール開発の「仕様や計画の変更がしにくい」「手戻り工数が大きくなりがち」といったデメリットや、アジャイル開発の「開発の方向性がブレやすい」「スケジュールや進捗管理がしにくい」といったデメリットをカバーし、それぞれのメリットを活かした開発を進められます。
９．まとめ
いかがでしたでしょうか？
アジャイル開発は、2001年に登場した比較的新しい開発手法で、「仕様変更に強い」「開発期間が短い」といった、従来のウォーターフォール開発にはないさまざまな特徴があります。
さらに、アジャイル開発では、「イテレーション」「スプリント」「ベロシティ」「ユーザーストーリー」など、聞きなれない専門用語がたくさん登場するため、まずはそれぞれの言葉の意味を正確に理解するところから始めてみるのが良いでしょう。
なお、当社コンピュータマネジメントでは、「情報システム部門の業務効率化に向けて、専門家の視点から具体的なアドバイスが欲しい」と感じている企業様向けに、情シス支援サービス「ION」を行っております。
以下リンクより情シス支援サービス「ION」に関する資料を無料でダウンロードすることができますので、興味のある方はぜひチェックしてみてください。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
