「2週間ごとに開発しているのに、最後になって使えないと分かった」。短い期間に区切るだけでは、この問題は解消しません。途中で何を確かめ、その結果から誰が計画を変えられるかが必要です。
アジャイル開発は、使えるものを小さく届け、得られた情報から次の仕事を調整する考え方です。速く作ることだけでなく、間違った方向へ大きく進み続けないために使います。この記事では、ソフトウェア開発に初めて関わる人に向けて、基本と実務上の判断を整理します。例は架空の設計例です。資料の確認日は2026年10月4日です。
30秒で要点
- 目的・品質・制約を共有し、使える変更を確かめて計画を更新する。計画や文書をなくす方法ではない。
- スクラムは目標に向けた検査と適応の枠組み。カンバンは仕事の流れを定義し、進行中の仕事を管理する。組み合わせも可能。
- 会議の実施回数や作業件数に加え、利用者が目的を果たせたか、滞留や手戻りがどう変わったかを見る。
最初の計画を、観察できる仮説にする
たとえば予約受付を改善するなら、「新しい管理画面を全部作る」は作業の指定です。「受付担当が、予約内容の確認に必要な情報を見つけられるようにする」は確かめたい状態です。同じ画面でも、どちらを目標にするかで、途中の確認内容が変わります。
目的が明らかでも、解決策の細部は使って初めて分かることがあります。一方、扱うデータの範囲やアクセス権、利用できる予算などは、試行中にも守る必要があります。変更できる部分と、守る条件を分けます。
最初に全要件を確定する進め方にも、合意や依存関係をそろえやすい場面があります。後で変更する費用が大きい設備や外部連携では、先行調査が重要です。アジャイルかどうかという名称だけで選ばず、何がまだ分からず、いつ確かめられるかを見ます。
宣言が重視するのは、形式よりも判断に役立つもの
2001年のアジャイルソフトウェア開発宣言は、人の対話、動くソフトウェア、顧客との協働、変化への対応を重視します。同時に、比較対象であるプロセス・文書・契約・計画にも価値があると明記しています。
このため「仕様書はいらない」「毎回違うものを作ってよい」と読むと、意図を取り違えます。たとえば認可の条件やデータの削除方法は、動く画面だけでは伝わりません。後から使う人が判断できる形で記録する必要があります。
宣言の原則には、継続的な提供だけでなく、持続可能なペース、技術的な品質、定期的な振り返りも含まれます。短納期を理由に確認を省くと、次の変更を難しくする負債が増えかねません。スクラムとカンバンは、何をそろえる方法か
スクラム：目標に向けて検査し、次を調整する
確認時点の公式資料は2020年版Scrum Guideです。スクラムでは、1か月以下の固定期間であるスプリントの中で、目標に向けた仕事を進めます。プロダクトオーナーは価値と仕事の優先順、スクラムマスターは枠組みの理解と有効性、Developersは利用可能な成果づくりを担います。
仕事の候補を並べるプロダクトバックログ、今回の目標と実行計画を含むスプリントバックログ、完了条件を満たす成果であるインクリメントを共有します。何を良くしたいのか、今回何に取り組むのか、何ができたのかを見えるようにする役割があります。
計画では目標と仕事を決め、デイリースクラムではDevelopersが目標への進み方を調整します。レビューで成果と状況の変化を検査し、振り返りで働き方の改善を考えます。日々の会議を上司への報告だけにしたり、レビューを完成品の発表だけにしたりすると、次を変えるための情報が失われます。
カンバン：始めた仕事を、終えられる流れへ
Kanban Guideの2025年5月版では、仕事の流れを定義・可視化し、進行中の仕事を管理しながら改善します。ボードを作る前に、何を一件とし、いつ開始・終了と数えるかを決めます。WIPとは、着手済みでまだ終わっていない仕事です。その増え方を制御し、詰まりを解き、終わるまでの時間の見通しを共有します。見通しには経過時間と確率を使いますが、納期の保証ではありません。
表が収まらない場合は、横にスクロールできます
| 見たい問題 | 確かめることの例 |
|---|---|
| 優先順位が毎日変わり、目的を見失う | 誰が目標と優先順を決めるか。変える理由を共有できるか |
| 着手は増えるが、完了しない | WIPと滞留している仕事、確認待ちの場所を見ているか |
| 動くが、実際には使えない | 完了条件に品質と利用可能性を含めているか |
| 納品後に初めて不満が分かる | 利用者の仕事に近い条件で、途中の成果を確かめているか |
この表は選択の入口です。スクラムとカンバンは排他的ではなく、スクラムの中で流れを測ることもできます。反対に、一部の会議や付箋だけを取り入れた状態を、枠組み全体を実践していると扱わないことも大切です。
「小さく作る」を、使える単位に置き換える
予約受付の架空例で考えます。データベースだけ、画面だけ、メールだけを順番に作ると、利用者の仕事が改善したかを確かめられるのは最後になります。そこで、対象を絞りながら、受付から確認までを通して使える変更を考えます。
表が収まらない場合は、横にスクロールできます
| 最初に決める項目 | 架空の試行での例 |
|---|---|
| 確かめたいこと | 受付担当が、予約情報の不足を確認できるか |
| 小さな提供範囲 | 一種類の予約について、必要項目を確認できる表示を加える |
| 守る条件 | 閲覧権限、入力内容の保護、既存予約への影響、復旧手順 |
| 完了したと言える条件 | 合意した入力例・権限・異常時の動作を検証し、担当者が操作できる |
| 確認する結果 | 情報を探す時間、確認し直した件数、見落とし、担当者の説明 |
| 次の判断 | 範囲を広げる、案を変える、必要性から再検討する |
これは必ずこの順に実装するという指示ではありません。システムの制約によって、先に調べるべきことは変わります。難しい部分を隠して「小さくできた」と見せるより、まだ確かめられていない条件を明らかにします。
利用者に未検証のものを触ってもらう前に、安全な環境と扱うデータを決めます。品質を含む完了の定義を満たすことと、実際の公開時期を判断することも分けます。スクラムのレビューを待たなければ公開できないわけではありませんが、公開日が来たから未完了を完了に変えることもできません。
速さと成果を、一つの数字にまとめない
作業が速く終わっても、利用者の目的に近づいたとは限りません。運び方と役立ち方を分けて見ます。
- 流れ：進行中の件数、一定期間に完了した件数、未完了の仕事の経過時間、着手から完了までの時間。開始・終了の定義をそろえる。
- 品質：確認漏れ、不具合、やり直した仕事。何を一件とし、いつ見つかったものを数えるかを決める。
- 利用結果：対象の仕事を完了できたか、必要な時間や負担がどう変わったか。対象者と観測期間をそろえる。
完了件数は、仕事を細かく分けるだけでも増えます。見積もりの点数も、チームごとの前提が異なります。異なるチームの件数や点数を並べる前に、数えているものが同じかを確かめます。
前後で所要時間が減っても、担当者の慣れや依頼内容の変化が関係するかもしれません。改善の候補を見つける観察と、施策が原因だったかを確かめる検証を分けます。データから施策を判断する進め方でも、この区別を扱っています。
会議を増やす前に、一つの仕事の流れを確かめる
小さく試すなら、最近完了した一件と、長く止まっている一件を選びます。依頼から完了までに、誰が何を判断し、どこで待ち、何を根拠に完了としたかをたどってください。
次に一つの詰まりを選びます。たとえば確認待ちが原因なら、新しい会議を足す前に、確認条件、担当する人、確認できる時間をそろえます。変えた条件と観察期間を記録し、次の仕事で何が変わったかを見ます。少数の試行だけで全社的な生産性向上は証明できませんが、次に調べる場所は絞れます。
仕事を選ぶ仕組みと、実装の品質を確かめる仕組みは補い合います。TDDの小さな検証サイクルやCI/CDの検査と公開条件も、必要な範囲から組み合わせて考えられます。
アジャイルという名前を採用したかより、前回分からなかったことが何だったか、その情報によって次の計画をどう変えたかを説明できる状態が、見直しの手掛かりになります。