「7pay問題を扱った記事に対し「それはウォーターフォール・モデルではない」との指摘」記事へのコメント

私の知ってるウォーターフォールモデル

[akiraani (24305)]

工程をいくつに分けるかとかは規模でも変わってくるだろうけど

・バグ管理とかを工程ごとに分けてチェックして品質をきちんと確保できてから、下流のフェイズに移行する

というのが鉄則だろうと。

ウォーターフォールのメリットは、あとどれくらいでアウトプットが出せるのか、現時点でどれくらい遅れているのかが把握しやすいということ。
デメリットは、上流のバグが下流で見つかるととんでもない時間ロスをすること。なので、上流がいい加減だとそのプロジェクトは必ず火を噴く。

納期、予算を計画的に配分している場合はウォーターフォールのメリットが強く生きる。
一方で、後戻りさせたときのロスがひどいので、外部要因での変化が大きかったりで要件や仕様が頻繁に変わるような案件には向かない。

7payの場合、最上流を管理する立場の人たちの認識がお話にならなくて「工程を終わらせる」という作業ができていないまま次の工程に移り、しかも後戻りを認めていない……ようにしか見えない。
ウォーターフォールは上流でのミスが致命傷になるやり方なので、トップがあれだとそりゃあ下流は地獄を見ますわな。
かといって、あんな規模のものでお金がかかわるようなものをアジャイルで作れってのも無理があるし、トップがあれでは同じ間違いを延々繰り返して無限反復になりかねない。
開発形態のせいにするのはちと無理がある。

--
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される

Re:私の知ってるウォーターフォールモデル

[Anonymous Coward]

結局はオムニ７の脆弱性が問題だったわけで。

7payを作り出すときに
決済アプリを作りますよ。認証は既存システムのID使うよって言われたら
じゃあ認証の性能保証はそっちでやるんだ。うちの仕事じゃないなって思うもん。
え、そっちで担保してくれるんじゃないの？
そこでワザワザ、これから繋ごうとしてるシステムに問題がないかアセスメントなんかやんないよ。

想像だけどさ

Re:

[Anonymous Coward]

下請けがオムニ7の方も調べて問題点を報告しても、
その下請けが管轄外の、即ち無意味な報告出してきたって事で減点してお仕舞い、てなりそ。

Re:

[Anonymous Coward]

今の時代にウォーターフォールやるなら、マイルストーンを細分化してゴールを雲の上から見えるように段階化させること。
不明な点があるなら、思い込みで仕事するのではなくコミュニケーションをとって共通認識であるようにすること。
さて、これは何て手法よ。