一石投じる目的の記事。
？？？ちょっと何言ってるかマジでわかんない。規模もドメインの種類も契約もチームの成熟度もガン無視で何を議論出来るの？
作れるというのは別に嘘でもなんでもないだろ…
それでもみずほ銀行は稼働している
いろいろ無視して単純化しすぎの二項対立だし、定量的な根拠みたいなのが全然出てこないし、一石投じたいらしいが何にめがけて石投げてるのかまったくわからない記事。職場の不満なら上司に言うべき。
現場同士でｷｬｯｷｬするならこれでもいいけど、一石投じたいなら推進してる人の視点からも考える必要があると思う
経験的な話のみで自説を展開する割に、批判的な意見は検証不能というのなんかダブスタだな
ウォーターフォールを謳った隠れアジャイルよりも、アジャイルを謳った隠れウォーターフォールの方が圧倒的に多いんじゃないのかな？ 違うのかな？
現場感覚の「現場」ってどこ？
ウォータフォールには少しでも手戻りが発生したら失敗、という定義があるのだろうか。状況によっては、より良い手法もあるだろうけど、幅広い範囲でgood enough な手法だと思う。
そのアジャイルは隠れウォーターフォールではないのか？
同じ論調でアジャイルの嘘みたいな話もでっち上げられるな。小さいウォーターフォール繰り返してマイクロマネジメントしてるだけの糞アジャイル現場結構あるだろ
ウォーターフォール憎しで冷静さを欠いた記事。一旦落ち着けよ。
検討時「こっちのが実績あるしリスクが少ないから」という選択した後、問題が生じると「リスクが無いって言ってたのに」っていうタイプの人かな？
（読まない）ちゃんと準備できるなら当たり前に作れるからだが。／「ソフトウェア」じゃなく「システム」に変えて、「短期で」「一発で」とか追加すればまぁ嘘になる。
こういった言説の方が注目を浴びるからってねー。宗派論争を避けると言いつつ嘘と断定する根拠が弱すぎるだろう
極論や断言はPV稼げるのかな？逆に警戒してみないけど。
「仕様変更プロセスもウォーターフォールに織り込まれたプロセス」と捉えればこの記事は間違っているし、「最初に決めた仕様で最後までいく」という思想に誤謬があるという指摘ならそれはそう
ウォーターフォールの原型と言われるRoyceの論文では明確に繰り返しが謳われてたし、現実にはWFと反復型、アジャイルの間のバリエーションでプロジェクトに応じて最適化されてる。そこを理解せず論じるのは不毛。
工程内のタスクを細かく細かくしていけばそりゃプロトタイピングとかアジャイル的な動きになるでしょ
ウォーターフォールは手法の話で、実務で100%その通りにできることを前提としてないでしょ。そのプロジェクトに応じて柔軟に対応するのは当たり前だよ。
どうしたどうした
過去の記事も併せて読むと、これはAIによる自動生成文のように思えてくる…
他の記事も見たけど、「なぜ、〜か？」ってタイトルめっちゃ多い
一回でも遡ったらウォーターフォールじゃないじゃん！って言うならそうかも知れない。そこにこだわる意味はあんまり分からないけど。
工程開発をウォータフォールってまとめてだだけだし、ウォータフォールも仕様変更できるし、アジャイルは仕様変更の道具じゃないので、それをアジャイルなんて言葉で呼ぶなといういつものやつ。/ 車載 ...察し
業界によって色々違うと思う。もっと具体例に踏み込んで、組み込みならではの視点を見せてほしい。自分は知らないのでそれなら興味ある。
何の主張なのだろうか。ウォーターフォールに見えててもアジャイルやってますとか言っても良いの？知ってる言葉で自分の知らない概念を話されているような感覚。仕様変更はそりゃあるやん？
SPAM
作れるぞ。工程戻ったりするだけで。
このアカウントの投稿見ると殆どのタイトルが「なぜ」で構成されてるな。いわゆるview稼ぎのお作法を延々と続けてるアカウントなのでそれ以上の意味はなさそう。
車載組込系らしいので業務システム受託とはいろいろ違う事情がありそう。大昔は既存の手作業の事務処理をIT化する案件が主流でアーキテクチャの選択肢も少なくゴール（≒仕様）がある意味シンプルで明確だった。
明日また来てください。本当のウォーターフォールを見せてあげますよ。
わたあめくらいフワフワしてんな
「作る」というのをこの人みたいな特殊な意味で使う人はほとんどいない。トンデモ
世の中にはアジャイルという名でミニウォーターフォールを繰り返している人もいるし、別に二項対立ではないよね。現場目線というのであれば、完成して動くのが正義やろ
「ウォーターフォールなんて効率悪いぃぃ！」、ワイ「アジャイルなんて大体が行き当たりばったりなだけやろ、開発手法なんてプロジェクトの性質や規模による」。
？？何と戦ってるのか分からないけど、組み込み、製造業あたりの人がターゲットなのかな…？
作れりゃ何でも良い。AIの発展でアジャイルも時代遅れになるだろうし。あと事業規模にもよるよな。数百人規模の開発でウォーターフォール採用するのは全然ありな判断だろ。
マネーまで流れてナンボ
むかしは計算機資源が高価で設計もフローチャートもコードも紙に書いて机上テストを通ってから入力してコンパイルしてたから動かしながら作るなんてとんでもなかったってことを知る世代の割合も減ったんだろうな。
アジャイル宣言と原則はこのような問題意識、ウォーターフォールへの誤解が出発点だったんだろうけど、さすがに多くの開発現場はもうそこは通過済みだと思う。「車載組込み」がそうではないってことなのかな…。
ウォーターフォールのプロジェクトなんて見たことないのだけれど、分野によっても違うのかな
くだらね。
ソフトウェア工学、ISO、RUPは読んでるのかな？知らんけど
モダンな手法ではなくなったというだけで「嘘」ではないだろ。実際、古の現場ではウォーターフォールで開発してリリースしていたわけだし。まあ、覆水が盆に返ったりはしていたわけだが……。
じゃあどうやって作ればいいのかって展開がなく、ただ批判しても何の意味もない気がするが。
10年前にもそういう議論があったような……
厳密に定義通りに運用しなきゃダメなら、アジャイルだろうがウォーターフォールだろうが規模が大きくなりゃ、あらゆるソフトウェアがつくれないって話になるよ。人が増えれば手順より楽を選ぶ人は必ず出る。
まず、そんなにアジャイルがやりたければ自分だけでやれ。下請を巻き込むな。請負契約で責任逃れしたいのならウォーターフォールが唯一の解となる。そしてそれは長年行われてきたことだ。
アジャイルなら作れるってのもたぶん嘘やで
きちんとしたウォーターフォールは割とアジャイルっぽくなる という話をしてた
せやなとは思いつつAI文体っぽさが
刺激的なタイトルで注目を集めるアテンションエコノミーの手法。
主張がぼんやりしていてよく分からないな。
顧客の要望や仕様変更というメテオフォールにも耐えて作られている現場もあるから、嘘よりも現実の方が厳しい
ビルドアンドスクラップの事をアジャイルっていうな
ウォーターフォール（手戻りなし）で進められるかどうかだと思う
この人の脳内で展開されているウォーターフォールは実在しないだろう。実際は、手戻りが発生したら誰かがその費用を払っているだけだ。極端に言えば最初から顧客が払う契約になっているのがアジャイル。
アジャイル信者は黙れ
アジャイルって、なんか『毎日毎週進捗管理しよう』という古来からの運営に名前を付けただけに見える。
出た、極論。こう言う輩がいるから宗教戦争みたいになるんだよ。世の中がソフトウェアの世界だけって思ってる？
まあいまだにWFでやってるとこだが、「前の工程を完全に終わらせてから次の工程へ」を厳密に守れたことなどまあない(よっぽど単純か小さいか)。記事のとおり、ビジネス都合で使われてる認識
最後はPMが滝に飛び込むのでウォーターフォールと言います
責任持って仕事をしない奴の戯言。作業内容によってウォーターフォールがアジャイルの何が最適なのかは変わってくる。すぐイチかゼロかにしたがる。オワコンとか言ってマウント取りたいだけだろ。
zennも変やな増えてきたなぁー。なんか異常に偏執的なやつが多いイメージ
ウォーターフォールが向いてる、というか、そうでないと進められない案件があるのよ。特にマルチベンダーの大型案件とか。と思った車載組込屋さんだった…。釣られた。
そりゃ計画通り実行できた完璧な開発なんてないでしょう。どういう計画の元で開発を進めるかって話なんだから。
じゃあそれをなんて呼ぶの？
車載組み込みもベンダー間調整、仕様確認は必要だから、フィードバック型ウォーターフォールになるんじゃないの? インクリメンタル開発はアジャイルだけじゃないし
当たり前だが上流が濁流だとゴミの山になる で実際大多数のそんな金ない開発は濁流のケースが多い
車載組込が専門らしいが、車載のソフトウエア開発プロセス認証はウオーターフォールモデル前提だろうにどうやってるんだ？ と思って記事一覧を見たら…。基本的に論点先取芸の人なのか。たぶん深く考えてないと思う
“言説は、方法論の正しさではなく、神話の正体としての物語です。” 人間味があっていいな
工程の途中で変更が入る事をアジャイルとは言いません。工程が要件定義まで巻き戻らないようならウォーターフォールのプロセスの範疇です／車載やってるようなのでWFに親でも殺されたのだろう
まぁ、言いたいことは判るし、厳密な議論でなく「グチ混じりの雑談なら十分題材としては成り立つ話」だとおもうけどなー
人月の神話
ウォーターフォールの対義語はアジャイルじゃないと思ってる。不確定要素をお互いに許容できるように調整できるような取り組みがアジャイルだと。スプリント計画とか言って実装内容決めるのはアジャイルではない。
こういうの読むと『AIが書いたみたいな文章だなー』と感じるのはなぜ？
ウォーターフォールってシャーロックホームズとかサムソンティーチャーのやつでしょ。
タイトルが浅慮すぎて笑っちゃったw
なんか過去の投稿見ると方向性がバラバラなのかなって感じたけど、どうなんでしょう。このぐらい扱えるんですかね。
タイトルの日本語の意味がわからんのだが
ウォーターフォールは完璧ではないが、きちんと使用凍結した証跡があると裁判で有利。アジャイルだとぜんぶ責任取らされるのでは
こういう整理論って何の意味があるの？どうでもよくない？
こういう整理論は個人でやるのは良いが、辺にグループ作ったり、コミニティや団体作って布教するのは権力欲だと思う。綺麗に分かれるものでもないし、対立煽るのは虚栄心と権力欲からだと思う。全く意味がない。
この観点は面白いな。日本的な職分の分化を重視しない世界でだけウォーターフォールの神話が維持されているわけだ。職分がはっきりしている世界だと、単に破綻するからビジネスモデルが転換しやすい。
去年「ウォーターフォール型で社内サービス作りたい」ってオーダーが来て技術者代表して参加したけど「依頼者に開発力がないと無理ですね」で終わったから、ウォーターフォール型でできるのは技術者だけだなと思う
前提とかふっとばした雑な考え方で恣意的に結論を決めるのは、ほとんど嘘と変わらない
逆になんでIT業界ではウォーターフォールを守れないことが許容されてるのかよくわからないんだよな、土木なんか遅延要因や問題が大量に発生するけどウォーターフォールでマネジメントしてるわけだし
あなたがウォーターフォールでソフトウェアを作れない程度のスキルスタックという事
明らかにAIで組み立てた主張なのに、論理構造が破綻していて結論ありきになってる。特定の意向に沿ったドキュメントをビルドしただけでその内容を検証するテストがされていない。 / https://b.hatena.ne.jp/site/zenn.dev/pdfractal
ウォーターフォールじゃないとヤバいシステムも結構あると思う。
“「ウォーターフォールでソフトウェアは作れる」” が神話だとして、じゃあアジャイルなら作れますなどという奴はペテン師だよ。
「心理、組織、歴史、そして認知の観点から整理します」この定型感ときたら…「「ウォーターフォールでソフトウェアは作れる」という言説は、方法論の正しさではなく、神話の正体としての物語です」これもなかなか
訳→後戻りしたらアジャイルだろ/真面目に読んでないので悪しからず
なぜウォーターフォールでソフトウェアを作れるかと言うと、プロジェクト管理が出来るから。と思っています。逆に言うと、高度な柔軟性を維持しつつ臨機応変に対応すればウォーターフォールは不要です。
車載組み込みのソフトウェアをウォーターフォールではない何かでどう開発しているのか書いてほしさ
ちゃんとしたウォーターフォールで開発できない人はアジャイルだろうがなんだろうがロクなものを開発できないと思うけどな
組み込み系の人か、大規模開発は素人なのがありあり。ウォーターフォールはクソだけど、他のどの方法よりマシなだけ。数百人のアジャイルとか、管理手法すら無いじゃん。
様式に基づいてドキュメント創るならWF方式が現場が楽ちんだっただけや。仕様書も現場検収まで済んだ後に作れば手戻りすくない。で、そのDoc持って横展しようとして事故る。AIプロンプトも同じことおきそう
全体としてはまさしくそうなんだけど「しかしこの乖離は、報告書や成果物には残りません」と言われるのはちょっとな。要件追加や変更は厳密に記録に残すでしょ
15年前の記事かと思ったわ そもそも今どきそんな事言うやついねーだろ
最大の収穫は未だにウォーターフォールはクソって言っておけばこんなにPVが稼げてしまうという事実の発見そのものだろう
生成AIの登場当初に「きちんとしたプロンプトを書かないと動かない」と言い張っていた人達もウォーターフォール信者なのであろうなあ。
なんか嫌なことでもあったのかい？/圧縮アルゴリズムみたいな研究が必要なものはともかく、ウォーターフォールが前提になるのは開発者が俯瞰できるレベルのものだよね。要件を決めて値段をつけるSIerには重要だよ。
またこの人か。次からはもうみんなブクマしなくて良いのでは？
昔はテストも簡単じゃなかったからウォーターフォールで作れるソフトしか作れなかったんだぞ、
うまくいったプロジェクトをアジャイルって呼んで、うまくいかなかったプロジェクトをアジャイルじゃない奴って呼ぶ人。真のスコットランド人。
むしろウォーターフォールであるべきだと思う。超大手でも総合試験最終日に仕様変更が当たり前のように行われている。ビル完成間近に1階を改造するようなものだ
初手ウォータフォールで作っても改修や運用はウォータフォールで回してないからな。
主張は同意できる部分もあるけど書き方が良くないというか、これだと議論が深まる前に読者が拒否反応を起こしてしまうのでもったいない
答え「実際にそうやって作られてきたから。」
？？？？
こういうこと言うと身も蓋もないんだけれど、世の中に出回っているウォーターフォールとアジャイルの対立軸で理解している人って、サイクル（スプリント）が長いか短いかくらいの違いしかない認識という気がする。
最初に作るべき仕様を決めて契約の区切りを作る。変更すべき仕様が出来たら追加契約をする。絶対に最初に決めた仕様で作りきるのではなく契約を区切って、変更点を分かりやすくして揉めないようにしているだけ。
"検証不能な主張であり、成功の定義が曖昧だからです。" それはまず自分に言うべきでは…
間違えない神の手法だけど、実際成功してたのもあったしなあ。
嘘じゃなくて前提じゃないの？ 藁人形論法にみえる
計画が実行段階で修正されるなんてソフトウェア開発に限らず当たり前の話だと思うが…
ソフトウェア以外の歴史にもよく出てくる「現在の前提や認識を基準に過去を語る・貶す」典型的な例。時代ごとの状況に応じてそのときの最適を選んできたにすぎない。そしてそれは今後も変わり続ける。
15年くらい前？に活発だったこの手の言説がやや下火になってるのはアジャイルが当たり前になったからかむしろ逆か。
ソフトウェアを作れるなんて嘘はおこがましいという話かしら
うーん？なんかエビデンスもなく否定してるような。
嘘じゃないでしょ。ウォーターフォールは絶対手戻りしてはいけないってのが嘘なだけで。ただ、当初の契約内容と、あまりにずれたときは専門家として、顧客に真正面から指摘しなきゃいけないのはいまだに嘘だろと思う
コメ欄「天才数人＋AIで設計と実装を貫通させる方が合理的」なぜその神話は信じてしまうのか・・・トラックナンバー減らしてどうする
AI臭すぎん？
"仕様溶解が起きていたにもかかわらず、それは公式記録には残りませんでした" 計画変更はプロジェクト管理において普通に発生する、それに対する追加予算も正常な経営判断。公式記録=議事録が無い筆者の世界が異常
昔ウォーターフォール開発やってたけど、詳細設計書が出来上がる時にはほぼ実装も終わっていた感じで、詳細設計レビューはほぼ実装レビューみたいな感じだったなあ
手戻りありならできるかも
ウォーターフォールと言いつつ随所でアジャイル的な手戻りは起きているし、アジャイルと言ってもウォーターフォール的な基礎を抑えてないと単なる行き当たりばったりになりプロジェクトが破綻する
読まなくていいな。
この手の言説で定量出して来る人ナカナカいないが、成果主義のない時代でFが言語の差での統計取ってたんよなあ。／神話の代わりに偽預言者出て来ても仕方ないのよ。
なおブクマ時点で2026年（令和8年）。2000年前後から頻繁にWF（ウォーターフォール）はクソ、なんちゃってWF、提唱者の言うWFと中身が異なると言わ続けて四半世紀が過ぎちゃった（近年はめっきり減ったが）。
何でこんな嘘を書いてるのか理解できない、ライターはどんな開発経験があるの？それとも炎上商法？これを掲載する側もまともじゃないよね（笑）。ド素人の戯言を発信するな！
今から考えると、昔のソフトは笑っちゃうほど単純だったんだよな。
これ未だに教育で教科書で学ぶからだと思います。
何を理想とするかって話なのかな。多重組織構造で上から落としていくのを前提とするWFと、最初から少しずつ動くものを積み上げてチーム開発しましょってアジャイルの違い、くらい？
こう言うのAIなのかな。所々強調文字謎だし。煽ってバズりやすい文章作れとかの指示なんだろうか
何か辛いことがあったのだろう。無事解決しますように。
ウォーターフォールだからダメ、みたいなのも根っこは一緒でしょ。適材適所でしかない
なぜ、「ウォーターフォールでソフトウェアを作れる」という嘘を信じる人が世の中にいるのか？
一石投じる目的の記事。
？？？ちょっと何言ってるかマジでわかんない。規模もドメインの種類も契約もチームの成熟度もガン無視で何を議論出来るの？
作れるというのは別に嘘でもなんでもないだろ…
それでもみずほ銀行は稼働している
いろいろ無視して単純化しすぎの二項対立だし、定量的な根拠みたいなのが全然出てこないし、一石投じたいらしいが何にめがけて石投げてるのかまったくわからない記事。職場の不満なら上司に言うべき。
現場同士でｷｬｯｷｬするならこれでもいいけど、一石投じたいなら推進してる人の視点からも考える必要があると思う
経験的な話のみで自説を展開する割に、批判的な意見は検証不能というのなんかダブスタだな
ウォーターフォールを謳った隠れアジャイルよりも、アジャイルを謳った隠れウォーターフォールの方が圧倒的に多いんじゃないのかな？ 違うのかな？
現場感覚の「現場」ってどこ？
ウォータフォールには少しでも手戻りが発生したら失敗、という定義があるのだろうか。状況によっては、より良い手法もあるだろうけど、幅広い範囲でgood enough な手法だと思う。
そのアジャイルは隠れウォーターフォールではないのか？
同じ論調でアジャイルの嘘みたいな話もでっち上げられるな。小さいウォーターフォール繰り返してマイクロマネジメントしてるだけの糞アジャイル現場結構あるだろ
ウォーターフォール憎しで冷静さを欠いた記事。一旦落ち着けよ。
検討時「こっちのが実績あるしリスクが少ないから」という選択した後、問題が生じると「リスクが無いって言ってたのに」っていうタイプの人かな？
（読まない）ちゃんと準備できるなら当たり前に作れるからだが。／「ソフトウェア」じゃなく「システム」に変えて、「短期で」「一発で」とか追加すればまぁ嘘になる。
こういった言説の方が注目を浴びるからってねー。宗派論争を避けると言いつつ嘘と断定する根拠が弱すぎるだろう
極論や断言はPV稼げるのかな？逆に警戒してみないけど。
「仕様変更プロセスもウォーターフォールに織り込まれたプロセス」と捉えればこの記事は間違っているし、「最初に決めた仕様で最後までいく」という思想に誤謬があるという指摘ならそれはそう
ウォーターフォールの原型と言われるRoyceの論文では明確に繰り返しが謳われてたし、現実にはWFと反復型、アジャイルの間のバリエーションでプロジェクトに応じて最適化されてる。そこを理解せず論じるのは不毛。
工程内のタスクを細かく細かくしていけばそりゃプロトタイピングとかアジャイル的な動きになるでしょ
ウォーターフォールは手法の話で、実務で100%その通りにできることを前提としてないでしょ。そのプロジェクトに応じて柔軟に対応するのは当たり前だよ。
どうしたどうした
過去の記事も併せて読むと、これはAIによる自動生成文のように思えてくる…
他の記事も見たけど、「なぜ、〜か？」ってタイトルめっちゃ多い
一回でも遡ったらウォーターフォールじゃないじゃん！って言うならそうかも知れない。そこにこだわる意味はあんまり分からないけど。
工程開発をウォータフォールってまとめてだだけだし、ウォータフォールも仕様変更できるし、アジャイルは仕様変更の道具じゃないので、それをアジャイルなんて言葉で呼ぶなといういつものやつ。/ 車載 ...察し
業界によって色々違うと思う。もっと具体例に踏み込んで、組み込みならではの視点を見せてほしい。自分は知らないのでそれなら興味ある。
何の主張なのだろうか。ウォーターフォールに見えててもアジャイルやってますとか言っても良いの？知ってる言葉で自分の知らない概念を話されているような感覚。仕様変更はそりゃあるやん？
SPAM
作れるぞ。工程戻ったりするだけで。
このアカウントの投稿見ると殆どのタイトルが「なぜ」で構成されてるな。いわゆるview稼ぎのお作法を延々と続けてるアカウントなのでそれ以上の意味はなさそう。
車載組込系らしいので業務システム受託とはいろいろ違う事情がありそう。大昔は既存の手作業の事務処理をIT化する案件が主流でアーキテクチャの選択肢も少なくゴール（≒仕様）がある意味シンプルで明確だった。
明日また来てください。本当のウォーターフォールを見せてあげますよ。
わたあめくらいフワフワしてんな
「作る」というのをこの人みたいな特殊な意味で使う人はほとんどいない。トンデモ
世の中にはアジャイルという名でミニウォーターフォールを繰り返している人もいるし、別に二項対立ではないよね。現場目線というのであれば、完成して動くのが正義やろ
「ウォーターフォールなんて効率悪いぃぃ！」、ワイ「アジャイルなんて大体が行き当たりばったりなだけやろ、開発手法なんてプロジェクトの性質や規模による」。
？？何と戦ってるのか分からないけど、組み込み、製造業あたりの人がターゲットなのかな…？
作れりゃ何でも良い。AIの発展でアジャイルも時代遅れになるだろうし。あと事業規模にもよるよな。数百人規模の開発でウォーターフォール採用するのは全然ありな判断だろ。
マネーまで流れてナンボ
むかしは計算機資源が高価で設計もフローチャートもコードも紙に書いて机上テストを通ってから入力してコンパイルしてたから動かしながら作るなんてとんでもなかったってことを知る世代の割合も減ったんだろうな。
アジャイル宣言と原則はこのような問題意識、ウォーターフォールへの誤解が出発点だったんだろうけど、さすがに多くの開発現場はもうそこは通過済みだと思う。「車載組込み」がそうではないってことなのかな…。
ウォーターフォールのプロジェクトなんて見たことないのだけれど、分野によっても違うのかな
くだらね。
ソフトウェア工学、ISO、RUPは読んでるのかな？知らんけど
モダンな手法ではなくなったというだけで「嘘」ではないだろ。実際、古の現場ではウォーターフォールで開発してリリースしていたわけだし。まあ、覆水が盆に返ったりはしていたわけだが……。
じゃあどうやって作ればいいのかって展開がなく、ただ批判しても何の意味もない気がするが。
10年前にもそういう議論があったような……
厳密に定義通りに運用しなきゃダメなら、アジャイルだろうがウォーターフォールだろうが規模が大きくなりゃ、あらゆるソフトウェアがつくれないって話になるよ。人が増えれば手順より楽を選ぶ人は必ず出る。
まず、そんなにアジャイルがやりたければ自分だけでやれ。下請を巻き込むな。請負契約で責任逃れしたいのならウォーターフォールが唯一の解となる。そしてそれは長年行われてきたことだ。
アジャイルなら作れるってのもたぶん嘘やで
きちんとしたウォーターフォールは割とアジャイルっぽくなる という話をしてた
せやなとは思いつつAI文体っぽさが
刺激的なタイトルで注目を集めるアテンションエコノミーの手法。
主張がぼんやりしていてよく分からないな。
顧客の要望や仕様変更というメテオフォールにも耐えて作られている現場もあるから、嘘よりも現実の方が厳しい
ビルドアンドスクラップの事をアジャイルっていうな
ウォーターフォール（手戻りなし）で進められるかどうかだと思う
この人の脳内で展開されているウォーターフォールは実在しないだろう。実際は、手戻りが発生したら誰かがその費用を払っているだけだ。極端に言えば最初から顧客が払う契約になっているのがアジャイル。
アジャイル信者は黙れ
アジャイルって、なんか『毎日毎週進捗管理しよう』という古来からの運営に名前を付けただけに見える。
出た、極論。こう言う輩がいるから宗教戦争みたいになるんだよ。世の中がソフトウェアの世界だけって思ってる？
まあいまだにWFでやってるとこだが、「前の工程を完全に終わらせてから次の工程へ」を厳密に守れたことなどまあない(よっぽど単純か小さいか)。記事のとおり、ビジネス都合で使われてる認識
最後はPMが滝に飛び込むのでウォーターフォールと言います
責任持って仕事をしない奴の戯言。作業内容によってウォーターフォールがアジャイルの何が最適なのかは変わってくる。すぐイチかゼロかにしたがる。オワコンとか言ってマウント取りたいだけだろ。
zennも変やな増えてきたなぁー。なんか異常に偏執的なやつが多いイメージ
ウォーターフォールが向いてる、というか、そうでないと進められない案件があるのよ。特にマルチベンダーの大型案件とか。と思った車載組込屋さんだった…。釣られた。
そりゃ計画通り実行できた完璧な開発なんてないでしょう。どういう計画の元で開発を進めるかって話なんだから。
じゃあそれをなんて呼ぶの？
車載組み込みもベンダー間調整、仕様確認は必要だから、フィードバック型ウォーターフォールになるんじゃないの? インクリメンタル開発はアジャイルだけじゃないし
当たり前だが上流が濁流だとゴミの山になる で実際大多数のそんな金ない開発は濁流のケースが多い
車載組込が専門らしいが、車載のソフトウエア開発プロセス認証はウオーターフォールモデル前提だろうにどうやってるんだ？ と思って記事一覧を見たら…。基本的に論点先取芸の人なのか。たぶん深く考えてないと思う
“言説は、方法論の正しさではなく、神話の正体としての物語です。” 人間味があっていいな
工程の途中で変更が入る事をアジャイルとは言いません。工程が要件定義まで巻き戻らないようならウォーターフォールのプロセスの範疇です／車載やってるようなのでWFに親でも殺されたのだろう
まぁ、言いたいことは判るし、厳密な議論でなく「グチ混じりの雑談なら十分題材としては成り立つ話」だとおもうけどなー
人月の神話
ウォーターフォールの対義語はアジャイルじゃないと思ってる。不確定要素をお互いに許容できるように調整できるような取り組みがアジャイルだと。スプリント計画とか言って実装内容決めるのはアジャイルではない。
こういうの読むと『AIが書いたみたいな文章だなー』と感じるのはなぜ？
ウォーターフォールってシャーロックホームズとかサムソンティーチャーのやつでしょ。
タイトルが浅慮すぎて笑っちゃったw
なんか過去の投稿見ると方向性がバラバラなのかなって感じたけど、どうなんでしょう。このぐらい扱えるんですかね。
タイトルの日本語の意味がわからんのだが
ウォーターフォールは完璧ではないが、きちんと使用凍結した証跡があると裁判で有利。アジャイルだとぜんぶ責任取らされるのでは
こういう整理論って何の意味があるの？どうでもよくない？
こういう整理論は個人でやるのは良いが、辺にグループ作ったり、コミニティや団体作って布教するのは権力欲だと思う。綺麗に分かれるものでもないし、対立煽るのは虚栄心と権力欲からだと思う。全く意味がない。
この観点は面白いな。日本的な職分の分化を重視しない世界でだけウォーターフォールの神話が維持されているわけだ。職分がはっきりしている世界だと、単に破綻するからビジネスモデルが転換しやすい。
去年「ウォーターフォール型で社内サービス作りたい」ってオーダーが来て技術者代表して参加したけど「依頼者に開発力がないと無理ですね」で終わったから、ウォーターフォール型でできるのは技術者だけだなと思う
前提とかふっとばした雑な考え方で恣意的に結論を決めるのは、ほとんど嘘と変わらない
逆になんでIT業界ではウォーターフォールを守れないことが許容されてるのかよくわからないんだよな、土木なんか遅延要因や問題が大量に発生するけどウォーターフォールでマネジメントしてるわけだし
あなたがウォーターフォールでソフトウェアを作れない程度のスキルスタックという事
明らかにAIで組み立てた主張なのに、論理構造が破綻していて結論ありきになってる。特定の意向に沿ったドキュメントをビルドしただけでその内容を検証するテストがされていない。 / https://b.hatena.ne.jp/site/zenn.dev/pdfractal
ウォーターフォールじゃないとヤバいシステムも結構あると思う。
“「ウォーターフォールでソフトウェアは作れる」” が神話だとして、じゃあアジャイルなら作れますなどという奴はペテン師だよ。
「心理、組織、歴史、そして認知の観点から整理します」この定型感ときたら…「「ウォーターフォールでソフトウェアは作れる」という言説は、方法論の正しさではなく、神話の正体としての物語です」これもなかなか
訳→後戻りしたらアジャイルだろ/真面目に読んでないので悪しからず
なぜウォーターフォールでソフトウェアを作れるかと言うと、プロジェクト管理が出来るから。と思っています。逆に言うと、高度な柔軟性を維持しつつ臨機応変に対応すればウォーターフォールは不要です。
車載組み込みのソフトウェアをウォーターフォールではない何かでどう開発しているのか書いてほしさ
ちゃんとしたウォーターフォールで開発できない人はアジャイルだろうがなんだろうがロクなものを開発できないと思うけどな
組み込み系の人か、大規模開発は素人なのがありあり。ウォーターフォールはクソだけど、他のどの方法よりマシなだけ。数百人のアジャイルとか、管理手法すら無いじゃん。
様式に基づいてドキュメント創るならWF方式が現場が楽ちんだっただけや。仕様書も現場検収まで済んだ後に作れば手戻りすくない。で、そのDoc持って横展しようとして事故る。AIプロンプトも同じことおきそう
全体としてはまさしくそうなんだけど「しかしこの乖離は、報告書や成果物には残りません」と言われるのはちょっとな。要件追加や変更は厳密に記録に残すでしょ
15年前の記事かと思ったわ そもそも今どきそんな事言うやついねーだろ
最大の収穫は未だにウォーターフォールはクソって言っておけばこんなにPVが稼げてしまうという事実の発見そのものだろう
生成AIの登場当初に「きちんとしたプロンプトを書かないと動かない」と言い張っていた人達もウォーターフォール信者なのであろうなあ。
なんか嫌なことでもあったのかい？/圧縮アルゴリズムみたいな研究が必要なものはともかく、ウォーターフォールが前提になるのは開発者が俯瞰できるレベルのものだよね。要件を決めて値段をつけるSIerには重要だよ。
またこの人か。次からはもうみんなブクマしなくて良いのでは？
昔はテストも簡単じゃなかったからウォーターフォールで作れるソフトしか作れなかったんだぞ、
うまくいったプロジェクトをアジャイルって呼んで、うまくいかなかったプロジェクトをアジャイルじゃない奴って呼ぶ人。真のスコットランド人。
むしろウォーターフォールであるべきだと思う。超大手でも総合試験最終日に仕様変更が当たり前のように行われている。ビル完成間近に1階を改造するようなものだ
初手ウォータフォールで作っても改修や運用はウォータフォールで回してないからな。
主張は同意できる部分もあるけど書き方が良くないというか、これだと議論が深まる前に読者が拒否反応を起こしてしまうのでもったいない
答え「実際にそうやって作られてきたから。」
？？？？
こういうこと言うと身も蓋もないんだけれど、世の中に出回っているウォーターフォールとアジャイルの対立軸で理解している人って、サイクル（スプリント）が長いか短いかくらいの違いしかない認識という気がする。
最初に作るべき仕様を決めて契約の区切りを作る。変更すべき仕様が出来たら追加契約をする。絶対に最初に決めた仕様で作りきるのではなく契約を区切って、変更点を分かりやすくして揉めないようにしているだけ。
"検証不能な主張であり、成功の定義が曖昧だからです。" それはまず自分に言うべきでは…
間違えない神の手法だけど、実際成功してたのもあったしなあ。
嘘じゃなくて前提じゃないの？ 藁人形論法にみえる
計画が実行段階で修正されるなんてソフトウェア開発に限らず当たり前の話だと思うが…
ソフトウェア以外の歴史にもよく出てくる「現在の前提や認識を基準に過去を語る・貶す」典型的な例。時代ごとの状況に応じてそのときの最適を選んできたにすぎない。そしてそれは今後も変わり続ける。
15年くらい前？に活発だったこの手の言説がやや下火になってるのはアジャイルが当たり前になったからかむしろ逆か。
ソフトウェアを作れるなんて嘘はおこがましいという話かしら
うーん？なんかエビデンスもなく否定してるような。
嘘じゃないでしょ。ウォーターフォールは絶対手戻りしてはいけないってのが嘘なだけで。ただ、当初の契約内容と、あまりにずれたときは専門家として、顧客に真正面から指摘しなきゃいけないのはいまだに嘘だろと思う
コメ欄「天才数人＋AIで設計と実装を貫通させる方が合理的」なぜその神話は信じてしまうのか・・・トラックナンバー減らしてどうする
AI臭すぎん？
"仕様溶解が起きていたにもかかわらず、それは公式記録には残りませんでした" 計画変更はプロジェクト管理において普通に発生する、それに対する追加予算も正常な経営判断。公式記録=議事録が無い筆者の世界が異常
昔ウォーターフォール開発やってたけど、詳細設計書が出来上がる時にはほぼ実装も終わっていた感じで、詳細設計レビューはほぼ実装レビューみたいな感じだったなあ
手戻りありならできるかも
ウォーターフォールと言いつつ随所でアジャイル的な手戻りは起きているし、アジャイルと言ってもウォーターフォール的な基礎を抑えてないと単なる行き当たりばったりになりプロジェクトが破綻する
読まなくていいな。
この手の言説で定量出して来る人ナカナカいないが、成果主義のない時代でFが言語の差での統計取ってたんよなあ。／神話の代わりに偽預言者出て来ても仕方ないのよ。
なおブクマ時点で2026年（令和8年）。2000年前後から頻繁にWF（ウォーターフォール）はクソ、なんちゃってWF、提唱者の言うWFと中身が異なると言わ続けて四半世紀が過ぎちゃった（近年はめっきり減ったが）。
何でこんな嘘を書いてるのか理解できない、ライターはどんな開発経験があるの？それとも炎上商法？これを掲載する側もまともじゃないよね（笑）。ド素人の戯言を発信するな！
今から考えると、昔のソフトは笑っちゃうほど単純だったんだよな。
これ未だに教育で教科書で学ぶからだと思います。
何を理想とするかって話なのかな。多重組織構造で上から落としていくのを前提とするWFと、最初から少しずつ動くものを積み上げてチーム開発しましょってアジャイルの違い、くらい？
こう言うのAIなのかな。所々強調文字謎だし。煽ってバズりやすい文章作れとかの指示なんだろうか
何か辛いことがあったのだろう。無事解決しますように。
ウォーターフォールだからダメ、みたいなのも根っこは一緒でしょ。適材適所でしかない