システム・ソフトウェア開発を考えている事業者の中には、「アジャイル開発が早くて良い」と聞いたことがある方も多いのではないでしょうか。
アジャイル開発は、2000年代に登場した比較的新しい開発手法で、現在では主要な開発手法の一つとなっています。
本記事では、アジャイル開発の概要や、メリット・デメリット、代表的な手法、アジャイル開発が向いているケースなどについて、詳しく解説します。
目次
アジャイル開発とは
「アジャイル開発」とは、開発とリリースを短いサイクルで繰り返していくソフトウェア開発手法のことです。
機能単位で細かに区切った、要件定義・設計・実装・テスト・リリースのサイクルのことを「イテレーション」と呼びます。
2001年、アメリカ・ユタ州で、より効果的なソフトウェア開発方法を模索する17人の専門家が集まり議論を行いました。その中で誕生したのが「アジャイルソフトウェア開発宣言」です。
「アジャイルソフトウェア開発宣言」の概要
「アジャイルソフトウェア開発宣言」のなかでは、ウォーターフォール開発を主流とする従来の開発手法の価値を認めたうえで、今後はより一層ユーザーを意識し、変化に対して柔軟かつ素早く対応することが重要だと語られています。
また、あわせて発表された「アジャイル宣言の背後にある12原則」では、チームでプロジェクトを進める際には、顧客第一の視点を持って改善を繰り返すという考え方が示されました。
アジャイル開発は、この「アジャイルソフトウェア開発宣言」を、具体的な開発手法に落とし込んだものです。
近年、アジャイル開発が注目されている理由
2000年代以前のソフトウェア開発の主流は、リリースまでの「売り切り型」でした。しかし、近年ではインターネットの普及に伴い、継続的なアップデートやサブスクリプションなど、継続的な価値提供を実現するスタイルが求められています。
顧客のフィードバックを受けながら素早く柔軟に対応していくアジャイル開発は、近年のニーズに応えうる手法として、広く採用されているのです。
アジャイル開発とウォーターフォール開発の違い
アジャイル開発では、はじめに開発工程全体を小分けにします。それぞれの工程は1～2週間ほどの短期間で完成し、それを繰り返すことでプロダクトの完成に近づけていきます。柔軟にクライアントの要望に対応でき、不具合発生時の対応工数が少なく、時間やコスト削減が可能な点が特徴です。
一方、ウォーターフォール開発とは、要件定義、設計、開発、テスト等の開発工程を、予め立てた計画に沿って順番に完了させ、最後にリリースする開発方法のことです。方針を決定してから開発を進めるため、進捗管理がしやすく、予算やメンバーのアサイン計画を立てやすいといったメリットがあります。
ただし、工程の後戻りが難しいため、開発途中での仕様変更がしにくく、開発の時間やコストが掛かることがデメリットです。
アジャイル開発のメリット・デメリット
アジャイル開発には、いくつかのメリットとデメリットがあります。それぞれ見ていきましょう。
メリット
アジャイル開発はイテレーションごとに開発を進めるため、仕様変更・追加に柔軟に対応しやすく、顧客やユーザーのニーズを反映しやすい点が大きなメリットです。
また、優先度順にテストとリリースを行うため、開発期間を短縮できるとともに、問題が発生した場合も後戻りの工数を抑えられます。そのため、開発側・クライアント側の両方にとって、無駄な時間やコストが生じにくくなることも魅力です。
さらに、開発工程を複数回、繰り返しコミュニケーションをとりながらブラッシュアップを行うため、開発者の成長を促しやすく、クライアントも高品質な成果物を得られる可能性が高まります。
デメリット
アジャイル開発のデメリットは、随時仕様変更が発生し得るため、スケジュールの全容を確定しづらい点です。工程ごとの期限が明確でない場合も多く、締切が守られなかったり、処理漏れが発生したりするリスクもあります。
また、メンバー間のコミュニケーションがうまくいかないと、開発が遅れる原因になりがちです。とくにプロジェクトが長期化し、メンバーの入れ替わりがあった場合、メンバー間の目的意識がずれたり、開発クオリティが変動したりする恐れがあります。そのため、アジャイル開発ではメンバー間の密接なコミュニケーションと、進捗状況の適切な管理が重要です。
仕様変更の可能性が少ないケースや、メンバー同士でコミュニケーションが取りづらいケース、リリース期日が厳格に決まっているケースでは、アジャイル開発を避けるのが望ましいでしょう。
アジャイル開発の流れ
アジャイル開発の基本的な流れは、以下の2つのフェーズに大別できます。
- リリース計画を策定する
- イテレーションを実行する
それぞれのフェーズについて詳しく解説します。
リリース計画を策定する
アジャイル開発では、まずはじめに、システム開発の全体計画を立てます。以下のような要素を取りまとめて、計画に落とし込みましょう。
- プロジェクトで実現する目標・ゴール
- イテレーションの長さ
- ベロシティ（1イテレーションでチームがどれくらい開発ができるか）の算出
- ユーザーの要望の優先順位付け
- 必要な工数の見積もり
アジャイル開発では、計画になかった要求や変更が途中で生じることも多いため、変更を前提としてプロジェクトを進めていきます。そのため、厳密な計画は決めず、開発を進める際の大体の方向性を打ち合わせる程度にとどめるのがポイントです。
イテレーションを実行する
リリース計画が策定されたら、それに基づいて機能ごとのイテレーションを繰り返し、製品を完成させていきます。各イテレーションが終了するたびにチームで振り返りを行い、顧客からのフィードバックを受けます。そして、顧客からの修正・追加等の要望を次のイテレーションに反映していくという流れです。
このサイクルを繰り返してブラッシュアップを重ね、ニーズに合った製品を開発していきます。
アジャイル開発の代表的な手法
アジャイル開発にはいくつもの手法があり、なかでも代表的なものが以下の4つです。
- スクラム
- エクストリーム・プログラミング（XP）
- カンバン
- ユーザー機能駆動開発 (FDD)
各手法の特徴を詳しく見ていきましょう。
スクラム
スクラムは、アジャイル開発の代表的な手法です。「スクラムガイド」という公式ガイドラインが存在しており、フレームワークとして参照されることが多いのが特徴です。
スクラムでは、メンバーたち自身が計画を立て、開発の進行や制作物に問題がないか等をイテレーション毎に精査します。
また、各メンバーにはそれぞれ明確に役割が充てられます。主な役割は以下の通りです。
- プロダクトオーナー：開発プロセス全体の方向性を決定する
- スクラムマスター：進捗管理を行う
- 開発者：各開発タスクを行う
各々が自身の役割を達成すると同時に、チーム全員が積極的にコミュニケーションをとり、協力して開発を進めることが重要です。
エクストリーム・プログラミング（XP)
エクストリーム・プログラミング（XP）は、事前に策定した計画への忠実性よりも、途中変更等の柔軟性を重視する手法です。
顧客の要望が変化することを前提とした手法であるため、詳細な計画は立てずに、顧客の要望をこまめに反映しながら、ソフトウェアを頻繁にリリースする点が特徴です。
XPの提唱者であるケント・ベック氏は、この手法を実施する際に重視するポイントとして、以下の5点を挙げています。
- コミュニケーション：チームメンバー、クライアントとの顧客を最重視する
- シンプル：最もシンプルな方法を実現するために何ができるかを考える
- フィードバック：常に変化する状況の中で、フィードバックを受けて常に改善を続ける
- 勇気：大胆な変更や素直な報告等、XPの実施に当たっての勇気を持つ
- 尊重：メンバーを互いに尊重しあう。相互にリスペクトする関係性があって初めてXPの価値は意味をもつ
なお、XPの代表例としては、2人のプログラマーが共同で開発を進める「ペアプログラミング」があります。1人が記述し、もう1人がレビューする形で、2人のプログラマーが各々の視点からコードを確認するため、問題を発見しやすい点が特徴です。
カンバン
カンバンは、名前の通り「看板」「標識」を意味し、行動の起点となる信号＝タスクを見える化して管理する手法のことです。
この手法では、洗い出したタスクに優先順位をつけ、着手するタスクの数に制限をかけて着手していきます。状況に応じて各タスクをカンバンボードの「To Do」「進行中」「完了」などの領域に貼り付けることで、見える化していきます。
各タスクの配置場所を確認することで、状況を迅速に把握できるため、リアルタイムに状況把握が必要なアジャイル開発と看板は相性が良い週報と言えるでしょう。
ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（FDD）は、クライアント目線で価値のある機能を中心に開発を進める手法です。
まず、プロジェクトに対するクライアントの要望を明確に汲み取り、機能ごとの設計・構築を「フューチャーリスト」にまとめます。そして、開発工程では適切なタイミングでクライアントへの提供を繰り返し、プロセスを進めていく流れです。
ユーザー機能駆動開発では、機能に重点を置くため、他の開発手法に比べて価値が高い機能の実装を実現しやすい点が特徴です。ただし、正確なクライアントニーズのくみ取りが必要となるため、計画段階からクライアントとの密にコミュニケーションをとることが求められます。
アジャイル開発が向いているケース
アジャイル開発が向いているのは、以下にあてはまるケースです。
- 要件の全体像がはっきりと決まっていないケース
- 開発途中で仕様が変わることが予想されるケース
- 顧客が開発に積極的に関わってくれるケース
- リリース後に継続的に運用していくケース
それぞれのケースについて解説していきます。
要件の全体像がはっきりと決まっていないケース
要件の全体像がはっきりしていないプロジェクトの場合、アジャイル開発が適しています。アジャイル開発であれば、ある程度を要件定義で定め、残りはプロジェクトの状況を確認しながら固められるためです。
完成した部分をクライアントが確認し、残りの要件を決めながら最終的な完成形に仕上げていきます。
開発途中で仕様が変わることが予想されるケース
開発途中で優先順位や仕様の変更が想定される場合も、アジャイル開発が合っているでしょう。アジャイル開発なら、機能毎に分割し短期間の開発を繰り返していくため、少ない手戻りで仕様変更が可能なためです。
一方、ウォーターフォール開発では、基本的に前工程に戻すことは困難です。そのため、開発が進んだ段階で機能変更などが生じた場合、変更や修正に多くの時間やコストがかかってしまいます。
これらを踏まえると、アジャイル開発は流行の移り変わりが激しい分野や、新規プロジェクトなど、開発途中での状況変化が予想されるケースに向いていると言えるでしょう。
顧客が開発に積極的に関わってくれるケース
顧客が開発に積極的に関わるかどうかは、アジャイル開発の成否を左右する要素のひとつです。
顧客がチームの一員として関わり、開発会社と密なコミュニケーションを取ってくれるケースならば、アジャイル開発のメリットを享受しやすいでしょう。例えばスクラムの手法で開発する場合、顧客がプロダクトオーナーの役割を担うことで、開発会社はより確実に顧客のニーズを汲むことができます。
逆に、開発会社に全て任せるようなケースでアジャイル開発を実施すると、開発スピードの低下につながる可能性があります。
このように、顧客がプロジェクトに深く関わるほど、アジャイル開発のメリットを引き出しやすくなるのです。
リリース後に継続的に運用していくケース
サービスを一度リリースして終わりではなく、新機能の実装や改善を継続的に繰り返すプロジェクトには、アジャイル開発が向いています。
例えば、サブスクリプション型サービスのアプリケーションや、スマホゲームアプリのように、ユーザーの操作性を重要視するシステム・ソフトでは、リリース後もユーザーの声を反映してブラッシュアップしなければいけません。特に、アプリ業界ではニーズの移り変わりや市場競争が激しいため、迅速な対応とローンチが重要です。
そのため、テストと修正を繰り返してスピーディに完成度を高められるアジャイル開発が向いていると言えるでしょう。
まとめ
アジャイル開発は、ウォーターフォール開発と比べてスケジュールの全容が確定しづらいものの、工程の見直しと後戻りがしやすく、ユーザーなどからのフィードバックを反映しやすい点で優れています。
その柔軟性の高さやコストの低さといった特性から、要件の全体像が決まり切っていないケースや、開発途中で仕様が変わるケース、リリース後も継続的に運用していくケースなどに向いています。特に、開発側とコミュニケーションを密にとりながら、低コストで高品質なシステムを開発・運用していきたい事業者におすすめの方法と言えるでしょう。
株式会社relationでは、多種多様な業種やサービスの開発・運用を行っており、お客様に寄り添ったICT戦略をご提案させていただいています。開発規模などに関わらず、お客様に合わせた専門チームを編成し、開発だけでなく運用までサポートさせていただくのが強みです。
「サービスの全体像や計画は決まっていないけれど開発を始めたい」「自社の声に耳を傾けてくれて一緒に運用までしてくれるパートナーが欲しい」といった事業者の方は、ぜひお気軽に株式会社relationにお問い合わせください。
