たとえるなら
味見をしながら作る料理です。レシピどおりに最後まで作ってから味を見るのではなく、途中で何度も味見をして調整します。食べる人の好みが途中でわかってきても、すぐ反映できます。
もう少しくわしく
アジャイル（agile）は「素早い・機敏な」という意味で、短い期間で「作る→試す→直す」を繰り返しながらサービスを育てていく開発方式の総称です。最初に完璧な計画を作り込むのではなく、まず動くものを小さく作って利用者や関係者の反応を確かめ、その学びを次のサイクルに活かします。
この方式が広まった背景には、「作ってみないとわからないことが多すぎる」という現実があります。利用者が本当に欲しいものは、実際に触ってもらって初めてわかることが多い。だったら、完成まで1年待つのではなく、数週間ごとに小さく出して確かめたほうが、的外れなものを作り込む無駄を減らせる、という考え方です。
考え方の土台には、2001年にまとめられた「アジャイルソフトウェア開発宣言」があります。文書よりも動くもの、契約交渉よりも顧客との協調、計画に従うことよりも変化への対応を重んじる——という価値観です。右側を軽んじるのではなく、どちらも大事なうえで左側により価値を置く、と明記されている点がよく誤解されます。
アジャイルの代表的な進め方に「スクラム」があります。1〜2週間の「スプリント」という区切りで開発を回し、毎日短い共有ミーティング（朝会）を行い、区切りの終わりに成果を見せ合って振り返る、という型が決まっています。求人票の「アジャイル開発の経験」は、多くの場合このスクラムでの開発経験を指しています。
もうひとつよく使われるのがカンバンです。作業を付箋やカードにして「未着手・作業中・完了」の列に並べ、進み具合を見えるようにします。スクラムのように期間を区切らず、流れ続ける仕事を扱うのに向いており、運用や問い合わせ対応のチームでもよく採用されます。
うまくいかないパターンもはっきりしています。朝会も振り返りもやっているのに、計画が毎回崩れる。「アジャイルだから仕様は決めなくていい」と誤解して、何を作るかが定まらない。短いサイクルにするだけで、作ったものを試す相手がいない。形式だけを真似ても、学びを次に活かす流れがなければアジャイルにはなりません。
ウォーターフォールとの関係は、優劣ではなく向き不向きです。作るものが最初から決まっていて関係者が多い大規模システムなら計画重視の進め方が向き、市場の反応を見ながら形を変えていくサービスならアジャイルが向きます。実際には、両方を組み合わせて進める現場も少なくありません。
現場での使われ方
「うちのチームはアジャイルで開発しています」
短いサイクルで作って試す方式で開発している、という意味。Web系の開発チームの多くがこのスタイルです。
「まず小さくリリースして、反応を見て改善しましょう」
アジャイルの考え方そのもの。完璧を目指して抱え込まず、早く出して学ぼうという提案です。
「アジャイルだから仕様は決めなくていい、ではないですよ」
よくある誤解への釘刺し。決め方が段階的なだけで、何を作るかを決めないわけではありません。
「振り返りで出た改善、次のスプリントで試しましょう」
学びを次のサイクルに回す動き。これが回っているかどうかが、形だけのアジャイルとの分かれ目です。
よくある質問
アジャイルとスクラムの違いは何ですか？
アジャイルは「短いサイクルで繰り返す」という考え方の総称で、スクラムはそれを実践するための具体的な型（役割や会議の決まり）のひとつです。スクラムのほかにも、カンバンなどの進め方があります。
アジャイルなら計画は立てないのですか？
計画は立てます。ただし「最初に全部を確定させる」のではなく、直近は細かく、先のことは大まかに計画し、学んだことに合わせて計画自体を更新し続けるスタイルです。
アジャイルとウォーターフォールはどちらが良いのですか？
優劣ではなく向き不向きです。要件が固まっていて関係者が多い大規模システムは計画重視の進め方が向き、市場の反応を見ながら育てるサービスはアジャイルが向きます。両方を組み合わせる現場もあります。
アジャイル開発宣言とは何ですか？
2001年に技術者たちがまとめた、アジャイルの価値観を示す短い文書です。文書より動くもの、計画に従うことより変化への対応を重んじる、といった内容で、「右側を軽んじるわけではない」と明記されている点が要点です。
少人数のチームでもアジャイルはできますか？
できます。むしろ人数が少ないほど、決めごとを軽くして回しやすくなります。大切なのは会議の型を守ることではなく、短く作って試し、その学びを次に活かす流れが続いているかどうかです。
