地獄的アジャイル？火消し？
こういうことよくあるんだよなあ。
アジャイルというより、これはただの火消しなんじゃあ？
件の記事では、「このプロジェクトの教訓」の一つとして、
建て直しの成功要因はアジャイルである
ということを挙げているが、少数の優秀な人間が無理やり何とかしただけなんでは？
火消しの場合、少数精鋭が投入されて(あるいは元々いて)その人たちで何とかするってケースが多いけど、そういう場合、アジャイルとかそんな大層なものじゃない気がする。
それはそうとして前のプロジェクトでは、まさにこの記事のような感じだった。
もう納期もスケジュールも破たんしている以上、とにかく「作る」「見てもらう」「動かしてもらう」、そして「指示してもらう」。この方がはるかに早いのです。
現場も上のように主張したんだけれども、設計者たちが強固に反対して泥沼な状況に陥っていた。特に、当時のPLが「ウォーターフォール」って看板を首から下げているようなタイプの人間だったので、とにかく文書文書手続き手続き。
破綻した手法や計画にこだわられても、現実的じゃないよなあ。ドキュメントだけ作ったところでプロダクトは出来ないもの。
そもそも、設計者のほとんどが、実装出来ない・アーキテクチャが組めない人間だったので、破綻しない訳がないプロジェクトだったんだけど。
日本のソフトウェア産業が上手くいっていないのは、「ウォーターフォール開発」のせいだとか、「元請け-下請け構造」のせいだとか言われているけど、実際のところは、その両方が合わさって上手くいかなくなっているんだと思う。
元請け(SE)/下請け(PG)って形で賃金もSEのほうが貰っていたりする訳だけど、元請け会社の人はろくに開発のことを知らないままだったりして、仕様・見積(時間と費用両方)で現実的でないものを出してきたりする。
自分が、SE側の人間になって思ったのが、PGからの叩き上げのSEが少ないというか、開発や技術を判ってないというか、そんな人間が物凄く多い。
そりゃ上手くいくわけがない。
ウォーターフォールにこだわる人が多いのも、「元請け-下請け構造」を崩したくないからだと思う。フェイズがしっかり区切られているから、外部に出しやすいしね。
なんとなく元請けって、問屋みたいなもので中間マージン抜いているだけのようなところがあるから、仕様とか見積だって甘くなって失敗に近づくんじゃないだろうか。(実際に大変な目にあうのは、大概、PG側で、物凄く無茶をさせられたりする。)
んで、ウォーターフォールの場合、見直しとか手戻りとかするようなフェイズがないから、余計状況が悪化するだけと。
でもウォーターフォールが必ずしも悪なんではなくて、日本のソフトウェア産業の構造と組み合わさった場合、酷いことになるんじゃないかなあ。
案件に対するノウハウも蓄積されていて、仕様・技術・スケジュール・手法等の不確定要素が少ない場合だと、効率がいいんじゃないのかな。
アジャイルは不確定要素が大きい場合にもっとも有効なのかもしれない。んでもって、最近は、短い納期・低コスト・早い対応を求められるケースが多いから、アジャイルのほうがそういうものには向いているんだろうな。
でも、大規模プロジェクトをアジャイルでっていうのはどうなんだろう？管理コストとか、ウォーターフォールの比にならないぐらいかかりそうな気もするんだけれども。
この辺り、識者の意見を聞いてみたい。
