はじめに
社内でアジャイル開発に関する相談を受けるときに、これってウォーターフォール開発と比べて効率的なのか？と聞かれることがあります。その内容について少し考えてみましたので整理したいと思います。
なお、私はスクラムマスター経験、社内のアジャイル開発の立ち上げ支援・推進などの経験があります。詳細は以前Agile Japan 2021というイベントで語ったことがあります。イベントサイトに当時のスライドも貼ってありますので宜しければ参照ください。
- 参考：Agile Japan 2021 公式サイト
アジャイル開発の特徴
アジャイル開発の特徴は様々ありますが、今回の効率的かどうかの検討に関係あるような内容をいくつか列挙したいと思います。
-
基本的には少人数メンバー固定で、プロダクトオーナー（PO）と開発メンバーが一緒になって開発する
-
一定の固定期間であるスプリントと呼ばれる単位で区切って開発を行い、スプリント開始時にはスプリントプランニングというイベントでやることを決め、スプリントの終わりまでにはスプリントレビューを行い、開発した内容を確認しながら進める
-
スプリント単位にやることを決めるため、スプリントレビューなどの際に各種ステークホルダーからフィードバックを受けて、次どのようなものを開発するのかを柔軟に考えながら進める
-
スプリント単位に本番環境へのリリースをするかどうかは、最初の計画時に取り決めを行うが、基本的にはリリース影響を鑑みまとめてリリースすることが社内では多い（ドメインの特徴もあり）
ウォーターフォール開発との比較
上記でアジャイル開発の特徴を述べました。ウォーターフォール開発では大規模、計画的に開発しますので、基本的には計画通りに開発していくことを是とし、開発していく中で要件の変更を行う際には「仕様変更」や「変更管理」と呼ばれるようなプロセスを経てプロジェクトへの影響確認を経て変更が取り込まれたり、取り込まれなかったりします。このプロセスはありつつも、プロジェクトマネジメントとしては、「仕様変更」や「変更管理」がなるべく発生しないように管理、各種ステークホルダーへの確認調整をしながら進めます。
実態としては「仕様変更」や「変更管理」が起きるものの、最初に立てた計画がそのままの場合、開発の時間軸と開発しているものの価値を図で示したものが以下のものとなります。
アジャイル開発の方から説明します。左下の開発開始時には右の方にある「当初見込」の星に向かって開発を進めます。一つ一つの矢印を一つのスプリント期間を示しているのですが、２つ目のスプリントを終えた時点のフィードバックと次のスプリントの計画時に少し方向性を見直して上向きになっています。これがアジャイル開発をして、短期間で繰り返し開発し、フィードバックを活かしてよりよく開発していくという醍醐味となります。当初見込の星より、アジャイル開発した結果の星の方が同じ時間で価値としては高いものになった、ということを示しています。
一方、ウォーターフォール開発の場合は黄色の矢印で示しています。最初から要件確定していて、開発するものに間違いが無いという前提を置いてしまっていますが、アジャイル開発した結果と同じものをウォーターフォール開発した場合は、紆余曲折せず一直線で開発を進めるということを示しています。先ほど述べた「仕様変更」や「変更管理」は起きないということも前提にしています。
このように最初から一番良い要件が分かるということは少ないので実態としては以下のような図の表現になります。頻繁に要件変更が発生するということを見越したケースに優位とも言えるものです。
まとめると、「アジャイル開発は効率的なのか？」という問いに対しては、
-
要件が確定していて、「仕様変更」や「変更管理」が発生しないということが見えている場合はウォーターフォール型で開発するのが効率的
-
要件の変更が見込まれる場合については、アジャイル開発のほうが効率的
となります。後者のケースをもう少し深堀して、効率的なケースを考えると
-
いくつかのスプリントを回している最中に、当初予定していたこの機能が不要ということが分かると作り物が減る
-
クラウドの利用やパッケージ、ツールなど経験していない技術の採用をする場合には、分からないものに対する見積もりは高くなるが、スプリントを回しながら習熟度が上がってくると見積もりが精緻になってきて、効率的に開発することが出来る
-
ウォーターフォール型開発だと、プロジェクトの後半にUAT(受け入れテスト）を行うことが多いが、そのタイミングで期待と異なると大きな手戻りになる。アジャイル開発の場合は初期のタイミングから動くものを確認するため、期待との相違があった場合でも早期に気づくことができる
といったものが挙げられます。
おわりに
上記の通り、アジャイル開発だと効率的というのはケースバイケースということを説明しました。アジャイル開発が後から出てきたものなので、新しいものはどんな観点でも良い、魔法の杖であるという印象で語っている人も時々いますので、このように記事にさせていただきました。
また本件もう少し難しい観点もあるので、観点だけ列挙しておきます。
-
アジャイル開発は体制を固定することが多いので、急激なメンバー増、チーム増を行うと開発スピードが安定するまでに時間がかかる
-
システムとしてはいつまでにリリースしたいが、スプリント毎の計画だけだとリリース日に対する確約をしにくい
-
同じシステム、同じチームでアジャイル開発とウォーターフォール開発をスイッチしながら進めることは難しい
最後は難しく感じられたかもしれませんが、社内でもアジャイル開発の事例や現場が少しずつ増えてきています。ご興味あれば採用ページから、カジュアル面談も可能ですのでお気軽にお声掛けください。
Discussion