べつに全部じゃないだろ
半分くらいは自分で作ってる。
大卒だったら上流工程にいける。
PGなんてよくねーよ。SI屋に嫁ぐと吉。
理系板みてみろ
情報XX学部みたいな学部は土木と並んで負け組学部だ
勝ちは電子工学や機械工学など
機械ですがPGですよ
まぁ負け組なのは確かだが
239 :
仕様書無しさん:04/04/04 18:27
俺は初任給増額でスカウトされたからかんけーねーな。
今通ってる高校にいろいろなツールを自作していて
しかも知り合いの間で使われているって
すごい奴がいるんだがこいつの将来はどうなんだろうか。
そいつと俺はSEを目指してるわけだが一生勝てない気がする・・・。
241 :
仕様書無しさん:04/04/04 18:52
>>240 やってみないとわからんよ。
社会じゃいろんな能力が必要だから、一部に秀でていても
そこからどう転がっていくかは不明。
まぁ悪いことじゃないだろうけど。
>>241 じゃあ俺の方がやばいわ・・・。
全体的にも負けが見えてる(鬱
情報科のある大学へ進もうと思ってたけど
諦めて地元の公務員でも目指すか・・・。
243 :
仕様書無しさん:04/04/04 19:13
244 :
仕様書無しさん:04/04/04 19:27
昔ウチの会社で働いてた人のこと。
そこそこ有能で某有名ソフト会社にいたらしいんだけど、
プライドが高くて「おれはレベルが違うんだ」みたいな感じだったらしい。
ウチを辞めて何年かして独立した。
けど結局うまくいかなくて、
パソコン使って悪さして捕まって警察が当時の仕事ぶりとか、
人間性とか、ウチの社長に聞きに来てた。
>>243 校内ネットワークで使うメッセンジャー。
IDとパスワードを管理するもの。
デスクトップで動き回るペットなど
10個前後作っておられます。
246 :
仕様書無しさん:04/04/04 19:32
ネットワークの不備を指摘してあげたのに捕まっちゃうレベルだからなー。今の日本は。
個人の優秀さと独立してやっていけるかどうかはまた別問題だけどなー。
>>246 もしかして、ネットワークの不備を指摘しただけじゃなくて、
そこで入手した情報を不特定多数に公開した人の話?
あれは捕まって当然だよ。
248 :
仕様書無しさん:04/04/04 20:00
個人情報をテストデータにつかってますが。
249 :
仕様書無しさん:04/04/04 20:01
えぇー。そうなの?原文見てないからなんともいえないけど、
新聞にもセキュリティ問題の専門家捕まる。見たいに扱われてたじゃん。
その他にも、どっかの高校生くらいの人が企業のネットワークに侵入して、
こんな簡単に進入を許すようではおまえらはなっとらん!見たいなメッセージを残して、
で、学校に行く途中の駅の改札出たところで警察に補導みたいな事件もあったね。
なんつうか、ハッカーに冷たいよね。ジャポンは。
ソフト設計者ってプログラマのこと?
ラダーっていうソフト使うんだけど
>>245 そのくらいは、日常的にプログラム書いている人なら作れるよ。
そもそもSEの能力とはあまり関係ないと思う。
>>252 そうなんですか!?
私はVBで簡単なスロットゲームを作るぐらいしかできないんで
すごいなと思ってたんですが。
私はSEになれないなんてことは無いんでしょうかね。
がんばってみようかな・・・。
文学部とかがPGになる時代だからねぇ
>>253 まだ高校生なんでしょう?
プロゴルファーとか特殊なものを除いて、普通の職業なら大抵やれるよ。
まあ、240が大学を卒業するころ、この業界がどうなっているかもわからんし、
どっちかといえば、公務員をお勧めしたい気もするけど。
SEはコーディングしないよ。
日本語で設計書書いてプログラマにコーディングさせんの。
で、一からシステム作ることもない。
ある業務のマスターがあって、「〜さま向け」にカスタマイズするだけ。
マスターのシステムを作る時はもちろん、それなりの費用をかけるが。
主な仕事は要求定義。
基本設計書だって既存の設計書を参考に決められたフォーマットで書くだけ。
できる限り大きく見積もって予算を引っ張ってくる。
競合他社がいるなら接待もする。
しかし、いざトラブルとなれば夜中の三時に電話かかってきたり、
弊社に責任がないことを契約書をタテに取りつつやんわりと指摘したり、
プログラマのせいにしてみたりする。
まあ、本当にこんぴうた好きなら研究職をめざせってこった。
大学逝けよ。
257 :
仕様書無しさん:04/04/04 21:41
大卒でPGってそんなに珍しいの?
うちの会社は、80年代は知らないけど、90年代以降はそれなりの大学(最低でもMARCHクラス)
卒しか、PGとして採用してないよ。
東大とかもたまにいるし。
うちの会社は一部上場だけど、やっぱり、ソフトウェア会社としてそれなりのところは、
その製品を産み出す人間もそれなりの頭脳でなければいけないってことでしょ。
誰が大卒が珍しいなんて言ったんだ?
259 :
仕様書無しさん:04/04/04 22:16
>>256 詳細設計ってプログラマがやるものなの?普通。
260 :
仕様書無しさん:04/04/04 23:14
詳細設計はさすがにプログラマー持ちだろ。仕事の様式は場所によるけど。
261 :
仕様書無しさん:04/04/04 23:29
>>260 なるほど。この業界ってよく建築業界に例えられるけど、
施工図(実際に施工する際の図面)だって大工さんがやるもんね、やっぱり。
要求定義や外部設計はSE(建築士)
詳細設計やプログラミング(施工設計や施工)はPG(大工)
って感じなんだなぁ。
262 :
仕様書無しさん:04/04/05 04:04
UMLでクラス図を書くことは詳細設計に値する。
と、いうことは、これからの時代は、
詳細設計もプログラマがやるのだ!
もはやSEなどこの世に必要ない。
UMLの登場によってSEがやる仕事もすべてプログラマだけでできる時代がやってきたのだ!
エンベデッド系だとけっこうずっとプログラムできます?
265 :
仕様書無しさん:04/04/05 22:29
詳細設計ってのは、一般的にはSEがやるの?PGがやるの?どっち???
266 :
仕様書無しさん:04/04/09 07:19
>>265 どっちかというとプログラマよりの人間じゃないか?
うちの会社の場合、変に古いから上司が汎用機の保守とかやってた人間で、
最近の事情を全然わかってないのに発言してテンヤワンヤだから
参考にならんと思うが。
管理職なんだか営業なんだかSEなんだかわからん人間が、
仕事をとってきて、その下のSEが、基本設計をやる。
そしてPGなんだかSEなんだかわからんオレが基本設計を半ば無視した詳細設計
をやりつつ、コードを書かせつつ自分でも書きつつ、
上の人間を言いくるめる役を負う糞会社がうちの会社。
PG未経験のやつが書いた詳細設計はものすごかった。
殆ど、企画草案か概略仕様書レベル。
「○○昨日詳細設計:
上のボタンを押すと編集画面が開き、編集画面で項目をにゅうりょくすると
データベースが更新される」
ぐらいで終わりとか
268 :
仕様書無しさん:04/04/12 01:25
>267
おいらが入社した一年目に作成したGUI仕様書を思い出すな。
もうちょいこまかかったけど。。
プログラム全然わからないSヨが書いた関数仕様書とかな。
関数名:DataBese_Update_Proguram_System_....(関数名だけで100文字ぐらい)
機能:データベースをアップロードする
引数:データベースの名前
戻り値:不明
>>269 >Proguram
ここでめまい。
>機能:データベースをアップロードする
ここで悪寒。
関数名だけで100文字ってC言語ですかねぇ。。。
>>270 むしろDataBeseの時点でめまいを感じろと言いたい
273 :
仕様書無しさん:04/04/18 00:07
あげ
274 :
仕様書無しさん:04/04/18 00:45
エッ!PG/SEって大卒がやるような仕事なの!
第n新卒とかなら選択肢も少なくなってるし、手ごろな仕事だから
いいだろうけど、将来のある若者がPG/SEとはねえ...。
>>274 釣りだと思うが、将来のない人が作ったプログラムほど
むごいものはないぞ。
277 :
仕様書無しさん:04/04/22 17:37
紅旗に乗ってみたい。日本人の馬鹿どもは乗るな。
278 :
仕様書無しさん:04/04/23 16:30
それより
>>1。
ちょっと前ビデオレンタル屋で「女子十二尺棒」っていうAVが出ててワロタヨ。
279 :
仕様書無しさん:04/06/12 11:40
280 :
仕様書無しさん:04/06/12 12:03
2004年 3月 朋也卒業
5月 渚と朋也が同棲を始める
2005年 3月 渚卒業
3月? 渚と朋也が結婚
5月? 渚妊娠
2006年 3月? 汐を出産。渚死亡(21歳)
2010年 4月 汐(4歳)幼稚園に入園
8月 汐と東北まで旅行。祖母と会う。親父との和解
10月 芳野と伊吹結婚。原因不明の発熱で汐倒れる
12月? 汐死亡。
281 :
仕様書無しさん:04/07/10 11:39
>>279 おれは大学院にいってるが
最近の卒論はその程度のパクリものが多い。
毎年レベルどころか新規性、オリジナリティ、面白味が下がっている。
282 :
仕様書無しさん:04/07/10 11:42
>>279 34ページから73ページまでは全部Cのソースコードだな。
おきまりのパターンですな。
修士論文ですらそういうのがあったりする。
しかし、さすがに彼らの場合は、新規性があるが。
>>279 29ページの5章 結論より
-----------------------
今回データ処理を行った探索アルゴリズムはリストと木構造であった。それぞれの処理
の結果を第4 章で述べている。結果、データ量が多い時は木構造、少ない時はリストを用
いる方が効率が良い、が、今後先、要素数が増えるということを考えると要素数が多くて
も処理の効率がよい木構造を使用するほうがよい。
-----------------------
Aさん「インデックス張っても、あんまり検索速度上がりませんね」
Bさん「レコード数少ないからなぁ」
DB設計で日常的に話されているような事柄を大学では時間をかけて研究していると
漏れの卒論なんて多元方程式の解き方だったぞ
しかも掃き出し法。