アジャイル開発とは?メリットとデメリットなどアジャイルをわかりやすく解説
ウォーターフォール開発モデルの欠点に対する解決策として、アジャイル開発モデルは2001年に生まれました。アジャイル開発モデルは、順次設計プロセスではなく、段階的なアプローチによってプロダクトを完成させることにより、ビジネスの変化に柔軟に対応します。
アジャイル開発の向き不向きというように言われることがありますが、時代背景の変化に伴って開発手法も変わってきたということだけなのです。
現在は、VUCA時代(不安定で、不確実で、複雑で、あいまい)ともいわれ、予測不可能なビジネス環境と不確実性が拡大しています。そのためアジャイルアプローチにより、ビジネスの変化に柔軟に対応していく必要があります。
それでもアジャイル開発で失敗したという経験がある方もいるかもしれません。
一般的に言われているアジャイル開発のメリットやデメリット以外に、認定スクラムマスター受講者、プロダクトオーナー受講者を対象にディスカッションした、実際の現場で感じたリアルな声もまとめています。
アジャイル開発を導入するにあたって、ウォーターフォールと比較して、アジャイル開発のメリットやデメリット、向き・不向きについて、一番よく聞かれる質問です。
そんなリアルな現場の声を聞きながら、アドバイスもまとめていますので参考にしてください。
アジャイル開発のデメリットと言われるものの中には、実は克服可能なものも多く、アジャイル開発の現場で多くの実績と経験を持つ、ジョー・ジャスティスのアドバイスも是非参考にしてください。
この記事でわかること
アジャイル開発とは?アジャイルをわかりやすく解説
アジャイルとは
アジャイルとは、直訳すると「素早い」「機敏な」という意味です。機能やサービスなどプロジェクトを迅速に提供し、柔軟な対応を実現するための考え方です。
アジャイルそのものには、定められたプロセスやツールはありません。
つまり、アジャイルは技術的な方法論ではなく、俊敏性を実現させるための概念のようなものです。
ウォーターフォール開発モデルの欠点に対する解決策として、アジャイル開発モデルは2001年に生まれました。アジャイル開発モデルは、順次設計プロセスではなく、段階的なアプローチによってプロダクトを完成させることにより、ビジネスの変化に柔軟に対応します。
アジャイル開発の向き不向きというように言われることがありますが、時代背景の変化に伴って開発手法も変わってきたということだけなのです。
現在は、VUCA時代ともいわれ、予測不可能なビジネス環境と不確実性は拡大しています。
そのためアジャイルアプローチにより、ビジネスの変化に柔軟に対応していく必要があります。
アジャイルとウォーターフォールの違いとは
ウォーターフォールは、将来を予測し、綿密な計画をたて、必要性が高いと考えられるニーズに基づき進めます。つまり、大きなサイクルで大きなプロダクトを完成させる手法です。
一方アジャイルの考え方では、リアルタイムなニーズやフィードバックを受けて、小さな単位で改善を繰り返し、ビジネスの変化に柔軟に対応していきます。つまり、小さなサイクルで小さなプロダクトを俊敏に完成させていきます。
ウォーターフォールからアジャイルが主流へ
・ステップが完了すると、前の段階に戻って変更を加えることができない
・ウォーターフォール手法は、初期要件に大きく依存する
・プロダクト全体は最後にのみテストされる
・計画では、クライアントの進化するニーズは考慮されない。プロジェクトの過程で生まれた新たな変更を加えたい場合は、プロジェクトは遅れ予算に影響を与える
アジャイルのメリット
現場で感じたアジャイル開発のメリットとは?
一般的に言われているアジャイル開発のメリットだけでなく、現場で実際にアジャイルを導入した経験者が感じた現場レベルでのアジャイルのメリットをまとめてみました。
メリット①開発スピードが早い
各チームが自律的に動き、他のチームを待ったり、余計なコミュニケーションによる非効率を解消できる。また優先度の高い必要な機能から順にリリースしていくことで、サービスインまでの期間を短縮することができ、迅速なスタートを切ることができる。
メリット②大きな手戻りのリスクを軽減できる
ウォーターフォール開発のような開発の最後にテストしリリースするということはなく、細かくテストし、リリースを繰り返すので手戻りのリスクを軽減できる。
メリット③プロジェクトの軌道修正が柔軟にできる
アジャイル開発では、状況の変化があったとしても柔軟に対応できる。そのため、不確実性の高いビジネス状況であっても、無駄を少なく開発することが可能。また投資の撤退となった場合でも最小限で判断できる。
メリット④顧客満足度の向上
顧客・クライアントのフィードバックを受けながら開発をしていくので、ニーズのズレが少なくなる。また、リリースとフィードバックを繰り返すことで、新たなアイディアも生まれ、最終的に価値の高いプロダクトに繋がる。
メリット⑤イノベーションの実現
迅速な意思決定と変化への対応ができることで、業務の効率化やスピーディーなイノベーションを生み出すことを可能とし、企業の価値向上に貢献する。
メリット⑥メンバーのモチベーション向上
小さなリリースをしていくことで成功体験が得られやすく、メンバーの士気向上に繋がる。また振り返りによる改善の機会が多く、生産性をあげることができる。
メリット⑦離職率の低下
自律的なメンバーで組成されているアジャイルチームは、各メンバーに権限が分散されており、やりがいを感じることができる。また心理的安全性が保たれており、離職原因の改善に役立つ。
認定スクラムマスター受講者、プロダクトオーナー受講者を対象にアジャイル開発を現場に導入した際に感じたアジャイル開発のメリットについてディスカッションした際の記録です。
アジャイルのデメリットと対策
日本の企業におけるアジャイル開発導入の障壁についても考えてみましょう。
認定スクラムマスター受講者、プロダクトオーナー受講者を対象にアジャイル開発を現場に導入した際に感じたアジャイル開発のデメリットや課題についてディスカッションしました。
それに対するジョージャスティスからのアドバイスも是非参考にしてください。
デメリット①全体のスケジュール感の管理が難しい場合がある
弊社のクラスを受講頂く方から、現場のリアルな声としてご相談を受けます。全体スケジュール感がわかりずらく、顧客の「アジャイルなら途中でなんでも追加できる」という誤った解釈から、どんどん追加作業が増え、結果的にウォーターフォール開発のように最終的に作業を詰め込み、残業せざるを得ないというケースが発生します。
これは導入の初期段階で、よくある問題かもしれません。Joeのアドバイスも是非参考にしてください。
スプリントバーンダウンチャートや、リリースバーンダウンチャートを使用して、作業トレンドを可視化させてください。
スプリントバーンダウンチャートや、リリースバーンダウンチャートを使用して、作業トレンドを可視化させてください。作業ペースは、スキルの向上や自動化の導入がなければ、大きくは変わりません。つまり、追加作業があれば、その分時間は掛かりますし、何を優先すべきか考える必要があります。そして顧客に正しくアジャイルを理解してもらえるよう、スクラムマスターは働きかけてください。
デメリット②チームメンバーのスキルのバラツキが開発の遅れに繋がりやすい
弊社のクラスを受講頂く方から、現場のリアルな声としてご相談を受けます。知識と経験値に差があり、若手メンバーの育成や、そもそも経験の低いメンバーをアジャイルチームに入れるべきではないのかという悩みがある。
現場で起こりうるこの悩みに対するJoeのアドバイスも是非参考にしてください。
チームでモブをしてみてください。
モブ(Mob)とは、チーム全員が同じことを同時に、同じスペースで、同じコンピューターで作業する方法です。(ペアから進化したのがモブです)
チームで知識を共有しクロスファンクショナルなチームの育成に役立ちます。シニアメンバーは、技術力を持ち、ジュニアメンバーは創造性を持っているかもしれません。ジュニアメンバーにはぜひ成功体験をしてもらってください。小さくても構いません。これは自信へと繋がり、より自律的なチームの一員になることを助けます。
デメリット③開発チームメンバーが固定されず、アジャイル開発のスキルがなかなか上がらない
弊社のクラスを受講頂くエンジニアの方から、現場のリアルな声としてご相談を受けるのが、開発メンバーが固定されない件です。
日本の企業では、1つのプロジェクトが終了する度に都度解散し、また新しいメンバーで次のプロジェクトがスタートするケースが多いようです。
せっかくアジャイル開発に慣れて来て、チーム全体がスキルアップしたタイミングでプロジェクトが解散されてしまい、別のメンバーで次のプロジェクトがスタートする為、またゼロからのスタートとなってしまい、チームが育ちにくいと言ったご相談をよく受けます。
日本のエンジニアの現場で起こりうるこの問題に対するJoeのアドバイスも是非参考にしてください。
チームメンバーは一定期間同じであることが望ましいです
しかしアジャイル開発へ移行段階にある場合は、プロジェクトを掛け持つこともしばしばあるかもしれません。その場合でも、チームで一緒に働く時間を作ることをおすすめしています。例えば月曜日はAチーム、火曜日はBチームなど。もしくは、午前中はAチーム、午後はBチームなど。そしてモブで働ければ、チームメンバーはより早くお互いを理解し、チームのスキルの向上も早いでしょう。チームで働く時間を増やせるといいですね。
デメリット④大規模開発で上手くいくイメージがもてない
弊社のクラスを受講頂くエンジニアの方から、現場のリアルな声としてご相談を受けるのが、大規模開発についてです。以前の大規模開発プロジェクトでアジャイル手法で行いましたが、上手くいかなかった経験があります。そのため大規模開発はウォーターフォール開発がいいのではないかと感じています。大規模開発でもアジャイル手法は有効なのでしょうか?
これは失敗したケースで、よくある問題かもしれません。Joeのアドバイスも是非参考にしてください。
大規模開発でもアジャイル手法は有効です。
大規模開発に向けて、アジャイルのスケールの手法は多く存在しています。失敗は色々なケースが考えられますが、よくあるのは、モジュールの分割が上手くいっていないこと。そしてインターフェースがきちんと定義されていないことが挙げられます。30日以内に設計、分析、構築、テスト、デプロイが完了できるように、並列実行可能なモジュールに分割できるよう再検討してみてください。
アジャイルのメリット・デメリットまとめ
- 開発スピードが早い
- 大きな手戻りのリスクを軽減できる
- プロジェクトの軌道修正が柔軟にできる
- 顧客満足度の向上
- イノベーションの実現
- メンバーのモチベーション向上
- 離職率の低下
- 全体のスケジュール感の管理が難しい場合がある
- チームメンバーのスキルのバラツキが開発の遅れに繋がりやすい
- 開発チームメンバーが固定されず、アジャイル開発のスキルがなかなか上がらない
- 大規模開発で上手くいくイメージがもてない
アジャイル開発の流れ
①開発するプロダクトのビジョンを定める
ビジョンは、プロダクトの展開によって、達成されるであろう望ましい状態の簡単な説明です。チームが効果的に作業を進めるためには、プロダクトのビジョンをチーム全員が理解している必要があります。
②プロダクトバックログの作成
プロダクトバックログには、プロダクト開発に関連するすべてのアイデアが含まれています。バックログの最初はブレインストーミングした大まかなアイデアの集まりとして始まりますが、プロジェクトが進むにつれて各バックログアイテムは徐々に明確化されていきます。
バックログアイテムは次のとおりです。
- 開発すべきものが ユーザーにどのようなメリットがあるかなど定義されている
- 開発範囲と、その作業サイズが明確になっている
- 何から開発をすべきなのか、優先順位付が付けられている
③イテレーション(反復)で開発を繰り返す
アジャイル開発では、一度に全ての機能をリリースするのではなく、段階的にリリースを繰り返していきます。たとえば、新しいアプリケーションや、既存のアプリケーションの機能強化をリリースするために、2週間や1週間などの短い一定のサイクルでリリースを行います。
アジャイルの手法
アジャイルは、顧客(ステークホルダー) とチーム間のコラボレーションと、短いサイクルでリリースを繰り返すことで、プロダクトの改善を継続的に行います。顧客(ステークホルダー)からのフィードバックを得て改善を繰り返し、品質を高めていくことが可能です。アジャイルは、開発途中に仕様や設計の変更があることを前提としており、この点が従来の開発プロセスとは大きく異なります。
アジャイルは、単一のフレームワークではなく、さまざまなフレームワークを包括する概念的な用語です。アジャイルには、スクラム、エクストリーム・プログラミング (XP)、ユーザー機能駆動開発(FDD) などのフレームワークや手法などがあります。
スクラム
スクラムは、チームのコラボレーションと、プロジェクト管理のフレームワークです。
スクラムのメリットは、チームの役割とプロセスを明確にすることで、チームが自己管理し、経験から学び、変化に適応することを可能にします
スクラム(Scrum)を簡単にわかる解説記事も参考にしてください。
エクストリーム・プログラミング(XP)
エクストリーム・プログラミングも、アジャイル開発の手法の1つです。スクラムと XP はどちらも、短い期間で反復的に開発するという共通の概念があります。
XPは、ソフトウェア プログラミング(技術面)に重点を置いています。テスト主導型の開発、ペアプログラミング、リファクタリング、集団的な所有権、継続的インテグレーション、YAGNI(必要なソースコードのみを記述する)など、いくつかのプラクティスが定義されています。
ユーザー機能駆動開発(FDD)
ユーザー機能駆動開発もアジャイル開発の手法の一つです。その名の通り、機能に焦点を当てた方法です。機能は FDD の基本要素で、スクラムのユーザー ストーリーと同じようなものです。5つのステップで、小さな機能単位で開発を進めます。
全体モデルの開発→機能リストを作成→機能別計画→機能別設計→機能別構築
アジャイルの向き不向き
アジャイルに向いているケースとそうでないケースを確認していきましょう。
アジャイルが向いているケース
- 要件の全体像が不明確
- フィードバックにより顧客ニーズを取り入れながらプロダクト開発をするケース
- 開発チームと顧客がワンチームで開発したいケース
要件の全体像が不明確
プロジェクトの初期段階では通常、不確実な要素があり、あいまいです。つまりプロジェクト開始直後に、詳細な作業範囲と仕様を策定するのは非常に難しいことです。これらは継続的に変化し、プロジェクトが進むにつれて明確になっていきます。アジャイルであれば、不確実性や変化への対応を随時行うことができます。
フィードバックにより顧客ニーズを取り入れながらプロダクト開発をするケース
プロジェクトの初期段階では、不確実な要素があるため顧客自身も、何が重要で何が必要なのか明確になっていないことがあります。アジャイルであれば、漠然とした顧客の要求からプロトタイプを作り、そこから顧客ニーズを汲み取って改良していくことも可能です。要件定義を細かく行うよりもニーズに沿った製品ができ、開発期間も短く済むケースがあります。
開発チームと顧客がワンチームで開発したいケース
アジャイルは、コラボレーションとフィードバックを重視するため、クライアントの関与が高いプロジェクトに最適です。従来の開発手法では通常、全ての機能が完成した段階で、最後に一度確認するだけでした。しかしアジャイルでは、細かい単位でリリースとフィードバックを繰り替えし、クライアントも含めたワンチームとして、より良いプロダクトを作ることに全員が協力します。
アジャイルが向いていないケース
アジャイルは、どんな開発であっても対応できますが、以下はアジャイルの効果を最大化することが難しいケースです。
- プロジェクトの不確実性は一切なく、計画通りの進行が可能
- チームメンバーは自律的な行動に興味が無く、上司からの指示を待っている
- 顧客は従来の開発手法を使用することを望んでおり、アジャイルについて知りたくない
- 組織や上司は、従来の開発手法を好み、チームへ協力的ではない
アジャイルよりウォーターフォールが向いているケース
一般的に以下のような場合、ウォーターフォールが向いているケースと言われます。
あらかじめ要件が確定しており、変更や修正が発生しない開発に向いていると言えます。つまりウォーターフォールは、手戻りをしないことが前提になるため、仕様変更がない開発に向いています。ウォーターフォールでは、仕様変更をせずに済むように入念な要件定義をしなければなりません。
アジャイルとスクラムの違い
アジャイルは、俊敏な開発やプロジェクト管理の概念です。スクラムはこれを実現するための手法の一つになります。
例えるなら、アジャイルはヤシの木で、スクラムはココナッツの実として存在するというイメージです。
なぜ今アジャイルが重要なのか?
現在は、VUCA時代とも言われます。開発中の発見や、進化する顧客のニーズ、変化するテクノロジー、競合他社のイノベーションによって引き起こされる継続的な変化に対応する必要があります。
アジャイルは、プロジェクトのタイムライン全体に影響を与えることなく、迅速かつ簡単に変更を加えることが可能です。つまり、アジャイルは、予定どおりに予算内でプロジェクトを完了するのに役立つため重要です。また、アジャイルは、複雑なプロジェクトに関連するリスクを軽減することにも役立ちます。
ウォーターフォールからアジャイルへ切り替える企業が増えて来ている
企業を取り巻く状況もどんどん変化が速くなり、予測できないことが増えています。スピードが必要な事業や、トライ&エラーを繰り返しながら新しいイノベーションを起こす領域では、従来型の開発手法ウォーターフォールでは対応しきれなくなってきました。
多くの組織は、ウォーターフォールからアジャイルへの移行に取り組み始めています。市場投入までの時間を短縮し、高品質な機能やサービスを提供するために、従来型のウォーターフォール プロセスをアジャイルに置き換えようと試みています。
アジャイルマニフェストと主要原則
アジャイルマニフェストは、ソフトウェア開発のプロセス改善を定義するという目的で2001年に作られました。これは、スクラムやエクストリームプログラミングなどのバックグラウンドを持つ 17 人がユタ州に集まり決定されました。
つまりこれ以前に、アジャイルを実現させるさまざまな手法はすでに存在していましたが、断片的であった考え方が、アジャイルマニフェストによって正式に定められました。
アジャイルマニフェストには、 12 の原則(アジャイル宣言の背後にある原則)のうち、4 つが中心です。
《アジャイルソフトウェア開発宣言》
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
(引用元:アジャイルソフトウェア開発宣言)
アジャイル開発関連用語|アジャイルでビジネス成功の鍵
プロダクトバックログ
プロダクトバックログは、開発対象の機能やサービスのリストです。これは、詳細なタスクリストでは無く、大きなアイテムのリストです。またこれらには開発すべき順に優先順位が付けられています。
ユーザーストーリー
アジャイルで使われる「ユーザーストーリー」は、各ペルソナの視点から書かれた開発対象の機能やサービスの説明です。
ユーザーストーリーの目的は、開発する機能やサービスが各ペルソナに、どのように価値を提供するかを明確にすることです。
ペルソナ
アジャイル開発において、ペルソナの設定は非常に重要です。
機能やサービスを開発する前に、誰のために、そしてなぜこれらを開発しているのかをチームで理解することが重要です。
この「誰のために」「なぜこれらを開発するのか」の対象として設定するのがペルソナです。
アジャイルでは、ユーザーのニーズに併せて柔軟に軌道修正が出来るのもメリットの1つです。ペルソナを設定する事で、顧客のニーズをチーム内で共通理解として意識する事ができます。
また、プロダクトが、大きなビジネス価値を持ち成長するために重要なのは、ユーザーだけではありません。
アジャイル開発のプロダクトに関わる「購入者」「ユーザー」「インフルエンサー」「ステークホルダー」「メンテナンス」「監査人」「アジャイルチーム」などについてもペルソナとして検討します。
バーンダウンチャート
アジャイルにおけるバーンダウン チャートは、時間の経過に伴うプロジェクトの進行状況を視覚的に測定します (縦軸は完了した作業量で、横軸は時間を表します)。
チャートは、作業スピードを可視化するため、プロジェクトの完了とプロジェクトの作業規模の現実的な時間枠を予測するのに役立ちます。
インクリメンタル(漸進)開発
アジャイルにおけるインクリメンタル開発とは、開発する機能やサービスを小さな単位に分割し、機能やサービスを段階的に完成させながら、連続して開発する方法。またこれらの分割した小さな機能やサービスは使用可能であること。
イテレーション(反復)開発
アジャイル開発の中で使われるイテレーション開発もインクリメンタル開発と同様に、開発する機能やサービスを小さな単位に分割し開発する方法です。
これは、開発プロセス全体を表し、計画、設計、開発、およびテストのステップが含まれます。
ウォーターフォール とは異なり、イテレーション開発では機能が 1 つずつリリースされます。
アプリ開発におけるアジャイル開発のメリット
アプリ開発において、アジャイルの効果はよく知られており、世界中で多くの企業がアジャイルを採用しています。
アジャイルの方法論には、プログラミング、開発プロセス、自動化、およびプロジェクト管理が含まれ、ソフトウェア開発を、より小さなモジュールに分割し小さな単位でリリースを繰り返します。
従来の開発手法では、完了までに時間がかかる大規模で複雑なプロジェクトでも、アジャイルであれば早期に市場へ投入することが可能になります。
アジャイル開発に関するFAQ|教えてジョー!
アジャイル業界をリードする、ジョー ジャスティスに直接質問して聞いてみました!
ウォーターフォールとアジャイルどっちがいいの?と迷っている方、アジャイルで失敗した経験のある方へのアドバイスも聞いてみましたので参考にしてください!
- ウォーターフォールからアジャイルへ切り替えする時の注意点
- アジャイル導入を会社の上層部を説得するには、どうするのが効果的?
- 会社でアジャイル導入するにあたりスクラムマスターの資格は必要ですか?
- 新米スクラムマスターなのですが、アジャイルで失敗した経験談を聞いておきたいです!
- チームメンバーにアジャイルマインドを浸透させるのに苦労しています!アドバイスをお願いします
- ウォーターフォールからアジャイルへ切り替えする時の注意点
-
まずは最初にチームや上司に、アジャイルを理解してもらうことです。スクラムマスターがコーチとして、アジャイルを理解してもらえるよう働きかけてみてください。
- アジャイル導入を会社の上層部を説得するには、どうするのが効果的?
-
いくつかの方法が考えられますが、アジャイルの良さを体験してもらうのが良いでしょう。アジャイルミニゲームで体験してみるというのは、よく取られる方法ですし、社内勉強会も良いでしょう。我々も研修を実施していますが、外部の研修に参加することも非常に良い方法です。すでに社内に成功事例があれば、それを提示することもできるでしょう。
- 会社でアジャイル導入するにあたりスクラムマスターの資格は必要ですか?
-
資格は必要ありません。必要なことはパッションです!ただ多くの場合は、資格を取ることでスクラムマスター自身の自信に繋がるでしょう。
- 新米スクラムマスターなのですが、アジャイルで失敗した経験談を聞いておきたいです!
-
よくあるケースは、アジャイルという言葉を使っているだけという場合です。アジャイル用語を使って、アジャイル開発をしているように見えるけど、実態は従来の開発手法から抜け出せていない時です。そのため、思うように成果が出ず、アジャイル開発失敗というように捉えられてしまいます。なので、まずはチームや上司にアジャイルを理解してもらい、全員が協力する必要があります。
- チームメンバーにアジャイルマインドを浸透させるのに苦労しています!アドバイスをお願いします
-
心理的安全性を高めることから始めてみてください。心理的安全性は、アジャイルを上手く機能させるために非常に重要です。
まとめ
プロジェクトの成果を最初から明確に理解でき、敏捷性を求められない場合はウォーターフォール開発が合っている場合もあるかもしれません。しかし時代の変化に伴って開発手法が変わってきているということは、もはや必然的なのかもしれません。アメリカやヨーロッパではもちろん、日本国内でもアジャイル開発の成功事例はたくさんあります。ぜひ、スモールスタートからでも初めてみてください!
アジャイルを理解するための関連記事
アジャイル関連の資格やトレーニングを知りたい
アジャイル関連の資格や研修に興味のある方は以下の記事もおすすめです!
アジャイル開発関連
スクラムマスター関連
スクラムマスターやプロダクトオーナー向けのおすすめ記事