アジャイル開発の浸透？なんだそれは。
アジャイル開発という概念が世に出て二十余年（2001年「アジャイルソフトウェア開発宣言」による）、最早、この技術も最新とは言えない、成熟したものとなりました。あなたの職場でも「アジャイルに進めよう」的な、凝り固まらず柔軟なプロジェクト体制にして行こうという流れ、プロダクト開発の長大化を防ぎアウトプットを細かく出していこうという意識変革が内外から求められているかと思います。
しかしプレイヤーとしての皆様は、とはいえ作るものは変わっておらず納期が決まっているので大変になるだけ、だとか、現場ボトムアップな提案は通らずトップダウンにやることが降ってくるからやる意味なくね、だとか、果ては作るもの・仕様が決まってないけど予算がついたからいい感じにアウトプット出してね、の意味だとか、都合よく「アジャイル」を使われて疲弊することもあるでしょう。多くは会社の通例や予算検討の流れがいまだにアジャイルに沿ってないからであり、一社員がなんともできないところもあり歯痒いものですね。いいの作ることは保証するからお金つけてくれよーー（泣）
うちの会社はアジャイル無理なんで…
とはいえお金は大事なんですよ。いかなる開発も「先にお金・人的コストを払って、後の利益・コストメリットを受け取る」ための手段なので、「何が出来るかわからんけどお金はください」は通らない。
だから、先に要件定義してくれないならアジャイルはうちの会社でやれないんだよねー、、、という甘えしがらみはいくつも聞いてきてて、まあその通りではありますが、そこは一旦頭まっさらに、どうしたら御社でもアジャイル開発に取り組めるか、想像してみましょ。
いくつかの事例を見てきて私が思うのは、アジャイル開発を開始する（≒お金を貰って開発する）にあたってお偉方とある程度のコミットメント（期間までにこれやるって話）を少なからずやらざるを得ないとは上記背景とかからも理解するんだけど、そこで確約するものがよくない例、多いんですよね。つまり、何を作るか（What）、どういうアーキで作るか（How）、挙句、いつ（When）までに完成するかを決めにいく方法。ここってアジャイル開発していくと一番変わる可能性が高いとこなんですよね。
なので、理想的には、ペルソナは誰か（Who）、何故作らないといけないのか（Why）、そのうえで、作るものではなく（not product）どういったことを目標（KPI）として評価するかを握りに行けるといいんですよね。まあそれができたら苦労せんわい、という声も聞こえてこなくもないですが。
ウォーターフォールはキメゴトを先にするスタイル
さて、絵空事は終わりにしてそれでも色々な都合上、ウォーターフォールで！ってケースもあると思うので、じゃあ折角ならいいウォーターフォール開発にしたいですよね。
まあもちろん案件別の向き不向きとかそういう話もあるんですけど、でもやることはアジャイルだろうと、ウォーターフォールだろうと実は本質あまり変わりません。そもそも、プロジェクトとは「何が課題か」、「何が制約・障害か」を常に切り分けしつづけていくプロセスおよびそのための検証作業なのですから。
ウォーターフォールは先に確認することを重視します。先にプロジェクトのモヤモヤしたところを明確化することにより、次の工程で手戻りなく進められることを期待して動きます。
アジャイルも基本的には先に確認しますが、明確化はそこまで強く求めません。代わりに多少の手戻りを許容し、再度課題・制約・障害を確認するフェーズに戻ることを恐れません。
私の理解するかぎり、ウォーターフォールとアジャイルの違いはこれだけです。
高度なウォーターフォールはアジャイルに似る？
それなのにウォーターフォールは要件定義が一苦労、なんて言われます。いやしかしながら、アジャイル開発でも要件を全然決めずに、少なくともDevメンバーが思い思いに勝手に作るなんてことはまずありえません。アジャイルでも要件定義（にあたるもの・行為含む）はなんらかの形で実施されますが、大きな違いは、その行動が都度実施されることです。先ほどの通り、やり直しを許容するわけですね。
さて、一般的なウォーターフォールの作業には順番はあります。まずは大きな要求の確認、そして順を追って要件定義、詳細設計とつめていきます。
何故、このステップを踏むかと言えば、やっぱり細かいことは始めからは見えないからですね。だから、外堀から決めていって、これはスコープ外である、このケースは対象外としてよい、と検討を深めていき、ようやっと細かいユースケースへとフォーカスできるようになるわけです。
ここで、ちょっと考えてほしいのは、このやり方ってとてもアジャイルなんですよ（う～ん哲学ワード）。
何が言いたいかって言うと、ウォーターフォールってやり直しは即プロジェクト遅延につながるから避けたい、そして、本当は最終的に策定したいのは開発そのものの仕様、だけどいきなりそこからは着手は出来ない、そのゴールに一番最短で近づきたいからこそ、外堀から決めていくしかないーーー結果、わからないからこそ、できることから着実に取り組む。ほら、これってアジャイルでしょ。
要はスタンスの違いってやつね
はい（完）。
ウォーターフォールは正しい中身（プロダクトの完成形）がわからないからこそ、外側から中へぎゅっと閉じ込めていく作業。アジャイルもまた正しい中身（プロダクトの完成形）がわからないからこそ、今できる中身を作りながら外枠を見つけに行く作業。方向性の違いとも言えそうですね。
私の業務は外部の会社様からアジャイル開発案件をいただいたあと、企画側のアシスタント役としてプロジェクトに入っていくかたちが多く、内容によってその都度求められる動き方が変わってくるんですよね。時にごりごりウォーターフォールな出力も求められるわけです。ただ、そのとき「アジャイルじゃないと嫌！」なんて言ってられませんので、そのときに考えるのは今まで書いてきた、ウォーターフォールはスタンスの違いでしかないってこと。本質を忘れなければきっとウォーターフォールだってアジャイルマインドで進められるんよ！