プログラムが組めないSEってどう思います?

このエントリーをはてなブックマークに追加
1仕様書無しさん
ERPのアプリケーションコンサル(財務会計)ということで転職します。
カテゴリーはSEということですが前職が経理屋で職種変更なんですが
プログラムは全く分かりません。

なんだか不安になってきたんだけど
こんなわたしでも通用しますか?

2仕様書無しさん:02/03/02 05:03
通用せん。転職は失敗ですな。
3仕様書無しさん:02/03/02 05:26
「ERPのアプリケーションコンサル(財務会計)ということで転職します。」ってことは、
まだ転職したわけではないんですね。
考え直すなら今のうちですよ。
プログラムを全く知らない SE なんて迷惑なだけだからね。
4 :02/03/02 05:34
PGやるんじゃないから問題なし。
コンサルだからPGじゃなくてSEにしておけって程度の事。
5仕様書無しさん:02/03/02 06:18
>>1
ERPのアプリケーションコンサルならプログラムなんて知らなくても
まったく大丈夫。でも入ってからはかなり勉強しなければなりませんね。
経理の時も勉強したでしょ?ところで経理の方はどれくらいの腕ですか?
一人で決算できます?
6仕様書無しさん:02/03/02 09:40
プログラミングなどには無縁のお仕事ですね。

SE(何度もいうようだけど、この SE という曖昧な単語は嫌い)と言わず、
経営コンサルタントと名乗ったほうが分かりやすいと思います。
7仕様書無しさん:02/03/02 09:43
基本的に無理。
中途採用で教育なんかしてくれないよ。
OJTとか言って、レコードの概念もわからない人間にフローチャート書かせて「こんなこともできないのか」って笑われておしまい。
8仕様書無しさん:02/03/02 09:51
>>7

別に、いいんでないかな・・・。

要するに、コンサルタントっていうのは営業と似たようなもので、
「この図で示したとおり、貴方の企業にはこのようなシステムを構築する価値はありますよ(ま、導入後失敗しても、それは提案を受け入れたあんたの責任だから、俺は責任とらんけどね)」

「じゃ、お願いしようか」

と、相手にうまく決断を促す仕事なわけだ。これは価値ある仕事だと思うよ。
9仕様書無しさん:02/03/02 09:56
>>8

しかも、説得を成功した後は、少なくとも、プログラマの顧客が「コンサルタント」
という構図になる。(コンサルタントが希望する機能をプログラマが実装する)

何を作ればいいのか分からないプログラマにとって、こういう存在は必要だと思う。
10仕様書無しさん:02/03/02 10:01
>>1
パッケージなんてカスタマイズしない方向でコンサルしていくし、
ERPベンダーSEでPG出来る人のが少ない。
11仕様書無しさん:02/03/02 10:02
>>9

まぁ本当ならコンサルタントなんて通さずに、ただシステムを求める顧客が
自分で必要な機能を決めて、プログラマにお願いする、というふうにするの
が本来のあり方だと思うんだけどね。

コンサルタントにまかせていいの?
それこそ、企業経営者の仕事じゃないのですか? と。

そっちのほうがプログラマにとっても有り難いはずだしね。
12仕様書無しさん:02/03/02 10:10
会社にもよる
プログラマの勢力が強い会社だと苦労するかもね。
「プログラムも出来ねぇ奴がうちで何するつもり?」と。
馬鹿みたいだが、結構あるんだよな、そういうの
13仕様書無しさん:02/03/02 10:15
プログラムそのものができる必要制覇ないのだけど、
プログラムすらしらない人間が、
システムの特徴とかわかるんでしょうか?
んで、わからない人がpresentationできるんでしょうか?
しかし、システムを良くわかる人とコンビで仕事すれば問題ないです。
14仕様書無しさん:02/03/02 10:18
>>12

そうですね。
「どうやって作るか?」より「何を作るか?」の方が圧倒的に重要な問題。

プログラマはそこんとこ押さえておかないといけないと思う。
そうでないと、往々にして必要の無いテクノロジの導入や、必要の無い機能
の実装をしてしまいがち。

顧客あってのプログラマ。
15仕様書無しさん:02/03/02 10:20
>>1
いわゆるコンサルという名の、SEという名の営業ですから(^^ゞ
16仕様書無しさん:02/03/02 10:25
>>13

確かに、システム開発に一回も携わってない人ってのも不安があって。

プログラマがやるべき仕事、設計や、開発期間の見積もり、スケジュール
管理といったところに、コンサルタントが口出ししてくるなんてことがあ
る。

一度、どういう仕事なのか、どういう役割分担が求められるのかっていうの
をコンサルタントは知るべき。
17仕様書無しさん:02/03/02 10:26
>>14
いや、ちと違うと思う。
プログラマにおいても何を作るかは大前提。
押さえなきゃも何も押さえてないで、仕事進むとは思えない。
「何を作るか?」・・・・・顧客が決定すること
「実現方法は?」・・・・・エンジニアが提供すること
彼らの橋渡しが、プログラムができないSEの仕事と思われ。
18仕様書無しさん:02/03/02 10:28
>>17
まちがった。舌の各個は「どうやって作るか?」
19仕様書無しさん:02/03/02 10:30
え?
プログラムの経験もないのに、どうやって工数を弾き出すんですか?
根拠が無いでしょ?
SEはシステムがどうとかっていうのも勿論必要だけど、
お金の事に関してもプロフェッショナルである必要があります。
いい加減な仕事はしないで下さい。
20仕様書無しさん:02/03/02 10:34
工数は現場のプログラマのみぞ知る。
21仕様書無しさん:02/03/02 10:36
どう実装するか思い浮かばないのにSEと自称する輩が多いことか・・・

認証部分から自作しようと見積もりとってきた奴いるし。
LDAP使えば済むことなのに。

「ORACLEを使ったシステム構築の実績はありますが
RDBMSについてはこれから前向きに検討しています」

とか

こんなのがいてわけわかんねーよ。
22仕様書無しさん:02/03/02 10:37
「書類じゃわかんないですよ工数なんて!」
23仕様書無しさん:02/03/02 10:44
>>22
わかるわかる。

「投入したデータを取り消す処理を追加」するってことになって
「1日あれば十分だろこんなの」とか
「そのレコード消すだけだろ?」とか
「更新処理流れてもそのレコード分だけ引けばOKだろ?」とか
やっぱり実装部分がどうなっているかわからないSEには
この程度の知識しかないのかなーと思ったよ。

24仕様書無しさん:02/03/02 10:47
>19
んじゃ、プログラムの経験ある人はどうやって工数はじき出すの?

どんぶり勘定?
それとも、脳内見積?
それはいい加減な仕事ではないの?
25仕様書無しさん:02/03/02 10:49
ご立派なPG上がりのSEが率いるプロジェクトに、
デスマーチはあり得ないって論旨になってきた。
26仕様書無しさん:02/03/02 10:55
>>24

そんなアナタに Extreme Programming。
27仕様書無しさん:02/03/02 11:03
>>25
ありえないですよ。私、そういうSEの元で仕事する機会がありましたけど、
土日祝日出勤一度もなかったですよ。徹夜も無かったですよ。
終電近くまで残業することは、6ヶ月中一ヶ月ほどあったけど、
それくらいかな。
28仕様書無しさん:02/03/02 11:07
>>19
工数は、PGとかと相談してはじくんですよ。
1>>はコンサルとして入るんだから工数はPGと相談して決めるんですよ。
1>>が工数算出したら大変だな。工数多ければ顧客に理由をつけることが
できず。説明できるレベルで工数出すとデスマーチ。
29仕様書無しさん:02/03/02 11:08
>>27
補足、そのプロジェクト。人が集まらなくて予定より
2人少ない状態で、がんばりました。
30仕様書無しさん:02/03/02 11:09
ERPが何たるかをしらないあふぉがあふぉなレスつけていてかなりワラエルーヨ。

ゲームプログラマか?
31仕様書無しさん:02/03/02 11:57
1はSAPのコンサルタントになるんだろ?
そうなると仕事なんてのは、営業サポートと、客の業務をいかにSAP向けに
カスタマイズするかだからプログラムどころかフロッピーをフォーマット
できないレベルでも問題ないだろ。
ハード周りはメーカーに見積もらせて、システム周りはR3使いにやらせて、
客にはSAP流の業務フローを押し付けて人月200万取れる素晴らしい商売だ。
32仕様書無しさん:02/03/02 12:28
めずらしくいいスレだ。

どうせ入社前にある知識なんてのは大したもんじゃないと考えて、
入ってからなんとかすればいい。
その点即戦力求めてる、なんて会社はクソだからやめた方がいい。
実際求めてねぇんだよ。教えるのがタルいからってだけだ。
33仕様書無しさん:02/03/02 13:12
SAP がどんなものか知りたい学生なんだけど、
SAP の書籍ってあんまり見ない。
WEB でも本でもいいから入門にいいのない?
34Delフサギコ ◆zE1iiRdQ :02/03/02 14:09
  ∧,,∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,゚Д゚彡 < XPで全部解決
  ,;゙  ミ     \_____________
\ミ.  ミ  その際、コンサルSEはオンサイト顧客的な
  ゛゛゛゛   仕事の仕方をするといいかも。

プログラミングは知らなくてよさそうだけど
XPは氏って置いたほうがいいとおもう。
ニポンにはオンサイト顧客がいないから。

俺の友人もノムソー辞めてどっか違うとこでSAPerになっちゃった。
>>33
そんな書籍あるの?
トレーニングだけですげー金必要なもんでしょ…多分

SAPってのは
勘定奉行とかあたりの似たようなソフトで
全国有名大企業全体に納入する用のソフト
で、カスタマイズするのが凄く難しかったりするので

ニポーンで数千人規模カスタマイズ仕事だけで
飯食ってる連中がいる

という感じなのかな?

SAP/R3
(リリース3って事)のちょっとしたVerUpだけでも
インスコとかがいろいろと大変な問題らしいよ。
351:02/03/02 14:24
みなさんResありがとう。

SAPのコンサルとして入社します。
入社後は1ヶ月ぐらいSAPの講習会に行くことになる予定です。

5>>簿記は1級持ってますが、一人でとなるとちょっと不安です。

仕事はプログラム組めなくても平気で
プログラマさんの領域まででしゃばらなければ
問題ないということなのかな。

>>15 本物のSEではなくSEという名の営業というのもわかりました。

>>33 SAPって会社名ですよ。アマゾンでERPで検索すると出てきますよ。


36 :02/03/02 14:29
プログラムが組めないのは問題だと思う。
いずれにしても一流SEにはなれない。

女性の場合、結婚して退社だもんな。
37仕様書無しさん:02/03/02 14:36
PGに陰で馬鹿にされながらがんばってください。
38仕様書無しさん:02/03/02 15:12
っていうか、SAPを使う企業じゃなくて、ほんとにSAPに入社するの?
だったら一人くらいここ読んでる人いると思うよ
入社を検討している会社名を掲示板でだすようなアフォ雇うのかね、、SAPは
391:02/03/02 15:18
>>38 SAPでもなくて、ユーザーでもなくて
SAPのR/3を取り扱うSIでした。
いくらなんでもそんな馬鹿じゃないです。
40仕様書無しさん:02/03/02 15:18
プログラムが組めなくても
完璧な仕様書が書ければ文句はない。

ただ、プログラムがわからないと
完璧な仕様書を作ることは難しい。(が、出来なくはない。)

こういうことでしょ?

そもそもSEとPGを混同してる会社が多いから
プログラム書けなきゃSEが出来ないなんてことに
なっているんだと思われ。
SEがプログラム書いてたら仕事は進みません。
4131:02/03/02 16:03
SAPのスレで世間一般のSEを論じても話にならんが‥。
ちなみに、ソフトだけの最小構成で600万、導入前のコンサルが月/200万、ハードやRDBで
数千万ってモノを導入できる企業はSAP屋の数より少ないって話があるぞ。
俺はCOBOLチックなマクロをおぼえてここ数年に賭けるのは御免だが。
42仕様書無しさん:02/03/02 17:26
SEはプログラムを書かない。・・・が、
プログラムを書けないSEは死んだ方が(・∀・)イイ!
43仕様書無しさん:02/03/02 18:21
プログラムがかけない優秀なSEの条件をあげてみよう。
とりあえずRDBMS関係。

・SQLについて知っている
・ストアドプロシージャについて知っている
・トリガについて知っている
・正規化理論について知っている
・インデックスについて知っている
・ロックについて知っている
・参照制約について知っている
・整合性制約について知っている
・SQLで簡単に出来る処理をロジックで書いて仕様にしない。
・パフォーマンスを挙げる方法を知っている

これらを知っていなけりゃまともな仕様書は書けなく、
知るためには実際に作ってみるのが一番早いと思うがどうよ。
44仕様書無しさん:02/03/02 20:56
だから、まずSEという言葉を忘れることからはじめましょう。

(プログラミングもしないのに、システムエンジニアって、
名前的になんじゃそりゃみたいなとこあるでしょ? 顧客
から仕事とってくるのは素晴らしい役割なのに)

プログラマか、マネージャか、顧客か。
開発に携わる人の種類としては XP 的にはこの三種類のみ。

>>1 さんは、開発の現場では「顧客」に当たると思います。
>>43 さんは、現場で働くプログラマの役割。
仕事の障害になってるものを取り除くのがマネージャの役割。
45仕様書無しさん:02/03/02 21:07
>>1
大丈夫です。絶対に通用しません。
 したがって謙虚な姿勢を保つことが大事です。
 そうしないと田中外相になります。
4643:02/03/02 21:09
>>44
うむ、俺もそう思うよ。XP的な分け方が一番良い。

自分的にはあそこに書いたのは全部プログラマの役目。
しかし、現実ではプログラマの役目の一部をSEに分け
SEがやっている。

もともとプログラマという同じ仕事なのだからSEという
仕事を作ってもプログラマと同じ能力が必要。
だからプログラムが組めないSEはSE失格となる。

だれだよSEってわけわからん職種作った奴は。
47仕様書無しさん:02/03/02 21:15
>1
もし hoyaならやめたほうがいいよ。
48仕様書無しさん:02/03/02 21:45
自分、SEというなのど素人、しかも給料だけ一人前の人間に
どんなけ苦労してきたことか。あいつらは業界の本当のお荷物です。
そんな人間にだけはならないように。
49仕様書無しさん:02/03/02 22:09
>>48

あなたがいうお荷物さんとは、具体的には、どんな仕事をやってたんですか?
50仕様書無しさん:02/03/02 22:16
>>49
具体的にはプログラムを組めないからプログラマに的確な指示を
だせず、プロジェクトに損害を与える。それが自分のせいだと
わからなくて他人を責める。
このスレで話題になっている人種だよ。
51仕様書無しさん:02/03/02 22:25
>>50

うーん、どうでしょう。
いくらプログラムを組めたところで、プログラマに指示をして、
それがうまくいくとも限りません。

その必要な機能をどのくらいの期間で作れるかはプログラマ
本人しか分かりません。


やはり、XP の導入の必要性を感じますな・・・。
52仕様書無しさん:02/03/02 23:10
> その必要な機能をどのくらいの期間で作れるかはプログラマ
> 本人しか分かりません。

つまり、プログラマの仕事量およびスケジュールを見積もるには、
プログラマの仕事(の質と量)が分かってないといけないという、
あたりまえの結論に。
53仕様書無しさん:02/03/03 00:18
このスレ、タイトルが悪いね。
タイトルに ERPとか出していれば、
無意味な SE-PG論にはなりにくかったろうに。
541:02/03/03 00:59
すんまそん。。

XPってのは要するにプログラミング以外の世界では
最近流行っている報連相と同義語と解釈していいのでしょうか。



55仕様書無しさん:02/03/03 01:08
>>54
なにを考えているのか分からんが、ここで出てきているXPとは
eXtremeProgramming (エクストリームプログラミング)のことだよ。
56仕様書無しさん:02/03/03 01:14
ホウレンソウと言われれば、まぁそういう意味も含まれてるか。
なんかイヤな表現だが。
57仕様書無しさん:02/03/03 01:18
というか、対外交渉も含めて最適な解が思いつける人が
SEと名乗るべき。
58仕様書無しさん:02/03/03 01:33
なんでSEってヴァカばっかなんだろうね。
稀によくできるSEに出会うと本当にビクーリするよ。

ヴァカSEとは・・・(一例)
・不勉強なくせにやたらと偉そう(圧倒的大多数)。
・プログラミングは能力の無い者のやることだと思っている
 (「お前やってみろ!」と言いたくなる・・・やらせても大概できない)
・時代の流れに疎い。私のような世捨て人のPGからみても
 時代遅れな開発手法しか知らない。
59仕様書無しさん:02/03/03 01:34
SEのSはスーパーのSであるべきだ、ということで一件落着かな
60仕様書無しさん:02/03/03 01:38
開発において、ホウレンソウを円滑に行う常識的な習慣を集めパッケージに
したのが eXtreme Programming とも言えますな。

XP では人、コミュニケーションが何より大切にされます。
61仕様書無しさん:02/03/03 01:39
>>58
「稀によくできるSEに出会うと本当にビクーリするよ。」
よくできるSEって、どういう人ですか? ヴァカSEと正反対の人?
62仕様書無しさん:02/03/03 01:48
>>61
人にきく時点でだめだめ。
身をもって知るべし!
63仕様書無しさん:02/03/03 01:48
稀にしかいないからなぁ。
漏れ的SE・PGの線引き
前提条件:ユーザーよりもシステムに詳しい
対人折衝能力のある人→SE
対人折衝能力の無い人→PG
PGは頭脳どかたと考えている人→SE
コンピュータ以外にはなんにも出来ない人→PG

つうかさ、PGもいずれはSE(セールスセンジニアの方ね)をやらなきゃいけなくなるのだからさ、
ちょっとは、この業界を変えてやるぐらいの意気込みのある人が出てきて欲しいのだけど・・・。
65 :02/03/03 01:55
日本の「SE」なぞ世界では通用しない。
対外交渉はSEの仕事ではない。
SEはシステム設計のエキスパートであるべき。
当然、PGの親玉みたいなプログラミングの知識も必要。

>>64 SEってのは普通システムエンジニアのことだが?
66仕様書無しさん:02/03/03 01:55
就職板のSEスレ見たことあるけど、業務内容を知らないまま
SEを志望する新卒(非工学部系)の多さに、ビックリしたことがある。
人事に「プログラムはすぐにくめるようになる」などとほのめかされ、
上流工程と下流工程と言う言葉を意味も知らず連発し、
上と下では上の方が偉いに決まってるという認識で、
PGよりもSEを志望している学生がかなりいた。
奴らに、情報工学という分野が何の為にあるのかを教えてやりたい。
67仕様書無しさん:02/03/03 01:58
>>64

どうかな・・・。
外部の人間がビジネスのことどのくらい理解できる?

コンサルタントってそんな簡単な仕事じゃないはず。

(しかし、その割に、そのビジネスが失敗したら、そのコンサルタント会社が
責任取るってことは無いんだよね。なんか胡散臭いよな・・・<コンサルタント)
68仕様書無しさん:02/03/03 02:00
プログラムできなくても問題なし。
会社があなたを採用したのは、業務知識 があるから。
客先の業務内容(運用)を理解して、対話することが重要な仕事。
そしてSAPに置き換えるには、どうすればよいかを検討する



69仕様書無しさん:02/03/03 02:00
>>65
対外交渉というより要求仕様分析ですよね。
昔は、PGとSEの区別はもっとはっきりしてたんですが...
70仕様書無しさん:02/03/03 02:01
>>66
今のハヤリはコン猿です。
情報工学とか情報科学とかのやぼったい知識はともかく
とりあえず「コンサル(ーん)」が大事らしいです。
71Delフサギコ ◆zE1iiRdQ :02/03/03 02:03

    ∬   ∧,,∧      / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ~━っミ ゚Д゚彡,,    <  SEって名は本当に忘れた方がいいね。
    ∀._(,,,~  ,,,~⊃_   \____________________
━┳┷ |. ,(~ヽ,,,ミ.
  ┃...| ̄ ̄し'J.  ̄ ̄ ̄
  ┻ ヽ ̄ ̄ ̄ ̄ ̄ ̄ ̄

XPでは@PG、A管理者、B顧客
これは
@開発者、
A開発者のまとめ役とかリーダーとかそんな人
B顧客がやってることを理解している人

ってのにわけられるね。Aは必要ない時もある。

いわゆる"プログラムが組めないから逝ってよしなSE"
ってのは開発者という立場で未熟な人だね。
でも、SEとしてA…はちょい難しいけど
Bの役目は十二分にこなせるよ。Bに徹するとよい。

よくできるSE=話のわかるSE かな。

とにかくコミュニケーションは蜜にとりましょう。
開発者とも顧客とも。それこそ、恋人のごとくね。
そうすれば大体、うまくいくんじゃない?

とりあえずSEって単語に対して
しっかりしたイメージを持っている奴は信頼するに値しない。


話戻すけど、SAPのコンサルっていって
SAP社に入ると思うってのは、どうかと…>>38
72仕様書無しさん:02/03/03 02:05
今の学生はノンポリばかりだからな。
そういや、バブル景気のころ証券業界に入って、バブル崩壊で悲惨な目に学生が随分いたな。
73仕様書無しさん:02/03/03 02:13
ちゃんとした要求定義から分析までをしっかりこなせるなら
それだけで飯食ってくのもありかもね。だけどこれってPGとして
必要とされる知識よりもかなり多くの知識が要求される。
これがしっかり出来るならエンジニアとして呼べるだろうよ。
でも出来る人なんてごく僅か。またそれだけの為に人を割り当てる
プロジェクトってかなりでかいものばかりだし。
74仕様書無しさん:02/03/03 02:15
元R/3のFI(財務会計モジュール)コンサルです。
その前にPG、SEやってましたけど、流行に乗って転職した口です。
あまりの酷い状況にさらされて、素直に辞めました。
今はJavaでWebアプの設計から実装までやってます。

でね、ここの板の人の思ってるSEと、>>1のいうSEてのは
全く別物なので、そこんとこちゃんと自覚してればそれで良し。
つかR/3使いがSEいうな。ムカツク。ABAP書いてPG気分やってろ。
R/3のカスタマイズできる程度で経営コンサルぶって経営語るな。
・・・って言いたくなる奴多し。全部がとは言わんが。

でも人月300万円だったので当時は給料良し。儲かる儲かる。死ぬほど
忙しかったけどな。今は給料は下がったけど、客に対して堂々と出来る
状態に戻ったよ。アドイン1本(フツ〜のVBとかなら20万円もらうのも
恥ずかしいくらいのレベル)作るのに100万単位の見積なんて、羞恥心が
あったら出せないだろ、普通。所詮、金持ち同士のITゴッコだ。
人間であることを捨てれば稼げるぞ>>1よ。頑張れ(藁
75仕様書無しさん:02/03/03 02:21
>>68 経理屋出身は人は良いが対話できねぇ奴多し。良し悪しは別でな。
1はSEってのをセールスエンジニアと読み替えて、営業の勉強に励むよし。
SIerならマシだが1が外資系のコンサル会社に入るんなら覚悟しておけ。
腕は要らない。口が食い扶持だ。
76仕様書無しさん:02/03/03 02:21
俺が今かかわってるプロジェクトは100人近い人間がいるよ。
もちろん、いくつかのグループで構成されているんだけど...
俺、最初は要求分析と設計だけやってたんだけど、
納期が迫って、今はプログラム書いたりデバッグ手伝ったり...
自分が SE なのか PG なのかよくわからんよ。
77Delフサギコ ◆zE1iiRdQ :02/03/03 02:31
  ∧,,∧   / >>76
  ミ,,゚Д゚ミ <   当たり前でしょ
  ミ   ミ   \ 
〜ミ,UU_ミ  

  って…要求分析と設計が出来なくて
  プログラムなんて組めませんが。
78仕様書無しさん:02/03/03 02:33
>76
SEやPMが現場に降りたら、もう大体だめだよね。
79仕様書無しさん:02/03/03 02:34
>77
サブシステム自体の要求分析なんだよ。3層C/S
80仕様書無しさん:02/03/03 02:43
>>76

こういうのがドキュンSEと言うんですね。
(設計してプログラミングしないなんて、アホかっちゅーねん)
81仕様書無しさん:02/03/03 02:44
えっ、SEがプログラム組むの?
82仕様書無しさん:02/03/03 02:49
>>73

XP的には、あなたの言う仕事は全てプログラマの仕事でございます。
83仕様書無しさん:02/03/03 02:51
80 は大規模プロジェクトを知らんらしい...
84仕様書無しさん:02/03/03 02:51
>>78
うちでは経営者まで現場におりてきます
85仕様書無しさん:02/03/03 02:51
>>84
きっついなー。
86仕様書無しさん:02/03/03 02:52
>84
その経営者、偉いよ。
87 :02/03/03 02:56
>>86
偉いと思うけど。
会社としては先が見えたなと思わないか?
88仕様書無しさん:02/03/03 02:59
>>76
とすると、自分でプログラム書いたりせずに、ライブラリなど次のプロジェクトで
役に立つものを今は設計したほうが、全体的には楽になるかもよ。
891:02/03/03 02:59
74>あまりの酷い状況にさらされて

忙しすぎてということ?それともぼったくりのような商売しているってこと?

宜しかったら教えてください。
90仕様書無しさん:02/03/03 03:00
>>74
>所詮、金持ち同士のITゴッコ

僕もそんな気がしますね。システム作りしている会社って、今、
バブルじゃないの? という気がしてます。

ちょっとお金持ちの企業が、ITを使ったビジネスの成功例を参考に
して、じゃあ、私たちも、と考えているんでしょうけども。
果たして、本当にリスクに見合うだけの投資なのかどうか。

まぁビジネスのことは、当事者しか分からないので、何とも言えま
せんが・・・。

プログラマは顧客の求める機能を実装するのみ。


>>76

フサギコが言ってたように、もう本当に「SE」ということを言葉を
使わないようにしたいものです。


>>87

偉い。最高の顧客。プログラマ的にはそれが一番ありがたい。
91仕様書無しさん:02/03/03 03:00
設立して何年経ってるかによるな。
立ち上げてまもない会社なら、こういったことは珍しくないだろうけど...
92仕様書無しさん:02/03/03 03:02
SAPはプログラムってほとんど組まないんでしょ?
むしろ業務にたいする分析力が必要だから、コンピュータ経験の長い奴より
経理経験のある奴の方がいいんじゃないかな。
僕はゲーム業界からシステム業界にきてるから一生、ERPは縁のない世界だ。
93仕様書無しさん:02/03/03 03:07
大規模プロジェクトにもXP的手法をとりいれることは出来ないかな
94仕様書無しさん:02/03/03 03:07
>>90
日本は業務コンサル能力と技術コンサル能力を兼ねたSEがまだまだ
少ないからね。
たいがい業務コンサルは口しか出さないで設計は書かない。
ほとんど技術SEが仕様、設計を考える。
できあがったシステムはほとんど技術SEのアイデアをもとに作られたシステム。
業務コンサルは会計士や税理士や業務経験のあるだけで、
システム化ということに対してはまったく勉強してないのが多いよ。
95仕様書無しさん:02/03/03 03:08
>>94
>業務コンサル能力

営業みたいなもんすか、それって
96仕様書無しさん:02/03/03 03:09
>>93
難しいね。半分要求分析して、10人ぐらいのグループに分けてそれから XP
なら何とかなるけど、100人なら10グループに分けるまでが難しい。
97仕様書無しさん:02/03/03 03:10
>>90
>>91
社長の定義が違わないか?

>>90 顧客側の社長?
>>91 開発してる自社の社長?

で、どっちよ。 >>84
前後のレスの文脈的には、自社みたいだが。
そりゃ…やばそうだよな。(w
98仕様書無しさん:02/03/03 03:11
>>94

XP的には、それで結構!! むしろ、実際にコーディングしない人間が
技術的なことに言及されてると、迷惑。
99仕様書無しさん:02/03/03 03:12
>>95
違います。
その業務に対してどういうシステムを作るかを考える人です。
場合によってはコンピュータに人をあわせて効率化をあげるような
ことをしてもいいのではないかと思うが、ほとんどのシステムは
それをやってない。
ただ紙やペンを使わなくさせればいいと考えてるだけのシステムが多い。
現状では紙、ペン、電卓のかわりにただシステムが作られているだけだよ。
100仕様書無しさん:02/03/03 03:14
>>98
コーディングってシステムではそれほど重要ではないでしょ?
プログラムなんて一、二週間勉強すれば大丈夫だしね。
101仕様書無しさん:02/03/03 03:14
>>99
ますますSEとの違いが分からなくなってきた。
102仕様書無しさん:02/03/03 03:19
>>101

SE という概念を捨てよう。

>>99 さんの申していることは。
コンピュータ化する際に、こういうことできますよ、っていう提案する
コンサルタント営業の人やね。
103仕様書無しさん:02/03/03 03:21
>>101
ワークフローみたいなもんがきちんと定義されていない業務をシステムにしろ
って言われるのは面倒でしょ。だから、業務自体の流れを先に改善するひとが、
業務コンサルで、それをシステムに落とすのが技術SEっていうことでしょ
104仕様書無しさん:02/03/03 03:22
>>100
やっぱネタ・・・だよね。
105仕様書無しさん:02/03/03 03:26
>>100
その辺はやっぱり生まれついての性質がものを言うなぁ。
だめなやつはだめ。
106仕様書無しさん:02/03/03 03:28
>>100

顧客にしてみれば、確かにコーディングなんてどうでもいいです。

今、どの機能が実装されているか、という進行状況を常にトラッキング
することが重要で、もちろん、顧客にはその権利があります。
107仕様書無しさん:02/03/03 03:28
SE は顧客の要求を分析し、システムのモデルを考え、
どこを自動化(コンピュータ化)するか等を、顧客の予算に応じて考える。
自動化する部分が決まったら、そこの外部仕様や処理方式を決定する。
ここまでが、SEの仕事だと思うな。
外部仕様や処理方式が明確になった時点で、PG に回す。
詳細設計、単体テストはPGの仕事。
総合テストは SE 立会い。
こんな感じかな。
108仕様書無しさん:02/03/03 03:32
>>107
予算は何を元に決めるの?
109仕様書無しさん:02/03/03 03:32
なんか、XP の話してる人がいるけど実際にやってるの?
すげー興味あるんだけど。
110仕様書無しさん:02/03/03 03:38
>>107

そういうふうに言うと、わりと明確だとは思うのですが。

全ての会社のSEという概念が >>107 さんのいうように
明確なわけでもないのが辛いところ。

しかも、プログラマと顧客が直結するメリットが大きい。

SE という役割もぼやーんとしていて、それならコンサルタントと
言うほうが分かりやすい。

SE という言葉は本当に曖昧でよくないと思う。
111仕様書無しさん:02/03/03 03:39
>>108
まず顧客の要求を全て聴いて、それぞれの要求にたいしどれくらいの工数(費用)がかかるかを見積もる。
当然ある程度のスラックをいれておく。
そして、それを顧客に提示するんだ。
後は顧客に決めてもらう。
顧客は要求自体を取り下げる場合もあるし、次期案件となる場合もある。
112仕様書無しさん:02/03/03 03:40
>>108

一番当てにあるのが、「前例」だと思う。
一人一人のプログラマの見積もりも同じで、一番見積もりのいい方法が
「昨日できたことは今日もできる」
113仕様書無しさん:02/03/03 03:43
>>107
外部仕様は画面や帳票でいいのかな?
処理方式とは何のことを指してるの?
114仕様書無しさん:02/03/03 03:54
>>113
外部仕様とは、顧客が見たり操作したりできる全てのものの説明。マニュアルみたいなもんだ。
処理方式は、顧客の要求とは直接には関係しない。
システムの個々の部分において、即時処理にすべきか一括処理にすべきかといった決定だよ。
工数のことを考えて、もっと細かく決定することも多い。
ソケットにするかRPCにするか、既存の部品を流用できないかとかいう判断だよ。
115仕様書無しさん:02/03/03 04:02
>>89
昔を思い出して可哀想になってきたので(俺自身がだw)、真面目に
書いてやる。

酷いのはぼったくりのほうだな。が、最初にぼったくるから後で
死ぬほど忙しい。

でだ。付け焼刃で出来もしない業務プロセスを知ったかぶって
押し付けるのがERPコンサルだ。違うというなら、ERP抜きで
成功報酬で経営コンサルをやってみればいい。出来る奴は殆どいない。
何故なら出来る奴はERPなんて土方やらなくても儲かるからだ。
116仕様書無しさん:02/03/03 04:02
それはさておき、口だけの押し付けプロセスが業務仕様として決まるとだな、
それをパッケージ上に実現しないといけない。でな、これが出来ないんだよ。
当然だ。Gap&FitなんていうがFitする箇所なんてないんだよ。しかし、この
時期になるとコンサル側は出来ませんとは言えないわけだ。そこで帳尻を
合わすために、技術者に押し付けるわけだ。具体的にはR/3ならアドオンだ。

で、だ。この状態でいわゆる本当のSEが呼び出される。フリーハンドなら
いいのだが、何せGapだらけのパッケージを使うのが前提だ。何せ数億だからな。
ハードも合わせると10億近くなる。利権の塊だ。見積の値引きが数億なんてことも
ある世界だ。さすがに破棄するわけにはいかん。なので無理やり作ることになる。

コンサルも暢気な事はしてられなくなる。最近はちゃんと動かないと訴訟も
あるからな。だもんで、結果として死ぬほど忙しくなる。
117仕様書無しさん:02/03/03 04:02
で、だな。駆り出されたSEやPGから見れば、無能なコンサルを殺したくなる
わけだ。しかしコンサルにはどうすることも出来ない。当然だ。スキルないから。
かくしてエンドユーザにとっても不幸なシステムの出来上がり。でもって
一部の偉いさんは出世するという段取りだ。

しかし1よ。これが事実だが、決して現場でそんなことに悩むな(藁
真面目に考えて、SEやPGのことまで考えるようなコンサルはすぐに
切られるぞ。でな、元経理屋のERPコンサルくずれは、よっぽど実績を
積んでおかないと潰しが効かないから覚悟しておけ。人の生き血をすすって
口八丁に磨きをかけてカネを溜め込んでおけ。そうすれば違う道が5年後には
開けるよ。

繰り返すぞ。ERPコンサルなんて本当のコンサルタントではない。そんなものを
期待していくと人生間違えるぞ。ぼったくりのテクニックを磨きにいくんだ。
ついでに現金ももらえるぞ。後、夜道には気をつけれ(藁
118仕様書無しさん:02/03/03 04:03
FI経由で本当のコンサルになりたいのなら、会計士のレベルは余裕で到達しておけ。
ERPコンサルのITスキルなんて世間は評価してないからな。
原価企画くらいは語れないと駄目だぞ。EVAとかバリバリになれ(笑)
今度入社する会社の次のパスを最初から考えて行動しないと消耗品になるぞ。
あと2回は転職する覚悟決めておけ。

何を好き好んでとも思うが、俺も入るまでは薔薇色の未来を夢想してたので
気持ちはわかる。まぁがんばれ。
119仕様書無しさん:02/03/03 04:03
あとな、経理っていっても今までいた会社の経理しかやったことがないなら、
気合入れるこった。俺はPG,SE時代に色んな業種の財務システムをやってきた
おかげで困らんかったが、業種が違うと勘定科目ひとつで戸惑うらしいぞ。
思い込みは厳禁だ。それとな、R/3は結構面白い。各モジュールが吐き出す
仕訳のパターンとシステマティックな振替伝票の技を知ると、会計というものの
奥深さと面白さを再認識できるぞ。会計は非常にロジカルだ。プログラミングと
相性が良い。そのロジックを理解できれば、ここの板の連中に馬鹿にされない
程度のプログラミングスキルも努力すれば習得可能だ。ま、そんな余裕は
ないだろうがな。

そうそう、ソフトリサーチセンターから出ている
「〜SEならこれだけは知っておきたい〜
 経理・財務知識の再入門講座」
という本は事前に読んでからアカデミーにいけ。R/3特有のトリッキーな
特殊仕訳などまで解説している。前半は普通の財務システム入門だが、
自分の経理知識の棚卸にもなるはずだ。

ま、後は毎日自分の鏡を見て、醜くなっていく自分に自己嫌悪しないように
人生のキャリアパスをしっかりと描いて頑張ってくれ。

長文スマソ。以上だ
120仕様書無しさん:02/03/03 04:12
>>119

これはすげぇ。熱い文章だ。

(僕は単に機能を実装するだけのプログラマなんですけども)
そんな不幸なシステムを生みだすコンサルタントに関らない、
自己防衛方法としては、

「プログラマが見積もりに参加できないプロジェクトには関らない」

これに尽きる。
121 :02/03/03 04:12
まだCOBOLが業界のメインだった頃にSEと呼ばれた人達の業務のひとつとして、
「電算化によるシステムの効率を最大限に上げる為、顧客がコンピュータに
合わせるように要求し教育もする」というのが含まれていました。そして、
歌って踊れるSEを目指せという言葉もありましたが、つまり接待上手でないと
仕事を取れないし、人間関係も上手くいかないという戒めを込めた言葉でした。
これは当然、システム設計もコーディングも出来た上での話です。
そしてその頃はよく「人間がコンピュータを使うのではなく、コンピュータが
人間を使う時代がくる」という話もしていました。
しかし、かつてのSE達は何処かへと消え去り、コーダーやパンチャーと呼ばれて
いた人達がいつの間かSEを騙って昔話をするうちに、いつの頃からかSEは無能で
ある事を指す代名詞の様になってしまいました。
122仕様書無しさん:02/03/03 04:13
>>119
一度あってみたいね、面白そうな奴だ。
123仕様書無しさん:02/03/03 04:22
組めなくてもいいから、設計書ぐらい書け。
プログラム言語を操れるのと設計書が書けるのは別だからな>全国のSE諸君
124仕様書無しさん:02/03/03 04:22
>>121
コーディングがまるで出来ないSEが昔からいたとは思えない。
いつからだろう、大手SIがPG経験のない人間にいきなりSE職をさせるようになったのは。
125仕様書無しさん:02/03/03 04:26
>>123 >>124

いや、もう だから、SE という言葉の意味自体が曖昧ですから、いくらあなたが
SEについて主張なさっても、ほとんど無意味です。
126仕様書無しさん:02/03/03 04:27
昔のSEは、コーディング、バリバリでした。
神でした。
127仕様書無しさん:02/03/03 04:28
>>125
業務コンサル、技術コンサルに分断するにしても、結局は両者とも「歌って踊れる」
SE的知識を要求されるのでは?
128115-119:02/03/03 04:30
>>1よ、最後にもうひとつだけお節介だが追加しておこう。
本当のERPの価値を知りたければ、生産管理を勉強しろ。
これも非常にロジカルだ。面白いぞ。生産管理を単に
製造業の1プロセスとして捉えるのではなく、資源配分の
ロジックとして見直して、それを会計で常に定量化して
把握するということを考えれば、ERPそのものがいかに感動的か
実感するぞ。しかしいきなりPPは辛いだろうから、FIに慣れてきたら
MMに手を出してみるといいだろう。会計だけに染まりきると
潰しきかんぞ、ほんと。ま、とはいえFIだけでも大変だがな。

ERPの本質を理解できれば、面白い仕事ができるはずだ。
ま、それでもR/3は(以下略)。とにかく頑張れ。俺は寝る。
129仕様書無しさん:02/03/03 04:33
>>127

だれが何を分析するんですか?
歌って踊れる、とは、どういう意味ですか?
SE的知識とはどういう知識ですか?

(せっかくのいいスレッドなので、できるだけ明確にお願い。
あと、何度も言われてますが何度も言いましょう。SE という言葉は曖昧なのでできるだけ避けてください)
130 :02/03/03 04:40
>>129
昔のSEってのはXPで言えばPGであり管理者であり顧客でもある事を
要求され、またそれを満たしていた人の事です。
もちろんそうでない人もいましたが。
そのうち「XPも今は昔になりにけり」と言われる時代がきます。
131仕様書無しさん:02/03/03 04:43
>>129
前スレでも似たような話が出ておりましたが、「歌って踊れる」っていうのは、
顧客折衝→要求分析→設計までこなすのがSEではないか?ということ。
当然、業務知識&技術知識が必要になるわけで…。

逆によい呼称があれば教えてください。
132仕様書無しさん:02/03/03 04:49
>>130
PGを何年か経験してSEになる、っていう流れも、「SEはPGとしての知識を必要とする」
ということが不文律としてあったからではないでしょうか。

プログラムを知らなくとも機能レベルまでの落としこみはSEで出来そうな気がしますが、
問題は「見積もり」ですかね。
結局、顧客折衝の中でスケジュールとかは決定していくものですから。
133仕様書無しさん:02/03/03 04:56
>>132
やはり工数の見積もりだろうと思います。
これは、PG やった人間が一番わかるとおもいますよ。
PG の経験がない人間には、この見積もりはかなり難しいのではないですか?
PG 経験の浅い、あるいは全くない SE が増えてるから、軋轢が生まれてくるのでしょうね。
PG も SE も最終目標は同じはずなんですが...
134 :02/03/03 05:17
>>132
>PGを何年か経験してSEになる、っていう流れも、「SEはPGとしての知識を必要とする」
>ということが不文律としてあったからではないでしょうか。
昔は「コンピュータは何でも出来て凄いらしい」程度の知識しかないクライアントに
ふっかけられた無理難題を手練手管で「それは無理だけど、こうしていいなら出来るし
コンピュータが凄いのは確かだ」と言いくるめて金をふんだくる、いや説得するのも
SEの役割でしたので、「コンピュータには何が出来るか」が分かっていない人をSEと
呼ぶのは途方も無く馬鹿げた事でした。もちろん、「コンピュータには何が出来るか」
とはつまりプログラムを作るという事が理解出来ているかという事です。

>問題は「見積もり」ですかね。
>結局、顧客折衝の中でスケジュールとかは決定していくものですから。
ここで本当に「歌って踊れる」という要素が重要になってきたり。
135仕様書無しさん:02/03/03 05:18
横槍ですが、工数の見積もり苦手です。

趣味で長いことプログラム書いてきたので、
どれくらいの期間でできるかなんて把握できないし、
俺より出来る人もなんにもできない新人君も
同じ1人/日で計算なんてできるわけないじゃないですか!!

この業界はどうなってるんですか!?
136 :02/03/03 05:25
>>133
>PG 経験の浅い、あるいは全くない SE が増えてるから、軋轢が生まれてくるのでしょうね。
現在SEと呼ばれる人に求められている一番大きな要素であり、また一番欠けている要素は
いわゆるオンサイト顧客という役割だと思います。すべての役割において未熟なSEは、
金払いと物分りの悪い客先に匹敵すると思います。
137仕様書無しさん:02/03/03 05:25
>>135
自分自身でも工数の見積もりが出来てなきゃ話にならん。

新人などを使う場合は自分工数xそれなりの係数じゃないんですかふつう。

138 :02/03/03 05:29
>>135
>俺より出来る人もなんにもできない新人君も
>同じ1人/日で計算なんてできるわけないじゃないですか!!

新人君は0.5人/日で計算しましょう。
実際にはもっと少ないかも知れませんが、それは出来る人がカバー。
139仕様書無しさん:02/03/03 05:34
>>135
この業界じゃ人/月とかで費用をを弾き出されることが多いですね。
無能な人間も有能な人間も基本的には同じ価格です(学歴による単価テーブルは存在しますが)。
そういった慣習を打ち破るのは難しいことだと思います。
経験者は、未経験者の2〜3倍は仕事をこなせるものです。
だからといって、経験者の売上が未経験者の2〜3倍になることってないですからね。
おかしな話ですよね。
140仕様書無しさん:02/03/03 05:36
>>135
見積もりはともかく工数が計算できない奴は終わってるな。
普通は一年この業界でやってればだいたい見えてくるだろ?
趣味でやってた?だいたい趣味のレベルがわかるよ(w
141narucy56:02/03/03 05:39
narucy56

ERP パッケージといっても、そう難しく考えることは無いと思う。
ERPパッケージとして求める機能を決めるのは顧客か、または、それを提案するコンサル
タントの仕事。開発の段階では、プログラマと顧客は密にコミュニケーションしてスト
ーリを定義し、一つ一つ、必要なものから作っていく。


今のシステム開発企業では、この顧客とプログラマが全くコミュニケーションが出来ない
状況。これはどうにかしなきゃいけない。

それよりは、ビジネスを理解するコンサルタントが近くにいれば、プログラマにとって顧
客の代わりになるから、少なくとも誰もビジネスを理解する人がいないよりは嬉しいと思
う。(本当は真の顧客が近くにいるのが最高なのだけど)

--
(気がつくと、こんなに書き込んでた。
6,8,9,11,16,20,24,44,49,50,60,67,80,82,90,98,102,108,110,120,125,129)
142仕様書無しさん:02/03/03 05:43
>>141
君のいうXP的手法ってどんなんなの?
実際にXPエクストリームでのプロジェクトにはいってるの?
教えてちょ&hearts
143narucy56:02/03/03 05:47
>>142

XP を知るのは関しては本を読むのが手っ取り早いと思います。

僕はERP パッケージの開発に携わったことは無くて、もっと要求のはっきりしたものしか
作ったことは無いです。XP を全面的に取り入れたプロジェクトに関ったことはありません。
144仕様書無しさん:02/03/03 05:48
>>141
XPのオンサイト顧客ってコミュニケーションの手段どう定義してたっけ?

クライアント先での打ち合わせって結構時間とられんだよなぁ。。。
145仕様書無しさん:02/03/03 06:22
>>135
趣味ね…。
例え趣味でも、本当に長い期間組んできたなら、
最低限、自分の工数くらいは解ると思うが。

あんたがヘタレなだけだろ?(w
146仕様書無しさん:02/03/03 12:25
>1
本題に戻りましょう。
まず、通用するかという点ですが、世間一般のSEとしては
まったく通用しません。ただSAPの世界では、会計の相談係り
としての仕事はできるでしょう。また営業の仕事もこなせるかも
しれません。
ただ忘れていけないのは、あなたはそれなりの給料はもらえますが
それは実力ではなく、世の中の恵まれないプログラマからかすりとった
給料、SEという定義が現在でもつうようするなら世間の優秀なSEから
かすりとった給料であるということです。
すこし、きつい言い方をしましたが、世間では実力があっても正当に
評価されず、リストラされている人々が相当数いると言うことを忘れないでください。
IT産業にはまだバブル経済が残っている部分もあるのです。
1471:02/03/03 12:41
115-119.128さんどうもありがとうございます。
非常に参考になりました。また現状を非常に分かりやすく
説明していただき感謝しております。

やはりSAPも流行り物で終わってしまうのかなあ。。

どっちにしろERPが業務構築のスタンダードにはなるのは
難しいってことでしょうか。

1481:02/03/03 12:45
146さんもありがとう。


149三流私大生:02/03/03 13:26
ERPってそんなに流行ってんの!?
大学でSCMの講義受けたときに出てきたんだけど、
大学の年季の入った教授が教えるからもう古い概念かと思ってた・・・
150仕様書無しさん:02/03/03 13:47
>>149
ほかの技術はすぐに廃れるけど、ものが経済だけに絶対に廃れないでしょ。
使っている技術のほうは廃れるかもしれないけど。
151名無しさん:02/03/03 14:43
>>139
自分に製造原価という考え方がないことを表明しているだけですね。
152 :02/03/03 15:10
SE試験問題

問1 システム工学
  コンピューターを使わないシステムを5つ挙げなさい。(10分)

問2 論理学
  ド・モルガンの定理を論理式で書きなさい。

問3 コンピューター一般
  コンピューターの構成要素を挙げなさい

問4 言語
  略
153仕様書無しさん:02/03/03 15:11
顧客要求の分析、設計のできないPGと、ドッコイドッコイ。
154仕様書無しさん:02/03/03 15:41
要求は分析するものじゃなくて
定義するもの
155仕様書無しさん:02/03/03 15:48
コンサルなので通用するでしょう。
(もちろんプログラムの知識があるに越したことはないですが)
開発でも、基本設計より上流で十分役に立つはずです。
仕様が分からず、ただひたすら製造してるPGよりも有用でしょう。

2CHで無知な学生やオタクの意見を聞いても仕方がないと思いますが。
156仕様書無しさん:02/03/03 15:58
>>155
カコイイ!
別にPGを馬鹿にしてくれてもかまわんが
無理な納期で仕事取ってくるなよ。
157仕様書無しさん:02/03/03 15:58
>>155
同意。
というかERP知らないのならでしゃばってこなければいいのに
スレ違いのSE不要論がでてくるのはやっぱりここの板のレベルの
低さなのだろうか?
それともレベルの低い奴が沢山レベルの低いレスを繰り返しているだけ?
158仕様書無しさん:02/03/03 15:59
>>156
早速現れましたね。レベルの低いあなた(w
159低レベルPG:02/03/03 16:01
呼んだ?
160仕様書無しさん:02/03/03 16:12
情報システム板とかこのスレ読んでると、
ERPって詐欺にしか思えないんですが、
実際はどうなんでしょうか?

SAPには何百人もの研究者がいて日夜
経営について研究を重ねているのでは
ないですか?
導入に対する弊害が日本の場合は大きいと
言われて久しいのですが、それとてもう
何年も言われていること。少しは開発元に
ノウハウが溜まってもいいころだと
思うんですが。
161仕様書無しさん:02/03/03 16:19
プログラマー版らしくないのからしいのか

通常ならばSEがPGできなくてもOK
だが
最近はそういった人間には仕事がこないことが多い
とくに新しくはじめるとかになると
現在にそれなりのネットワーク(伝ともいふ)がないから
大変じゃないだろうが

こんなはずではといったかんじの再転職組は多い
16274=115-119=128:02/03/03 16:29
今起きた。>>160 ERPそのものが詐欺ではない。ERP「ビジネス」が
ぼったくり商売だということだ。オプソのERPもいくつか存在する。
JP対応してはいないが、多言語・多通貨などにも対応している。
かなりちゃんとしたものがある。俺はERPの理念は良いと思ってるが
今のERPビジネスには誠実さが皆無だと思っている。俺は幸いコード
をまだまだガシガシ書いているので、オプソのERPに出来るだけ関わって
いきたいとは思っている。ま、英語の壁は大きいがな(泣

で、R/3に話を絞れば、経理屋上がりが技術的裏付けなしにFIのSEでも
コンサルでも呼び名はどうでもいいが、やってたとしてもカスタマイズ
データをエントリするための所詮オペレータに過ぎないってこった。
経理屋は仕訳は見れても、仕訳を通したプロセスをイメージする力が
ない。それはそういう仕事をしてなかったんだから仕方がない。
ERPは会計を正確にするのではなく、業務の「プロセス」を変えるものだ。
だから仕訳とプロセスの関係をシステマティックに把握して、かつ
今までとは違う「新しい(=見たことがない)」プロセスを提示できなければ
高給取りのコーダに過ぎなくなるわけだ。だから潰しが効かない。

だから1よ。真面目にスキルをつけたいなら、仕訳を仕訳としてみるな。
仕訳の元になっている業務機能とそのプロセスに注目しろ。会計の知識を
ゼロリセットする覚悟をもて。しかしそうするとド素人になるから、
周囲に冷たい目で見られる。当然だ。高給取りなんだからな。

R/3そのものは悪くない。だがR/3で「なければならない」わけでもない。
ERPという理念は企業の大小と問わず非常に有用だ。だが、実現手段は
今のERP「ビジネス」に貢がなくても他にもあるということだ。
逆に腕に覚えのあるSE,PGがもっとそこにコミットすると、価格破壊・構造改革
を実現できて、面白いと思うぞ。

日本への導入が難しいのは、プロセスの特殊性もあるが、そのプロセスが遂行
されている企業の文化や風土に原因がある。

プロの経営者がいないのだから仕方がないがな。優秀なプログラマを極めるのも
優秀な経営者を極めるのも、どちらも非常に修練が必要だ。出世のゴールが
社長という旧来の日本企業ではプロの経営者にはなり辛い。そういう経営者には
ERPという道具は使いこなせないのだよ。厨房PGがプログラミング言語を使いこなせ
ないのと同じこった。
163仕様書無しさん:02/03/03 16:38
Systematic〜♪
Systematic〜♪

ウォー!!!    by the mad capsole market
164仕様書無しさん:02/03/03 16:41
>>162
オープンソースのERPって例えばどんあのがあるんですか?
教えてください。
16574=115-119=128:02/03/03 17:00
探せよ(w それこそ君らの嫌いなSEやコンサルや営業などに馬鹿にされるぞ。
オプソなんて守備範囲だろ? sourceForgeに逝って、ERPで検索しろ。

俺が注目しているのは、CompiereERP/CRMって奴だ。R/3もビックリって
感じだな。そりゃ言い過ぎか(笑)。pure Javaなので、俺のような
Java屋にはピッタリだ。とはいえ、ちゃんとR/3などのように、言語知識が
なくてもカスタマイズできるようになっている。他にもgnuERPとか色々とあるぞ。
ま、凄いのもあれば、お前ERP言いたいだけちゃうんか、ってのもあるがな(w

ちなみに、ERPというのはマーケティング用語だと思ってる。というのは、
通常の経営理論(生産管理ならTOCとかMRPとか、まぁCRMとかもだな)というのは
ちゃんと本当に理論化されていて、それを実装したソフトウェアがあったり
するんだが、ERPは、そういう理論がなく(amazonでERPで検索しても、理論書は
皆無だ。全部パッケージの解説書だしな。)、ERPパッケージにしても
Planningといいながら計画機能が貧弱すぎて、SCMソフトなどに
頼っていたり、HRM周りの人的資源配布計画のようなところにMRP的なロジックが
入っていないなど、幕の内弁当的な組合せに終始しているからだ。
かろうじて言えば、日本でいうDOAが理論背景だな。データセントリックって
奴だ。ま、ITって言葉に理論体系がなく、故に素人が踊りまくってバブルになるのと
同じだよ。その筋でちゃんとした理論家がいれば、決して廃れないしバブルに見えても
定着していく。SCMやCRMってのはその辺期待できるものがある。ERPはかろうじて
BPRやABC会計を拠り所に出来るかもな。

海外の連中は、ちゃんと理論体系を持っているから、実装までしたがるんだよ。
だからソフトウェアも骨太になる。経営理論とプログラミングを切り離している
時点で、日本ってのは全然負けてるって感じだな。奴らにとって経営は数学と
同レベルだ。連中は自分の理論を実践したいから、理論をプログラミングして
実現してくる。で、それを一生懸命に広めようとしてマーケティングを仕掛けてくる。
成功すれば第一人者として名声と富を得るわけだ。SEとかPGなんて狭いところで
切り分けなんてしてないよ。つか、向こうではSEとかPGなんて切り分けあんのか?
コード書くのも設計するのも出来て当然だろ。
166仕様書無しさん:02/03/03 17:05
プログラミングできないSE ∽ 方程式が解けない解析数学者
167仕様書無しさん:02/03/03 17:18
もっと短くまとめられないのかよ(;´д`)
168仕様書無しさん:02/03/03 17:24
悪いが74の文章、コピーさせてもらったよ。

おれも業務系の人間としてもっと勉強しなくては。。
16974=115-119=128:02/03/03 17:30
>>167 スマソ。以後気をつけるよ。許してくれ。
コードも仕様も文章もシンプルに、だな。
170仕様書無しさん:02/03/03 17:36
法学部出身のヤツって文が長いよね。 スマソ
171Delフサギコ ◆zE1iiRdQ :02/03/03 18:23

  ,,,,,,,,,,,,,∧,,∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′,,,,,,,ミ,,゚Д゚彡< 設計なんてコードの都合上変化する
  UU""" U U   \_______________
変化を抱擁するために設計する人は
開発者でなけりゃいけません。

コードがかけなくて設計が出来るわけないです。
172仕様書無しさん:02/03/03 18:46
 大手メーカがPG経験なしの新人をSEにしたのは、米に対抗するための
国策(国の指示)があったからだと何かの本で読んだことがあります。

 昨今の政治家をみていても思うのですが、何でもかんでも上下に分業して
上は大まかな方針だけ示せればいいという考えが広く深く根付いているようですね。
小泉氏の発言にもまさにそれがあって(最近非難が向けられるようになりましたが)
ガッカーリです。
ところで、こういう思想って連立方程式をしらない文系に顕著で、村上氏
などが指摘される現在の日本の教育の弱点と強く関係しているように
おもいませんか?
17374=115-119=128:02/03/03 19:41
>>172

俺は文系だが、文系・理系と区別したがる神経が理解できない。
論理というのは等しく必要だろうに。
音楽や絵画などにも数学の素養が大きく入り込むし、マーケティングには
統計などは必須だ。こういったものを扱うと自ずから論理的にならざるを得ない。
逆に論理だけでは理系であっても駄目だろう?
連立方程式を知っている文系であれば問題はないのか? 問題定義の仕方が
既に論理的でないと感じるぞ。教育をとやかく言うなら、まず自分の子供を
しっかり育てろ。机上の空論を言ってるクソSEと同じだ(藁
174仕様書無しさん:02/03/03 20:32
>>171
> コードがかけなくて設計が出来るわけないです。

自分の発言読み返して、赤面することはないか?
175仕様書無しさん:02/03/03 20:34
>>174
プログラムの設計とシステムの設計の
区別が付いてないんでしょう。
176仕様書無しさん:02/03/03 20:35
>>174
>>171は全然問題ないと思うが。
177仕様書無しさん:02/03/03 20:35
>>172
理系であること・文系であることで、人間の能力や資質、スキルは
割り出すことは出来ない。
すべてはあくまでも、当人のモチベーションとエクスペリエンスでしかないんだよ。
178仕様書無しさん:02/03/03 20:36
>>176
はあ?全然関係ないの?誤爆って事ね?>>171は。了解。
179仕様書無しさん:02/03/03 20:43
>>173
 君がコンプをもってるのはよく分かったけど、話はそういうことじゃない。
なんで連立方程式の話をしたかというと、分けて考えると解決しない問題が
あるということを言いたかったからだ。

 僕は学生の頃に、卒研をまとめる時に絶えず気にしていたのが、
データは十分に取れているのか、その関係は十分に抽出できているのかという
ことだった。 論理が完璧でも認識が不十分なら意味がないからだ。

 まともに頭を使っている人間ならこんな事は常識的な注意点だと思ってたけど、
最近は中学時点から数学を捨てても大学卒業までいけるという事実を知って
そうでもないと考えるようになった。
 連立方程式ならこれを分けて扱うと明らかに解けないことが目で見えて明らかだが、
複雑でなんでもうやむやにされがちな日常生活からこういった当たり前の危機感が
学習できるだろうか?

 現に君も論理性の話だけで、その下にある認識に付いては触れていないし、
昨今のスレ中で論理に付いて語られる場合も指摘されるたところを読んだことがない。

 つまり、何でも分離して処理できる、生産性を上げられるというのは
単純作業などからにおいてのみ帰納できる事実であって、頭脳労働である
システムの設計においてまでこれを適応するのは、無茶であり、
(理性的には常識だろうけど)
にもかかわらず、これがまかり通っているのは客観的評価が厳しい科学的な
教育や訓練が不足しているからではないのか?
 今いろんな所に露呈してるいーかげん、不正、そういったキーワードもどこかで
こういった現実と絡んできそうだが、さすがにそこまでいうと空論になるだろう。
何より、僕の知見を越えているはずだから。
180仕様書無しさん:02/03/03 20:53
要約:
設計とコーディングを職業・スキルとして分けてしまうと、
多くの重要な問題を認識・対処できなくなってしまうという話。
18174=115-119=128:02/03/03 21:01
>>179

> 君がコンプをもってるのはよく分かったけど、話はそういうことじゃない。
>なんで連立方程式の話をしたかというと、分けて考えると解決しない問題が
>あるということを言いたかったからだ。

俺がコンプレックスを持っているとは知らなかった。ありがとう。皮肉ではないぞ。
自分の気付いていないことに気付くのは嬉しいことだからな。

さて、言いたかったのであれば、最初からそのように書け。ソースコードでも
こんなつもりではなかった、というようなコードを書くのか? 仕様書でも?
最初から手間を惜しまずに書くことだ。そうすれば最初から以下のように同意できる。

さて、分けて考えるだけでは駄目なのではないか? という指摘には全くもって
同感だ。異論はない。>>179の意見には全面的に同意する。しかしながら、それが
「連立方程式」でなければならないのか、という点で疑問なのだよ。まして、
理系・文系と「分けて」いるのは君だ。

連立方程式を知っている・知っていない という軸と、理系である・文系である
というのは別だろう? 掛け合わせると4通りある。まず君が提示した中でも
それぞれについて考えないと答えを出すのは無理だよな?

一方で君が指摘しているように、この4通りというのは論理的ではあるが、
そもそも「連立方程式に対する知識が、言いっ放しにせずにきちんと実行する力の
習得に必須である」という認識は、本当に十分なデータがあるのかというと
そうではないと考えるのだよ。

つまり、俺は君が>>179で書いた、正にその思考の結果、君の発言の前提に違和感を
感じているわけだ。

なので、その違和感のある前提を元にした教育システムへの指摘というのも
当然?マークが点滅しただけだ。

理系・文系と分けている結果、科学的な訓練や結果が不足しているために、
現状の問題が生じていると指摘したいのであれば、問題の核は「連立方程式を
知らない文系」にあるのではなく、理系・文系として分けてしまっている
教育システムに問題があるということではないか? 恐らくそういうことを
指摘したいのだろう? 俺も全面的に同意する。が、出来れば最初から面倒でも
書いたほうが良いぞ。君は頭が良いかもしれないが、周囲がみんな君のように
理解力に優れているわけではない。だからこそ、そんな現状を憂いているのだろう?

繰り返すが、君の>>179の主張には全面的に賛成だ。そして気付きをくれたことに
感謝する。ありがとう。
182仕様書無しさん:02/03/03 21:04
お前ら文章長すぎないですか?
18374=115-119=128:02/03/03 21:07
>>182 ほんとにそうだな。何度もスマソ。飯食いに逝ってくる。
184仕様書無しさん:02/03/03 21:12
>>182 いいじゃん。お前短すぎ
185お風呂好き:02/03/03 21:23
コード書けなくても、
お話が通じる人だったら別にいいような。
あと、プログラマの意見をいっぱい聞いて
くれる人かなぁ。
186仕様書無しさん:02/03/03 21:27
要は既に誰かによって分けられたものにはバイアスがかかってるということ?
187Delフサギコ ◆zE1iiRdQ :02/03/03 21:35
マア オアツイコトデ
  ,,,,,,,,,,,,,∧,,∧   /理系、文系
〜′,,,,,,,ミ,,゚Д゚彡< …日本の教育がとかいうとすぐこれだ…
  UU""" U U   \
理系でも全体の3/4はプログラミングなんて
組めないと思うけど?

プログラム組めないSEも少々問題かもしれないけど
プログラミングしてりゃ、会話すら怠ってもよいと
思っているジジイどもも、逝ってよしかもね。


>>174、ときどき必要以上に蒼ってしまったときとか。思うぞ。
>>175、システムの設計ってなんだかな。
 システムエンジニァよりあいまいな言葉じゃない?
188仕様書無しさん:02/03/03 21:48
たまにコードの書けないSEが紛れこんでくるね。
174=175とか。
189仕様書無しさん:02/03/03 21:55
プログラム書けなくても仕様をきちんと理解してくれていたら
別に問題ないよ。
190仕様書無しさん:02/03/03 22:07

VBやDelphiしか使えないSEというのもイタイよね。
191仕様書無しさん:02/03/03 22:08
きちんと、が深いと思われ…
192仕様書無しさん:02/03/03 22:22
>>188
174=175とか言っている時点でイタイと思っている俺174&175さんがいる。
2ちゃんでその=使う奴って、本当にいたいよ。
>>1+2+3+4+5+6+7+8+9+10=55
ってこった。
193仕様書無しさん:02/03/03 22:28
図星つかれてぶち切れですか。
ほっとけよ。
194仕様書無しさん:02/03/03 22:30
>>175
システムデザインするときにプログラムはしらなくてもできるけど、
ミドルウェアを使う場合だが、アーキテクチャは知ってる必要あると思われ。
でなければ、実装したときに、あまりに困難、または性能の悪いシステムに
しなければならないようなものになりかねないよね!
そのアーキテクチャを知ってる人間がプログラムを知らないことはまれだと思う。
そのあたりの認識の相違かと思われ。
195 :02/03/03 22:52
お客とシステム仕様をきっちり詰めて文書を残す仕事ができれば問題ない。
プログラムはPGにまかせればよい。

しかし、全然しらんとPGにナメられるよ。
196175:02/03/03 22:57
>>192
しかも俺のこと SE だって。
そんなインチキ臭い職業選んだ覚えはないぞ。
197仕様書無しさん:02/03/03 23:01
その、きっちりっていうのがPGにとって
のきっちりなら、やはりプログラミング
を知っていることが必要ということでしょう。

SEがきっちり仕事できれば問題ないのだけど、ほんと、鶏と卵…
198仕様書無しさん:02/03/03 23:04
というか、連立方程式?
199仕様書無しさん:02/03/03 23:05
プログラムが出来ないまともSEがいるのなら見てみたい。

いくら理論上、プログラムが出来ないまともなSEが存在すると
言っても現実にいない、もしくは少ないんじゃ意味ない。

実際にはプログラムが出来ない馬鹿SEか、
プログラムもできる優秀なSEしかいない。
200仕様書無しさん:02/03/03 23:14
あとプログラムができる馬鹿SEな
201仕様書無しさん:02/03/03 23:17

VBやDelphiでGUIプログラミングしかできないくせに、
「俺はプログラミングもできる」と言っている
SEもミジメだよな
202仕様書無しさん:02/03/03 23:18
俺はSEはプログラムができなくてもいいと思う。
プログラマなんてかわりはいくらでもいるけど、
ほんとに優秀なSEは数少ない
203仕様書無しさん:02/03/03 23:19
下手したらPGの数よりSEのほうが多い罠…
204仕様書無しさん:02/03/03 23:19
>>201
GUIプログラムのほうがむずかしいよ。
205仕様書無しさん:02/03/03 23:20
>>202
非論理的だね。
206仕様書無しさん:02/03/03 23:22
>>202
文がつながってませんが?
プログラムしなしなくても〜なら
わかるけど。
207仕様書無しさん:02/03/03 23:33
>>202
君はプログラマの質は関係ないって言いたいのか?
208仕様書無しさん:02/03/03 23:42
>>203
その通り。PGよりSEの法が多いかもしれない。
しかもSEのうち能力のあるのは一握り。
あとは年功序列にしたがってPGからSEへ名目上なったか
あるいはSEとして採用されたか。
しかも莫大な労務費を食うから、システムの値段がつりあがる。
いまにばちがあたりますぞ。高給取たちよ。
209仕様書無しさん:02/03/03 23:42
対象のSEよりPGに要求される種の
スキルが低い場合は不満は感じない
かと思います。相対的は問題でしよう。
210仕様書無しさん:02/03/03 23:49
>>209 意味不明
211仕様書無しさん:02/03/03 23:50
PGでもSEでもいいけどさ、もうちょっと論理的な文章書こうぜ。>209
212仕様書無しさん:02/03/03 23:51
あれ?このスレって400くらいまでいってなかったっけ?
あれあれ?
別スレ?
213仕様書無しさん:02/03/03 23:52
似たようなスレが乱立してるからナ。
214スレッド下っぱー:02/03/03 23:54
コンピュータに出来る事と出来ないことがある。
システムに出来ることと出来ないことがある。

現在の予算で直接/間接に使用できる要素技術と、顧客のニーズを秤にかけて、
ここはこの機能を使えば出来ます、でも、この機能を実現するのは無理です、みたいに
出来ない事はできない、ときちんと言えるSEをPGとしては望んでいる。
出来もしないことを出来ると言われるのは最終的にお客も困るよね。

上記が可能なためには、ある程度は技術に対する実践的な知識が必要なはず。
で、そのレベルで知識を持っている人が、現在の至れり尽くせりのプログラミング環境でさえ
プログラミングができないような人であるっていう状況が想像できない。

・自分の適性はプログラマ向きじゃないから組まない
・しこしこコーディングしたりデバッグしたりするのはめんどい
ってのは、「組めない」んじゃなくて「組まない」ってことだよね?
215仕様書無しさん:02/03/03 23:56
PGであるあなたが〜209〜な問題でしょう。
216209ではないが:02/03/04 00:02
>>210-211
ようわからん。

>>209
「PGが不満に感じるのは、SEが自分よりも高いスキルをPGに要求してる時」
だって意味じゃないの???ちょっと意味を狭くしてしまったけど。
217仕様書無しさん:02/03/04 00:08
>214 それはきわどいけど、
現にPG経験がなければ「組めない」です。
でないと、めんどくさい、の先に何があるかわからないでしょ?
めんどくさい、と実質不可能の違いわかる?工期も検討付く?回避策を提案できる?



218仕様書無しさん:02/03/04 00:15
>>217
そういう無能が辞めればみんな幸せ。
219210-211ではないが :02/03/04 00:22
>>216
漏れも>>209の書いてることがサパーリ理解できん!
220仕様書無しさん:02/03/04 00:28
面倒なのはみんな面倒なのだけど、
それを克服するのがスキルだと思ふ。
感性の話はわからないけど、
デバッグにしてもバグの出そうなところとか
わかればデバッグの方針も決まるし、
発見も早い。
SEが理解してれば設計で回避もできて
バグも少なく納期も早いかと…。
221仕様書無しさん:02/03/04 11:45
--
XP は、顧客の定義とプログラマの実装という、サークルオブライフが大事なのだ。
そのサークルを壊してはならない。
--

ここのスレッドのいう SE というのは、サークルを壊してしまうもののように思う。
SEは仕様書さえあれば実装なんてすぐに
でてくるものと思ってるが、それは別に
いいとして最終的な青果物がソフトウェア
であるということを忘れているのが多い。

これは仕事をする上での心構えとして
最悪のものだと思う。
223仕様書無しさん:02/03/04 22:22
しかし、元バリバリのデキるプログラマがSEになられるのも困り物。
奴、自分が現役の感覚ですんごい短い線表引いてくれやがる。
224仕様書無しさん:02/03/04 22:24
>>223
あそれ分かる!
キャパシティが狭い人だと悲惨だよね。
225仕様書無しさん:02/03/04 22:26
>>223
ワラタ!
同じ経験ありだよ。その人なら出来る工数で計算されてもねぇ。
周りがじぇんじぇんついて来れず、当然火だるまになって大変だたYO!
226仕様書無しさん:02/03/04 23:23
実際、そういうのもったいないね
227仕様書無しさん:02/03/04 23:45
>>223
うちは元バリバリの厨房プログラマがSヨだから結構幸せ。





工数の面だけダカナー
228仕様書無しさん:02/03/05 00:29
>>225
元一流選手が監督になると、しばらく、
「なぜ出来ないんだ?」と怒るらしい。
王や長島や星野や山本にこういわれて、反論できる選手はいないだろう。
229仕様書無しさん:02/03/05 00:35
>>228
そういえばダイエーのピッチングコーチやってた
村田兆次が現役選手より速い球投げて、自信なくした
ピッチャーがいたとかいなかったとか、そんな話あったねw。
230仕様書無しさん :02/03/05 00:51
うちの会社のSEはひどい。OSの最新バージョンが出たりすると、勝手に最新
バージョンをインストールしたりして、ソフトをあぼーんさせてお客さんの
お怒りを買っている。よく今まで首にならなかったものだ。
こういうSE(System Experiment)ってみんなの会社にもいない?
231仕様書無しさん:02/03/05 00:54
>>230
漏れんとこにはいないな。
なにせ指定OS(Win95・98)以外いれると必ずバグルから無理だろ。(w
232仕様書無しさん:02/03/05 03:35
こんな時間に書きこんでしまうのも何ですけど・・・

皆さんの話見てると全然ネットワークとかハードの話が出てこないですね。
個人的にはネットワーク構成や、ハードの提案、実装まで入ってくるのがSEに
なってくると思います。

今業務でWebサーバ2台、DBサーバ1台、メールサーバ1台で運用して
ますけど、PGの人達はまったくそこら辺に興味が無いようです。
上記内容はネットワークエンジニアの仕事と言われるかもしれませんが、
Tomcatとかアプリケーションも絡んでくるのでやはりSEの領分だと思います。

本題に戻りますが、環境構築含めて顧客に提案するためにはPG知識は必須です。
SAPではないのですが、なぜPHPを選ぶのか?なぜJavaを選ぶのか?
そこら辺を根拠立てて説明しないとユーザーも納得しないと思いますが・・・
というか、そこら辺の知識が無いでユーザーに最適なシステム提案なんて出来ないです。

上記はあくまでも、知識ベースの事ですけどコーディングについては
少なくとも一つの言語を知っていれば使いまわせる気がします。
(Basic系はきついです・・・ね)
C++書ける人は、JavaもPHPもだいたい書けますよね。
んで、Web系とDBまわり、ネットワーク周りを押さえていれば言うこと無し
だと思います。

あとはいかにユーザーのイメージ通りに作り上げるかですね。
たとえ素晴らしいシステムでなくても、ユーザーが自分で望んだものであれば
納得してもらえます。ただ、コンサルと称してユーザーに押し付けるやり方を
してしまい、もしユーザーが気に入らなかった時は最悪な事になります。
※最近かなりこの業界はゴタゴタしてます・・・
233仕様書無しさん:02/03/05 03:45
>232
あぁそれで今日も胃が痛い思いをしてきたヨ。
ていうか、最近、「もう大手には頼みたくない」って話、多くねぇ?
234232:02/03/05 03:54
>>233
大手のSEは激ヤバですね・・・
特に若い人とスキルの無い中年の組み合わせが最悪
235233:02/03/05 04:08
洩れもそんなに事例知ってるわけじゃないけどさ、
ネットバブルの頃の(金額が)デカいシステムのリプレースの時期で、
そんなにコストもかけられないし、大手はもうイヤ、ってとこ多い。

大手だと、営業とかが壁作ってクライアントと実装者(設計者)が隔絶されるよね。
それも「ゴタゴタしてる」原因の一つだと思うにょ。
大手のSEは組織に守られてるからな。いろんな意味で。
236仕様書無しさん:02/03/05 04:14
つまり俺の時代だ、と。
237233:02/03/05 04:16
そんなにキャパないけどね(w
238仕様書無しさん:02/03/05 04:18
サーバを立てるなんて誰でも出来ますよ? 正直・・・。
239232:02/03/05 04:21
>>237
いや、大手は本気で組織に守られてますよね・・・
んで散々荒らした後にとんずらします。

残ってケツ引くのは下請けの中小企業がほとんど
240232:02/03/05 04:24
>>238
いや・・・プログラマで自分でサーバ立ててる人をあまり見たこと無いよ
apacheなんてwin版でてるから、簡単にWebサーバあたりなら立てられる
のに、いやいいよって断られるし。
そもそもTCP/IPを分かってない人が多いのにビックリです。

って、マジレスは駄目ですか?
241232:02/03/05 04:25
ああ・・・いやって否定形使いすぎだな・・・
日本語に難があるので寝ることにします。スレ汚しスマソ
242233:02/03/05 04:29
まぁ「サーバを立てる」ってのは最初の一歩なわけでさ。
できて当然だとは思うな。

>240
最近でもそういうモンなんすかね?
オイラはもともとWebアプリケーション関連から入ったので、
そこらへんは結構やってるんだけど(運用とかもやったたし)。
243仕様書無しさん:02/03/05 05:34
おいおい、systemとprogramの単語くらい英英辞典で調べろよ。
何だ何だ、設計って単語の意味もわかんねぇ奴いるし。
ついでに曖昧って単語も引いておけ。何だ連立方程式って。
システマティック?笑っちゃうよな。英語コンプか? コンプて何?
ねぇねぇ。つぅか、こんなレスで>>1は満足しているのか? ERP?それが何? おいおい
熱血すりゃみんなダンマリかよ(藁藁 つぅか、ここのスレ悲しいくらいに
馬鹿の長文に優しいな。。理系の漏れは小泉以上に首相の資格アリか?おめでてぇな。
お前らPG,SE言いたいだけちゃうんかと。オプソのERP知ってるくらいでそんなに
いうか? かこいいね。つぅか、このスレhttp://pc.2ch.net/test/read.cgi/prog/1015165917/に
負けてるんちゃうんか? >>1よもっと頑張れや。
244仕様書無しさん:02/03/05 05:37
>>243誤爆?
245仕様書無しさん:02/03/05 05:39
>>243 藁藁が痛いな(藁藁
246仕様書無しさん:02/03/05 05:41
プログラマ兼SEが機能外要求定義するとだいたい無難なところに
落ち着く。これは不勉強なSEでもそうなるものだけどね。
それで上手くいくことがままあるから、選択の
ためだけに勉強する人はすくないんじゃないかな?
でもこんなんだから必要のないところでOracleなんて
導入したりして、オラクル社は、、(以下省略

ネットワークの知識が少ないのは同意。耳の痛い話です。
247仕様書無しさん:02/03/05 05:43
>244なんで?
248仕様書無しさん:02/03/05 05:45
>>264 それってOracleの問題か? ムノーなSEの問題だと思うが?
249仕様書無しさん:02/03/05 06:00
>>248

予言?
250narucy56:02/03/05 06:56
>>232

> 本題に戻りますが、環境構築含めて顧客に提案するためにはPG知識は必須です。
> SAPではないのですが、なぜPHPを選ぶのか?なぜJavaを選ぶのか?
> そこら辺を根拠立てて説明しないとユーザーも納得しないと思いますが・・・
> というか、そこら辺の知識が無いでユーザーに最適なシステム提案なんて出来ないです

提案の段階ではそんな技術的な話は無用。
どんなビジネス価値があるかということを説明できればそれでOK。

(これは実に重要で責任が重い仕事だが、実際にはビジネスが失敗してもコンサルタントは責任とらない。ここがコンサルタントは美味しい職業と言われる理由かも。

ま、数年後には顧客も、自分がちゃんとビジネス価値を策定できないとダメなんだということが、分かってくるとは思うんだけど・・・。)
251仕様書無しさん:02/03/05 07:14
プログラムが組めないSEが設計すんな!
構造化設計?オブジェクト設計?プロセス中心?データ中心?
いいえ。抽象的設計です。
252とおりすがり:02/03/05 07:23
>>240
>そもそもTCP/IPを分かってない人が多いのにビックリです。

俺、ネットワーク屋なんだけどさ、うちの現場ではWAN超えでWinodowsネットワーク
を使うプログラマが意外と多いのに驚いた。
コマンドでいうと、 copy \\%computername\〜〜の類ね。
ネットワーク屋はWAN越えの場合は普通はftpを使うのだけどね。
この辺の両者の意識の違いに未だ躊躇している・・・。
起き抜けで脳味噌寝てるので駄文スマソ。
253narucy56:02/03/05 07:31
>>178
> システムの設計ってなんだかな。
> システムエンジニァよりあいまいな言葉じゃない?

その通りだと思う。

「設計」という言葉の意味をはっきりさせなきゃいけない。

ここでいう設計というのは、プログラマがどう求められている機能を実装するか、という設計だよね。

「どうやってビジネス価値を生みだすのか」という顧客かコンサルタントが行う設計があって、そっちのほうがはるかに重要な問題なんですけども・・・。>>1 には、この重要な仕事をがんばって欲しい。


でさ、もうホントに SE という言葉もわけわかんなくて。

このどっちの設計をやるのか、どっちもやるのか、どっちもやらないのか、どっちも中途半端にやるのか。
そもそも、何をやるのか。

会社によっても人によってもバラバラ。この SE という言葉をどうにかできないだろうか。
254仕様書無しさん:02/03/05 07:37
SE と呼ばれている人をけなすわけじゃなくて、両方の設計も分かっている人は、もしいるならそれはそれでいいと思うし・・・。

重要なのは「何の責任を持ってるのか」ということを一人一人チームの中で決めておくことだと思う。
255仕様書無しさん:02/03/05 10:58
>>253
>ここでいう設計というのは、プログラマがどう求められている機能を実装するか
>、という設計だよね。
個人的にはこの部分はPGの領域にすべきだと思う。
そうしないといつまでたってもコーダとしか呼ばれない。
そのためには、サーバの立ちあげやDB/ネットワークの知識は避けて
通れないと思う。

んで、
>「どうやってビジネス価値を生みだすのか」という顧客かコンサルタントが
>行う設計があって、そっちのほうがはるかに重要な問題なんですけども・・・。
この部分をSEに頼みたいなぁ。
SEは非常にあいまいな顧客の要件をあいまいさを許さないコンピュータの世界
におきかえてPGに説明するのが本筋だと思う。そのためには業務知識が非常に
重要にねってくると思う。

ちゃんとコンセプトを持って仕様を考えてくれればその後の実装は自分でやる
んだけどなぁ。いつもSEが持ってくるのは顧客のメモ書(以下愚痴)
256仕様書無しさん:02/03/05 11:57
自分はまったくのSEで、今もちょうど新業務プロセスはどうあるべきか、などといった仕様書を書いる最中ですが、今のリーダに文句言われてSEに2種類あることが、わかりました。
リーダのやり方:
それまでの話をまとめて、その工程の仕様書(報告書)を作る。
自分:
それまでの話を元に、その工程の仕様書(定義書・設計書)を作る。

要求定義→外部設計→内部設計→プログラミング→テストの工程で
自分は前工程の成果を元に、次の工程を行うと思ってました。
テストはプログラミング結果を、
プログラミングは内部設計を、
内部設計は外部設計を、
外部設計は要求定義を、元とするとずーっと思ってたら、なんと目の前の”上級SEさま”は
顧客の要望だけをまとめた”報告書”を要求定義書だといっております。
外部設計(まだ入口だけど)は顧客のヒアリング結果を、見てくれよくまとめれば良いんだそうです。

要求定義書は要求定義の報告書なので、外部設計のためのものではなく、
外部設計書は外部設計の報告書なので、内部設計のためのものではなく、
内部設計書は内部設計の報告書なので、プログラミングのためのものではなく、
テストはテストケースは考えず、テスト計画書と結果報告書を作る。
これがSEの作業であり、成果物のようです。

ハードの設計図面は、次の工程で実物を作る為のもの、
ソフトの設計書は、次の工程でプログラを作るためのもの、と思っていた自分は
今までSEとして失格だったようです。
自分はSEとはシステムを作る人だと思ってましたが、書記及び文書構成屋だったんですね。
10年間何してたんだろう?浅はかだった。
257仕様書無しさん:02/03/05 12:15
>256
Sヨ単価が地盤沈下してる時代に、話を纏めるだけの人はヤヴァくない?
それに、顧客の方も知識ついちゃって、話を纏める人をエンジニアと呼ばないよ。
258仕様書無しさん:02/03/05 12:53
>>252
それはただ単にWin房の集まりだからでしょ。
259仕様書無しさん:02/03/05 13:00
す、すみません。
ネットワークなプログラマですが、WAN越えでSamba使ってます。

べ、便利なんですもの…。
260仕様書無しさん:02/03/05 20:06
>>256
書記・文書構成屋ていうのは、なかなか難しいごとだぞ
261仕様書無しさん:02/03/05 21:34
ゼロサムゲーム業界ってのは、誰か一人が単価下げて受注をはじめる。
それに対抗して他社も単価切り下げてくから、どんどんデフレスパイラルに落ち込む。
理系のくせにこんな理屈もわからないから、どんどん品質低下に進むんだね。
正直、有能な人は、人の仕事の請け負いやめて、自分で価値を創造した方がいいと思う。
262仕様書無しさん:02/03/05 21:37
理系・文系論争なんてこのスレではやってませんが。
誤読者多発みたいですな。
263仕様書無しさん:02/03/05 21:39
>>252
どっちだって大差ねえよ。
264仕様書無しさん:02/03/05 21:42
>>262
君は、理系の部分の軽い、ただの煽りにとらわれて、本質が読めないようだね。
265仕様書無しさん:02/03/05 21:45
学力がらみだと、最近、読解力が落ちてるってニュース聞いたけど、
あれの正体は話を最後まで聞かない奴だと思うな。
客先も職場も、国会もTV討論もフライングばっかりだよな。

と、話を教育に振ってみる(藁
266仕様書無しさん:02/03/05 21:46
このスレも、もうつまらん。サゲ!!!!!
267仕様書無しさん:02/03/05 21:50
>>265
それって、話を聞かない奴が多くなったってこと?
結果としては、毒か威力落ちてると、一緒だよね。
で、そうだとして、
話を最後まで聞かない奴が多くなったのは何故?
テレビだけでんく、ゲーム機や、ミュージックプレーヤーなども
手軽に入るようになったためか?
268仕様書無しさん:02/03/05 21:57
マクルーハンが言うところの「ホットなメディア」の影響じゃない?


とか中途半端な知識をひけらかしてみる。

イッテミタカッタンダヨー
269仕様書無しさん:02/03/05 21:58
>>267
君みたいに、誤字脱字に無頓着になった人が増えたからじゃないの?
270仕様書無しさん:02/03/05 21:59
分かんないけど、気が短くなってるって傾向はいろんなニュースや
統計や日常から感じるな。 深く考える時間や習慣が無くなった
からってのが一つにはあるかもな。
 プログラマはその点恵まれた職業なのかもしれないけど、
271仕様書無しさん:02/03/05 22:02
>深く考える時間や習慣が無くなった
やっぱり、そうでもないかも。
哲学書が売れるようになったって聞いた。特にバブル以降。
でも本を読む時間が増えたってニュースは聞かないな。
よくある二極化だろうか。
272仕様書無しさん:02/03/05 22:30
世の中全般的に逝き急いでる気がするね。
なんつーか、今日明日の糧を得るのでイッパイイッパイというか。
273仕様書無しさん:02/03/05 23:01
>>271
ソフィーのなんとかの影響じゃない?
小林よしのりの影響で右よりになる厨房が
沢山いるってことと同じようなもんでしょ。
274仕様書無しさん:02/03/06 02:35
 就職活動真っ盛り青二才です。

 就職活動中です。
 いわゆるSI系と呼ばれる会社の説明会よく行きます。
「我が社はトータルソリューション企業です」
「ゆくゆくはPMになって頂けるようなプロダクトSEを我が社は欲しています」
要するに、経営コンサル的な事できるようになってチョンマゲってな感じの説明ばかり受けます。
 たまたま同席した学生に話を聞くと
「俺、トータルソリューションがどうのこうの・・・」と、パンフレットみたいな話されました。
 一切のコーディング無しで、既存製品組み合わせればシステムできるんだな、
って感じの体験学習みたいなのもやらされました。

 普通に疑問です。PM候補ばっかり取って誰が実際にモノを作るんですか?
長年第一線でPGをしていけるような人材が欲しいという話はどこの説明会でも
聞きませんでした。作ったものを最高品質で、みたいな話もです。
275仕様書無しさん:02/03/06 03:15
>>274
> 誰が実際にモノを作るんですか?
下請けの日本人、中国人、インド人、ロシア人などなど。

> 長年第一線でPGをしていけるような人材が欲しいしいという話はどこの説明会でも
聞きませんでした。

プログラミングは基礎なんだよぉ。
PGは単価が安いんだよぉ。
上流工程の方が金になるんだよぉ。
ぎじゅつりょくはもとよりさまざまなのうりょくをようきゅうされてたいへんなんだよぉ。

下流工程の品質は上流工程の品質が高ければどうにかなるもんなんだよぉぉ
276仕様書無しさん:02/03/06 03:23
>275
ならんだろ。
277仕様書無しさん:02/03/06 03:42
>276
なる。

最悪、品質の悪い部分だけ別の奴に作り直しさせればいいんだよぉ。
278仕様書無しさん:02/03/06 06:57
>275
ならんね。
品質の悪い部分をカバーする為のコードがあちこち入ってきてるんじゃないかな。
システムってものは、それを構成するコンポーネントのなかで一番できの悪い部分に引きずられるもんだよ。
279仕様書無しさん:02/03/06 08:16
少なくとも、上流工程がクソだと下流でどうあがいても
どうしようもないって事は確かだと思われ。
280仕様書無しさん:02/03/06 08:43
上流がよければいいんだけどね。全部とはいわんが実際は上流がクソで苦しめられてる。
下流が全力を出せないのよ。むしろ押さえつけられてる。
それで品質が下がっているのを下流のせいにされたらたまらない。
せめて下流が力を出せる程度に技術力をつけてほしい。

その基礎技術の重要なものの一つがプログラミング能力なんだが、
これを軽視しているからいつまでたっても技術力がついてないんだよね。
他にもやらんといかんことはあるだろうが、それだけ金をもらってるんだ。
手抜きせずにやれ。
281仕様書無しさん:02/03/06 09:10
分かった。今必要なのは「開発作業そのものの」コンサルタントだ。
本来は不必要なものだが、今の開発組織形態ってのはクソすぎる。
組織再編して要らない人材を切ってくれれば、効率よく開発できるようになり、
結果的には業界盛り上がってみんなハッピーだ。

(めちゃめちゃ話分かりづらくなってるな。XP の組織みたくシンプルにならん
だろうか)
282仕様書無しさん:02/03/06 09:33
SEがテスターになればいいのさ。
かれらが気取って仕事してる以上は
どうにもならないのさ。
283仕様書無しさん:02/03/06 10:20
上流が良いとか悪いとか切り分けて考えれる=ウォータフォール
だよ。
スパイラルなら、また上流と言われる工程にフィードバックされる。
Sヨが要ると、Sヨを養うために上流と下流を切り分けなきゃならんのだよね。
プログラマだけにしときゃ、ここで上流とか下流とか言われてる工程を両方とも出来るから、
スパイラル出来るYO!
284仕様書無しさん:02/03/06 10:23
>システムってものは、それを構成するコンポーネントのなかで
>一番できの悪い部分に引きずられるもんだよ。
これにははげどう。
だけど、その一番出来の悪いコンポーネントを簡単に切り離す事
ができるようにするのが上流工程に腕の見せ所ではないかい?
従ってオレは「なる」に一票。
285仕様書無しさん:02/03/06 10:30
>284
なわけねーだろ。
コンポーネントが良いか悪いか、や、切離す作業はコード上で行われる。
286仕様書無しさん:02/03/06 16:25
個人的にゃ、上流とか下流とかの境界がだんだん薄れているような気がする。
なんつうか、コンポーネントの切り分けにしても、
プログラマーとしての能力をもった人間の役割ではないかと思う今日このごろ。
287仕様書無しさん:02/03/06 18:18
上流だの、下流だの、そんな曖昧なことやってたんじゃダメだよなぁ。

何が上流で何か下流なのか、それぞれどんな責任があるのか。ちっともはっきりしない。責任を曖昧にするシステムがしっかりと出来上がっちゃってるんだよね。
288仕様書無しさん:02/03/06 18:58
>>287
それはあんたのとこだけ。
289仕様書無しさん:02/03/06 19:01
上流は下流の切り分けは、半端な人間がそこそこの仕事をするためにあるのさ。
290仕様書無しさん:02/03/06 20:13
個人的には上流、下流というのに分けられるのか疑問だけど、
デザインパターンのようなものは上流、下流のどっちに含まれると思う?
291Delフサギコ ◆zE1iiRdQ :02/03/06 22:07
  ,,,,,,,,,,,,,∧,,∧ 
〜′,,,,,,,ミ,,゚Д゚彡
  UU""" U U   

____∧_______

SEというわけのわからん単語を使い飽きたら
上流下流っちゅうわけわからん分類分けですか。
なんとも言葉遊びが好きなんか?

自分で言った言葉の意味がわからなって
自分で首をしめるなよっトナー
292Delフサギコ ◆zE1iiRdQ :02/03/06 22:17

   ∧,,∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,゚Д゚彡 < 日本は情報産業後進国だと思われ
   U  つ∀ \____________
 〜ミ  ミ ┴
   ∪''∪ 
>>274さん
金に目がくらんでる経営者ばかりだから
口八丁のヤシを
ジオンのザクみたいに
量産したいんでしょうね。

良質のプロマネになるためには
プログラミング経験は必要じゃないかな。
そういう経験がなかったら
プロジェクトメンバを引っ張っていくのは
実に難しくなると思うの。
293252@今日も眠いぞ:02/03/06 22:51
>>258
どうやら、Win房の集まりのようです。コマンドを使えない人がたくさんいました。

>>259
やってることは同じですが、UNIXマンセーな私としてはWAN越えのsambaは許します(藁

>>263
ま、最後には大差はありませんが、やっぱり信用できない。
オマケに切断しても、不要なパケットを飛ばしてくれるし・・・。

このところこの件でネットワークチームとプログラムその他チームの喧嘩が絶えません(泣
294274:02/03/06 23:04
 みなさんいろいろありがとうございます。

就活真っ盛り青二才です

 う〜〜ん。やっぱりいまいち分からないです。
C○Cの説明会とか行くと
「PG->SE->PMとステップアップし、CE、営業は別物と
考えている学生さんが多いようですが、
実際はSE->PM, CE->PM, 営業->PMなど、
柔軟に変化できる人材を求めています」
と、説明されます。
 
 そういう柔軟性がある人材は要るのだろうなとは理解できますが、
何故かPGの存在を消すような説明です。
アレ?PGは?という感じです。

 また、どこのSI系の説明会も似たようなモノなので、
学生らもすり込まれているらしく
「ソリューションが…、フレキシブルに…、ERPを活用して…」
等、上っ面にしか見えない会話ばかりされます。
なんだろコイツラ?という気分になってきます。
295仕様書無しさん:02/03/06 23:09
そーゆー実態がよくわかんない言葉で客を騙す商売なんだから
社員もだまされとかなきゃ精神もたんっちゅうねんな
296仕様書無しさん:02/03/06 23:17
PGはなにか泥臭い実装の細部を扱う人って
イメージなんじゃないかな。ものを売るために
そういったものを避ける必要があるならそれは
構わないんだけど、なんかそうでもないような。
297Delフサギコ ◆zE1iiRdQ :02/03/07 00:03
 / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 | T字型人間を目指せとかいわれちゃったりして
 \_ ________________
    |/
  ∧,,∧
  ミ,,゚Д゚ミy━~~
   U   ミ
 〜ミ   ミ
   U''U

横に手広く、一つを深く知るってね。


ま・PGの存在を消すような、商売のやり方は
情報産業後進国の遅れたやり方なんだと思います。
優れてないソリューションでしょうな。

大手は出来の悪いSEの頭数をそろえて
システムの作成工数を見積もって
お金をガッポガッポ収集するようになってるんじゃないかしら。

今時、仕事でしかパソ触らないSEってのでも
仕事しているみたいだし。


新人には会社の都合でどんな部署にでも逝け
配属に関して不満を持つなという
意味合いも込めて営業でも、CEでも
(ってカスタマーサポエンジニアだよね?)
PMになれって事を言っているわけだけど

自分のキャリアプランを考えてシステム開発したいなら
俺なら、営業配属になったら即転職だね。
回り道をするほど人生は長くなくてよ。
298Delフサギコ ◆zE1iiRdQ :02/03/07 00:19
   ∧,,∧    / ̄
  ミ,,゚Д゚彡 <  で、誤解の亡きようにいいますが
  (ミ  ミ)   \_
 〜ミ  ミ
   ∪''∪

>柔軟に変化できる人材を求めています」

ギチギチのプログラマで、頭の中にソースコードしかなくて
上司との日常会話すら困難で
客との会話もママならなくて
客へのプレゼンなんか絶対に出来ないけど
作るものは誰よりもいいものを早く仕上げる
頭の切れる技術者

ってのは人材として求めてない…ってのは事実でしょう。

少ないニーズはあるけどね。

周りの学生には流されなくても、いいと思うよ。
どこのSIerでも開発わかってる人と
わかってない人では仕事の効率が違ってくる。

開発わかってないと、営業的能力で仕事を補う
必要が出てくるんだけど、こっちの方が相当つらいかも。
299仕様書無しさん:02/03/07 00:42
オレは10年ずっとプログラマやってたんだけど、

>「ソリューションが…、フレキシブルに…、ERPを活用して…」

みたいな会話が普通に話される職場なんて一度も見た
ことがないドキュソだ。で、こういうのって
本当にあるの?
Tec-Bingなんかでは、SIだのIT、ソリューション、
なんて言葉はよく見るけど、転職希望者に夢を見させる
ための煽り言葉だとずっと思ってた。
いったい、そういう職場ではどんなふうに仕事が進められてるんだ?
本当にこういう世界で仕事してるひと、どんなことしてるんだ?
300仕様書無しさん:02/03/07 00:47
>>299
狭い世界から出てきなさい
301 :02/03/07 00:47
>>299
技術的な仕事は全部下請けor社内の他部署にまわして
技術者と営業の中間みたいなことをいしている人達がそういう
会話をしている。といってみるテスト
302仕様書無しさん :02/03/07 00:53
>>299
客にニーズがあってから初めて仕事をもらうんじゃなくて、
経営戦略がどうとか、適当に話ぶち上げて仕事をもぎとるような
商売してるところは大手の殆どかと。
ある意味かれらがそうやって仕事をとっているから、景気が悪いのに
この業界仕事があるのかも。
303仕様書無しさん:02/03/07 00:55
特に「コンサルタント」を自称される方々は、
クライアントにウケる美辞麗句を並べ立てるために、
そういう会話をしがちですな。
304299:02/03/07 00:56
SEは文書構成屋だ、って書いた人がいて、それには激しく同意
するんだけど、結局、CTCやNRIってその文書さえも自分では
書かずに下請けに書かせてるんだろうか?
下流の下っ端でしかないオレからみると、まるで実体のない
ものなんだが。
305Delフサギコ ◆zE1iiRdQ :02/03/07 00:56
   ∧,,∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,゚Д゚彡 < スーツ着て、会議ばっかりしてんちゃう?
  |⊃▽|⊃  \____________
 〜| ◇| ←┐
   ∪''∪  .└ネクタ-イのツモ-リ
306仕様書無しさん:02/03/07 01:00
>>304
SEが下流を自認するところがイタイ。
好きにすれば。
307299:02/03/07 01:04
>経営戦略がどうとか、適当に話ぶち上げて仕事をもぎとるような
>商売してるところは大手の殆どかと。

で、それで上手くいってるのかな?
適当に話をぶち上げといて、実際にそれだけのシステムが
できて、顧客が大満足したらいんだけど、10年この業界で
仕事してるオレからみると、そういう例はとても少なそう
なんだけど、どうよ?
下請けでも、元請けでもいいけど、一番大事なところに
いるやつ1人がダメなだけで失敗したプロジェクトは結構
見てきたぞ。
308仕様書無しさん:02/03/07 01:07
>>307
10年やっててそれかよ。ダセー
ダメなヤツ一人で失敗するのはリーダが無能だからだろ。
あった瞬間に見抜けよ。
309299=304:02/03/07 01:08
>>306
オレはSEじゃなくて、プログラマだって299で書いてるじゃん。
とは言え、この4,5年は上流も下流もない、スパイラルの真ん中
くらいで仕事してる立場なんだが。
310仕様書無しさん:02/03/07 01:08
>>299
俺はむしろ、そーゆー会話の方が莫迦臭いと感じるけどな。
まぁ素人騙してナンボの商売だから、それでいいのかもしれないけど。
311299=304:02/03/07 01:10
そーゆー会話って?
312仕様書無しさん:02/03/07 01:12
>>308
あった瞬間は見抜けないなあ。
313Delフサギコ ◆zE1iiRdQ :02/03/07 01:14
>>307
>で、それで上手くいってるのかな?

カンガエル ホドニ ダツリョク
   ∧,,∧     /キャツラは
   ミ,,゚Д゚彡  < いいものを作ったかどうかでお金を取るのではなく
   ミU  U    \どれだけ人が動いたかでお金を取りますな。
 〜ミ ,, ミ
   ∪ ∪ 
     汎用機で作った出来の悪いシステムを
     数年かけてPCで動くような出来の悪いシステムにして
     それをブラウザで動くような出来の悪いシステムにして…

と、出来の悪いシステムを長い年月かけて
作りつづけるちう無駄を繰り返しているだけではないかしら。
金だけは入り込んでくるけど。

これって、うまく・・・逝ってる?
314299:02/03/07 01:15
>>313
納得。
315310:02/03/07 01:17
>「ソリューションが…、フレキシブルに…、ERPを活用して…」
あなたがた意味判って言ってるですかバカヤロ!みたいな。
316仕様書無しさん:02/03/07 01:22
>>315
了解。
だいたい、オレはITって言葉が嫌い。
あと2,3年のうちに陳腐な言葉の代表になるぞ、絶対。
今だと、「マルチメディア」とか「情報化革命」みたいな。
317274:02/03/07 01:25
 貴重なご意見どうもです。

>>295
 ウウ。学生までだましてどないしはるんですか。

>>296
 他の学生の話聞いてるとばりばりそんなイメージで通ってます。

>>297
>自分のキャリアプランを考えてシステム開発したいなら
>俺なら、営業配属になったら即転職だね。
 …新卒→中途採用っていけますか?

>周りの学生には流されなくても、いいと思うよ。
 他の学生のようにSCMやらERMやらの事について語らなければ
内定取れないのではないかという恐怖感に襲われるんです。
 いちおうシステムどうのといった学科に居るんで、
SCMやらERPとかの講義を受けてる人間です。
受けてるが故に、そんな簡単に語れる概念ではないというのが分かります。
下手に語ると上滑りっつーことが分かるので、
語りたくもないわけです。

なんかホントに…なんつっていーか。
大手と呼ばれるところもどこも言うことがペラペラな気がするんです。
でもペラペラなことを言わないと、学生が来ないから言ってるだけなの…?
ペラペラな事言って寄ってくる学生採って会社やっていけるのかなと思いますし…。

会社選びってむちゃくちゃ難しいですね。

 …スレ違いですみませんです。
318Delフサギコ ◆zE1iiRdQ :02/03/07 01:38
   ∧,,∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,゚Д゚彡 < 実を言いますと…
   U  つ∀ \____________
 〜ミ  ミ ┴
   ∪''∪ MidNightはワインでも

実は、NRIは友達がお勤めになって
アボーン転職したので知ってるんですが
CTCってのはなんちゅう会社ですか?

SCMとかERMとかってのはなんじゃらほい。

>SCMやらERPとかの講義を受けてる人間です。
>受けてるが故に、そんな簡単に語れる概念ではないというのが分かります。

簡単に語れる概念ではないなら
ソフトウェアになりえないから安心しなさいな。
出来上がっても簡単には使えないから
誰にも使われない役立たずシステムかしら。

そんなフサも、ITって名のつく部署にお勤めで....
大丈夫か?>>ミ゚w゚,,彡
319Delフサギコ ◆zE1iiRdQ :02/03/07 01:44
>会社選びってむちゃくちゃ難しいですね。

適当に会社絞った後は
残業時間とか年収とか
オネーチャンがイパーイとかの労働条件
ましそうな所でテキトでいいんじゃない?
あと、技術者キボンなのに営業配属とかされない会社とか。

会社の中でも部署によって仕事内容も
職場環境もマッタク違ってくるだろうから、
こだわらなくてもいいとおもわれ

会社にほれ込みすぎて、理想と違って後悔せんよに。
1つの職場がダメだったらどこでも次はあるんですから
会社も仕事もあっさり変えられるような
柔軟な人材を世の中は求めてるんじゃない?

   ̄ ̄ ̄ ̄ Ο  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
       ο
       ゚
    ∧,,∧      オヤスーミ
| ̄ ̄ミ,,-Д-ミ ̄|  
|\⌒⌒⌒⌒⌒⌒\
|  \           \  
\  |⌒⌒⌒⌒⌒⌒|
  \ |_______|
320仕様書無しさん:02/03/07 01:56
>317
ていうか、大手の方がそういう点ではいい加減だよ。
どんなクソSE・PGも組織の看板に守られてるからね。
SEはいい加減なことをくっちゃべり、
PGはいい加減な実装をしてくる。
で、クライアントはブチ切れ。

そういう意味では、大手よりは中小の方がしっかりしてるヒトは
多いと思われ。
中小だと、本当に少人数でヒアリングから実装まで全部担当するからね。
ゴマカシが効かない。
321仕様書無しさん:02/03/07 01:56
特にメーカー系列SIのSE/PGはほとんどクソです。断言してもいい。
322仕様書無しさん:02/03/07 11:03
>CTCってのはなんちゅう会社ですか?
伊○忠テクノサイエンス
名前が示すとおり、某商社系のシステム会社。
親会社が商社だけにプレゼン「は」うまいよ〜ん。
323仕様書無しさん:02/03/07 15:14
>1のかた
もう転職されたんですか。もしされたなら、その後を聞かせてください。
324仕様書無しさん:02/03/07 15:22
要求定義のできないSE逝ってよし。
これは能力の問題じゃなくて、度胸がないせい。
いつまでもつまらない細部で会議ばっかやってる
せいか頭がいかれてるものと思われます。
325仕様書無しさん:02/03/07 16:06
>要求定義のできない

これは、Sヨとか、そういう問題じゃないよ。
どんなアウトプットにもその前に要求定義があるんだから、
この人は開発に関係する仕事はマズイんじゃない?
326仕様書無しさん:02/03/07 16:27
>324
いや、そいつが度胸あっても困ると思うぞ。
「わかりました!!ここはもう思い切って全件削除しましょう!!」
とかあっさり決められた日にゃぁ...

スキルがあるという前提があれば度胸を持ってくれて構わんが。
327仕様書無しさん:02/03/07 18:17
度胸つうか責任だな
328仕様書無しさん:02/03/07 18:48
 
329仕様書無しさん:02/03/07 22:51
漏れ、理系・文系・上流・下流・SE・PGとかよりも、体育会系・文化系の
違いっぽいのを感じることの方が多い気がするんだが、お前らどぉよ?
漏れだけかなー? 文系の体育会系とか理系の文化系とかあったりして
何となく体育会系が来ちゃうと「やべ」とかさ(w 特に営業とかプロマネとかに
そういうのがいると、話が全然かみ合わないとか。漏れは無気力のヒッキー
文化系だけどさ(藁 気合とか根性とか、およそシステム作るのにかみ合わない
キーワードが大前提に来ちゃうと引くんだよ、漏れ。
330Delフサギコ ◆zE1iiRdQ :02/03/08 01:43

   ∧,,∧     /イトチュウ系か…
   ミ;゚Д゚彡  < 
   ミU  U    \数ヶ月前、イト厨系のインフォアベニウってトコ
 〜ミ ,, ミ      面接ったYO....
   ∪ ∪
 残業氏ぬほど多いって豪語してた
 んでパスったけど。
331仕様書無しさん:02/03/12 13:08
332 :02/03/12 13:23
>>1
俺??
333出張32:02/03/12 20:25
>>1
悪いことは言わんから「コンサル=営業支援者」程度で我慢しとけ!
設計者を目指すのならCOBOL系に限定して精進しろや、それならば
言語等知らなくてもお手本は幾らでもありサポートもしっかりしてるから
何とかなるだろう。
だが、オープン系の設計者を目指すのなら使われる材料の性質や特徴を熟知する
必要があり難しいと言える。

# もし君が設計者としての武器を会計知識に限定するのならば営業支援者としての
# 技量しか持ち合わせていないことを理解してくだされ。
334仕様書無しさん:02/03/12 23:11
>>333よ過去ログ読めや。R/3担当って言ぅとるがな。>>1はどないしとるんや?
3351:02/03/13 00:53
呼びました?
話がそれてるようなので静かにしてました。

332は俺じゃないよ。

336仕様書無しさん:02/03/13 02:33
出張32は放置するべし。相手にする価値は無い。
337仕様書無しさん:02/03/17 15:30
出張32は情シス板へ帰れ
338仕様書無しさん:02/04/18 22:29
       我等極悪非道のageブラザーズ!
       ネタもないのにageてやろう!
     くっくっく…
        ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ∧_∧   ∧_∧   age
       (・∀・∩)(∩・∀・)    age
       (つ  丿 (   ⊂) age
        ( ヽノ   ヽ/  )   age
        し(_)   (_)J
339仕様書無しさん:02/04/18 23:20
なんだかんだいっても、人月でいえば

クソSE>敏腕PG

なんだよなー。鬱だ。
340仕様書無しさん:02/04/18 23:25
ごちゃごちゃほざいていても、所詮はPGはPG。ピーピー叫くのが精一杯です。
コードなんか書けなくても工程管理と仕様固めができればSEはいいのです。
道具とソレを使う人との関係といえばわかりがいいでしょうか?
341仕様書無しさん:02/04/18 23:32
SEは道具
342仕様書無しさん:02/04/18 23:37
PGは、使い捨て
343仕様書無しさん:02/04/18 23:39
>>342 すぐ痛むしな(ワラ
344仕様書無しさん:02/04/18 23:46
>>340
コードがかけないのに工程管理とか仕様とかできるSEってのが
ようわからん。つうか、客先にいってシステムの概要を聞いて
いる段階で、「ここはこんな感じのコードになるなー」とか
「あー、コードは簡単だろうけど、ボリュームきつー」とか
自分がプログラミングするときの感覚で話をすすめるのだが・・・

そうでないSEは、どういう思考回路なんだ?????
345仕様書無しさん:02/04/18 23:57
>>344
一日が24時間だから、工数は3倍までの余裕があると考えている。
346340:02/04/19 00:00
>>344 細かいことはいいのよ。PGの表情でだいたい大変さは分かるからさ。
それに俺がいってる書けないってのは、製品として納めるようなコードは
書けないと言うか、書ける必要がないってことね。
そういうみみっちい仕事はPGのやることだろ?
まあ、PGどもは生かさず殺さずということで、マターリといきましょうや。
347仕様書無しさん:02/04/19 00:04
>>344
あまりそんな奴いないと思うけど
既成概念がない分新しいものができると思う、プログラミングもできて設計も
既成概念にとらわれなければ一人前のSEだけどねと思う
348仕様書無しさん:02/04/19 00:09
コードが書けないSEの言っていることに根拠は無い。
349仕様書無しさん:02/04/19 00:12
>>348 コードが書けてもPGとは限らないというwana
350仕様書無しさん:02/04/19 00:15
PG=まじめなひと
SE=うそを言う人
コードによって定義されない >>ALL
351仕様書無しさん:02/04/19 00:18
一番むかつくのは、コードを書いていたけど忘れたSE。
自分の誤った方法論を押し付ける。
・・・屑だ。
352仕様書無しさん:02/04/19 00:23
SEがしたいからSEになるというならましだが、
PGが出来ないからSEになると言う奴にはろくな奴はいないな。
あと、俺はPGが出来ないからと断言する奴とか
自分がPG出来ないのにPGを馬鹿にする奴とかもダメだな。
353仕様書無しさん:02/04/19 00:29
SEの人ってどんなことを勉強しているのですか?
単に仕事をこなしていれば立派なSEになれますか?
354仕様書無しさん:02/04/19 00:34
>>353 2、3人PGをポンコツにしないと立派なSEにはなれません。
コレホント。
355仕様書無しさん:02/04/19 00:34
スクラムが組めないFWってどう思います?
356仕様書無しさん:02/04/19 00:37
>>354
それだけで立派なSEになれるのか? 簡単そうだな。
357仕様書無しさん
>>352
同感。プログラムを組まないSEと組めないSEでは大違い。