アジャイル開発とは?概要から進め方、メリット・デメリット、開発手法について
目次[非表示]
- 1.アジャイル開発とは
- 1.1.アジャイルソフトウェア開発宣言
- 1.1.1.アジャイルソフトウェア開発宣言
- 1.1.2.アジャイル宣言の背後にある原則
- 1.2.「ウォーターフォール型」との違い
- 1.2.1.ウォーターフォール型の進め方
- 2.アジャイル開発の基本的な工程
- 3.アジャイル開発で使われる3つの手法
- 3.1.スクラム
- 3.2.エクストリームプログラミング(XP)
- 3.2.1.エクストリームプログラミングの5つの価値観
- 3.3.ユーザー機能駆動開発(FDD)
- 4.アジャイル開発の一般的な進め方
- 5.アジャイル開発のメリット
- 5.1.開発をスピーディーに行える
- 5.2.顧客のニーズに応じやすい
- 5.3.修正や追加がしやすい
- 5.4.開発チームが成長しやすい
- 6.アジャイル開発のデメリット
- 6.1.開発にブレが生じやすい
- 6.2.全体像が不明瞭で管理が難しい
- 7.アジャイル開発が失敗した事例と原因
- 7.1.アジャイル開発に対する知識不足
- 7.2.チームの役割を理解していない
- 7.3.発注者を開発に巻き込めていない
- 7.4.優先順位がつけられていない
- 7.5.コミュニケーションが不足している
- 8.アジャイル開発が向いているプロジェクト
- 9.アジャイル開発に最適な発注先をスムーズに見つける方法
- 10.まとめ
- 11.オフショア開発会社のリソースをうまく活用する
アジャイル開発とは
「Agile(素早い、機敏)」という意味の通り、アジャイル開発はシステムやソフトウェアを短期間で開発する手法です。
アジャイル開発の最大の特徴は、従来の方法に比べて柔軟に開発が行える点です。システム開発を小さな単位に分けて、実装とテストを繰り返しながらプロジェクトを進めていきます。
また、アジャイル開発では、発注側と開発側がチームを組むのも特徴と言えます。従来の手法では、発注側がタッチするのは要件定義まででした。それに対してアジャイル開発では、開発が終了するまで発注側と開発側が一丸となって開発を進めることになります。
アジャイルソフトウェア開発宣言
「アジャイルソフトウェア開発宣言」とは、ソフトウェア開発を行ううえでのマインドセットのことです。従来とは違う手法で開発していた17人の開発者が議論を行い、2001年に公開されました。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
同時に「アジャイルソフトウェア開発宣言」を実践するために、従うことが望ましいとされている「アジャイル宣言の背後にある原則」があります。
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」を念頭に置くことで、より良い成果を出すことにつながります。
「ウォーターフォール型」との違い
システム開発の一般的な手法に「ウォーターフォール型」があります。ウォーターフォール(滝)の名前の通り、上から下に落ちるように工程を分けて開発を進める手法です。
ウォーターフォール型の進め方
- 要件定義
- 基本設計
- 詳細設計
- 製造
- 単体テスト
- 結合テスト
- 総合テスト
- 運用テスト
- リリース
ウォーターフォール型は、要件定義どおりに上から下に流れるように開発を行います。予定通りに進めることが基本となるため、納品の期日やコスト、責任の所在が明確といったメリットがあります。一方、要件定義が漏れていた場合、途中で変更が難しく納期の遅れやコストオーバーを招く恐れがあります。
アジャイル開発の基本的な工程
アジャイル開発は、基本的に次の2つの工程に分かれています。
- リリース計画
- イテレーション
以下で詳しく解説します。
リリース計画
ソフトウェアの方向性を決める工程が「リリース計画」です。ウォーターフォール型の場合、要件定義でソフトウェアに実装する機能や性能をしっかりと決めてしまいます。一方アジャイル開発では、開発途中でも仕様の変更・追加を前提としているため、大まかな計画を決めるだけにします。
イテレーション
イテレーションには「反復」という意味があります。アジャイル開発では、「計画」→「設計」→「実装」→「テスト」→「リリース」を、イテレーションという小さな単位に分けて開発を行います。
1つのイテレーションが終了後、発注側の意見を参考に改善しながら次のイテレーションといった具合に、イテレーションを繰り返しながら開発を進めます。ひとつのイテレーションは2週間〜3か月ほどで完了を目指します。
アジャイル開発で使われる3つの手法
一口にアジャイル開発と言っても、次のようにいくつかの手法に分かれています。
- スクラム
- エクストリームプログラミング(XP)
- ユーザー機能駆動開発(FDD)
以下ではアジャイル開発で使われる3つの手法について解説します。
スクラム
チーム全員で役割を決めて開発を進める手法です。チームが一丸となって開発に取組む様が、ラグビーでスクラムを組むのに似ていることから名付けられました。
スクラムには「スクラムガイド」というものがあり、ガイドの定義に沿って開発が進められます。ですが、スクラムには明確に「こうするべき」という方法は記されておりません。
そのためスクラムは、チーム内で「必要なものは?」「期限はいつまで?」「誰が担当する?」など、タスクを分散させて開発を進めるのが基本となります。
メンバーが各々の役割をこなすことで、作業を効率的に行うことが可能です。 そのため、なによりもメンバー内でコミュニケーションをとることを求められます。
エクストリームプログラミング(XP)
エクストリームプログラミング(XP)は、他のアジャイル開発の手法と同様に、仕様の変更や追加を柔軟に行える手法です。エクストリームプログラミング(XP)は、5つの価値観、5つのルール、12のプラクティスで成り立っています。
エクストリームプログラミングの5つの価値観
-
コミュニケーション
XPもアジャイル開発の手法のひとつなので、コミュニケーションが重要です。チーム内で情報の共有を取ることが、開発の成功につながります。
-
シンプル
将来の事を考えて、様々な機能やシステムを実装しがちですが、結局必要ないというケースも少なくありません。そのようなことに貴重な時間や労力を使うのではなく、まずはシンプルな機能を実装して、必要になったら後で実装すれば良いという考えです。
-
フィードバック
クライアントやユーザーに、開発したシステムやソフトウェアのフィードバックをしてもらうことで、無駄を削ぎ落として本当に必要なものだけを実装できます。
-
勇気
しっかりと計画を立てて開発をするウォーターフォール型とは違い、アジャイル開発は仕様の追加や変更が起こる可能性が高い手法です。もしかしたら、当初の予定から大きく外れたものになるかもしれません。そのような時でも、勇気を持って作り直す必要があります。
-
尊重
コミュニケーションが特に重要となる開発手法だからこそ、開発者や発注者はお互いの意見を尊重する姿勢が必要です。相手のことを下に見るような態度をとると、コミュニケーションが取りづらくなります。その結果、開発は失敗に終わるでしょう。
ユーザー機能駆動開発(FDD)
ユーザー機能駆動開発(FDD)とは、ユーザーにとって価値のある機能(feature)を優先して開発を進める手法です。ユーザー機能駆動開発(FDD)は、「5つの基本活動」という工程と、「ベストプラクティス」で構成されているのが特徴です。
アジャイル開発の一般的な進め方
一口にアジャイル開発といっても、スクラムやエクストリーム・プログラミング(XP)、ユーザー機能駆動開発(FDD)といった手法があります。アジャイル開発では、これらの手法を使いながら、次のような進め方で開発を行います。
- プロジェクトマネージャーやエンジニアなどで、10名以下のチームを編成する
- 1〜4週間でイテレーションが完了する規模で機能や業務を分ける
- 開発する機能や業務に優先度をつけて、優先度の高い順に開発を進める
- 計画〜テストを経て、期間内で開発が終了した範囲でリリースする
- リリース後に発注側と開発側が協議・検討し、次の開発に進む
- 2〜5を1つのイテレーションとして繰り返しながらプロダクト完成を目指す
アジャイル開発のメリット
アジャイル開発には、次のような4つのメリットがあります。
- 開発をスピーディーに行える
- 顧客のニーズに応じやすい
- 修正や追加がしやすい
- 開発チームが成長しやすい
以下で詳しく解説します。
開発をスピーディーに行える
アジャイル開発では、優先度の高い機能からリリースするため、開発をスピーディーに行えます。
顧客のニーズに応じやすい
各イテレーションごとに発注側と要望のすり合わせが行われます。顧客のニーズに応じて、修正や改善を行える点がメリットです。
修正や追加がしやすい
ウォーターフォール型と違い、要件定義をしっかりと決めずに開発を進めます。そのため、発注側の要望に合わせて修正や追加がしやすいといった特徴があります。
開発チームが成長しやすい
短い周期で一連の開発工程を繰り返すことから、開発チームやプロセス自体の課題の発見・解決機会が多く提供されます。結果、チームやプロセスの改善、成長を促進しやすい点がメリットと言えます。
アジャイル開発のデメリット
アジャイル開発は柔軟に開発を行えるのがメリットですが、次のようなデメリットがあることも理解しておきましょう。
開発にブレが生じやすい
開発前に仕様や要件を明確に決めないため、追加や修正がしやすい反面、開発にブレが生じやすいデメリットがあります。修正や追加を重ねた結果、当初の予定と違ったものになる恐れがあります。
全体像が不明瞭で管理が難しい
アジャイル開発はチームごとに開発を進めるため、ウォーターフォール型に比べると全体像が不明瞭になりやすく、管理が難しいといったデメリットがあります。
アジャイル開発が失敗した事例と原因
アジャイル開発が失敗する原因として、次のようなものが挙げられます。
- アジャイル開発に対する知識不足
- チームの役割を理解していない
- 発注者を開発に巻き込めていない
- 優先順位がつけられていない
- コミュニケーションが不足している
以下では、アジャイル開発で失敗する原因と理由について解説します。
アジャイル開発に対する知識不足
国内ではウォーターフォール型が主流であり、アジャイル開発はまだまだ浸透しているとは言えません。そのため、知識不足な状態でアジャイル開発を導入しがちです。その結果、成果を出せずに失敗するケースは少なくありません。
チームの役割を理解していない
ウォーターフォール型とは違い、スクラムには「プロダクトオーナー」や「スクラムマスター」といった役割があります。しかし、これらは開発の方向性を決めたりチームをサポートするのが役割です。
ところが、役割を理解せずにプロダクトオーナーとスクラムマスターがそれぞれ指示を出してしまうと、アジャイル開発の強みである「チームの自己組織化」が機能しないばかりか、現場が混乱するといった事態を招いてしまいます。
発注者を開発に巻き込めていない
従来の開発手法の場合、発注側は要件定義で関わる程度でした。しかし、アジャイル開発では、発注側もチームの一員となって開発に参加しなければ機能しません。イテレーションごとに発注側の意見が反映されなければ、アジャイル開発の意味がなくなってしまいます。
優先順位がつけられていない
アジャイル開発では、無駄なものを作らずに重要なものから開発するのが基本です。そのためには、開発すべき優先順位を付ける必要があります。どれが重要なのか、優先度が高いのかを判断できず、無駄なものから開発した結果、失敗するケースも見られます。
コミュニケーションが不足している
アジャイル開発では、コミュニケーションを取りながら開発することを重視しています。例えば急な仕様の変更があった際、情報が共有されなければ無駄な機能を追加する恐れがあります。
チーム内でコミュニケーションが不足することで、アジャイル開発の強みが損なわれてしまうのです。
アジャイル開発が向いているプロジェクト
アジャイル開発を導入する際は、向き不向きがあることを理解する必要があります。アジャイル開発に向いているケースには、主に次のようなものがあります。
- 後々に仕様変更の可能性がある場合
- 要件定義の全体像が明確ではない場合
- 発注者自身も開発に参画する場合
- テスト用の試作を重ね、ニーズを反映したプロダクトを作りたい場合
以下で詳しく解説します。
後々に仕様変更の可能性がある場合
ビジネスを取り巻く状況は刻一刻と変化します。その流れを正確に予測することは困難と言えるでしょう。当初の予定では状況に合わせて必要と思えたシステムも、後々になって追加や変更が必要になることは珍しいことではありません。
このように、状況の変化で仕様変更の可能性がある場合、とりあえず開発を進めていき、後で追加や変更のできるアジャイル開発は適切な手法と言えます。
要件定義の全体像が明確ではない場合
要件定義がしっかり固まった状態で開発が進められるのが理想です。しかし、中にはイメージはできているけど要件が明確でないケースも少なくありません。
ウォーターフォール型の場合、要件定義が決まっていない状態で開発を進めると失敗する可能性が高くなります。しかし、アジャイル開発であれば、要件の全体像が明確でなくても機能の改善や追加が柔軟に行なえます。
発注者自身も開発に参画する場合
ウォーターフォール型の場合、発注側は要件定義と最終チェックにだけ参加するというのが大半でした。しかし、アジャイル開発は開発側と発注側がチームとなって開発を進めることになります。クライアントも積極的に開発に参画することで、要件を素早く伝えることができるため開発がスムーズに進みます。
テスト用の試作を重ね、ニーズを反映したプロダクトを作りたい場合
アジャイル開発では、大まかな要件を決めてからとりあえず開発を進めて、必要になったら修正・追加が行なえます。そのため、まずはテスト用のサンプルを作ってから、顧客のニーズを反映したプロダクトを作りたいといった場合にも適しています。
アジャイル開発に最適な発注先をスムーズに見つける方法
アジャイル開発の発注先を見つけるために、「ビジネスマッチングサイト」を活用している人も多いのではないでしょうか。その際、必ず発注先の実績を確認するようにしましょう。国内でもアジャイル開発が浸透してきているとはいえ、まだまだ理解が浅い開発会社も少なくありません。
そこで、開発会社の実績をチェックすることで、理解度やノウハウがあるかを把握することが可能です。
▼システム開発のアウトソースは、こちらを参考にしてみてください。
→システム開発は外注か内製か?外注する前に覚えておきたいメリット・デメリット
まとめ
当記事では今回、アジャイル開発について解説しました。
アジャイル開発は「状況の変化で仕様変更の可能性がある場合」「要件の全体像が明確ではない場合」といったプロジェクトケースに最適です。
そんなアジャイル開発には、「開発をスピーディーに行える」「顧客のニーズに応じやすい」「修正や追加がしやすい」といったメリットがあります。
その反面「開発にブレが生じやすい」「全体像が不明瞭で管理が難しい」などのデメリットもあることを理解しておきましょう。
「アジャイルソフトウェア開発宣言」の中で、「包括的なドキュメントよりも動くソフトウェアを」という文言があるため、要件定義書などドキュメントは必要ないと考える人も少なくありません。
しかし「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」ともあります。つまり、ドキュメントは必要ないという意味ではないのです。
オフショア開発会社のリソースをうまく活用する
日本国内で優秀なエンジニアを確保するのは時間や投資コストの面などでハードルが高いのも事実であり、システム開発、さらにはその先のDXで課題を抱えている企業のすべてに適用できるアプローチではありません。
このため、弊社コウェルをはじめ、ベトナムで多数エンジニアを抱えるオフショア開発会社をうまく使い分けながら、テストや開発を進めていく方法も有効な選択肢のひとつです。
実際にどのように開発を進めていくのかについては大きく分けて2パターンが存在します。ひとつは、仕様書をもとにオフショア開発会社が決められた期間までに所定の成果物を完成させる「受託開発型」、もう一つはオフショア開発会社に在籍するエンジニアの中から、指定のメンバーを「専属チーム」として組成し、各メンバーのスキルや経験に応じて決められた人月単価(月額料金)が発生する「ラボ型」です。
オフショア開発会社と組んで海外で開発を進める場合、仕様書などの要件定義はもちろんこと、異なる言語や文化に起因するコミュニケーションギャップが生じるのは避けて通れない課題と言えます。このため、自社のパートナーとして適切な開発会社を選定する上では、それらのコミュニケーションギャップをいかに埋めながら、プロジェクトを推進していくことができるかどうかを見極める視点が欠かせません。
コウェルでは日本語能力の高いベトナム人エンジニアがテストや開発に従事する体制を基本としています。加えて、日本のお客様とテスト・開発の現場をつなぐ役目を果たす日本人ブリッジSEも多数在籍しており、日本人とベトナム人のエンジニアが協力しながらプロジェクトを管理、運営することでコミュニケーションを円滑にし、高い品質を実現できる体制を構築しています。
なお、コウェルに関する詳細資料は以下でダウンロードすることが可能です。また、具体的なご相談がございましたら、以下のお問い合わせからもお気軽にご連絡ください。
コウェルのサービスメニュー>>>
コウェルは、日本とベトナムから世界中のお客さまへ高品質なソフトウェアテスト・品質保証・オフショア開発サービスを提供しています。
コウェルの開発導入事例>>>
コウェルは情報通信、金融、流通・小売サービス、医療・ヘルスケアなど、さまざまな業界のお客様の導入を支援しています。