まとめ
メニューを開く-
デスマーチは人を壊すので絶対に許すわけにはいかない。そうやって開発者をやめてしまった人もいる。自分やチームを追い込んでいいものを作りたいなら、スケジュールで追い込むのは最悪のやり方だ。 -
私、すべてのデスマーチに関わりたくない！！ 全ての宇宙、過去と未来の全てのデスマーチをスルーする！！」 -
俺思うんだけど、虚淵さんはデスマーチで人や人間関係が壊れるのを見て来たから、まどかを作れたんだと思うんだよね。この前、全話見直してそう思ったよ。RT @nezumimusume 私、すべてのデスマーチに関わりたくない！！ 全ての宇宙、過去と未来の全てのデスマーチをスルーする！！」
-
デスマーチは人間関係壊れるよねー。ボロボロだったよ。マジで。
-
うーん、スケジュールで追い込むのとデスマーチを強行するのは別の話なんだがなぁ…。PMの仕事が理解されない理由がちょっとわかる。 -
うーん、スケジュールで追い込むのとデスマーチを強行するのは別の話なんだがなぁ…。PMの仕事が理解されない理由がちょっとわかる。
-
むしろ、デスマーチにしないための予防措置として進捗の可視化を行う必要があるわけで。
-
むしろ、デスマーチにしないための予防措置として進捗の可視化を行う必要があるわけで。
-
このノートに名前を書かれたプロジェクトはデスマーチになる -
かくいう自分もデスマーチの原因の一つだったことがあるので、その反省を踏まえて、やはりデスマーチは決してよくない。それを回避する技術や方法はいくら研究してもし過ぎることはない。そこにゲーム開発の明るい未来があるかもしれないよ。ちょっと玄人的だけどね。それは開発者を大切にすることだ。
-
そういえば、専門の時に「デスマーチについてのレポート」を書いた記憶があるな。まぁ内容はそんなに求められていなかったけど（どっちかっていうと、そういうものがあるから注意するんだっていうのが目的だったみたい。 -
自分のやれた範囲だとスケジュール以前に １．まず機能毎の工数を出す ２．工数が出せない行程を発見、そこを最初に持ってくる算段をする ３．工数を実際の人間・期間に当てはめてみる ４．個人毎の消化速度の差を融通 ５．クリティカルチェーンを調整 ６．公開・運用し、工数見込みの甘さを補正
-
ここまでやってやっと、「スケジュール通り作りましょう」と言えるんじゃないかと。そのスケジュール運用中にデスマ突入するようなら、デスマを解消する方法も自ずから分かるはず。
-
といってもまぁ実際できることって、工数（≒仕様）を削るか、期間を延ばすしかないんだけど。クリティカルチェーンがキツキツの段階で人をぶっ込んでデスマ解消される例は希。
-
デスマーチが起きるのは、未来より現在を優先させるからですよ。 -
Wikipediaによると、デスマーチは常軌を逸して過酷なプロジェクトの事。与えられたのが必要な期間の半分、スタッフが必要な人数の半分、要求機能や性能が想定の二倍、などが目安とされている。それにより残業、徹夜、休日出勤の常態化などが起こる。 -
デスマーチだと感じたときに必要だと思うのは、まずほんとにデスマーチなのか確認する事。次にどこがデスマーチなのか確認する事。そして、そこをなんとか出来ないか交渉する事。要求された事をそのままがむしゃらにやってしまって公開するというのはよくあるパターン。
-
やる事は多い、人数は増えない、期間も伸びない、クオリティは落とせない、そして交渉も出来ない、しかも成功率は低い、というのは間違いない本当のデスマーチだが、幸いにして私はまだそこまでのものに出会った事はない。それでも、デスマーチなのでは？ という疑問は十分に人を蝕む。
-
デスマーチTLなんてあったの -
Content from Twitter
コメント