SlideShare a Scribd company logo
1 of 108
Download to read offline
最近アジャイル界隈で
      よく聞く話
「自分の現場がウォーター
  フォールで全然ダメで
 それをアジャイルなら
 変えられないかと思って」
いったい誰と戦って
 いるんだ・・・・・
ちょっと待て
「自分の現場がウォーター
  フォールで全然ダメで
 それをアジャイルなら
 変えられないかと思って」
そもそも
ウォーターフォールって
      だめなの?
なんでそんなものを
みんな使っているの?
というか
ウォーターフォールって
        なに?
いつどこで
  生まれたものなの?
ということで我々は
ウォーターフォールの
起源に迫ってみることにした
History of WaterFall
     瀬宮 新(@shin_semiya)
ウォーターフォールだと
 思われているもの
・よくある仕様変更
・手戻りしない直列的な工程
・大量の書類
・絶対固定の納期と予算

 →そしてデスマーチへ
本当の
 ウォーターフォール
  ってそもそもなに?
ウォーターフォールの起源

Winston.W.Royce
Managing the Development
          of Large Software Systems

という論文(5ページくらい)
分析


     実装
要求
     分析
          設計
               実装
                    試験
                         運用
Royceは言った(1)
  2回実施せよ
     (プロトタイプ)
  テストを計画せよ
     (設計よりも前に)
  顧客をまきこめ
     (反復的なチェック)
当初のRoyce案では
 ウォーターフォールを
  反復型開発として
   して提案していた
Royceは言った(2)

仕様変更があったら
  費用/納期を追加しろ
仕様変更があったら
  もう一回やりなおせ
つまり
ここさぁなんかイメージと
      違うんだよね
すると
おかわり=反復的な開発
なるほどなるほど
それでは
どうしてこうなった
時は1980年代
・システム開発は大規模化
・税金による予算化に
  「おかわり」は不向き
・予算と納期の追加が続発
  →「おかわり」しすぎ!
再発防止策が必要だな
ということで
DOD-STD-2167(1985.6)
(文書をいっぱい作ろう!)
DOD-STD-2167A(1988.2)
(工程の反復の否定
  ウォーターフォールは
      「おかわり」禁止!)
反復型開発が否定され
 直列的ウォーターフォール
       が生まれた
DOD-STD-2167A(1988.2)
  を真に受けると
・ウォーターフォール
  (絶対に「おかわり」禁止)
・ほかの開発手法
  (大規模開発に不向き)
                の二択
そして滝は詰まり始めた
一方、日本では
1985. 日本電信電話 設立
1988. NTTデータ 設立

1990. バブル崩壊
(システム要員の外注化)
日本ではSIが発達し同時に
 開発手法もアメリカから
   輸入された
システム開発の普及
 ・大規模システム
   = ウォーターフォール
 ・書類が山盛り
 ・「おかわり」禁止
がデファクトスタンダードに
輸入された経緯はわかった
日本では今でも
 ウォーターフォールが
  炎上している
それではアメリカでは
炎上しなかったの?
もちろん大炎上したよ
大炎上する案件が複数発生
再発防止策が必要だな
DOD-STD-2167A(1988.2)
↓
MIL-STD-498(1994.12)
(頻繁な顧客レビューの推奨)
DOD 5000.2(2000)
(反復型および
       スパイラル型を推奨)
開発は反復型重視へ
      回帰した
さらに
XP 白本(1999)
アジャイルマニフェスト
 (2001.2)

(1993.のJacob Nielsen のUIテスト
  あたりをみても業界全体が
  反復的開発と頻繁なFBに
                  傾いている)
反復型開発の復活
直列的WF    に対する反動!

   改善派    反復的WF


   革命派    アジャイル
つまりダメな
 ウォーターフォールに
  嵌り込んでいたのは・・
       日本だけ!
嵌っている・・首まで・・
つまりダメな
 ウォーターフォールに
  嵌り込んでいたのは・・
       日本だけ!
これを知った時、私は
こう思いました
調達標準は反復型重視へ
       回帰した
ではウォーターフォールは
     どうあるべき?
・プロトタイプを作る
・頻繁な顧客フィードバック
・反復的で機能追加型の開発
     にシフトすべき
そもそも
ウォーターフォール <<<
 <(壁)<<アジャイル
    なのか?
(一面の真実)
仕様変更が許容範囲に収まる場合
ウォーターフォールのほうが
  アジャイルよりも安いし早い

完全にアジャイルに進めると
対象やドメインモデルが複雑だと
  破綻する可能性が高い
ではどちらを選択すべきか?
慣れた人に任せるべきだ
    (Martin Fawler)
そもそもの問題として
ウォーターフォールだと
 思われているもの
・よくある仕様変更
・手戻りしない直列的な工程
・大量の書類
・絶対固定の納期と予算

 →そしてデスマーチへ
問題を突き詰めると
・抜け漏れのない要求仕様
・誤りのない前工程
・納期と費用の精密見積り
       は不可能だ!
こういう人がいる
日本のウォーターフォール
    における開発では
手強い敵がいる
無責任な顧客
多重下請け構造
常に過重なタスク

デスマ根絶のため
 どげんかせんといかん!
彼らが立ち上がった!
俺達も続くぞ!
終わりのないデスマを
アジャイルにより根絶する

 俺がガンダムになる!
 俺達がガンダムだ!
そんなにうまくいくか?
本当にあなたは
 ガンダム(アジャイル)に
  なれますか?

 あなたの隣の同僚は?
 あなたの会社の偉い人は?
 あなたの顧客は?
アジャイルは人に
   多くを求める
アジャイルチームに
    要求される能力

・自己組織化
・コマンドコントロール不要
・改善する意思
・成果責任
そしてなにより
・意思決定できるPO
・権限移譲と信頼する経営陣
・お金を交渉できる能力!

       が必要になる。
誰もがこの働き方を
気に入るわけじゃない
本当にあなたは
 ガンダム(アジャイル)に
  なれますか?

 あなたの隣の同僚は?
 あなたの会社の偉い人は?
 あなたの顧客は?
手強い敵がいる
本当にガンダムが必要か?
量産機で勝てる戦術も
 必要ではないか
解決したかったもの
・よくある仕様変更
・手戻りしない直列的な工程
・大量の書類
・絶対固定の納期と予算

 →そしてデスマーチへ
そもそもの問題として
・抜け漏れのない要求仕様
・誤りのない前工程
・納期と費用の精密見積り
       は不可能だ!
解決方法は
アジャイルだけではない
量産機で勝てる戦術
=反復的ウォーターフォール
開発を複数のサイクルに分割
 →後のサイクルで改善可能
・仕様の抜けに対応しやすい
・小さいサイクルなら制御可
・考慮漏れに対応しやすい
・進捗速度が上がる
・「強い」POがいなくても
   開発可能
・比較的既存の体系を
   流用しやすい
・契約形態についても同様
   機能の分割納入に近い。
・偉い人や顧客を
  (比較的)説得しやすい
・重量級開発にも
  (比較的)耐えられる
では日本のソフトウェア開発は
      これからどうなる
・反復型ウォーターフォール
・アジャイル
・そのほか
    に分かれると思う

残念なウォーターフォールも残るだろう
ご清聴ありがとうございました

More Related Content

Viewers also liked

TDDBC 横浜 演習課題
TDDBC 横浜 演習課題TDDBC 横浜 演習課題
TDDBC 横浜 演習課題
Hiroyuki Ohnaka
 
TDD Boot Camp 東京 for C++ 課題
TDD Boot Camp 東京 for C++ 課題TDD Boot Camp 東京 for C++ 課題
TDD Boot Camp 東京 for C++ 課題
Takashi Imagire
 
20120706-readablecode
20120706-readablecode20120706-readablecode
20120706-readablecode
Masanori Kado
 

Viewers also liked (11)

TDDBC 横浜 演習課題
TDDBC 横浜 演習課題TDDBC 横浜 演習課題
TDDBC 横浜 演習課題
 
TDD Boot Camp 東京 for C++ 課題
TDD Boot Camp 東京 for C++ 課題TDD Boot Camp 東京 for C++ 課題
TDD Boot Camp 東京 for C++ 課題
 
ライフゲームでプログラミング
ライフゲームでプログラミングライフゲームでプログラミング
ライフゲームでプログラミング
 
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
 
ソーシャルゲームにおけるAWS/MongoDB利用事例
ソーシャルゲームにおけるAWS/MongoDB利用事例ソーシャルゲームにおけるAWS/MongoDB利用事例
ソーシャルゲームにおけるAWS/MongoDB利用事例
 
ペアプロワークショップ
ペアプロワークショップペアプロワークショップ
ペアプロワークショップ
 
coderetreat
coderetreatcoderetreat
coderetreat
 
20120706-readablecode
20120706-readablecode20120706-readablecode
20120706-readablecode
 
Jenkins user conference 東京
Jenkins user conference 東京Jenkins user conference 東京
Jenkins user conference 東京
 
Jenkins に XFD を追加してみると
Jenkins に XFD を追加してみるとJenkins に XFD を追加してみると
Jenkins に XFD を追加してみると
 
Mongo sharding
Mongo shardingMongo sharding
Mongo sharding
 

Recently uploaded

Recently uploaded (7)

LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 

History_of_waterfall_append