アジャイル開発とは短い期間で「動くもの」を作っては確かめ、変更を受け入れながら進める開発の進め方の総称。出発点は2001年のアジャイルソフトウェア開発宣言で、代表的なやり方がスクラム（1か月以内のスプリントを繰り返す）。ウォーターフォールとの違いの表と、向き・不向きを公式資料の原文で確かめた【2026年10月版】

2026年10月13日・日本時間時点の情報です。 アジャイル開発（agile development）とは、ソフトウェアを一度に作り切らず、短い期間で少しずつ作って「動くもの」を確かめ、その結果を次の作業に生かしながら進める開発の進め方の総称です。内閣官房のガイドブックは、反復する期間を1か月以下を基準として検討することが多いと書いています。代表的なやり方のスクラムは無料で、スクラムガイドは「スクラムは無料であり、本ガイドで提供されるものである」と書いています。ただしIPA（情報処理推進機構）は、要件を曖昧にしたままでも必要な機能がすぐできる「魔法の杖」のように思われているなら改めるべきだと書き、頼む側にも深い関わりを求めています。

3行まとめ

1. アジャイル開発は、短い反復で動くものを作って確かめる進め方の総称。出発点は2001年2月の「アジャイルソフトウェア開発宣言」（署名者17人・4つの価値と12の原則）で、内閣官房のガイドブックは反復する期間を1か月以下を基準として検討することが多いと書く。
2. 代表的なやり方のスクラムは、1か月以内の決まった長さの「スプリント」を繰り返す。ガイドが「3 つの明確な責任」と呼ぶプロダクトオーナー・開発者・スクラムマスターが、プロダクトバックログ（作りたいものの一覧）を使って進める（スクラムガイド2020年11月版）。
3. ウォーターフォールの代わりではなく、向き不向きがある。内閣官房のガイドブックは、全容が明らかになっていない領域が向き、詳細が定まっている領域は不向き、大規模・極めて複雑・ミッションクリティカルな領域は慎重な判断が必要と書く（2021年の政府情報システム向けの文書）。

この記事は、アジャイルを初めて検索した人に向けて、意味・宣言の中身・ウォーターフォールとの違い・スクラム（スプリントを含む）・向き不向きを、公式ページとIPA・内閣官房の文書の原文で確かめながら書いています。プログラミングそのものはコーディングとは、AIにコードを書かせる話はバイブコーディングとはに送り、ここでは「開発の進め方」に絞ります。

アジャイルの意味は「俊敏」。ソフトウェアの話になったのは2001年の宣言から

英語の agile は形容詞です。デジタル大辞泉（コトバンク掲載）は「アジャイル(agile) [名・形動]俊敏であるさま。機敏な。敏捷な。」と載せています。Cambridge Dictionary は、仕事の進め方を表す使い方（MANAGEMENT）を次のように説明し、発音は英国式 /ˈædʒ.aɪl/、米国式 /ˈædʒ.əl/ と載せています。

「used for describing ways of planning and doing work in which it is understood that making changes as they are needed is an important part of the job」

（訳：必要に応じて変更を加えることが仕事の大事な一部だと理解されている、計画と仕事の進め方を表す語）

ソフトウェアの進め方を「アジャイル」と呼ぶようになったのは、2001年からです。宣言の公式サイトの沿革ページによると、2001年2月11日〜13日、米国ユタ州のスキー場にある The Lodge at Snowbird に17人が集まり、Extreme Programming・SCRUM・DSDM などの代表と、「an alternative to documentation driven, heavyweight software development processes」（訳：ドキュメント主導で重量級のソフトウェア開発プロセスに代わるものの必要性）に共感する人たちが議論して、宣言ができたと書かれています。署名者には、後で出てくるスクラムガイドの著者 Ken Schwaber と Jeff Sutherland も入っています。

個々の手法は宣言より前からありました。沿革ページによると、2000年に書かれたいくつかの記事は、こうした手法を「Light methodologies, such as Extreme Programming, Adaptive Software Development, Crystal, and SCRUM」（訳：Extreme Programming、Adaptive Software Development、Crystal、SCRUM のような軽量の方法論）と呼んでいました。スクラムガイドの日本語版も「我々は 1990 年代初頭にスクラムを開発した。」と書いています。

内閣官房の「アジャイル開発実践ガイドブック」（2021年3月30日）は、この言葉を「アジャイルとは、元来は特定の開発プロセスを指すものではなく、より良い開発のあり方を追求する態度のことを指しています。」と書いています。特定の手順書の名前ではなく、考え方の名前です。

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

agilemanifesto.org の日本語版は、4つの価値を次のように書いています。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

同じサイトの英語版は次のとおりです（訳は上の日本語版。日本語版の末尾に「Japanese translation by Kenji Hiranabe」と書かれています）。

「Individuals and interactions over processes and tools」 「Working software over comprehensive documentation」 「Customer collaboration over contract negotiation」 「Responding to change over following a plan」 「That is, while there is value in the items on the right, we value the items on the left more.」

日本語版の結びの「左記」「右記」は、どちらがどちらか迷います。IPAの事業ページは同じ文を「各文の前者(「よりも」の前の言葉)に価値があることを認めながらも、私たちは後者(「よりも」の後の言葉)の事柄により価値をおく」と言い換えています。これに従うと、次の表になります。

英語の結びが「while there is value in the items on the right」（右側の項目にも価値はあるが）と書くとおり、宣言はドキュメントや計画を要らないと言っているわけではありません。

宣言には12の原則のページが付属します。日本語版から3つ引きます。

• 「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
• 「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
• 「動くソフトウェアこそが進捗の最も重要な尺度です。」

ウォーターフォール開発との違い。出典の記述を同じ観点で並べた表

内閣官房のガイドブックは、従来の開発スタイルを「システム開発の全体をフェーズで分割定義し、各フェーズが完遂されなければ次のフェーズへと移行できない」ものと説明し、コラムでは「従来の開発スタイル(ウォーターフォール型)」と書いています。IPAの契約書のページは「開発対象全体の要件や仕様を確定してから開発を行うウォーターフォール開発」と書きます。この書き方を、アジャイルについての記述と並べます。

どちらが優れているかは、出典のどれも言い切っていません。IPAの事業ページは「すべてのソフトウェア開発にアジャイル型開発手法を適用できる、あるいはすべきだ、という立場ではありません」と書き、「ウォーターフォール型の開発が適している場面もあれば、アジャイル型の開発が適している場面もあります」と続けます。内閣官房のガイドブックには「混ぜるな危険」というコラムがあり、ウォーターフォールに慣れた人がアジャイルの進捗を心配して報告書の提出などの監視を強めると「アジャイル開発の流れを阻害してしまうことにもつながりかねません」と注意しています。

「アジャイルは計画も要件も決めない」とは、出典は書いていません。IPAのメッセージは次のように書いています。

「アジャイル開発が、要件を曖昧にしたままでも必要な機能がすぐに開発されるというように、あたかもユーザ企業にとっての魔法の杖のように思われているとすれば、そのような考えは改められなければなりません。」

IPAの契約前チェックリストは、「プロジェクトの初期計画が立案されているか」「十分な初期バックログがあるか」を確認項目に挙げます。内閣官房のガイドブックの図は、「全体計画の立案を行わない反復開発」に「政府情報システム開発では採用しない」と書き添えています。

スクラムとは。代表的なやり方の定義を、スクラムガイドの日本語版で確かめる

スクラムガイドは、Ken Schwaber と Jeff Sutherland が書いたスクラムの定義の文書で、scrumguides.org が公開しています。日本語版は、スクラムを次のように定義しています。

「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」

続けて「簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。」として、次の4段階を挙げています。

1. 「プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。」
2. 「スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。」
3. 「スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。」
4. 「繰り返す。」

スクラムとアジャイルの関係は、スクラムガイドの外の文書が書いています。内閣官房のガイドブックは用語表でスクラムを「アジャイル開発の1つとされ、国内外を問わず、適用されていることが多い開発手法」と説明し、IPAのアジャイル開発版モデル契約のページは「アジャイル開発手法としてスクラムを採用しています」と書いています。スクラムガイド自身の本文（日本語版PDFと英語のHTML版）には、筆者が検索したところ「アジャイル」「agile」の語が1回も出ませんでした。2020年版の変更点を書いた改訂履歴のページは、IT の仕事を連想させる語を取り除いたと書き、ガイドの冒頭も、スクラムは「スクラムが誕生したソフトウェアプロダクト開発の領域を超えて」さまざまなドメインで採用されていると書いています。

スプリントとは何か

スプリントは、スクラムが開発を区切る期間の名前です。日本語版の文面は次のとおりです。

「スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。」

「一貫性を保つため、スプリントは 1 か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。」

英語版は「Sprints are the heartbeat of Scrum, where ideas are turned into value.」「They are fixed length events of one month or less to create consistency.」（訳：スプリントはスクラムの心臓の鼓動で、アイデアが価値に変わる場。一貫性のために、1か月以下の決まった長さである）です。プランニングからレトロスペクティブまで、プロダクトゴールの達成に必要な作業は、すべてスプリントの中で行われます。

長さについて、日本語版にも英語版にも「2週間」という数字は出てきません（「週間」「week」で検索して0件）。1週間・2週間・4週間という例は、内閣官房のガイドブックが「反復する期間は、1か月以下(1、2週間、または4週間)を基準として検討することが多く」と書いているものです。途中の変更について、スクラムガイドは「スプリントゴールの達成を危険にさらすような変更はしない」と書く一方、「学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある」とも書いています。

スプリントの中の4つのイベント（会合）と、1か月のスプリントの場合の時間の上限は、日本語版では次のとおりです。

3つの責任（役割）と3つの作成物

日本語版は、スクラムチームを「スクラムマスター1 人、プロダクトオーナー1 人、複数人の開発者で構成される」「スクラムチーム内には、サブチームや階層は存在しない」と説明し、人数は「通常は 10 人以下」です。内閣官房のガイドブックは体制を「役割」と呼び、プロダクトオーナー支援を加えた4つを挙げていますが、2020年版のスクラムガイドの本文は、日本語版の巻末の用語集を除いて役割（role）という語を使わず、「開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する」と書いています（英語版は「Scrum defines three specific accountabilities」）。

内閣官房のガイドブックは、スクラムマスターが従来のプロジェクトマネージャー（PM）と誤解されることが多いと書き、PM は「指揮者・指示者」として上位者の立ち位置から動くのに対し、スクラムマスターは開発チームに対等なスタンスで指示はしない、と区別しています。

文書によって書き方が違う所もあります。デイリースクラムは、スクラムガイド2020年版が進め方を開発者に任せ、2017年版の質問を削除した（改訂履歴のページ）のに対し、内閣官房のガイドブック（2021年）は「昨日実施したこと」「本日実施すること」「直面している問題、懸念点」の3点を確認するとしています。人数も、スクラムチーム全体を「通常は 10 人以下」とするスクラムガイドに対し、内閣官房は開発チームを「7、8名を上限」としており、数える範囲が違います。

アジャイル開発は、どんな仕事に向き、どんな仕事に向かないと書かれているか

本記事が使った資料の中で、向き不向きを一番まとまった形で書いているのは、内閣官房の「アジャイル開発実践ガイドブック」（2021年3月30日初版。PDFの改定履歴では、最後の改定は2021年5月10日）です。同ガイドブックは「適用対象」の節で、政府情報システムの整備を対象とし、「アジャイル開発への理解を深めるための参考文書であり、遵守を求めるものではありません」と書いています。デジタル庁の標準ガイドラインのページ（最終更新日2026年10月6日）では「DS-121 アジャイル開発実践ガイドブック」として、位置づけは Informative（参考とするドキュメント）、「策定日または最終改定日：2021年3月30日」と表示されていました。

ガイドブックの「アジャイル開発に向いている・不向きな領域」の節は、「どのような場合でもアジャイル開発を採用すれば良いというものではありません」と前置きして、3つに分けています。

IPAの事業ページ（2009〜2013年度の事業の成果）にも似た整理があります。ウォーターフォール型は「高信頼性が求められる基幹システム等、過去のほとんどの分野で実績」があるとし、アジャイル型は「情報システムを市場へいち早く提供していくことに価値があると考えられる分野」に向くとします。大規模開発・分散拠点（オフショア含む）開発・組織（会社）間をまたぐ開発・組込みシステム開発は、経験が十分には蓄積されておらず「現在、チャレンジと創意工夫が求められています」と書き、この「現在」は事業が行われた当時のことです。IPAの「アジャイルプロジェクト実践ガイドブック」（Ver1.1。奥付は2023年4月第1刷・2024年5月第2刷）は、古くから稼働している基幹システムの改修について、「変更に対する影響も大きく、技術的な負債も残っていることが多いため、アジャイルの利点を活用しきれない」と書いています。

頼む側の時間も条件として書かれています。内閣官房のガイドブックは、調達仕様書に「開発手法はアジャイル開発を採用すること」と書けば、あとは事業者がうまく進めてくれると考えてはいけないとして、発注者に「日次ないし週数回以上の打ち合わせの時間」を求め、準備できない場合は「成功確率が大きく下がります」と書きます。IPAの契約前チェックリストには、「開発対象プロダクトがアジャイル開発に適しているか」「1チーム(最大で10名程度)の継続的対応にて、開発可能な規模であるか」「適切なプロダクトオーナーを選任し、権限委譲ができるか」が入っています。

これらを自分の仕事に当てはめる問いにすると、次の3つになります。出典の記述を筆者が組み替えたもので、公式の判定表ではありません。

1. 作るものの全容（画面・機能・数字）を、いま言葉にできるか。できて、途中で変わる見込みも小さいなら「不向きな領域」に近く、できないなら「向いている領域」に近い。
2. 作ったものを使う人に触ってもらい、その反応で直せる余地があるか。
3. 頼む側が、週数回以上の打ち合わせと、その場の判断に時間を割けるか。

日本の企業では、アジャイルの原則とアプローチはどれくらい取り入れられているか

IPAの「DX動向2025」（調査期間は2025年2月上旬から3月下旬）は、日米独の企業に「アジャイルの原則とアプローチの取入状況」を尋ねています。日本は「全面的に取り入れている」の回答割合がすべての部門で1割以下で、「一部取り入れている」との合計でも一番進んでいる「IT部門」で5割弱、米国は各部門とも7割前後、ドイツは各部門とも6〜7割程度と、IPAは書いています。IPAは「日本企業は取組むことが望まれる」と結んでいます。この数字は、DXの調査の中で原則とアプローチの取り入れを部門別に尋ねたもので、スクラムを使う開発チームの割合を直接示す数字ではない、と筆者は読んでいます。

次の版の「DX動向2026」（2026年7月30日公開。日本企業が対象の2025年度調査で、調査期間は2026年4月中旬から6月中旬）は、企業文化・風土の1項目として「事業実施に向けてアジャイルのアプローチで遂行している」を尋ねています。図表2-13の回答は「できている」16.4%、「十分ではない」52.3%、「できていない」31.3%（n=1,777）でした。本記事が本文とデータ集の図表の題名を確かめた範囲では、2025年版の「アジャイルの原則とアプローチの取入状況」に当たる部門別の図表は見当たりませんでした。設問も対象国も違うので、2025年版の数字と並べて増えた・減ったとは言えません。

AIでソフトウェアを作る時代に、アジャイルはどうなるのか。出典が言っていることと、言っていないこと

IPAの「AIを用いたソフトウェア開発」のページ（公開日2023年12月20日・最終更新日2026年9月11日。更新履歴によると9月11日の更新は問い合わせ先の変更）は、ソフトウェア開発での主な活用場面として「対話型AIを用いた要件定義」「各種会議の議事録管理」「生成AIによるプログラム開発(コード生成、ペアプログラミング等)」「レビュー」「AIによるテスト、テストデータ作成」を挙げています。AIの使い道の一覧で、アジャイルとウォーターフォールのどちらに向くかは書かれていません。取得したページで「アジャイル」の語が出るのは、案内メニューの「情報システム・モデル取引・契約書(アジャイル開発版)」の1か所だけでした。

アジャイルの側からAIを語った当事者の発表として、Thoughtworks が2026年2月2日付で出した発表があります。宣言の25周年に合わせて、2月1日〜3日にユタ州パークシティで行う「Future of Software Development Retreat」を案内し、宣言の署名者の1人で同社の chief scientist の Martin Fowler の言葉を載せています。

「With this event, we are gathering those who are exploring the change AI brings to the very foundations of how we build software.」

（訳：この催しで、AIがソフトウェアの作り方の土台そのものにもたらす変化を探っている人たちを集める。）

同じ発表には同社の製品（AI/works）の実演も含まれています。集まりの結論は、本記事では確かめていません。

宣言（日英）とスクラムガイド（日英）の本文には、2026年10月13日に筆者が取得した版で、AIに触れた語はありませんでした。「AIでアジャイルの進め方がどう変わるか」への公式な答えは、この記事が使った宣言・スクラムガイド・IPA・内閣官房の資料には見つかっていません。AIにコードを書かせる側はバイブコーディングとは、Anthropicが6段階の開発の流れを説明した公式ブログはAI-Native SDLCとはに書いてあります。そのブログは従来の流れを「Traditionally, each stage is a discrete phase owned by a different role.」（訳：従来は、各段階が、別々の役割が受け持つ独立した局面である）と書きますが、筆者が取得した本文に agile・sprint・scrum・waterfall の語は出てきませんでした。

2026年10月13日の2時台に、宣言とスクラムガイドの公式ページを開くと

筆者は2026年10月13日の2時1分に、宣言（日本語・英語）・12の原則・沿革ページ・スクラムガイドのWeb版を取得し、2時2分に日本語版PDFを取得しました。2時7分から2時8分には、ログインせずに、宣言・スクラムガイドのWeb版・IPAのモデル契約ページ・デジタル庁の標準ガイドラインのページを、画面なしのブラウザで1280×800と390×844の幅で開いて撮影しました。

• 宣言の日本語版には、タイトル、4つの価値、署名者17人の名前、「© 2001, 上記の著者たち」があり、ページ末尾に「Japanese translation by Kenji Hiranabe」とありました。ページの本文に、版数や改訂日の表示は見つかりませんでした（年は2001だけ）。390×844の幅では、宣言の行が「実／践」のように語の途中で折り返されました。
• スクラムガイドのWeb版には見出し「The 2020 Scrum Guide」と「November 2020 version」の文言、ページ末尾に「© 2025 ScrumGuides.org」がありました。2026年10月13日時点で、このサイトが示すスクラムガイドは2020年版です。
• IPAのモデル契約ページには「公開日:2020年3月31日」「最終更新日:2026年9月11日」（更新履歴では、組織改編に伴う問い合わせ先の更新）、デジタル庁のページの表では、アジャイル開発実践ガイドブックの「策定日または最終改定日」は2021年3月30日のままでした。
• スクラムガイドの日本語版と英語版の本文を検索すると、「アジャイル」「agile」「週間」「week」、AIに触れた語は、いずれも0件でした。

実際のチームでの運用と、スクラム以外の手法は確かめていない

• 実際の開発チームでスクラムを回した経験は、筆者にはありません。イベントの運び方や、うまくいかない時の様子は書いていません。
• スクラム以外の手法（宣言の沿革ページが名前を挙げた Extreme Programming など）の中身は、取得していません。
• デジタル庁のページでは DS-100・DS-110・DS-120 の3文書が「策定日または最終改定日：2026年6月12日」と表示されています。そこに含まれるアジャイル関連の記述が変わったかどうかは確かめていません。
• IPAの事業ページの整理は2009〜2013年度の成果で、その後の事例の増減は反映していません。内閣官房のガイドブックの向き不向きは政府情報システムが対象で、民間のアプリ開発や個人の開発にそのまま当てはまるとは、出典は書いていません。
• 本文で使った資料に、同じ条件でアジャイルとウォーターフォールの費用・期間・成功率を比べた数字は、本記事が確認した範囲では見つかりませんでした。「アジャイルのほうが安い・早い」とは、これらの資料からは言えません。

宣言・スクラムガイド・IPA・内閣官房の資料と、取得した時刻

本文で名指しした資料は、すべて記事冒頭の sources に入れています。取得は2026年10月13日（日本時間）の2時1分から2時9分（DX動向2026のデータ集だけは2時25分）で、各資料の取得時刻は sources の各行に書きました。取得したテキストと画面の撮影は、筆者の作業フォルダに保存しています。文書は更新されるので、使う前に各ページの最新の表示を見てください。