アジャイルvsウォーターフォール、どちらが優れている?

という話題がX(旧Twitter)上で繰り広げられていました。

自分はウォーターフォールはもちろん、アジャイルの現場を経験しています。

そして、アジャイルの現場を経験した際は、現場のリーダーからアジャイルについての説明を、2~3日かけてレクチャーして貰いました。

そこで得られた知見を元にすると、何の前提も無しに「アジャイルの方がウォーターフォールよりも優れている!」という人達は、

アジャイルをよく理解せずに現場を炎上させてきた人達じゃないかと思います。

実際レクチャー受けている時でも、誤解している人が多いっていう話です。

レクチャー受けている時は、そういう誤解を全て解消してくださいました。

そもそもの話、

アジャイルという開発方式は存在しない

ウォーターフォールは、要件定義をしっかり決めて、それに従って後戻りがないように仕様、設計、製造工程まで進め、

テスト工程を経て「設計通りに動作している」ことを確認する開発方式だと思います。

これは要件定義からリリースまで十分にスケジュールがあるから出来ることなんですよね。

ただ、最近のこの世の中、この開発方式が通用するのは一部だけで、

最近では、社会のニーズに合わせて、ソフトウェアを開発し提供しなければならない。

という流れがある事から、アジャイルという考えが生まれました。

このリンク先にあるのがアジャイル宣言と言われまして、

https://agilemanifesto.org/iso/ja/manifesto.html

これをベースに様々な開発手法が生まれました。

当時の現場では、スクラム開発という体制を敷いていて、スクラム開発についての説明もきちんと行って頂けました。

アジャイルと言えばスクラム開発が代表例ですが、他にも様々な開発フレームワークがあるようです。

整理しますと、

アジャイル→ソフトウェアの状態

スクラム開発→アジャイルを実現するための開発フレームワーク

と言うふうに教えて貰いました。

そもそもウォーターフォールの開発をアジャイルで置き換えることが出来るのか?

プロダクトの開発には、何もない状態から初版のプロダクトを完成させる、というプロセスが必ず必要になります。

この初版のプロダクトがとても重要で、すでに完成されているプロダクトを流用するのであれば良いのですが、

たいていの場合は要件定義をしっかり検討し、きちんと動く物を完成させる、というこれまでと同じ作業が発生します。

この作業をアジャイルに置き換えることは出来るのでしょうか?

アジャイルでは、要件定義からリリースまでの短い(だいたい1週間~1ヶ月が一般的)サイクルを繰り返す事でプロダクトを完成させていきます。

このときの要件定義の内容はサイクル内で完成できる内容でなければならないし、そうしなければ開発体制は崩壊します。

そして、サイクルの最後では必ず動くプロダクトを完成させなければ鳴りません。

はい、ここまで聞いた正しい認識を持った技術者なら、こんなのアジャイルじゃ無理じゃん!と思うはず。

ウォーターフォールとアジャイルにはそれぞれメリデメがあり、プロダクトの正確に合わせて最適な手法を選択する必要があります。

単純にウォーターフォールvsアジャイル、どちらが優れているかという議論はただただ不毛でしかありません。

もう一回アジャイルという物を学び直してください。

我々が経験したアジャイルの現場では、その特徴を十分に理解しているため、

プロダクトの初版リリースまではウォーターフォールで、それ以降のアップデートはアジャイルで開発を行っていました。

これはウォーターフォール、アジャイルの特徴を生かした最適解であると思っています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください