「ウォーターフォール開発」、本当に日本でうまく行っているのか？ 97
ストーリー by hylom
日本的、ということだろうか 部門より
日本的、ということだろうか 部門より
Unkown 曰く、
「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。
/.J諸兄方の職場では、ウォーターフォール開発手法で本当にうまく行っていますか？ また、今使っている開発手法は何ですか？
これは、7月21日に行われたAgile Conference Tokyo 2010でのトークセッションで話題にされたそうで、参加者のレポートやTwitter実況などによると、Humble氏は日本の開発工程に「バグフィックス工程」がないことに驚いたらしい。頻繁なテストやコーディング段階での修正が品質に寄与しているそうだが、Humble氏はそれでも「アジャイル開発のほうが安く、簡単に高品質を確保できる」と主張した模様。
アジャイル開発は日本には馴染まない (スコア:5, すばらしい洞察)
でも、この国だと子受け孫受けまでいって共同作業とか実質不可能。
完全に仕様が決まって落ちてくるウォーターフォール以外にコンセンサス取れんだろ。
Re:アジャイル開発は日本には馴染まない (スコア:5, すばらしい洞察)
Re:アジャイル開発は日本には馴染まない (スコア:1)
実際にはウォータフォールもどきですね。
Re:アジャイル開発は日本には馴染まない (スコア:5, おもしろおかしい)
納品書出してからプログラムを作り、それが終わってから仕様書を書く、
という開発形態は「鯉の滝登りモデル」とでも言えばいいのでしょうかねぇ?
Re:アジャイル開発は日本には馴染まない (スコア:3, おもしろおかしい)
＞納品書出してからプログラムを作り、それが終わってから仕様書を書く、
さらには、それが終わってから契約書を書く。
契約書にサインするのは開発期間終了後。
Re:アジャイル開発は日本には馴染まない (スコア:4, おもしろおかしい)
フリーフォールモデルとでも名付けようか。
Re:アジャイル開発は日本には馴染まない (スコア:2, おもしろおかしい)
仕様を凍結せずに次に進み, 状況によっては元に戻って修正を加えるというのは実はアジャイル開発と同じじゃないのか. ただ, そのサイクルが長すぎるために気づかないだけで.
名づけるとしたらメイルシュトローム開発でしょうか. 一回巻き込まれたらもう終わり.
Re:アジャイル開発は日本には馴染まない (スコア:1, すばらしい洞察)
逆に(現実と無関係に)「予定通り[Y/y]」しか選択肢ないから…orz
Re:アジャイル開発は日本には馴染まない (スコア:4, おもしろおかしい)
「遅延が発生しました。」
・アジャイル的選択肢
1、機能の削減
2、納期の変更
3、(長期の場合)人員追加
・日本型ウォーターフォールの選択肢
1、必死で頑張る
2、死ぬ気で頑張る
3、(短期でも)人員追加して、死ぬまで頑張る
＞逆に(現実と無関係に)「予定通り[Y/y]」しか選択肢ないから…orz
修羅場モードに入りますか？ [YES／もちろん]
Re:アジャイル開発は日本には馴染まない (スコア:2)
Re:アジャイル開発は日本には馴染まない (スコア:1)
ゴムが十分に長ければ、ちゃんと着地できますよ！
Re:アジャイル開発は日本には馴染まない (スコア:2)
他にも書いたけど、
＞しかし、中間から下流にとってはアジャイルなんじゃないかと思う。
これは違う。
ためしに週40時間労働が守れてる組織がどれだけあるか聞いてみればいい。
＃これは本当にアジャイル開発を理解した上での発言なのだろうか？
＃「行き当たりばったりで臨機応変な対応」はアジャイル開発じゃないよ。
＞こういう統計を取るに当たって現場の声を聞いていないだけじゃないか？
現場の声を聞いたら、アジャイルですなんて答がでるわけないじゃないか。
日本の開発現場に夢見すぎ。
Re:アジャイル開発は日本には馴染まない (スコア:2)
いや、週４０時間残業ぐらい守れてるところ多いだろう！
・・・と思ったら、週４０時間労働、か・・・。
銀行という組織は４０時間労働らしいよ。監視が厳しくて、サービス残業できないらしい。
うちは・・・週３０時間自己啓発かな・・・。
Re:アジャイル開発は日本には馴染まない (スコア:1)
週40時間労働はXPのプラクティスの一つであって、アジャイルの本質とは関係ないですよ。
こういうのが入っているアジャイル手法は、XP以外には知りません。
＃XP=アジャイルって、何年前の認識なんだ…。
Re:アジャイル開発は日本には馴染まない (スコア:1)
結局ウォーターフォールのスケジュールを引かないと発注もらえなかったりするし。
# プライムより下請けの方が客(プライム→ユーザ、下請け→プライム)に対して与し易いとか考えて、
# わざわざ単独提案をしないのは内緒だ。
Re:アジャイル開発は日本には馴染まない (スコア:2)
「日本には馴染まない」というよりは、「多重下請け構造には馴染まない」というべきでは。
多重下請け構造から利益を得る丸投げ屋と、自分では開発にかかわらず丸投げする
顧客担当者がいる限りは、どのような開発手法もうまくいかない。日本の多重下請け構造
におけるウォーターフォールの最大のメリットは、何もできない足を引っ張るだけの
元請けの丸投げ屋さんでも、多額の報酬を得られること。
生産性と品質の低下、それに多くの犠牲者と引き替えにね。
水が流れるというより (スコア:4, おもしろおかしい)
水が流れるというより、「覆水、盆にかえらず」を体現しちゃってる開発が多い気がする
Re:水が流れるというより (スコア:2, おもしろおかしい)
>それは、実装不可能な「何とか設計書」を書くのが間違っているだけで、
じゃあとりあえず上流工程屋をまとめて全員クビにしろよ。
あいつら何にも出来ないクセに時間と金だけは浪費してるんだぜ？
それはできない相談だろ？にもかかわらず、
「役に立つ設計書を書けばいいのです(キリッ)」
って言われても、たちの悪い冗談にしか聞こえないよ。
ウォーターフォールで通してくれるならいいが (スコア:4, 参考になる)
ウォーターフォールならウォーターフォールで通してくれるならいい。
最初にきちんと仕様を決めて、最後までそれで通すなら。
現実には、制作がほぼ終わった頃や最悪の場合はリリース近くになってから
仕様変更→制作→検証を繰り返すという、
泥沼アジャイルとでも言うべき状態になることが珍しくない。
こういう状況は「ウォーターフォールがうまくいってる」とは言えないでしょう。
発注側が、下請けがそう簡単に要望を断れないことが分かった上で
最初にFIXした予算のままで仕様変更をゴリ押しで通すためのプランニング、
それが日本のウォーターフォールだな、と思います。
--------------------
/* SHADOWFIRE */
なにをもって「うまくいった」とするのか (スコア:3, 興味深い)
私の実体験のみに基づいた感覚です。
うまく行った、というより、試験に合格するため点数だけ積み上げた、というのに近いと思う。
あの有名な絵(タイヤのブランコのやつ。「顧客の説明」とか「営業の約束」とかのアレです)のとおりで、
元からして過不足がある、いびつなシステムしか作れていないのでは無いかと思う。
その点、最終的な顧客満足を得るまで何度も調整を繰り返すアジャイルとは
目指すゴール自体が違うのかな、とも思う。
Re:なにをもって「うまくいった」とするのか (スコア:1, すばらしい洞察)
ＩＴの本質は「パターン化された」「大量のデータを」「地理的環境に関係なく」「高速に処理し」「２次・３次加工も容易」という部分をどれだけ「長所として」のばせるか、と言う点だと思う。
アジャイルもコストが安い、と言う点よりは長所をどのようにのばせるか、が重要。
コスト削減は２番目か３番目か、４番目か、重要度は落とした方が結果的に会社としては良くなると思う。
そんな私は、経営とは関係ないシタッパーズ ＆ 今はシステム屋でも無し。
Re:なにをもって「うまくいった」とするのか (スコア:2, すばらしい洞察)
＞コードの質的にもユーザエクスペリエンス的にも、
＞？？？なものができあがるのは、どうかと思いますよね。
あるある。
「この機能があると便利」
「この部分は操作性に問題があるから、このように変更した方が良い」
というのが良くあるんだけど、
「仕様書を変更する許可が下りない」
「上司を説得するのが面倒」
「検証に時間がかかる」
みたいな理由でお蔵入り。
変更と実装にかかる時間よりも、ウォーターフォールが作った無意味な足枷の方が
ずっと重くて、雁字搦めで身動きが取れなくなってるのが日本の現状。
RTFA (スコア:3, 参考になる)
Agile Tokyo 2010 Continuous Delivery [continuousdelivery.com]
Indeed, everybody I spoke to confirmed that waterfall worked perfectly well for them as a software development methodology. This was staggering to me, since outside Japan large software projects run with waterfall routinely go over budget and end up with either cuts in scope or poor quality – several recent reports, such as this one [zdnet.com]
さうんずふぁみりあー?
うまく行っているというより、プロンプトもどってきた！成功！ 的な
エターナルフォースウォーターフォール (スコア:3, おもしろおかしい)
開発者は死ぬ
QCサークル活動とかの活動成果報告みたいなものですよね (スコア:2, すばらしい洞察)
これってQCサークル活動とかの活動成果報告みたいなもんですよね。
・うまく逝った活動のみが報告対象
・結果にあわせて問題を再構成
↓
・成功報告は常に大成功
うまくいかなかったプロジェクトってなかったことにして報告しないので、報道されてしまったもの以外基本的に成功したプロジェクトしか人の耳目に入らないハズ。
うまく行く以外の結論なんて出てこないですよ。
日本式アジャイル (スコア:2)
日本式アジャイルがあってもいいじゃないか -> 「アチャ」イルプログラミング
どちらも本家とはかけ離れ、それぞれの方式の優位をうたう人への反例になるだろうけど。
日本的ウォーターフォール開発の実際 (スコア:2, 興味深い)
ほぼ予定通りに比較的大きな規模のウォーターフォール型プロジェクトが終了した（とされた）例をいくつか見ていますが、下記のような流れでした。
BI～BDはエンジニアの埒外で実施され、基本的に過去の例の焼き直しに最低限の追加だけで要件が詰められていない。
FDはさすがに上級エンジニアが作成に参加しているが、不完全なBDを元にしているのでそれに従えばゴールだとは誰も思っていないが口には出さない。
DDは下請けが納入ドキュメントを作成する（でっち上げる）作業であって製造のための詳細設計ではない。
Mの段階でも下請けは出来上がるものは見えていないが単体・総合試験項目は決められるので、それを通すことだけを目的に製造する。
UT、SIは淡々と進めるが、往々にしてこのあたりで客先との会議でBI・BDの不備がいくつか発見（！）されて仕様が追加されるが、残業でなんとかする。
PT、RTの段階でBD・BI不備が致命的であることが客先との共通認識となり、（末端の人間にとっては）予定通りに緊急事態に陥る。
ここで大規模プロジェクトが違うのは、まがりなりにもそれなりに能力が高い人間が揃っていること、有害なまでに縦に長い組織になっているが他業務兼任者が少ない、つまりマンパワーに質量ともに潜在的な余裕があるところと末端のメンバーの責任感（というか耐久力というか、とにかく逃げないこと）です。
この後どうなるかというと客先担当者から末端の製造担当、試験担当、文書作成担当まで現場に横並びになり、ウォーターフォール開発がライン生産方式に変貌します。1日にウォーターフォールを何回転もさせる状況はむしろアジャイルなんじゃないかと思いますが。
もちろんこれを休日返上、現場に缶詰めで実行したとしても全てが解決するはずもないのですが、交渉によってひとまず客先の受入れ判定をパスできる要件を最低限に引き下げ、優先度が低い開発未完了項目は本番障害として管理され、運用維持として再編された開発チームが引き続き開発を行うということで納められます。
これで業務としてのプロジェクトが利益を生んだとしても、ウォーターフォール開発の実践例としては最低の部類だと思います。プロジェクト管理としては失敗だらけで、それを末端の個人の努力、しかも原動力は金銭的なインセンティブや忠誠心などといったものではなく、失敗を受け入れない文化と硬直した雇用市場からくる強迫観念といったネガティブな動機で解決した例でしかないからです。
ただ、こういった展開が期待できるのはある程度の能力、社会的地位、収入がある20代後半の日本人を相手にした場合で、徐々に通用しない場面が増えてきています。これからは恵まれた環境の大企業でもプロジェクト管理を本当にすることが必要となり、管理技術の水準も高める必要性が増してくると思います。
通常は中小企業よりも大企業の方が先進的な技術、手法の研究や導入に熱心なのですが、日本のIT企業においては逆に大企業こそ旧来の日本の商慣習に則ったビジネスを展開しているのがおもしろいと思います。
Wallfall? (スコア:1)
WallfallではなくWaterfallでは?
元の英文もそうなってますし。
# タレコミ人の名前もUnknownではなかろうか…ウンコウンでは響きが下品すぎるような
Re:Wallfall? (スコア:3, おもしろおかしい)
「要件漏れがありました」
┣¨┣¨┣¨┣¨┣¨┣¨┣¨┣ ...
Re:Wallfall? (スコア:1)
ちなみに"domino effect"って単語はあるみたいだね。
どちらかというと"butterfly effect [wikipedia.org]"という気もするけど。
＃「ウオーターフォール開発では、上流工程のわずかなミスが時間とともに拡大して、
＃ 結果に大きな違いをもたらす。そしてそれは予測不可能」
流れが止まらないからでしょ (スコア:0)
流れ行く (スコア:2)
And now for something completely different...
Re: (スコア:0)
Waterfallはこっそり直してるみたいだけどうんこはそのままなのでそういう名前の人みたいだな。
＃こっそり直してなかったことにしようとするのはしょうがないか
確かに無い (スコア:1, おもしろおかしい)
雪崩落ちてるだけかも (スコア:1)
別枝にもありますけど、それ以外が機能しないってのはあると思います。
あと、業種を別にすれば他の国にもあるとおもうのですが、力技で対応できてしまうパターン(時には良い方向に働くこともある)の一つとして「日本 - IT(?) - ウォーターフォール」という組み合わせがあるのかなと
まあ、穏やかな時でも発展的とは言いがたく、デスマりやすいですが...
# 「アメリカ - 小規模決済 - 小切手」とかもかな?
# 「中国 - 宇宙開発 - 飛ばしたもの勝ち」もか?
M-FalconSky (暑いか寒い)
Re:雪崩落ちてるだけかも (スコア:3, 興味深い)
それに加えビジネス的な課題として
ウォーターフォール以外は
「スケジュールと予算が組み辛い」
これが大きい。
アジャイルは予算面で、スパイラルは進捗説明で難儀する。
理解ある顧客ばかりではないからね。
経験的にはプロトタイプ→ウォーターフォールの順での構築が
いちばん効率がよかった
Re:雪崩落ちてるだけかも (スコア:4, 参考になる)
> 経験的にはプロトタイプ→ウォーターフォールの順での構築がいちばん効率がよかった
Winston Royce氏が発表した，もともとのウォーターフォール開発に関する論文では，そういう「二度開発することを，あらかじめ予定しておけ。まず試作してから，その知見を踏まえもう一度作り直して，それを納品しよう」と論じていたようですね。
論文の和訳 [hatena.ne.jp]にある「STEP 3: 2度行う」あたりが，該当するかと。
いつ，なぜ，この繰り返し開発の考えがスッポリ抜け落ちて，一発勝負の賭けのような危ないものにウォーターフォール方式は化けてしまったんだろう？
他にも，Always All Ways: [IT] ウォーターフォールの興亡 [pub.ne.jp] も参考になるかも。
Re:雪崩落ちてるだけかも (スコア:3, 興味深い)
あと、日本の場合、顧客側の担当に裁量権がない場合が多いです。
アメリカでは、顧客側の代表としてちゃんと裁量で判断できる人が出てきますが、
日本では、エライ人は後ろに控えていて、担当として出てくるのはメッセンジャーボーイ。
顧客企業の社員ですらないことが往々にしてあります。
これじゃアジャイルは無理です。
理解のない顧客と仕事しても、炎上のリスクを抱えるだけで、いいことなんて何もないです。
景気がよければ他の案件で埋め合わせればいいかもしれませんが、そうはいかないご時世です。
この景気の悪い時にこそ、顧客を選んで炎上の危険を回避したいものだと思っています。
Re:雪崩落ちてるだけかも (スコア:1)
「ウォーターフォールでは予算が組みやすい」というのは言い過ぎではないかな。
それは本来なら支払わなければならないはずの，「仕様変更や見積もりミスに伴う
追加予算」を支払わずに踏み倒しているので、建前では見積もりがしやすいと
いうことになっているだけ。
トラブルが発生した時でさえ、残業手当も追加要員の費用も認めないから、
サービス残業が殺人的なレベルに達したりするし、あまつさえメンバーが鬱病に
なっても過労死しても金一封さえ出ないよね。
＃原価率600％のプロジェクトとかサービス残業月200時間超(?)とか。
それらに対する正当な対価をきちんと支払ってたら、「ウォーターフォールは
予算が組みやすい」なんて、冗談でも言わなくなると思うよ。
＃他に #1808531 の問題もある。当初の設計に問題があっても、予算の変更を避ける
＃ために、問題を修正するよりは問題を放置するほうを選択する。正に本末転倒。
スルガ銀行 (スコア:1, 参考になる)
スルガ銀行がIBMを訴えた内容の一部が判明
http://srad.jp/developers/article.pl?sid=08/04/28/0541220 [srad.jp]
日本人の減点主義が生かされる場面 (スコア:1)
同じ試験をパスしていてもさあ (スコア:1, 興味深い)
いじりまくった一万行のコードでも
シンプルな100行のコードでも
同じ品質である、それどころか、前者が生産性が高い
と言われる、日本のウォーターフォール
アフリカのある部族の雨乞い成功率100%と言うが、 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
アジャイルじゃない (スコア:1)
>> 頻繁なテストやコーディング段階での修正が品質に寄与しているそうだが、
>それってすでにアジャイルと呼べるんじゃない？
違うと思う。
日本でいう『テスト』は、テスターの人海戦術や開発者のサービス残業による手動テストだから。
>修正の中には「仕様の修正」もまず入っているし。
スコープの見直しとか、週40時間労働が入ってない時点でダメ。
Re:アジャイルじゃない (スコア:2, すばらしい洞察)
ましてや、週40時間なんてのもアジャイルかどうかに全く関係ない。
orz
Re:アジャイルじゃない (スコア:1)
なんでコレに「素晴らしい洞察」が付いているのか知らないけど、
モデレータはアジャイル開発を勉強してないだろ。
Re:アジャイルじゃない (スコア:1)
Re:アジャイルじゃない (スコア:1, 参考になる)
アジャイル開発の話をするなら、まず「アジャイルソフトウェア開発宣言」 [agilemanifesto.org]と付随する「アジャイル宣言の背後にある原則」 [agilemanifesto.org] (12原則) を出しましょうよ。 公式に日本語訳されたことだし。
で、 それらにはたしかに「週40時間」という具体的な数字は出てこないけど、 12原則のいくつか (下記) からは、アホみたいな残業して疲弊してちゃダメだろ、 という結論が導かれると思われる。
# でも、 日本で一番無視されるのは、 原則の 4番目 orz
# アカウント持ってないので AC
宇宙戦艦大和モデル (スコア:2)
ああ、成功したと言う。
類の開発です。
Re:宇宙戦艦大和モデル (スコア:2)
おかげで当初の要件にない「惑星国家一つ壊滅」まで要件に入っちゃったけどね。
それでも果たすのが日本式。