[2ch元スレ] ＰＣ等 > プログラマー Tweet



[231 res] 全部 1- 101- 201- 最新50

スポンサードリンク

---

1 : 仕様書無しさん : 03/05/05 20:38

上司とか営業の人に、「このプログラム、何日くらいかかる？」と聞かれて、
答えても、それより短すぎたり長くかかったりで、
開発時間の見積もりが下手です。

こういうののコツとか、
あるいは、自分で考えた日数の２割り増しで答えてるとか、
そういう経験則でもいいので、語ってください


スポンサードリンク

2 : 仕様書無しさん : 03/05/05 20:43

昨日の天気

3 : 仕様書無しさん : 03/05/05 20:49

長かったり短かったりした場合に、それが予測可能だったかを考える。
予測不可能で、長かったり短かったりした時間を全部合計して0 になっていれば、それでまぁ妥当な見積りだったってことにしちゃえば？

つか、とりあえず何が原因で予想と違ったかはちゃんと覚えておくべし。
そんくらいじゃない？

4 : 仕様書無しさん : 03/05/05 20:50

目一杯多く言えばいいだろ。どうせ見積もり聞くやつは内訳を理解できないのだから
うまく埋めとけばＯＫ。他にも仕事があるってことで、
「私がやるならこれとこれを考慮するとこれくらいかかります。」

5 : 仕様書無しさん : 03/05/05 20:58

｢最短見積もりの三倍で出せ｣と言っている人がいる。
それなりにいい数字になってる気がします。

6 : 仕様書無しさん : 03/05/05 20:59

ぼったくってなんぼのモンですよ。
所詮そんなもんです、ほとんどの業界は。

中国に開発拠点ができたのでウチの会社じゃ通用しませんが。

7 : 仕様書無しさん : 03/05/05 21:01

>>1

まず、調査を先に行って、機械的にコーディングするだけの状態にしてしまう。
そのタイミングで、見積もる。第1レベルは、機能単位で。第2レベルは、モジュール単位で。

8 : 仕様書無しさん : 03/05/05 21:03

>>7
あんたみたいな香具師がいるからＯＯが浸透しないんだね。香ばしいよ。

9 : 7 : 03/05/05 21:20

>>8

ＯＯって何？

10 : 仕様書無しさん : 03/05/05 21:43

ﾌﾟ

11 : 仕様書無しさん : 03/05/05 21:49

>>9
こんな感じのヤツ
ttp://www.wakhok.ac.jp/~tatsuo/sen97/1shuu/fig3.gif

12 : ななし : 03/05/05 21:55

「俺様が作れば３日もあればちょちょいのちょいだな」って思ったら「一ヶ月かかります」って言っときゃ
間違いない。

13 : 仕様書無しさん : 03/05/05 21:58

ファンクションポイントとか（ｗ

まぁ実際には係数がかかる。　人によって生産性が違いすぎるからね。
ちゃんとデータ取って、誤差を修正することで精度が上がります。

それをやらない奴は、いつになっても計画が計画になってない（ｗ
計画が立たない状態ですな。（やってみなけりゃわからない状態）

14 : 仕様書無しさん : 03/05/05 22:03

>5がものすごく良い事いった。

15 : 1 : 03/05/05 22:45

>>5
>最短見積もり
をどうやって出せばいいのでしょうか？

16 : 5 : 03/05/05 22:55

>>15
勘でいいと思うよ。いや真面目に。

17 : 仕様書無しさん : 03/05/05 23:01

勘でドンッ！さらに3倍ドンッ！！って感じですか・・・

18 : 1 : 03/05/05 23:39

>>5
以外とあってるかもしんない、自分の場合も

19 : 仕様書無しさん : 03/05/05 23:57

>>17
クイズダービーみたいだな

20 : 仕様書無しさん : 03/05/06 00:03

開発環境（言語+OS+ミドルウェア)が今まで通りならファンクションポイント
+経験則(過去の見積もりと誤差)でかなりイイ線見積もれるよ。
開発環境をコロコロ帰られたら上の体制が悪いので逆ギレすべし。
逆ギレできないならリスク混みで3倍見積もりでok.

21 : 仕様書無しさん : 03/05/06 00:03

茶柱が立った！

22 : 仕様書無しさん : 03/05/06 00:13

すでに結論が出てて藁多

23 : 仕様書無しさん : 03/05/06 00:13

>>13 >>20
過去の記録が大事だよねー。
個人レベルでは記録とってるから、自分が作る場合の見積りはできるけど
他人のは無理っぽい。

24 : 仕様書無しさん : 03/05/06 00:17

漏れ、新人の頃から客先にぶっぱなされてた身分だから
見積もりを個人で記録するってことの重要性が今わかりました。。。
暗黙は誰も教えてくれないでつ（涙）

25 : 20 : 03/05/06 00:22

>>24
経験ないならしょうがない。自分のレベルx1.5ぐらいで責任は一個上に
持たせるようにしときなさい。
経験ないのに見積もりさせるならそれはそれは上の責任だから。

26 : 仕様書無しさん : 03/05/06 01:20

>>25
漏れは派遣社員だけどよ、見積もりで即答しないといけない場面があって
ほんとに困った経験はある。契約上、どこまでが俺の仕事かさえも明らかではない。

27 : 仕様書無しさん : 03/05/06 01:21

>>26
>即答しないといけない場面
手口が密室販売そのものだな(w

28 : 仕様書無しさん : 03/05/06 01:38

初めて作った見積もりはことごとく親受けの営業にはねかえされたな…
40過ぎの元PG営業にタイマン交渉
上乗せ金額はことごとく見破られて立場ドンドン弱くなって…
折衝能力と説得しえるだけの技術が不足してたのを痛感させられた

んで結局引かれまくった見積もりで当然の如くデスマ突入…
今思い出しても悔しくて辛くて情けない思い出…

29 : 仕様書無しさん : 03/05/06 02:08

まぁあれだ…




　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…本を読めや

30 : 仕様書無しさん : 03/05/06 02:10

川合堂ライセンス（´_ゝ｀）

31 : 仕様書無しさん : 03/05/06 02:21

デスマーチに入ったのは、折衝能力じゃなく
開発能力が不足してたんだろ

そういう相手だと分かってくると、発注する側も
泣きたくなってくるよ

32 : 仕様書無しさん : 03/05/06 02:28

>デスマーチに入ったのは、折衝能力じゃなく
>開発能力が不足してたんだろ

これは微妙だな。
受注したときからダメなの判ってる仕事なんていくらでもある。
期間とかね。

33 : 仕様書無しさん : 03/05/06 03:00

XP緑本にあったよ「昨日できたことは今日もできる」

34 : 仕様書無しさん : 03/05/06 03:03

ＸＰ黒本にあったよ「昨日動いたシステムは今日も動く」

35 : 仕様書無しさん : 03/05/06 03:26

ＸＰ裏本にあったよ「昨日抜けたエロビは今日も抜ける」

36 : 仕様書無しさん : 03/05/06 06:18

それはSEXP

37 : 仕様書無しさん : 03/05/06 13:10

>>5

俺もそれ。ＸＰでは理想時間って呼ぶけど

>>15
パーフェクトな自分を想像する。
それでも分からないなら、たぶん自分には開発出来ない。

38 : 仕様書無しさん : 03/05/06 18:00

PSPは？

39 : 仕様書無しさん : 03/05/06 22:42

漏れの場合
小さい修正：1日
1～3画面程度作成：3日
1機能丸ごと：10日
開発期間と相手の顔色で適当に答えてまつ。

40 : 仕様書無しさん : 03/05/06 23:56

>>39
それって、言語は？

41 : 仕様書無しさん : 03/05/07 00:16

>>40
Ｊａｖａ

42 : 仕様書無しさん : 03/05/07 01:15

>>28-32
大事なのは技術力よりも度胸か。

開発能力が不足してるなら不足してるなりの正しい見積りを出せばよい。
背伸びして無理な仕事を受けるとあちこちに迷惑をかけることになる。
ある程度自信がないとできないことだし、何度か痛い目を見てから
悟るんだけどね…。

43 : 名無し募集中。。。 : 03/05/07 16:49

漏れはASP+VBScriptでeコマースサイトをいじくってる。
しょっちゅう仕様変更やら機能追加やらで見積りを作る機会があるのだが、
うちの場合は

・「何も障害が無くて100%仕事に集中できた場合の完成予想時間」

を過去の経験から割り出した上で、

・「途中で割り込みの作業が出た場合の増分」
・「仕様変更が出た場合の増分」
・「デバッグ時間と称した上乗せ分」

などをこれらも過去の経験から算出して合算。
それを担当営業に投げつける。
そして、担当営業がさらに勝手に数%程度金額と納期を上乗せしてクライアントへ出す。

もし、クライアントが「少し安くしてくれ」と言われた場合は営業が上乗せした分を差し引いて出す。
大抵はこれで通る。
クライアントとの信頼関係にもよるが、最初ちょっと高めに出して少し減額するってやり方は有効らしい。
新規案件には適用できないのがつらいが。

44 : 仕様書無しさん : 03/05/08 01:11

「『この案件にかかりっきりだとしたら』１週間です」
みたいに答えるようにしてます

あるいみ前もっていいわけしてるようなもんだけど

45 : 仕様書無しさん : 03/05/08 01:35

>>44
で、かかりっきりでやらせてもらえる時間を貰ったとしてだ。
遅れたら何と言う？

46 : 仕様書無しさん : 03/05/08 01:38

そんな事気にしてたら仕事なんか出来まへん。
ヤバいなら、そうならないように努力しろ。

47 : 仕様書無しさん : 03/05/08 01:40

>>1

「これをＡの期間でやれ」と言われるのを想像する
　　↓
泣きたくなる
　　↓
Ａの３倍が見積もり

48 : 44 : 03/05/08 02:15

>>45

んー、いままで、かかりっきりでやれる時間をもらえた場合は、
徹夜してでもなんとか奇跡的に終わらせてきたので・・・

49 : 44 : 03/05/08 02:23

つっても、かかりっきりなんてほんのたまに。

50 : 仕様書無しさん : 03/05/08 02:34

残業が許されない状況で開発やるのはしんどかったな

51 : 仕様書無しさん : 03/05/12 22:45

>>50
なんでそんな状況がありうるの？

52 : 仕様書無しさん : 03/05/13 00:20

残業が月10時間程度しか認められないところは多いぞ

53 : 仕様書無しさん : 03/05/13 00:47

サービス残業すれば

54 : 仕様書無しさん : 03/05/14 22:33

ところでおまいら、工程管理にどんなツール使ってる?
オレはPrimavera Project Plannner 3.1

55 : 仕様書無しさん : 03/05/14 23:34

>>54
チラシの裏

56 : 仕様書無しさん : 03/05/15 00:01

>>54
ポストイット

57 : 仕様書無しさん : 03/05/15 00:04

>>54
脳内管理

58 : 仕様書無しさん : 03/05/15 00:55

>>54
工程管理ねぇ。
うちは仕様管理が大変だよ…。

59 : 仕様書無しさん : 03/05/15 01:22

はじめから管理されていない。
強いていえば納期だけは決まっている。
気まぐれでリリース時に承認をうける。

こんなバカやってりゃトラブるに決まってる。

60 : 仕様書無しさん : 03/05/15 01:23

オープンソースな某ソフトウェアの，更なる高速化の作業。
既に，レイテンシを考慮して命令を並べていたり
飽和演算に奇妙なトリックを使っていたりと，
アセンブリレベルで㌧でもない最適化が施されていて
もはやﾜﾀｽのような厨房が太刀打ちできるシロモノじゃなかた。

これでどう作業期間を見積もれと (+д+l||l) 泣いていいですか・・

61 : 仕様書無しさん : 03/05/15 01:53

>>60
某ソフトウェアって何？
オープンソースソフトを某とか言う必要ないだろうが。

62 : 仕様書無しさん : 03/05/15 02:25

身元が割れる可能性はあるわな

63 : 仕様書無しさん : 03/05/15 07:52

>>59
同じ同じ。
どこもそんなもんか。

64 : 仕様書無しさん : 03/05/15 08:15

あのさ、
部屋に温度計あるかい？　温度計見る前に　温度自分で予測してるかい？
部屋に時計あるかい？　毎朝目が覚めたら　時計見る前に何時だって予測してから見てるかい？

小さな単位でも、これは何分かかるって自分で予測してから仕事してるかい？

65 : 仕様書無しさん : 03/05/15 08:57

>60
CPUを増設する時間+メモリを増設する時間+HDDを増設する時間

66 : 仕様書無しさん : 03/05/15 09:29

>>54
ちらっと見たけど､ちと高価じゃないかい？
まあきちんとした機能がありそうだから､もうちょっと
調査してみるわ｡

ちなみに、うちは現在MSProject2k｡
中華､現在うちはいくら管理ソフトがあっても
管理体制も何もあったもんじゃないから（泣

67 : 仕様書無しさん : 03/05/15 10:11

ワシの長年の経験から、>>5が正解だと言える。

研究っぽい開発やってると、1年単位でものごと考えるから、1年の計画が
3年になったりする。社長の気が変わればプロジェクトはおしまいだ。

68 : 仕様書無しさん : 03/05/15 11:17

※末承諾広告
スタッフは皆様の生活を応援します
１万円～１００万円まで１５分で審査
（１００万円以上のご融資も可能）
完全自社貸付なので安心してご利用いただけます

お申し込みは
0120-39-4400
携帯からもＯＫ！
インターネットは
http://www.staff-japan.com


迷ったらまずお電話ください
必ずお力になります。

69 : OracleボンカレーGold : 03/05/15 13:51

>>68
>迷ったらまずお電話ください
>必ずお力になります。

ほっほー。じゃあデスマーチ中の漏れの仕事を楽にしてくれんだろうな｡
ぁあ？末承諾広告野郎よ｡

70 : 仕様書無しさん : 03/05/15 21:03

>>64
スレの空気が冷えたみたいだけど
温度計どうだい？

71 : 仕様書無しさん : 03/05/16 00:43

なんで最初にゴールを決めてから開発しないの？
ゴールに含める用件を増やしたり取り下げたりで増減はあっても、
そのほうがクライアント、デベロッパともにハッピーじゃないの？

72 : 仕様書無しさん : 03/05/16 01:53

ゴールゥ？
それが設定できるんなら、営業に感謝しなさい。

73 : 仕様書無しさん : 03/05/16 02:11

>>72
なんで営業なの？営業は「ニーズ」を捉えてくるのが大事。
ゴール設定は、営業というよりも要件定義者の責任だぞ。

74 : 仕様書無しさん : 03/05/16 02:27

>>73
営業は仕事取って来るのが大事に決まってるだろヴォケか。
あんたは炎天下で、車の通る数分スイッチ押してりゃいい。

75 : 仕様書無しさん : 03/05/16 02:34

>>74
の２行目の意味がわからなくて寝れません

76 : 仕様書無しさん : 03/05/16 02:36

>>74
なんか人を不幸にする仕事しか取れなさそうに聞こえる。
煽りでなく、マジで。

77 : 仕様書無しさん : 03/05/16 07:00

>>1
そんなのコツは簡単だ。　自分が1ヶ月と言ったら1ヶ月でやるんだ。

78 : 仕様書無しさん : 03/05/16 17:34

>>73
要件定義者なんつったって、誰も何を作ったら良いのか知らないのが
開発というものだ。　何を作ったら良いか明確なら、仕事は半分終わったも
同じ。

79 : 仕様書無しさん : 03/05/16 18:10

>>78
最適な解を締め切り間際まで考えてるってのが正確なのでは？

80 : 72 : 03/05/16 18:50

>>73
だから>>78の言う通りなんだよ。「契約」と「追加費用」で、この要件定義者とやらの
DQNな迷いを断ち切る素晴らしい力量の営業でもいなきゃ、
>>79の言う通り、納品直前に基本的な仕様の変更を言い出す馬鹿な客に振り回される訳さ。

大体、この業界の契約形態がオカシイんだと思うよ、俺は。

81 : 仕様書無しさん : 03/05/16 18:56

>>66
１セット50マンだからな（ｗ

きちんとした工程管理をしておくと楽だぞ。
Hour単位で余裕時間とかだせるし、人員配置が楽になる。
特にデスマーチ直前の時に威力を発揮するね。

デスマーチに入ってしまえば、工程管理もクソもないんだが（Ｗ

82 : 仕様書無しさん : 03/05/16 19:02

>>80
>基本的な仕様の変更
これを断ち切っちゃうと客は使えないシステムを掴まされることになるぞ。
契約を盾に押し切ることも出来るだろうが、100%次の受注はない。それどころか
その客の業界中に言いふらされる可能性まである。そこで、粘り強く交渉にあたる
人間が必要になるって訳だ。

83 : 仕様書無しさん : 03/05/16 19:54

それならコンポーネント指向のRADを使え。
納品の直前までコンポーネント作って、納品次にカスタマイズ。

84 : 72 : 03/05/16 23:50

>>82
同意。
だからこそ、そこで納期の延長を交渉できる。
だから、工程管理は自分一人で解決する問題ではなくて、
営業含めた周囲の人間巻き込んで初めてできるんだよな。

85 : 仕様書無しさん : 03/05/17 00:04

RUPは、
要件を見つけるごとに一覧に追加し、
一覧のうちから開発対象項目を選び出してスコープにする。
要件一覧＝開発構想、スコープ＝プロジェクト範囲という位置付けだ。

一覧中からスコープへの組み入れ、もしくはその逆という変更は、
正式な手続きのもののみ認める。

すごく合理的だし、
お客も要件を変更したという認識をもってくれる。

RUPを真似て試みているんだが。
失敗するよと思ってる方、理由を教えてくれませんか？
何としても成功させたいんで。

86 : 仕様書無しさん : 03/05/17 00:07

>>85
手続きだけで全工程の1割以上を占めそうだ。

87 : 仕様書無しさん : 03/05/17 00:09

この業界は子供のサッカーと同じ
全員がボールに向かって走っていく…

目先の作業だけしか見えない人が多くて作業の全体量を割り出して
計画を立てようって考えがないんだよ

88 : 仕様書無しさん : 03/05/17 00:14

>>85
>要件を見つけるごとに一覧に追加し
ド素人の客相手だと、その作業は本番稼動後にしか行えない罠。

89 : 仕様書無しさん : 03/05/17 00:15

>>87
部下をボールに向かわせない上司は考え物。
あんたが言ってるボールとは意味合いが違うかもしれないが。

90 : 72 : 03/05/17 00:15

>>87
うまいね！
で、監督もコーチも審判も素人がやってるからルール自体が崩壊する訳ね。

91 : 仕様書無しさん : 03/05/17 00:16

>>88
＞ド素人の客相手だと、その作業は本番稼動後にしか行えない罠。
意味が不明

92 : 仕様書無しさん : 03/05/17 00:16

>>87
>全体量を割り出して
これがどんだけ難しいかわかってるのかと小半年間(ry

93 : 仕様書無しさん : 03/05/17 00:18

>>91
ド素人ﾊｹｰﾝ

94 : 72 : 03/05/17 00:25

>>86
ど素人の客や業界ずれした客の要件は、ドラえもんの四次元ポケットさ。
後からどんどん何でも出てくる。

全体作業量なんて工程管理のような線形的な論理スキームで捕捉できるわきゃない。
だから営業の交渉技術が大事なんだよ。

95 : 仕様書無しさん : 03/05/17 00:27

>>94 いいこと言うねぇ。

96 : 仕様書無しさん : 03/05/17 00:34

>>95
ｼﾞｻｸｼﾞｴﾝﾊｶｺﾜﾙｲ

97 : 72 : 03/05/17 00:41

>>96
トイレに行ってた。
席を外してる間に誉められて嬉しいが、
うんこしてる間に濡れ衣着せられるとブルーだぜ。
つか、論拠ないレス返すあんたは素人確定かな。

98 : 仕様書無しさん : 03/05/17 00:47

>>94
要件が出てくること自体は悪いわけじゃないだろ。
そういう発見的な行為こそ開発プロジェクト。内容はどんどん発展するもの。
でもデベロッパがそれを受け入れる＝工数・期間が増えるということ。
この分かりきったことを客に認めさせるには、現状を目に見える形にする努力が必要なわけだ。
「駄目です」って言うんじゃなくて、出てきた要件は受け止める。記録する。
ただしプロジェクトスコープには含めない。なぜなら工数が変わるから。

必要なのは「事前にルールに合意しておく」という作業だ。
まっさらの状態から上記ルールの取り決めをしておくのはたやすい。
なぜなら客はまだ要件を出していないから。

何かを決めだすにつれて客もいろいろと思いつくから、合意はどんどん難しくなる。
ああ不幸の始まりだ。

99 : 仕様書無しさん : 03/05/17 15:06

え？
そんなの話し合ったって結局やるしかないじゃん。
そんな、約束したよね？作戦なんて効くのか？
次の仕事くんのか？

100 : 仕様書無しさん : 03/05/17 15:10

>>99
心理戦。　初戦でこちらにメイワクを掛けて申し訳ないという気持ちを
先方に発生させて、言いにくい雰囲気を作る。

ただし、でかいシステムだと向こうも担当者をコロコロ変えてくるから
大変である（ｗ

101 : bloom : 03/05/17 15:11

http://homepage.mac.com/ayaya16/

102 : 仕様書無しさん : 03/05/17 17:21

>>100
そもそもソフトウェアなんて作らせてなんぼだと思ってる人に
心理戦なんて効くのか？
思ったとしてもむこうはすみません、こっちはしょうがねーなでいい仕事できんのか？
基本的にそーゆー雰囲気にしちゃうってことでしょ、それ。

103 : 仕様書無しさん : 03/05/17 17:52

>>85

RUP を具現化したものが XP なんて言われ方してるよね。
柔軟な態度でいれば、うまくいんでないか。

104 : 仕様書無しさん : 03/05/17 19:57

>>85

成功するか失敗するかは、手法によらない。　プロジェクトマネージャの力量に夜。
銀の弾丸はないのだ。

その手法で、合理的とか正式とか言ってみても所詮人がやることだ。
思い違いや勘違い、政治的な圧力等々予定通りにいかないのが人生なのだ（ｗ

105 : 87 : 03/05/17 21:13

>>89
上司も一緒にボールを追いかけちゃうのが問題かと

>>92
難しいし、完全に把握できるとは思っていないけど、
全体量を割り出そうとする姿勢が重要だと思ってる。
状況は刻一刻と変わるから、新しい作業が出てきたら
以前に割り出した全体量に追加していく　というやり方をしてる

106 : 仕様書無しさん : 03/05/18 00:13

最終的に成功するプロジェクトというのは、
＞状況は刻一刻と変わるから
を、収束に向けてコントロールできたプロジェクトの事をいうのだ。
デスマはこれが発散状態にある。　変化する速度の方が、解決する速度を
上回っている。　時間とともに変化する力が衰えるか、解決する力が衰えて
やがて収束する。　それが冷たい死だとしても。

107 : 仕様書無しさん : 03/05/18 00:16

全ては貧乏が悪いのさ。

108 : 外注業者 ◆ZrKCVqY7tQ : 03/05/18 00:57

全ては利己主義的な出産マシーンが悪いのさ。

109 : 仕様書無しさん : 03/05/18 01:25

>>108
お前がいるとネタスレと勘違いされて非常に迷惑だ。ｶｴﾚ！

110 : 外注業者 ◆ZrKCVqY7tQ : 03/05/18 12:48

>>109

うっさい。過激に反応するな。
2ch自体がネタスレの集まりだろうが！！

111 : 仕様書無しさん : 03/05/19 13:09

ネタスレ化決定！！！！！

112 : なぎさっち ◆Nagi/FmYMM : 03/05/19 13:45

>110
煽りに反応しないの。

113 : 仕様書無しさん : 03/05/19 19:17

なぎさっち ◆Nagi/FmYMM
ってリアルであったらうざそーぅ

114 : 仕様書無しさん : 03/05/19 19:53

虫が部屋の壁のいたるところに張り付いてやがる。
大きさは網戸の網目と同じくらいの大きさだから、網戸でも平気で入ってこれるのかな。
そろそろ虫除けがいるな。

115 : 外注業者 ◆ZrKCVqY7tQ : 03/05/19 20:37

>>112

声援、ありがとう。私の同志だね。

>>114

そんなにあちこちに書き込んでさあ。。。流行らせたいの？

116 : なぎさっち ◆Nagi/FmYMM : 03/05/19 20:50

>113
＞うざそーぅ

　そう？

117 : 仕様書無しさん : 03/05/20 20:06

↑
先生！煽りに反応しますた！！！！

118 : 山崎渉 : 03/05/22 01:56

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

119 : 仕様書無しさん : 03/05/22 04:41

>>5
おれも、かなりぴったりだよー。
ありがとう

120 : 外注業者 ◆ZrKCVqY7tQ : 03/05/22 07:18

貴重なスレッドを残そう。

121 : なぎさっち ◆Nagi/FmYMM : 03/05/22 13:40

>117
駄洒落禁止、とか言って欲すぃかった

122 : 仕様書無しさん : 03/05/22 16:49

>>121
おまいはまたネギに戻れ。

123 : ねぎ ◆Nagi/FmYMM : 03/05/22 17:12

>122
了解しました、ご主人様

124 : 仕様書無しさん : 03/05/22 17:27

>>123
ねぎじゃなくてネギだよ。このウスノロ！

125 : ネギ ◆Nagi/FmYMM : 03/05/22 17:40

>124
こう？

126 : 仕様書無しさん : 03/05/22 20:24

>>124
放置プレイでつか？

127 : 仕様書無しさん : 03/05/23 14:08

俺も>>5で正解だと思う。
んで、最短見積の出し方は>>47かなぁ。


※業務連絡
既にこのスレの問題は解決済みなので、以後ネタスレとして再利用してください。

128 : 仕様書無しさん : 03/05/23 14:20

えーと・・・・・・ふとんがふっとんだ

129 : なぎさっち ◆Nagi/FmYMM : 03/05/23 14:58

シャベル持ってしゃべる

130 : 仕様書無しさん : 03/05/23 19:04

>>129
また戻ってる・・・

131 : なぎさっち ◆Nagi/FmYMM : 03/05/23 19:16

北から来た

132 : 仕様書無しさん : 03/05/23 20:41

消防署の方から来ました

133 : 仕様書無しさん : 03/05/23 20:49

開発時間の見積もりは
最短時間の三つ盛り

134 : 仕様書無しさん : 03/05/23 21:12

>>133がｲｲこと言った!!!!!

135 : 外注業者 ◆ZrKCVqY7tQ : 03/05/23 21:56

うっさいは、うっさい。

136 : 仕様書無しさん : 03/05/23 22:38

>>135
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=%E3%81%86%E3%81%A3%E3%81%95%E3%81%84

137 : 外注業者 ◆ZrKCVqY7tQ : 03/05/23 23:04

>>136

私じゃないよ。

138 : 山崎渉 : 03/05/28 16:56

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

139 : 外注業者 ◆PVCAbsPHPE : 03/06/05 21:42

2年目坊主の学習時間を、私たちの工数から捻出している。
汚いよ。

140 : 仕様書無しさん : 03/06/17 01:18

>>127
結論出ちゃってるのかー。
なんか新ネタないかどうかあげてみよっと。

141 : 仕様書無しさん : 03/06/17 07:09

あんまり関係ないけど、こっちは見積もり「の」3倍らしい

ttp://www.ese.yamanashi.ac.jp/~itoyo/papers/newspaper/sinpou030523.htm

142 : 外注業者 ◆PVCAbsPHPE : 03/06/19 07:58

現在、2年目坊主を管理。SEが作成した中計画を基にして、案件ごとに作業を段階分けし、小計画を立案している。
中計画を守るために残業しても構わないと言われているので、小計画を決められた日数の中で考える。

143 : 仕様書無しさん : 03/06/24 15:19

MS-Projectみたいなプロジェクト管理ツール使ってるひといます？

144 : 仕様書無しさん : 03/06/24 15:49

弊社の見積もり　　　１
Ｍ社の現場見積もり　×２
Ｍ社の営業見積もり　×２

で、最終的に４倍の見積もり資料が客先に出ます。
で、客先からゴラァ電話が直接ウチにかかってきます。
ウチのせいじゃないのに・・・。

145 : 仕様書無しさん : 03/06/24 16:46

>>143
普通使ってるだろ

146 : 仕様書無しさん : 03/06/24 16:56

そうなのか・・・。うちみたいにプログラマ１人だと使ってないもんで

147 : 仕様書無しさん : 03/06/24 18:48

>146
1人なら使うメリット無し。
っていうか、小規模PJならヘタなツール使うよりホワイトボード等の
アナログなもので進捗管理するほうが建設的だと思う。
ツールに振り回されてる人をみると、何の為のツールなんだかって思う。

148 : 仕様書無しさん : 03/06/24 19:56

販促用ポスターの裏側を活用してます。

149 : 仕様書無しさん : 03/06/24 22:35

進捗管理は全部エクセルです…

150 : 仕様書無しさん : 03/06/24 22:59

>>149
結構多いよねそれ。時間対効果で考えると

151 : 仕様書無しさん : 03/06/24 23:12

自分は大学行きながらアルバイトでプログラムを組んでいるんだけど、
納期一ヶ月で仕様書を渡されたんだけど、
授業サボって二日間デスマして完成させてしまった。
どうするべき？本職の方、教えてください。

152 : 仕様書無しさん : 03/06/24 23:18

>>151
君、デスマの使い方が間違っている気がする。

153 : 外注業者 ◆PVCAbsPHPE : 03/06/24 23:19

>>143

周りの進捗・工数管理担当者は使っているよ。
私には10年早いかな？
大計画・中計画にはMS-Project良いと思う。
私程度の特攻隊長が小計画を作る上では、紙に手書きで十分だと思う。

>>144

*1.1とか*1.2ならわかるけど。。。
*2はひどいね。

>>146

見せる相手がいるからこそ、必要だもんね。あるいは、管理する対象がたくさんいるときとか。

>>151

早すぎるのは、逆にマズイ。
考えが足りないと思われるよ。
事前に期待されている工数の*0.8ぐらいで終了させたら？なんちゃって。。。

154 : 仕様書無しさん : 03/06/24 23:20

>151
ちゃんと完成しているかどうか残りの全期間かけて確認しろ

155 : 仕様書無しさん : 03/06/24 23:37

二日間のデスマって、君、デスマの定義が違うよ。
ずーっと家に帰れないのがデスマですが。
どれくらが「ずーっと」かというと、二日間ではない。アルルカンでもない。

156 : 仕様書無しさん : 03/06/25 00:02

てゆーかなあ。
この中で1日7.5hで計算してるやつはいるのか？
いないだろ。

157 : 仕様書無しさん : 03/06/25 00:04

>>151
どうするべきって、納期と工数の区別がつかないわ、デスマの意味も
間違ってますわじゃ小学校からやり直すしかないだろうが。

てか、やり直すべき（ｗ

158 : 仕様書無しさん : 03/06/25 00:06

デスマって「今週は２日しか家に帰ってないな」とかそういうことだろ？
洩れはそんなのが序の口だった。だから今はPGはやってないよ。
でも、他人のプログラムを診ることはある。。。仕様書無しで・・・。

159 : 仕様書無しさん : 03/06/25 00:55

>>151
ちゃんとテストしたの？

160 : 仕様書無しさん : 03/06/25 01:12

>>151
お願いだから、そのソースを引き継ぐ人間(社員)の事を考えて作ってあげて。

161 : 仕様書無しさん : 03/06/25 01:21

>>160
バイトにそこまで要求するなよ(w
#ガテン系バイトしかしたことなかったなあ。。。虚弱体質なのに。

162 : 山崎 渉 : 03/07/15 11:34

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

163 : 山崎 渉 : 03/08/02 03:02

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

164 : ぼるじょあ ◆yBEncckFOU : 03/08/02 06:07

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

165 : 仕様書無しさん : 03/08/02 18:40

ファンクション法とかありますけど、やっぱりKKD法ですね。
K・・・勘
K・・・経験
D・・・度胸
やっぱり世間で一番用いられているのではないでしょうか？
情シス板にも似たスレッドが昔からありましたけど。

166 : 仕様書無しさん : 03/08/02 19:05

俺、上司にそういう質問されて適当にＸＸくらいといったら
「根拠は？なんでそんなに簡単に答える？」
といわれたので、ちょっと考えた風にして、ＸＸくらいかなと難しい顔でいう
ことにしている。

ようは、馬鹿には　はったり　で十分。

167 : 仕様書無しさん : 03/08/02 22:24

正確な見積もりが出せるのは、過去にやった仕事の
焼き増しのような仕事の時だけだよ。
リピートの仕事ね。

新規の仕事なんか、正確な見積もりなんて出せないよ。
気分だけ。

それに、とある人間が３日でできる仕事でも、
別の人間がやると、１ヶ月かかっても出来なくて、
思いっきりバグ有で中途半端なものが、とりあえず納品されてる
ということだってある。
で、一端納品しちゃったものだから、そのプログラムを捨てて、
３日で新たに作って納品するわけにも行かずに、
仕方なくそのバグ入りプログラムを動くようにしたりするから、
さらに１ヶ月掛かったりする。

そんなもんよ。ねー皆さん。心当たりあるでしょ？

168 : 仕様書無しさん : 03/08/04 03:23

>>144
直接発注すれば１／２になるよと売り込め。
何度もやってれば向こうも少しは考えるだろうよ。

169 : 山崎 渉 : 03/08/15 23:33

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

170 : 仕様書無しさん : 03/08/15 23:35

>>167
心当たりがどうとかじゃなくてまんまやんけ。

171 : 仕様書無しさん : 03/08/16 01:23

ついさっき知った方法なんですが、PERT手法使っている人いますか？

楽観的見積もり値（a)，最確見積もり値(m)，悲観的見積もり値(b)を設定し

期待値＝ (a+4m+b)/6 で計算。

詳しくは、
http://www.infoscape.jp/tms/pm/method/PERT.htm
に載ってる（結構わかりやすい）

172 : 仕様書無しさん : 03/09/04 10:35

age

173 : 仕様書無しさん : 03/09/04 10:43

>>171
悲観的見積もり値＝∞
なので
期待値＝∞

174 : 仕様書無しさん : 03/10/11 01:22

age

175 : 仕様書無しさん : 03/10/14 13:01

今度 VB と「くりすたる・れぽぉと」とかいうやしを使って
多数の帳票 (種類や中身は不明) とやらを印刷する仕事が来る・・らしい。
見積もり出せってうるさいから，とりあえず 2 週間って答えておいたよ。
もれ VB 初めてだから，わくわくするよ。
basic だから行番号とか必要なんだよな。list コマンドで整形するのな。

・・・あ，「くりすたる・れぽぉと」って何？ おいしい？

176 : 仕様書無しさん : 03/10/14 13:32

餌が大きくすりゃよく釣れるというわけでもないのだ。

177 : 仕様書無しさん : 03/10/14 16:23

>>176

175が晒されたいマニアかも知れないぞ(w

178 : 仕様書無しさん : 03/10/18 01:19

while(1){
　　　&deth_march;
}

179 : 仕様書無しさん : 03/10/18 01:59

deth

180 : 仕様書無しさん : 03/11/12 05:51

age

181 : perlだけどさ。。。 : 03/11/12 05:56

while(1){
　　　while(1){
　　　　　　while(1){
　　　　　　　　　&deth_march;
　　　　　　　　　$rand = int(rand(100));
　　　　　　　　　if ($rand == 1) last;
　　　　　　}
　　　　　　&deth_march;
　　　　　　$rand = int(rand(100));
　　　　　　if ($rand == 1) last;
　　　}
　　　&deth_march;
　　　$rand = int(rand(100));
　　　if ($rand == 1) last;
}

182 : 仕様書無しさん : 03/11/12 10:11

>>173
経験の浅い香具師はみんなそうだ。ベテランだとて知らない環境（言語、ツール等）だと、そうだ。
何回か書かれているが、最確見積もり値＊３で見積もれ。
それが通るなら。

183 : 仕様書無しさん : 03/11/12 10:35

理想時間見積もり＊３だな、やっぱ。

184 : 仕様書無しさん : 03/11/12 11:18

このご時世だと、それがなかなか許されないんだよねぇ。

赤覚悟で見積もって仕事とるくらいなら、仕事ないほうがマシだと
俺は思うんだが。。。

185 : : 03/11/12 11:52

OOでソフト作るときは、某Dr. Fairyによると統計的に2倍掛かるってさ。
だから LOCにしろ FPにしろ、経験と勘にしろ、出した工数の2倍にしとけと。
3倍は多いと思うよ。

186 : 梨 : 03/11/12 14:09

>>185
理想見積時間1+開発側の悲観1+顧客の非協力的態度1=3

で、どうでしょう。

187 : 仕様書無しさん : 03/12/15 10:24

すみません。お知恵下さい。

自社開発でソフトを作っているのですが、弱小会社ゆえに無理な開発期間を
強いられています。

開発スタートする前にある程度の打ち合わせは行なったのですが、
今までの経験上、必要な工数は12人/月位で、WEBで検索しても大体
そのような期間が必要な規模でした。
しかし、前述の通り12人/月は許されません。（ちなみに開発人員は私１人です）

求められているのは「とにかく早く完成を」ですので、仕方がないので
詳細仕様等全く詰めずにプログラムを組んでいる状態です。
詳細仕様を詰めたとしてもケツは既に決められていますし、真面目に書類
を作成していると全く作っていないと思われてしまうのです。
（そんな悠長な事をするからには確実に間に合うんだろうな？と言われる始末）

何だかんだで半年近く続けてきたのですが、これまでも頻繁に「いつ完成
するのか？」という問いかけをされてきまして、かなり明確な完成日を
回答しないと納得してくれない日々が続いてきました。

自分としては詳細仕様どころか要求仕様すら曖昧な状態で、いつ追加修正等が
発生するか分かりませんし、そもそも規模が大きいですのであと何が必要なのか
明確に掴めていません。

そのため、適当に「あと○週間くらい」としか答えられず、またその期限も
どちらかと言うと急かされて自分の思っている期間より短い日数でないと
納得してもらえません。

188 : 仕様書無しさん : 03/12/15 10:24

さてここから本題なのですが、上記のようなやり取りを何度か繰り返している
と当然のように「またか（延びるのか）そんなんじゃダメだろ。」と
強い口調で完成を急かされているのですが、もはやプログラマとしての
技量や尊厳を蔑視された扱いをされるような口調にもなってきました。

どうにか状況を理解してもらいたいのですが、なにか良い方法はないでしょうか？

189 : 187 : 03/12/15 10:27

ちなみに、私の開発時間の見積もり方は「思った期間の２～３倍が妥当」
という考えを元に算出しており、以前はこの通りの期間でアップしてました。
もちろん、見積もり前にある程度の詳細仕様は書き上げます。

190 : 仕様書無しさん : 03/12/15 11:26

>>187
「無理な開発期間」を承知の上で、開発に着手したことがまず、誤りであった。
「とにかく早く完成を」という「時間が最重要」であるならばコストの投下と機能面での譲歩
のどちらかあるいは両方を調整しなければならないはずだったのだ。
本当の問題は「あなたのプログラマの尊厳」もさる事ながら、「いつ完成するかの見通しが立っていない」
ということだろう。（なにが完成するのかという問題もあるが）
結局、進捗管理責任担当は誰なのかということで、その人間が冒頭に記述した誤りを犯したということだ
これからどうするかは、これかもう「上司に相談する」しかない。その上司が駄目ならばさらにその上司に相談するしかない。
社長からして駄目なほど「弱小会社」ならば、会社をやめろ。
そんな会社にいても将来は暗いと思うが。あなたには責任はないぞ。

191 : 仕様書無しさん : 03/12/15 12:00

>187が相手にしているのはエンドユーザ?元請?それとも社内の上司?
その辺によっても色々と変わってくると思うが・・・

まず大前提として、
「とにかく早く完成を」と「仕様が決まっていない」
というものがそもそも大きく矛盾している事を認識しないと話が進まない。
仕様が決まってないという事はつまり何をすれば完成なのかの基準が無いんだから。

その上で、完成するかという問いかけに関しては
「今確定している仕様を満たす物が完成するのはいつです」
という風にしないとな。
んで仕変、追加修正発生時は再度スケジュールを組みなおす必要があり、作業期間は伸びる。
至極当然の話。

なんか文章だけ読んでると、>187は言われるがままに作業だけしているように見える。
コードを書くだけが開発者の仕事じゃないよ。

192 : 仕様書無しさん : 03/12/15 12:15

>>187
バッカじゃねぇのｗ

193 : 仕様書無しさん : 03/12/15 12:33

>>192
でも辞めるときって>>187みたいな理由で辞めるときが多いよね。

194 : 仕様書無しさん : 03/12/15 12:39

>>187のケースは、不具合改修作業に仕様追加を盛り込まれて、次の
リプレースまで無限に開発が続く。

担当者が逃げる典型例。

195 : 仕様書無しさん : 03/12/15 12:46

一旦この辺でプロジェクトを見直して妥当なラインでスケジュールを切り直すしかないな。
今上がってきている仕様からスケジュールを出して、
「出来る部分についてはやります。上がってきていない部分については作業期間が必要です」
と、正直にいえ。
ズルズル続けてもかえって相手に迷惑がかかるだけだし、自分も辛い。

相手の問題点を責めるための物証
＃仕様が遅れている事実や、こちらから催促を行った電話やメールの記録、最初の打ち合わせ段階での資料など
はきっちり集めとけよ。
でないと「お前がやるって言っただろ」と一方的に責任をなすりつけられる可能性が高いぞ。

196 : 194 : 03/12/15 12:50

>>187は早急に行動を起こしたほうが良い。大変なことになるよ。
そうやって追い込まれてやめるしかなくなったりノイローゼ気味になったのを
俺自身も含めて何人か知ってる。健闘を祈る。

197 : 192 : 03/12/15 13:02

>>193
>>187みたいな状況に陥ったことをけなすつもりは毛頭ないよ。そのような
状況をなんとか打開しようとしてることがバッカじゃねぇのってこと。
そんな会社はとっとと辞めてしまえ。

198 : 193 : 03/12/15 13:06

>>197
激しく同意。

199 : 仕様書無しさん : 03/12/15 13:38

俺も同意。
そういう状況に陥ってしまった>187が2chに聞くしかないような
状況になるまで放置してる時点でその会社NGだぬ。

200 : 187 : 03/12/15 15:39

皆さんレスありがとうございます。

>>190
弱小と言うか零細なので私の上司は社長になります。
つまり無茶を言うのは社長なので、状況の改善はうまく説得するか辞めるか
さっさと完成させてしまうかの３択となります。

何だかんだ言われつつ一つだけ救われているのは「完全な完成じゃなくても
いいから最低限のものを上げてくれ」ということです。
しかし、何を以ってして最低限を定義付けているのかは不明です。
（恐らく言ってる本人も分かって無くて、過去の経験からするとトラブルが
起こった時点で「最低限に達していない」と判断される可能性は高いです。）

>>191
相手は上司ですが、営業ですので顧客に対しては売り込みを行なっています。

＞「とにかく早く完成を」と「仕様が決まっていない」
＞というものがそもそも大きく矛盾している事を認識しないと話が進まない。
仰る通り、矛盾がありますので話が平行線です。
この点に関しては繰り返し理解を求めてきたのですが「じゃあ仕様書を書かせて
やるから、いつ完成するのか明確に。絶対厳守で。」という答えが返ってきます。
しかしここで問題なのは、最初にも書きましたが「実は既にケツは決められている」
ということです。
どうやら「仕様書を書けば無茶な納期がまかり通る」ような論法に展開されて
しまうのです。このままではおちおち仕様書も書いてられません。

201 : 187 : 03/12/15 15:40

>>192>>197
>>193
>>194
以前勤めていた会社も似たような状況だったのに加え、決定権も権力も無いくせに
責任だけは押し付けられるポジション（管理職でもないのです）だったため、辞めて
今の会社に移ったという経緯があります。
今の会社では納期の件以外は好きにさせてくれるため、うまく立ち回ればやりがいは
あるのですよね。
自分はちょっと馬鹿正直な所があるため、交渉ごとがヘタなのかとは思っています。

>>195
＞「出来る部分についてはやります。上がってきていない部分については作業期間が必要です」
＞と、正直にいえ。
出来る限り、正直に状況説明は行なっているのですが、相手はいわゆる「ど素人」の
ためか、例えばあるワークシートを持つ画面を作る場合、EXCELの画面でもくっつければ
完成すると思っているようです。
本当にそんな事で完成するのかどうかは私が判断すべき事なので、その辺は信用して
欲しい所なんですが、その場では何となく納得したような返事は貰いつつ最後の言葉は
「早くしてくれ」なんです。
信用していないからそういう言葉が付いて出てくるのか、それとは関係なくそう言うしか
ないのか分かりませんが、ある意味人口無能を相手にしている気分になります。

ちょっと愚痴っぽくなってきましたね。すみません。


>>196
ちょっとモチベーションがかなり落ちているので、仕事のペースが落ちて来ているのは
事実ですね。
最近は人と喋るのが辛いような気はします。
（息を吐くように喋ってしまうので苦しい。しゃべりながらため息ついているような。）

202 : 187 : 03/12/15 15:43

まあ辞めるのは簡単ですが、自分の弱点も克服したいなと思っています。
　交渉ごとの弱さ
　要領の悪さ
　それほど手早くは無い仕事（真面目に作り込んでしまう。手を抜くのがヘタ）


この業界ではこのような理不尽な抑圧って多いと思うのです。
ですから、弱さを克服しないと辞めてもまた同じ目に合ってしまう可能性がありますし、
その都度辞めるのもちょっと安易すぎるかなと。

203 : 仕様書無しさん : 03/12/15 17:17

>201
そこまで酷い所の経験は無いけど、状況はなんとなくわかるよ。
>「実は既にケツは決められている」
っていうの自体も、そう珍しい話じゃない。
まだそういうDQNなやりかたがまかりとおる業界だからね。
結果的に辞める事になっても、同じ過ちを繰り返さない方法を身につけないと無限ループに･･･

んで、そういう時どうするか、って事だけど。
結局の所、営業(社長)というフィルタを通して仕事しているのが一番マズいんじゃないの。
対応策としては、「技術者自身が客と直接交渉」じゃないかと思われ。
そうやって、開発の主導権をしっかり握る方向に動けば今よりはマシにできる可能性はある。
その客もDQNだったら・・・迷う事は無い、全速力で逃げろ。

204 : 194 : 03/12/15 17:54

出来る部分の定義することと、残工の定義とスケジュールを決めないと、
残工が雪達磨式に増えるからね。出来る部分の不具合対応とセットで言って
来るから、こういうケースは終わり無き仕様にはまりやすいよ。

205 : 仕様書無しさん : 03/12/15 21:32

>187
いま、うちの会社(これも弱小)から助っ人に行ってる爆発した案件も、
そんな感じで、すごいデジャブ…

206 : 仕様書無しさん : 03/12/18 02:33

俺も自分のいた会社のワンマン社長としか思えん。
他の奴の書く破綻プロジェクトに対する正しい対応は通用しないと思われ。
ケツを持たされるのはお前だ。今すぐ辞めろ。

207 : 187 : 03/12/18 04:56

やはりこの業界はこういう状況って多いんでしょうね。

>>203
＞対応策としては、「技術者自身が客と直接交渉」じゃないかと思われ。
一応、パッケージソフト開発なので客からの無茶な要求は無いのです。
つまり営業がより売り易くするための要求が厳しいといった状況ですね。
もちろん、会社の状況改善が前提の下での要求ですので・・協力するしか
ないのです。

>>204
曖昧な部分は将来のバージョンアップで対応すれば良いとよく言われます。
PSXなんか例に出されますね。だから最低限のものをくれと。

やはり技術素人に理解してもらうのは無駄なのでしょうか。

>>205
どこでもありがちなんでしょうか・・・・・。

>>206
そうですね。仰る通りです。
しかし、何とか改善出来るならそのための努力は行なってみたいのです・・。

ところでかなり以前ですが、このような記事を見かけてブックマークして
いたのですが、これを見せた所で効果あるでしょうか？
ttp://www.solid-web.com/article/2001/0930.html

こういう状況が当たり前ならもっと過酷な条件を突きつけてやろうなんて
思いますでしょうか？

208 : 仕様書無しさん : 03/12/19 11:34

この業界もうダメポ

209 : 仕様書無しさん : 03/12/19 13:19

>>187
>いたのですが、これを見せた所で効果あるでしょうか？
>ttp://www.solid-web.com/article/2001/0930.html
何かを見せて効果がある相手なら話したほうがもっと効果があると思わないか？

お前がいくら頑張って仕事したからといって独りの作業量なんてタカがしれてる。
徹夜続きでフラフラになって仕事するよりも、残業しないで布団でしっかり寝たほうが効率上がる場合も多いぞ。

お前は今の会社を辞めたら死んでしまうのか？そうじゃないだろ。仕事はいくらでもあるよ。
逆に今の心身状態が続くとかなりの高確率で死ぬかもな。過労死か自殺かはしらんけど。

とにかく、出来ないものは出来ないのだから開き直るしかない。

210 : 仕様書無しさん : 03/12/19 13:19

俺はそういう状況を何とかしようと５年間頑張って、とうとう退職した
奴を知ってるが、「３年早く辞めればよかった」と常に言ってるぞ。

頑張るのも良いと思うけど、自分の中で期限を決めて、状況が改善され
ないようなら辞めるべき。

211 : 仕様書無しさん : 03/12/21 17:22

>>209の「とにかく、出来ないものは出来ないのだから開き直るしかない。」

これが正解w

212 : 仕様書無しさん : 03/12/21 18:35

>>187

嘘で出してしまった「あと５週間後」とかに、客が設備や
人員やその他のプログラム外のリソースを予約していた日にゃ、
『できませんでした』では済まないな。
少なくともリソース予約の損害賠償(その分の値引)をされても
文句は言えない。

自分のみを守るためにも、会社に(なによりユーザーに)迷惑を
駆けないためにも、 >>211 >>209 の言っていることを
肝に銘じるべき

213 : 仕様書無しさん : 03/12/28 04:22

age

214 : 仕様書無しさん : 04/01/30 02:14

age

215 : 仕様書無しさん : 04/01/30 02:20

営業が仕事取ってくる時に決めちゃうから、自分で見積もったこと無いよ。



・・・頼むから勝手に決めるな。

216 : 仕様書無しさん : 04/01/30 10:54

187と漏れの現状は全く一緒。マジびびった。

217 : 仕様書無しさん : 04/01/31 01:32

>187
漏れも以前一人で受け持っていたプロジェクトもそんな感じだった

SE（肩書きだけの汎用系から落ちてきた中年）から
A4で2枚の手書きのフローチャートだけで
パイロット・システム（平均のプログラマで15人/日～20人/日くらいの規模）を
7人/日で作ってくれと無理難題を言ってきたのね。

まあ、第一印象で馬鹿かこいつと思ったんだが、
直接のご指名だったのと、ざっと見た感じ、やってやれない事も無いなと思い承諾。

ところが組んでる最中に、そのSEが要件レベルで変更をかけて来やがる
そして、そいつが思い出したかのように進捗状況を確認してきて
漏れがまだ終わってません、と素直に答えると
まあ案の定、今日一日何をやってたんだと指摘が来るわな

で、漏れは日頃の日課でタスクリスト(To-Do List)を詳細に記録しているので
その日の全作業内容を口頭で（超高速）列挙してやったんだわ
その大半（14件中の10件くらい）が、そいつ（ＳＥ）からの要件変更の対応だった為
そいつ唖然とした顔で何も言えなくなってたよ。＜内心してやったりとほくそ笑んだよ

それ以来、そいつは進捗状況は聞いて来るが
漏れが終わってませんと言っても、以前のようなバカな指摘はして来なくなったよ。

218 : >217の続き : 04/01/31 01:32

スレとはちょっと趣旨がずれたけど、そういった対応で相手を牽制する手段もあるという事例です。
特にプログラム（現場）に詳しくない上司や、システムに深くかかわってないＳＥなんかに
今自分がどのようなタスクをこなしているかを明確に伝えるのは有効かと思います。

まあ、無理なら無理でその理由を詳細に列記した資料なり理論なりを叩き付けてやれば
大抵の人間（システムに疎い人間でも）は納得するけどね。

それでもやれって言うバカなＳＥには、漏れのとどめの台詞で
「命削ってまでやれって言うなら、やりますがもしもの場合は責任取って貰えるんですよね？」
ってのと
「今の状態を改善する気が無いのなら、このプロジェクトを降りさせて頂きます（会社辞めます）」
と言ってやります、既に2回言ったことがありますが（一人はSE、もう一人は社長）
これを言ってやると大抵は、人員の増員、規模の縮小、納期の延長、とかを検討してくれました。

まあ、ご参考までに命在っての物種ですからね。

219 : 仕様書無しさん : 04/02/01 02:34

正直、そこまでプロジェクトに尽くす義理も無いな、と感じる

220 : 仕様書無しさん : 04/02/04 05:28

あげ

221 : 仕様書無しさん : 04/04/02 03:14

age

222 : 仕様書無しさん : 04/04/02 06:59

この業界って実に多いよなぁ、こういう話。
俺も独立のきっかけがそのケースなんだよな。
どう考えても18人月の仕事を新人2人をOJTで教育しながら
半年でやれと言われ「その納期ではできません」と答えるも、アホ社長から
「業務命令だ」と言い切られ、半年間ボロボロになって仕事したけど
やっぱり間に合わなくて、部下の前で大声で始末書を書けと言われたよ。
怒りで手が震えた。
どうにも我慢ができなくて、始末書の代わりに退職届けを書いたよ。
俺が辞めて半年後に倒産したときは、心の底から嬉しかったな。ｗ

223 : 仕様書無しさん : 04/04/02 07:04

思うに、会社の体力がなくなってくると無理な納期の仕事も取らざるを得ないし、
納期を正確に見積もれないやつが上司だと、自分も含めて会社はボロボロになる。

どっちにしても、無理な納期を強要されるような会社に将来はないと言っていい。

224 : 仕様書無しさん : 04/04/04 21:36

ソフトハウス以外の一般企業に入って、小規模の開発をしたりすると悲惨なことがあるな。
開発のことを何も解ってないオッサンが上司で勝手に納期を決められたり。

225 : 仕様書無しさん : 04/04/14 00:18

>>224
遠慮なくそのオッサンにつっかえせ。
できないものはできないと。
あまり感情的にならずに根気よく言ってれば、
相手もそういうものなのかと納得するよ。

226 : 仕様書無しさん : 04/04/25 16:09

ＣＭＭＩというプロセス成熟度評価の基準がけっこう世にひろまり世界標準化
してきているそうですが、みなさんの"開発環境"もその成熟度評価の対象として
評価されていますか。

よろしければＣＭＭＩの浸透度の現実について論じてください。オナガイします。

227 : 仕様書無しさん : 04/04/25 16:25

CMMI?はぁ？なにそれ？







というのが99%の現状だ。ネタではなくホント。

228 : 仕様書無しさん : 04/04/25 17:10

>>227
ありがとうございました。
もしかして、とは思っていましたが、「やはり、、」そうでしたか・・・。

ソフトウエア開発技術者試験でも出ていたこのタームはまだ一般のシステム開発
の現場には浸透していない状態なんですね。

また考えてみます。

229 : 仕様書無しさん : 04/04/25 19:05

>>223
そういう企業は直ぐに倒産して、
企業のスクラッチ＆ビルドが速い業界になってほしい。

230 : 仕様書無しさん : 04/04/25 19:09

日本の企業は今CMMなんかよりPMやISMS認定取得に忙しいだろ。

231 : 仕様書無しさん : 04/04/25 23:17

（作業時間×作業数）÷規定勤務時間
でやると、どんぐらいでできるか
わかる、作業時間等の割り出しは
過去の自分の作業データから算出
上の奴は一日の規定時間を考えずに
見積もりするからな、あとできない
事はできないと言う事も大事だす