アジャイル開発とは？手法5つ・進め方とウォーターフォールとの違い

学生のころ、友人とレポートを分担したことがあります。前半を私、後半を友人。 話は5分で決まりました。

提出の前夜に突き合わせたら、真ん中の章が2つありました。

私は「前半に入る」と思って書き、友人は「後半に入る」と思って書いていた。中身はほとんど同じで、参考文献まで一致していました。

分担が失敗した理由は、境界を決めなかったからではありません。お互い、自分の担当だと信じていたからです。 疑う理由がどこにもなかった。

先に一行だけ置きます。アジャイル開発とは、短いサイクルで動くものを出し、それを見ながら次を決めていく進め方のことです。最初に全部決めて順番に作るウォーターフォールに対して、途中で変わることを前提にします。

題材は、ホテル向けのゲストサービス基盤です。滞在客が自分の端末から手続きをして、通知を受け取る。小さなアプリが複数ぶら下がっている構成です。

前置きはさておき、本題に入ります。

今日は、この開発にAIを入れて並行度を上げた結果、何が起きたかという話をしていこうと思います。

① 教科書どおりに、短いサイクルで並行させる

先に、アジャイル開発を教科書どおりに整理しておきます。何を指す言葉なのか、どの手法があり、どう進め、どこで失敗するのか。

アジャイル開発とは

アジャイル開発とは、短い期間の開発を繰り返しながら、動くものを少しずつ増やしていく開発の進め方です。「アジャイル（agile）」は「機敏な」という意味の英語です。

「速く作る方法」だと理解すると、外れます。狙っているのは速さではなく、間違っていたと分かるまでの時間を短くすることです。この違いが、後のデメリットの読み方を変えます。

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

2001年に技術者たちがまとめた文書が出発点です。次の4つを「左より右を重んじる」形で置いています。

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

左側を捨てる宣言ではありません。原文には「左にあることがらに価値があることを認めながらも」と書かれています。ドキュメントを書かない口実として引用されることが多いのですが、それは読み違いです。

アジャイル開発が生まれた背景と歴史

作る前に仕様を全部決める進め方では、決めた時点と作り終えた時点で、前提が変わってしまう案件が増えました。

とくに、利用者の反応を見ないと正解が決まらない領域——業務システムより、顧客が直接使うサービス——で、先に決め切れないことが前提になりました。この必要から、反復して作る進め方が広がっています。

ウォーターフォール開発との違い

	ウォーターフォール	アジャイル
進み方	要件→設計→実装→テストを順に1度だけ	短い周期で、全工程を繰り返す
仕様	最初に確定させる	進めながら決める
動くものが出る時期	終盤	最初の数週間で出る
変更への対応	追加見積もりになる	次の周期に入れる
向いている条件	作るものが確定している	作りながら決める必要がある
弱いところ	途中で変えられない	全体像と総額が見えにくい

優劣ではなく、前提の違いです。法令対応のように仕様が外から決まっている案件では、ウォーターフォールのほうが安く速く終わります。

なぜアジャイル開発が必要とされるのか

• 変化の速い市場に対応するため — 決めた前提が、作り終える前に変わる
• 顧客価値を早く届けるため — 一部でも先に出せば、そのぶん早く使ってもらえる
• 手戻りを小さくするため — 間違いに気づく時期が早いほど、直す量が少なくて済む

3つ目が本質です。短い周期で回すのは、速く作るためではなく、間違いを早く見つけるためです。

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

手法	中心にあるもの	向いている状況
スクラム	役割・会議・成果物の型が決まっている	最も広く使われている。まず選ぶならこれ
XP（エクストリーム・プログラミング）	ペア作業、テスト駆動、頻繁な統合といった技術の実践	技術面の品質を上げたい
FDD（ユーザー機能駆動開発）	機能の一覧を作り、機能単位で進める	機能が数え上げられる
LSD（リーンソフトウェア開発）	ムダの排除。製造業の考え方をソフトへ持ち込む	流れの詰まりを直したい
カンバン	作業を見える化し、同時に進める数を制限する	運用や保守のように、依頼が随時来る

最後の1行が実務では効きます。スクラムは期間を区切る前提なので、割り込みが多い運用の仕事には合いません。その場合はカンバンのほうが素直に回ります。

スクラムの進め方｜イベントと成果物

スクラムでは、決まった長さの期間（スプリント）を繰り返します。

	何をするか
スプリントプランニング	その期間に何を作るかを決める
デイリースクラム	毎日短く集まり、進み方と詰まりを共有する
スプリントレビュー	動くものを見せて、意見をもらう
レトロスペクティブ（振り返り）	進め方そのものを見直す

成果物としては、プロダクトバックログ（作りたいことを並べた優先順位つきの一覧）と、スプリントバックログ（その期間に取り組む分）を持ちます。

4つのうち省かれやすいのはレトロスペクティブです。ここを省くと、同じ詰まり方を毎回繰り返すことになります。

アジャイル開発の用語｜押さえておく4つ

• ユーザーストーリー — 「誰が、何をしたくて、なぜ」の形で書いた要求の単位
• イテレーション（スプリント） — 繰り返す1周期。1〜4週間が一般的
• ベロシティ — 1周期で処理できる量。実績から測る
• リリース計画 — どの機能を、どの周期で出すかの見取り図

ベロシティは、目標ではなく計測値です。上げることを目標にすると、見積もりの数字が膨らむだけで、実際の量は変わりません。

アジャイル開発の進め方｜5ステップ

	やること	決めるもの
1	取り組むテーマ（範囲）を決める	ゴールと、含まないもの
2	チームを組む	役割と、決められる人
3	リリース計画と全体スケジュールを作る	イテレーションの長さ、ベロシティ、優先順位
4	イテレーションを回す	各周期で出す動くもの
5	次に取り組むテーマを検討する	続けるか、変えるか

1の「含まないもの」が抜けると、範囲が毎周期ふくらみます。アジャイルは変更を受け入れる進め方ですが、受け入れる代わりに、何かを外す判断がセットです。

リリース計画で決めること

• プロジェクトのゴール（何が達成されたら終わりか）
• イテレーションの長さ（1〜4週間。途中で変えない）
• ベロシティの見立て（最初は仮置きし、実績で補正する）
• ユーザーストーリーの優先順位と、おおよその工数

優先順位は、価値の大きさではなく「先に確かめたいこと」で付けてください。不確かなものを後回しにすると、いちばん危険な部分が終盤に残ります。

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

• リリースまでの時間を短縮しやすい — 全部そろう前に、一部を出せる
• 仕様変更に柔軟に対応しやすい — 次の周期に入れればよく、契約の作り直しにならない
• 顧客ニーズを反映しやすい — 動くものを見せて意見をもらう場が、毎周期ある
• 修正にかかるコストが少ない — 間違いに気づく時期が早く、直す量が小さい

4つとも、同じ1つの性質から来ています。周期が短いことです。周期を長くすると、メリットは4つとも同時に薄れます。

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

デメリット	何が起きるか	手当て
全体像を把握しにくい	最終的に何ができるのかが見えない	リリース計画で見取り図を持つ
スケジュールの管理が難しい	終わりの時期と総額が読めない	期間と予算を先に固定し、範囲のほうを動かす
開発コンセプトがぶれやすい	毎周期の要望に流され、方向が変わる	ゴールと「含まないもの」を文書で持つ
コミュニケーションのコストが大きい	会議が増え、開発の時間が減る	会議の目的と時間の上限を決める

2行目の手当てが、発注する側にとっていちばん重要です。「いつ、いくらで、何ができるか」を全部固定することはできません。期間と予算を固定し、その中で作るものを選び直す形にすると、社内の承認も通ります。

アジャイル開発が向いているケース・向いていないケース

	向いている	向いていない
仕様	作りながら決める必要がある	外から確定して与えられる
利用者	反応を見ないと正解が決まらない	要件が法令や規程で決まる
発注側の関与	毎周期、見て決められる人がいる	担当が会議に出られない
契約	準委任で、期間に対して支払える	請負で総額を先に確定したい
規模	小〜中。1チームで見渡せる	多数のチームが同時に動く大規模

3行目を満たせない案件では、採用しないでください。発注側が毎周期の判断に加われないアジャイルは、仕様が決まらないまま作り続ける状態になります。

アジャイル開発が失敗する3つのケース

失敗	現れ方	手当て
コミュニケーションが活性化していない	毎日の共有が報告会になり、詰まりが表に出ない	「困っていること」を先に話す順番にする
リーダーの役割が機能していない	優先順位が決まらず、全部が同時に進む	決める人を1人にする
発注者が積極的でない	レビューに出てこず、終盤にまとめて指摘が来る	参加を契約上の前提として明記する

3つとも、技術ではなく体制の問題です。手法をスクラムからカンバンに替えても、この3つは1つも解決しません。

アジャイル開発を成功させるポイント

• 進め方を定義し、プロセスを見直し、定着させる — 型を持たずに「柔軟に」やると、ただの無計画になる
• 品質とチームの状況を可視化する — 不具合の数、処理した量、詰まっている箇所を数字で見る
• 1周期の長さを変えない — 比べられなくなる
• 振り返りを省かない — 進め方そのものを直す唯一の場

2つ目に補足します。見るべきなのは進捗率ではなく、「完了」と判定された単位の数です。進捗率は、判断する人によって動きます。

アジャイル開発で使うツール

• バックログ・タスク管理 — 優先順位と担当を1か所で持つ
• ソース管理と自動テスト — 短い周期で壊れていないかを確かめる
• チャットとビデオ会議 — 短く頻繁なやりとりを支える
• ドキュメント共有 — 決まったことを、探せる場所に置く

2つ目が無いまま周期を短くすると、確認の作業だけが増えていきます。自動で確かめる仕組みは、アジャイルの前提条件に近いものです。

アジャイル開発のよくある質問

Q. アジャイル開発とウォーターフォール開発の違いは何ですか。
ウォーターフォールは要件から順に1度だけ進み、仕様を最初に確定させます。アジャイルは短い周期で全工程を繰り返し、進めながら決めます。優劣ではなく前提の違いで、仕様が外から確定している案件ではウォーターフォールのほうが安く速く終わります。

Q. アジャイル開発にはどんな手法がありますか。
スクラム、XP（エクストリーム・プログラミング）、FDD（ユーザー機能駆動開発）、LSD（リーンソフトウェア開発）、カンバンの5つが代表的です。まず選ぶならスクラムですが、割り込みが多い運用の仕事にはカンバンのほうが合います。

Q. アジャイル開発のデメリットは何ですか。
全体像を把握しにくい、スケジュールの管理が難しい、コンセプトがぶれやすい、コミュニケーションのコストが大きい、の4つです。発注する側の手当てとしては、期間と予算を先に固定し、範囲のほうを動かす形にすると通しやすくなります。

Q. アジャイル開発は、どんなプロジェクトに向いていますか。
作りながら決める必要があり、利用者の反応を見ないと正解が決まらない案件です。ただし条件が1つあり、発注側に、毎周期見て決められる人がいること。これを満たせない場合は、採用しないでください。

Q. アジャイル開発が失敗するのは、なぜですか。
コミュニケーションが活性化していない、リーダーの役割が機能していない、発注者が積極的でない、の3つが典型です。3つとも技術ではなく体制の問題で、手法を替えても解決しません。

Q. イテレーション（スプリント）の長さは、どう決めますか。
1〜4週間が一般的です。重要なのは長さそのものより、途中で変えないことです。長さが変わると、周期ごとの処理量（ベロシティ）を比べられなくなります。

アジャイルの教科書どおりに進めました。短く区切って、動くものを出し、見ながら次を決める。

そこにAIを入れると、サイクルはさらに短くなります。そして、並行させられるようになりました。

→ 人がブランチを切って、片方の機能を進める
→ AIが別のブランチで、別の機能を進める
→ できたものから順にマージする

きれいに回りました。 作業が重ならないようにブランチを分けているので、衝突も起きません。

ここまでは、教科書どおりです。
この時点の体制を数字で置いておきます。同時に走るブランチが2本、ぶら下がるアプリが5つ、1サイクルは3日。 マージは週に2回でした。

指標	導入前	並行後
同時進行のブランチ	1本	2本
1サイクル	10日	3日
週あたりのマージ	1回	2回

ここまでが、アジャイル開発の教科書どおりの整理です。短い周期で回し、動くものを見せ、優先順位を組み替える。手法も、用語も、失敗のパターンも、ここに出そろっています。

この記事の後半で扱うのは、その先です。短い周期を、さらに並行させたとき、「いま何が正しい状態なのか」はどこにあることになるのか。

② そのとおりに進めて、通知が2回届く

本番で、プッシュ通知が2回届くようになりました。

しかも1つのアプリではありません。ぶら下がっている5つのアプリ、全部でです。

引き継ぎ資料に、こう残っています。

「item 15 (order-placed push) was built TWICE」

注文完了の通知が、2回実装されていました。

人のブランチとAIのブランチが、同じ通知機能を、それぞれ独立に作っていたのです。

そして、ここに核心があります。

関数名は、5つとも完全に一致していました。

違っていたのは、トリガの名前にアンダースコアが1つ入っているかどうかだけでした。

③ そして、Gitがコンフリクトしていないと気づく

Gitは、何も警告していませんでした。

ファイル名が違い、トリガ名も一文字違うので、衝突として検出されないからです。

つまり、こうなっていました。

→ バージョン管理はきれいなまま
→ レビューも通っている
→ 本番だけが壊れている

対処として、一度はマイグレーションのファイルを削除しています。ところが、その削除に付けられたコメントが、この記事の核心です。

「v2はマイグレーションファイルを削除しただけ。既に適用済みのDBには何の効果もない。古いトリガが新しいトリガと並存し、注文INSERTごとに両方が発火して、5つのミニアプリ全部でプッシュが2回届く」

ファイルを消しても、データベースからは消えません。

④ 原因は「作業単位」と「真の状態」がずれていたこと

原因を一つに絞ると、これでした。

AIの作業単位はリポジトリです。しかし、システムの真の状態はデプロイ済みのデータベースにあります。

エージェントは、ファイルを削除すれば機能が取り消されると推論します。 これはコードについては正しい。ところがデータベースの定義は、一度適用されたら、ファイルの有無とは無関係に残り続けます。

そして、これはAI特有の誤りではありません。人も同じように間違えます。 ただ、並行度が上がったぶん、間違いが本番に届く速度だけが上がりました。
数え直すと、こうなっていました。同じ責務の関数が5つ、トリガが2つ、発火が1注文あたり2回。 影響したアプリは5つ全部です。

⑤ 直してみる — 消すものと、残すものを分ける

やったことは3つです。

1. トリガだけを落として、関数は残した。
二重に発火していたのはトリガです。関数そのものは片方が使われている。全部消すのではなく、発火の口だけを閉じました。 外科的な判断です。

2. ガードレールを、コードレビューから移した。
レビューでは見つかりません。ファイル名も定義名も違うからです。 見るべきなのは、適用済みの定義と、いま書かれている定義の差分でした。

3. 二重実装のうち、AI側を採用した。
人が書いた側を捨てています。理由は、AI版のほうが考慮が多かったからです。

→ 表示言語の解決が入っていた
→ 初期ステータスの制御が入っていた
→ 例外を包んで、決済のロールバックを防ぐ処理が入っていた

書いた主体ではなく、含まれている考慮の数で決めました。
判断に使った表がこれです。

観点	人が書いた版	AIが書いた版
表示言語の解決	無し	有り
初期ステータスの制御	無し	有り
決済ロールバックの防止	無し	有り
採否	破棄	採用

運用の側でも、同じ考えの線が引かれていました。社内の質問に対する回答にこうあります。「productionに移行するまでにソースレビューをしたり、ProductionのDBマイグレが破壊的なのでアクセス権を切り替えてDBマイグレをする人を限定しています」。

ところで、ここで限定しているのはコードを書く人ではありません。定義を適用する人です。コードは誰が書いてもよく、適用だけを絞る。 この記事の事故は、まさに適用の側で起きました。

⑥ あとで知った — 25年前の宣言に、答えが書いてあった

素朴な対処のつもりでしたが、調べると同じことを指す一文は、すでにありました。

アジャイルソフトウェア開発宣言は、2001年2月11日から13日、ユタ州スノーバードのロッジに集まった17人の開発者によって書かれています。ケント・ベック、マーティン・ファウラー、ロバート・C・マーティンといった面々です。

そこにまとめられたのは、4つの価値と12の原則でした。有名なのは価値のほうです。

「包括的なドキュメントよりも、動くソフトウェアを」

私たちが速くしていたのは、まさにこの方向でした。ドキュメントを飛ばして、動くものを出す。AIを入れて、さらに速くする。

ところが、12の原則のほうにこう書かれています。

「技術的卓越性と優れた設計に対する不断の注意が、機敏さを高める」

機敏さは、設計への注意の結果として得られる、と書かれているのです。注意を省いた先にあるものではない。

私たちは、速くするために注意を省き、その結果として機敏さを失っていました。 通知が2回届く状態は、機敏でも何でもありません。

25年前の宣言に、順序が書いてありました。

新しい理屈は、ひとつも要りませんでした。
ところで、宣言の12の原則には他にも効く一文があります。「動くソフトウェアこそが進捗の最も重要な尺度です」「シンプルさが本質です」。ただ、私たちが飛ばしていたのは「技術的卓越性への不断の注意」の1件だけでした。とはいえ、飛ばした1件が全部を持っていきました。

あとで知った — この現象には、名前と論文が付いていた

適用済みの定義とリポジトリがずれる、という話を現場の勘で扱っていました。この現象には、すでに名前が付いています。

スキーマドリフトです。そして2026年、PingCAP の研究チームが TINE（TiDB Iterative Non-Destructive Environment for Agentic App Building） という論文で、これを正面から扱っています。データベース分野の国際会議 SIGMOD の2026年 Companion に採択されました。

論文の指摘が、こちらの実感より一段厳しい。エージェントが移行処理を生成して実行し、その途中で実行時エラーに当たると、データベースは「元の定義でも、新しい定義でもない状態」で残ります。

壊れるのは、2つの変更が噛み合わないときだけではありません。1つの変更が途中で止まっただけでも、そうなります。

対処として論文が採る形が、命令ごとに分岐を切る設計です。次の版は、前の版のデータベース分岐のコピーオンライトの複製を出発点として受け取ります。移行が失敗しても、失敗はその分岐の中に閉じ込められます。

運用側の対処としては、2026年時点でこう整理されています。

“`

1. エージェントごとに作業場を分ける（git の worktree 単位で隔離する）
2. 共有の定義変更は、担当を1名に固定する（移行の所有者を決める）
3. あるいは、各エージェントが自分の表しか触らないように仕事を割る

“`

2件目が要点です。 定義の変更だけは並行させない。並行度を上げる対象と、上げてはいけない対象を分けるという線の引き方で、これはコードレビューの強化では出てこない発想でした。

⑦ 何が変わったか

レビューする対象が変わりました。

“`
前：コードの差分を見る → ファイル名が違えば衝突に見えない
後：適用済みの定義との差分を見る → 名前が違っても重複が見える
“`

「Gitがきれいなら安全」という前提を捨てたことが、いちばん大きい変化です。
見る対象を変えてから、同種の重複は0件です。ただし観測期間はまだ3か月なので、断言はしません。

⑧ 現場で使うなら、この2枚

表1：並行させる前に決めること

決めること	決めないと何が起きるか
機能の境界（名前ではなく責務で）	同じものが二度作られる
データ定義を触ってよいブランチ	適用済みの定義が並存する
削除の意味（ファイルか、適用済みか）	消したつもりが消えていない
二重実装が出たときの採否基準	書いた人で決めてしまう

表2：Gitで見つからない衝突の探し方

見るもの	方法	見つかるもの
適用済みの定義一覧	本番から取得して比較	名前違いの重複
発火する口の数	トリガ・フックを数える	二重発火
同一イベントの購読者	購読側を列挙	通知の重複

「ファイルを消したから大丈夫」を、この表で置き換えてください。

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「コンフリクトしない衝突がある」。 バージョン管理が何も警告しないまま、2件の変更が本番で噛み合わなくなります。並行度を上げた日から出ました。

2件目、「システムの真の状態は、適用済みDDLにある」。 リポジトリの中身ではありません。両者がずれた瞬間、レビューは実態を見ていないことになります。

3件目、「ファイルを消しても、定義は消えない」。 削除したのは手順書であって、適用済みの定義そのものではありません。ここを取り違えると、消したつもりの列が残ります。

4件目、「レビュー対象は、コードからスキーマへ移す」。 並行度が上がるほど、事故はコードの外で起きます。見る場所を移さないまま人数だけ増やすと、見落としが増えます。

5件目、「並行度を上げる前に、差分検証を置く」。 適用済みDDLとの突き合わせを自動化してから、同時に走らせる本数を増やします。順番を逆にすると、戻すのに数日かかります。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

並行度は、これからも上がります。そして、上がるほどコンフリクトしない衝突が増えます。 これは技術の進歩で解決しません。Gitが見ているものと、本番が持っているものが違う、という構造だからです。

→ 並行度が上がる → 同じ責務に別の名前が付く
→ 名前が違う → Gitは衝突を検出しない
→ 検出されない → レビューも通る
→ だから、本番だけが壊れる
検知にかかった時間も残しておきます。二重発火が始まってから気づくまで6日、原因の特定に2時間、修正そのものは15分でした。見つけるまでが、直すまでの24倍かかっています。

アジャイル開発にAIを入れるとき、増やすべきはレビューの回数ではありません。レビューの対象を、コードから適用済みの定義へ移すことです。

ただし、正直に書いておきます。この差分検証は、まだきれいに自動化できていません。 適用済みの定義を取ってきて比較する仕組みは作れますが、「これは重複か、意図的な並存か」の判断は人が見ています。そこを機械に渡す方法は、まだ持っていません。

ところで、事故のあと引き継ぎ資料に書き足した一文が「ファイルの削除は、適用済みの定義を取り消さない」です。ただ、この一文を読む人がいるかは分かりません。

関連して、内製化しても意思決定は速くならない話と、PoCでは出ない最後の0.1%話を別に書いています。AI時代の要件定義話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIプロダクト開発のページに整理しています。

---

並行作業といえば、洗濯機を回しながら料理をして、両方を焦がしたことがあります。

洗濯物は焦げないはずなんですが、乾燥までかけたまま忘れるという形で、ちゃんと焦げました。

以上です。