業務系の人って痛いよねｗ
1 ：仕様書無しさん：
業務系の人って痛いよねｗ
|
|
|
2 ：(^ｰ')b ◆EoOYgmEaZE ：2005/05/20(金) 23:35:18
だよねー^^
3 ：仕様書無しさん：2005/05/20(金) 23:38:30
このスレ痛いよねーw
また無駄なスレが一つ立った。
そして、誰かのスレ立て権が復活した。
そして、誰かのスレ立て権が復活した。
蓼食う虫もｓ好き
ｸｿｽﾚ立てるﾔｼって痛いよねw
>>1
詳しく。
詳しく。
8 ：仕様書無しさん：2005/05/21(土) 00:19:42
ハーバード・ビジネス・レビューの最新号に載ってる、
ロバート S.キャプラン教授の時間主導型ABCマネジメントってどうよ？
ロバート S.キャプラン教授の時間主導型ABCマネジメントってどうよ？
何も知らない低学歴な若者が「知的で創造的な仕事」と勘違いしてプログラマなるものを目指すが、
低学歴無知識の人間が高度な分野の会社に入れるわけもなく、痛い業務系ドカタとなり奴隷のように扱われて
「プログラマなんかなるもんじゃない」と２ちゃんで愚痴る。
こういう可哀想な人間を減らすためにも業務系の痛さは教えておいたほうがいい。
低学歴無知識の人間が高度な分野の会社に入れるわけもなく、痛い業務系ドカタとなり奴隷のように扱われて
「プログラマなんかなるもんじゃない」と２ちゃんで愚痴る。
こういう可哀想な人間を減らすためにも業務系の痛さは教えておいたほうがいい。
在庫管理・売り上げ管理・顧客管理とかの事務系
工学や理学の知識がほとんど要らない
人海戦術での力仕事開発
工学や理学の知識がほとんど要らない
人海戦術での力仕事開発
12 ：仕様書無しさん：2005/05/21(土) 00:28:30
頭悪いののために、こんな痛いｽﾚを立てる>>1も、
相当頭が悪い暇人と見たｗ
相当頭が悪い暇人と見たｗ
13 ：仕様書無しさん：2005/05/21(土) 00:31:40
・受託開発
・特定の客向けのカスタムメイド
・ほとんど似たプログラムのスクラップ＆ビルドの繰り返し
・他人が作ったライブラリ・フレームワークに肉を付けるだけ
・アセンブラや C/C++ よりも Java や COBOL、PHP など
・特定の客向けのカスタムメイド
・ほとんど似たプログラムのスクラップ＆ビルドの繰り返し
・他人が作ったライブラリ・フレームワークに肉を付けるだけ
・アセンブラや C/C++ よりも Java や COBOL、PHP など
>>11が頭の使い方を知らない業務系PGだってことはよく分かった。
15 ：仕様書無しさん：2005/05/21(土) 00:34:12
・「帳票」がキーワード
16 ：仕様書無しさん：2005/05/21(土) 00:35:06
どんな仕事なのか調べもせずにこの業界に入ってくる奴らも問題だが、
そういう奴らをかき集め経歴ごまかして一山いくらで売り飛ばして
金儲けしようとする奴らも問題。
そういう奴らをかき集め経歴ごまかして一山いくらで売り飛ばして
金儲けしようとする奴らも問題。
18 ：仕様書無しさん：2005/05/21(土) 00:37:11
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
素人妄想ｽﾚ
乙かれちゃん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
素人妄想ｽﾚ
乙かれちゃん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>16
マルチメディア系、シミュレーション系、制御系、通信系、ミドルウェア系・・・
マルチメディア系、シミュレーション系、制御系、通信系、ミドルウェア系・・・
マジ質問なんだが、欧米でも業務系はこんなにひどいのか？
日本だけの現象？
日本だけの現象？
＞制御系、通信系
爆笑
爆笑
23 ：仕様書無しさん：2005/05/21(土) 00:40:12
>>21
痛いのはオマエの頭
痛いのはオマエの頭
仕事に痛いも痛くないもないのです
例えば>>1のような痛い人にはそれが解らんのです
例えば>>1のような痛い人にはそれが解らんのです
>>16がネタじゃないならそうとう痛いなｗ
26 ：仕様書無しさん：2005/05/21(土) 00:42:33
マルチメディア系＝フラッシュ職人？
日本じゃ優秀な理系はメーカーに流れる
29 ：仕様書無しさん：2005/05/21(土) 00:47:42
>>28
おじいちゃんは、何も言わなくていいんだよ。
おじいちゃんは、何も言わなくていいんだよ。
業務系アプリの人ってよく馬鹿にされてるけど、
この板の人から見たら共通クラスライブラリとかフレームワーク作る人もレベル低いの？
自分はVCやってて、アプリの下層はC++っつーかC言語風の開発だし
馬鹿にされるのは分かるんだけど
共通ライブラリでレコードデータ格納クラスとかのソース読んでるとすげーなと思うんだが。
本当にeffectiveC++やらMore～やらで書かれてる(もしくはそれ以上)とおりに
組んでるじゃん！って感動したんだけど。
こんなので感動してる俺が低レベルなのは間違いないんだろうけど、
上で挙げたような人も制御系やゲームのプログラマに比べたら大したことないの？
この板の人から見たら共通クラスライブラリとかフレームワーク作る人もレベル低いの？
自分はVCやってて、アプリの下層はC++っつーかC言語風の開発だし
馬鹿にされるのは分かるんだけど
共通ライブラリでレコードデータ格納クラスとかのソース読んでるとすげーなと思うんだが。
本当にeffectiveC++やらMore～やらで書かれてる(もしくはそれ以上)とおりに
組んでるじゃん！って感動したんだけど。
こんなので感動してる俺が低レベルなのは間違いないんだろうけど、
上で挙げたような人も制御系やゲームのプログラマに比べたら大したことないの？
35 ：仕様書無しさん：2005/05/21(土) 00:52:43
>>28
おじいちゃんは、今週のIPA祭りに行きましたか？
おじいちゃんは、今週のIPA祭りに行きましたか？
36 ：仕様書無しさん：2005/05/21(土) 00:53:44
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
素人妄想ｽﾚ
乙かれちゃん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
素人妄想ｽﾚ
乙かれちゃん
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>34
おじいちゃんは、何も言わなくていいんだよ。
おじいちゃんは、何も言わなくていいんだよ。
39 ：仕様書無しさん：2005/05/21(土) 00:56:37
業務系ってわけのわかんないなんとかフレーム枠とかいって、
新規案件を作り出すようなことまだやってるの？
新規案件を作り出すようなことまだやってるの？
42 ：仕様書無しさん：2005/05/21(土) 01:04:24
スレタイトルが「葉鍵系の人って痛いよねｗ」に見えたのは俺だけで良いw
>>42
難しいお話してるから迷惑かけちゃ駄目だよ。さあ一緒に帰ろう。
難しいお話してるから迷惑かけちゃ駄目だよ。さあ一緒に帰ろう。
業務アプリって技術的にたいしたことない上に、対象となるものが技術とはなんの関係もない
業界ルールだったり社内慣習なわけだから、優秀な技術者が魅力を感じないってのが
あるな。
それから、質の高いものを効率よく作るより人月を多くしたほうが儲かる という馬鹿げた
慣習はなんとかならんのか。
業界ルールだったり社内慣習なわけだから、優秀な技術者が魅力を感じないってのが
あるな。
それから、質の高いものを効率よく作るより人月を多くしたほうが儲かる という馬鹿げた
慣習はなんとかならんのか。
>>44
時代に乗り遅れすぎ。
時代に乗り遅れすぎ。
「高卒可」「文系可」
これが全て。
これが全て。
48 ：仕様書無しさん：2005/05/21(土) 01:16:49
>>44
高卒専門卒の場合はどうか知らんが、少なくとも理系大卒の場合、そもそも
人間が決めたルールや契約に支配された世界よりも、自然法則に支配された世界に
魅力を感じて理系の世界に進んだ香具師が多いだろうからねえ。
高卒専門卒の場合はどうか知らんが、少なくとも理系大卒の場合、そもそも
人間が決めたルールや契約に支配された世界よりも、自然法則に支配された世界に
魅力を感じて理系の世界に進んだ香具師が多いだろうからねえ。
社会科学を勉強したくて文系に進んだ奴と 数学ができなくて文系に進んだ奴がいるわけだが、
この業界にやってくるのは・・ｗ
この業界にやってくるのは・・ｗ
業務系の人って３０過ぎたらどうするの？
業務知識を生かしてスーパーやコンビニでバイト？
業務知識を生かしてスーパーやコンビニでバイト？
51 ：仕様書無しさん：2005/05/21(土) 01:28:58
スレとはあんまり関係ないが、
ロボット動かしたり映像をデジタル化したり３Dのゲームを作ったりするのに、
いかに数学の知識が必要かを中高生にはきちんと教えるべきではなかろうか。
ロボット動かしたり映像をデジタル化したり３Dのゲームを作ったりするのに、
いかに数学の知識が必要かを中高生にはきちんと教えるべきではなかろうか。
>>51
ヒントを見る限りじゃ、お前が大きな勘違いをしているように見えるがｗ
ヒントを見る限りじゃ、お前が大きな勘違いをしているように見えるがｗ
何かの本で読んだが、高校生に数学と物理を絡めて教えるのは「禁止」されているらしい。
速度を微分したら加速度になるとか、積分をつかえば走った距離がわかる という教え方を
したらいけないんだそうな。
速度を微分したら加速度になるとか、積分をつかえば走った距離がわかる という教え方を
したらいけないんだそうな。
55 ：仕様書無しさん：2005/05/21(土) 01:43:00
ところで業務系以外の人は何が優れてんの？
58 ：仕様書無しさん：2005/05/21(土) 01:51:49
>>54
漏れが高校の頃は物理の電気回路の授業とかではﾊﾞﾘﾊﾞﾘ微積分使ってたんだけど、
時代が変わったんだなあ。
大学の電気系に進学してからの方が、むしろ簡略された計算法を習って四則演算が
多くなったり（ｗ
漏れが高校の頃は物理の電気回路の授業とかではﾊﾞﾘﾊﾞﾘ微積分使ってたんだけど、
時代が変わったんだなあ。
大学の電気系に進学してからの方が、むしろ簡略された計算法を習って四則演算が
多くなったり（ｗ
59 ：仕様書無しさん：2005/05/21(土) 01:55:09
業務系以外の人が数学とか物理に詳しいのはわかるんだけど
銀行員やら証券会社の人間と金融の話できないでしょ？
銀行員やら証券会社の人間と金融の話できないでしょ？
60 ：仕様書無しさん：2005/05/21(土) 01:55:18
・・・まぁ、ここの学生がほざいてられるのも、
学生で居るうちだけだろう・・・
おまえよりよっぽどいい学歴だけど。
学生で居るうちだけだろう・・・
おまえよりよっぽどいい学歴だけど。
61 ：仕様書無しさん：2005/05/21(土) 01:58:14
業務系の人達はこういう(>>60-61)感じで争うのが痛いねｗ
63 ：仕様書無しさん：2005/05/21(土) 02:04:52
学部生→修士→博士→ポス毒→赤ポス→研究員→助教授→教授→学部長→学長→・・・
↓ ＼ ↓ ＼ ↓ ／ ↓ ↓ ↓ ↓ ↓ ↓
現場←開発職←研究職←フリー←←←←←＋←←ちょっとずれてる人
↓ ↓ ↓ ：
よくわからない人 会社経営等
↓ ＼ ↓ ＼ ↓ ／ ↓ ↓ ↓ ↓ ↓ ↓
現場←開発職←研究職←フリー←←←←←＋←←ちょっとずれてる人
↓ ↓ ↓ ：
よくわからない人 会社経営等
64 ：仕様書無しさん：2005/05/21(土) 02:07:00
なんちゃって。
学部卒でも脳減る症もらえるらしいしｗ
学部卒でも、そこらの教授よりよっぽど進んだ基礎研究やってるのも居るしｗ
学部卒でも脳減る症もらえるらしいしｗ
学部卒でも、そこらの教授よりよっぽど進んだ基礎研究やってるのも居るしｗ
65 ：仕様書無しさん：2005/05/21(土) 02:07:52
>>37 痛々しい自慢だなｗ
66 ：仕様書無しさん：2005/05/21(土) 02:12:22
目糞鼻糞を笑うっていう言葉はおまえらのためにある言葉だな。
67 ：仕様書無しさん：2005/05/21(土) 02:13:26
>>45
ごめん。まじでなんで>>44が時代に乗り遅れてるのかわかんねーや。
時代に乗り遅れてすぎてるオレの為に詳しく説明してくれ。
ばかばかしいとかくだらない理由はつけないで
無知な私にご教示ください。
※ヒントとかなしで
ごめん。まじでなんで>>44が時代に乗り遅れてるのかわかんねーや。
時代に乗り遅れてすぎてるオレの為に詳しく説明してくれ。
ばかばかしいとかくだらない理由はつけないで
無知な私にご教示ください。
※ヒントとかなしで
まめまめまーめ？
=====================
ﾗﾍﾞﾙの低いｽﾚでちゅね！
=====================
ﾗﾍﾞﾙの低いｽﾚでちゅね！
=====================
70 ：仕様書無しさん：2005/05/21(土) 02:16:26
帰宅のあそこはひどかったｗ
想像の範囲外だったな、マジ
想像の範囲外だったな、マジ
>>67
追い詰めるんじゃねーよ 可愛そうだろｗ
追い詰めるんじゃねーよ 可愛そうだろｗ
業務系って最大開発期間が3ヶ月なんでCとか使ってられないんです。
業務系って平均学歴が帝京大学文学部とかなんで（ｒｙ
>>73
期間は関係ないだろよ。
期間は関係ないだろよ。
関係ないと本当に言い切れるだろうか
よく考えてみよう
よく考えてみよう
例えばVBを使えばCを使うより短期間で同品質のものができるのなら、
世の中からCはなくなっているだろう。
世の中からCはなくなっているだろう。
>>77
適材適所だろｗ
適材適所だろｗ
そりゃー知らなんだ。
高専卒とか、旧制高校卒なら、結構多そうだけど。
高専卒とか、旧制高校卒なら、結構多そうだけど。
＞業務系って最大開発期間が3ヶ月
なるへっそ。 随分下っ端なのね
なるへっそ。 随分下っ端なのね
開発期間や頭数でものを語るのが業務系ならではというところでしょうかｗ
研究員なら学会発表や論文という客観的な評価があるから実力主義と言えない事もないが、
実際のところ有名大院卒以外が研究職につける可能性はきわめて低い
実際のところ有名大院卒以外が研究職につける可能性はきわめて低い
鼻息荒くゲーム会社に入ってきた新人が、まったくついていけずに業務系や２次元エロゲーに
転向しようか思い悩む季節。
転向しようか思い悩む季節。
>>83
ああ。業界知識ない人だからしょうがないな。
赤ポスと違って、企業の研究所はそんな無意味なハードルはねぇよ。
基礎研ならいざしらず、中研ならふつーに新卒採用してる。
総研とかSIerの偽研究所なら、入社して３年で研究員（ｗ
ああ。業界知識ない人だからしょうがないな。
赤ポスと違って、企業の研究所はそんな無意味なハードルはねぇよ。
基礎研ならいざしらず、中研ならふつーに新卒採用してる。
総研とかSIerの偽研究所なら、入社して３年で研究員（ｗ
86 ：仕様書無しさん：2005/05/21(土) 14:10:18
業務系をもっと具体的というか、細分化して欲しいな。
ビジネス向けパッケージソフト（を作る側）も業務系なの？
ビジネス向けパッケージソフト（を作る側）も業務系なの？
会計や在庫管理のパッケージなら業務系じゃね？
特定顧客向けソフトみたいに「バグは運用でカバー」とか
「バグは現場でつぶす」みたいなコントは許されないだろうから
多少はシビアかも知れんが。
特定顧客向けソフトみたいに「バグは運用でカバー」とか
「バグは現場でつぶす」みたいなコントは許されないだろうから
多少はシビアかも知れんが。
業務系じゃなくとも、飯食う時間を惜しんでカップ麺かっ食らい、ぷちぷちを身に包んで寝る生活が痛くないかといえば（ｒｙ
89 ： ：2005/05/21(土) 14:55:23
オープン系はどうしてやりましょうか？
92 ：仕様書無しさん：2005/05/21(土) 16:07:29
ヨドバシやヤマダ電機に置けそうにないのは、いくら「パッケージ」と名乗っても
業務系のような気がする。
業務系のような気がする。
93 ：仕様書無しさん：2005/05/21(土) 16:17:24
くだらねぇなおまえらって。
驚速ADSLとか
理系仕事か文系仕事かの違い
業務系だけど、可愛い彼女とﾁｮﾒﾁｮﾒして幸せな俺は勝ち組
98 ： ：2005/05/23(月) 00:14:24
>>97 ミニ豚衛門をめざせよ。
金目当てと言うが、容姿ならいいのか？ “生き方が好き”とか
言われてみたいとか？ 所詮人間は、特に女は打算の生き物、男に依存して
生きる物。 金も人格の一部だ。自信もって、金目当ての女が集るとこに
いってこい。
金目当てと言うが、容姿ならいいのか？ “生き方が好き”とか
言われてみたいとか？ 所詮人間は、特に女は打算の生き物、男に依存して
生きる物。 金も人格の一部だ。自信もって、金目当ての女が集るとこに
いってこい。
99 ：仕様書無しさん：2005/05/23(月) 15:27:01
技術的水準の低さを承知の上でやってるならまぁ別にいいが、
それを理解してない奴は確かに痛いと思う。
それを理解してない奴は確かに痛いと思う。
100 ：仕様書無しさん：2005/05/23(月) 15:55:23
ここ１年以上、業務系のアフォな会社に関わっていたおかげで、
みっちり１年分浦島太郎になっちまった。
なんだかんだで手付かずのままだった Spring Framework, PicoContainer, Seasar周りをフォローするため、
http://www.kakutani.com/trans/fowler/injection.html
など追っかけ中。。。
自称業界随一のコンサルがやってる筈の会社に行って、なんでこんなに時流から取り残されるんだろう？
みっちり１年分浦島太郎になっちまった。
なんだかんだで手付かずのままだった Spring Framework, PicoContainer, Seasar周りをフォローするため、
http://www.kakutani.com/trans/fowler/injection.html
など追っかけ中。。。
自称業界随一のコンサルがやってる筈の会社に行って、なんでこんなに時流から取り残されるんだろう？
>>100
アルファ・ギーク、アーリー・アダプターである事を避けるってのは
防御というか保身というかそういう価値観を持つコンサルなら
まあアリなんじゃないの？
作ってる方からすると頭腐ってきそうでやってらんねーけどな。
DIコンテナなんかはかなり実案件回ってるみたいだし
アーリーアダプターといっていいかはまた別だけど。
やっぱ、使いたいよねー。
アルファ・ギーク、アーリー・アダプターである事を避けるってのは
防御というか保身というかそういう価値観を持つコンサルなら
まあアリなんじゃないの？
作ってる方からすると頭腐ってきそうでやってらんねーけどな。
DIコンテナなんかはかなり実案件回ってるみたいだし
アーリーアダプターといっていいかはまた別だけど。
やっぱ、使いたいよねー。
アルファギークってのはコンサルだのとはまた別だなーすまん。
アーリーアダプターうんぬんはこっち。
http://www.atmarkit.co.jp/aig/04biz/earlyadapter.html
アーリーアダプターうんぬんはこっち。
http://www.atmarkit.co.jp/aig/04biz/earlyadapter.html
103 ：仕様書無しさん：2005/05/23(月) 17:18:22
なんだ、コンサルって問題解決には最新技術の創出と適用も厭わないのかと思ったら(例: Martin Fowler)、
国内のコンサルは勇気がない知恵遅れなんかよ。
相手して損したあるよ
国内のコンサルは勇気がない知恵遅れなんかよ。
相手して損したあるよ
>>103
ファウラーなんて、芸能人みたいなもんですよ。
もう大スターですから、すべからくコンサルにあのレベルを
求めるのは酷ってもんです。
あそこまでイノベーターで居られて
ちゃんと収益をあげるってのは凄いと思うよ。
書籍であーだこーだぬかすだけってんじゃないんだもんねー。
一緒に仕事した人で、
一歩流行遅れ、これが成功の秘訣だ、って
説教してくれたお方もおりましたよ。
ファウラーなんて、芸能人みたいなもんですよ。
もう大スターですから、すべからくコンサルにあのレベルを
求めるのは酷ってもんです。
あそこまでイノベーターで居られて
ちゃんと収益をあげるってのは凄いと思うよ。
書籍であーだこーだぬかすだけってんじゃないんだもんねー。
一緒に仕事した人で、
一歩流行遅れ、これが成功の秘訣だ、って
説教してくれたお方もおりましたよ。
で、その流行遅れ主義の人のプロジェクト、
面白い事にそういう姿勢ってのは
コーディングにまで波及するもんで、
当然の如くコピペの嵐でねぇ。
二度と関わりあいたくないよ。
でも、アナパタ読むとドメインモデルは
ドメインの専門家であるお客さんはすぐに理解するって
書いてあるけど、無理、絶対！
そらあんただから出来るんだよ！ってツッコミ入れたくなります。
面白い事にそういう姿勢ってのは
コーディングにまで波及するもんで、
当然の如くコピペの嵐でねぇ。
二度と関わりあいたくないよ。
でも、アナパタ読むとドメインモデルは
ドメインの専門家であるお客さんはすぐに理解するって
書いてあるけど、無理、絶対！
そらあんただから出来るんだよ！ってツッコミ入れたくなります。
＞一歩流行遅れ、これが成功の秘訣だ、って
これに関しては正論じゃない？
一部を除いて業務アプリで最新技術を取り込む必要もないし、
現状の業務系技術者のレベルを考えると危険すぎるｗ
これに関しては正論じゃない？
一部を除いて業務アプリで最新技術を取り込む必要もないし、
現状の業務系技術者のレベルを考えると危険すぎるｗ
無知で勉強しない客をカモに、大風呂敷広げまくりのＳＩ会社が受注し、
それを「安さ日本一」だけが売りのド素人軍団ソフト会社が開発する。
こんなすごい業界ほかにもあるんだろうかｗ
それを「安さ日本一」だけが売りのド素人軍団ソフト会社が開発する。
こんなすごい業界ほかにもあるんだろうかｗ
108 ：103：2005/05/23(月) 18:03:43
別に無理に「最新」とやらに拘るつもりはないんだが。
例えばユーザ企業の情報システム部に、
なんか変な事言っているからよく聞いて見ると、
どうもアナパタと同じ種類の問題意識を持って、
それを苦労して自分の言葉で説明しようとされる
・・・いわゆる天然物つうか原石みたいな方が居て、
おもろいから長い目で付き合おうって事で、
こっちも気合入れて調べ事始めたんだけど、
間に入ってるSIerが話を全部幼稚で頓珍漢なものとして
貶めちゃおうとするんで、非常に難儀をした。・・・つか契約取れなかった。
こーゆーお客さんの意図を汲むには、
やっぱ最新だろうと未開拓だろうと、切り込む姿勢も欲しかったな、と。
あ、コンサルが悪いわけじゃないなｗ
例えばユーザ企業の情報システム部に、
なんか変な事言っているからよく聞いて見ると、
どうもアナパタと同じ種類の問題意識を持って、
それを苦労して自分の言葉で説明しようとされる
・・・いわゆる天然物つうか原石みたいな方が居て、
おもろいから長い目で付き合おうって事で、
こっちも気合入れて調べ事始めたんだけど、
間に入ってるSIerが話を全部幼稚で頓珍漢なものとして
貶めちゃおうとするんで、非常に難儀をした。・・・つか契約取れなかった。
こーゆーお客さんの意図を汲むには、
やっぱ最新だろうと未開拓だろうと、切り込む姿勢も欲しかったな、と。
あ、コンサルが悪いわけじゃないなｗ
>>106
んまー、程度によるよ・・・・。
スローガンとして「一歩流行遅れ」ってのはアリかも知れないけど
やってるのって過去案件のプロダクトのコピー生産の奨励だったり
それが作りやすいんだったらいいけど、とんでもなく手間がかかる奴で
結局見積もりしやすいとかスパイクするコストは勿体無いとか
凄く後ろ向きな理由なんだよねぇ。
だから作る側からすると、例えば、工数減るんだからO/Rマッピング使おうよ、とかさ、
提案したい事一杯あるのに、実績とか調べもせずに冒険は許さんじゃ
作る人間のモチベーションもションボリルドルフですよ。
ずーっとJDBCゴリゴリ書くかと思うと、いやだよー。
業務系技術者のレベルを考えると、トランザクションとかは
AOPで判ってる人がねじ込んだりの方が良くない？
んまー、程度によるよ・・・・。
スローガンとして「一歩流行遅れ」ってのはアリかも知れないけど
やってるのって過去案件のプロダクトのコピー生産の奨励だったり
それが作りやすいんだったらいいけど、とんでもなく手間がかかる奴で
結局見積もりしやすいとかスパイクするコストは勿体無いとか
凄く後ろ向きな理由なんだよねぇ。
だから作る側からすると、例えば、工数減るんだからO/Rマッピング使おうよ、とかさ、
提案したい事一杯あるのに、実績とか調べもせずに冒険は許さんじゃ
作る人間のモチベーションもションボリルドルフですよ。
ずーっとJDBCゴリゴリ書くかと思うと、いやだよー。
業務系技術者のレベルを考えると、トランザクションとかは
AOPで判ってる人がねじ込んだりの方が良くない？
>>108
うわーそれ勿体無い！凄い羨ましい・・・・。
うわーそれ勿体無い！凄い羨ましい・・・・。
結局業務系SEって
ソーシャル・エンジニアなんだよなあ・・・・。
確かに、痛いよね（スレタイに沿ってみた）
ソーシャル・エンジニアなんだよなあ・・・・。
確かに、痛いよね（スレタイに沿ってみた）
↑(スレタイをローカライズしてみた)
「一歩流行遅れ」って他人が慣らした道をあるくってことだから、俺はそうしたい。
自分がはじめて使って、落とし穴にはまりまくって、脱出法を３テツで見つけ出した
苦労を、後から来たやつは「どうすればいいの？」ってだけですり抜けて行く。
やってらんねー。
自分がはじめて使って、落とし穴にはまりまくって、脱出法を３テツで見つけ出した
苦労を、後から来たやつは「どうすればいいの？」ってだけですり抜けて行く。
やってらんねー。
人の後ろを歩く人は、好きな所に逝けない。人と同じ回避策しかとれない。
だから、つまんねぇ
だから、つまんねぇ
一歩ならいいんだが五歩のこともしばしばｗ
技術者のレベルいかんでは、「大人の選択」として十歩遅らすプロのマネージャーもいるらしいｗ
技術者のレベルいかんでは、「大人の選択」として十歩遅らすプロのマネージャーもいるらしいｗ
117 ：仕様書無しさん：2005/05/23(月) 21:26:20
そうか。
俺は元豆蔵社長が役員やってる会社に間違って入っちまったんだが、
中の連中は構造化設計すらおぼつかないようなのばっかで、騙されたと感じた。
きっと元豆蔵の彼も、>>116と同じような思いで仕事していたんだろうな。
そーゆー低レベルな現場に、豆蔵の看板ちらつかせて他人を巻き込むような真似は、
やってほしくなかったんだが。
俺は元豆蔵社長が役員やってる会社に間違って入っちまったんだが、
中の連中は構造化設計すらおぼつかないようなのばっかで、騙されたと感じた。
きっと元豆蔵の彼も、>>116と同じような思いで仕事していたんだろうな。
そーゆー低レベルな現場に、豆蔵の看板ちらつかせて他人を巻き込むような真似は、
やってほしくなかったんだが。
豆蔵関係者って聞いて、さっさと断らねぇお前がバカｗ
わが国の業務系のレベルが低いのはパッケージが発達してないというのも原因ではないか？
客がシロウトな癖になぜか「独自システムを構築すれば差別化がはかれて収益力アップ」
とかいう発想でいるから、一山いくらのDQN技術者潜り込ませビジネス市場ができあがっている
ような気がする。
客がシロウトな癖になぜか「独自システムを構築すれば差別化がはかれて収益力アップ」
とかいう発想でいるから、一山いくらのDQN技術者潜り込ませビジネス市場ができあがっている
ような気がする。
120 ：仕様書無しさん：2005/05/23(月) 22:14:01
>>118
ああ、俺も豆には妙な胡散臭さを感じてたから、よっぽど断ろうと思った。
他にもいくつか面白そうな仕事があったからな。
ただ、いまどきオブジェクト指向を前面に出して、
他じゃ見た事も無い職種で募集してたから、入っちまったよ(泣
一応、内定出てから大急ぎで同業他社に応募出して、
妙な評判がないかどうか探りを入れたんだが。
特に悪評がない・・・つうより無名すぎて誰も知らなかったという・・・
ああ、俺も豆には妙な胡散臭さを感じてたから、よっぽど断ろうと思った。
他にもいくつか面白そうな仕事があったからな。
ただ、いまどきオブジェクト指向を前面に出して、
他じゃ見た事も無い職種で募集してたから、入っちまったよ(泣
一応、内定出てから大急ぎで同業他社に応募出して、
妙な評判がないかどうか探りを入れたんだが。
特に悪評がない・・・つうより無名すぎて誰も知らなかったという・・・
122 ：仕様書無しさん：2005/05/23(月) 22:25:22
無名な元豆関係者って時点で気付けよ！
123 ：仕様書無しさん：2005/05/23(月) 22:26:58
ところで、妙に事情通な事を言っていた
>>116はどこに逝ったんだ？
>>116はどこに逝ったんだ？
125 ：仕様書無しさん：2005/05/23(月) 22:36:12
仲間なんて……たくさんだ。孤独に生きる。
そう言う人に業務系は向いている。助けも庇いもしない。
そう言う人に業務系は向いている。助けも庇いもしない。
>>116＝119
外資の投資会社から見ると、
「日本の会社は経営者不在の宝の山」なんだそうだ。
つまり現在居る経営者に経営スキルがないから、
本来その企業が持っているパフォーマンスを充分発揮できずに居る、という事だ。
これは、経営者のみならず、株主、従業員にとっても非常に不幸な事だ。
なぜなら、いくら優れた従業員が入っても、経営者に判断力と行動力がないから
決してその従業員の才能を生かす事ができず、結果、株主に対する配当も出ないからだ。
キミのような人間には、まず経営スキルを磨く事を薦める。
外資の投資会社から見ると、
「日本の会社は経営者不在の宝の山」なんだそうだ。
つまり現在居る経営者に経営スキルがないから、
本来その企業が持っているパフォーマンスを充分発揮できずに居る、という事だ。
これは、経営者のみならず、株主、従業員にとっても非常に不幸な事だ。
なぜなら、いくら優れた従業員が入っても、経営者に判断力と行動力がないから
決してその従業員の才能を生かす事ができず、結果、株主に対する配当も出ないからだ。
キミのような人間には、まず経営スキルを磨く事を薦める。
高学歴だと何かマズイんですか？
あそこはIT業界のMITをうたってられるので、
私の大学院時代の研究成果を生かせると考えたんですが。
あそこはIT業界のMITをうたってられるので、
私の大学院時代の研究成果を生かせると考えたんですが。
131 ：128：2005/05/23(月) 23:56:14
なんだ、単なる煽りかよ
>>131
あそこは元経営者が強烈な２ちゃねらーで、
元居た会社のスレ立てて暴れまわってるから、気をつけた方がいい。
ここで余計な事言うと、何年間でも粘着されるぞ。俺はかれこれ４年位かな。
内定の方は、検討に値すると思う。特に地雷が居なくなった今ならな。
あそこは元経営者が強烈な２ちゃねらーで、
元居た会社のスレ立てて暴れまわってるから、気をつけた方がいい。
ここで余計な事言うと、何年間でも粘着されるぞ。俺はかれこれ４年位かな。
内定の方は、検討に値すると思う。特に地雷が居なくなった今ならな。
133 ：仕様書無しさん：2005/05/24(火) 00:20:17
すばらしく良スレ
もっとやれー
もっとやれー
134 ：仕様書無しさん：2005/05/24(火) 00:22:26
また煽りかよ。プロ固定ちゃん
※ このスレは完全フィクションでお送りしております。
実在の団体、人物とは一切関係ありません。
実在の団体、人物とは一切関係ありません。
↑なんだよコレ？
137 ：仕様書無しさん：2005/05/24(火) 00:24:46
よし、仕切り直したし、遠慮なくやってくれや
138 ：仕様書無しさん：2005/05/24(火) 00:25:42
プロ固定うざー
まぁ、>1-127はノンフィクションな訳だが
140 ：仕様書無しさん：2005/05/24(火) 08:45:37
>>120
10年くらいずれた発言なんで、眩暈がしました。
少なくともここ数年のSIerの健全な考え方は、
Blog上のトラバ(2005/5/1 05:05)あたりです。
加えるなら、
・日本はJust In Time～Agileの先進国であること
・日本の組織における業務知識の蓄積や、知識の体系化は
組織全体に薄く広がる形で実現されていること
・この結果、高密度の知識の集積があってはじめてなされる、
質的変化(ブレークスルー)たとえば方法論やパラダイムの変革が
発生しにくいこと
も見逃せないでしょう。
10年くらいずれた発言なんで、眩暈がしました。
少なくともここ数年のSIerの健全な考え方は、
Blog上のトラバ(2005/5/1 05:05)あたりです。
加えるなら、
・日本はJust In Time～Agileの先進国であること
・日本の組織における業務知識の蓄積や、知識の体系化は
組織全体に薄く広がる形で実現されていること
・この結果、高密度の知識の集積があってはじめてなされる、
質的変化(ブレークスルー)たとえば方法論やパラダイムの変革が
発生しにくいこと
も見逃せないでしょう。
141 ：仕様書無しさん：2005/05/24(火) 08:49:06
・・・おい、そのトラバ先、アスパラちゃんだよｗ
スマソ、ろくなトラックバックついてないようですね。
適当にそれっぽいトラックバックを選んだんだけど、
リンク先見て、眩暈しました。
適当にそれっぽいトラックバックを選んだんだけど、
リンク先見て、眩暈しました。
そろそろ臭くなってきたんで
ｽﾚごと情シス板に移動して貰えませんかね？
ｽﾚごと情シス板に移動して貰えませんかね？
>>143 プロ固定ウザイよ。さっさと氏ね
/ﾘﾊﾊﾊﾊ
Lゝ‘д‘)ゝ <進路ｸﾘｱです、発進してください
Lゝ‘д‘)ゝ <進路ｸﾘｱです、発進してください
業務系って、ドキュメントを何でもかんでもExcelで
書く人たちの事でしょ。
書く人たちの事でしょ。
Excelで問題あるの？
業務系の人て感覚が各自で、
「自分が仕事に就いた時」から止まってるんだよな。
頭は良い人が多いから余計にもったいなく思える。
まあ使わないままでは既にさび付いてるんだろうけど。
「自分が仕事に就いた時」から止まってるんだよな。
頭は良い人が多いから余計にもったいなく思える。
まあ使わないままでは既にさび付いてるんだろうけど。
俺も頭いいです
特に書く意味もねぇ糞レスを
淡々と書くバカ>>143-150が居るのは、何故？
淡々と書くバカ>>143-150が居るのは、何故？
２ちゃんプロ固定は書いてナンボの歩合給だから
なんだ、世の中、下には下が居るんだね。
154 ：仕様書無しさん：2005/05/25(水) 00:33:12
>>154
トヨタの事だったりしてな。
トヨタの事だったりしてな。
156 ：仕様書無しさん：2005/05/25(水) 00:40:32
・・・業界外の基地の外がやってきたｗ
業務系のＰＧまじでつまらん
もっとこう頭使う奴がやりたい
もっとこう頭使う奴がやりたい
日本語で書け。
159 ：仕様書無しさん：2005/05/25(水) 00:54:41
金稼ぐために仕事するか、技術屋として名前を残したいか
その違いだろ
稼ぐだけなら業務系の方が「最終的には」効率いいのは自明
その違いだろ
稼ぐだけなら業務系の方が「最終的には」効率いいのは自明
160 ：仕様書無しさん：2005/05/25(水) 00:56:38
自分が技術系で立派なんだと言いたいなら
Windows以上のOS作って普及させて
C++以上の言語の開発でもしとけっての
Windows以上のOS作って普及させて
C++以上の言語の開発でもしとけっての
出たね極論。
>160
自分が業務系で立派なんだと言いたいのなら
年収100億円貰ってみろ
とか。
自分が業務系で立派なんだと言いたいのなら
年収100億円貰ってみろ
とか。
164 ：仕様書無しさん：2005/05/25(水) 02:51:55
業務系が痛いって言ってる人は何やってるの？
165 ：仕様書無しさん：2005/05/25(水) 02:54:35
そりゃ業務系以外だろ。
166 ：仕様書無しさん：2005/05/25(水) 08:56:22
よ～し
VB＋Oracleのデータぶっこ抜きパターン考えちゃうぞ～
VB＋Oracleのデータぶっこ抜きパターン考えちゃうぞ～
>>163
設計とプログラミングが別作業だと思ってる人って業務系には多いよな
設計とプログラミングが別作業だと思ってる人って業務系には多いよな
171 ：仕様書無しさん：2005/05/25(水) 13:42:05
つか、業務系以外って、何がすごいんよ？
>>171
C言語を使うところ
C言語を使うところ
174 ：仕様書無しさん：2005/05/25(水) 14:23:04
業務系の人は、
業務系以外の分野というと
・基盤系
・運用系
あたりしか見えていないが、
そもそも業務系などという言葉を使いたがるのは、
金融・通信・製造などの分野でCOBOLや名も知れぬ言語、はたまたC++やJavaなどを使って、
鬼のように巨大だが単純な動きしかしないソフトを何億円もかけて作るようなカワイソウな現場のみ
業務系以外の分野というと
・基盤系
・運用系
あたりしか見えていないが、
そもそも業務系などという言葉を使いたがるのは、
金融・通信・製造などの分野でCOBOLや名も知れぬ言語、はたまたC++やJavaなどを使って、
鬼のように巨大だが単純な動きしかしないソフトを何億円もかけて作るようなカワイソウな現場のみ
業務系SE －システムエンジニア－
仕事内容
ユーザーのニーズを的確に把握した上で、コンピュータにどんな仕事をさせるかを考
え、そのためのシステムを設計するのがシステムエンジニアの仕事です。コンピュー
タの言語を使って実際のソフトウェアを組むのがプログラマであり、システムエンジ
ニアは、そのソフトウェアの設計を行うわけです。職場はコンピュータメーカーやソ
フトウェア開発企業がほとんどです。
やりがい
コンピュータそのものを熟知するだけでなく、銀行の預金システムの開発に携わるな
ら銀行業務を、商品管理システムの開発に携わるなら流通業界の物の流れを、という
ように、システム化する仕事全体の内容や流れを理解することも大切です。そういう
意味で、SEを目指すならば自分の興味のある分野を持っていると強みになります。
働ける業界
大型汎用機やパソコンなどを扱うコンピュータメーカーのシステム開発部門、あるい
はソフトハウスと呼ばれるソフトウェア開発企業。それ以外にも、パッケージソフト
ベンダーや、製造、流通、金融系企業などの情報システム部門がある。ソフトハウス
では基本的に、他社が依頼するシステムの設計や開発を行う。また、コンピュータメ
ーカーでは、自社製品を用いてのシステム開発が多い。
必要な知識・スキル
システムエンジニアなどの高度情報処理技術者が取得する資格には、経済産業大臣指
定の試験機関（財）日本情報処理開発協会 情報処理技術者試験センターが実施する
「情報処理技術者試験」などがあります。SEを目指すのであれば少なくとも、基本情
報技術者程度の知識は必要でしょう。上級の資格を取得しているとかなり有利になり
ますが、難易度はかなり高いようです。また、いくら資格を取得していても、一人前
になるまでにはかなりのキャリアを積まなければなりません
仕事内容
ユーザーのニーズを的確に把握した上で、コンピュータにどんな仕事をさせるかを考
え、そのためのシステムを設計するのがシステムエンジニアの仕事です。コンピュー
タの言語を使って実際のソフトウェアを組むのがプログラマであり、システムエンジ
ニアは、そのソフトウェアの設計を行うわけです。職場はコンピュータメーカーやソ
フトウェア開発企業がほとんどです。
やりがい
コンピュータそのものを熟知するだけでなく、銀行の預金システムの開発に携わるな
ら銀行業務を、商品管理システムの開発に携わるなら流通業界の物の流れを、という
ように、システム化する仕事全体の内容や流れを理解することも大切です。そういう
意味で、SEを目指すならば自分の興味のある分野を持っていると強みになります。
働ける業界
大型汎用機やパソコンなどを扱うコンピュータメーカーのシステム開発部門、あるい
はソフトハウスと呼ばれるソフトウェア開発企業。それ以外にも、パッケージソフト
ベンダーや、製造、流通、金融系企業などの情報システム部門がある。ソフトハウス
では基本的に、他社が依頼するシステムの設計や開発を行う。また、コンピュータメ
ーカーでは、自社製品を用いてのシステム開発が多い。
必要な知識・スキル
システムエンジニアなどの高度情報処理技術者が取得する資格には、経済産業大臣指
定の試験機関（財）日本情報処理開発協会 情報処理技術者試験センターが実施する
「情報処理技術者試験」などがあります。SEを目指すのであれば少なくとも、基本情
報技術者程度の知識は必要でしょう。上級の資格を取得しているとかなり有利になり
ますが、難易度はかなり高いようです。また、いくら資格を取得していても、一人前
になるまでにはかなりのキャリアを積まなければなりません
コメント
業務系SEの需要は相変わらず高い。その主な理由は、企業における情報システムの
重要度が増していること。既にシステムを導入している企業でも、新規事業や効率化の
ためのシステム再構築が続いている。今後はより専門分野に特化した開発需要が予想
されるため、メーカー、金融、流通など開発対象への高度な知識、最適な開発のため
の先端技術、顧客への提案力などが重視されそうだ。
業務系SEの需要は相変わらず高い。その主な理由は、企業における情報システムの
重要度が増していること。既にシステムを導入している企業でも、新規事業や効率化の
ためのシステム再構築が続いている。今後はより専門分野に特化した開発需要が予想
されるため、メーカー、金融、流通など開発対象への高度な知識、最適な開発のため
の先端技術、顧客への提案力などが重視されそうだ。
177 ：仕様書無しさん：2005/05/25(水) 14:32:15
>>174
狭い世界観ですね
狭い世界観ですね
178 ：仕様書無しさん：2005/05/25(水) 14:33:42
基礎研究所勤めで、論文書きまくり、特許取りまくりレベル以外は痛いってことでFA？
業務系SEが他職種になだれこまないように、
どの業務系よりも他の職種が（・∀・）ｲｲという情報は
決して教えてはいけない決まりになっている。
どの業務系よりも他の職種が（・∀・）ｲｲという情報は
決して教えてはいけない決まりになっている。
なだれ込むも何も、業務系が楽で稼げるから転職する必要はない。
楽な部分（余暇）を技術向上に充てるも趣味でプログラムするのも自由。
堕落するのも自由。
個人的には人生を狂わすゲーム系、携帯系は御免こうむりたい。
楽な部分（余暇）を技術向上に充てるも趣味でプログラムするのも自由。
堕落するのも自由。
個人的には人生を狂わすゲーム系、携帯系は御免こうむりたい。
（;;ﾟДﾟ）
そもそも仕事がいくら楽でも、
ドツボにはまらず定時退社できる業務系なんてあるんかいな。
職場のレベルが低いと、当たり前の事ができない構ってちゃんに翻弄されて、
新しい分野を一から考えるような個人的課題は難しくなるんじゃねぇの
・・・人のblog追っかけて最先端でござい、みたいなアーリーアダプターならそれで満足できるんかもしれんが
ドツボにはまらず定時退社できる業務系なんてあるんかいな。
職場のレベルが低いと、当たり前の事ができない構ってちゃんに翻弄されて、
新しい分野を一から考えるような個人的課題は難しくなるんじゃねぇの
・・・人のblog追っかけて最先端でござい、みたいなアーリーアダプターならそれで満足できるんかもしれんが
低レベルPGに合わせて、コーディングルールを極めてシンプルにした結果、
シンプルなコードが複雑怪奇な動きをする、というのが業務系の基本だとおもふ。
ちょうど、機械語はシンプルだが解読が面倒くさいように。
シンプルなコードが複雑怪奇な動きをする、というのが業務系の基本だとおもふ。
ちょうど、機械語はシンプルだが解読が面倒くさいように。
理系の優秀な技術者が単純な業務アプリ開発に関わるのは無駄が多すぎるから、
低脳技術者の受け入れ先として業務系は必要。
ただし、基本情報処理やソフ開の試験に受からない奴とか、
高校程度の数学が理解できないほどの超低脳が紛れ込むのはやはり問題があるので、
免許制度の導入を検討すべきではなかろうか。
それから、経歴詐称については、重い罰則を設けるべき。
低脳技術者の受け入れ先として業務系は必要。
ただし、基本情報処理やソフ開の試験に受からない奴とか、
高校程度の数学が理解できないほどの超低脳が紛れ込むのはやはり問題があるので、
免許制度の導入を検討すべきではなかろうか。
それから、経歴詐称については、重い罰則を設けるべき。
だーら、業務系にも色々あるんだし、一括りに出来るかよ。
クライアントによって規模もさまざまだし、形態もパッケージやASP、
制御系に近いものもある。
○○系とか一括りに結論付けているヤツが痛杉。
クライアントによって規模もさまざまだし、形態もパッケージやASP、
制御系に近いものもある。
○○系とか一括りに結論付けているヤツが痛杉。
まあ、理系だなんだ書いてる奴は学生だな。
空論書いて悦に入る。
学生じゃなかったら痛すぎ。
空論書いて悦に入る。
学生じゃなかったら痛すぎ。
>>174,183
＞金融・通信・製造などの分野でCOBOLや名も知れぬ言語、はたまたC++やJavaなどを使って、
＞鬼のように巨大だが単純な動きしかしないソフトを何億円もかけて作るようなカワイソウな現場のみ
これって汎用系では？
Javaとか入ってくるとオープン系か。
＞金融・通信・製造などの分野でCOBOLや名も知れぬ言語、はたまたC++やJavaなどを使って、
＞鬼のように巨大だが単純な動きしかしないソフトを何億円もかけて作るようなカワイソウな現場のみ
これって汎用系では？
Javaとか入ってくるとオープン系か。
「理系」という言葉に過敏に反応する人がいるようですｗ
192 ：仕様書無しさん：2005/05/25(水) 18:24:52
>>184
いや、渡辺氏のblogにあるＳＡ／ＳＤ手法
(旧物理モデル→旧論理モデル→新論理モデル→新物理モデル)
を使って、古い業務システムのプラットフォーム・ミグレーションするような
頭を使わない作業こそ、業務系の真骨頂だろう
いや、渡辺氏のblogにあるＳＡ／ＳＤ手法
(旧物理モデル→旧論理モデル→新論理モデル→新物理モデル)
を使って、古い業務システムのプラットフォーム・ミグレーションするような
頭を使わない作業こそ、業務系の真骨頂だろう
195 ：仕様書無しさん：2005/05/26(木) 22:39:20
Thought Works曰く「後ろめたい気分にならずに金儲けできる」
Paul Graham曰く 「普通の会社に良いハッカーはほとんどいない。
皆、ThoughtWorksやGoogleのような20～30の会社に固まっているから」
上司曰く 「自分の食い扶持は自分で稼げ」
結論： 「良い職場環境は自分達で作る」
Paul Graham曰く 「普通の会社に良いハッカーはほとんどいない。
皆、ThoughtWorksやGoogleのような20～30の会社に固まっているから」
上司曰く 「自分の食い扶持は自分で稼げ」
結論： 「良い職場環境は自分達で作る」
社会人として働いていく上で大切なことがある。
人を認めることだ。
１よ。おまえから見ればゴミのような業務系ＰＧでも、
それを必要としているところもあるのだよ。
人を認めることだ。
１よ。おまえから見ればゴミのような業務系ＰＧでも、
それを必要としているところもあるのだよ。
198 ：仕様書無しさん：2005/05/28(土) 12:45:37
一応ﾏｼﾞﾚｽしておこう。
業務系という卑しい職業で
尊敬を受けたいのであれば、
下記のルールを守る事。
1. 嘘はつかない事。
「できるつもりだったけどできませんでした」
という発言は、絶対しない事。
これは、経営者も同じ。
2. 他に責任転嫁をせず、自身の責任を全うする事。
「○×のせいでできませんでした。」
「そこは自分の担当外なので自分の責任ではありません」
という発言は、できるだけしないようにする事。
これは、経営者も同じ。
3. 向上心を持って己を磨く事。
「この仕事は嫌いだけど、生活のためにやっています」
「くだらない仕事だけど、お金が儲かるからいいじゃん」
という生き方は、今後やめてくれ。
これは、経営者も同じ。
業務系という卑しい職業で
尊敬を受けたいのであれば、
下記のルールを守る事。
1. 嘘はつかない事。
「できるつもりだったけどできませんでした」
という発言は、絶対しない事。
これは、経営者も同じ。
2. 他に責任転嫁をせず、自身の責任を全うする事。
「○×のせいでできませんでした。」
「そこは自分の担当外なので自分の責任ではありません」
という発言は、できるだけしないようにする事。
これは、経営者も同じ。
3. 向上心を持って己を磨く事。
「この仕事は嫌いだけど、生活のためにやっています」
「くだらない仕事だけど、お金が儲かるからいいじゃん」
という生き方は、今後やめてくれ。
これは、経営者も同じ。
もはや業務系とは関係ない話だ
業務系には馬鹿が多いから、
>>198といった低レベルなルールすら守れないのが多い。
>>198といった低レベルなルールすら守れないのが多い。
201 ：仕様書無しさん：2005/05/28(土) 13:40:00
多い少ないという次元の話なら
プ ロ グ ラ マ は 女 に モ テ な い か ら 痛 い よ ね ｗ
という話の次元と同じだな
プ ロ グ ラ マ は 女 に モ テ な い か ら 痛 い よ ね ｗ
という話の次元と同じだな
業務系か、それ以外の主技術系であるかの違いは簡単だ。
スーツ姿で仕事をしているのはほぼ業務系（最近は私服も多いけど）
なんで客先にいかない日でもスーツ着て仕事してんだよ。
GLAYかおまえらは！
スーツ姿で仕事をしているのはほぼ業務系（最近は私服も多いけど）
なんで客先にいかない日でもスーツ着て仕事してんだよ。
GLAYかおまえらは！
もはや業務系とは関係ない話だ
あれ、デジャブ？
あれ、デジャブ？
>>201はいつも言葉のマジックに騙されて、無駄な物ばかり買わされている低脳ｗ
>>204
モテないプログラマが釣れましたよ
モテないプログラマが釣れましたよ
>>198
なんか現場をしらなすぎる。奇麗事ばかりで馬鹿馬鹿しい。
別に尊敬なんかしてもらわなくていいし。
そりゃ最初は頑張ってプロジェクト成功させるつもりだったけど、無理だったよ。(1)
お客さんの言うことが変わりすぎる。当初の仕様どおりに完成させたのに
根本から作り直さないといけない仕様変更を平気でしてくる。
営業もへらへらして「うん、そっちの方が良いですね」とか言ってるだけ。(2)
こんな仕事にプライドとか向上心とか持てる？無理だよね。
こんなつまらない仕事はないと思っているし大嫌いだけど、
生活の為に仕方なく働いているよ。(3)
なんか現場をしらなすぎる。奇麗事ばかりで馬鹿馬鹿しい。
別に尊敬なんかしてもらわなくていいし。
そりゃ最初は頑張ってプロジェクト成功させるつもりだったけど、無理だったよ。(1)
お客さんの言うことが変わりすぎる。当初の仕様どおりに完成させたのに
根本から作り直さないといけない仕様変更を平気でしてくる。
営業もへらへらして「うん、そっちの方が良いですね」とか言ってるだけ。(2)
こんな仕事にプライドとか向上心とか持てる？無理だよね。
こんなつまらない仕事はないと思っているし大嫌いだけど、
生活の為に仕方なく働いているよ。(3)
> なんか現場をしらなすぎる。奇麗事ばかりで馬鹿馬鹿しい。
・・・えぇーとぉ。
釣られました宣言と受け取っても良いですかね？
・・・えぇーとぉ。
釣られました宣言と受け取っても良いですかね？
209 ：仕様書無しさん：2005/05/30(月) 12:43:52
>>207
典型的業務系
典型的業務系
>>208
釣られてるわけじゃない事にしたい宣言かと。
釣られてるわけじゃない事にしたい宣言かと。
COBOLerと業務系を同視している人多いよね
まったくだ。業務系に失礼だね
213 ：仕様書無しさん：2005/05/31(火) 09:56:28
>>211
痛さの本質はおなじだけどなｗ
痛さの本質はおなじだけどなｗ
業務系は糞
エロゲ系が最高
エロゲ系が最高
禿同
そーか。これだけパロディーですよ信号を満載していても
リアル扱いされるくらいのクオリティーなのか、業務系は・・・
リアル扱いされるくらいのクオリティーなのか、業務系は・・・
業務系を馬鹿にしてる奴は技術こそ正義と考えているお子様。
たまには外に出ろよ。
たまには外に出ろよ。
218 ：仕様書無しさん：2005/06/04(土) 12:30:09
>>217
別に技術が正義とは言わんが、業務系の奴らが書いている抽象化すらされていない糞
コードなんざもう少しスキルがある奴もしくは向上心のある奴に書かせたら
もっと保守性が高く品質の良いプログラムにできるんだよね。
頼むからもう少し向上心を持て、ステップ単価で契約を取ってきて、性能も
保守性もむちゃくちゃなコードを書き散らすのは迷惑だからやめろ。。。
障害が起きたとき、何から何まで自分たちで責任をとってくれるならかまわない
が、たいていの場合、関係ない人間まで巻き込んでいることを自覚しろ。
別に技術が正義とは言わんが、業務系の奴らが書いている抽象化すらされていない糞
コードなんざもう少しスキルがある奴もしくは向上心のある奴に書かせたら
もっと保守性が高く品質の良いプログラムにできるんだよね。
頼むからもう少し向上心を持て、ステップ単価で契約を取ってきて、性能も
保守性もむちゃくちゃなコードを書き散らすのは迷惑だからやめろ。。。
障害が起きたとき、何から何まで自分たちで責任をとってくれるならかまわない
が、たいていの場合、関係ない人間まで巻き込んでいることを自覚しろ。
巻き込むもなにも、お互い系列が違えば絡むことないんじゃ？
業務系に糞PGが存在したとして、他の制御系やらゲーム系に関係するか？
業務系に糞PGが存在したとして、他の制御系やらゲーム系に関係するか？
220 ：仕様書無しさん：2005/06/04(土) 15:04:38
業務系の仕事は確かに沢山あるが、利益率はorz
おまけに、開発チームの内訳が詐欺師に送り込まれた経歴詐称
の自称プログラマが９割くらいというのが実情。
いかにしてプログラマでさえない者にプログラムを作らせるか？
（当然、言語はJava以外に選択肢は無くなる）
そんなプロジェクトばかり管理していると、業務系の人間に特有の思想
が必然的に形成されるんですな。
おまけに、開発チームの内訳が詐欺師に送り込まれた経歴詐称
の自称プログラマが９割くらいというのが実情。
いかにしてプログラマでさえない者にプログラムを作らせるか？
（当然、言語はJava以外に選択肢は無くなる）
そんなプロジェクトばかり管理していると、業務系の人間に特有の思想
が必然的に形成されるんですな。
業務系PGがどうのこうのという問題より、仕事を取ってくる営業のやり方が
DQNってパターンが多すぎるんじゃないか？
予算・納期etc
そんな状況で真面目にやるPGが少ないのも当たり前とか。
だからつじつま合わせにDQNPGもまた、大量投入されると。
でもそれで仕事が回ってしまうから業界全体が麻痺している感がある。
また、業務系における客側のDQN率も高そうだ。
他の業界の場合はごまかしが効かないから、まともなPGが居ないとつとまらない。
そういう差が如実に出てるんじゃないか？
DQNってパターンが多すぎるんじゃないか？
予算・納期etc
そんな状況で真面目にやるPGが少ないのも当たり前とか。
だからつじつま合わせにDQNPGもまた、大量投入されると。
でもそれで仕事が回ってしまうから業界全体が麻痺している感がある。
また、業務系における客側のDQN率も高そうだ。
他の業界の場合はごまかしが効かないから、まともなPGが居ないとつとまらない。
そういう差が如実に出てるんじゃないか？
業務系の底辺とはCOBOLerでもC厨房でもなく、VB房＆VBA遣いの事務員だったりする。単価的に(笑
Java？いやあれは馬鹿には書けない言語。
実際、どうしようもない猿が多い現場では、
猿にはコードを触らせず、設計書もどき書きに専念してもらって、
後は海外発注する、と聞く(笑
そんな猿でも月単価80以上取る事が多いとか・・・
Java？いやあれは馬鹿には書けない言語。
実際、どうしようもない猿が多い現場では、
猿にはコードを触らせず、設計書もどき書きに専念してもらって、
後は海外発注する、と聞く(笑
そんな猿でも月単価80以上取る事が多いとか・・・
223 ：仕様書無しさん：2005/06/04(土) 20:04:08
お前みたいな日本語不自由なのがのたくっていない業界の事だよ
お前が所属するバクテリア業界以外
227 ：仕様書無しさん：2005/06/05(日) 11:08:12
馬鹿が依頼し、詐欺師が受注して、DQNが作る業務アプリ（笑）
>228
客が馬鹿なのはベンダーが
馬鹿でいて欲しいと願ったから。
客が馬鹿なのはベンダーが
馬鹿でいて欲しいと願ったから。
痴呆の進んだ老人をだまして、かなりいい加減な欠陥工事で高い金を請求する
悪徳リフォーム会社があるらしいが、業務系開発と何か共通点があるなｗ
悪徳リフォーム会社があるらしいが、業務系開発と何か共通点があるなｗ
231 ：仕様書無しさん：2005/06/05(日) 14:41:10
>>230
まったくだ。客が馬鹿なとこなんかそっくりすぎて笑える。
まったくだ。客が馬鹿なとこなんかそっくりすぎて笑える。
悪徳リフォーム会社は最初からきちんとした工事をする気がない。
業務系SE/PGは、とりあえずまともなものを作る気はあるんだが低脳ゆえに・・・ｗ
業務系SE/PGは、とりあえずまともなものを作る気はあるんだが低脳ゆえに・・・ｗ
最近は、単価をあげづらくなったような気がする。
逆にそれに見合わない規模のものも多いし。
昔は、3人月なのにで1人で1週間でできちゃったとかあったのになあ。
逆にそれに見合わない規模のものも多いし。
昔は、3人月なのにで1人で1週間でできちゃったとかあったのになあ。
某メーカで理系のシミュレータをFortran や Cで作ってたんだけど、
業務系って大変だとおもうんだけど。
介護のために退職して帰省して在宅勤務しようとすると、
業務系しかないんだよね。
VB,Perl,PHP,ASP,Java といろいろ使ってきたけど、
面白くもない、めんどくせえーーってことを延々とやらないといけないんだよ。
今はJavaが多いな。VBなんかよりはおもしろい。
今回初めて、StrutsとHibernateを使ってみたよ。
この辺の環境やツールはバージョンが頻繁に上がるし、
最新のものを使おうとすると、ドキュメントはほとんど英語で、
それなりの知識とたえなる勉強は必要な気がする。
業務系って大変だとおもうんだけど。
介護のために退職して帰省して在宅勤務しようとすると、
業務系しかないんだよね。
VB,Perl,PHP,ASP,Java といろいろ使ってきたけど、
面白くもない、めんどくせえーーってことを延々とやらないといけないんだよ。
今はJavaが多いな。VBなんかよりはおもしろい。
今回初めて、StrutsとHibernateを使ってみたよ。
この辺の環境やツールはバージョンが頻繁に上がるし、
最新のものを使おうとすると、ドキュメントはほとんど英語で、
それなりの知識とたえなる勉強は必要な気がする。
>234
どんな仕事があるかは
お前の実力しだいだろ。
どんな仕事があるかは
お前の実力しだいだろ。
> 理系のシミュレータ
ここが笑いどころっすか？
文系シミュレータ
フリータ系シミュレータ
爆笑
ここが笑いどころっすか？
文系シミュレータ
フリータ系シミュレータ
爆笑
238 ：仕様書無しさん：2005/06/05(日) 20:30:30
サイエンス系バリバリでモデル計算や測定技術検証やってた俺に言わせると、
「理系のシミュレータ」という言葉にはあまりに違和感があり過ぎる。
「理系のシミュレータ」という言葉にはあまりに違和感があり過ぎる。
> それなりの知識とたえなる勉強は必要な気がする
妙なる勉強？ここも笑いどころっすか？
妙なる勉強？ここも笑いどころっすか？
ここまで来ると、ｲﾀｲﾀしい。
ここで業務系を叩いてる奴って、そーゆーレベルの業務系としか関わりがないってことを
自分で明らかにしてるってことだよな？
自分で明らかにしてるってことだよな？
>>240
きっと、「絶え間ざる勉強」という表現を知らない学生さんなんだろうなｗ
きっと、「絶え間ざる勉強」という表現を知らない学生さんなんだろうなｗ
業務系を自称して自作自演とは、悲惨だな。
業務系の人って、ちょっと頭の弱い別業界の人だと思っている。
サンデープログラマのほうがよっぽど技術は高いだろ。
最近の業務系は、プログラムには何の興味もないがほかに職がなかったから、
という理由で入ってくる奴も多いようだし。
最近の業務系は、プログラムには何の興味もないがほかに職がなかったから、
という理由で入ってくる奴も多いようだし。
>>243
「絶え間ない（なき）」と「たゆまざる」とゆう日本語をどちらもご存知ない？
嗚呼、正確な日本語を使うこと能わざる者の何と多きことよ。
斯様な惨状に対し、筆舌に尽くしがたき不安を覚えざるべからざるものなり。
「絶え間ない（なき）」と「たゆまざる」とゆう日本語をどちらもご存知ない？
嗚呼、正確な日本語を使うこと能わざる者の何と多きことよ。
斯様な惨状に対し、筆舌に尽くしがたき不安を覚えざるべからざるものなり。
250 ：仕様書無しさん：2005/06/05(日) 22:17:56
252 ：仕様書無しさん：2005/06/05(日) 22:31:13
253 ：仕様書無しさん：2005/06/05(日) 22:32:58
255 ：仕様書無しさん：2005/06/05(日) 22:44:31
どうでもいいですけど、素人さんが威張り散らしてるスレはここですか？
>>255
なんだおまえ、自分の事をよくわきまえてるじゃん
なんだおまえ、自分の事をよくわきまえてるじゃん
>>255
素人＝？
素人＝？
日曜日「も」プログラム組んでる人間のことをサンデープログラマだと勘違いしてるんだろ
>>259
藁ﾀ
藁ﾀ
大工が日曜日に仕事と関係ないものを
作ったとしても日曜大工とはいわんな。
作ったとしても日曜大工とはいわんな。
>>259
そうだったのか！！！！わろた。
そうだったのか！！！！わろた。
263 ：仕様書無しさん：2005/06/06(月) 00:14:51
>>261
えーと、
言うよ？別に辞書引くまでもなく常識だと思うけど…
http://dictionary.goo.ne.jp/search.php?MT=%C6%FC%CD%CB%C2%E7%B9%A9&jn.x=22&jn.y=7
>>258
趣味でしか触らない人しか含めないのであれば、
それこそ本職に敵う道理が無いな。
えーと、
言うよ？別に辞書引くまでもなく常識だと思うけど…
http://dictionary.goo.ne.jp/search.php?MT=%C6%FC%CD%CB%C2%E7%B9%A9&jn.x=22&jn.y=7
>>258
趣味でしか触らない人しか含めないのであれば、
それこそ本職に敵う道理が無いな。
家帰って来てまでVBを選ばない漏れは、ある意味サンデーﾌﾟﾛｸﾞﾗﾏ。
ごめんね。
たえなる → たゆまぬ だね。
理系のシミュレータって表現おかしいの？
光学、力学、電磁気学の数値計算といえばよかったのかな。
当時は数値計算と呼ぶのは受けが悪かったので、シミュレーションと呼んでいた。
シミュレータ作成が仕事ではなくて、研究開発が仕事だったので、
入力は、数値を書き並べたファイルを読ませて、結果も数値で得て、Exceで表示させるという、
入出力部分をほとんど省略してソルバーだけといったものをつくって使っていた。
入出力部分をつくるのは、とても面倒で難しいとおもっていたので、回避していたわけだけど、
業務系というのは、この入出力部分にあたるわけなんだよね。
それも、専門家じゃなくて、パソコンもまともに使えない人が使うという前提で
作らないといけない。やはり難しいと思うよ。
文系のシミュレーションというのは、経営シミュレーションみたいなものを想像していた。
たえなる → たゆまぬ だね。
理系のシミュレータって表現おかしいの？
光学、力学、電磁気学の数値計算といえばよかったのかな。
当時は数値計算と呼ぶのは受けが悪かったので、シミュレーションと呼んでいた。
シミュレータ作成が仕事ではなくて、研究開発が仕事だったので、
入力は、数値を書き並べたファイルを読ませて、結果も数値で得て、Exceで表示させるという、
入出力部分をほとんど省略してソルバーだけといったものをつくって使っていた。
入出力部分をつくるのは、とても面倒で難しいとおもっていたので、回避していたわけだけど、
業務系というのは、この入出力部分にあたるわけなんだよね。
それも、専門家じゃなくて、パソコンもまともに使えない人が使うという前提で
作らないといけない。やはり難しいと思うよ。
文系のシミュレーションというのは、経営シミュレーションみたいなものを想像していた。
業務系がまず画面から入るのは確かに多いというか基本だと思うが
別に難しくは無いよ
面倒なだけで
なんつーか仕様や設計が全部画面ドリブン、みたいな。
モデル先ありきじゃなくてさ。
それが典型的なDQN業務系。
別に難しくは無いよ
面倒なだけで
なんつーか仕様や設計が全部画面ドリブン、みたいな。
モデル先ありきじゃなくてさ。
それが典型的なDQN業務系。
まずは職に就け。話はそれからだ。
>>244
もちろん理解してるよ。
でも痛いとか思わないよ。（思わないようにしてる）
誤解を恐れずに書くと、
俺を含めて向上心の強い奴って、他人にも同じレベルを要求しちゃって、
「なんで？なんでおまえは・・・」とか勝手に思っちゃうんだよね。
でもさ、みんながみんな好き好んで仕事してるとは限らないじゃん。生活のためって
ゆーのもありじゃん？
要は、業務系だから痛いんじゃなくて、仕事に対する考え方の違いかな。
もちろん理解してるよ。
でも痛いとか思わないよ。（思わないようにしてる）
誤解を恐れずに書くと、
俺を含めて向上心の強い奴って、他人にも同じレベルを要求しちゃって、
「なんで？なんでおまえは・・・」とか勝手に思っちゃうんだよね。
でもさ、みんながみんな好き好んで仕事してるとは限らないじゃん。生活のためって
ゆーのもありじゃん？
要は、業務系だから痛いんじゃなくて、仕事に対する考え方の違いかな。
>>263
煽るわけではないけども。
日曜大工、辞書には「本職の大工も含む」とも書いてないので
辞書にどう書いてあるかは何の担保にもならないでしょう。
ただ、日曜大工とは、「日曜だけの大工さん」的な使い方をされると
俺は今まで生きてきて思ってるんだが。サンデープログラマーも同じく。
理系のシミュレータってのは、ヘンな言葉だけどわざと極端な省略するのは
符丁としてはありだと思うよ。
>>252は一般論としてゆってるのでバカ。
煽るわけではないけども。
日曜大工、辞書には「本職の大工も含む」とも書いてないので
辞書にどう書いてあるかは何の担保にもならないでしょう。
ただ、日曜大工とは、「日曜だけの大工さん」的な使い方をされると
俺は今まで生きてきて思ってるんだが。サンデープログラマーも同じく。
理系のシミュレータってのは、ヘンな言葉だけどわざと極端な省略するのは
符丁としてはありだと思うよ。
>>252は一般論としてゆってるのでバカ。
>>268
「痛い」っていうのは、お前みたいに自称「向上心が強い」とか言いながら、
レベルの低い業務系に関わってるような奴のことじゃね？
レベルの低さを認識した上で、生活のために働いているような人たちは
ちょっと情けない人生だとは思うけど、「痛い」というのとは違う。
「痛い」っていうのは、お前みたいに自称「向上心が強い」とか言いながら、
レベルの低い業務系に関わってるような奴のことじゃね？
レベルの低さを認識した上で、生活のために働いているような人たちは
ちょっと情けない人生だとは思うけど、「痛い」というのとは違う。
271 ：仕様書無しさん：2005/06/06(月) 10:46:02
素で痛い>>263晒しあげ
言葉を間違えて覚えてることは誰にもあることだが、
>263のリンク先の辞書の説明を見て、自分の説が正しいという
裏づけになると思ってるところがかなりアレだなｗ
# 常識とか言ってるし
ほかにもいろんな言葉を間違えて覚えてるんだろう
>263のリンク先の辞書の説明を見て、自分の説が正しいという
裏づけになると思ってるところがかなりアレだなｗ
# 常識とか言ってるし
ほかにもいろんな言葉を間違えて覚えてるんだろう
まずは職に就け。話はそれからだ。
低いってのは、
買い物カゴに入れて注文データ作っておしまいで
回収だの請求だの消し込みだの支払だの
手形決済だのやらない奴の事じゃないのかな？
高いとなると、どこまでいけば高いと認めてくれるのか
恐くて下手に言い出せないなあ。
買い物カゴに入れて注文データ作っておしまいで
回収だの請求だの消し込みだの支払だの
手形決済だのやらない奴の事じゃないのかな？
高いとなると、どこまでいけば高いと認めてくれるのか
恐くて下手に言い出せないなあ。
Javaで言うと、JSFやSpring、Hibernate使ってキッチリMVCでWebアプリ
組んでりゃそこそこレベル高い
無論業務系の中での話
所 詮 そ の 程 度 な の さ
組んでりゃそこそこレベル高い
無論業務系の中での話
所 詮 そ の 程 度 な の さ
> 回収だの請求だの消し込みだの支払だの
そりゃ単に処理が「多い」だけだろ・・
そりゃ単に処理が「多い」だけだろ・・
回収だの請求だのが技術レベルと何の関係があるんだよ
いや、だからお前は何も知らない無知蒙昧バカのまんまで恥晒してろ、と。
いやぁ～、可哀想なお人だなｗ
いやぁ～、可哀想なお人だなｗ
あ、ちなみに業務系の回収/請求は、なんかESBのご先祖みたいな痛いミドルウェアを使って、
マルチプロトコル/マルチベンダーのオンライン接続とかするらしいね。
EC系だと・・・おしえてあげないよっ（ｼﾞｬﾝ
マルチプロトコル/マルチベンダーのオンライン接続とかするらしいね。
EC系だと・・・おしえてあげないよっ（ｼﾞｬﾝ
だから回収や請求だってばｗ
>284
ああ、MQとか、セゾンが作ったﾊｧﾊｧﾌｰみたいな名前のヤシねｗ>>痛そうなミドル
ああ、MQとか、セゾンが作ったﾊｧﾊｧﾌｰみたいな名前のヤシねｗ>>痛そうなミドル
批判・抽象する奴は決してその理由を書かない。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
批判・抽象する奴は決してその理由を書かない。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
批判・抽象する奴は決してその理由を書かない。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
言ってしまえば理由なんてないのだ。
自分のもつコンプレックスを消したいと願い、他人に転嫁してるに過ぎないのだ。
すげぇコンプレックスだな >>288-290
>>291
おまえ簡単に釣られすぎ。
おまえ簡単に釣られすぎ。
いや、毎晩この時間は 2ちゃんの煽り厨房をもぐら叩きする時間にしてるから。
一匹いたら百匹隠れてると思え>>煽り厨房
一匹いたら百匹隠れてると思え>>煽り厨房
納得。
>>272
主に大工とは別の職業を持つ者が、余暇を利用して行う木工作業を指す。
主に大工とは別の職業を持つ者が、余暇を利用して行う木工作業を指す。
まずは職に就け。話はそれからだ。
>>120
書きそびれましたが、
例の香具師の仕事で、国内の典型的な会計ドメイン・モデルを確認するために、
渡辺幸三氏の著書 「業務別データベース設計のためのデータモデリング入門」
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/
浅海智晴氏のJavaWorld連載 「Javaデザインノート」
も参考にさせて頂きました。
渡辺氏は、企業システム・モデリングのための
モデリングツール「XEAD」を開発し、 http://homepage2.nifty.com/dbc/xead.html
その上で典型的な業務モデルを構築中、 http://watanabek.cocolog-nifty.com/blog/2005/02/index.html
浅海氏は、「伝票指向アーキテクチャ」のための
XMLドリブン開発ツール「RelaxerStudio」を開発し、 http://www.relaxer.org/studio/index_ja.html
コアのアイデアはJasmineSoft Harvestが商品化 http://www.jasminesoft.co.jp/harvest/thanks.html
ということです。
お二人の考え方には、違いがあるものの(業務モデリング vs 業務アーキテクチャ)、
結局よく似たアプローチを採られている(業務モデリングの中心にXMLを据える)のが興味深いですね。
書きそびれましたが、
例の香具師の仕事で、国内の典型的な会計ドメイン・モデルを確認するために、
渡辺幸三氏の著書 「業務別データベース設計のためのデータモデリング入門」
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/
浅海智晴氏のJavaWorld連載 「Javaデザインノート」
も参考にさせて頂きました。
渡辺氏は、企業システム・モデリングのための
モデリングツール「XEAD」を開発し、 http://homepage2.nifty.com/dbc/xead.html
その上で典型的な業務モデルを構築中、 http://watanabek.cocolog-nifty.com/blog/2005/02/index.html
浅海氏は、「伝票指向アーキテクチャ」のための
XMLドリブン開発ツール「RelaxerStudio」を開発し、 http://www.relaxer.org/studio/index_ja.html
コアのアイデアはJasmineSoft Harvestが商品化 http://www.jasminesoft.co.jp/harvest/thanks.html
ということです。
お二人の考え方には、違いがあるものの(業務モデリング vs 業務アーキテクチャ)、
結局よく似たアプローチを採られている(業務モデリングの中心にXMLを据える)のが興味深いですね。
業務系が痛いって言ってるヤツは、そういう痛い事をやってきた/やらされた訳で。
そう、このスレは痛いヤツらの集合スレなのよね。
俺もな。
そう、このスレは痛いヤツらの集合スレなのよね。
俺もな。
はぁ？
痛い人が痛い方法で進めてる業務系から、
どうやって研究開発費用を搾り出すか、
という観点でしか、係わり合いになるつもりはないけどｗ
痛い人が痛い方法で進めてる業務系から、
どうやって研究開発費用を搾り出すか、
という観点でしか、係わり合いになるつもりはないけどｗ
力仕事の業務系をいかに効率よくスマートな形で作り上げるか知りたいんですけど
どういったものを勉強したらいいですか？
そういった方法論を取り上げた本とかないですか？
クラス設計書のきちんとした書き方とか一度勉強してみたいんですけど‥
ちなみにひよっこＰＧです‥
どういったものを勉強したらいいですか？
そういった方法論を取り上げた本とかないですか？
クラス設計書のきちんとした書き方とか一度勉強してみたいんですけど‥
ちなみにひよっこＰＧです‥
303 ：仕様書無しさん：2005/06/10(金) 09:38:10
クラス設計のドキュメントならUMLを勉強すればいいし、開発方法論についても
いろいろな書籍は出てるだろうが、業務系がDQN力仕事なのは構造的なもの
だから・・・。
とりあえず経歴詐称を指示されたら、はっきり「NO!]という勇気やプライドを持とう。
いろいろな書籍は出てるだろうが、業務系がDQN力仕事なのは構造的なもの
だから・・・。
とりあえず経歴詐称を指示されたら、はっきり「NO!]という勇気やプライドを持とう。
>>302
設計書の書き方ってのはないけど
http://www.amazon.co.jp/exec/obidos/ASIN/4797328517/
これなんかどう？
あまり夢を大々的に語ってないのはよかった
更に夢がないけど
http://www.amazon.co.jp/exec/obidos/ASIN/4534036558/
これはとても納得がいった。
上流工程だけど。
設計書の書き方ってのはないけど
http://www.amazon.co.jp/exec/obidos/ASIN/4797328517/
これなんかどう？
あまり夢を大々的に語ってないのはよかった
更に夢がないけど
http://www.amazon.co.jp/exec/obidos/ASIN/4534036558/
これはとても納得がいった。
上流工程だけど。
>>302
クラス設計書？どこのメーカーでの呼び名？
そんな文書名聞いた事もねぇよ（ぷぷぷ
>>304
さっそく渡辺氏の本を薦めるあたりに、そこはかとない痛さを感じた。
>>305
お前の発言は、全部鸚鵡返しでつまらんから、もう発言しなくて良し。さっさと首吊れよ
クラス設計書？どこのメーカーでの呼び名？
そんな文書名聞いた事もねぇよ（ぷぷぷ
>>304
さっそく渡辺氏の本を薦めるあたりに、そこはかとない痛さを感じた。
>>305
お前の発言は、全部鸚鵡返しでつまらんから、もう発言しなくて良し。さっさと首吊れよ
富士通？そりゃ単なるローカルルールじゃないの
アクセンチュア？あぁ、あそこはそーゆーセンスだ。外部設計/内部設計とか（ｗ
IBM？IBMとプロジェクトやった事あるけど、OO以前の時代だからなぁ。よくわかんないでつ。
アクセンチュア？あぁ、あそこはそーゆーセンスだ。外部設計/内部設計とか（ｗ
IBM？IBMとプロジェクトやった事あるけど、OO以前の時代だからなぁ。よくわかんないでつ。
ああ、探してみたら富士通系ユーザ研究会でそーゆー呼び名使ってる所もあるみたいね。
1998年度分科会 研究成果報告書『アブストラクト』
Javaを用いた基幹システムの構築Ⅱ
－システム構築における適用評価と開発ガイドライン－
http://www.lsken.gr.jp/opn/act/ron/98/bun14.html
・・・開発作業手順は、実績があり大規模システムに適用でき、多人数で統制のとれた形で
進められる富士通社のSDEM90を参考にし、どの開発工程のどのカテゴリにおいてJava特有
の作業を追加・融合させるかということで進めた。
その結果、SDEM90のシステム分析／ユーザインタフェース設計工程においてシステム開発
範囲全体の"クラスの関係"と"クラスのグループ化"を整理する作業を、システム要求仕様と
ユーザインタフェース設計をスパイラルに行う必要があり、システム構造設計／プログラム構
造設計工程において、個別のクラスやインタフェースをJava用にアレンジしたドキュメントを用
い設計する必要があると判った。
プロトタイプシステムの作成過程で出来上がったドキュメントを検証した結果、システム分析
工程ではJava特有のドキュメントは必要なく、システム設計開発工程において、分析工程時
のクラス図の中でシステムの細分化またはグループ化するときの「パッケージ・モデル図」、
クラス図の各クラスやインタフェースをJavaでコーディングするレベルまで記述する
「クラス設計書」「メソッド仕様書」「インタフェース設計書」の4つのドキュメントが必要であると
判断し、そのひな形を提案する。
1998年度分科会 研究成果報告書『アブストラクト』
Javaを用いた基幹システムの構築Ⅱ
－システム構築における適用評価と開発ガイドライン－
http://www.lsken.gr.jp/opn/act/ron/98/bun14.html
・・・開発作業手順は、実績があり大規模システムに適用でき、多人数で統制のとれた形で
進められる富士通社のSDEM90を参考にし、どの開発工程のどのカテゴリにおいてJava特有
の作業を追加・融合させるかということで進めた。
その結果、SDEM90のシステム分析／ユーザインタフェース設計工程においてシステム開発
範囲全体の"クラスの関係"と"クラスのグループ化"を整理する作業を、システム要求仕様と
ユーザインタフェース設計をスパイラルに行う必要があり、システム構造設計／プログラム構
造設計工程において、個別のクラスやインタフェースをJava用にアレンジしたドキュメントを用
い設計する必要があると判った。
プロトタイプシステムの作成過程で出来上がったドキュメントを検証した結果、システム分析
工程ではJava特有のドキュメントは必要なく、システム設計開発工程において、分析工程時
のクラス図の中でシステムの細分化またはグループ化するときの「パッケージ・モデル図」、
クラス図の各クラスやインタフェースをJavaでコーディングするレベルまで記述する
「クラス設計書」「メソッド仕様書」「インタフェース設計書」の4つのドキュメントが必要であると
判断し、そのひな形を提案する。
あ、これも富士通系だ。
UMLによるオブジェクト指向開発実践ガイド
吉田 裕之 (著), 上原 忠弘 (著), 山本 里枝子 (著), 田中 達雄 (著)
http://www.amazon.co.jp/exec/obidos/ASIN/477410714X/250-4795441-7608243
カスタマーレビュー
設計ドキュメントのカタログでしかない, 2002/09/09
特に開発プロセスやオブジェクト指向の考え方を説明するでもなく、UMLの簡単な説明と、
実際に作成する図やクラス設計書の例が記載されているだけである。
日本人の悪い癖で、ドキュメントを重要視しすぎている感があり、この本で紹介されているような
手順だと実際のプロジェクトへの適用は難しいと思う。
仕様書のフォーマットのカタログとしては良いかもしれないが、この本を読んでもあまり得るもの
は少ないと思う。
まあ、その分お偉いさんのオブジェクト指向入門書としては適当なのかも…
UMLによるオブジェクト指向開発実践ガイド
吉田 裕之 (著), 上原 忠弘 (著), 山本 里枝子 (著), 田中 達雄 (著)
http://www.amazon.co.jp/exec/obidos/ASIN/477410714X/250-4795441-7608243
カスタマーレビュー
設計ドキュメントのカタログでしかない, 2002/09/09
特に開発プロセスやオブジェクト指向の考え方を説明するでもなく、UMLの簡単な説明と、
実際に作成する図やクラス設計書の例が記載されているだけである。
日本人の悪い癖で、ドキュメントを重要視しすぎている感があり、この本で紹介されているような
手順だと実際のプロジェクトへの適用は難しいと思う。
仕様書のフォーマットのカタログとしては良いかもしれないが、この本を読んでもあまり得るもの
は少ないと思う。
まあ、その分お偉いさんのオブジェクト指向入門書としては適当なのかも…
>306=108=103
で、いいのかな？
ファウラーでもってコンサルがどうとか
いってるの方が相当痛いと思うよ
だからまあ言いっこなしだ
で、いいのかな？
ファウラーでもってコンサルがどうとか
いってるの方が相当痛いと思うよ
だからまあ言いっこなしだ
書き忘れ
渡辺氏の本がどうとかいう話へのレスです。
クラス設計書なんて言葉俺も現場じゃ聞かないが
本かwebかどこで聞いたか知らないけど耳なじみはいいよ
渡辺氏の本がどうとかいう話へのレスです。
クラス設計書なんて言葉俺も現場じゃ聞かないが
本かwebかどこで聞いたか知らないけど耳なじみはいいよ
Fowlerって進んでる事もあれば、遅れてる事もある、
有名タレントみたいなコンサルに過ぎないと思うけど。
有名タレントみたいなコンサルに過ぎないと思うけど。
書き忘れ
>>312
http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%22%E3%82%AF%E3%83%A9%E3%82%B9%E8%A8%AD%E8%A8%88%E6%9B%B8%22&num=100
"クラス設計書" の検索結果のうち 日本語のページ 約 40 件中 1 - 20 件目 (0.41 秒)
>>312
http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%22%E3%82%AF%E3%83%A9%E3%82%B9%E8%A8%AD%E8%A8%88%E6%9B%B8%22&num=100
"クラス設計書" の検索結果のうち 日本語のページ 約 40 件中 1 - 20 件目 (0.41 秒)
ＵＭＬの本など色々教えてくださりありがとうございました。
参考にします。
あと皆さんすごいですねぇ。。
クラス設計書はうちの先輩社員が言っていてたまたま私が覚えていた単語です。
うちは富士通ではありませんが、富士通系列の某会社はお得意先で、
仕事をずっと取っているのでそちらからこの単語が入ってきたんだと思います。
参考にします。
あと皆さんすごいですねぇ。。
クラス設計書はうちの先輩社員が言っていてたまたま私が覚えていた単語です。
うちは富士通ではありませんが、富士通系列の某会社はお得意先で、
仕事をずっと取っているのでそちらからこの単語が入ってきたんだと思います。
システム内部仕様書だのの書き方にはちゃんとIEEEに規格があるみたいやね。
ttp://www.metabolics.co.jp/SoftwareProcess/ieee-scsm.html
に色々載ってる。
ttp://www.metabolics.co.jp/SoftwareProcess/ieee-scsm.html
に色々載ってる。
PMBOKオススメのSA/SD(構造化分析設計)のためのIDEF0/IDEF1Xっすか。
なんともはや・・・いやメタボリックの人が薦めるのなら・・・
IEEE Std. 1016-1998, IEEE Recommended Practice for Software Design Description
IEEE Std. 1320.1-1998, IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0
IDEF0は構造化分析/設計(SADT)を図式化したもの．UMLの前身か．DoD関係では使われていたのではないか? その定義自体がここで行なわれている．
UMLの状態図あるいはアクティビティ図に近い．
105 pp.
IEEE Std. 1320.2-1998, IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97(IDEFobject)
IDEF1Xは｢情報モデル｣を表現する．一方IDEF0は｢機能モデル｣を表現する．IDEF2は「動的モデル｣を表現するが，今では使われていない．
UMLのクラス図に近い．
303 pp.
なんともはや・・・いやメタボリックの人が薦めるのなら・・・
IEEE Std. 1016-1998, IEEE Recommended Practice for Software Design Description
IEEE Std. 1320.1-1998, IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0
IDEF0は構造化分析/設計(SADT)を図式化したもの．UMLの前身か．DoD関係では使われていたのではないか? その定義自体がここで行なわれている．
UMLの状態図あるいはアクティビティ図に近い．
105 pp.
IEEE Std. 1320.2-1998, IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97(IDEFobject)
IDEF1Xは｢情報モデル｣を表現する．一方IDEF0は｢機能モデル｣を表現する．IDEF2は「動的モデル｣を表現するが，今では使われていない．
UMLのクラス図に近い．
303 pp.
320 ：仕様書無しさん：2005/06/16(木) 15:45:15
使えなさ過ぎて技術系から業務系に回される人の話はよく聞きますが、
その逆はやっぱり無理なんでしょうか？
その逆はやっぱり無理なんでしょうか？
なんでそう思う？
業務系以外の方がインドなんかに食われるんじゃねーの。
業務系の上流工程はやつらに無理っぽいし。
業務系の上流工程はやつらに無理っぽいし。
日本の業務系がドカタ仕事から脱却して質が上がったとしても、
インドの優秀な技術者が大挙押しかけるから痛し痒しだなｗｗ
インドの優秀な技術者が大挙押しかけるから痛し痒しだなｗｗ
324 ：仕様書無しさん：2005/06/16(木) 20:19:09
外国に発注すると基本的にコストは安いんだが、
意思の疎通が難しいとか連絡取り合うの大変とかなんやらで結局工数がかかるんで
最終的にはあまりやすく上がらないって聴いたけどほんまかいな
意思の疎通が難しいとか連絡取り合うの大変とかなんやらで結局工数がかかるんで
最終的にはあまりやすく上がらないって聴いたけどほんまかいな
こういうとこでいきがってるやつが一番痛いわな
そうです。私たち業務系は１さんのようなスーパープログラマが作った
ソフトウェアを利用して組み合わせてシステムを構築してるだけなのです。
これからも使ってあげるから、すばらしいソフトウェアを世に送り出してね！
ソフトウェアを利用して組み合わせてシステムを構築してるだけなのです。
これからも使ってあげるから、すばらしいソフトウェアを世に送り出してね！
125 名前：非決定性名無しさん[] 投稿日：2005/06/14(火) 13:58:20
中国人、インド人を使うのは変動要素の少ない手間暇のかかる仕事を切り出すしかない。
業務アプリは不向きだ。技術センスのある人間を選んで各種ドライバソフトの開発等ではかなり
使えるらしい。個人技では奴らの方が上。英語もできるし、インターネットがらみの開発では
将来、日本人が脅かされる可能性は高い。
ただし彼らの辞書には忠誠心という用語は無い。
甘ちゃんの日本人マネージメントではノウハウを盗まれて途中で逃げられる可能性も高い。
奴らの日本語学習熱も凄いらしい。理由は一つ。日本語さえ出来れば個人技レベルでショボイ
日本人技術者から一気に仕事を奪える自信があるかららしい
中国人、インド人を使うのは変動要素の少ない手間暇のかかる仕事を切り出すしかない。
業務アプリは不向きだ。技術センスのある人間を選んで各種ドライバソフトの開発等ではかなり
使えるらしい。個人技では奴らの方が上。英語もできるし、インターネットがらみの開発では
将来、日本人が脅かされる可能性は高い。
ただし彼らの辞書には忠誠心という用語は無い。
甘ちゃんの日本人マネージメントではノウハウを盗まれて途中で逃げられる可能性も高い。
奴らの日本語学習熱も凄いらしい。理由は一つ。日本語さえ出来れば個人技レベルでショボイ
日本人技術者から一気に仕事を奪える自信があるかららしい
中華やインドが業務系向かんちゅーのは同感だな。
そもそも業務系には大した技術力は必要とされず、
客からの横槍でコロコロ変わる仕様への対応能力やコミュニケーション能力、
最終的には力技でどうにかする根性(w
といったものの方がはるかに重要。
持ってるモノにかなりインピーダンスマッチがあると思う。
多少人件費安くても割にあわんことが多いんじゃないか。
そもそも業務系には大した技術力は必要とされず、
客からの横槍でコロコロ変わる仕様への対応能力やコミュニケーション能力、
最終的には力技でどうにかする根性(w
といったものの方がはるかに重要。
持ってるモノにかなりインピーダンスマッチがあると思う。
多少人件費安くても割にあわんことが多いんじゃないか。
330 ：名無しさん：2005/06/16(木) 23:25:42
ちょっと思ったのですが、痛い人って業務系以外の人に多くないですか？
業務系の人は普通の人が多いと思います。
業務系の人は普通の人が多いと思います。
まとめると
技術畑の価値観で痛い人
即ち
一般社会では普通の人
って事になりますかね。
確かに普通に痛い人は業務系、無理だよなー。
人間系が多すぎる。
技術畑の価値観で痛い人
即ち
一般社会では普通の人
って事になりますかね。
確かに普通に痛い人は業務系、無理だよなー。
人間系が多すぎる。
332 ：仕様書無しさん：2005/06/17(金) 00:03:29
その通り。
業務系は、よほどのバカでない限り、普通の人でもできる仕事。
コンピュータ寄りになるほど、理屈っぽいヤツが集まる。
普通の人達はそれが痛いとうつるらしいが、
その連中も業務系は烏合の衆だと思っている。
結局お互いに、どう思われようと痛くもかゆくもない。
業務系は、よほどのバカでない限り、普通の人でもできる仕事。
コンピュータ寄りになるほど、理屈っぽいヤツが集まる。
普通の人達はそれが痛いとうつるらしいが、
その連中も業務系は烏合の衆だと思っている。
結局お互いに、どう思われようと痛くもかゆくもない。
>>331-332
なんだ、客先と直接交渉で済むような、
よっぽどショボい仕事しかしてねぇんだな。
規模の大きな業務系の下っ端現場マネージャのDQNぷりを知らねぇとはｗ
俺？例え技術系絡みでも、業務系のDQNとは話もしたくねぇ～よｗ
なんだ、客先と直接交渉で済むような、
よっぽどショボい仕事しかしてねぇんだな。
規模の大きな業務系の下っ端現場マネージャのDQNぷりを知らねぇとはｗ
俺？例え技術系絡みでも、業務系のDQNとは話もしたくねぇ～よｗ
なんで客先の交渉が必要という話が
客先の交渉で済む、って事になるのがわからん。
必要条件と十分条件くらい判らない奴に
システム設計なんてまかせられん。
釣られてやったぞ。
客先の交渉で済む、って事になるのがわからん。
必要条件と十分条件くらい判らない奴に
システム設計なんてまかせられん。
釣られてやったぞ。
相変わらず馬鹿だな。
お金じゃぶじゃぶ払ってくれる上玉のお客さん所で、
客先交渉できるのは極一握りの人間だけで、
後は本当に糞の役にも立たねぇ人格障害者が一杯詰まってる
って話だよ
お金じゃぶじゃぶ払ってくれる上玉のお客さん所で、
客先交渉できるのは極一握りの人間だけで、
後は本当に糞の役にも立たねぇ人格障害者が一杯詰まってる
って話だよ
336 ：仕様書無しさん：2005/06/17(金) 02:48:06
俺様がバカスカ売ってやってんだからよぉ、
もうちぃとまともなプログラム組んでくれないかなあ？
せっかく導入してくれたお客様に
「ドライバのバグです…申し訳ございません」
って頭下げなければならない営業の身にもなれってぇの
てめーら頭いいんだろ？ﾌﾟｯ
だったらちゃんと仕事しろ
もうちぃとまともなプログラム組んでくれないかなあ？
せっかく導入してくれたお客様に
「ドライバのバグです…申し訳ございません」
って頭下げなければならない営業の身にもなれってぇの
てめーら頭いいんだろ？ﾌﾟｯ
だったらちゃんと仕事しろ
337 ：仕様書無しさん：2005/06/17(金) 02:59:32
頭を下げるのがお前の仕事。
文句言わずにやれﾌﾟ
文句言わずにやれﾌﾟ
338 ：仕様書無しさん：2005/06/17(金) 03:08:04
私は九州生まれ、九州育ちです。
私が今までずっと疑問に持ってきたのは
「飴」のことを「飴ちゃん」と、関西の人は言うのですが
私は九州、（すくなくとも宮崎、熊本）では、聞いたことがないんです。
だからいまだに凄く、違和感があるんです。
どうしてお菓子の中でも「飴」のみを「飴ちゃん」というのでしょう
飴だけを、「ちゃんづけ」するのは、ほかのお菓子に対して
えこひいきしているような、そんな感覚を持ってしまうのです。
これは関西特有のものなのか、どうかがずっと気になっているのです
良かったら、教えて下さい。
「飴ちゃん」という表現は全国的なものなのか、そうでないのかが
知りたいのです。
駄スレで申し訳ありません・・・m(__)m
私が今までずっと疑問に持ってきたのは
「飴」のことを「飴ちゃん」と、関西の人は言うのですが
私は九州、（すくなくとも宮崎、熊本）では、聞いたことがないんです。
だからいまだに凄く、違和感があるんです。
どうしてお菓子の中でも「飴」のみを「飴ちゃん」というのでしょう
飴だけを、「ちゃんづけ」するのは、ほかのお菓子に対して
えこひいきしているような、そんな感覚を持ってしまうのです。
これは関西特有のものなのか、どうかがずっと気になっているのです
良かったら、教えて下さい。
「飴ちゃん」という表現は全国的なものなのか、そうでないのかが
知りたいのです。
駄スレで申し訳ありません・・・m(__)m
現場と営業のいがみ合いはこの業界に限った事じゃないな。
340 ：仕様書無しさん：2005/06/17(金) 03:10:13
でも結構、「飴ちゃん」は全国版のようですね(;^_^A
じゃーーー「ちょこれいと」や「びすけっと」の立場はーーー！！
と思ってしまう私の方がオカシイのかもかも（-_-;）
じゃーーー「ちょこれいと」や「びすけっと」の立場はーーー！！
と思ってしまう私の方がオカシイのかもかも（-_-;）
でその話題はこのすれに関係あるの？
342 ：仕様書無しさん：2005/06/17(金) 03:11:17
>>338
忘れちゃいけない関西弁に「～さん（はん）」と言うのがありますよね。「お芋さん」「お日ーさん」「お伊勢さん」「姫路を治めて居ったのは○○（大名の名前）さんや」という風に何にでも使われるようです。
関西文化の影響のある所なら使うのではないですか?
富山でも「報講（ほんこ）はん」というように語的には使うみたいです。
私の曾祖母が、出雲出身で足利弁・伊達弁が混ざるんですけど、「～さん」を使ってたみたいです。
「飴ちゃん」もこの手の言い方では?
忘れちゃいけない関西弁に「～さん（はん）」と言うのがありますよね。「お芋さん」「お日ーさん」「お伊勢さん」「姫路を治めて居ったのは○○（大名の名前）さんや」という風に何にでも使われるようです。
関西文化の影響のある所なら使うのではないですか?
富山でも「報講（ほんこ）はん」というように語的には使うみたいです。
私の曾祖母が、出雲出身で足利弁・伊達弁が混ざるんですけど、「～さん」を使ってたみたいです。
「飴ちゃん」もこの手の言い方では?
343 ：仕様書無しさん：2005/06/17(金) 03:12:12
サラリーマンになれば常識です。
「コカ・コーラさんからお電話です」
浅田飴も企業名じゃなかったかな？
「浅田飴さんからお電話です」
「コカ・コーラさんからお電話です」
浅田飴も企業名じゃなかったかな？
「浅田飴さんからお電話です」
自作自演しねや
345 ：仕様書無しさん：2005/06/17(金) 03:13:46
346 ：仕様書無しさん：2005/06/17(金) 03:15:46
>342
そんなやつおらへんやろ～
蚊のこと か～ちゃん っていうか？
そんなやつおらへんやろ～
蚊のこと か～ちゃん っていうか？
347 ：仕様書無しさん：2005/06/17(金) 03:23:19
348 ：仕様書無しさん：2005/06/17(金) 03:24:50
>>347
きっと営業＝客先交渉と勘違いしてるんじゃねぇか（ﾜﾗ
きっと営業＝客先交渉と勘違いしてるんじゃねぇか（ﾜﾗ
え？営業って伝書鳩みたいなもんじゃねーの？
見積もりからサポートまで技術にやらせてさ！
見積もりからサポートまで技術にやらせてさ！
そうだよ。具体的な話になるとＳＥ帯同だもん。
なんだ、新人か（はげわら
なんだ、しょぼしょぼ仕事 (推定工数＜２～３人月) の人か
353 ：仕様書無しさん：2005/06/17(金) 08:59:33
ここのレスを見て、
次に情報システム板のスレタイ (企業名除く) を見れば、
ここに粘着してるバカが業界外の素人である事がわかる。
次に情報システム板のスレタイ (企業名除く) を見れば、
ここに粘着してるバカが業界外の素人である事がわかる。
>>336さんは何か製品の営業ですか？
浄水器でも売り歩いてんだろｗ
業務システムの営業っつーより完成品の営業みたいやね。
357 ：仕様書無しさん：2005/06/17(金) 20:50:04
社内 業務システム作ってる奴ってどんな感じ？
きっと、名刺をお偉いさんの机の上に置いて回るタイプだよ。
359 ：名無しさん：2005/06/17(金) 21:07:49
見積もりやサポートは技術者の仕事じゃないですか？
私は優秀な営業を見たことがあります。
何がすごいかって、値段を言わない。
打ち合わせで客が探ってきても、ヒントになるようなことも全然言わない。
そのうち客がじれて、「○千万円でどうですか」と言って、
これが予想金額より多くても、ニコリともせずに、「うーーーむ。持ち帰って検討します。」
即答している技術者には営業は無理でしょう。
私は優秀な営業を見たことがあります。
何がすごいかって、値段を言わない。
打ち合わせで客が探ってきても、ヒントになるようなことも全然言わない。
そのうち客がじれて、「○千万円でどうですか」と言って、
これが予想金額より多くても、ニコリともせずに、「うーーーむ。持ち帰って検討します。」
即答している技術者には営業は無理でしょう。
360 ：名無しさん：2005/06/17(金) 21:19:57
ちなみに業務系以外と言うのは、パッケージ系の事ですか？
それで他んとこに仕事もってかれないのか？
>>364
２ｃｈだし、最近IT投資へ対する批判本も出てきたから書いちゃう。
現状のシステムを人質に取ってからやるテクニック。
企業のIT部門縮小化は、システムを人質に取れるので、
かなり美味しい。嫌われても金稼ぎたいなら、何ぼでも稼げる。
なーんて商売をやってるところは、利益率が高い。
２ｃｈだし、最近IT投資へ対する批判本も出てきたから書いちゃう。
現状のシステムを人質に取ってからやるテクニック。
企業のIT部門縮小化は、システムを人質に取れるので、
かなり美味しい。嫌われても金稼ぎたいなら、何ぼでも稼げる。
なーんて商売をやってるところは、利益率が高い。
で、悪評が立ってすぐに淘汰
>>366
それがなかなか淘汰されない。
システムを人質にとってるが、システムを人質に取ってるぞ、
なんて口に出して言う訳が無いんだから。
昔の商いは、覚悟が有ったけど、今はシステム担当者なんて
所詮サラリーマンなんだから、ベンダーやインテグレーターが、
システム人質に取っても、なんら抵抗できない。
返り血浴びる覚悟持ってるシステム担当者なんて居ない。し、
居たら潰しにかかるのがITベンダー。
IBMが始めたTOP営業ってやつね。
それがなかなか淘汰されない。
システムを人質にとってるが、システムを人質に取ってるぞ、
なんて口に出して言う訳が無いんだから。
昔の商いは、覚悟が有ったけど、今はシステム担当者なんて
所詮サラリーマンなんだから、ベンダーやインテグレーターが、
システム人質に取っても、なんら抵抗できない。
返り血浴びる覚悟持ってるシステム担当者なんて居ない。し、
居たら潰しにかかるのがITベンダー。
IBMが始めたTOP営業ってやつね。
ますます悪徳リフォーム会社と似てきた業務系ｗ
オレはある意味業務系のSEを尊敬してる。
あの人達WordとExcelがあれば仕事になるでしょ。
あと最近だとHTMLエディタとかかな？
OOとか開発ツールとか言語とかの知識ほとんどいらねー。
SQLだけはバリバリみたいだけどね。
あの人達WordとExcelがあれば仕事になるでしょ。
あと最近だとHTMLエディタとかかな？
OOとか開発ツールとか言語とかの知識ほとんどいらねー。
SQLだけはバリバリみたいだけどね。
>345
法「人」っていうぐらいだから「人」なんですよ。
「人」にさんをつけるのはおかしくないです。
法「人」っていうぐらいだから「人」なんですよ。
「人」にさんをつけるのはおかしくないです。
じゃあ関係が悪くなったら、氏をつけるんだな。
372 ：仕様書無しさん：2005/06/18(土) 13:34:46
>>369
へえ、そんな楽な仕事あるならぜひ紹介してくれ
へえ、そんな楽な仕事あるならぜひ紹介してくれ
>>266
あまり大きなモデルを作らないほうがいいことも、業務系ならある。
モデリング対象が自然界じゃなくて朝令暮改なユーザーだからさ、
あんまり真面目にドメインだのなんだのやっても１年後に全部パーに
なったり。そういうときは単純な業務処理を遷移でつないだ方が
作るのもメンテも楽。
あまり大きなモデルを作らないほうがいいことも、業務系ならある。
モデリング対象が自然界じゃなくて朝令暮改なユーザーだからさ、
あんまり真面目にドメインだのなんだのやっても１年後に全部パーに
なったり。そういうときは単純な業務処理を遷移でつないだ方が
作るのもメンテも楽。
>372
おまいがやってる仕事
おまいがやってる仕事
375 ：仕様書無しさん：2005/06/18(土) 21:32:43
>>370
ということは、法人格が無い社団の場合は、「さん」を付けることが出来ない。
ということは、法人格が無い社団の場合は、「さん」を付けることが出来ない。
376 ：仕様書無しさん：2005/06/18(土) 21:56:56
>>378
それは君も無知。
データからだろうが、画面からだろうが、どっちのアプローチも存在する。
業務の流れ、利用の把握が必須なんだから、両方からアプローチってのが普通だと思うけどね。
データだけからアプローチした場合、最後の段階で現場に使えないとか言われるパターンに入りやすい。
画面からだけだと、データ構造が現業務を引きずって改善って部分が薄くなりやすい。
それは君も無知。
データからだろうが、画面からだろうが、どっちのアプローチも存在する。
業務の流れ、利用の把握が必須なんだから、両方からアプローチってのが普通だと思うけどね。
データだけからアプローチした場合、最後の段階で現場に使えないとか言われるパターンに入りやすい。
画面からだけだと、データ構造が現業務を引きずって改善って部分が薄くなりやすい。
顧客がデータの話すら出来ない場合を考えると、
画面の遷移だけを提示して、あとはこちらでなんとかする場合が多かった。
担当者が変わるごとに画面を変更したりとか。。。
画面の遷移だけを提示して、あとはこちらでなんとかする場合が多かった。
担当者が変わるごとに画面を変更したりとか。。。
>>382
データモデル命でおじちゃんおばちゃんが使うってことを忘れてる人よりまし。
少なくとも使えるものは納品できるから。
両方のバランスを取ってシステムデザインできる人って、あんまりいないよな・・・
データモデル命でおじちゃんおばちゃんが使うってことを忘れてる人よりまし。
少なくとも使えるものは納品できるから。
両方のバランスを取ってシステムデザインできる人って、あんまりいないよな・・・
>>383
おいおい、それはちょっとまってくれ。
データモデルから入る人だってどこかでUIは作るさ。
UIなしで納品なんてできないんだから。
使いやすさ(UI)と整合性(データモデル)は別にあるって理解してるしね。
でも、画面から入る人は、データモデルやデータの流れにたどりつかない。
結果、つじつまの合わない(あってないことに気づけない)ものができあがる。
おいおい、それはちょっとまってくれ。
データモデルから入る人だってどこかでUIは作るさ。
UIなしで納品なんてできないんだから。
使いやすさ(UI)と整合性(データモデル)は別にあるって理解してるしね。
でも、画面から入る人は、データモデルやデータの流れにたどりつかない。
結果、つじつまの合わない(あってないことに気づけない)ものができあがる。
>>384
だからバランスだとみんな書いてるだろ？
>>378が自分の基準だけで他人を馬鹿といってるけど、自分も馬鹿だと気付いてない。
客迎合しすぎてデータの流れが無茶なのもNG。
プログラム都合を利用者に押し付けるのもNG。
だからバランスだとみんな書いてるだろ？
>>378が自分の基準だけで他人を馬鹿といってるけど、自分も馬鹿だと気付いてない。
客迎合しすぎてデータの流れが無茶なのもNG。
プログラム都合を利用者に押し付けるのもNG。
>384
読解力ない君にはなにやらせてもろくなものできなそうだね
読解力ない君にはなにやらせてもろくなものできなそうだね
>>385
いやあ、画面しか見てない人はかなりいるが、
データモデルしか見てない人は存在しないってことが言いたかっただけなんだけど。
UI作らないわけにいかないんだから。
で、バランスなんだってことは当たり前のこととして、じゃあどっからはいるのが適切かっていうと、
やっぱりデータモデルから入るのが整合性が保証しやすくて良いのではないかと。
>>381も書いてるけど、客はたいてい画面のことしか見ないわけですよ。
客がそうなのはそれでいい。
でも、そこで迎合しすぎるのを防ぐためには、まずデータの流れを抑えておかないと
良し悪しがわからない。
だから、「最初に画面から始める」ってのはアウトな手法と言いたい。
>>380も書いてるとおり、「画面からだけだとデータ構造が現業務のままになりやすい」
それを防ぐためにも、いったん画面から離れたところから考えはじめたい。
データモデルを考えることが「プログラム都合」てことはないよ。
客の要望をきちんとした形で最大限満たすためにやってることです。
いやあ、画面しか見てない人はかなりいるが、
データモデルしか見てない人は存在しないってことが言いたかっただけなんだけど。
UI作らないわけにいかないんだから。
で、バランスなんだってことは当たり前のこととして、じゃあどっからはいるのが適切かっていうと、
やっぱりデータモデルから入るのが整合性が保証しやすくて良いのではないかと。
>>381も書いてるけど、客はたいてい画面のことしか見ないわけですよ。
客がそうなのはそれでいい。
でも、そこで迎合しすぎるのを防ぐためには、まずデータの流れを抑えておかないと
良し悪しがわからない。
だから、「最初に画面から始める」ってのはアウトな手法と言いたい。
>>380も書いてるとおり、「画面からだけだとデータ構造が現業務のままになりやすい」
それを防ぐためにも、いったん画面から離れたところから考えはじめたい。
データモデルを考えることが「プログラム都合」てことはないよ。
客の要望をきちんとした形で最大限満たすためにやってることです。
>>387
そんなのどっちもどっち。原理主義的で排他な思想は話しにくい。
でも、データ主導型といってもそもそもの現物ってのは業務でありその操作画面だからね。
最初がそこなので、いきなりデータってものが概念だけ存在するわけじゃない。
そんなのどっちもどっち。原理主義的で排他な思想は話しにくい。
でも、データ主導型といってもそもそもの現物ってのは業務でありその操作画面だからね。
最初がそこなので、いきなりデータってものが概念だけ存在するわけじゃない。
>>387
わたしの経験だと、データモデルに最も重みを置く人にとって
UIは付け足しなんだよ。「俺のモデルは美しいだろう」って
レベルで満足していて、使い勝手を気にしない人がすんごい多い。
UIって「作らないわけにいかない」程度の認識で作って現場に
持ってくと首を絞められかねんのだが。作業効率に直接関わって
くる部分なのに経営層はなぜか気にしないけど。
わたしの経験だと、データモデルに最も重みを置く人にとって
UIは付け足しなんだよ。「俺のモデルは美しいだろう」って
レベルで満足していて、使い勝手を気にしない人がすんごい多い。
UIって「作らないわけにいかない」程度の認識で作って現場に
持ってくと首を絞められかねんのだが。作業効率に直接関わって
くる部分なのに経営層はなぜか気にしないけど。
ちょっと無理やりこのスレの流れに摺り寄せるけど、
業務系で使えない奴ってそういうバランスとかすり合わせが出来ない奴だよ。
業務だけがとにかく優先でシステムを知らない営業ＳＥもそうだし、
業務を全く考えないプログラマもそう。
他の分野から見た場合、前者はシステムとかプログラムを知らない癖にという対象だし、
後者は他の分野をりプログラムレベルが低いだけのプログラマ。
で、私が思う理想的な業務系技術者てのは、あくまで業務を考えるのが主で
それをシステムでどう表現するかを考えデザインできる人。
業務系で使えない奴ってそういうバランスとかすり合わせが出来ない奴だよ。
業務だけがとにかく優先でシステムを知らない営業ＳＥもそうだし、
業務を全く考えないプログラマもそう。
他の分野から見た場合、前者はシステムとかプログラムを知らない癖にという対象だし、
後者は他の分野をりプログラムレベルが低いだけのプログラマ。
で、私が思う理想的な業務系技術者てのは、あくまで業務を考えるのが主で
それをシステムでどう表現するかを考えデザインできる人。
391 ：仕様書無しさん：2005/06/19(日) 11:39:54
そして業務システムコンサルの会社を作る
392 ：仕様書無しさん：2005/06/19(日) 11:50:04
しかし、コンサルティングという業種は、
強力な営業力があって初めて成り立つものであり、
知識や技術だけで客がついてきてくれると思ったら大間違い。
強力な営業力があって初めて成り立つものであり、
知識や技術だけで客がついてきてくれると思ったら大間違い。
>>390
薬にも毒にもならないレスだな
薬にも毒にもならないレスだな
使い勝手を軽んじてる奴は氏ね、じゃなくて死ね。
UIのようなもっとも変動性の高い要素より、モデルのようにより変動性の低い
要素から固めていくのは基本だろ。
抽象から具象、概要から詳細。画面は変動性が高く具体的で詳細なるものの
最たるもんだ。
ドキュメントは複数のビュー表現を持てるんだし。
てめーらMVCって知ってるか？
ま、業務系は画面の裏側で別に大したことやってるわけじゃねーからこれで
済むんだろうな。
で、大したモン作ってるわけじゃねーのに使い勝手だのバランスだのと、
威張ってやがる。
おおかた昔の端末エントリに慣れたユーザのためにEnterでフォーカス遷移
させたりとかそういう下らないUI要素の苦労話程度が関の山なんだろ？
要素から固めていくのは基本だろ。
抽象から具象、概要から詳細。画面は変動性が高く具体的で詳細なるものの
最たるもんだ。
ドキュメントは複数のビュー表現を持てるんだし。
てめーらMVCって知ってるか？
ま、業務系は画面の裏側で別に大したことやってるわけじゃねーからこれで
済むんだろうな。
で、大したモン作ってるわけじゃねーのに使い勝手だのバランスだのと、
威張ってやがる。
おおかた昔の端末エントリに慣れたユーザのためにEnterでフォーカス遷移
させたりとかそういう下らないUI要素の苦労話程度が関の山なんだろ？
画面から入るってのは業務をちゃんとモデル化できてない証拠
昔のオンラインシステムをリプレースする、などの要件で
もともと画面が存在する場合にありがちなパターンだな
見えてる画面だけで話が進んじゃう
昔のオンラインシステムをリプレースする、などの要件で
もともと画面が存在する場合にありがちなパターンだな
見えてる画面だけで話が進んじゃう
いやぁ スレタイ通りの人が次から次へと・・
業務系って画面とデータだけですべてが片付くからアレだねｗ
業務系って画面とデータだけですべてが片付くからアレだねｗ
>>395
画面はアプリケーション設計上大切なんじゃなくて、業務フローの設計上大切。
だれも、設計の段階でも画面からやるのがいい、とは言ってない。
業務システムが技術的に対したことやってないのは確かだ。
むかし、金がないという5店舗の小売業にExcelとVBAで販売管理を書いた。
場合によってはその程度のスキルでもいい。ただし儲けに役立たんとだめ。
金儲けのために、たまたまコンピュータを使ってる世界だから、
設計・プログラミング「だけ」が好きな人には向かないよ。
画面はアプリケーション設計上大切なんじゃなくて、業務フローの設計上大切。
だれも、設計の段階でも画面からやるのがいい、とは言ってない。
業務システムが技術的に対したことやってないのは確かだ。
むかし、金がないという5店舗の小売業にExcelとVBAで販売管理を書いた。
場合によってはその程度のスキルでもいい。ただし儲けに役立たんとだめ。
金儲けのために、たまたまコンピュータを使ってる世界だから、
設計・プログラミング「だけ」が好きな人には向かないよ。
401 ：仕様書無しさん：2005/06/19(日) 19:55:59
だから簿記とか勉強するんだろ。
企業活動の基本だからね。
データの流れ＝金の流れと考えられないとダメだよな。
データの流れ＝金の流れと考えられないとダメだよな。
でも金ばかりに目がいって、ユーザの幹部連の言うこと鵜呑みにして在庫を
極限するシステムを作ったら注文に応えられなくなって大慌て。
なんて楽しい事態もありうるしな。
極限するシステムを作ったら注文に応えられなくなって大慌て。
なんて楽しい事態もありうるしな。
>>403
それはそれでいいんじゃないのか？
システムが柔軟じゃなくて改造とかパラメータで対応できなかったら嫌だけど。
プログラマーっていうだけの人間って不要でしょ。
デジドカ的案件でもし必要でもそれなら日本人じゃなくていいわけだし。
そもそも、業務系でもそういう超巨大案件って少なくなってきてるし。
それはそれでいいんじゃないのか？
システムが柔軟じゃなくて改造とかパラメータで対応できなかったら嫌だけど。
プログラマーっていうだけの人間って不要でしょ。
デジドカ的案件でもし必要でもそれなら日本人じゃなくていいわけだし。
そもそも、業務系でもそういう超巨大案件って少なくなってきてるし。
そうやって設計や開発をおろそかにするから火を噴くんだろ
まあ一番の原因は「そこ」じゃねーけどな
まあ一番の原因は「そこ」じゃねーけどな
>>398ってつまんない釣り？
それとも本気でそう思ってる痛い人？
それとも本気でそう思ってる痛い人？
ん？本気なんじゃねーの？
計算機処理なんてメモリだのI/Oポートだのからなんか読み出したり
書き込んだり足したり引いたりしたりするだけだろ
それをより抽象化して高級にデータだのアルゴリズムだの言ってるだけじゃん
計算機処理なんてメモリだのI/Oポートだのからなんか読み出したり
書き込んだり足したり引いたりしたりするだけだろ
それをより抽象化して高級にデータだのアルゴリズムだの言ってるだけじゃん
マ板を見てればわかるが、
ここ最近ゴミが会社に入ってプログラマ自称してるもんだから
日本では「プログラマ」はゴミの代名詞なんだよ。
ここ最近ゴミが会社に入ってプログラマ自称してるもんだから
日本では「プログラマ」はゴミの代名詞なんだよ。
>>408
ヒトも原子の(略
ヒトも原子の(略
>>408
その論理はアリなの？
その論理はアリなの？
なんで高尚な意見が必要なんだ？
うは。痛々しい。
アフォのせいで「言葉遊び」のスレになっちゃったな
高尚なご意見ってなんなんだw
で、釣りとか逝ってる奴はまともな反論もなしに釣りとか書いてるのか？
なんか名無しだと誰が誰だかよくわからんのだが
>>408だが
まあ、>>408は極論だろうな
だが、ある意味それが計算機の本質であるのも事実だ。
アルゴリズム＋データ構造＝プログラム
はWirthの古典だが、
結局のところ、今の計算機も当時と同じノイマン型のアーキテクチャであって、
GUIが流行ろうがオブジェクト指向が流行ろうがネットワーキングが主流に
なろうが、その本質だけは変わらない。
で、この古典的認識がDQNだと言ってる根拠は何なんだ？
俺はその説明が聞きたいな。
まあ、>>408は極論だろうな
だが、ある意味それが計算機の本質であるのも事実だ。
アルゴリズム＋データ構造＝プログラム
はWirthの古典だが、
結局のところ、今の計算機も当時と同じノイマン型のアーキテクチャであって、
GUIが流行ろうがオブジェクト指向が流行ろうがネットワーキングが主流に
なろうが、その本質だけは変わらない。
で、この古典的認識がDQNだと言ってる根拠は何なんだ？
俺はその説明が聞きたいな。
いつになく荒れているようですが。
計算機の話をしているのか、プログラムの話をしているのかよく分かってないですが、
計算機処理の本質は入力と出力ではないんですかね。
計算機の話をしているのか、プログラムの話をしているのかよく分かってないですが、
計算機処理の本質は入力と出力ではないんですかね。
427 ：仕様書無しさん：2005/06/19(日) 21:58:08
428 ：仕様書無しさん：2005/06/19(日) 22:04:32
どっちもどっち
イタい事には変わりない
イタい事には変わりない
>>395辺り
ICONIXのユースケース駆動開発では、
・ドメインモデリングによるデータ構造の抽出
・簡単な画面スケッチをたたき台とした、
ユースケース手法による要求機能の抽出
という二つの軸に沿って、分析～設計を進める。
これは今野氏も長瀬氏も、はたまた豆蔵創設者も、インアルカディア藤野氏も
認めている共通認識である点に注意。
ICONIXのユースケース駆動開発では、
・ドメインモデリングによるデータ構造の抽出
・簡単な画面スケッチをたたき台とした、
ユースケース手法による要求機能の抽出
という二つの軸に沿って、分析～設計を進める。
これは今野氏も長瀬氏も、はたまた豆蔵創設者も、インアルカディア藤野氏も
認めている共通認識である点に注意。
>>431
・・・それをやる人を、貴方は何と呼んでいるかを知りたいな
・・・それをやる人を、貴方は何と呼んでいるかを知りたいな
画面なんて後からでいいんですよ・・・
ってコンサルの一言で後々グズグズになったプロジェクトが結構あるんだけどなぁ。
具体→抽象→具体→抽象・・・
抽象から入ると仕様の甘いプロジェクトになりがち。
具体から入るとメンドクサイから大きな変更しないんだよな。
ってコンサルの一言で後々グズグズになったプロジェクトが結構あるんだけどなぁ。
具体→抽象→具体→抽象・・・
抽象から入ると仕様の甘いプロジェクトになりがち。
具体から入るとメンドクサイから大きな変更しないんだよな。
>>433
「業務系オブジェクト指向コンサル」とでも呼ぶのかな。
貴方は多分、私が会った事がある人物であり、
かつて２ちゃん上で「ロバストネス分析はICONIX本に載っている」
と紹介してくれた方ではないかと思う。
ICONIX本は先見性とユニークさとシンプルさを兼ね備えたすばらしい本だと感じるが、
国内ではどちらかというと軽視されている気がする。
例えば >>431 に挙げた名前の一つと関連する仕事をした時にも、
ICONIX本の話は一回も出なかったし、またICONIX手法の話もほとんど通じなかった。
これはどういう事なのだろうか。
「業務系オブジェクト指向コンサル」とでも呼ぶのかな。
貴方は多分、私が会った事がある人物であり、
かつて２ちゃん上で「ロバストネス分析はICONIX本に載っている」
と紹介してくれた方ではないかと思う。
ICONIX本は先見性とユニークさとシンプルさを兼ね備えたすばらしい本だと感じるが、
国内ではどちらかというと軽視されている気がする。
例えば >>431 に挙げた名前の一つと関連する仕事をした時にも、
ICONIX本の話は一回も出なかったし、またICONIX手法の話もほとんど通じなかった。
これはどういう事なのだろうか。
他の方への紹介：ICONIX本とは、この書籍です。
ユースケース入門―ユーザマニュアルからプログラムを作る Object Technology Series
http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/
ユースケース入門―ユーザマニュアルからプログラムを作る Object Technology Series
http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/
>>395
Enterでフォーカス遷移なんてものは使い勝手の表層にすぎない。使い勝手の本質は
ユーザーさんを「直感的なオペレーション」が実現できてるかのように勘違いさせつつ
ルールの囲いに「誘導」することにある。
Enterでフォーカス遷移なんてものは使い勝手の表層にすぎない。使い勝手の本質は
ユーザーさんを「直感的なオペレーション」が実現できてるかのように勘違いさせつつ
ルールの囲いに「誘導」することにある。
横レスだけど。ロバストネス分析って
ユースケースからオブジェクトを抽出する分析方法
でいいの？
・・・手順が逆のような気がするのはｵﾚﾀﾞｹﾀﾞﾛｳｶ
ユースケースからオブジェクトを抽出する分析方法
でいいの？
・・・手順が逆のような気がするのはｵﾚﾀﾞｹﾀﾞﾛｳｶ
違う。
安くて読みやすい本だから、自分で買って勉強する事を薦める。
またオブジェクト指向の広場に関連記事があるから、それにも目を通すと良い。
安くて読みやすい本だから、自分で買って勉強する事を薦める。
またオブジェクト指向の広場に関連記事があるから、それにも目を通すと良い。
441 ：名無しさん：2005/06/20(月) 17:23:32
話が戻りますが、ＯＳもゲームもパッケージな訳で（組み込みはちょっと違うかも知れませんが）、
パッケージ系ＶＳ業務系と言うことみたいですね。
ただパッケージ系をやったことある人が、業務系を馬鹿にするという無意味なことはあまりしないと
思うのですが、もしかしたら「パッケージ系に憧れる、業務系が嫌になった業務系の人が、
業務系を馬鹿にするというスレ」ではないでしょうか？
パッケージ系ＶＳ業務系と言うことみたいですね。
ただパッケージ系をやったことある人が、業務系を馬鹿にするという無意味なことはあまりしないと
思うのですが、もしかしたら「パッケージ系に憧れる、業務系が嫌になった業務系の人が、
業務系を馬鹿にするというスレ」ではないでしょうか？
>>441
いや、ただ単にどの分野であっても自分の技量に自身がもてない馬鹿が、
他人を見下すことで精神バランスを保ってるだけだろ？
無知な思い込みというか、ステレオタイプな書き込みだけだもんな。
業務系開発がそんなにダメとかっていうなら、世の中にあふれるシステムななんなんだと。
いや、ただ単にどの分野であっても自分の技量に自身がもてない馬鹿が、
他人を見下すことで精神バランスを保ってるだけだろ？
無知な思い込みというか、ステレオタイプな書き込みだけだもんな。
業務系開発がそんなにダメとかっていうなら、世の中にあふれるシステムななんなんだと。
443 ：仕様書無しさん：2005/06/20(月) 17:41:59
専門性が低い人は、どっちでもいいんだろうね。
サイエンス系研究開発や、
基盤系ミドルウェア研究開発の人間からすると、
業務系の多くは頭の中に事務作業の事しかないうわっ付いた土方に見える
サイエンス系研究開発や、
基盤系ミドルウェア研究開発の人間からすると、
業務系の多くは頭の中に事務作業の事しかないうわっ付いた土方に見える
> 業務系開発がそんなにダメとかっていうなら、世の中にあふれるシステムななんなんだと。
そうだよな。世の中にあふれてる道路や線路や橋は誰が作ってると思ってんだよ。
あ、ドカタか！？ｗ
そうだよな。世の中にあふれてる道路や線路や橋は誰が作ってると思ってんだよ。
あ、ドカタか！？ｗ
だから何？
じゃあ家電を作ってるのは誰？中国の工員さんか？
家電って随分と馬鹿な人たちが作ってるんですね。
じゃあ家電を作ってるのは誰？中国の工員さんか？
家電って随分と馬鹿な人たちが作ってるんですね。
なんか人に言われた通りに作る仕事しかイメージできない人がいますねｗ
>>443
たぶん釣りで書いてるんだろうけど。研究開発ってのは国や儲けてる会社が
頭のいい好き者に捨てぶちを与えて遊ばせて将来に備えてるって「側面」を、あなた見逃してるんじゃないの。
ノブレス・オブリージュって言葉を知ってるんなら、
あなたらが俺ら下々の稼ぎを使って遊んでるんだってことを、記憶の片隅に止めておいてくれよ。
たぶん釣りで書いてるんだろうけど。研究開発ってのは国や儲けてる会社が
頭のいい好き者に捨てぶちを与えて遊ばせて将来に備えてるって「側面」を、あなた見逃してるんじゃないの。
ノブレス・オブリージュって言葉を知ってるんなら、
あなたらが俺ら下々の稼ぎを使って遊んでるんだってことを、記憶の片隅に止めておいてくれよ。
いや単に組織に必要な新技術育成/導入と、
対外的/内部的な技術ヒエラルキーの形成が目的でしょ。
もっとも製造業と違ってソフトウェア業界では
日本方式はなかなかうまくいっていないけどね（藁
対外的/内部的な技術ヒエラルキーの形成が目的でしょ。
もっとも製造業と違ってソフトウェア業界では
日本方式はなかなかうまくいっていないけどね（藁
そして単なる新人なら成長を５年位待って見切りをつける所を、
研究職だと大体10年位待って、ビジネス的に物になるアウトプットを出せなければ、
どっかのビジネス化に成功した研究プロジェクトの現場展開に回される、と。
そして「物になる/物にならない」の判断基準が恣意的なのは、普通の新人も研究職も同じ（藁
研究職だと大体10年位待って、ビジネス的に物になるアウトプットを出せなければ、
どっかのビジネス化に成功した研究プロジェクトの現場展開に回される、と。
そして「物になる/物にならない」の判断基準が恣意的なのは、普通の新人も研究職も同じ（藁
450 ：名無しさん：2005/06/20(月) 22:25:52
>>442
しかしそのような時期は長続きしないと思いませんか？
半年もすれば自分位置も分かるはず。つまり新人と言うことですか。
時期的に言うとこういう事でしょうか。
「夢と希望にあふれて入社してきた新人が、業務に就いて、
俺のやりたかったことはこんな事じゃない！！研究開発がやりたかったんだ！！
と言いたいんだけどそこまで自信がないから、とりあえず業務の悪口。」
こんな所でしょうか。
でも安心してください、新人の方々。
新入社員で研究開発に回されることはありません。
数年やって才能があればそういう機会にも恵まれると思いますよ。
しかしそのような時期は長続きしないと思いませんか？
半年もすれば自分位置も分かるはず。つまり新人と言うことですか。
時期的に言うとこういう事でしょうか。
「夢と希望にあふれて入社してきた新人が、業務に就いて、
俺のやりたかったことはこんな事じゃない！！研究開発がやりたかったんだ！！
と言いたいんだけどそこまで自信がないから、とりあえず業務の悪口。」
こんな所でしょうか。
でも安心してください、新人の方々。
新入社員で研究開発に回されることはありません。
数年やって才能があればそういう機会にも恵まれると思いますよ。
>>450
あるよ。いたもん、漏れ。
あるよ。いたもん、漏れ。
>>451だった...orz
454 ：仕様書無しさん：2005/06/20(月) 23:38:28
業務システムやってて、
ある程度の規模の研究開発部門持ってる会社は、
勝ち組 (除く：自腹で研究開発/社長命令でプレハブで研究開発)
ある程度の規模の研究開発部門持ってる会社は、
勝ち組 (除く：自腹で研究開発/社長命令でプレハブで研究開発)
実際、資金援助を受けてるところは監査が入るので、
ひどい待遇を受ける確率はかなり低い予定。
ひどい待遇を受ける確率はかなり低い予定。
>>424
プログラマとしての立場からすると、痛いほど良く分かる。
でも、顧客や営業から見ると、プログラムのデータ･論理構造や、
下手をすると品質よりも「使い易さ」や「デザイン」の方に価値がある。
逆にいうと、業務系は美しいアルゴリズムや
洗練されたデータ構造だけではカネを取れない世界だ。
昔、典型的システム屋に業務系プログラムを組ませたことがある。
必要な機能要件、システムの品質は確かに揃っておりソースも洗練されていたが、
入力する文字の大きさが小さかったり、デザインが顧客要望に応えられる
レベルではなかったりで、顧客からはクレーム噴出しまくりだったよ。
むしろ品質には難があっても、顧客の要望を、使い勝手レベルで取り入れた
別システムの方が受けが良かった。
良くも悪くも業務系はそんな世界。
プログラマとしての立場からすると、痛いほど良く分かる。
でも、顧客や営業から見ると、プログラムのデータ･論理構造や、
下手をすると品質よりも「使い易さ」や「デザイン」の方に価値がある。
逆にいうと、業務系は美しいアルゴリズムや
洗練されたデータ構造だけではカネを取れない世界だ。
昔、典型的システム屋に業務系プログラムを組ませたことがある。
必要な機能要件、システムの品質は確かに揃っておりソースも洗練されていたが、
入力する文字の大きさが小さかったり、デザインが顧客要望に応えられる
レベルではなかったりで、顧客からはクレーム噴出しまくりだったよ。
むしろ品質には難があっても、顧客の要望を、使い勝手レベルで取り入れた
別システムの方が受けが良かった。
良くも悪くも業務系はそんな世界。
457 ：456：2005/06/21(火) 00:12:31
>>385
ちょいと聞きますが、データモデルを作る時に、どのデータが何処で把握されてるか
ヒヤリングしませんか？経理が入力してた営業データは、営業事務が経理向けに
加工してたデータだったりしやしませんか？出口に欲しいデータは何時どこでどのように
把握されてるのか？
画面から設計するのはやばいんですよ。
もちろん、顧客と会話をするために画面を見せる事も有りますが名、今時まったくの手作業
からコンピューター化なんて無いのですから。
>>389
業務系のSEにとっては、UIは付けたしってのは有る意味正解です。
であるから、業務系のプログラマーは、UIのスペシャリストで居たい
わけなんですが・・・・。
売掛買掛と、売上支払、の違いすら分かって無いヤバイSEさんまで居る・・・
ちょいと聞きますが、データモデルを作る時に、どのデータが何処で把握されてるか
ヒヤリングしませんか？経理が入力してた営業データは、営業事務が経理向けに
加工してたデータだったりしやしませんか？出口に欲しいデータは何時どこでどのように
把握されてるのか？
画面から設計するのはやばいんですよ。
もちろん、顧客と会話をするために画面を見せる事も有りますが名、今時まったくの手作業
からコンピューター化なんて無いのですから。
>>389
業務系のSEにとっては、UIは付けたしってのは有る意味正解です。
であるから、業務系のプログラマーは、UIのスペシャリストで居たい
わけなんですが・・・・。
売掛買掛と、売上支払、の違いすら分かって無いヤバイSEさんまで居る・・・
>457
性能・生産性の向上に寄与するならば
エロゲーを作らせる方が投資するけどな。
性能・生産性の向上に寄与するならば
エロゲーを作らせる方が投資するけどな。
460 ：456：2005/06/21(火) 00:44:13
>>459
抽象論ではなく、具体的に話そうよ。
絵炉ゲー作りには絵師さんの工数、音声さんの工数、PGの工数、
脚本さんの工数などがある。
通常の二次元絵炉ゲーでは、どうみても全体の工数から見た、
PGの工数は決して多くない。
つまり、製作者の側から見て投資する理由はない。
性能の件に関しても反対だ。例えば、お前は
「標準のゲームよりも2倍早くおっぱいが揺れます！」
とかいう謳い文句のゲームに魅力を感じるか？
顧客が魅力を感じないモノに投資する投資家はいないよ。
抽象論ではなく、具体的に話そうよ。
絵炉ゲー作りには絵師さんの工数、音声さんの工数、PGの工数、
脚本さんの工数などがある。
通常の二次元絵炉ゲーでは、どうみても全体の工数から見た、
PGの工数は決して多くない。
つまり、製作者の側から見て投資する理由はない。
性能の件に関しても反対だ。例えば、お前は
「標準のゲームよりも2倍早くおっぱいが揺れます！」
とかいう謳い文句のゲームに魅力を感じるか？
顧客が魅力を感じないモノに投資する投資家はいないよ。
462 ：456：2005/06/21(火) 00:48:02
やはり論点がズレていると思う。まあどうでもよいが。
464 ：456：2005/06/21(火) 00:55:31
上の方での議論って、>>397>>398あたりに端を発してて、
>>408=>>424は、計算機プログラムについての原理的な説明をしとるだけだろ。
そこでは別にコンピューティングという人の営み一般や、そこに発生する
商行為については念頭にさえ置かれていないし、議論の対象となっていない。
それに対する>>456のレスってのは、なんつーか花に関する植物学的
説明に対して「いや花は愛でるもんだ」と突っ込んでるようなものであって、
全くのナンセンスというか、ドメインというものを全く考慮してない。
>>408=>>424は、計算機プログラムについての原理的な説明をしとるだけだろ。
そこでは別にコンピューティングという人の営み一般や、そこに発生する
商行為については念頭にさえ置かれていないし、議論の対象となっていない。
それに対する>>456のレスってのは、なんつーか花に関する植物学的
説明に対して「いや花は愛でるもんだ」と突っ込んでるようなものであって、
全くのナンセンスというか、ドメインというものを全く考慮してない。
まあ痛いのは自覚しとるようだがの。
議論のスリカエということで言えば、
システム設計、プログラム設計の巧拙を論じているときに
「そんなのは業務系じゃ大した問題じゃない、設計のいいプログラム
作ったところで、飯は食えない」
というのも、厳密にはすりかえだろうな。
設計と営業は独立した問題なんだから。設計より営業が重要であろうが
そうでなかろうが、設計が良いほうが望ましいのは事実だし、
良い設計について議論することは可能なはずなのだ。
システム設計、プログラム設計の巧拙を論じているときに
「そんなのは業務系じゃ大した問題じゃない、設計のいいプログラム
作ったところで、飯は食えない」
というのも、厳密にはすりかえだろうな。
設計と営業は独立した問題なんだから。設計より営業が重要であろうが
そうでなかろうが、設計が良いほうが望ましいのは事実だし、
良い設計について議論することは可能なはずなのだ。
そこに発生する性行為は別途見積もってもらってくださいね
花びらは好きですよ
自分が入社１年目に作ったソース見たら
寒気がしてきた‥これ人に見られたらﾃﾗﾔﾊﾞｽ
寒気がしてきた‥これ人に見られたらﾃﾗﾔﾊﾞｽ
>470
おまえのソースは今でも十分やばいよ。
ダメな例として新人研修に使わせてもらってる。
おまえのソースは今でも十分やばいよ。
ダメな例として新人研修に使わせてもらってる。
472 ：仕様書無しさん：2005/06/21(火) 06:14:30
エロゲの例えで言うと、昔エロゲのキャラが実は男だった事件を
思い浮かべたらいい。いくら魅力的なキャラでも、データ構造が
目的と合わなから、ユーザーから物凄いクレームが付いた。
まっこの場合クレーム付ける方もどうかと思うが。
思い浮かべたらいい。いくら魅力的なキャラでも、データ構造が
目的と合わなから、ユーザーから物凄いクレームが付いた。
まっこの場合クレーム付ける方もどうかと思うが。
>>467
それはそうだが。しかしやっぱり立場による。
当然良い設計に興味があるけど、そこだけ切り出して議論することは
無意味であるという役割を、業務系の人間は割り振られている。
技術ってのはそれを適用する環境を無視して議論すると、とんでもない
結論になりやすいから危険だよ。
もちろん研究開発は別だけど。でもそれは現場の人間が“仕事”で考える
ことじゃないし。
それはそうだが。しかしやっぱり立場による。
当然良い設計に興味があるけど、そこだけ切り出して議論することは
無意味であるという役割を、業務系の人間は割り振られている。
技術ってのはそれを適用する環境を無視して議論すると、とんでもない
結論になりやすいから危険だよ。
もちろん研究開発は別だけど。でもそれは現場の人間が“仕事”で考える
ことじゃないし。
474 ：456：2005/06/21(火) 08:20:04
>>765
だからスレタイ（ｒｙ
このスレのドメインはあくまでも「業務系」であって、おまいの話
（プログラムの抽象論）はいわばサブドメインだろう。
俺はサブドメインの話をメインに戻しただけだよ。
うぉう。遅刻するからこの辺で。
だからスレタイ（ｒｙ
このスレのドメインはあくまでも「業務系」であって、おまいの話
（プログラムの抽象論）はいわばサブドメインだろう。
俺はサブドメインの話をメインに戻しただけだよ。
うぉう。遅刻するからこの辺で。
このスレあげるやついたいよね。
このスレあげるやつ
いたいよね。
このスレあげるやつ
いたいよね。
自作自演の練習?
>>458
だからバランスだと・・・。
あんた自分が正しいって言ってもらわないとダメな人なんか？
で、データの把握ってのは入力される”画面”や、出力される”帳票”から把握しますよね。
それをモデル化して整合とって画面にフィードバックしてUIの打ち合わせやって・・・を繰り返すのが仕事でしょ？
あんたの言い方はモデル完璧なら画面は自動的に付いて来るから、客はそれ使いやがれって聞こえるけど。
だからバランスだと・・・。
あんた自分が正しいって言ってもらわないとダメな人なんか？
で、データの把握ってのは入力される”画面”や、出力される”帳票”から把握しますよね。
それをモデル化して整合とって画面にフィードバックしてUIの打ち合わせやって・・・を繰り返すのが仕事でしょ？
あんたの言い方はモデル完璧なら画面は自動的に付いて来るから、客はそれ使いやがれって聞こえるけど。
俺より優秀な業務系は居ないと思っています。
>>479
奇遇だなあ、俺と一緒だ
奇遇だなあ、俺と一緒だ
482 ：仕様書無しさん：2005/06/21(火) 14:41:22
業務系の方々は、何に対してモチベーションを感じるのでしょうか？
>>482
とても良い質問だと思うので非業務系の俺に少し予想させてくれ。
顧客の業務を高度化してあげる事により顧客の市場競争力を(ry
顧客の業務を省力化してあげる事により顧客の利益の(ry
顧客の感謝
仕事だから
・・・うーん認識が浅いなぁ。本当の業務系の人に答えてもらいたいなorz
とても良い質問だと思うので非業務系の俺に少し予想させてくれ。
顧客の業務を高度化してあげる事により顧客の市場競争力を(ry
顧客の業務を省力化してあげる事により顧客の利益の(ry
顧客の感謝
仕事だから
・・・うーん認識が浅いなぁ。本当の業務系の人に答えてもらいたいなorz
やっぱりお客さんと直接顔をあわせられることかな。
でもこれだけだと寂しいのでフリーソフトを作って
不特定多数からの賛辞ももらってるよ。
でもこれだけだと寂しいのでフリーソフトを作って
不特定多数からの賛辞ももらってるよ。
485 ：仕様書無しさん：2005/06/21(火) 15:28:46
でよ、そろそろまとめてくれ。
業務系が何故痛いのか
->
業務系以外は何故痛くないのか
->
客と打ち合わせたり客に感謝されるのが楽しいのなら、営業とかのほうが
いいような気もするけど、それはまた別なのか？
いいような気もするけど、それはまた別なのか？
業務系がなぜ痛いか？
痛いわけじゃない。
他の業務の人が割りが合わない仕事での精神崩壊の結果、業務系が楽してると思うことで逆恨みして精神均衡を図ってるから。
業務系以外がなぜ痛くないか？
そう思わないと自己否定になって、精神崩壊しちゃうから。
痛いわけじゃない。
他の業務の人が割りが合わない仕事での精神崩壊の結果、業務系が楽してると思うことで逆恨みして精神均衡を図ってるから。
業務系以外がなぜ痛くないか？
そう思わないと自己否定になって、精神崩壊しちゃうから。
やっぱり自分で作ったものに対して感謝されたいじゃない
俺はテーブルの設計からコーディングまで一人でやっちゃうような
小さい仕事が多いから楽しいYO!
俺はテーブルの設計からコーディングまで一人でやっちゃうような
小さい仕事が多いから楽しいYO!
それは両者とも典型的な技術思考。
エンドユーザが使えるものを考えずに、プログラマが勝手に自分の技術顕示欲を満たしているだけだ。
そういう奴が作ると、使えないエロゲーが出来るわけだ。
大事なのは、その揺れに萌えがあるかだ。
リアルだろうが赤くて３倍速だろうがそんなのどうでもいいこと。
エンドユーザが使えるものを考えずに、プログラマが勝手に自分の技術顕示欲を満たしているだけだ。
そういう奴が作ると、使えないエロゲーが出来るわけだ。
大事なのは、その揺れに萌えがあるかだ。
リアルだろうが赤くて３倍速だろうがそんなのどうでもいいこと。
・・・ああ。エロゲーを「使う」わけね
エンドユーザの希望に沿う仕様にすることと
良いシステム設計をすることは独立した問題なのだが。
なぜか、ごっちゃにしてすり変えてる香具師が相変わらず多いな
「乳ゆれの見せ方」のようなエンドユーザの関係する外部仕様は
開発の前段階で決定されているべきであって、
開発に入ってしまえば技術指向でかまわんのだ。
むしろ、工数内で、ソフトウェア工学的な視点から見て出来る限り「良い」プログラムを書くべきなのだ。
それが、その後の保守性、信頼性、仕様変更やカスタマイズへの対応性に直接繋がるのだから。
良いシステム設計をすることは独立した問題なのだが。
なぜか、ごっちゃにしてすり変えてる香具師が相変わらず多いな
「乳ゆれの見せ方」のようなエンドユーザの関係する外部仕様は
開発の前段階で決定されているべきであって、
開発に入ってしまえば技術指向でかまわんのだ。
むしろ、工数内で、ソフトウェア工学的な視点から見て出来る限り「良い」プログラムを書くべきなのだ。
それが、その後の保守性、信頼性、仕様変更やカスタマイズへの対応性に直接繋がるのだから。
>>494
いいこといった
いいこといった
>>494
だから、勝手仕様で作ろうとする輩がいると、リアル性とか言い始めるという話でしょ。
>>460は設計というかシステム要件の話、>>491はそれを受けたPGが勝手仕様で暴走しそうな人。
それ以降はちゃちゃ。
だから、勝手仕様で作ろうとする輩がいると、リアル性とか言い始めるという話でしょ。
>>460は設計というかシステム要件の話、>>491はそれを受けたPGが勝手仕様で暴走しそうな人。
それ以降はちゃちゃ。
「良い」プログラムというのが、技術者から見て「つまんね」となりがちなのが、
業務系に優秀な人材が集まりにくい要因。
業務系に優秀な人材が集まりにくい要因。
物理学的に見ていかにリアルにおっぱいを揺らすかということより、
「抜ければいいんだから、おっぱいはできるだけ大きく、顔はできるだけ幼く。
そのギャップが大切なんだよ！」
とかいう客のわがままを聞かないといけないのが業務系。
「抜ければいいんだから、おっぱいはできるだけ大きく、顔はできるだけ幼く。
そのギャップが大切なんだよ！」
とかいう客のわがままを聞かないといけないのが業務系。
499 ：仕様書無しさん：2005/06/21(火) 18:03:13
業務系がなぜ痛いか？
国内の業務系では
・優れた理論やパラダイム(ビジネス、マーケティング、情報)に基づいて
・優れたアーキテクチャ(J2EE, SOAP, SOA, ESB)や
・他に先行した優れたパッケージ(ERP, CRM, CTI, etc.)
を作る会社が絶対的に少ないから、業務系はつまんない。
え？パッケージ適用も仕事のうちだって？だからそれは土方に任せとけって・・・
ちなみに上記でワザと省いてある事例は、多少なりとも国内に実績がある分野だ。(PLM, PDM, CORTA, etc.)
国内の業務系では
・優れた理論やパラダイム(ビジネス、マーケティング、情報)に基づいて
・優れたアーキテクチャ(J2EE, SOAP, SOA, ESB)や
・他に先行した優れたパッケージ(ERP, CRM, CTI, etc.)
を作る会社が絶対的に少ないから、業務系はつまんない。
え？パッケージ適用も仕事のうちだって？だからそれは土方に任せとけって・・・
ちなみに上記でワザと省いてある事例は、多少なりとも国内に実績がある分野だ。(PLM, PDM, CORTA, etc.)
ようするに
要求定義（萌える乳揺れを是非実現してもらいたい）
↓
分析（OK、OK、「使える」乳揺れってことね）
↓
設計（ﾂﾏﾝﾈ。ついでに3倍速で乳を揺らせとこ）
ってことね。
要求定義（萌える乳揺れを是非実現してもらいたい）
↓
分析（OK、OK、「使える」乳揺れってことね）
↓
設計（ﾂﾏﾝﾈ。ついでに3倍速で乳を揺らせとこ）
ってことね。
>>499
頭のいい俺様の作ったパッケージを使わないやつらは糞だ、って思想？
それはそれでいいと思うが、天上から下界に来てお前ら馬鹿だって
わざわざ言いにくるほどあんたは暇なんだね。ほかの頭のいい連中の
足を引っ張ることだけはするなよ。
頭のいい俺様の作ったパッケージを使わないやつらは糞だ、って思想？
それはそれでいいと思うが、天上から下界に来てお前ら馬鹿だって
わざわざ言いにくるほどあんたは暇なんだね。ほかの頭のいい連中の
足を引っ張ることだけはするなよ。
>>494
>むしろ、工数内で、ソフトウェア工学的な視点から見て出来る限り「良い」プログラムを書くべきなのだ。
>それが、その後の保守性、信頼性、仕様変更やカスタマイズへの対応性に直接繋がるのだから。
そこだ。
「ソフトウェア工学的な視点」での保守性と、
「ユーザ視点」での保守性が一致するかどうか。
DBはまともな奴が書けばほとんどの場合長く使えるからここでは除外する。
業務機能の実装でソフト的に正しくってのは、現在では「OOしる」ってことだと信じてる人が多い。
あなたがどうかはわからないが、まず前提としてこれを置く。
でも、実際の会社は構造が常に変化するからOOで保守性が保証できるか、難しいところがある。
それなら「画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく」という設計もありうる。
（「画面から設計する」ではありませんし、OOだって活用します）
全体としては古くさい手法だし構造は美しくない。でも業務変更に伴う改造には強い。
なぜならシステムの内部構造と業務フローが一致していて、データの流れが非常にシンプルだから。
なんでそんなに業務理由での改造を重視するかと言えば、儲けてる企業は常に変革を求める場合が多いから。
こうしておくと保守の際には凡庸なSEでも間違いを犯さずにすむ。
大体の場合に優れた設計家は新規プロジェクトに投入されているから、
これは最適解ではないけれど現実解としては有用だと思うよ。
>むしろ、工数内で、ソフトウェア工学的な視点から見て出来る限り「良い」プログラムを書くべきなのだ。
>それが、その後の保守性、信頼性、仕様変更やカスタマイズへの対応性に直接繋がるのだから。
そこだ。
「ソフトウェア工学的な視点」での保守性と、
「ユーザ視点」での保守性が一致するかどうか。
DBはまともな奴が書けばほとんどの場合長く使えるからここでは除外する。
業務機能の実装でソフト的に正しくってのは、現在では「OOしる」ってことだと信じてる人が多い。
あなたがどうかはわからないが、まず前提としてこれを置く。
でも、実際の会社は構造が常に変化するからOOで保守性が保証できるか、難しいところがある。
それなら「画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく」という設計もありうる。
（「画面から設計する」ではありませんし、OOだって活用します）
全体としては古くさい手法だし構造は美しくない。でも業務変更に伴う改造には強い。
なぜならシステムの内部構造と業務フローが一致していて、データの流れが非常にシンプルだから。
なんでそんなに業務理由での改造を重視するかと言えば、儲けてる企業は常に変革を求める場合が多いから。
こうしておくと保守の際には凡庸なSEでも間違いを犯さずにすむ。
大体の場合に優れた設計家は新規プロジェクトに投入されているから、
これは最適解ではないけれど現実解としては有用だと思うよ。
>>503
長々書いてるが、
OO設計と
画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく
という設計指針
は並列で語る問題じゃないだろ。
お互いに直交しているとまでは言わずとも独立した問題だから、これで
OOを否定するのは説得力が欠ける。
無論、常に、
> OOで保守性が保証できるか
といえば、それは否だ。OOにしたからといって全てが解決する訳でもない。
ソフトウェア工学の世界には銀の弾は存在しない。ただそれだけのことで、
そんなのはただの常識だ。
長々書いてるが、
OO設計と
画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく
という設計指針
は並列で語る問題じゃないだろ。
お互いに直交しているとまでは言わずとも独立した問題だから、これで
OOを否定するのは説得力が欠ける。
無論、常に、
> OOで保守性が保証できるか
といえば、それは否だ。OOにしたからといって全てが解決する訳でもない。
ソフトウェア工学の世界には銀の弾は存在しない。ただそれだけのことで、
そんなのはただの常識だ。
>>504
すまん。OOじゃなくてドメインモデルだ。暑さでぼーとしてたらしい。
それと、別になにも否定しちゃいない。
>>505
たとえば、設計書が普通のユーザに読めるように書かれてるかどうか。
優しい言葉でという意味ではなく、業務フローに沿って書かれているかという点で。
「ソフトウェア工学的な視点」って、エンジニアに理解しやすいってことでしょ。賞味の話が。
すまん。OOじゃなくてドメインモデルだ。暑さでぼーとしてたらしい。
それと、別になにも否定しちゃいない。
>>505
たとえば、設計書が普通のユーザに読めるように書かれてるかどうか。
優しい言葉でという意味ではなく、業務フローに沿って書かれているかという点で。
「ソフトウェア工学的な視点」って、エンジニアに理解しやすいってことでしょ。賞味の話が。
>>503
「画面という客との共通言語(略)緩く繋いでおく」ってのが具体的ではないのであれだけど
何度も言われているとおり、ほとんどのお客は画面が興味の中心だから
いきなりデータモデルもってって説明するようなことはできない。
客との話の中心が画面になるのまあ当然のことかと思う。
で結局、大部分の業務系の開発ってまさしく「画面という(略)緩く繋いでおく」やり方がほとんどじゃないの？
客とは画面の話して、内部の設計では画面から対応付けたDBを定義して、あとは
どの画面でどの項目をいじるいじらない、を続けていく、といった感じの。
「DBはまともな奴が書けば(ry」あたりからの想像も入ってるけど、
「画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく」って言葉から
読み取れるのはこんなところなんだけど。
「画面という客との共通言語(略)緩く繋いでおく」ってのが具体的ではないのであれだけど
何度も言われているとおり、ほとんどのお客は画面が興味の中心だから
いきなりデータモデルもってって説明するようなことはできない。
客との話の中心が画面になるのまあ当然のことかと思う。
で結局、大部分の業務系の開発ってまさしく「画面という(略)緩く繋いでおく」やり方がほとんどじゃないの？
客とは画面の話して、内部の設計では画面から対応付けたDBを定義して、あとは
どの画面でどの項目をいじるいじらない、を続けていく、といった感じの。
「DBはまともな奴が書けば(ry」あたりからの想像も入ってるけど、
「画面という客との共通言語を使ってデザインした業務処理を緩く繋いでおく」って言葉から
読み取れるのはこんなところなんだけど。
509 ：仕様書無しさん：2005/06/21(火) 21:05:51
>>502
いや、そういう観点ではない。
OracleもBEA WebLogicもIBMもSunも、
業務系からの上がりで食ってる会社だと思うけど、
食物連鎖の随分上位に居て、
ソフトウェア工学的にも非常に興味深いプロジェクトをやってるでしょ？
同じ業務系の上がりで食うにしても、地べたの近くで這いずり回らず、
他のSIerを技術的に手足として使いまわせるような良い技術製品を出して商売する
そういった面白い企業が少ないと思うんだ
いや、そういう観点ではない。
OracleもBEA WebLogicもIBMもSunも、
業務系からの上がりで食ってる会社だと思うけど、
食物連鎖の随分上位に居て、
ソフトウェア工学的にも非常に興味深いプロジェクトをやってるでしょ？
同じ業務系の上がりで食うにしても、地べたの近くで這いずり回らず、
他のSIerを技術的に手足として使いまわせるような良い技術製品を出して商売する
そういった面白い企業が少ないと思うんだ
といった観点で見ると、
ここで議論されている内容は、一連のワークフロー製品、EA/ESB製品で、
ある程度カバーできる話だと思うんだが。どうでしょう
ここで議論されている内容は、一連のワークフロー製品、EA/ESB製品で、
ある程度カバーできる話だと思うんだが。どうでしょう
むしろ出来のいい環境、パッケージ、ライブラリを利用していかに
安く上げるかが業務系、という気がするが。
そういう意味では、どんな技術があって、どんなことがどれぐらい簡単に
出来るか、を把握していることが、業務系技術者にとっては重要。
ボルトとナットを作るのは業務系の仕事じゃない。
安く上げるかが業務系、という気がするが。
そういう意味では、どんな技術があって、どんなことがどれぐらい簡単に
出来るか、を把握していることが、業務系技術者にとっては重要。
ボルトとナットを作るのは業務系の仕事じゃない。
あ、そ。
まぁSIerつうくらいで、俺も昔っからそういう意見だ。
現場には、手作り可能な範囲のミドルウェアを
一から手作りしたがる厨房が多いけどね。
で、>>509で言ってるのは、
ボルトやナットの製造装置や、工作機械作成用工作機械といった
付加価値が高く市場もそれなりに広い分野の方が、
より大きな影響力を与える事ができて面白いよ、っていう話だ
まぁSIerつうくらいで、俺も昔っからそういう意見だ。
現場には、手作り可能な範囲のミドルウェアを
一から手作りしたがる厨房が多いけどね。
で、>>509で言ってるのは、
ボルトやナットの製造装置や、工作機械作成用工作機械といった
付加価値が高く市場もそれなりに広い分野の方が、
より大きな影響力を与える事ができて面白いよ、っていう話だ
>>512
OracleやBEA WebLogicはシングルCPUライセンス500万とかの世界だから、
最低数千万規模の商談じゃないと厳しいだろうね。Sunはそれ載せるためのハード。
IBMは世界最大のメーカ＆SIerだからなぁ。ミニマムってよくわからん。
つか、SunやIBMは業界への影響力って部分が大きい。
オープンソース込みなら、Linuxベースで一番小さな規模のお客さんにも対応できるでしょ？
OracleやBEA WebLogicはシングルCPUライセンス500万とかの世界だから、
最低数千万規模の商談じゃないと厳しいだろうね。Sunはそれ載せるためのハード。
IBMは世界最大のメーカ＆SIerだからなぁ。ミニマムってよくわからん。
つか、SunやIBMは業界への影響力って部分が大きい。
オープンソース込みなら、Linuxベースで一番小さな規模のお客さんにも対応できるでしょ？
↑に挙げた値段は、Web用ライセンス。
ユーザー数限定なら、もっと安かったような気が・・・最近はどうなんだろう
ユーザー数限定なら、もっと安かったような気が・・・最近はどうなんだろう
オープンソースでライセンス無料のワークフロー/ESB製品は、
当分出てこない気が・・・
当分出てこない気が・・・
オープンソースはプログラマのプログラマによるプログラマのためのプログラム
ってな側面が大きいからな。
プログラマ自身の必要性だの技術的興味だのが無い限り、なかなか
タダでプログラム作ろうって気にはならんでしょ。
もっともデキのよいオープンソースのソフトウェアって、結局
OS、コンパイラ、テキストエディタだもの。
ってな側面が大きいからな。
プログラマ自身の必要性だの技術的興味だのが無い限り、なかなか
タダでプログラム作ろうって気にはならんでしょ。
もっともデキのよいオープンソースのソフトウェアって、結局
OS、コンパイラ、テキストエディタだもの。
>>508
ユーザが開発に積極的にレビューしてくれまつ。例外処理の漏れを結構拾ってくれる。
自分の仕事が明確に書かれると読むのが面白いみたいよ。
それに外部仕様レベルでの合意だと「そういう意味じゃなかった」ってのが
どうしても後から出るし。
ユーザが開発に積極的にレビューしてくれまつ。例外処理の漏れを結構拾ってくれる。
自分の仕事が明確に書かれると読むのが面白いみたいよ。
それに外部仕様レベルでの合意だと「そういう意味じゃなかった」ってのが
どうしても後から出るし。
俺は大体300万くらいだよ
521 ：名無しさん：2005/06/21(火) 23:24:40
何やらパッケージや、大手に素晴らしい幻想を抱いている人がいるようですが、
パッケージや大手のミドルウェア開発をやった事がある人で、
開発の素晴らしさを語れる人はいませんか？
是非とも聞いてみたいです。
パッケージや大手のミドルウェア開発をやった事がある人で、
開発の素晴らしさを語れる人はいませんか？
是非とも聞いてみたいです。
522 ：仕様書無しさん：2005/06/21(火) 23:37:09
市販のパッケージって一般の業務ではいまいち役にたたない
やっぱりオーソドックス過ぎて細かいところが管理できない
やっぱりオーソドックス過ぎて細かいところが管理できない
>>521
> 何やらパッケージや、大手に素晴らしい幻想を抱いている人がいるようですが、
それを幻想だと決め付ける根拠があるのなら、自分で説明したらいい。
説明できないのであれば、それは「幻想を抱いている人が居る」というあなたの妄想だ。
従って>>521は、手数をかけて実体験を説明しても、
ばっさりと無視するか、ことごとく否定してくる輩と区別が付かない
> 何やらパッケージや、大手に素晴らしい幻想を抱いている人がいるようですが、
それを幻想だと決め付ける根拠があるのなら、自分で説明したらいい。
説明できないのであれば、それは「幻想を抱いている人が居る」というあなたの妄想だ。
従って>>521は、手数をかけて実体験を説明しても、
ばっさりと無視するか、ことごとく否定してくる輩と区別が付かない
>>517-518
ワークフローやESBについて、ある程度のコア技術はオープンソースで公開されているので、
残りの部分をシンプルに堅牢にシステム化して、オープンソースで公開する所がそのうち出てくるでしょう。
そういったオープンソース自身の開発や利用こそ、技術者として幸せに生きる一つの道だと考えています。
ワークフローやESBについて、ある程度のコア技術はオープンソースで公開されているので、
残りの部分をシンプルに堅牢にシステム化して、オープンソースで公開する所がそのうち出てくるでしょう。
そういったオープンソース自身の開発や利用こそ、技術者として幸せに生きる一つの道だと考えています。
>技術に重きを置くとよほどの能力がある人を除いては、年を重ねるごとに
>若い連中に怯えなきゃならないし。
少し違う。
技術に重きを置くと、能力と無関係に、組織内での相応の処遇を受けられなくなる。
のです。
>若い連中に怯えなきゃならないし。
少し違う。
技術に重きを置くと、能力と無関係に、組織内での相応の処遇を受けられなくなる。
のです。
ドカタは日本人じゃなくてもいいもんな～。ｗ
業務系に限らず、その辺りに危機感ない人が多いよね。
日本人であることの売りを考えないと。日本語での意思疎通に不自由してるのはやっぱ拙いよ。
業務系に限らず、その辺りに危機感ない人が多いよね。
日本人であることの売りを考えないと。日本語での意思疎通に不自由してるのはやっぱ拙いよ。
ドカタ仕事に甘んじてると年とともに捨てられるような気もするが。
しかし、「技術は二の次、三の次」というのがごく自然に通用する世界って
いうのもある意味すごい。
しかし、「技術は二の次、三の次」というのがごく自然に通用する世界って
いうのもある意味すごい。
違うよ多分。ベテランの無能になって、周りから一目置かれてるんだよ。
あの人は･･･って。本人が気付いていないだけ。
あの人は･･･って。本人が気付いていないだけ。
530 ：名無しさん：2005/06/22(水) 10:15:48
>>523
IやBのミドルウェアの開発を手伝ったことがありますが、
有り余る時間と資金を使って、自由な発想で高度なプログラムを組むと言うのには程遠く、
実際は何かのベースがあって、それの解析から始まる地味な仕事でした。
問題は最新技術（高度と言うよりは出たばかり）を使うので、
それの使い方が分からない（マニュアルがなかったり、古かったりする）のと、
その最新技術が運用に耐えられない（例えばメモリリーク）ような場合に、
どうにかして回避しなければならないと言うことでした。
当然、スケジュールはあります。
笑えるのは一番大変だったのはインストール（環境設定）と言うことでした。
１週間やって設定が完了しなかった時は、インストールCDを全力で投げたら
何メートル飛ぶか試してみようかと思ったぐらいです。
Sのシステムもやったことがあります。
私の行った所はソフトよりハードの人が多く、最初は性能測定から始まりました。
その時はSとOと一緒に、DB更新のプログラムを作って、条件変えて延々と測定でした。
一番参ったのは性能目標値がどこから計算したのか、非現実的だった時でした。
これもどうにかしなければなりません。
私の経験上、研究開発部門で一番重要なのは、問題解決能力（解析と対処）です。
時にはハードも含みます。言語だの構造だのは知っていて当然ではないでしょうか？
ただ、当然自分の経験が全てではないわけで、素晴らしい環境で高度な開発と
言うのもあるのかもしれません。
是非とも聞いてみたい。
と言うか行きたいので教えてください。
IやBのミドルウェアの開発を手伝ったことがありますが、
有り余る時間と資金を使って、自由な発想で高度なプログラムを組むと言うのには程遠く、
実際は何かのベースがあって、それの解析から始まる地味な仕事でした。
問題は最新技術（高度と言うよりは出たばかり）を使うので、
それの使い方が分からない（マニュアルがなかったり、古かったりする）のと、
その最新技術が運用に耐えられない（例えばメモリリーク）ような場合に、
どうにかして回避しなければならないと言うことでした。
当然、スケジュールはあります。
笑えるのは一番大変だったのはインストール（環境設定）と言うことでした。
１週間やって設定が完了しなかった時は、インストールCDを全力で投げたら
何メートル飛ぶか試してみようかと思ったぐらいです。
Sのシステムもやったことがあります。
私の行った所はソフトよりハードの人が多く、最初は性能測定から始まりました。
その時はSとOと一緒に、DB更新のプログラムを作って、条件変えて延々と測定でした。
一番参ったのは性能目標値がどこから計算したのか、非現実的だった時でした。
これもどうにかしなければなりません。
私の経験上、研究開発部門で一番重要なのは、問題解決能力（解析と対処）です。
時にはハードも含みます。言語だの構造だのは知っていて当然ではないでしょうか？
ただ、当然自分の経験が全てではないわけで、素晴らしい環境で高度な開発と
言うのもあるのかもしれません。
是非とも聞いてみたい。
と言うか行きたいので教えてください。
＞笑えるのは一番大変だったのはインストール（環境設定）と言うことでした。
＞１週間やって設定が完了しなかった時は、インストールCDを全力で投げたら
＞何メートル飛ぶか試してみようかと思ったぐらいです。
すみません。笑いのつぼがよく理解できません。
＞１週間やって設定が完了しなかった時は、インストールCDを全力で投げたら
＞何メートル飛ぶか試してみようかと思ったぐらいです。
すみません。笑いのつぼがよく理解できません。
土方の定義をしてなかったな。わたしは現場で汗水流して働く、程度の意味で
使ってたんだけど。土方＝仕事のレベルが低い、ってことじゃなかったんだが。
それに技術は二の次だよ。技術は仕事の道具であって目的じゃないから。
大事なのは課題を解決していくこと。そしてその中で斬新的に新しいものを
取り入れていくこと。トラブっても押さえ込めそうなら大胆な挑戦をしてもいい。
使ってたんだけど。土方＝仕事のレベルが低い、ってことじゃなかったんだが。
それに技術は二の次だよ。技術は仕事の道具であって目的じゃないから。
大事なのは課題を解決していくこと。そしてその中で斬新的に新しいものを
取り入れていくこと。トラブっても押さえ込めそうなら大胆な挑戦をしてもいい。
533 ：仕様書無しさん：2005/06/22(水) 10:41:17
建築士＝SE
ドカタ＝プログラマ（トラックの荷台にまとめられ現場まで送迎される所もそっくり）
ドカタ＝プログラマ（トラックの荷台にまとめられ現場まで送迎される所もそっくり）
>>532
定年までドカタが可能ですか？
定年までドカタが可能ですか？
うちの>>532は、日本一の日雇い人夫だい！
>>532
幅広く儲けられるのは「優れた技術」ではなくて「技術を役に立たせる技能」じゃないかな。
歳を取ったら技術だけでは食っていけないと思ったから、外勤の設計屋に転職して修行中。
工場のシステム設計とか企画段階からユーザといっしょにやると面白いよ。
幅広く儲けられるのは「優れた技術」ではなくて「技術を役に立たせる技能」じゃないかな。
歳を取ったら技術だけでは食っていけないと思ったから、外勤の設計屋に転職して修行中。
工場のシステム設計とか企画段階からユーザといっしょにやると面白いよ。
>>534
のまちがい。
のまちがい。
「外勤の設計屋」って何だ？
>>538
受注したプロジェクト毎に、開発室をユーザ内に設置して仕事してる。
受注したプロジェクト毎に、開発室をユーザ内に設置して仕事してる。
派遣ってことだね。
541 ：仕様書無しさん：2005/06/22(水) 13:50:41
今更ながら、業務系って何?
>>541
日常社会のさまざまさ業務をサポートするシステムのこと。
対義としたら、組み込み系、ハードゲイ、萌えゲーム系かな？
業務系といっても、業種では金融、生産、物流、販売など多岐に渡るし。
対象となる言語、プラットフォームもホストから汁男優までといろいろ。
本来的には業務に対する知識、理解力、提案力など必要な分野なんだが。
プログラム組むだけなら馬鹿でもできるし、日本人じゃなくてもそれこそ人じゃなくてもいい。
日常社会のさまざまさ業務をサポートするシステムのこと。
対義としたら、組み込み系、ハードゲイ、萌えゲーム系かな？
業務系といっても、業種では金融、生産、物流、販売など多岐に渡るし。
対象となる言語、プラットフォームもホストから汁男優までといろいろ。
本来的には業務に対する知識、理解力、提案力など必要な分野なんだが。
プログラム組むだけなら馬鹿でもできるし、日本人じゃなくてもそれこそ人じゃなくてもいい。
544 ：デフォルトの名無しさん：2005/06/22(水) 14:14:20
だから派遣なんだろ？
横レスだが派遣じゃないわな。
派遣つうのはあくまで派遣元会社と派遣者の契約で、派遣先と派遣者は特に契約ない。
だから、極端な話、仕事がまともに終わらなくても直接の責任はない。
で、今の彼の場合は検収上がらないと契約内容によっては一切かねが出ないわけで。
まさか、”検収”って言葉を理解せずに派遣とかいってるんじゃないよね。
派遣つうのはあくまで派遣元会社と派遣者の契約で、派遣先と派遣者は特に契約ない。
だから、極端な話、仕事がまともに終わらなくても直接の責任はない。
で、今の彼の場合は検収上がらないと契約内容によっては一切かねが出ないわけで。
まさか、”検収”って言葉を理解せずに派遣とかいってるんじゃないよね。
つまり派遣か
547 ：仕様書無しさん：2005/06/22(水) 16:01:33
「おもちゃプ」 って何？ゲームのこと？
549 ：仕様書無しさん：2005/06/22(水) 16:25:40
ここで、書いているやつは無職か学生。
>>549
お前も俺もな
お前も俺もな
つか年商1000億位のSI会社でも、
ろくな研究開発予算は持ってない。
大抵の仕事は委託研究とか研究支援とか新分野開拓みたいなのかな。
俺は運良く社運を賭けて新しい分野に進出するプロジェクトにはまり込んだから、
古くからやられてた委託研究(通産)の延長線上にあるフリをして、
実用化研究みたいなのを数年間できて、とても美味しかった。
ろくな研究開発予算は持ってない。
大抵の仕事は委託研究とか研究支援とか新分野開拓みたいなのかな。
俺は運良く社運を賭けて新しい分野に進出するプロジェクトにはまり込んだから、
古くからやられてた委託研究(通産)の延長線上にあるフリをして、
実用化研究みたいなのを数年間できて、とても美味しかった。
553 ：名無しさん：2005/06/22(水) 22:15:53
楽園ってモチベーション維持が大変なんだよねぇ～。
つう意味で楽園ではない
つう意味で楽園ではない
あと、自分で一通りの開発できない奴も多いから、
連中はプログラマ確保と管理でてんてこ舞い・・・
連中はプログラマ確保と管理でてんてこ舞い・・・
556 ：名無しさん：2005/06/22(水) 22:41:21
ちなみに、ずっと開発系一筋（入社時除く）と言う人はここにいるのでしょうか？
普通は552さんのように、研究開発もやるけど業務開発もやると言うのが
普通だと思うのですが。
普通は552さんのように、研究開発もやるけど業務開発もやると言うのが
普通だと思うのですが。
>>556
よく意味わかんないけど、
サイエンス系なら業務込みで実態研究開発一筋って多いよ。
ソフトウェア系は新陳代謝が激しいのと、
ちゃんとした研究開発部門持ってる所が一握りだからなぁ。
宮廷出たドクター餅が大学教員に転進、つうのが極少数居て、
あとは普通に役職上がってくだけでしょ。
よく意味わかんないけど、
サイエンス系なら業務込みで実態研究開発一筋って多いよ。
ソフトウェア系は新陳代謝が激しいのと、
ちゃんとした研究開発部門持ってる所が一握りだからなぁ。
宮廷出たドクター餅が大学教員に転進、つうのが極少数居て、
あとは普通に役職上がってくだけでしょ。
>>556
よく意味わかんないけど、
サイエンス系なら業務込みで実態研究開発一筋って多いよ。
ソフトウェア系は新陳代謝が激しいのと、
ちゃんとした研究開発部門持ってる所が一握りだからなぁ。
＋俺の上の世代でヒラの技術者で頑張りたいつってた連中も、
＋いろいろな事情でとりあえず役職餅になって、人を束ねる義務背負い込まされて、・・・。
＊あと宮廷出たドクター餅で、大学教員に転進つうのが極少数居たなぁ。
よく意味わかんないけど、
サイエンス系なら業務込みで実態研究開発一筋って多いよ。
ソフトウェア系は新陳代謝が激しいのと、
ちゃんとした研究開発部門持ってる所が一握りだからなぁ。
＋俺の上の世代でヒラの技術者で頑張りたいつってた連中も、
＋いろいろな事情でとりあえず役職餅になって、人を束ねる義務背負い込まされて、・・・。
＊あと宮廷出たドクター餅で、大学教員に転進つうのが極少数居たなぁ。
バカばっか
哀れな奴
562 ：仕様書無しさん：2005/06/23(木) 10:48:37
業務系を嫌うヤツは、技術云々より対人会話能力に難がある訳だが
業務系に巣食うヤツは、技術に難があると。
563 ：名無しさん：2005/06/23(木) 11:03:49
ちょっと間違えてました。
・業務系ＶＳパッケージ系
ではなくて、
・業務系ＶＳ研究開発
ですね。
プログラマの楽園は未だ確認出来ずと言う所でしょうか。
教員は研究開発とは違いますし、個人請負も楽園には遠い。
個人でシェアウエアはある意味理想かもしれませんね。
金の問題がなけらばですが。これが一番問題ですが。
逆に言うと、
「金持ちでシェアウエア開発」
が真の楽園と言えるのかもしれません。
つまり
・業務系ＶＳ道楽研究開発
確かに道楽研究開発圧勝かと思われます。
・業務系ＶＳパッケージ系
ではなくて、
・業務系ＶＳ研究開発
ですね。
プログラマの楽園は未だ確認出来ずと言う所でしょうか。
教員は研究開発とは違いますし、個人請負も楽園には遠い。
個人でシェアウエアはある意味理想かもしれませんね。
金の問題がなけらばですが。これが一番問題ですが。
逆に言うと、
「金持ちでシェアウエア開発」
が真の楽園と言えるのかもしれません。
つまり
・業務系ＶＳ道楽研究開発
確かに道楽研究開発圧勝かと思われます。
>>562
タクシーの運転手やスーパーのレジうちの人に接するときと同じで、別に軽蔑するわけじゃないけど
いくらで代わりのいる仕事って自分はやりたくないなって感じかな。
もちろん彼らがいないと困るわけだし、プロ意識のある人もいるってことはちゃんと理解している。
別に嫌ってるわけじゃないからそのへん誤解しないで。
タクシーの運転手やスーパーのレジうちの人に接するときと同じで、別に軽蔑するわけじゃないけど
いくらで代わりのいる仕事って自分はやりたくないなって感じかな。
もちろん彼らがいないと困るわけだし、プロ意識のある人もいるってことはちゃんと理解している。
別に嫌ってるわけじゃないからそのへん誤解しないで。
>>564
引き篭りのおまいには、タクシーの運転手もレジ打ち接客も出来ない仕事だろ。
引き篭りのおまいには、タクシーの運転手もレジ打ち接客も出来ない仕事だろ。
×おまい
○技術オタ
にしとく。
○技術オタ
にしとく。
568 ：仕様書無しさん：2005/06/23(木) 14:07:43
そりゃ仮にトヨタの社長が急にいなくなってもトヨタがつぶれる事はありえない。
でもトヨタの社長が急にいなくなるのと、工場でボルト締めてる工員が一人いなくなるのとでは・・・。
わかりますよね？
でもトヨタの社長が急にいなくなるのと、工場でボルト締めてる工員が一人いなくなるのとでは・・・。
わかりますよね？
で、>>564は自分はトヨタの張とか奥田と同じくらい、代替が難しいプログラマーだといいたいのか？ｗ
571 ：デフォルトの名無しさん：2005/06/23(木) 15:37:06
犬小屋作って有頂天で得意満面な人いるからね～
思うのは自由だしね
思うのは自由だしね
高卒、専門卒、文系、Cランク大・・・
こういう連中が大半を占めてるうちは、反論してもむなしいな
こういう連中が大半を占めてるうちは、反論してもむなしいな
学歴なんて気にしてるのは、学生か、自分にそれしかすがるものが無い奴だけだよ。
うち「ちゃんとしてる」かどうかはともかく研究開発部門あるけど、
そっからシステム部門にうつってきた人、評判悪いんだよね。
頑固で融通が利かなくてコミュニケーション能力に問題があるタイプで。
まあ優秀は優秀だから、使いようはある筈なんだが、
あまりそういうタイプの優秀さが求められてないっつーか。
そっからシステム部門にうつってきた人、評判悪いんだよね。
頑固で融通が利かなくてコミュニケーション能力に問題があるタイプで。
まあ優秀は優秀だから、使いようはある筈なんだが、
あまりそういうタイプの優秀さが求められてないっつーか。
でも「自分でなければ代替がきかない」と思うことは
悪い事ではない
悪い事ではない
>>575
社畜、過労死、自殺・・・への第一歩。
自分がいなくても仕事なんぞは進むし、自分がいなくてもどうにかなる仕組みを構築するのも仕事のうち。
自分の代替を考えないってのは業務系だと最悪。あんた墓場までシステムもっていくんだろうね？
社畜、過労死、自殺・・・への第一歩。
自分がいなくても仕事なんぞは進むし、自分がいなくてもどうにかなる仕組みを構築するのも仕事のうち。
自分の代替を考えないってのは業務系だと最悪。あんた墓場までシステムもっていくんだろうね？
確かに業務系の場合、「わかりやすい」プログラムを書くことは重要。
ただし、「わかりやすい」を勘違いしている奴が多いｗ。
# グローバル変数を使ったほうがどこからでも参照できる とか
# ひとつの関数ですべてやったほうがあちこち探さないでいいから追いやすい とか
ただし、「わかりやすい」を勘違いしている奴が多いｗ。
# グローバル変数を使ったほうがどこからでも参照できる とか
# ひとつの関数ですべてやったほうがあちこち探さないでいいから追いやすい とか
頭悪かろうが、レベル低かろうが、それをちゃんと認識した上で真面目に
働いてるのであれば別に痛くはない。
働いてるのであれば別に痛くはない。
>>577
いくらなんでもレベル低すぎ
いくらなんでもレベル低すぎ
>>576
粘着するなよ。俺がそう思うって言ったか？仕事に対する姿勢の事を言ったんだ。
>自分がいなくてもどうにかなる仕組みを構築するのも仕事のうち。
そらそうだがそれを考えるのはその「自分」の管理者だろう。
各自担当者にそんなことまで考えさせるのか？
粘着するなよ。俺がそう思うって言ったか？仕事に対する姿勢の事を言ったんだ。
>自分がいなくてもどうにかなる仕組みを構築するのも仕事のうち。
そらそうだがそれを考えるのはその「自分」の管理者だろう。
各自担当者にそんなことまで考えさせるのか？
俺の場合、（低レベルな例になるが）個人的に定数文字列は#defineするより
ベタで書いてあったほうが分かりやすい。
こーゆーのは普通リファクタリングの対象とされてるが、ベタで書いてあるほうが
見てすぐ分かるもの。
ベタで書いてあったほうが分かりやすい。
こーゆーのは普通リファクタリングの対象とされてるが、ベタで書いてあるほうが
見てすぐ分かるもの。
業務系の人って尿道に爆竹突っ込んで炸裂させても平気だよね。
>>584
sed
sed
>>576はいいこと言ってる
業務系プログラマにしろ工場のライン工にしろ、単純業務に従事する人間は
いつでもすぐに交換可能な状態にするのがベスト。
不慮の事態に対応するリスク管理の意味でも、安い人間に交代しやすくするという
コスト管理という意味でも。
だが逆にそのことは優秀な人間を排除してしまうという諸刃の剣でもある。
あと、いくら作業を単純化したところでソフトウェア開発にはどうしても
自由度が残ってしまうが、頭の悪い奴に限ってつまらないスタンドプレーに走って悦にいってる。
頭の悪い奴のためにわざわざ作ったルールを守れないこういう奴は本当に痛い。
業務系プログラマにしろ工場のライン工にしろ、単純業務に従事する人間は
いつでもすぐに交換可能な状態にするのがベスト。
不慮の事態に対応するリスク管理の意味でも、安い人間に交代しやすくするという
コスト管理という意味でも。
だが逆にそのことは優秀な人間を排除してしまうという諸刃の剣でもある。
あと、いくら作業を単純化したところでソフトウェア開発にはどうしても
自由度が残ってしまうが、頭の悪い奴に限ってつまらないスタンドプレーに走って悦にいってる。
頭の悪い奴のためにわざわざ作ったルールを守れないこういう奴は本当に痛い。
業務系プログラマ＝単純業務
という点で認識が分かれそうだな
ちなみに俺の認識は「否」だが
ま、一口に業務系とか言っても、幅広いしな
という点で認識が分かれそうだな
ちなみに俺の認識は「否」だが
ま、一口に業務系とか言っても、幅広いしな
588 ：仕様書無しさん：2005/06/23(木) 21:14:18
業務系は文系出身者の行くところだ。
工学系出た奴ならやっぱ、制御系だよな。
業務系なんてVBA厨のやる仕事だ。
文句あるか?
以上。挑戦者求む!
工学系出た奴ならやっぱ、制御系だよな。
業務系なんてVBA厨のやる仕事だ。
文句あるか?
以上。挑戦者求む!
無いからもう帰っていいよ
文理分けてる段階であほ。
制御系なんて簡単なんだけどね、業務系の魑魅魍魎に比べたらなんて素直なんだろう、装置って。ｗ
で、ベタというか判りやすいプログラムって、マクロ視点では業務に忠実なロジックを書くことかな？
ミクロ的には普通に構造化プログラムの基本を守っていればほぼ問題なし。
制御系なんて簡単なんだけどね、業務系の魑魅魍魎に比べたらなんて素直なんだろう、装置って。ｗ
で、ベタというか判りやすいプログラムって、マクロ視点では業務に忠実なロジックを書くことかな？
ミクロ的には普通に構造化プログラムの基本を守っていればほぼ問題なし。
591 ：仕様書無しさん：2005/06/23(木) 21:32:37
俺の先輩は「構造化プログラム＝多重while文からのgoto脱出」と信じている。
オブジェクト指向を「グローバル変数でメッセージを共有する」と解釈しているし。
そんな先輩は「仕事の出来るプログラマは常に多忙だ。デスマと俺は親友同士さ」
と豪語している。毎年、新人教育にも積極的だしさ。
オブジェクト指向を「グローバル変数でメッセージを共有する」と解釈しているし。
そんな先輩は「仕事の出来るプログラマは常に多忙だ。デスマと俺は親友同士さ」
と豪語している。毎年、新人教育にも積極的だしさ。
592 ：仕様書無しさん：2005/06/23(木) 21:51:52
>>591
釣りだよな？な？
釣りだよな？な？
>>590
分かりやすさって相対的で基準あいまいだし
言語にも激しく依存するんだよなー
perlみたいに誰が書いても醜くなる言語だとか
C++みたいにやたらと複雑で容易に手におえないコードになっちゃう言語とか
Cみたいに業務ロジックに入る前にmalloc()からはじめなきゃいかん言語とか
lispみたいにカッコばっかつけんなよコノやろうみたいな言語とか
そーゆーのもあるし
分かりやすさって相対的で基準あいまいだし
言語にも激しく依存するんだよなー
perlみたいに誰が書いても醜くなる言語だとか
C++みたいにやたらと複雑で容易に手におえないコードになっちゃう言語とか
Cみたいに業務ロジックに入る前にmalloc()からはじめなきゃいかん言語とか
lispみたいにカッコばっかつけんなよコノやろうみたいな言語とか
そーゆーのもあるし
業務系に限らず、言語なんぞ実現のための手段であって目的じゃないんだけどね。
技量足らなくて言語云々言う奴も、言語基地外もどっちも滑稽。
技量足らなくて言語云々言う奴も、言語基地外もどっちも滑稽。
595 ：仕様書無しさん：2005/06/23(木) 22:23:17
問題領域に対して適切な言語、ライブラリ、環境、etc...
を選ぶかどうかで著しく開発工数が変わってくるのだが。
それが「どうでもいい」とか言ってる香具師は、逝って良し。
おまえらは見積もりも出来ない営業同然のセールスエンジニアだ。
を選ぶかどうかで著しく開発工数が変わってくるのだが。
それが「どうでもいい」とか言ってる香具師は、逝って良し。
おまえらは見積もりも出来ない営業同然のセールスエンジニアだ。
597 ：名無しさん：2005/06/23(木) 22:49:56
業務系の痛い事例とかないですか？
痛くない方がめずらしい。
>597
某OSのバグのせいでもないのに
某OSのせいにしている輩を見ると、ほんと痛いな、と思う。
しょうがないのかもしれないけど、業務系の人々はその傾向が強い。
なんかワカランチンまで某OSをこき下ろしているし。みてらんない。
某OSのバグのせいでもないのに
某OSのせいにしている輩を見ると、ほんと痛いな、と思う。
しょうがないのかもしれないけど、業務系の人々はその傾向が強い。
なんかワカランチンまで某OSをこき下ろしているし。みてらんない。
業務系といえばcheckZenkakuで決まりだね！
どっかに派遣されたらまずこいつを捜します。
全角調べるやり方も十人十色。
日本代表でだれか一人に作らせろよ。
どっかに派遣されたらまずこいつを捜します。
全角調べるやり方も十人十色。
日本代表でだれか一人に作らせろよ。
>>600
それはちょっと痛いね。IsZenkaku にすべき。
それはちょっと痛いね。IsZenkaku にすべき。
IsMultiBytes
>>600の例は秀逸！
業務系で再利用可能な共通部品といったら、まず
・文字コードのチェックと変換
・日時に関する関数 (営業日とか営業時間とか、みなし営業日とか)
・金に関する関数 (BCD演算からはじまって、消費税とか、両替とか)
だろ。
でかなり順位が下がって、アーキテクチャ固有の面倒(?)な処理が、
フレームワークとか全然無視してUtilityクラスとして提供されたり
・文字コードのチェックと変換
・日時に関する関数 (営業日とか営業時間とか、みなし営業日とか)
・金に関する関数 (BCD演算からはじまって、消費税とか、両替とか)
だろ。
でかなり順位が下がって、アーキテクチャ固有の面倒(?)な処理が、
フレームワークとか全然無視してUtilityクラスとして提供されたり
ライン工と業務系マ
ライン工
「誰でもできる簡単な仕事だってことくらいわかってるよ。だから何？
俺頭悪いし、別に金さえもらえればなんだっていいよ」
業務系マ
「やっぱ俺ってこういう知的作業にむいてるんだよな。Fランク大落ちて
専門学校に進んだときはみんなから影で馬鹿にされたけど、学校の成績
と頭のよさは別なことくらい気づけっての。
おっと、このコンボボックスにはソートして入れるのか。
えっとソートの関数は・・・。調べるのめんどくさいや。自分で作っちゃえ。
『えー、ソートを自分で作っちゃうなんて○○さんて凄い！』とか言われちゃうんだろうな。
よし、出来上がり。あれ？ソートされてないぞ？ このコンボボックスバグってんな。
しっかりしてくれよDELLさんよぉ。
ライン工
「誰でもできる簡単な仕事だってことくらいわかってるよ。だから何？
俺頭悪いし、別に金さえもらえればなんだっていいよ」
業務系マ
「やっぱ俺ってこういう知的作業にむいてるんだよな。Fランク大落ちて
専門学校に進んだときはみんなから影で馬鹿にされたけど、学校の成績
と頭のよさは別なことくらい気づけっての。
おっと、このコンボボックスにはソートして入れるのか。
えっとソートの関数は・・・。調べるのめんどくさいや。自分で作っちゃえ。
『えー、ソートを自分で作っちゃうなんて○○さんて凄い！』とか言われちゃうんだろうな。
よし、出来上がり。あれ？ソートされてないぞ？ このコンボボックスバグってんな。
しっかりしてくれよDELLさんよぉ。
いたいたしい
>>582 >>584
文字列はともかくとして、ステータスや区分を表すような数値は
#defineやenumで定義するのが得策。
たとえば、顧客管理で更新区分の新規を表すフラグとして1を入れている場合と
顧客年齢層区分の10代を意味する為に1が入っている場合、ベタ書きしてしまうと、
後の改修で「顧客年齢層区分で10代を扱う箇所」を検索する際に
更新区分の箇所まで引っかかってしまい、手間が増す。
文字列はともかくとして、ステータスや区分を表すような数値は
#defineやenumで定義するのが得策。
たとえば、顧客管理で更新区分の新規を表すフラグとして1を入れている場合と
顧客年齢層区分の10代を意味する為に1が入っている場合、ベタ書きしてしまうと、
後の改修で「顧客年齢層区分で10代を扱う箇所」を検索する際に
更新区分の箇所まで引っかかってしまい、手間が増す。
「おい！ この引数が２０個もあるsoutって関数は何なんだ。」
「やだなぁ、エスアウトじゃなくてソートですよ。データを並べかえる関数。
何で２０個も引数があるかって？ 並べ替える対象が２０個あるからですよ。
おや、だったら入力と出力で４０個必要じゃないかと今思ったでしょ？
一つの引数が入力と出力の二つをかねてるんですよ。ちょっとした発想の転換。
こういうOSに近い処理とかはメモリの節約とかも重要なんですよ」
「やだなぁ、エスアウトじゃなくてソートですよ。データを並べかえる関数。
何で２０個も引数があるかって？ 並べ替える対象が２０個あるからですよ。
おや、だったら入力と出力で４０個必要じゃないかと今思ったでしょ？
一つの引数が入力と出力の二つをかねてるんですよ。ちょっとした発想の転換。
こういうOSに近い処理とかはメモリの節約とかも重要なんですよ」
配列で渡せ(;'A`)
>>608
ネタなのか痛いのか判別が難しいところだ・・・・
ネタなのか痛いのか判別が難しいところだ・・・・
だから、ワザワザ同じものを
#define UPDATETYPE_REGISTER (1) /*更新タイプ：新既登録*/
#define AGE_SORT_10 (1) /* 年齢区分：10代 */
と定義してそれを使うわけで。
#define UPDATETYPE_REGISTER (1) /*更新タイプ：新既登録*/
#define AGE_SORT_10 (1) /* 年齢区分：10代 */
と定義してそれを使うわけで。
>>606,609
同じ人ですか？すごく面白いです。シリーズ化きぼんぬ
同じ人ですか？すごく面白いです。シリーズ化きぼんぬ
>>585
sedを使えないわけではないけどね
>>608 >>612
固定文字列に限った話題なのになぜステータスや区分の話に変えるｗ
>>611はその様な主旨だと思うが。
#貴方の揚げている例は双方ともdefineではなくenumにすべきだと思う。
#「更新タイプ」は正確には「更新タイプ区分コード」、「年齢区分」は正確には「年齢区分コード」
sedを使えないわけではないけどね
>>608 >>612
固定文字列に限った話題なのになぜステータスや区分の話に変えるｗ
>>611はその様な主旨だと思うが。
#貴方の揚げている例は双方ともdefineではなくenumにすべきだと思う。
#「更新タイプ」は正確には「更新タイプ区分コード」、「年齢区分」は正確には「年齢区分コード」
615 ：仕様書無しさん：2005/06/24(金) 12:10:11
616 ：615：2005/06/24(金) 12:11:22
結局ここに巣食ってるのは、業務系は業務系でも下っ端PGばっかだな
そこだな、話が噛まないのは。
実際のところ、業務系で純粋なＰＧなんて要らないでしょ。
ある程度顧客と喋れて、要件まとめられて、導入できて、満遍なく出来ないと。
そうじゃない奴は痛いって言われるのは当たり前。
プログラムはあくまで業務目的を完遂する為の手段なので、
極端な例、人系でやるとか、Ｅｘｃｅｌにやらせた結果だけもらうとか、そういう判断とかも必要になる場面もある。
プログラムを作ることが目的ではなく、システム全体を作ることが目的。
それを考えられずに、いわれたとおり作りましたっていう仕事をしたければ、中国人とかと単価競争して残るしかない。
そういう業務系ＰＧってのは要らないよ。
新人時代の最初のプロジェクトはまあいいけど、次からドンドンと仕事の幅を広げないと。
実際のところ、業務系で純粋なＰＧなんて要らないでしょ。
ある程度顧客と喋れて、要件まとめられて、導入できて、満遍なく出来ないと。
そうじゃない奴は痛いって言われるのは当たり前。
プログラムはあくまで業務目的を完遂する為の手段なので、
極端な例、人系でやるとか、Ｅｘｃｅｌにやらせた結果だけもらうとか、そういう判断とかも必要になる場面もある。
プログラムを作ることが目的ではなく、システム全体を作ることが目的。
それを考えられずに、いわれたとおり作りましたっていう仕事をしたければ、中国人とかと単価競争して残るしかない。
そういう業務系ＰＧってのは要らないよ。
新人時代の最初のプロジェクトはまあいいけど、次からドンドンと仕事の幅を広げないと。
PG自体が業務系じゃ下っ端扱い
619 ：仕様書無しさん：2005/06/24(金) 13:19:44
>>617
そういう発想をするヤツが作った仕様というのは、ほとんどが糞である。
業務系といえども、技術的バックグラウンドがないとお話になりません。
業務知識だけなら、現場の事務員の方が優れているんだよ。
技術などいらないというのなら、自らを現場の事務員と同じと宣言しているようなもの。
優秀な業務系SEというものは、
まず、技術があって、その次にヒューマンスキルが付随しているものである。
ヒューマンスキルが必要というのは、
技術しかないヤツを戒めるための言葉であり、
技術がないヤツを安心させるための言葉ではない。
そういう発想をするヤツが作った仕様というのは、ほとんどが糞である。
業務系といえども、技術的バックグラウンドがないとお話になりません。
業務知識だけなら、現場の事務員の方が優れているんだよ。
技術などいらないというのなら、自らを現場の事務員と同じと宣言しているようなもの。
優秀な業務系SEというものは、
まず、技術があって、その次にヒューマンスキルが付随しているものである。
ヒューマンスキルが必要というのは、
技術しかないヤツを戒めるための言葉であり、
技術がないヤツを安心させるための言葉ではない。
まず「業務系における技術」を定義しないと・・・
もし中国人が勤勉で、日本に友好的でかつ言葉の壁がなければ、業務系プログラマの
９５％は失業してるだろうな。
先の反日デモのニュースをTVで見ながら、一緒に拳を振り上げて「愛国無罪」と叫んでいる
業務系マの姿が目に浮かぶｗ
９５％は失業してるだろうな。
先の反日デモのニュースをTVで見ながら、一緒に拳を振り上げて「愛国無罪」と叫んでいる
業務系マの姿が目に浮かぶｗ
> 理工学的な技術はほとんど必要ない。
これが必要なPGって何系よ？
これが必要なPGって何系よ？
625 ：仕様書無しさん：2005/06/24(金) 16:10:08
> 三次元計測制御とか解析シミュレーションとか
じゃ、この辺の業界に従事しているPGは素晴らしい。その逆は痛い訳ね。
で、その辺の業界を一言で言って何系よ？ｗ
三次元計測制御系とか解析シミュレーション系と言えばいいのか？
【三次元計測制御系や解析シミュレーション系のPG素晴らしい】スレでも
立ててくれ。
じゃ、この辺の業界に従事しているPGは素晴らしい。その逆は痛い訳ね。
で、その辺の業界を一言で言って何系よ？ｗ
三次元計測制御系とか解析シミュレーション系と言えばいいのか？
【三次元計測制御系や解析シミュレーション系のPG素晴らしい】スレでも
立ててくれ。
627 ：仕様書無しさん：2005/06/24(金) 16:58:42
628 ：仕様書無しさん：2005/06/24(金) 17:54:20
そもそもこのスレに分類出来る人が居ませんしね
何が>>626をこんなに興奮させたんだろう？ｗ
ま、コンプレックスがあるだけマシかもしれん。
ほんとに痛い奴はコンプレックスすら感じてないわけだから。
ほんとに痛い奴はコンプレックスすら感じてないわけだから。
業務系だからと言って、
コンプレックスやルサンチマンを抱いてるのが必ずしも「マシ」な証拠ではないと思うのだが。
なぜ、コンプレックスを感じなければ成らないんだい？
コンプレックスやルサンチマンを抱いてるのが必ずしも「マシ」な証拠ではないと思うのだが。
なぜ、コンプレックスを感じなければ成らないんだい？
逆。コンプレックスを抱いてるひとが比較して自分が優位だと信じたがるわけで。
コミュニケーションが技術？
そう考えられない時点であんたが判ってないってことだよ。
techniqueとengineeringの違いすらわからないお猿さんがいますねｗ
>>630
＞コンプレックスがあるだけマシ
>>631
＞必ずしも「マシ」な証拠ではない
>>630=632
＞逆。コンプレックスを抱いてるひとが比較して自分が優位だと信じたがるわけで。
＞比較して自分が優位だと信じたがる
＞比較して自分が優位だと信じたがる
＞比較して自分が優位だと信じたがる
という点がサッパリ説得力どころか根拠にもならないって事だろ。
対人能力に優れた業務系様に歯向かっちゃだめよ。
＞コンプレックスがあるだけマシ
>>631
＞必ずしも「マシ」な証拠ではない
>>630=632
＞逆。コンプレックスを抱いてるひとが比較して自分が優位だと信じたがるわけで。
＞比較して自分が優位だと信じたがる
＞比較して自分が優位だと信じたがる
＞比較して自分が優位だと信じたがる
という点がサッパリ説得力どころか根拠にもならないって事だろ。
対人能力に優れた業務系様に歯向かっちゃだめよ。
セールスエンジニア
サービスエンジニア
カスタマーエンジニア
マネージングエンジニア
アカウンティングエンジニア
ジェネラルエンジニア
サービスエンジニア
カスタマーエンジニア
マネージングエンジニア
アカウンティングエンジニア
ジェネラルエンジニア
虚勢に必死
644 ：仕様書無しさん：2005/06/24(金) 22:02:55
だーかーらー、業務系は文系の人間がやるものであって、
工学系のエンジニアの出る幕じゃねいっつーの。
俺達は制御系で、誇り高きエンジニアするんだもんな。
工学系のエンジニアの出る幕じゃねいっつーの。
俺達は制御系で、誇り高きエンジニアするんだもんな。
「おい、このコードなんでこんなフラグだらけなんだよ。もっと
シンプルなステートマシンとして実装できないのか。これじゃ意味不明だぞ」
「これぐらい余裕ですよ。もう、Aさん、大卒の癖に記憶力が無いんじゃないですか？
私はインデント100レベル、グローバル変数5000個、関数10万行ぐらいは余裕です」
シンプルなステートマシンとして実装できないのか。これじゃ意味不明だぞ」
「これぐらい余裕ですよ。もう、Aさん、大卒の癖に記憶力が無いんじゃないですか？
私はインデント100レベル、グローバル変数5000個、関数10万行ぐらいは余裕です」
つまんないな
・メソッドコール毎にログ出力
・try {.. } catch (Exception ex) { log.print(ex.Message); throw(ex); }
みたいにログ吐いて再スローするだけの例外ハンドラを毎度実装
・なぜかログ出力クラスを自前実装
・Aspect指向？何それ
・try {.. } catch (Exception ex) { log.print(ex.Message); throw(ex); }
みたいにログ吐いて再スローするだけの例外ハンドラを毎度実装
・なぜかログ出力クラスを自前実装
・Aspect指向？何それ
648 ：仕様書無しさん：2005/06/24(金) 22:53:32
馬鹿の一つ覚えしかできない
哀れな煽りのピントの外れっぷりを
生暖かい目で鑑賞するスレ
哀れな煽りのピントの外れっぷりを
生暖かい目で鑑賞するスレ
>>649
図星をさされたらしいな
図星をさされたらしいな
おまいらかみ合ってませんよ
で、とにかく半角カナを使いたがる技術者の大半は過去の遺物。
多分昔Z80アセンブラとBASICが友達だった。
単なる2chねらという説もあるが。
多分昔Z80アセンブラとBASICが友達だった。
単なる2chねらという説もあるが。
いや、純粋に偏屈な嫌われ者でしょ？
本人が気付いてないだけ、こだわりと執着・粘着・ストーカー行為の区別がつかないタイプ。
半角・全角がどうしたって？ばっかじゃないの？
本人が気付いてないだけ、こだわりと執着・粘着・ストーカー行為の区別がつかないタイプ。
半角・全角がどうしたって？ばっかじゃないの？
>>657
純粋に基地害じゃん。単に回りが相手にしてないから気付かないんでしょ？
純粋に基地害じゃん。単に回りが相手にしてないから気付かないんでしょ？
粘着しとるのはそっちだろ。
しかも人格攻撃のみ。
くだらん。
俺の提示したテーゼに疑問があるんなら、てめーの技術力で反証せよ。
しかも人格攻撃のみ。
くだらん。
俺の提示したテーゼに疑問があるんなら、てめーの技術力で反証せよ。
で？半角だどうだ関係ないこと言い始めたのはあんただろ？
分裂？統合失調？
分裂？統合失調？
すげえ粘着っぷりだな
おまいらいいかげんにしろ
おまいらいいかげんにしろ
LinuxはLinuxであって、Ｌｉｎｕｘではない。
技術者にとっては自明なことだな。
技術者にとっては自明なことだな。
しつけー。ダメだ全角半角厨。
664 ：仕様書無しさん：2005/06/24(金) 23:23:39
ＪＡＶＡ
667 ：名無しさん：2005/06/24(金) 23:25:44
元コボラー課長＆部長（5年以上ソースはみてない）の、C言語プロジェクトで
痛い目にあった事ならあります。
「プロシージャー仕様書を書きなさい。
プロシージャーを呼び出している所は必ず入出力を明記すること。」
プロシージャーと言うのは関数（標準関数含む）たとの事でした。
「詳細設計の段階で9割り以上のバグを取れ。」
案件は新規業務でしたが、新規も改修も同じだとの思想らしいです。
半年ドキュメント作って、3カ月でコーディング。
でも、いいらしいです。なぜなら設計段階に9割りのバグが取れているはず。
コーディングやテストは新人大量投入。
なぜなら設計書を見れば、キーパンチャーでもコーディング可能なはず。
単体試験はありません。単体試験と結合試験を同時にやるようです。
なぜなら、コボルではコーディングの次は内部試験、運用試験と続くらしいです。
痛い目にあった事ならあります。
「プロシージャー仕様書を書きなさい。
プロシージャーを呼び出している所は必ず入出力を明記すること。」
プロシージャーと言うのは関数（標準関数含む）たとの事でした。
「詳細設計の段階で9割り以上のバグを取れ。」
案件は新規業務でしたが、新規も改修も同じだとの思想らしいです。
半年ドキュメント作って、3カ月でコーディング。
でも、いいらしいです。なぜなら設計段階に9割りのバグが取れているはず。
コーディングやテストは新人大量投入。
なぜなら設計書を見れば、キーパンチャーでもコーディング可能なはず。
単体試験はありません。単体試験と結合試験を同時にやるようです。
なぜなら、コボルではコーディングの次は内部試験、運用試験と続くらしいです。
>>666
いやあ、業務系PGなんぞ要らない（あ、もとは全角だったか）なんてことを
鬼の首でも取ったように大威張りで言われてもな。
そもそもSE/PGなんてくくりは日本独自の腐れ産業システムだから、
>>617程度にも容易に批判可能な「要らない」ものな訳ですよ。
一方において、それなりに大規模なプロジェクト／システム／企業が
関わっている場合、皆がコンサルタントや営業、マネージメントの専門家
である必要は無くて、適材適所で分業が出来たほうがいいに決まっているのだが、
>>617程度の雑なアタマではそういう発想は無視されているわけだ。
いやあ、業務系PGなんぞ要らない（あ、もとは全角だったか）なんてことを
鬼の首でも取ったように大威張りで言われてもな。
そもそもSE/PGなんてくくりは日本独自の腐れ産業システムだから、
>>617程度にも容易に批判可能な「要らない」ものな訳ですよ。
一方において、それなりに大規模なプロジェクト／システム／企業が
関わっている場合、皆がコンサルタントや営業、マネージメントの専門家
である必要は無くて、適材適所で分業が出来たほうがいいに決まっているのだが、
>>617程度の雑なアタマではそういう発想は無視されているわけだ。
>>667
ウォーターフォール信者ですな。
結構多いですね、年配の方には。
彼らにとってはソフトウェア開発は入力と出力がはっきりしていて
機械的な作業に落とすことのできるパイプライン的なプロセスであるらしい
やることが決まりきっていたメインフレーム＆コボル時代にはもしかしたら
そうだったのかもしれない。
今や業務系でさえそうじゃないんだが、「技術なんぞどうでもいい」という
声はここでも聞こえてくるね。
ウォーターフォール信者ですな。
結構多いですね、年配の方には。
彼らにとってはソフトウェア開発は入力と出力がはっきりしていて
機械的な作業に落とすことのできるパイプライン的なプロセスであるらしい
やることが決まりきっていたメインフレーム＆コボル時代にはもしかしたら
そうだったのかもしれない。
今や業務系でさえそうじゃないんだが、「技術なんぞどうでもいい」という
声はここでも聞こえてくるね。
と、＞＞６６８のプログラマー（ＰＧ）が申しております。
>>670
かわいそうに、あんたの会社にはまだPG（全角）なんて職種があるんだな
かわいそうに、あんたの会社にはまだPG（全角）なんて職種があるんだな
なんか盛り上がってるな。
自分が頭がいいと思ってるコンプレックス馬鹿は手がつけられねぇからなｗ
自分が頭がいいと思ってるコンプレックス馬鹿は手がつけられねぇからなｗ
ハニカミ見ておっきした。
>>672
コンプレックスじゃない、彼に与えるのはＣＯＭＰＬＥＸだ。
コンプレックスじゃない、彼に与えるのはＣＯＭＰＬＥＸだ。
676 ：仕様書無しさん：2005/06/24(金) 23:54:52
あはは。馬鹿はまたフレーム議論を自作自演してるｗ
>>617
一見まともそうだけど、「業務系に純粋なPGなんて要らない」とは、
しょぼい現場しか知らないのか、はたまた素人が空想で書いているのかｗ
頭が痛くなるようなレベルの人間集めて、頭が痛くなるようなヲータフール手法を流すのは、
業務系の大規模開発と相場が決まってる・・・つまり業務系PGとは実在するんだよ。但し多少中国人、わずかにインド人ｗ
>>617
一見まともそうだけど、「業務系に純粋なPGなんて要らない」とは、
しょぼい現場しか知らないのか、はたまた素人が空想で書いているのかｗ
頭が痛くなるようなレベルの人間集めて、頭が痛くなるようなヲータフール手法を流すのは、
業務系の大規模開発と相場が決まってる・・・つまり業務系PGとは実在するんだよ。但し多少中国人、わずかにインド人ｗ
社会にゴミは必要なんだよ
社会からゴミを掃除したら、今までゴミじゃなかった奴がゴミになるだけだ
社会からゴミを掃除したら、今までゴミじゃなかった奴がゴミになるだけだ
つまり「業務系技術者は高い技術も能力も必要としないが、世の中には必要な存在」ってことだな。
これなら双方文句はないだろ。
お互い少し譲歩しろ。
これなら双方文句はないだろ。
お互い少し譲歩しろ。
>>677
相変わらずアンタのレスはピントづれまくりだな。
中国人やインド人でもできる、つうあたりがキモ。
ついでにいうと、日本固有の業務知識に依存しない
制御系や高度なオブジェクト指向のプログラミングの分野では
中国人やインド人がかなり活躍すると漏れも思う
相変わらずアンタのレスはピントづれまくりだな。
中国人やインド人でもできる、つうあたりがキモ。
ついでにいうと、日本固有の業務知識に依存しない
制御系や高度なオブジェクト指向のプログラミングの分野では
中国人やインド人がかなり活躍すると漏れも思う
682 ：仕様書無しさん：2005/06/25(土) 00:47:54
組み込み系が最強
> 高度なオブジェクト指向のプログラミングの分野
それ、どんなだ
秒速30万キロで水素エンジンを噴射しながら後退しつつ
タスク間で夢見るメッセージ送受信を行うような
ワンダホーでエキセントリックでちょっぴりおちゃめな
プログラムのことか
それ、どんなだ
秒速30万キロで水素エンジンを噴射しながら後退しつつ
タスク間で夢見るメッセージ送受信を行うような
ワンダホーでエキセントリックでちょっぴりおちゃめな
プログラムのことか
衛星プロジェクトでアルゴリズム担当してた漏れに対して、
頭悪過ぎな発言だな。
頭悪過ぎな発言だな。
アタマ？悪いですが何か？
でも、漏れとか言いませんが何か？
（くそう、そんな仕事してみたい....）
でも、漏れとか言いませんが何か？
（くそう、そんな仕事してみたい....）
686 ：仕様書無しさん：2005/06/25(土) 01:12:07
まあ秒速30万キロは光速だからね
アタマの悪い業務系のぼくにもパッと思いつくスピードが
まいっちんぐなワケですよ
アタマの悪い業務系のぼくにもパッと思いつくスピードが
まいっちんぐなワケですよ
物理板でやれよ厨房
どっちでもいいけど板違いなのすらわからないのはさすがだな。
話の流れがあると思うけどね。
それにマ板はもともとネタ板だよ。ム板にでも逝ったら？
それにマ板はもともとネタ板だよ。ム板にでも逝ったら？
693 ：仕様書無しさん：2005/06/25(土) 02:39:12
>>690
付け刃の知識で煽るとは、哀れなもんだ。
化学が噴射スピードを決めてくれるのかい？
そして噴射物の相対論的効果も化学が与えてくれるのかい？
・・・業務系の人物と話してて噴飯物なのは、
まさにこのレベルの取り違えを平気で業務領域で行う、という点だ。
技術領域は言わずもがな。
付け刃の知識で煽るとは、哀れなもんだ。
化学が噴射スピードを決めてくれるのかい？
そして噴射物の相対論的効果も化学が与えてくれるのかい？
・・・業務系の人物と話してて噴飯物なのは、
まさにこのレベルの取り違えを平気で業務領域で行う、という点だ。
技術領域は言わずもがな。
695 ：仕様書無しさん：2005/06/25(土) 02:47:56
↑典型的なバカ
↑同意
＞化学が噴射スピードを決めてくれるのかい？
>>693
噴射スピードを決めてくれるのが化学なのではなく、
それを実測などで数値化することが化学。
物理屋さんは全部演繹しないと気がすまないようだけど・・・
まぁ、俺は
①物質によって噴射スピードが決まっている
②そのスピードは高速よりもはるかに遅く
相対論的効力を論じる余地がない
③①は化学の問題である
といいたいだけ。
相対論的効果なんていってるけど、
水素エンジンの最高速度を考えたら、それこそ噴飯ものだよ。
>>693
噴射スピードを決めてくれるのが化学なのではなく、
それを実測などで数値化することが化学。
物理屋さんは全部演繹しないと気がすまないようだけど・・・
まぁ、俺は
①物質によって噴射スピードが決まっている
②そのスピードは高速よりもはるかに遅く
相対論的効力を論じる余地がない
③①は化学の問題である
といいたいだけ。
相対論的効果なんていってるけど、
水素エンジンの最高速度を考えたら、それこそ噴飯ものだよ。
①物質によって噴射スピードが決まっている
はぁ？
②そのスピードは高速よりもはるかに遅く
相対論的効力を論じる余地がない
まぁ置いとくとして
③①は化学の問題である
はぁ？
痛々しいな
はぁ？
②そのスピードは高速よりもはるかに遅く
相対論的効力を論じる余地がない
まぁ置いとくとして
③①は化学の問題である
はぁ？
痛々しいな
姉ちゃんがボクの下着を、まで読んだ。
> 噴射スピードを決めてくれるのが化学なのではなく、
> それを実測などで数値化することが化学。
はつみみです：-P
> それを実測などで数値化することが化学。
はつみみです：-P
ヒント：燃焼速度
もう寝る。
もう寝る。
ヒント：ノズル
ヒント：姉ちゃん
704 ：仕様書無しさん：2005/06/25(土) 03:43:46
業務系ってこんなんばっかだな。
化学も相対論も俺様定義でケムに巻いて、
例：
ヤバくなると雲隠れして、陰に隠れて最後っ屁。
化学も相対論も俺様定義でケムに巻いて、
例：
ヤバくなると雲隠れして、陰に隠れて最後っ屁。
http://www.google.com/search?num=10&hl=ja&c2coff=1&biw=885&q=%22%E7%9B%B8%E5%AF%BE%E8%AB%96%E7%9A%84%E5%8A%B9%E5%8A%9B%22&lr=lang_ja
"相対論的効力"に該当するページが見つかりませんでした。
検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
"相対論的効力"に該当するページが見つかりませんでした。
検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
この粘着してんのは業務系にコンプレックスでもあんのか？
むしろ姉ちゃんコンプレックスか
まず、全角厨ってのは物理化学の話の馬鹿とイコールなのか？
そしたらかなりの馬鹿だね。ほんと自分が賢いと思ってる。
そしたらかなりの馬鹿だね。ほんと自分が賢いと思ってる。
哀れな奴
711 ：仕様書無しさん：2005/06/25(土) 07:19:54
奴は、「自分がバカなのではなく相手こそが真のバカだ」
というつまらない言辞に時間をかけるから一発で判る。
そんなことやってるから、５年間も無職で引き篭もるハメになるんだろう？
というつまらない言辞に時間をかけるから一発で判る。
そんなことやってるから、５年間も無職で引き篭もるハメになるんだろう？
賢いって大変ですね。
馬鹿ばっかりの俗世間で生活するの大変でしょうに。
馬鹿ばっかりの俗世間で生活するの大変でしょうに。
>711
PGで
5年も無職の人っているのかしらん。
定年退職でもなければ致命的だと思うけど。
PGで
5年も無職の人っているのかしらん。
定年退職でもなければ致命的だと思うけど。
確かに業務系はレベル低いし、それなりの奴しかいないが、俺だけは例外。
俺も例外C言語ができるし
業務系を叩いている人も業務系関係者なんでしょ？
俺だけが例外だと張り切って業務系から離れたヤツがここに粘着している罠
俺はVBしかできないけどＡＰＩとか呼んだことあるから制御系でも通用すると思う
719 ：仕様書無しさん：2005/06/25(土) 13:33:10
いやー、業務系ってスバラシイ♪
別に業務系だから痛いとは思わないけど、コミニュケーション能力を「技術」という奴がいるのには
さすがに笑った。
書いた本人も後で恥ずかしい思いをしただろうｗ
さすがに笑った。
書いた本人も後で恥ずかしい思いをしただろうｗ
>720
イタタタタw
書いた本人も後で恥ずかしい思いをしただろうw
イタタタタw
書いた本人も後で恥ずかしい思いをしただろうw
業務系の痛い奴が語る「技術」って、伊東家の食卓の裏技レベルだからなぁｗ
723 ：仕様書無しさん：2005/06/25(土) 14:17:10
と、元業務系が語るのであった
業務関係を見下す人たちは、学歴とか収入とかの
偏った”価値観”でしかものを見れない人たち
だと思います。
頭の良し悪しだけで職業の優劣を決定されてしまうのは
間違っています。
偏った”価値観”でしかものを見れない人たち
だと思います。
頭の良し悪しだけで職業の優劣を決定されてしまうのは
間違っています。
technologyもskillもtechniqueも訳すと「技術」
業務系にとってはあくまで技術＝スキル
決してエンジニアリングではない
そこが痛いと言われるゆえん
決してエンジニアリングではない
そこが痛いと言われるゆえん
そうだな、スキルの範囲を超える技術って必要じゃないな業務系は。
で、何でそれが痛いんだ？
で、何でそれが痛いんだ？
クライアントとの折衝ってスキルの範囲を超えてるよ
粘着してるのって、自分の分野で通用しないから、こっち来て愚痴ってるんだろ？
言葉ジリというか言葉の定義だけ粘着して、本質の議論ができないからつまらん奴。
言葉ジリというか言葉の定義だけ粘着して、本質の議論ができないからつまらん奴。
「習得方法が確立されていて反復練習によって確実に習得できるもの」
ぐらいの理解じゃなかろうか。掛け算の九九とか。
ぐらいの理解じゃなかろうか。掛け算の九九とか。
一般人から見たら「プログラマ＝コミュニケーション能力にちょっと欠ける人たち」って
認識なのに、自分たちは高いと思ってるんだね。
ただの事務員の意見でした。
認識なのに、自分たちは高いと思ってるんだね。
ただの事務員の意見でした。
誰のことかと思えば…
>>733-734
プログラミング技術のことですが、何か？
折衝なんかやってらんねーと言いたかっただけなんだよね。
コミュニケーション能力が無いと言うか、基本は引き篭りだからね。俺
>>733-734
プログラミング技術のことですが、何か？
折衝なんかやってらんねーと言いたかっただけなんだよね。
コミュニケーション能力が無いと言うか、基本は引き篭りだからね。俺
>>737みたいなタイプが多いと思ってたんだけど、このスレ見てるとやたら
コミュニケーション能力を強調する人多いね。
コミュニケーション能力はもちろん必要だけど、それに長けた人が多いようには
感じないんだけど・・。
コミュニケーション能力を強調する人多いね。
コミュニケーション能力はもちろん必要だけど、それに長けた人が多いようには
感じないんだけど・・。
ない奴ってのがとことん無いのがあれだな。
対社外レベルどころか、社内、チーム、マンツーマンでも厳しい奴とかいるし。
対社外レベルどころか、社内、チーム、マンツーマンでも厳しい奴とかいるし。
営業・交渉（喧嘩もあり）は皆が皆できんでもいいが
客と全く話せないってのは困るわなあ
客と全く話せないってのは困るわなあ
>>739
>>741
じゃあ このスレで業務系の人が必死にアピールしてる
「技術じゃ劣るが、コミュニケーション能力は勝ってる」ってのは何なの？
やっぱり、技術もコミュニケーション能力も劣ってる人がやる仕事ってこと？
>>741
じゃあ このスレで業務系の人が必死にアピールしてる
「技術じゃ劣るが、コミュニケーション能力は勝ってる」ってのは何なの？
やっぱり、技術もコミュニケーション能力も劣ってる人がやる仕事ってこと？
ＳＥ＞ＰＧという文化があるのが業務系の特徴だよな。
実際、業務系のプログラミング部分自体はたいした技術力必要ないわけだし。
「プログラミングなんて下っ端がやるもの」という文化に対するストレスが、
このスレでの過敏な反応の一因であると見るがいかがなものか。
実際、業務系のプログラミング部分自体はたいした技術力必要ないわけだし。
「プログラミングなんて下っ端がやるもの」という文化に対するストレスが、
このスレでの過敏な反応の一因であると見るがいかがなものか。
文化というかシステムというか。
新人の最初の配属時はPGで後はエスカレータ式にSEにしてみたり。
で、肩書きだけの問題だったり。
まあ、SEはSEで、「コーディングができないSE」という技術者だかよく
わかんない人種が結構いて、それはそれで馬鹿にされたりするのが
業務系なんだが、完全に発注側として下請けに丸投げのスタイルでは
それで困らないのも事実で。つかそういうシステムで動いてる業界で。
でも最近は小型短納期開発が多くて、旧態依然としたシステムが
結構破綻してきてるのも事実。
新人の最初の配属時はPGで後はエスカレータ式にSEにしてみたり。
で、肩書きだけの問題だったり。
まあ、SEはSEで、「コーディングができないSE」という技術者だかよく
わかんない人種が結構いて、それはそれで馬鹿にされたりするのが
業務系なんだが、完全に発注側として下請けに丸投げのスタイルでは
それで困らないのも事実で。つかそういうシステムで動いてる業界で。
でも最近は小型短納期開発が多くて、旧態依然としたシステムが
結構破綻してきてるのも事実。
制御系もゲーム系も大した技術力は必要無い訳で。
技術力が無い香具師ほどとりあえず業務系は～
と逝っとけばOKみたいな短絡思考しか持ってないよな。
技術力が無い香具師ほどとりあえず業務系は～
と逝っとけばOKみたいな短絡思考しか持ってないよな。
わはははは。
でも、制御屋、ゲーム屋→業務系の転向は通常「技術面」では
全く問題ないが、逆は厳しいんじゃないか。
でも、制御屋、ゲーム屋→業務系の転向は通常「技術面」では
全く問題ないが、逆は厳しいんじゃないか。
当社の業務におけるコミュニケーション能力の中で第一義とされているのは
声 が で か い こ と
であります。隊長
声 が で か い こ と
であります。隊長
技術がどうかはしらねーが、大体使えないよな。
お前、それを客が認めると思うのか？っていうプログラマー都合仕様を平気で言うんだよね、技術偏重の人って。
あと、何でも作ればいいと思ってるから、コスト無視して作らんでも転がってるものまで作るし。
お前、それを客が認めると思うのか？っていうプログラマー都合仕様を平気で言うんだよね、技術偏重の人って。
あと、何でも作ればいいと思ってるから、コスト無視して作らんでも転がってるものまで作るし。
俺の個人的経験から言って、「車輪の再発明しちゃう人」って
要するに耳・アンテナの類がダメな人。既存技術を知らない、調べないから
作ってしまう。
技術指向かどうかは関係ない。つか本当に技術指向なら、そういうことは
ありえない。
要するに耳・アンテナの類がダメな人。既存技術を知らない、調べないから
作ってしまう。
技術指向かどうかは関係ない。つか本当に技術指向なら、そういうことは
ありえない。
>>751
コスト意識ないのはコミュニケーション偏重の人が多いって印象だけどなあ。
これから作るものがどれぐらいのコストがかかるかわからないから
お客のいうことはとりあえずOKで、ってスタイル持ってる人多い印象。
技術的なバックボーンがないから、コミュニケーションしてても
出るとこと引くとこがわからないらしい。
コミュニケーションってのを仲良くなることと勘違いして
仲良くなった結果「つきあいだから」断れなくなったりとか。
どうもプログラマ都合仕様ってのにこだわってるみたいだけど（CEかなんか？）、
ほんとにそれが「プログラマ都合」なのかどうか・・・。
「コスト的スケジュール的に無理です」ってのを極解しているだけなのでは？
プログラマと「コミュニケーション」してみることをお勧めしますよ。
お客の側だけ向いてるのが「コミュニケーション」ではないでしょ？
コスト意識ないのはコミュニケーション偏重の人が多いって印象だけどなあ。
これから作るものがどれぐらいのコストがかかるかわからないから
お客のいうことはとりあえずOKで、ってスタイル持ってる人多い印象。
技術的なバックボーンがないから、コミュニケーションしてても
出るとこと引くとこがわからないらしい。
コミュニケーションってのを仲良くなることと勘違いして
仲良くなった結果「つきあいだから」断れなくなったりとか。
どうもプログラマ都合仕様ってのにこだわってるみたいだけど（CEかなんか？）、
ほんとにそれが「プログラマ都合」なのかどうか・・・。
「コスト的スケジュール的に無理です」ってのを極解しているだけなのでは？
プログラマと「コミュニケーション」してみることをお勧めしますよ。
お客の側だけ向いてるのが「コミュニケーション」ではないでしょ？
>>756
コスト意識の向いてるベクトルが少なくとも違うよね。
技術が分からないタイプのSEに欠けており、しかも問題なのが
見積もり能力が無いこと。それを自覚して毎回お持ち帰りして開発側と
ネゴ取ってればいいんだが、往々にして客商売はそうは運ばない。
コスト意識の向いてるベクトルが少なくとも違うよね。
技術が分からないタイプのSEに欠けており、しかも問題なのが
見積もり能力が無いこと。それを自覚して毎回お持ち帰りして開発側と
ネゴ取ってればいいんだが、往々にして客商売はそうは運ばない。
原価のわからない営業って
「営業」と言っていいのか？
「営業」と言っていいのか？
759 ：仕様書無しさん：2005/06/26(日) 09:08:03
コスト管理は一般的に製造部門の仕事かな。
歩合が売上ベースだと、原価なんか知ったこっちゃなくなるかもねぇw
歩合が売上ベースだと、原価なんか知ったこっちゃなくなるかもねぇw
ふとんの訪問販売とか
掃除機の訪問販売だと
そうなのかもな。
掃除機の訪問販売だと
そうなのかもな。
制御系なんかは低いレイヤで蠢いているだけの存在。
762 ：仕様書無しさん：2005/06/26(日) 18:03:41
>751は自分が劣悪な環境に居ることに気づかないでそれが普通だと思い込んでいるだけ。
>>762
制御系、ゲーム系だろうが、できる人は出来るよ。
ただ、大体においてそっちから流れてきた人ってのは
そっちでなんか理由があって来てるから、ベストじゃない人なんだよね。
まあ、そんな人が流れてくる環境事態が劣悪だというならそれは認めるけどね。ｗ
制御系、ゲーム系だろうが、できる人は出来るよ。
ただ、大体においてそっちから流れてきた人ってのは
そっちでなんか理由があって来てるから、ベストじゃない人なんだよね。
まあ、そんな人が流れてくる環境事態が劣悪だというならそれは認めるけどね。ｗ
優秀な奴が制御系から業務系にいくことはまずないしな。
逆に自分は優秀だと勘違いしてるやつが制御系にのりこんで、
泣きべそかいてる光景はよく見るがｗ
逆に自分は優秀だと勘違いしてるやつが制御系にのりこんで、
泣きべそかいてる光景はよく見るがｗ
制御系が優れてるってことはよくわかった。
でもな業務系のほうがいい給料もらってるってのはどう説明すんの？ｗ
でもな業務系のほうがいい給料もらってるってのはどう説明すんの？ｗ
>>765
なんでそんな事に説明が必要なのだ？
なんでそんな事に説明が必要なのだ？
制御系が優れてるってことはよくわかった。
でもな業務系のほうがいい給料もらってるって事実に対して自分の中でどう折り合いつけてんの？ｗ
でもな業務系のほうがいい給料もらってるって事実に対して自分の中でどう折り合いつけてんの？ｗ
給与なんて飾りです、会社のお偉いさんがそういってるからそうなのです！
Dircet3Dもバリバリ使う業務系の俺が来ましたよ。
>>769
業務系でんなモン何につかっとるんだ？
業務系でんなモン何につかっとるんだ？
バリバリよろしくぅーーーーーーーーーーーーっ！
EasterEggだろ？
やっぱおしゃれな人はそういう見えないところに凝らないと。
やっぱおしゃれな人はそういう見えないところに凝らないと。
Direct3Dは趣味です。
業務系ゲームソフト作ってる人も「業務系」ですかね？
776 ：仕様書無しさん：2005/06/27(月) 01:37:03
業務系ゲームソフトとは何かをまずは定義して欲しい
大学でせっかく制御の勉強したのに（倒立しんしとかNN）業務系のゴリゴリ力仕事してます
ここに粘着してるキミは、
明日の仕事は無いのかな？
つか、未来永劫仕事無いのか？
・・・気楽でいいなぁ、落伍者は
明日の仕事は無いのかな？
つか、未来永劫仕事無いのか？
・・・気楽でいいなぁ、落伍者は
>>778
「業務用」と「業務系」を混同してないか？
「業務用」と「業務系」を混同してないか？
>780
しーっ。黙っといてやれよ。
しーっ。黙っといてやれよ。
業務系だけど、3Dを駆使してシミュレーションさせる案件がありますた。
これ以上詳しく書けませんけど。
これ以上詳しく書けませんけど。
それはここで言ってる業務系とはちがうだろ
会社や部署が普段扱ってる案件が業務系で、自分自身も業務系の人と
認識している、という意味じゃまいか
認識している、という意味じゃまいか
制御系の人達って低所得者層に入ってたんだｗ
自演乙ｗ
788 ：名無しさん：2005/06/27(月) 20:59:25
妙に最新技術に詳しくても実務に使った事が無さそうな人がいるようですが、
いったいどうゆう職業の方なのでしょうか？純粋に興味があります。
いったいどうゆう職業の方なのでしょうか？純粋に興味があります。
知ってることと実務で使うことは当然別だろ？
まさか覚えたら死ぬまで続ける猿ですか？
まさか覚えたら死ぬまで続ける猿ですか？
>>778
いちお２流くらいのとこなんだけどね。
いちお２流くらいのとこなんだけどね。
大学の専門の知識なんか全然つかわねーし
今の俺は学生どころか工房厨房にも劣るな確かに
今の俺は学生どころか工房厨房にも劣るな確かに
792 ：名無しさん：2005/06/28(火) 08:48:50
>>789さん
知っていて使ったことがあると、知っていて使ったことがないでは
当然別だと言うのは分かりますが、それが死ぬまで使うとどう関係あるのか分かりません。
最新技術は出るのが早いから使っている暇が無いと言う意味でしょうか？
知っていて使ったことがあると、知っていて使ったことがないでは
当然別だと言うのは分かりますが、それが死ぬまで使うとどう関係あるのか分かりません。
最新技術は出るのが早いから使っている暇が無いと言う意味でしょうか？
俺は最新技術を知ってるけど実務では使わない低レベルな仕事しかしてないんだよ。
でも技術力は確かに高いしお前らより全然レベルは上なんだ。
という意味に見えた。
でも技術力は確かに高いしお前らより全然レベルは上なんだ。
という意味に見えた。
サルの部分は書いといて余計だとは思った。
ただ、知ってると使うってのが直結してるのは流石にいないだろ？
知ってる＝選択肢が増える、使う＝諸事情を総合的に判断して使う。ですから。
使うってのが自分でテストする程度なのか、実務でどっかで試せるのかで全く違うわな。
技術者としたら新しいものに飛びつきたいし試したいのは判るけど、それとシステムの安定・成功は別だから。
ただ、知ってると使うってのが直結してるのは流石にいないだろ？
知ってる＝選択肢が増える、使う＝諸事情を総合的に判断して使う。ですから。
使うってのが自分でテストする程度なのか、実務でどっかで試せるのかで全く違うわな。
技術者としたら新しいものに飛びつきたいし試したいのは判るけど、それとシステムの安定・成功は別だから。
これからは業務系でも３Dは必須になるだろう。３Dは今のところ最も初心者に優しいイ
ンターフェースであることが証明されており、技術の向かう次の目的地の一つだからだ。
ンターフェースであることが証明されており、技術の向かう次の目的地の一つだからだ。
下痢便がこびりついてるな
でも業務系に携わってる香具師が一番給料良さそうだよなｗｗ
金融、証券の案件なんて羽振りのいいお客様だから
給料ガッポリって感じじゃね？
物流系はチープな客が多いが。
通信系はドコモ、ＫＤＤＩ案件なら良いね。
ＮＴＴ案件はイマイチだね。
制御系・・・携帯端末、カーナビ案件なら良いが、ＮＣ工作系だとたぶん脂肪
金融、証券の案件なんて羽振りのいいお客様だから
給料ガッポリって感じじゃね？
物流系はチープな客が多いが。
通信系はドコモ、ＫＤＤＩ案件なら良いね。
ＮＴＴ案件はイマイチだね。
制御系・・・携帯端末、カーナビ案件なら良いが、ＮＣ工作系だとたぶん脂肪
いろんな板にマルチポストするほどおもしろくもない記事だから
てゆーかつまらんからほどほどにしとき
てゆーかつまらんからほどほどにしとき
ん？
801 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:23:18
銀行システムやってます。金融の話はめったにしませんよ。
上司は、銀行員。
上司は、銀行員。
802 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:27:50
まあ、常々おもうけれど、格下の人（たとえば制御系の人にたいして、業務系の人）をたたくっていう行為は仕事上でうまくいってなかったりするんだよね。
結局そういう人は、業務系でうまくいってる人と比べて上かどうなのかは、微妙なとこだね。
（関わるだけなら、だれでもできる）
結局そういう人は、業務系でうまくいってる人と比べて上かどうなのかは、微妙なとこだね。
（関わるだけなら、だれでもできる）
803 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:30:52
あと、給料多くもらってるほうがそれなりに需要や価値があるということですよ。
あとは自己満足の世界ってことです。
あとは自己満足の世界ってことです。
上とか下とかない。
ただ、技術を必要とする状況とマンパワー的なものを必要とするそのウエイトが違うのは確か。
ただ、技術を必要とする状況とマンパワー的なものを必要とするそのウエイトが違うのは確か。
805 ：仕様書無しさん：2005/10/10(月) 13:43:03
806 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:47:08
>>163
業務系以外でもこんなﾊﾞｶがいるんだ
業務系以外でもこんなﾊﾞｶがいるんだ
>>804
> 上とか下とかない。
>
> ただ、技術を必要とする状況とマンパワー的なものを必要とするそのウエイトが違うのは確か。
技術力に関しては、大きな上下格差があるのは確か。
業務系のやつが技術について語ったりしてるのを見ると確かに痛さは感じる。
> 上とか下とかない。
>
> ただ、技術を必要とする状況とマンパワー的なものを必要とするそのウエイトが違うのは確か。
技術力に関しては、大きな上下格差があるのは確か。
業務系のやつが技術について語ったりしてるのを見ると確かに痛さは感じる。
809 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:57:07
>>198
何これ？当たり前じゃない？あほ？
何これ？当たり前じゃない？あほ？
810 ：せる ◆9gLessA9bA ：2005/10/10(月) 13:58:22
811 ：仕様書無しさん：2005/10/10(月) 14:00:58
>>809
こういう当たり前のことが出来ない奴が業務系には
多いってことなんじゃねーの？
系統はどうだか知らんが、こういう奴は結構いるな
俺はこういう奴は嫌いだ･･･が結構上流工程に多かったりする･･･
こういう当たり前のことが出来ない奴が業務系には
多いってことなんじゃねーの？
系統はどうだか知らんが、こういう奴は結構いるな
俺はこういう奴は嫌いだ･･･が結構上流工程に多かったりする･･･
812 ：せる ◆9gLessA9bA ：2005/10/10(月) 14:04:06
>>807
なんか、論点が深くなりすぎていますが、少なくとも給料は自分で決めているものではないですよね？
自己満足も含まれますけど。
同じ給料で、大変な思いをするのと、楽なのとどっちが優れていると思いますか？
なんか、論点が深くなりすぎていますが、少なくとも給料は自分で決めているものではないですよね？
自己満足も含まれますけど。
同じ給料で、大変な思いをするのと、楽なのとどっちが優れていると思いますか？
だからなんで何ヶ月も前のﾚｽに
今頃ノコノコ出てきてﾚｽ付ける莫迦が湧くんだよ。
(しかもｺﾃ名乗る場合が多い)
今頃ノコノコ出てきてﾚｽ付ける莫迦が湧くんだよ。
(しかもｺﾃ名乗る場合が多い)
なにこの糞コテ
業務も制御もやるけど、計算式とか考えるのはどのみちPGの仕事では無いので
レベルなんぞ差が付きようが無いと思うんだが。
っていうか、技術の使いまわしのほとんど利かない制御系は正直あんまり受けたくない。
そのかわりドマイナーな環境使えれば売り手主導にはなることもあるんだけど。
でも、あまり吹っかけるとハードから全面リプレースされて、経験を技術として売れなくなる。
そしたら廃品回収したり路上で雑誌売ったりしないといけなくなるかもな。
まぁ、どのみち吸収力と環境適応力が無駄に無いと制御はできないからなんでもやれると思うよ。
レベルなんぞ差が付きようが無いと思うんだが。
っていうか、技術の使いまわしのほとんど利かない制御系は正直あんまり受けたくない。
そのかわりドマイナーな環境使えれば売り手主導にはなることもあるんだけど。
でも、あまり吹っかけるとハードから全面リプレースされて、経験を技術として売れなくなる。
そしたら廃品回収したり路上で雑誌売ったりしないといけなくなるかもな。
まぁ、どのみち吸収力と環境適応力が無駄に無いと制御はできないからなんでもやれると思うよ。
組み込み制御とかもＯＳが乗るようになってから業務と変わんなくなってきたよね。
今時下層からＣでガリガリ書くのってあるのかな？
今時下層からＣでガリガリ書くのってあるのかな？
>>816
> 業務も制御もやるけど、計算式とか考えるのはどのみちPGの仕事では無いので
> レベルなんぞ差が付きようが無いと思うんだが。
そんなコーダレベルの話は誰もしてないが？
＃ ＰＧ＝言われたとおりにプログラムを作るだけの人 という低レベルな発想の
＃ 人間はいつごろから増え始めたんだろう？
> 業務も制御もやるけど、計算式とか考えるのはどのみちPGの仕事では無いので
> レベルなんぞ差が付きようが無いと思うんだが。
そんなコーダレベルの話は誰もしてないが？
＃ ＰＧ＝言われたとおりにプログラムを作るだけの人 という低レベルな発想の
＃ 人間はいつごろから増え始めたんだろう？
>>817
比率的には少なくなってきているけど、あるよ
比率的には少なくなってきているけど、あるよ
>>818
って答えが返ってくるとは思ったが、もちろんSEの仕事でも無いってのはわざと書かないでみたんだがｗ
って答えが返ってくるとは思ったが、もちろんSEの仕事でも無いってのはわざと書かないでみたんだがｗ
822 ：仕様書無しさん：2005/11/02(水) 01:13:24
つ フレームワーク
このスレの９９％のレスは
「底辺で這い回るような業務系には死んでも就きたくない。」
「こんな低俗な事のために、自分が身につけてきたものがあるわけでない。」
こう言いたいんだろうが、
実際問題、ここで糞吐いてるレス主は
罵詈雑言の業務系ですら使い物にならねーよｗ
或いは、その業務系にも耐えられなかった負け犬の遠吠えか。
もっともらしい理論こね回してるだけで、結局何も出来ないんだろうがｗ
まず、社会に出てＧＳ辺りでバイトしてからほざけ。
お前らが言うところの業務系以外はこんなところで糞垂れる時間はないぞ。
まぁ、そんな時間もったいなくて自分のやるべき事に寝食忘れて没頭するだろうがな。
「底辺で這い回るような業務系には死んでも就きたくない。」
「こんな低俗な事のために、自分が身につけてきたものがあるわけでない。」
こう言いたいんだろうが、
実際問題、ここで糞吐いてるレス主は
罵詈雑言の業務系ですら使い物にならねーよｗ
或いは、その業務系にも耐えられなかった負け犬の遠吠えか。
もっともらしい理論こね回してるだけで、結局何も出来ないんだろうがｗ
まず、社会に出てＧＳ辺りでバイトしてからほざけ。
お前らが言うところの業務系以外はこんなところで糞垂れる時間はないぞ。
まぁ、そんな時間もったいなくて自分のやるべき事に寝食忘れて没頭するだろうがな。
827 ：仕様書無しさん：2005/11/03(木) 16:47:14
業務系の末端プログラマがアホなだけ。
上の奴らはそれなりに凄いよ。
上の奴らはそれなりに凄いよ。
禿げ同
98%は末端だがなｗ
98%は末端だがなｗ
一番給料が良いのは何系？
830 ：仕様書無しさん：2005/11/04(金) 12:57:47
何系ってこともないだろ。会社によってピンキリ。
もちろん高学歴で一流企業の研究開発職はそれなりにもらってるが。
もちろん高学歴で一流企業の研究開発職はそれなりにもらってるが。
>>829
突き詰めればマイナーな処理系マスターしてれば
その分単価は高くはなる。
でも仕事も少ない諸刃の剣。
メインストリームから外れたらゼロになるリスクも負う。
そういう意味じゃ、制御系だと手持ちのネタ次第では一時的にバブル状態になる事はありえる。
それもフリーならって条件付だけどな。
そういう意味じゃなくて客の種類で言えば、金融が一番儲かるんじゃない？
涸れて安定してる環境で別にトリッキーさなんか微塵も無いプログラムを淡々と組めばいいんだから。
まぁ、サラリーマンだから個人の給料に差があるかどうかなんて単純に会社の業績次第だろうけど。
>>830
研究(開発)職はプログラマーじゃないだろ。
突き詰めればマイナーな処理系マスターしてれば
その分単価は高くはなる。
でも仕事も少ない諸刃の剣。
メインストリームから外れたらゼロになるリスクも負う。
そういう意味じゃ、制御系だと手持ちのネタ次第では一時的にバブル状態になる事はありえる。
それもフリーならって条件付だけどな。
そういう意味じゃなくて客の種類で言えば、金融が一番儲かるんじゃない？
涸れて安定してる環境で別にトリッキーさなんか微塵も無いプログラムを淡々と組めばいいんだから。
まぁ、サラリーマンだから個人の給料に差があるかどうかなんて単純に会社の業績次第だろうけど。
>>830
研究(開発)職はプログラマーじゃないだろ。
833 ：仕様書無しさん：2005/11/05(土) 00:02:04
何が研究だよ。日本でまともな基礎研究で
成果出してるところは皆無に近い状況なのに。
シリコンバレーでさえ、淡々プログラミングで儲かってるのに。
成果出してるところは皆無に近い状況なのに。
シリコンバレーでさえ、淡々プログラミングで儲かってるのに。
>>827
とりあえず１から８２４くらいまで１００回ほど声に出して読んでみろ。
話はそれからだ。
それとも都合の悪い過去レスにはふれられたくないのか？
お惚けが下手ですな。エロイ人は。
>>828
その末端にも引っ掛らなかった負け犬が何か？
とりあえず１から８２４くらいまで１００回ほど声に出して読んでみろ。
話はそれからだ。
それとも都合の悪い過去レスにはふれられたくないのか？
お惚けが下手ですな。エロイ人は。
>>828
その末端にも引っ掛らなかった負け犬が何か？
基礎研究だけが研究だと思ってる低学歴がいるなｗ
836 ：仕様書無しさん：2005/11/05(土) 17:10:21
先生！>>835は夏休みの研究をまだやってません。
マッチ棒で船作ってるそうです。
マッチ棒で船作ってるそうです。
ﾊｲﾊｲ ﾜﾛｽﾜﾛｽ
痛くないやい！
840 ：仕様書無しさん：2005/12/12(月) 00:52:30
プログラムや仕様バグで世界経済を混乱に陥れることが出来るのは業務系ならではの醍醐味。
東証ガンガレ
東証ガンガレ
>>842
東証のせいで樹海に行った香具師もおるかもしれんぞ・・・。
東証のせいで樹海に行った香具師もおるかもしれんぞ・・・。
844 ：仕様書無しさん：2005/12/12(月) 01:17:54
>>11
> 在庫管理・売り上げ管理・顧客管理とかの事務系
>
> 工学や理学の知識がほとんど要らない
> 人海戦術での力仕事開発
どうやらお前は数年前の古い知識と情報しか持ってないようだな。
最近の業務系は工学や理学の知識を十分必要としている。
ソフトウェア工学、データベース工学、アジャイルソフトウェア開発手法、
オブジェクト指向設計(Object Oriented Design),
オブジェクト指向解析(Objected Oriented Analysis),
eXtreme Programming, Rational Unified Process(RUP), UML(Unified Modelling Language)
EA(Enterprise Architecture),SOA(Service Orieneted Architeture),
SCM(Supply Chain Management), ERP(Enterprise Resource Planning),
ハードウェア工学、電子工学、離散数学、デジタル信号処理、多変量解析、
アスペクト指向、デザインパターン(Design Pattern)、
アーキテクチャパターン(Architecture Pattern)、通信工学、セキュアシステム、
サーバ管理能力、UNIX系OS操作・管理能力、通信プロトコル仕様、W3C勧告、
CGI, Perl, PHP, Java, Java EE(J2EE), *sh, テスト駆動開発
の知識が無ければ
これらの開発は一切できない。
単純作業だったら業務系の案件がこんなにまで増える筈はない。
COPBOL時代の単なるルーチンワークと一緒だと勘違いしないように。
> 在庫管理・売り上げ管理・顧客管理とかの事務系
>
> 工学や理学の知識がほとんど要らない
> 人海戦術での力仕事開発
どうやらお前は数年前の古い知識と情報しか持ってないようだな。
最近の業務系は工学や理学の知識を十分必要としている。
ソフトウェア工学、データベース工学、アジャイルソフトウェア開発手法、
オブジェクト指向設計(Object Oriented Design),
オブジェクト指向解析(Objected Oriented Analysis),
eXtreme Programming, Rational Unified Process(RUP), UML(Unified Modelling Language)
EA(Enterprise Architecture),SOA(Service Orieneted Architeture),
SCM(Supply Chain Management), ERP(Enterprise Resource Planning),
ハードウェア工学、電子工学、離散数学、デジタル信号処理、多変量解析、
アスペクト指向、デザインパターン(Design Pattern)、
アーキテクチャパターン(Architecture Pattern)、通信工学、セキュアシステム、
サーバ管理能力、UNIX系OS操作・管理能力、通信プロトコル仕様、W3C勧告、
CGI, Perl, PHP, Java, Java EE(J2EE), *sh, テスト駆動開発
の知識が無ければ
これらの開発は一切できない。
単純作業だったら業務系の案件がこんなにまで増える筈はない。
COPBOL時代の単なるルーチンワークと一緒だと勘違いしないように。
845 ：仕様書無しさん：2005/12/12(月) 01:22:53
>>11
昨今の業務系でさらに必要になる可能性のあるものを伝えておこう。
量子力学、量子コンピュータ、暗号化技術、
代数学、数論、遺伝子工学、クローン技術、バイオインフォマティックス(情報生物学)、
ライフサイエンス、音響工学、画像工学、数値解析、機械工学、ロボット工学、
組み込み技術、集積回路工学、幾何学、化学、物理学、航空宇宙工学、海洋工学、
ヒューマンインターフェース工学
などだ。
心せよ。
昨今の業務系をあなどることなかれ。
昨今の業務系でさらに必要になる可能性のあるものを伝えておこう。
量子力学、量子コンピュータ、暗号化技術、
代数学、数論、遺伝子工学、クローン技術、バイオインフォマティックス(情報生物学)、
ライフサイエンス、音響工学、画像工学、数値解析、機械工学、ロボット工学、
組み込み技術、集積回路工学、幾何学、化学、物理学、航空宇宙工学、海洋工学、
ヒューマンインターフェース工学
などだ。
心せよ。
昨今の業務系をあなどることなかれ。
> W3C勧告
ﾃﾗﾜﾛｽw
ﾃﾗﾜﾛｽw
847 ：仕様書無しさん：2005/12/12(月) 01:25:07
21世紀はこれから本格的に真のユビキタス社会がやってくる。
それに備えるために我々業務系開発者は
これらの技術を習得しなければならない義務がある。
人類の未来のために。
これからナノテクノロジー、DNA、クローン技術、ロボット工学、
サイボーグ技術が発達してゆく。
これらに備え、我々はやらなければならないことが山ほどある。
我々はハードウェア工学をしっかりと学ばなければならない。
それに備えるために我々業務系開発者は
これらの技術を習得しなければならない義務がある。
人類の未来のために。
これからナノテクノロジー、DNA、クローン技術、ロボット工学、
サイボーグ技術が発達してゆく。
これらに備え、我々はやらなければならないことが山ほどある。
我々はハードウェア工学をしっかりと学ばなければならない。
848 ：仕様書無しさん：2005/12/12(月) 01:27:04
>>846
XML技術を侮ることなかれ。
Web Ｓｅｒｖｉｃｅｓ技術はSOAでは当たり前のように使われている。
だが、C言語時代の古い人間はなぜかこれらを理解できていない人間が
未だに多い。彼らはCSVで十分だと言い張り、XMLのことを少しも理解しようとしない。
此では、彼らの鈍感さが足かせになり、科学技術の進歩に貢献することができない！
XML技術を侮ることなかれ。
Web Ｓｅｒｖｉｃｅｓ技術はSOAでは当たり前のように使われている。
だが、C言語時代の古い人間はなぜかこれらを理解できていない人間が
未だに多い。彼らはCSVで十分だと言い張り、XMLのことを少しも理解しようとしない。
此では、彼らの鈍感さが足かせになり、科学技術の進歩に貢献することができない！
849 ：仕様書無しさん：2005/12/12(月) 01:27:43
知は力なり
科学は力なり
プログラマ＝ソフトウェア科学者なり
科学は力なり
プログラマ＝ソフトウェア科学者なり
言葉を羅列しただけで高尚な世界へいけると思っているJava厨の典型じゃん。
オールラウンダーな俺からしてみれば、業務系は単純作業の塊に過ぎない。
慣れればどんな分野でもそうだが、業務系はそれが顕著。
オールラウンダーな俺からしてみれば、業務系は単純作業の塊に過ぎない。
慣れればどんな分野でもそうだが、業務系はそれが顕著。
851 ：仕様書無しさん：2005/12/12(月) 01:36:30
すぐにJava厨と反応する奴はＣしかできないで
自称「オールランダー」なのですw
自称「オールランダー」なのですw
Javaという言語は単純作業を減らすために
生み出されたことが解らない人がわめいているようです。
生み出されたことが解らない人がわめいているようです。
アカデミックな人ほど、複雑に構造化されたデータよりもプリミティブな
データを直接扱いたがる人が多いな。
Binary 2.0 なんてその典型ｗ
データを直接扱いたがる人が多いな。
Binary 2.0 なんてその典型ｗ
byte[]が一番信頼性の高いデータだからな
856 ：仕様書無しさん：2005/12/12(月) 03:04:27
>>844のW3C勧告を笑わずに読み飛ばせる奴は神。
漏れんとこの場合は、
正直XMLは余計なタグばかり増えてかえって負荷の元になってるような気がするから
一部の設定ファイル以外では使わない方がいくね？って方向になりつつある。
特にSOAPが酷い。
正直XMLは余計なタグばかり増えてかえって負荷の元になってるような気がするから
一部の設定ファイル以外では使わない方がいくね？って方向になりつつある。
特にSOAPが酷い。
まあ CSV にしろ何にしろ、ファイルの仕様さえきちんと決めとけば
いい話だしな。
外部との通信でどうしても XML が必要になったら、そのときに
機械変換すればいいだけ。
いい話だしな。
外部との通信でどうしても XML が必要になったら、そのときに
機械変換すればいいだけ。
SOAPなんて最初から回避したし
まあ、iniファイルをプロセス間通信に使っちゃうような人もいるからな
866 ：仕様書無しさん：2005/12/18(日) 00:12:19
iniファイルは [foo] って感じでセクションを2段にできるが
propertiesファイルは[]セクションがないのは何でだろう。
foo.bar=hogeみたいにしてるみたいだし、そのほうが使いやすいのか？
propertiesファイルは[]セクションがないのは何でだろう。
foo.bar=hogeみたいにしてるみたいだし、そのほうが使いやすいのか？
868 ：仕様書無しさん：2005/12/18(日) 01:36:48
>>867
プログラムで処理するときのことを想像してみたら？
セクションがあってもできないことはないけど、
うまく階層化した構造の方が解析しやすいことは確か。
そういう構造の方が時として良い設計である場合がある。
プログラムで処理するときのことを想像してみたら？
セクションがあってもできないことはないけど、
うまく階層化した構造の方が解析しやすいことは確か。
そういう構造の方が時として良い設計である場合がある。
>>868
まぁ、「いっぽうロシアは鉛筆を使った」の良い例ではあるね。
まぁ、「いっぽうロシアは鉛筆を使った」の良い例ではあるね。
>>867
3階層以上を設定できるじゃん。
でも、日本語扱うのが糞ﾒﾝﾄﾞｸｾｴから漏れはpropertiesあんまり使わない。
でも、どっちがどうとかいうより所詮APIがあるかどうかってだけだから、ああいうのは。
さくっと読めりゃなんでもいい。
3階層以上を設定できるじゃん。
でも、日本語扱うのが糞ﾒﾝﾄﾞｸｾｴから漏れはpropertiesあんまり使わない。
でも、どっちがどうとかいうより所詮APIがあるかどうかってだけだから、ああいうのは。
さくっと読めりゃなんでもいい。
871 ：仕様書無しさん：2005/12/20(火) 12:53:53
業務系でも楽しいんだから別にいいじゃん。
872 ：仕様書無しさん：2005/12/20(火) 13:00:51
ぼくが作ったプログラム見てみてよ。
http://virus.org.ua/unix/woid.jpg
http://virus.org.ua/unix/woid.jpg
はいはいわろすわろす
874 ：仕様書無しさん：2006/02/16(木) 18:14:51
業務系で一番ギャラのいいジャンルって何？
やっぱり金融系？
やっぱり金融系？
業務系という言葉は初めて聞いたな。
他に何系があるんだ？
銀河系とかモハ系とか萌え系あたりか？
他に何系があるんだ？
銀河系とかモハ系とか萌え系あたりか？
出会い系は業務系に入るのか？
ギャラはしょぼい。
ギャラはしょぼい。
878 ：名無しさん：2006/02/17(金) 23:20:40
通信系が一番楽しい。ギャラは交渉次第。
ちなみの876に激しく同意。
ちなみの876に激しく同意。
>>875
モグリの業者ですか?
モグリの業者ですか?
>>876
ぜんぜんおっ系だぜ
ぜんぜんおっ系だぜ
881 ：仕様書無しさん：2006/02/18(土) 16:31:15
何故に今更そんなことを
884 ：仕様書無しさん：2006/02/18(土) 23:27:36
金もらえれば何だってやるけどね。
>>884
そりゃそうだ。遊びでやってんじゃないからなぁ。だから、
頭がいいだけの奴は大企業の研究室で飼い殺しにしといて貰いたい。
って前まで思ってた。でも・・・
大規模プロジェクトで、納期が迫ってるのにミドルウェアの設計がちっとも
FIXしないのはどういう訳だと調べたら、開発担当の研究室連中がこの期に及んで
「オブジェクト指向としての正しい設計とは」とか議論してやがる。
田所博士に成り代わって俺が一発ぶん殴ってやる、と思った。
頭が良くてもセンスが無いとデザインは出来ない現実を認めろ、とも思った。
でも本社様なのでなにも言えませんがなにか。
そりゃそうだ。遊びでやってんじゃないからなぁ。だから、
頭がいいだけの奴は大企業の研究室で飼い殺しにしといて貰いたい。
って前まで思ってた。でも・・・
大規模プロジェクトで、納期が迫ってるのにミドルウェアの設計がちっとも
FIXしないのはどういう訳だと調べたら、開発担当の研究室連中がこの期に及んで
「オブジェクト指向としての正しい設計とは」とか議論してやがる。
田所博士に成り代わって俺が一発ぶん殴ってやる、と思った。
頭が良くてもセンスが無いとデザインは出来ない現実を認めろ、とも思った。
でも本社様なのでなにも言えませんがなにか。
886 ：仕様書無しさん：2006/02/19(日) 15:14:58
>>885
俺はお前みたいに理論抜きの根性論のヤツが大嫌いだ。
お前は「運用で逃げる」という言葉を最初から多用するヤツだ。
そもそも、「運用で逃げる」という言葉は、負け犬の使う言葉である。
お前が馬鹿にする研究室連中は問題に対して、逃げずに正面からぶつかっているのに、
それを自分より劣るものとして卑下しているのは、周りから見ていると悲しい。
つまるところ、お前は開発段階においてから問題管理をインシデント管理と混同しており、
開発局面においてもインシデント対処をしてしまうバカっぷり全開というわけだ。
さっさと業界から足を洗って、コンビニ店員かタクシー運転手にでも転進した方がいいんじぇねぇか？
俺はお前みたいに理論抜きの根性論のヤツが大嫌いだ。
お前は「運用で逃げる」という言葉を最初から多用するヤツだ。
そもそも、「運用で逃げる」という言葉は、負け犬の使う言葉である。
お前が馬鹿にする研究室連中は問題に対して、逃げずに正面からぶつかっているのに、
それを自分より劣るものとして卑下しているのは、周りから見ていると悲しい。
つまるところ、お前は開発段階においてから問題管理をインシデント管理と混同しており、
開発局面においてもインシデント対処をしてしまうバカっぷり全開というわけだ。
さっさと業界から足を洗って、コンビニ店員かタクシー運転手にでも転進した方がいいんじぇねぇか？
887 ：仕様書無しさん：2006/02/19(日) 15:37:03
納期を守ってる奴は好きにやればいいよ。
888 ：仕様書無しさん：2006/02/19(日) 15:42:25
889 ：仕様書無しさん：2006/02/19(日) 18:53:19
>>889
確かに、おまえさんレベルの奴はいない。
確かに、おまえさんレベルの奴はいない。
891 ：仕様書無しさん：2006/02/19(日) 22:12:52
開発担当の研究室連中は理論抜きの根性論のヤツに飯を食わせてもらっている現実
それが、機械工学なら中身の理論は重要なんだが。
ソフトウェア工学では「中身の理論」もカプセル化してかまわないので、要件外の理論に拘るのは得策ではない。
ソフトウェア工学では「中身の理論」もカプセル化してかまわないので、要件外の理論に拘るのは得策ではない。
893 ：仕様書無しさん：2006/02/21(火) 09:19:27
設計で必要なのはセンスじゃなくて経験。
まあ、どっちのとってもいい経験になるんじゃね？
まあ、どっちのとってもいい経験になるんじゃね？
894 ：仕様書無しさん：2006/02/21(火) 09:33:20
経験があってもセンスが無い設計。みただけでｵｴｰとなる。
センスの良い設計はどこかシンプルで美しいオーラがある。
センスの良い設計はどこかシンプルで美しいオーラがある。
895 ：仕様書無しさん：2006/02/21(火) 10:31:11
UMLとオブジェクト指向設計でUMLの静的クラスが1ページ
に書ききれなくなって分散されている。ドキュメントのリンクが
正しく張られてなくて泣きそうだ。こんな設計するリーダーは
Java大好き人間。もし文句を言おうものならオブジェクト指向論を
3時間語られちゃうから逆らえないよ。
に書ききれなくなって分散されている。ドキュメントのリンクが
正しく張られてなくて泣きそうだ。こんな設計するリーダーは
Java大好き人間。もし文句を言おうものならオブジェクト指向論を
3時間語られちゃうから逆らえないよ。
897 ：仕様書無しさん：2006/02/21(火) 13:36:05
いっそ3時間で論破してやれば？
「経験」と「経験年数」は違うものだからなあ。
組み込み系のほうが痛いことがよくわかったわけだが。
制限された環境では実効優先だからな。
実装できん事には設計に綺麗も汚いもない。
携帯とか車載とか、やりたくない分野の筆頭だ。
実装できん事には設計に綺麗も汚いもない。
携帯とか車載とか、やりたくない分野の筆頭だ。
プログラマーきもちわるい・・・
マでもないのにわざわざこんな板に釣り糸垂らしに来るが香具師が居たらきもちわるいな
／＼⌒ヽﾍﾟﾀﾝ
／ ／⌒)ﾉ ﾍﾟﾀﾝ
∧＿∧ ＼ （( ∧＿∧
（； ´Д｀））' ））（・∀・ ；）
/ ⌒ノ （ ⌒ヽ⊂⌒ヽ
.（O ﾉ )￣￣￣(）__ ）
）_）＿） （;;;;;;;;;;;;;;;;;;;）（＿（
／ ／⌒)ﾉ ﾍﾟﾀﾝ
∧＿∧ ＼ （( ∧＿∧
（； ´Д｀））' ））（・∀・ ；）
/ ⌒ノ （ ⌒ヽ⊂⌒ヽ
.（O ﾉ )￣￣￣(）__ ）
）_）＿） （;;;;;;;;;;;;;;;;;;;）（＿（
お膣毛