私はITエンジニアのプロとしてお金を稼ぐ立場です。その個人の意見です。
ただの意見ですので、見たくなければ見なくても良いですし、ましてや説得しようとも思っていません。
できるだけ非IT業界の方が読んでもなんとなくわかるを目指して書いているので単語はできるだけ簡単そうなものを選んでいます。IT業界の方が逆に読みにくい場合はすみませんがご容赦願います。
2026/06/29：リンク切れを修正しました。
私がどういう立ち位置の人間か
私はIT業界に10年以上います。社内SE（内製／自社開発）の経験が長く、ファーストキャリアはこれです。
その後、SIerに転職しました。100人ぐらいのプロジェクトに入ってプロトタイプ＋V字モデルベース（からのメテオフォール風味）で開発部分をリードしリリースするようなことをしたり、似たような規模のアジャイルもしたこともあります。納品型のプロダクト開発をウォーターフォールでやらさせていただいたこともあります
実はアジャイル推しではありません。柔軟にというか内製推しといった方が良いかもしれません。ウォーターフォールもアジャイルも両方やったことがある者の意見としてみていただければ幸いです。
ゆえにポジショントークも特にないです。
X（Twitter）での炎上の経緯
これが炎上したポストです。
『世界一流エンジニアの思考法』の著者である牛尾剛氏のブログ記事を読んで、感想というかアウトプットというか、まぁ7年も前の内容だから少しは許容される世界になっとるやろという軽い気持ちで意見感想をポストしたわけです。なので聞く聞かないは好きにすれば良いし押し付けする気も全くないです。
結果、燃えました。原因も分かっていてですね、それをこれから書いていきます。
炎上の原因①純粋なウォーターフォールと書けなかったこと
私が指すものが純粋なウォーターフォール（滝）なんですよ。前に戻ることをそもそも考慮に入れない。
そして純粋なウォーターフォールではビジネスとして成り立たないから手戻りが発生したらコストが多くなるデメリットを承知でするウォーターフォール（アジャイル要素を取り入れた）に進化させて日本で使い続けているにすぎません。
なのでウォーターフォールは手戻りOKなのに叩いているやつがいるぞってなるわけですよ。（個人的にはウォーターフォールって名前やめちまえ、改名しろって思うわけですよ、なんだよ滝登りって）
X（Twitter）は課金していなければ140の文字数上限あるので、「純粋な」という3文字は省略したいわけですよ。「大前提は前のフェーズに戻らない」と書いてあるので省略しても分かるだろうと。前工程ってやればできたかもって後になって思いましたが、あまりITに詳しくない人にも向けて発信しているので、そこは堪忍してって感じです。
炎上の原因②反復前提をアジャイルと解釈される
私の意図としてはアジャイルのことなんてさらさら語っていないわけなんですよ。強いていえばウォーターフォールの起源となる論文を書いた名前もついていない手法の方がよかったなと思っているぐらい（この話は後でも解説します）
なので私のポストはウォーターフォールVSアジャイルと間違えられたわけです。
さっきの滝登り！これも反復ってことやぞ。工程の行き来と書けばもう少し私の意見は理解されたのだろうか。どのみち燃える気がする。
さらにウォーターフォール以外はアジャイル、ウォーターフォールの反対はアジャイルって思っている人が大勢いるってことです。物事を2つに分けたがる分断本能が働くのでしょう。
炎上の原因③タイミングが悪かった
私がポストする前にウォーターフォールVSアジャイルについて書いている人がいました。結論は使い分けというごく平和なものでしたけど。
また、この本も盛り上がっているところなので、この本読んだだけの薄っぺらいもの見てなんかイキってるやつおるぞみたいなこと勝手に思うのですよ。「記事読んで」って書いたけど、それがみなさん読めてないのですよね。
X（Twitter）炎上のまとめ
ということで、原因はこんなところでしょう。ウォーターフォールは戻れるって主張する人とアジャイルと戦わせるなと主張する人がカオスになっていて、どちらも私が言いたいことではないので( ﾟдﾟ)ﾎﾟｶｰﾝってなってました。
ウォーターフォールに何かしらメリットがあるかもしれない、その時は指摘してもらおうと控え目に「一切メリットを感じたことがない」と抑えていました。止めておきなさいも私は言ってない。
「ウォータフォールは一切メリットがないので止めておきなさい」と言ったのはサム・グッケンハイマー（Microsoft社員）だ。
人の頭の中は勝手に想像豊かになって誰が何を言ったのかはそこまで気にならないようだ。
また今回の炎上で誰一人として大したメリットを言った人はいませんでした。
→ウォーターフォール以外の手法もビジネスで使えている
→使わざるを得ない場合があるだけで成立しないのではないか。暴論を言ってしまうなら「風邪はなくなっていないのでメリットがあります」と同じ原理だがそんなことは言わないでしょ（最初は別のものにしようとしてましたが止めました）。
ここまで時代に合わないものなので、メリットは一切ないと言い切ってしまっても良かったぐらいだ。どうせ読み手には脳内でそう言ったことになっているようだから。
どう読むかは読み手の自由ですが、140文字に何を望んでいるのか。個人攻撃する者も出てくる始末。流せるレベルなので流します。（当たり前ですが度が過ぎていれば法的措置も検討はしますよ）
少し関係ないかもしれませんが、IPAの『共通フレーム２０１３の概説』で”プロジェクト全体はウォーターフォールモデルを採用”と書いてあるが”「Ｖ字モデルの採用」を提唱”とも書いてある点は恨んでます。1970年代に米国で広まった前工程に戻らないウォーターフォールモデルと1980年代にドイツで広まった前工程に戻ることを禁止していないVモデルを共通点あるだけで同じ括りにすべきではないと思う。「ウォーターフォール（V字）」とか「ウォーターフォール＝V字モデル」のような解釈が増えて説明がすごく面倒臭い。
ウォーターフォールとは何か
図にするとこれです。Wikipediaでは『ウォーターフォール・モデルは、ソフトウェア工学における古典的な開発モデル。』とあります。
特徴としては作業工程をトップダウンで分けています。そのためスキル別に分業することができ、低スキル者も関わりやすくなっています。
私流に定義するのならこちらになります。（完全な定義が存在していないため参考程度にご覧ください）
※ビジネス上うまくいかなくなり前工程に戻ることは特例ととらえ、この定義では除外する
ウォーターフォールのメリット
スケジュールや進捗管理がしやすいゆえに人材確保や契約が取りやすい
本当にそうか？
ソフトウェア開発においては仕様変更や追加要望がないことはほぼありません。大なり小なりありますし、仕様変更や追加要望が多すぎることによって失敗したプロジェクトだってあります。
期限が決まっていれば、下の工程にとれる時間が減っていき、ほとんどの場合は発注者が強いので残業でカバーすることになります。その人件費が増えればそれだけ利益を圧迫します。利益が圧迫するだけならまだ良いですが、赤字になることもあります。また、プロジェクトが失敗した場合は報酬の返還を含む損害賠償を請求されることがあります。
目先の利を追ったとしても失敗プロジェクトは損失になります。
69%とは何の数字が分かりますか？ソフトウェア開発のプロジェクトの失敗率です。ソフトウェア開発において成功するよりも失敗の方が多いのです。コストを下げるためにウォーターフォールを採用する場合が多いと思いますが、失敗リスクを上げている気がしてなりません。
「納品のない受託開発」で有名なソニックガーデンという会社もありますので、契約が絶対にとれないわけではありません。不確定要素が多い場合は準委任契約を用いたり、多段階契約することでリスクを減らすことも可能です。
真っ先にウォーターフォールじゃなければできないという考えは良い考えなのでしょうか。
低スキルの人材を登用できる
正気か？
確かにウォーターフォールは多重下請け構造に都合が良いとは思います。ただし多重下請け構造は問題になっています。大企業病に近しいものも感じます。
低スキルの人が役に立つ仕事としては、以下ぐらいと思います。
- 設計のドキュメントにおいて、単語や語尾の統一を含む体裁を整える
- 入力検証のコーディング
- テストのコーディング
また、低スキルの人の比率もよく考えた方が良いポイントです。低スキルの人の比率が高ければ高いほどプロジェクト失敗のリスクが増えます。低スキルの人10人よりも優秀な人1人の方が早い場合もあります。教育コストや尻拭いで困ることもあります。
ビジネス観点の人がこれをメリットとしてあげるのは百歩譲って許容しますが、技術者自身がこれをメリットとしてあげていては恥ずかしくないのかな？と思います。
ウォーターフォールが向いているプロジェクト
ウォータフォールモデルが向いているのは、スコープが固定されており、プロジェクトが固定的で、確実であり、技術が明確に理解されているものである。
引用：https://simplearchitect.hatenablog.com/entry/2016/06/20/080807
牛尾氏のブログで引用したものを探してみたが、みつかりませんでしたのでそのまま引用します。
牛尾氏とほとんど同じで、私もお目にかかったことはない。軍用ソフトウェアかハードウェアに近いプロジェクトぐらいであると思う。少数のプロジェクトが向いていますというのはいかがだろうか。
ウォーターフォールの歴史
ウォーターフォールの歴史要約
Wikipediaに書いてあるので、そちらも見ていただければわかるのですが、要約と加筆をするとこのようになります。
1968年、NATO後援の国際会議にて、ソフトウェア開発を工業製品の作成方法に変える方法として、工程を分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとする原形が提唱された。
T.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」にウォーターフォールという用語が登場し、TRW/軍サイト防衛ソフトウェアプロジェクトのトップダウン的なアプローチに用いられている。
B.W.Boehamが1981年に出版した本「Software Engineering Economics」において、起源がW.W.Royceによって1970年に発表された論文「Managing the Development of Large Software Systems」と述べているが、結論は受け継がれておらず説明の途中経過のみを参照しており、真逆の結論になっている。
Royceモデルの深堀
W.W.Royceによって1970年に発表された論文「Managing the Development of Large Software Systems」の手法では名前がついていません。ここではRoyceモデルとします。
Royceモデルが結論とする図はこちらです。
それでウォーターフォールはこちらの図になります。
どう思いましたか？
これが
こうだ！
最初からあの結論の図を見せても、読者はよくわからないと思います。なので、ロイス博士はその図に至るまでの段階を図4枚差し込んで説明します。図5が結論にも関わらず、図2がロイスの主張だ！と広い範囲で解釈されてしまったのです。
ロイス博士の主張は図2では不十分なので図3が理想で図4になることが多く図5にできれば失敗しにくいという意です。
Royceモデルの特徴をまとめるとこちらのようになります。（現代でも有用なものを特に抽出）
- ドキュメントがどれだけ必要か提起する
- パイロット版を作成しシステム設計から運用までを2回やる
- お客様を早い段階で巻き込む
- コストはかかるが、これらをやらなかった方がコストが掛かる。
Royceは途中問題が発生することは織り込み済みで、問題が起きた時の対処まで盛り込んでいることが分かります。また、発注者と使用者が違う要求をすることも対処可能です。
ウォーターフォールの歴史の参考文献等
こちらのブログ記事「僕たちはまだ本当のウォーターフォールを知らない」は綺麗にまとまっていて面白いです。また小樽商科大学の小椋俊秀氏の論文「ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く – 小樽商科大学学術成果コレクション」も読みごたえがあります。ご興味があれば読んでいただければと思います。
Wikipediaに書かれているウォーターフォールの歴史も置いておきます。
1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。
「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味し、W. W.ロイスによって1970年に発表された論文「Managing the Development of Large Software Systems」の内容が元になったとされる。この論文において、「大規模ソフトウェア開発には、製品製造過程のようにいくつかの工程に分けたトップダウンアプローチが必要」と述べている。しかし論文には「ウォーターフォール・モデル」という記述は無く、また、前工程への後戻り（見直し）も提唱されており、元の論文の内容とは異なっている。
初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはロイスだと述べている。
引用：Wikipedia
ウォーターフォールの問題点
私が感じている問題点
誤解がないように先に述べるとウォーターフォール（滝）の話でVモデル・Wモデルのことは論じない。触れてしまうものはVモデル・Wモデルでも問題ではあるが、混ぜると本質を見失いやすくなるためウォーターフォール（滝）に限定する。
- 根底にはエンジニアをブルーワーカーのように働かせる意図がある
- 前工程が完了するまで待てない
- 仕様変更や追加要求に答えないため発注元の理想は叶えにくい
- 完成したものを変えられずエンドユーザーの満足度が低い
- イニシャルコストと人件費を安くするが、拡張させるコストまでは考慮にない
根底にはエンジニアをブルーワーカーのように働かせる意図がある
ウォーターフォールが生まれたのは第三次産業革命の1970年代頃である。
この一文を書くだけでも少々悲しくなる。
多重下請け構造で実施しても問題なく、可能な限り人件費を安く抑えることを考えると、非常に合理的な手法です。
30年ぐらいウォーターフォールで開発していた米技術者が間違いに気付いて、ウォーターフォールが悪だったと言っていて、既に答えが出ているようなものです。YouTubeなどでも探せばあるので探してみてはいかがだろうか。
ソフトウェア開発において過労や鬱になってしまう人が多いのも根本にこれであると思います。私と一緒に働いた人で数人は鬱の診断されてますので、あまり他人事ではありません。
ウォーターフォールを取り入れることは全然かまわないし、適している箇所はそうすべきとは思います。第四次産業革命の現在においてホワイトワーカーの仕事をしないといけない技術者にとってウォーターフォールをそのまま使うというのは、未来にとって良いものなのでしょうか。
前工程が完了するまで待てない
ウォーターフォールの前提ですね。ほとんどどの発注者も純粋なウォーターフォールは完成まで時間が掛りすぎるので、もっと早く完成して欲しいと言うと思います。
VモデルやWモデルといった、前工程の完了を前提としていないものもあります。
仕様変更や追加要求に答えないため発注元の理想は叶えにくい
ウォーターフォールの前提を通すならこういうことです。
予算の少ない発注者の立場であった場合は困ることになります。（大規模開発はお金を出す発注者側の立場が強いことが多いので逆の問題がでますが）
完成したものを変えられずエンドユーザーの満足度が低い
ウォーターフォールの前提を通すならこういうことです。
発注者側の使用者にとっては、開発完了後にお披露目となります。ほとんど完成してしまっているので、使用者からの要望は叶えられません。
自国の勝利が目的の軍用ソフトウェアならば使い勝手などは気にすることではないですが、現代のソフトウェアでは満足度は重要な要素です。
イニシャルコストと人件費を安くなるが、拡張させるコストまでは考慮にない
ソフトウェアは建築や機械とは違い作って終わりにはなりません。追加機能を増やしたりセキュリティを強化するバージョンアップを繰り返します。
全くバージョンアップしないソフトウェアならば問題はないですが、バージョンアップがないソフトウェアは脆弱性のかたまりになるかもしれませんよ。
よくあるのは拡張性のないコードになりやすく、バグを起こさない品質にこだわるあまりスマートな対応を行えず、拡張すればするほどそこを避けるためのコストが重たくなっていきます。
書籍からのご紹介
ここでは述べませんので、詳しく知りたいのであれば読んでみてください。
ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない
デザインのためのデザイン フレデリック・フィリップス・ブルックス
ウォーターフォール・アプローチは，危険かつ問題をはらんだ，企業における風土病
ソフトウェア職人気質: 人を育て、システム開発を成功へと導くための重要キーワード
秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた
初めてのアジャイル開発 ～スクラム、XP、UP、Evoで学ぶ反復型開発の進め方～
ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている
自社開発（内製化）のすすめ
ここまで読んでいただいた方ならお分かりになると思います。ウォーターフォールを採用しているのは、事業会社がシステム開発会社（ベンダ）に依頼する構図になる。
事業会社で自社開発において手法が選べる場合にわざわざウォーターフォールのみを採用ことはない。米国では内製化が95%以上となっている。内製の利点について経験をもとに述べる。
外注では現場や人にナレッジ・経験が貯まりにくい
発注元はドキュメントの数々と完成したソフトウェアを手にするが、中身は良く分からないものになる。ドキュメントはトラブルがあった時か次回改修する時ぐらいにしか出番はないし、ソースコードの中身も見ることも少ない。
ここまでは発注元の話だが、システム開発会社でもプロジェクトが終了すると運用案件がなければその場で別のプロジェクトに行くことになる。運用案件があったとしても運用メンバーを参加させ大半は同じように現場に残らない。そうなると知識を持った人材が別に行くことになる。その為のドキュメントといえばそうなのだが、知識と経験を持った人が現場から減るのは変わりません。
自社開発での喪失は従業員の休職か退職となるが、広い範囲で見ると外注ではもっとコントロールしにくく知らぬ所で経験が喪失していることになるのです。そこまでならまだマシで競合他社にその経験が流出すると脅威にもなりえます。それならば働きやすい環境や条件で自社開発をして技術者囲う方が現場の流出を防ぎ経験値が貯まるのではないかと考えます。
ソフトウェア開発を1回で理想なものを作ることはとてつもなく難しい
家を建てる場合、ハウスメーカーに依頼すると思います。戸建てを建てことがある人はご存知と思いますが、「家は3回建てないと理想の家にはならない」という格言があります。
家ですら理想に至るまで3回も必要なのに変化が激しいソフトウェア開発を1回で理想なものにすることは難しいです。
理想ではないソフトウェアはどうなるかというと、使われずに捨てられる。もしくは文句言われ続けながら使われ続けます。範囲が狭ければそこだけを改修すれば良いですが、広ければ全てをリプレース（作り直し）することになります。
自社開発ならば少しずつ直していくことも小さく作って反応をみながら大きくしていくことも契約による制限がないので柔軟に対応しやすいです。
ソフトウェアはリリースがゴールではなく運用から先の方が長い
進学や結婚をしたことがある人はご存知と思いますが、それをできたことがゴールではないのですよね。進学の場合は卒業までがゴールです（就職やキャリアアップまで発展するかもしれません）し、結婚をゴールに設定してしまうとまずまずの確率で離婚するかよろしくない結婚生活になります。
ソフトウェアも同じでリリースがゴールではありません。リリースから様々な要望が出てきたり、機能を拡張していきます。
私は自社のプロジェクトを外部に発注する側も経験してますが、納品された物のソースコードを読むと拡張性が高くない書き方が多いです。こういうコードは技術負債になります。そうならないため、拡張性や保守性が高いコードを書こうと思うと長年システムを運用して改修を繰り返す経験がないと難しいのかもしれません。
品質ってなんだろうと考えたことがあります。テストが通って、どんな操作をしてもバグが出ない。それ以外にもユーザー満足度や保守性、これも品質として重要視していく必要はないでしょうか。こちらは外部に依頼していたのでは難しく自社開発ならではと考えてます。
圧倒的にスピードか早く効率が良い
熟練のエンジニアが自社にいると、1聞いたら10返してくれる人もなかにはいます。ソースコードは読みやすく命名も的確なため、そこまでドキュメントを残す必要もなくなり少なくすることも可能です。保守性の高いコードを書けるだけでなく、再利用も可能なので、別のソフトウェアに展開することや、改修のコストも低いです。技術負債も少なくなるでしょう。仕様も大まかには頭の中に入っているので開発のたびに仕様書を隅から隅へ読むようなことはしません。
と良いこと並べても理解しにくいとは思います。外部に依頼すると2〜3ヶ月待たされるものが、自社に熟練エンジニアがいると数分〜1・2週間で終わるといった案件は多く発生します。
とはいえこれはそのようなエンジニアがいた場合になりますので、未経験や低スキルのエンジニアを固めたところでこのようにはなりません。技術負債が増え、何ヶ月経っても作り方が分からず完成しないということも考えられます。なので、いかに技術のあるエンジニアを迎えるかが鍵になります。
日本の正社員は辞めさせにくい点もありますので、最初に基準に満たない人を正社員で採用して教育も辞めてもらうこともできず困る場合があります。まだ内製化のできていない企業は、最初に業務委託などで入ってもらうことから始めるとそのリスクは減らせます。採用の見る目を養えるまでそのように動くと良いと思います。
ウォーターフォールはメリットがないのまとめ
燃えようが燃えなかろうが、恐らく数年経っても私の意見は変わらないと思います。
実はですね、私としてはウォーターフォールはどうでも良いと思ってます。Royceモデルの図と出会ってとても感動しました。少年の心を思い出すぐらいに。論文が出たのが1970年で50年以上も前ですよ！凄過ぎる！
ウォーターフォールもない時代にプロトタイプとアジャイルの良いとこどりのような手法を論文にまとめていたこと。目先に囚われず長期的視点で全体コスト最適とユーザー満足度を備えていること。
確かにコストと期間はかかりますよ。ですがここまでやっていれば失敗プロジェクトは減っていたと思いますし、適正価格のソフトウェア開発ができたと思います。
ウォーターフォールでジャブしてRoyceモデルの右ストレートにしようと思ってジャブで燃えてしまったので、『メリットがない』はキラーワード過ぎました。甘く見てました。
ここまで1万文字を超える長文をお読みいただきありがとうございました。
日本のIT業界の現場が少しでも良くなることを願います。