『デスマーチとはプロジェクトが抱える責任を全てプログラマにおしつけるということ』
ソフトウェア開発のデスマーチの惨状を聞くと、ほとんど例外なくプログラマが徹夜で頑張っている。逆に言うと、プログラマが徹夜で頑張るしかないプロジェクトほどデスマーチになる確率が高いと言えるだろう。 プログラムを書かなければソフトウェアが完成しないのはその通りだと思うが、遅れた原因はプログラマにだけあるとは思えないのに、なぜプログラマだけが苦行に耐えないといけないのだろうか。 従来の開発方法の場合、原因ははっきりしていて、前工程が遅れて、納期は変わらないから、プログラミングの工程に全てのしわ寄せが来るのである。 やっかいなのはプログラミングの工程自体はスケジュール通りに始まっているというケースである。仕様が確定していないのになぜか並行で工程が進んでしまう。こうなると関係者はスケジュールはやや遅れているが問題ない（平行で動いているので効率的とまで思ってしまう）という認識になりやすい。 クリティカ
あなたは“デスマーチ・プロジェクト”とどう闘うか？
「Web 2.0で語られる『永遠にベータ版』を聞くたびに、それって『永遠にデスマーチ』と思えてしまうんですよね」——。弊社の某誌編集長のひと言である。 「デスマーチ」という言葉を聞くとき、読者の皆さんも最新トレンド技術の開発動向を思い浮かべ、ニュースをにぎわすシステムダウンを思い、最近音信不通の知人に思いをはせ、自分自身の今の境遇を振り返るのではないだろうか。 デスマーチ・プロジェクト——過酷な条件でのソフトウエア開発プロジェクトに、そう名づけた人物がいる。米国のコンサルタント、エドワード・ヨードンである。 1980年代に構造化方法論を、1990年代オブジェクト指向方法論を提唱したことで知られるヨードンが、1996年に著した本のタイトルが『デスマーチ』だった。当時、無謀なプロジェクトに対する皮肉のきいた文章や辛口の批評が面白く、一読者として楽しんだ。しかし、今回『デスマーチ 第2版』の日本
ここギコ！: デスマーチの作り方 -ある程度の規模の組織には、情報を送り出す強力な心臓が必要-
2006年02月12日 デスマーチの作り方 -ある程度の規模の組織には、情報を送り出す強力な心臓が必要- デスマーチの作られる原因にはいろいろあるとは思うけど、一つには規模や性格の異なる案件で、これまで自分達が成功してきたやり方で押し通そうとすることがあるんじゃないかと思った。 2桁単位の開発人員でのプロジェクト、顔を合わせるだけで情報が交換できるようなプロジェクトでは、チームリーダーが週1回ミーティングして意識合わせするだけでよかったかもしれない。 でもこれまでそんな開発ばかりやってきたところが、いきなり3桁人員の開発プロジェクトを引き受けて、これまでどおりのやり方でやろうとしても、うまくいくはずがない。 プロジェクトの血液とも言える新鮮な情報はあちこちで行き渡らなくなり、規模が大きいだけにリーダーの数も多いので、定例のリーダー会議とやらは際限もなく続いて時間を無駄にするばかり。
デス・マーチとＣＭＭ
デス・マーチとＣＭＭ （１９９９／２／１４，２０ 全面見直し＆一部項目の追加・訂正） 『デスマーチ』（Ｅ．ヨードン著、松原友夫／山浦恒央訳、トッパン刊）という本が出ています。既に読まれた方も大勢いるのではないでしょうか。この本の副題に「なでソフトウェア・プロジェクトは混乱すのか」とある通り、この本は、現状のソフトウェア開発現場の混乱の状況を分析し、デスマーチに陥らないための幾つかのヒントが紹介されています。 この本の論点は、最後の７章「常態としてのデスマーチ・プロジェクト」にあります。それは原書の副題が「The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects」となっていることからもうかがい知ることが出来ます。要するにこの本は、これからは市場の要請も厳しくなって「デスマーチ」が「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
