上の記事を読んで、10年ほど前の鈴木雄介さんの以下の記事を思い出しました。
興味深いことに、タイトルは同じなのに中身はそれぞれ全く違う視点で書かれています。
上のSongmu氏の記事は、ウォーターフォールもアジャイルっぽく運用できるから許してあげて、というアジャイル目線の話。それに対して10年前に書かれた雄介さんの記事は実践的に使い分けやアレンジを論じられています。
アジャイルは価値観ですが、ウォーターフォールは開発手法(プロセス)です。
アジャイルとウォーターフォールを対比させることのおかしな点は、前項で書いた通りアジャイルは価値観ですが、ウォーターフォールは開発手法(プロセス)であるということです。直交概念であり、比較レイヤが誤っています。
引用：高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
ウォーターフォールにも価値観はあるし、アジャイルにも開発手法があり、ちゃんと理解していれば問題はありません。
引用：高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
いや、ちょっと待って・・・
アジャイル開発が定着して早うん年。
ウォーターフォールを知らない世代が増えてきて、それに合わせてアジャイルの理解も急速に劣化しているように感じます。
これって、初期のアジャイルが打破したかった状況なんだけどな・・・
この件について社内でシェアしたところ、さらに面白い意見が出てきました。
・ITのことを知らないマネジメントのプロがIT組織のマネジメントをすることはできるんだろうか？
・営業のことを知らないマネジメントのプロが営業組織をマネジメントすることはできるのか？
オライリーの『ソフトウェアアーキテクチャの基礎』に次のような記載があります。
・アーキテクチャには正解も不正解もない。あるのはトレードオフだけ
・あらゆる問いに共通する答えは「場合による」
・ググっても正解は見つからない
・ビジネス/文化/予算/期間/スキルセット/その他の要因に依存する
プロジェクトの進め方でも、各手法や実践的ノウハウや思想についても、どういった局面でどう選択するかは「場合による」だし、そのプロジェクトに合わせて組み合わせれば、アジャイルもWFも垣根なく扱えるように思えますね。
何事も、いくつかを扱い、比較し合うことで初めてそれぞれの良さ・辛さが具体的に見えてくる部分がありますし、そういった意味で「ちゃんとしたWF」の経験者が減ってきて、結果的にアジャイルの理解も甘くなってきそうな気もします。
プロジェクト管理ができていない状況で、アジャイルでやろうとしたら、炎上案件になりますよね。
さんの引用の通りで、そもそも手法には優劣がない。マネジメントをするのか、しないのか、じゃないでしょうか。
業績悪化中の会社で「マネジメントせよ！」の号令でやってることってただのマイクロマネジメント（マネジメントという言葉が使われてはいますが・・・）なので。
”事態が悪化するとマイクロマネジメントしたくなる人の心理”についても、どこかで議論してみたいです。
＜終＞
