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

ERPのアプリケーションコンサル（財務会計）ということで転職します。
カテゴリーはSEということですが前職が経理屋で職種変更なんですが
プログラムは全く分かりません。

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

通用せん。転職は失敗ですな。

「ERPのアプリケーションコンサル（財務会計）ということで転職します。」ってことは、
まだ転職したわけではないんですね。
考え直すなら今のうちですよ。
プログラムを全く知らない SE なんて迷惑なだけだからね。

PGやるんじゃないから問題なし。
コンサルだからPGじゃなくてSEにしておけって程度の事。

>>1
ERPのアプリケーションコンサルならプログラムなんて知らなくても
まったく大丈夫。でも入ってからはかなり勉強しなければなりませんね。
経理の時も勉強したでしょ？ところで経理の方はどれくらいの腕ですか？
一人で決算できます？

プログラミングなどには無縁のお仕事ですね。

SE（何度もいうようだけど、この SE という曖昧な単語は嫌い）と言わず、
経営コンサルタントと名乗ったほうが分かりやすいと思います。

基本的に無理。
中途採用で教育なんかしてくれないよ。
ＯＪＴとか言って、レコードの概念もわからない人間にフローチャート書かせて「こんなこともできないのか」って笑われておしまい。

>>7

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

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

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

と、相手にうまく決断を促す仕事なわけだ。これは価値ある仕事だと思うよ。

>>8

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

何を作ればいいのか分からないプログラマにとって、こういう存在は必要だと思う。

>>1
パッケージなんてカスタマイズしない方向でコンサルしていくし、
ERPベンダーSEでPG出来る人のが少ない。

>>9

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

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

そっちのほうがプログラマにとっても有り難いはずだしね。

会社にもよる
プログラマの勢力が強い会社だと苦労するかもね。
「プログラムも出来ねぇ奴がうちで何するつもり?」と。
馬鹿みたいだが、結構あるんだよな、そういうの

プログラムそのものができる必要制覇ないのだけど、
プログラムすらしらない人間が、
システムの特徴とかわかるんでしょうか？
んで、わからない人がpresentationできるんでしょうか？
しかし、システムを良くわかる人とコンビで仕事すれば問題ないです。

>>12

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

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

顧客あってのプログラマ。

>>1
いわゆるコンサルという名の、SEという名の営業ですから(^^ゞ

>>13

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

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

一度、どういう仕事なのか、どういう役割分担が求められるのかっていうの
をコンサルタントは知るべき。

>>14
いや、ちと違うと思う。
プログラマにおいても何を作るかは大前提。
押さえなきゃも何も押さえてないで、仕事進むとは思えない。
「何を作るか？」・・・・・顧客が決定すること
「実現方法は？」・・・・・エンジニアが提供すること
彼らの橋渡しが、プログラムができないSEの仕事と思われ。

>>17
まちがった。舌の各個は「どうやって作るか？」

え？
プログラムの経験もないのに、どうやって工数を弾き出すんですか？
根拠が無いでしょ？
SEはシステムがどうとかっていうのも勿論必要だけど、
お金の事に関してもプロフェッショナルである必要があります。
いい加減な仕事はしないで下さい。

工数は現場のプログラマのみぞ知る。

どう実装するか思い浮かばないのにＳＥと自称する輩が多いことか・・・

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

「ＯＲＡＣＬＥを使ったシステム構築の実績はありますが
ＲＤＢＭＳについてはこれから前向きに検討しています」

とか

こんなのがいてわけわかんねーよ。

「書類じゃわかんないですよ工数なんて！」

>>22
わかるわかる。

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

>19
んじゃ、プログラムの経験ある人はどうやって工数はじき出すの？

どんぶり勘定？
それとも、脳内見積？
それはいい加減な仕事ではないの？

ご立派なＰＧ上がりのSEが率いるプロジェクトに、
デスマーチはあり得ないって論旨になってきた。

>>24

そんなアナタに Extreme Programming。

>>25
ありえないですよ。私、そういうSEの元で仕事する機会がありましたけど、
土日祝日出勤一度もなかったですよ。徹夜も無かったですよ。
終電近くまで残業することは、６ヶ月中一ヶ月ほどあったけど、
それくらいかな。

>>19
工数は、ＰＧとかと相談してはじくんですよ。
1>>はコンサルとして入るんだから工数はＰＧと相談して決めるんですよ。
1>>が工数算出したら大変だな。工数多ければ顧客に理由をつけることが
できず。説明できるレベルで工数出すとデスマーチ。

>>27
補足、そのプロジェクト。人が集まらなくて予定より
２人少ない状態で、がんばりました。

ERPが何たるかをしらないあふぉがあふぉなレスつけていてかなりﾜﾗｴﾙｰﾖ。

ゲームプログラマか？

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

めずらしくいいｽﾚだ。

どうせ入社前にある知識なんてのは大したもんじゃないと考えて、
入ってからなんとかすればいい。
その点即戦力求めてる、なんて会社はｸｿだからやめた方がいい。
実際求めてねぇんだよ。教えるのがﾀﾙいからってだけだ。

SAP がどんなものか知りたい学生なんだけど、
SAP の書籍ってあんまり見ない。
WEB でも本でもいいから入門にいいのない？

　　∧,,∧　 　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ミ,,ﾟДﾟ彡　＜　XPで全部解決
　 ,;ﾞ　　ﾐ　 　 　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
＼ﾐ.　　ミ 　その際、ｺﾝｻﾙSEはｵﾝｻｲﾄ顧客的な
　　゛゛゛゛ 　　仕事の仕方をするといいかも。

ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは知らなくてよさそうだけど
XPは氏って置いたほうがいいとおもう。
ﾆﾎﾟﾝにはｵﾝｻｲﾄ顧客がいないから。

俺の友人もﾉﾑｿｰ辞めてどっか違うとこでSAPerになっちゃった。
>>33
そんな書籍あるの？
ﾄﾚｰﾆﾝｸﾞだけですげー金必要なもんでしょ…多分

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

ﾆﾎﾟｰﾝで数千人規模カスタマイズ仕事だけで
飯食ってる連中がいる

という感じなのかな？

SAP/R3
(ﾘﾘｰｽ3って事)のちょっとしたVerUpだけでも
ｲﾝｽｺとかがいろいろと大変な問題らしいよ。

みなさんResありがとう。

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

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

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

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

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

プログラムが組めないのは問題だと思う。
いずれにしても一流ＳＥにはなれない。

女性の場合、結婚して退社だもんな。

PGに陰で馬鹿にされながらがんばってください。

っていうか、SAPを使う企業じゃなくて、ほんとにSAPに入社するの？
だったら一人くらいここ読んでる人いると思うよ
入社を検討している会社名を掲示板でだすようなｱﾌｫ雇うのかね、、SAPは

>>38　SAPでもなくて、ユーザーでもなくて
SAPのR/3を取り扱うSIでした。
いくらなんでもそんな馬鹿じゃないです。

プログラムが組めなくても
完璧な仕様書が書ければ文句はない。

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

こういうことでしょ？

そもそもSEとPGを混同してる会社が多いから
プログラム書けなきゃSEが出来ないなんてことに
なっているんだと思われ。
SEがプログラム書いてたら仕事は進みません。

SAPのスレで世間一般のSEを論じても話にならんが‥。
ちなみに、ソフトだけの最小構成で600万、導入前のコンサルが月/200万、ハードやRDBで
数千万ってモノを導入できる企業はSAP屋の数より少ないって話があるぞ。
俺はCOBOLチックなマクロをおぼえてここ数年に賭けるのは御免だが。

SEはプログラムを書かない。・・・が、
プログラムを書けないSEは死んだ方が（・∀・）ｲｲ!

プログラムがかけない優秀なSEの条件をあげてみよう。
とりあえずRDBMS関係。

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

これらを知っていなけりゃまともな仕様書は書けなく、
知るためには実際に作ってみるのが一番早いと思うがどうよ。

だから、まずSEという言葉を忘れることからはじめましょう。

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

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

>>1 さんは、開発の現場では「顧客」に当たると思います。
>>43 さんは、現場で働くプログラマの役割。
仕事の障害になってるものを取り除くのがマネージャの役割。

>>1
大丈夫です。絶対に通用しません。
　したがって謙虚な姿勢を保つことが大事です。
　そうしないと田中外相になります。

>>44
うむ、俺もそう思うよ。XP的な分け方が一番良い。

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

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

だれだよSEってわけわからん職種作った奴は。

>1
もし　hoyaならやめたほうがいいよ。

自分、SEというなのど素人、しかも給料だけ一人前の人間に
どんなけ苦労してきたことか。あいつらは業界の本当のお荷物です。
そんな人間にだけはならないように。

>>48

あなたがいうお荷物さんとは、具体的には、どんな仕事をやってたんですか？

>>49
具体的にはプログラムを組めないからプログラマに的確な指示を
だせず、プロジェクトに損害を与える。それが自分のせいだと
わからなくて他人を責める。
このｽﾚで話題になっている人種だよ。

>>50

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

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


やはり、XP の導入の必要性を感じますな・・・。

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

つまり、プログラマの仕事量およびスケジュールを見積もるには、
プログラマの仕事（の質と量）が分かってないといけないという、
あたりまえの結論に。

このｽﾚ、タイトルが悪いね。
タイトルに ERPとか出していれば、
無意味な SE-PG論にはなりにくかったろうに。

すんまそん。。

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

>>54
なにを考えているのか分からんが、ここで出てきているXPとは
eXtremeProgramming (エクストリームプログラミング)のことだよ。

ホウレンソウと言われれば、まぁそういう意味も含まれてるか。
なんかイヤな表現だが。

というか、対外交渉も含めて最適な解が思いつける人が
SEと名乗るべき。

なんでSEってヴァカばっかなんだろうね。
稀によくできるSEに出会うと本当にビクーリするよ。

ヴァカSEとは・・・（一例）
・不勉強なくせにやたらと偉そう（圧倒的大多数）。
・プログラミングは能力の無い者のやることだと思っている
　（「お前やってみろ！」と言いたくなる・・・やらせても大概できない）
・時代の流れに疎い。私のような世捨て人のPGからみても
　時代遅れな開発手法しか知らない。

SEのSはスーパーのSであるべきだ、ということで一件落着かな

開発において、ホウレンソウを円滑に行う常識的な習慣を集めパッケージに
したのが eXtreme Programming とも言えますな。

XP では人、コミュニケーションが何より大切にされます。

>>58
「稀によくできるSEに出会うと本当にビクーリするよ。」
よくできるSEって、どういう人ですか？ ヴァカSEと正反対の人？

>>61
人にきく時点でだめだめ。
身をもって知るべし！

稀にしかいないからなぁ。

漏れ的SE・PGの線引き
前提条件：ユーザーよりもシステムに詳しい
対人折衝能力のある人→SE
対人折衝能力の無い人→PG
PGは頭脳どかたと考えている人→SE
コンピュータ以外にはなんにも出来ない人→PG

つうかさ、PGもいずれはSE（セールスセンジニアの方ね）をやらなきゃいけなくなるのだからさ、
ちょっとは、この業界を変えてやるぐらいの意気込みのある人が出てきて欲しいのだけど･･･。

日本の「ＳＥ」なぞ世界では通用しない。
対外交渉はＳＥの仕事ではない。
ＳＥはシステム設計のエキスパートであるべき。
当然、ＰＧの親玉みたいなプログラミングの知識も必要。

>>64 ＳＥってのは普通システムエンジニアのことだが？

就職板のSEスレ見たことあるけど、業務内容を知らないまま
SEを志望する新卒（非工学部系）の多さに、ビックリしたことがある。
人事に「プログラムはすぐにくめるようになる」などとほのめかされ、
上流工程と下流工程と言う言葉を意味も知らず連発し、
上と下では上の方が偉いに決まってるという認識で、
PGよりもSEを志望している学生がかなりいた。
奴らに、情報工学という分野が何の為にあるのかを教えてやりたい。

>>64

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

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

（しかし、その割に、そのビジネスが失敗したら、そのコンサルタント会社が
責任取るってことは無いんだよね。なんか胡散臭いよな・・・＜コンサルタント）

プログラムできなくても問題なし。
会社があなたを採用したのは、業務知識　があるから。
客先の業務内容（運用）を理解して、対話することが重要な仕事。
そしてＳＡＰに置き換えるには、どうすればよいかを検討する

>>65
対外交渉というより要求仕様分析ですよね。
昔は、PGとSEの区別はもっとはっきりしてたんですが...

>>66
今のハヤリはコン猿です。
情報工学とか情報科学とかのやぼったい知識はともかく
とりあえず「コンサル（ーん）」が大事らしいです。

　　 　∬　　　∧,,∧　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 　 ~━っミ ﾟДﾟ彡,, 　　　＜ 　SEって名は本当に忘れた方がいいね。
　 　 ∀.＿（,,,~　　,,,~⊃＿　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━┳┷　|.　,(~ヽ,,,ﾐ.
　 ┃...|￣￣し'Ｊ. ￣￣￣
　 ┻ ヽ￣￣￣￣￣￣￣

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

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

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

よくできるＳＥ＝話のわかるＳＥ　かな。

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

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


話戻すけど、SAPのコンサルっていって
ＳＡＰ社に入ると思うってのは、どうかと…>>38

今の学生はノンポリばかりだからな。
そういや、バブル景気のころ証券業界に入って、バブル崩壊で悲惨な目に学生が随分いたな。

ちゃんとした要求定義から分析までをしっかりこなせるなら
それだけで飯食ってくのもありかもね。だけどこれってPGとして
必要とされる知識よりもかなり多くの知識が要求される。
これがしっかり出来るならエンジニアとして呼べるだろうよ。
でも出来る人なんてごく僅か。またそれだけの為に人を割り当てる
プロジェクトってかなりでかいものばかりだし。

元R/3のFI（財務会計モジュール）コンサルです。
その前にPG、SEやってましたけど、流行に乗って転職した口です。
あまりの酷い状況にさらされて、素直に辞めました。
今はJavaでWebアプの設計から実装までやってます。

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

でも人月300万円だったので当時は給料良し。儲かる儲かる。死ぬほど
忙しかったけどな。今は給料は下がったけど、客に対して堂々と出来る
状態に戻ったよ。アドイン1本（フツ〜のVBとかなら20万円もらうのも
恥ずかしいくらいのレベル）作るのに100万単位の見積なんて、羞恥心が
あったら出せないだろ、普通。所詮、金持ち同士のITゴッコだ。
人間であることを捨てれば稼げるぞ>>1よ。頑張れ（藁

>>68　経理屋出身は人は良いが対話できねぇ奴多し。良し悪しは別でな。
1はSEってのをセールスエンジニアと読み替えて、営業の勉強に励むよし。
SIerならマシだが1が外資系のコンサル会社に入るんなら覚悟しておけ。
腕は要らない。口が食い扶持だ。

俺が今かかわってるプロジェクトは100人近い人間がいるよ。
もちろん、いくつかのグループで構成されているんだけど...
俺、最初は要求分析と設計だけやってたんだけど、
納期が迫って、今はプログラム書いたりデバッグ手伝ったり...
自分が SE なのか PG なのかよくわからんよ。

　　∧,,∧　 　／　>>76
　 ミ,,ﾟДﾟﾐ ＜　　　当たり前でしょ
　 ﾐ　 　ミ　 　＼　
〜ﾐ,ＵＵ_ﾐ 　

　　って…要求分析と設計が出来なくて
　　プログラムなんて組めませんが。

>76
SEやPMが現場に降りたら、もう大体だめだよね。

>77
サブシステム自体の要求分析なんだよ。3層C/S

>>76

こういうのがドキュンSEと言うんですね。
（設計してプログラミングしないなんて、アホかっちゅーねん）

えっ、SEがプログラム組むの？

>>73

XP的には、あなたの言う仕事は全てプログラマの仕事でございます。

80 は大規模プロジェクトを知らんらしい...

>>78
うちでは経営者まで現場におりてきます

>>84
きっついなー。

>84
その経営者、偉いよ。

>>86
偉いと思うけど。
会社としては先が見えたなと思わないか？

>>76
とすると、自分でプログラム書いたりせずに、ライブラリなど次のプロジェクトで
役に立つものを今は設計したほうが、全体的には楽になるかもよ。

74>あまりの酷い状況にさらされて

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

宜しかったら教えてください。

>>74
>所詮、金持ち同士のITゴッコ

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

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

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

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


>>76

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


>>87

偉い。最高の顧客。プログラマ的にはそれが一番ありがたい。

設立して何年経ってるかによるな。
立ち上げてまもない会社なら、こういったことは珍しくないだろうけど...

SAPはプログラムってほとんど組まないんでしょ？
むしろ業務にたいする分析力が必要だから、コンピュータ経験の長い奴より
経理経験のある奴の方がいいんじゃないかな。
僕はゲーム業界からシステム業界にきてるから一生、ERPは縁のない世界だ。

大規模プロジェクトにもXP的手法をとりいれることは出来ないかな

>>90
日本は業務コンサル能力と技術コンサル能力を兼ねたSEがまだまだ
少ないからね。
たいがい業務コンサルは口しか出さないで設計は書かない。
ほとんど技術SEが仕様、設計を考える。
できあがったシステムはほとんど技術SEのアイデアをもとに作られたシステム。
業務コンサルは会計士や税理士や業務経験のあるだけで、
システム化ということに対してはまったく勉強してないのが多いよ。

>>94
＞業務コンサル能力

営業みたいなもんすか、それって

>>93
難しいね。半分要求分析して、１０人ぐらいのグループに分けてそれから XP
なら何とかなるけど、１００人なら１０グループに分けるまでが難しい。

>>90
>>91
社長の定義が違わないか？

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

で、どっちよ。　>>84
前後のﾚｽの文脈的には、自社みたいだが。
そりゃ…やばそうだよな。(w

>>94

XP的には、それで結構！！　むしろ、実際にコーディングしない人間が
技術的なことに言及されてると、迷惑。

>>95
違います。
その業務に対してどういうシステムを作るかを考える人です。
場合によってはコンピュータに人をあわせて効率化をあげるような
ことをしてもいいのではないかと思うが、ほとんどのシステムは
それをやってない。
ただ紙やペンを使わなくさせればいいと考えてるだけのシステムが多い。
現状では紙、ペン、電卓のかわりにただシステムが作られているだけだよ。

>>98
コーディングってシステムではそれほど重要ではないでしょ？
プログラムなんて一、二週間勉強すれば大丈夫だしね。

>>99
ますますSEとの違いが分からなくなってきた。

>>101

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

>>99 さんの申していることは。
コンピュータ化する際に、こういうことできますよ、っていう提案する
コンサルタント営業の人やね。

>>101
ワークフローみたいなもんがきちんと定義されていない業務をシステムにしろ
って言われるのは面倒でしょ。だから、業務自体の流れを先に改善するひとが、
業務コンサルで、それをシステムに落とすのが技術SEっていうことでしょ

>>100
やっぱネタ･･･だよね。

>>100
その辺はやっぱり生まれついての性質がものを言うなぁ。
だめなやつはだめ。

>>100

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

今、どの機能が実装されているか、という進行状況を常にトラッキング
することが重要で、もちろん、顧客にはその権利があります。

SE は顧客の要求を分析し、システムのモデルを考え、
どこを自動化(コンピュータ化)するか等を、顧客の予算に応じて考える。
自動化する部分が決まったら、そこの外部仕様や処理方式を決定する。
ここまでが、SEの仕事だと思うな。
外部仕様や処理方式が明確になった時点で、PG に回す。
詳細設計、単体テストはPGの仕事。
総合テストは SE 立会い。
こんな感じかな。

>>107
予算は何を元に決めるの？

なんか、XP の話してる人がいるけど実際にやってるの？
すげー興味あるんだけど。

>>107

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

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

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

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

SE という言葉は本当に曖昧でよくないと思う。

>>108
まず顧客の要求を全て聴いて、それぞれの要求にたいしどれくらいの工数(費用)がかかるかを見積もる。
当然ある程度のスラックをいれておく。
そして、それを顧客に提示するんだ。
後は顧客に決めてもらう。
顧客は要求自体を取り下げる場合もあるし、次期案件となる場合もある。

>>108

一番当てにあるのが、「前例」だと思う。
一人一人のプログラマの見積もりも同じで、一番見積もりのいい方法が
「昨日できたことは今日もできる」

>>107
外部仕様は画面や帳票でいいのかな？
処理方式とは何のことを指してるの？

>>113
外部仕様とは、顧客が見たり操作したりできる全てのものの説明。マニュアルみたいなもんだ。
処理方式は、顧客の要求とは直接には関係しない。
システムの個々の部分において、即時処理にすべきか一括処理にすべきかといった決定だよ。
工数のことを考えて、もっと細かく決定することも多い。
ソケットにするかRPCにするか、既存の部品を流用できないかとかいう判断だよ。

>>89
昔を思い出して可哀想になってきたので（俺自身がだｗ）、真面目に
書いてやる。

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

でだ。付け焼刃で出来もしない業務プロセスを知ったかぶって
押し付けるのがERPコンサルだ。違うというなら、ERP抜きで
成功報酬で経営コンサルをやってみればいい。出来る奴は殆どいない。
何故なら出来る奴はERPなんて土方やらなくても儲かるからだ。

それはさておき、口だけの押し付けプロセスが業務仕様として決まるとだな、
それをパッケージ上に実現しないといけない。でな、これが出来ないんだよ。
当然だ。Gap&FitなんていうがFitする箇所なんてないんだよ。しかし、この
時期になるとコンサル側は出来ませんとは言えないわけだ。そこで帳尻を
合わすために、技術者に押し付けるわけだ。具体的にはR/3ならアドオンだ。

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

コンサルも暢気な事はしてられなくなる。最近はちゃんと動かないと訴訟も
あるからな。だもんで、結果として死ぬほど忙しくなる。

で、だな。駆り出されたSEやPGから見れば、無能なコンサルを殺したくなる
わけだ。しかしコンサルにはどうすることも出来ない。当然だ。スキルないから。
かくしてエンドユーザにとっても不幸なシステムの出来上がり。でもって
一部の偉いさんは出世するという段取りだ。

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

繰り返すぞ。ERPコンサルなんて本当のコンサルタントではない。そんなものを
期待していくと人生間違えるぞ。ぼったくりのテクニックを磨きにいくんだ。
ついでに現金ももらえるぞ。後、夜道には気をつけれ（藁

FI経由で本当のコンサルになりたいのなら、会計士のレベルは余裕で到達しておけ。
ERPコンサルのITスキルなんて世間は評価してないからな。
原価企画くらいは語れないと駄目だぞ。EVAとかバリバリになれ（笑）
今度入社する会社の次のパスを最初から考えて行動しないと消耗品になるぞ。
あと2回は転職する覚悟決めておけ。

何を好き好んでとも思うが、俺も入るまでは薔薇色の未来を夢想してたので
気持ちはわかる。まぁがんばれ。

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

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

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

長文スマソ。以上だ

>>119

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

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

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

これに尽きる。

まだCOBOLが業界のメインだった頃にSEと呼ばれた人達の業務のひとつとして、
「電算化によるシステムの効率を最大限に上げる為、顧客がコンピュータに
合わせるように要求し教育もする」というのが含まれていました。そして、
歌って踊れるSEを目指せという言葉もありましたが、つまり接待上手でないと
仕事を取れないし、人間関係も上手くいかないという戒めを込めた言葉でした。
これは当然、システム設計もコーディングも出来た上での話です。
そしてその頃はよく「人間がコンピュータを使うのではなく、コンピュータが
人間を使う時代がくる」という話もしていました。
しかし、かつてのSE達は何処かへと消え去り、コーダーやパンチャーと呼ばれて
いた人達がいつの間かSEを騙って昔話をするうちに、いつの頃からかSEは無能で
ある事を指す代名詞の様になってしまいました。

>>119
一度あってみたいね、面白そうな奴だ。

組めなくてもいいから、設計書ぐらい書け。
プログラム言語を操れるのと設計書が書けるのは別だからな＞全国のＳＥ諸君

>>121
コーディングがまるで出来ないSEが昔からいたとは思えない。
いつからだろう、大手SIがPG経験のない人間にいきなりSE職をさせるようになったのは。

>>123 >>124

いや、もう だから、SE という言葉の意味自体が曖昧ですから、いくらあなたが
SEについて主張なさっても、ほとんど無意味です。

昔のSEは、コーディング、バリバリでした。
神でした。

>>125
業務コンサル、技術コンサルに分断するにしても、結局は両者とも「歌って踊れる」
SE的知識を要求されるのでは？

>>1よ、最後にもうひとつだけお節介だが追加しておこう。
本当のERPの価値を知りたければ、生産管理を勉強しろ。
これも非常にロジカルだ。面白いぞ。生産管理を単に
製造業の1プロセスとして捉えるのではなく、資源配分の
ロジックとして見直して、それを会計で常に定量化して
把握するということを考えれば、ERPそのものがいかに感動的か
実感するぞ。しかしいきなりPPは辛いだろうから、FIに慣れてきたら
MMに手を出してみるといいだろう。会計だけに染まりきると
潰しきかんぞ、ほんと。ま、とはいえFIだけでも大変だがな。

ERPの本質を理解できれば、面白い仕事ができるはずだ。
ま、それでもR/3は（以下略）。とにかく頑張れ。俺は寝る。

>>127

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

（せっかくのいいスレッドなので、できるだけ明確にお願い。
あと、何度も言われてますが何度も言いましょう。SE という言葉は曖昧なのでできるだけ避けてください）

>>129
昔のSEってのはXPで言えばPGであり管理者であり顧客でもある事を
要求され、またそれを満たしていた人の事です。
もちろんそうでない人もいましたが。
そのうち「XPも今は昔になりにけり」と言われる時代がきます。

>>129
前スレでも似たような話が出ておりましたが、「歌って踊れる」っていうのは、
顧客折衝→要求分析→設計までこなすのがSEではないか？ということ。
当然、業務知識＆技術知識が必要になるわけで…。

逆によい呼称があれば教えてください。

>>130
PGを何年か経験してSEになる、っていう流れも、「SEはPGとしての知識を必要とする」
ということが不文律としてあったからではないでしょうか。

プログラムを知らなくとも機能レベルまでの落としこみはSEで出来そうな気がしますが、
問題は「見積もり」ですかね。
結局、顧客折衝の中でスケジュールとかは決定していくものですから。

>>132
やはり工数の見積もりだろうと思います。
これは、PG やった人間が一番わかるとおもいますよ。
PG の経験がない人間には、この見積もりはかなり難しいのではないですか？
PG 経験の浅い、あるいは全くない SE が増えてるから、軋轢が生まれてくるのでしょうね。
PG も SE も最終目標は同じはずなんですが...

>>132
>PGを何年か経験してSEになる、っていう流れも、「SEはPGとしての知識を必要とする」
>ということが不文律としてあったからではないでしょうか。
昔は「コンピュータは何でも出来て凄いらしい」程度の知識しかないクライアントに
ふっかけられた無理難題を手練手管で「それは無理だけど、こうしていいなら出来るし
コンピュータが凄いのは確かだ」と言いくるめて金をふんだくる、いや説得するのも
SEの役割でしたので、「コンピュータには何が出来るか」が分かっていない人をSEと
呼ぶのは途方も無く馬鹿げた事でした。もちろん、「コンピュータには何が出来るか」
とはつまりプログラムを作るという事が理解出来ているかという事です。

>問題は「見積もり」ですかね。
>結局、顧客折衝の中でスケジュールとかは決定していくものですから。
ここで本当に「歌って踊れる」という要素が重要になってきたり。

横槍ですが、工数の見積もり苦手です。

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

この業界はどうなってるんですか!?

>>133
>PG 経験の浅い、あるいは全くない SE が増えてるから、軋轢が生まれてくるのでしょうね。
現在SEと呼ばれる人に求められている一番大きな要素であり、また一番欠けている要素は
いわゆるオンサイト顧客という役割だと思います。すべての役割において未熟なSEは、
金払いと物分りの悪い客先に匹敵すると思います。

>>135
自分自身でも工数の見積もりが出来てなきゃ話にならん。

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

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

新人君は0.5人/日で計算しましょう。
実際にはもっと少ないかも知れませんが、それは出来る人がカバー。

>>135
この業界じゃ人/月とかで費用をを弾き出されることが多いですね。
無能な人間も有能な人間も基本的には同じ価格です(学歴による単価テーブルは存在しますが)。
そういった慣習を打ち破るのは難しいことだと思います。
経験者は、未経験者の2〜3倍は仕事をこなせるものです。
だからといって、経験者の売上が未経験者の2〜3倍になることってないですからね。
おかしな話ですよね。

>>135
見積もりはともかく工数が計算できない奴は終わってるな。
普通は一年この業界でやってればだいたい見えてくるだろ？
趣味でやってた？だいたい趣味のレベルがわかるよ(w

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)

>>141
君のいうXP的手法ってどんなんなの？
実際にXPエクストリームでのプロジェクトにはいってるの？
教えてちょ&hearts

>>142

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

僕はERP パッケージの開発に携わったことは無くて、もっと要求のはっきりしたものしか
作ったことは無いです。XP を全面的に取り入れたプロジェクトに関ったことはありません。

>>141
XPのオンサイト顧客ってコミュニケーションの手段どう定義してたっけ？

クライアント先での打ち合わせって結構時間とられんだよなぁ。。。

>>135
趣味ね…。
例え趣味でも、本当に長い期間組んできたなら、
最低限、自分の工数くらいは解ると思うが。

あんたがﾍﾀﾚなだけだろ？(w

>1
本題に戻りましょう。
まず、通用するかという点ですが、世間一般のSEとしては
まったく通用しません。ただSAPの世界では、会計の相談係り
としての仕事はできるでしょう。また営業の仕事もこなせるかも
しれません。
ただ忘れていけないのは、あなたはそれなりの給料はもらえますが
それは実力ではなく、世の中の恵まれないプログラマからかすりとった
給料、SEという定義が現在でもつうようするなら世間の優秀なSEから
かすりとった給料であるということです。
すこし、きつい言い方をしましたが、世間では実力があっても正当に
評価されず、リストラされている人々が相当数いると言うことを忘れないでください。
IT産業にはまだバブル経済が残っている部分もあるのです。

115-119.128さんどうもありがとうございます。
非常に参考になりました。また現状を非常に分かりやすく
説明していただき感謝しております。

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

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

146さんもありがとう。

ERPってそんなに流行ってんの！？
大学でSCMの講義受けたときに出てきたんだけど、
大学の年季の入った教授が教えるからもう古い概念かと思ってた・・・

>>149
ほかの技術はすぐに廃れるけど、ものが経済だけに絶対に廃れないでしょ。
使っている技術のほうは廃れるかもしれないけど。

>>139
自分に製造原価という考え方がないことを表明しているだけですね。

ＳＥ試験問題

問１　システム工学
　　コンピューターを使わないシステムを５つ挙げなさい。（１０分）

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

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

問４　言語
　　略

顧客要求の分析、設計のできないＰＧと、ドッコイドッコイ。

要求は分析するものじゃなくて
定義するもの

コンサルなので通用するでしょう。
（もちろんプログラムの知識があるに越したことはないですが）
開発でも、基本設計より上流で十分役に立つはずです。
仕様が分からず、ただひたすら製造してるＰＧよりも有用でしょう。

２ＣＨで無知な学生やオタクの意見を聞いても仕方がないと思いますが。

>>155
ｶｺｲｲ！
別にPGを馬鹿にしてくれてもかまわんが
無理な納期で仕事取ってくるなよ。

>>155
同意。
というかERP知らないのならでしゃばってこなければいいのに
スレ違いのSE不要論がでてくるのはやっぱりここの板のレベルの
低さなのだろうか？
それともレベルの低い奴が沢山レベルの低いレスを繰り返しているだけ？

>>156
早速現れましたね。レベルの低いあなた（ｗ

呼んだ？

情報システム板とかこのスレ読んでると、
ERPって詐欺にしか思えないんですが、
実際はどうなんでしょうか？

SAPには何百人もの研究者がいて日夜
経営について研究を重ねているのでは
ないですか？
導入に対する弊害が日本の場合は大きいと
言われて久しいのですが、それとてもう
何年も言われていること。少しは開発元に
ノウハウが溜まってもいいころだと
思うんですが。

プログラマー版らしくないのからしいのか

通常ならばＳＥがＰＧできなくてもＯＫ
だが
最近はそういった人間には仕事がこないことが多い
とくに新しくはじめるとかになると
現在にそれなりのネットワーク（伝ともいふ）がないから
大変じゃないだろうが

こんなはずではといったかんじの再転職組は多い

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

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

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

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

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

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

Systematic〜♪
Systematic〜♪

ウォー！！！　　　　by the mad capsole market

>>162
オープンソースのERPって例えばどんあのがあるんですか？
教えてください。

探せよ（ｗ　それこそ君らの嫌いなSEやコンサルや営業などに馬鹿にされるぞ。
オプソなんて守備範囲だろ？　sourceForgeに逝って、ERPで検索しろ。

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

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

海外の連中は、ちゃんと理論体系を持っているから、実装までしたがるんだよ。
だからソフトウェアも骨太になる。経営理論とプログラミングを切り離している
時点で、日本ってのは全然負けてるって感じだな。奴らにとって経営は数学と
同レベルだ。連中は自分の理論を実践したいから、理論をプログラミングして
実現してくる。で、それを一生懸命に広めようとしてマーケティングを仕掛けてくる。
成功すれば第一人者として名声と富を得るわけだ。SEとかPGなんて狭いところで
切り分けなんてしてないよ。つか、向こうではSEとかPGなんて切り分けあんのか？
コード書くのも設計するのも出来て当然だろ。

プログラミングできないSE ∽　方程式が解けない解析数学者

もっと短くまとめられないのかよ（;´д｀）

悪いが74の文章、コピーさせてもらったよ。

おれも業務系の人間としてもっと勉強しなくては。。

>>167　スマソ。以後気をつけるよ。許してくれ。
コードも仕様も文章もシンプルに、だな。

法学部出身のヤツって文が長いよね。　スマソ

　　,,,,,,,,,,,,,∧,,∧　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′,,,,,,,ミ,,ﾟДﾟ彡＜　設計なんてコードの都合上変化する
　 UU""" U U　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
変化を抱擁するために設計する人は
開発者でなけりゃいけません。

コードがかけなくて設計が出来るわけないです。

　大手メーカがＰＧ経験なしの新人をSEにしたのは、米に対抗するための
国策（国の指示）があったからだと何かの本で読んだことがあります。

　昨今の政治家をみていても思うのですが、何でもかんでも上下に分業して
上は大まかな方針だけ示せればいいという考えが広く深く根付いているようですね。
小泉氏の発言にもまさにそれがあって（最近非難が向けられるようになりましたが）
ｶﾞｯｶｰﾘです。
ところで、こういう思想って連立方程式をしらない文系に顕著で、村上氏
などが指摘される現在の日本の教育の弱点と強く関係しているように
おもいませんか？

>>172

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

>>171
> コードがかけなくて設計が出来るわけないです。

自分の発言読み返して、赤面することはないか？

>>174
プログラムの設計とシステムの設計の
区別が付いてないんでしょう。

>>174
>>171は全然問題ないと思うが。

>>172
理系であること・文系であることで、人間の能力や資質、スキルは
割り出すことは出来ない。
すべてはあくまでも、当人のモチベーションとエクスペリエンスでしかないんだよ。

>>176
はあ？全然関係ないの？誤爆って事ね？>>171は。了解。

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

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

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

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

　つまり、何でも分離して処理できる、生産性を上げられるというのは
単純作業などからにおいてのみ帰納できる事実であって、頭脳労働である
システムの設計においてまでこれを適応するのは、無茶であり、
（理性的には常識だろうけど）
にもかかわらず、これがまかり通っているのは客観的評価が厳しい科学的な
教育や訓練が不足しているからではないのか？
　今いろんな所に露呈してるいーかげん、不正、そういったキーワードもどこかで
こういった現実と絡んできそうだが、さすがにそこまでいうと空論になるだろう。
何より、僕の知見を越えているはずだから。

要約：
設計とコーディングを職業・スキルとして分けてしまうと、
多くの重要な問題を認識・対処できなくなってしまうという話。

>>179

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

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

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

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

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

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

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

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

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

繰り返すが、君の>>179の主張には全面的に賛成だ。そして気付きをくれたことに
感謝する。ありがとう。

お前ら文章長すぎないですか？

>>182　ほんとにそうだな。何度もスマソ。飯食いに逝ってくる。

>>182　いいじゃん。お前短すぎ

コード書けなくても、
お話が通じる人だったら別にいいような。
あと、プログラマの意見をいっぱい聞いて
くれる人かなぁ。

要は既に誰かによって分けられたものにはバイアスがかかってるということ？

ﾏｱ　ｵｱﾂｲｺﾄﾃﾞ
　　,,,,,,,,,,,,,∧,,∧　　 ／理系、文系
〜′,,,,,,,ミ,,ﾟДﾟ彡＜　…日本の教育がとかいうとすぐこれだ…
　 UU""" U U　　　＼
理系でも全体の3/4はプログラミングなんて
組めないと思うけど？

ﾌﾟﾛｸﾞﾗﾑ組めないＳＥも少々問題かもしれないけど
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞしてりゃ、会話すら怠ってもよいと
思っているジジイどもも、逝ってよしかもね。


>>174、ときどき必要以上に蒼ってしまったときとか。思うぞ。
>>175、ｼｽﾃﾑの設計ってなんだかな。
　ｼｽﾃﾑｴﾝｼﾞﾆァよりあいまいな言葉じゃない?

たまにコードの書けないＳＥが紛れこんでくるね。
174=175とか。

プログラム書けなくても仕様をきちんと理解してくれていたら
別に問題ないよ。

VBやDelphiしか使えないＳＥというのもイタイよね。

きちんと、が深いと思われ…

>>188
174=175とか言っている時点でイタイと思っている俺174＆175さんがいる。
２ちゃんでその＝使う奴って、本当にいたいよ。
>>1+2+3+4+5+6+7+8+9+10=55
ってこった。

図星つかれてぶち切れですか。
ほっとけよ。

>>175
システムデザインするときにプログラムはしらなくてもできるけど、
ミドルウェアを使う場合だが、アーキテクチャは知ってる必要あると思われ。
でなければ、実装したときに、あまりに困難、または性能の悪いシステムに
しなければならないようなものになりかねないよね！
そのアーキテクチャを知ってる人間がプログラムを知らないことはまれだと思う。
そのあたりの認識の相違かと思われ。

お客とシステム仕様をきっちり詰めて文書を残す仕事ができれば問題ない。
プログラムはＰＧにまかせればよい。

しかし、全然しらんとＰＧにナメられるよ。

>>192
しかも俺のこと SE だって。
そんなインチキ臭い職業選んだ覚えはないぞ。

その、きっちりっていうのがＰＧにとって
のきっちりなら、やはりプログラミング
を知っていることが必要ということでしょう。

ＳＥがきっちり仕事できれば問題ないのだけど、ほんと、鶏と卵…

というか、連立方程式？

プログラムが出来ないまともＳＥがいるのなら見てみたい。

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

実際にはプログラムが出来ない馬鹿ＳＥか、
プログラムもできる優秀なＳＥしかいない。

あとプログラムができる馬鹿SEな

VBやDelphiでGUIプログラミングしかできないくせに、
「俺はプログラミングもできる」と言っている
SEもミジメだよな

俺はSEはプログラムができなくてもいいと思う。
プログラマなんてかわりはいくらでもいるけど、
ほんとに優秀なSEは数少ない

下手したらPGの数よりSEのほうが多い罠…

>>201
GUIプログラムのほうがむずかしいよ。

>>202
非論理的だね。

>>202
文がつながってませんが？
プログラムしなしなくても〜なら
わかるけど。

>>202
君はプログラマの質は関係ないって言いたいのか？

>>203
その通り。PGよりSEの法が多いかもしれない。
しかもSEのうち能力のあるのは一握り。
あとは年功序列にしたがってPGからSEへ名目上なったか
あるいはSEとして採用されたか。
しかも莫大な労務費を食うから、システムの値段がつりあがる。
いまにばちがあたりますぞ。高給取たちよ。

対象のＳＥよりＰＧに要求される種の
スキルが低い場合は不満は感じない
かと思います。相対的は問題でしよう。

>>209 意味不明

PGでもSEでもいいけどさ、もうちょっと論理的な文章書こうぜ。>209

あれ？このスレって４００くらいまでいってなかったっけ？
あれあれ？
別スレ？

似たようなスレが乱立してるからナ。

コンピュータに出来る事と出来ないことがある。
システムに出来ることと出来ないことがある。

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

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

・自分の適性はプログラマ向きじゃないから組まない
・しこしこコーディングしたりデバッグしたりするのはめんどい
ってのは、「組めない」んじゃなくて「組まない」ってことだよね？

ＰＧであるあなたが〜２０９〜な問題でしょう。

>>210-211
ようわからん。

>>209は
「PGが不満に感じるのは、SEが自分よりも高いスキルをPGに要求してる時」
だって意味じゃないの？？？ちょっと意味を狭くしてしまったけど。

>214 それはきわどいけど、
現にＰG経験がなければ「組めない」です。
でないと、めんどくさい、の先に何があるかわからないでしょ？
めんどくさい、と実質不可能の違いわかる？工期も検討付く？回避策を提案できる？

>>217
そういう無能が辞めればみんな幸せ。

>>216
漏れも>>209の書いてることがｻﾊﾟｰﾘ理解できん！

面倒なのはみんな面倒なのだけど、
それを克服するのがスキルだと思ふ。
感性の話はわからないけど、
デバッグにしてもバグの出そうなところとか
わかればデバッグの方針も決まるし、
発見も早い。
ＳＥが理解してれば設計で回避もできて
バグも少なく納期も早いかと…。

--
XP は、顧客の定義とプログラマの実装という、サークルオブライフが大事なのだ。
そのサークルを壊してはならない。
--

ここのスレッドのいう SE というのは、サークルを壊してしまうもののように思う。

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

これは仕事をする上での心構えとして
最悪のものだと思う。

しかし、元バリバリのデキるプログラマがＳＥになられるのも困り物。
奴、自分が現役の感覚ですんごい短い線表引いてくれやがる。

>>223
あそれ分かる！
キャパシティが狭い人だと悲惨だよね。

>>223
ﾜﾗﾀ！
同じ経験ありだよ。その人なら出来る工数で計算されてもねぇ。
周りがじぇんじぇんついて来れず、当然火だるまになって大変だたYO!

実際、そういうのもったいないね

>>223
うちは元バリバリの厨房プログラマがSヨだから結構幸せ。





工数の面だけﾀﾞｶﾅｰ

>>225
元一流選手が監督になると、しばらく、
「なぜ出来ないんだ？」と怒るらしい。
王や長島や星野や山本にこういわれて、反論できる選手はいないだろう。

>>228
そういえばダイエーのピッチングコーチやってた
村田兆次が現役選手より速い球投げて、自信なくした
ピッチャーがいたとかいなかったとか、そんな話あったねｗ。

うちの会社のSEはひどい。OSの最新バージョンが出たりすると、勝手に最新
バージョンをインストールしたりして、ソフトをあぼーんさせてお客さんの
お怒りを買っている。よく今まで首にならなかったものだ。
こういうSE（System Experiment）ってみんなの会社にもいない？

>>230
漏れんとこにはいないな。
なにせ指定OS（Win95・98）以外いれると必ずバグルから無理だろ。（ｗ

こんな時間に書きこんでしまうのも何ですけど・・・

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

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

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

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

あとはいかにユーザーのイメージ通りに作り上げるかですね。
たとえ素晴らしいシステムでなくても、ユーザーが自分で望んだものであれば
納得してもらえます。ただ、コンサルと称してユーザーに押し付けるやり方を
してしまい、もしユーザーが気に入らなかった時は最悪な事になります。
※最近かなりこの業界はゴタゴタしてます・・・

>232
あぁそれで今日も胃が痛い思いをしてきたヨ。
ていうか、最近、「もう大手には頼みたくない」って話、多くねぇ？

>>233
大手のSEは激ヤバですね・・・
特に若い人とスキルの無い中年の組み合わせが最悪

洩れもそんなに事例知ってるわけじゃないけどさ、
ネットバブルの頃の（金額が）デカいシステムのリプレースの時期で、
そんなにコストもかけられないし、大手はもうイヤ、ってとこ多い。

大手だと、営業とかが壁作ってクライアントと実装者（設計者）が隔絶されるよね。
それも「ゴタゴタしてる」原因の一つだと思うにょ。
大手のSEは組織に守られてるからな。いろんな意味で。

つまり俺の時代だ、と。

そんなにキャパないけどね（ｗ

サーバを立てるなんて誰でも出来ますよ？　正直・・・。

>>237
いや、大手は本気で組織に守られてますよね・・・
んで散々荒らした後にとんずらします。

残ってケツ引くのは下請けの中小企業がほとんど

>>238
いや・・・プログラマで自分でサーバ立ててる人をあまり見たこと無いよ
apacheなんてwin版でてるから、簡単にWebサーバあたりなら立てられる
のに、いやいいよって断られるし。
そもそもTCP/IPを分かってない人が多いのにビックリです。

って、マジレスは駄目ですか？

ああ・・・いやって否定形使いすぎだな・・・
日本語に難があるので寝ることにします。ｽﾚ汚しｽﾏｿ

まぁ「サーバを立てる」ってのは最初の一歩なわけでさ。
できて当然だとは思うな。

>240
最近でもそういうモンなんすかね？
オイラはもともとWebアプリケーション関連から入ったので、
そこらへんは結構やってるんだけど(運用とかもやったたし)。

おいおい、systemとprogramの単語くらい英英辞典で調べろよ。
何だ何だ、設計って単語の意味もわかんねぇ奴いるし。
ついでに曖昧って単語も引いておけ。何だ連立方程式って。
システマティック？笑っちゃうよな。英語コンプか？　コンプて何？
ねぇねぇ。つぅか、こんなレスで>>1は満足しているのか？　ERP？それが何？　おいおい
熱血すりゃみんなダンマリかよ（藁藁　つぅか、ここのスレ悲しいくらいに
馬鹿の長文に優しいな。。理系の漏れは小泉以上に首相の資格アリか？おめでてぇな。
お前らPG,SE言いたいだけちゃうんかと。オプソのERP知ってるくらいでそんなに
いうか？　かこいいね。つぅか、このスレhttp://pc.2ch.net/test/read.cgi/prog/1015165917/に
負けてるんちゃうんか？　>>1よもっと頑張れや。

>>243誤爆？

>>243　藁藁が痛いな（藁藁

プログラマ兼SEが機能外要求定義するとだいたい無難なところに
落ち着く。これは不勉強なSEでもそうなるものだけどね。
それで上手くいくことがままあるから、選択の
ためだけに勉強する人はすくないんじゃないかな？
でもこんなんだから必要のないところでOracleなんて
導入したりして、オラクル社は、、（以下省略

ネットワークの知識が少ないのは同意。耳の痛い話です。

>244なんで？

>>264 それってOracleの問題か？　ﾑﾉｰなSEの問題だと思うが？

>>248

予言？

>>232

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

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

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

ま、数年後には顧客も、自分がちゃんとビジネス価値を策定できないとダメなんだということが、分かってくるとは思うんだけど・・・。）

プログラムが組めないＳＥが設計すんな！
構造化設計？オブジェクト設計？プロセス中心？データ中心？
いいえ。抽象的設計です。

>>240
>そもそもTCP/IPを分かってない人が多いのにビックリです。

俺、ネットワーク屋なんだけどさ、うちの現場ではWAN超えでWinodowsネットワーク
を使うプログラマが意外と多いのに驚いた。
コマンドでいうと、 copy \\%computername\〜〜の類ね。
ネットワーク屋はWAN越えの場合は普通はftpを使うのだけどね。
この辺の両者の意識の違いに未だ躊躇している･･･。
起き抜けで脳味噌寝てるので駄文スマソ。

>>178
> ｼｽﾃﾑの設計ってなんだかな。
> ｼｽﾃﾑｴﾝｼﾞﾆァよりあいまいな言葉じゃない?

その通りだと思う。

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

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

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


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

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

会社によっても人によってもバラバラ。この SE という言葉をどうにかできないだろうか。

SE と呼ばれている人をけなすわけじゃなくて、両方の設計も分かっている人は、もしいるならそれはそれでいいと思うし・・・。

重要なのは「何の責任を持ってるのか」ということを一人一人チームの中で決めておくことだと思う。

>>253
>ここでいう設計というのは、プログラマがどう求められている機能を実装するか
>、という設計だよね。
個人的にはこの部分はPGの領域にすべきだと思う。
そうしないといつまでたってもコーダとしか呼ばれない。
そのためには、サーバの立ちあげやDB/ネットワークの知識は避けて
通れないと思う。

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

ちゃんとコンセプトを持って仕様を考えてくれればその後の実装は自分でやる
んだけどなぁ。いつもSEが持ってくるのは顧客のメモ書（以下愚痴）

自分はまったくのSEで、今もちょうど新業務プロセスはどうあるべきか、などといった仕様書を書いる最中ですが、今のリーダに文句言われてSEに２種類あることが、わかりました。
リーダのやり方:
それまでの話をまとめて、その工程の仕様書（報告書）を作る。
自分:
それまでの話を元に、その工程の仕様書（定義書・設計書）を作る。

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

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

ハードの設計図面は、次の工程で実物を作る為のもの、
ソフトの設計書は、次の工程でプログラを作るためのもの、と思っていた自分は
今までSEとして失格だったようです。
自分はSEとはシステムを作る人だと思ってましたが、書記及び文書構成屋だったんですね。
10年間何してたんだろう?浅はかだった。

>256
Sﾖ単価が地盤沈下してる時代に、話を纏めるだけの人はヤヴァくない？
それに、顧客の方も知識ついちゃって、話を纏める人をエンジニアと呼ばないよ。

>>252
それはただ単にWin房の集まりだからでしょ。

す、すみません。
ネットワークなプログラマですが、WAN越えでSamba使ってます。

べ、便利なんですもの…。

>>256
書記・文書構成屋ていうのは、なかなか難しいごとだぞ

ゼロサムゲーム業界ってのは、誰か一人が単価下げて受注をはじめる。
それに対抗して他社も単価切り下げてくから、どんどんデフレスパイラルに落ち込む。
理系のくせにこんな理屈もわからないから、どんどん品質低下に進むんだね。
正直、有能な人は、人の仕事の請け負いやめて、自分で価値を創造した方がいいと思う。

理系・文系論争なんてこのスレではやってませんが。
誤読者多発みたいですな。

>>252
どっちだって大差ねえよ。

>>262
君は、理系の部分の軽い、ただの煽りにとらわれて、本質が読めないようだね。

学力がらみだと、最近、読解力が落ちてるってニュース聞いたけど、
あれの正体は話を最後まで聞かない奴だと思うな。
客先も職場も、国会もＴＶ討論もフライングばっかりだよな。

と、話を教育に振ってみる（藁

このスレも、もうつまらん。サゲ！！！！！

>>265
それって、話を聞かない奴が多くなったってこと？
結果としては、毒か威力落ちてると、一緒だよね。
で、そうだとして、
話を最後まで聞かない奴が多くなったのは何故？
テレビだけでんく、ゲーム機や、ミュージックプレーヤーなども
手軽に入るようになったためか？

マクルーハンが言うところの「ホットなメディア」の影響じゃない？


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

ｲｯﾃﾐﾀｶｯﾀﾝﾀﾞﾖｰ

>>267
君みたいに、誤字脱字に無頓着になった人が増えたからじゃないの？

分かんないけど、気が短くなってるって傾向はいろんなニュースや
統計や日常から感じるな。　深く考える時間や習慣が無くなった
からってのが一つにはあるかもな。
　プログラマはその点恵まれた職業なのかもしれないけど、

>深く考える時間や習慣が無くなった
やっぱり、そうでもないかも。
哲学書が売れるようになったって聞いた。特にバブル以降。
でも本を読む時間が増えたってニュースは聞かないな。
よくある二極化だろうか。

世の中全般的に逝き急いでる気がするね。
なんつーか、今日明日の糧を得るのでイッパイイッパイというか。

>>271
ソフィーのなんとかの影響じゃない？
小林よしのりの影響で右よりになる厨房が
沢山いるってことと同じようなもんでしょ。

　就職活動真っ盛り青二才です。

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

　普通に疑問です。PM候補ばっかり取って誰が実際にモノを作るんですか？
長年第一線でPGをしていけるような人材が欲しいという話はどこの説明会でも
聞きませんでした。作ったものを最高品質で、みたいな話もです。

>>274
> 誰が実際にモノを作るんですか？
下請けの日本人、中国人、インド人、ロシア人などなど。

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

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

下流工程の品質は上流工程の品質が高ければどうにかなるもんなんだよぉぉ

>275
ならんだろ。

>276
なる。

最悪、品質の悪い部分だけ別の奴に作り直しさせればいいんだよぉ。

>275
ならんね。
品質の悪い部分をカバーする為のコードがあちこち入ってきてるんじゃないかな。
システムってものは、それを構成するコンポーネントのなかで一番できの悪い部分に引きずられるもんだよ。

少なくとも、上流工程がクソだと下流でどうあがいても
どうしようもないって事は確かだと思われ。

上流がよければいいんだけどね。全部とはいわんが実際は上流がクソで苦しめられてる。
下流が全力を出せないのよ。むしろ押さえつけられてる。
それで品質が下がっているのを下流のせいにされたらたまらない。
せめて下流が力を出せる程度に技術力をつけてほしい。

その基礎技術の重要なものの一つがプログラミング能力なんだが、
これを軽視しているからいつまでたっても技術力がついてないんだよね。
他にもやらんといかんことはあるだろうが、それだけ金をもらってるんだ。
手抜きせずにやれ。

分かった。今必要なのは「開発作業そのものの」コンサルタントだ。
本来は不必要なものだが、今の開発組織形態ってのはクソすぎる。
組織再編して要らない人材を切ってくれれば、効率よく開発できるようになり、
結果的には業界盛り上がってみんなハッピーだ。

（めちゃめちゃ話分かりづらくなってるな。XP の組織みたくシンプルにならん
だろうか）

SEがテスターになればいいのさ。
かれらが気取って仕事してる以上は
どうにもならないのさ。

上流が良いとか悪いとか切り分けて考えれる＝ウォータフォール
だよ。
スパイラルなら、また上流と言われる工程にフィードバックされる。
Sﾖが要ると、Sﾖを養うために上流と下流を切り分けなきゃならんのだよね。
ﾌﾟﾛｸﾞﾗﾏだけにしときゃ、ここで上流とか下流とか言われてる工程を両方とも出来るから、
スパイラル出来るＹＯ！

>システムってものは、それを構成するコンポーネントのなかで
>一番できの悪い部分に引きずられるもんだよ。
これにははげどう。
だけど、その一番出来の悪いコンポーネントを簡単に切り離す事
ができるようにするのが上流工程に腕の見せ所ではないかい？
従ってオレは「なる」に一票。

>284
なわけねーだろ。
コンポーネントが良いか悪いか、や、切離す作業はコード上で行われる。

個人的にゃ、上流とか下流とかの境界がだんだん薄れているような気がする。
なんつうか、コンポーネントの切り分けにしても、
プログラマーとしての能力をもった人間の役割ではないかと思う今日このごろ。

上流だの、下流だの、そんな曖昧なことやってたんじゃダメだよなぁ。

何が上流で何か下流なのか、それぞれどんな責任があるのか。ちっともはっきりしない。責任を曖昧にするシステムがしっかりと出来上がっちゃってるんだよね。

>>287
それはあんたのとこだけ。

上流は下流の切り分けは、半端な人間がそこそこの仕事をするためにあるのさ。

個人的には上流、下流というのに分けられるのか疑問だけど、
デザインパターンのようなものは上流、下流のどっちに含まれると思う？

　　,,,,,,,,,,,,,∧,,∧　
〜′,,,,,,,ミ,,ﾟДﾟ彡
　 UU""" U U　　　

＿＿＿＿∧＿＿＿＿＿＿＿

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

自分で言った言葉の意味がわからなって
自分で首をしめるなよっトナー

　　 ∧,,∧　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ミ,,ﾟДﾟ彡　＜　日本は情報産業後進国だと思われ
　　 U　　つ∀　＼＿＿＿＿＿＿＿＿＿＿＿＿
　〜ﾐ　　ﾐ　┴
　　 ∪''∪　
>>274さん
金に目がくらんでる経営者ばかりだから
口八丁のﾔｼを
ジオンのザクみたいに
量産したいんでしょうね。

良質のﾌﾟﾛﾏﾈになるためには
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ経験は必要じゃないかな。
そういう経験がなかったら
ﾌﾟﾛｼﾞｪｸﾄﾒﾝﾊﾞを引っ張っていくのは
実に難しくなると思うの。

>>258
どうやら、Win房の集まりのようです。コマンドを使えない人がたくさんいました。

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

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

このところこの件でネットワークチームとプログラムその他チームの喧嘩が絶えません（泣

　みなさんいろいろありがとうございます。

就活真っ盛り青二才です

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

　また、どこのSI系の説明会も似たようなモノなので、
学生らもすり込まれているらしく
「ソリューションが…、フレキシブルに…、ERPを活用して…」
等、上っ面にしか見えない会話ばかりされます。
なんだろコイツラ？という気分になってきます。

そーゆー実態がよくわかんない言葉で客を騙す商売なんだから
社員もだまされとかなきゃ精神もたんっちゅうねんな

PGはなにか泥臭い実装の細部を扱う人って
イメージなんじゃないかな。ものを売るために
そういったものを避ける必要があるならそれは
構わないんだけど、なんかそうでもないような。

　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　|　T字型人間を目指せとかいわれちゃったりして
　＼＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　|/
　　∧,,∧
　　ミ,,ﾟДﾟﾐy━~~
　　 U　　 ﾐ
　〜ﾐ　 　ﾐ
　　　Ｕ''Ｕ

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


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

大手は出来の悪いSEの頭数をそろえて
ｼｽﾃﾑの作成工数を見積もって
お金をｶﾞｯﾎﾟｶﾞｯﾎﾟ収集するようになってるんじゃないかしら。

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


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

自分のキャリアプランを考えてｼｽﾃﾑ開発したいなら
俺なら、営業配属になったら即転職だね。
回り道をするほど人生は長くなくてよ。

　　 ∧,,∧　　　 ／￣
　　ミ,,ﾟДﾟ彡　＜　　で、誤解の亡きようにいいますが
　　(ﾐ　　ミ)　　　＼＿
　〜ﾐ　　ﾐ
　　 ∪''∪

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

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

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

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

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

開発わかってないと、営業的能力で仕事を補う
必要が出てくるんだけど、こっちの方が相当つらいかも。

オレは10年ずっとプログラマやってたんだけど、

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

みたいな会話が普通に話される職場なんて一度も見た
ことがないドキュソだ。で、こういうのって
本当にあるの？
Tec-Bingなんかでは、SIだのIT、ソリューション、
なんて言葉はよく見るけど、転職希望者に夢を見させる
ための煽り言葉だとずっと思ってた。
いったい、そういう職場ではどんなふうに仕事が進められてるんだ？
本当にこういう世界で仕事してるひと、どんなことしてるんだ？

>>299
狭い世界から出てきなさい

>>299
技術的な仕事は全部下請けor社内の他部署にまわして
技術者と営業の中間みたいなことをいしている人達がそういう
会話をしている。といってみるテスト

>>299
客にニーズがあってから初めて仕事をもらうんじゃなくて、
経営戦略がどうとか、適当に話ぶち上げて仕事をもぎとるような
商売してるところは大手の殆どかと。
ある意味かれらがそうやって仕事をとっているから、景気が悪いのに
この業界仕事があるのかも。

特に「コンサルタント」を自称される方々は、
クライアントにウケる美辞麗句を並べ立てるために、
そういう会話をしがちですな。

SEは文書構成屋だ、って書いた人がいて、それには激しく同意
するんだけど、結局、CTCやNRIってその文書さえも自分では
書かずに下請けに書かせてるんだろうか？
下流の下っ端でしかないオレからみると、まるで実体のない
ものなんだが。

　　 ∧,,∧　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ミ,,ﾟДﾟ彡　＜　ｽｰﾂ着て、会議ばっかりしてんちゃう？
　　|⊃▽|⊃　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　〜|　◇| ←┐
　　 ∪''∪　　.└ﾈｸﾀ-ｲのﾂﾓ-ﾘ

>>304
SEが下流を自認するところがｲﾀｲ。
好きにすれば。

>経営戦略がどうとか、適当に話ぶち上げて仕事をもぎとるような
>商売してるところは大手の殆どかと。

で、それで上手くいってるのかな？
適当に話をぶち上げといて、実際にそれだけのシステムが
できて、顧客が大満足したらいんだけど、10年この業界で
仕事してるオレからみると、そういう例はとても少なそう
なんだけど、どうよ？
下請けでも、元請けでもいいけど、一番大事なところに
いるやつ1人がダメなだけで失敗したプロジェクトは結構
見てきたぞ。

>>307
10年やっててそれかよ。ﾀﾞｾｰ
ダメなヤツ一人で失敗するのはリーダが無能だからだろ。
あった瞬間に見抜けよ。

>>306
オレはSEじゃなくて、プログラマだって299で書いてるじゃん。
とは言え、この4,5年は上流も下流もない、スパイラルの真ん中
くらいで仕事してる立場なんだが。

>>299
俺はむしろ、そーゆー会話の方が莫迦臭いと感じるけどな。
まぁ素人騙してナンボの商売だから、それでいいのかもしれないけど。

そーゆー会話って？

>>308
あった瞬間は見抜けないなあ。

>>307
>で、それで上手くいってるのかな？

ｶﾝｶﾞｴﾙ ﾎﾄﾞﾆ ﾀﾞﾂﾘｮｸ
　　　∧,,∧　 　　 ／キャツラは
　　 ミ,,ﾟДﾟ彡　 ＜　いいものを作ったかどうかでお金を取るのではなく
　　 ﾐU　 U　　　　＼どれだけ人が動いたかでお金を取りますな。
　〜ﾐ　,,　ﾐ
　　 ∪ ∪　
　　　　　汎用機で作った出来の悪いシステムを
　　　　　数年かけてPCで動くような出来の悪いｼｽﾃﾑにして
　　　　　それをブラウザで動くような出来の悪いｼｽﾃﾑにして…

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

これって、うまく・・・逝ってる？

>>313
納得。

>「ソリューションが…、フレキシブルに…、ERPを活用して…」
あなたがた意味判って言ってるですかバカヤロ！みたいな。

>>315
了解。
だいたい、オレはITって言葉が嫌い。
あと2,3年のうちに陳腐な言葉の代表になるぞ、絶対。
今だと、「マルチメディア」とか「情報化革命」みたいな。

　貴重なご意見どうもです。

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

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

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

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

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

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

　…スレ違いですみませんです。

　　 ∧,,∧　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ミ,,ﾟДﾟ彡　＜　実を言いますと…
　　 U　　つ∀　＼＿＿＿＿＿＿＿＿＿＿＿＿
　〜ﾐ　　ﾐ　┴
　　 ∪''∪　ＭｉｄＮｉｇｈｔはワインでも

実は、NRIは友達がお勤めになって
ｱﾎﾞｰﾝ転職したので知ってるんですが
CTCってのはなんちゅう会社ですか？

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

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

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

そんなフサも、ITって名のつく部署にお勤めで....
大丈夫か？>>ミﾟｗﾟ,,彡

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

適当に会社絞った後は
残業時間とか年収とか
ｵﾈｰﾁｬﾝがｲﾊﾟｰｲとかの労働条件
ましそうな所でﾃｷﾄでいいんじゃない？
あと、技術者キボンなのに営業配属とかされない会社とか。

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

会社にほれ込みすぎて、理想と違って後悔せんよに。
1つの職場がダメだったらどこでも次はあるんですから
会社も仕事もあっさり変えられるような
柔軟な人材を世の中は求めてるんじゃない？
＼
　 ￣￣￣￣　Ο　￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　ο
　　　　　　　ﾟ
　　　　∧,,∧　 　　　　ｵﾔｽｰﾐ
|￣￣ミ,,-Д-ミ￣|　　
|＼⌒⌒⌒⌒⌒⌒＼
|　 ＼ 　　　　　 　 　 ＼ 　
＼　 ｜⌒⌒⌒⌒⌒⌒｜
　 ＼ |＿＿＿＿＿＿＿|

>317
ていうか、大手の方がそういう点ではいい加減だよ。
どんなクソSE・PGも組織の看板に守られてるからね。
SEはいい加減なことをくっちゃべり、
PGはいい加減な実装をしてくる。
で、クライアントはブチ切れ。

そういう意味では、大手よりは中小の方がしっかりしてるヒトは
多いと思われ。
中小だと、本当に少人数でヒアリングから実装まで全部担当するからね。
ゴマカシが効かない。

特にメーカー系列SIのSE/PGはほとんどクソです。断言してもいい。

>CTCってのはなんちゅう会社ですか？
伊○忠テクノサイエンス
名前が示すとおり、某商社系のシステム会社。
親会社が商社だけにプレゼン「は」うまいよ〜ん。

>1のかた
もう転職されたんですか。もしされたなら、その後を聞かせてください。

要求定義のできないSE逝ってよし。
これは能力の問題じゃなくて、度胸がないせい。
いつまでもつまらない細部で会議ばっかやってる
せいか頭がいかれてるものと思われます。

>要求定義のできない

これは、Sﾖとか、そういう問題じゃないよ。
どんなアウトプットにもその前に要求定義があるんだから、
この人は開発に関係する仕事はマズイんじゃない？

>324
いや、そいつが度胸あっても困ると思うぞ。
「わかりました!!ここはもう思い切って全件削除しましょう!!」
とかあっさり決められた日にゃぁ...

スキルがあるという前提があれば度胸を持ってくれて構わんが。

度胸つうか責任だな

　

漏れ、理系・文系・上流・下流・SE・PGとかよりも、体育会系・文化系の
違いっぽいのを感じることの方が多い気がするんだが、お前らどぉよ？
漏れだけかなー？　文系の体育会系とか理系の文化系とかあったりして
何となく体育会系が来ちゃうと「やべ」とかさ（ｗ　特に営業とかプロマネとかに
そういうのがいると、話が全然かみ合わないとか。漏れは無気力のヒッキー
文化系だけどさ（藁　気合とか根性とか、およそシステム作るのにかみ合わない
キーワードが大前提に来ちゃうと引くんだよ、漏れ。

　　　∧,,∧　 　　 ／ｲﾄﾁｭｳ系か…
　　 ミ；ﾟДﾟ彡　 ＜　
　　 ﾐU　 U　　　　＼数ヶ月前、ｲﾄ厨系のｲﾝﾌｫｱﾍﾞﾆｳってトコ
　〜ﾐ　,,　ﾐ 　　　　　面接ったYO．．．．
　　 ∪ ∪
　残業氏ぬほど多いって豪語してた
　んでパスったけど。

http://mentai.2ch.net/test/read.cgi/infosys/996345793/
良スレなので紹介&あげ

>>1
俺？？

>>1
悪いことは言わんから「コンサル＝営業支援者」程度で我慢しとけ！
設計者を目指すのならＣＯＢＯＬ系に限定して精進しろや、それならば
言語等知らなくてもお手本は幾らでもありサポートもしっかりしてるから
何とかなるだろう。
だが、オープン系の設計者を目指すのなら使われる材料の性質や特徴を熟知する
必要があり難しいと言える。

# もし君が設計者としての武器を会計知識に限定するのならば営業支援者としての
# 技量しか持ち合わせていないことを理解してくだされ。

>>333よ過去ログ読めや。R/3担当って言ぅとるがな。>>1はどないしとるんや？

呼びました？
話がそれてるようなので静かにしてました。

332は俺じゃないよ。

出張32は放置するべし。相手にする価値は無い。

出張32は情シス板へ帰れ

　 　 　 　我等極悪非道のageブラザーズ！
　 　 　 　ネタもないのにageてやろう！
　　　　　くっくっく…
　 　 　 　￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 ∧＿∧ 　 ∧＿∧ 　　age
　 　 　 　（・∀・∩）（∩・∀・）　　　　age
　 　 　 　（つ　　丿 （ 　　⊂）　age
　 　 　 　 （　ヽノ　　 ヽ/　　）　　　age
　 　 　 　 し（＿）　　 （＿）Ｊ

なんだかんだいっても、人月でいえば

クソSE＞敏腕PG

なんだよなー。鬱だ。

ごちゃごちゃほざいていても、所詮はPGはPG。ピーピー叫くのが精一杯です。
コードなんか書けなくても工程管理と仕様固めができればSEはいいのです。
道具とソレを使う人との関係といえばわかりがいいでしょうか？

SEは道具

PGは、使い捨て

>>342　すぐ痛むしな（ﾜﾗ

>>340
コードがかけないのに工程管理とか仕様とかできるSEってのが
ようわからん。つうか、客先にいってシステムの概要を聞いて
いる段階で、「ここはこんな感じのコードになるなー」とか
「あー、コードは簡単だろうけど、ボリュームきつー」とか
自分がプログラミングするときの感覚で話をすすめるのだが・・・

そうでないSEは、どういう思考回路なんだ？？？？？

>>344
一日が24時間だから、工数は3倍までの余裕があると考えている。

>>344　細かいことはいいのよ。PGの表情でだいたい大変さは分かるからさ。
それに俺がいってる書けないってのは、製品として納めるようなコードは
書けないと言うか、書ける必要がないってことね。
そういうみみっちい仕事はPGのやることだろ？
まあ、PGどもは生かさず殺さずということで、ﾏﾀｰﾘといきましょうや。

>>344
あまりそんな奴いないと思うけど
既成概念がない分新しいものができると思う、プログラミングもできて設計も
既成概念にとらわれなければ一人前のSEだけどねと思う

コードが書けないSEの言っていることに根拠は無い。

>>348　コードが書けてもPGとは限らないというwana

ＰＧ＝まじめなひと
ＳＥ＝うそを言う人
コードによって定義されない　>>ALL

一番むかつくのは、コードを書いていたけど忘れたSE。
自分の誤った方法論を押し付ける。
･･･屑だ。

SEがしたいからSEになるというならましだが、
PGが出来ないからSEになると言う奴にはろくな奴はいないな。
あと、俺はPGが出来ないからと断言する奴とか
自分がPG出来ないのにPGを馬鹿にする奴とかもダメだな。

SEの人ってどんなことを勉強しているのですか？
単に仕事をこなしていれば立派なSEになれますか？

>>353　２、３人PGをポンコツにしないと立派なSEにはなれません。
コレホント。

スクラムが組めないFWってどう思います？

>>354
それだけで立派なSEになれるのか？ 簡単そうだな。

>>352
同感。プログラムを組まないSEと組めないSEでは大違い。