3秒でわかる
動くものを短い間隔で作って確かめ、要求の変化に合わせて計画を直していく開発の考え方。作る前に仕様を固め切れない案件で使われます。
30秒図解
もう少し詳しく
どういうものか
アジャイルは、数週間ほどの短い区切りで「動くもの」を作り、使う人に見せて、次に何を作るかを決め直していく開発の進め方の総称です。2001 年のアジャイルソフトウェア開発宣言が出発点で、そこには四つの価値が並んでいます。プロセスや道具より個人と対話を、包括的なドキュメントより動くソフトウェアを、契約交渉より顧客との協調を、計画に従うことより変化への対応を重んじる、というものです。左側を捨てるのではなく、右側をより重んじるという書き方になっている点が読み落とされがちです。
なぜ必要か
ウォーターフォールは、最初に仕様を全部決められる前提で成り立ちます。しかし新規サービスや社内業務の改善では、使ってみて初めて「そこは要らなかった」と分かることが珍しくありません。一年かけて作ってから間違いに気づくと、修正費用は膨れ上がります。短い区切りで見せて直すのは、間違いを早く小さく見つけるための仕組みです。
具体例
スクラムでの二週間の流れを並べると次のようになります。
Day 1 スプリントプランニング 今回やる項目を積む
Day 1-9 デイリースクラム 毎朝15分で進み具合と詰まりを共有
Day 10 スプリント<a href="/glossary/review" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">レビュー</a> 動くものを関係者に見せて意見をもらう
Day 10 レトロスペクティブ やり方自体の改善点を1つ決める積む項目はプロダクトバックログから選び、次のような一文の形で書くのが一般的です。
店舗スタッフとして、在庫が5個を切った商品を一覧で見たい。
発注のタイミングを逃さないため。似た用語との違い
アジャイルは考え方、スクラムはその考え方に沿った具体的な枠組み、カンバンは仕掛かりの数を絞って流れを整える方式です。DevOps はさらに後工程まで含めて、開発と運用の間の壁を無くす取り組みを指します。求人票で「アジャイル開発」と書かれている場合、実態はスクラムであることが多いため、面接では区切りの長さと誰が優先順位を決めるのかを確かめると中身が分かります。
つまずきやすいところ
「ドキュメントを書かなくてよい」という誤読が最も多い失敗です。宣言が言っているのは、動くものより分厚い資料を優先しないという話であり、設計判断の記録まで捨ててよいという意味ではありません。もう一つは、短い区切りだけ真似て、レビューで出た意見を計画に反映しない運用です。区切りを刻んでも直さないなら、締切が増えただけになります。
覚え方
「一年かけて一回見せる」のではなく「二週間ごとに十回見せる」と置き換えると、何を短くしているのかが掴めます。短くしているのは作業量ではなく、間違いに気づくまでの距離です。区切りごとに必ず動くものが出てくること、そしてそこで得た意見が次の計画を変えること、この二つが揃って初めてアジャイルと呼べます。片方だけなら、単に締切が細かくなった開発になります。