アジャイルなのか、ウォーターフォールなのか、再び

　アジャイルなのか、ウォーターフォールなのか、という論争は場所によっては未だ活発で、その判断のヒントを求められることが少なくない。

　ケースは2つ。1つは、今までウォーターフォールのみで開発を行ってきた伝統的な大企業がいよいよアジャイルを考えるという局面において。もう一つは、アジャイルの経験はないがウォーターフォールをとにかく滅ぼしたいと躍起になっている状況において。

　前者においては、取り組もうとしていること、獲得したい成果によってどうあるべきかは変わるため、丁寧に考える必要がある。ああそうですか、では明日からアジャイルに取り組みましょう、というノリではない。

　後者の場合は、頭に血が上り加減なので、アジャイルにやることが目的になっていることただ指摘したところで受け入れ難い。こちらは慎重に議論を行う必要がある。

　つまり、どちらも手間はかかる。

　2つのケースでの、説明の仕方を考えていて「確実性をどこで確保するか」は一つ問いになるかもしれないと思い至った。ここでいう確実性とは、何を作るべきかが決まった状態のこと。その状態をどうやって確保するか？2軸ある。全体から決めるか、反復活動の中で決めるか。

　「全体から決める」とは、全体像をすっかり明らかにしてから決めること。「反復活動の中で決める」とは、全体像を捉えること自体が大きなコストとなるので、短い反復活動を繰り返す中で、その決定に至るというイメージ。2軸で、以下のとおりマッピングしてみる。

　まず極端な例で考えると、「全体」軸の極みは、反復活動を一切しないウォーターフォールということになる。「反復」軸の方は、全体計画を一切立てないアジャイルな開発。両者とも、理屈を組み立てる上であえて置いているエッジケースなので、現実にはあまりお目にかからないかもしれない。

　さて、この度合いで何を表現したいかというと、もちろん、両極端で捉えましょうではない。取り組もうとしていること、あげたい成果に対して、全体ー反復のライン上のどのあたりがフィットしそうか、見立てましょうということだ。

　こういう度合いの判断でいくと、忌み嫌われやすいウォータースクラムフォール（要件定義やシステムテストをフェーズとして置き、開発を反復に行う）も、組織やチームの進化の過程としては選択肢に入ってくる。

　スクラムは、AEPでいうリリースプランニングが公式には織り込まれているわけではないので、反復寄りに位置している。仮説検証型アジャイル開発は、中庸のイメージ。スクラムを織り込みながら、何を作るべきかは「仮説検証」という別の活動で一定の確保を行う。検証結果に基づいて、リリースプランニングも行う。

　あくまで経験則からの感覚。以前書いたnoteもご参考に。