アジャイル 開発とウォーターフォール開発には多くの相違点（同じところも違うところも）があります。
今回は、ウォーターフォール開発でよくある事象をアジャイル開発 で問題解決することを書きます。
ウォーターフォール開発とは、最初に立てた計画通りに、工程を一方通行で進み、最後にできあがったプロダクト（ソフトウェア）をリリースするという手法です。日本ではもっとも使われています。
プロジェクトの開始時点でおよそのシステムの概要（スコープ）、スケジュール、コストを決めるため、予算の計画も立てやすくステークホルダーもいつどうなるのか、の計画を立てやすいです。
よって、当初に立てた計画に通りに全てのことが進むのであれば最も効率が良いと言えます。
- 開発対象の機能が実際のユーザーに使われてビジネス価値を生む
- 適切なステークホルダーを適切なタイミング、人数でアサインできる
- 一度定義した要求、要件、設計は途中で一切変更されない
- 技術的に解決が困難な問題が発生しない
- 品質問題（機能、性能、セキュリティ、運用）が発生しない
- 想定外のリスク、問題が発生しない
- リリース時点（キックオフから半年〜数年後）の市場ニーズを正確に予測できる
- コストが予算内に収まる
- リリース後の運用がスムーズに回る
上記のような奇跡的な条件が揃っていれば何も言うことがありません。
そして、プロジェクトマネージャーはプロジェクトの成功に責任を持つために、上記を満たせるように奔走することになります。
比較的小規模（1ヵ月〜半年）の開発の場合は全て満たせることがあるでしょう。例えば新規のソフトウェア開発ではなく、エンハンス（小規模な改修）案件の場合は機能追加、改修程度で大きなリスクがない場合もあります。
しかしながら、数年にも及ぶ大規模開発の場合に、当初の計画通りに進む確率は天文学的低いです。
そして、経験を積み優秀なプロジェクトマネージャーほど鼻がききますので、ソフトウェア開発に入る前からどれほど危険であるか察することができます。そのタイミングでプロジェクトを中止したり、計画の見直しをしたり、参画を回避できればまだよいですが、組織的な理由で進まざるを得ない状況がよくあります。
そうして、無理な計画がある中で頑張った結果、下記のような問題が起こります。
問題を10個あげましたが、ソフトウェア開発ではどれもあるあるです。
無理な計画はやはり無理であるため、問題が発生してから途中で計画の変更が行われます。
要件定義が完了せずに長引いたり、設計が終わっていないのに製造工程に入ったり、途中で要件が変更されたり、テストで致命的な要件漏れや品質問題が発生したり。
このように逆流したり、川が1本から複数本になってくると、もはや一方通行のウォーターフォールとは言えない状態となります。嵐になってしまうとどこに流れて良いのかさえ分からなくなります。完全なウォーターフォールにすることは極めて難しいのです。
結果的にそのように問題が表面化して嵐になると、デスマーチと呼ばれる状態となり、人と予算が大量投入されて、スケジュールも延期してなんとかソフトウェア開発が完了するまで走り続けることになります。
その後、無事にリリースされて世に受け入れられてビジネス価値を生むことになればまだ良いですが、ニーズに合わずに使われなかったり、品質問題（特にセキュリティ）が発生し、最悪はサービスの中止に追い込まれることもあります。死に物狂いで頑張って社会に貢献できるもになればまだよいですが、そうならないと報われません。
そこで、それらをいかに解決できないか、カイゼンできないかと考えて生まれたのがアジャイル 開発です。
理想的なアジャイル 開発は要求からリリースまでを1〜2週間程度をひとつのイテレーション（スプリント）として、反復的に開発をします。
ウォーターフォール開発ではキックオフからリリースまでを半年から数年の1サイクルにするのに対し、そのサイクルをぐっと縮めて、何度も何度もイテレーションを回し、少しずつ開発していきます。
サイクル単位に計画の見直しを行うため、当初の計画に縛られることがありません。そのときそのときに最も優先順いの高いこと（最も価値を生むこと、または最もリスクを回避するために必要なこと）をするのです。
そして、定期的（毎月〜3ヵ月に1度程度）にこのままソフトウェア開発を進めるのか、方向性を変更するか、中止するかを判断します。
ウォーターフォール開発では品質、スケジュール、スコープが固定化されて、それに対してコストを算出します。
アジャイル 開発では品質のみが固定化されます。スケジュールとコスト（人✖️期間）は半固定です。スコープは最も柔軟に変更（優先順位の変更）されます。
高い品質が求められるのは何も変わりません。実際に世に出してユーザーに使われるものであり、裏でどのように開発されているかは関係ありません。例外的に実証実験のようなものは高い品質より、高い価値の検証が重視されます。求められる品質のレベルは実際にそれを使うひとがどれほど高い期待をするかに依存します。
社会的に影響の大きいソフトウェアに極めて高い品質を求められるのは当たり前です。
スケジュールとコストはある程度固定にしないと予算の確保ができません。ただ、何をどのくらい開発するのかは変化しますので、それに対応したスケジュールとコストにする必要があるため、半固定と考えています。
スコープが柔軟に変化することは、アジャイル 開発の大きな特徴のひとつです。
何を開発するのが最もユーザーに価値を提供できるかを検討しながら進めるため、機能の優先順位が毎週変化します。そして、スケジュールとコストが半固定化されているため、優先順位の高いものから開発し、低いものは開発されません。そうすることによって、価値を発揮するものにフォーカスし、無駄なことはしなくてよいことになります。
私が開発者（エンジニア）視点で特に良いと感じていることは、安定的にチームメンバーが維持されていること、ほぼ全工程で製造（コーディング）ができることです。
開発者はプログラムをコーディングすることが好きなひとが多いです。
要件の調整や設計についてはマチマチです。ただ、テストの打鍵が好きという人はとても少ないです。
多くのウォーターフォール開発では上流工程の人数が少なく、製造工程で一気に増やし、その後リリースに向けて人が減らされていきます。
そんなプロジェクトの都合の良いタイミングで大量の良い人材（プロジェクトのスキルに適応する人）をアサインすることは困難です。結局、人数は必要なためスキルアンマッチの人もアサインされますが、それは互いに不幸なことです。
そして、製造（コーディング）もこれまでの十分な背景を理解できないまま急かされてやることになり、好きでもないテストの打鍵もやらされ、そのテスト工程ではあまりスキルの向上も見込めません。
それに対してアジャイル 開発では、プロジェクトに対して安定的に参画しているために、誰の何のために開発しているかという背景（コンテキスト）を理解し、納得しながら進めることができます。好きな製造（コーディング）も常にでき、スキルの向上も見込めます。テストについては、基本的にテストコード（ユニットテスト）となるため、打鍵はツールが代わりに実行してくれます。
いかがでしたでしょうか。
ウォーターフォール開発の絵をご覧いただき、あるある、というワードはありましたでしょうか。そして、何か変えたい、カイゼンしたいと思いましたでしょうか。
アジャイル 開発の解決のところではあくまで理想的なことを書いています。そして、一気に完全体のアジャイル 開発であるキラキラとした世界にすることも、また奇跡的かもしれません。
切り替えるにしても、文化、システム、契約、人などの様々な問題があって一筋縄ではいきませんし、ウォーターフォール開発の方がよい場合もあります。
アジャイル 開発ではウォーターフォール開発を否定していません。
ただ、ウォーターフォール開発かアジャイル 開発かのゼロかイチかではなく、少しずつできるところから、よりアジャイル に変えていけたらと考えています。
アジャイル 開発ができる環境にできたら、その環境に入れたら、アジャイル って難しくないな、と感じると思います。
よりアジャイル な環境になってくると、環境や周りのひとにせいにしいたり、それらに対する愚痴も言えなくなってきます。その結果、チームと個人のリーダーシップやパフォーマンスが求められ、自己研鑽も必須となってきます。ひとことで言うと、さぼれなくなります。良い意味で、アジャイル は決して楽ではありません。
アジャイル によってプロジェクト上の多くの問題が解決でき、アジャイル であることが当たり前の世界になったら、やっぱりソフトウェア開発の本質である、アーキテクチャ、テクノロジー、エンジニアリングの高いスキルが今以上に叫ばれる時代になると思います。
さて、これからどんな未来になるか楽しみです。