イテレーションとは｜アジャイルで期間を区切って作る進め方

イテレーションとは、ソフトウェアの開発を数週間ほどの短い期間に区切り、その期間の中で計画、設計、実装、テスト、振り返りまでをひと通り行い、これを何度も繰り返していく進め方のことです。英語の iteration は「反復」という意味で、アジャイル開発の現場では「1回分の開発の区切り」を指す言葉として使われています。この記事では、イテレーションの意味と必要とされる理由、よく混同されるスプリントやインクリメントとの違い、1回のイテレーションの流れ、期間の決め方、うまく回らないときの直し方までを順に説明します。イテレーションで扱う作業を、チームで担当と期限を共有しながら進める方法として、Pinatecaのようなボード型のプロジェクト管理の道具の使いどころにも触れます。

イテレーションとは何か

イテレーションという言葉は、使われる場面によって指すものが少し変わります。まずはこの違いを押さえておくと、調べものの途中で混乱しにくくなります。

開発の進め方としてのイテレーション

プロジェクト管理やアジャイル開発の文脈では、イテレーションは「決まった長さの開発期間の1回分」を指します。たとえば2週間のイテレーションなら、2週間ごとに「何を作るかを決める」「作る」「確かめる」「振り返る」を行い、終わったらすぐに次の2週間に入ります。1回ごとに、実際に動く状態のソフトウェアを少しずつ育てていくのが特徴です。

プログラムの処理としてのイテレーション

プログラミングの文脈では、イテレーションは「同じ処理を繰り返すこと」、つまりループ処理を指します。配列の要素を1つずつ取り出して処理する、といった場面で使われる言葉です。

const tasks = ['画面の設計', 'ログイン機能', '決済のテスト'];
for (const task of tasks) {
  console.log(task); // 要素を1つずつ取り出して処理する（反復処理）
}

この記事で扱うのは前者の「開発の進め方としてのイテレーション」です。どちらも「繰り返す」という同じ考え方から来ていますが、検索で出てくる解説の中には後者の意味で書かれたものもあるため、読むときにどちらの意味かを確かめると迷いません。

なぜ「繰り返す」ことが大事なのか

イテレーションの考え方の背景には、「最初に全部を正しく決めることはできない」という前提があります。お客様自身も、動くものを触ってみてはじめて「本当に欲しかったのはこれではなかった」と気づくことがよくあります。短い期間ごとに動くものを見せ、意見をもらって次の期間に生かせば、方向の誤りが小さいうちに直せます。

開発の道具を提供している CircleCI の解説も、この点を利点として挙げています。

比較的早い段階から実際に動くプログラムを提供することで、顧客からの追加リクエストにも対応しやすいというメリットもあります。このことから、イテレーションは重要な仕組みの一つであり、アジャイル開発においての必要性が挙げられます。 出典: circleci.com

アジャイル開発とウォーターフォールの中での位置づけ

イテレーションを理解するには、それが使われるアジャイル開発と、対になる進め方であるウォーターフォールの違いを知っておくと分かりやすくなります。

ウォーターフォールの進め方

ウォーターフォールとは、要件定義、設計、実装、テスト、リリースといった工程を、上流から下流へ水が流れるように1回ずつ順番に進める開発の進め方です。前の工程が終わってから次の工程に進むため、計画が立てやすく、作るものがはっきり決まっている開発に向いています。一方で、テストの工程になって初めて動くものができるため、最初の要件の誤りに気づくのが遅れやすいという弱点があります。

アジャイル開発の進め方

アジャイル開発とは、短い期間で動くものを作って確かめることを繰り返しながら、変化に合わせて計画を見直していく開発の進め方の総称です。2001年に発表された「アジャイルソフトウェア開発宣言」と、その背後にある12の原則が、考え方の土台になっています。原則の1つには、リリースの間隔について次のように書かれています。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 出典: agilemanifesto.org

イテレーションは、この「短い間隔で動くものを届ける」という原則を、日々の仕事の単位に落とし込んだものです。アジャイル開発は考え方や価値観の総称で、イテレーションはそれを実践するための仕組みの1つ、と整理できます。

2つの進め方の比べ方

観点	ウォーターフォール	アジャイル開発（イテレーション）
工程の進め方	工程を1回ずつ順番に進める	短い期間の中で全工程を繰り返す
動くものができる時期	テストの工程の後半	最初のイテレーションの終わりから
変更への強さ	後半の変更ほど手戻りが大きい	次のイテレーションで取り入れやすい
向いている開発	要件が固まっている、作り直しが難しい	要件が変わりやすい、早く反応を見たい

どちらが優れているというより、作るものの性質で選ぶものです。法令で仕様が決まっている仕組みや、ハードウェアと一体で作るものはウォーターフォールが向いている場面が多く、利用者の反応を見ながら育てる Web サービスやアプリはイテレーションを使う進め方が向いています。

イテレーションとスプリント、インクリメントの違い

イテレーションを調べると、必ずと言ってよいほど「スプリント」と「インクリメント」という言葉が一緒に出てきます。3つの関係を整理しておきましょう。

スプリントとの違い

スプリントは、アジャイル開発の手法の1つである「スクラム」で使われる言葉で、指しているものはイテレーションとほぼ同じ「決まった長さの開発期間」です。違いは、どの手法の言葉かという点にあります。イテレーションは XP（エクストリーム・プログラミング）をはじめ、アジャイル開発全般で使われる一般的な言葉で、スプリントはスクラムでの呼び名です。

スクラムの公式の手引きである「スクラムガイド」は、スプリントの長さを次のように定めています。

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

スクラムでは、スプリントの中で行う会議（イベント）の名前と時間の上限も決まっています。スプリントの最初に何を作るかを決める「スプリントプランニング」、毎日15分で進み具合を確かめる「デイリースクラム」、作ったものを関係者に見せる「スプリントレビュー」、やり方を振り返る「スプリントレトロスペクティブ」の4つです。1か月のスプリントなら、スプリントプランニングは最大8時間、スプリントレビューは最大4時間、スプリントレトロスペクティブは最大3時間とされています。イテレーションという言葉自体には、こうした会議の決まりは含まれていません。

インクリメントとの違い

インクリメントは「増分」という意味で、イテレーションやスプリントの成果として積み上がる「使える状態の成果物」を指します。イテレーションが「期間」であるのに対し、インクリメントは「その期間で生まれたもの」です。1回目のイテレーションでログイン機能ができ、2回目で商品の一覧ができた、というとき、それぞれがインクリメントにあたります。

3つの言葉の関係

言葉	指すもの	主に使われる手法
イテレーション	決まった長さの開発期間の1回分	XP、アジャイル開発全般
スプリント	決まった長さの開発期間の1回分（1か月以内）	スクラム
インクリメント	1回の期間で積み上がった使える成果物	スクラム、アジャイル開発全般

チームの中でどの言葉を使うかは、採用している手法に合わせれば問題ありません。大事なのは、言葉の違いより「期間を区切り、毎回動くものを作って確かめる」という中身を守ることです。

XP（エクストリーム・プログラミング）でのイテレーション

イテレーションという言葉が広まったきっかけの1つが、XP（エクストリーム・プログラミング）です。XP は、1990年代の終わりに提唱されたアジャイル開発の手法で、短いイテレーションと、開発の具体的な実践の決まりを組み合わせているのが特徴です。

イテレーションは「XP - エクストリームプログラミング」( 次の項で紹介しています）で使用されます。設計から開発、テスト、改善のプロセスを繰り返すイテレーションは、この改善までの工程を短期間かつ高頻度で行うため、失敗と改善という経験を集めやすくXP開発の中に組み込まれています。 出典: circleci.com

XP では、イテレーションを1〜2週間ほどの短い期間で回すことが多く、その中で次のような実践を組み合わせます。

• テスト駆動開発: 先にテストのコードを書き、それが通るように本体のコードを書く進め方です。毎回のイテレーションで動くものを作るとき、壊れていないことをすぐに確かめられます。
• ペアプログラミング: 2人で1台の画面を見ながら、1人が書き、もう1人が確かめる進め方です。間違いに早く気づけ、知識がチームに広がります。
• 継続的インテグレーション: 書いたコードを頻繁に1つにまとめ、自動のテストを走らせる仕組みです。イテレーションの終わりにまとめて結合する手間と危険を減らせます。
• リファクタリング: 動きを変えずにコードの中身を整理し直すことです。短い期間で機能を積み上げていくと、コードが散らかりやすくなるため、こまめに整えます。

XP のイテレーションの計画では、利用者から見た機能を「ユーザーストーリー」という短い文で書き、チームでかかる手間を見積もってから、そのイテレーションで扱うものを選びます。ユーザーストーリーとは、「会員として、パスワードを忘れたときに自分で再設定したい」のように、誰が何のために何をしたいかを1文で書いたものです。機能を技術の言葉ではなく利用者の言葉で書くことで、お客様と開発者が同じものを見て優先順位を話し合えるようになります。

XP の実践は、全部を一度に取り入れる必要はありません。たとえば、まずは継続的インテグレーションで自動のテストを毎回走らせる仕組みだけを整え、慣れてきたらテスト駆動開発を一部の機能で試す、という順番でも、イテレーションの質は確実に上がります。

1回のイテレーションの流れ

ここでは、2週間のイテレーションを例に、1回の流れを5つの段階に分けて説明します。手法によって呼び名は違っても、中身はおおむねこの形です。

段階1: 計画（1日目）

イテレーションの最初に、チームとお客様（またはプロダクトの責任者）で、この期間に何を作るかを決めます。開発するものの候補の一覧（バックログ）から、優先度の高いものを上から選び、チームがこの期間でこなせる量に収めます。あわせて、「この期間が終わったときに何ができていれば成功か」というゴールを1文で決めておくと、途中で判断に迷ったときの拠り所になります。

段階2: 設計と実装（2日目から9日目）

選んだ作業を、設計、実装、テストの順に進めます。ウォーターフォールのように設計を全部終えてから実装に入るのではなく、1つの機能ごとに設計から実装、テストまでを通して仕上げていくのが基本です。毎日短い時間で集まり、「昨日やったこと」「今日やること」「困っていること」を共有して、問題を早く拾います。

段階3: テスト（各機能の完成時と最終日の前）

機能ができるたびにテストを行い、イテレーションの終わりには、まとめて動かしたときに問題がないかも確かめます。「完成」の基準をあらかじめチームで決めておくことが大切です。テストが通っていない、レビューが済んでいない、といった状態のものを「できた」と数えると、次のイテレーションに見えない宿題が残ります。

段階4: レビュー（10日目）

できあがったものを、お客様や関係者に実際に動かして見せます。ここでもらった意見は、バックログに新しい項目として加えたり、優先度を入れ替えたりして、次のイテレーションの計画に生かします。

段階5: 振り返り（10日目）

最後に、チームのやり方を振り返ります。「うまくいったこと」「うまくいかなかったこと」「次に試すこと」を出し合い、次のイテレーションで試す改善を1つか2つに絞ります。振り返りで出た改善を全部やろうとすると、どれも中途半端になります。

5つの段階は、2週間の中で毎回同じ曜日に同じ順番で行うと、チームに習慣として根づきます。たとえば、月曜の午前に計画、毎朝10時に短い共有、2週目の金曜の午後にレビューと振り返り、と決めてしまえば、会議の日程を毎回調整する手間がなくなり、お客様もレビューの予定を立てやすくなります。

イテレーションの期間の決め方

イテレーションの長さに決まった正解はありませんが、多くのチームは1〜4週間の範囲で選んでいます。スクラムなら1か月以内という上限があり、アジャイル開発の原則でも「できるだけ短い時間間隔」が勧められています。期間を決めるときは、次の観点で考えます。

短い期間（1週間）が向いている場合

• 利用者の反応を見ながら、細かく方向を変えたいとき
• 小さなチームで、1つの機能を数日で作れるとき
• 新しいサービスの立ち上げ直後で、何が求められているかがまだ分からないとき

短い期間は、方向の誤りに早く気づける反面、計画とレビュー、振り返りの時間の割合が大きくなります。1週間のイテレーションで会議に1日使うと、開発に使える時間は4日です。

長い期間（3〜4週間）が向いている場合

• 1つの機能を作るのに、どうしても1週間以上かかるとき
• お客様の確認に時間がかかり、短い間隔ではレビューの場を設けられないとき
• 複数のチームで足並みをそろえる必要があるとき

長い期間は、まとまった機能を作りやすい反面、途中で方向がずれたときの手戻りが大きくなります。

迷ったら2週間から

最初は2週間で始め、3〜4回繰り返してから見直すのが無理のない進め方です。大事なのは、一度決めた長さを毎回変えないことです。長さが毎回違うと、1回のイテレーションでチームがどのくらいの量をこなせるかが比べられなくなります。この「1回でこなせる量」を、アジャイル開発では「ベロシティ」と呼び、次の計画を立てるときの目安に使います。

イテレーションの計画を支えるバックログの作り方

イテレーションの計画がうまくいくかどうかは、計画の前に用意する「バックログ」の質でほぼ決まります。バックログとは、これから作る機能や直す点の候補を、優先度の高い順に並べた一覧のことです。スクラムでは「プロダクトバックログ」と呼ばれ、プロダクトの責任者が並び順を決めます。

良いバックログには、次の3つの特徴があります。

1つ目は、上にある項目ほど細かく、下にある項目ほど大まかであることです。次のイテレーションで扱う上位の項目は、チームが手間を見積もれる大きさまで分け、完成の条件も書いておきます。数か月先に扱うかもしれない下位の項目は、「会員の機能を充実させる」のような大まかな書き方でも構いません。全部を最初から細かく書こうとすると、書いた内容の多くが、実際に扱う前に古くなってしまいます。

2つ目は、並び順がはっきりしていることです。「優先度：高」の項目が20個並んでいるバックログでは、計画のときに何から手を付けるかを決められません。同じ優先度を付けるのではなく、1番目、2番目と順番を付けます。順番を決める基準は、利用者にとっての価値、作らなかったときの損失、ほかの作業の前提になるかどうか、などです。

3つ目は、定期的に見直されていることです。イテレーションのレビューでもらった意見や、市場の変化によって、項目の価値は変わります。スクラムでは、この見直しの作業を「リファインメント」と呼び、イテレーションの途中で時間を取って、次の回の候補を細かく分けたり、並び順を入れ替えたりします。リファインメントを怠ると、計画の会議の場で項目の中身を話し合うことになり、会議が長引く原因になります。

バックログの1項目は、先に触れたユーザーストーリーの形で書くと、誰のための機能なのかが伝わりやすくなります。「会員として、注文の履歴を一覧で見たい。過去に買った商品をもう一度注文するためだ」のように、誰が、何を、何のためにしたいかをそろえて書きます。

見積もりとベロシティの使い方

イテレーションを何回か回すと、チームが1回でどのくらいの量をこなせるかが分かってきます。この量を測り、次の計画に生かす方法を説明します。

作業の大きさを相対で見積もる

アジャイル開発では、作業の大きさを「何時間かかるか」ではなく、「ほかの作業と比べてどのくらい大きいか」で見積もる方法がよく使われます。たとえば、チームがよく知っている小さな作業を「1」とし、それより2倍ほど大きいものを「2」、さらに大きいものを「3」「5」「8」のように数字で表します。この数字を「ストーリーポイント」と呼びます。時間で見積もると人によって差が大きくなりますが、相対で比べると、チームの中で感覚をそろえやすくなります。

ベロシティを計算する

1回のイテレーションで完成の基準を満たした作業のポイントを合計したものが、そのイテレーションのベロシティです。たとえば、3回のイテレーションで完成したポイントが18、22、20だったなら、平均はおよそ20ポイントです。次の計画では、この20ポイント前後の作業を選べば、無理のない量に収まると考えられます。

ベロシティを使うときの注意

ベロシティは、チームが自分たちの計画を立てるための目安であって、チーム同士を比べたり、個人の評価に使ったりするためのものではありません。ポイントの付け方はチームごとに違うため、別のチームと数字を比べても意味がありません。また、ベロシティを上げることを目標にすると、見積もりの数字を大きめに付けるようになり、目安としての役に立たなくなります。メンバーの入れ替わりや休暇がある回は、ベロシティが下がるのが自然なので、計画の量もそれに合わせて減らします。

イテレーションを始める前に決めておくこと

これからチームでイテレーションを始める場合は、1回目の計画に入る前に、次のことを決めておくと立ち上がりがなめらかになります。

1. イテレーションの長さと、始まりと終わりの曜日
2. 計画、毎日の共有、レビュー、振り返りを行う日時と、参加する人
3. 並び順を決める責任者（スクラムならプロダクトオーナー）
4. 「完成」とみなす基準（テストが通っている、レビューが済んでいる、など）
5. 作業の一覧と進み具合を共有する場所（ホワイトボード、表計算ソフト、プロジェクト管理の道具など）
6. 途中で割り込みの依頼が来たときの受け付け方

特に4つ目の「完成の基準」は、最初に文章にしておくことが大切です。基準があいまいなまま始めると、人によって「できた」の意味が違い、レビューの場で食い違いが表に出ます。基準は1回目から完璧である必要はなく、振り返りのたびに見直して育てていけば十分です。

イテレーションがうまく回らないときの原因と直し方

イテレーションは、形だけ取り入れても成果が出ないことがあります。現場でよく起きる問題と、その直し方を挙げます。

毎回、予定した作業が終わらない

原因の多くは、計画の段階で詰め込みすぎていることです。前の数回のイテレーションで実際に終わった量の平均を目安にし、それ以上は入れないようにします。作業を1日から2日で終わる大きさに分けると、見積もりの誤りも小さくなります。

イテレーションの途中で作業が割り込む

途中で急ぎの依頼が入るたびに対応していると、計画がいつも崩れます。割り込みを受ける窓口を1人に決める、割り込み用の時間をあらかじめ見込んでおく、急ぎでないものは次のイテレーションの候補に回す、といった決まりを作ります。

レビューで「思っていたものと違う」と言われる

計画の段階で、お客様と「完成の姿」をそろえられていない可能性があります。ユーザーストーリーに「どうなれば完成か」という条件を書き添え、計画のときにお客様と一緒に確かめます。

振り返りが形だけになる

毎回同じ意見が出て、何も変わらない振り返りは、チームの意欲を下げます。前回の振り返りで決めた改善を、次の振り返りの最初に確かめる習慣をつけると、振り返りが「言いっぱなし」で終わらなくなります。

イテレーションの終わりに「ほぼ完成」が残る

「9割できた」ものは、利用者から見れば使えないものです。完成の基準を満たしたものだけを成果として数え、残ったものは次のイテレーションで改めて計画に入れます。

イテレーションの作業をチームで共有する道具

イテレーションを回すには、「今回のイテレーションで扱う作業」「それぞれの担当」「いまの進み具合」をチーム全員が同じ場所で見られることが欠かせません。

小さなチームで始めるなら、ホワイトボードと付箋、または表計算ソフトの一覧で十分です。表計算ソフトなら「作業」「担当」「見積もり」「状況（未着手・進行中・確認中・完了）」の列を作り、イテレーションごとにシートを分けておくと、過去の回と比べることもできます。

どの道具を使う場合でも、共有の場所には「今回のイテレーションのゴール」を一番目立つ場所に書いておくことをおすすめします。作業の一覧だけが並んでいると、メンバーは目の前の作業を片付けることに意識が向き、途中で計画を変えるべきかどうかを判断する拠り所を失います。ゴールが見えていれば、「この作業は今回のゴールに関係しないので次の回に回そう」という判断を、メンバー自身ができるようになります。あわせて、完成の基準も同じ場所に書いておくと、レビューの前に「できた」の意味を確かめ直す手間が省けます。

一方で、メンバーが在宅で働いていたり、複数の案件を並行して進めていたりすると、表の一覧では「どの作業がどこで止まっているか」が見えにくくなります。こうした場面での選択肢の1つが、Pinatecaのようなボード型のプロジェクト管理の道具です。

公式サイトによると、Pinateca はカンバン、ガントチャート、カレンダー、リスト、時間割、リソースなど8種類のボードを選んで使える国産のプロジェクト管理の道具です。カンバンボードでは列にカードを並べて進み具合を動かせるため、「今回のイテレーション」「進行中」「レビュー」「完了」といった列を作り、作業を1枚ずつのカードとして担当と期限を付けて並べると、イテレーションの進み具合を1画面で見渡せます。カードには見積もりの工数や優先度などの項目を自由に追加でき、カードごとのコメントとワークスペースのチャットで、作業についての話し合いをそのカードのそばに残せます。人やチームごとの負荷の偏りを見るリソースボードもあり、特定の人に作業が集まっていないかを計画のときに確かめる使い方もできます。

料金は、5人まで、ボード10個までのフリープランが期限なしで使え、クレジットカードの登録は不要と案内されています。それを超える場合は、1人あたり月額500円（税抜）のスタンダードプランで、人数とボードの上限がなくなります。Trello から、ボードやカード、添付を読み込んで移る機能も用意されています。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

イテレーションの経験が生きる働き方

イテレーションで開発を進める経験は、エンジニアとしての働き方にも直結します。業務委託やフリーランスで Web サービスやアプリの開発に関わると、多くの現場で2週間前後のイテレーションやスプリントが採用されています。参加してすぐに「計画、実装、レビュー、振り返り」の流れに乗れる人は、現場の立ち上がりが早く、任される範囲も広がりやすい傾向があります。

在宅ワークとフリーランスの仲介を長く続けてきた運営者として見てきた限りでは、継続して声がかかるエンジニアほど、コードを書く速さより、イテレーションの終わりに「何ができて、何が残ったか」を短く正直に報告することを大事にしています。期限の直前に「実は終わっていません」と伝えるより、途中で「この作業は次の回に回したほうがよい」と早めに相談するほうが、依頼する側は計画を立て直しやすくなります。この積み重ねが、仲介の手数料が乗らない直接の取引でも長く続く信頼につながっていきます。

アプリの開発の仕事の種類と、案件で求められる技術は、アプリケーション開発のお仕事で紹介しています。スマートフォンのアプリや業務アプリの開発で、どんな工程を任されるかが整理されています。

AI を業務に取り入れる支援でも、まず小さく試し、使ってもらって直すことを繰り返すイテレーションの考え方が役に立ちます。AIコンサル・業務活用支援のお仕事では、AI や業務の道具を導入し、定着させる仕事の種類が紹介されています。マーケティングやセキュリティの分野でも、施策を短い期間で試して数字を見て直す進め方は共通しており、AI・マーケティング・セキュリティのお仕事で仕事の例を確かめられます。

画面の設計を担当するデザイナーも、イテレーションのたびにレビューで意見をもらい、画面を直していく働き方が一般的です。デザインの仕事の報酬の目安は、デザイナーの年収・単価相場で確かめられます。

介護や福祉の事業所が記録の仕組みを電子化するときも、一度に全部を切り替えるより、一部の業務から試して現場の声を聞き、少しずつ広げていく進め方が向いています。補助金を使った電子化の進め方は、介護・福祉事業所のDX化2026｜IT導入補助金で介護記録を完全デジタル化で整理しています。

イテレーションは、期間を区切り、毎回動くものを作って確かめ、やり方を振り返るという単純な仕組みです。最初から完璧に回す必要はありません。2週間の区切りで1回目を始め、振り返りで見つけた改善を1つずつ試していけば、チームに合った回し方が見えてきます。

よくある質問

Q. イテレーションとスプリントは同じ意味ですか？

指しているものはほぼ同じで、どちらも決まった長さの開発期間の1回分です。違いは使われる手法で、イテレーションは XP をはじめアジャイル開発全般で使われる一般的な言葉、スプリントはスクラムでの呼び名です。スクラムでは、スプリントは1か月以内の決まった長さとされ、中で行う会議の名前と時間の上限も決まっています。

Q. イテレーションの期間は何週間がよいですか？

多くのチームは1〜4週間の範囲で選んでいます。迷った場合は2週間から始め、3〜4回繰り返してから見直すのが無理のない進め方です。一度決めた長さは毎回変えないことが大切で、長さをそろえることで、1回でこなせる作業の量を比べられるようになり、次の計画が立てやすくなります。

Q. ウォーターフォールの現場でもイテレーションの考え方は使えますか？

使えます。全体はウォーターフォールで進めながら、画面の試作や一部の機能だけを短い期間で作って確かめる、という組み合わせは珍しくありません。早い段階でお客様に動くものを見せられるため、要件の誤りに気づくのが早くなります。ただし、契約や納期の決め方が変わることもあるため、事前に関係者と進め方をそろえておく必要があります。

Q. 1人で開発する場合もイテレーションは役に立ちますか？

役に立ちます。1人でも1〜2週間の区切りで作るものを決め、期間の終わりに動くものを確かめて振り返ると、作業の抱え込みや方向のずれに早く気づけます。依頼主がいる場合は、区切りごとに動くものを見せて意見をもらうと、最後の段階で大きな手戻りが起きるのを防げます。会議の形にこだわらず、計画と確認と振り返りの3つを守ることが要点です。