カレーなる辛口Javaな転職日記 RSSフィード

2008年 12/31

「現場の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/sm3070618

Part1:http://csx.jp/~inko/swf/dm.swf

Part2:http://csx.jp/~inko/swf/end_of_dm.swf

システム障害はなぜ起きたか~みずほの教訓

システム障害はなぜ起きたか~みずほの教訓


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:『ソフトウエア・ファクトリー』ってそういう意味だったりして.

*4http://d.hatena.ne.jp/JavaBlack/20081004/p3

*5:こんな感じで。 http://d.hatena.ne.jp/JavaBlack/20081226/p1

のぶあきのぶあき 2009/01/01 12:06 工事進行基準…機能するんですかねぇ?
絵に描いた餅、形骸化、もしくは辻褄あわせに
結局下請けに押し付けられて泣かされる図式になったりして

JavaBlackJavaBlack 2009/01/03 10:12 そもそも工事進行基準とシステム開発と,いったい何の関係があるのかと.そんな感じです.工事進行基準は上に挙げたデスマになる問題点のどれとも関係してないですよね.
むしろお役所の単年度予算とか入札制度とか,SI的日本企業的な人月単価や多重下請け丸投げ制度にメスを入れるべきかと.

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト

コメントを書くには、なぞなぞ認証に回答する必要があります。