Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
History of WaterFall
Search
semiyashin
June 21, 2012
Technology
12k
15
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
History of WaterFall
20120621
semiyashin
June 21, 2012
More Decks by semiyashin
See All by semiyashin
Backlog Talk part1
semiyashin
0
120
Backlog Talk part2
semiyashin
0
150
sales_strategy
semiyashin
0
160
dancing_dev
semiyashin
0
100
develop_process
semiyashin
0
130
start_producer
semiyashin
0
250
eds_strategy
semiyashin
0
210
shibuyarb20130515
semiyashin
1
260
TokyoRUbyKaigi_10
semiyashin
0
290
Other Decks in Technology
See All in Technology
Escolhendo LLMs na Prática: Lições Reais em Busca Agêntica no Mercado Livre —TDC 2026 Floripa
jpbonson
0
120
[MIRU26] To What Extent Does MLLM-as-a-Judge Exhibit Cross-Model Preference Bias?
keio_smilab
PRO
0
100
20260608_Codexの可能性_ノンプログラマー向け_大城追記
doradora09
PRO
0
720
BigQuery を検索ソースとした AI Agent の作り方って 〇〇 通りあんねん
satohjohn
0
150
toio・myCobotでフィジカルAIっぽいことを行うための検討(とりあえず調査) / フィジカルAI LT(IoTLTによる開催)
you
PRO
0
230
LLMリーダーボードアップデートに向けたAgentic Math_SWEのトレースについて
nejumi
0
190
オートロックマンションなのに、各部屋は施錠なし!? 攻撃者が組織内ネットワークで大暴れする理由 / The Front Door Is Locked, but the Rooms Are Wide Open: Why Attackers Move Freely Inside Enterprise Networks
nttcom
0
780
AI驚き屋発見器
yama3133
2
400
大 AI 時代におけるC# の事情 ~ぶっちゃけトークを交えながら~
nenonaninu
1
620
脱Jenkins、インターン生が挑んだCIツールGitHubActions移行
mixi_engineers
PRO
1
300
現場で使える AWS DevOps Agent 活用ノウハウ - Release Management 機能の検証結果を添えて / AWS DevOps Agent Release Management and Know-How
kinunori
5
840
[しろおび夏祭り2026] チャットするAIから、作業するAIへ - 使われ方の変化と、その裏側で起きていること
kk0n
0
850
Featured
See All Featured
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Side Projects
sachag
455
43k
Building AI with AI
inesmontani
PRO
1
1.1k
Git: the NoSQL Database
bkeepers
PRO
432
67k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
250
Accessibility Awareness
sabderemane
1
170
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
330
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2.1k
Transcript
最近アジャイル界隈で よく聞く話
「自分の現場がウォーター フォールで全然ダメで それをアジャイルなら 変えられないかと思って」
いったい誰と戦って いるんだ・・・・・
ちょっと待て
「自分の現場がウォーター フォールで全然ダメで それをアジャイルなら 変えられないかと思って」
そもそも
ウォーターフォールって だめなの?
なんでそんなものを みんな使っているの?
というか ウォーターフォールって なに?
いつどこで 生まれたものなの?
ということで我々は ウォーターフォールの 起源に迫ってみることにした
None
History of WaterFall 瀬宮 新
ウォーターフォールだと 思われているもの
・よくある仕様変更 ・手戻りしない直列的な工程 ・大量の書類 ・絶対固定の納期と予算 →そしてデスマーチへ
本当の ウォーターフォール ってそもそもなに?
ウォーターフォールの起源 Winston.W.Royce Managing the Development of Large Software Systems という論文(5ページくらい)
分析 実装
要求 分析 設計 実装 運用 試験
2回実施せよ (プロトタイプ) テストを計画せよ (設計よりも前に) 顧客をまきこめ (反復的なチェック) Royceは言った(1)
当初のRoyce案では ウォーターフォールを 反復型開発として して提案していた
仕様変更があったら 費用/納期を追加しろ 仕様変更があったら もう一回やりなおせ Royceは言った(2)
つまり
ここさぁなんかイメージと 違うんだよね
すると
おかわり=反復的な開発
なるほどなるほど
それでは
どうしてこうなった
None
時は1980年代
・システム開発は大規模化 ・税金による予算化に 「おかわり」は不向き ・予算と納期の追加が続発 →「おかわり」しすぎ!
再発防止策が必要だな
ということで
DOD-STD-2167(1985.6) (文書をいっぱい作ろう!) DOD-STD-2167A(1988.2) (工程の反復の否定 ウォーターフォールは 「おかわり」禁止!)
反復型開発が否定され 直列的ウォーターフォール が生まれた
DOD-STD-2167A(1988.2) を真に受けると ・ウォーターフォール (絶対に「おかわり」禁止) ・ほかの開発手法 (大規模開発に不向き) の二択
そして滝は詰まり始めた
None
一方、日本では
1985. 日本電信電話 設立 1988. NTTデータ 設立 1990. バブル崩壊 (システム要員の外注化)
日本ではSIが発達し同時に 開発手法もアメリカから 輸入された
システム開発の普及 ・大規模システム = ウォーターフォール ・書類が山盛り ・「おかわり」禁止 がデファクトスタンダードに
None
輸入された経緯はわかった
日本では今でも ウォーターフォールが 炎上している
それではアメリカでは 炎上しなかったの?
None
もちろん大炎上したよ
大炎上する案件が複数発生
再発防止策が必要だな
DOD-STD-2167A(1988.2) ↓ MIL-STD-498(1994.12) (頻繁な顧客レビューの推奨) DOD 5000.2(2000) (反復型および スパイラル型を推奨)
開発は反復型重視へ 回帰した
さらに
XP 白本(1999) アジャイルマニフェスト (2001.2) (1993.のJacob Nielsen のUIテスト あたりをみても業界全体が 反復的開発と頻繁なFBに 傾いている)
反復型開発の復活
つまりダメな ウォーターフォールに 嵌り込んでいたのは・・ 日本だけ!
嵌っている・・首まで・・
つまりダメな ウォーターフォールに 嵌り込んでいたのは・・ 日本だけ!
これを知った時、私は
こう思いました
調達標準は反復型重視へ 回帰した
None
ではウォーターフォールは どうあるべき?
・プロトタイプを作る ・頻繁な顧客フィードバック ・反復的で機能追加型の開発 にシフトすべき
None
そもそも ウォーターフォール <<< <(壁)<<アジャイル なのか?
(一面の真実) 仕様変更が許容範囲に収まる場合 ウォーターフォールのほうが アジャイルよりも安いし早い 完全にアジャイルに進めると 対象やドメインモデルが複雑だと 破綻する可能性が高い
ではどちらを選択すべきか?
慣れた人に任せるべきだ (Martin Fawler)
None
では日本のソフトウェア開発は これからどうなる
・反復型ウォーターフォール ・アジャイル ・そのほか に分かれると思う 残念なウォーターフォールも残るだろう
None
ご清聴ありがとうございました