イテレーションとは?反復・ループ・スプリントの使い分け【2026年版】分野ごとの意味と発注側が決める3つ

「提案書に『2週間のイテレーションで進めます』と書いてあるが、これは何を指しているのか」——開発を外部に委託しようとしている方から、こうした相談をよく受けます。別の会社の提案書では同じところが「スプリント」になっている。社内のエンジニアに聞くと「ループのことでは」と言われる。機械学習のログにも同じ単語が出てくる。同じ語があちこちで違う顔をしているため、調べても自分の文脈に当たらないのが実情です。

結論から言うと、イテレーションは「反復・繰り返し」を意味する英語で、IT分野では分野ごとに指すものが違う多義語です。プログラミングではループ処理の1周、機械学習では学習の反復回数、ソフトウェア開発では設計から検証までを1回ぶん詰め込んだ開発サイクルを指します。開発の文脈に限れば、イテレーションは反復型開発で広く使われる一般語で、スクラムではこれを「スプリント」と呼びます。ただし、スクラムガイド2020年版に「イテレーション」という名詞は登場しません(2026-09-15確認)。

語の意味がそろえば、提案書の一文は読み解けます。「2週間のイテレーションで進めます」とは、2週間ごとに動くものが出てきて、そのたびに発注側が見て判断を返す、という意味です。裏を返すと、判断を返す人と期限と基準が決まっていなければ、反復は形だけになり、固定費と会議だけが残ります。用語の確認は、発注側の作業を洗い出す作業でもあります。

本記事では、イテレーションの語義と分野ごとの意味、ソフトウェア開発における反復型開発とウォーターフォールとの対比、イテレーションとスプリントの呼び分け、1回の長さの目安と決め方、インクリメンタル開発との違い、外部チームに反復型で任せるときに発注側が決める3つ、よくある質問の順に解説します。呼び分けの根拠は、スクラムガイド、アジャイルソフトウェア開発宣言、IPAの公開資料、XPの原典を直接確認し、確認日を付けて示します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。反復型で始めた案件がうまくいかないときに共通しているのは、たった2つです。この記事を読み終えるころには、目の前の文書に出てくる「イテレーション」がどの意味かを判別でき、外部に任せるときに何を決めればよいかが分かるはずです。

イテレーションとは——「反復」「繰り返し」を意味する英語で、分野ごとに指すものが違う

イテレーション(iteration)は、英語で「反復」「繰り返し」を意味する言葉です。IT分野ではこの語が分野をまたいで使われており、指しているものが文脈ごとに違います。開発計画の話なのか、プログラムの動きの話なのか、学習の回数の話なのかで、まったく別のものを指します。まずは自分が見ている文書がどの文脈かを判別するところから始めてください。

語義: iterate(反復する)の名詞形。日本語では「反復」「繰り返し」

イテレーションは動詞 iterate(反復する、繰り返す)の名詞形です。カタカナでは「イテレーション」、まれに「イタレーション」とも表記されます。日本語の定訳は「反復」「繰り返し」で、IPAの公開資料では「反復（イテレーション）」と併記されています。

注意したいのは、日本語のIT現場でこの語がカタカナのまま輸入され、分野ごとに別の意味を背負ったまま並存している点です。用語が多義的なまま会議で使われると、同じ単語で別のものを話してしまいます。定義をそろえるのは、実は最初にやるべき仕事です。

分野別に何を指すか——一般語、プログラミング、機械学習、デザイン、ソフトウェア開発

同じ「イテレーション」が、分野ごとに何を指すかを一覧にしました。

本記事では、イテレーションを「開発チームが期間を区切って、計画から動くソフトウェアの確認までを一通り行う単位」という意味で使います。上の表の一番下にあたる用法です。同じ語が「プログラムの中で処理を繰り返すこと」を指す場面もありますが、発注の文脈で出てくるのはほぼ前者です。以降、断りがなければ前者の意味で読み進めてください。

プログラミングのイテレーション——ループ処理の1周と「イテレータ」

プログラミングの文脈では、配列やリストなどに対する反復処理、またはその1周をイテレーションと呼びます。この意味で検索した方は、ここまでで目的の答えに届いています。

Python 3の公式ドキュメント用語集は、関連する2語を次のように定義しています。イテラブル(iterable)は「要素を一度に1つずつ返すことができるオブジェクト」で、リストや文字列、タプル、辞書、ファイルオブジェクトなどが該当します。イテレータ(iterator)は「データの流れを表現するオブジェクト」で、__next__() を繰り返し呼ぶと次の要素が返り、要素が尽きると StopIteration を送出します。

ここで押さえておきたいのは、Python公式の用語集に「iteration」という単独の項目は置かれていないことです。反復すること自体は説明の中で使われる普通の英単語であり、特別に定義された専門語ではありません。開発計画の「イテレーション」とは、たまたま同じ語を使っているだけの別物だと考えてください。

機械学習のイテレーション——ライブラリによってエポックを指すこともある

機械学習の学習ログに出てくるイテレーションは、学習を何回繰り返したかを表します。ここが厄介で、同じ iteration という語が、ライブラリによって「1回のパラメータ更新」を指したり「データ全体を1巡すること(エポック)」を指したりします。

たとえば scikit-learn の MLPClassifier は、パラメータ max_iter について「確率的ソルバー(sgd、adam)では、これはエポック数(各データ点が何回使われるか)を決めるものであり、勾配更新の回数ではないことに注意」と明記しています。つまり、同じライブラリの中でもソルバーによって iteration の中身が変わります。

機械学習のログを読むときは、その語がエポックなのかパラメータ更新なのかを、ライブラリのドキュメントで確認してください。ここを取り違えると、学習にかかる時間の見積もりが桁で狂います。ここまでが「同じ語が分野で別のものを指す」という話です。次は、本記事の主題であるソフトウェア開発のイテレーションを見ていきます。

ソフトウェア開発のイテレーション——反復型開発の1サイクルと、ウォーターフォールとの対比

ソフトウェア開発の文脈でイテレーションと言うとき、それは「要求の整理から実装、テストまでを1回ぶん詰め込んだ短い開発サイクル」のことです。このサイクルを何度も回して完成度を上げていく進め方を、反復型開発(イテレーティブ開発)と呼びます。ここが提案書や会議で出てくるイテレーションの正体です。

反復型開発の考え方——要求・開発・テストを1サイクルに詰めて何度も回す

IPAが公開している『ITSS+ アジャイル領域へのスキル変革の指針「アジャイル開発の進め方」』は、アジャイル開発の前提となる流れを「第1反復(要求→開発→テスト)、第2反復、…第n反復」を経て第1リリースに至り、それをリリースの数だけ繰り返す図で示しています。1回の反復の中に、要求・開発・テストが全部入っている点が要点です。

この形にする理由は、途中で方向を変えられるようにするためです。1回ごとに動くものが出るので、発注側はそれを見て「思っていたものと違う」「次はこちらを優先したい」と判断を返せます。反復型の価値は、速く作れることではなく、途中で方向を変えられることにあります。逆に言えば、判断を返す人がいなければ、この形を採る意味は薄れます。

アジャイルソフトウェア開発宣言の背後にある原則も、第3原則で「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」と述べています。短い間隔で動くものを出すこと自体が原則として掲げられているわけです。

ウォーターフォールとの対比——工程を1回ずつ通すか、短いサイクルを何度も回すか

ウォーターフォール開発は、要件定義・設計・実装・テスト・リリースという工程を順番に1回ずつ通します。反復型は、その一連を小さくして何度も回します。発注側から見た違いを整理します。

ウォーターフォールの工程の中身やV字モデルについては「ウォーターフォール開発とは」の記事で詳しく扱っています。また、工程全体の地図は「要件定義とは」の記事が参考になります。

誤解されやすいのは、「反復型なら仕様変更が無料でできる」という点です。反復型でも総量は増えません。優先順位を入れ替えられるだけです。何かを先に入れれば、何かが後ろに下がります。ここを「柔軟だから何でも入る」と受け取ると、失敗のもとです。

1回のイテレーションの中身——何が「終わった」と言える状態か

1回のイテレーションで何をどこまでやるかは、手法によって細かさが違います。共通しているのは、次の4つが1回の中に収まることです。

1. 計画: そのサイクルで何を作るかを決める。全部ではなく、優先順位の上から入るぶんだけ
2. 開発: 設計・実装を行う
3. 検証: テストを行い、動く状態にする
4. 確認: 発注側が見て、判断を返す

問題になりやすいのは4つ目です。「開発は終わったがレビューが2週間後」という状態になると、サイクルは回っているように見えて、実際には判断が1回ぶん遅れ続けます。私が見てきた案件でも、ここが詰まっているケースがいちばん多いです。では、何をもって「終わった」と言えるのでしょうか。その基準を決めるのは開発会社ではなく、発注側の仕事です。この点は最後の章でもう一度扱います。

イテレーションとスプリントの呼び分け——一次情報で確かめた4つの事実

上位の解説記事のほとんどが「スプリントはスクラムで使い、イテレーションはXPで使う」と説明しています。おおむねそのとおりですが、根拠が示されている記事は多くありません。そこで、スクラムガイド、アジャイルソフトウェア開発宣言、XPの原典、IPAの公開資料を直接開いて、それぞれが実際にどの語を使っているかを確認しました。確認日は2026年9月15日です。

スクラムガイド2020年版に「イテレーション」という名詞は出てこない(2026-09-15確認)

スクラムの定義書であるスクラムガイド(2020年11月版)の全文を検索したところ、iterat を含む語は1箇所しかありませんでした。それは「Scrum employs an iterative, incremental approach to optimize predictability and to control risk(スクラムは、予測可能性を最適化しリスクを制御するために、反復的で漸進的なアプローチを採用する)」という一文で、使われているのは形容詞の iterative です。名詞の iteration は1度も出てきません。

代わりにスクラムガイドが定義しているのが Sprint です。「Sprints are the heartbeat of Scrum(スプリントはスクラムの心臓の鼓動である)」とし、「They are fixed length events of one month or less to create consistency(一貫性を生むための、1か月以内の固定長のイベントである)」と定義しています。

つまり、スクラムを名乗る場では「スプリント」が正式な語であり、イテレーションはスクラムの用語ではありません。スクラムの3つの責任・5つのイベント・3つの作成物といった中身については、「スクラムとは」の記事で扱っています。本記事ではこれ以上踏み込みません。

アジャイルソフトウェア開発宣言の12原則にも出てこない(2026-09-15確認)

「アジャイル開発ではイテレーションと呼ぶ」と書かれた記事は多いのですが、アジャイルソフトウェア開発宣言と、その背後にある12の原則には、iteration も iterative も1度も登場しません(英語版・日本語版とも確認)。

原則が述べているのは、先に引用した「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」という一文と、「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」という一文です。反復の考え方は明確に書かれていますが、それを指す固有名詞は置かれていません。

この事実自体が、読者にとって有用だと考えています。「アジャイル開発の公式な用語だからイテレーションと呼ぶ」という説明は、出典をたどると成り立ちません。

XPは「イテレーション」を正式な語として使う

一方、エクストリームプログラミング(XP)の解説サイト ExtremeProgramming.org は、「Iterative Development」というルールを置き、「開発スケジュールを1〜3週間の長さの12回程度のイテレーションに分割する。1週間が最良の選択である」「プロジェクトを通じてイテレーションの長さは一定に保つ。これがプロジェクトの心臓の鼓動である」と述べています。イテレーション計画ミーティングを各イテレーションの冒頭に置くことも、ルールとして明記されています。

XPの文脈では、イテレーションは定義された正式な語です。「スプリントはスクラム、イテレーションはXP」という一般的な説明は、この対比に基づいています。

呼び分けの早見表と、実務での結論

4つの一次情報を並べると、次のようになります。

IPAの資料は、日本語圏での両語の関係をもっとも端的に説明しています。「スクラムは反復（イテレーション）を繰り返す開発プロセスです。この反復の単位を『スプリント』と呼びます」とあり、スキル項目の一覧では「イテレーション」の別名として「タイムボックス、スプリント、反復」を挙げています。

実務での結論は3つです。第1に、イテレーションは反復型開発全般で使える一般語、スプリントはスクラム固有の語です。第2に、スクラムを採用しているなら、用語はスクラムガイドに合わせてスプリントで統一するのが安全です。第3に、社内と委託先で呼び方が違う場合は、契約前にどちらかへ寄せることです。呼び方が2つあると、議事録と課題管理表で別の単位が並び、後から数え直す羽目になります。用語をそろえるのは、実は最初にやるべき仕事です。

1回のイテレーションはどれくらいか——長さの目安と決め方、インクリメンタル開発との違い

「2週間のイテレーション」と書かれていたとき、その2週間はどこから来た数字なのか。結論から言うと、1〜4週間が標準で、プロジェクトの途中では固定するのが原則です。ただし出典によって表現が違うので、まず目安を並べ、そのうえで自社の案件で何を基準に決めればよいかを整理します。

長さの目安——1〜4週間が標準。出典ごとの表現の違い

出典が違っても、共通しているのは2点です。上限がおおむね1か月であることと、プロジェクトの途中では変えないのが原則であることです。長さが毎回変わると、前回と比べて速いのか遅いのかが分からなくなり、見通しが立たなくなります。

長さを決める3つの判断材料——判断を返せる頻度、レビュー参加者の都合、1回あたりの固定費

自社の案件で1週間にするか2週間にするかは、次の3つで決めてください。

1. 発注側が判断を返せる頻度。 1回ごとに優先順位の判断と、成果物の確認が必要です。週1回それができる体制なら1週間、月2回が限度なら2週間が現実的です。ここを無視して短くすると、開発は終わっているのに確認待ちの状態が積み上がります
2. レビューに出る人の都合。 決裁権のある人が出られる曜日と時間帯に合わせます。海外チームの場合は時差も条件に入ります。ベトナムと日本の時差は2時間で、日本の午前中はベトナムの朝にあたるため、当日中に判断を返せます
3. 1回あたりの固定費。 1回ごとに計画とレビューの時間がかかります。開発2週間+会議2時間なら会議の比率は低いですが、開発3日+会議2時間では比率が跳ね上がります。短くするほどフィードバックは速くなりますが、会議の比率は上がります

加えて、長期休暇の扱いを先に決めてください。ベトナムの法定祝日は2026年で年12日(労働法112条の条文上は11日で、2026年からベトナム文化の日が加わります)で、旧正月のテトは2026年は2月14日から22日までの9連休です。この期間をまたぐサイクルは、最初から短く区切るか、1回飛ばす前提で計画を立てます。休暇をまたいだまま同じ長さで走らせると、そのサイクルだけ成果が薄くなり、原因が休暇なのか生産性なのか判別できなくなります。

イテレーティブ(反復)とインクリメンタル(漸進)は別の概念

混同されやすいのが、イテレーティブ(反復的)とインクリメンタル(漸進的)です。この2つは別の概念で、両立します。

絵に例えるなら、下描きから何度も描き直して1枚を仕上げるのがイテレーティブ、キャンバスの左端から順に描き足していくのがインクリメンタルです。

スクラムガイド2020年版が「an iterative, incremental approach(反復的で漸進的なアプローチ)」と2語を並べているのは、スクラムが両方を採るためです。1回のスプリントで新しい機能を積み増し(インクリメンタル)、同時に既存の部分をフィードバックに応じて作り直す(イテレーティブ)。スクラムガイドはこの積み増し1回ぶんの成果物を Increment と呼び、「プロダクトゴールに向かう具体的な踏み石であり、それまでのすべてのインクリメントに追加される」と定義しています。

発注側にとっての実務的な意味は、「1回ごとに機能が増えるとは限らない」ということです。作り直しに使うサイクルもあります。機能の数だけで進捗を測ると、作り直しのサイクルが「何もしていない期間」に見えてしまいます。何を成果とみなすかを先に合意しておかないと、評価が噛み合わなくなります。

外部チームに反復型で任せるとき、発注側が決める3つ——長さ・レビューの出席者・完了の定義

ここまでは語の意味の話でした。最後に、実際に外部の開発会社へ反復型で開発を任せるとき、発注側が契約前に決めておく3つを挙げます。私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。反復型で始めた案件がうまくいかないときに共通しているのは、「レビューに決裁権のある人が出ていない」「完了の定義が口頭のまま」の2つです。どちらも、契約前に決めておけば避けられます。

決めること1: 1回の長さと、いつ見直すか

1回の長さは、前章の3つの判断材料(判断を返せる頻度、レビュー参加者の都合、1回あたりの固定費)で決めます。そのうえで、見直してよいタイミングを先に決めておくことをおすすめします。

原則としてプロジェクトの途中では変えませんが、実際には「2週間では確認が追いつかない」「1週間では会議ばかりになる」という声が、開始から2〜3回目で出ます。「3回目が終わった時点で一度だけ見直す」と最初に合意しておけば、その場の空気で変えることを避けられます。見直しの機会を設けないまま走らせて、5回目あたりで誰かが不満を言い出す、という展開は要注意です。

決めること2: レビューに誰が出るか——決裁権のある人が出ていないと反復は形だけになる

反復型の価値は、1回ごとに方向を変えられることにあります。方向を変える判断ができる人がレビューの場にいなければ、その価値は出ません。

よくあるのは、担当者だけがレビューに出て、「持ち帰って確認します」で終わるパターンです。次のサイクルが始まっても判断が返ってこないため、開発チームは前回の続きを推測で進めます。3回目あたりで方向のずれが表面化し、作り直しになります。これは開発会社の問題ではなく、出席者の設計の問題です。

決めておくのは次の3点です。誰が出るか(優先順位を決められる人を最低1名)、いつやるか(曜日と時間帯を固定)、その場で何を決めるか(次のサイクルに入れるものと、後ろに下げるもの)。 当社の案件では、介護記録SaaS「CareViewer」のように、週次で優先順位の判断を返す運びにできている案件は、要件が動いても開発が止まりません。この案件は日本語で話せるブリッジSE1名とフルスタックエンジニア2名の体制で、従来の半分以下のコストで継続開発を回しています。

決めること3: 完了の定義——口頭のままにしない

「終わった」と言える状態の基準を、文書にしてください。テストはどこまで通っていればよいのか、レビューは誰が承認するのか、ドキュメントはどこまで残すのか。この基準がないまま進めると、1回目の終わりに「終わっていない」「終わっている」の議論が起きます。

完了の定義の作り方と、レビューやふりかえりの運び方については、「アジャイル開発 外注」の記事で契約と体制の観点から詳しく扱っています。本記事では、発注側が決める項目であるという位置づけだけ押さえてください。開発会社が勝手に決めるものではありません。

当社の体制——時差2時間、日本人PMがフロント。向く案件・向かない案件

当社は、ホーチミンを拠点にベトナムのIT人財でチームを組みます。ベトナムと日本の時差は2時間で、日本の午前中はベトナムの朝にあたるため、レビューの結果を当日中に開発へ戻せます。体制は、日本人PM/ブリッジSEをフロントに置くパターンA(推奨)と、エンジニアのみのパターンBの2つです。1回ごとの判断を日本語で受け止める役割を置くのがパターンAで、反復型で進める案件にはこちらをおすすめしています。

品質は仕組みで担保します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。公開単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USDです(1USD=150円換算目安)。日本人PMフロント+2〜3人月の最小構成で、月額約80万円からとなります。専属チームを月額で持つ形については「ラボ型開発とは」の記事もあわせてご覧ください。

正直に書くと、反復型が向かない案件もあります。要件が確定していて期日までに一括で納めたい案件、発注側にレビューへ出られる人を置けない案件は、反復型より請負での一括開発のほうが合います。逆に、作りながら決める必要がある新規事業、リリース後も改善が続くSaaSは反復型が向きます。判断がつかない場合は、現在の体制と要件をお聞かせください。どちらが合うかの見立てからお答えします。

【FAQ】イテレーションに関するよくある質問

イテレーションについて、発注側の担当者からよく受ける質問を5つにまとめました。用語の確認から、発注側の工数の見積もりまでを扱います。

Q1. 読み方と英語表記は?

「イテレーション」と読みます。英語表記は iteration で、動詞は iterate です。文献によっては「イタレーション」と表記されることもありますが、同じ語です。形容詞の iterative は「反復的な」、日本語では「反復型」「イテレーティブ」と訳されます。

Q2. 「スプリント」と言い換えてよいですか?

日常会話では通じますが、スクラムを採用している現場では避けたほうが安全です。スクラムガイド2020年版が定義しているのはスプリントだけで、名詞のイテレーションは登場しません(2026-09-15確認)。逆に、XPやその他の反復型開発では、イテレーションが正式な語です。社内と委託先で呼び方が違う場合は、契約前にどちらかへ統一してください。

Q3. 1週間と2週間、どちらがよいですか?

発注側がレビューと優先順位の判断を返せる頻度で決めます。週1回それができるなら1週間、月2回が限度なら2週間です。XPは1週間を推奨していますが、これは顧客が開発チームと同じ場にいる前提の推奨です。発注側が別組織で、決裁者の時間が限られる場合は、2週間のほうが現実的です。

Q4. 途中で長さを変えてよいですか?

原則は変えません。長さが変わると、前回と比べて進んでいるのかどうかが測れなくなります。ただし、開始から2〜3回目で「確認が追いつかない」「会議ばかりになる」という声が出るのは普通のことです。「3回目の終わりに一度だけ見直す」と最初に決めておくのが現実的です。

Q5. 発注側の工数はどれくらい見ておけばよいですか?

2週間のサイクルなら、レビュー1〜2時間、次の優先順位を決める打ち合わせ1時間、そのあいだの質問への回答が随時、というのが当社の案件での目安です。1週間のサイクルならこれが倍の頻度になります。当社の場合、日本人PMをフロントに置くパターンAでは、仕様の言語化と開発チームへの展開をPMが巻き取るため、発注側に残るのは優先順位の判断と成果物の確認です。体制は1名から組め、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位での対応。

まとめ: イテレーションは多義語——文脈を見分け、開発では長さ・出席者・完了の定義を先に決める

イテレーションは「反復・繰り返し」を意味する英語で、IT分野では分野ごとに指すものが違います。プログラミングではループ処理の1周、機械学習では学習の反復回数(ライブラリによってはエポック)、デザインやサービス開発では作って試して直す1周、ソフトウェア開発では要求から検証までを1回ぶん詰め込んだ開発サイクルです。まず、目の前の文書がどの文脈かを見分けてください。

開発の文脈では、イテレーションは反復型開発全般で使える一般語で、スクラムではこれを「スプリント」と呼びます。スクラムガイド2020年版に名詞のイテレーションは登場せず(形容詞 iterative が1箇所のみ)、アジャイルソフトウェア開発宣言の12原則にも登場しません。一方、XPは「1〜3週間、1週間が最良」としてイテレーションを正式な語に置いています。IPAは「反復（イテレーション）」と訳し、その単位をスプリントと説明しています(いずれも2026-09-15に一次情報を確認)。1回の長さは1〜4週間が標準で、プロジェクトの途中では固定するのが原則です。

外部の開発会社に反復型で任せるなら、発注側が決めるのは3つです。1回の長さと見直しのタイミング、レビューに出る人(優先順位を決められる人を最低1名)、そして完了の定義。この3つが決まっていなければ、反復は形だけになり、固定費と会議だけが残ります。スクラムの3つの責任・5つのイベント・3つの作成物についてはスクラムとは、スプリントの回し方と契約・体制についてはアジャイル開発の外注もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、反復型と一括請負のどちらが合うかの見立てと、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。