プログラミングスキルをもっと評価すべき２

1 ：仕様書無しさん：04/06/09 15:19

http://jibun.atmarkit.co.jp/ljibun01/rensai/consult/consult023.html

優れたプログラマへの評価はもっと高くあるべきなのではないでしょうか。
新人プログラマを何人も使うくらいであれば、一見開発に時間がかかるよう
に思えますが、ベテランのプログラマを利用した方が、開発期間、コスト、さ
らには運用管理についても良いのではないかと考えることが最近多くなっ
ています。
--------------------
２スレ目に突入です。

過去スレ

プログラミングスキルをもっと評価すべき
http://pc5.2ch.net/test/read.cgi/prog/1084889246/

2 ：仕様書無しさん：04/06/09 15:24

プログラミングスキルをもっと評価すべきだけど、評価できる奴がおらん

3 ：仕様書無しさん：04/06/09 15:32

>>2
では、何をどうやって、どんな基準で評価して欲しいのか
現役ＰＧが指し示してやればいい

4 ：仕様書無しさん：04/06/09 15:45

>>3
まちまちだろう。基準など示せない。
メモリが５１２ＫバイトなどのＤＯＳの時代は、実行コードのコンパクトさが重要視されたけど。
今のように、５１２Ｍバイトが当たり前に搭載できる時代は、メモリを馬鹿食いしても、実行速度重視だし。
また、制御系なら、キャッシュにコードが全部収まり、ＲＡＭからはデータだけってのもあるしね。

5 ：仕様書無しさん：04/06/09 15:48

ただ言えるのは、管理職のオヤジからは、プログラミング言語が、ハングルやアラビア語に見えているってこった。
良い文章か悪文か判定不能。

6 ：仕様書無しさん：04/06/09 15:56

>>4-5
論理的思考が仕事のはずのＰＧが１レスの猶予もなく降参宣言か

まちまちで、基準など評定不能だというなら
限りなく効果的な判定に近づく最適解を見つけ出せばよいだろうが

7 ：仕様書無しさん：04/06/09 16:24

＞限りなく効果的な判定に近づく最適解を見つけ出せばよいだろうが

　青果物=programmer（仕様書,給与,応答時間（納期））;

8 ：仕様書無しさん：04/06/09 16:41

考え方がちょっと違うような気がする。

管理する側から見ると、個々のスキル差を考慮しない方が管理しやすい。
つまり、「個人のスキル差に影響されない作業方法」が望まれるわけだ。

いままで５人で１ヶ月かかったから、今度もそうなるだろう的な予想がしたいからね。
だから個人的にはプログラマが二極化するような気がする。

1.職人プログラマは研究開発や特定の製品に特化した技術を磨き、高い対価を支払われるが、廃れたら終わり。
2.職業プログラマは大規模プロジェクトの土木担当で対価は安い。その分気楽に流されるまま。
3.どちらも嫌なやつは、品質管理やマネージャ。

プログラマから見ると、
1.ハイリスク、ハイリターン
2.ローリスク、ローリターン
3.リスク管理を自分でしたい（ただ責任は自分以外にも及ぶ）

だと思ってる。

9 ：仕様書無しさん：04/06/09 17:06

> 1.職人プログラマは研究開発や特定の製品に特化した技術を磨き、高い対価を支払われるが、廃れたら終わり。
> 2.職業プログラマは大規模プロジェクトの土木担当で対価は安い。その分気楽に流されるまま。

プログラミングスキルをもっと評価すべき　と言ってる奴は大体2だけどな

できる奴は自然と評価されてるから、評価して欲しいなんて主張しない。
相対評価の低い奴ほど客観的評価をしろと主張するが、評価軸が変わったところで
評価が低いのは変わらない。

という結論が前スレで出たから新スレは入らなかったんだが、結局また評価の低い
奴らがグダグダくだらない主張を繰り返すのか。

10 ：仕様書無しさん：04/06/09 17:20

>9
Javaのsocketはポート公開しないなんて言う人の集まりですから。
これ以上言っても無駄です。

11 ：仕様書無しさん：04/06/09 17:59

結局はコミュニケーションでしょ。評価っていうのは。あとバランスね。

12 ：仕様書無しさん：04/06/09 19:53

>10はこのスレの熱烈なファンだなｗ
なにが書き込まれているか気になってしょうがないか？

13 ：仕様書無しさん：04/06/09 21:45

まー結局この業界
プログラムへたくそで出世した香具師は見たこと無いな

14 ：仕様書無しさん：04/06/09 22:12

逆だろフツー
プログラムすごくて出世した香具師を見たことない

15 ：仕様書無しさん：04/06/09 22:48

>>6
君の思考には嫌悪を覚える。
評価基準を決めもせずに最適化だって？
目的も無しに手段を行使するなんて、君は本当にプログラマか？
それは普通、妥協と呼ばれるんだよ。

16 ：仕様書無しさん：04/06/09 22:53

>>14
できる奴は、開発プロセスとか客や他部門との関係なんかも
「プログラム」する。

オレにはできんガナー。さようなら。

17 ：仕様書無しさん：04/06/09 23:00

上司と酒飲めば良いんじゃないか？
簡単ジャン。

18 ：仕様書無しさん：04/06/09 23:09

みんな酒のみますが

19 ：仕様書無しさん：04/06/09 23:25

>>15
>君は本当にプログラマか？
明らかに違うだろ。

20 ：仕様書無しさん：04/06/09 23:25

論点ってだいたいこんなところでしょうか
1. 「もっと評価すべき」というが、どうやって評価すればみんな納得するのか
2. 「もっと評価すべき」というが、そもそもなんで今評価されていないのか
3. 「もっと評価すべき」というが、仮に適正評価できたらその後どうなるのか

あとこのコンサルのおっさんは雲の上から問題を放り投げただけで
解決しようとは思ってないだろうし、自分の関わる仕事でベテラン起用なんか
しないんだろーなーと思うがどうだろう。

21 ：仕様書無しさん：04/06/10 00:04

デスマーチ好きの一掃をすべきだ。
特に他人にデスマさせるのが好きな奴は措置入院。

22 ：仕様書無しさん：04/06/10 01:15

まだやるつもりかい。

コーダーはプログラマーとしては評価されないんだよ。
当然だろ

23 ：仕様書無しさん：04/06/10 01:24

品質を高く保つには、プログラミングスキルが必要だよ。
業務スキルだけじゃ、営業と変わりない。

24 ：仕様書無しさん：04/06/10 01:47

品質の定義と評価方法から始める？

25 ：仕様書無しさん：04/06/10 01:50

だれもコーダーをプログラマとして評価しろなんて言ってないんだけど
わかってない人がまたのこのこ出てきたみたいだね。

設計からちゃんとやってるプログラマの評価として、工程管理や
設計のスキルと同様にコーディングスキルも評価していいんじゃないか、
っていう話だと思うけど。

それがいつの間にか「コーディングスキルだけの人間も評価しろ」に
置き換わるのは、何かトラウマか個人的な執着でもあるんだろうな。

26 ：PGがマネジメントを語って何が悪い：04/06/10 02:18

>>20
コンサル？私のことかい？
私は君の隣で働いているかもしれない単なるいちプログラマだよ。

>雲の上から問題を放り投げただけで解決しようとは思ってないだろうし

いいや。解決してみせるつもりだ。……君は私を笑うかい？
だが、解決策を見つけるにはこのスレのプログラマたちの助けが要る。手伝って欲しい。

http://www.mikihoshi.com/wiki/wema.cgi?page=200406100037483544

もう少し要素を増やして、問題の流れを簡潔にまとめたいんだ。
何が一番の原因なのかが分かれば、解決策が見えてくるかもしれない。

27 ：仕様書無しさん：04/06/10 07:55

>>25
>工程管理や
>設計のスキルと同様にコーディングスキルも評価していいんじゃないか、
>っていう話だと思うけど。

うわぁ～
コーディングスキルが工程管理や設計と同列だと思ってるの？
流石はコーダー君。

28 ：仕様書無しさん：04/06/10 10:26

なんか全てのプログラマを、==コーダー、と定義したい池沼の方が居られるようですne。

29 ：仕様書無しさん：04/06/10 12:43

>>27
ｺｰﾃﾞｨﾝｸﾞできないﾌﾟﾛｸﾞﾗﾏを使いたいと思うか？

30 ：仕様書無しさん：04/06/10 13:10

相変わらず低次元の争いか

31 ：仕様書無しさん：04/06/10 18:05

>>27
Go to hospital.

32 ：仕様書無しさん：04/06/10 21:16

>>29
コーディングしか出来ないプログラマも役にはたたねーけどな。ある程度は自前で管理位はやってくれねぇと困るんだよねぃ。

33 ：仕様書無しさん：04/06/10 22:01

プログラムが動く仕組みを理解出来ないSEも役に立たねーけどな。
お前は営業か、それとも顧客の代理人か。

34 ：仕様書無しさん：04/06/10 22:11

↑こういうなすり合いも、業界のレベル下げてる要因だよな

35 ：仕様書無しさん：04/06/10 22:24

>>34
同感。文句言う前に自前で設計や管理くらいやってくれと言いたい機会がどれほど多いことか。何人日で出来るか?程度の質問でフリーズすんだからさ、出来ねえ奴ってのは。

36 ：仕様書無しさん：04/06/10 22:30

この板に常駐してて
スキル高いやつを片っ端から自作自演で叩いてるヒキコモリが居るんだよ
ＩＤ無い板はどこもそう

37 ：仕様書無しさん：04/06/10 22:34

>>36
被害妄想うざい

38 ：仕様書無しさん：04/06/10 22:56

>>32
コーディングは名人級だが管理設計はダメな人と
管理設計は名人級だがコーディングはダメな人と
「プログラマ」として採用されるのはどっち？

というふうに考えると、後者はそもそもそれ系の会社に
すら入れないと思うんだよね。

39 ：仕様書無しさん：04/06/10 23:21

なすり合いっていうか、
「自分の好きなことしかやらない」っていう子供っぽい考え方の人がものすごく多い。
そもそも、人付き合いしたくないからコンピュータ業界なのかもしれないけど。

どこの業界にもそれぞれの職業のスキルはあるはず。
それなのに、なんでこんな「手順の一部にこだわる」人が多いんだろう。
こだわった結果いいものが出来るなら構わないけどそうなってない。

40 ：仕様書無しさん：04/06/10 23:26

両方できる人は有能、
片方だけしかできない人は普通、
両方できない人は無能

ということで大半の人は納得できると思うんだけど、ただ一人だけ
「コーディングのスキルはどうでもいい」「コーディングスキルは他の
スキルに比べて重要度が低い」と思ってる人がいるから話が
こじれてるんだろうな。

41 ：仕様書無しさん：04/06/10 23:33

どっちにしても両方出来るやつなんか見たことない。
元来が相反する能力が必要なんだから。
出来るとしたら精神分裂的な奴だけだろう。

42 ：仕様書無しさん：04/06/10 23:36

人の管理をきっちりやるにはまず兼任禁止だと思わない？

43 ：仕様書無しさん：04/06/10 23:39

そうだと思う。
人を管理するって言う言葉は嫌いだけど。

44 ：仕様書無しさん：04/06/10 23:56

人の管理をする前に、人事採用担当者の目利きを最適化汁！
さすれば、管理コストは大幅に減少する。

45 ：仕様書無しさん：04/06/11 00:39

>>41
コーダーの言い訳ですね。

まぁ、コーディングは普通の知能を持った人なら誰でもできると
いうことを認めたくないのはわかりますが。

46 ：仕様書無しさん：04/06/11 00:45

てか、今でもコーダーがマジいるのか？サブシステムくらいまで最低できないと仕事になんねえよな？

47 ：仕様書無しさん：04/06/11 01:05

コーダーなんてものは、パンチカード時代の遺物。

会社にいる定年間際のおじさんの昔話では、
確かに昔のメインフレームでは、
上流行程　→　プログラマー　→　コーダー　→　キーパンチャー　となっていたそうだ。
まず、プログラマーとコーダーが統合され、
パンチカードの廃止と共にキーパンチャーも消えたそうな。

当時のプログラマとコーダーの業務分担はどうなっていたのか、俺は想像できない。

48 ：仕様書無しさん：04/06/11 01:10

実は>>45だけがコーダーの罠

49 ：仕様書無しさん：04/06/11 01:21

>46 サブシステムくらいまで最低できないと仕事になんねえよな？
普通サブシスでも100人月以下ってことはないだろ。
おまえ一人で出来るのか？
すげーな。
それともチンケなものしか作ったこと無いのか？

50 ：仕様書無しさん：04/06/11 01:36

>>45
だから主婦のパートとか学生のバイトにやらせれば？
職安でうろうろしてる日雇いのおじさんとかも。

「だれでもできる」って言うならね。

51 ：仕様書無しさん：04/06/11 07:47

評価するには測定する必要があるんだが

どうやってプログラミングスキルを測る？
試験でもすればいいのか？

52 ：仕様書無しさん：04/06/11 07:58

最低限基本情報処理を持ってなかったら、業務禁止にしようぜ。
基本情報処理なんて、この業界で普通に働いてる人間なら余裕だし、
知識を持たないエセSEならもしかして落ちてくれるかも試練。

53 ：仕様書無しさん：04/06/11 08:04

ttp://www.it-career.jp/
IT-SSでﾚﾍﾞﾙはかっとけ。

54 ：仕様書無しさん：04/06/11 10:12

今時のＰＧとコーダーの分類についてだが、たとえば

・データＡを受け取って処理して結果Ｂを吐き出してＣに伝える

という仕様があって

これをもとにいきなり設計・プログラムできるのがプログラマなのか？
で、この仕様から設計・具体的な処理フロー・アルゴリズムまでが提示されて
はじめてプログラムできるのがコーダーってこと？

でも、こんなコーダーっているのか？
いるとするなら単なる新人だろ

55 ：仕様書無しさん：04/06/11 10:15

>>51
上流工程だって測定してないじゃん。

56 ：仕様書無しさん：04/06/11 10:59

>>13
いっぱいいると思うけど・・・

57 ：仕様書無しさん：04/06/11 12:56

>>54
規模の大きなプロジェクトだと、
＞で、この仕様から設計・具体的な処理フロー・アルゴリズムまでが提示されて
＞はじめてプログラムできるのがコーダーってこと？
というようなコーダーを使ってるところもある。
もっとも処理フローを作る能力が無いというよりは、処理フローを作る権限を
与えられて無いと言ったほうが正確だけど。

58 ：仕様書無しさん：04/06/11 13:26

建設的な議論にするなら、「この業界の理想的な分業とは」というテーマに
したほうがよさそうだね。

59 ：仕様書無しさん：04/06/11 14:05

分業そのものに反対。協業なら支持。
新人は、一人前の人間に弟子入り汁

60 ：仕様書無しさん：04/06/11 18:49

>>59 そんな貴方に…この本をお勧めしたい。

http://d.hatena.ne.jp/asin/4894712741
http://d.hatena.ne.jp/asin/4894714418

徒弟制度にしろ、という話は前からある。

61 ：仕様書無しさん：04/06/11 19:31

>>60
義妹制度になりませんか？(*´д｀)ﾊｧﾊｧ…

62 ：仕様書無しさん：04/06/11 19:45

>>61
「コードがバグっていてよ」

でもマジで、マリみて制度にしたらけっこううまくいくかもしれない。

63 ：仕様書無しさん：04/06/11 21:46

>>54
じゃ、俺プログラマだ。
画面イメージが書かれた紙っぺら一枚もらって、
あとはおまかせって感じだから。

64 ：仕様書無しさん：04/06/11 22:36

>>59-60
容姿の優れた女の子しか弟子入りできないのが現実なわけだが

65 ：仕様書無しさん：04/06/12 00:23

>>54
沢山いるよ。
このスレせ必死になってコーディングマンセーしてる君とか。

66 ：仕様書無しさん：04/06/12 00:33

プログラミングスキルの個人差はこれからどんどん
無くなっていくんじゃない？
一昔前のCとかCOBOLとかはコーディングレベルに個人差は出てたけど、
（特にマニアが書いたアセンブラは読めない！！）
今はほとんどフレームワークに則った開発じゃん。
API並べりゃ出来ちゃうし、誰が書いても似たようなもんだろ？

67 ：仕様書無しさん：04/06/12 00:34

ソースコードをデザインするのは楽しいと思うんだけど。
ソースコードを「書く」作業は事務的作業だけどよ。

68 ：仕様書無しさん：04/06/12 00:35

じゃあ新宿西口で雑誌並べてるオッサンにでも作らせとけ

69 ：仕様書無しさん：04/06/12 00:37

ちゃんと教えりゃできるかもな。
モラルとかのことはおいといて。

70 ：仕様書無しさん：04/06/12 00:40

>66
プログラマの発言じゃないね。
隣の席のコボラーが書いたコード見たことないの？
#っていうか、66がコボラか？

71 ：仕様書無しさん：04/06/12 00:47

>>66
コード記述ってさ、基本は反復と条件分岐と変数宣言
および代入とサブルーチン呼び出しの組み合わせでし
かないわけで。

それらの賢い、あるいはマトモな使いかたってのを知ら
ない馬鹿は沢山いて、そいつらはどれだけライブラリを
整備しようと、その整備されたライブラリの上で馬鹿な
コード書きますよ。

72 ：66：04/06/12 00:48

>>70
意味不明。確かに俺は君の脳内で定義された
プログラマではないと思うが。

73 ：66：04/06/12 00:52

>>71
半分くらい同意です。
ただ昔に比べたら個人差は無くなってきたのかなと。

74 ：仕様書無しさん：04/06/12 00:54

やったこと無い奴からは「誰がやってもおなじじゃん」と見えるものだ。

75 ：仕様書無しさん：04/06/12 01:17

>>74
それは違う。

普通の知能を持った人なら、「誰がやっても同じじゃん」と思う。
しかし、一般よりも知的レベルが劣る人達には難しいと思えるんだろうな。
それはそれで可哀相なことです。

大丈夫。僕は君のことをイジメたりしないから。
自分が幸せなら、それはそれでいいと思うよ。

76 ：仕様書無しさん：04/06/12 01:20

確かに、プログラマにもなれない馬鹿がいっぱいいるようだな。

77 ：仕様書無しさん：04/06/12 01:22

問題なく動きゃいいじゃん。

78 ：仕様書無しさん：04/06/12 01:58

コーダー君ってどうでもいいところに拘るよね。

保守のことを考えて全体の見栄えを統一するために、
プロジェクトでインデントを４スペースにしようと言っら
「２スペースにするべきだ！」
っと永遠と３０分も言い張っていた。

で、いざコーディングを見てみたらインデント以前の問題。
そりゃ、意味もなくif文を多重ネストしたらそうなるわな。
ヤレヤレ。

79 ：仕様書無しさん：04/06/12 02:06

>>73
むしろ昔と比べて広がってるよ。
例えばCとJavaの言語仕様だけ比べるなら差はもちろん縮まっている。
だけど昔よりもアプリ自体が巨大になって、覚えることは増えている。
フレームワークを使用するにしても、使用出来ない人、ただ使用する人、
ソースコードも読んでちゃんと使う人、など様々。
どのフレームワークがどれに適切で、どのようなものには適さないなんて
ことも覚える必要がある。

俺も昔MS-DOS上でアセンブラを使ってたけど、狭い範囲だから出来た
ことで、必要な知識量は今の方が増えてるよ。
クロック数を数えたり、コードの動的書き換えするより、クラスライブラリや
デザインパターンを覚えて理解する方が大変だって分かるよね。

アルゴリズムやデータ構造が必要なのは今も昔も変わってないし、
オブジェクト指向が理解出来なくて置いてけぼりにされているのがいるのは
今の方が広がっている証拠だよね。

それにしてもこの業界にいながら継続して勉強しない奴が多すぎる。
ネットで検索して調べない奴がいたのにはマジでびっくりした。
柴田芳樹氏が雑誌でネットで安易に調べる奴が多い、と嘆いていたが
それ以下だ。

80 ：仕様書無しさん：04/06/12 02:19

>>79
MS-DOS上でのアッセンブラを使ったぐらいで昔を語って欲しくないな。

昔はリソースの制限が今以上にきつかった。
お気楽さから言ったら今のほうが全然楽だぞ。
最適化していない直感的なアルゴリズムでもそれなりの性能でるしな。

81 ：仕様書無しさん：04/06/12 02:21

>>78
インデントなんて後からどーにでもなること。
30分相手する方もあほうでしょ。

偏ったコーダーだけを取り上げて、
十把一絡げに断罪するのはやめてほしい。

明快な実装方針とロジックが組めれば
コーダーとしてはGood enoughだと思う。
確かにコーダーの仕事は小さいけど、誰にでも
できるってもんじゃないし、軽いわけでもない。

82 ：仕様書無しさん：04/06/12 02:42

関係ないかも知れんが、コーダーって名刺になんてかいてあるの？

83 ：仕様書無しさん：04/06/12 02:44

>>82
プログラマー　もしくは　ITエンジニア

JAROに電話したくなるよ

84 ：仕様書無しさん：04/06/12 02:58

ITエンジニアか。
プログラマの名刺に、SEとかいてあることもあるし。
名刺は名刺ということか。

85 ：仕様書無しさん：04/06/12 03:11

>>81
チームで仕事したことある？
コーディング途中でも、他の人のコーディングを見ることあるでしょ。
その時にインデントや、コメントの付与規則がメチャクチャなら萎えるだろ？

86 ：仕様書無しさん：04/06/12 03:18

>>85
おまえに管理能力が無いだけだな。
わざわざネットで引き合いに出されるコーダ君が可哀想になるな。
おまえには能力のかけらも無さそうだな。
会社で浮いてるだろ？

87 ：仕様書無しさん：04/06/12 03:37

「誰がやっても同じ」
というのは、他人が自分より優れたコードを書くということに
気付いていないか認めないか、ってことだろうな。
つまり自分のレベルの低さがわからないから「同じ」に
見えるわけだ。

謙虚な人は他人のコードを見て「あ、この技はすごいな」
とか「そうか、こういう方法があったのか」とか、学ぶことがいろいろ
あって、そうすると「自分はまだまだだな。世の中には
すごいスキルを持った人がいるな」と思うわけだが、自分が
最強と思っていてその実たいしたことない場合、他人の
コードを見ても「ふーん」程度にしか思わないと。

88 ：仕様書無しさん：04/06/12 04:36

誰がやっても同じ！
私にはコミュニケーション能力があります！！

89 ：仕様書無しさん：04/06/12 08:47

まあ人間の個々の能力には明らかにバラつきがあるんだから大抵のことには優劣が付く。
プログラミングに限らず「誰がやっても同じこと」なんてそうそうあるわきゃ無いわな。

それでも
　「そんなことは無い。誰がやっても同じだ」
と強弁する人は多分、実務経験が無いか少ない、あってもよほど小さなプロジェクトしか
経験が無い、メダル級に頭が弱いか、の何れかに違いない。

90 ：仕様書無しさん：04/06/12 09:23

>>89

管理側の人間にしてみれば、プログラマの能力のバラつき
なんて管理の邪魔でしかない。均一なものほど管理しやすいものは
ない。

という理論を振りまいている、自称昔は実務をバリバリにこなしていた
「優秀な」管理者が近くにおりますが...。

91 ：仕様書無しさん：04/06/12 09:31

短納期の仕事が増えてきてるんだから、プログラマーのスキルは
かなり重要になってきてると思うんだけどね。

92 ：仕様書無しさん：04/06/12 10:04

>>91
短納期だからこそ交渉は重要。より短期間での要件定義に設計が求められると思うんだが。
コーディングスキルはあって、当たり前。その上が重要なんじゃないのかね。

もっとも、コーダーで済むほど甘い所なんてあるの?

当たり前の様に、要件定義やら設計やらをやってるんだけど、もちろん、コーディングも込みで。

93 ：仕様書無しさん：04/06/12 10:31

プログラミングスキルが高いと残業時間が減る
プログラミングスキルが低いと残業時間が増える
ゆえにプログラミングスキルが低いほど給与が増える

94 ：仕様書無しさん：04/06/12 10:48

しつけーなおまいら！
わかったよ。
日曜大工で不細工な犬小屋作るなら設計して釘も打てるってわけだな。
ビル建てるとなると支持されたとおり動くドカタなんだろ？
犬小屋を上手に作れてもビルは建たないぞ。
犬小屋作れたくらいで勘違いして俺はスーパープログラマ
なんて間違っても思うな。
恥かくだけだぞ。
犬小屋作ってるやつに稀に神みたいなのもいるが
おまいらじゃないことは確かだｗ

95 ：仕様書無しさん：04/06/12 10:58

とんでもなく不細工なビルや、いつも補強工事ばかりしてるビルが
建ち並んでるのはどういうことですか？

96 ：仕様書無しさん：04/06/12 11:01

>>95
犬小屋よりも少しはCool！

97 ：仕様書無しさん：04/06/12 11:05

犬小屋とビルを対比させた例ってよく聞くけど、この話の元ネタって何？

98 ：仕様書無しさん：04/06/12 11:12

俺が最初に見たのはK仲川だな(もう10年くらい前だと思うが)。
元ネタはしらん。

99 ：仕様書無しさん：04/06/12 11:35

>>98
おまえ10年もこんなとこで･･･

100 ：仕様書無しさん：04/06/12 11:37

よく聞くネタだが、能無しPG黙らせるにはもってこいだな。

101 ：仕様書無しさん：04/06/12 11:40

そうか？

102 ：仕様書無しさん：04/06/12 11:46

ＰＧって上司たちと酒飲まないやつが多いね。

103 ：仕様書無しさん：04/06/12 11:46

>>100
ついでに能力のあるPGを黙らせる手段としても有効だけどな。大規模システムの
設計を単独でこなすPGは国内じゃ少数派だから、大抵はこれで黙るんだな。

もっとも、黙られてしまうと困るのは、ユーザじゃなくて、結局はPG自身なんだ
けどね。設計と製造の分業なんて理想論は通用なんかしないし、本当に使いモノに
ならないPGってのは、視野の狭い奴で、自分の分担の前後左右を一切、確認しない
ようなのを言う。

104 ：仕様書無しさん：04/06/12 11:49

>>102
客と飲んでたほうが気楽だし。

105 ：仕様書無しさん：04/06/12 11:50

>>103
ん～、文章が支離滅裂だな～（ｗ

106 ：PGがマネジメントを語って何が悪い：04/06/12 11:55

>>93
そこが問題だ。
最良の解決策は経営者の信念を変えさせることだが、
経営者が「残業多い＝頑張っている」の構図を
信仰してしまっている場合、それは容易ではないだろう。

しかし、この前提が崩れない限り、プログラミングスキルは評価されないのだ。
プログラミングスキルを高め、プロジェクトを無残業でスケジュール通りに完遂したとき、
給与は最低額になることになる。

ではどうしたらいいか？

この矛盾を管理職の連中に説明した後で、
プロジェクトをスケジュール通りに完遂できなかった時に
ボーナスにペナルティを与えるよう説得することだ。

つまり、プロジェクトを成功させる優秀なプログラマである君はいつも通りボーナスをもらい、
プロジェクトを失敗させる無能なプログラマはボーナスをもらえないようにするわけだ。

管理職の連中はコスト削減が大好きだ。人件費を削るのが
三度の飯より大好きだ。たぶん快く了承されるだろう。
そしてついでにこうも言っておくことだ。

「もしこの方法で浮いたコストをスケジュール通り完了したプロジェクトのメンバーに配分するなら、
メンバーのやる気は向上し、スケジュール通りに完了するプロジェクトの数が増え、
四半期内の消化プロジェクト数が増え、売上が増え、もちろん利益も増えるだろう」

覚えておくといい。ある矛盾した評価基準をどうしても変えられないときに
有効なのは、別の評価基準を組み合わせることで矛盾を相殺することだ。

107 ：仕様書無しさん：04/06/12 11:56

>>105は使いモノにならないんだね。つか、素人さんか(w

108 ：仕様書無しさん：04/06/12 11:59

>>106
それは、遅れる理由が、コーディングのスピードのみの場合にしか成立しない理屈ですな。
現実には、カットオーバー直前まで要件と仕様が固まっていない場合だってあるわけですが、それすらも、コーディングスキルでどうにかしてみせると?
馬鹿じゃないの?

109 ：仕様書無しさん：04/06/12 12:05

>>106
アンタ、前になんか図書いてた人か？　だったらわかってると思うが

・プログラミング工程への「入力」となる設計がマトモであること
・プログラミング工程に現実的な期間設定がされていること

という仮定が成り立たない限り、
いくら目の前のボーナスを弄っても本質的に解決はしないぞ。

プログラミング工程の生産性向上はそろそろ限界にきている。
本当は上流工程のスキルを的確に測定し、一定水準を
保つような方法を考えるべきなのだが、誰もそうしない。
そうなると困る人たちが大勢いるからな。

110 ：仕様書無しさん：04/06/12 12:07

>>93
プログラミングスキルが高いと、必然的に仕事が集まって残業が増える
プログラミングスキルが低いと、必然的に仕事が来なくなって残業が減る
だがしかし、給与に大差は生まれない

>>108
＞カットオーバー直前まで要件と仕様が固まっていない場合だってある

むしろ、そのパターンが最も多い気がする･･･

111 ：PGがマネジメントを語って何が悪い：04/06/12 12:09

>>108
その意見はもっともだ。しかし、そういった状況は私の提案が生み出すわけではなくて、
原因は他にあるのではないかな？

要求を固められない顧客から仕事を取ってきた無能な営業。
要求があっても仕様を固められない無能なSE。

彼らがいることが問題の原因なのだろう？
ならば、失敗したプロジェクトに関わった彼らのボーナスもカットするというのが公平というものだ。

確かに一時期は、PGに対して不当なボーナスカットが行われるかもしれない。
しかし、無能な営業や無能なSEが駆逐されるのだとすれば、将来的にはPGのプラスにもなるはずだ。

それとも君は、別の方法で残業問題を解決できるのかな？

112 ：108：04/06/12 12:19

>>110
結局、要件と仕様が固まるまで待つわけにはいかず、独自でやらざるをえない
場合がほとんど。本当に必要なのは、コーディングスキルじゃないと思うね。
つーか、コーディングスキルはPGなら最初から持ってて当たり前のもの。

むしろ、プラスアルファで、SEやアナリストがやっていた業務もやっていかな
きゃなるまいというのが本音。実際、要件定義から設計、製造、試験と一通り
こなしてるしね、自分も。ほんとは、コーディングだけやりてぇけど(その方が
ストレス少ないし)、設計があがってくるまで待ってたら、スケジュール的に
死ぬのは自分自身だもんなぁ。

>>102
上司がPMやPLやってたら呑むけどね。つか、同じ開発部隊の長なら一応、呑んで
おくことにしている。年配者やリーダーになるようなのは、一緒に呑む奴しか信
じないといった特徴があるんよ。これはI社みたいなとこですら、不思議と同じで、
面白いと思っている。

113 ：仕様書無しさん：04/06/12 12:22

Ｈ社は最悪っす。

114 ：PGがマネジメントを語って何が悪い：04/06/12 12:24

>>109
>プログラミング工程の生産性向上はそろそろ限界にきている。

そういう君はテストファーストしているかい？リファクタリングしているかい？
フレームワークの利用は？コードレビューは？コーディング規約は改良は？
設計のユーザ・レビューは？要求管理は？問題点管理は？タスクの優先順位確認は？
メンバーの工程見積もりの管理は？時間ばかりを取る打ち合わせのかわりに
メールを活用しているかい？そろそろ限界にきている？本当に？

XPによって誤解されているが、テストファーストは重要だよ。生産性が実際に向上する。
他の生産業での、工程でのテスト・品質管理の重要さを考えれば、至極当然のことだが。

115 ：仕様書無しさん：04/06/12 12:24

このスレにいる煽りがプログラミングスキル＝コーディングスキルと
考えるのはどういう訳かな。
デザインパターンやアルゴリズムなどは考慮外なんだろうか。

116 ：仕様書無しさん：04/06/12 12:25

>>114
よく言った。

117 ：108：04/06/12 12:25

>>111
問題を他責にしたって、解決はしないでしょ?
「他所が悪いんだ」
この理屈で解決しているのなら、誰も困りはしない。

ちなみに言っておくが、賃金の話なんて、実現はほとんど不可能。ほんとに
やりたいのなら、それだけの権限が要る。PGの立場では無理。

もっと現実的に考えると、PGがSEを兼任する方が容易だ。つーか、実際に
そうしている所が多いけどね。あなたの所は設計すらせずに済んでいるのかい?

118 ：108：04/06/12 12:26

>>115
無視はしていないけどね。設計もやってるんで、当前の様にPGに必要と
思っている。が、>>111の話だとその様に読めないんでね。

119 ：仕様書無しさん：04/06/12 12:29

ＳＥだけいればいいんじゃねーの。
製造は海外へでも。

120 ：仕様書無しさん：04/06/12 12:33

年々必要な知識が増えていくのに、PGの地位は年々落ちていく。
何なんだろうねー。

まあ、実際驚くほど無能なPGはいるけどね。
外注でやる気がなくて、教えても覚えず、仕様書出しても読まず、
仕事中に２ｃｈして、出来ないことを相談せずに抱え込む。
正直自分の目で見たが信じられない。
俺の権限じゃチェンジ出来なかったし。

だけど必要な知識が増えているんだから、プログラミングスキルは
重要性を増しているはずだ。
もっと評価して、無能PGと有能PGを分けるべきだ。

121 ：PGがマネジメントを語って何が悪い：04/06/12 12:34

>>117
だから管理職の人間にプレゼンテーションしろと言っているんじゃないか。
>>118
そりゃ、>>111は残業問題に限っての解決策だからね。
別の問題には別の解決策がある。

PGがSEを兼務するというのは、生産性問題の解決策だろう。

無能なSEのせいでプロジェクトが終わらない
↓
↓←優秀なPGがSEを兼務しよう
↓
プロジェクトが終わらないと会社が儲からない
↓
↓
PGが評価されない

という考え方だ。きちんと理に適っている。賛成だ。

122 ：仕様書無しさん：04/06/12 12:34

客が日本語が使えなくても良いと言うなら、海外へ丸投げだ

123 ：仕様書無しさん：04/06/12 12:36

>>119
SEを営業と読み替えてもいいかも。

SEがPGに比べて評価されてるのは、会社にとって金になるからだよな。
それって営業至上主義のDQN会社と同じじゃないか。
営業>SE>PGか？
それはおかしいじゃないか。
この業界の製造は手作業なんだから、製造する人間をもっと評価して欲しい。

124 ：仕様書無しさん：04/06/12 12:37

>>119
で、こんなものが納品されると。
ttp://www9.plala.or.jp/pandanotasogare/dvd.html

125 ：仕様書無しさん：04/06/12 12:37

そこでXPですよ

126 ：109：04/06/12 12:38

>>114
方針の都合で納品後はやたらとリファクタリングするわけにもいかんのだが
だいたい全部やってるよ。全部に十分な時間をとっているとは言えないけど。
十分な時間があって、それでも品質低いならXPも有効だろう。でも、それ以前。

あと、テストファーストってのは意外にプログラマからも受けが悪い。
「テストコードも作ろう」なんて言うと「仕事増やすな」とか言う奴がけっこういる。
XP文化を浸透させるのには時間が要るのかなと思う。

ここに来る人たちは、それぞれの目の前に広がっている開発現場に
相当ひどいバラツキがあることを考慮すべきだと思う。
本に書いてあるようなことがそのまま適用できれば誰も苦労しない。

あとXPを実践していくためには、同じメンバーで2～3回くらい
プロジェクトをやっていけるような土壌が必要。外注使いまくりで
ひとつ終わるたびに半分入れ替わりじゃ、いつまでたっても
レベルが上がらない。

114はそろそろトリップくらいつけたらどうだ？

127 ：仕様書無しさん：04/06/12 12:41

>>123
営業が評価されてるんじゃなくて、単純に文系業種の方が評価が高いってことなんじゃないの?
ただでさえ、理系は分が悪いから、今の日本じゃ

128 ：仕様書無しさん：04/06/12 12:42

商社辺りがインドや中国への仲介を担当して、ソフトウェア会社は７０％ぐらいあぼーん

俺は一生最新技術について行けるつもりだから、小規模フリーでやろうかな。
最近経理関連の本を買ってみたけど、思ってたより難しく無さそうだ。
腰を落ち着けて勉強すれば何とかなりそう。
もちろん本職とは比べものにならないけど。

129 ：仕様書無しさん：04/06/12 12:43

納品後には普通リファクタリングしないだろう。

130 ：仕様書無しさん：04/06/12 12:43

流れ作業でテレビやカメラのねじを締めてる奴らも同じこと思ってるんだろうなｗ

131 ：仕様書無しさん：04/06/12 12:45

>>130
内容がないよう

132 ：仕様書無しさん：04/06/12 12:47

http://ime.st/www.personal-media.co.jp/book/c/ansi.html
↑これ、最強

133 ：仕様書無しさん：04/06/12 12:54

何も仕事しなくて、それこそコーダーに徹してる奴が一番評価高いのが問題だな。

134 ：仕様書無しさん：04/06/12 13:00

>>133
そんなの本当にいるのか?
普通に考えても、それだと納期に間に合わねえじゃん

135 ：仕様書無しさん：04/06/12 13:02

納期に間に合わなくてもがんばってる奴が評価されるのは常識。

136 ：仕様書無しさん：04/06/12 13:03

>PGがSEを兼務するというのは、生産性問題の解決策だろう。
だったらやれば～
なんでやってないの？
会社がやらしてくれないなんて言うなよ～
会社だってホントにできる人なら任せるよ～
やらしてもらえないのは信用ないんだね～
(´,_ゝ｀)ﾌﾟｯ

137 ：仕様書無しさん：04/06/12 13:08

>>135
そんな甘い会社ばかりではないのが現実。つか、納期にも間に合わず、客と会社の
双方にダメージが及んでて、何の評価だよ。

138 ：仕様書無しさん：04/06/12 13:11

>>126
そうやって勝手にXPの話だと解釈するのはやめてくれ。
私が語っているのはテストファーストだ。XPじゃない。集合論を復習しろ。

「テストファーストだけでも実際に生産性が向上する」と言っているのに
なんで「十分な時間が無い」と反論する？
十分な時間が無いからこそ、テストファーストする必要があるんだが。

君は生産ラインの最後で不良品を取り除くと、それより前の工程での生産活動が
不良率分、完全に無駄になるという製造業の常識も知らないのか？

不良品（＝バグ）は、作ってから時間がたてばたつほど修正のためのコスト（＝時間）が増えていく。
当然、バグを作った直後にテストして発見して修正したほうが、最終的な生産性は高くなるんだよ。

テストプログラムを書くコストは、生産ラインで不良品検査体制を構築するコストと同じだ。
面倒かもしれないが、生産性を向上させるためには、やらなければならない（Must!）。

>>129
なぜそこで「納品後」に話を限定するのだろうか。
納品後にリファクタリングする必要は無いだろう。
普通は納品前にリファクタリングする。
コードがスパゲティ化して機能追加に時間がかかりすぎるようになる前に。

139 ：仕様書無しさん：04/06/12 13:13

>>138
＞>>126
＞方針の都合で納品後はやたらとリファクタリングするわけにもいかんのだが

140 ：PGがマネジメントを語って何が悪い：04/06/12 13:13

うっかり名前を入れ忘れた。見ればわかるだろうが、>>138は私だ。

141 ：仕様書無しさん：04/06/12 13:15

仕事して納期に間に合わせる：当然(評価±０)

納期に間に合わない：プログラマが悪い(コーダーへの評価±０)
そんなプロジェクトで残業する：がんばってるね(コーダーへの評価プラス)

142 ：仕様書無しさん：04/06/12 13:19

>>138
生産効率って言ってもなぁ、テストファーストが可能なのは、設計が固まり変更が起きない場合のみだろ?
そんな状況が、開発の初期段階で生じる様なら、誰も苦労しないんじゃないか?
面倒だと言うのは、初期段階じゃないからだと思うんだけどな。

手法も大事だが、もっと根本的に設計の早期確定が重要だと思うよ。

143 ：仕様書無しさん：04/06/12 13:24

>>142
×設計
○要求
だと思うが

144 ：142：04/06/12 13:27

>>143
んだな。もっとも、画面デザインレベルや、入出力部分の定義とか、概要設計
段階までは客との折衝がどうしても要る。

その意味では、設計も確定させておきたいけどね。概要レベルまでが確定して
いりゃ、後はこちらで何とでも料理できるわけで。

145 ：PGがマネジメントを語って何が悪い：04/06/12 13:31

>>139
「もしかしたら、方針のほうが悪いのではないか」と考えたことはあるかね？
残念ながら「動いているものには触るな」は、大昔の話だ。（今でもCOBOLなどにはあてはまるのだろうが、ね）

外部に影響が出ないことが保証されているリファクタリングが存在する。

プライベート変数を使用目的に合わせて命名しなおすのに、なんら問題は無い。
スペルミスはコンパイラによって報告されるだろう。

メソッドの中で使用しているアルゴリズムを置き換えたところで、
結果が変化しないことが保証されているならば、やはり問題は無い。
バブルソートをクイックソートに変えても、誰も困りはしないだろう。

にもかかわらず、リファクタリングの全てを完全否定するというのは非合理的だ。

テストがきちんと書かれていれば、「リファクタリングしてテストしてリリース」は
実現可能なことなのだ。

>納品後はやたらとリファクタリングするわけにもいかんのだが

悪い方針はそれ自体が生産性の制約になりうるという典型的な例だな。
昔に比べてコンピュータは速くなった。だが、テスト方針もリリース方針も変化しなかった。
故に生産性は向上しなかった。それは当然のことで、問題点は明らかだ。

もし方針を変更するつもりが無いというのであれば……君の会社の行く末に心から同情するよ。

146 ：仕様書無しさん：04/06/12 13:41

未然に防がれた危機に気付かなければ、危機を防いだ人が評価される事はない。
しかし、実際に起きた問題を収束させたとしても、収束させた人間が表特別評価
される事はない。　消防士が火事場で火を消すのは当然と思われている様に。

147 ：仕様書無しさん：04/06/12 13:48

>>124
そこまでヒドイとは思わなかった…
オフショア開発にかかわってたヤツが禿げたのも納得できるクオリティーだな

148 ：139：04/06/12 13:49

>>145
俺は>>126とは別人で、>>129は>>126に対してのレスだ。
リファクタリングに関してはあんたが間違っているなんて一言も言ってない。

149 ：仕様書無しさん：04/06/12 13:51

>>145
変数名くらいなら、開発環境によっちゃ、自動置換とかしてくれるのもあるし、
コンパイラが面倒見てくれるのかもしれんが、アルゴリズムはそうはいかねえ
だろ?

外部に影響が出ないと言い切れるのかねぃ。アルゴリズムまで変えちまったら、
その部分は新規設計と同じだと思うんだが。

信頼性を考えたら、危ないと思うんだがなぁ。

キミは入力ミスなどの人間性の問題を無視してねーか?
アルゴリズム変えた場合のエラーは予測するの難しいぞ。コンパイラが教えて
くれない場合すらあるしな。（間違っていても、そのままコンパイルが通る
場合だって無いとは言えない)

リファクタリングを否定はしないが、それは充分な時間的、人的余裕がある場合
の話だと思う。

150 ：仕様書無しさん：04/06/12 13:55

・・・リファクタリングって保守時のほうがメインだと思っていたぁよ
新規開発時にもやるの？。二度手間じゃないの？

151 ：仕様書無しさん：04/06/12 13:56

>>149
そんな時のためのUnitテストだろう。

152 ：仕様書無しさん：04/06/12 14:04

>>151
それ二度手間。そもそも、アルゴリズムなんてものは設計段階で確定させるもの
だし、後で交換するのは、設計段階で問題があった証拠。

見易く直したり、コメント入れたり、ムダな処理を削ったりするのは分るが、
アルゴリズムまで手入れるのなら、新規設計同然。

そんな状況で信頼性確保できるの?

単体テストにだって限界はある。結合させて初めて発生する問題もある。
自分の担当の前後左右も見ていないとドツボにはまるだけのこと。

153 ：仕様書無しさん：04/06/12 14:08

>>152
よく分かってないんじゃ。

154 ：109：04/06/12 14:09

テストケース・シナリオを作って、
実装もぜんぶ終わるまで仕様が変わらない
そんな幸せな現場で働きたい。
テストファーストで失敗したプロジェクトにいたので過剰反応なのは反省している。
製造業がどうたらって話はわざわざ言われなくてもわかる。

だが、テストファーストは一人で推進できるような代物ではない。
どうも>>138の言ってることは頭でっかちというか、本に書いてあることを
コピペしてるように見える。実践した結果があるのなら具体例も出してもらいたい。

あと、納品後のリファクタリングというのは言い方が悪かった。
納品後＝問題発生時のメンテナンスのみという形態であれば
コードに手を入れるべきではないだろう。
だが「動いているコードに手を入れるな」という古いルールを打ち破るのが
リファクタリングの出発点だったはず（違ってたらすまん）。
結果、リファクタリング前後で動作が変わってはいけないので
ここでしっかりとしたテストが必要になる。
じゃあどういうテストが有効か→テストファーストの原則
（テスト仕様を通るようにコードを書く）の議論へ。

テストファーストやリファクタリングは密接に関連づいているので
あえて「XP」という言葉で総称した。ちょっと乱暴だったかもしれない。

いろいろ言い訳がましいかもしれないが、私はプロジェクト全体について
口出しできる立場ではない。
だが、「方針のせいで動けない」のは社内政治の範疇なので
ここで議論するのはやめにしたいと思う。

155 ：仕様書無しさん：04/06/12 14:10

>>154
＞テストケース・シナリオを作って、
＞実装もぜんぶ終わるまで仕様が変わらない

XPでもそんなことは前提にしていないな。

156 ：PGがマネジメントを語って何が悪い：04/06/12 14:12

>>148
間違えてすまなかった。

>>149
入力に関する部分とロジックに関する部分の設計を分離しておくのは
ソフトウェア設計の基礎だと思っていたのだが。
君はユーザからの入力を、正当性検査もせずにロジック側で扱っているのか？
ソート・アルゴリズムの取替えさえ満足に行えない設計で、
本当に顧客の要求に耐えうるのか？リファクタリング以前の問題だな。

>それは充分な時間的、人的余裕がある場合

コードの重複、マジックナンバー、信頼性に欠ける車輪の再発明、GUIでのロジック実装、
意味を教えてくれない変数名、メソッド名、誤用された継承、インターフェイス、etc...

一度腐りきってしまったコードは、機能追加や改修にとても時間がかかるようになる。
時間的余裕が無いからと言い訳して、滅茶苦茶なコーディングを許容して、
みるみるうちにソフトウェアを腐らせてしまうのは君の勝手だ。

だが、私が小さな機能追加にまるまる一ヶ月かかると見積もっても、どうか驚かないでくれよ。
腐ったソフトウェアは、充分だったはずの時間をどんどん食い潰す。そうと知っていて放置したんだろう？

157 ：109：04/06/12 14:14

>>155
テストファーストとXPは別、という>>138の考え方に立つなら
テストケース作成時に仕様が固まっている必要があるだろうと思った。

もちろん実際そんなことはない。

他にも穴があったら指摘してほしい。

158 ：仕様書無しさん：04/06/12 14:23

>>157
テストファーストというのは開発の最初にテストを作るのであって、
プロジェクトの最初にテストを作る訳じゃない。
だから、テスト作成→開発→仕様変更→テスト作成→開発→・・・
となるのは仕方が無く、それでも充分工数や品質に貢献を
もたらす、ようだｗ

最初はプロジェクトメンバーに理解してもらえなかったり、慣れて
なかったりするが、これだけ知名度が上がればなんとかなるん
じゃないかな。

159 ：仕様書無しさん：04/06/12 14:24

ところで、一つ聞きたいのだが、

CVSやVSS等のバージョン管理ツール、xUnitに代表される単体テストツール、
MakeやAntなどのビルドツール、JlintやFindBugsなどの静的ソース解析ツールなど、

各種開発支援ツールを使いこなすことって、プログラミングスキルに含まれますか？

160 ：仕様書無しさん：04/06/12 14:24

実際、議論できるくらい考えてる奴ばかりなら何も問題ないんだよ

リファクタリングさせたらバグ作りこんだりするようなことも多いし
10人のプログラマに書かせたコードを自分で全部眺めて直すわけにもいかないし

「ちゃんとテストすれば」ってそんなの当たり前の話で、
そのために「ちゃんとしたテスト」を作れる人がほとんどいない

161 ：仕様書無しさん：04/06/12 14:25

>>159
含まれるでしょ。

162 ：仕様書無しさん：04/06/12 14:28

>>160
ちゃんとテストを作るのもプログラミングスキルの一つだと思う。
テスト作成のための本も何冊も出てるし、テスト自動化のツールも
いくつも出てる。

163 ：仕様書無しさん：04/06/12 14:31

PGがマネジメントを語って何が悪いの中の人はなんでそんなに偉そうな口調ですか？

164 ：仕様書無しさん：04/06/12 14:37

テストケースは要件定義をもとにして設計者とは別の人間に作らせなきゃおかしいだろ

165 ：仕様書無しさん：04/06/12 14:38

現実を見ずに語ってるから。

166 ：PGがマネジメントを語って何が悪い：04/06/12 14:38

>>157
仕様が大きく変わったら、またテストケースを書いて実装するんだよ。

メソッドA'のテストケースを書いて、メソッドA'を実装する。
（必要であれば、メソッドAとメソッドA'の結果が等しくなることを保証するテストケースも書く）
メソッドAを呼び出している部分を全て検索し、メソッドA'に取り替える。
念のためメソッドAの中にassert処理を埋め込む。（言語によって例外やexitなど、方法は変わる）

話を聞いていると、ここらへんはかなり誤解されてるみたいだな。

>>163
そのほうが楽しいからね。私が。

167 ：仕様書無しさん：04/06/12 14:45

assert書いて怒られました

なんだこの隠蔽体質…

そうか！　これがオブジェクト指向のカプセル化という奴か！

168 ：いかりや超透：04/06/12 14:48

正しいことをやりたかったら、偉くなれ

169 ：仕様書無しさん：04/06/12 14:48

>>159
プログラミングスキルというと大体、各種プログラム言語の仕様や
アルゴリズムの理解といった話になる。

どちらかというと、それはプログラマのスキルといったほうが正しいのでは？

170 ：PGがマネジメントを語って何が悪い：04/06/12 14:53

>>164
単体テストから検収テストまでを十把一絡げにテストと呼んでいるようだが、
ここで語られているのは単体テストのほうだよ。

各モジュールが仕様通りに動き、バグが無いことをブラックボックスで確認するテストだ。

その上で
>要件定義をもとにして設計者とは別の人間に作らせなきゃおかしいだろ
と言っているのかい？

製造業を見るんだ。
作った本人か、あるいはその次の工程の直前に品質検査（＝テスト）をして、
不良品を即座に生産ラインから取り除く体制になっているじゃないか。

そういう意味でのテストは、プログラマ本人が書いたもので充分なんだ。それだけで生産性は向上する。
どこまで出来たのかもはっきりし、進捗管理も格段にしやすくなる。

もちろん、結合テストや検収テストについては別の方法が必要になる。
SEが顧客の操作手順を再現してテストを考案したりすることもできるが、
最終的にはユーザを交えたテストが必要になるだろう。

ユーザの時間を確保して、集中的に密度の高いテストしてもらう必要がある。
さもなくば、顧客はソフトウェアが仕様を満たしていることを確信できず、
検収を嫌がるだろう。売上がその月の損益計算書に載せられず、利益は減り、
プロジェクトに関わる全員の評価が下がってしまうだろう。
まあ、こんな話題は板違いだろうが……要するに評価が下がるのだけは間違いない。

プログラミングスキルの中でも、テストはとりわけ重要なのだ。

171 ：仕様書無しさん：04/06/12 15:50

はっきり言って、顧客の評価なんてどうでもいいんだがな。

172 ：878：04/06/12 15:52

PGとSEを兼任という解決策というのは、だめＳＥを追い出すということだとおもうけど、
PGとSEの間のコミュニケーションコストをゼロにするという効果もあるのではないかともおもう。
優秀な人ならひとりでやってもらって問題ないけど、おっちょこちょいな人はチェック
機構を用意してあげないと困ったことになるのでコミュニケーションしないわけにはいかんね。
コミュニケーションしやすく、したくなるように如何に仕向けるか。
最近は、技術的なことよりもデマルコやワインバーグの方向が本質なのではないかと思ってしまう。

目標を定めずに作業をするのは効率が悪いだろう？
あれやこれや、行き先があいまいなままふらふらと。。。
テストファーストは小さな「目標設定」なんじゃないかとおもう。
その目標設定はユニットテスト通過という明確なものだ。
今日はここまでってテストを作ってがんばって終わらせれば
残業しないですっきり帰れるぜ。

173 ：仕様書無しさん：04/06/12 15:52

>>170 ちょっと補足してみます
大まかに開発工程を設計→製造→テストと考えます。
設計とテストはもう少し分けて時系列に並べると
1.欲しがっているものは何か分析、何を作るか設計
2.どうやって実現するか考える設計
3.製造
4.考えた通りにものができたか確認テスト
5.欲しかったものができたか確認テスト

4.は2.の検証、5.は1.の検証です。
んで、なかなか要求が固まらないとか、作ってみないと良く分からんとかの
理由で前段階が完全に固まってからでないと次やっちゃダメ(ウォーターフォール)
ってのは間違った方針であるとされ、
・単位分割してやる
・ペンキ塗りみたいに下地塗り→本塗りといった感じで繰り返す
方が良いとなってきてます。
例えば 1が3つに分けて考えられるとして
1→
　[1]2→3→4
　[2]2→3→4
　[3]2→3→4
→5
検証した結果、ちょっと手直しが必要となったら
1'→...
近年では2,3,4は一緒くたにして
設計時にテストを作ってから実装→動作確認する手法が薦められています(テストファースト)
ここはプログラミングスキルです。

蛇足ですが1,5は本来SEがやるべきところなんですが、
場合によっては2,4の延長でなんとかごまかす場合がよくあります(w
あるいはPGなのに1から5までやらざるをえないとか(w

174 ：仕様書無しさん：04/06/12 17:26

>はっきり言って、顧客の評価なんてどうでもいいんだがな。

あなたは給料がもらえない身分になって構わないわけでつね？(w

175 ：仕様書無しさん：04/06/12 17:35

>169
各種開発支援ツールを使いこなすことはプログラミングスキル

確かにプログラミングスキルはプログラマのスキルだがね。

176 ：仕様書無しさん：04/06/12 18:33

顧客の評価から、給料までは
風が吹いてから桶屋がもうかるまでと同じくらい離れてるわけでね。

もうけたいからって風を起こす桶屋は馬鹿だろ。

177 ：仕様書無しさん：04/06/12 19:24

>>176
確かこんな話だよな？

風が吹いてホコリが飛ぶ
↓
目にホコリが入って盲目の人が増える
↓
盲目の人は三味線を習って旅芸人になる
↓
三味線を作るために猫の皮が使われる
↓
猫が減って鼠が増える
↓
鼠が増えて桶がかじられる
↓
桶の交換サイクルが早くなり、桶屋が儲かる

実際に桶屋が儲かるかどうかはさておき、
この因果関係の連鎖を考え付いた奴は天才だと思うｗ

178 ：仕様書無しさん：04/06/12 19:35

無理があるな
普通、目にホコリが入ったぐらいで失明するかな？

179 ：仕様書無しさん：04/06/12 19:42

s/プログラマ/Sヨ/g
s/テスト/プログラミング/g
s/テスター/プログラマー/g

なぜ「プログラミング」は軽視されるのか？
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040531/145101/

#ちょっと無理があるかな？

180 ：仕様書無しさん：04/06/12 20:41

>>177
間違っているよ。
正しくは、s/盲目/○○○/g　です。

エセ文化人の言うことを守るのではなく、日本の文化を守ろうよ。

181 ：仕様書無しさん：04/06/12 21:12

>顧客の評価から、給料まで

勤め先がアボーンorもまえリストラ、とかを想像してました

182 ：仕様書無しさん：04/06/12 21:23

>>180
いちいち逆言葉狩りするやつもうざい。

183 ：仕様書無しさん：04/06/12 21:24

>リファクタリングさせたらバグ作りこんだりするようなことも多いし
>そのために「ちゃんとしたテスト」を作れる人がほとんどいない

最初からUnitテストに汁!
後で困らないから

184 ：仕様書無しさん：04/06/12 21:38

>173
誤解をしそうだから補足しとく(なんて親切なもれ)
>近年では2,3,4は一緒くたにして
>設計時にテストを作ってから実装→動作確認する手法が薦められています(テストファースト)
一気に全部やるのではなく小さい単位まで分割して、
分割した単位ごとに設計&テスト→実装確認、だ
ちょこっと書いてはテスト、だ

185 ：仕様書無しさん：04/06/12 21:40

>>184
効率悪そうだなぁヲイ。漢ならびしっとビッグバンテスト一発で決めろや。

186 ：仕様書無しさん：04/06/12 21:47

http://japanese.joelonsoftware.com/Articles/FiveWorlds.html

ソフトウェア開発には、しばしば交わっているがたいていは分かれている、5つの世界があると思う。その5つとは：

パッケージ
インターナル
組み込み
ゲーム
使い捨て

だと、

187 ：878：04/06/13 02:28

↑のとこであたらしいのを見つけたよ。

プログラムマネージャだって。
http://japanese.joelonsoftware.com/PainlessSpecs/3.html

188 ：仕様書無しさん：04/06/13 05:06

コーダーには、ＯＳやコンパイラがらみの処理を軽く見てる奴が多い。
その結果、中大規模アプリでは正体不明のバグを引き起こす。
あっちこっちで好き勝手にメモリーがらみの処理を行えば、
フラグメンテーションが起きるのは当たり前だし、
配列処理で巨大な処理を行えば
スタックオーバーフローなんてあっと言う間だ。

で、そうしたバグの正体を即座に推測できない奴が、
コーダーやＳヨなわけだが・・・

ハードがらみの処理は危険だから、ラップもせずに使うのはﾔﾒﾚ

189 ：仕様書無しさん：04/06/13 08:39

中国なら３０ﾏｿ以下
ベトナムなら２０ﾏｿ以下

上流工程なんか知らんと言ってるコーダー君は15ﾏｿぐらいの給料で
満足してもらわんとならんな。

190 ：仕様書無しさん：04/06/13 09:17

御用聞きは、基本的に相手の気分を害さない事しか言わないから、不興を買いにくい。
つじつまあわせを他人に丸投げしても罪悪感を感じない、正真正銘人間のクズ。

191 ：仕様書無しさん：04/06/13 09:22

>>188
> で、そうしたバグの正体を即座に推測できない奴が、

それできるやつは相当優秀だぞう

192 ：仕様書無しさん：04/06/13 09:30

推測したとて確認するし、それが真の原因なのか否かを実証する。
推測可能なスキルは絶対的に必要というわけではない

193 ：仕様書無しさん：04/06/13 09:38

ＰＭやＳＥって技術的なことにはノータッチというのが一般的なのでしょうか？
ユースケースやクラス図をＰＧが書いて会議のネタとして用意しても

ＳＥ「プログラムなら、お前らでレビューすればいいだろうが！」

全く技術的なことに興味を示さない。むしろ拒否する。
しかも

ＳＥ「プログラムだけじゃなくて、上流の仕事もしろ！」

ひとり、キレたＰＧが居て自宅謹慎になった。
辛いプロジェクトだ・・・

194 ：仕様書無しさん：04/06/13 09:57

>>193
ふむ、うちの職場のPMは、コーディングしてるぞ(笑)
正直、そのPGには同情する

195 ：仕様書無しさん：04/06/13 10:05

>>193
業務系ではよくあるパターン

196 ：仕様書無しさん：04/06/13 10:07

>>193
Ｈ系ではよくあるパターン

197 ：193：04/06/13 10:10

>>195 その通りです
>>196 その通りです（ｗ

198 ：仕様書無しさん：04/06/13 10:11

>>195
業務系うんぬんの分類はあまり関係ない。
実際、うちも業務系だが、SE自身のレビューはちゃんとしているうえに、PMが、
コーディングまで分担している。

199 ：878：04/06/13 14:20

おれはたのしい。おれはめぐまれてる。

200 ：仕様書無しさん：04/06/13 15:21

>>199
>>878ってなんのこ……ハッ！
あなた未来から来た人ですか？そうなんでしょう！

み、未来の画期的開発手法を御教授ください。
時間法とか色々あるのでしょうが、どうか是非！！！

201 ：仕様書無しさん：04/06/13 15:49

まあ、このスレ終盤になるのはせいぜい数ヶ月先だろ。
万馬券情報聞いたほうがいい。

202 ：仕様書無しさん：04/06/13 16:09

プログラミングスキルがあると判断された奴だけ、
設計が担当できるようにしてくれ。
コーディングもろくに出来ない先輩が詳細設計したので、最悪な事になってる。

203 ：仕様書無しさん：04/06/13 16:36

はははは。ありがちだ。よくあることだ。

だが誰もその状況を変えようとしない。

プロジェクトが遅れようと、デスマーチに突入しようと、億の単位の損失が出ようと、
会社は潰れず、解雇もされず、基本給が減るわけでもボーナスが減るわけでもない。

そういうものなのだ管理職とは。
不平不満に蓋をして、平穏無事に見せかける。

それだけだ。それだけが彼らの仕事だ。ははははは。

204 ：仕様書無しさん：04/06/13 16:38

>>203みたいな意識でいる管理者が多いから、うまくいかねえんだよな。

205 ：仕様書無しさん：04/06/13 17:35

>>191
ネタか？
あまりにもラベル低いだろをい。

206 ：仕様書無しさん：04/06/13 18:04

>ユースケースやクラス図をＰＧが書いて会議のネタとして用意しても
>ＳＥ「プログラムなら、お前らでレビューすればいいだろうが！」

えー、プログラムレベルのユースケースやクラス図は全く無意味だと思います

207 ：仕様書無しさん：04/06/13 18:23

>>206
そうかぁ？

208 ：仕様書無しさん：04/06/13 19:44

>>206
クラス図、オブジェクト図、コラボレーション図等、プログラムからは読み取るのに
時間がかかる情報はプログラムレベルで書いても良いと思う。ただしそれは外部仕様書
からは切り離して、ソースにくっつけるべきだけど。

でも、ソースにくっつけるべき図を会議でPMやSEに見せるのは反対。抽象度の高い
図ですら文句をいわれたら、転職を考える。

209 ：仕様書無しさん：04/06/13 23:47

>>194 >>198
PMが実務を担当しちゃうのはよくないと思うけどなあ。
もちろん、やろうと思えばできる人でないと困るけど。
ちゃんとマネジメント行き届いてる？

210 ：仕様書無しさん：04/06/13 23:51

>>209
問題ないと思う。つか、目の前に居すわってるんで、行き届き過ぎとも言う。

211 ：仕様書無しさん：04/06/14 00:22

>>210
10人以下のプロジェクトならPMがコーディングしてても問題ないかな。
それ以上だと、やってはいけない。
ＰＭ本来の仕事は、プログラマーとは別の視点で見る必要があるから
それなりの規模になったらＰＭに専念すべき。
切り替えが失敗して中途半端になる。

212 ：仕様書無しさん：04/06/14 08:03

>>211
同意。
最近読んだ『成果責任は誰にある？』によれば、上司は部下よりも長期的な仕事をしないと
組織は上手く回らないらしい。

その原則を破って上司が部下のレベルに降りていくと、短期的には作業する人が増えて
楽になるが、長期的には部下の仕事が滞るという結果になる。
逆に上下関係が多すぎても、誰の判断を仰いで良いのか分からなくなって同じ結果となる。
上下関係を正しく構築できれば、業務の効率はそれだけで倍以上になるのだそうだ。

これは自分の経験にも一致する。

213 ：仕様書無しさん：04/06/14 23:32

http://www.atmarkit.co.jp/news/200406/12/agile.html
「日本のITエンジニアは「プロジェクト管理のど素人」集団？」

ようはＰＧできないからマネジメント専門でやりたいということか。

214 ：仕様書無しさん：04/06/14 23:37

建築業界のゼネコン→設計士→大工みたいな構図に
するのは難しいだろうね。

うちらの業界って家電とか機械系からの流れが強いから
設計者と工場の組立工みたいな感じになりやすいのかね。

215 ：仕様書無しさん：04/06/14 23:41

>>213
このオッサンは目の前の聴衆に向かって
「つーかおまえら馬鹿杉」と言いたかっただけ

否定できないがね

216 ：仕様書無しさん：04/06/14 23:57

ＰＧスキル無しのＰＭ　→　ＰＧの嘘を見抜けず頑張った分だけ顧客に損害

217 ：仕様書無しさん：04/06/15 00:05

なんでこうコーダーちゃんは極端なんだろうな。

　ＰＧの中にはコーディングしかできないアホなコーダーがいる
　ＳＥにはコーディングさへできないアホがいる
　ＰＭにはちゃんとしたマネージメントができなアホがいる

どれも真。しかし
　ＰＧはアホなコーダーばかり
が違うように
　ＳＥはコーディングさへできないアホ
　ＰＭはマネージメントができなアホ
は違うのだよ

まぁ、コーダーには論理的に考えることができないから
理解できないのかもしれないが・・・

218 ：仕様書無しさん：04/06/15 00:14

＞クラス図、オブジェクト図、コラボレーション図

そんなものは打ち合わせには必要ないですね｡
むしろ、しっかりとかかれた機能仕様書、詳細仕様書が必要です｡
ですマーチになるような所はたいていそういうものがない。

219 ：仕様書無しさん：04/06/15 00:15

ＰＧスキルありのＰＭ　→　たとえ技術的に貢献しても評価対象外

220 ：仕様書無しさん：04/06/15 00:18

私は最近デスマってるプロジェクト3箇所の応援を経験しましたが、
共通する問題点は、信じられるドキュメントがまったくないということだ。
あと、デグレートチェックすらしないので、修正するたびにデグレードしてる｡
あきれたよ。

221 ：仕様書無しさん：04/06/15 00:19

コーダーを煽るしか能のないアホを締め出す最適なソリューションってないですかね？

っていうかきょうびコーダーなんているのか？

222 ：仕様書無しさん：04/06/15 00:22

最近、まともな日本語すらかけない奴が多い｡
SE、PG、PMですらそういう奴はいる。困ったもんだ｡

223 ：仕様書無しさん：04/06/15 00:23

プログラミング技術＝ドキュメント作成技術

224 ：仕様書無しさん：04/06/15 00:36

>>221
コーダーを煽るしか能のないアホにはそれ相応のアホコーダーがアサインされてんじゃないですかね。

225 ：仕様書無しさん：04/06/15 00:59

ウォーターフォールしかできないCOBOLerを218に発見しますた

226 ：仕様書無しさん：04/06/15 01:04

業務アプリの開発手法はウォーターフォールが最適

227 ：仕様書無しさん：04/06/15 01:04

>>225
は？
プロトタイピング揮発ならやったことはありますが｡
呼び名がどうあれ、まともなドキュメントがなければダメです｡

228 ：仕様書無しさん：04/06/15 01:14

まともな、というのがどこに行くかだよね。
無駄なドキュメントを書かすのは、工数の無駄と言うことを念頭に置いて欲しい。

229 ：仕様書無しさん：04/06/15 01:15

>>221
>っていうかきょうびコーダーなんているのか？

>>221

230 ：仕様書無しさん：04/06/15 01:17

>>226
いまどき、ウォーターフォールは無いでしょ。
そんな開発手法は予算的に汎用機でしか許されてないでしょ。

>>227
ていうか、UMLはドキュメントではないのですか？
お前、実は「UML」という単語を聞いたことないの？
いまどきUMLも知らないんじゃ、オフショア開発できないぞ。

231 ：仕様書無しさん：04/06/15 01:18

>>230
？？？
いつUMLのお話が？

232 ：仕様書無しさん：04/06/15 01:20

>>227
経験則を語っただけで「偏見に基づくキメツケを行う子供」がいるところなので
あまり過剰に反応することはありません。
正面切った反論がないのは、同意されたと思っていれば良いのです。

233 ：仕様書無しさん：04/06/15 01:21

オフショア開発って楽しそうだね
ttp://www9.plala.or.jp/pandanotasogare/dvd.html

234 ：仕様書無しさん：04/06/15 01:23

>>232
227みたいな馬鹿丸出しの発言によく同意できるな。
お前の馬鹿さ加減にも感心するぜ。

235 ：仕様書無しさん：04/06/15 01:23

>>232
了解しました｡
いきなり、関係ない話されても訳がわからんよ。
精神的に大丈夫なんでしょうか？

236 ：仕様書無しさん：04/06/15 01:25

>>234
私は頭が悪いので、私が語ってもいないことを、勝手に読み取る能力はありませんよ｡

237 ：仕様書無しさん：04/06/15 01:25

>>231
たどって行けば218にたどり着く。
218はUMLのことを仕様書ではないと考えているようである。

238 ：仕様書無しさん：04/06/15 01:25

本州以外はオフショアですか？

239 ：仕様書無しさん：04/06/15 01:26

基本中の基本であるプログラミングができないのに開発手法やドキュメントフォーマットのこと
考えるのが好きなヤツの心理はプロスポーツの熱狂的ファンに近いらしい。

240 ：仕様書無しさん：04/06/15 01:26

>>235
一人で自作自演してんじゃねぇよ。
馬鹿の上塗りﾊｽﾞｶｽｨ

241 ：仕様書無しさん：04/06/15 01:28

>>237
論理的能力に欠けているようですね。
打ち合わせに必要ないと言っているだけですが。

242 ：仕様書無しさん：04/06/15 01:30

茨城より北、岡山より西はオフショアです。言葉も通じません。

243 ：仕様書無しさん：04/06/15 01:30

「機能仕様書、詳細仕様書が必要です」と書いてるよね？

論理的思考の前に、日本語の勉強を始められたほうが良いのでは無いでしょうか。

244 ：仕様書無しさん：04/06/15 01:33

(1)クラス図、オブジェクト図、コラボレーション図　っていうのはUMLの一部。
(2)UMLは仕様書です。

そこらへん理解していますか？

245 ：仕様書無しさん：04/06/15 01:33

U　うんこ
M　まみれ
L　レディー

246 ：仕様書無しさん：04/06/15 01:34

>>226
ウォーターフォールでやってるところありますよ。オープン系で。
それ以外の開発手法だとドキュメント書くだけの人は居場所ないみたい。
で、一生懸命ドキュメント書いてるけど結局デスマーチです。

予算もないし納期も短いところで完璧なドキュメント書いてる余裕は
まったくなく、結局予想を超える確認・実装工数を取られ・・・。
しかも急いで書いてるから業務的にも矛盾があるが
ウォーターフォールなのでかなりあとでないと矛盾が判明しにくいようです。

まともなドキュメントが必須なら、今は、
ドキュメントを高速に大量生産してかつ正しいことを迅速に検証する方法が必要だと思います。
個人的には、ドキュメントが正しいことを迅速に検証するのは難しいとも思いますが。

247 ：仕様書無しさん：04/06/15 01:34

>>244
仕様書がいらないといつ言いましたか？

248 ：仕様書無しさん：04/06/15 01:34

>>235
許してやれよ。
意味を知らずにかっこよさそうな言葉を使いたかっただけなんだって。
生暖かく見守ってあげるのが吉

249 ：仕様書無しさん：04/06/15 01:35

>>243
お前頭悪いって。
>>237もお前か？「ＵＭＬが仕様書でない」というのはお前の頭だけに入ったノイズだからもう気にするな。

250 ：仕様書無しさん：04/06/15 01:37

>>246
ドキュメントが正しいか検証する能力がないのに、何故コーディングができるのでしょうか？

神のお告げ？それともデンパかなにかを受信してますか？

251 ：仕様書無しさん：04/06/15 01:38

業務系ならDB定義書だけで設計者の意図がくみ取れてしまったりする。

252 ：仕様書無しさん：04/06/15 01:39

お前もかなりの粘着だな。
一人でカキコして、別の自分に「許してやれよ」って諭すのはないだろ。
見ていて恥ずかしいぜ。

253 ：仕様書無しさん：04/06/15 01:40

>>250
勘で作ってるんでしょ？
こえーよ。

254 ：仕様書無しさん：04/06/15 01:40

>>249
お前、いつのまにか考え方変えてるね。
恥ずかしくないのか？

255 ：仕様書無しさん：04/06/15 01:40

俺も仲間に入れてくれ、何の話してんの？

256 ：仕様書無しさん：04/06/15 01:40

>>250
ワープロ文書はコンパイルエラー出ないし厳密なつじつまチェックは非常に困難。
バカにはなおさら困難。

257 ：仕様書無しさん：04/06/15 01:41

もう俺ねむたいんだけど、そろそろ解放してくれないかな？
粘着さんよ

258 ：仕様書無しさん：04/06/15 01:42

>>256
プログラムはもっと困難だろ？

259 ：仕様書無しさん：04/06/15 01:42

>>255
粘着さんが伝統的仕様書とUMLの狭間で、伝統的仕様書に固執している姿を拝見するスレです

260 ：仕様書無しさん：04/06/15 01:43

粘着さんﾏﾝｾｰ

261 ：仕様書無しさん：04/06/15 01:45

粘着さん怖いよ～

262 ：仕様書無しさん：04/06/15 01:46

ヒヤリングした内容をUMLに起こしてみて、どういう会社だここは？
ってなることがたまにある。

263 ：仕様書無しさん：04/06/15 01:46

粘着さんが消えちゃった。
あぁ、寂しいなぁ。
それでは、おやすみなさい。

264 ：仕様書無しさん：04/06/15 01:47

>>258
「コンピューターに対する命令として妥当かどうかを検証」するのはコンピューター言語の場合はコンパイラがチェックしてくれる。
ワープロ文書の場合はワープロ屋の目作業。プログラマの仕事じゃねー。

265 ：仕様書無しさん：04/06/15 01:50

>>264
自分から世界を狭めてどうする。楽しいこともいっぱいあるよ。

266 ：仕様書無しさん：04/06/15 01:50

>>264
コンパイルしただけで、不良がなくなるのか？

267 ：仕様書無しさん：04/06/15 01:50

>>262
現場の人間はシステム化に反対しているというケースなのでは？
ぜひ気合を入れて「誰が何したか」キッチリ記録に残るシステムを作ってあげてね。

268 ：仕様書無しさん：04/06/15 01:54

>>267
それあるね。奇妙なことに、最初は協力的でも途中から突然否定的な態度を
とるような人が必ず現れる。

269 ：仕様書無しさん：04/06/15 01:55

>>266
「コンパイルがとおる」＝「コンピューターに対する命令として妥当」
「コンピューターに対する命令として妥当」≠「不良がなくなる」

270 ：仕様書無しさん：04/06/15 01:58

ログ機能に関する要件だけ経営者層からでてるとかｗ

271 ：仕様書無しさん：04/06/15 02:01

ヒアリングに比べて、機能要件を絞り込む段階では
内部の対立構造が見えすぎて怖いよね。

272 ：仕様書無しさん：04/06/15 02:26

>>222
ていうか、むしろこの仕事やると日本語下手にならねえか？
言語野破壊されんのかな。普通にしゃべれなくなるような気がするんだけど。

273 ：仕様書無しさん：04/06/15 06:58

ハハハハ　お前ら楽しそうだな。　つーか結局、デスマ好きなんだろ？

274 ：仕様書無しさん：04/06/15 08:18

なんか煽りに釣られて無駄にレス消費してるみたいだけど、
要するに日本の技術者は馬鹿すぎ。

ほとんどあらゆるデスマーチに共通している点は、
広義のドキュメント（UMLやメモ書き等も含む）も作らずにチームで開発できるわけないのに、
本当に全く何のドキュメントも無しにプログラミング工程を始めていること。

「動けばいいじゃん」という致命的に馬鹿な思考回路になってるんだろうね。
無能PGの脳内ではいざしらず、実際に顧客の考え通りに動くわけがないんだけど。

結局、顧客の要件定義書も無い、仕様書も無い（＝結合テスト不可能＝永遠に未完成）、
モジュールの分割、共通化（オブジェクト指向ならクラスの設計）も無い、
効率の良い開発ツールも無い（現実を無視してまで導入を拒絶する無能管理職がいる）、
バージョン管理も無い（＝デグレしまくり）、そして最悪なことに危機認識も無い。

これだけ何も無ければ、生産性は地に落ちるのがあたりまえ。
高スキルの職人PGは担当範囲を終わらせてくれるように見えるが、
そもそも仕様が無いのだからそれは完成ではない。顧客の一言で全部振り出しに戻る。

そして納期。

仕様書が無いまま結合テスト敢行＝要するに全部顧客が目視確認
＝テスト工数天井知らず→顧客の考えと違う部分が見つかり開発続行
＝絶対に完成できない。

分かっているのに変えられない。分かっているのに変えようとしない。
要するに日本の技術者は馬鹿すぎ。

275 ：仕様書無しさん：04/06/15 08:24

ドキュメントを作っても、ダメなプロジェクトはダメ。

276 ：仕様書無しさん：04/06/15 08:41

>>275
仕様書を書いてもダメなプロジェクトには、レビューが無い。

要するにダメな仕様書に突っ込みを入れるという状況が無い。

１．仕様は論理的に矛盾
２．既存技術では仕様実現は不可能（まだ研究段階の技術、等）
３．判断のための調査工数が不足
４．実現は可能だが工数が不足

少なくともこのレベルの突っ込みが技術者側から出なければ、糞仕様がまかり通る。
そんな仕様書は、あっても存在しないのと同じか、それより悪い結果しか生まない。

「まともなドキュメント」を作れないプロジェクトというのは、常に失敗するのさ。

277 ：仕様書無しさん：04/06/15 08:46

>>274
技術者がというより管理者と経営者がではないのか？

278 ：仕様書無しさん：04/06/15 09:21

>>277
いいや。経験上、デスマーチの最大の原因は現場で作業している技術者だよ。
管理者や経営者がいくら馬鹿とはいえ、納期に間に合わないことは本意ではない。
間に合わせるための合理的な手段を教えてもらえれば、利益のことを考えてちゃんと判断する。

「M月D日までにツールAを導入しないと、このプロジェクトの進捗は停滞します。
ツールA無しにこの工程を行うのは現実的ではありません。ツールAが無しで
作業したなら、納期に間に合わないことは保証します」
と進言されて、全く動かない管理者はいない。
動かなかったら、自分のせいでプロジェクトが遅れたことになるからだ。

しかし、技術者は違う。
彼らは技術的には優秀であっても進捗のことなど本当に何も知らないし、知ろうともしない。
自己満足のために後の工程を犠牲にしたりする。設計を完璧にしようとして、テスト工数を
全て削ることもざらだ。しかも、管理者への報告では無意識に嘘をつくこともある。

「プログラムはほぼ完成しました。後はテストだけです。すぐ終わります」

しかし、手動・目視のテストにプログラミングと同じくらいの工数が掛かることを、
ほとんどの技術者は全く自覚していない。

技術者はプロジェクトの進捗を軽視し、あろうことか利益に至っては眼中に無い。
だから現場に危機意識が育たない。管理者はあいまいな嘘の報告を受け取って安心している。
管理者からの報告を受けて、顧客と経営者は納期までに終わると信じている。

要するに日本の技術者は馬鹿すぎ。

279 ：878：04/06/15 09:25

はじめから仕様書かっちりな仕事なんてしたことない。ラフなやつを元に作りながら固めていく感じだ。ひとりPJだけど。

280 ：仕様書無しさん：04/06/15 09:47

普通のドキュメントは動かない。
ゆえに、動作の検証など出来るはずもない。
それならコードに落とせる UMLの方が何億倍もマシだ。

コードは動く。
Unitテストも書ける。
故に、動作の検証が出来る。

これだからコードの書けないSﾖどもは。

281 ：仕様書無しさん：04/06/15 09:51

>>278
総論は支持するが。
各工程毎の成果物の検証をしない／できないという管理者の存在のほうが本質的な問題ではないのか。
成果物の検証をしないいうのは、品質管理が存在しないと同義であって、工期管理やコスト管理の不在より
（品質が目に見えないという特性を持つが故に）性質がわるい。
「管理者に管理手法を教育するべきだ」という改善案は出せるが、あなたの改善案は何なのか。

282 ：仕様書無しさん：04/06/15 09:51

プログラミングを知らないコーダーをいくら集めてもプログラムが完成しないように、
プロジェクトマネジメントを知らない技術者をいくら集めてもプロジェクトは成功しない。

故に、優秀なPMが一人投入されてもデスマーチは解決しない。

283 ：仕様書無しさん：04/06/15 09:58

>>281
「技術者に管理手法を教育するべきだ」

284 ：仕様書無しさん：04/06/15 10:07

>>278
274はﾌﾟﾛｼﾞｪｸﾄ全体の管理手法のまずさを指摘している。
それは現場の技術者が一存で決められるものではないでしょ。
それで全面的に技術者だけのせいにするのは上に甘い考えだよ。

285 ：仕様書無しさん：04/06/15 11:00

>プログラムはほぼ完成しました。後はテストだけです。すぐ終わります

ここがおかしい。
1)プルグラマがやるテストならプログラミングと同時に終わってるはず
2)納品前の検証レベルのテストなら、プルグラマが検証できるはずが無い

286 ：仕様書無しさん：04/06/15 11:12

>>278
誰が責任を取るのかはっきりしてなかったり、上層部で責任のなすりつけ合いを行っている
とこも多いぞ。下手に動くと責任取らされるから動かない奴も多いし。

・タスクの優先順位を誰も指示しない(指示できる人間がいない)
・「新しい人員投入→疲れたら交代」を繰り返してるので、１ヶ月ごとに方針が変わる
という末期的症状なプロジェクトもあるしな。

287 ：仕様書無しさん：04/06/15 11:54

実際、勤め先がアボーンとか、もまえリストラ、とか普通に思いつくけどなぁ

>技術者はプロジェクトの進捗を軽視し、あろうことか利益に至っては眼中に無い。
>だから現場に危機意識が育たない。

本当？バイトとか派遣とかぢゃないの？

288 ：仕様書無しさん：04/06/15 12:56

>普通のドキュメントは動かない。
>ゆえに、動作の検証など出来るはずもない。
>それならコードに落とせる UMLの方が何億倍もマシだ。

もまえ、逝ってる事がよくわかんねーぞ
どっちも結局コードにしないと検証不可能だろが

289 ：仕様書無しさん：04/06/15 13:11

>>288
UMLのファイルをコードに変換するメカニズムがあるらしいんだ。
#それが可能だとしてもUMLがソースと呼ばれることになるだけなんだけどね

290 ：仕様書無しさん：04/06/15 13:15

ﾊﾞﾗﾝｽの問題だな。
利益「だけ」しか考えてないと三菱自工やみずほになる。

291 ：288：04/06/15 13:29

>289
そーすると、マシン語(二進数、16進数)→アセンブラ→高級言語
に続く次のプログラム言語になるって事?

292 ：仕様書無しさん：04/06/15 16:14

>技術者に管理手法を教育するべきだ

"手法"ではダメだな。まず考え方を身につけさせないと

293 ：仕様書無しさん：04/06/15 16:26

>278
管理者や経営者が馬鹿なので、税所から間に合わない納期で始まる。
そもそも間に合わせる合理的な手段は存在しないのに、捕らぬ狸の利益のことを考えてちゃんと判断する。

間に合わなかったら、技術者のせいでプロジェクトが遅れたことにすればよいからだ。

しかし、技術者は違う。
彼らは技術的に可能であっても無理な納期のことなど本当に何も言わないし、思いつきもしない。
実現のために無茶な納期を犠牲にしたりする。設計を完璧にしようとして、テスト工数を
延長することもざらだ。しかし、管理者への報告では無意識に嘘をつくこともある。

294 ：仕様書無しさん：04/06/15 16:38

>290
そうかな?
利益「だけ」考えてれば、自らの首を絞めるまねはしないだろ。

295 ：仕様書無しさん：04/06/15 17:08

>>294
みずほも三菱もそれが利益になると信じてやった結果があれだ。
人間の予測能力なんて限界がある、というかたいしたｼﾛﾓﾉではない。
危険なのは自らの「利益になる」という判断を盲信することだな。

296 ：仕様書無しさん：04/06/15 17:15

>>294
議論の対象を「利益の内容」に言い換えるだけで、
根本的には何も変わっていないよね。

297 ：仕様書無しさん：04/06/15 19:03

目先の利益と継続可能な利益は違う
個人やインナーサークルの利益と、組織益や社会益は違う

298 ：仕様書無しさん：04/06/15 19:52

技術者は利益より自己満足を追及する傾向がある

・納期に遅れても納得いくものを作れればよい
・納期に間に合って品質もOKでも、自分がつまらない仕事はやりたがらない
・とりあえず面白ければいいという学園祭的達成感

技術力向上と知的好奇心はかなり関連あると思うので
上記傾向が必ずしもまずい訳じゃないのだが、それを優先するあまり
他のこと（利益etc）をまったく計算に入れない、オタク的な狭い考えの人が多い。

結論：やっぱりデスマ好き。

299 ：仕様書無しさん：04/06/15 19:54

目先の利益に囚われすぎるのもどうかと思うぞ。

300 ：仕様書無しさん：04/06/15 19:59

生産工場で仕事をしている技術者の方々は
「品質と納期が全てであって、利益のことなぞ全く考えない」
らしい。利益を考えるのは経営側のテーマであるのだそうだ。

301 ：仕様書無しさん：04/06/15 20:06

客から、システムに機能追加の依頼があったとしよう。
この依頼を客の満足の行く形で完遂できれば、確かに一時的に利益は上がる。
しかし、機能を追加することはシステムに新たな制約を付け加えることとなる。
さらに悪いことに不具合の引き金となることも十分考えられる。

営業は受けろと言い、技術屋は他の方法でカバーしろと言う場面はよくあるな。

302 ：仕様書無しさん：04/06/15 20:16

営業は、ある意味同じ仕事をチャレンジに見せる能力が大事かも。
「こんな簡単な仕事だから３ヶ月でできるよね」より
「普通なら半年かかるけど申し訳ない、３ヶ月でできないか、お願いする。」
の方が良かろう、もちろん実際の納期は９ヶ月だろうけど。

303 ：仕様書無しさん：04/06/15 20:21

・納期に遅れなければ顧客が納得できなくてもよい
・納期に間に合って品質もOKでも、自分が目立たない仕事はうけてこない
・とりあえず規模がでかければ良いという男根的達成感

営業って

304 ：仕様書無しさん：04/06/15 20:42

兵隊も戦略を考えて動けとかいうつもりか。

305 ：デブお断り：04/06/15 20:45

今時は司令塔が現状把握できないから兵隊がスマートになる方向

306 ：仕様書無しさん：04/06/15 20:56

だからこそ、これまでの仕事はきちっとライブラリ化
しておけと何度も何度も言ってるだろうに。
これだけで、バグの発生率はかなり下がる。
次の仕事だぁ！？引き継ぎに時間がかかると言っとけ。

307 ：仕様書無しさん：04/06/15 20:57

スマートな兵隊が絶望的な戦線に残るとも思えないのだが

308 ：仕様書無しさん：04/06/15 21:15

>>278
管理者が馬鹿なだけじゃねーか。

309 ：仕様書無しさん：04/06/15 22:00

>>308
278が馬鹿なだけだろ

310 ：仕様書無しさん：04/06/15 22:05

>>278
ネタだと思いたいが・・・。

まず、自己満足だとか、うかがい知れない他者の内面にすべてを帰着させる
その論法はやめなさい。何の足しにもならない。本当にそうなのか証明できないし、
双方が自己満足による欺瞞を主張しだして水掛け論になる。
だいたい顧客にもそんな説明できないでしょ？

次に、うその進捗が問題の主原因なのだとしても、それをわかっていながら、
結局何の対策も採っていないと顧客にばれたらそのＰＭは間違いなく外される。
実際、成果の度合いを推し量るのは難しく、嘘でなくても間違いはある。
それなのに個々の担当者の自己申告による進捗率でやっていたら個人差がでて当たり前。
マネジメントで真っ先にやるのが成果・進捗の評価を外部化すること。
ＰＭの仕事ってプロジェクトの状態を客観的に捉えることにほかならないわけだから、
作業者に実感をヒアリングすることはあっても、その総和をもって全体の進捗にしたりしない。
そんなものに何の保証もないことは自分で述べているのだからわかるでしょ？

うそをつかれて困るとかそんなレベルで管理を語らないように。

311 ：仕様書無しさん：04/06/15 22:12

なんでどいつもこいつも決めつけ口調ですか？　自分の現場が全てですか？
どの例も（レベル低いとはいえ）ありえる話だと思うんだが…。

そういう視野の狭さからまず直したほうがいいんじゃないの？

312 ：仕様書無しさん：04/06/15 22:23

>>279
>はじめから仕様書かっちりな仕事なんてしたことない。
そりゃそうだろう。かっちりした仕様書は開発者間の情報伝達のために作るものではないのだから。
悪意を持った人間（客側・開発側双方に存在しうる）にかき回されないようにするために作成されるのだ。

313 ：仕様書無しさん：04/06/15 22:38

仕様書は悪意を持った人間によってかき乱すためにあるんですよ。
仕様変更って知りませんか？

314 ：仕様書無しさん：04/06/15 22:39

>>271
>ヒアリングに比べて、機能要件を絞り込む段階では
>内部の対立構造が見えすぎて怖いよね。
システムの作りようによって自分が「指示する人」になるか「指示される人」になるわけだから当事者にとっては大問題。
そういう場合は「指示される人」が「指示する人」を選べるようなシステムにできればいいのにと他人事ながら考えてしまう今日この頃。

315 ：仕様書無しさん：04/06/15 22:51

>>313
よくそんなつまらないこと書き込む気になれますね
今後の展開、オチとも全く期待がもてませんｗ

316 ：仕様書無しさん：04/06/15 22:56

まあなんだかんだ行って大半の現場は賽の河原なわけで。

積むのがプログラマ、崩すのがエライ人。

317 ：仕様書無しさん：04/06/15 23:00

もはや業務系システム開発の失敗が許される時代じゃないんだが…

318 ：278：04/06/15 23:04

大漁だな。

319 ：仕様書無しさん：04/06/15 23:07

いや、許しまくりだろいまだに

320 ：仕様書無しさん：04/06/15 23:23

プログラミングスキルのない素人ＳＥのみなさんに
いままでどんなヘマやらかしたのか書き込んで欲しい。

321 ：仕様書無しさん：04/06/15 23:38

プログラミングスキルが評価されないと，高度なプログラミングスキルを持った人間が育たないってことでしょ。

322 ：仕様書無しさん：04/06/15 23:38

>>320
プログラミング初心者の外注に、上級者だと売り込まれて見抜けずに
プロジェクトを潰しました。

323 ：仕様書無しさん：04/06/15 23:40

>>322
ありがち。

324 ：仕様書無しさん：04/06/15 23:44

>>322
まず最初にバグ対応させてＰＧの力量をみるべし。次の人どうぞ。

325 ：仕様書無しさん：04/06/15 23:46

最近、コーディングの仕事がほとんどなくなってきたよ。
要求分析、見積もり、外注管理、スケジューリング、まーあんま面白れー仕事じゃねーなー

326 ：仕様書無しさん：04/06/16 00:05

仕事があるだけ、ありがたいと思わなきゃね。

327 ：仕様書無しさん：04/06/16 00:17

下見てどーすんだバカ

328 ：仕様書無しさん：04/06/16 00:34

ここにいるコーダー君達は、自分達がどれぐらいプロジェクトに
貢献しているか理解しているのだろうか？
自分がいるためにどれぐらい儲けがでるかを。

理解していないから、これだけ大口が叩けるんだろうな。

329 ：仕様書無しさん：04/06/16 00:38

>328よりは・・・

330 ：仕様書無しさん：04/06/16 00:49

ここで講釈たれてないで現場で言えば良いのに
言えないか現場じゃその辺にいるその他大勢の使えない人たちだもんねｗ

331 ：仕様書無しさん：04/06/16 00:56

>>328
椅子に１ヶ月座っているだけで人月の実績になるんだよ。
働きたいヤツだけ働いてりゃいいんだ。
俺はテキストブラウザで遊び放題。
テキストブラウザなら、2chで遊んでも顧客には見破られません。

332 ：仕様書無しさん：04/06/16 00:58

まあ大半の奴は自分が替えの効く人間であることを否定したいだろうな。
しょうがないなプライド高いし。
プライド無い奴もあてにならんので嫌だけど。難しいな。

333 ：仕様書無しさん：04/06/16 09:48

>>325
PGからSEにクラスチェンジしました。
営業の売り出し文句が変わりました。

334 ：仕様書無しさん：04/06/16 10:09

>>325
部下のコーディングを見て、修正したりはしませんか？
部下がつかないような会社なら、転職をお進めします。

335 ：仕様書無しさん：04/06/16 10:24

>>325,>>333-334
で、実際に転職すると、
飼っていたPGに逃げられたと、
このスレがにぎわうと。

正しいプログラマの飼い方
ttp://pc5.2ch.net/test/read.cgi/prog/1068218328/l50

まあ所詮は人売り屋だしな。
IT業界や自分の将来を考えるなら、
そこそこの企業に入った方がいいぞ。

336 ：仕様書無しさん：04/06/16 21:21

>>331のように正直なのはすごく好感が持てる。
きっとできないことはできないと言える人物なのだろう。
この業界にはできないことをなかなか白状しないヤツが非常に多い。
引き受ける時点で途中で投げ出す決意を固めている。

337 ：仕様書無しさん：04/06/16 21:56

>>1-336
>優れたプログラマへの評価はもっと高くあるべきなのではないでしょうか。
優れたプログラマはな。
おまえらなんて愚痴だけが取り柄の下等プログラマじゃん。このアル中どもがっ！

338 ：仕様書無しさん：04/06/16 22:09

>>337はエスパー

339 ：仕様書無しさん：04/06/16 22:20

>>331のような奴も>>336が書いてるような奴も不要です。
ゴミ箱に捨てましょう。

340 ：仕様書無しさん：04/06/16 22:21

>>336
自分とその周りがレベル低いからといってそれで業界を語られても。
単にあんたが嫌われてるだけなんじゃ・・・。

341 ：仕様書無しさん：04/06/16 22:29

アル中なのか。
酒少ない奴が多いと思ってたが。

342 ：仕様書無しさん：04/06/16 22:44

自らアルコールに溺れて脳細胞を破壊するPGは負け組。
旨い酒を上司に奢ってもらってたまに飲むPGは勝ち組。

343 ：仕様書無しさん：04/06/16 22:46

奴隷語録(1)
旨い酒を上司に奢ってもらってたまに飲むPGは勝ち組。

旨い酒を上司に奢ってもらってたまに飲むPGは勝ち組。

さあ、みなさんご一緒に

旨い酒を上司に奢ってもらってたまに飲むPGは勝ち組。

344 ：仕様書無しさん：04/06/16 22:47

上司と飲んで楽しいやつなんているのか？学生の妄想か？

345 ：仕様書無しさん：04/06/16 22:58

>>338
それは338がアル中ということ？

俺の周りはデスマ中の方が多そう。
hoge1[i].hoge2[j].hoge4[i+j+1].hoge3_1[i+j+k-2].hoge3_2[u*v].（以下改行無しで画面幅x2.5くらい）
と言う感じのコードを21時や22時にガリガリ書いてる。

頼むから寝てくれ(´д`;)

346 ：仕様書無しさん：04/06/16 23:11

できの悪い人達を残業責めで虐待しているのは経営者なのだ。
できる人に敵意を持つのはお門違いなのだ。

347 ：仕様書無しさん：04/06/17 00:47

>>345
後でソースを見直すと、
ポインタや参照を使った方が10倍以上は早かったと、
無茶苦茶後悔しそうなソースやね。

348 ：仕様書無しさん：04/06/17 00:50

PGは下戸が多いと思うんだが

349 ：仕様書無しさん：04/06/17 02:06

>>348
まぁ、飲む機会がないから慣れてないのでしょう。
合コンさへ一度も行ったことない奴等の度合いが多そう。

350 ：仕様書無しさん：04/06/17 02:30

>>349
いったことあるけど、話下手ですんまそん。面白い話題提供できません。

351 ：仕様書無しさん：04/06/17 06:58

>>350
会話もせずに、ずぅ～っと黙りこくってる奴もいるよね。
そういうのって失礼だと思います。
ならば最初から来なければいいのに。場が微妙な雰囲気に
なって他の人達に迷惑なんですよね。

ちなみに。
プログラマーの人ってコミニュケーション能力が一般よりも
劣る人が多いですよね。
一部の例外的な人を除いて、そういう人はコンピュータとの
コミニュケーション能力も低いように見えます。
一方的で独善的で、特定な部分にこだわった偏執的で。
しかし、当人はコンピュータとのコミニュケーションが上手いと
勘違いしている。長い時間相手にしていれば上手いわけでは
ないのに。最悪な人は、独占欲まで持ってたりする。

人間相手のコミニュケーションとコンピュータ相手のコミニュケーション
は重なる部分が多いのに。ましてや、ＰＧならば仕様書の
確認等の対人間相手のコミニュケーションは必須。
コンピュータ言語に拘ってばかりいないで、もうちょっと
コミニュケーション能力を磨けよ。

352 ：仕様書無しさん：04/06/17 09:07

と、PGの業務とほとんど関係ないMS-Office系アプリケーションが
上手く使えることを自慢したい年頃の>>351が申しておりますｗ

353 ：仕様書無しさん：04/06/17 09:15

>>351
>人間相手のコミニュケーションとコンピュータ相手のコミニュケーションは重なる部分が多いのに。
どこが？

354 ：仕様書無しさん：04/06/17 09:47

>>353　
命令して、その善し悪しを判断せずにそのまま実行するところ。

355 ：仕様書無しさん：04/06/17 10:09

さすが部下にロボトミーを施している上司は言うことが違う。

356 ：仕様書無しさん：04/06/17 11:08

コンピュータ相手のコミュニケーションという発想自体がオタク臭くて気持ち悪いが。
オタクが多いと言われてるPGでも、そんなこと思いつく奴はめったにいないぞ。

357 ：仕様書無しさん：04/06/17 11:51

誰が作っても、大して変わらないコードってのが問題じゃないの？
見やすいってはあるけど、作っててつまんないんだよな
実行速度よりも統一性。分かっちゃいるけど、個性を出したい。
そんな俺は　ダメプログラマーorz

358 ：仕様書無しさん：04/06/17 11:51

エロゲのしずぎです

359 ：仕様書無しさん：04/06/17 12:10

インターフェイスやエラー処理等は統一されてないと困るが、
実装方法に関しては千差万別だぞ。

つーか、コピペでバブルソートやるくらいなら、関数ポインタとqsortを使ってくれと切実に思う。

・・・・・・テストでデカイデータ流してて、いつまでたっても終わらないなーと思って
ソースを見てみたらこれかよ。まったくよぉー。

360 ：仕様書無しさん：04/06/17 12:47

ソースレビューもしないででかいテストデータ流すアフォ

361 ：仕様書無しさん：04/06/17 12:57

>>357
禿銅

でも、世の中というのは「アホを切り捨てないで使っていかなければならない」ので
そうするより他ないんだよ。諦めろ。

日曜大工でシェアウェアでも作って一発当てたら？

362 ：仕様書無しさん：04/06/17 13:12

でも、誰が作ってもそれほど変わらないｺｰﾄﾞってのは、
保守性も高いし、あとの手間考えると、やっぱ意味があるよ。
漏れは将来の自分のためにもそう言うｺｰﾄﾞ書くように心がけてるよ。
家で趣味のｺｰﾄﾞ書くときもね。

363 ：仕様書無しさん：04/06/17 13:29

>>359
ハァ？
プログラムなんて動けばどうでもいいんだよ。
実行速度なんてもんにこだわるなんてアホのすることじゃん。
まったく、これだからヲタクはキモイよねw

364 ：仕様書無しさん：04/06/17 13:46

誰が作ってもそう変わらないコード書くなら別にいいんだよ。
バブルソートなんて変なコード書く奴がいるから問題になる。

365 ：仕様書無しさん：04/06/17 14:30

>>363
お前の作ったSQL見直してろ

366 ：仕様書無しさん：04/06/17 14:32

【プログラミングスキルが高い人】
標準ので提供されている関数やクラスをうまく再利用したり、言語の
定石に従って書くことが多いので、スキルが高い人同士のコードは
スタイルに若干の違いはあれど、大体似たコードになりやすい。

【プログラミングスキルが低い人】
ネットや既存のコードからの切り張りになりがちなので、同じプログラム内
でもスタイルの統一がとれておらず、意味不明なコードになりやすい。
標準で提供されている機能を自作しては、悦に入っていることもしばしば
見受けられる。無論、彼らの生み出すコードはカオスそのものである。

367 ：仕様書無しさん：04/06/17 15:50

バグを出さないように書かれた
簡潔なコードが一番良いね。
まあ、速度に関してはケースバイケースだから、
何も言わないけど。

368 ：仕様書無しさん：04/06/17 16:02

プログラミングスキルの高さをアッピールする良い方法なんかない？

369 ：仕様書無しさん：04/06/17 16:06

誰でもできるような仕事をしてる奴は、誰でも読めるようなコードを書けってことだ。
誰でもできるような仕事をしている奴が、「スキルを評価しろ」とか寝言を言うなってことだ。

370 ：仕様書無しさん：04/06/17 16:09

>>368
ループじゃない？結構あそこはセンスが見える

371 ：仕様書無しさん：04/06/17 16:41

>>370
そんな小さな話かよ・・・・

372 ：仕様書無しさん：04/06/17 16:42

>>368
自分からアピールしなくても自然に評価されるような高いスキルを身に付ける

373 ：仕様書無しさん：04/06/17 17:17

>>368
スキルの低い奴をこき下ろす

374 ：仕様書無しさん：04/06/17 17:25

>>369
何度も同じことを言わせるなよ。
「だれでもできる」ってんならﾏｸﾄﾞﾅﾙﾄﾞのﾊﾞｲﾄ女子高生に
時給800円でやらせてみろや。

375 ：仕様書無しさん：04/06/17 17:26

モジュールの概念をまともに知っているかどうかで、
関数の書き方は、かなり違ってくるぞ。
ただ、中途半端に知ってる奴がモジュール化すると、
ろくでもない事になる場合が……

376 ：仕様書無しさん：04/06/17 17:29

>>368
スキルが高い奴が失敗したときにフォローに入って問題を解決する。
無論、そいつが失敗するように罠を張る必要があるわけだが。

377 ：仕様書無しさん：04/06/17 17:38

>>374
多分、できちゃうと思う。

378 ：仕様書無しさん：04/06/17 17:45

>>377
こどもが？

379 ：仕様書無しさん：04/06/17 17:47

800円でできるのかﾊｧﾊｧ

380 ：仕様書無しさん：04/06/17 17:55

>>377
こらこら、>>374 のプライドが傷ついちゃうだろ。

381 ：878：04/06/17 19:56

まともなモジュールの概念ってなに

382 ：仕様書無しさん：04/06/17 22:04

>>366の言っている事はかなり重要だぞ。

理解度が高い人間の書いたコードの方が
「誰が書いても相似」「コピペで楽にできるじゃん」
と言われるってことだ。

皮肉を言うと、それを言われない奴は理解度と
コード整理に難があるという事だが、、、

383 ：345：04/06/17 22:41

>>347
困ったことに彼は本当に前向きで頑張り屋さん。
しかもそんなコードを何万行も兎に角も管理しているので、
若いのもあるけど、実はすごい頭いいんじゃないだろうかと思ってる。

彼は自分でも言っているんだけど、あんまり新しいことをしないで、
簡単なことだけでゴリゴリ作ってるって言ってるので、
loopの見易さのために仮参照作るとか、知らんかもしれん(´д`)

問題は、Characterの良さや、腕力的な管理能力と、書くコードが
全然比例しないことで、彼のようなタイプをこき下ろさない方法で、
別に、良コードを評価しないと、社会的に受け入れられないんじゃ
ないかということだ。

難しいよ、、、そんなコード解析させられた瞬間は、
「顔洗って来い！」とか喧嘩したくなるんだが(-_-;

384 ：仕様書無しさん：04/06/17 22:49

>>381
概念ではなく具体的なモノとしては

抽象性、一般性、(再)利用性が高い
内部にはミスはない
ありがちな(外部からの)ミスには対応
(予測して吸収、未然に防止)できる

くらいあれば気軽にコピペできる

385 ：仕様書無しさん：04/06/17 22:53

>>384
仕事じゃ、そんな無駄なものは作らないけどな。

386 ：仕様書無しさん：04/06/17 22:54

普通はコピペしちゃまずいだろ。
クラスをそのまま流用するのはいいが。

387 ：仕様書無しさん：04/06/17 22:55

俺は、「真面目な頑張り屋さん」のコードが大嫌いだ

プログラマってのは、いかに怠けるかということをもっと真剣に考えるべきだ。
まあ綺麗な言葉でいえば「保守性の高いコード」と言えなくもないが…。

「怠惰」「傲慢」「短気」の原則でコードを書いて欲しい。

388 ：仕様書無しさん：04/06/17 22:57

>>382
で、その「理解度の高いPG」を優遇してますか？

389 ：仕様書無しさん：04/06/17 23:00

>>387
楽だ本はその箇所だけでも立ち読みする価値がある。

390 ：384：04/06/17 23:02

>>386
今居る所だと、先輩に質問すると、
「～～をコピペするといいよ」
とマジで言われます。

ライブラリは自分で持て、ということかなぁ？
実際>>384のようなものではないので、クラスごと
持ってきても使えません。

逆に政治力のある人のクラスを流用「させられて」
困ってます。

391 ：仕様書無しさん：04/06/17 23:04

>>366 >>382
取りあえずマなんだから何にしても具体的なコードが必要だろ。
言語はJavaで、こんな感じでどうだ？
つーか、例題作ってる間になんでこんなにスレが伸びてるんだ？

public static void main(String[] args) {
    // お題：listをString配列に変換する。
    // 結果はコンソールに出力。書式自由。
    List list = new ArrayList();
    String[] stringResult = null;
    list.add("hoge1");
    list.add("hoge2");

    //【プログラミングスキルが高い人】
    stringResult = (String[])list.toArray(new String[0]);
    System.out.println(Arrays.asList(stringResult));

    //【プログラミングスキルが低い人】
    stringResult = new String[list.size()];
    int index = 0;
    Iterator it = list.iterator();
    while (it.hasNext()) {
        stringResult[index++] = (String) it.next();
    }
    for (int i = 0; i < stringResult.length; i++) {
        System.out.print(stringResult[i] + " ");
    }
    System.out.println("");
}

392 ：382：04/06/17 23:11

>>388
ごめん、俺の政治力ランクは現在最低レヴェルなのです( ; _ ; )
「～～のクラス、利用させてもらってます。出来がいいですよ。」
と言うくらいのことしかできん(>_<)それはやってる。

393 ：仕様書無しさん：04/06/17 23:20

>>381
かなりはしょって、大ざっぱに説明するぞ。

プログラムを分割する方法にも作法っつーもんがあって、
そうした作法を無視して書かれたソースが悪いソースで、
作法どおりに書かれたソースが、良いソースと、ただそんだけ。

グローバル変数が数多く使われているソースは、
他の関数との関連性が強いから、後からの再利用が行いにくい。
グローバル変数が少ないソースは、他の関数との関連性が
弱いから、再利用を行い易い。

で、なるべく何度も使えるようなソースを書けと。

次に、こうしたソースを書いていると、
他から呼び出される関数は意外と限られる。
で、他から呼び出されない関数は、static関数にする事で、
他のファイルからは呼び出せなくなる。こうすると、
外部と連携する関数が少なくなるから、理解し易くなる。

で、あとから見直した時に理解し易いソースを書けと。

で、こうした概念をデータ構造に関連付した
プログラムが、オブジェクト指向プログラミングと。
はしょりすぎて、理解不能かな？

394 ：仕様書無しさん：04/06/17 23:25

>>392
本人に直接感謝の念を示すのも大切ですが、なるべくえらい人の前でその人の功績をアッピールしましょう。

395 ：仕様書無しさん：04/06/17 23:26

いくらなんでもはしょりすぎ
ちょっとつながりもおかしいし

396 ：仕様書無しさん：04/06/17 23:27

>>392
何かあんたの使う顔文字、可愛いなｗ

397 ：仕様書無しさん：04/06/17 23:28

>>391
あなたは、まあ誉めてるわけですが、
＞【プログラミングスキルが低い人】
のエミュレートはできてない( ; _ ; )

後者も、再介入性は高いので、良いコードの部類に入ると思います

俺の見た【プログラミングスキルが低い人】なら、
int index;
index--;
(略)
index += 1;
stringResult[index] = (略)

くらいのことはしますし、Iteratorとか使えません。(C++での話ですが)
Javaは仕事でやってないので、一部変なこと書いてるかもしれませんが。

398 ：仕様書無しさん：04/06/17 23:36

>>387
>「怠惰」「傲慢」「短気」の原則でコードを書いて欲しい。
な奴ほど、何も考えてなさそうなコピペ満載コードが多いんじゃ。

399 ：仕様書無しさん：04/06/17 23:36

俺の見た【プログラミングスキルが低い人】

26｜void main(){
//...省略因みにGREP結果"if"1000個以上,"strcat"1000個以上、等等
18129|}

400 ：397：04/06/17 23:37

だいーち、
stringResult
なんてわかりやすい変数名使ってくれるようなら、
苦労しないっすよ(>_<)ノ;;ﾊﾞﾝﾊﾞﾝ!

vSR

とかがいいとこ

401 ：仕様書無しさん：04/06/17 23:38

Arrays.asListのtoString()出力に依存したコードはどうかと思う

402 ：仕様書無しさん：04/06/17 23:39

「モジュール」＋「結合」＋「強度」＋「独立」＋「階層構造化」
あたりでぐぐって味噌。

403 ：仕様書無しさん：04/06/17 23:41

>>401 つまりはこのくらいのことは書いて見せろと。

System.out.println(new ArrayList(Arrays.asList(stringResult)){
public String toString(){/*省略*/}
});

404 ：392：04/06/17 23:43

>>394
気をつけて実行してみます。

>>396
ありがとう。言われるとうれしいものですね。

405 ：401：04/06/17 23:47

>>403
ﾜﾗﾀ
いや、そこでこれ見よがしに無名クラスまで使うのはただのｵﾅｰﾆ野郎でしょ。
Java詳しくない人は読めないよ。

単に「出力されるデータの書式は明示的に書くべき」と言いたかった。
標準APIでも、toString()で出てくる文字列は仕様で決まってるわけじゃないので
バージョン変わって動かなくなる可能性がある。

そこらへん、「Javaの鉄則」という本がおすすめ。

406 ：仕様書無しさん：04/06/17 23:52

>>393
staticのくだりは、少なくとも俺の知ってるC++では正しくないような。
むしろutility class functionとして呼び出されることが
多いんじゃないか？

private か protected の方が適当ではないか？

407 ：仕様書無しさん：04/06/17 23:52

>>403
いや、こうだろ(ﾌﾟ

public static interface ArrayFormatter{public String format(Object[] array);}

ArrayFormatter formatter = IoCContainer.getInstance(ArrayFormatter.class,"MyFormatter");
System.out.println(formatter.format(stringResult));

//IoCContainerのコンフィギュレーションは省略

408 ：391：04/06/17 23:56

まぁ、【プログラミングスキルが低い人】のパターンは何種類かあったんだけどね。

<int index = 0;
---
>int i = 0;

<stringResult[index++] = (String) it.next();
---
>stringResult[i++] = (String) it.next();

<for (int i = 0; i < stringResult.length; i++) {
---
>for (i = 0; i < stringResult.length; i++) {

にしたらループ変数を使いまわすことになって結構、嫌かも。

>>366の
>標準ので提供されている関数やクラスをうまく再利用したり、言語の
>定石に従って書くことが多い
>>382の
>「誰が書いても相似」「コピペで楽にできるじゃん」
をコードに落とすことが目的だったので、まぁ、少々の不備は勘弁してくれ。

409 ：仕様書無しさん：04/06/18 00:07

変数のスコープは可能な限り小さくすべき。でも、JavaやC#の時代になっても
郷に従わないで「Cの流儀」を押し通す人ってけっこう多い。
良い文化は守るべきだけど、ループ変数の使いまわしはただの弊害。

新しい言語に取り組むときは、新しい文化・流儀があればそれを尊重すべき。

410 ：C++厨：04/06/18 00:10

>>408
お、俺の知ってる世の中じゃ
「○○君(俺)、君の××関数見たけど、なんで
for(int i=0; (略)
の後に、
for(int j=0; (略)
とかしてあるんだい？同時に使わないだろ？」
「いや、、、混同したら危険ですから、、、」
「馬鹿だなあ、変数領域が無駄じゃないか、先ず
int i;
として使いまわせばいいじゃないか！」
とか平気で言われます(u_u;)

vector.size()を(int)にcastする(しかも只のcastだ!)のを、
秘密のテクニックのように教えられたこともあるます(u_u;)

そんなんunsigned int で使うわｺﾞﾙｧ!(ﾟДﾟ;)

411 ：仕様書無しさん：04/06/18 00:11

Java5年やってて最近Cの仕事をする羽目になってｺﾝﾅコード書きました。
外部公開するのはヘッダだけ。(MT-safety関係は省略)

MyModule.h
typedef struct{
　void (*PublicFunc1)(Args*);
　void (*PublicFunc2)(Args*);
}MyModule;
extern MyModule* getMyModlue();

MyModule.c
static MyModule* instance = NULL;
static void MyModule_PublicFunc1(Arg* args){/*省略*/}
static void MyModule_PublicFunc2(Arg* args){/*省略*/}
static void MyModule_PrivateFunc1(){/*省略*/}
//...
static MyModule* createMyModule(){
　MyModule* instance = (MyModule*)malloc(sizeof(MyModule));
　instance->PublicFunc1 = MyModule_PublicFunc1;
　instance->PublicFunc2 = MyModule_PublicFunc2;
　return instance;
}
MyModule* getMyModule(){
　if(instance == NULL){instance = createMyModule();}
　return instance;
}

412 ：仕様書無しさん：04/06/18 00:12

>>408
趣旨についてはりょーか～いー・)ノ

413 ：878：04/06/18 00:17

Java使いなのでグローバル変数は無いです。CとかPerlのときもJavaっぽくやってしまいます。

そういえば、先日３年目になった友人が「JavaでWebシステムを作ってるけどオブジェクト指向がわからない」と言っていました。
おまいは２年間なにをやっていたんだと。（ry
自分は向いていないんじゃないかとか言ってました。
人事とか、管理したいとかいってました。
２ちゃんで見るような会社なのかと思いました。
助けてあげたほうが良いでしょうか。

414 ：仕様書無しさん：04/06/18 00:23

>>413
Java分かんない奴に管理されたくないよ。
上司は部下より長期的な視点に立って判断を下さなきゃいけないんだが、
Java分かんない奴にそんな視点があるとは到底思えないね。

絶望的。

415 ：仕様書無しさん：04/06/18 00:24

オブジェクト指向がわからなくても求められる機能が実現できれば問題ないはず。
向いてない人って悩みどころも頓珍漢。

416 ：391：04/06/18 00:25

はぁ～、こーすればよかったんだよな～。
listのtoString()が見やすいんでつい。

    // お題：listをString配列に変換する。
    // 結果を判定して、そのbool値をコンソールに表示。
    List list = new ArrayList();
    String[] stringResult = null;
    list.add("hoge1");
    list.add("hoge2");
    String[] expected = new String[]{"hoge1", "hoge2"};

    //【プログラミングスキルが高い人】
    stringResult = (String[])list.toArray(new String[0]);
    System.out.println(Arrays.equals(expected, stringResult));

で、【プログラミングスキルが低い人】はおもむろに
expectedとstringResultの中身をループで回してフラグ立てて判定すると。

なんか、自分が【プログラミングスキルが低い人】に見えてきた。＿|￣|○

417 ：411：04/06/18 00:31

クラスも作っちゃうよ。
MyClass.h
typedef struct　MyClass{
　void(*PublicFunc)(MyClass*,Arg*);void(*destructor)(MyClass*);
}MyClass;
extern MyClass* NewMyClass();

MyClass.c
typedef struct MyClassImpl{
　void(*PublicFunc)(MyClass*,Arg*);void(*destructor)(MyClass*);
Field* field;
}MyClassImpl;
static void MyClass_destructor(MyClass* this){}
static void MyClass_PublicFunc(MyClass* this){
　MyClassImpl* impl = (MyClassImpl*)this;
　//...
}
static void MyClass_PrivateFunc(Arg* args){}
MyClass* NewMyClass(){
MyClassImpl* instance = (MyClassImpl*)malloc(sizeof(MyClassImpl));
instance->destructor = MyClass_destructor;
instance->PublicFunc = MyClass_PublicFunc;
　instance->field = NewField();
return(MyClass*)instance;
}
USAGE:MyClass* obj=NewMyClass();obj->PublicFunc(args);obj->destructor(obj);

なんでCで書いてるんだろ、俺…orz

418 ：仕様書無しさん：04/06/18 00:31

>>410
for(int i=0; (略)
の後に、
for(int j=0; (略)
の意味良く分からないけど、
使わないものを書いとくのは嫌だな。

419 ：仕様書無しさん：04/06/18 00:32

Java使ってるだけでOO理解してると思ってるやつ大杉。

420 ：仕様書無しさん：04/06/18 00:35

>>418
アホですか？

421 ：仕様書無しさん：04/06/18 00:36

おまいら、開発者だねー。
で、４０歳なったら、何すんの？
開発？ＳＥ？

422 ：仕様書無しさん：04/06/18 00:37

なんか気のせいかも知れないが、現物のコードが出て来て
技術論的な話になったとたん、例のコーダー煽りさんが
消えていなくなったような。

423 ：401：04/06/18 00:39

switch文とかenumとかinstanceofをやたら使う奴って
だいたいオブジェクト指向わかってない。

424 ：410：04/06/18 00:39

>>418
省略しすぎスマソ。

for(int i=0; i<hoge1; i++){
/* 略 */
}
for(int j=0; j<hoge2; j++){
/* 略 */
}

を、

int i;
for(i=0; i<hoge1; i++){
/* 略 */
}
for(i=0; i<hoge2; i++){
/* 略 */
}

にしちゃえという指示。

425 ：仕様書無しさん：04/06/18 00:41

Cはちゃんとは知らんのだけど、
for(int i=0; (略){
//something
}
for(int i=0; (略){
//something
}

でもいいんだよな？
俺ならそうするってだけだけど。

あんまりスコープを広げるのも嫌だけど、一文字の変数をたくさん使うのもいやぽ。
ループカウンタはiで、二重ループのときはjも使う・・・みたいな方が分かりやすくない？

426 ：仕様書無しさん：04/06/18 00:42

>>423
オブジェクト指向を極めた人のソースコードには、条件分岐が「ない」。
というのはどうでしょう。

427 ：仕様書無しさん：04/06/18 00:42

>>425
とあるコンパイラのバグを除けばfor内で宣言された変数のスコープは
for内のみです

428 ：仕様書無しさん：04/06/18 00:43

> 「馬鹿だなあ、変数領域が無駄じゃないか、先ず

無駄にはならないことを教えてさしあげたほうがいいんだろうなあ
あと、無駄になったとしてもスタックをsizeof(int)食うだけなんだが
組み込み系ならともかく・・・

429 ：仕様書無しさん：04/06/18 00:45

業務系アプリ開発で1バイト単位をケチる奴は馬鹿。間違いない。
同じく、CPUクロック1サイクル程度をケチる奴も馬鹿。間違いない。

430 ：仕様書無しさん：04/06/18 00:46

>>418

for(int i=0;i<n;i++) {
　...
　foo(i);
}
for(int j=0;j<m;j++) {
　...
　bar(j);
}

を

int i;
for(i=0;i<n;i++) {
　...
　foo(i);
}
for(i=0;i<m;i++) {
　...
　bar(i);
}

にしろ、ということと思われ。確かに脱力するなあ。

431 ：仕様書無しさん：04/06/18 00:46

ライブラリやミドルウェアの知識もプログラミングスキルだと思いませんか？

432 ：401：04/06/18 00:46

>>425
その昔、
for (int i = 0; (略)){
//something
}
//afterloop なぜかここで i を読める

と書いても、ループの外で i を参照できる処理系があったのです
i と j に分けてあるのは、そこらへんの名残だと思う

433 ：仕様書無しさん：04/06/18 00:49

ケチらなくてもコンパイラのほうが最適化してる罠。
多少リソースを考慮しないのはかまわないが
まったく無駄なコード、頭の悪いアルゴリズムはやめてと。

434 ：401：04/06/18 00:49

あー、>>427が正しい。処理系じゃなくて、コンパイラのバグだな
ビジュアｒうわなにをするやｑｗせｄｒｆｔｇｙふじｋぉｐ；

435 ：仕様書無しさん：04/06/18 00:53

>>433
iをレジスタ割付した結果>>432みたいな事がある処理系もあるわけで。
つかっちゃならんと思うけど値は残っててもキニシナイな、漏れ。

436 ：仕様書無しさん：04/06/18 00:53

>>425
微妙。

多分OKだと思う。というか、俺もそういう方針(ﾉﾄｷﾓ）。
jが出るとdouble nest, kがでるとtripple nest と
わかるのも有用だと思います。

ただし、「caseとか使うな！ifでいい！」
とまで言っている本では、loop変数も共用するな
と明言する。

確かに、へろ～としてて、書き間違えた場合、
エラーメッセージが出ないバグが出る可能性は
増している。

まあ、l,m,n まで使って足りないようだったら、
構成を考え直した方が、、、ということなのかも。

437 ：仕様書無しさん：04/06/18 00:57

int i;
for(i=0;i<n;i++) {
　...
　foo(i);
}
for(i=0;i<m;i++) {
　...
　bar(i);
}
うん、これはおかしいのは確かだ。。

for(int i=0;i<n;i++) {
　...
　foo(i);
}
for(int i=0;i<m;i++) {
　...
　bar(i);
}
でも、これのi,jで分けるのはどうなの？そこまでこだわる必要ないと思うけど。
というかむしろ、１重ループならiのみでいいんじゃない。

438 ：ｷﾞｬｰ(・∀・;)：04/06/18 00:58

>>432
それは知りませんでした。勉強になります

439 ：427：04/06/18 01:01

むしろ敢えて口に出して主張しあうことでもないと思ふ。
無駄にポリモーフィズムを使ってswitch文のリファクタリングしたぜ～とか
言ってバグ埋め込んでるアホとかを語ってほすぃ。

440 ：仕様書無しさん：04/06/18 01:04

あら?
IJKはFORTRANのときの習慣だと思ったが。

441 ：仕様書無しさん：04/06/18 01:06

俺の職場でリファクタリングという単語は使われていない(；ー；)ノ

442 ：401：04/06/18 01:07

アホはアホでも両方知ってる奴と、
switch文しか知らない奴だったら前者のほうが少しだけ
救いよう（改善の余地）があると思う。

知ってる狭い範囲でなんでもやろうとするコードは見苦しい。
いまだに、データ構造ったら配列しか知らない奴のコードとか…。
せっかくC++とかJava使ってても意味ない。

443 ：仕様書無しさん：04/06/18 01:09

>>439
リファクタリングでエンバグするってことは、それはリファクタリングじゃないよな。
自動テストが揃っていなかったわけで。

444 ：427：04/06/18 01:16

CollectionでIterator使うより配列使ったほうが
世間的に可読性が高かったりする。
「配列のほうがコード少ないしわかりやすいじゃん」

445 ：仕様書無しさん：04/06/18 01:21

>>444
Iterator には begin から end、
という横断保証性がある、、、

‥‥ひょっとしてそういう話じゃない？？

446 ：仕様書無しさん：04/06/18 01:22

>>406
クラスのstatic関数だとそーなるな。
グローバルなstatic関数を作って、
別のファイルから実行して味噌。
こんな感じで。

file1.c

static void hoge1(){puts("ｵﾚﾓﾅｰ");}
void hoge2(){puts("ｵﾏｴﾓﾅｰ");}

file2.c

static void hoge1();
void hoge2();

void main()
{
hoge1();
hoge2();
}

447 ：401：04/06/18 01:24

>>444
リストの走査、本当はIterator使って書きたいんだけど…

List list; //中身とか略。

Iterator iterator = list.iterator();
while(iterator.hasNext()){
Object obj = iterator.next();
dosSmething(obj);
}
より
for (int i = 0; i < list.size(): i++) {
Object obj = list.get(i);
dosSmething(obj);
}

のほうが10倍以上もパフォーマンス出るとなるとさすがに妥協。
最近のJavaはこのへんマシになったんでしょうか。

448 ：仕様書無しさん：04/06/18 01:27

やっとHelloWorldは卒業しましたってとこか？

449 ：仕様書無しさん：04/06/18 01:28

すみません、このｽﾚなんでCとC++の区別が出来ない連中が
集まってんですか？

450 ：仕様書無しさん：04/06/18 01:28

>>447
上より下のほうが早いのは、コレクションが単純な配列などでインプリメント
されている場合だけっしょ？リンクリストだったりツリー構造でインプリメント
されていた日には、list.get(i)をくり返す方がよっぽど遅くなるはずだが…

451 ：仕様書無しさん：04/06/18 01:29

>>449
ハァ？そんな奴いるの？

452 ：仕様書無しさん：04/06/18 01:32

なんか具体的なコードが出てくるとわかりやすいな。

>>391はできるだけ既存のライブラリ等の再利用を促すこと。

>>407はIOCを使用すること。(最近の流行りなのか？)

>>410は変数の使いまわしによるメモリの省力化。

他、スレ追いきれてないので(ry

なんか時代によってプログラミングテクニックって
変わっていくもんだなぁとしみじみと感じてしまった。

453 ：仕様書無しさん：04/06/18 01:33

>>449
C++でもCのコードが動くから。

454 ：仕様書無しさん：04/06/18 01:34

>>447
list.size()を何回呼べば気が済むんだか…

455 ：仕様書無しさん：04/06/18 01:35

>>449
じ、、、Javaって知ってる？

今頃来ても、遊んであげられないや、残念(>_<)ノ

キター(AAry)
はいはい、よっと、(AAry)

456 ：仕様書無しさん：04/06/18 01:36

>>454
その辺はコンパイラが真っ先に最適化かけるところ。なので無問題。

457 ：仕様書無しさん：04/06/18 01:38

>>446
Globalですか、、、やったことなかった。明日試してみます。

458 ：仕様書無しさん：04/06/18 01:38

>>446
ちなみに一応書いておくが、
hoge2()からhoge1()は呼び出し可能。

459 ：427：04/06/18 01:45

CとC++の区別っていうことの意味はわかるんだけど
VCでコンパイルする分には問題ないでしょ。流しましょう。

460 ：仕様書無しさん：04/06/18 02:00

>>459
MFCを使うと、一度使用した関数を
ライブラリ化して再利用する事が出来んからな。

461 ：仕様書無しさん：04/06/18 02:30

一応、クラスの再利用は可能だけども、
色々と不都合が大きすぎるんよ。
で、VCは使っているけどMFCは捨てた。

462 ：仕様書無しさん：04/06/18 02:32

>>461
世間一般ではそれを挫折と呼ぶ。

463 ：仕様書無しさん：04/06/18 03:56

>391
業務系Java原人出現だな(´,_ゝ｀)ﾌﾟｯ
いかにも業務系が好みそうなｺｰﾃﾞｨﾝｸﾞだがスキルなんか高くはない。
逆アセンブルしてみ。

464 ：仕様書無しさん：04/06/18 07:02

>>463
じゃあ最先端プログラマーの喪前ならどう書んだよ
逆汗するとどう違うのかも説明しろ

465 ：仕様書無しさん：04/06/18 07:38

>>460
は？

466 ：仕様書無しさん：04/06/18 08:04

>>464
放置放置
どうせ何も出来ないんだから。

467 ：仕様書無しさん：04/06/18 08:45

>>456
いや、そこにはかからないだろ。
　dosSmething(obj);
で list.size() が変化しないことをコンパイラは確信できない。
（何かとんでもないことをしてくれそうな名前だしな）

468 ：質問元：04/06/18 09:12

(´,_ゝ｀)ﾌｰﾝ

469 ：仕様書無しさん：04/06/18 09:29

CPUの処理速度が速くなってきてるこの時世に、
>>391が挙げてるような手続きの違い云々なんてのは
単に見易さメンテのし易さの問題であって
実行結果にゃ大差ないし問題ない、
その程度の事が果たしてプログラミングスキルと言えるのかね？

470 ：質問元：04/06/18 09:37

>469(´,_ゝ｀)ｿﾀﾞﾖﾈ

471 ：仕様書無しさん：04/06/18 09:37

例えば以下のネタスレなんだが
http://pc5.2ch.net/test/read.cgi/prog/1087128122/l50

こういったお題を挙げられた時に、
脳内でアルゴリズムがポンと構築できて、
それをすんなりと実装できるような能力こそが
プログラミングスキルなんじゃないの？

472 ：質問元：04/06/18 09:39

(´,_ゝ｀) >391はサンプルコードに全角の空白を入れているところが
評価できるよな。ﾏﾒなﾔｯﾁｬ

473 ：仕様書無しさん：04/06/18 09:45

>>472
この板は先頭の半角スペースはトリムされちゃうの。
だからインデントするためには全角スペースが必要なの。

474 ：仕様書無しさん：04/06/18 09:46

>>469
標準のライブラリなんかに用意されてる処理は、
自作したりせずに、それを使えってことでしょ。

475 ：質問元：04/06/18 09:51

>473
知ってるよ。だから真面目な対応をするあなたを評価した。

>474
なあ、データ量僅少なサンプルでは問題ないけど
30万件以上のDBを操作するのってテクがいるよね？
パフォーマンスの部分だけどJavaで実装するのって
けっこう大変だよね。糞遅いと客に文句言われたりしたら
どう解決する？
皆の意見を聞きたい。

476 ：仕様書無しさん：04/06/18 09:52

>>471
そうだ。そのとおり。その種のスキルが本当のプログラミングスキルに他ならない
だが実際上の業務でその種のアルゴリズム創案のようなスキルを求められるのは稀だ
何ゆえこんな違いが発生するのかについてだが、
本来、人間のテリトリーであるところの「企業における経済活動」をIT化しようとすること自体に、真の原因が存在すると思うが
どうよ

477 ：仕様書無しさん：04/06/18 09:56

>>475
お前ならどうする？

478 ：仕様書無しさん：04/06/18 09:58

>>476
ﾌﾟ

479 ：質問元：04/06/18 10:01

>477
漏れが先に語るとつまらないでしょう

480 ：仕様書無しさん：04/06/18 10:02

>>474
そういうのはコーディングスキルって呼べばいいんじゃないの？
当然あるに越したことは無いスキルだけども。

481 ：仕様書無しさん：04/06/18 10:02

>>475
DBが遅いのをJAVAでなんとかできるの?

482 ：仕様書無しさん：04/06/18 10:07

>>479
んなこたぁない。語れよ。

483 ：仕様書無しさん：04/06/18 10:08

>>481
データを読み込んでからのJAVA側の話でしょ。

484 ：質問元：04/06/18 10:08

>481　それじゃあ問題解決しようとする気持ちそのものがないわけだね

>481は客から文句言われた経験ない？
たとえば>481が作ったシステムと
同じ環境で>478が作ったほうのシステムが倍の速さで動作したら
>481は立場がないよね。
こういう事をプログラムスキルって言うのじゃないの？

485 ：仕様書無しさん：04/06/18 10:12

プログラムスキル
プログラムスキル
プログラムスキル
プログラムスキル
プログラムスキル
プログラムスキル
プログラムスキル

486 ：仕様書無しさん：04/06/18 10:14

SAPの仕事は糞だったが、唯一最適化の
作業だけは最高に面白かったのを思い出したよ。
各種日時処理が１２時間オーバー頻発だったのを
片っ端からコードを最適化して1/5に短縮とかね。
プログラミングの喜びはそこらへんに一つあるよね。

487 ：質問元：04/06/18 10:15

>483
仕様として、大量のクエリー結果resultsetオブジェクトを所有しないと
いけない状況だったらと仮定すると

どうだろう。結構難しいよね。
クエリーを小分割して吐くか、一括でシリアライズするか
そのときの状況とデータ件数でなんともいえないけどね。
例えば3万レコードだったら一括案はだめでしょう。
まあこんな仕様はないと思うけど。
じゃあ3万レコードが1000レコードだったらどう
微妙だよね。

488 ：仕様書無しさん：04/06/18 10:15

>>486
設計が悪い。

489 ：仕様書無しさん：04/06/18 10:17

>>487
( -д-)、ﾍﾟｯ　ﾂﾏﾗﾝ

490 ：質問元：04/06/18 10:22

>489　はすごいですね。漏れはいつもJava JDBCとパフォーマンスの
問題については悩んでます。>489は神ですね。

491 ：仕様書無しさん：04/06/18 10:23

結局、その場の状況に応じた作業すればいいということだな。

492 ：仕様書無しさん：04/06/18 10:24

>>490
一生悩んでろｗ

493 ：仕様書無しさん：04/06/18 10:43

高々レコード数30万件程度でテクがどうのって…

まさか全部手元に持ってきて処理してるんじゃないだろうな？

494 ：仕様書無しさん：04/06/18 10:51

>>493
教えて君にﾏｼﾞﾚｽするのもどうかと思われ。

495 ：391 ：04/06/18 11:27

>>472-473
全角空白？それはどの環境で？
補足しておくと、プログラムをHTMLに貼り付けるときは、

s/ / /g とするのが常識だと思っていたもので。

さすがに今時、文字実体参照を知らないプログラマは少ないだろうし。

496 ：仕様書無しさん：04/06/18 11:32

>>495
s/ / /gで何がしたいの？

497 ：391：04/06/18 11:37

ミスった。
s/ /＆nbsp;/g

498 ：仕様書無しさん：04/06/18 11:39

かっこ悪～い。

499 ：仕様書無しさん：04/06/18 11:59

プログラマなんか使い捨てだからどうでも良い。
適当におだててりゃなんでもいうこと聞くわな。

500 ：仕様書無しさん：04/06/18 12:02

プログラマーって、はたから見ると気持ち悪いっていうか・・・

勝手にオナニーして自己満足してなさい

501 ：仕様書無しさん：04/06/18 12:07

>500
そんなあなたもプログラマーｗ
いじけてないでガンバレや

502 ：仕様書無しさん：04/06/18 12:09

下流のくせにいきがっている奴が多いよな。
まったく、悔しかったら上流まで上っておいで。
どうせ君たちには無理だと思うけどw

503 ：仕様書無しさん：04/06/18 12:28

>>502
しゃけかよっ！

504 ：仕様書無しさん：04/06/18 12:38

自分を上流だと思っている底辺が定期的に現れるなｗ

505 ：仕様書無しさん：04/06/18 12:47

>>504
いっかげつで、それもスイカじゃないのかよ！

506 ：仕様書無しさん：04/06/18 12:50

誤爆？

507 ：仕様書無しさん：04/06/18 12:53

>>503
しゃけは上流までいくとうまくなくなるよなぁ

508 ：仕様書無しさん：04/06/18 12:59

上流／下流って・・・
単なる前工程／後工程だろ
#ちなみに「しゃけ」は方言な。鮭の事だろ

509 ：仕様書無しさん：04/06/18 14:14

上司に気に入れられるよう仕事をしつつ、技術者としての信念ももちつつやれば？

510 ：仕様書無しさん：04/06/18 14:16

友人の建築士が言ってた。
現場の大工さんを単なる「作業者」として見下してる建築士は、だいたいいい仕事ができないが、
大工さんの「技術」をきちんと見て、大工さんの立場からの意見もちゃんと聞く建築士は
いい仕事してる人が多いんだそうだ。

511 ：仕様書無しさん：04/06/18 15:04

>>510
できるやつを見下したりはしないさ。
おまえみたいに能書きばっかで使えないくずを見下してるだけだよ。
気づいてなかった？

512 ：仕様書無しさん：04/06/18 15:30

友人の言葉を紹介しただけのやつにまでからんでるよw
そうとうﾘｱﾙで欝憤が溜まってるんだろうなぁ。

513 ：仕様書無しさん：04/06/18 15:48

リアルじゃ人にからむ勇気すらない誰にも相手にされないカスなんだろｗ

514 ：仕様書無しさん：04/06/18 16:22

(´,_ゝ｀)急がしかったので暫く放置したたらレスが進んでるな・・・

>高々レコード数30万件程度でテクがどうのって…
>まさか全部手元に持ってきて処理してるんじゃないだろうな？
喪前みたいにVectorファミリのヒープ使い切るほど無理につめこんだり
なんて事はしないよ。分かってｲいたけどやっぱりｳﾞｧｶﾀﾞﾅ喪前
喪前なんてどうせStringとStringBufferの内部仕様の違いもしらねえんだろ

515 ：仕様書無しさん：04/06/18 16:23

「急がしかった」って、2ch用語か何か？

516 ：仕様書無しさん：04/06/18 16:29

>StringとStringBufferの内部仕様の違いもしらねえんだろ
わぉ

517 ：仕様書無しさん：04/06/18 16:34

>515
自分はバグだらけの糞コード書くくせに
他人のバグはすぐ見つけ、偉そうに指摘するタイプだな

518 ：仕様書無しさん：04/06/18 16:36

>>515
雰囲気は出てるが、ヴァカ丸出しだな
小さい頃からそう覚えてたんだろうｗ

519 ：仕様書無しさん：04/06/18 16:41

>>514の今後のスケジュール
誰かが「じゃ、「StringとStringBufferの内部仕様の違い」とやらを説明してみろ。」　と煽り

514氏登場。得意げに説明するが、当然のごとく間違いを指摘される。

あわてて知識をひけらかし、弁解しだす。

その知識にさらに突っ込みが入る。

逆切れして馬鹿にされる

「実は釣りでした」と負け惜しみ

放置

520 ：仕様書無しさん：04/06/18 16:58

>>517
こんな明らかな個所を「すぐ見つける」だけなら
タイプなんか関係ないのでは？ ;-)

521 ：仕様書無しさん：04/06/18 16:59

(´,_ゝ｀)>519まあそんなに怒るなよ

522 ：仕様書無しさん：04/06/18 17:27

>>514
>喪前みたいにVectorファミリのヒープ使い切るほど
なんで俺がそんな事やったと思うわけ？毒電波でも受信したか？
で、どうなの？
SQL もマトモに使えないもんだからフェッチループ作って
リソース浪費してるの？してないの？

523 ：仕様書無しさん：04/06/18 17:39

おいおい、ちったぁまともな反論してみろよ
アフォには無理かｗｗｗ

524 ：仕様書無しさん：04/06/18 18:08

>>515
「分かって」も多分そう。

525 ：仕様書無しさん：04/06/18 18:23

>>524
「ｲいたけど」も？

526 ：仕様書無しさん：04/06/18 18:30

(´,_ゝ｀)ﾊﾊ
そんなに気ずかいするなよ、照れるじゃんか

527 ：仕様書無しさん：04/06/18 18:32

(´,_ゝ｀)ｻﾃ
仕事お先にかたずけなくちゃ

528 ：仕様書無しさん：04/06/18 18:34

>>524
「放置したたら」はどうなん？

529 ：仕様書無しさん：04/06/18 18:35

(´,_ゝ｀)手続き型のｷﾐﾀﾁって
幸せだな～

530 ：仕様書無しさん：04/06/18 19:04

>>528
それはtypoだろう

531 ：仕様書無しさん：04/06/18 19:08

君達はもう少しこう仲良くできないものかね？

532 ：仕様書無しさん：04/06/18 19:09

引くに引けなくなった誰かさんを除いては
現在おおむね仲が良いですけど。

533 ：仕様書無しさん：04/06/18 19:12

おおむねと言えば、高岡早紀ちゃん結婚してたんだね。しかも今は不倫中だとか・・・

534 ：仕様書無しさん：04/06/18 20:09

話を蒸し返すようですが、みなさんの知識がWindowsに寄っているために
C++の規格や歴史を交えてお話しさせて頂きます。

for(int i=0;i<n;i++) {
　...
　foo(i);
}
for(int i=0;i<m;i++) {
　...
　bar(i);
}

この記述は移植性に問題があります。
最初のC++の規格ではforで宣言した変数のスコープはforの外側と同じであると規定されていました。
その後、規格が変更になり上記のようなコードもありになっています。
UNIX上では様々なCPU、コンパイラで動くように移植性には細心の注意を払います。

よって、移植性を考慮したプログラミングでは、
上記の場合はスコープ外で変数を宣言するか、２個目のforを別の変数名にすることになります。

535 ：仕様書無しさん：04/06/18 20:46

>>534
スレ違い。ム板でやってくれ。
Unix使いって古い規格に縛られるのが好きなのか？
VC6.0、VC7.0、VC7.1、gcc3.xに対応できれば十分じゃん。

・各コンパイラのboost適応状況
ttp://boost.sourceforge.net/regression-logs/

・参考までにVC6.0での回避方法
#include <stdio.h>
// VC6.0対応
#if _MSC_VER == 1200
# define for if(0);else for
#endif // _MSC_VER

int main()
{
    for (int i = 0; i < 10; i++) {
        printf("%d\n", i);
    }
    for (int i = 0; i < 10; i++) {
        printf("%d\n", i);
    }
    return 0;
}

536 ：仕様書無しさん：04/06/18 20:46

>よって、移植性を考慮したプログラミングでは、

{for() {
}}

ってする。

>上記の場合はスコープ外で変数を宣言するか、２個目のforを別の変数名にすることになります。

アフォか？

537 ：仕様書無しさん：04/06/18 20:55

>>534
>よって、移植性を考慮したプログラミングでは、
C++ではなく、Cを使う。

538 ：仕様書無しさん：04/06/18 21:12

>>535-537
必死だな(藁

539 ：仕様書無しさん：04/06/18 21:13

窮地に立ったらまず必死発言

540 ：仕様書無しさん：04/06/18 21:16

>>534
別にその例に関しては初期化してるからいいじゃん。

541 ：仕様書無しさん：04/06/18 21:18

まあこういうのってプログラミングスキルって言うよりは
単なる豆知識のひけらかしだわな。

542 ：仕様書無しさん：04/06/18 21:22

>>540
同じスコープ内で２回宣言していることになり、コンパイルエラーになる処理系があります。
古いHP-UXでエラーになりそうな予感。

543 ：仕様書無しさん：04/06/18 21:24

>>541
Windowsプログラマにとっては豆知識でも、

知っていないとバグになって納品できない場合、「豆知識」という言葉では終わらない。
テスト環境を４０種類も用意してテストなんてことはできないから、最低限の移植性に関する知識は必要。

544 ：仕様書無しさん：04/06/18 21:26

そもそも１００％修正無しで移植できるような
プログラムって例えばどんなの？

545 ：仕様書無しさん：04/06/18 21:34

>>544
１００％修正ナシが目的ではない

移植するときに面倒にならないための豆知識

546 ：仕様書無しさん：04/06/18 21:44

旧規格のコンパイラにかけるのを想定して
実装しなきゃならないなんてかなり稀なケースだよ。
そもそも規格そのものが変更になったんだから、、
世間一般の標準的なプログラマであれば、
そんな事に神経使う必要なんかこれっぽっちも無いでしょ。
知ってて損はないけど、別に特にもならんような豆知識。
遠い国の知らない田舎街でしか使えない特ダネ情報なんかどうでもよかよ。

547 ：仕様書無しさん：04/06/18 21:52

言ってることも間違ってないし、悪気はないんだと思うが

> みなさんの知識がWindowsに寄っているために
> C++の規格や歴史を交えてお話しさせて頂きます。

ここらへんの「ちょっと上から見た」言い方が
このスレの住人としては気に食わないんだろーと思う。

技術職の人間は言葉遣いとか、かなり無神経になりやすいと思う
（漏れもそうなので気をつけたいと思っている）

548 ：仕様書無しさん：04/06/18 21:56

このスレのプログラマ気取りの阿呆どものレスはマジで腹いて。
インド人プログラマの靴下でも食べてなさい。

549 ：仕様書無しさん：04/06/18 21:58

・・・とＳヨさんが仰られています

550 ：仕様書無しさん：04/06/18 22:02

>>546
UNIX系の大規模プロジェクトに参加すると、移植性の大切さがわかると思うよ。

551 ：仕様書無しさん：04/06/18 22:04

自分の環境でしか通らないようなソースをコミットした日にゃ、そらもう袋だたきですわ。

552 ：仕様書無しさん：04/06/18 22:07

UNIX系のC++大規模プロジェクトねー。
最近あんまりないよね。

553 ：仕様書無しさん：04/06/18 22:10

で、移植性を高めるための具体的な方法は？

554 ：仕様書無しさん：04/06/18 22:16

>>550
普通は、処理系決め打ちでいくけどな。

555 ：仕様書無しさん：04/06/18 22:23

ANSIに準ずる様書いてれば大丈夫なんじゃないの？

556 ：仕様書無しさん：04/06/18 22:26

そういえばむかしコテハンで似たようなタイプがいたな。
「おまえらレベル低いな」みたいなことは言うんだが、
決して自分から自分のレベルを示すようなことは
いっさい言わない。
トーチカの銃眼から銃口だけ出して一方的に撃ってる
ようなタイプ。

557 ：仕様書無しさん：04/06/18 22:30

>>553
C++で移植性を高めるための禁止事項一覧

(1)：for文での変数宣言禁止・・・>>534
(2)：new演算子使用禁止・・・古い規格はNULLを返す。
(3)：例外使用禁止
(4)：名前空間使用禁止
(5)：RTTI使用禁止
(6)：tamplate使用禁止

取りあえずこんなところだろ。
詳しい奴補足よろ。

558 ：仕様書無しさん：04/06/18 22:34

つまり、全てのコードをANSI準拠のCで書けばいいって事だね

559 ：仕様書無しさん：04/06/18 22:35

補足
(7):class 使用禁止

560 ：仕様書無しさん：04/06/18 22:38

顔文字を使う無能が出没しているようだな。
欝陶しいから文学系の板に帰って自作自演していてくれ。

561 ：仕様書無しさん：04/06/18 22:56

まとめると、C++使用禁止ってことか

562 ：仕様書無しさん：04/06/18 23:25

mozillaのコーディング規約は557に近いものがあるな
(1)(2)はさすがにないが

563 ：仕様書無しさん：04/06/18 23:39

禁止事項追加

(8)/**/コメントのネスト禁止 (C++に限ったことではないが)
(9)インライン関数禁止

>>559
私の勤務先では、デフォルトコンストラクタを必ず定義するという条件付きでクラス使用が許されています。

564 ：仕様書無しさん：04/06/18 23:42

Ｋ仲川は
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ

565 ：仕様書無しさん：04/06/18 23:42

mozillaのコーディング規約は、Windows , Mac, UNIXのどれでも動かそうという、さらに条件が厳しい規約。

規約を厳しくしているのは、主にMacとHP-UXなわけだが・・・

566 ：仕様書無しさん：04/06/18 23:44

>>564
そのような内容を書き込む場合は、かならず１カ所は「うこん」を混入しておくように。
厳しく注意しておきます。

567 ：仕様書無しさん：04/06/18 23:47

各種プラットホームへの移植に関するテクニックや知識などのスキルは高く評価してもいいと思うんだけどね。

568 ：仕様書無しさん：04/06/19 00:01

>>564
プログラマならプログラム書いて短縮しろ

569 ：仕様書無しさん：04/06/19 00:20

if ( style == "うんこ" && smell == "カレー" ){
　　　eat();
　　　cout << "TOTOのお皿に盛りつけないでよ！" << endl;
} else if ( style == "カレー" && smell == "うんこ" ){
　　　eat();
　　　cout << "うんこ味だった・・・" << endl;
} else if ( style == "カレーうどん" && smell == "うんこ" ){
　　　eat();
　　　cout << "うんこ味だし、おまけに回虫まで入ってるよ・・・" << endl;
}

570 ：仕様書無しさん：04/06/19 00:21

解説
(1)は、カレー味のうんこ
(2)は、うんこ味のカレー
(3)は、虫下しを飲んだ後のうんこ

571 ：仕様書無しさん：04/06/19 00:25

虫下しって使わない方がいいんじゃなかったっけ？
ちょっとぐぐって調べてくる。

572 ：仕様書無しさん：04/06/19 00:36

あった

http://home.owari.ne.jp/~fukuzawa/nikki01-8.htm
８月１８日（土）　腹の虫と人間
のところ

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
腹の虫がいなくなると同時に、花粉症やアトピー、気管支喘息などのアレルギー病で苦しむ人が増えてきたのだ。
ドイツのハンブルク大学の研究によると、回虫などの感染率が低い地域では、アレルギー病の発生率の上昇が見られるという。

　京都大学霊長類研究所の調査によると、この２０年間で猿の花粉症は少しも増えていない。一方で、サルに棲みついている
寄生虫が常に８０パーセントを超えていることがわかっていて、ここでも人間における寄生虫の感染率の低下と
花粉症発病率との相関が指摘されている。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
って全然流れと関係ねーじゃんｗ
何、１人で調べてんだ、俺ｗ
ﾊﾞｶｼﾞｬﾈーのｗ

573 ：仕様書無しさん：04/06/19 00:39

「お腹に寄生虫」と「田舎に帰省中」って似てるよな。

574 ：仕様書無しさん：04/06/19 00:47

不覚にもﾜﾗﾀ

575 ：仕様書無しさん：04/06/19 01:03

576 ：仕様書無しさん：04/06/19 02:00

>>567
いろんなOSで動かしたいソフトはJavaで書けば？

577 ：仕様書無しさん：04/06/19 03:58

求人広告を見てて明らかに変だと思うことは、
何故、組込みのようなハードとソフトの知識が必須で
専門的で難しいそうな仕事の値段が安くて、
誰でもできそうなWeb関連やスクリプトでの知識で終わるような
仕事が高いのだ！

むしろ、能力的に見たら逆だろ。この状況は絶対おかしいと思う。
日本のソフトウェア産業がだめだってのが、これを見てよく分かった。

578 ：仕様書無しさん：04/06/19 04:26

>577
それじゃ釣れねーぞ

579 ：仕様書無しさん：04/06/19 04:28

>>578が釣れた。

580 ：仕様書無しさん：04/06/19 05:37

いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？
いろんなOSで動かしたいソフトはJavaで書けば？

581 ：仕様書無しさん：04/06/19 05:52

>>567
それなりに知識は必要なんだが、
そもそも移植なんて作業自体がほとんどない。

582 ：仕様書無しさん：04/06/19 06:54

そんなこと言ってるから骨髄移植のドナーが少ないのです。

583 ：仕様書無しさん：04/06/19 10:07

>>577
>日本のソフトウェア産業がだめだってのが、これを見てよく分かった。

あなたの発言を見て、私は「ソフトウェア産業がだめだってのが良くわかった」

給料は需要と供給のバランスによって決定される。
いくら難しい職種だろうが、人が余ってれば賃金は下がる。
逆に簡単な仕事でも需要（仕事）に対して人が少なければ賃金は上がる。

こんな一般常識もしらずに、「日本のソフトウェア産業だめだ」
と書けちゃうあなたのような人がいるから
「日本のソフトウェア産業はだめ」なんだろうな。

そもそも、コーディングレベルなら組み込み系とWeb系も
どっこいどっこいだと思うがな。

584 ：仕様書無しさん：04/06/19 10:16

週報に
「○○殿と○○について打ち合わせ」というキーワードがないと評価が低い。

585 ：仕様書無しさん：04/06/19 10:24

日本人のエンジニアって、自分の実力と分不相応な誇りを持ちすぎている。
仕様通りにコードを書く実力しかなくても
「俺は第一線で活躍するエンジニアだ！」とか思っていたりする。
少しは身の程を知ったほうがいいと思う。

586 ：仕様書無しさん：04/06/19 10:24

だから旧規格のＣ＋＋コンムパイラに通すような
ケースの仕事って具体的にどんなのよ？

587 ：仕様書無しさん：04/06/19 10:28

>>585
いるいる。
ウォータフォールとスパイラルの違いも分からない奴が
（というかそういう分類があるということすら分からない）
「俺はＳＥ」だと言っている。

見ていて辛い。

588 ：585：04/06/19 10:43

まあ個別にバカがいるのはどの業界でも同じなんだけど、
日本ではプログラマが必要以上にバカにされている反動なんだと思う。

最低限の論理的思考も持ち合わせていない、ソフトウェア開発に
本来就いてはいけないようなド素人をも大量投入して
人海戦術をやってきた（そして、ある程度通用してしまった）せいで
日本人プログラマ全体のレベルが大きく押し下げられたのが
原因だと思う。

プログラマという仕事自体はなんらバカにされるものではないのに。

589 ：仕様書無しさん：04/06/19 10:49

プログラミング能力をもっと評価されたいのであれば、少なくとも中国人プログラマなんか目じゃないくらいすばらしいプログラムをビシビシ書いていかなくてはならんだろ。
同じレベルなら安いほうにやらせるのは今の日本なら当然。

590 ：仕様書無しさん：04/06/19 10:51

>>589
すばらしいプログラムを見抜けるひとは誰だ？

591 ：仕様書無しさん：04/06/19 10:58

全員が基本情報処理（旧二種）持ってる
だけでもずいぶん違ってくるんだが……

592 ：仕様書無しさん：04/06/19 11:02

>>591
やけにレベルが低いな
そんなんだから馬鹿にされるんだと思うんだが・・・・・・

593 ：仕様書無しさん：04/06/19 11:04

>>590
要はバクの出ないコードを速く仕上げるってことだろ。
お前にできるか？

594 ：仕様書無しさん：04/06/19 11:05

根本的にその辺のどうでもいい資格をとれる能力と
プログラムを組める能力ってのが全く違うところから理解する必要がありげ。

595 ：仕様書無しさん：04/06/19 11:12

>>594
ファゲ銅
>>591みたいなのが一生懸命レベルを下げてる上に、その自覚がないから（ｒｙ

596 ：仕様書無しさん：04/06/19 11:17

資格もとれないアホをふるい落とすことはできる
最低限のスタートラインには役に立つと思うんだが
ただ、そんなことやっても誰も（主に雇用者側が）得しない
資格を必要以上にバカにするのも、この業界の特徴。

資格の有無と仕事のできるできないが　"必ずしも"　結びつかないことを
根拠に資格自体を否定するような発言が目立つ。
（ここでは、ベンダーの資格ビジネスがどうという議論はしない）

中学生が「数学なんか勉強しても社会で役に立たない」とか
ゴネてるのと同じ。役に立てられない奴がアホ。

597 ：仕様書無しさん：04/06/19 11:27

ベンダー資格でもそうなんだけど、最低レベルの資格は
プログラム書いたこと無くても(製品使ったこと無くても)、
勉強すれば取れちゃうってのがね。
実際に勉強だけで取っちゃった奴らが多いというのも
馬鹿にされる理由なんだろう。

598 ：仕様書無しさん：04/06/19 11:42

デスマーチ2級もってます。

599 ：仕様書無しさん：04/06/19 11:42

> 資格もとれないアホをふるい落とすことはできる
> 最低限のスタートラインには役に立つと思うんだが

そういう次元の低い議論が馬鹿にされてるんだが

「日本の大学生のレベルは低すぎるから、せめて中学レベルの数学が出来ない人を受け入れるのは止めましょう」とかいう議論をしてもしょうがない

600 ：仕様書無しさん：04/06/19 11:43

SEがプログラミングの概要を知るために受けるのにはいいかも。

601 ：仕様書無しさん：04/06/19 11:45

プログラマ名乗るなら、最低でもソフ開くらいとれYO。

602 ：仕様書無しさん：04/06/19 11:49

プログラマ名乗るなら、最低でもLinuxカーネルぐらい理解しろYO。

603 ：仕様書無しさん：04/06/19 11:49

仰る通りの馬鹿でスマン。
漏れも「資格を使った一部の足切り」で本当にどうにかなるとは思っていない。
ただ、資格の勉強して知識を得ることまで否定するのはどうかなと。

そこでだ、>>599はプログラマの質を上げるためにはどうしたらいいと思う？

604 ：仕様書無しさん：04/06/19 11:50

そんなもん取っても何の役にもたたん

605 ：仕様書無しさん：04/06/19 12:05

>>603
資格が悪いとは言ってないよ。
少し勉強しさえすれば取れる資格は意味がないと言ってる。
基準を設けるのは大歓迎だが、基準が低いとなんの意味もない。

606 ：仕様書無しさん：04/06/19 12:07

>>604
知能が劣る馬鹿を足切るためには役に立つだろう。

資格＝能力　ではないから、資格をもっていても能力が保証される
わけではないが、
普通の知能を持った人間なら簡単に取れる資格さへ取れないアホは
そもそもいらないってことで。

都合が悪いですか？>>604

607 ：591：04/06/19 12:12

ふるいをかけるのも一つの方法だし、
教育指導するのも一つの方法でしょ。
根本的な解決にはならんけど。

旧二種を出したのはただの妥協だけどな。
旧一種持ってるヤシはなかなか見ないんで。

608 ：仕様書無しさん：04/06/19 12:17

足切りに使っちゃうと、「足切りで落されないこと」を目標に頑張っちゃう
奴が増えるからな。

609 ：604：04/06/19 12:18

>>606
馬鹿は五分話せば見抜ける。

610 ：仕様書無しさん：04/06/19 12:23

>>609
で、あなたはｱﾌｫでも取れる資格は当然もってるのですよね？

ｱﾌｫと５分も話す労力が惜しいから、書類時点で落とすのには有効でしょう。

611 ：仕様書無しさん：04/06/19 12:24

>>607

＞旧一種持ってるヤシはなかなか見ないんで。

さっさと今の会社を移ったほうがいいと思うよ。
おそらくあんたが言ってる「レベル」自体がちと低い。

「仕事できないやつほど資格だけ取ってる」という話は、
一般にどこの会社でも多いから、あんたに対する反論が出るんだが、
あんたの会社の場合は、それ以前の問題のようだから。

612 ：仕様書無しさん：04/06/19 12:24

>>608
頑張れない奴や知識を持たないヤシよりはマシ。

613 ：仕様書無しさん：04/06/19 12:29

>>610
わかんない奴だな。
俺は資格なんぞ全く持ってない。
そして、資格の有無はスキルの判断材料にはならん。
#ついでにいうと学歴もな。

614 ：仕様書無しさん：04/06/19 12:31

>>612
足切り逃れのために資格取る奴を頑張ってると思うのか。

615 ：仕様書無しさん：04/06/19 12:32

>>613
ついでに言うと職も持ってないんだろ

616 ：仕様書無しさん：04/06/19 12:34

>>611
どこの会社にもいるよね。
ｱﾌｫな資格さへ取れないことを仕事のせいにする奴が。

旧一種、今はソフ開だっけ？
あのレベルなら、生き帰りの電車のなかで、ほんのちょっと
参考書読めば合格できるだろうに。
アプリケーションエンジニアだって、普通に仕事をしていて
その内容を小論文に書けばいいだけだろ？
試験に行く時間さへ取れればなんとかなるのに、試験を受ける
時間もないほど忙しいの？
こういう言い訳する奴が不思議でならん。
自分が馬鹿なことを言いふらしてるってこと？？

617 ：仕様書無しさん：04/06/19 12:35

>>604
ずいぶん報われないところで働いてんだな。

618 ：仕様書無しさん：04/06/19 12:36

基本的に中に入っちゃえば資格が問われることはまず無いというのもあるけどな。

619 ：仕様書無しさん：04/06/19 12:40

>>613

っと、低学歴のそして何度も基本を不合格となった恥ずかしい人が
負け犬の遠吠えをしています。

ﾌﾟﾌﾟﾌﾟ

620 ：仕様書無しさん：04/06/19 12:43

資格なんかより知能指数で判断したほうが楽尚且つ的確でよい。
あとは人間性の問題だけ。

621 ：604：04/06/19 12:52

>>615 と　>>617
マトモな反論しろ

資格を取るために勉強すること自体は役に立つかもしれないけど
資格を取ること自体は何の役に立つ？。
一時金や手当が出るのは個人的な利得であるのは事実だけど、それだけのことだろ。
会社が営業しやすくなるという理由はあるが、それは会社の都合だろ？

プログラミングスキルの話をしているんだよなぁ
まず「資格はスキルを示すか示さないか」を話題の中心にするべきだろ

で、「資格はスキルを示さない」が俺の意見であるわけ。
どうよ

622 ：仕様書無しさん：04/06/19 12:53

>>620
資格は書類面接の時の足切りに使用
　　　↓
入社試験で、知能テストに準じたテスト
（一般以下をふるい落とし）
　　　↓
面接で人間性を見る

これだけやれば、少しは精度はあがるかな。
でも、ｱﾌｫは紛れこむけどね。
やらないよりはマシでしょう。

623 ：仕様書無しさん：04/06/19 12:56

プログラミングスキルと資格なんか関係あんの？
話しつくされたネタつまんねーよ

624 ：仕様書無しさん：04/06/19 12:58

>>621
だから言ってるだろうが。
ｱﾌｫでも取れる資格さへ持っていないようなｱﾌｫは評価の対象外だと。
資格＝能力ではないが、ｱﾌｫ資格さへ取れないｱﾌｫは能力を判定する
スタートラインにも立ってないってことを自覚しろよ。

625 ：878：04/06/19 13:01

>>878
80点以上を見分けるのはむりだけど30点以下を見分けることは出来る。そんなもん？
結局、、、びみょうやね。オンラインで受験できて70点以上ぐらいを見分けられる仕組みがあったらなあ。

実際の現場には資格なんてなくてもスーパーなやつもいるから、人が足りないときに資格で足きりするのは
もったいない気もしないでもないよね。

626 ：仕様書無しさん：04/06/19 13:03

>>624
君が評価方法として資格を判断材料とするのは良くわかった。
・・・面接される側なんだろうね

627 ：仕様書無しさん：04/06/19 13:04

624は悔しくてパニックになった模様です。
矛盾した文書にも気づいていないｗ

628 ：仕様書無しさん：04/06/19 13:05

>>621がユーシューなのはわかったよ、それでいいよもう。
これからも自分の道を勝手に進んでくれ。そしてもうここに来んなよ。

もっている資格とスキルの程度に「ある程度」相関が認められればいいの。
乱暴な言い方だと、無資格者100人チームと有資格者100人チームの
アウトプットを比べて、有資格者チームのほうがマシな結果が出るようなら
それで十分なの。

あと「会社が営業しやすくなる」って発想はちょっと派遣奴隷の
コンプレックス丸出しで笑えるが、逆に考えれば
資格は転職するための保険程度にはなるわな。

まず、資格があれば書類選考で有利なのは間違いない。
（多すぎても問題なので、レベル高いほうから数個書くのがベストか）

まあ、面接の場でまで資格をアピールするのは逆効果だが…。
ネタにだされたら逆にさらっと流すくらいのほうが良い。

629 ：仕様書無しさん：04/06/19 13:07

経営者としては、当たりがでるまでハズレくじひくわけにもいかんのだよ

630 ：仕様書無しさん：04/06/19 13:13

「ある程度」すら相関が無いから役に立たねぇと言われてるんだが。

631 ：仕様書無しさん：04/06/19 13:14

無能同士で言い合いすんな（・∀・）/

632 ：仕様書無しさん：04/06/19 13:17

>>628
募集に来た人間に資格とスキルとの相関がある会社というのはそれこそ底辺だ。
無資格のやつはそもそも前歴プログラマじゃないとかいう類の。

633 ：仕様書無しさん：04/06/19 13:20

>>630
相関がないと判断した理由は？
相関という言葉の意味を理解してる？
まぁ、できる奴はあんな低レベルな資格など鼻歌混じりで取得できるし、恥ずかしくて自慢もしない。せいぜい英検3級と同レベル

634 ：仕様書無しさん：04/06/19 13:26

とりあえずお前らバカなんだろ？

635 ：仕様書無しさん：04/06/19 13:30

>>633
そろばん３級でも評価してくれますか？

636 ：仕様書無しさん：04/06/19 13:33

>>633
新人君とかインターンで来てる人を見て。
そりゃ町中で兄ちゃんに声かけて開発人員集めるんなら
「基本情報持ってる人いませんか～」
と声かけた方が効率いいだろうけど、そんな状況じゃないだろ。

637 ：仕様書無しさん：04/06/19 13:36

10年選手と新卒を比較した場合、新卒の方が資格持ってる率は高そうだが。

つか、中途と新卒の採用基準は全然違うだろ。
中途の場合は資格より経歴重視だろ？

資格マンセーな人の会社では、資格試験内容に沿った職務でもしてんの？

638 ：仕様書無しさん：04/06/19 13:41

>>633
まぁ、そんな感じ。
いま人余りまくり。派遣会社も2週間に1度くらい仕事ありませんか、と電話をかけてくる状態。スキルシートが大量にくるから、振るい落としの一つとして使っている。

639 ：仕様書無しさん：04/06/19 14:10

>無能同士で言い合いすんな（・∀・）/
無能だから、あれこれ議論のフリをして

己　の　無　能(脳)　を　ブ　ロ　ッ　キ　ン　グ　し　て　い　る　の　で　つ

非同期の割り込みは不可能な頭脳の持ち主ばかり集まっています。

640 ：仕様書無しさん：04/06/19 14:17

究極の無能が現れたところで次の話題に行こうか

641 ：仕様書無しさん：04/06/19 14:37

はい、次の方どうぞ
↓

642 ：仕様書無しさん：04/06/19 14:57

ハッカー的な優秀なプログラマが資格如きに意味を見出すとは思わない。
自身の実力に自身を持ってるからそんなものに頼る必要は無い。
まあ無論そういった人種は、大企業で働くけるようなタイプではないから
少数精鋭で合理的な仕事をして、ガンガン儲けてるよ。
何より彼らは他人のスキルを見抜く嗅覚が企業の人間とは全く違う。

643 ：仕様書無しさん：04/06/19 15:02

はい、次の方どうぞ
↓

644 ：仕様書無しさん：04/06/19 15:05

採用試験（SE、プログラマー）を作るぞ

問い１、あなたが仕事をする際にいつもやっている習慣はなんですか？

645 ：仕様書無しさん：04/06/19 15:09

「まとめる、整理する」に１番時間を費やす。
余分なものを徹底的に剥ぎ取ってみる。

646 ：仕様書無しさん：04/06/19 15:14

↑
無能一確

647 ：仕様書無しさん：04/06/19 15:15

まずはｳﾝｺしてすっきりしてからかな。

648 ：仕様書無しさん：04/06/19 15:15

まず、作業の定義を行う。

プログラマとして。だよな。
理論的には仕様書という形で作業の定義は完了しているはずなんだが。
仕様書も人間が記述するものである以上、
矛盾や抜けが皆無であることは少ないからな

649 ：仕様書無しさん：04/06/19 15:17

>ハッカー的な優秀なプログラマ
少なくともここには絶対いないぞ。

650 ：仕様書無しさん：04/06/19 15:38

＞まずはｳﾝｺしてすっきりしてからかな。
とりあえずこれか

651 ：仕様書無しさん：04/06/19 15:49

資格をバカにするのはそれよりも上級の資格を取ってからバカにするがよろし。
取得も出来ずにバカにするのは、ただのバカ。
そんなバカが多すぎるのが問題です。
あんなものは仕事には関係ないと言っているヤツほど、仕事が出来ない。

652 ：仕様書無しさん：04/06/19 15:57

全く資格が無くいが特別優秀な人というのは、転職先を探すということはありません。
条件の良いオファーが向こうから飛び込んでくるから、それに乗るだけなのです。

就職に応募してくるようなヤツで無資格というのは、やはりかなりの確率で無能。
会社の採用担当なんて、確率が高い方を優先するんですから、
無資格の人は強いコネを探すとか、そちらでがんばって下さい。

653 ：仕様書無しさん：04/06/19 16:02

エクスペクト・パトローラー！！

654 ：仕様書無しさん：04/06/19 16:04

プログラマというのは、小さなレベルの技能転換を
常に要求されるから、最低限それができる、
ということの証明にはいいんじゃないの？＞資格

それだと資格を取るまでの期間が指標としては良い、
ということになって、一般にはわからんけど。

で、それとは別に、○○で十何年、潰しは効かんが
この範囲では無敵に近い、という奴も評価すれば良し。

655 ：仕様書無しさん：04/06/19 16:06

>>651
そもそも資格がスキルの何の指標にもなっていないのに
なんでとれとれうるさいのか全く理解できない。
仕事ができるのと、資格をもってることに何の関連も無いじゃないか。

そりゃいくらか勉強すればとれるだろうよ？
だけど、現場でまったく役に立たない資格を現場にいる俺等がＮｏと
言わないで誰がＮｏと言えるんだ。
意味の無い資格は現場からＮｏと言ってやらなきゃ何も変わらないよ。

656 ：仕様書無しさん：04/06/19 16:09

>>４
＞今のように、５１２Ｍバイトが当たり前に搭載できる時代は、メモリを馬鹿食いしても、実行速度重視だし。

メモリを馬鹿食いしても、オブジェクト志向重視でクラスをたくさん作るということの間違い

657 ：仕様書無しさん：04/06/19 16:14

>>655
世間的に評価されているけど、ソフト開発の現場では必要ないとあんたは
思っているＩＴ関連の資格を例示してくれ。

658 ：仕様書無しさん：04/06/19 16:18

情報2種も持っていない。無資格だが、スカウトあったぞ。
（スキルには自信ある。）
外資系は日本国内のそういう資格とは重視してないみたい。
年棒もよかったが、今の仕事が楽だから見送ったけどね。
ソフト開発でも取得して無敵モードに入りたい。

659 ：仕様書無しさん：04/06/19 16:22

１種なら持ってるが、それで無敵なのか？

660 ：仕様書無しさん：04/06/19 16:24

なんで喪前らはそういう個人レベルの話しかできないんですか？

661 ：仕様書無しさん：04/06/19 16:25

>>658
外から話が舞い込んでくるのが本当なら、
別にソフ開など必要ないし、とっても無敵モードになるわけが無い。

取得したら無敵モードになれると思っている時点で、
オファーがあったのがウソだということがバレバレです。

妄想癖を直して、初級シスアドの勉強でもしてなさい。

662 ：仕様書無しさん：04/06/19 16:26

ソフ開＝プロダクションエンジニア＋1種

663 ：仕様書無しさん：04/06/19 16:26

初級シスアドに合格して、会社から１０万円の報奨金が出た。
すごいでしょ！　正直驚いた。

これからは毎年２回、初級シスアドを受験する予定です。

664 ：仕様書無しさん：04/06/19 16:28

>>662
１種とプロダクションエンジニアの２つとも合格するほうが難しいです。

プロダクションエンジニアが不人気だったので、
レベルを落として統合したというほうが正しい。

665 ：仕様書無しさん：04/06/19 16:30

情報処理試験の種類が多すぎる。
昔は２種・１種・特殊・オンラインの４つだけだった。

今の状態じゃ、いくら取得しても追いつかない。

666 ：仕様書無しさん：04/06/19 16:30

資格手当の種類が増えるから俺は歓迎だけどな。

667 ：仕様書無しさん：04/06/19 16:32

>>593
その前にぃ、要件を完全に網羅し、かつ矛盾の無い仕様書を書けてるのか？

668 ：仕様書無しさん：04/06/19 16:34

ああいう資格を作成している奴とか、ここみてるだろ？

ＨＩＴＡＣＨＩうぜぇーよ。

あの問題賢いポチのなり方の問題だもんな。帝王学でもなんでもない。

669 ：644：04/06/19 16:37

問い２、
あなたが部下を持つことになりました。しかも部下を選べます。
選抜するための試験問題を１問だけ出題できます。どんな問題ですか？

670 ：仕様書無しさん：04/06/19 16:38

資格ってスキルがない人が企業に売り込むための印籠でしょう
昔からやっているような↓な人は
>全く資格が無くいが特別優秀な人というのは、転職先を探すということはありません。
>条件の良いオファーが向こうから飛び込んでくるから、それに乗るだけなのです。

資格なんてないと思うよ。
資格試験教材が出る前にそれらの技術をマスターしているからね。

671 ：仕様書無しさん：04/06/19 16:39

俺はキングになりたい。

キングになる奴は資格をたくさん取るだろうか？
資格は、商品価値を高める付加価値であって
あなたという商品にオプションで付いている売り物でしかない。

俺は意思を持ったバイヤーになりたい。

672 ：仕様書無しさん：04/06/19 16:42

>>656
メモリを沢山乗せていても
フラグメンテには注意ね。

673 ：仕様書無しさん：04/06/19 16:42

資格をたくさん取りたい椰子は己の自信のなさを提示しているかのようだ。
資格は、判断基準に迷う場合の道標になるだけであり
あなたという商品が誰がみても優秀ならばなにもいらない。

俺は自分で仕事を選択出来るのを誇りに思っている。

674 ：仕様書無しさん：04/06/19 16:47

もまいらもちつけよ流れ速杉

675 ：仕様書無しさん：04/06/19 16:48

部下の能力を判断できない上司に対して、自分の能力を誇示するという意味がある。
少なくとも、基本情報すら合格できない無能な上司に対しては・・・

そういう上司ほど、資格をありがたがるのです。

676 ：仕様書無しさん：04/06/19 16:53

>部下の能力を判断できない上司

こんなのにあれこれ言われて
喪前らかわいそう杉だな

677 ：仕様書無しさん：04/06/19 16:59

つまり自分で開業しろって事だ。

678 ：仕様書無しさん：04/06/19 17:17

>>629
派遣会社や人材紹介会社になめられてるだけでしょ？

679 ：仕様書無しさん：04/06/19 17:22

高度情報処理については、ある程度評価してる。
DBスペシャリストなら、ある程度はDBの基礎知識があるとみなせる。
NEもしかり。

基礎開と基本は何の判断基準にもならない。

680 ：仕様書無しさん：04/06/19 17:30

SunのJava認定試験じゃだめですか？
http://sedap.sun.com/JPN/certification/javamain.html

681 ：仕様書無しさん：04/06/19 18:38

>>624
あのさ、自動車の運転免許を取るのに大卒の資格が
必要か？
弁護士になるのに漢字検定やパソコン検定の資格が
必要か？

そういうことだろ。

682 ：仕様書無しさん：04/06/19 18:43

>>681
資格が必須な職種もあるけどな。
ちなみに、弁護士もその１つ。

683 ：仕様書無しさん：04/06/19 18:46

>>680
いいと思う。
でもプログラマだけまともでは不十分。
要件定義や設計するヤツにもこの資格が必須。

684 ：仕様書無しさん：04/06/19 18:48

>>682
だからそういう意味じゃなくて。
その業務にとって必要なことを満たしているかどうかの資格なら
意味があるが、単に「このレベルの資格が取れる知能があるか
どうか」を見るために資格を必須にしようなんて考えは
馬鹿げてる、ということ。

そりゃ弁護士が漢字もろくに書けなければ仕事にならんけど、
だからといって漢字検定必須にしたりしないだろ。

685 ：仕様書無しさん：04/06/19 19:05

>>684
´_ゝ`）　設計にはプロ倉民具スキル不要と言いたいのですね

686 ：仕様書無しさん：04/06/19 19:06

>684
言いたい事は解るが喩えがまずい。

漢字が読めないような奴は司法試験受からないので弁護士にはなれないし、
学者からの弁護士資格取得も無理だろう。

687 ：仕様書無しさん：04/06/19 19:07

>>681
車を運転するためには運転免許が必要だし、運転免許の取得は
１８歳以上である必要がある。

688 ：仕様書無しさん：04/06/19 19:12

>685
速いクイックソートの実装方法なんかのスキルは不要

689 ：仕様書無しさん：04/06/19 19:19

資格とか試験問題って解くだけでも為になるし、全くの無駄ではないと思う。
だけど、現場で起こる事象や問題は、流行の言語とか手法とか関係なく、
またどんなOSだろうと容赦なく起こる。問題の次元が全く違うんでない？

資格試験では「流行」とか「よく起こりうる」問題を解決するスキルを養い、
現場では「特異」とか「滅多に起こらないが結構致命的」な問題を解決する
スキルを養う。

と俺は思ってるよ。

今は、そうやって得たスキルを全く理解出来ない奴ら(管理者とか営業)を
如何に撃退するかというスキルをそろそろアップさせたいがな。

690 ：仕様書無しさん：04/06/19 19:20

ついにここまで資格業者が出張ってきたか・・・

691 ：仕様書無しさん：04/06/19 19:40

>>686
だから「漢字検定に合格する能力がないから漢字検定を
持っていない」んではなくて「弁護士になるのに漢字検定は
いらないから持ってない」ってのはあり得るでしょ。

692 ：仕様書無しさん：04/06/19 19:42

>>資格試験では「流行」とか「よく起こりうる」問題を解決するスキルを養い、

違うよ。

資格試験は「時代遅れ」で「もう使われていない」技術を暗記するスキルを養うものだ。

無駄。

693 ：仕様書無しさん：04/06/19 19:47

卒業生が最先端

694 ：仕様書無しさん：04/06/19 19:51

参考図書持ち込みおよびネット利用が可能な資格試験なら
少しは実際の業務に近い能力が測れるかもしれない。

695 ：高卒アニオタ中年：04/06/19 19:51

資格があると何が便利かというとだな。
実力を示す機会がなくとも、ある程度のスキルを証明できることだ。

たとえば、何らかの仕事を請ける場合、
「組み込み系ネットワーク機器の仕事を何年やっていました」
とだけきいても実力にはピンからキリまで開きがある。
そこで、情報処理技術者試験のEMとNEを有していれば、
少なくとも専門知識を覚える上での基礎は身につけているとの証明にはなる。
(過去の実績の裏づけになり、説得力が増す)

会社として仕事を請ける場合もそう。
納入実績を示すだけではなく、「全員が情報処理資格取得者」などと
書くことができれば、相手に対してのセールスポイントになる。

実力があるやつは、実力を簡単に証明したいから資格を取るんだよ。
実力があるのなら、資格を取るなんてたいした手間じゃない。

まあ、>>692のように、資格すら取れない香具師が
何をほざいても悲しいだけだよな (w

696 ：仕様書無しさん：04/06/19 19:53

実力がなくても、資格を取るなんてたいした手間じゃないよ。

697 ：仕様書無しさん：04/06/19 19:59

>>659
その手の説明はし尽くされている。
みんな知ってて反論してるんだから、いいじゃん、ほっといてやれよ。

698 ：仕様書無しさん：04/06/19 20:03

>>695
その意見に賛成だね。
外注でとんでもないのを見るにつけ、基本情報すら無いやつは出入り禁止にしたほうがよいと思う。
もちろん、基本情報もっていてもとんでもないのもいるけど、
持っているやつと持っていないやつとの間には、DQN発生率において大きな隔たりがあるのも事実。

かといって、メンバー全員が最低ソフ開という条件を付けると、妥当な費用では人が集まらない。

開発要員大量投入の時は、SIerはDQNを混ぜ込んでくるので、そのような条件を付けることが寛容かと思われます。

699 ：仕様書無しさん：04/06/19 20:28

>>698
同意。
Java使える奴３人と言ったら、一人だけ口がうまいだけで
Java使ったことがない奴が混じっていた。
まあ、俺が面接に参加出来る権限を持ってないのが、全ての
原因だったのだが。

700 ：仕様書無しさん：04/06/19 20:31

仕事を受注するという観点から見れば695に同意できるんだが、
実際に現場で仕事をする場合には、資格はあまり意味をもたないのも事実。

つまり、

資格は必要だ → Sヨ
資格は不要だ → コーダー

という位置付けでOK？

701 ：仕様書無しさん：04/06/19 20:33

条件を厳しくするのが寛容というのは、
何か逆説的な補遺でもあるのだろうか
(DQNが来たら必ず手足へし折って叩き出してるとか)

702 ：仕様書無しさん：04/06/19 20:37

>>701
肝要の間違いだと思うよ、多分

703 ：仕様書無しさん：04/06/19 20:41

2chで誤字を指摘してもしかたなかろ

704 ：仕様書無しさん：04/06/19 20:43

>>703
>>701の意見は、「寛容」だから出て来たものだと思ってな
おめーには向けてねえから無視してくれや

705 ：高卒アニオタ中年：04/06/19 20:52

>>700
まあ、業務の作業の役に立つかどうかという点で、
資格の有無で差異がないということには同意。

ただ、仕事をする上で、
自分の実力を証明できる手段があったほうが
有利になることも多いのは事実。

コーダーだろうがなんだろうが、持っておいて損は無いと思うぞ。

たとえば、やりたい仕事に関係する資格を集めておけば、
おのずとそれ関係の仕事が入ってくるようになるし、
仕事を遂行する上での発言力も高くなる。

資格はとるのが目的じゃない。
活用してこそ価値があるんだから、自分に合った資格をとる事が大切。

コーダには、コーダのための資格があるんだから、
そのあたりを上手い事活用してみ？

706 ：仕様書無しさん：04/06/19 20:59

>>693
京コンＯＢ発見！！

707 ：仕様書無しさん：04/06/19 21:08

京都コンピューター学院か懐かしいな
西沢学園のＣＭまだやってるのかな

708 ：仕様書無しさん：04/06/19 21:17

そもそも使えない奴が入ってくるのを資格のせいにしようという
考え方がおかしい。

「DQNの峻別が難しいから、資格でスキルを証明しよう！」

なんて確実性の無い対策を打ち出すくらいなら、
面接に現場のPGを同席させるように管理職を説得するほうが先だろ。

あ、君たちは派遣だから面接やっちゃうと違法なんだっけｗ

709 ：仕様書無しさん：04/06/19 21:17

あだまうろ

710 ：仕様書無しさん：04/06/19 21:20

>>708
・・・と、無資格のDQNが騒いでおります。

711 ：仕様書無しさん：04/06/19 21:25

>>709
あの中年白人女性はなんなんだ？社長の愛人？そんなのＣＭに出すわけないか

712 ：仕様書無しさん：04/06/19 21:34

>>711
ttp://www.globetown.net/~herige/hanmei.html

713 ：701：04/06/19 21:36

>>702
ﾋｻﾞﾎﾟﾝthanks

俺自身が逆説の徒というか、言葉をオブラートに
異物と一緒に包む人なので、本気で括弧内考えたヨ

714 ：仕様書無しさん：04/06/19 21:42

>>712
ありがとう
次、タケモトピアノのＣＭで（ｒｙ

715 ：仕様書無しさん：04/06/19 21:45

資格よりコネの方が確実。

716 ：仕様書無しさん：04/06/19 21:49

>>714
ドカタとしての自負がまだ残ってるなら自分で調べれ。

717 ：仕様書無しさん：04/06/19 21:50

>>715
それ、ますますプロスキに関係ない。
つか、もう就職の話はどうでもいーじゃん。

718 ：仕様書無しさん：04/06/19 21:57

いや、コネで紹介される方が的確にスキルを反映してるよ。

719 ：仕様書無しさん：04/06/19 22:04

>>718
根本的に頭わるいだろ
紹介する側はどうやってスキルを把握すんだよ

720 ：仕様書無しさん：04/06/19 22:06

そりゃ、一緒に仕事してればわかるだろ。

721 ：仕様書無しさん：04/06/19 22:19

>>720
派遣会社の営業ではなくて、派遣ＰＧに紹介してもらえってこと？

722 ：仕様書無しさん：04/06/19 22:22

>>720
その前に撥ねなきゃならんだろ。
契約上そうなってるし、法律上本当は事前面接だって
だめだったはず。
基本情報処理なんて業務やってる人間だったら誰でも
取れるんだから、とんでもない奴だけ落としてくれればいい。

723 ：仕様書無しさん：04/06/19 22:57

ところで資格持ってる奴ってみんな仕事できるの？

724 ：仕様書無しさん：04/06/19 23:00

>>723
それは言っちゃだめｗ

725 ：仕様書無しさん：04/06/19 23:01

アホが来ると人命にかかわるから、などの理由で
資格取得を法律で定めている職種を考えてみる。

司法試験とおったから　弁護士として一人前か？
国家試験とおったから　医者として一人前か？

んなこたーない。ただのスタートラインだ。
医者も弁護士もピンからキリまでいるけど
「資格もってるのに実務で役に立たない」とか程度低いこと
言ってる奴は誰もいないよね。なんでだろーね。謎だね。

726 ：仕様書無しさん：04/06/19 23:01

資格は役に立たないってところはみんな同意なんだろ？

もってないよりかまし、とか
最低ラインがなんたらかんたら、とか
ホントにプログラマなのかと思う。

資格なんて実力の証明になんてまったくならないじゃん。
いっとくけど、最低ラインも切れないよ。
プログラム組む能力と全く無関係。

努力がとうとかの話を持ち出す奴がいるけど、全然違う話じゃん。
むしろ方向性の間違った努力をする奴は邪魔じゃん。
そもそも努力とスキルは比例しないじゃん。（これ重要）

まあ、会社によっては資格持ってると、
給料が上がるとかあるならまだ理解できるけど、
実務にはなんの役にも立たないじゃん。

現場の俺等がそんな資格なんて認めちゃっていいのかよってことじゃん。

何度もいうけど努力を評価してはいけないじゃん。

727 ：仕様書無しさん：04/06/19 23:03

>725
「資格もってないのに実務で使える」奴がいないからだろ。
おおっぴらに活動してるモグリの医者とか弁護士が見当たらないからな。

728 ：仕様書無しさん：04/06/19 23:06

>>726
確かにコーダには必要のない知識だな　それは認める

729 ：仕様書無しさん：04/06/19 23:13

とりあえず、資格よりもプログラミングテクニックをもっと評価すべき、というスレタイに
沿った結論が出たところで(出ていなくても)次のネタお願い。資格ネタはもうお腹いっぱい。

730 ：仕様書無しさん：04/06/19 23:20

>>725
腕の悪い医者や弁護士はたくさんいると思うが。

731 ：仕様書無しさん：04/06/19 23:21

プログラムできる奴ってさ、やたら細かくない？
話してて、人が用語ちょっと間違うさ、余裕で脳内補完できるくらいの間違いでも、
鬼首取ったような顔して話の腰折るじゃん。
もう、人としておかしいんだから評価されなくて当然だと思うよ。
皆さんの周りにもこういう人いません？

732 ：仕様書無しさん：04/06/19 23:22

>>729
だいぶ都合が悪くなってきたみたいですね。

余程のｱﾌｫじゃない限り取れる資格を取れないのだから、
ある意味可哀相な人なのですね。
ご同情申し上げます。

733 ：仕様書無しさん：04/06/19 23:22

いません

734 ：仕様書無しさん：04/06/19 23:24

>>727
俺はゲーＰＧだけど
みんな資格もってないよ。
でも、３Ｄや物理演算とか業界全体で水準が高いよね？

こんな感じで満足かな？

735 ：仕様書無しさん：04/06/19 23:27

>>731
職業上、細かいことに拘るのは事実だが、それが日常生活にも及ぶってことは
少ないと思う。デスマ中なら話は別だが。

736 ：仕様書無しさん：04/06/19 23:28

>>732
だから、お前、業者に踊らされてるって気が付かないの？
それとも必死でとった資格が糞扱いされてキレちゃったｗ？

737 ：仕様書無しさん：04/06/19 23:29

>>731
他人の間違いに慣れてないのか、どちらかというと
プログラム書かない奴の方がそういうの多いと思うぞ。

738 ：仕様書無しさん：04/06/19 23:32

>>737
なあ、俺等いつもバグ出す側だしなぁ。
結構、間違いには寛容だと思うんだけど。
マ板もム板も重箱の隅をつつく奴って少ないけどな。

739 ：733：04/06/19 23:33

いや、、、ひょっとして「できる奴」と
仕事したことがないのかもしれん、、、

>>731
あなたがひょっとしてかなりミスの少ないできる人で、
他人の（結構ヤバい)ミスに気付いて指摘を繰り返してると、
少ないミス(どころか用語の互いの意味違い)まで指摘
してくる、ということはよくある。

ミスを指摘されて本気でありがとうと思うのは、
本当に人間ができているか、信頼関係が本当に進んでないとない
普通は反射的に反発している

740 ：仕様書無しさん：04/06/19 23:33

>>734
その分、コードは汚い。
汚くても良いのだから、汚くなるのは当たりまえ。

でも、ゲームＰＧが身なりまで汚くなるのは、見ていて見苦しいよ。
一部を除いて給料も安いみたいだしね。

741 ：仕様書無しさん：04/06/19 23:41

>>736
お前は真性ｱﾌｫか？

ｱﾌｫ資格は誰でも取れるんだよ。普通の知能があれば。
そんなのは誰も自慢していないし、自慢すること自体が恥ずかしい。
俺は普通自動車免許持ってるんだぞぉ～　並に恥ずかしいことだ。
しかし、それすらも取れないｱﾌｫは不要だと言ってるんだよ。

742 ：仕様書無しさん：04/06/19 23:43

>>739
同じように指摘しても「アドバイスをもらった」と受け取るやつと
「いちゃもんつけられた」と受け取るやつがいる。
伸びるやつは当然（ｒｙ

743 ：仕様書無しさん：04/06/19 23:44

仕事できる奴は試験形式とか出題ポイントとかちょっと勉強すればすぐ資格なんか取れる
ただその「ちょっと勉強すれば」が社会人には難しいし果たしてそれ程の価値もあるものかと
いうところだ。

744 ：仕様書無しさん：04/06/19 23:45

ちなみにこういうＳＥさんが居た。かなり昔の話だが、、
情報処理一種その他色々の資格をもっていたＳＥさんなんだが、
彼は古い技術から最先端の技術までの膨大な知識量を持っていた。
もちろん言語仕様にも精通していてその記憶力は正確。誰が見ても優秀なＳＥ。
ただ唯一の難点は彼はプログラミングが書けないって事。
書かないんじゃななくて書けない。いや、書くことはできるんだけど初心者レベル。
動くものを作るまでに人の数倍は時間が掛かる。
自分でもプログラミングが苦手という意識はあるらしく、彼はコードを書くはおろか
見る事すら避けながら働いてたよ。しょうがなくコーディングしなければならなくなった
場合は真っ赤な顔して唸りながらモニタに向かってた。

これは実話だよ。ちなみに某ランドでの話だよ。
知識量だけでは実装力を測れないという事をこの時初めて確信したよ。

745 ：仕様書無しさん：04/06/19 23:45

>>731
プログラムできるから、ちと天狗になってるヤシなんでは？
20代前半とかの若いPGなら結構いそうだが。

746 ：仕様書無しさん：04/06/19 23:49

>>745
そういのは、徹底的に叩きのめしといた方がいいな。

747 ：仕様書無しさん：04/06/19 23:49

>>743
難しいのか？
情報処理の基本やソフ開レベルを受けることがそんなに社会人には難しいのか？
たった一日、試験日の日に予定をあければ取れるだろう。
もしかして、わざわざ勉強しないと取れないと思ってるのか？

748 ：仕様書無しさん：04/06/19 23:50

>>744
それだけ頭が良くて人並みにすら
できないというのは謎だな。

749 ：仕様書無しさん：04/06/19 23:50

だりぃ

750 ：仕様書無しさん：04/06/19 23:52

>>747
うちの会社なんて土日休むと怒るぜｗ

751 ：仕様書無しさん：04/06/19 23:55

なんで資格の話にすり変わってんだよ？　無資格者ファビョりすぎ。
黙殺しとけばいいだろうに。

752 ：仕様書無しさん：04/06/19 23:57

常にくだらないほうに話がすすむのがこのスレの一番の特徴。
こんなんで評価して欲しいと言ったところで・・・

753 ：仕様書無しさん：04/06/19 23:57

>>740
いつの時代のゲーＰＧの話してるの？
開発に参加してみりゃわかるけど
いまは３Ｄオブジェクトの管理やイベントの管理やらで
かなり設計が上手くないとゲーム作れないぞ。
コード汚なくて作れるもんじゃねぇよ。
DirectXSDK落としてきて、ソース見てミロよ、ハゲ。

それに一番ＯＯにとっつきやすいのって多分ゲーＰＧだぞ。
シューティングゲームとか作るときにＯＯが自然に身につくって
いう旨みもある。

754 ：仕様書無しさん：04/06/20 00:03

>>753
で、身なりはどうなの？
給料はどうなの？

755 ：仕様書無しさん：04/06/20 00:04

はぁ。
結局このスレに集まってくる香具師は、
ｱﾌｫ資格すら取れない妄想癖のコーダ君達ばかりってことですね。
ラベルが低すぎつ。

756 ：仕様書無しさん：04/06/20 00:06

>>754
身なりはボロ雑巾。
給料は激安。

>>755
じゃあ、もう、くんなよ。
大事な資格、枕の下に入れてもう寝ろｗ

757 ：仕様書無しさん：04/06/20 00:12

そういや、なんかくれるんだったっけ。
昔、当時の一種(と二種)取ったときになんか来たような記憶があるんだが
完全に紛失してるぞ。

758 ：進捗報告：04/06/20 00:15

本日の進捗 2004/06/19(土)
■全体の進捗率：75.3%

■作業内容
　・資格の有効性についての打ち合わせ。

■参考資料
　・>>568-753

#つーか、マ板で1日で185レスかよw

759 ：仕様書無しさん：04/06/20 00:18

>>757
あれって再発行してくれないんじゃなかったっけ。　たまに証書のコピー要求する
客とかいるから俺は大事にとってある。

760 ：仕様書無しさん：04/06/20 00:22

>>758
虫の火星祭りの時は1スレぐらい消費したぞｗ

761 ：仕様書無しさん：04/06/20 00:25

>>742
昔CADで描いた回路の自動検証プログラムをしていたことがあるが、
Error Reportをして、
「いや、そんなはずはない、ちゃんと描いた」
と言わなかった大卒以上は居なかった、、、

俺も最初は、
「ちゃんと描いたつもり、とちゃんと描かれてるのは違うんだよぉ！」
とか吼えてたが、後の方になると
「そうだねぇ(・∀・)じゃあ座標○○××のところを一緒に見てみようか」
自信満々→愕然、というのを見るのが楽しくなりました。
歪んでしまったよママンorz

762 ：仕様書無しさん：04/06/20 00:27

>>761
歪んでないって。
そーやって、心の中でバカにしつつ顔は笑顔。
人を上手に使うのですよ。

763 ：仕様書無しさん：04/06/20 00:29

>>761
なんでその文脈で「大卒」という言葉がでてくるのか。

764 ：仕様書無しさん：04/06/20 00:30

「資格」の次は「学歴」かよ。

765 ：仕様書無しさん：04/06/20 00:32

で、プログラミングスキルの話は？

766 ：仕様書無しさん：04/06/20 00:32

文章見ればわかるだろ
かなりのあほだほっとけ

767 ：仕様書無しさん：04/06/20 00:39

プログラミングスキルを重視しない人間の発想
・オレＰＧスキル低いから要件定義／設計しかしないよ
・要件定義／設計に問題があると分かってるならＰＧが直してくれよ
・あとで自分が困らなくて済むんだからタダでやってくれてもいいだろ
・要件定義／設計ぐらいやらせてくれなきゃオレ仕事無いよ
まとめると、他人への依存心と幼児性が強い役立たず。

768 ：761：04/06/20 00:42

>>762
ありがとう
まーそういうことがあった方が以後スムーズでしたね。

>>763
特に資格持ちがいないのと、
マジできれいにそこで分かれたから。

>>764
う、、、荒れる話題だったな。スマン。

ミスとプライドに関する話題だったとご理解ください。

769 ：仕様書無しさん：04/06/20 00:45

*/

ここまでは全てコメント行として扱われます。

770 ：仕様書無しさん：04/06/20 00:51

>>769
そっちだけ書いたり残ったりするのは極めて迷惑で嫌われる

771 ：仕様書無しさん：04/06/20 00:58

プログラミングスキルを重視しない人間というかＳヨの特徴
・厚顔無恥
・コスト意識ゼロ
・頭が悪い
ようはゴミ

772 ：仕様書無しさん：04/06/20 01:02

　　　　　　　京都　　　　　　名古屋
神戸　大阪　　奈良　　　　　　　　　　　　　　　　　東京
　　　　　　　橿原　　　　　津　　　　　　　　　　　　横浜
　　関空　　　　吉野　　　伊勢　
　　和歌山　　　　　　　　　　　　　　　　静岡

初代首都、橿原に先端工場を。

現在では６０万人の中心として法律に指定され、
今年高速道路が出来、２年後にも高速道路が出来、
紀伊半島の中心、そして、東と西日本をつなぐ要所です。

奈良県行政よ、補助金を出せ！！官公庁も作らないで

773 ：仕様書無しさん：04/06/20 01:09

このスレを潰そうとしてる人間というか荒しの特徴
・2～3回連続で書く(複数人を装う?)
・まともな会話ゼロ(相手しようとしている人も無視)
・誰かをｱﾎと言ってるだけ(理由なし)
評価はまかす

774 ：仕様書無しさん：04/06/20 01:15

>>771
じゃあＰＧだけで作ってろや

775 ：仕様書無しさん：04/06/20 01:19

>>774
それ禁句だな。

776 ：仕様書無しさん：04/06/20 01:22

｢出来ない奴ほど優遇される｣　ある意味真理である。

出来る奴の方がそうでない奴より少なく、出来ない奴は出来る
奴が優遇される事によって、自分達の待遇が相対的に下がる
事を何より恐れる。

よって、出来ない奴らは自分達の方が有利になる様に、徒党を
組んで出来る奴が不利になる様に仕向けていく。

その結果、出来る奴は現場で搾取され続ける事になる。　これが、
現場軽視のこの国の姿。

777 ：仕様書無しさん：04/06/20 01:27

>>774
その意見はぜひリアルな世界でも発表して欲しいですな
ＰＧからは歓迎されると思います

778 ：仕様書無しさん：04/06/20 01:29

そろそろ、できる奴→現場から退場、というところまで
圧力が高まってない？
それとも、ニューカマーにもできる奴は一定割合
居るので完全な空洞化は防がれるというお考えか？

779 ：仕様書無しさん：04/06/20 01:31

>>776
会社は年金のことでもうヤバイのよ。
できるヤツにできないヤツぶら下げとく時代じゃないわけよ。

780 ：仕様書無しさん：04/06/20 01:36

できない奴ってサービス残業してれば置いといてもらえると思ってない？

781 ：仕様書無しさん：04/06/20 01:37

>>779
会社にとって

できる奴　　　　　　　　　できない奴
　　｜ﾌﾞﾗｻｹﾞ　　＜　　　　　　｜
できない奴　　　　　　　　できる奴

になる理由を詳しくお願いします

782 ：仕様書無しさん：04/06/20 01:39

>>781
できる奴が責任取らなくて済む

783 ：仕様書無しさん：04/06/20 01:43

ウチ原則PGだけだ

弊害：
１：まとめ人が居ないので、1PJ/1PGになりがち
２：仕様書が無い
３：要素技術を一人当たりたくさん使うので、コピペ横行

コピペしてる割には、作法とかの交流が成されてなくて、
レビューとかも大変でございます。

SEというよりPL置けという感じがするが

784 ：仕様書無しさん：04/06/20 01:54

>>783
作ったＰＧ以外の者にソースから仕様書をリバースエンジニアリングさせるのがいいんじゃないでしょうか。
経験の浅い者にやらせればスキルアップも期待できそうですが。

785 ：仕様書無しさん：04/06/20 02:07

(=д=)ｴｴｴｴ
できない奴上になっても責任とってくれないヨー

786 ：仕様書無しさん：04/06/20 02:30

>>747
　ソフ開の試験問題、一度でも見たことあるか？
　あれほど実務から乖離した試験はないぞ。
　
　はっきり言って、取ろうと思ったらそのための勉強をしないと無理。

　実際、外資系（IBMとか）はこの手の国家試験は軽視してるそうだし。
　大学教授の業務に関する知識なんてあんなもんだ。
　

787 ：仕様書無しさん：04/06/20 03:06

>>763
ようするに、人から指摘されていちゃもんつけられたと思う奴は伸びるってことでしょ。

788 ：仕様書無しさん：04/06/20 03:09

実務から乖離しているのは、あなたが特定の製品しか扱っていないから。
普遍的なことを勉強しておくのも悪くないぞ。

789 ：786：04/06/20 03:39

>>788
　本当に試験受けたことあるのか？
　
　大半の問題は業務系を意識した内容だが、組み込み系としか思えない問題もあったり…

　一番問題なのは、試験時間だな。
　どこに１時間３０分で仕様を理解して云々…　なんてプロジェクトがあるのか。
　つまり、君が思っているように、普遍的に考えて問題を解こうとすると時間が足りなくなる。
　（「こういう問題にはこういう答え」というパターンを覚えないと受からないということ。）

　最後になるが、自分はいろんな業種、製品（開発ツールのことか？）で開発しきた。
　試験のレベル自体は低い。
　試験時間が十分あれば受かる自信はある。

790 ：仕様書無しさん：04/06/20 03:56

>>747の口ぶりは学生っぽいな。
まあ実務を知らないんだろうから、試験と実務の乖離なんて
想像できないんだろう。
だれでも学生のうちは学校で習ったことが世の中の基本だと
錯覚するものだからな。

養老ｾﾝｾｲが本の中で書いていたが、解剖の実習中に
実際の死体の内臓を見て「先生、これ教科書と違います」
って言った学生がいたそうだ。

791 ：仕様書無しさん：04/06/20 08:30

>>786
あなたの業務に関係ないからといって「実務から乖離」とか
言えちゃうんだ。

あそこに出てる問題は、一般常識なんだよ。
古い用語もあるけど、どこかで使われている一般的に使われているもの。

いいか。
君のための試験じゃないんだよ。あれは。
なんでそう自己中心的に考えちゃうのかな。

ちなみに。ＩちゃんだとＰＧ自体が優遇されてないからな。
君達の出番はないよ。
その代わり、ＰＭＰ資格とかのマネージメント系の資格が
優遇されている。
プロジェクトの進行にはＰＭＰの用語が使われる。
資格が優遇されていないわけではない。

>>789
だから。
トータルの一般常識なんだって。
君の狭い範囲では使わないかもしれないがな。
あんぐらい理解しとけよ。
それと。試験時間云々の前に。1時間もあれば終わるだろうが。あんなの。
パターンもくそも、選択に悩むような問題あるか？
もっと根本的な原因があなたにあるのでは？

>>790
たしかにコーダー君には関係ないかもね。
でも、あの程度の一般常識はこの業界にいるのなら知っておいたほうがいいのでは？

792 ：仕様書無しさん：04/06/20 08:48

優秀なPGは資格なんか取れるけど取らないだけなんだよ。
時間の無駄金の無駄ハッカー哲学などの諸所の理由によって。
その辺理解してもう絡まないでくれ。

793 ：仕様書無しさん：04/06/20 09:07

>>792
っということは、あなたは優秀なハッカーなのですね。
凄いでつねぇ～

っていうか。自分のことをハッカーとか言っちゃうぐらい
厚かましい人種もいるのですね。くわばらくわばら

794 ：仕様書無しさん：04/06/20 09:22

>>786
そりゃあどんな試験だってそれ用の対策を取ったほうが合格しやすい
だろうよ。別にソフ開に限った話じゃない。
でもソフ開はそれをやらんと受からんレベルでは決してない。

>>789
どうもあんたは業務系らしいが、だったらなおさらソフ開ごとき余裕だろ？
あれはかなり業務系よりだと思うぞ。
そりゃあ確かにあんなもんできたからって業務には役に立たんかも知らんね。
レベルが低すぎて。DB の問題なんか業務系をバカにしてるとしか思えん。

795 ：仕様書無しさん：04/06/20 09:27

>>792
ハッカー様お早ようございます。
朝から白昼夢とは大変ですね。

ところで。
私の認識しているハッカー像では、自分の評価なんて気にしない人だと思っていました。勉強になりました。
それでは良い白昼夢を！

796 ：仕様書無しさん：04/06/20 09:44

プログラマに資格は不必要だがSEには必要かもね。
実装工程を知らずにＳＥなる職務に辿り着けるパスが存在するからね。
技術無知なＳＥを弾く程度には参考になるとは思う。
ま、中途半端に知識を溜め込んでる輩が一番デンジャラスなのだがね。

797 ：仕様書無しさん：04/06/20 09:51

というか、俺らハッカー的プログラマは業務系の仕事なんか
しないからどうでも良い話だけどね。
ま、たまにシステムコンサルタントみたいな仕事した時に企業の
ＳＥっぽい人と顔合わせるくらいだよ。
普段は自宅か別荘でコードと睨めっこしてるよｗ
ちなみに今は軽井沢からｗ

798 ：仕様書無しさん：04/06/20 10:07

資格否定派は、

　　取れるけど採れない奴の数 >> 取ろうとしても取れない奴

と思ってるのか？

799 ：仕様書無しさん：04/06/20 10:08

× 取れるけど採れない奴の数 >> 取ろうとしても取れない奴
○ 取れるけど取らない奴の数 >> 取ろうとしても取れない奴

800 ：仕様書無しさん：04/06/20 10:14

資格資格とうるさいのは、資格に幻想を持つ引きこもりが混じっているからだろう。
資格なんかいくら取っても、それだけじゃ派遣会社の登録にしか役に立たないよ。

まあ一般論として会社が手当を出すところは、取っておいて損はないだろう。
会社にとって何の意味があるのかわからんが、おれなんか行政書士の資格まで取ってるよ（ｗ
スキルとはまったく関係がない話。

801 ：仕様書無しさん：04/06/20 10:15

いや、思ってないけどね。

802 ：仕様書無しさん：04/06/20 10:26

>>791
>あそこに出てる問題は、一般常識なんだよ。
>古い用語もあるけど、どこかで使われている一般的に使われているもの。

磁気テープの容量の計算とかフローチャートの穴埋めとか、
確かに「古いけど基本」だな。

勉強するのはバカらしく思えるけど。

803 ：仕様書無しさん：04/06/20 10:40

結局このスレはくだらない話で落ち着くわけねｗ

804 ：仕様書無しさん：04/06/20 10:41

現在、バックアップで一般的に使われているメディアの種類を述べよ。

805 ：仕様書無しさん：04/06/20 10:46

>>804
今でも磁気テープだよ。さすがにオープンリール型はもう化石同然だが、
カートリッジ型の奴は、今でも現役だろ。

806 ：仕様書無しさん：04/06/20 10:46

DDS2あたりが無難。

807 ：仕様書無しさん：04/06/20 11:03

テープメディアのテクノロジが蓄積データ量の増加と
ハードディスクの容量増加に追いついてない。
価格や安定性はともかく、制限時間内にバックアップを
終えにくくなってきた。

808 ：仕様書無しさん：04/06/20 11:06

テープドライブの制御プログラムなんて書く機会めったに無いよな。

809 ：ＩＮＴ３：04/06/20 11:17

>>797
　おれも軽井沢に別荘を買った。
　ピリンスＨから、しなの鉄道の反対、北側だ。
　新聞屋の角を北にまがって、ゴミ置き場（コンクリで
　かこまれている）をすぎて（３０メートルぐらい）、
　ななめ左に小さい未舗装の入っていける路があるでしょ？
　そのあたりなんだ。

　今東京だが、おれが軽井沢に行ったときには、
　よければおれの別荘にも遊びに来てくれよ。
　小さな別荘で恥ずかしいけどな。

　でも、あれだな、ハッカー的プログラマって何だね？
　プログラマならハッキングできるのは当然として、
　ハッキングで飯食うとしたら、業務的な依頼も多いと
　思うがな？
　どういう仕事してんのか教えてね。
　おれは何でも屋だ。

　よろしこ！

810 ：仕様書無しさん：04/06/20 11:20

多分ＰＧに資格は不要というのは正しいかもしれない。資格を証明する相手がそもそも居ないからね。まあ、ソフ開くらい持っててもらいたいもんだが。
ＳＥに資格は不可欠といっていい。基本くらい持ってないと顧客先で「取らないんですか？」みたいに言われるのがうざい。いろいろ持ってたほうが、話がしやすい。仕事が取りやすい。ＰＧに仕事を持っていってあげやすい。
元ＰＧ現ＳＥで、資格不要説を説いていた奴は納得しないらしいが、社会は彼らを受け入れてくれるキャパシティはまだ無い。素直に資格取ってくれ。

811 ：仕様書無しさん：04/06/20 11:23

>>800とかは基本情報処理も取れない糞みたいな奴なんだろうな。
医師や弁護士免許は実務には役に立たない、なんて言っても
最低限のレベルを上げるために実際に存在する。
底辺を切り捨てるために必要なわけだ。

実際に出来ないにしても、基本情報処理のようなレベルの低い資格
も取れない糞は、業界から去って欲しい。

812 ：786：04/06/20 11:27

>>791
　おまえ池沼か？
　誰が「理解していない」なんて書いた？
　でたらめを書くな。

>それと。試験時間云々の前に。1時間もあれば終わるだろうが。あんなの。
　時間一杯で見直す時間すらなかった。
　お前さんは仕様書いてそれを見直すことすらしないのか？

>>794
　誰が「解けない」なんて書いた？

　自分は業務系の人間だよ。
　で、問題＆試験方法が馬鹿らしいので一度受けて意欲が失せた。
　途中でヤニ吸えないのも辛いし。

>>811
　資格と免許を混同するな。
　免許は許可証だ。

791、794共に、とりあえずレス付けるならちゃんと読んでからにしてくれ。

813 ：仕様書無しさん：04/06/20 11:34

>>812
>自分は業務系の人間だよ。
　で、問題＆試験方法が馬鹿らしいので一度受けて意欲が失せた。
　途中でヤニ吸えないのも辛いし。

ちょっとおかしいんじゃね？

814 ：高卒アニオタ中年：04/06/20 12:51

>>812
とれない香具師が何をほざいても所詮は負け犬。

「その気になれば俺はすごいんだぞ」と言う香具師に限って、
結局何もできないのが常。
本当にできるやつは、その気になった「結果」を出してくる。

お前も技術屋の端くれならちったあわきまえろ。
自分の知らないことを知った風に「簡単だよ」と言い放つのは
この業界の人間としてはかなり恥ずかしいぞ。

根拠の無い主張は聞き入れてもらえねーぞ？
資格なんて簡単だとまで言い放つのなら、
資格を取れるだけの実力があることを証明できるようになれ。
話はそれからだ。

815 ：仕様書無しさん：04/06/20 13:09

資格ひとつも持ってなくて、スキルも低くて仕事遅れまくりだったあいつがＵＭＬの認定試験に受かったとたん見違えるほど有能に
　
　　
　　　
なることはなかった…

816 ：仕様書無しさん：04/06/20 13:26

しかし、自分の実力の無さを真摯に受け止め、努力することに目覚めた彼は
見違えるほどの実力をつけ、あらゆる面に能力を発揮し始めた。

817 ：786：04/06/20 13:30

>>814
>自分の知らないことを知った風に「簡単だよ」と言い放つのは
　ちょっと待ってくれ。
　いつこんなこと書いた？

　意味の無い「資格」で「結果」を出そうとは思わないだけ。
　仕事では「結果」を出しているし、（出向先の）マネージャにも評価されている。
　
　学生時代に二種とシスアド取ったが、役に立ったと思ったことは一度も無いね。
　だから、一種（ソフ開）には期待していたが、期待はずれだったということ。

　資格そのものが無意味とは思っていないが、本当に意義があると思える
　資格と出会ってないということ。

自分の書き方が悪いのか分からないが、うまく伝わらないみたいなんで
ＲＯＭにもどります。

818 ：仕様書無しさん：04/06/20 13:32

>817
頼む一生ROMっててくれ

819 ：仕様書無しさん：04/06/20 13:35

＞自分の書き方が悪いのか分からないが、うまく伝わらないみたいなんで
＞ＲＯＭにもどります。

その言葉絶対忘れるなよ
約束守れよ

820 ：644：04/06/20 13:43

いいことかんがえた。

グーグルみたいにリンクを受けた数とリンク元の質で評価が決まるプログラマー評価ネットワーク。

821 ：814：04/06/20 13:43

>>817 いつこんなこと書いた？
　>>789 試験のレベル自体は低い。
　>>812 誰が「解けない」なんて書いた？
いたるところにかかれてるが・・・？

まあ、資格自体に価値が薄いというのはおおむね同意。
が、そこまでソフ開が簡単すぎて意味が無いと思っているなら、
高度情報処理試験の一つでもとってみるべきじゃないか？

あと、一種とソフ開はかなり変っているのでそのつもりで。

822 ：仕様書無しさん：04/06/20 13:58

いやはや。
786君は自分の無能さを必死にアピールしてなにが楽しいんでしょうかね。プレーの一種？

823 ：仕様書無しさん：04/06/20 14:00

負けを認めてもう出てこないと言ってんだから蒸す返すな

824 ：仕様書無しさん：04/06/20 14:02

>>816
しかしプログラミングスキルにおいては遂にHelloWorldの域を出ることはなかった

825 ：仕様書無しさん：04/06/20 14:05

資格自体にはさほど意味がないが、底辺を切り捨てるのにはかなり有効だ。
資格すら取れない、資格の勉強もしない奴を切り捨てるのに、明確なラインになる。

826 ：仕様書無しさん：04/06/20 14:14

まぁ、身内の贔屓目な評価だけじゃなく、客観的（とされている）な立場の評価も参考にするてことで。

827 ：仕様書無しさん：04/06/20 14:14

そういう意味で学歴と一緒だな。
旧帝大工学部卒＝優秀ではないが、そこに合格するだけの努力とやる気は
過去にあったという指標にはなる。

828 ：仕様書無しさん：04/06/20 14:15

>>817
お前のように、「余裕で取得する実力はあるが、あえて取得しない」
みたいな態度でいるヤツは、うそぶいている無能なヤツと幹部には映るんだよ。

だからお前みたいに出向に出されるんだよ。

まあ、その幹部達の評価はだいだい正解なんだけどね。

829 ：仕様書無しさん：04/06/20 14:16

受験するだけの機会があるのに受けない、合格しない、ではどうしようもない。

830 ：仕様書無しさん：04/06/20 14:16

> 旧帝大工学部卒＝優秀ではないが、そこに合格するだけの努力とやる気は

自分との違いは、努力とやる気の違いと思いたいのかｗ

831 ：仕様書無しさん：04/06/20 14:19

>>830
いや、俺も一応旧帝大だし、上であえて取得しないといってる奴とは別人だが、
旧帝大でてもどうしようもないのは確かに存在する。少ないけどね。
目安にはなる。

832 ：仕様書無しさん：04/06/20 14:21

資格問題については、
「ﾌﾟﾛｸﾞﾗﾐﾝｸﾞｽｷﾙを評価する」だけの資格が
あればこのスレ的には丸く収まるはずなのだが、、、

なんで一般教養入れちゃうんだろうな？

833 ：仕様書無しさん：04/06/20 14:27

うちの会社（中規模IT企業）、かなりのDQNぞろい。

情報処理の資格取得をしているかどうかで分類して、
それぞれの場合のDQN発生率を調べたことがあります。

資格ありの場合、DQN発生率は7%～10%くらい
資格無しの場合、DQN発生率は30%～35%くらいでした。

統計を取った後、採用する際は資格無しの場合は書類選考で落としています。
でも、それじゃなかなか人が集まんないんだよね。

834 ：仕様書無しさん：04/06/20 14:28

680 ：仕様書無しさん：04/06/19 17:30
SunのJava認定試験じゃだめですか？
http://sedap.sun.com/JPN/certification/javamain.html

835 ：仕様書無しさん：04/06/20 14:30

>>834
いいと思うよ。
受験料２万４千円だけど、社会人なら払える額だろう。

836 ：仕様書無しさん：04/06/20 14:34

( ﾟДﾟ)y─┛~~経営者が払えや

837 ：仕様書無しさん：04/06/20 14:40

ベンダー資格はすぐ廃れる。
Novellの資格、今じゃ名刺に刷ってるヤツいないよね。

価値が下がってくる。維持するのには金がかかる。
Oracle Goldなんて、今じゃ誰でもとれる資格。

MCSEなんか取ってみろ、維持するだけでも金と時間がかかりすぎ。

838 ：仕様書無しさん：04/06/20 14:43

実際、時代遅れの内容が多くて面倒くさいのは事実だからなぁ、、、
最近は経理システムの仕事だったので、簿記３級の方が距離が近いかも

ところで、管理職は、自分にないスキルも評価できないとまずいと
思うのだが、そういう能力を持った管理職少なくない？（特に技術上がり）

ここはちゃんと管理職講習でそういう人格者になってもらうか、
ふるいおとさないといかんのじゃないかな。
んで、SEも半管理職として、一部受けてもらうと。

話が散漫で申し訳ないが、結局「ﾌﾟﾛｸﾞﾗﾐﾝｸﾞｽｷﾙを評価するｽｷﾙ」の、
世の中での絶対量を増やさないと、どうにもなりそうもないなあと。

839 ：仕様書無しさん：04/06/20 14:49

>>833
頭数そろえれば商売になる会社なんだから、どうでもいいとは思う。

840 ：仕様書無しさん：04/06/20 14:53

>>833
ＤＱＮの認定基準を知りたい

841 ：69式フリーPG ◆hND3Lufios ：04/06/20 14:56

おいらがリーマンだった頃は、管理職講習を受けさせられてたぞ。
禿しくまんどくさかったけど。

842 ：仕様書無しさん：04/06/20 15:04

底辺でうごめいている会社にはその様なものは必要ありません。
全員が突撃要員です。

843 ：仕様書無しさん：04/06/20 15:07

オペレーターにおけるDQN認定基準

DQN3級
　　　独力でシステムダウンできる。
DQN2級
　　　なおかつ、それに気付かない。
DQN1級
　　　さらに、人に責任を転嫁することが出来る。
DQN名人
　　　責任を転嫁する相手は、ユーザーの担当者。

844 ：仕様書無しさん：04/06/20 15:13

プロジェクトマネージメントなら今はPMP資格がお薦めかな。中途半端に事情通な客受けがいい。それっぽい言葉ならべてたら、かなり信頼されて受注できた。初めて直接的に資格が役にたったよ。

845 ：仕様書無しさん：04/06/20 15:15

DQNは工数の足しにならないだけでなく、教育の時間も必要になってくるからやばい。
マイナスだよマイナス。

846 ：仕様書無しさん：04/06/20 15:23

悪いけどなんか資格重視派のほうが厨臭いレスが多いよな、やっぱり・・・。

847 ：800：04/06/20 15:25

>>838
まあ上司に「このへんの資格を取ってほしい」と言われたら、
役に立つ立たないは別に素直に言うことを聞いておくれよ。
自分の裁量だけで評価できればいいんだけど、組織としてはそうもいかない。
特に、時間に適当だとか、評価上何らかの問題があるやつね。

848 ：仕様書無しさん：04/06/20 15:35

時間に適当なのは論外だが
評価は合議制で行うわけではあるまい
それとも評価が出来る人がいないのかな

849 ：仕様書無しさん：04/06/20 15:36

>>846
そう思う？。実は俺もそうだ。
まあ読む人が自分で判断すれば良いだけのことだね（W

850 ：仕様書無しさん：04/06/20 15:37

まあ、野球のルールや技術を知らない人が、
野球選手の能力を評価することはできないよ。
で、「この選手は年俸いくらだから、きっといい選手に
違いない」とか、「PL高校の出身だから」とか、そういう
判断に頼ることになるんでしょ。

あ、巨人のスカウトみたいなものか。ｗ

851 ：仕様書無しさん：04/06/20 15:48

まあ、社会が資格を重要視しているかしていないかの判断は個人の自由だし、
社会が重要視していると判断しても、実務に役立たないと思いつつも割り切って
受けるのも個人の自由だし、実務に役だたないものは不要と受けず、不利益を
被るのも自由だ。また、重要視していないと判断したのなら、受ける必要は無いし、
それでも資格マニアとして受けるのも個人の自由だろう。

852 ：仕様書無しさん：04/06/20 15:51

>>846
主観的結論だけ述べるというのはどうかと。
>>849
印象操作に近いことをするのはどうかと。

俺は、能力の劣る者からいなくなれば良くなる、
という考えが見え隠れして同調できんけどね＞資格重視

853 ：仕様書無しさん：04/06/20 15:51

DQNはそんな文節の多い文章は読めません。
箇条書きにして下さい。

854 ：69式フリーPG ◆hND3Lufios ：04/06/20 15:52

>>851
個人個人の属している組織、環境によっても違うだろうしね。

855 ：仕様書無しさん：04/06/20 15:53

つまり評価も外注っていうことか。

ますますエライ人のする仕事がなくなっていくな。

856 ：仕様書無しさん：04/06/20 16:01

中途未経験ならいざ知らず、ソフト開発の世界に関わろうとする人間
が、就職前に資格の一つも取ろうとしないっていうのは、心がけが悪い
様に思うんだけどな。

基本情報くらいなら学生の時に取れるでしょうに。

857 ：仕様書無しさん：04/06/20 16:02

下からすくい上げるから、DQN濾しとしての資格が必要となる。

858 ：仕様書無しさん：04/06/20 16:02

おれは「能力の劣る者からいなくなれば良くなる」
と思っているが、資格なぞは気にしない

859 ：仕様書無しさん：04/06/20 16:03

調理師みたいに、有資格者以外は就職出来ないようにしたほうがいいよな。

860 ：仕様書無しさん：04/06/20 16:05

一定水準、一定待遇を維持するためには、有資格者を義務付けるのは有効。
調理師、理容師、ボイラー技師、危険物取扱とかな。
資格がなかったら本当にDQNのすくつになってしまう。

861 ：仕様書無しさん：04/06/20 16:05

>>856
というより、学生向けのお遊び資格になってしまってることが問題なのだが。

862 ：仕様書無しさん：04/06/20 16:09

DQNが流入して、総数が増えると、その職種全体の需要が供給に対して飽和して
しまう。どうしても安いやつが使われるしね。
そうして、スキルがあり本来もっと高給をもらえる技術者も単価を下げざるおえなくなる。

DQN派遣会社のために単価が下がったよなー。と思う人いない？

863 ：仕様書無しさん：04/06/20 16:14

>>861
どっかのサイトに書いてあること真に受けてるだけで、
実際に情報処理の試験受けたことないでしょ？
全然意味のない問題なんて出ないよ。
コンピュータに興味を持ててちゃんと試験勉強できるような奴じゃないと
受からない。

864 ：69式フリーPG ◆hND3Lufios ：04/06/20 16:17

俺が２種を受けた時は英語と数学があって、高校～共通１次位のレベルだったような
記憶があるな。あれは選択科目だったのかな。

865 ：仕様書無しさん：04/06/20 16:18

>>864
え？

866 ：仕様書無しさん：04/06/20 16:19

>>862
実際そうだろうね。
低レベルDQNを切り捨てられる基準がないから、スキルがある人間も
下げざるを得ない。

867 ：仕様書無しさん：04/06/20 16:24

社会秩序のためにも、本来はそういう基準が必要なんだよね。
それは技術のある、努力した優秀な技術者を保護するためでもあるし、
その成果物の水準を保つためでもある。

大型免許を持たない奴が運転するトレーラが横行する道を自転車で走る気はしないし、
医療資格を持たないモグリ医者の医療を受ける気がしないのと同じこと。
無資格者のさばいたフグ刺を食う勇気があるかい？

868 ：仕様書無しさん：04/06/20 16:25

人売り派遣業がよろこぶだけ。＜基準なし

869 ：861：04/06/20 16:29

>>863
おれも周囲も遊び感覚で取ってたけど。
まじめに受けてた奴はいなかったな。

870 ：69式フリーPG ◆hND3Lufios ：04/06/20 16:31

>>865
ちがったっけ？ｗ
なんせ１０年以上前で、殆ど勉強もしなかったのであんまり記憶が・・・。
午後は確かCASLで受けたような気がする。
ｽﾏｿ

871 ：仕様書無しさん：04/06/20 16:53

そういえば選択問題で、わざわざ間違っている
問題を選択したという強者がいたな。
こーゆー場合は、何を選んでも○になるから、とか。

872 ：仕様書無しさん：04/06/20 17:04

クヌース本とかGoF本とかが出題範囲の資格を設けるべきだと思う。

873 ：仕様書無しさん：04/06/20 17:05

あと、英語も必須だな。
英検２級～３級程度の能力が無いと、ソフトウェアの開発は困難だ。

874 ：仕様書無しさん：04/06/20 17:11

>>870
英語と数学あったよ。　必須じゃなくて選択だったけど。　簿記とかもあった。
俺も英語と数学を選択した。

２種を受けなかった奴らは、英語と数学が嫌だったんじゃないの？ｗ

午後は CASL と C を選択した記憶が・・・

875 ：仕様書無しさん：04/06/20 17:13

２種の英語と数学は、センター試験よりずっと簡単だったと思うが・・・

876 ：仕様書無しさん：04/06/20 17:54

文法的にはセンター試験よりも簡単でした。
但し、専門用語の語彙があればの話。
専門用語がわからなければ、全く意味が通じない。

877 ：69式フリーPG ◆hND3Lufios ：04/06/20 18:00

>>874
やっぱあったよね。簿記とか工業数学もあったんじゃないかな。
簿記とかやったことなかったんで、英語と数学で受けたんだよ。思い出した。

>>875, >>876
まあ、よく考えたら受験後大学で４年間呆けてても受かったわけで、
簡単なはずだね。ｗ
失礼。

878 ：仕様書無しさん：04/06/20 19:42

>>861
同意。
ごく簡単なものすら組めない、プログラミングはドシロウトの学生が、
試験勉強だけでけっこう取ってるのをたくさん見た。
逆に業界でいい仕事してる人でも取ってない人（取れない人じゃないよ）
がたくさんいるのも見た。

そういう現状では、何を言っても「ほんとに意味のある資格なんだろうか」
という疑問が生まれてくるのは仕方ない。

879 ：仕様書無しさん：04/06/20 19:46

だから、有資格者しか仕事出来ないようにすればいいんだよ。
試験ももっと難しくして。馬鹿は受からないようにして、優秀な人も受ける動機付け
が必要なんだな。現状だと取っても少し手当てが出る程度だから、誰も取らない。

880 ：仕様書無しさん：04/06/20 19:47

>>878
そういうことは、最低でも高度区分で２つくらい合格してから言ってくれ。
そうじゃないと、負け犬が吠えている程度にしか見られないぞ。

881 ：仕様書無しさん：04/06/20 19:49

>>880
そういうことはきちんと仕事で成果を出してから言ってくれ。

と資格を取った学生には言いたい。

882 ：仕様書無しさん：04/06/20 19:51

>>879
難易度の問題じゃないんだよ。
業務上必要とされる技術や知識、考え方、適性などを
見るのに適した「内容」にしないと意味がない。

少なくとも現状の試験内容では「持ってるからこの業界の
仕事に向いてる」と言うのは難しい。

883 ：仕様書無しさん：04/06/20 19:53

情報処理技術者も国家資格士にして、情報処理業務に従事する技術者に義務付ける。
これでDQNは死滅する。優秀な人は残り、高単価も維持できるだろう。
中国からの技術者流入も防げるし、良いこと尽くめだが、人売り業者が
そんな法律を成立はさせるはずが無い。

884 ：仕様書無しさん：04/06/20 19:57

>>883
人買いもね

885 ：仕様書無しさん：04/06/20 19:57

自動車修理工ですら資格が必要なのに。

886 ：仕様書無しさん：04/06/20 19:59

>>878
取れる人っていうのは、ドシロウトだろうがそれだけの下地があるっつー事だからね。
試験に受かった人じゃないとこの仕事に就けないってことにすれば
>>862で出た問題を解消するのには意味あると思うよ。

887 ：仕様書無しさん：04/06/20 20:00

まあ、このままだと自動車整備士以下の単価になるのは間違いないよね。
歯止めが無いもの。

888 ：仕様書無しさん：04/06/20 20:01

じゃあそういうのおまえがつくってみせろ

889 ：仕様書無しさん：04/06/20 20:02

仕事が多いのに単価が安いから、その辺で拾った素人を派遣するんだ。
単価が高い仕事にはそれなりの技術者を派遣してるよ。

890 ：仕様書無しさん：04/06/20 20:09

使えるやつか判別可能なテストを持った俺は勝ち組?

891 ：仕様書無しさん：04/06/20 20:10

そして、単価の安い素人の実績が増えていくと業界全体の単価が下がっていくんだよな。

892 ：仕様書無しさん：04/06/20 20:26

ネットワーク系や組み込み系といった具合に、
業界毎に違ったテストを行える方が理想かな？
十把一からげにIT業界とするのもどうかと。

893 ：仕様書無しさん：04/06/20 20:31

もう寝るぽ(;´Д｀)

894 ：仕様書無しさん：04/06/20 20:36

お前らほとんど話かみ合ってないなｗ

895 ：仕様書無しさん：04/06/20 20:37

とりあえず、DQNをカットできるのなら試験でも何でも良い。

896 ：仕様書無しさん：04/06/20 20:38

DQNって何なの？ずっと気にはなってたのよ。ドラクエナイン？

897 ：仕様書無しさん：04/06/20 20:38

試験でいいから問題作れ。うんこやろうめ

898 ：PGがマネジメントを語って何が悪い。：04/06/20 20:41

PGは工場の機械工と全く同じ運命を辿っているのだよ。
職人から分業へ、分業からライン工へ。
各工程に必要とされるスキルは低下していき、単価はどんどん安くなる。
それは「ものをつくる業界」では避けられない潮流だ。
生き残りたいなら、この運命に立ち向かわなければならない。

899 ：仕様書無しさん：04/06/20 20:45

資格を義務付けるか否かが、ただの工員か職人かの分水嶺なのである。

900 ：仕様書無しさん：04/06/20 20:46

元々分業が主流で、ライン工のような仕事だったわけだが。
職人的な仕事だったのはゲームプログラマとかシェアウェアの作者くらいじゃないか？

901 ：仕様書無しさん：04/06/20 20:47

じゃあ、ラッダイト運動するか！

902 ：仕様書無しさん：04/06/20 20:47

それは業務系のお話。パッケージはそうじゃないよ。

903 ：仕様書無しさん：04/06/20 20:47

ソフトウェアや雑誌・新聞といった「コンテンツ」は工場で作らない。

904 ：仕様書無しさん：04/06/20 20:50

うちの会社は、プログラム作ってる事務所を「工場」と呼んでますが。

905 ：仕様書無しさん：04/06/20 21:05

話が何個も平行しているぞ。
漏れの頭では判別不能。
誰かまとめれ。

906 ：仕様書無しさん：04/06/20 21:09

仕様書を読む能力が試験で判別出来ればな・・・

907 ：仕様書無しさん：04/06/20 21:10

国語の問題は必要だよな。

908 ：仕様書無しさん：04/06/20 21:22

英語の問題も必要だな。
数学の問題も必要だ。

909 ：仕様書無しさん：04/06/20 21:25

試験で道徳を判別出来れば・・・

910 ：仕様書無しさん：04/06/20 21:28

>>896
道徳や知性をもたないヤシの事。

911 ：仕様書無しさん：04/06/20 21:30

>>898
プログラミング（システム構築）を、テーラーの科学的管理法を理論的背景として
定量化し、容易に管理したいという要求はここ30年ほどある。
そしてそれが可能ならとっくにそうなっているさ。なぜそうなっていないのかを考えてみるべし。
生産という共通のキーワードは存在するが、ソフトと工業製品はその生産資源からして全く違う
という事実に気が付いているかな。

912 ：仕様書無しさん：04/06/20 21:34

>>908
英語って必要か？
ネットに繋がるなら辞書見ればいいじゃん。

913 ：仕様書無しさん：04/06/20 21:36

業務系だけだよ。工業製品化できると勘違いしている香具師は。

914 ：仕様書無しさん：04/06/20 21:36

まあさ、むりだからさ。あきらめたよおれは。定量化とかそういうの。
「ピープルウエア」と「スーパーエンジニアへの道」って本を読んで考えがかわった。
もまいらもよんでもれ。

915 ：仕様書無しさん：04/06/20 21:39

>>912
単語調べれば読めるくらいの英語力は必要だな。

916 ：仕様書無しさん：04/06/20 21:40

CodeProjectを斜め読みできる程度の英語力は不可欠だろう。業務系以外は。

917 ：仕様書無しさん：04/06/20 21:55

資格板ですら資格とったからどうこうって話にはならないのに香ばしいスレだな

918 ：PGがマネジメントを語って何が悪い：04/06/20 22:08

>>911
この業界が製造業より建築業の形態に近いことくらい知っているさ。

ところで、誰か定量化の話をしたかな？生産的な工場なら定量化なんて愚行はやっていないはずだが。
どうやら君は製造業の革命続きの歴史を知らないらしい。大量生産はもはや過去の手法だ。
現在の製造業はIT業界なんかよりもよっぽど人間的で合理的だよ。

フォードは食品業界から流れ作業をパクッた。
異なる業種の常識に気付いたなら、自分の業界に革命を起こすことも可能だろう。
似ている建築業からでなく、違っている製造業を見習ったほうが良いこともあるさ。

919 ：仕様書無しさん：04/06/20 22:14

>>898が何気に的を射た発言をしてるな。全くその通りだな。
でかい会社に凄腕のＰＧが希少なのはそういった理由だと思う。

920 ：仕様書無しさん：04/06/20 22:16

見習うのなら官業を真似るべきね。つまり公務員ってこと。

能力に関係なく、能力以上の給料がでる。
掃除でもゴミ集めでも公務員なら良い給料。
一番大切な仕事は、組織を肥大化させること。
世間の相場以下の給料でがんばっているのは、一部のキャリア組のみ。

921 ：仕様書無しさん：04/06/20 22:17

テーラリズムへのアンチとしてセル方式もあるしな。
製造、製造業へのアナロジーも有効だと思うよ。

「ムリ、ムラ、ムダ」を無くすことは重要だ。
だがデスマを簡単に起こすスキルのある奴は、「ムリ」を無くそうとしない。考えることもない。

922 ：仕様書無しさん：04/06/20 22:20

>>919
プログラマが「ライン工」と呼べるか否かは、その作業が
「自動化」出来るか否かにかかっていると思うが。

日本の工業分野の技術力を支えているのは、確かに
零細企業のエンジニアである事は間違いないが、
かといって彼らが「ライン工」と呼べるかと問われれば、
それについては首を横に振らざるを得ないだろう。

923 ：仕様書無しさん：04/06/20 22:52

>>921
新聞記事から抜粋。

「いまのプログラムを生かして作ると３年かかる。
一から作れば１年以内にできる。」
　その通りになった。

924 ：仕様書無しさん：04/06/20 22:57

>>923
その種の分析が可能な人間こそが金の草鞋を履いてでも求めるべき人材だナ
まあ一般にはその種のスキルをプログラミングスキルとは呼ばない様だが
スレ違いスマン

925 ：仕様書無しさん：04/06/20 23:08

ああもう、じゃーどうすればいんだよ。
あした会社にいってなにからはじめりゃいいでつか

926 ：仕様書無しさん：04/06/20 23:10

便所掃除

927 ：仕様書無しさん：04/06/20 23:12

基本情報もってると基本給にいくぶんかプラスのある会社はあるよ

928 ：PGがマネジメントを語って何が悪い。：04/06/20 23:21

>>921
まあ、トヨタのやりかたにも色々と問題点はあるんだけどね。
例えば、そのムダがスループットにどのくらい影響しているのかを考慮していない、とか。
ここらへんをあんまり語ると板違いと言われそうだが。

>>922
日本の大手製造業は大量生産方式を採用していない。だから彼らは「ライン工」ではない。

>>923
後者を選択したのなら、約3倍の生産性を達成したことになるね。

この業界もこういう話ばかりならいいんだが。

929 ：仕様書無しさん：04/06/20 23:24

>>925
○○が一番重要だと思うスキルを向上させる。
○○には「会社」か「自分」が入る。
どちらを選択するかは自分で決める

930 ：仕様書無しさん：04/06/20 23:33

>>925
会社の人間と対話してみる。話して分かる相手なら、
話をしているうちに良いアイデアも浮かんでくるさ。