料理を完成させてから出すのではなく、まず一皿出して食べてもらい、感想を聞いて味や盛り付けを直す。それを何度か繰り返して仕上げていく。アジャイルは、ソフトウェアをこの試食の要領で作っていく進め方です。
最初にすべてを設計して作り切るのではなく、短い期間で小さく動くものを作り、使ってみて分かったことを次の作業に活かします。途中で要件が変わっても対応しやすいのが特徴で、Webサービスやアプリの開発でよく採られています。
2週間ごとに何が起きているのか
アジャイルのチームは、たとえば2週間くらいの短い区切り（イテレーション）を繰り返します。
- その期間で作る範囲を決め、最低限の機能が動くものを作る
- 依頼者や利用者に実際に触ってもらい、感想や要望を聞く
- 分かったことを、次の区切りで作るものに反映する
- 区切りの終わりに、チームの進め方そのものも振り返って直す（レトロスペクティブ）
早い段階から動くものを見られるので、「完成してみたら想像と違った」というズレは小さく抑えられる。アジャイルの考え方を実践する具体的なやり方として有名なのがスクラムで、「スプリント」と呼ばれる短い開発単位や、毎日の短い打ち合わせなどの進め方を定めています。短い区切りで何度もリリースするために、テストとデプロイを自動化する CI/CD と組み合わせることがよくあります。
「アジャイルだから」の誤解
アジャイルで進めてるなら、途中で仕様をいくら変えてもいいんですよね？
「変えやすい」と「いくら変えてもいい」は、実は別の話なんだ。
アジャイルは、「ドキュメントを書かない」「計画を立てない」という意味ではありません。変化に対応しやすい計画の立て方をし、必要な文書は残しながら進めます。文書化を省きすぎると、あとから「なぜこうなったのか」が誰にも分からなくなります。
「柔軟に変えられる」と「何でも変えてよい」も別の話です。変更には必ず影響があり、その分どこかの作業が後ろにずれます。変えるたびに影響を見積もる習慣がないと、「アジャイルだから何でもOK」という空気が、かえって現場を混乱させます。
発注する側に求められること
アジャイルで頼むと、依頼する側の出番が増えます。区切りごとに動くものを見て、感想や判断を返す人がいなければ、試食の感想がないまま料理を作り続けることになります。依頼者や利用者が継続して関われる体制があるかを、始める前に確かめてください。
要件が最初から固まっていない、あるいは変わり続けるプロジェクト、利用者の反応を見ながら機能を育てていくサービス、密に話し合える小さめのチームで進める開発に向いています。最初に全体を決めて順番に作るウォーターフォールとの選び分けは、ウォーターフォールとアジャイルの違いで詳しく比べています。