アジャイル開発とはわかりやすく言うとどのような開発手法なのでしょうか？
アジャイル開発は、従来の開発手法よりスピード感があり、クライアントからの変更リクエストなどに素早く対応することができるため、変化の激しい現代に適した手法として浸透しています。
アジャイルという言葉は、かつては、主にIT業界で使われていた言葉でしたが、最近では企業がビジネスをすすめていく時の考え方として、様々な場面で活用が進んでいます。
そこで今回は、アジャイル開発に注目し、アジャイル開発のメリット・デメリットを含めて解説します。
アジャイル開発を簡単に解説
アジャイルとは、「素早い、機敏な」といった意味を表す形容詞です。アジャイル開発では、機能単位で「計画→設計→開発→テスト→納品」という開発工程を繰り返します。語弊を恐れずに言うなら「作りながら考える」開発手法となるでしょう。
機能単位で開発工程を繰り返すため、単にスピーディに開発できるだけの開発手法ではなく、クライアントの要求に素早く対応でき、プロダクトの価値を最大限発揮させることに重点を置いた開発手法なのです。
また、アジャイル開発はアジャイルなソフトウェア開発手法の総称です。アジャイル開発の、基本的なプロセスに基づいた複数の開発手法が存在します。
それでは、アジャイル開発について更に詳しく見ていきましょう。
アジャイル開発を詳しく解説
スピードを加速させ、プロダクトの価値を最大限に発揮させる効果をもたらすのが、アジャイル開発です。
この章では、「アジャイル開発とは何か」についてさらに詳しく解説します。
アジャイル開発の歴史・背景
アジャイル開発を理解するには、登場するまでの歴史と、必要とされるようになった背景を知ることは重要です。
新しい考え方は、従来の考え方の問題点や、課題を解決するための解決策として登場してくるものです。アジャイル開発も同様で、従来の開発手法の問題点や課題を解決する手法として発展してきました。
1990年代半ばになると、ソフトウェア開発技術者が、スピード感をもって高品質の開発をすすめるためには、従来の手法では対応できない状況になってきていました。
そのため、解決策として新しい開発手法が提案されるようになってきました。それが、アジャイル開発の始まりだといわれています。1990年代には、スクラム、エクストリームプログラミング（XP）、ユーザ機能駆動開発（FDD）などの開発手法が、次々に提案されました。
2000年代に入ると、アジャイル開発はより世界に向けて明確に発信されるようになります。その大きな原動力となったのが、次の宣言です。
2001年に、当時のアジャイル開発分野で名声を博していた17名が集まりました。17名は、それぞれが自分が考えるアジャイル開発手法を提案してきたわけですが、この会合では、アジャイル開発の統一した原則を公式に定義するために議論しました。この会合でできあがった文書が、以下に引用した宣言です。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas© 2001, 上記の著者たち
アジャイルソフトウェア開発宣言
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。
宣言には、著者として会合に参加した17名の名前が記載されています。世界中の言語で翻訳可能な形式で掲載され、コピーも自由なため、世界中にメッセージが明確に拡散されています。
従来の開発手法との違い
従来の開発手法（ウォーターフォール開発）の問題点や課題を解決する手法として、アジャイル開発は発展してきました。具体的にどこが違うのでしょうか。
ウォーターフォールとは、滝のように、上から下まで水が落ちるように開発工程をすすめていく手法です。滝の水は落下すると元には戻りませんし、下方向以外の方向に進路を変えることもできません。
従来の開発手法は、ゴールを明確に決め、詳細に計画を立てます。工程は計画に沿って、順番に実施されていきます。前の工程が終わらないと、次の工程には進めません。また、クライアントからの変更リクエストに対して、柔軟に対応することが困難になります。万が一、変更が必要になった場合は、計画段階からやり直さなければならないケースが多く、膨大な時間と費用のロスが生じる可能性があります。
一方アジャイル開発は、機能単位で「計画→設計→開発→テスト→納品」という工程を継続しますので、クライアントの要求を確認することができます。その結果変更点が生じても、小さな単位で柔軟に対応できます。
ウォーターフォール開発は以下の記事で詳しく解説しています。
アジャイル開発の流れ
アジャイル開発の流れは、詳細では、後述するスクラム、XP、FDDなど、それぞれの開発手法によって違います。ここでは、各手法に共通する基本的な流れを紹介します。
反復増加型プロセス
アジャイル開発では、機能単位で「計画→設計→開発→テスト→納品」という開発工程を反復して、反復ごとに機能を増加させていきます。この流れを「反復増加型開発」と呼び、共通したプロセスになります。
リリース計画
アジャイルで開発を始める際には、詳細な計画をたてることはありませんが、大まかな仕様や開発対象などを計画します。また、反復増加型プロセスで、どの機能を先行して進めるか、開発工程に載せるのか、といった順位づけや、規模見積りなどを行います。
イテレーション
反復増加型プロセスの中のひとつの機能単位での「計画→設計→開発→テスト→納品」サイクルが「イテレーション」です。一般的に、1週間から4週間程度の日程で、開発を回していきます。
イテレーションを組んでクライアントの要求に素早く対応し、機能の開発や要件の見直しなどの仕様変更に対応します。
メリット
前述の「アジャイル開発の歴史・概要」の章で紹介した宣言に照らし合わせて、メリットを紹介しましょう。メリットを理解することで、アジャイル開発の取組みの品質をより向上させる事ができます。ここでは、代表的なメリットを4つ紹介します。
個人と対話を重視するので強いチームを形成できる
アジャイル開発の代表的な手法であるスクラムでは、最適なチームの人数は3~10人と言われています。
イテレーション単位で3~10人の小規模なチームで臨むので、当事者意識が生まれモチベーションがUPし、コミュニケーションが活発化します。また、メンバーが多様な作業を何度も経験できるため、開発者の成長を大きく促す事につながります。
動くソフトウェアを優先する
アジャイル開発では動くソフトウェアを優先するため、成果物としての納品を求められるような綺麗にまとまったドキュメントを作成しません。
そのため、GitHubのIssue機能やBacklogなどプロジェクト管理ツールなど活用できるため、ドキュメント作成の手間が大幅に省けます。
仕様書などは作成しますが、工程ごとの引き継ぎ書などは不要になるので、全体の作業量は減少します。
顧客との協調を重視するので満足度の高い製品を提供できる
アジャイル開発では、機能を１つずつ順に利用可能な状態にまで完成させるので、要望の誤解の確認や品質の検証が早期に実施されます。つまり、結果的に顧客の想像通りの満足度の高いソフトウェアを提供出来るのです。
変化への対応を重視するので製品の競争力が向上する
アジャイル開発では、ユーザーの要求の変化に合わせて迅速に機能を追加・変更できるため、ユーザーのニーズに合った競争力の高い製品を提供することができます。
デメリット
アジャイル開発にはデメリットも存在します。デメリットを理解することで、よりプロジェクトの成功の確率を高めることができます。ここでは、3つのデメリットを紹介します。
開発期間をコントロールし辛い
アジャイル開発では、チーム単位で「計画→設計→開発→テスト→納品」という開発工程を継続して、繰り返すケースがほとんどです。各チームで作業を進めていくため、全体のスケジュール管理が困難になるケースがあります。その結果、開発期間のコントロールがし辛くなり、最悪の場合納期に間に合わないことも考えられます。
方向性がブレやすい
開発をスタートする段階で詳細な仕様などは決めずに、大まかな状態で開発をスタートするケースが一般的です。作業を進めながら、機能単位で「計画→設計→開発→テスト→納品」という開発工程を反復して、クライアントの要望を取り入れ、仕様の変更を行っていきます。
この時、正しい要求が導き出せなかったり、その場しのぎの対応をしてしまうと、方向性がブレてしまう可能性があります。
開発は何らかのニーズによってスタートしますが、方向性がブレるとクライアントからの改善要求が継続し、反復増加型プロセスが長期間に渡って繰り返される事になりかねません。こうなると、スピーディに開発をすすめることができるアジャイルのメリットを損ない、費用も増加することになります。
人員の入れ替え・追加が難しくなる場合も
アジャイル開発では動くソフトウェアを優先しますが、ドキュメント作成を疎かにしていると属人化しやすい傾向があります。そのような状態になってしまうと、人員の入れ替えや追加が難しくなります。
アジャイル開発であっても、必要な情報はドキュメントとして残しておくことが重要です。
向いているプロジェクト
アジャイル開発は、特に以下のようなプロジェクトに最適の手法と言えるでしょう。
開発途中で変更や新機能の追加が必要になるプロジェクト
IT分野のサービスでは、新機能の登場が数多く起こります。開発途中のプロジェクトも、同様に変化に合わせた対応ができる手法が望ましくなります。その点で、アジャイル開発は向いています。
また、アジャイル開発では、開発を始める際に、仕様イメージや、開発の対象などを計画し、反復増加型プロセスにおいてどの機能から開発工程に載せるのか、といった順位づけをおこないます。
しかし、クライアントを取り巻く社会環境は常に変化しており、クライアントは、当初の計画や、機能の優先順位を変更するケースも出てきます。こうした、社会環境の変化に応じた変更についても対応可能です。
完成時の全体像が出来上がっていないプロジェクト
近年のビジネスでは、スピード感が成功のための最も重要なポイントになっています。そのため、クライアントからの依頼の中には、完成時の全体像が出来上がっていないプロジェクトも多く存在します。
そのため、要件が満たされていない状態から開発をスタートして、機能単位で「計画→設計→開発→テスト→納品」という工程を繰り返し、クライアントの要望を取り入れながら、仕様の変更を行っていくアジャイル開発が最適な手段となります。
クライアント側の立場で見ても、機能単位で、納品された内容を確認しながら、完成時の全体像を確立できます。
向かないプロジェクト
アジャイルは、どちらかというと一般的には以下のようなプロジェクトには不向きと言われています。
完成度や納期が重視され綿密な計画を立てる必要のあるもの
アジャイル開発は、開発を始める際に、大まかな仕様や開発対象などを計画するだけで、詳細な計画をたてることはありません。したがって、綿密な計画を立てる必要があるプロジェクトには不向きと言われています。
クライアントの要求が、開発を開始する時点で明確に確定していて、その要求を実現するための仕様や、実現を阻む問題点や課題が明確で、完成したゴールが明らかになっている場合は、ウォーターフォール開発が向いています。
段階的な機能追加が必要とされないもの
プロジェクトを計画してから完成まで、要求の変更や機能を追加・変更が発生する可能性がない場合は、アジャイル開発を採用するメリットが少ないでしょう。開発をスタートする前に、対象範囲などを決め、綿密に計画を立てて進めていくべきでしょう。
また、初期リリースまでのMVP開発はアジャイル開発ではなくウォーターフォール開発が向いています。製品としてユーザーが価値を感じる最低限の機能を持った状態までは、機能ごとに分割して開発するよりも、リリースまでに必要な機能をまとめて開発した方が効率が良いです。
MVP開発については以下の記事で詳しく解説しています。
アジャイル開発の手法
アジャイル開発手法に共通するプロセスは、機能単位で「計画→設計→開発→テスト→納品」という開発工程を反復して、反復ごとに機能を増加させていく「反復増加型開発」で、複数の手法が考えられてきました。
アジャイル開発は、アジャイルな複数のソフトウェア開発手法の総称です。複数の手法が提唱されてきましたが、ここでは、代表的な手法を3つ紹介します。
スクラム
スクラムは、アジャイル開発で、反復増加型開発のプロセスを実行する開発チームが、効率的に作業を遂行するためのフレームワークです。
1993年、ジェフ・サザーランド氏らが、反復増加型開発を実行する過程で考えられたのが、プロジェクト管理フレームワーク「スクラム」です。スクラムのネーミングのルーツは、1986年、野中郁次郎氏と、竹内弘高氏によって発表された論文「The New New Product Development Game」であると言われています。論文の中には、日本の製造業の組織形態が、ラグビーのスクラムのようだと例えられていました。
スクラムでは、反復増加型開発期間はクライアントや営業部門などの干渉を全く受けない環境が確保され、プロジェクト管理の権限や開発手法などの決定は開発チームが行います。
開発チームは、干渉を受けず権限を持つことで、自律的にプロジェクト管理をしていくことになり、チーム内で急速に自己組織化がすすみ、イノベーションを生み出す環境も創造していきます。
スクラムではイテレーションのことをスプリントと呼びます。
エクストリームプログラミング(XP)
開発に必要なプラクティスをまとめたものです。プラクティスを活用することで、アジャイル開発を継続的に実行していくポイントを認識することができます。
ケント・ベック氏と、ウォード・カニンガム氏が、ソフトウェア開発のべストプラクティスをパターンとして集め始めたことがルーツと言われています。1999年にケント・ベック氏は、集めてきたパターンをまとめ提唱しました。
XPでは、アジャイル開発を実践するうえで重要なポイントとして下記の5つを上げています。
- コミュニケーション
- シンプル
- フィードバック
- 勇気
- 尊重
ベストプラクティスは、プロジェクトに関わるメンバー全員に関連する「共同プラクティス」、開発チームを対象とした「開発プラクティス」、管理者を対象とした「管理者プラクティス」、クライアントを対象とした「顧客プラクティス」で構成されています。
ユーザー機能駆動開発(FDD)
業界のプラクティスをまとめたものです。1997年ジェフ デ・ルーカ氏が、銀行における開発プロジェクトを実施したときに作成したものです。ユーザー機能駆動開発(FDD)の特徴は、ユーザー（顧客）にとっての機能価値の観点で、開発を進めていく点です。
開発以外にも活かせるアジャイル思考
アジャイル開発という言葉は、かつては主にIT業界で開発手法のひとつとして使われていた言葉でしたが、最近では企業がビジネスをすすめていく時の考え方として、様々な場面で活用が進んでいます。アジャイルという言葉も、ビジネスの場面でよく目にするようになってきました。アジャイルの考え方に基づいた思考を「アジャイル思考」と言います。
アジャイル思考が、近年注目されている背景には、社会環境があります。現代は、変化のスピードが早いのが特徴です。ビジネスでも、スピードが求められます。スピード感を加速するアジャイルの考え方は、今の時代に求められています。
また、現代は、何が起こるのか分からない時代です。近年は、デジタル化やグローバル化などによって、新しいビジネスが次々に登場して市場を拡大しています。さらに、異常気象やパンデミックなど、思いもよらないことが数多く発生しています。そんな社会環境の中で、変化に柔軟に対応する事ができるアジャイル思考が解決策として期待されているのです。
アジャイル思想を簡単に解説すると、大きく分けてアジャイル開発の本質を含んだ2つの特徴だと言えます。アジャイルは、反復増加型プロセスで、機能単位で「計画→設計→開発→テスト→納品」という開発工程を反復して、反復ごとに機能を増加させていきます。この基本的な仕組みは、アジャイルの本質を表しているともいえるでしょう。
アジャイル思想では、第1に素早くPDCAを回していくことが特徴としてあげられます。第2に、「作りながら考える」いわゆるトライ&エラーの実行が特徴になります。
アジャイル思考は、ビジネスをすすめていく時の考え方として、様々な場面で活用が進んでいます。
まとめ
アジャイル開発は、機能単位で「計画→設計→開発→テスト→納品」という開発工程を繰り返す「作りながら考える」開発手法です。従来の手法と比べ、スピーディーに作業をすすめることができます。また、クライアントの要求に素早く対応して、プロダクトの価値を最大限発揮させることができ、競争力が高い製品を開発できる点も魅力です。
アジャイル開発はメリットが多くあります。一方でデメリットもありますので、開発に応じて採用するかどうか考える必要があります。
アジャイルの考え方は、アジャイル思考と言われています。現代は、先が見えない時代です。また、時代の変化はスピード感を増しています。ビジネスには、変化に合わせて柔軟に対応できる経営が求められています。アジャイル思想は、予測ができない時代に対応していくための解決策として、開発以外でも求められるようになっています。開発だけでなく、これからのビジネス全般を考えていくうえで重要なポイントになるでしょう。
