毎年必ずどこかでウォーターフォールとアジャイルを対立させ「ウォーターフォールwwwww」と味付けしたツイートに待ってましたと総ツッコミが入るムーブがあるように思います。
今シーズンは下記のツイートがK点超えの大ジャンプを記録しました。
今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗は絶対に許されないと連呼する世界と、とっとと失敗しようぜと言う世界では、どちらが成長できるかは明らか。 https://x.com/toukatsujin/status/1863023816290762841
Xでは多方面から「いやいやいやいや、どんな世界線ですかそれ？！」と突っ込みが入った。失敗の許容度がゼロか100かってなんぞ？っていう感じ。そらそうよ。
これを受けて木村氏は「批判の中で呆れたのは、開発手法の話と取り違えた人が多すぎることだ。私のツイートは間違ってないし、そんなことを言ってるのではない」と第2ラウンドの鐘を鳴らされた。以下の記事になる。
最も重要なのは「とっとと失敗しようぜ」、アジャイル開発は人月商売の毒が回ったか | 日経クロステック（xTECH）
残念ながら、無料会員登録が必要だ。
私は心に刃を当て、無料会員登録という荒行を成し遂げ、ご高説を承りました。
その私が言う。読む必要はない。
雑にまとめた木村氏の主張
アペリティフにどうぞ。
ウォーターフォールが絶対に失敗するな、アジャイルがとっとと失敗しよう。その真意は以下にある。
開発手法の話ではなく、失敗を恐れずチャレンジし続けるマインドがあるかないか、それをビジネスモデルとして是としているかの違い。クラウドの上に自社プロダクトを開発して挑戦する会社は、新しいマーケットを開拓するために「とっとと失敗」して、正しく高速に新しいチャレンジをしている。アジャイルの骨子はここにあり、それを具現化したシンボルとして最たるものが、GAFAMに代表されるBig Techだ。
ウォーターフォールは工程の逆流が許されない。なぜなら、悪の組織ITベンダーは上意下達を前提に下請けに流す多重下請け構造を敷いており、そのために完璧な仕様が前提となるからだ。完璧な仕様、それはお客様の要望を全て取り入れたもの(御用聞き）。下請けの会社に入ったら、与えられた仕様に基づいて、なんのチャレンジもなく仕様を変えることもできず御用聞きのコードを書くようになる。私がそうだった。なにもいいことはなかろう。
そのような組織文化・マインドの違いについて論じているのに、開発手法が良い悪いを言っても意味がない。ウォーターフォール型がダメなのは論ずるまでもない、それぐらいわかれ〜
こんな感じ。
あ、そう・・・
古いネタで恐縮ですが、心の中のエリカ様が「別に・・・」って。生産的な教訓が何も無い。しょうもないITベンダーに就職したらすぐ逃げろはわかるけど、ウォーターフォールとアジャイルの理解は深まらない。
マインドを持ち出すから生産的な話にならない。ウォーターフォールとアジャイルとは開発方法論だと思いますよ。あくまでも。応用は効くかもしれないけど。
ウォーターフォールとアジャイルの対比に感じた「ボタンの掛け違い」を、自分なりに整理しました。メインディッシュをご賞味ください。
ウォーターフォール＝多重下請けの悲哀？
PDCAの「C」はリリースした機能を使うことで検証しないと意味が薄いのは、ウォーターフォールもアジャイルもない。水に砂糖を入れたら甘くなるぐらい自明。
そんな自明なこともできない多重下請け構造は何やねんって話は、工程の分断によるビジネスモデルの悲哀。ウォーターフォール＝多重下請けにすり替わってる気がする。ビジネスモデルの話とソフトウェア開発の方法論がぶつかるから、水掛け論に終わるように感じた。
人月という単位ほどわかりやすいものはないし、一人が一人以上稼ぐことはできないが損することもないので、合理性はあるんだよな・・・。プロダクトやサービスに昇華できない会社がうんちって断罪するのも、生産的な教訓がゼロ。
あるいは、ウォーターフォール＝一括請負？
一括請負＝ウォーターフォールなのかもしれない。お互い不幸だと。使ってみないとわからんから、と。納品のない受託開発やればいいじゃない、と。チーム貸しの契約で御社専用のITラボどうっすかのほうがええでしょう、と。
だがしかし、エンジニアをレンタルするという考えに至らない会社も多くあるように思われ、その場合は成果物責任を問えない契約は飲めませんという考えも、根強く残っていると思う。責任追わせられるの重要ですからね、発注する側は。開発◯万円・運用△万円で丸投げできる契約、求められません？現実はキビシー。
注文住宅の工事に入ってから、やっぱり住みづらいんで図面引き直せ。これはあり得ないんで勘弁してくれって話、至極全う。意味がわかりません。行間の誤解は双方にあるし、難しいよねその綱引き。その綱引き、もうええでしょうと申された！わかりみ！
ただ「これ合意したけど、そもそも仕事回んねーわ」っていう状況までこじれたら、我々IT側の運営責任も問われて然るべき。こんな状況になった免罪符にアジャイルを持ち出すやつはいねーよなぁ？！？！
僕のまわりだけかもですが、求められるのよ、請負。特に受託開発のようなオーダーメイド商品は。ウチも（求められて納められると判断したら）直で請負でやっています。高度な綱渡りを自分のリスクでやる変態がいてもええでしょう。頼むわ。
単純にPDCAの回し方の違い？ほんま？
アジャイルが機能単位で「P→D→C→A」を細かく回すとしたら、ウォーターフォールは全機能を対象に「PPPPP→DDDDD→CCCCC→→AAAAA」を回す前提になってる気がする。ほんまかいな？ 請負・委任関係なく、フェーズを切って設計してリリースすれば、進め方としては同質だと思われる。受託者と発注者のリスク配分の問題だけにも見える。
工程の逆流が起こってしまうと大変なことになるので、それを防ぐ方法は細かくリリースして軌道修正しましょう。だって全機能を一気に実装して調整できなかったら死ぬから、と。ただ、ウォーターフォールでアジャイル的な進め方が可能と考えると、両者を区別できる判断軸を僕はほぼ失った。識者の意見を頂戴したい。自分の理解が浅いのだと思う。
企業にITが根付く温度差、千差万別
納品のない受託開発やITラボ型開発を提案されて「いいっすね〜」となる会社は、かなりDXが進んでらっしゃると思う。これらのビジネスって、一言で言えば内製化支援。
今使っているソフトウェアやSaaSなどでちゃんとビジネスが回り、そこから継続的な改革が必要で自分たちで舵取りする合意が取れ、請け負うとかじゃなくてプロが助産してくれる環境がベスト。そういう意思決定だと勝手に推測する。「ビジネスを支えるITを内製して育てるための支援」という王道、素晴らしい。両手を上げて賛同します。アジャイルだぜ。
ITでビジネスを変えられる所に至ってない会社も当然多くある。エンジニアを雇用する意味を見いだせないので、ソフトウェアを調達する。その考えがあかん、と。発注者が勉強して賢くなれ、ITを根付かせる努力をせよ。仰るとおり。でも、どうやって？ 開発方法論に答えはないように思う。
ウォーターフォールやアジャイルという話で、企業のビジョンや組織文化などのソフトな話にどう影響を与え、事業会社にITを根付かせる一助になるのか。ビジョンや組織構造に目を向けるなら、そういう立ち位置で意見交換をしたいものだ。
仕様を調整する力がないなら、デスジャイル
本記事を書くのにアジャイル、ウォーターフォール、プロジェクトなどでツイート検索した。一定のボリュームがあったのが「きちんとウォーターフォールを経験したほうがいい」的なもの。その背景は、以下のようなものだと推察する。
何かの機能を実装する時に、ライブラリを入れてなんとなく動かすところから始める。ライブラリの背景やポリシーは理解せずに。DeepLinkやりたいって言われたんで脳死でFirebase Dynamic Link入れた、みたいな。
選定した理由が要件(制約)から逆算して詰めた結果じゃないから、応用が効かない。ひどい場合だと、テストケースをまともに作れない。コードを書いて動かすだけなら(AIが助けてくれるのもあるよね)、できちゃう。動きはするけど、自分で要望→要求→要件→設計→実装→検証→リリース→運用改善みたいな一連の流れを経験してないから、仕様を調整すべきというアンテナが育たないのかも。そういう、"ジュニア++フリーランス"に痛い目を見た話が昇華して、ウォーターフォールを経験せよにつながっているっぽい。
仕様を調整する力がないアジャイルは、デスジャイルだろ。北斗の拳の究極版読んでて、降りてきた。あべしジャイル→デスジャイル。冗談は置いといて、仕様の調整が機能しないスプリントが何本も走ったら負債一直線では・・・
先に要件ガチで詰めて調整しても死ぬときは死ぬ。ウォーターフォールとアジャイルどっちやねん以前の問題で、乱暴だけど「即死とゆるやかな死、どっちがいい？」という悲しい結末が。即死のほうが傷が浅いケースもあるからなぁ。
こちらが締めのデザートになります。
目の前のお仕事に向き合おう
ウォーターフォールの悪魔化とアジャイルの神格化、もうええでしょう。ウォーターフォールが日本的商慣習とくっついて悪魔化された一種の怪談、ネタで楽しむにしても、もうええでしょ！
目の前にある仕事、それが今のあなたの仕事の全て。僕もそう。
「このままやり続けて良いのだろうか」的な疑問もわいて来るはず。開発方法論やビジネスモデルの狭間に落ちて、うまくいかなくて、つまづくこともあるでしょう。思うようにはいかん。そこで止まらないこと。生まれて来た疑問を考えるのが、次の「目の前のお仕事」になる。それを片付けたら、質の違う課題が出てくる。そんなもん。
