「現場のSE, PGが考えるデスマる条件とは」
http://alfalfa.livedoor.biz/archives/51412678.html
- ウォーターフォール
- 低スキル - 大人数開発
- 人月単価
- 多重下請け構造:技術のないピンハネ屋と下請け苛めの最強コンボ
- 時代遅れのスキル
- 年功序列:組織に自らを改善する仕組みがないため,COBOLerなどの老害を排除できない.
- 「設計工程」と「プログラミング工程」(製造工程)を分割する
- 「上流工程」という名目で時間と資金を浪費
- PMBOKやITSSが幅をきかす.
- 技術者の意見より管理職や営業の意見(或いは願望)が優先される.
- コン猿が大きな顔をする.
- 実現可能性も分からないまま無理難題をふっかける顧客.
- しかもそれを断らない担当者.
- 鉄筋減らしてコストダウン.
- 技術よりもコミュニケーション能力が重要と言ってはばからない:低スキル - 大人数開発の裏返し.
- 機能が際限なく追加される.
- 意味もなく頻繁に仕様変更.
- しかも納期と予算はそのまま.
- さらに人を追加する.
- 指揮系統が複数あって,それぞれから矛盾した命令が下りてくる.*1
- 特に組織内部に利害の対立がある場合は最悪.複数の業者に分割発注している場合や,一企業内部の部門間の対立などがある場合がこれに該当する.*2
などなど.
でも突き詰めると,そのほとんどは『多重下請け構造』の結果にも見える.多重下請け構造こそが日本のIT業界の構造的問題であり,日本がデスマーチ量産工場と化していった原因と言えよう.*3
レバレッジ経営・レバレッジ開発: http://d.hatena.ne.jp/masayang/20080920/1221876250
デスマーチ大作戦
http://www.nicovideo.jp/watch/sm3070618Part1:http://csx.jp/~inko/swf/dm.swf
Part2:http://csx.jp/~inko/swf/end_of_dm.swf

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))
- 作者: Jr.,フレデリック・P.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2002/11
- メディア: 単行本
- 購入: 8人 クリック: 167回
- この商品を含むブログ (175件) を見る

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者: エドワード・ヨードン,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2006/05/03
- メディア: 単行本
- 購入: 9人 クリック: 355回
- この商品を含むブログ (119件) を見る

- 作者: 日経コンピュータ
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2002/06/03
- メディア: 単行本
- 購入: 1人 クリック: 12回
- この商品を含むブログ (36件) を見る
119 仕様書無しさん :2008/09/13(土) 14:54:16
責任感無い人この業界多いよな?それがデスマの原因だろ。
それは原因ではなくて結果。
責任感ある人は、転職するか過労死でいなくなる。
一瞬で同じことを考えた.
デスマの経験をしたことないマは一度経験して欲しいw
確実に何か人生変わるぜw
そこで人生が終わるかもしれないぞ.
他にも参考になる意見が大杉.まったく嫌になる.orz
http://b.hatena.ne.jp/entry/http://alfalfa.livedoor.biz/archives/51412678.html
他業界から見てると、それだけ失敗案件だらけで、よく会社倒産しないよな。どこで利益出してるんだろ?
小さい所は普通に潰れてます.ごく普通のことなので,滅多にニュースになりません.*4
大きい所は下請けいじめとか,下請けのサービス残業で穴埋めします.単価切り下げを『お願い』(という名の命令)してくることもあります.*5
あと,基本的にデスマのリスク分込みで見積もりするとかね.
発注側と受注側のリテラシーがかけ離れている場合、発注側はとりあえず叩いてみるというプレイをするしかない。信用創造は受注側の仕事だと思う。
それがダメなんだってば....orz
「とりあえず」で開発者(と会社)を潰さないで欲しい.
「信用創造」なんて「オレは信用しないよ.もっと『誠意』を見せろ(=値引きしろ)」というお客の前では無力です.
マネジメントの折り合いがすべて。で、折り合いがつかないならスタートしないこと。工事進行基準も始まるし、これに合わせられないならそれは最初のマネジメントができてないという事。
これは嘘くさい.「工事進行基準」なんてプログラミングをやったことのないバカが何も考えずに作った奴だろ.
「スーツ(笑)」の人なんかがこういう意見を鵜呑みにするから困る.
*1:その矛盾を現場でなんとかすることを「行間を読む」や「コミュニケーション能力」という言葉で誤魔化さないでもらいたい.命令が矛盾している時点で,その命令は単純に実行不可能.可能なのは,いずれかの命令を無視することだけだ.
*2:大人数プロジェクトの大半が該当する気もする.
*3:『ソフトウエア・ファクトリー』ってそういう意味だったりして.