5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

この会社辞めようと思った腐れ上司の一言#0x13

1 :憑かれたマ:04/10/23 14:10:01
作業現状を全く把握していない上司の一言。
時代に取り残された上司のトンデモ一言。
キバヤシもびっくりの電波一言。
そのような恨みつらみを語り合いましょう。

前スレ
この会社辞めようと思った上司の一言#0x12
http://pc5.2ch.net/test/read.cgi/prog/1095668367/

過去スレは おいおい。

2 :憑かれたマ:04/10/23 14:10:34
【過去スレ】
 この会社辞めようと思った上司の一言
  #1. http://mentai.2ch.net/prog/kako/992/992259973.html
  #2. http://pc.2ch.net/prog/kako/1003/10034/1003497181.html
  #3. http://pc.2ch.net/prog/kako/1024/10247/1024763650.html
  #4. http://pc.2ch.net/prog/kako/1034/10344/1034469344.html
  #5. http://pc.2ch.net/prog/kako/1036/10365/1036592708.html
  #6. http://pc.2ch.net/prog/kako/1039/10393/1039356915.html
  #7. http://pc.2ch.net/test/read.cgi/prog/1040889506/
  #8. http://pc.2ch.net/test/read.cgi/prog/1046862372/
  #9. http://pc.2ch.net/test/read.cgi/prog/1052406871/
  #A. http://pc.2ch.net/test/read.cgi/prog/1056418451/
  #B. http://pc.2ch.net/test/read.cgi/prog/1059282090/
  #C. http://pc.2ch.net/test/read.cgi/prog/1066523696/
  #D. http://pc.2ch.net/test/read.cgi/prog/1070528461/
  #E. http://pc3.2ch.net/test/read.cgi/prog/1075987262/
  #F. http://pc3.2ch.net/test/read.cgi/prog/1080728238/
  #10.http://pc5.2ch.net/test/read.cgi/prog/1084716778/
  #11.http://pc5.2ch.net/test/read.cgi/prog/1088578899/

3 :仕様書無しさん:04/10/23 14:13:00
>1 おっ津。

4 :仕様書無しさん:04/10/23 14:13:26
そして加齢に3ゲトゥ

5 :仕様書無しさん:04/10/23 14:14:28
更に過激に生まれ変わったなw
1乙。

6 :仕様書無しさん:04/10/23 16:04:16
作業パターン別にチェックリストを作れと言われて地道に数えてみたら、
すごいパターン数になったから、分割マトリクスにしてみた。4枚くらいになった。まあ
実用的なサイズに収まったと思う。

おれ 「さすがに全パターンのチェックリストを作ると、一ヶ所違うだけで別パターン扱いになって
数百枚になるから、実用的じゃありません。
いざ使う時に数百枚から今回のパターンを数枚選ぶなんて無理ですから、マトリックスにしました。
実際に使う時にはマトリクスからチェックリストを作れるようにしてあります。」
上司 「楽するんじゃなくて、俺の言う通りつくれよ」
おれ 「数百枚になりますよ?」
上司 「数百枚だろうがなんだろうがちゃんと作れ」
おれ 「確認させて下さいね。数百枚のチェックリストを渡しますけどそれでいいんですね?」
上司 「そうしろっていってるんだ。黙ってやれ」

黙ってマトリクスを列で分割してコピー&ペーストでチェックリストにして、数百枚印刷して
渡してあげました。マトリクスについては、「そんなお前が楽したもんはいらん」だそうなので、
ファイルも消しました。

いまは誰に見られる事も無く、バインダに挟んだ状態で棚に大事に保管されてるそうです。

7 :仕様書無しさん:04/10/23 16:11:16
>>6
かわいそうだな・・・
強く生`

8 :仕様書無しさん:04/10/23 17:08:26
>>6
マトリクスを展開するスクリプト組めばすぐにできたのでは…
もちろん上司には「一所懸命やりました」という顔をして提出。

9 :仕様書無しさん:04/10/23 20:32:26
そ〜いうときはさあ、サンプルを2〜3枚裏紙にでも刷って
「こんな感じのが数百枚にもなりますよ。現実的じゃないですよね
マトリックスで出しましょうか」って話を持ってくもんだよ

いきなり意図のと違う形を持ってっても相手も意地になる
だからといって何も考えずにそのまま数百枚提出したら
それはそれで「なに紙の無駄遣いしてんだ。ちっとは考えろ」とか
言う輩なんだろうけどな…

10 :仕様書無しさん:04/10/23 20:37:33
>6
「楽するな」って楽するための開発じゃないか。この業界。
バカジャネーノ

11 :仕様書無しさん:04/10/23 22:52:24
>>9
むろんそうしたよ。「言ってたのはこういうイメージですよね(紙を見せる) 〜中略〜 現実的じゃないんで、
こういうマトリクスにまとめてみました」と。おれとしてはチェックする側も紙数百枚渡されるよりチェック
しやすいだろうと思って...
そのあと数百枚をチェックしたかどうかは知らない。してるわけないんだろうけど。

>>8
うん、マトリクスからチェックリスト化するのはそんなにはかからなかったんだよ。
むしろ枠線とかをきれいに調整するほうが...

う、そこをVBAでやればよかった.....orz

12 :11:04/10/23 22:54:56
しかしまあ政治的には、もう一段階前のフェーズでも設けて、さりげなく
「数百枚になってあなたが大変ですよー」とかやっといた方がよかったかな、
とは思う。

13 :仕様書無しさん:04/10/23 23:01:18
手ぬるい。
政治的には、数百枚ものチェックリストを奴が一人で
チェックせざるを得ないよう自業自得パターンへ持ち込んでおくべき。
#もちろん、その上の上司に密告して効率の悪い事する阿呆上司だと印象づけておくんですよ?


14 :仕様書無しさん:04/10/23 23:14:31
「チェックまだぁチンチン」をしつこくやれば。
て、そんなこと言ったらお鉢が回ってきそうだしなあ。

15 :仕様書無しさん:04/10/24 00:22:03
必要なのは物量であって内容と質ではなかったりする・・・・

効率良いと思って少なくすれば「少ない!楽するな!」といわれ、
意地になって大量に作るとちょろっとしか確認しないで書棚の肥やし・・・・・orz


16 :仕様書無しさん:04/10/24 01:27:33
で、結局品質は上がらず、と。
orz

17 :仕様書無しさん:04/10/24 01:56:24
>>15
>必要なのは物量であって内容と質ではなかったりする・・・・
ステップ数が作業量の唯一の基準
残業時間ががんばっているかどうかの唯一の基準

・・・・


18 :仕様書無しさん:04/10/24 02:01:41
体育会系根性バカ上司にとっては、楽をする=手抜き

19 :仕様書無しさん:04/10/24 04:03:13
漏れの現上司はチームが楽できるようになる提案は快く採用してくれるが、そーじゃないのは渋る。
良い上司だと思うのだが、「既存のソースは、要求通りに動く限りなるべく手を加えない」のを徹底させた挙句、
プロダクツが泥縄的実装(読み辛くはないが、ツッコミ所満載)の塊になってしまうのが玉に瑕。
ソースを見る度にリファクタリングしてぇと悶絶するのは、贅沢な悩みなんだろうか。

20 :仕様書無しさん:04/10/24 04:17:42
有効性の証拠を見せないと動けないんじゃないかな。
リファクタリングした後に動作の検証漏れが出るリスクがある限り採用できないと思う。
作りっぱなしで無責任なことはできんからね。
再テストの工程含めて期間内に作成できる計画があるなら説明したらどう?

21 :仕様書無しさん:04/10/24 08:31:54
xUnitでまず網羅的なテストスィートを作れ

22 :仕様書無しさん:04/10/24 12:33:33
Javaで書かれたWebシステムの既存コードの機能拡張の設計を
UMLでやれって言われてるけど、ソースを調べたら1画面1クラス1JSP、
クラスの中は初期化メソッドとリクエスト受付メソッド(ダラダラ書いてあって500行はざら)くらい、
DBアクセスはSQLを直接渡す専用クラスという代物だった。
エンティティありません、コントローラも何も全部1メソッドで書かれてるじゃん、という状態だったので
画面クラスだけのクラス図を出したら、リーダー経由でコンサルが
「バウンダリしかないんですが、御社は手続指向で開発してるんでしょうか?」
と言ってきた。
そうなんじゃねえの?
これPHPで書いたWebシステムと大差ないし。
アクティビティ図って言い張ってフローチャートでも書きますか?

23 :仕様書無しさん:04/10/24 12:37:45
で、どこに上司がでてくるんだ?

24 :仕様書無しさん:04/10/24 13:15:57
>>22
そんなんでいちいち会社辞めてたら、入る会社がなくなってしまう

25 :仕様書無しさん:04/10/24 15:14:49
DB周りがほぼ決まったのが先週末。
画面部品のプロパティ名の命名基準は先週末に客に提示で、まだOKがでていない。
それなのに詳細設計とコーディングが同時並行で行っています。

すばらしい企業様です。目立は。害虫の俺が見てもうらやむ進行状況管理です。
営業日ベースで15日の遅れにも微塵の不安を感じさせません。

是非こんな状況でも平静にいられる上司になってみたいです。

26 :仕様書無しさん:04/10/24 16:08:22
15日ぐらいならまだ大丈夫

27 :仕様書無しさん:04/10/24 20:13:43
>>25
もしかして私と一緒のプロジェクトにいる関連会社の方ですか?


28 :仕様書無しさん:04/10/24 21:49:40
実装だけを中国へ投げるっていっているアホンダラがいるのってうちだけ?
要求定義は外注は踏み入れてはいけない聖なる領域みたいだし。
設計とプロジェクト管理(!)はうちら外注の仕事。
上司が言っているオブジェクト指向っていったい何なんだろうと思う。


29 :仕様書無しさん:04/10/24 22:02:04
要件定義:請けもと
基本設計:請けもと、外注
詳細設計:請けもと、外注
PG開発:中国、外注
コーディングチェック;請けもと、外注
単体テスト:中国、外注
結合テスト:請けもと、外注
客先テスト;請けもと、外注

全体スケジュール管理;請けもと
PG開発スケジュール管理;外注

というのを体験したことはある。

30 :仕様書無しさん:04/10/24 22:07:34
>>25
えーと、俺のこと言われてるみたいでドキッとしたが、
目立とあってほっとした。

31 :仕様書無しさん:04/10/24 22:11:26
他でもそうなんかよ
NヨC?

32 :仕様書無しさん:04/10/24 22:35:39
>>25
進捗管理の面で一番余裕あったのが目立だった。PJによるけど。
目立 >> IBM >>>>>> 不治痛 >>>> ... >> NヨC だな。

技術はともかく、目立は素晴らしい会社だと思う。(マジで)

33 :仕様書無しさん:04/10/24 22:39:19
>>28
日本の低能プログラマに任せるより、上海あたりの中国エリートPG
集団に投げる方が、良いもの出来そうだとは思うけどな。

百歩譲って日本のPG連中による成果よりいくらか低質だったとしても、
どうせ業務アプリなんて中身は五十歩百歩でたいしたことをやってな
いし、海外投げはお得。


34 :仕様書無しさん:04/10/24 22:52:36
いいよな、奴らに関わった事の無い香具師は気楽で。

35 :仕様書無しさん:04/10/24 22:59:49
仕事とプライベートをめりはりつけてるのは別に中国人に限ったことでもないし
日本以外の国では普通のこと
日本が異常なだけだろうに、日本人はもっと楽していいんだよ実際

36 :仕様書無しさん:04/10/24 23:03:15
>>27
金勘定系で都内で作業をしてます。これ以上は機密保持のため。

>>33
ちなみに上海は単価高騰なので、上海より南か北京より北に投げるとお得。
内陸部でも良いと思いますよ。、南京や重慶とかw

害虫なのであちこち渡り歩いてますが、
進捗管理が一番うるさかったのは4大じゃないところだった。
今のところ4大メーカーだとこんな印象だな。
I>F>>>N>>>>>>>>>>目立
これで目立がリカバリを見せたら変わるけどな。

37 :仕様書無しさん:04/10/24 23:04:34
目立は
「単体テストにおいてはキロステップあたりn個のバグを見つけなければならない」
とか変な決まりが多くて嫌なんだよ。

この場合、結局バグの捏造が横行するわけなんだが。

38 :仕様書無しさん:04/10/24 23:12:29
だいたいそんなにあわててシステム作る必要がどこにあるんだい
みんなのんびりやったって誰も困りやしないよ
自分で自分の首を絞めるのはもうやめようよ


39 :仕様書無しさん:04/10/24 23:18:35
>>33
>上海あたりの中国エリートPG集団に投げる方が

優秀な中国人は中国にはいないよ。優秀であればあるほど
外国に逃げていく。

40 :仕様書無しさん:04/10/24 23:35:23
>>36
そのプロジェクト、超大型ですか?

41 :仕様書無しさん:04/10/24 23:41:26
優秀な日本人は日本にはいないよ。優秀であればあるほど
外国に逃げていく。

42 :仕様書無しさん:04/10/24 23:43:33
>>37
目立がどうして採用しているのか知らないけど、それ、COBOLの頃の名残なんだと。
COBOLの業務アプリって結局MOVEとか四則演算の羅列(単純な処理をダラダラと書く)だから、
バグ件数=係数×ステップ数 が、概ね成り立っていたらしい。
バグはケアレスミス以外ほとんど発生しないという前提だね。

だから、そういう仕事じゃないんなら無意味な指標だよ。

もしそういう仕事をしてるなら、バグを捏造してるって事は係数が大きすぎるんだろう。
係数を改訂すりゃいいんだろうけど、みんながバグ捏造するなら正確な統計は取れないだろうね。
訳も分からず形だけ真似てるからそんな事になるんだな。

43 :仕様書無しさん:04/10/25 00:43:28
>41
そうでもない。

44 :仕様書無しさん:04/10/25 07:13:18
オフショア開発ってどうかなぁ?


45 :仕様書無しさん:04/10/25 08:21:14
> 「単体テストにおいてはキロステップあたりn個のバグを見つけなければならない」
旧二種では、単体テストでこれだけテストして、これだけバグが見つかったら
テストされて無い部分の残りのバグはこれくらいあるだろう。
と予測を立てる物だったはずなんだがなぁ。

いつの間に予測された数だけ見つけなきゃならない物になったんだ?


46 :仕様書無しさん:04/10/25 08:56:46
工程中に「ここでバグを最低○個見つける」なんていうフェーズがあって
なおかつスケジュールが遅れ気味だったら絶対捏造するよなぁ…。

そして多分そんな規則があるとすると
コーディング規約とかもバグを防ぐ効果が無いようなものばっかりなんだろうな。

47 :仕様書無しさん:04/10/25 09:02:31
>>45
アホが仕切って自分が理解できる範疇に収めようとするから。
Java で定数を切り出す設計にしたら「即値で書け」と怒り出したあほプロマネがいたぞ。
なんでプロマネがそこに口を出す?
当然デスマって死屍累々だたーよ。w

48 :仕様書無しさん:04/10/25 12:49:28
>>44
現在オフショア開発中
出てくるソースは本当に単体テストしたのかよこれ、つーレベルです。
マジでいやになってきた

49 :仕様書無しさん:04/10/25 14:46:28
営業マンからのメールが上司から転送されてきました。
この営業マンを見習えとの意味を込めて。

メールの内容は
「座っているだけでは受注できません。動いて頑張るのみです。」
と。

受注しただけで社長表彰。
しかもかなり無理してるからこちらが死ぬ。


50 :仕様書無しさん:04/10/25 14:59:45
帳尻合わせしなくていい奴は楽でいいよな。 営業ってホンマむかつく。

51 :仕様書無しさん:04/10/25 15:12:40
デスマは営業のせいと言っても過言ではない

52 :仕様書無しさん:04/10/25 15:28:42
オッス!オラ部長

53 :仕様書無しさん:04/10/25 16:00:49
営業のあの能天気な言動がムカツク。
客先に適当に調子のいい事言ってるデタラメさ加減が信じられない。

一見歩み寄りの困難な案件を、交渉によって成立させる事が責務
のはずなのに、一方的に不利な条件で受注してきやがる。

向こうに最大限都合のいい条件をのむんだから、客ウケが良くなる
のは当然だっちゅうの。

54 :仕様書無しさん:04/10/25 16:28:02
オッス!オラ営業!!
いっちょ、出来ない事も「出来ます」って言ってみっか!!

55 :仕様書無しさん:04/10/25 18:36:47
オッス!オラ営業!!
このままではやられる、みんなの元気を分けてくれ!!

56 :仕様書無しさん:04/10/25 19:33:02
>55
お前に吸い取られるだけ吸い取られて
逆さに振っても血も出ねーよヽ(`Д´)ノウワァァン

57 :仕様書無しさん:04/10/25 20:43:33
>>45
それは別の話だ。

58 :仕様書無しさん:04/10/25 20:44:03
受注した仕事の利益は営業の成績に影響しないの?

59 :仕様書無しさん:04/10/25 21:22:38
>>47
即値のほうがシンプルだからじゃねーの?

60 :仕様書無しさん:04/10/25 21:32:13
>>59
お前みたいな奴がいるから>>37みたいな規約が存在し続けるんだ!

61 :仕様書無しさん:04/10/25 21:36:37
>>60
きみって、Cとかだとdefine切りまくって満足する人でしょ?

62 :仕様書無しさん:04/10/25 22:03:16
即値って何?

63 :仕様書無しさん:04/10/25 22:07:35
リテラル

64 :仕様書無しさん:04/10/25 22:19:05
>>62
このスレに来るには10年早いんじゃねーか?

65 :仕様書無しさん:04/10/25 22:24:00
目立もうダメポ(;´д⊂)
開発の仕方を奴等は知っているのか?と問いつめたい。
これでスケジュールが遅れてるから土曜日出てください。とか言われてもなぁ。
莫迦すぎる。

66 :仕様書無しさん:04/10/25 22:30:23
>>49
>「座っているだけでは受注できません。動いて頑張るのみです。」

スゲー頭悪そう。戦略が感じられない。
でもその頑張ってる様子が意外と効いたりするから侮れない。

67 :47:04/10/25 22:50:14
>>59
クラス内で閉じて1,2回参照されるだけならいいんだけどね。
共通ライブラリのクラスが返すステータスがint型のマジックナンバーだったから。
999==終了みたいな。
おっと、スレ違いだ。。999

68 :仕様書無しさん:04/10/25 22:55:33
>>67
なんだかよくわからんが、根本的に設計が糞っぽいぞ

69 :仕様書無しさん:04/10/25 22:57:15
>>65
気を付けろ!それが奴らの「実績ある開発技法」だ!

「この期間で開発できました」という報告は残っても「工程はデスマの連続でした」っていう記録は残らないからなぁ・・

70 :仕様書無しさん:04/10/25 22:59:06
判定サブルーチンが文字列を返してて
「空(正常)以外ならそれを表示してエラー処理」
とかになってたりすると泣ける。

その後の機能拡張でエラーによって後処理を分岐させる必要が出てきて
しょうがないからその文字列から判断で分岐を書くと
しばらくしてそれを忘れた頃に文言を変えろと指示が来て
元サブルーチン内の出力だけを変えると後処理に失敗してあぼーん、
というのが即値による泥沼のスタンダードパターン。

71 :47:04/10/25 23:14:17
>>68
>なんだかよくわからんが、根本的に設計が糞っぽいぞ

うん、そうだよ。俺は共通ライブラリを提供してもらう側だったんだけど、
そういう状態だったんで経緯を聞くと >47 だったって話。端折って自分
のことのように書いちゃったけどね。
で、こいつらに type safe 説明してたら開発期間終わりそうだったんで
定数は復活させといてね、と言うのが精一杯だった。。

72 :仕様書無しさん:04/10/25 23:45:43
>>58
営業成績は粗利じゃないの?
つまり受注した時点での予想される利益
もっとたち悪いのが売り上げ主義だけど、マイナスでも仕事とったらOK
どっちにしても、あとどうなろうがしったこっちゃないってこと


73 :仕様書無しさん:04/10/25 23:52:07
>>72
だったら予想利益じゃなくて、実績利益で評価したら問題は解決しそうだけどね。
まあ、問題を解決したいと思ってるのが開発側の人間だけじゃ無理かも知れないけど。

74 :仕様書無しさん:04/10/25 23:55:25
利益が出なかったのは開発が食いつぶしたせいになるよ。
決して営業が無理な注文を取ってきたからってことにはならない。

75 :仕様書無しさん:04/10/26 00:02:07
>>74
でもさ、開発が食いつぶそうが何だろうが、とってくる仕事が毎回赤字だったら
その営業は無能って事になりそうな気がするけど。甘い?
うちの会社は営業がないからよく分からないんだけど。

76 :仕様書無しさん:04/10/26 00:30:24
普通、営業はほぼ売上げだけで評価されるよ。

77 :仕様書無しさん:04/10/26 00:40:49
>>75
甘いと思う。毎回毎回開発が無駄に金を使ったと思われるだけだよ。
もちろんまともに予算管理できるような会社だとそうじゃないとは思うけど、
営業主体の会社だったらどう転んでも開発が悪いことになる。

78 :仕様書無しさん:04/10/26 00:47:24
営業と開発の不幸な乖離現象っすな。
本来手を携えあわなきゃいけないのに。

79 :仕様書無しさん:04/10/26 01:09:04
回り回って「あなたの会社にはもう頼まない」って事になって真っ先に逃げ出すのが営業・・・・
今の仕事は責任取って終わらせろ!となって屍を積み上げる開発・・・

なんだ、どう転んでも責任は営業に行かないような仕組みになってるんだな・・・(´Д⊂グスン

80 :仕様書無しさん:04/10/26 02:17:05
去年の今頃、日立ソフトの大阪は不夜城だったな。。。

81 :仕様書無しさん:04/10/26 11:28:33
「それは仕事と関係ない」

両親とも癌で入院しています。
迷惑が掛ると思い、会社には言ってませんでした。
一昨日、医者から母の余命が1ヶ月と宣告されました。
少しでも母のそばにいてあげたい気持ちから
会社に話したのですが
話の途中で上司が怪訝になり
「それは仕事と関係ない」
とバッサリ切り捨て話すら聞いてもらえませんでした。
疲れていたので言い返すことも出来ずそのまま仕事を続けました。
今日は無断欠勤しています。
もう会社には行かず母のところへ行きます。


82 :仕様書無しさん:04/10/26 11:57:07
家族より仕事を優先するやつは俺は嫌いだ

83 :仕様書無しさん:04/10/26 12:00:11
>81
あなたが正しい。

84 :仕様書無しさん:04/10/26 12:05:28
コピペにマジレスっすか・・・

85 :仕様書無しさん:04/10/26 12:21:46
上司が会社を休もうと言い訳してきたときに
「それは仕事とは関係ない」
これ最強。


86 :仕様書無しさん:04/10/26 12:40:56
>>81
あなたが正しい。
会社のために尽くしたって、あなたが急病や怪我でダウンしたら
切り捨てるのが会社。でも、ちゃんと上司に反論しといた方が良かったな。
ちなみに退職に関する法律(商法)では、3年以上勤務していると即日退職
できるらしい。

87 :仕様書無しさん:04/10/26 12:42:39
>>85
イイネーーー。でもそういう腐れ上司に限って自分優先なんだよな。
「部下が居なくなる=自分の評価が下がる」だもんな。


88 :仕様書無しさん:04/10/26 15:17:17
>>81
労働三法を持ち出して喧嘩するのが正しい

89 :仕様書無しさん:04/10/26 17:00:50
>>81
無断欠勤は良くない。
どんな形であれ休暇取得の「宣告」だけはしておいたほうがいい。
あんまり揉めそうだったら、人事宛に内容証明郵便+配達証明付で送付。
電話は録音設備が無い場合はお勧めしない。
(録音設備があっても裁判の時は文書起ししなきゃならないから面倒)

90 :仕様書無しさん:04/10/26 20:57:00
>>81
すげー上司だな。そこまで行くと天晴れだ。

91 :仕様書無しさん:04/10/26 20:58:58
そんな上司ごろごろいるぞ

92 :仕様書無しさん:04/10/26 22:21:13
>>91
天晴れな会社にお勤めですね。合掌。

93 :仕様書無しさん:04/10/26 23:39:11
目立・・・系列子会社の社員に愛想尽かされてどうすんのよ
「ここまでやり方悪い所は初めてだ」って・・・


94 :仕様書無しさん:04/10/27 00:21:08
>>81
うらやましい、同意レスがつくなんて…
2年ぐらい前に同じような経験して、一時的に介護の関係で定時出社できなくなった。
そしたらクビにされて、それをマ板で愚痴ったら叩かれまくったよ…
仕事に関係ない事情を持ち込む方が間違ってるって…

うちの場合は親父が癌でお袋は脳内出血だったけどね…
収入絶たれた上に介護疲れで、おまけにマ板で叩かれて、
一時はもう自分が死んじまおうかと思ったよ…


もう両親とも逝っちゃったけどね…
自分はおめおめとまだ生きてるけど…

95 :仕様書無しさん:04/10/27 01:28:40
>94
イ`。
2chで叩かれた位で、命を(自分のも他人のも)粗末にするな。

96 :なぎさっち ◆Nagi/FmYMM :04/10/27 10:16:54
>94
そりゃ叩いたヤシがアホ。

って、オイラは当時叩いてないよな...。

97 :仕様書無しさん:04/10/27 10:19:00
暇だから叩いたかも
まあ2ちゃんなんてそんなもの
真に受ける必要はない

98 :仕様書無しさん:04/10/27 11:17:32
とりあえず、うちの会社の営業は元開発者ばっかりでよかったなとしみじみ

99 :仕様書無しさん:04/10/27 11:25:57
うちの会社の営業は元COBOL開発者ばっかりで散々だorz

寝言みたいな仕様変更が出るたびに
「一日徹夜すりゃできるだろ?」
アフォだと

100 :仕様書無しさん:04/10/27 12:05:00
>>99
そういう連中は早く絶滅して欲しいね

229 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)