ウォーターフォールに何もメリットはない？ 153
ウォーターフォールじゃないと下請けに丸投げできないのでは 部門より
アジャイル開発が広がる昨今でも、大規模開発ではウォーターフォールといった考えが主流と思われるが、そうした考えを一蹴する、MicrosoftのDevOpsエバンジェリストの牛尾氏による「私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い」というブログが微妙に注目を集めている。
事の発端となったのは、先日来日した米Microsoftのプロジェクトマネージャで「No.1 DevOps Person」と呼ばれるサム・グッケンハイマー氏と日本企業とのやり取り。氏は企業からの「アジャイルと、ウォータフォールのメリット・デメリットを教えてください」との質問に対して「ウォータフォールは一切メリットがないので止めておきなさい」ときっぱり言い放ったとのこと。これを見て、これまでそう思いつつも、周りを気にして「大規模開発ではウォータフォール」などとしていたことに気づかされたという。
記事によれば、2015年時点で世界のソフトウェア開発プロジェクトのうち実に95%がアジャイル開発に移行済みで、また海外では技術系の書籍もアジャイル以降の考え方が前提となっているにも関わらず、日本ではいまだアジャイル開発を採用しているのが31%に留まるなど、大幅な遅れを見せている。また「大規模ではウォーターフォール」と言いつつ最大規模のソフトウェア会社であるMicrosoftは当にアジャイル化を終えており、海外の技術系ではウォーターフォール押しの企業など存在しないとしている。
現在の日本でウォーターフォールが続いているのは、単に日本がウォーターフォールを前提として制度を作ってしまっていることに起因すると分析している。今までは内需で賄えていたが、この状況で海外企業が乗り込んでくればまさに竹槍で戦闘機と戦うようなもので一溜りもなく、日本の習慣や現状を新しい考えに合わせて変えるべきとまとめている。
無いよね (スコア:3, すばらしい洞察)
一度やってみれば誰でもわかる。
作るものを細大漏らさず最初に決めるなんて、
誰にもできないもの。
Re:無いよね (スコア:2, おもしろおかしい)
最近アジャイルは死んだと聞いた
水の流れで溺れ死んだのかと
Re: (スコア:0)
最初に決めてなかったから、ということにできた方がいいでしょ。
Re:無いよね (スコア:1)
そういう細かい事情説明は何の役にも立ちませんて。
一番下っ端の最下流が非を問題にされて責めを負うことだけが決定事項。
Re: (スコア:0)
で、予算と期間は決まってるのに、作るものの子細を決めずに作り始めるわけね。
Re:無いよね (スコア:1)
＞ そもそもそれがおかしいというのがアジャイルですから。
もっと言えば
『「期間が決められる」または「この期間でどれだけできる」と数か月以上のスパンで、なんのデータもなく、作ったことの無いものの作業を予想できると思っているのがおかしい。』
というのがアジャイル開発のうちのタイムボックスで分割する理由の一つ。
Re:無いよね (スコア:1)
> 日本でもパートナー企業周辺はドキュメントもないし、口頭指示だし、作り直しも頻発してて、アジャイル開発だと言っていいと思います
ドキュメントが無いとか口頭指示とか作り直しとか全てアジャイル開発とは関係無い。
公的部門の情報システムが原因かも (スコア:1)
せめてスパイラルモデルを取り入れられるように、組織の偉い人が情報システムの特性を理解してくれれば良いんだけど。
Re: (スコア:0)
そんな国や自治体って世界的に見ても少数派だと思うのですが(個人の感想です
うじゃうじゃ
Re: (スコア:0)
少数派だからどう、って話でもないと思う
公用語が日本語なのも、主食に米を食うのも、夜中に女性が外を一人歩きしても然程危険がないのも、バカみたいに鉄道が発達してるのも、魚を生食するのが普通なのも、世界的に見たら「少数派」ではあるのだが、それが悪いことかどうかというと別問題だし
自治体に潤沢というほど潤沢に予算がある国なんてそう無いだろうし、単年度主義とかが明確に駄目とは限らないんじゃないかなぁ
# もちろん欠点があることは認めるが、それが利点と比べて大きいかどうかは別問題だ
Re: (スコア:0)
いや、世界的にも多数派でしょう。(個人の感想)
Re:公的部門の情報システムが原因かも (スコア:2)
「ブラウザ経由でICカード読むこと」に固執する必要無いよね
言い方じゃないのかなあ (スコア:1)
そりゃ全部まとめて1個のウォーターフォールじゃ時間もかかるしうまくいかんでしょ。
フェーズプランというか、ある程度小分けした単位で小さな滝が流れていけば、アジャイルといっしょじゃないのかなあ。
Re:言い方じゃないのかなあ (スコア:1)
2週間単位でフェーズプランを立てて、
それに合わせてPDCAを回していろいろ工夫しつくせば、
アジャイルと同じになりますね。
開発モデルじゃなくてさ (スコア:1)
ビジネスモデルの話でしょ。
利用者の運用まで考えずに開発だけアジャイルにしたって
意味ないどころかむしろ悪化するよね。
まず完品しか興味のない客の考え方をどうにかしないと。
Re: (スコア:0)
ポジショントークですね
作る方は継続的に金出せよと思ってるけど、発注側は稟議は１回にしたいから、こうなっている。
Re: (スコア:0)
利用者の運用まで考えるのがDevOpsでは。
大規模？ (スコア:1)
「大規模に向いている」の方が幻想なのでは？
どっちかというと、技術的な問題の少ないもの
プログラマの技術力を問わないプロジェクト
に向いていると思うwww
あと、組織的な行動が得意な日本人（いろいろな意味が入っているけどw）に向いているかと
あとは、試行錯誤が必要なプロジェクトには向いてないなどもあるね。
Re:大規模？ (スコア:1)
「大規模に向いている」は、
アジャイルの初期に言われた話が語り継がれているだけではないですかね。
アジャイルが生まれてからまだ20年程度。
初期に書かれた意見がまだググったらたくさん見つかる時間しかたってません。
で、大規模開発はもともと難しい面がたくさんあるので、
ノウハウがたまっていないと失敗しがちですね。
他の難しさとは違って、アジャイルが特に得意である理由もなかった。
いうならば、
アジャイルはウォーターフォールと同程度に大規模開発が苦手、でしょう。
ウォーターフォールができてあまりたってない1980年代、
いったいどれだけ大規模なシステムが開発されていたというのか。
Re: (スコア:0)
アジャイルとの相性は規模ではなく意思決定権の所在で決まるんだろ。
顧客が指定した機能を搭載していく受注開発型に不向きで顧客から吸い上げた要望を取捨選択できる商品に向いている。
早い話ウィンドウズやマイクロソフトオフィスのようなソフト。
予算が将来にわたって安定的に確保できるか否かも重要だろうね。
アジャイルやると要件がぶれまくる (スコア:1, 興味深い)
「アジャイルでやりましょう」と言って始まったプロジェクトは要件がぶれまくって酷いことになりました。
ウォータフォールだと客側の責任者として「それなりに偉い人」が立つので、ぶれないのですが、アジャイルだと偉い人が立たないので……
# ビジネスフローが曖昧な客の所ではウォータフォールが無難です。（アジャイルやると終わらない）
notice : I ignore an anonymous contribution.
MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
恥ずかしくないのかなぁ、この肩書き。
Re:MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
日本で、英語由来のカタカナがきで使うと恥ずかしいものかもしれないが
北米であったり、英語使ってであれば何も恥ずべきシロモノではないと思う。
細かい条件で(日本で、日本語話者を相手に…など)こだわりすぎていませんか?
Re:MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
前例があるから恥ずかしさはないのでしょう。
だから胡散臭いことが否定理由にならないという問題は棚上げすれば、だが。
Re:MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
＞"DevOpsエバンジェリスト"の前例
ないでしょうね。
新奇な何かを普及させる役割がエバンジェリストの存在意義。
古臭い別の何かを普及させるためには相応の異なる肩書きを採用するはず。
オフトピですが。
// てっきり「エバンジェリスト」がカタカナ書きだから否定的見解なのだと…
Re:MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
それはDevOpsに対して疑念・猜疑心を抱いているということなのではないか?
と言っては言葉が過ぎるでしょうか?
// Evangelist であると自称して開き直らないとやってられないミッション
// だという事を否定するつもりはありません。DevOps 如何に関わらず。
Re:MicrosoftのDevOpsエバンジェリストの牛尾氏 (スコア:1)
伝道師と名乗れというのか。
そっちのほうが恥ずかしいと思う。
雇用・契約形態が全て (スコア:1)
海外や国内いずれにおいても、大規模システム開発には、
「初期の開発時期は維持保守の時期に比べて人数が大量に必要」という特性があります。
この特性にフィットするための方法は雇用制度や契約形態のために、国や地域で異なります。
例えば、今回の記事で出てきた国でいうなら、
アメリカ:開発時期に要員を雇用・実費償還契約し開発完了後は維持保守の要員を残して解雇・契約終了
本邦:保険機構、人材派遣業、商社機能を兼ねたSIerを元請けとして一括請負契約し元請けが多段下請け構造に投げていく
という違いが出ます。
アメリカなどで、アジャイルのいわゆる「チーム内顧客」や「計画ゲーム」が成立するのは、
「顧客が雇用した専門家が顧客側の意志決定者として存在しうる」、
「実費償還契約故にやっただけコストがかかるため、顧客側がどこまでやり込むかを決定する動機がある」
といった、契約の特性に由来する事情があるからです。
本邦で、パッケージやインハウスの開発以外の、大規模システムでアジャイルが成立し得ないのは、
「顧客側の意志決定者が基本的に素人」(大体は管理、よくても維持・保守程度の要員であるため開発経験が薄い)、
「チーム内顧客が法的に不可能」(一括請負契約でそれをした場合、厳密には「顧客→元請け」も「元請け→下請け」も偽装請負)
「一括請負で全てのリスクを受注者が既に負っているため、顧客側に自分でリスクを制御する動機が薄い」
といった、同じく契約の特性に由来するもので、
本邦で「アジャイルで自社以外の案件の開発」を売りにしているSIerはどこも一括請負契約以外の契約形態を
併せて提案しているのもそのためです。
また、本邦で繰り返しのないウォーターフォールが主流であるのも、
「工程ごとに契約を分割することで一括契約のリスクを軽減している」(工程が逆流するとリスク軽減効果が減少する)、
「工程ごとに下請けへの発注を行うことで人員数を制御しコストを制御する」(工程が逆流するとコスト制御効果が減少する)
等々の契約の特性に由来しています。
おそらく、グッケンハイマー氏はアメリカの雇用・契約形態を前提に語っており、
筆者の方はそこを読み取れていなかったという話ですね。
アメリカの一部でのアジャイルにせよ、本邦の繰り返しのないウォーターフォールにせよ、
流行り廃りや技術の高低ではなく、雇用・契約形態という容易に変えがたい制約条件があるなかで、
「制約条件から自動的に導き出された最適解」
であるので、制約が変わらないかぎりは、
本邦の大規模システム開発でアジャイルが用いられたりはしないでしょうね。
※その他、本邦SIerにおける多重下請け構造や「顧客にいち早く価値を届けるよりも瑕疵がないことを重視」といった
方向性も同様に雇用・契約形態に由来するものですが、それはまた別の話。
はやく海外企業が乗り込んできてくれればよいのに (スコア:0)
どうせ本当に戦闘機が飛んでくるまでは、竹槍を握った自分が如何に愚かなんて気づかないのだし。
腐臭漂う日本のソフトウェア開発業界は、さっさと外力で思い切り焼き払ってもらったほうが幸せに思います。
Re:はやく海外企業が乗り込んできてくれればよいのに (スコア:2, 興味深い)
日本のソフトウェア開発業界が本当にダメならとっくに焼き払われてると思います。
発注側はとしてお金はあるので。
実際問題、商習慣と言語の壁は思ったより厚い。
アジャイルのような素晴らしい開発手法を使ってることよりも、
効率悪くても、今の文化で仕様が正確に伝わって、それなりの製品が作れたほうが嬉しいから残っているのではないかと。
# つまり、物理的に戦闘機が飛んできて物理的に焼き払えば実現できますね(オイ
Re: (スコア:0)
これだよね。結局のところポジショントークで、日本の商習慣の壁を壊せないから「日本のやり方はクソ」って言ってるだけ。
それでも意識高い系の経営者とかは騙されて「よし次の社内システム更改はアジャイル開発しよう」とか考えちゃって海外企業にいいようにされる、って程度の効果はあるだろうけど。
どんな国にも面倒な商習慣とかの壁はあるから（アメリカだとヤードポンド法とか、ＥＵだと面倒な規格対応とか）別に日本に限った話じゃないんだけどなぁ。
Re: (スコア:0)
> どうせ本当に戦闘機が飛んでくるまでは、竹槍を握った自分が如何に愚かなんて気づかないのだし。
いやそのくらいじゃあ気づきもしませんよ。というか気づいてたとしても誰もやめようと言わない。
焦土にされても本土決戦に向けて意気軒昂。新型爆弾2発落とされて、かつ同盟破棄されて参戦されてやっと諦めるレベル。
Re: (スコア:0)
アジャイルなんて言い始めて何年も経つのに、何時戦闘機が攻めてくるんですか。
空襲食らってから考えるでしょう。
日本企業の、発注側がね。
Re: (スコア:0)
ゆとりの十八番、環境転嫁&シンデレラ願望ですね。
Re: (スコア:0)
あれ？この前日本IBMが思いっきり案件コケさせて [it.srad.jp]なかったっけ？w
水流 (スコア:0)
ウォータフォールモデルこそ至高です
これ以上簡潔な作り方はありません
ウォーターフォールのメリット (スコア:0)
トラブった時の責任を曖昧に出来る
って誰かが言ってたな・・・ 隣の隣の席の上司だっけ？？？
Re: (スコア:0)
逆じゃないの？
ウォーターフォールだと、各段階でドキュメントが作られるんだから、
どこのドキュメントで問題が発生したかわかる。で、それを書いた奴の責任。
すべてのドキュメントに間違いが無いなら、コーディングした奴の責任とはっきりする。
Re:ウォーターフォールのメリット (スコア:1)
レビューで問題点を見抜けなかったレビューアー全員の責任になるからじゃないでしょうか?
Re: (スコア:0)
レビュープロセスにも責任者はいるでしょ。
適切にレビューを実施していなければリーダーないし統括責任者の責任だし。
そもそも責任者曖昧にしてとくするのは発注者側で、
請負側が責任切り分けられなかったら費用の交渉なんてできないじゃん。
どんな管理してるんだろ。
アジャイル化した (スコア:0)
結果があのWindows10なんでしょ？
駄目じゃん
Re:アジャイル化した (スコア:1)
同意
Re: (スコア:0)
Windows10がああなったのはああしたいからでしょう。客の声に耳を傾けるせいでもある。あえて言えば昔のウインドウズは一年おきにでていたのでまあアジャイルに近いウォーターフォールだったんじゃないかね。
Re: (スコア:0)
とWindowsXPユーザーが申しております。
CMMってウォーターフォールですよね？ (スコア:0)
CMMは米国発だと思ってたのですが…
F-35はどうなる？ (スコア:0)
F-3の方が深刻かも。
なんとかおじさん (スコア:0)
ちょっと前まで static おじさんが結構な割合で生息してたけど最近はすっかり駆逐された感
ウォーターフォールおじさんも年貢の納め時ってことでしょう
Re:なんとかおじさん (スコア:2)
手動プラスモデ＋５
すばらしい洞察
Re:そもそも受注型は「世界的には珍しい」 (スコア:1)
発注側も本当に決済権を持っている人ならともかく、決済権を持ってる人に説明をする係だと、工程表があった方が費用の根拠を説明しやすい。
だから日本では大規模予算(≠開発)ではウォーターフォールの方が意思疎通がしやすい。
出来上がったものは細部は誰の希望とは一致しないかもしれないけど、期間とお金は予定通りに消化出来る。足りなくなるけど。
Re:何のメリットも無いって言うとウソ臭くなる (スコア:1)
って言うかすごく頭悪そうに聞こえるんだけど
それはわからんでもないが。
いままでウォーターフォールでうまくいった“ものもある”んだから、何のメリットも無いことはないやろ。
そんなことはないんじゃない?
そのウォーターフォールで上手く行ったものを、アジャイルでやったらもっとうまく行く、とかだったら。