業務屋はＳＥを名乗るべからず

まじ迷惑なんだよお前らみたいなのが
技術のぎの字もしらねーのになにがＳＥだ
技術の分るＳＥが見たらお前らの作ってる物が糞だってことぐらい簡単に分るんだぞ
お前らの作ってるドキュメントなんていまどき営業職のやつらだって書ける程度のもんだ
わかってんのか？

とにかく業務屋は死にやがれ

ドキュンメントしか書けない>>1さんもどうぞお死にになって下さいませ。

ピュアなＳＥって、土方？

１の言う「業務屋」って言葉の定義を説明しておくれ。
どうもウチの職場で使われてる「業務屋」とは意味が違うようだ。
会社ごとに用語の意味合いが微妙に違うのはよくあることだけれど。

そうそう、
あっちの会社では八百屋さんだったのが、こっちの会社では
お肉屋さんだったりする。

>>1
いいたいことは、わからないでもない。
お客にその辺をじわじわアピールしてこうよ。

営業から言わせて貰えば、
技術を知らない業務屋ＳＥの方が、
業務を知らない技術屋ＳＥより商売になるのだが・・・
いくら、超最新技術で、すばらしい作りになっていても、
高くて、客の望みにあってなかったら売れんからなあ。

※１ではないです。

>客の望みにあってなかったら

君ラってさ、処理の効率化よりコードのコピペじゃん。
君ラってさ、ディストリビューションもユーザビリティも
　　　　　　無視の寄せ集めでSIじゃん。

毎回毎回著しい処理性能の悪化で客の望みを打ち砕くのも
業務至上主義SE（と言い換えさせてもらう）の得意技だね。
別にそれもひとつの生き方だから否定したりはしないけどさ。
技術にこだわる人間は当社には必要ないなんて真顔でいってると
そのうち会社傾くよ。わかってる？

１ではないが心当たりがあるので定義させてもらうと

1)客の要望や問題とシステム化の接点（妥協点）をバランスよく
　構成するのが本来求められる通常のSE。やぱこうでなくちゃ。

2)客の要望や問題解決よりも自分の興味を優先するのが技術偏重SE。
　業務至上主義SEとは常に犬猿の仲。ところで会社PCの壁紙に
　恥ずかしげもなくでじこを貼るのはやめなさい。　

3)客と一緒になって自社のSEや外注プログラマに無理難題をいうのが
　業務至上主義SE。おまえはどっち側の人間だ？

4)Excelで線表引いて、会議で進捗遅れの責任が誰に
　あるのかを明らかにすることしかしないのがPM。あんたそれだけで
　モノができるなら誰も苦労せんて。

>>8
客を、その気にさせるだけで、
売ったらおしまいという考えの人達に何を言ってもね。
それに、うちの年収１０００万以上の営業さんは、
みんなわかってるから安心して！！

客としては、3)のSEは嬉しい

>>11
その通り。それ故に始末におえない。
自分は客の評判がすこぶるいいって思うわけ。
そりゃなんでも言うこと聞いてりゃそうなるさ。
で、こいつらの定番はそのままユーザ企業に転職しちゃう事。
昔のコネクションで古巣にはでかい面。いい迷惑だよ。

>>12
さすがに、ウチの会社はそういうやつを採用する気はない

＞昔のコネクションで古巣にはでかい面。

俺のことだと思った奴がいっぱいいるだろ。
そういうのを心の琴線っていうんだぜ。

業務屋にしろ技術屋にしろ
稼げるＳＥにならないと。
＞こいつらの定番はそのままユーザ企業に転職しちゃう事。
＞昔のコネクションで古巣にはでかい面。
ユーザ企業の情シスしかも中途なんて会社の主流じゃないんで
長い目でみたら面白くないんじゃないの。

>>15
コネクションが腐った時点で一巻の終わり　チョンチョン☆
なんよね

このご時世、人事リフレッシュが多いから要注意だよそういう人は

９さんの書き込みの４）に爆笑。

>>14
>そういうのを心の琴線っていうんだぜ。
さすがにそれは日本語としては違うと思う。

age

4)をだれもやらないプロジェクトに参加しています。
あちこちに地雷が埋設してあるような地獄のプロジェクトに
なっています。
4)は必要悪でしょう。

メーカのSEは業務屋だよな。
来年から鬱だな。
技術やりたかったから、小さいソフト会社に行くべきだったのかな？

メーカのSEでも、例えば科学技術系なら、
要求される内容がちと違うかモナー

将来性のあるなしは、この際目をつぶるとして(爆

誰かメーカのSEいないの？
IとかNとかFとかHとかさぁ
メーカSEの実態が知りたいよ

>>8
オマエ、逝ってよしネ。
しょせん、システムなんて、業務のための道具だよ。
それをワカラネ奴は、どっかのDQN F社にでも行けば。

>>24
道具でないシステムって存在するのか？ (笑
このスレは実務経験の無い人が結構カキコしてるようだね。

君達の考える「ＤＱＮでないシステム」を具体的に書いてみてよ。

# アドバイスはそれを見てからね♪

>>25
あのな、「システム」の話じゃないだろ。
これだから技術屋は（藁

>>25
あんたってさあ、スレの趣旨とか文脈を全然無視して、自分の言いたいこと言うのが
スタイルみたいね。
漏れは、>>8みたいな、業務を無視したセリフが気にいらなくて、あえてカキコしているだけだよ。


＜このスレは実務経験の無い人が結構カキコしてるようだね。
何を根拠に判断しているのか、論拠を示して欲しいものだね。

>>26
うん、違うね。

>>27
> あんたってさあ、スレの趣旨とか文脈を全然無視して、自分の言いたいこと言うのが
> スタイルみたいね。

そうそう、だしに使って悪かったね。

> 漏れは、>>8みたいな、業務を無視したセリフが気にいらなくて、あえてカキコしているだけだよ。

判ってるよ。

(・∀・) >>23は業界外の煽らーっぼいね(藁

>>28
なんと、しおらしい
（煽りじゃないぜ）
レスサンクス！

業務家だけど何か？

業務屋 サンクス！

おれはやらんよ。
単価安いし。

半人前は「業務生」と名乗ることにしたら？

>>32
誰の単価が安いの？

メーカＳＥは業務しらないよ。
担当するユーザにもよるけど・・
メーカＳＥは大企業相手が主だから、「今年は経費のシステムの改修」「ユーザ子会社のホテルの予約システムやってね」
「設備管理システムの改修ね！」「Notesもやんなきゃ・・」「ユーザ子会社
の研究用実験データ管理システムつくってね」
と何でもかんでもやらされる。
業務を覚えるまないよ

このスレが混乱した一番の理由。

「指示通りに作業するだけの人」＝「業務屋」と考えてる１に落ち度あり！

# 用語の意味意図が人により大きく異なる典型例ですな。

業務に強いＳＥは必要だろ。
コーダーがいきがっても、なにを作るかを決まらんとやくにたたんだろ。

ただ、業務だけ、技術だけ、っていうのは極端だな。
新入りは技術屋から入って、客と折衝したりしながら業務屋の色が濃くなって
いく、っていうのがうちの一般的なパスだが。

>>３６
あんたがいるからだよ。

>>37
まあ、両方こなせて一人前でしょうな。
オープン系に移った為にこれまで有していた技術が使えなくなり場違いな設計を
しているＳＥが巷に溢れていることを思えば当然と言えるね。

>>38
幼稚な反応は願い下げなんだけどね♪
1-24迄で既に混乱しまくってるけど如何説明するつもりだい？(笑

# お子様が口を挟むのはダメですよ。

>>36

＞＞「指示通りに作業するだけの人」＝「業務屋」と考えてる１に落ち度あり！

＞＞# 用語の意味意図が人により大きく異なる典型例ですな。

まとめたつもり？
ｱﾀﾏﾜﾙｲﾉｶｺﾜﾙｲ

あっと言う間にクソスレ化させる能力に感服。

>>40
うん、まとめたつもりだよ♪
1の言うところの「技術なし」で「業務知識あり」の人って顧客になってしまうからね。
顧客の「業務知識あり」はコンピュータによるシステム化を前提にしたものではないから
結局のところそんなお人が居るとするのならば「顧客の指示した通りに作業をするだけの人」になるでしょう。

# 頭悪いと言う前にちょっとは考えろよ。（笑

>>41
もとからクソレスだと思うぞ！ (ハネッかえる暇があるなら少しは論点を整理しろよ。

そろそろ業務屋さんになりたいなぁ・・・

お前議論以前に、「つもり」とか、「思う」とかが大杉。

>>42
> もとからクソレスだと思うぞ！ (ハネッかえる暇があるなら少しは論点を整理しろよ。

うん、いつもクソレスだね、君のは。
わかってるじゃん。

>>42
いや、あの・・・
わざわざ事細かに説明してもらって悪いんですが、その意見がね
しょぼいって言ってんの。
ちっともまとまってないんだってば。

# 頭悪いと言う前にちょっとは考えろよ。（笑
頭使うのは吝かでないですから、もう少し身のある発言を希望いたします。
個人的にはですね、
>>9 の1)〜3)がよくまとまってて好きです。( 4)は私怨がひしひしとw このスレとはあんま関係ないような。)

しかし日常の生活で、ここまで知的なレベルがすれ違う人と接することはほとんどありませんので、
つくづく2chて刺激的だなと思います。
神様、>>42との出会いに感謝いたします。

論点を整理しろよ、なんて面白すぎだよ。

おまえ「論点」て言いたいだけだろ。

>>46
何を見当違いしているのか？ (笑
本来、議題項目を規定するのは起題者の義務ですわ。
確かに９さんの定義は一般的なんだけど1さんの内容と噛み合う点は何処にも無い。
つまりは１さんが出てこない限りこのスレはクソってことなんですわ。

# 頭を使えと言ったのは上記の点に着目しろってことですわ。（笑
# はー、ジャマイね。

>>47
# 頭を使えと言ったのは上記の点に着目しろってことですわ。（笑

げっ、まじですか？あの文脈でここまで語ってた？

>>46 の発言読んで思いついただけなんじゃ・・・

>>48
いえ、最初から起題者に対して以下のように「業務屋」に対する定義が一般的に通じない状態で曖昧で
あることを指摘し、混乱要因であり落ち度であることを指摘しています。

> このスレが混乱した一番の理由。
> 「指示通りに作業するだけの人」＝「業務屋」と考えてる１に落ち度あり！
> # 用語の意味意図が人により大きく異なる典型例ですな。

# もっと判り易く書かんと読みきれないのでしょうか？ (笑

>>49
出張32さんて、法学部出身でしょう。
なんとなくそう思った。

あー、あー
馬鹿二人発見。

わざわざ発見しなくても（ｗ

おおおおおおおお！
出張３２が好きそうなレスだな。

つーか、明らかに狙っただろう？>>1

で、ログ読むのめんどうで読んでないんだけど、
出張が技術はいらん！業務で金かせげるんだ！　で終わり？

つーか勉強しろよ文系

営業マンの出張

このスレもかなり荒れてるねぇ（ｗ

あのさ、ひとりで開発から営業までできるヒトなら、
ここに書いてあることを言う権利があると思うよ。
で、ここで偉そうに言ってる人たちはそれができるんだね？

ムカついたりするのはわかるけど、それをその相手にぶつけるんじゃなくて、
こんな場で発散してどうすんのさ。少しでも自分の現場の環境改善しようと
思うなら直接相手に言えばいいじゃん。
それが言えないからって、こんな場で発散するなってーの。

馬鹿とか糞スレとかいう前に、自分が相手の立場になったときに
その仕事を完璧にこなせるのか、客観的に考えてみたらどう？
それともイマドキの大人ですらそこまで想像力が低下してるのか？（ｗ

お客さんの要望と業務の本質は往々にして食い違っていることもある。
そこを見切ってシステム化につなげる提案をするのが業務系ＳＥでは？
提案をするにあたっては当然その先の開発についても見切ることができなくては
ならないので、技術スキルも必要。
そういうＳＥになりたい。

ｗ(￣△￣;)ｗおおっ!
最近は誰もカキコしとらんｗ

あ、、、、俺が起て逃げしたスレだこれ
まだ生きてたのね

さ、続けてくれよ
業務屋さん、 技術屋さん。

一番望ましいのは、ユーザからの要望を最良の方法（コスト、納期、品質・・・）で１００％応えること。
しかし実際には色々な問題（要員不足、予算、技術的な問題等・・・）が絡んでそれを実現するのは難しい。
そこで必要になるのが、誰もが（ユーザ、開発者、上役・・・）納得出来る落し所を見つけて、
そこへ落ち着かせるための提案・折衝能力ということになるのでは？
そう考えると、業務屋がリードして技術屋がサポートする相互補完の関係が必要になると思われます。

>>1
は>>9のいうところの”２番目の”ＳＥだあね。
んで、>>9のいうところの”３番目”寄りのＳＥに敵愾心を抱いてると。

っていうか、漏れ的にはどっちも”ＳＥ”じゃないんだけどね。(w
なのに、>>1の”ピュアＳＥ”ってハンドルが。。

恥ずかしさのあまり立て逃げしたんだろ（嘲笑）。

業務屋つーのはだな一言でいうと
オナニー設計しかできない奴のことさ

極端な話、技術屋はバイト君でもできる。
業務屋はバイト君ではできない。

>>63
>業務屋つーのはだな一言でいうと
> オナニー設計しかできない奴のことさ

オナニー設計という言葉が当てはまるのは
どっちかというと技術系の方が。

業務系は手抜き設計しか出来ないというのが正しいんでないかい。
このお客さんはこんなの望んでないと割り切ってまうような。

別に煽りじゃないＹＯ！

漏れ、どっちかというと手抜き系（爆
それでもお客さんに文句いわれたこと無いから仕事としては問題ないし。
よく指名される（藁

age

よくシステムの記述にロールを使うじゃない。
ロールごとに担当作業と責任範囲を規定するやつ(たとえばJ2EEのBluePrints)。
ロールをベースにして話さない？

システム構築の最初からでいくと、たとえばこんな感じ。
　・要求提示
　・現状分析
　・改善策定義
　・改善策の実行計画
　・資源の提供
　・資源の配分

このあと実装担当、テスト担当とかまで続いて、
40〜50はでてくるんじゃないかな。

SEとか業務屋とか言っても、それこそ組織や個人ごとに考えが異なってくると思う。
「業務屋とは、ナニとナニとナニのロールの人。××ができないから糞」
みたいに言ってくれれば分かりやすい。

情報処理試験の分類のようなアプリケーションエンジニアみたいな分類は、
まだまだ荒すぎる。

>>67
いや、だからさぁ〜（汗"
このスレの起題者は、ほんのちょぴしの知識と経験で業務系ＳＥの実務を表層のみを
眺めて騒いでるだけですってば！
経験が浅いと何でもかんでも機能を盛り込むのが最善だと思い込んでしまうからね。
その程度の方に>>65さんが書いた「手抜き」の意図は理解出来ないし>>61，>>64さん
の発言すら「何言ってんだ！」で終わってしまう。

# 悲しいけど現実
# まあ、もうちょっと経験とスキルを磨いて貰うしかないね。

>>68
「2ヶ月前に終冬してた」というのは >>67 を書いてる間に気づいたんだけど、
せっかく書いたから書き込んじゃった。

>>1 みたいな考え、大嫌いなんだよね。
ネタなんだろうけど、同じことを考えてる奴って実際に少なからずいそうな気がする。

続けるのもリソースの無駄かなあ。

（＾＾）

あぼーん

>>69
Ｓヨですな。

（＾＾）

ageｯﾂ

チーフアナリストと名乗って松

>>69
1では無いが、
>>1は、ネタじゃないと思うよ。
>>1みたいのが、居ないほうが不思議だと思う。

例えば、
スポーツするから良い靴は無いかと問い合わせて来た客が居たとして。
それぞれのスポーツに適した靴があることを知った上で
更に同じスポーツの靴でもコンセプトの違う靴があることを知った上で
どれが最適の靴なのか判断できるのがＳＥだと思うんだよね。

コンセプトの違う靴があることを知らないのが、
>>1の言う「業務屋」だと思うんだよね。
表面的なことだけで仕事してるＳＥは多いと思うよ。
ただ、それは別の職種であっても多分同じことだと思うけどね。
>>1は、その点を見つめる目だけは正しいと思うよ。

1はＳＥをシステムエンジニアの意味で書いていますか？
もしそうならシステムの定義をどのように考えているのでしょうか？
コンピュータソフトとシステムを取り違えているような。。。

業務を知らないSEは滑稽だわ
業務なんぞ関係ないとか言ってる香具師は
指示されたことだけやっていればよいPGレベルの証

（＾＾）

業務なんてシステム化する前に使われてた紙の「伝票」や「申請書」見せてもらえば把握できるっしょ？
悪いこと言わんから頭の不自由でない若者は技術から入んなさい。

世には、「一般」のフローとはまったく異なる業務フローを行っている企業もごまんとあるのです。
アウトプットの帳票はいっしょでも、出てくるタイミングや順番が異なることもある。
創業者がそれを「競争力の源泉」だと考えているんです。

自分の間隔だけで判断しないほうがいいよ。
(こんな例は、日経コンピュータやら日経システム構築を読んでいればいくらでも出てくるよ)

> 紙の「伝票」や「申請書」見せてもらえば把握できる

君のお仕事は紙の「伝票」や「申請書」を電子化することだけ？
エクセル・ワード使いのＯＬの姉ちゃんと同じってことだ（ｗ

>>82
>君のお仕事は紙の「伝票」や「申請書」を電子化することだけ？
うんにゃ。Web化もしくはC/S化すること。

>>80,83
>君のお仕事は紙の「伝票」や「申請書」を電子化することだけ？
うんにゃ。Web化もしくはC/S化すること。

それでわかったつもりかい。
そんなんじゃ、「業務完了までの時間短縮」とか「同業務に関与する人減らし」
とか、業務フローを変えるなどのお客様のご要望にはついていけないと思うけど。
業務屋はそういうところも含めてお客様の話についていけなきゃいけないから、
君がいう技術屋とは違う能力なわけ。
それとも、ＰＧ書けるぐらいのことで技術屋とか名乗っちゃってるわけ？
そんなんだからアルバイトでもできちゃうとか言われちまうんだよ。
そんなレベルの奴は一生仕様書どおりにＰＧ作ってろ。

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

>>83
>>君のお仕事は紙の「伝票」や「申請書」を電子化することだけ？
>うんにゃ。Web化もしくはC/S化すること。

ここを読んで、笑ったのは私だけか？

>86
おれも笑った。83が楽そうでいいよね。

>>84
>そんなんじゃ、「業務完了までの時間短縮」とか「同業務に関与する人減らし」
>とか、業務フローを変えるなどのお客様のご要望にはついていけないと思うけど。
ついていけないというか関わりたくない。

>業務屋はそういうところも含めてお客様の話についていけなきゃいけないから、
>君がいう技術屋とは違う能力なわけ。
知ってるよ。

>それとも、ＰＧ書けるぐらいのことで技術屋とか名乗っちゃってるわけ？
オレはそうじゃないけど、それもアリだろ。

>そんなんだからアルバイトでもできちゃうとか言われちまうんだよ。
バイトでも時給4000円以上のヤツなら一人で一通りできてしかるべきだろうな。

>そんなレベルの奴は一生仕様書どおりにＰＧ作ってろ。
？
話は変わるが、実装工程を中国やインドの業者に発注する場合の仕様書って、
ソースのコメントなみの記述を求められるらしいね。
それプラス、テストの手順書とチェックシート。
ほんとにコスト削減になってんだか。

>>88
> 話は変わるが、実装工程を中国やインドの業者に発注する場合の仕様書って、
> ソースのコメントなみの記述を求められるらしいね。
> それプラス、テストの手順書とチェックシート。

ソースのコメント並みの記述って、本来あるべきものだよ。
「本来あるべきもの」を(意図的にか無意識にかはさておき)省略してるのが
これまでののやり方であっただけ。

> ほんとにコスト削減になってんだか。
これには同意。
システム開発はコストを正確に測ることが難しいから、
目に見えるものだけの費用を使って積算したらコスト削減になってます、ってだけの話だと思う。

>>89
なぜにsage？

>>83
は冗談を書き込んでいますよね。まさか本気じゃないですよね。

今時、技術だけでは通用しませんぞ。

数年後、ここの何人がこの業界にいれるのか
今から楽しみにしています。ﾌﾟｯ


技術一辺倒は時代錯誤甚だしいね。

多分、全員残るんじゃない。

一生懸命に考えてそのザマかよ・・・。

技術SEは中国・インド使うからいらん。
業務SEとPMだけいればいい。

>>96
その技術ＳＥに細かい指導をするのは？
結局技術＋英語を知っている奴が必要になってくる。

（＾＾）

>>97
バイトにでもやらせとけば？

>>99
バイト、誰の金で雇うんだ？

まだこんなこと言ってやがる
http://science.2ch.net/test/read.cgi/infosys/1040065457/l50
252 ：非決定性名無しさん ：03/05/05 03:26
中国人だと5万ｴｿ／月なのでもう日本人なんて使えねえ

業務屋もいつかは死ぬ。技術屋も。
どんな分野のＳＥになろうともいつかは死ぬ。

＞100
そういう仕事あったよ。日本語片言の中国人ＳＥとの橋渡ししてくれって
中国語話せないのに（結局やらなかったけど）

>9のいうところの２）は余計な仕事増やしてくれるから嫌われるし、
３）は敵扱い♪技術的な問題点をあげると文句いってくるしね〜

>89
賛成！
漏れは「１の言う」業務屋あがりのＳＥだが、「オフショア」とか言って
うわべの「値段」だけで評価しちゃうんだよね。
実際のコスト（金額に表れないモノも含めて）は、かなり莫大なんだけどね。

会計あきたから、金融やろうかと思うがどう？

あぼーん

あぼーん

2001年に中日ドラゴンズに１０億円という巨額の金額で入団した川崎憲次郎。
しかし彼は入団してから２年間、１軍のマウンドで1球も投げていない。 怪我は治っているが、２軍での投球も拒否。
最近では自宅での休養（サボリ）を続けているという。
ちなみにヤクルトの伊藤選手も同じような状況であるが、本人からの要望で給料の８〜９割を返還している。 一方川崎憲次郎はビタ１文も返してはいない。
もちろん税金等の問題があり、そんな単純ではないが１本１０円のワクチンを１０億円で買うならば１億人の人口が救えるのだ。
食料に困っている１億人の人たちにうまい棒を買ってあげられるのだ。
必死に生きて餓死していく人たちの前で川崎憲次郎は優雅な生活を楽しんでいる。
こんなことは許されない。皆もオールスターのファン投票で川崎憲次郎に投票し、出場させるのだ！！
5月23日の中間発表ではセリーグの先発２位につけている！！
投票は6月22日まで！！
https://allstar.sanyo.co.jp/vote/
中日・川崎憲次郎、依然先見えず…
http://www.zakzak.co.jp/spo/s-2003_02/s2003021502.html

>>9
この分類はとてもよく出来てる。
どうやら、この職種には適性というものがなく、各々の特性に応じてでたらめに仕事しているということだ。
3)とか4)とかの人種は責任をなすりつけるのにたけた人物であるから、立ちの悪いことにトラブルが生じた場合たいていが、技術をもった作業者の責任にされてしまっている。
これは業界の構造的問題となりつつあるんではないか。
早期に既得権者であり抵抗勢力である3)や4)の人種の淘汰と、2)の誰もわかってくれないと思い込んでいる精神のケアが必要だと思う。

派遣の業務屋ってどんなことするんですか？

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

>110
コンサル

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

ピュアなＳＥって、土方？

ピュアな「ＳＥ」はアイビーエム職種名だろ?

ピュアなＳＥＸは中田氏！

文系と理系がいつも平行線なのはどこも一緒だ
漏れは文系は苦手だ
良いとこ取って　自分らが中心だと勘違いしてる
理系の方が距離感において大人であることが多い
これって何の違いなんだ？

文系と理系で分けているわけではないが、
人によって解決策を優先するか真善美を優先するかの違いはあると思う。

解決策といっているのは、
必ずしも正しくないが次善(ともすれば次々善、次々々善)の策でも受け入れるということ。

文系、理系って、、、、ガキじゃねーんだからくだらねぇカテゴライズするなっての（ｗ

>>1
あー、わかるわかる。
業務をわかるから金を引っ張ってこれる、だから業務屋は偉い、という論理で
偉そうにしたあげく、糞以下のシステムを作って客の信頼をなくす奴が、うちの
会社にもいるわ。

ピュアＳＥなら政治・経営・業務もできないとな（ｗ
お前さん >>1 はＳＥではないようだな

　社会システム ⊂ 企業システム ⊂ 業務システム ⊂ 情報システム ⊂ 技術システム

>>121
おもしろい

>>121
つまり、「社会」がエンジニアリングされていない国では、
あるいは、法令というプログラムがバグだらけの国では、
ＩＴなんて、どだい無理な話という事でつか？

>>123
バグを無くすのは本当のプログラムでも困難だけど、法令のバグを直さない、直したくない寄生虫が多い国って事ですよね？
ま、どこの国でも893や日本の官僚、政治家のような寄生虫はいるけど、社会の一部だから。
ITとはまた別の問題ですね。

> ITとはまた別の問題ですね。

いや。そんなことは100も承知なわけだが。。。

情シスを含む、より大きな枠組のシステムを理解していなければ、
まともな情シスの構築なんてできませんよ。ということでそ。>>121

一生PG/OPでいるならまだしも、コンサル目指すなら必須の考え方でそね。

生涯一プログラマで居られるって格好いい
マネージャやらコンサルタントに逃げるより。
できるコンサルタントはプログラマとしても優れてるけど。分野にもよるか。

アメリカとかじゃ普通に一生プログラマとして生きる人間がいるんだよな。
プログラミングの腕というのが評価されているわけだ。

コンサルという言葉を聞くとすぐに妄想を膨らませ過剰反応 >>126
逃げる以前に逃げられる能力があるかどうか（ｒｙ

メリケンかぶれのPGの地位向上委員会メンバー登場 >>127
一生PGしていたければしてればいいだろうに
「評価してもらえないから辞める」なんて奴はどんな業種でも使えない奴だ

保守age

>>128
>>「評価してもらえないから辞める」なんて奴はどんな業種でも使えない奴だ

だから、あなたは上司の腰巾着に徹しているのでつね。

>>130
そうそう。評価されない奴ほど、評価される人のことを、そうやって妬む。
そして、世の中と一線を隔した孤高の天才を演じるてみる。
もしくは、意味もなく諂い、テキパキ働いてるフリし、必要以上の敬語を使ってみたりする。

でも、実際はそんなことで評価されるほど、バブル後の企業は甘くない。
評価されない奴は、いつまで経っても評価されない。
評価される観点そのものの認識がずれているから。

業務屋の生態

１．仕事をもらえた。早速PGを集めるぞー
２．良いPGが集まらない。社内に技術を蓄積してないからだが、もちろん業務屋は気付かない。
　仕方がないので外注に頼む
３．設計を始める
　しかしシステムについて知らないので設計は無茶苦茶だ。
４．外注に作らせる
　しかしシステムについて知らないので指示が曖昧だ。
５．制作が進まない
　設計が進まないのでPGへの指示がころころ変わり、呆れた外注はやる気をなくして仕事をしないが、
　システムについて知らないので業務屋はそれにも気が付かない。
６．納期が迫ってきたぞ！
　設計もまだ出来てないが、無理矢理作らせる
　外注は期限が終わったら関係ないので、残業代稼ぎにだらだら仕事をする
７．納期が過ぎたぞ！
　画面だけ完成。
　顧客に持って行くが文句を言われ、要求を丸飲みすることで何とか納期を延ばしてもらう
８．やった完成だ！
　ようやく完成するが、システムの中身はボロボロ。
　バグに継ぎ当てして何とか納める
９．その後・・・
　直しても直してもバグが出てくる
　しょうがないので、外注の一人を常駐させて対処する
　今回も赤字だ
　

文系SEがこの業界をダメにしている。

管理される者は管理するものを忌み嫌う
　　　概してそれは前者の無知によるものだ
　　　　　　　　　　　　　　　　　　─── ピラト・ダムソン

>>134
いや、管理が必要だと言うことは十分知っているんだけど・・・
私って我侭だから管理されるの嫌なのよね。
それで、管理に必要な報告関係の資料は全て秘書に書かしてたりする♪
前は可愛い女性秘書だったんだけど、今は親父秘書（47歳）だったりするから
ちっとばかし味気ないけどな。

技術屋に一言言いたい。
「コスト意識を持て」

>>134
遠目で作業を眺めているだけの奴等が「管理出来ている」って
評価されているのは癪に障る。
「君達みたいな技術屋はもう要らない、システム開発は外注に
どんどん出すから、うちの会社は管理が出来る人間が欲しいんだ」
って言われ続けると腹が立つ。
管理って案山子をやっていればいいの？って本気で思う

>>136
管理人に一言言いたい。
「案山子は黙って座ってろ、内容分からんくせに喋るな」

要は内容のわかる案山子になれと。

ここで文句たれてる香具師らは
若いんだか無能なんだかで　管理仕事とは無縁の下請作業しかしたことないってことだろ？
自らバカでーすといってるようなもん
しょぼすぎ

>>127
> プログラミングの腕というのが評価されているわけだ

ばーか。金を産むということを評価してんだよ。勘違いも甚だしい。

業務屋とかいちいちそんな職つくるなよなー。
技術しかしらんで愚痴ってるようなもんやー。
用はバランスでしょ。
業務が長けている事も、凄い事だと思うけどなー。
どう金を生んで、どう信用を築いていくかでしょ。

>>142
業務しか知らん奴のことを叩いてるだけでしょ。
両方知ってるなら文句ないんじゃ。

>>141
品質向上にメリットがあると評価されてるんだろ。

>>143
> 業務しか知らん奴のことを叩いてるだけでしょ。
それ叩くのなら、技術しかしらない奴も叩かれるかと．．．．
はっきり言って、使えません！
仕様を正しく読む能力に著しく欠ける。

やはりバランス大事ですね♪

>>144
大抵業務屋は中年より上が多いから、会社の地位が高いことが多く
技術屋を叩いている。
だからここで叩かれるわけだ。
業務だけじゃ全く使えないというのがこのスレなんだから、技術だけじゃ
全く使えないというのは他のスレでやってくれ。

業務屋は、経営屋に使われ、技術屋を使い、その過程で利益を生む。
技術屋は、業務屋に使われ、利益のおこぼれをもらう。
ビジネスモデルとして、技術屋は儲からない立場なのだ。

技術屋はもっと営業力を鍛えるべきだね。
客と協力すれば、安く良い物が業務屋抜きで出来上がるんだから、
がんばった方がいい。

俺もフリーになろうと業務の本や法律の本を最近読みあさってるが、
技術本よりも安くて分かりやすい本がたくさんあるよ。
技術を学ぶ熱心さをそこに向ければ、きっと習得できると思う。

>>145
なるほど、自分の立場を忘れて、他人をたたくためのスレなのか。
人間が小さいな。
それってたのしいのか？
俺は哀れみを感じるが。

>>148
俺はわざわざ興味のないスレに来て、煽ってる148に哀れみを感じるよｗ
まあ、自己弁護に必死なんだろうけどね。

>>149
つまらないな。
もう少しひねった文章書いてくれ。
それでは何も伝わらん。

>>150
お前アホだろ
148が149よりレベル高いって言うのか

>>150
レベル以前に話がかみ合っていない。
それをわざわざ煽る、おまえのレベルが低いのは確かな情報。

>>151
スルーしろ。

業務屋のしきるプロジェクトって、必ずの様に潰れるね

「業務屋」は、システムの分割統治を業務で行おうとするが、
分割後のそれらにはすべて似たような機能が共通して含まれる。

上記の分割のままシステムを作ったら、
破綻するのは目に見えている。

技術屋に質問。
・資格とか持ってる？
⇒基本情報とソフ開しかない、ってことはないだろ。
・自分たちの開発費が、売上原価になるのか、管理費になるのか把握してる？
⇒自分の給料がどこから出てくるか、仕事してるならわかるだろ。

ピュアＳＥなら政治・経営・業務もできないとな（ｗ

　社会システム ⊃ 企業システム ⊃ 業務システム ⊃ 情報システム ⊃ 技術システム

そんな一元的なモノの見方じゃＳＥは勤まりません。
逆もまた真なり。

社会システム ⊂ 企業システム ⊂ 業務システム ⊂ 情報システム ⊂ 技術システム

オレは１種（時効か？）しか持ってないけどな・・・

中身がわからなかったら設計も提案も出来ないと思うんだけど、
業務屋のみなさんはどうやってるのですか？想像？

中身がわからなかったら設計も提案も出来ないと思うんだけど、
技術だけ屋のみなさんはどうやってるのですか？想像？

キミらの知ってる「業務屋」とやらがどんな奴らかは知らんが
べき論としての設計手法は、経営 → 業務 → 技術 であり
べき論としてのキャリアパスは、下流・技術屋 → 中流・業務屋 → 上流・コンサル屋 だ

>>158 のような技術ありきの企業システムなどありえないし
>>159 のような中身を知らずに設計・提案などもありえない

キミらの知ってる業務屋がそれにあてはまっていないとしたら
キミら自身の所属している組織のキャリアパス構造・設計手法が
間違っている（＝二流・三流）というだけのことでしかない

批判すれば批判するほど自身を貶めている。憐れだな

>>159
正解。
経験がない場合、本を読んだり、人の話で中身をイメージするしかない。

業務屋（の存在そのもの）を批判してるとしたらかなりイタイ。
体系的なマネジメント手法等を勉強してないのがバレバレ。
居酒屋で上司の批判してる無知な新人リーマンと同じレベル。

まぁ業務屋は業務屋で、とんでもない要求を受けてしまうことがあるし、
システム屋はシステム屋で、構造とかパターンばっかりで
データの意味なんて全然気にしてなかったりする。

普通の神経してたら、ある程度の領域までお互いに踏み込まないと
不安で業務もシステムも設計できないはずなんだがなぁ。

ここ３年くらい技術系にいるけど、業務系のＳＥって、業務改善の提案さえ客の言いなりで、
ひたすら御用聞き＆画面デザインしかやってない。それ以上に踏み込もうともしていない。
この間、業務ＳＥすっ飛ばしてエンドユーザーと２時間くらい話をしたら、たまりにたまった課題が
ほとんど解決してしまった。間に業務系ＳＥが入って伝言ゲームになっていたのが元凶だな。

日本中こんなプロジェクトばかりではないとは思うけど、技術系の連中が業務系ＳＥと話すより
エンドユーザーと話したほうが早いと思い出したらもう、業務系ＳＥなんてジャンルはは不要に
ならないか？（どうせ、ものすごい業務改善なんてできないんだから）

技術系出身でもユーザーからヒアリングできる機会があれば業務系ＳＥもどきもできるが、
業務系の人々は技術系抜きで今の担当システムサービスインさせられるのかな？
ネットワークの物理設計できる？ディスクの効率配置できる？言われたことしかやらない
ＮＴＴの孫請けのガキどもやＣＥにちゃんと作業指示できる？
データベースのチューニングできる？障害対策の手順書作成できる？

それより、これからは技術的なことも覚えようという気持ちの切り替えができる？（これが一番聞きたい）

> 普通の神経してたら、ある程度の領域までお互いに踏み込まないと

そうそう、こういうこと意識してる人がいないプロジェクトってまず破綻してるよね。
自分の責任範囲を明確にしておくのは大事なことだけど、
その垣根の高すぎる人がこの業界にはあまりに多すぎ・・・

>>165
163の発言の意味、わかってるか。

>167
わかってますよ。業務系のＳＥを否定してはいるわけではないです。
要は業務系とか技術系とか関係無しに前向きに進めていこうという
ＳＥばかりならもっと仕事も楽しいのだけど、そうじゃない現状の愚痴。

ただ、業務系と胸を張る人の方が困ったチャン率高いですよ。
ちなみに私は業務８年、インフラ７年でこういう結論に至りました。

業務屋を対等に見ない技術屋、技術屋を対等に見ない業務屋がいるのが問題だな。
排斥してどうする。

さらにいうなら、客も対等だ。

>>167
163の書き込みなんて、レスを付ける価値がないと思うが。

> 業務系の人々は技術系抜きで今の担当システムサービスインさせられるのかな？

こういう発言があるとね。頭悪いのがバレちゃうのね。

技術屋が業務屋になれば万事解決なんだろ？
ここにいる技術屋がそうでないのは、
　・業務屋になりたくないから、ならない
　・業務屋になれない
のどっちか。

世の構造からすると、だいたいが後者なんだわな。

元アカウントSEで、ドロドロした仕様策定がイヤでシステム屋に
なって喜んでる人も結構いるはず。

そりゃ全体的に見りゃ少ないけどね。

>>172
業務屋になる方が難しいとでも思ってるのかな。
売ってる本は業務系の方がかなり薄くて安いが。
大体世の中の構造ってなによ？

俺の知ってる業務屋は、進歩する技術について行けない奴ばかりだ。
それにコンプレックスを持っているのか、Javaやオブジェクト指向、Web技術なんかが
かなり憎んでる。
わけわからん。

売ってる本の厚さで判断するのか・・・
ネタだよな、流石に?

馬鹿だな。
指標の一つだよ。

業務屋とか技術屋なんて分類は昔はなかったよ。
皆、業務も技術もやってたよ。
１０年前のバブル崩壊と、Ｃ／Ｓの台頭でホスト系以外の技術を
覚える気の無い人たちが作ったのが、アプリ系ＳＥというジャンル。
つまり逃げ道として発生した職種だ。
通産のアプリケーションエンジニアを持ってる業務屋ってどのくらい？
たぶん１割以下なんてレベルじゃないでしょ（１％以下かな）
技術が無くて業務知識だけならエンドユーザーと同じじゃない。

俺は技術屋になりたいと思っている。
より正確には技術コンサルだ。

業務ドメインのスペシャリストは企画した人間でありエンドユーザーだ。
システムを構築する側の人間がもともわかっているということはありえない。
あるとしたら、それは不幸な関係だ。

金輪際、顧客がインサイトに入らないシステム開発は行わない。
業務の話は顧客を全面的に信頼する。
だから技術の話は俺を全面的に信頼してくれ。

桃源郷へ連れてってやるぜ。

同じ経験年数なら、業務屋の方が給料いい・出世も早い
評価なんてそんなもんさ

でも業務屋の仕事は、やっていてもつまらん仕事ばかりだろ。

業務屋の人たちって、本当に業務を分かってるのかな？
うちの会社の業務屋は何十回もヒアリングに行って、それでいて設計はまるで出来ずに
プロジェクト完了予定を過ぎても仕様変更が入るけど。

つまらない仕事ばかりしている馬鹿な業務屋の話をしても仕方ないし
つまらない仕事ばかりしている馬鹿な技術屋の話をしても仕方ない
下を見るのは無意味だ

> 俺の知ってる業務屋は

> アプリケーションエンジニアを持ってる業務屋って１割以下なんてレベルじゃない

> でも業務屋の仕事は、やっていてもつまらん仕事ばかり

> うちの会社の業務屋は

二流・三流の技術屋、必死だな（ｗ

本来、情シス業界の頂点にはコンサル屋がおり、
人・物・金の動きを含めた業務プロセスの再構築・設計を行い、
自動化可能な部分をシステム化するところまで導いていく(べき)もの。
組織の統廃合、物流変更、人員配置調整など、非常に強力な権限を持つ。

でも。このようなスーパーコンサルを雇うのは、とってもコストが高い。

たいていは、このあたりの上流要件定義は顧客側の企画部あたりで
実施していることが多い。それなりのエリートを参加させて。
んで、最後のシステム化のところだけを担当するために雇われるのが、業務屋。

なぜ、業務屋が仕様変更に巻き込まれるかというと、顧客サイドの
上流要件定義がしっかりしていないから。
それをブレークダウンさせた下流要件定義はモロに影響を受けることになる。

突き詰めると、顧客がケチ、かつ、頭が悪いのが悪い。
そして、業務屋が仕事をとってくるような会社は、
上流要件定義まではビジネスにできない会社、提案力・技術力もない会社、
「情シスつくらんかな」の“それなり”の会社でしかない。

まあ。二流・三流ということだ。

＞本来、情シス業界の頂点にはコンサル屋がおり、

どこでそんな嘘を教わってきたんだ、厨房

というより、業務屋って業務のことすら分かってないアホの集まり。

>というより、業務屋って業務のことすら分かってないアホの集まり。
うんにゃ。Web化もしくはC/S化すること。

>>187
意味がわからない…
本当に>>186に対するレスなの？

業務系のスキルってどれぐらい横展開が効くんだろ？

常に初業務な気がするんだが・・・

>>189
横展開ということは、縦展開もあるのか？

>>184
二流、三流の会社が「システム」という道具を使ったところで何かが良くなるのだろうか。
上流の要件定義がマトモにできない会社は、システムに何を期待しているんだろう。

技術について行けなかった奴が、業務屋になるからなぁ。

ゴミSEドモ・・・はよ氏ねや

>>191
何もよくならん。期待しているのは目先の￥だろう。

顧客の示した現状の業務プロセスを疑うことなくシステム化しようとする業務屋と、
言われたことを忠実にシステム化することに生き甲斐を感じる技術屋の集団。

「技術的には可能ですが、それをシステム化することが本当に望ましいことですか？
むしろ…（提案）」と言い出せない業務屋・技術屋は、全部、二流・三流。

> どこでそんな嘘を教わってきたんだ、厨房

上流設計の研修受ければ教われますよ。たぶん。ＰＧ研修じゃ教われません。（ｗ

経営者が求めているのは、情シス（箱モノ）ではなく、
情シスを使うことで得られる収益の増加（リターン）ですから。
そこまでの提案・設計・根拠作りなくして進めるＰＪなんて、
「ライバル社が入れたから我が社も」というレベルのアホ経営者と、
それをカモにするハイエナＳＩｅｒでしょうなあ。

やれやれ。

類(糞ＳＥ)は友(糞業務屋)を呼ぶ
五十歩(糞ＳＥ)百歩(糞業務屋)
目糞(糞ＳＥ)鼻糞(糞業務屋)を笑う

>>195
その「設計」も「根拠作り」も「提案」の実現にしか役立たないだろ？
だからプロがゼロから作り直すかドカタがデスマやるしかないっての

>>195
隗より始めよ。という言葉を君におくろう。

SIerにしろコンサルにしろ、自分とこのシステムどうなってるねん？

俺はいまだに情報技術は人を幸せにすると考えているからね。

この幸せは、多分にいろんな意味を含んでいる。
「いま見たい色が分かるなんて、あら素敵（はあと」とか。
「監査のためにいくらか形式的にしたおかげで、
　プロセスを標準化できてルーチンワークをルーチンプロセッサに丸投げできてハッピー」とか。

「情報技術が入ると仕事は難しくなる(デマルコ)」という状況になってほしい。
人間がもっと創造的になるように。

営業のできるプログラマが一番最強

>俺はいまだに情報技術は人を幸せにすると考えているからね。

青臭いね。個人的にはおおいに賛同するけど。
そういうポリシーがなくちゃただの生産機械扱いだもんで。

効率化によってあるグループの人たちの仕事を人間要らず
にして利益に変換する。こういう作業の片棒担いでると、
ときどきその行為にどれだけ意味があるのかと思えてくる。
それでも人間は、まだ先にいけるはずだと信じたい。

ごね得業務屋が世界最強。技術屋にすべて押し付けて光より早く逃げる。
アテネいけるぜ。あとは何を聞いても「知らない」の一点張り。

IBMなんかはコンサル集団持ってるし
絶対に儲かる見積とＰＪの進め方しかしないし

それに引き換え、ココの住人の勤める会社はなあ（ｗ

>>203

システム屋なんてどこも同じ。
ＩＢＭだってＮＲＩだってろくなもんおさめてこないじゃん。

>204
まあまあ、きみの会社といっしょにしては失礼だよ

>>204
まぁあの人たちは、自作しないのだし、
レビューだって適当だし。
「なんとか」動けは成功事例。

「なんとか」しか動かないのは顧客側の要件そのものが洗練さ（ｒｙ

>>207
そのお客がちょっとだけオツムが良くなってしまえば
お前の食い扶持などたちまちなくなる。

ダメＳＥの仕事振りって
安いファミレスのキッチンのバイトを思い出すよ。

仕事に対する意識とか客に対する気持ちとか
モラル全般において同レベルもしくはそれ以下。
出されたものが食えるだけファミレスの方がマシじゃないか。

>>208
そうならないように必死で雑用を増やしているのですが？

＞＞210
ほほう。
まあ頑張れ。

アナルオナニー、マジで新たな世界が開けるよ。
四つん這いになってローションをたっぷり塗るんだ。
指の爪はもちろん短く切ってヤスリで滑らかになるよう削っておく。
まずは穴付近をゆっくり愛撫、やりにくかったら
側臥位で片足を上げる感じで、玉との間の前立腺も刺激してやる。
優しく優しく…くすぐったいか気持ちいいの中間くらいで撫ぜる。
馴染んできたら、改めてもう一度ローションを手に取っていよいよ挿入。
この時に絶対に焦ってはいけない。そして力んでもいけない。
リラックスして深呼吸して、ゆっくりゆくっる、あんヌプヌプするぅとかそういうイメージで！
痛いと思ったら一旦引こう、焦りは禁物だ。
気持ちを落ち着けて、なおかつ昂ぶらせて雰囲気を盛り上げる。
自分は処女で、今は大好きな憧れの先輩との初めてのHなんだ、とかなんでもいい、
とにかく盛り上がる設定を脳内で作って、興奮を極限まで持っていく。
なんなら「そんなトコ、ダメだよぅ…！ダメだったらぁ…ん…！」とか声を出そう。
興奮が山場を迎えたら愛撫していた指を一気に、しかし滑らかにゆっくり、穴に入れる！
初心者は人差し指だ、小指ではやりづらいし、中指は痛いと思うからな。
さあ、ついに憧れの先輩のが挿入された！痛い！痛い！
でも先輩は気にせず動かす、気にしないけど、優しく暖かく、ゆっくり…。
ここではもう恥ずかしがらず声を出そう！ため息だけでもいい。
ローションが足りなかったら空いてる手で追加、そしてできれば乳首も一緒にいじろう。
痛い痛い痛い痛い痛い…いた…いいた…い…い…たくない…？
何度か動かすうちに、ローションが馴染み痛みはなくなり、
くすぐったいような切ないような、今まで味わったことのない快感に変わるはずだ。
そうなったらこっちのもの。感性の赴くままに快感スポットを見つけて攻めよう。
空いた手で、ギンギンなペニスをしごいてもいいだろう。同時責めは快楽の坩堝だぞ。
さあ、これであなたも、アナルオナニーのとりこになること間違いなし。
ただし、浣腸なりビニールシートなりの用意はしておくといいかもな。
俺は面倒だからウンコそのままティッシュで拭って、シャワーに直行だけど。

業務フローしか書けないSEでも、SEと呼んであげるべきなのでしょうか？
プロジェクトの内容について「知らない」と平気で言うプロジェクトマネージャーでも、
プロジェクトマネージャーと呼んであげるべきでしょうか？

同情してやればつけ上がるし、無視すれば逆ギレするし・・・
本当に困ったものです。

>>213
「問い詰める」という選択肢がないな。

プログラムかけない奴は馬鹿ばっかり。
うちの部長は偉そうな女だけど俺のようなプログラムは絶対かけない。

プログラムかけない奴はこの業界いる意味なし。
邪魔だから死んでくれ。

女部長かー。結婚してんの？

プログラム書けなくても、中身を理解していればいいんじゃない？
今ならオブジェクト指向への理解は必須だ。

業務屋＝ユーザのお話し相手
仕様変更なんて気にしない、なが〜くお付き合いしてあげるのが私のお仕事。

システム屋さんみたいにシステム組上げるのが目標じゃない。
システム変えながらなが〜くお付き合いして、人を派遣しして
上前はハネテ儲けるのだよ。

女部長：
逆セクハラしまくり。
同期の男はコピー取り係に移動。
若手男子には接待同席強要。
接待後のお誘いが恐いらしい。ムゲに拒否するとダメプロジェクトに移動。

メーカーには技術屋が多い
ソフトハウスには業務屋が多い

よって、メーカーで業務屋ができる人は重宝される。しかし、評価は低い。
ソフトハウスに技術屋は無理。技術情報がメーカーより少ないから。

漏れのような、メーカーで業務屋もやる技術屋がもてはやされる。つらい。。。

それから、業務屋には定年はないが、技術屋には定年があるね。３５歳ごろに。

孤高の画像処理屋いる？

>>218は時給給900円くらいかな

>>221
それから、技術屋は人が足らないけど、業務屋は人が余ってるね。

>219は釣りの作り話?
だとしたら出世するタイプはホスト系か

>>225
その内「ホスト力」なんて本がでるよ。

>>224 メーカー系はその逆だぞ。実態

業務屋にも光を〜

最初の五年業務屋、後の五年技術屋のSEっす。
＞１の言いたいことはようく解るが、
俺も業務やってたころは性能なんて
意識してなかったもんな。技術屋バカ
にしてたよ。でも技術屋５年もやって
ると、このままでイイのかとマジに思う。
ある程度の歳いくと、転職するにゃ業務
知識必須だもんね。

エンジニアの為の出会い系板
http://www.2ch-off.net/off/engineer/

シティ★アスコム
http://www.city.co.jp
福岡市早良区百道浜2丁目2番22号

この会社は若年退職が大変多いです。
理由は白シャツ以外厳禁、１０分前出社（でないと上に睨まれ査定に影響）、
通信講座の強制受講（受けないと昇格ポイントにならない）といったような
厳しい規律があるからです。僕も耐えられなくなって辞めました。
まぁ、銀行の子会社だし、上層部の販管費泥棒たちはみーんなシティからの
天下りだからそういう風習になるのも仕方はないんですが。
あと個人的には国立大偏重主義や資格偏重主義などもキライだったし、
辞めて新しい会社に移って、ここで得たスキルの低さを痛感させられたのも事実です。

age

システム屋のおれらからすると技術屋は余っているがな。
逆に業務知っているやつがいないから客の要求仕様作成能力が甘いとデスマ必至。
こちらは間違いに気がつかないから。
コードは正確に書けてバグも少なく期日通りに上がったとしてもユーザにとっては
使えないシステムで作り直し…

業務知識知らないでよく仕事が取れるな

営業でいいじゃん
業務営業。
SEである必要はないし、実際技術のない業務屋はSEではないんだから。

ソフトウェア後進国の日本で、技術の進歩についていけない業務屋は何なんだろうね。
カスタムソフトウェアの輸入の急増は、業務屋のせいかもしれない。

ここって、コボル屋さんという井戸の中の会話？

業務知識っつーても、ほんのサワリしか知らないわけで。
同じ客の仕事してれば別だけど。違う客のところ行ったら通用しないわけです。
業務屋って意味あるのか。

プロセスとデータの静的動的定義に最新のコンピュータ技術はいらんだろう。

最新のコンピュータ技術・・・・いろいろあるからね

オブジェクト指向すら分からない奴って、一体何なの？

>>237
基礎ってものが有るので、通用しない事は無いぞ。
業務手順の骨、肉、枝葉、を会得するには、勉強と、
ユーザ3社程度扱えば、何とかなり始める。

まぁ、案件によっては、枝葉を立派にしたいという
案件なのに、枝葉だからと言って、適当ぶっこく
白痴なSEが増えてるけどな（ｗ

ERPって、骨、肉は有りもの使って、枝葉を御社に
合わせましょうってシステムなのに、枝葉の開発力無いから、
ERPの有りもの納品して、納品はしたんだから金払えって言う
惨劇がちらほらと。

オブジェクト指向馬鹿ってまだいるんですね。
自分の仕事（業務）をオブジェクト指向分析なり設計で定義すりゃ何が問題か解るよ。

がんばれ学問坊主。

>>242
＞何が問題か解るよ。
を書けない人がたーくさん（ｗ

ユーザ企業にはあまりメリット無いなぁ。

オブジェクト指向なんて基礎知識だから、SEで出来ない人間なんて
いないだろう。
出来なかったらオブジェクト指向言語での設計なんて、出来ないじゃないか。

>>244
>>242にそんな知識も知恵も無いと思うが、
オブジェクト指向分析（ビジネスルールレベル）だと
どうもしっくり来ないんだよね。もちろんアクターは
使えるけど、アレがオブジェクト指向かというと疑問だよね。
UMLの表記ルールでは有るが。

んとまぁ、結局データベースはRDBが使いやすいってのが
この問題の一番の肝だね。

オブジェクト至高？

ヴァカが大ヴァカを騙してるだけじゃん・・・

>>245
ま〜ま〜、発言する前に「分析」という言葉を辞書で引いてみろ。
そして爪先っちょだけでもその行為が出来ているか、
ＯＯＡ技法が保証している考えろ。

分析が何かを解っている人間は、安易に分析行為やっています
なんて発言せんのだよ。

がんばれ学問坊主。

>>246
オブジェクト志向はヴぁかをカプセル化して、現実から隔離するのに必要なのです。

オブジェクト嗜好はシームレスなので
プログラミングがわかるとセッケイもブンセキも全部出来ちゃいます。

設計とはＵＭＬを書く事です。

うむ、早速一匹つれているｗ

>>249
おまえ保守要員にケテーイ

訳の分からない、穴だらけのDBのテーブル設計書
作って威張り腐られてもなぁ・・・
むかつくだけなんだけど・・・・
お前らはlogicとかは自動で誰かが作ってくれるのがあたりまえなんだよな・・・
氏ねや低脳自称SEども

ＳＥさんも頑張っているの。
威張らないと、別の誰かにヌッ殺される運命にあるのよ。
本当はプログラム組みたいのよ。かんべんしてよ。

かあいそうに、、、まともな業務屋と仕事した経験がないんだ、、、そりゃそれじゃ苦労するわ、、、

>>250
おまえは、どの業界へいっても通用しない。

最近この板にド素人がまじりこんでいるよな。
そしてなぜかUMLとかOOについて語りたがる。
事務系のニオイがぷんぷんするんだが。

> そしてなぜかUMLとかOOについて語りたがる。

でも、何にも語れていないのがそれなりに見ていて面白いですね。

>258
おまえまだいたのか

エンジニアの皆様へ
月単価60万円以下で、請け負うのは、辞めましょう。
儲かるのは、人売り屋だけです。

>>260
ブローカーですか。
本人達は、ＩＴ「商社」マンだとか抜かしておりますが。
将軍様のお国と大差ないですな・・・
インドのスーパーＳＥの取分も受注金額の１／３だとか。

>>253
勝手に出来るとは思ってないけどDB設計に比べたら単純作業だとは思うな。

ってかＤＢ設計って超簡単なんだけど・・・・（笑
レベルが低過ぎるよ。

そうかなぁ。業務システムの根幹だしこれが正解みたいのもないから重要かつ難しい部分だと思うな。

>>263
262はレベルの低いことしかやったことがないんだろう。

DBの物理設計って、暗記テストみたいなもんだったりします？

あ、DB設計って、物理設計じゃないよ。論理設計ね。

あー、プログラムでデータ構造作るより単純だよね。

へぇ。まぁせいぜいがんばってインド人 中国人に負けないようにコーディングやってくれよ。

データモデリングが簡単だって?
業務が簡単ならそうだろうね

268は基幹業務システムを作ったことがないんだろう。

>>270
業務が超複雑でも分析過程に比べれば物凄く単純で簡単ですよ♪

分析過程って何のどういう分析？

>272はモデリングを設計フェーズでしかやらないらしいな。

構想を確立することこそ難しい。
具体的な組上げは簡単だよ。（モデリング自体は超簡単！（これも当り前

もちっとレベル上げて下さいな♪

おっとと、注意事項を忘れてしまったよん♪
モデリングの超ブロに失礼な発言だったので補足しておくが、>>274はEXCELやWindowsOSのように
モデリング命な開発を枠外（例外）としていることに注意くださいな。
大規模開発と言えど上記の例のようなモデリング必死な開発はそうそう無いからね♪
もちろん、その主たる技術者は超プロですから元々枠外なお人達です。

>>275
253の発言を受けて
DBの論理設計とその処理ロジックの設計のどちらが
本質的で難しい作業かどうかを問題にしているのです。

「構想を確立することこそ難しい。」
当たり前のことを何をえらそうに語っているのでしょうか。

ahe

データモデルを簡単と言う奴は、学生かコーダーだから無視してよし。
そいつらは、基本的な情報の多面性（受身的な性質）を理解していない。

例えばだ、２chでも他人の文書を如何様にでも受取れるだろ、
それが情報の多面性だ。情報自体は意図をもたない。だから厄介であり融通が利く。

>>279
それは幼稚な論だなぁ〜
まぁ、「ＤＢ設計が出来て一人前」ってのは極普通に言われることなのだが・・・
それって技術者として最低ランクの話なんだよ。

もっともそこに行き着くまで平均して３−５年程度の修行期間がある訳だが・・・(早い人だと１年以内)
だけど所詮は最低ランクの話であり熟練者から見れば「超簡単」な部類なんだよ。

だからさ、モデリングとテーブル設計の違いくらいわかれよ
な
一人前なんだろう?

disturbanceを全てconstraintに落とし込むのは無理だよ

>>279
問題意識があるからこそ、データが初めて情報となる
神の息吹だね
システム設計は極めて恣意的だよ
最初に言葉ありき・・・さ

計算機そのものが純粋な人工物であり恣意的なものだ
例えば the Matrix みたいにね

仕事のきれっぱしをしているだけで、簡単だとかいっているのが痛いんですよ。
ほんとに一から考えるような場合はそれなりに大変。
そんな仕事はありませんけど。

出張32を名乗る者よ。

身の反論じゃ無くて、俺の意見より一つも二つも上行く閲覧者の為になる意見をだせよ。
もう一回チャンスやるから。議論対象者と認めれる意見を出せよ。

>>280
その最低ランクすら奪い合いしないと調達できないSI業界をどう思いますか？
DB設計できる奴がプロジェクト開始段階で調達できる確率10%（泣

というか最近採算ラインが単金50万プロジェクトばっかりで、頼みにしている
連中に逃げられまくりなんですけど・・・・・・

余程恵まれてない環境で働いてるんだろうなぁ。
類は友を呼ぶというか。

>>285
ってか、残念だけどお前さん賢さと技量の両方が足りていないから論対象にならない。

>>286
アフォが多いので商売するには住み易く快適な環境ですね♪

age

利用者が増えるに従って、頭のおかしな人もそれなりに出没するようになって来ています。
頭のおかしな人に関わるとなにかと面倒なことが起こる可能性があるので、注意しましょう。

頭のおかしな人の判定基準

・「みんなの意見」「他の人もそう思ってる」など、自分の意見なのに他人もそう思ってると力説する人
　他人が自分とは違うという事実が受け入れられない人です。自分の意見が通らないとコピペや荒らしなど
　無茶をし始めるので見かけたら放置してください。

・根拠もなく、他人を卑下したり、差別したりする人、自分で自分を褒める人
　他人を卑下することで自分を慰めようとする人です。実生活で他人に褒めてもらう機会がないが
　プライドだけは高いとか、匿名の掲示板しか話し相手のいない人です。可哀想なので放置してください。

・自分の感情だけ書く人
「〜〜がムカツク」とか自分の感情を掲示板に書くことに意味があると思っている人です。
何がどのようにムカツクのか論理的に書いてあれば、他人が読んでも意味のある文章になりますが、
そういった論理的思考の出来ない人です。もうちょっと賢くなるまでは放置してあげてください。

出張32は二点目にまさに合致する人物と思われます。
彼の言う事は無視して議論を続けましょう。

>>290
そういう人ですか。情報ありがとう。

業務システムにおけるデータとプロセスは、結果と経過の関係ともいえる。
結果の連続が経過であり、経過の一時的状況が結果である。

つまり最初＆最終インタフェース以外の設計におけるデータ定義とプロセス定義は
どちらにも変換可能だからどっちが難しいとか簡単とか定義は出来ない。

逆にそんな難易度定義が出来ると言う事は、
設計におけるデータとプロセスの変換性を知らないと言う事になる。

例としては、集計テーブルは集計プロセスをデータ化したものだ。

若い人には目新しい技法に目を奪われず、こういう基本的な所を抑えて欲しいと思うし。
こう言う基本的な事を教える先輩方々が増えて欲しいものだ。

って俺も若いけどｗ

>>291
君は根本から勘違いしている。

> つまり最初＆最終インタフェース以外の設計におけるデータ定義とプロセス定義は
> どちらにも変換可能だからどっちが難しいとか簡単とか定義は出来ない。

これは当り前（但し、当り前の展開に今までなっていなかった。

でだ、分析工程がより難しいとしている理由は、要件定義が不定でありそれを確定する肯定だからだ。
もちろん、論理的手法だけでは行なえない肯定である。
結局、基準となる定義があれば、それを頼りに後は単純作業なんだよ。
もちろん、程度の問題は存在するけどね。
難しいとされる程に予算と時間は与えられていない。
その制限の中で出来るだけ最良を選ぶのだから技量は必要なのだが・・・（そこまででしかない

PS。
投稿文章をちゃんと理解し正しい情報であるか否かを見極める能力を身に付けた方が良いと思うぞ。

×肯定　○工程

>>291
なるほど。興味深い議論ですね。
では、データとプロセスどちらから先に手を付けるのが良いのでしょうか。
※出張32は無視で。

データとプロセスは両方が相手に影響を与える。理想は同時に着手しながら
陶芸の土や手打ちそばのように相互乗り入れで練りあげる時間が必要。
やっつけ仕事でプログラムXXX本、人月YYY人/月とかいう表面上の成果物ばかりに
目がゆくけど生データの分析、問題点指摘、業務ルール、コード運用等の地道な
周辺の仕切が出来るには技術以外に深い業務知識とコミュニケーション能力、大局観
が必要。汎用機分野には熟練したシステム職人がいたけど、オープンの時代の若手中心
の世界ではこの辺の地に足のついた設計・開発・運用まで目が届く人が少なくないか?

そんなユーザ企業の中堅管理職の一人言ですが。

> オープンの時代の若手中心の世界ではこの辺の地に足のついた
> 設計・開発・運用まで目が届く人が少なくないか?

ご指摘通りだよ。
少なくてマトモに機能していないのが実情だ。（改善されるまでにはまだまだ時間が掛かる。
とまぁ〜そんなことで間に合わせとして２流以下の熟練技術者が設計に付くパターンとなる。
ところがその設計者の多くがオープン系をよく知らないので色々と問題が発生している訳だ。

かと言って、未熟者が設計責任者では最初からペケな訳で顧客側での要件定義能力に左右されることになる。
まぁ、そんなことだから私なんかは楽に商売させて貰っている。
アフォと未熟者が殆どな業界は住み易い。

>>290
質問の返答としては、295さんと同意見です。
片方だけから一方的にシステム構築する事は出来ません。

あらゆる仕事は２点以上の軸からせめ、まさしく練りあげる行為が大切だと考えます。

お勉強ばかりでシステム工程考えると、あらゆる工程に分析、設計、実装、検証行為が
存在する事を認識出来ずに、画一的な判断や断片的な視点しか持ちえなくなります。

残念ながら機械相手のシステム開発であっても多くの人間が共同して行う仕事という
前提がある以上は、面倒でも何度でも練り上げる行為が必要です。

テーブル設計とデータモデリングの区別もつかないような奴(32)と
まじめに分析とか設計とか話してもしょうがないよ

>>297
少し違うな。
情報の整合性と発生タイミング、それによる価値の検討。
最初にすることはこれだけだよ。

ここで十分な要件定義を行なってしまうことが大事であり、練り上げるべきは情報そのものなんだよ。
もちろんそこで多くの約束事が定義されるが、ここではまだモデリングやDB設計の必要は無い。
この過程を飛ばして勢いモデリングやDB設計に入るから後戻りが生じる。
一度定義したものを壊すのは難しい。
その結果歪なシステムが出来上がってしまうぞっと。

だいたいメーカ系のシステム屋は後戻りで法外な追加開発料をとりすぎ。
柔軟なシステムは素早いプロトタイプ等で目に見えない物を目に見えるようにする
事が重要。バインダ横一列の玉虫色の役立たず提案書、仕様書にユーザにペタコンと目くら印
をおさせる事しかやってない輩が多し。

建築や都市の設計の一流所はすかさずイメージのわくジオラマをつくり景観、機能性、安全性、
人・車の流れ、商売の動き等・・・・いろんな観点から顧客と対話を続ける。
本当の成功する開発は上流工程〜下流工程、業務知識、見識のある出来の良い
極少数精鋭体制で試作発展型で開発するのが理想だと思う。

表面的なXXXX人月という外注丸投げ・ヤッツケ仕事のSI産業は直に淘汰されるだ
ろうけどね。

プロトタイプを必要に応じて作ることは悪いことではなく寧ろ率先して使うべきだ。
しかし、それはプロトタイプに過ぎないことを明示し開発は要件定義段階のままであることを伝えて置くべきだろう。
開発コストを考慮しないのであれば試行錯誤な開発でも構わないだろうが・・・
それだと後戻り作業が幾らでも出てしまうから大規模開発は不可能といえる。（小規模は可能だ）

痛いところを突かれると相変わらず無視し続けるね、彼は。

>>300

>表面的なXXXX人月という外注丸投げ・ヤッツケ仕事のSI産業は直に淘汰されるだ
>ろうけどね。

それは無いね、それを望んでいるがの結局ユーザなんだから。
今だにそれを理解せずに同行不満を言うユーザが、悪徳ＩＴ企業より一番始末が悪い。

またＩＴ業界は、自分達の侵した過ちを自分達で修正出来ずにメディアや団体を使って情報操作（方向は間違いでは無いと思う。）により
修正しようとしている状態だから非を認めている分、若干マシ。

この低レベルな責任の擦り付け合いを助長するか、チャンスと見るか。
それが自分自身の程度を見分ける指標ともなる。

>>300
>本当の成功する開発は上流工程〜下流工程、業務知識、見識のある出来の良い
>極少数精鋭体制で試作発展型で開発するのが理想だと思う。

それが理想である→同意
それを顧客が望んでいる→そんな顧客はほとんどいない

だな。そんなものに高い単金を払っても良いと考える顧客は皆無。顧客の関心は
「早いい安いｳﾏｰ」が全てだよ。下手すると「狂牛病になってもいいからとにかく早い安いｳﾏｰ」。

そもそもうまいものくったことないから
なんでもｳﾏｰ

バカがレスつけなきゃ優良スレになりそうなのにな

>>306
バカがつけるレスの一例。

そうね。出張は消えてほしいね。

そんな寂しいこと言うなよ

>下手すると「狂牛病になってもいいからとにかく早い安いｳﾏｰ」。
で、狂牛病になったら文句言うんだろ？

┌──┐ 　 　 　 　 　┌──┐
｜　 警｜ 　 　 　 　 　｜　 警｜
├──┼─　 　 ┌──┐─┼─
｜・∀・｜　 　 ┌┤'A`　├┐｜ 死なせてよー
｜〜 　┌───┘　 　 ｜　 ｜
｜ 　─┤　 　 　 　 　 　 ｜　 ｜
｜ 　─┤　 　 　 　 　 　 ｜　 ｜
└┬┬└──────┘┬┘
　 ｜｜　 　 　 　 　 　 　 ｜｜

■□■【2005年度SI企業ランギング】■□■
71　野村総研(NRI) NTT-DATA 日本IBM
---↑東大・京大ライン↑-----
70　べリングポイント [Microsoft] [Oracle] [Sun]
---↑一橋・東工大ライン↑-----
69　富士通 NEC 電通国際情報サービス(ISID)
68　日立製作所 日本総研　
---↑旧帝国大学・早慶ライン↑-----
67　HP(Hewlett-Packard) アビームコンサルティング IBMビジネスコンサルティングサービス
66 　大和総研 みずほ情報総研 Accenture [SAP]　[Cisco]
65 　日本ユニシス 新日鉄ソリューションズ(NS-sol) 伊藤忠テクノサイエンス(CTC）
64　 日立ソフトウェアエンジニアリング　NTTコムウェア
---↑神戸・筑波・東京外語・お茶・横国・都立・上智・ICU・東京理科・同志社ライン↑-----
63 　沖電気工業 　住商情報システム(SCS)　フューチャーシステムコンサルティング
62　TIS オービック 三井情報開発　日立情報システムズ　NECソフト
61　東芝情報システム　CRCソリューションズ　CSK ソニーグローバルソリューションズ
60　NTTソフト 日立システム＆サービス　富士通FIP JR東日本情報システム JRシステム
---↑中位駅弁大学・明治・立教・青学・中央・法政・学習院・立命館・関学・関大ライン↑-----
59　CEC　富士通システムソリューションズ(Fsol)　東京海上システム開発　[日本NCR]
58　オージス総研 インフォテック　ダイヤモンドコンピュータサービス ニッセイ情報テクノロジー
57　 NECネクサスソリューションズ　富士通ビジネスシステム(FJB)　日立電子サービス アルゴ21
56　 富士通アドバンストソリューションズ(FASOL) さくら情報システム　
---↑下位駅弁大学↑-----
55　ニイウス　日本情報産業　インフォコム トヨタコミュニケーションシステム
54　日本情報通信 日立ビジネスソリューション クレスコ　
53　富士通中部システムズ(FJCL) 　富士通関西システムズ(FKS) 大塚商会
52　NTTデータクリエイション NTTデータクオリティ 　NTTデータネッツ　NECフィールディング
51　NK-EXA NTTデータCS 日本フィッツ アイネス [ISE] CAC
41〜50　CSKネットワークシステムズ
---↑日東駒専ライン↑-----

もう就職活動のシーズンか。。。

業務アプリのエンジニアって性格悪いやつ多いねえ。
考え方が古くて閉じられてるし。
仕事じゃオープン系の技術使ってたりするのになｗ
消えろや。いらねえよ。

>>314
その考えが古くて閉じられている。
しかも、性格以上に頭が悪いな。
でも、お前みたい奴は必要だ。底辺は組織に必要

うるせんだテメエは。

図星ｶﾖ

ｵｯﾊﾟ━━━━(((（（（　。　人　。　）））)))━━━━ｲ!!!!

実態がわからない

age

どうした、恥じたのかい。悔いたのかい。
便所の落書きと違う事が解ってやったんだろうが！

最下層0669

富士データシステム
の社長のやーーーまだ！セレブ気取りの馬鹿！

三流以下のソフト開発で全国の福祉施設
を食い物にしている悪徳会社。うんこ会社！

>>323
尼の会社？

あげ

いつまでも子供みたいな事で。。。

図星ｶﾖ

毎日人の悪口を書きまくっている粘着バカ永宗はここにもいるのか！
毎日人の悪口を書きまくっている粘着バカ永宗はここにもいるのか！
毎日人の悪口を書きまくっている粘着バカ永宗はここにもいるのか！
毎日人の悪口を書きまくっている粘着バカ永宗はここにもいるのか！
毎日人の悪口を書きまくっている粘着バカ永宗はここにもいるのか！

あげ