- 1 名前：デスマ特攻隊長 mailto:sage [03/10/18 00:45]
- なんだかんだとデスマーチ参加者の心の拠り所
かといってこのままで良い訳がない…
そんなデスマーチに命を費やすそんな人達の
理不尽な体験や愚痴を書き込むスレ 3つ目
過去スレ
【デスマーチ参加者がもの凄い勢いで寿命を削るスレ】
pc.2ch.net/test/read.cgi/prog/1010939153/
【デスマーチ参加者がもの凄い勢いで寿命を削るスレ2 】
pc.2ch.net/test/read.cgi/prog/1038472754/
- 599 名前：仕様書無しさん mailto:sage [04/07/17 11:54]
- このスレの誰かが蜜Ｕバンクのシステム統合に行くのだろうな・・
みずぽを超えるのか超えないのか
史上最大のデスマになれるのか
- 600 名前：仕様書無しさん [04/07/17 14:57]
- >599
狙ってた統合案件もってかれちゃってこっちは火の車っすよ。
もし補償金出たとしてもこっちまではおりてこないしなぁ。
- 601 名前：仕様書無しさん mailto:sage [04/07/17 17:08]
- >>468
胃のあたりに鉛球打ち込まねばならんやつが1024人以上も？
- 602 名前：仕様書無しさん mailto:sage [04/07/18 17:36]
- 181 名前：あなたのうしろに名無しさんが・・・ 投稿日：04/07/11 20:21 ID://1hWtpi
あのさ、普通あらかじめ検証とか動作確認すると思うんだよ。
でもモノが届いたらてぶっつけ本番でサーバ構築しろって言われたんだわ。
モノは一流企業の社内LAN向けサーバ10台弱。期間は2週間。
参考書籍は市販本のみ。インストールテスト用のPC一台もなし。
パラメータはインストール寸前に届く。漏れ素人に毛が生えたレベル。
このプロジェクトやばくね？
189 名前：あなたのうしろに名無しさんが・・・ 投稿日：04/07/13 23:57 ID:tyV0g4mL
>>181
今、鯖構築といわれてもピンキリだからな。
どんな鯖よ？
190 名前：181 投稿日：04/07/15 02:46 ID:EufSe2Xe
レスありがと。今度話すわ。今日は寝かせて。死ぬ。
191 名前：あなたのうしろに名無しさんが・・・ 投稿日：04/07/18 15:33 ID:MMHL7XRd
上のレスから３日。
>>181の遺体はどんな異臭を放っているのでしょうか・・・
192 名前：あなたのうしろに名無しさんが・・・ 投稿日：04/07/18 16:54 ID:fk/hbNb8
>>191
まだ生きてるけどサーバルームで缶詰（半冷凍）と予想する。
俺等の日常はオカ板の燃料だそうですよ・・・・・・・
- 603 名前：仕様書無しさん mailto:sage [04/07/18 18:17]
- ついにこの日がやってきた、みずほ銀行の勘定系システム統合がスタート : IT Pro ニュース
ttp://itpro.nikkeibp.co.jp/free/NC/NEWS/20040716/147357/
- 604 名前：仕様書無しさん [04/07/18 23:37]
- おわらねえ・・・・
後一週間で完成させねば・・・・
巷は連休age
- 605 名前：仕様書無しさん mailto:sage [04/07/18 23:49]
- 予想デスマ突入率50%くらいのチームに入った。
それでも期間が短いだけで予算は潤沢に有ったから、
効率よくまわせば何とかこなせるかなと思っていたが、
人材不足だとかで予定通りに人が入って来ない。
上は後から増やせば大丈夫だろ、って言う。いい年して、
10人×12ヶ月と、5人×12ヶ月+10人×6ヶ月は同一ではないと
理解できてないらしい。
- 606 名前：仕様書無しさん [04/07/19 00:29]
- >>605
人月計算としても間違ってるぞｗ
- 607 名前：仕様書無しさん [04/07/19 00:34]
- >>606
人月計算としてならあってるだろ。
- 608 名前：仕様書無しさん mailto:sage [04/07/19 00:41]
- コア5人が12ヶ月フルで
バックアップ10人が中途で6ヶ月
合計120人月と言いたい訳やね
- 609 名前：606 mailto:sage [04/07/19 03:15]
- もうだめぽ
- 610 名前：仕様書無しさん [04/07/19 06:56]
-
デスマの本質は金銭欲と有名になりたいという欲求にあると思われます。
もしくは人生捨ててるか。
自分がそうでなくても、周囲か上層部がその可能性が高い。
自己満足が周囲を地獄にしているってわかってます？
- 611 名前：仕様書無しさん [04/07/19 09:19]
- 馬鹿だからだろ。
近視眼的な思考しかできない真性の低能は、餌を見ると反射的に金網に突っ込んで、
血塗れになって死ぬ。「急がば回れ」の真逆を突き進む、鶏マネジメントの典型が、デスマーチ。
- 612 名前：仕様書無しさん mailto:sage [04/07/19 10:19]
-
必要な作業を（なるべく正確に）洗い出して、
要求期間内に作業を消化するのに必要な人員（スキル面、人月面）を割り当てる。
仕様変更や不測の事態に備えて、少し余裕を見ておく。
スケジュール内でどうしても吸収できない仕様変更は、リスケとセットで受ける。
これだけやっとけば、簡単にデスマにはならないと思うけどね。
最初の「必要な作業を洗い出す」とこから出来ない（しない）リーダが、巷にはあまりに多い。
顧客の仕様変更のせいにしたり、メンバの能力不足のせいにしたりしてね。
顧客や上司を納得させる説明ができない（そも自分の頭の中で理由が明らかでない）のも問題だね。
できない作業を受ける／部下にやらせる、なんて責任を伴うプロの仕事じゃないよ。
- 613 名前：仕様書無しさん mailto:sage [04/07/19 11:34]
- school4.2ch.net/test/read.cgi/job/1088424783/323
にも言ってやってくれ
- 614 名前：仕様書無しさん mailto:sage [04/07/19 14:12]
- >>612
プロの仕事じゃないといっても、それが出来ない営業やリーダーがほとんどだからね。
だから当然デスマは無くなることはない。
なんで出来ないかってーと、他の仕事みたいに仕事量の定量化が難しいからか。
個々人によって仕事量は軽く2〜3倍は違うし、作業の分担も統合も（他の職種に比べて）難しい。
それを把握出来る人ってのは本当の意味でのリーダー（全てにおいて一番能力が高い人）だけかと。
だがリーダーが年功序列の順になってる現状では、そんな人は極一握りになってしまう。
まぁ自分が30代になるまでにしっかり力を付けて、
リーダーになった時に同じ過ちを繰り返さないようにするしかないかな。
- 615 名前：仕様書無しさん mailto:sage [04/07/19 14:57]
-
>>614
いや本当に難しいと思うよ。
でも完璧な人間がいなくても、プロジェクトがある以上、その中で最善の人選をするしかない。
リーダがダメなら、誰か能力のある人が影のリーダとなって、足りない部分を補うしかないでしょ。
（まあ、そういう形ではあまり上手くいかないけど）
そういう能力が自分も含めてプロジェクト内にないなら、諦めてデスマを受け入れるしかないね。
ちなみに、３０代になる前でも似た経験は積めると思うよ。
仕事量の見積りとスケジュールの調整を、リーダ相手にやればいいんだから。
こういうのは、一担当者のうちからやってないと、リーダになって突然できるものじゃない。
- 616 名前：仕様書無しさん mailto:sage [04/07/19 20:33]
- 定量的にとらえることが難しい対象であっても、対象をとらえる際の精度を上げることは可能だ。
そういったプロセスを構築する取り組みがPMBOKだし、
技法としてファンクションポイントなどがあったりする。
「精度をあげることで総合的な管理は可能」という命題は正しいと考えている。
定量化するのではなく、総体的に見て一定の範囲に制御することはできるはずだ。
これが組織からデスマーチを救う道の一つであることは間違いない。
しかし、これをプロジェクト単位で適用するのも適切ではない。
それでは単なる責任者探ししか行われないからだ。
あくまで組織の長期的な取り組みとして、
過去のプロジェクトの成否は後のプロジェクトへのフィードバックとして生かさなければならない。
- 617 名前：仕様書無しさん mailto:sage [04/07/19 21:36]
-
まずは、プロジェクト単位からでも適用すべきじゃないのか。
「組織の長期的な取り組みとして〜なければならない」なんて言ってる間に、悲劇は生まれ続ける。
現場でもがく人間からすれば、自分のプロジェクトが救えれば先ずはそれで十分以上だし。
「責任者探し」つーより、「適任者探し」だよね。
小さい所からコツコツと（まして、そこが自分に関係する場所なら尚更）。
- 618 名前：仕様書無しさん mailto:sage [04/07/19 22:11]
- >616の言う「責任者探し」は、
日本では大概「スケープゴート探し」と同義だからね……
仮にプロジェクト始動時には「適任者」でも、プロジェクトがコケたとき
そいつは荒海に投げ込まれる持衰（じさい）でしかない。
- 619 名前：仕様書無しさん mailto:sage [04/07/19 22:39]
- >>618
「スケープゴート探し」なんて、後ろ向きな発想だな。
暗に失敗する事を前提にしてるじゃん。
まあ、そんな政治的な色合いの濃いプロジェクトは妄想の中だけにして、現実に目を向けましょう。
プロジェクトってのは大体外面は成功してるもの（明らかな大失敗がない限り）。
問題は、そのために現場にデスマを強いるかどうかって事で・・・・。
「適任者」をプロジェクトの頭に据える事ができるかどうかは、デスマの発生確率に大きく影響すると思う。
「適任者」たる能力がある人間を、アッサリ切り捨てれる程人材豊かな組織はちょっと現実には想像できないな。
- 620 名前：仕様書無しさん mailto:sage [04/07/19 23:09]
- >>619
>政治的な色合いの濃いプロジェクトは妄想の中だけにして、現実に目を向けましょう。
知らないという事は無力だな。「妄想の中だけにして」などと煽るようなことを言うな
>「適任者」をプロジェクトの頭に据える事ができるかどうかは、デスマの発生確率に大きく影響すると思う
そうだな。そして適任者に充分な権限があればデスマの発生確率は大きく下がる。
>「適任者」たる能力がある人間を、アッサリ切り捨てれる程人材豊かな組織はちょっと現実には想像できないな
組織は「適任者」を切り捨てない。「適任者」を切り捨てる個人がいるだけだ。
組織の利益と個人の利益が常に一致するわけではない。すなわち「自己の保身を最優先にする個人」などだ。
その様な人間が存在することも現実には想像出来ないとか妄想だとは言わんよなぁ
「純朴ではあるが、良く知らない」という印象だ。
- 621 名前：仕様書無しさん mailto:sage [04/07/20 00:15]
-
妄想だと決め付けるのは、間違いだった。
そういう人間がいないと決め付けるつもりもない。
ただ、「足を引っ張る人間があちこちに」みたいな考え方は、
自意識過剰と言うか、考えすぎと言うか、評価されない事への言い訳っぽいというか、まあそんな印象がある。
能力のある人間は、よほどの事がない限り周囲の人間にとって有益だし、そんなに足を引っ張る個人がいるかな。
この世の中にそんなケースは存在しない！なんて言わないけど、上のような評価されないことへの言い訳のケースとどっちが多いのかな。
まあ、この辺りが「純朴ではあるが、良く知らない」ところなのかな。
そちらは「エクスキューズの多い、悲観主義者」って印象だね。
- 622 名前：仕様書無しさん mailto:sage [04/07/20 07:13]
- 責任って言葉は日本ではいかにとらないかってためだけにあるのだよ。
- 623 名前：仕様書無しさん mailto:sage [04/07/20 09:21]
- 結果的に足を引っ張ってる事を、いつまでたっても認識できない奴は多いような気が。
- 624 名前：仕様書無しさん mailto:sage [04/07/20 12:40]
- >>621
まあそちらが私のことをどの様に評すかは気にならない。
私としても悪口を言いたいがためにレスした訳では無い。
足を引っ張ろうと意図して行動する人間は本当に少ないが、>>623の言う種類の人間は少なくは無い。
問題が各人のスキルだけに帰着されるのならば、デスマを発生させなくすることはそれほど困難ではないだろう。
私が言いたいのは「各職掌の人間（PM除く）のスキルが不足が故に発生するデスマはない」ということだ。
スキル不足が原因となっている様に見えるデスマは、本当は「各人に対するスキル管理の不足」が真の原因だろう。
そうならばこれは「管理能力不足の人間に管理をやらせたPMの誤り」と言うことになる。
もう一つ言いたいのは「デスマは人災である」ということだ。
>>612などは妥当な見解だが、
プロジェクトに関係する全ての人間の能力に全く問題が無い場合であってもデスマはおこる。
そちらの表現を使うなら「政治的な色合いの濃いプロジェクト」で。
そちらの総論を否定するわけではない。
>「適任者」をプロジェクトの頭に据える事ができるかどうかは、デスマの発生確率に大きく影響すると思う。
これには同意する。
まあその「プロジェクトの頭」が撤収も含めて全権を保持しているか否かは最大限に重要な点だ。
権限の不足しているPMはPMの名に値しない。これもまた指揮系統不備／権限委譲不備
という政治的な問題なのだが。
私の総論は「スキルの問題を過大視しない方が良い」だ。
#とりとめのないレスで失礼した。
- 625 名前：仕様書無しさん mailto:sage [04/07/20 18:26]
- デスマーチに陥るか否かの大部分は、
プロジェクトが始まる前にほぼ大勢が決していることが多い。
プロジェクトの作業をWBSに落とし込むことが多いと思うが、
このときどの程度まで詳細化しているかを考えてみてほしい。
たとえば何らかの業務システムを新規開発すると仮定して、
運用の設計やユーザー教育、テストというような中盤から終盤にかけてのタスクを
どのくらいの粒度まで分解しているだろうか。
2ヶ月くらい大雑把に線を引いておき、「後で考えればいい」と据え置いている場合をよく見る。
これは悪夢の始まりである。
開発プロセスのV字モデルに見られるように、テストや導入フェーズの作業に前工程は厳然と存在する。
その前工程はシステムの開発当初から実施することができる。
実装作業は行わなくても、方針や設計はいくらでも行っておくことができるのだ。
プロジェクトマネジメントの(守られていない)基本中の基本として、
プロジェクト開始時にWBSを可能な限り詳細化しておくことを肝に銘じておきたい。
少数精鋭のコアメンバ(顧客含む)が1週間ほどの時間をかけて行うのが望ましい。
これ以上の詳細化は無理だと思うところからさらに3段階くらい掘り下げたい。
WBSを細かくしておくほど現状とのズレは認識しやすくなり、プロジェクトの軌道修正も容易になる。
できる限り細かい粒度のWBSを、日単位で計画しておきたい。
- 626 名前：仕様書無しさん mailto:sage [04/07/21 00:47]
- プロジェクトは「最初」が一番重要というのは禿同。
スタートを上手く切れなければ後々がうまく行くわけが無い。
最初たらたらやって最後に頑張ればいいや〜というお気楽馬鹿が多過ぎるのがね。
デスマーチが無くならないわけだ。
- 627 名前：仕様書無しさん mailto:sage [04/07/21 10:03]
- スタートは大事だね
あと、次の仕事とれないのを異常にびびって
採算度外視で仕事とってくる営業も一因かと
デスマ→やる気低下→品質低下→次の仕事無し
- 628 名前：仕様書無しさん [04/07/21 14:03]
- デスマがデスマたる所以は、未来が見えないことだ。
顧客も見えず、稼動予定も見えず、進捗も納期も見えない。
ただ無能な管理者の「頑張れ」の声だけで行軍が行われる。
五里霧中に迷っている者がゴールに辿り付けるはずもなく。
デスマーチ。
- 629 名前：仕様書無しさん mailto:sage [04/07/21 14:11]
- やばい東京めっちゃ暑い
もちろん開発室缶詰なんで風邪ひきそうなくらい寒いけど
外との気温差がマジやばい
一応、停電にそなえて臨時バックアップ中〜
- 630 名前：仕様書無しさん mailto:sage [04/07/21 14:57]
- >>624
「エクスキューズの多い、悲観主義者」なんて失礼な事言っちまった。
これは謝罪して全面撤回させてもらいましょう。
624を全部読んだけど、漏れも殆ど同意見だ。
>まあその「プロジェクトの頭」が撤収も含めて全権を保持しているか否かは最大限に重要な点だ。
>権限の不足しているPMはPMの名に値しない。これもまた指揮系統不備／権限委譲不備
>という政治的な問題なのだが。
そのとおりだね。そしてＰＭをやるなら、こういった不備を「仕方ない」で済ましちゃいけないと思う。
それは会社にとっても本人にとっても、誰よりも参加するメンバにとって大いなる不幸だからね。
- 631 名前：仕様書無しさん mailto:sage [04/07/22 01:58]
- 1倍の余裕をもって
スケジュールを組めば完璧。
3ヶ月かかるんだったら
設計・開発・テスト3ヶ月、予備3ヶ月。
これでデスマ完全駆除。
- 632 名前：仕様書無しさん mailto:sage [04/07/22 02:30]
- >1倍の余裕をもって
ﾃﾞｽﾏ ｹﾃｰｯｲ
- 633 名前：仕様書無しさん mailto:sage [04/07/22 07:04]
- ＞3ヶ月かかるんだったら
これが、事前に３ヶ月と精度よく見積もれればいいんだけどねえ。
大規模案件であればあるほど、困難なんだよね・・・
- 634 名前：仕様書無しさん mailto:sage [04/07/22 09:46]
- >>631
要件定義やら外部設計がないぞ、おい
- 635 名前：仕様書無しさん mailto:sage [04/07/22 23:17]
- >100
僕の会社にも仕事ください。
- 636 名前：仕様書無しさん mailto:sage [04/07/23 00:38]
- むかしこのスレにも書いたことある者だ。
デスマ途中で退職し、いよいよ転職先へ出向く。
デスマを生まないように自分を戒めるために、改めてスレを読み直したところだ。
転職先では、いわゆる上流工程やコンサルタントをすることになる。
ソフトウェア工学はもとより、PM、ビジネス書などもかなり読んできた。
設計や実装に責任を持つ立場から、ビジネスの視点で責任を持つ立場に移ることになる。
仕事しかせずに過ごす毎日も嫌ではなかったが、
いまではそんな毎日は、たとえ可能であるとしてもやってはならないと思うようになった。
ここにいる歴戦の者達を再び生まないよう、これから最大限に努力する。
組織や環境は個人を救わない。救うのはいつも個人だ。
おおくの場合は本人自らが自分を救うのだが、俺は他人としてお前らを救いたい。
俺が救われたように。
- 637 名前：仕様書無しさん mailto:sage [04/07/23 10:18]
- [245]仕様書無しさん<sage>
04/07/22 23:15
上司の一言ではないが、デスマで連日泊まり込みの最中、
夜中に取っ組み合いのケンカが始まったり、朝５時からの
ミーティングのテーマが「夜型生活の脱却をするには」
だったりしたら悲惨だよ。これ実話。
- 638 名前：仕様書無しさん mailto:sage [04/07/23 13:19]
- >636
少しだけ期待してる がんがれ
- 639 名前：仕様書無しさん mailto:sage [04/07/23 18:02]
- 半年プロジェクトなのに、今頃要件定義がおわた。
あと２月でクラス図などの詳細設計を作って、実装、単体テスト、結合テスト、既存システムとの連動確認テスト
・・・夏休みどころか、土日もないな。この糞暑い時期に厳しく勤労をせねばならんとはヽ(´ー｀)ノ
人員の追加ですか？実装対象の画面数が半分に減ったので増員は認められませんでした。 (ﾟдﾟ)ｳﾏｰ
- 640 名前：仕様書無しさん mailto:sage [04/07/23 20:43]
- >>636
アフォか。
自分の周りを救えないヤツが誰を救えるちゅーねん。
成功体験こそが人を成長させる。途中で逃げ出す香具師に何ができるのよ。
実際のデスマを救うのは、詰め込んだソフトウェア工学やＰＭスキルじゃないぜ。
頭でっかちの勘違い君が一人誕生か・・・・。
- 641 名前：仕様書無しさん mailto:sage [04/07/24 00:00]
- 成功体験が人を成長させるって、幼いなー
- 642 名前：仕様書無しさん mailto:sage [04/07/24 00:15]
- 成功体験で自分の経験則に自信をつける事
失敗体験で原因を考察し、自分なりに結論を持つ事
どちらも大切だ
- 643 名前：仕様書無しさん [04/07/24 00:50]
- 今日も日の出が拝めそうだ・・・
- 644 名前：仕様書無しさん mailto:sage [04/07/24 01:16]
- >>640
逃げるが勝ち。
同じこと繰り返しているところにい続けても
人生の無駄使い。
- 645 名前：仕様書無しさん mailto:sage [04/07/24 01:59]
- >月でクラス図などの詳細設計を作って、実装、単体テスト、結合テスト、既存システムとの連動確認テスト
クラス図?、いらね
まず結合テストと既存システムとの連動確認テストの設計から始めろ
その後、単体テスト&実装が終わったら結合&連動確認テストだ
ここまで1.5カ月
- 646 名前：仕様書無しさん mailto:sage [04/07/24 07:53]
- 30を超えると成功体験でしか成長しなくなる
- 647 名前：仕様書無しさん [04/07/24 09:09]
- 50を越えると過去の成功体験にすがりついて成長しなくなる。
- 648 名前：仕様書無しさん mailto:sage [04/07/24 09:26]
- 成功体験なんて諸悪の根元だろうに。
少しは経営学の本でも読んでみろや。
- 649 名前：仕様書無しさん [04/07/24 09:43]
- 『市場の変化がますます加速している』 かつ、『個人が過去の成功体験に基づいて行動している』 とき、
『現在市場に必要とされている行動が取れない』ため、『市場への対応が遅れる』 わけで、
『企業の業績が悪化する』 ことは明白だと思うんだが。
違うかな？
- 650 名前：仕様書無しさん mailto:sage [04/07/24 11:29]
- ビジネス書を読むのは偉いが
それを鵜呑みにして畑違いな分野まで持ち込もうとゆーのが、もうね
- 651 名前：仕様書無しさん [04/07/24 11:34]
- そうそう。
実務経験の乏しいライターの講釈なんて鵜呑みにしてたら、害虫スレの144のようになる。
- 652 名前：仕様書無しさん [04/07/24 11:57]
- なるほど。
だからこの業界は焼畑農業時代から脱却できないのだな。
- 653 名前：仕様書無しさん mailto:sage [04/07/24 16:36]
-
>>642の言うとおりでしょ。
失敗体験（または、それを観察すること）で原因を考察し、自分なりに結論を持ち、
それを元にした成功体験で、自分の経験則を作り出す。
あとは、その経験則を盲信せず、見直し改善を加えていく。
>>648や>>649は、このデスマスレでは勘違い君だな。
それとも、実務経験ナシの妄想君か、実態は見ようとしない暴走君か。
- 654 名前：仕様書無しさん mailto:sage [04/07/24 16:58]
- 成功体験は、諸悪の根源というわけではないよ。
充分に成熟し変化が起こりにくい環境で、
何がどれだけ達成されると成功とされるかが明確な状況において、
その指標を的確に達成するには成功体験を持つ者のほうが有利だ。
しかし、それほど硬直的な場所はどこにもない。
まだ、失敗体験のほうがマシかもしれない。
失敗する方法はどんな状況でもほぼ同じだが、成功する方法は状況ごとに異なるから。
- 655 名前：仕様書無しさん mailto:sage [04/07/24 18:18]
-
成功体験豊かな人より、失敗体験の豊かな人のほうがマシだって・・・・・？
漏れの経験では、プロジェクトを成功させる人は、大体において別プロジェクトでも成功できる。
逆にプロジェクトを失敗させる人は、別のプロジェクトでもやはり失敗しがち。
成功体験を基にした経験則って、ＰＭにとって物凄い貴重なスキルだと思う。
漏れなら、成功体験豊かなリーダの率いるプロジェクトに参加したいけどね。
- 656 名前：仕様書無しさん [04/07/24 19:08]
- >>655
20年前の成功体験を振りかざすPMなら、差し上げますが。
- 657 名前：仕様書無しさん mailto:sage [04/07/24 19:12]
- >>655
おまいは面接の度に「このプロジェクトのリーダーは常に成功を収めてきましたか？」
なんて聞くのか？
- 658 名前：仕様書無しさん mailto:sage [04/07/24 19:14]
-
>>656
その後も成功体験を重ねてるなら貰ってもいいです。
お返しに、若くしてＰＭの立場になったけど、いまだ連敗中のＰＭはどうですか？
豊富な失敗体験をもってますよ。
- 659 名前：仕様書無しさん [04/07/25 02:46]
- printf("もう辞めさせてください。");
- 660 名前：仕様書無しさん mailto:sage [04/07/25 06:12]
- >>659: In function `main':
: undefined reference to `printf'
collect2: ld returned 1 exit status
- 661 名前：仕様書無しさん mailto:sage [04/07/25 08:02]
- >>654
>失敗する方法はどんな状況でもほぼ同じだが、成功する方法は状況ごとに異なるから。
本当か？
- 662 名前：仕様書無しさん mailto:sage [04/07/25 09:48]
- >>661
>>失敗する方法はどんな状況でもほぼ同じだが、成功する方法は状況ごとに異なるから。
>本当か？
違うと思うけどね。
失敗する原因は無数にあり、失敗する人は、毎回少しづつ違う原因で失敗を繰り返す。
成功する人は、その時々で違う失敗に繋がる要因を、破綻しない程度にクリアすることができる。
>>654はプロジェクトというものを知らないのか、とてつもない切れ者かのどっちかだね。
- 663 名前：仕様書無しさん [04/07/25 12:51]
- 成功する方法は一つだと思う。
・目標を明確にして、努力する。
要件定義や仕様確定が出来ていないと、
「目標を明確にできていない」わけで、
失敗がほぼ確定する。
努力だけで目標に達成できるというのは、
一部の無能管理者の信仰に過ぎない。
- 664 名前：仕様書無しさん mailto:sage [04/07/25 15:07]
- ・目標を明確にして、努力する。
これだけ知ってれば、目標に達成できるというのは、
一部の無能管理者の信仰に過ぎない。
「努力する」なんて精神論持ち出してる時点でアンタ終わってるよ。
『プロジェクトが成功しないのは、各メンバの「努力が足りない」せいだ。
漏れは用件定義や仕様確定をキチンとやった。』
なんて日頃から言ってるんだろうね。
アンタと一緒に仕事してる香具師が可哀相だよ・・・
- 665 名前：仕様書無しさん [04/07/25 16:43]
- >>664
「努力が足りない」なんて言っていないが。
「努力が足りない」なんていう奴は、それこそ
努力＞＞＞＞＞＞＞＞＞目標
って思い込んでるんだよ。馬鹿の代表。
私は、重要度で言うと、
目標＞＞＞＞＞＞＞＞＞努力
だと考えている。完全に逆の立場だ。
私は開発者に100の努力を求めるより、
その前の工程に10の努力を求めるほうを選ぶ。
そのさらに前の工程に1の努力を求められれば、
それが最良だ。
本来、努力とは「頑張ること」ではない。「結果を出すこと」だ。
- 666 名前：仕様書無しさん mailto:sage [04/07/25 17:28]
- >>665氏の言わんとしてるのは、概ねこんなところかな？
・開発者の頑張りに頼る状況となった時点でもうダメぽ。
・要件定義や仕様確定などの上流工程にこそ力を注ぐべき。
・頑張ってること自体に意味はない．結果を出してこそ．
間違いじゃないと思うけど、そんなこと常識じゃないの？
（少なくとも、このスレで異論のある人はいなさそうだけど）
その総論を、現実に当て嵌める所でＰＭクラスは皆苦労してるわけで・・・
- 667 名前：665 mailto:sage [04/07/25 18:46]
- >>666
君はそれらが常識だと言いながら、
実際には現実に当て嵌めることができないと言う。
ここに、矛盾がある。
この矛盾は、一体何故生まれるのだろうね。
- 668 名前：仕様書無しさん mailto:sage [04/07/25 19:16]
-
>>666
本を読んだりして「それ」を知る（理解する）ことは簡単だけど、
実際に「それ」を実行しプロジェクトを成功させることは極めて難しい。
ここに矛盾がありますかね？
知るだけで皆成功するなら、デスマなんてこの世に存在しませんよ。
何故せくさせることが難しいかは、ソフトウェア開発の持つ色々な特性故でしょう。
これも知ったからといって、どうにもなることじゃないでしょうが・・・・
665はＰＬやＰＭの経験はないの？経験してれば難しさは理解できると思うけど。
- 669 名前：665 mailto:sage [04/07/25 19:23]
- >>668
なるほど。ソフトウェア開発の持つ特性故に、
知識を実践することが困難である、というわけか。
では、「ソフトウェア開発の持つ特性」とは何だろう？
PLやPMの経験が無い私に、どうか教えてくれないかな。
- 670 名前：仕様書無しさん mailto:sage [04/07/25 19:55]
- 実現する要件と工数、納期まで現場にいない営業や管理者が決めちゃうこともあるからな。
一度でもデスマでモノが出来るのを経験したら、
「実務者に与えた損害＝管理者・会社の利益」と考える管理者が出来上がるのは無理もない。
この図式が根底にある人が部長クラスにいるとかなり厳しい。
漏れも露骨なのは一人しか見たこと無いけど、その人が関わると常にデスマだったよ。
出世も早いから本人は面白くて仕方がないかも知れんが、行軍させられる方は氏ぬ。
- 671 名前：665 mailto:sage [04/07/25 20:15]
- >一度でもデスマでモノが出来るのを経験したら、
>「実務者に与えた損害＝管理者・会社の利益」と考える管理者が出来上がるのは無理もない。
ほう。それは斬新な評価基準だね。
「時は金なり」という格言があるが、それと同じくらいに矛盾している。
喜ばしいことに、私はデスマでモノが出来る経験はしたことが無いよ。
XSS脆弱性まで抱えた致命的なバグだらけのソフトウェアが捻り出される
現場にいたことはあるが……「モノが出来る」経験はしたことが無い。
ところで、残業代はどうなのかな？
- 672 名前：仕様書無しさん [04/07/25 20:50]
- 携帯開発のスレでYRP常駐の生々しいハナシが面白い。
- 673 名前：仕様書無しさん [04/07/25 21:13]
- >672
久々にこのスレを超えるレベルの話だな。
俺たちも負けてられない。誰かネタを頼む！
- 674 名前：何をいまさら mailto:sage [04/07/25 21:23]
- 横須賀 陸の孤島 プリズン
- 675 名前：仕様書無しさん mailto:sage [04/07/25 21:24]
- >>669
漏れの考えるソフトウェアの特性（デスマに繋がるもの）は大きく２つ。
・出来栄え（品質）を確認するのがむずかしい・モノがちゃんと出来ているかわからない。
（レビューやテストなど、相当のエネルギー／技術を必要とする）
・担当者やその時の状況で生産性が大きく変わる。
このため、「やれば出来てしまう（出来ているように見える）」ケースがある。
これが根本的な原因だと思う。（やらせれば出来ると誤解する香具師、計画をキチンと立てない香具師がでてくる）
ちなみに漏れも「デスマで良いモノが出来る経験」はしたことが無い。
よい作業プロセスがよい製品を生むというのが、マイ経験則だな。
よい作業プロセスを確保するために、顧客や上司相手に調整を繰り返すわけですな。
で、かなりスレ違いになりつつあるので、申し訳ないが今後はＲＯＭらせてもらう。
満足なレスも出来ずトンズラになるっぽですが・・・勘弁して。
- 676 名前：665 mailto:sage [04/07/25 21:58]
- >>675
・出来栄え（品質）を確認するのがむずかしい・モノがちゃんと出来ているかわからない。
（レビューやテストなど、相当のエネルギー／技術を必要とする）
Plan-Do-Check-Actionサイクルでの『Check』工程が難しい、ということか。
結果、効果的な改善策が行えないままになり、生産性が停滞しつづける。
つまり、『Check』工程に明確な指標を策定しない限り、問題は解決しない。
・担当者やその時の状況で生産性が大きく変わる。
人間や気候が関わっている多くの業界では、生産性は『統計的変動』の影響を受ける。
別の業界でも起こり得る問題だが、IT業界では客観的計測が難しい『開発者の体調』などに
大きく影響を受けるため、見落とされがちで、『統計的変動』が引き起こす影響は特に顕著だ。
スレ違いっぽいレスに答えてくれてありがとう。非常に参考になったよ。
- 677 名前：仕様書無しさん mailto:sage [04/07/25 22:06]
- >>671
もちろん正規のコストを払うケースに比べれば品質は落ちます。
でも革命的なモノを作ってるわけではないので、
お客様の検収に通る程度のモノにはなるのです。
残業代も全額は貰えません。
残業代払ったら、実務者に損害を与えられないですから。
- 678 名前：665 mailto:sage [04/07/25 22:21]
- >>677
なるほどなるほど。
ソフトウェアの品質＞顧客の検収基準
という前提を満たしつつ、サービス残業によって作業時間を確保し開発を進めるという方針か。
これは私の推測だが、現場には未テストのコードが沢山あるのかな？
この方針の抱える問題は、デスマーチ推進者が顧客とのコミュニケーションに
失敗したり、品質の管理に失敗したりすることで、
ソフトウェアの品質＜顧客の検収基準
になってしまったときだろうね。この状況は極めて危険だ。
顧客がゴネて売上の入金が遅れたり、入金しなかったり、
契約違反だとして損害賠償を求められたり、
悪い噂が流れて次の仕事が取ってこれなくなったりする。
もしかしたら、こういう状況でも体力のある一次請けは倒産せずに生き残るかもしれない。
だが、二次請け三次請けはキャッシュフローに苦慮しているところが多いと聞く。
倒産しちゃうかもなー。
- 679 名前：仕様書無しさん mailto:sage [04/07/25 22:23]
- 以前、デスマプロジェクトが佳境に入った時、
>>670の言ってるような上司が首を突っ込んできて
大変な状況になったことがある。
その上司が来た当日から全員総出で職場に泊まり込みの
毎日が始まり、寝たいと訴えても「みんなも寝ずに働いて
いるのだから、君だけが寝てもらう訳には行かない」と、
寝ることすら許されない状況に。
（まぁ、許可なく勝手に睡眠は取ってましたが。）
風呂にも入れず、良くて週１回シャワーが浴びれるかどうか
なんて調子で一月以上突っ走った後、今度は食事の時間や
休憩時間までも制限し始めたのでたまりかねて抗議したら
「オレは昔からずっとこのやり方でやってるんだ。この状況を
乗り越えるにはこうするしかないんだ。」と言って聞かなかった。
結局、納期が伸びて仕切り直しとなったらしい。
- 680 名前：仕様書無しさん mailto:sage [04/07/25 23:07]
- 誰か、
「『実務者に与えた損害＝管理者・会社の利益』と考える管理者」に
「自分で何やってるかわかってます？
そこまでして出世したいですか？」って聞いてみてよ。
- 681 名前：仕様書無しさん mailto:sage [04/07/25 23:25]
- 「オレがいつお前達に損害を与えたって?!
誰のおかげで仕事ができると思ってるんだ!!ふざけるな!!」
と逆ギレされるのがオチだと思われ。
- 682 名前：仕様書無しさん mailto:sage [04/07/25 23:35]
- >>681
まぁ、その通りﾀﾞﾅ。
そう言うﾔﾂは、
「自分が来たからこのﾌﾟﾛｼﾞｪｸﾄは完遂出来たんだ。｣
と言うﾀｲﾌﾟが多いし。
- 683 名前：仕様書無しさん mailto:sage [04/07/26 00:04]
- そろそろ、無能連中の議論見るのも飽きたんだけど、
おもしろいネタないの？
- 684 名前：仕様書無しさん mailto:sage [04/07/26 00:17]
- 部下全員でシカトするのが最良の方法かと
- 685 名前：仕様書無しさん mailto:sage [04/07/26 01:40]
- PGだろうがSEだろうが部長だろうが役員だろうが
デスマに疑問をいだかない企業は老い先長くないよ。
失業率にかまけてPGが増えてる今だから通用してるけど。
- 686 名前：仕様書無しさん mailto:sage [04/07/26 02:23]
- ttp://homepage3.nifty.com/dochikushow/diary/comic/mazu.htm
「納品さえ済めば、プログラマは死んでも問題ない」
- 687 名前：仕様書無しさん [04/07/26 04:56]
- デスマから開放されましたが。
なにか？
- 688 名前：仕様書無しさん mailto:sage [04/07/26 10:11]
- 以前デスマ中に、外注のＰＧの♀がぼやいてた
「わたしは事務職として会社に入ったのに・・」
なんか、派遣した会社の体制とか、これがデスマの一因かとか
事務職でプログラミングはひどいよねとか、受け入れたうちも悪いのか？とか
やっぱりこの業界ゆがんでるな。とか。
いまさらだけど色々思って悲しくなった・・orz
- 689 名前：１ユーザ mailto:sage [04/07/27 01:29]
- お馬鹿ちゃんな営業とかすっとばしてみんなとお話できたらいいのに。
- 690 名前：仕様書無しさん [04/07/27 06:43]
- 今年の４月に中小ソフトウェア会社を退職して、工事現場で空調設備の仕事してます。
転職するときは肉体労働が嫌でしょうがなかったですが、やってみると意外と面白い。
朝は早いですが、６時には仕事終わるし残業代も全額出る。
プログラマ時代は定時で帰る事なんか月に一度。しかも定時で帰ると時間がありすぎて何していいか分からない。
デスマーチを経験すると辛くても耐えられるなぁ。
- 691 名前：仕様書無しさん mailto:sage [04/07/27 09:54]
- 私もシステム開発の仕事が能力がついていけず辞めました
今は介護職についてますが交代制だから時間がくれば帰れるし
夜勤当直といっても多少眠いのを我慢してればいいんです
デスマーチで徹夜してもものができず、夜が明けていくあの焦燥感に
くらべればたいていのことには耐えられる
- 692 名前：仕様書無しさん mailto:sage [04/07/27 11:19]
- >>478
｡･ﾟ･(ﾉД‘)･ﾟ･｡
- 693 名前：仕様書無しさん [04/07/27 11:19]
- >>690-691
スレ違いだが・・
人並みの生活できるようになったのか
おめ。もう二度とこっち側に戻って来るなよ
- 694 名前：仕様書無しさん mailto:sage [04/07/27 11:48]
- >>553
戦地に行かない奴ほど、好戦的なんだよな。
- 695 名前：仕様書無しさん mailto:sage [04/07/27 12:03]
- 若くても脳卒中とか普通になるから、「寝るな」とかいう会社とは、早い目に縁切るんだな。
俺はまあ、生き残ったからカキコの一つも出来るがな、急性のやつは、生き残るのも難しいぞ。
あと、体普通に動かすってのは、すごく難しいものだってのを、もれなく体感できる。
生き残れば、な。
- 696 名前：仕様書無しさん [04/07/27 14:18]
- プロジェクトが始まって以来
毎月残業が300時間越えるのはデスマーチですか？
一週間寝ないと視界がモザイクになり流れ星のようなノイズが走るのは
脳の仕様でせうか？
- 697 名前：仕様書無しさん [04/07/27 14:23]
- そりゃー、おまえあれ、あれだよ
デスマーチだよ
ノイズが走るのはおまえの仕様
残業が300かぁー
スレタイどーりに凄い勢いで寿命を削ってるな
- 698 名前：仕様書無しさん mailto:sage [04/07/27 14:41]
- 始まって以来って、最初からそれかよ！
- 699 名前：仕様書無しさん [04/07/27 14:55]
- >>698
すでに完了した仕事だけど
無理やり客にねじ込まれた仕事でね
他のプロジェクトから引っこ抜かれて
要件定義や見積もりから運用指導まで全部一人で3ヶ月でおわらせろって
やつだった
|
 |
