アジャイル開発とは｜特徴やメリット・デメリットをわかりやすく解説

アジャイル開発とは、短い期間で開発と確認を繰り返し、顧客に価値のあるソフトウェアを早く、継続的に届けるための考え方（アプローチ）の総称です。特定の手法の名前ではなく、スクラムやカンバンなどの手法は、この考え方を実践するための枠組みにあたります。

私はプロジェクトマネージャーとして、ウォーターフォール開発とアジャイル開発の両方の現場を経験してきました。アジャイル開発を取り入れた現場では、「計画を立てなくてよい」「ドキュメントは不要」といった誤解から、かえって混乱が起きる場面も見てきました。

この記事では、アジャイル開発の定義と価値・原則を一次情報にもとづいて整理したうえで、特徴、ウォーターフォール開発との違い、代表的な手法、スクラムとの関係、進め方、メリット・デメリット、向き不向き、よくある誤解を解説します。

執筆者：和田匠真

IT業界で20年以上の実務経験を持つプロジェクトマネージャー。プログラマー・SEを経てPMとなり、大手企業のシステム提案からデリバリーまで一貫して従事。PMP／認定スクラムマスター（CSM）保有。ウォーターフォール／アジャイル双方の現場経験をもとに、プロジェクト管理に関する記事を執筆。

アジャイル開発の計画と進み具合を管理するなら、当社が提供するLychee Redmineもご検討ください。Neoバックログでスプリントを計画し、Neoカンバンで日々の進み具合をチームで共有でき、30日間の無料トライアルでお試しいただけます。

 

アジャイル開発とは

アジャイル開発は、短い期間で開発と確認を繰り返し、顧客に価値のあるソフトウェアを早く継続的に届けるための考え方・アプローチの総称です。決まった手順を持つ1つの手法を指す言葉ではない、という点を最初に押さえておきましょう。

アジャイル開発の定義

IPA（情報処理推進機構）は、アジャイル開発を次のように定義しています。

「アジャイル開発とは、ビジネス価値の最大化に向けて、顧客に価値のあるソフトウェアを早く、継続的に提供するためのアプローチです。」

アジャイル（agile）は、英語で「素早い」「機敏な」という意味です。また、内閣官房IT総合戦略室のアジャイル開発実践ガイドブックでは、アジャイル開発を「インクリメンタルかつイテレーティブな開発」と表現しています。つまり、少しずつ機能を増やし、開発を繰り返しながら改善していく進め方です。
（出典：IPA「アジャイル領域へのスキル変革の指針 アジャイル開発の進め方」／内閣官房IT総合戦略室「アジャイル開発実践ガイドブック」）

アジャイルソフトウェア開発宣言と4つの価値

アジャイル開発の考え方の土台は、2001年にソフトウェア開発者17人がまとめた「アジャイルソフトウェア開発宣言」です。宣言では、次の4つの価値が示されています。

「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」
（引用：Agile Manifesto「アジャイルソフトウェア開発宣言」）

宣言は、プロセスやドキュメント、計画を否定しているわけではありません。それらにも価値があると認めたうえで、個人と対話や動くソフトウェアなどを、より重視するという意味です。

アジャイル宣言の背後にある12の原則

宣言には、価値を具体的な行動に置き換えた「アジャイル宣言の背後にある原則」（12の原則）があります。たとえば、最初の原則は「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」です。

ほかにも、動くソフトウェアをできるだけ短い間隔でリリースすること、ビジネス側の人と開発者がプロジェクトを通して日々一緒に働くこと、チームが定期的にふりかえってやり方を調整することなどが示されています。12の原則は、日々の判断に迷ったときに立ち返る基準として役立ちます。全文は公式サイトで確認できます。
（出典：「アジャイル宣言の背後にある原則」）

アジャイル開発が広まった背景

市場や利用者の要望は、短い期間で変わるようになっています。そのため、開発の最初にすべての要件を決めきれないプロジェクトが増えました。最初に決めた仕様のまま数か月かけて作っても、完成したときには求められるものが変わっている、ということも起こり得ます。

また、DXの推進によって、新しいサービスを小さく作り、利用者の反応を確かめながら改善する進め方が求められています。こうした変化に対応する方法として、短い期間で作って確かめるアジャイル開発が広く取り入れられるようになりました。

 

アジャイル開発の特徴

アジャイル開発の特徴は、大きく4つに整理できます。いずれも、変化に対応しながら価値を届けるという考え方から生まれたものです。手法によって具体的な進め方は異なりますが、ここで紹介する特徴は多くの手法に共通しています。

短いサイクルで開発・確認・改善を繰り返す

アジャイル開発では、短いサイクルで開発・確認・改善を繰り返します。サイクルの区切り方は手法によって異なります。

たとえばスクラムでは、1か月以内の決まった長さのスプリントを繰り返します。IPAの資料では、スプリントは1〜4週間の時間枠とされています。一方、カンバンのように固定の期間を設けず、作業の流れを見える化しながら継続的に改善する手法もあります。サイクルの形は違っても、作って確かめて直す、という流れは共通です。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」／Kanban Guides「The Kanban Guide（2025年5月版）」）

優先度の高い機能から作る

アジャイル開発では、作りたい機能や要望を一覧（バックログ）にまとめ、価値の高いものから順に開発します。

すべての機能が完成するのを待たずに、使える状態になったものから順に届けられる点が特徴です。優先順位はサイクルごとに見直すため、途中で重要な要望が見つかれば、順番を入れ替えて先に取り組むこともできます。限られた期間と予算の中で、価値の大きい機能から確実に届ける考え方です。優先順位の判断には、利用者や事業部門の意見も取り入れます。

顧客や利用者と協力しながら進める

アジャイル開発では、顧客・利用者・事業部門が開発に関わり、完成したものを確認してフィードバックを返します。12の原則にも、ビジネス側の人と開発者が日々一緒に働くことが挙げられています。

そのため、発注する側の担当者が継続して関わることが欠かせません。完成品の受け取りだけを待つのではなく、途中の成果を見て意見を伝えることで、本当に必要なものに近づけていきます。開発チームと発注する側が、同じ目標を持つ1つのチームとして進めるイメージです。

チームが自ら進め方を改善する

アジャイル開発では、チームが定期的にふりかえり、自分たちの進め方を見直して改善を続けます。12の原則の「チームがもっと効率を高めることができるかを定期的にふりかえり、それに基づいて自分たちのやり方を最適に調整します」という考え方です。

外から決められたやり方に従うだけでなく、チームが自ら工夫して進め方を良くしていく点が、アジャイル開発の大きな特徴です。改善を積み重ねることで、チームに合った進め方が少しずつ固まっていきます。

 

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

アジャイル開発とよく比べられるのが、ウォーターフォール開発です。ここでは、計画の立て方やリリースの時期など進め方の違いと、どちらを選ぶかの考え方、両方を組み合わせる方法を整理します。

計画と要件の決め方の違い

ウォーターフォール開発では、最初に要件と計画を固め、要件定義・設計・実装・テストと工程を順番に進めます。前の工程が終わってから次の工程に進むため、全体の見通しを立てやすい進め方です。

一方、アジャイル開発では、大まかな方向性を決めたうえで、詳細は開発を進めながら決めていきます。最初にすべてを決めきらず、サイクルごとに優先順位と計画を見直す点が大きな違いです。計画を立てないわけではなく、計画を立てる単位と見直す頻度が異なります。

リリースの時期と変更への対応の違い

ウォーターフォール開発では、すべての工程が終わった最後にまとめてリリースするのが一般的です。途中で仕様が変わると、前の工程に戻って作り直す手戻りが大きくなりやすくなります。

アジャイル開発では、短い期間ごとに使える機能をリリースでき、優先順位の見直しによって変更を取り込みやすくなります。利用者の反応を早く得られるため、作ったものが使われないリスクも小さくしやすいでしょう。ただし、変更を取り込むほど、全体の範囲や時期は見直しが必要になります。

どちらを選ぶかの判断基準

どちらが優れているということではなく、プロジェクトの条件によって合う方法が変わります。判断の材料になるのは、要件がどれだけ決まっているか、途中で変わる可能性があるか、顧客がどれだけ開発に関われるか、納期と予算をどこまで固定する必要があるか、の4点です。

要件が固まっていて変更が少ないならウォーターフォール開発、要件が変わりやすく顧客が継続して関われるならアジャイル開発が合いやすくなります。詳しい比較は、次の記事で解説しています。

両方を組み合わせるハイブリッド型

アジャイル開発とウォーターフォール開発は、どちらか一方を選ぶだけではありません。工程やチームによって、両方を使い分ける方法もあります。

たとえば、基盤となるシステムや外部との連携部分は仕様を固めてウォーターフォール開発で進め、利用者が触れる画面や機能の改善はアジャイル開発で進める、という形です。変わりにくい部分と変わりやすい部分を分けて考えると、それぞれに合った進め方を選びやすくなります。

組み合わせる場合は、両方の進め方の予定がずれないよう、連携する時期を事前に決めておきましょう。

 

アジャイル開発の代表的な手法

アジャイル開発を実践するための手法には、いくつかの種類があります。ここでは、スクラム・カンバン・エクストリーム・プログラミング（XP）の3つを中心に紹介します。

スクラム

スクラムは、チームで短いスプリントを繰り返しながら、価値を生み出すための枠組みです。プロダクトオーナー・スクラムマスター・開発者の3つの責任と、スプリントなどのイベント、プロダクトバックログなどの作成物が定められています。

IPAの資料でも、代表的な手法としてスクラムを例に説明されています。チームで役割を分担しながら、計画・開発・確認・ふりかえりを一定のリズムで繰り返したい場合に向いています。スクラムについては、次章以降で詳しく説明します。

カンバン

カンバンは、作業をカードにして「未着手・作業中・完了」などの列に並べ、仕事の流れを見える化する手法です。カンバンガイドでは、プロセスを通じた価値の流れを最適化するための戦略とされています。

同時に進める作業の数（仕掛かり中の作業）を抑えることで、作業の滞りを見つけて流れを改善します。スプリントのような決まった期間を設けずに使えるため、問い合わせ対応や運用保守など、作業が随時発生する業務にも取り入れやすい手法です。

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

エクストリーム・プログラミング（XP）は、品質を保ちながら変更に対応するための、開発の実践を重視する手法です。

代表的な実践として、先にテストを書いてから実装するテスト駆動開発、2人で1台の画面を見ながらプログラムを書くペアプログラミング、コードの変更をこまめに統合して確認する継続的インテグレーションなどがあります。

変更が多いプロジェクトでも、品質を落とさずに開発を続けるための工夫が詰まっていることが特徴です。ほかの手法と組み合わせて取り入れられることもあります。

そのほかの手法

スクラム・カンバン・XPのほかにも、アジャイル開発の手法はあります。

• ユーザー機能駆動開発（FDD）は、利用者にとって価値のある機能を単位に、計画と開発を進める手法です。
• リーンソフトウェア開発（LSD）は、ムダを省き、価値を素早く届けることを重視します。
• 適応的ソフトウェア開発（ASD）は、推測・協調・学習のサイクルで、変化に適応しながら進める手法です。

それぞれの特徴と選び方は、次の記事で詳しく紹介しています。

 

アジャイル開発とスクラムの関係

アジャイル開発とスクラムは、混同されやすい言葉です。「アジャイル開発とスクラム開発の違い」を知りたいという声も多いのですが、2つは並べて比べるものではありません。

アジャイル開発という考え方の中に、スクラムという実践の枠組みが含まれる関係です。

アジャイル開発は考え方で、スクラムはその実践方法の一つ

アジャイル開発は、アジャイルソフトウェア開発宣言に示された価値と原則にもとづく、開発の考え方の総称です。決まった手順や役割を定めたものではありません。

一方、スクラムは、その考え方を実践するための具体的な枠組み（フレームワーク）の一つで、責任・イベント・作成物がスクラムガイドに定められています。

つまり、スクラムで進める開発はアジャイル開発の一種ですが、アジャイル開発のすべてがスクラムというわけではありません。カンバンやXPで進める開発も、アジャイル開発に含まれます。2つの関係と選び方は、次の記事で詳しく解説しています。

スクラムチームの3つの責任

スクラムチームは、プロダクトオーナー・スクラムマスター・開発者で構成されます。2020年版のスクラムガイドでは、これらを「役割」ではなく「責任（アカウンタビリティ）」と表現しています。一般には役割とも呼ばれます。

• プロダクトオーナーは、プロダクトの価値を最大化することに責任を持ち、プロダクトバックログを管理します。
• スクラムマスターは、スクラムの理解と実践を支援し、スクラムチームの有効性に責任を持ちます。
• 開発者は、各スプリントで使える成果（インクリメント）を作ることに責任を持ちます。

何を作るかの判断、進め方の支援、成果づくりを3つの責任で分担することで、チームが自ら判断して進められるようになります。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

アジャイル開発の進め方【スクラムの例】

アジャイル開発の進め方は、手法によって異なります。ここでは、代表的な手法であるスクラムを例に、流れを紹介します。プロダクトバックログをもとに計画を立て、開発・テスト、スプリントレビュー、スプリントレトロスペクティブまでを行うのが1回のスプリントです。

プロダクトバックログを作り優先順位を決める

最初に、作りたい機能や改善したい点、解決したい課題を一覧にまとめます。この一覧がプロダクトバックログです。スクラムガイドでは、プロダクトの改善に必要なものを順番に並べた一覧とされています。

並び順を決める責任を持つのは、プロダクトオーナーです。利用者や事業部門の要望を聞きながら、価値の高いものが上に来るように並べます。プロダクトバックログは一度作って終わりではありません。スプリントレビューで得た意見や状況の変化をもとに、項目の追加や並び替えを続けていきます。

スプリントプランニングで今回の目標と作業を決める

スプリントの最初に、スプリントプランニングを行います。スクラムチーム全体で、このスプリントで達成する目標（スプリントゴール）を定めましょう。取り組む項目は、プロダクトオーナーと相談しながら開発者が選び、完成させるための作業を計画します。

スプリントの長さについてスクラムガイドでは、1か月以内の決まった長さで決めることが定められています。IPAの資料では、スプリントは1〜4週間の時間枠とされ、予定した機能が完成しなくても延長しないことが原則です。

期間を固定することで、計画・確認・ふりかえりのリズムが一定になり、チームの実績をもとに次の計画を立てやすくなります。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」／IPA「アジャイル領域へのスキル変革の指針 アジャイル開発の進め方」）

開発・テストを進め、デイリースクラムで計画を調整する

スプリントの期間中、開発者は設計・実装・テストを進め、完成の定義を満たすインクリメントを作ります。完成の定義とは、作業が「完成」したといえる品質の基準を正式に示したものです。

また、各稼働日に15分のデイリースクラムを行い、スプリントゴールに向けた進み具合を確認して、今後の作業計画を調整します。デイリースクラムは、状況を報告するだけで終わらせず、ゴールに近づくために今日の計画をどう変えるかを話し合う場です。作業が止まっている点や困っている点があれば、その場で共有し、早めに手を打てるようにします。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

スプリントレビューで成果を確認する

スプリントの終わりには、スプリントレビューを行います。完成したインクリメントを顧客や関係者に見せ、プロダクトゴールに向けた進み具合を一緒に確認します。

関係者から得たフィードバックをもとに、次に何をするかを話し合い、プロダクトバックログを見直します。完成した機能を承認してもらうだけの場ではありません。利用者の反応や市場の変化をふまえて、プロダクトの今後の方向を関係者と決める場だと考えましょう。

スプリントレビューで得た意見が、次のスプリントの計画につながります。

スプリントレトロスペクティブで進め方を見直す

スプリントの最後に、スクラムチームでスプリントレトロスペクティブ（ふりかえり）を行います。メンバー同士のやり取り、進め方、ツール、完成の定義などについて、うまくいったことと課題を話し合い、次のスプリントで改善することを決めます。

私が関わったプロジェクトでも、ふりかえりで「仕様の確認待ちで作業が止まる」という課題が出たため、次のスプリントでは、プロダクトオーナーと確認する時間をあらかじめ決めて試しました。改善策は小さく決めて次のスプリントで試し、その結果をまたふりかえることで、チームの進め方が少しずつ良くなります。進め方の詳細は、次の記事で解説しています。

 

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

アジャイル開発には、変化に対応しながら価値を届けるための、次の4つのメリットがあります。ただし、効果はプロジェクトの条件や運用の仕方によって変わるため、期待できる効果として確認しましょう。

仕様の変更や追加に対応しやすい

アジャイル開発では、短いサイクルごとに優先順位を見直します。スクラムではスプリントごとに、カンバンでは作業の流れの中で随時、次に取り組む内容を決め直します。

そのため、開発の途中で生まれた要望や、市場・利用者の変化を取り込みやすくなります。最初に決めた仕様に縛られず、その時点で価値が高いものを優先できる点がメリットです。ただし、新しい要望を受け入れると、ほかの項目の順番が後ろに下がることもあります。

変更の影響を関係者と確認しながら調整しましょう。

早い段階で価値を届けてフィードバックを得られる

アジャイル開発では、使える状態になった機能から順にリリースできます。すべての機能の完成を待たずに、利用者に価値を届けられる点が特徴です。

利用者の実際の反応を早い段階で確かめられるため、次に何を作るべきかを根拠をもって判断しやすくなります。想定していた使い方と実際の使われ方が違う場合も、早く気づいて方向を修正できます。

作ったものが使われないまま終わるリスクを小さくできる点も、大きなメリットといえるでしょう。

手戻りによる損失を小さく抑えやすい

アジャイル開発では、短い期間ごとに完成したものを確認するため、認識のずれや不具合に早く気づけます。

認識のずれや不具合を早く発見できれば、その誤りを前提に開発が進むことを防ぎ、手戻りによる損失を抑えやすくなります。ただし、修正の影響が1回のサイクルで開発した範囲に収まるとは限りません。既存の機能や設計への影響も確認する必要があります。

スクラムガイドでも、新しいインクリメントはこれまでのインクリメントに追加され、すべてが連携して機能することを確かめるために検証されると説明されています。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

チーム内で状況や課題を共有しやすい

アジャイル開発では、日々の短い打ち合わせや定期的なふりかえりを通じて、チームの状況が見える状態になります。スクラムでは、デイリースクラムとスプリントレトロスペクティブがこの役割を担います。

誰が何に取り組み、どこで困っているかが共有されるため、問題を早く見つけて、チームで解決しやすくなります。特定の人だけが状況を知っている、という属人化も防ぎやすくなります。

課題を個人で抱え込まず、チームで話し合って解決する習慣が身につく点もメリットです。

 

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

アジャイル開発には、注意すべき点もあります。ここでは、代表的な4つのデメリットと、それぞれの対策を紹介します。前章のメリットとあわせて、自社のプロジェクトに合うかを判断する材料にしてください。

全体のスケジュールや費用を見積もりにくい

要件の不確実性が高い案件では、開始時点で「どこまで作るか」「いつ終わるか」「いくらかかるか」を同時に確定することが難しくなります。開発を進めながら詳細を決めるため、最初の見通しと実際がずれることもあります。

対策として、期間と予算の上限を先に決め、その範囲で優先順位の高いものから作る、という考え方で計画を立てましょう。サイクルごとの実績をもとに、残りの期間と予算で何ができるかを関係者と見直していけば、見通しの精度も上がっていきます。

開発の方向性がぶれやすい

アジャイル開発は変更を受け入れやすいぶん、目的があいまいなまま進めると、要望が次々に追加され、何を目指しているのかがわからなくなることがあります。

対策は、プロダクト全体の目標と、各サイクルの目標を明確にすることです。スクラムでは、プロダクトゴールとスプリントゴールがこの役割を持ちます。新しい要望が出たときは、目標に近づくかどうかを基準に優先順位を判断すると、方向性を保ちやすくなります。

目標はチームと関係者がいつでも確認できる場所に示しておきましょう。

チームの経験と顧客の継続的な関与が必要になる

アジャイル開発では、チームが自ら判断して進める力が求められます。また、顧客や事業部門が定期的に成果を確認し、意見を伝える体制も欠かせません。

発注側が開発に関わる時間を確保できないと、判断が遅れて作業が止まってしまいます。経験が少ない場合は、小さな範囲や1つのチームから始め、ふりかえりを通じて進め方を身につけていくとよいでしょう。

あわせて、顧客側の担当者にいつ、どの場面に参加してもらうかを、開始前に合意しておくことも大切です。

全体の進み具合が見えにくくなることがある

アジャイル開発では、短いサイクルの作業管理に意識が向きやすくなります。全体の目標やリリースの計画を共有していないと、プロジェクト全体がどこまで進んでいるのか、複数のチームがどのような状況なのかを把握しにくくなります。

対策として、バックログとリリースの計画を見える状態にし、サイクルごとの成果を全体の目標と結びつけて確認しましょう。関係者が同じ情報を見られるツールを使うと、チームの外にいる人も全体の進み具合を確かめやすくなります。

 

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

アジャイル開発が合うかどうかは、プロジェクトの条件によって変わります。ここでは、内閣官房IT総合戦略室の「アジャイル開発実践ガイドブック」の記述をもとに整理します。

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

アジャイル開発実践ガイドブックでは、アジャイル開発が向いているケースを次のように示しています。

「開発対象についてある程度の方向性はあるものの、全容が明らかになっておらず、開発を進めながら詳細化していく必要があるケース。」

たとえば、新しいサービスの開発、利用者の反応を見ながら改善するシステム、継続して機能を追加していくプロダクトなどが当てはまります。最初にすべてを決めきれず、作って確かめながら進める必要がある場合に、アジャイル開発の強みが生きます。
（出典：内閣官房IT総合戦略室「アジャイル開発実践ガイドブック」）

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

一方、向いていないケースは、次のように示されています。

「あらかじめ対象範囲や実現するべき詳細が定められており、明らかになっているケース。業務内容が明らかになっており、作って確認するという余地が少ない領域。」

たとえば、実現する内容が詳細まで合意されており、試作や利用者の反応によって見直す必要が少ない案件です。このような場合は、工程ごとの成果物を確認しながら進めるウォーターフォール開発も選択肢になります。

顧客が継続して関与できない場合は、手法を決める前に、誰が要件や優先順位を判断するかを整理する必要があります。システム全体ではなく、不確実性の高い一部分にアジャイル開発を取り入れる方法も検討できます。
（出典：内閣官房IT総合戦略室「アジャイル開発実践ガイドブック」）

 

アジャイル開発でよくある誤解

IPAの資料では、「「唯一の正しい」アジャイル開発というものはありません。」と述べたうえで、「本質を理解せずに形だけ真似しても成果は創出することはできません。」と注意を促しています。ここでは、よくある4つの誤解と、実際の考え方を紹介します。
（出典：IPA「アジャイル領域へのスキル変革の指針 アジャイル開発の進め方」）

計画を立てなくてよいという誤解

「アジャイル開発は変化に対応する進め方なので、計画はいらない」と考える人がいます。

実際には、計画が不要なのではなく、短いサイクルごとに計画を立て直します。プロダクト全体の目標やリリースの計画と、サイクルごとの計画（スクラムではスプリントプランニング）の両方を持つことが大切です。宣言の「計画に従うことよりも変化への対応を」も、計画の価値を認めたうえで、変化への対応をより重視するという意味です。

計画を立て、状況に合わせて見直し続けることが、アジャイル開発の計画の考え方です。

ドキュメントを作らなくてよいという誤解

宣言の「包括的なドキュメントよりも動くソフトウェアを」という言葉から、ドキュメントは作らなくてよいと考える人もいます。

しかし、宣言はドキュメントの価値も認めたうえで、動くソフトウェアをより重視するという意味です。必要なドキュメントは、目的と読む人に合わせて作ります。たとえば、運用や保守に必要な情報や、チームで共有すべき設計の判断などは、文書として残しておくと後から役立ちます。詳しくは、次の記事で解説しています。

短期間・低コストで開発できるという誤解

アジャイル開発なら、早く安く開発できると考える人もいます。

早く届けられるのは優先度の高い一部の機能であり、プロダクト全体の期間や費用が必ず減るわけではありません。価値の高い機能から順に届けることで、早い段階で効果を得られたり、不要な機能を作らずに済んだりすることはあります。

一方で、短いサイクルでの確認やふりかえりには時間がかかり、顧客側の関与も必要です。コストの削減だけを目的にせず、価値を早く届けるための進め方として捉えましょう。

手法を取り入れれば成果が出るという誤解

スクラムのイベントなど、手法の決まりごとを取り入れれば、それだけで成果が出ると考える場合もあります。

しかし、決まりごとを形だけ行っても、目的や価値を考えなければ成果にはつながりません。たとえば、デイリースクラムが報告するだけの会議になったり、ふりかえりで決めた改善が実行されなかったりする状態です。

迷ったときは、宣言の4つの価値と12の原則に立ち返り、その活動が顧客への価値につながっているかを確かめましょう。

 

アジャイル開発の導入例と公的な取り組み

アジャイル開発は、企業や公的機関でも取り入れられています。ここでは、企業の公式発表と公的機関の公開資料にもとづいて、民間企業の例と、政府の情報システムに向けた取り組みを1つずつ紹介します。

KDDIの取り組み

KDDIは、2013年からアジャイル開発によるサービス開発に取り組んでいることを公表しています。

2022年5月13日のKDDIの発表によると、KDDIは2022年5月12日に、アジャイル開発の事業を担う「KDDIアジャイル開発センター株式会社」を設立しました。

発表では、これまでのアジャイル開発の経験を生かして、法人のお客さまのDXに向けた開発を支援することが示されています。社内で積み重ねたアジャイル開発の取り組みを、専門の会社として事業にした例です。
（出典：KDDI「KDDI Digital Divergence Holdings Launched」）

政府情報システム向けの参考文書の整備

政府でも、情報システムの開発にアジャイル開発を取り入れるための参考文書が整備されています。内閣官房IT総合戦略室は、2021年3月30日に「アジャイル開発実践ガイドブック」を決定しました。

現在、このガイドブックは、デジタル庁の「デジタル社会推進標準ガイドライン」に「DS-121」として掲載されており、参考とするドキュメント（Informative）に位置づけられています。

ガイドブック自体にも「アジャイル開発への理解を深めるための参考文書であり、遵守を求めるものではありません。」と書かれています。アジャイル開発の考え方や進め方を学ぶ資料としても、無料で読むことができます。
（出典：デジタル庁「デジタル社会推進標準ガイドライン」／内閣官房IT総合戦略室「アジャイル開発実践ガイドブック」）

 

アジャイル開発のプロジェクト管理ならLychee Redmine

当社が提供するLychee Redmineでは、Neoバックログ・Neoカンバンを使って、アジャイル開発の計画と実行を管理できます。デメリットの章で触れた「全体の進み具合が見えにくい」という課題にも、計画と進み具合をチームで共有することで対応しやすくなります。

Neoバックログでスプリントの計画を立てる

Neoバックログでは、バックログの並び順を変更すると、チームの実績にもとづいてスプリントへの割り当てが自動で再計算されます。計算には、1スプリントで消化できるポイントの目安を示す「ベロシティ」を用います。

計算結果は、計画を検討するための目安です。実際に取り組む項目は、スプリントゴールや今回の稼働状況を踏まえ、プロダクトオーナーと相談しながら開発者が選びます。

スプリントゴールは画面の上部に常に表示されるため、チームが目標を意識しながら作業を進められます。リリースラインごとにチケットを管理でき、期日に間に合わないチケットはアラートで知らせます。

Neoバックログは、スタンダード・プレミアム・ビジネスの各プランで利用できます。

Neoカンバンでスプリント中の進み具合を共有する

Neoカンバンは、Neoバックログと同じスプリント・同じチケットのデータを共有します。計画はNeoバックログ、日々の実行はNeoカンバン、という形で使い分けられます。

プロダクトバックログの各項目（PBI）を表す親チケットごとに、子タスクをまとめて表示できます。デイリースクラムでは、開発者が同じ画面を見ながら、スプリントゴールへの進み具合を確認し、必要に応じて計画を調整できます。

タスクはドラッグ＆ドロップで状態を更新でき、チーム単位で絞り込んで表示することもできます。複数のチームが関わるプロジェクトでも、自分たちの作業に集中して確認できます。
（出典：Lychee Redmine「Neoバックログ」／Lychee Redmine「Neoカンバン」）

ガントチャートのプロジェクトと同じ環境で管理できる

Lychee Redmineでは、ガントチャートを使うプロジェクトとNeoバックログを使うプロジェクトを、同じ環境で管理できます。そのため、ウォーターフォール開発のプロジェクトを続けながら、一部のチームからアジャイル開発を始めることもできます。

なお、Neoバックログが有効なプロジェクトでは、スプリント期間でチケットを絞り込んでガントチャートで確認する機能もあります。ただし、併用はスケジュールの二重管理につながりやすいため、日常的な運用には推奨されていません。

上長やクライアントにスケジュールの根拠を示す必要がある場合など、やむを得ない場面に限って使いましょう。
（出典：Lychee Redmine「リリースノート Lychee Agile」）

また、企業のアジャイル開発の導入と定着を支援するコーチングサービスも提供しています。Neoバックログの詳細は、次のページをご覧ください。

 

アジャイル開発に関するよくある質問

最後に、アジャイル開発についてよくある質問に回答します。本文で扱いきれなかった、スクラムとの違いやスプリントの期間、ソフトウェア開発以外での使い方など、用語と適用範囲についての疑問を取り上げました。

アジャイル開発とスクラム開発は何が違いますか？

アジャイル開発は、アジャイルソフトウェア開発宣言の価値と原則にもとづく、開発の考え方の総称です。スクラムは、その考え方を実践するための枠組みの一つです。

比べる対象ではなく、アジャイル開発の中にスクラムが含まれる関係で、スクラムで進める開発はアジャイル開発の一種といえます。カンバンやXPで進める開発も、同じくアジャイル開発に含まれます。

詳しくは、本記事の「アジャイル開発とスクラムの関係」の章と、次の記事をご覧ください。

イテレーションとスプリントは何が違いますか？

どちらも、開発を繰り返す短い期間の区切りを指す言葉です。イテレーションは「反復」という意味の一般的な呼び方で、XPなどの手法でも使われます。

スプリントは、スクラムでの呼び方です。スクラムでは、スプリントは1か月以内の決まった長さで、その中でスプリントプランニングからスプリントレトロスペクティブまでを行うとスクラムガイドで定められています。

基本的な考え方は同じで、手法によって呼び方と決まりごとが異なると理解するとよいでしょう。

1回のスプリントはどのくらいの期間ですか？

スクラムガイドでは、スプリントは1か月以内の決まった長さとされています。IPAの資料では、1〜4週間の時間枠と説明されています。

どの長さにするかは、チームとプロダクトの状況に合わせて決めます。期間が短いほど、成果を確かめて方向を修正する機会が増えます。一方で、計画やふりかえりの回数も増えるため、チームの負担とのバランスを見て決めましょう。

一度決めた長さは、スプリントごとに変えず、一定に保つのが基本です。

アジャイル開発はソフトウェア開発以外でも使えますか？

アジャイルソフトウェア開発宣言は、名前のとおりソフトウェア開発を対象にまとめられたものです。

ただし、短い期間で計画・実行・ふりかえりを繰り返し、結果をもとに進め方を改善する考え方は、ソフトウェア開発以外の仕事にも取り入れる例があります。たとえば、マーケティングの施策や社内の業務改善のプロジェクトなどです。取り入れる場合も、目的と成果を確かめる場を設け、形だけにならないようにすることが大切です。

まずは小さな取り組みで試し、ふりかえりながら自分たちの仕事に合う形に調整しましょう。

 

まとめ：アジャイル開発の考え方を理解し、自社のプロジェクトに合う進め方を選ぼう

アジャイル開発は、短い期間で開発と確認を繰り返し、顧客に価値のあるソフトウェアを早く継続的に届けるための考え方です。特定の手法の名前ではなく、スクラム・カンバン・XPなどは、その考え方を実践するための手法にあたります。

ウォーターフォール開発とどちらが優れているかではなく、要件の決まり具合や顧客の関わり方など、プロジェクトの条件に合わせて進め方を選ぶことが大切です。アジャイル開発を取り入れる場合は、小さな範囲から始め、ふりかえりを通じて自分たちに合う進め方へ改善していきましょう。

アジャイル開発の計画と進み具合を管理するなら、当社が提供するLychee Redmineもおすすめです。Neoバックログ・Neoカンバンを30日間の無料トライアルでお試しいただけます。