いまさら聞けない基本"を解説！

アジャイル開発とは？開発手法やメリット・デメリット

システムの開発手法として主流だったウォーターフォール開発に変わり、存在感を示している開発手法が「アジャイル開発」です。アジャイル開発では、設計やテストなどの開発工程を小さいサイクルで繰り返す手法を取り、開発期間の短縮を実現しています。

ではなぜ、アジャイル開発を活用することで開発スピードがアップするのでしょうか。ここでは、ウォーターフォール開発とアジャイル開発の違いや、スクラムに代表されるアジャイル開発の手法、さらにメリットやデメリット、アジャイル開発に向いているプロジェクトなどを詳しく解説します。

アジャイル開発とは？

アジャイル開発（アジャイルソフトウェア開発）は、近年存在感を示している、システムやソフトウェア開発手法のひとつです。

アジャイル開発の原型が生まれたのは1990年代。後述する「スクラム」や「XP」といった手法がまず誕生し、2001年には、これらの開発者が集って「アジャイルソフトウェア開発宣言」がされました。ここからアジャイル開発という概念が広く知られるようになります。

アジャイル開発は、機能単位の小さいサイクルで開発を繰り返す手法を取っています。各プロセスに目標や成果物が設定されているため、それらを満たすことで品質が自然に担保される仕組みです。

アジャイル開発が近年主流になったのは、サービスインまでにかかる時間を短縮できたり、開発途中で仕様や要件の変更に柔軟に対応できるためです。現代のソフトウェア開発はスピードが求められるうえ、リリース後も製品力の強化のために改良を続ける必要があり、アジャイル開発と相性がよいと考えられています。

従来のウォーターフォール開発との違い

アジャイル開発以前に主流だったのがウォーターフォール開発です。ウォーターフォール開発では、工程を後戻りしない前提で開発を行う古典的な手法です。

ウォーターフォール開発では、要件定義や全体の設計を固めてから開発に着手するため、開発が開始するまでに時間がかかり、開発途中での仕様変更が困難です。また、「設計、開発、実装、テスト、運用」などの各工程で行う段階的に完了させていくので、柔軟な対応がしづらく、結果として開発期間の延期に繋がることがあります。

その点アジャイル開発は、開発途中で仕様変更があっても、工程を小さく後戻りして開発を繰り返せるため、開発期間を短縮でき、コストも抑えられます。

アジャイル開発の代表的な手法

アジャイル開発には、いくつかの開発手法が存在します。ここでは、代表的な手法を3つ紹介します。

スクラム

「スクラム」は、アジャイル開発の中でもっとも有名な手法・フレームワークです。

メンバーは基本的に固定されていて、「プロダクトオーナー」「開発者」「スクラムマスター」などの役割が与えられます。メンバー自ら開発計画を決め、進行状況や制作物を精査します。そのため、メンバー間のコミュニケーションが重要です。

スクラムが正しく機能し、コミュニケーションも良好な状態では、小回りの効く強力な組織となり、開発要求に俊敏に応えられます。メンバー同士の得手、不得手を理解したうえで開発を行うため、お互いをカバーしあうことも可能です。

一方で、コミュニケーションが足りず、正常に機能しないと、制作物がリリースできなかったり、クオリティに問題が起こったりします。語源となったラグビーの「スクラム」のように、チーム全員が協調できるかがカギです。

エクストリーム・プログラミング（XP）

「エクストリーム・プログラミング（XP）」は、スクラムよりも継続的な対応に強い開発手法です。

チームでは「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」の5つの価値を中心に据えて開発に取り組んでいきます。また、スクラムと同じくコミュニケーションも大切です。

開発方針はできるだけ「シンプル」なことで、不要な機能はそぎ落とします。また、最初に緻密な計画を立てるのではなく、開発が進むとともに臨機応変に対応していくため、スクラムよりも計画の変更に対してさらに柔軟です。

こうした特性から、顧客の要望などを取り入れつつ、技術面を重視して柔軟に対応したいプログラマー中心の開発に特に向いています。

ユーザー機能駆動開発（FDD）

「ユーザー機能駆動開発（Feature Driven Development：FDD）」は、ユーザーにとって価値のある機能を特に重視して開発を行う手法で、2週間程度の短い期間でシステムを作成し、ユーザーに提供します。

FDDでは、「全体モデル開発」「フィーチャーリストの構築」「フィーチャーごとの計画」「フィーチャーごとの設計」「フィーチャーごとの構築」の5つの基本活動を基に開発を進めます。

機能を重視したシンプルな開発を得意とし、大規模なプロジェクトにも対応できます。一方で、顧客からの要望が開発の基本になるため、あらかじめ顧客が求める機能を正確に把握する必要があり、相応のコミュニケーションコストが発生します。

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

開発スピードが速い

アジャイル開発の最大のメリットは、臨機応変な対応が可能なことと、開発スピードが速いことです。

最初にすべて決定してから開発を行うのではなく、各機能を切り分けて「開発→実装→テスト」を繰り返し行うことや、ウォーターフォールモデルとは違って手戻りが少ないことから、リリースまでの時間を短縮できます。

不具合の修正工数が少なく済む

アジャイル開発は、各機能を切り分けて開発を行うため、不具合が発生したときの修正作業がスムーズです。

従来のウォーターフォールモデルは全体をまとめて開発するため、トラブルが起きた箇所によっては、手戻り工数が多くなり、全体の再設計を行うこともありました。しかし、アジャイル開発であれば、ずっと少ない工数で修正できます。

顧客のニーズに応じやすい

アジャイル開発では、開発サイクルごとに顧客の要望とのすり合わせを行います。一見面倒にも思えますが、開発中に顧客とコミュニケーションを取りながらの開発となるため、顧客の要望から大きく外れてしまうことがなくなります。

顧客の要望をヒアリングする機会も多いことから、顧客のビジネス状況の変化なども把握しやすくなり、細かなニーズに応じやすくなるメリットもあります。

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

全体のスケジュールがわかりづらい

アジャイル開発は機能ごとに開発を行うため、全体のスケジュールが見えづらくなるデメリットがあります。

プロジェクト全体のスケジュールが把握しづらいため、想定より開発期間が長くなりがちで、リリースの期限が厳密に決まっているプロジェクトにはあまり向きません。

開発の方向性がぶれやすい

アジャイル開発では、最初に明確な仕様を決定せずに開発を進めます。それゆえ、要件の追加や変更に強い一方で、開発の方向性がぶれやすいデメリットがあります。

また、顧客とのコミュニケーションがうまくいかなかったり、要望を聞きすぎてしまったりして、それらが影響して方向性がぶれることもあります。

アジャイル開発では、場当たり的な開発に陥ってしまったり、当初の方向性が大きくズレてしまったりしないよう、常に方向性をコントロールする必要があります。

アジャイル開発に向いているプロジェクト

途中で仕様変更が想定されるプロジェクト

アジャイル開発は、最初にすべての要件定義を行わなくても開発をスタートできます。また、仕様変更に強いことも長所です。そのため、途中で柔軟に仕様を変更していくことを前提として、ひとまず70％ほど要件定義が固まったところでプロジェクトを発進できます。

また、顧客が将来的なビジネスの状況を予想しきれていないものの、システム開発は早めに始めておきたいケースにも向いています。現代はビジネスを取り巻く状況が刻一刻と変わっていきますが、アジャイルであれば柔軟に仕様を変更しながら開発を行えます。

顧客がチームの一員として参画するプロジェクト

従来のウォーターフォール開発でも、顧客がプロジェクトに参画することがありました。その場合、システムの最終チェックが主な役目でしたが、アジャイル開発ではチームの一員として参画できます。

スクラムであれば、「プロダクトオーナー」を顧客であるクライアントの担当者が担います。従来見えづらかったシステム開発の状況がリアルタイムで把握でき、顧客側にとっての大きなメリットとなります。

その他のメンバーにとっては、プロダクトオーナーが要件を伝えてくれたり、連絡役となってくれるため、より柔軟に開発が進められることがメリットとなるでしょう。

アジャイル開発は「DX推進」にも重要

近年、注目を集める「DX（デジタルトランスフォーメーション）」の推進にも、アジャイル開発は重要な役割を果たすと考えられています。

DXは、ビッグデータやデジタル技術を駆使して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを再構築したり、変革したりといった概念のことです。

DXでは絶えず変化する市場を意識する必要があるため、柔軟に仕様変更ができ、かつ開発スピードも速いアジャイル開発が適切と考えられており、このことは情報処理推進機構が発行する「DX白書白書2021」でも指摘されています。

出典：DX白書2021｜IPA（情報処理推進機構）

アジャイル開発とDevOpsの違い

もうひとつ、DX推進に重要な役割を果たすと考えられているものに「DevOps」があります。

DevOpsとは、開発チームと運用チームが緊密に連携・協力して、ソフトウェア開発をスピーディーに行う手法のことです。開発チームと運用チームは、立場の違いから対立してしまうことがありますが、DevOpsでは双方が協力することの重要性を説いています。

DevOpsでは、互いに尊重しあうこと（Respect）、互いを信頼しあうこと（Trust）、失敗に対して健全な態度を取ること（Healthy attitude about failure）、非難しないこと（Avoiding Blame）といった4つのマインドを重視し、さまざまなツールの力も借りてチームの連携を目指します。

DevOpsの狙いが正しく機能すると、プロジェクトの生産性と開発スピードが向上し、プロダクトの信頼性も向上するため、プロダクトのビジネス的な価値が高まります。

アジャイルは開発の手法のことであり、DevOpsは開発チームと運用チームの協力に関する概念のため、言葉の示す意味は違います。アジャイル開発を行いつつ、DevOpsを取り入れることも可能で、このふたつは協力関係としても機能します。