2023.08.21

アジャイル開発とは？概要や進め方、ウォーターフォール型開発との違いやスクラムについて解説

著者株式会社SHIFT　マーケティンググループ

Introduction

ビジネス環境の変化が激しい今日。ソフトウェア開発の効率化は、プロダクト・ライフサイクルを意識し、市場のニーズに迅速に応えるための課題の一つといえます。その課題に対応する方法として主流となりつつあるのがアジャイル開発です。変化が激しい昨今に対応できる開発手法として、多くの企業が採用を始めています。

本コラムでは、アジャイル開発の概要や手法、メリットやデメリット、そしてアジャイル開発の成功・失敗事例についてご紹介します。

アジャイル開発とは何かわかりやすく解説

アジャイル（Agile）とは、英語で「素早い」「機敏な」などの意味です。開発用語であるアジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつであり、文字通り「素早く」開発を行う方法です。複数のエンジニアでチームを組み、ユーザーを巻き込みながら以下の工程を繰り返し行い、機能をブラッシュアップしながらプロダクトを完成させます。

・要件定義
・設計
・開発
・テスト
・リリース

アジャイル開発は、2000年代に開発手法として採用されるようになり、今日では主流の開発手法のひとつとなりつつあります。例えば、SHIFTが行った調査によると、調査対象のうちの74％が「アジャイル開発を導入済み」、あるいは「導入を検討中」、「導入予定あり」と回答していることからも、この傾向を理解することができるでしょう。

本調査では、アジャイル開発の導入状況のほか、導入の目的や効果、開発対象としているシステムといったこともご紹介しています。以下ページから資料をダウンロードいただけますので、参考にしてみてください。

アジャイル開発白書

近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。

ダウンロード

アジャイルソフトウェア開発宣言

軽量のソフトウェア開発を実践、提唱していた17人の技術者やプログラマーが集まり、2001年に議論をして生まれたのが「アジャイルソフトウェア開発宣言」です。この宣言は、アジャイル開発とそれに基づく12の原則を定義していることもあり、アジャイル開発の公式文書として広く知られています。

例えば、この宣言の12の原則には、次のようなものが記されています。

「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」
「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」

この原則にもあきらかなように、アジャイルソフトウェア開発宣言には、アジャイル開発のポリシーとともに、この開発によってユーザー（顧客）にもたらされる「価値」が記されているともいえます。したがって、アジャイル開発を進めるプロジェクトの関係者は、この宣言に記されていることを念頭に置いて、プロジェクトを推進することが求められるといってもいいかもしれません。

ウォーターフォール型開発とアジャイル型開発との違い

あらかじめすべての開発工程の計画を立て、要件定義、設計、開発、テストという工程を順番に完了させ、最後にリリースするというウォーターフォール型の開発と異なり、アジャイル型開発（アジャイル開発）では、1週間から2週間程度のサイクルの中でこれらの一連の工程が完結するように機能を小分けにした開発を繰り返し、プロダクトを完成させるという特徴があります。なお、この小さな単位の開発はイテレーションやスプリントといわれます。決まったイテレーションサイクルの中で、チームのベロシティにあった複数のユーザーストーリーを順番にもしくは並列して実装します。

	アジャイル型開発	ウォーターフォール型開発
推奨されるプロジェクトの規模	1チーム10人以下の小規模開発向け	チームの構成員数が多い大規模開発向け
開発期間	短い	長い
メリット	・ユーザーニーズに柔軟に対応できる・不具合発生時の対応工数が少ない・時間やコストが削減できる	・方針が決定してから進めるため進捗管理がしやすい・予算が立てやすい・メンバーのアサイン計画が立てやすい
デメリット	・開発の方向性がブレやすい・スケジュールや進捗確認がしにくい	・開発途中での仕様変更に対応しにくい・時間やコストがかかる

ウォーターフォール型開発の場合、開発当初の要求に従って、開発の範囲や計画を定め、工程ごとのリソースを確保し、計画に従って工程を進めていき、プロダクトを完成させます。そのため、開発途中に要求の変更があった場合や、仕様変更が入った場合などには、追加の費用や開発期間が発生する可能性があります。

これに対して、アジャイル型開発の場合は、まず大まかな計画を立て、チームを組み、機能単位での小さな開発サイクルを繰り返していきます。チームにアサインされるメンバーは、設計、開発、テストといった複数の工程を担います。プロダクトの完成までの工程では、仕様変更の確認や要求についてのフィードバックなどを臨機応変に受けながら進めるため、ベロシティの範囲内で最適解を求めながら開発を進めることができる手法だといえます。

アジャイル開発の進め方・流れ

続いて、アジャイル開発がどのような流れで進められるのかについて見ていきましょう。具体的な流れは次の通りです。

①リリース計画を立てる
②イテレーション（小サイクルでの開発）を実施する

アジャイル開発では、おおよそのリリース計画を立てたのち、イテレーションと呼ばれる機能単位での開発サイクルを繰り返し、プロダクトを作り上げていきます。ウォーターフォール開発の場合は最初に要件定義をしたのちに再度要件定義することは基本的にはありませんが、アジャイル開発では機能ごとに要件定義を実施する点が異なるポイントです。

それぞれの手順について、詳しく見てみましょう。

①リリース計画を立てる

まずは、いつまでにどの機能をリリースするかのおおよその計画を立てます。アジャイル開発の前提として、プロジェクトを進める中で設計や仕様の変更は発生するので、リリース計画はあくまでおおよその計画であり、状況に応じて継続的に修正を行う必要があります。

リリース計画を立てるにあたっては、以下の要素が必要です。以下の要素を踏まえ、どの機能がいつまでにリリースするのかを計画に落とし込みます。

・プロジェクトのゴール
・イテレーションの長さ
・ベロシティの算出
・ユーザーストーリーの優先順位と工数

プロジェクトのゴール

このプロジェクトでは何を実現するのか、目標・ゴールを明確にします。

イテレーションの長さ

イテレーションとは、「反復・繰り返し」という意味で、アジャイル開発においては、要件定義・設計・実装・テスト・リリースの1サイクルを指します。イテレーションの期間は1～4週間が一般的で、イテレーションごとに機能をリリースするのが基本です。イテレーションの期間はプロジェクトによって異なります。

また、アジャイル開発のひとつの手法であるスクラムにおいては、イテレーションではなくスプリントと呼ぶのが一般的です。

ベロシティの算出

ベロシティとは、1イテレーションにおいてチームがどのくらいの開発ができるかを数値化したものです。

ユーザーストーリーの優先順位と工数

ユーザーストーリーとは、ユーザーがどのような目的で、何を実現したいのかを文章で簡潔にまとめたものです。アジャイル開発では要件の代わりによく使われます。ユーザーストーリーに優先順位を付け、それぞれどれくらいの工数が必要となるのか見積ります。

②イテレーション（小サイクルでの開発）を実施する

イテレーションとは、計画に基づいて短期間に定められたテーマから、要件定義～テスト、リリースを行うサイクルのことです。1回のイテレーションごとに成果物を作成します。リリースした機能の確認を行い、顧客からのフィードバックや修正・不足事項は次のイテレーションに反映し、プロダクトを作り上げていきます。

このサイクルを繰り返し、プロジェクトを徐々に進めていきます。

アジャイル開発の手法

アジャイル開発の手法の代表的なものとしては、「スクラム」、「エクストリーム・プログラミング（Extreme Programming：XP）」、「ユーザー機能駆動開発（Feature Driven Development：FDD）」といったものがあります。実際の開発現場では、これらの代表的な手法を部分的に併用して進めることになるでしょう。

ここでは、SHIFTの調査のなかで、開発経験がある企業の約85％が開発手法として採用していると回答していた「スクラム」を中心に紹介します。

スクラム

スクラムとは、アジャイル開発のフレームワークの一つとして位置づけられるものです。プロダクトオーナー、スクラムマスター、開発者が10人以下のチームを組み、機能単位で「計画、設計、開発、テスト」、そしてリリースのサイクル（スプリント）を繰り返し、プロダクトを完成させます。

ユーザーを巻き込みながら開発することで、顧客の価値を最大化しつつ、素早く、動くプロダクトを完成させることが特徴です。

スクラムを行う上で参照されることの多い「スクラムガイド（日本語版）」には、スクラムのプロセスとして次の5つを挙げています。

ここでは、ガイドに従ってこの5つのプロセスについて紹介します。

1．スプリントプランニング（スプリント計画）

スプリント計画は、スプリントの起点として位置づけられるスプリントで実行する作業の計画を立てるプロセスです。スプリントの計画は、チーム全体の共同作業で作られます。

スクラムオーナーは、プロダクトのゴールとそのための手順などに基づいて、スプリントに関わるチームのメンバーが、そのスプリントで何を実現するのかを理解するよう促します。

チームのメンバーは、チーム全体でそのスプリントが実現することの意味を理解し、スプリントゴールを定義し、ゴールに至るまでに何を成し遂げるのかを決めます。

2．スプリント

スプリントは、計画に基づき、設計、開発、テストを行い、機能をリリースするプロセスです。スプリントの期間は1ヶ月を上限として定められています。スプリント期間中には、後述するようなデイリースクラム、スプリントレビュー、スプリントレトロスペクティブ（振り返り）を行いながら、プロダクトを完成させていきます。

なお、スプリントにおいては、ゴールの達成を危険にさらすような変更はしないことなどが原則として定められています。

3．デイリースクラム

デイリースクラムは、スプリントを円滑に進めるためのコミュニケーションのプロセスです。1回を15分程度のイベントとしています。無用な混乱を招かないように、定例朝会といったような形式で、スプリントの期間中、毎日、同じ時間・場所でやることが推奨されています。デイリースクラムでは、進捗状況や課題を共有することで現状を把握します。

4．スプリントレビュー

スプリントレビューは、スプリントの成果物を検査したり、評価したりする、いわゆるレビューのプロセスです。スクラムのチームだけではなく、ユーザーも参加して行われます。

レビューによっては、プロダクトバックログの項目が追加、削除されたり、ゴールに向かう最適な手順への入れ替えが行われたりということもあります。いずれにしても、限られた時間やコストのなかでプロダクトの価値を最適化させることを目指して行われるのがこのプロセスです。

5．スプリントレトロスペクティブ（振り返り）

スプリントレトロスペクティブは、「品質と効果を高める方法を計画する」プロセスのことです。スクラムによってもたらされた効果（価値）や、プロダクトのゴールに向かうためのチームの品質（状態、コミュニケーションのあり方など）も含めた計画を行います。

スプリントレトロスペクティブは、スプリント終了時に行われます。ここでは、スプリントを振り返り、進捗に影響したものを特定し、原因を探求。また、発生した問題やその解決方法を明確にするように話し合い、品質と効果を高める方法を明確化していきます。

なお、スクラムの成果物のうち、重要なものとしては、次の2つがあげられます。

・プロダクトバックログ
・スプリントバックログ

プロダクトバックログ

プロダクトバックログは、機能や改善が必要なものについて優先順位をつけ、記述したものです。優先順位をつけることで、今回のスプリントで対応する機能、次回のスプリントで対応する必要がある機能といったことを明確にできます。また、プロダクトバックログは、ステークホルダーがプロダクトの状況を把握することにも用いられます。

スプリントバックログ

スプリントバックログは、プロダクトバックログから、スプリントのチームが対応する期間の分を選択、抽出したタスクのリストのようなものです。わかりやすくいえば、スプリントの開発計画ともいえます。

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

エクストリーム・プログラミングとは、開発者を中心とした開発手法のことです。

機能単位で設計、開発、テストというイテレーション（反復）を繰り返すなかで、2人1組でコーディングとレビューを同時に進行させる「ペアプログラミング」を行ったり、チーム内で定める自己文章化を推進しコメントを減らす「コーディング規約」などに基づき開発を行ったりすることで、効率的な開発を行えるようにするところが特徴といえます。

また、仕様変更や追加を前提として位置付けていることが特徴ということもあり、ユーザーからの要求を、勇気をもって柔軟に受け入れ、開発することが重要な要素の一つともいえます。

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

ユーザー機能駆動開発とは、ユーザーにとっての機能価値（feature）というものを中心とした開発手法のことです。実際に動く機能のリリースを一定の間隔内で繰り返し、プロダクトを完成させていきます。

機能を開発する前提として、ユーザー側のビジネスモデルを理解し、ログイン機能、ユーザー登録機能といった機能単位で設計、開発、テストを行っていくことが特徴的です。

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

アジャイル開発の概要や特徴、そして開発手法についてこれまでご紹介してきました。次に、アジャイル開発のメリット・デメリットについて触れていきたいと思います。

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

アジャイル開発の場合、機能単位で設計、開発、リリースを行うことができるので、スピーディーにプロダクトや機能をユーザーに提供できるというメリットがあります。

また、ユーザー側の要求を取り入れながら開発できるため、開発側にとってもユーザー側にとっても開発意図にかなった価値の高いプロダクトや機能をリリースできることもメリットです。

さらに、都度要求を確認しながら小さい単位で開発ができるため、手戻りが少なく、工期、コストを抑えた開発ができることもメリットです。

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

アジャイル開発のデメリットとしては、柔軟性があることが影響して、開発の方向性がぶれてしまうということが考えられます。しかも、変更や追加を受け入れながら開発するため、かえって工期が長くなってしまったり、コストが予想よりも高くなってしまったりする、ということも懸念点です。

また、小さな機能単位での開発に目が奪われてしまうことで、全体のスケジュール感が把握できなくなってしまうということも考えられます。

そのようなことにならないようにするためには、例えばプロダクトバックログを参照し、この機能は、「どのような価値をもたらすものか」、「何のためにあるのか」、「いつまでにリリースする必要があるのか」といったことに絶えず立ち返り、プロジェクト全体をコントロールしていくことが重要といえます。

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

アジャイル開発には、多くのメリットがあるといわれていますが、この開発手法がすべてのシステムに対応するとはいいがたいところもあります。

アジャイル開発が向いているものの代表例は、Webサービス（EC、SNSなど）、Webアプリやスマホのアプリ、ゲームなどのように、頻繁に新しいサービスが開発され、またプロダクトのライフサイクルが早いものだといえます。SHIFTが行った調査でも、アジャイル開発を経験している企業の9割近くが、WebサービスやWebアプリの開発についてアジャイル開発を行っていることからも、これらのシステムがいかにアジャイル開発に向いているのかを理解することができるでしょう。

Webサービスやゲームなどの場合、開発中やリリース後にユーザーのニーズが変わってしまうことも多く、その変更に柔軟な対応が必要なことがあります。また、類似するサービスも多く存在するため、サービスのコモディティ化が起こりやすく、いかに迅速にサービスをリリースし、ユーザーの反応に応じながら迅速にシステムを改善していくかといったことが、サービスをマネタイズするうえで重要な要素です。

このような場合、計画をじっくり立て、それに合わせてリリースしていくといった開発手法よりも、変化を前提とした開発手法の方が向いているということがいえるでしょう。

アジャイル開発の導入状況のほか、導入の目的や効果、開発対象としているシステムといったこともご紹介しています。下記ページから資料をダウンロードいただけますので、参考にしてみてください。

SHIFTアジャイル開発白書2020

アジャイル開発で成功した事例・ポイント

多くのメリットがあるアジャイル開発ですが、ポイントを押さえなければ実際には上手く機能しません。SHIFTが多くのお客様のアジャイル開発プロジェクトをご支援する中で実際に成功した事例やそのポイントをご紹介します。

進め方を定義し、プロセスを見直し、定着させること

教育サービス事業に携わるA社は、基幹システムの刷新をウォーターフォール開発にて推進していましたが、要件定義がまとめられず思うように進まずにいました。旧システムが複雑であったことやドキュメントなども少なかったことから、調査だけで相当な年月がかかってしまう状態でした。一方で、ウォーターフォール開発の推進によって期限が決まっていた中で進めていたため、不十分な調査の中で開発を進めようとしたことでうまくプロジェクトが進まない状況でした。このため、A社は開発プロセスの見直しをはかり、アジャイル開発による基幹システムの刷新を進めることになりました。

しかしながら、アジャイル開発が初導入ということもあり、進め方がわからない点、納期が間伸びしていた点、品質が良くない点が課題としてあがっていました。そこで、SHIFTはアジャイルQA支援チームを立ち上げ、アジャイル開発プロセス定着支援、開発プロセス改善、インクリメント開発定着支援を行いました。

結果として以下のような成果が見られました。

・品質リスクを特定し障害予防施策を打つことで障害摘出率が90%向上
・定型／反復的な回帰テストは自動テスト導入（API／GUI）しスプリントを25%短納期化
・顧客価値の高いPBIに再整理し効率化をはかることでリリースを40%短納期化

実際プロジェクトを進める中で、各種データハブになる基幹システムであったため、さまざまな方向からの要求・要件変更が発生しました。アジャイル開発に切り替えたことでこれらにも対応することが可能になり、ほかの新規サービスとの連携も取れるようになったこともアジャイル開発を進めた成果としてあげられます。

今回のケースでは、アジャイル開発プロセス定義支援や開発プロセス改善を考慮したことで、プロジェクトを成功させることができました。アジャイル開発の経験が少ない中で、導入してすぐに開発を成功させることは簡単ではありません。アジャイル開発をどう進めるべきか定義し、プロセスの見直しを行い、そしてそのプロセスを定着させることが大切です。

品質やチーム状況を可視化し、改善を図ること

大手金融業のB社は高い品質が求められる金融Webサービスにおいて品質課題を抱えていました。開発優先順位にテスト難易度が考慮されておらず、テスト期間にて早期発見すべき不具合が散見される状態でした。

そこで、SHIFTがご支援させて頂くことになるのですが、SHIFTへの期待は品質向上、開発メンバーが品質を意識したアジャイル開発プロセスに適応すること、また、顧客ヒアリングで指摘された問題の早期解決をアジャイル開発によって実現することでした。

SHIFTは品質保証戦略の立案、スプリント内の機能・シナリオテスト実施、自動テストの拡充、チーム状況の可視化を行うことで課題解決に臨みました。

結果として以下の成果が見られました。

・スプリント内でのテストが可能になるようなプロセスに変化し、UT／API／E2E各層における定型／反復的な回帰テストの自動テスト導入により25％短納期化に成功
・開発ブランチ、テスト環境別のテスト整理、効率化により効果的な手動テストの実施を行うことで障害摘出率が90%向上
・リリース難易度と顧客価値を考慮したPBIの再整理を行い、チーム状態を可視化することで改善意識が高まりチームの成長が促進されたため、生産性が向上

これらを実現したことで、品質の向上および顧客ニーズに合ったサービスのマーケットインの実現に成功しています。

今回のケースでは、品質保証戦略の見直しや状況の可視化を考慮したことで、プロジェクトを成功させることができました。アジャイル開発を成功させるポイントとして、顧客要件や課題の早期解決を図るために品質やチーム状況を可視化し、改善を図ることが大切です。

アジャイル開発で失敗するケース

アジャイル開発を導入したからといって上手くいくケースばかりではなく、実際、多くの失敗事例も報告されています。続いては、アジャイル開発が失敗したケースについてご紹介します。

失敗してしまう理由はいくつかありますが、代表的なものは次の3つです。

・メンバー間のコミュニケーションが活性化していない
・リーダーの役割が機能していない
・発注者が積極的ではない

総合すると、アジャイル開発の失敗で多いのは仕組みではなく人に起因しているというケースです。どのような内容なのかを解説していきます。

メンバー間のコミュニケーションが活性化していない

ここでいうメンバーとは、クライアントを含めたプロダクトに関わるすべての人を指します。このメンバー間のコミュニケーションが活性化しなかったため、アジャイル開発が失敗するケースがあります。

アジャイル開発において重要なのは、相手の意見を尊重することではなく提案や指摘ができるような環境です。この環境が出来上がっていなければ、アジャイル開発を成功するのは難しいといえます。相手の批判をする必要はありませんが、ひとつの製品を開発する上で活発な議論が取り交わされるくらいの風通しの良さが求められます。

リーダーの役割が機能していない

スクラムマスターやプロダクトオーナーなどのリーダーが役割を果たせていない場合も、アジャイル開発の失敗確率が高くなります。どちらも開発チームの方向性やスケジュール管理・調整を行う人物ですが、彼らが機能しなければ工程の延長や顧客ニーズに達していない商品が出来上がってしまう可能性があります。

リーダーに任命された人はその役割を自覚し、特定の利害関係者のいいなりにならないようにしなければなりません。

発注者が積極的ではない

アジャイル開発では発注者も開発に関与して初めて望んでいるものが完成します。開発者だけが中心の従来型の開発とは違い、ユーザーニーズを大きく反映させるアジャイル開発では発注者の存在が非常に重要なカギを握っています。

たとえ発注者であっても、良いものを一緒に作っていく意識が重要です。

アジャイル開発の導入の相談はSHIFTグループにお任せ

今日、アジャイル開発は、ソフトウェア開発の開発手法として認知され、多くの企業で採用されるようになりました。

アジャイル開発は、手法とともに、その思想が広がり、プロダクトの価値を最大化させるといったメリットを享受できている企業も増えてきているのです。

一方で、SHIFTの調査では、アジャイル開発を導入したものの、「組織・顧客との間での理解不足」「人材の確保や育成」といったことが課題となり、アジャイル開発について、満足できる結果を得られなかった企業も、少なくはないということが明らかになっています。

つまり、コスト削減や工期を短縮させたいという目的のもと、すべてのプロジェクトでアジャイル開発を採用したほうがよいというわけではないようです。重要なのは、自社が開発するシステムの特性に合わせて、適した開発手法を選択することなのかもしれません。

＞＞アジャイル開発支援サービスのページへ
＞＞お問い合わせのページへ
＞＞料金についてのページへ
＞＞導入事例のページへ

資料ダウンロード／動画視聴

アジャイル開発の実態調査

ソフトウェアテスト入門動画

SHIFTサービス資料

テストサービス導入事例集

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る