【日本だけ】SEという職業をなくそうぜ【変な職種】

1 ：2007/06/21 〜 最終レス ：2013/06/10

未経験で入社したのに、
肩書きはプロのSEだっておｗｗｗｗｗ

2 ：

プログラマーの上位職かSEではなく業務の上位工程ってだけだからな
プロジェクトがでかくなると必須なんだよ、なくせないんだよ
別にソース書けなくてもSEは出来るがなプログラムの基礎程度は必須だろうが、言語独自の機能なんぞはプログラマーに聞くんだよ

3 ：

使えないSEさえいなけりゃ別にSEという職があってもいいと思う

4 ：

つまり、小説の作家を先生と読んで
「早く書いてくださいよ〜」となきつく
あれかｗ
おい、これから先生と呼べ。

5 ：

そうだな
接客、仕様交渉、工程計画やスケジュール、各開発者進捗管理、システム全体の進捗管理
この辺全部プログラマーがやればSEなんて糞くだらん職業いらん
プログラマーにも先生早く書いて下さいよーとか言わないですむし万事解決だな

6 ：

>>5
そもそも、それらはPGの仕事ではないどころか
本来のSEの仕事でもないだろう
歪んだ構造がデフォだから仕方ないのだろうけれど

7 ：

>6
んじゃSEの仕事って何なの?

8 ：

>>6
おまえ何も知らないでかいてんじゃね？

9 ：

でもさ、君たちみたいなコーダに毛が生えた程度のプログラマって
分析、設計どころかユーザと打ち合わせするできないでしょ。
要件まとめようってのにコーディングレベルでしか考えられないでしょ？
君たちって。
ユーザ相手にコーディングがどうだこうだって言う子が多いよねプログラマって。
そんなわけで、言われた通りコーディングだけしててよ。
と言ってもバグだらけで結局SEが直してリリースしてんだけどね。
ちょっとは役に立ってよ

10 ：

>>9
へ〜〜〜〜〜〜〜〜すごいな〜〜〜〜〜〜〜〜〜
えらいな〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

11 ：

PG経験があまり無いSEって、なんか、PGを見下してる奴多いよな

12 ：

SEが立てるスケジュールって
なんの根拠も無いよね？

13 ：

>>5
> 接客、仕様交渉、工程計画やスケジュール、各開発者進捗管理、システム全体の進捗管理
それって技術者の仕事？

14 ：

>>13
何も知らん人間は出て行けよ
カス

15 ：

俺はコーディングもできるスーパーSE
通称Ｘ

今おまえらの頭に浮かんだアルファベット３文字はなんだ？

16 ：

>>15 すぐに>>15は　DQNと浮かんだが
ところで、DQNスーパーSE Xさま、
コーディングとプログラミングのちがいってなに？

17 ：

>>5
接客：営業
仕様交渉：プロマネ
工程計画やスケジュール：プロマネ、リーダ
各開発者進捗管理：リーダ
システム全体の進捗管理：プロマネ
ドキュメント作成：新人プログラマ
その他：プログラマ
でいいんじゃ？

18 ：

>>16
コーディング＝バグを注入する作業
プログラミング＝計画法

19 ：

>17
業務種別を更に細かくするならいいだろうけど、小業務別に人事割りしたら遊務社が増えるし、それだけコストもかさむんだべ?
だから何でも屋の業種が暗黙的にいるんじゃなかろうか

20 ：

設計しろやw

21 ：

何でも屋だから設計もやってるだろ

22 ：

>>19
何でも屋なんて中途半端なもんいらんだろ

23 ：

馬鹿は正しいプログラムは書けない
ただ
文章は馬鹿でも書ける

24 ：

優秀な人間ならPGにはならんで、頭がいいと勘違いしてる馬鹿を
安くコキ使うと思いました。
優秀ならそんな待遇で働いてないよねぇｗ

25 ：

むしろ頭がいい分、他のことがおざなりになってんだろ
人間関係の構築ができないとか性格が馬鹿正直であるとかで
かえって利用しやすい
PGの本当の仕事は役員に飯を食わせることなのさ

26 ：

>>25
それを頭悪いって言うのだが。

27 ：

SEの仕事を見ると、
とてもエンジニアの仕事とは思えんなｗ

28 ：

で？

29 ：

専業SEとか専業PGとかいらねえのだけはガチ

30 ：

ただの営業やマネージャでいいと思うんだが？
システムとかエンジニアとか
関係ない仕事でしょ？

31 ：

て言うか、SEも糞。ウォーターフォールモデルも糞。
ゼネコン体質も糞。日本だけの悪しき構造。

32 ：

>>30
実は>>29が良いこと言ってる。
よく考えてみ。

33 ：

実は>>30もいいことを言っている。
よく考えてみ。

34 ：

SEにしろPGにしろ会社の歯車ってことを
忘れてるやつがおおいってのはまちがいない

35 ：

>>34
それとSEの必要性はどういった関係があるのでしょうか？

36 ：

>>35
所詮、同じｸｽﾞってことじゃね?

37 ：

>>30
システムを設計するのがSE
プロジェクトの人員とか進捗とか管理するのがプロマネ
契約取ってきたり成果物を売りに行くのが営業
個人的には、まぁ>>29

38 ：

基本は全てウォーターフォールなのを知らない>>31も糞

39 ：

「相武 紗季」
画数：相(9) 武(8) 紗(10) 季(8)
天画（家柄）17画 中吉 負けず嫌いな頑固者
地画（個性）18画 中吉 エネルギッシュな親分肌
人画（才能）18画 中吉 エネルギッシュな親分肌
外画（対人）17画 中吉 負けず嫌いな頑固者
総画（総合）35画 中吉 縁の下の力持ちで実力発揮
評価 : 80.0点
モバイル姓名判断（http://n1.mogtan.jp/?s488625）

40 ：

>>38
>基本は全てウォーターフォール
kwsk

41 ：

googleとかの欧米企業は、落水モデルなんかで
開発しねーよ。

42 ：

＞基本は全てウォーターフォール
何か違う気がするが、上手く言えない。
インクリメンタル、スパイラルなんかは、
基本的にウォーターフォールを短いサイクルで繰り返すだけと見れなくも無い。
プロトタイピングはウォーターフォールとは関係ないか。
ただ、ウォーターフォールに競合するモンでは無いかも。
テストファーストはウォーターフォールじゃないな。
開発プロセスのモデルって他に何がある？
要件定義→設計→実装→テストで並ばない開発プロセスって他に何かあったっけ？

43 ：

アジャイル

44 ：

いきなり作って即リリース

45 ：

>>42
>開発プロセスのモデルって他に何がある？
ウォーターフォールじゃなくてブラックホールとかスパイラルじゃなくてスピンとか。

46 ：

ウォーターフォールって
雨が降って、川になって、海に注がれて、
蒸発して、雲になって、雨になって・・・って循環する作り方？

47 ：

>>46
シャレだとしたら言いえて妙だなぁ。
雨降ってるが、一部は大体川やら海やら途中で蒸発して上流に戻る。
上流に戻るはずの一部は雲になったまま降ってこない・・・。
マトモに海に流れ出る頃には砂利だの何だの、不純物が一杯混じってる。

48 ：

S = システム　　　　（´_ゝ｀）ﾌｰﾝ
E=エンジニア　　　　(ﾟДﾟ)ﾊｧ?

49 ：

落水教授の研究室が既にウォーターフォールモデルを否定
する論文出しまくってるのを知らない>>38は馬鹿。
>>46
ちゃんと落水教授の原著論文読め。

50 ：

人に職業を聞かれるとプログラマだと言います。
「プログラマ？なんですか、まだ SE になれないんですか、ぷっ…
あれっ、名刺にはシステムエンジニアと書いてあるじゃないですか」
とかことがたまにあって、そんな人に
プログラマ = SE + プログラミング能力
なのだと説いて聞かせてもなかなか納得してもらえません。

51 ：

日本のSEの仕事って、海外じゃ誰がやってるの？
営業？プログラマ？

52 ：

社長

53 ：

>>50
相手の技術レベルがすぐにわかって便利。
でも、「システムエンジニア」と書かれた名刺を持っている人にしか
使いこなせないという諸刃の剣。素人にはお勧めできない。

54 ：

確かにここまで読んでるとＳＥってなんだ？
って気になってきますね・・・。

55 ：

>>51
プログラマだね。外資でもそう。
日本のプログラミングできないSEは海外いったらまずあぶれる。

56 ：

>>5
進捗管理なんて外資ではやらん。
自分で仕事とってきて、お客さんと直接話して、自分でエンド決めて、
仕事がぽしゃっても自分の責任。仕事がとってこれなくなったらクビ。
誰も管理しないし、上下関係もないし、仕事さえしてれば何しようが自由。

57 ：

アメリカなんかじゃ顧客の会社が自分とこの要求をまとめる専門のエンジニアを雇うらしいよ。
技術わからんアホが直接交渉したりしないようにして、効率よく開発するんだと。
まぁディルバートなんかあるからどこまで本当かわからないけどね。

58 ：

外人（米系）は己以外何者も信じてないからな。個人主義がデフォ。
自分の責任でとってきた範囲で賛同者を集めたり、足りない分は人を
雇ったりして仕事を終わらす。無意味な会議も当然ない。
臨時従業員でも優秀な人はそのまま引き抜かれるし、人事なんて現場が
決めた雇用者を人員登録するだけの事務屋。役員でさえ働かなきゃ淘汰されるから。
日本の会社の醸造部やSEや人事なんて仕事してるとは言えないね。

59 ：

×醸造部
○上層部

60 ：

日本にもアメリカみたいな会社出来ないかな〜
給料たかくて、個人主義で、無駄な会議をしない会社。

やっぱ、俺が作るしかないか・・

61 ：

>>60
>給料たかくて(自宅警備員比)、個人主義で(1人で客先常駐)、無駄な会議をしない会社(そもそも社員とすら思われていない)。
派遣？

62 ：

昔俺がいた会社には、役職だけは付いているがたまに俺が客先から戻ると
球技大会の組み合わせや宴会の段取りを考えてばかりいる管理職がいたが、
そんな人はアメリカにはいないわけだな？ｗ

63 ：

ゴマすってるだけの使えない上役はいるけど、球技大会の組み合わせはありえないｗ
立食パーティーの段取りなんかは秘書の派遣のねーちゃんの仕事。
球技大会とか変な大会で下手に束縛すると外人は離れてくから。「みんなでわいわい」
という発想がそもそもない。やるなら派手に豪勢にやらないと参加してくんない。
>>60
外資に入ればいいじゃん。その代わりある日突然クビになったりするけどねｗ

64 ：

>>63
来年から外資です。
ＩＢＭみたいな一流外資じゃないけど、日系企業に比べれば幸せになれそうだわ。

65 ：

>>42
＞開発プロセスのモデルって他に何がある？
賽の河原モデル
　　納期間際に鬼がくる、納期が過ぎても来るｗ
ゴミ屋敷モデル
　　拡張？を繰り返した結果、底のほうには誰もしらない実装が．．．

66 ：

>やるなら派手に豪勢にやらないと参加してくんない。
ＭＬＢの遠征で新人が変な格好させられたりするやつか？ｗ
あとパイのぶつけあいとか。アメリカって日本人の集団行動馬鹿にする割には
自分たちは極端に行動することあるって感じるんだけどな

67 ：

>65
今うちのプロジェクトは、ゴミ屋敷モデルと賽の河原モデルのミックスです。

68 ：

すてきやん

69 ：

サバトちゃんの家モデル

70 ：

systems engineer

71 ：

Excelで仕様書を書くやつは皆くそ

72 ：

グリッド付きで、どこからでもかけるワープロを作ったら、ヒット間違いなし。

73 ：

>>72
テキストボックス使えば？ページのどこにでも任意に配置可能だし。
あとは表組使うとか。　wordの表組みは結構自由が利くからな。

74 ：

>>72
それExcelでセルを細かい格子状にしてやる裏技じゃね

75 ：

EXCELの一番の欠点は、一見WYSIWYGのように見えて実はそうじゃないことｗ
行末欠けの確認と調整に辟易する。

76 ：

>>75
どこかの仕様書で､Excelでページいっぱいのでかい枠をつくってその中にテキストボックスを配置したものを見たことがある｡
Wordにしろよ・・・
あと、「一太郎」で作られた仕様書を見たことがあるぞ。あれは困った｡
作る方は楽かもしれないが｡

77 ：

まだプレインテキストの方がましだ

78 ：

HTMLで書けばどうか

79 ：

そもそも「システム作り」を考えるって経営者だよね。
ユーザ企業が直接、もしくはシステム系子会社がやるべき仕事だ。
SIerとか妙な仕事だと思うよ。
銀行・JR・証券あたりが人件費を減らすために考えたんだろ。
プログラマは電機電器メーカ・ソフトメーカに就職すれば良い。
ユーザ企業から要望あったときだけ、金かけてオーダメイドで作れば良い。
IPAの資格試験もなんか変だね。
プロマネは、試験問題に会計・生産管理・マーケティングが出てくる。
ユーザ企業のための資格ってのがモロに出てる。

80 ：

本来設計からPGがするわけだが、要件定義後（これを何故か設計といわれる場合するらあるが）
顧客に対する出戻りが発生しないという前提なので、話がおかしくなる。

81 ：

ＳＥってパソコンばっかりやってて目が悪くなるイメージがあるけど、
大丈夫？

82 ：

システムエンジニア
システムマネージャー
システムアーキテクト
システムデベロッパー
システムコンサルタント
システムオペレーター
システムアドミニストレーター

これらの違いを簡潔に述べよ

83 ：

あああとあと
システムアナリスト
システムパイロット
システムピッチャー
システムキャッチャー
システムカウンタック
などなどさまざまな業種があります。

84 ：

UFOピッチャー

85 ：

>>82
ポンチ画書き
管理者
夢想者
調停者
詐欺師
キーパンチャー
子守

86 ：

>9
そういう奴に限って、要件定義書書かせると「顧客情報を登録する」「顧客情報を更新する」
みたいなゴミしか書いて寄越さないのな。
俺は業務知識がある、俺は何でもできる、客をひきつける魅力がある、
とか寝言抜かす奴は特にダメだ。
もうプログラミングできるできない以前の問題で、お客さんの言う曖昧な単語を
具体的な何かに置き換えられない感じ。
少なくとも、上の工程をやらせるには力が足りなさ過ぎる。
まぁ寝技営業でもしてせいぜい客にゴマ擦ってくれ。
俺は嫌だから任せるよ、と。
例えば
「顧客情報って何ですかね。　氏名、住所、電話番号、性別、職業、趣味志向、購入した製品、
もちろんその他色々ありますが、お客さんは何を『顧客情報』だと考えているんですか？
で、どうしてお客さんはその情報が欲しいと思っているか、説明してくれませんか」
なんていうとマジギレしやがるのな。常識で分かるだろ！　とか言って。
しゃあないからSE飛び越えて、客と直に電話したりメールのやり取りしたよ。

87 ：

当社のおっさんSE。
・コーディングができない、ソースが追えない
・設計書の記述が曖昧
・PGが質問しても回答が曖昧
→仕方ないので、PGが知恵を振り絞ってどーにか実装。
→製造段階で詳細化された部分の仕様が理解できない！
よって、検収もできない。。。
企業の採用担当者の方、どうか、このおっさんを
もらってやって下さい。
少なくとも、当社のような２次請以降専門の弱小企業では、
いらないです。

88 ：

テスタ、雑用
↓
プログラマ、デバッガ
↓
レビュア、設計
って、段階を踏んで上がっていければいいんだけどな。
プログラマあがりのＳＥじゃなくて、プログラマ崩れのＳＥが多い。

89 ：

ＳＥって使えないイメージが強すぎる。
営業しかやらなくてもＳＥだったりするし

90 ：

>>89
誰でも名乗れちゃうよね。

91 ：

結局、SEってなんなん？
実装できなくてもSEだったり、
え？できなくてもSEって呼んでよいのか！？
たまに要件定義などで、「実装を意識しないこと」とか聞くけど、
それって実装ができないSEのためのセーフティーネット？？

92 ：

>>91
要件定義はあくまで顧客の要求を洗い出すだけ。
ただ、この段階でハードに関する諸元を見積もる必要はある。
ここで実装を考える工程を入れるとSE/PG分業の意味がない。
実装を意識するのは設計の段階。

93 ：

結局、SEって無能な人なんですね。

94 ：

>>92
はぁ？？？
実装手法によってハードに関する諸元が変化するのが普通だが………

95 ：

>>94
なんで実装手法でハードの諸元が変わるの？
その実装手法って何を指してるの？

96 ：

ミドルウェア群の選択とそれに対する妥当なハードウェア構成は密接に結びついている。
要件定義の段階で、その要件を実現可能な実装方式くらい頭に浮かんでいないようではお話にならない。

97 ：

実装できないSEはクソということで一致しましたね。

98 ：

>>91
確かに、実装の '詳細' を意識したら、おかしな事になる
だがどのプロダクトを組み合わせれば出来るかとか、
そうなるとOSはこれで行こうとか、
大体今の要件だと、規模はこの程度だから、この金額でとか、
客側に提案したりするためには、結局実装の構成自体は意識出来ないと論外
しかもその後要求仕様から基本設計へ落とし込むわけで、
その時に下に付くSEやPGに具体的な実装も考慮した指示が出せないんじゃ、
くだらないフィルタリングや妄想が入らないだけ、まだ伝書鳩の方がマシ

99 ：

SE<<<<<<<<<<伝書鳩

100 ：

実装出来ないSEはクソって言葉が指す「実装」て何よって話なんだけどな。
要件定義の工程で求められる能力とプログラムで求められる能力は別でしょ？
そりゃプログラム出来るに越した事はないけどさ。
SEって職制を無くしてPM/PGだけにしてしまえばスッキリするってのが
このスレの結論なんだろうけど。

101 ：

>>100
詳細な実装までは必要ないんじゃねぇの？
だけど、少なくとも、データの流れ方とか、各サブシステムでどの程度の処理
をどんな風に実行しなきゃいけないとか、その程度は押さえる必要があるかと…
極端な例だけど、多数の時系列に連続変化する事象を比較して、結果を元にイ
ベントを抽出後、各イベントを元に処理をするってなシステムを考える
受け取った事象を直接 DB に書くのと、抽出されたイベントを DB に書くので
は実装戦略は大きく変わるし、トランザクションの量も大幅に変わるから、要
求されるハードウェアスペックも変わるでしょ？
てなわけで、詳細は必要ないとしても、要件定義段階でおおざっぱな実装を想
像できない場合、コスト見積もりその他も含めて失敗する可能性が高いって事
だわ
で、実際、よくあるんだわ。「どう見ても要件定義の失敗だろ？」ってな、遅
くて高くてバギーなシステムが…

102 ：

要件定義の時点でシステム内に矛盾含んでたら、
奇跡でも起きない限りシステムは破綻しますから。

103 ：

>>101 の例だと, 生データdbに突っ込むと, 重くてバギーな
システムになるような気がするけどな.
ハードもハイスペックなもの必要じゃない?
だけど, dbをどっちに置いてもシステム的には矛盾しない

104 ：

>>101
例にあげた話だと、DBの構成をどうするかは顧客の要求と予算で変わる。
言葉が足らなくて誤解されてるのかも知れんが、ソフトの諸元決定は
要件定義か設計かって話なら、
それは要件定義だと考えてる。
で、「おおざっぱな実装を想像」の実装って言葉を
システム構成と
読みかえてもいいなら、俺の考えてる事とだいたい同じだと思う。
システム構成考えられないSEは確かにクソだ。
そんな奴は要らんわな。

105 ：

何かおかしなところに改行が入ってる。。。

106 ：

携帯か？

107 ：

>>104
業務系とかだと、経験的な部分が優先されると思われるが、自然現象を
サンプリングするような場合、それは当てはまらなくってだなぁ………
物理法則の勉強のやり直しとか始まるわけで、既存のミドルウェアとか
ほとんど役に立たなくなくなるんだわ
その時にも、ちゃんとシステム構成できるんだったら SE と呼んでもいい

108 ：

はぁ? 馬鹿?
そんなの大学、いや高校で習った物理で十分だろ?
どこの低学歴だよ? まさか池沼文系?
IT業界には全く向かないので、来ないでください。
間違っても組込制御には来んな!

109 ：

> そんなの大学、いや高校で習った物理で十分だろ?
お前、高校で流体力学とか物性物理学とかやったのか？
すごいな、どこの高校だよ？

110 ：

ＳＥはエンジニアだから開発者、設計者だろ
プログラマはドカタ
決まったものを決まったとおりに組み立てるだけ
頭を使うが頭を使わない。いわゆるブルーカラー

111 ：

ふつ〜マだって要件定義とか設計とかやるだろ

112 ：

>>110みたいな頭の悪いのをなくそうってスレなんだが

113 ：

>>110 みたいなコーダーって、まだ棲息してるんだな。

114 ：

SEがエンジニアだとはユニークな発想ですね

115 ：

http://blog.goo.ne.jp/16th-night

116 ：

自分の都合により終了しました

117 ：

一ヶ月振りあげ

118 ：

セクシャルエンジニア【SexualEngineer】[名詞]
プログラマをRする人または職業名。SE。

119 ：

恥ずかしい馬鹿だなw
sexualの意味ぐらい調べてから書けばいいのに。

120 ：

ばるさみこす。

121 ：

くすっ

122 ：

海外ではなんて言ってるの？
ソフトウェア・エンジニア？

123 ：

料理ができないでレシピ作るって言ってるのと一緒
実装出来ない奴は設計と称したゴミを作ってるだけ
包丁使えない料理人がいるのかよ　ぉい

124 ：

将軍が実際の戦場で戦えるか、というとそうでもない

125 ：

あれだよなSEって
最低の味方＝最強の敵
要するに牟田口

126 ：

Javaは一行が長すぎるから気持ち悪い

127 ：

なあに、某PERFORM VARYING文を持つ言語に比べれば

128 ：

>>127
それ何てPL/I？

129 ：

日本語でおｋ

130 ：

つ[なでしこ]

131 ：

昨今ではプログラムどころか日本語すらまともにかけない人ほどSEを自称しているような。
百害あってなんとやら

132 ：

SE はプログラマ上がりなんだから、
実装もできるはずなんですよ。
プログラマ崩れは SE とは言わないんです。
つまり、この業界に向いてるかどうか、
2〜3 年プログラマやってる内に見極めて
見切りをつけろってことです。
崩れたんなら、荷物まとめてクニヘカエレ。

133 ：

三菱に逝ってるが、PG崩れがSE, SE崩れがPM,
更に崩れてパワポ落描きしか出来ないのがコン猿
ということに成ってるな。

134 ：

仕事ありますか？

135 ：

背広着た秋葉系・ホスト、風俗嬢みたいな奴はマジいらんわ。
ちゃんとした奴寄越せ。

136 ：

>>49 誰だよその人。ちゃんとお前の口で説明しろ。

137 ：

ホスト・風俗嬢が経営してるような派遣会社に頼らず、自分で
人集めしろ！

138 ：

SQLも知らんでDB設計する糞。
プログラム書けないで仕様書書く糞。
何も知らんから提案書まとめるしかできない糞。
そんなのが課長職しよるんで、マジで鬱。
最低でもプログラム書けないやつは辞めろ。

139 ：

出来ないヤツから先に管理職に出世する狂った業界

140 ：

>>139
出来るやつ出世させたら誰が実務作業やるんだよ。

141 ：

>>140
でもPG上がりの有能なSEやPMと仕事すると、やっぱり仕事がはかどるんだよな

142 ：

>>138
>SQLも知らんでDB設計する糞。
SQLを知っているかどうかと、まともなDBの設計が出来るかどうかは別問題。
>プログラム書けないで仕様書書く糞。
プログラムを書けるかどうかと以下同文。
>何も知らんから提案書まとめるしかできない糞。
まとめてくれるだけマシじゃないか。
>そんなのが課長職しよるんで、マジで鬱。
担当者が動きやすくするのが役目の管理職が
そんなことしてるってのは、つまり
他にちゃんと出来る奴がいないわけでしょ？
そりゃあ困ったね。

143 ：

なんか嫌なことでもあったんだろうな

144 ：

やっぱ、SEは免許制にするべきだよ。

145 ：

うちの会社のSEはDB設計とUIのプロトタイプ作って終わり
エクセルにUIの画像張りつけて設計書といってるだけなんだが
実装の仕方とかSQLとか諸々はPGに丸投げ
これって一般的なのか？

146 ：

一人で全部作ったほうが早いよ

147 ：

>>145
PGとしては
中途半端に実装方法書かれると
逆に足を引っ張られる

148 ：

>>145
>実装の仕方とかSQLとか諸々はPGに丸投げ
当たり前だろう。コーダーじゃあるまいし。

149 ：

NTT-DATA様は、エクセルの代わりにパワポ紙芝居を残して逝きました。
しかも実装不可能な未来技術を前提とした「設計(笑)」
22世紀の道具とか、ドラエモンを前提に設計すんな、と。
文系出身にSE,PGとか技術職を名乗らせるなよ。

150 ：

Googleでは偉い人ほどコーディングするという話

151 ：

要件定義も設計も実装もやる俺は、SEなのだろうか？PGなのだろうか？
名刺の肩書きはコンサルだが。

152 ：

俺も同じだが、名刺の肩書きは「○○部　開発リーダー」っていう
単なる係長相当の役職しか書いてない

153 ：

ずっとＰＧやって初めてＳＥやってわかったこと。
これは別職種だと思う。
SEに必要な力　＝　
・えらそうに見える力。下にえらそうにできるかんじ。ハッタリ力。
・要点まとめて話せる、まとめられる力。
・ユーザの視点に立った設計。
・PG以上の細かいミスのない設計書を書く能力
・複数の設計書のフォーマットを知ってるかどうか
・メールや書類整理が長けてる人
・人のせいにするのがうまい人
ＰＧに必要な力＝
・技術
・適当力（進捗をあげること第一。　最初から完璧にはくめませーん。ｋｓ設計が多い昨今、まじめにやってたら馬鹿みます）
・見切り力（ＳＥの設計書の行間を読んで、想像、提案。今ある中で今できる最大のものを
最短でFIXする力。全部に手をつけて全部進捗80とか言わない力）
・ＳＥさんを困らせない空気読める力。大人力。
（ここまちがってるんすけどぉ・・・　みたいな事は言わない。　こっそり間違いは指摘。）
いわゆるＳＥの仕事である業務全体の流れを知り、
どのようにしてシステムが動くかというのはＰＧもＳＥも常に意識しておくべきことで
ＰＧはコーダーだ。
SEはPGに一切思考させない、といったブってるＳＥもいるがそれは絶対に無理。無理。無理。
組むのＰＧで　メインはＰＧ。ＳＥが詳細すぎるプログラムのような詳細設計を書くような
設計させる会社は糞。

154 ：

むしろPGがプログラム作る時に詳細設計書くべき

155 ：

むしろ詳細設計書なんていらない。

156 ：

>>153
すべてPGがやればいい。というより通常する。
日本でいうシステムエンジニア(SE)は日本にしかいない。
プログラミングできないSEというものが不要。

157 ：

システムエンジニアなんだからシステムエンジニアリングには通じているのだろう。
ソフトウェアエンジニアリングに通じているかどうかは知らんが

158 ：

というか、結局「システムエンジニアリング」というのが正しく理解されてないのが
問題の根本なのかね。
少なくともなんか技術営業みたいのがSEを自称してるのは変だよねw
ちなみに（本来の意味の）SEって言葉は意外と歴史が古いみたいだね。
大村平って人が1971年に書いてる本に出てきてびっくりしたよ。

159 ：

海外だと「プログラマ」という呼び名は「コーダー」と一緒で蔑称なんだよな
大抵の求人にはソフトウェアエンジニア募集と書いてある
システムエンジニアはソフト会社では求人していない（ボーイングは求人してそう）

160 ：

>>155
詳細設計はいるよ。
ただ、最近あった糞な会社は
詳細設計にループカウンタがどう、とかそういうことも
書いてるやつがあった。
理由は詳細設計を見てすべてを理解するため、だそうだ。
後の面手のためだとか言ってたけど・・・実際メンテすんのはPGだしさ
ｐｇがこんな詳細設計見てメンテしたりするとおもうんかｗって話。
成果物として考えているみたいだが実際納品するのはソースだからさ。
ＳＥは上の人間に以下に自分の仕事ができたかをアピりたいだけのために
詳細設計書を活用していたりする
でも実際そんなことありえんからな。
詳細設計書見てプログラム組めなかったら意味がない

161 ：

カウンタ等はかいてるくせに
使用するクラス類などの網羅をしていない
ほしいことは
・前後の画面やクラスの繋がり
・このクラスが担う機能、どのように使われたいか
・publicのプロパティ、メソッド
・どの共通クラスを使っているか、引数、プロパティ、メソッド名
・どのtableを使っているか
・何がしたいか
特にどの共通クラスを使っているか、引数、プロパティ、メソッド名の羅列を
詳細設計を書くときに省く人がいる。
変更になった場合大変なのはよくわかるが、実際ＰＧが面倒なのはここ。
ここを先に調べて網羅してくれていることでほとんどのＰＧはサックサク組めていく。
ここを羅列しないで詳細設計の意味があるかと言いたい。
実際組むときに　共通クラスの詳細設計をあさり、　引数を確認し、　何を設定するかを
調べながら組んでいくのは詳細設計の意味がないよ。
で、何がしたいかさえ論理で書いてくれたら
それを一番美しいいい方法でPGが実現するから。
で、このような設計書を書こうと思えばプログラムしたことのない人にはつらいはず。
なので実際ＰＧ経験のある人じゃないとやって欲しくないんだよ

162 ：

そこまで詳細レベルなら、コードとJavaDoc相当でいい。
要するに、詳細設計なんてプログラマがやればいい。
ドキュメント書いてコードも書くなんて、只の二度手間。

163 ：

そこまで書いたらPGって本当にコーダーじゃねーか？

164 ：

>>162
そう思うのはお前さんがＳＥやったことないからだよ。
プログラマまかせにしてると
やばいことになる。
新人ｐもいるのでプログラムに入る前に詳細設計書はいるよ。
>>162
は浅いしシステムわかってないな。
途中から単価のやっすいやっすい新人PGを服数人入れるｐだってあるんだよ。
そういうとき、はい今日からおねがいします。　じゃあ組んでね。
ってすぐスムーズに行くはずないでしょ。
こういうプログラマがいるから、困るんだよ。
JavaDocは結果論だよ。成果物になりえない会社もあるし。
JavaDocでいいというなら詳細設計書自体いらない。　基本設計書と概要設計だけでよくなる。
上級ＰＧばかりでとりそろえられるほど今予算はないよ。

165 ：

新人を教育するのは、チームの仕事
負荷をSEに集中させたらパンクするだけ

166 ：

>>165
は？
教育？
やめようぜ。使い捨ての１，２年のPGをわざわざ教育なんかさせるわけないだろ。
将棋の駒だよ
システム全体を見れないプログラマは駄目だな
自分はこうならないようにしよう

167 ：

全体を考えれない人間は、技術力の底上げも考えないわな

168 ：

>>167
いまどきプログラマなんか正社員で雇わないからね。
採用するときに技術の底上げなんか考えてられないでしょ。
その技術持ってる奴と、使えそうな新人入れるだけ。

169 ：

>>168
同意
技術技術言ってる奴って結局小さいところしかわかってない。
SEはプログラム組めるべきだと考えるしＰＧのほうが大事だとは思うけど
>>162
こんな馬鹿がいるからやっぱり無理。

170 ：

>>164
俺は提案も要件定義も設計もコーディングも全部やるんだよ。
そのうえで、詳細設計書なんていらないって言ってるんだ。
新人をいきなり何人もプロジェクトに突っ込む時点で、間違ってるんだよ。
新人に任せてほったらかしじゃ、やばいことになるのは当たり前だ。
ちゃんと指導してやれ。書いたコードもレビューしてやれよ。
最初から何でも出来る奴なんて居ない。人材は育てるもんだ。
詳細設計書とやらを一生懸命書いて、それをコードに落とさせるだけじゃ、
いつまで経っても、そのPGは詳細設計なんて出来るようにならないよ。
だから、一緒に詳細設計をするんだよ。道具は裏紙とホワイトボードで十分だ。

171 ：

>>170
>そのうえで、詳細設計書なんていらないって言ってるんだ。
お前が一生面倒みるっていうならそれでも構わん。

172 ：

>>170
えーそんなんいらんわー
そんなちいさいシステム、やったからって何って話。
そんな人の意見は一般的な大きなプロジェクトには通用しないよ。
一人で小さいシステム作ってるのと
大規模なPJで働くのとはまた別の話。
ここでは大規模な話がメインでしょ。
＞新人をいきなり何人もプロジェクトに突っ込む時点で、間違ってるんだよ。
そうせざるをえん事情ってのがあるんだよ。
今は予算がきつい。
まぁここに関しては自分はPMとかそれ以上になったことはないんで
人材確保の部分から口だしできんのでね。
でも何度かあったのさそういうことは。
んでPGにまかせたらどえらいソースがもどってきましたとさ。
てことで、詳細設計書はいるとは思う

173 ：

>>172
大規模なものを大規模なまま開発しようとするから、そういうことになる。
そもそも、ウォーターフォールってのがどういうケースを念頭に置いて考案されたかを見直して見るべき。
あなたの考える大規模の殆どが、そのケースには当てはまらないと思う。
もし、あなたのプロジェクトがロケットを飛ばしているのなら、それはあなたの言うとおりだ。

174 ：

>>173
>大規模なものを大規模なまま開発しようとするから
意味が不明。
大規模なものを開発するから
各分担が必要で、きちんとした基本設計、概要設計、機能設計、詳細設計が必要。
一人ですべて担当していた人間が
大規模PJにやってきて自分勝手やられるのが一番困る。本当に困る
下手なプライドがある分使いにくい。年齢がいっていればなおのこと。
”分業”を理解できない。
ソースや設計は頭の中状態。
こんな人が「俺はできます」な風にいすわられると本当に苦労する。

175 ：

設計書も成果物である。
詳細設計書は新規でやってきたPGに「はい作って」と渡して
それだけで作れるようにできていなくてはいけない。
新規でやってきたPGが　今から　「はい！作ります」と作り始められる詳細設計所であれば
矛盾するが詳細な記述はいらない。
基本設計、概要設計とどう違うかというと、そこはやはり使っているクラスやテーブルの網羅につきる。
実際ＰＧ組むときに大変なのはそこだからね。
そういうものです。
かつ、成果物として見た目が整っていること。
詳細設計書は、後のメンテのために使われることはまず、ない。
それはPG組めない糞ＳＥの戯言。そこは無視していい。
javadcでいいとかｗｗｗ笑うからｗそれは。
後はやっぱ命名規約や、フォーマットの初期設定も大事だし、
フォーマットにのっとるあまり、ソレを見てもプログラム作れない詳細設計所にならないように
注意しなくてはいけない。これ新人ＳＥが陥るしょうもないミス。

176 ：

話が噛みあってないみたいね。
とりあえず俺は>>172の言ってることの方が正しいと思う。
っていうか、>>170は相手の話を理解してないねw
一方がエンジンを流れ作業で作るには作業員用の手順書が必要だって話をしてるのに、
もう片方は職人が名人芸で作るエンジンにそんなものいらねえって言ってる。

177 ：

まあ>>170みたいな気質の人が日本人は多いから
アポロ計画みたいな巨大プロジェクトって日本は難しいんだろうたぶん。
航空機産業が弱い理由もそのあたりにあるのかもしれん。

178 ：

それだけでプログラム組めるレベルの詳細設計書を書くくらいなら最初からプログラム書いた方が早くないか？
俺は設計者と実装者を分けるのは時間的にもコスト的にも効率悪いと思う。
まあ両方をこなせる人を確保するのが難しいってのは判るけど。

179 ：

>>177
航空機産業が弱いのは別の問題でしょ？
戦後の日本は航空機開発に対して戦勝国から制限かけられてたから弱い。

180 ：

結論
規模が問題の開発にはSEが必要。
新規性、難易度が問題の開発にはSEは不要。
人月で商売する仕事ではSEが必要。
製品で商売する仕事ではSEは不要。

181 ：

雇用創出のためにはSEは必要。
国際競争力向上のためにはSEは不要。
製造の現場ではSEは必要。
技術開発の現場ではSEは不要。

182 ：

ＳＥ／ＰＧで分けるくらいだったら実装者とテスタをきちっと分けたほうが
ずっと効率がいいだろ。

183 ：

テストは作った人間の責任、って文化はどうにかならんもんかね。

184 ：

動作が理解できないのでテストができないからとか？

185 ：

人月計算では、効率をよくしても意味が無いってのがね。
アメリカなんかは、ユーザ企業での内製が多いみたいだけど、
日本では雇用の流動性がないことがネックになるね。

186 ：

流し読みしかしてないけど
予算の関係（という理由）で使えない新人入れるなんて論外
納期に間に合わなくて、会社の信頼を落とすだけ
こんな事を平気で言う、営業や社長がいる会社とは取引しないわ

187 ：

新人はいらない

188 ：

馬鹿な会社はシステムエンジニアとセールスエンジニアの区別がつかないんだよな

189 ：

>>182
それがなかなか難しいよ。
だってテストする人っていうのは
絶対的にシステムを理解してなくちゃいけない。
単体テスト仕様書を
コーディング担当者以外にしてもらい、
また別の人にテストしてもらう、というのはある意味理想だよ。
でも実際無理だって・・・工数的にも倍時間かかってしまう
理想は設計者が単体テスト設計書を書くのがいいんだけど、
ここでＳＥがＰＧ経験豊富かどうかでばっくり分かれてしまう。
PG経験がないSEの書いた単体テスト設計書じゃテストが網羅できない。
結局PGが単体テスト設計書をかいて、テストするのが効率が一番よくなる。
しょうがないんだよね。。
ここをしょうがないで割り切らず、燃えて爛れたプロジェクトがあった。死んででいいと思う。

190 ：

>>189
単体テスト仕様書もまともに書けない奴がＳＥを名乗るのはどうかと思うが。
そんな奴の設計書なんかいったいどんなモンなんだ。御用聞きレベル？
ＳＥって職種があいまいだからスレタイの話になんじゃね？

191 ：

>>190
いや、もちろん書くことは書くでしょう。
普通にぱっとみできてるぽいのは。
ただしＰＧ側からするとこれ網羅できてんのか？という仕上がりも多い。
結局すべてのコード通そうと思うと
ＳＥの書いた単体テスト設計書じゃ難しかったりする。
バチー！っと設計の段階でキマるようなプロジェクトが少なすぎる。
いろいろなこと、開発の際のことまでフォローしてるスーパーSE（スーパーPGにもなりうる）が
少なすぎるため
結局実際くみ出した段階で誤差や仕様バグがでてきたりでｇｄｇｄ
これプログラマあるある。
実際組み始めたらＳＥ通しの連携ができてなくて
変なプライドとか人間関係でうまく機能してないことも。
結局全体を見通せる上級ＰＧが上に気を使いながら下に指示しながら
しかもあたりさわりなく、気を悪くさせないように立ち振る舞うってことになるんだよなぁ。

192 ：

設計書書いた本人（SE）がプログラム組めばいいのになと、思うことがありました。
そしたら、私の仕事が無くなる。。。ツライところです＾＾；

193 ：

独りでこなせる規模だとそれでもいいだろうけどね。もしくは、ホントに人月分のスケジュールで動けるとか。
# あくまで、目安ね。
# 人月を肯定するつもりはない。
でも、大抵の場合そんな事ないでしょ。

194 ：

いや、だからスレタイ通りの話になるとずっと言ってるわけだが。
そんな現状こうだからこれでいいの話は愚痴スレへ行けってとこじゃない？
＃肯定するつもりはないだの言うのは
＃オマエラ実務知らないだろ目線にしか見えないぞ

195 ：

>>194
＃

とかさ・・・
ふりぃよ・・・
じじぃばっかだな

196 ：

実装、単体テストまでがセットで、結合試験以降を実装者とは別のが試験するのは
意味が歩けど、単体試験から別の奴がやるなんて効率悪すぎだろ。

197 ：

単体試験の項目の洗い出しと実施は実装者がするけど、項目の
レビューはみんなで相互に行うっていう普通のやりかたがやっぱり
一番現実的なんだよ。
あとはしっかりとしたドキュメントに落とさなくてもいいんでモジュールの
I/Oを意識した古典的な視点でのモデリングをやっといてくれると、
他人が項目の妥当性を評価し易い。

198 ：

>>194
まぁ、設計しかしない(できない)ヤツが作った設計書なんて普通は役に立たないから、そんなヤツイラネってのは同意する。

199 ：

入社した時から自分の失敗やわがままな要求をすべて下請けに肩代わりしてもらい、
コードを書けば無限ループを起こし、それをバートナーと言う名の常駐奴隷に直させて育って来たSEが、
一人でまともにプロジェクトを管理、進められるはずもない。

200 ：

>>201
パレスチナ問題って深刻だね。

201 ：

今北だけど>>170みたいなアホに仕事させるために詳細設計書は必須だとおもた

202 ：

富士山の3776m地点ですが、グーグルアースや
ゼンリンの電子地図でいくら探しても見つかりません。
本当に富士山って3776mあるのでしょうか。
それとも実際は古いデータで、GPSなどの精密な測量では、
すでに風化や地殻変動などでどんどん低くなってたり
しているのでしょうか。
ちなみにゼンリン電子地図で探し当てたポイントで最高地点は3769mでした。

203 ：

プログラマーなら登って実測データとの突き合わせからでしょう

204 ：

>>202
ゼロメートルの原点は疑わないのか？温暖化で水位上がってるぞ。

205 ：

>>202
ttp://www15.ocn.ne.jp/~t-long/fuzisan/fuzizatu/fuzisannohyoukou.htm
GPS+水準測量で3775m、更に重力補正して3776mだそうだ。

206 ：

神はサイコロを振らないのさ。

207 ：

プロジェクトの規模によって違うんじゃないの？

208 ：

>>207
ここで自分の意見強く言ってる連中は、すでに何度もその考えで押し通してきてる連中。
いまさら柔軟に考えるなんて出来やしない。
こうやるしかないんだ、で思考停止。自分で物を考えない依存体質丸出し。
だから7000億も赤字出すんだよ。

209 ：

>>164
> 途中から単価のやっすいやっすい新人PGを服数人入れるｐだってあるんだよ。
SEが単価上げるために、わざわざドキュメント書きという仕事をつくってた時代もあったんだなぁ。

210 ：

※ただし、「日本だけ」

211 ：

海外のＳＥはもっと悲惨だよ。インド人がいるから。

212 ：

海外にはSEって言葉ないってばｗ

213 ：

ＳＥという言い方はしてないな。呼び方はＰｒｏｇｒａｍｍｅｒかＣｏｎｓｕｌｔａｎｔが一般的なのかね？
海外のＳＥの方が上流から下流まで網羅できてると思うね。日本みたいに上流しかできないよう
な奴はすぐにくびだ。日本のＳＥは甘いよ。

214 ：

おいｗ逆だよｗ
海外で働いたことも無いのに思い込みで勝手に書きすぎだよ
運用と開発をしっかり分けてデータベースエンジニア、ネットワークエンジニア、アプリケーションエンジニア、フロントエンジニア、
アーキテクター、プログラマ・・・などなどと分けてそれぞれが専門性を身に付けお互いの立場をリスペクトしている。
何でもやらせて専門性のない何でも屋に仕立て上げてシステムエンジニアと呼ぶのが日本のやりかた

215 ：

「海外」でひと括りにする奴の言うことなんざ信用できませーん

216 ：

従業員2000人、拠点数全国30の製薬会社があります。
全国の昨今の不況から生産体制を見直し、受注があってから原材料を調達し製造・納品するなど在庫削減とキャッシュフロー改善を
行うことになりました。
あなたはプログラマーです。まずなにをしますか？

217 ：

模範解答：「SEが仕様書書くまで2chで巡回」

218 ：

ていうか
>受注があってから原材料を調達し製造
いくらなんでも遅すぎだろうｗ
生産計画システムは必須だな。
>全国の昨今の不況から
そういや某社の自動倉庫化計画がポシャったなあ。

219 ：

>>216の続き
プログラマーのあなたは、そんなの遅すぎるといい、SEが仕様書を作ってから読んでくれと突き返しました。
困った製薬会社が付き合いのある仕入れ先に相談したところ、他社と比べて生産体制が遅れていることがわかりました。
また社内にヒアリングしたところ、納入先の病院では携帯電話が使えないため、ノートPCで在庫確認やタイムリーな情報提供が
できないとの不満が出ており、売上に悪影響を及ぼしていることがわかりました。
さて、プログラマーのあなたはどうしますか？

220 ：

バックレ

221 ：

続き
製薬会社は、いろいろ問題が顕在してそうなこと、IT屋さんに聞いてもいまいち解決策が出てこないことから、コンサルタントを参画させることにしました。
数ヵ月の調査・検討の後、業務フローの見直し、体制の再編、他社アライアンス方針などが決まりました。
ITシステムに間しては、コンサルタントからの紹介されたSEに依頼しました。
方針に基づき、生産管理、財務、人事、資産管理はドイツの会社が作ったパッケージ、営業支援や拠点系はセールスフォーなんとかを使い、
社内ネットワーク、回線、サーバ、社員用PC等のインフラも再構成を行います。
さて、プログラマーはなにをしますか？

222 ：

>>219
>携帯電話が使えないため
携帯がないのならPHSハンディターミナルを食べればいいじゃない

223 ：

アーキテクトにまかせる

224 ：

そんな製薬会社が社内ＳＥがいないのにプログラマだけ飼ってるわけないだろ。
社内のプログラマがいたらソイツをＳＥと称してなんもかんもやらせるか
まるっかた外に投げて責任だけはソイツにおっかぶせるか。
前提がおかしい話をぐだぐだ書くな馬鹿。

225 ：

>>221の続き
そのSE曰く、ドイツの会社が作ったパッケージの製薬向けノウハウがあり、
テンプレートの採用とカスタマイズで実現できるそうで、
コーディングはしないとのことでした。
また、営業支援系は要件をしっかり固めて設計すれば、海外でプログラム開発を
するとのこと。セールスなんとかとの相性も良く、早く安くできるとのこと。
中国人やインド人に重要なプログラムを作らせるのは心配でしたが、
ここ数年で海外アウトソースのノウハウが蓄積されており、コミュニケーションやスキル等も問題ないそうです。
インフラ系はSEの会社で一括して引き受け、グランドデザインから現地導入、
5年間の保守体制まできっちりそろえてくれました。
その結果、なんとか予定通り無事稼働させることができました。当初はトラブルもありましたが、
なんとか方針通り動いているそうです。
予算の都合上、初年度は部分導入でしたが、新たな経営課題も出てきたので、次年度以降もコンサルや
ＳＥと共に最適化を断行してゆく方針とのことです。
さて、プログラマーはなにをしますか？

226 ：

新薬試験のモルモットになる

227 ：

SEがやってる仕事をそっくりそのままプログラマにやらせればいい。
SEの仕事ができないプログラマはプログラマ失格なのだから。
ちなみにプログラマの仕事ができないSEもSE失格。

228 ：

三食昼寝つきの高給バイトだもんな。＜治験

229 ：

>>225
かなりの部分を外注に出してるね。
すごく日本的な考え方に基づいた進め方してるけど
そのやり方でうまくいくためにはそのプロジェクト管理する側に
プログラミングできる人がいないとうまく進んでいかないだろうね。
外に投げるにしても技術もってないと主導権失うからね。
レビューも出来ないんじゃアホなしステム押し付けられて終わってしまうので
結局設計できてプログラミングできる人はいるんだよ。

230 ：

>>212
システムエンジニアリングって言葉は
機械、ソフトを含んでいるモノをトータル設計してる人たちの
仕事に当てはまる言葉だからただのコンピュータ屋さんには
使わないだろうね。

231 ：

>>229
これのどの辺にプログラミングスキルがいるんだ？

232 ：

>>231
逆に聞きたいが、ここまでまるっきり外注使う場合
システムの内部のことまでよく理解できる人間を抱えていないと
どうやってレビューするんだ？まさか相手の言うこと丸のみかい？
成果物のまっとうな評価ができなきゃ外注先はこんなもんかと
手を抜くよ。システムの出来と客の賢さには相関がある。
スキルという意味ではいらないが、システムの設計上どこか
不具合が生じる可能性があるところは前もって確認したりしないか？
そういうのって実際に開発経験ある人でないとわからんと思うけどね。
コンサルや元請のＳＥがアホに丸投げしたら、カオスになるのは
目に見えてるので自分側にわかってる人がいないと危険だと思うけどね。

233 ：

今外資系で働いてるけど、
研究・実装・企画・デザイン・設置・保守
全部やってるぞ。良い感じになってきたら、参加者が増えてプロジェクトが巨大化するが
基本全部自分でやる。
まぁ、楽しいからいいけど・・・
この辺は、業種の問題だろうね。

234 ：

Googleとかそんな感じのイメージがある。
研究者がソフトウェア書いてる外資系企業ってそんな感じだね。
正直羨ましい・・・

235 ：

徹夜でコードを書く女王がいる会社だしな

236 ：

>>233
>良い感じになってきたら
「企画→良い感じ」の間の日程とかってどうなってるのかね。
日本の企業の感覚だと、企画段階でケツが決まってしまって、
良い感じになろうがなるまいが、納期いないに完成させろ、
って感じになっちゃうし、上司というのはダメと言うことはあっても、
「良い感じ」なんてことは言わないし、部下とそういう「感じ」を
共有するつもりなんてハナからないような人ばかりだが。

237 ：

プログラムができないのに設計されるとね、
男塾名物の一直線に突き進めのアレみたいなことになる。
とにかくやることは決まってるけど、それがそもそも実現不可能だったり、
既存の実績ある物件やノウハウが一切使えず高コストだったり。
そうならないよう、早い段階早い段階から、
実現可能で楽な道のりで進めるような仕様調整をするべき、
なのにねぇ。

とりあえず、月曜からまた人力で富士山を切り崩すような仕事に戻る。

238 ：

システム全体の構成要素を考えたら、プログラムスキルが要求されるところなんぞ
大した割合じゃないでしょ。
例えば「全社グループウェアシステム導入」なんてコーディングいらんぞ。
プログラマーはプログラムが万能だと思ってるフシがあって、顧客の業務やプロセスを
軽視する傾向がある。

239 ：

>>238
>例えば「全社グループウェアシステム導入」なんてコーディングいらんぞ。
日本のSIerが抱える案件の多くはそれとは真逆、っていう前提がすでにある。
むしろそうやってパッケージを活用してくれる
(もちろん、パッケージが活用できるよう既存業務フローも変えてくれること前提)なら
ありがたくてありがたくて、涙が出るほどありがたいことだよ。

240 ：

>>239
ああ、たしかにそうだな。
スクラッチ開発至上主義は確かにあるな・・・
それでも、例えば「拠点サーバリプレース」「ネットワーク再構築」「運用管理システム構築」
「IPセントレックス」「ディスアスタリカバリシステム構築」とか・・・・
プログラマいらないシステム案件はたくさんある

241 ：

>>240
俺の経験上、だが
サーバのリプレースとかネットワーク再構築とかは
たいていその機会に
(契機であるEOSLなどの要素を乗り切るために最低限となること以外に)
余計なことをバンバンやろうとしてシステム全体が悲惨な状況になる。
その「余計なこと」にはプログラマが必要になる要素が多大に含まれることが多い。

242 ：

>>238
>プログラマーはプログラムが万能だと思ってるフシがあって、顧客の業務やプロセスを
それって、プログラムできない奴の信仰のような気がする。
じっさい経験を積んだプログラマーほど、「最善の方法はプログラムなんて作らないこと」と、
思ってるよ。
プログラムさえ作らなきゃ、バグもでないし、メンテコストもかからないし、
ベストの解決法だもん。
まともな経験のあるプログラマがなんでもかんでもプログラムで開発しようとするのは、
そうせざるを得ない状況に追い込まれてるからだよ。
（もちろん、なかには、いわれたことを右から左にコーディングするだけのやつもいるけど）
プログラム無しで済ます案を難癖つけて潰して、そういう状況に追い込むような上司が
納期やなにやらで顧客から苦情が上がってきたときに初めて言い出すんだからふざけるなと言いたくなる。
結局、言うこと聞いてると、最初こっちが出した代案そのまんま。
なんでこっちの代案を最初に蹴ったかというと、
そもそも、こっちの言ってることが何を意味しているのか理解できずに、
理解できない代案を出されたことに腹をたてただけ。
まあ、しいて言うなら、「開発しない代案」が本当に問題解決になるんだ、
ってことをプレゼンする能力に欠けてる奴は多いかもしれない。
だから、上のような上司とも齟齬も起きちゃうという面もあるんだろうけど。

243 ：

まぁ、プログラマは基本的に
「めんどくさがるやつ」ほど、いい方向に向かうからな・・・。
やる気を出せば出すほど、どつぼにはまるのが嫌なお話だ。

244 ：

>>238
＞プログラマーはプログラムが万能だと思ってるフシがあって
逆だろ
ITのことを何も知らない客のほうが、プログラムは万能だと思ってるよ
プログラムを組めばどんな無理難題も解決できると盲目的に信じ込んでる

245 ：

めんどくさがる奴のが良い方向に向かうのはいいけど
めんどくさがる奴は勉強もしない奴が多いのでどっちもどっち

246 ：

違うよ、「楽をするためにはどんな苦労も厭わない」これが正しいプログラマ。
単なるものぐさとは違う。

247 ：

矛盾だな
だが納得

248 ：

>>247
よく勘違いされる人がいるが、矛盾はしていない。
どれくらいまで先を見通せるか、の域を伸ばしながら
楽ができるように先を見越して行動できるようになっていく、というのは
「先行投資」や「リスクマネジメント」と本質的に変わらない。

249 ：

直感的に「これは面倒なことになりそうだ」って思ったことを
「どうすれば単純化できるか」という視点で再編すると、だいたいうまくいくよ。
「複雑だ」とか「めんどそうだ」って直感は、大体あたってて、死亡フラグ。
まぁ、直感って言ったけど、ようはこれ
ゴールまでの見通しが立てれるかどうか。という問題なんだよね。

250 ：

それ以前に自分の考えを説明するのをめんどくさがる奴が多い。
説明と称してまくしたてたあげく
「こんなこともわかんねぇのかよ、ふっ」
みたいな態度されちゃ、そりゃＳＥとやらを間におきたくもなるわな。

251 ：

説明を俺がはしょり始めたのって、俺の場合トラウマからなんだよな・・・。
昔、ある上司の下で働いてたとき・・・
長ったらしく細かく説明してたら、最後まで聞かずに誤解をしてお怒りになる事が多かった。
それ以前に最後まで聞かずに、別の話題に入ることも・・・。
で、なんか自分の中で
・まず結論を言う。
・1要素の説明は長くても10秒以内。
・多少嘘でもいいから、素人でもわかった気にさせる。
って感じの説明に自動的になるようになって・・・
いつの間にか中身がない説明ばっかするようになった。

252 ：

問題は、そのSEが顧客よりも技術的知識が無い場合だよ。
そのための SE なのに技術者の説明がわからんといって逆切れする。
「じゃあお前の仕事はなんなんだよ」といいたくなる。

253 ：

俺も何となく口頭説明は10秒以上しちゃだめな気がしてハラハラしてる。
20秒くらいしゃべったときは、周りの視線が痛い…orz

254 ：

>>253
ありすぎて困るｗｗｗｗｗ
それでいつもわからんって言われるんだけど、何なんだろうなｗ
そんなに長く話してるわけじゃないのに極端に短く話そうとして破綻してるｗ

255 ：

すぐ怒る上司は、他の人の説明をどうしてるか観察してみそ。
誰の説明でも怒ってるなら、それは単に、怒るために怒ってるだけかもよ。
その場合の理由としては、
１．本当に分からないので怒っている
２．とりあえず怒っておかないと上司としての威厳が保てないと思ってる
という事が考えられる。
そういうときは、面倒だから、お客さんと直にネゴして、問題ないようなら、
上司には適当なこと言って進めちゃうほうが、能率の面からも、
精神衛生上（その上司も含め）も、いいと思う。

256 ：

>>255
上司通さなかった場合、何か問題起きたときの責任が・・・

257 ：

>>256
そのあたりは微妙な問題だけど、100% その考え方で行くと、
にっちもさっちもいかなくなることってけっこうあるっしょ。
その「何か問題」のレベルと内容によるんじゃない？
問題がおきても自分で対処できるレベルの問題のケツを持ってもらうために、
理解するつもりのない上司に説明続けるのって、あなたにとっても、
プロジェクト全体にとっても（ひいてはその上司にとっても）
何の利益にもならないじゃん。
入社したての新入社員ならともかく、何年かやってれば、多少の問題は自分で対処できるだけの、
能力（技術力だけじゃなくて、顧客のキーパーソン（単に役職が上というだけじゃなくて、
システム部門の「真の」実力者とか、ユーザ部門のベテランとか）とコネを作ったりする）
が、ついてきてるはずでしょ？
そういう能力がまったくなくて、顧客との交渉は全部上司任せだとしたら、
確かに、その上司のいいなりになるしかないね。

258 ：

いい意見がたくさん出てるが、その仕事をしてるってことはもうプログラマーじゃなくSEだよ
というのが多いな。
なぜそこまでプログラマーにこだわる？

259 ：

寧ろ、なぜそこまで分類に拘る？

260 ：

>その仕事をしてるってことはもうプログラマーじゃなくSEだよ
まあ、それだけ SEって職種が独立して存在する意義が薄いってことなんだろう。

261 ：

わかった。人によりSEの定義が違うから、こんな話になるんだよ。
昔から言われてたが、結局同じことだな。

262 ：

とりあえず、可能な限り物事をプログラムで解決しようとするのがプログラマだって思った。
すべての物がプログラマブルになれば、きっとそこはマの楽園になる。

263 ：

人件費を増やせない事情は変わんないので
同じ予算で、仕事だけが増える＝デスマ化する

264 ：

>>249
同意。複雑な要求を複雑なままコードに落とすバカは新でくれ。
>>261
SE = プログラマ。世界の常識。分けんじゃねぇよ。

265 ：

>>264
スレタイ・・・

266 ：

この業界プライド高くて凝り固まった人が多そうなイメージだ

267 ：

今更ながら、良いスレタイだ。

268 ：

>>266
素人から見た専門家のイメージなんて押しなべてそういうものでしょ。

269 ：

素人と言うより、団塊世代の高卒DQN管理職が言いそうだな。

270 ：

大卒でも自分の専門分野外はそんなもんだよ。
文系理系って大騒ぎするのは大多数大卒でしょう。

271 ：

SEにプログラミングスキルはあればベターだけど必須じゃないだろ。
情報処理試験もソフ開を名称変更。PMBOKもPMに言語経験に依存しない体系だし、
ITILも同様。
時代は変わってんだよ。

272 ：

んなこたぁない。
少なくとも並以上にデキる言語が一つは必要だと俺は思う。
プログラミングスキル無しでどうやって見積ったり、設計したりすんだよ?
根拠なしか?

273 ：

前のアレは3人で1ヶ月かかったから・・・これも同じぐらいだな(ｷﾘｯ)

274 ：

つうか、全然知らなかったら、プログラマになめられるだろ。
どうやってマネジメントするんだ。それは別の人に頼むのか？

275 ：

大工仕事のできない大工の棟梁はいないと思うんだけどなぁ…
人の上に立ちたいなら人以上のスキルがあるべきだと思うよ。

276 ：

>>273
規模ちいせえなぁ。
上から下まで全部一人でやれ。

277 ：

>>274
その理論で言ったら、自動車会社の社長は
自動車工を経験しないとなれないなｗ

278 ：

当たり前。
トヨタもホンダも、創業者は現場を知ってた。
だからここまで繁栄があったわけで・・・

279 ：

トヨタは豊田家３代目までは工学博士
他社で現場経験もやってから取締役として入社。
４代目が経済学修士

280 ：

>>277
つうかまあ、大企業なら、実際に現場の技術者のマネジメントは、
社長とは別の人に頼んでて、
社長はマネジメントする人のマネジメントをするのが仕事だな。
で、>>274 　は、そういう大企業の社長と現場の技術者の間にあるような、
巨大な組織と何人ものマネジメントのプロを間に介さないと、
マネジメントできないんですか？　っていう皮肉なんだが。

281 ：

>>274
え？
プロジェクトやっていた奴らに任せるだけだよ
見守っていればマネジメントになるんだよ

282 ：

>>281
「プロジェクトやっていた奴ら」って、お前の仕事は何なの？
というか、誰がどういう理由でお前に給料払うの？

283 ：

先月は稼働時間が多かったから減らせとか、少なかったから増やせとか位しか
いわないPMとかしかいないからな。 具体的指示が出来なかったりするのが
結構いるわけで、見てるだけと変わらんよな。

284 ：

なんか話が変わってきてね？
「こういう奴いるよね」って話だっけ？

285 ：

まじめに話しているのかも不明

286 ：

俺は今風のSEなんです、偉いんです、
偉い俺が言うんだから、プログラマは
俺の言うとおりにプログラムを作るべきなんです。
俺が予定を出したら、ほうっておいても予定通りに
いわれたとおりのものを完成させるべきなんです。
プログラマは俺にわかるように説明するべきなんです。
俺は偉いSEだから勉強なんて全然する必要がないんです、」
偉いんですから。
客も俺が説明したら納得するべきなんです、
俺の知らないことを質問したりしたらだめなんです。
偉い俺の困るようなことを質問してはいけないんです。
なんといっても俺はSEなんだから、
SE である俺をみんなが大事にして、尊敬して、言うとおりにするべきなんです、
というかわざわざ言わなくても察して動くべきなんです。
偉いSEの俺が何か言わなきゃ生らないなんておかしいんです。
それでシステムが完成したら、それは偉いSEである俺のおかげなんです、
プログラマとか客とか、みんなバカで取るに足りない連中なんだから。

287 ：

>>286
そりゃSEとプログラマ、プログラムと仕様書を置換しても良さそうだな。

288 ：

つまり、SEはプロジェクトがうまくいかないとき、
プログラマがバグが出たときに、パソコンに悪態をつくのと
同じように、プログラマや顧客に悪態をつくもんだと
あなたは思ってるわけですな。

289 ：

プラントエンジニアは配管や電気装置そのものを作る経験はいらない
レコーディングエンジニアは作曲や演奏そのものの経験はいらない
システムエンジニアは・・・・
そういうことだ
プログラマ君たちはなにか勘違いしている

290 ：

で、プラントエンジニアやレコーディングエンジニアに匹敵する「スキル」は持ってるの？
プログラムしないSEさんは。
まあこの案件激減でプログラムしないSEもずいぶん駆逐・淘汰されたけどな

291 ：

PGは現場で働いて設計図見ながら家を作る大工さん
SEはお客さんから話きいて家の設計図を書く建築士さん
って感じですかね
大工はノコギリやカンナなんかで熟練者と初心者では全く別物だろうし
建築士も強度たりないくそ設計図やごちゃごちゃした設計図を書く人としっかりした建築士がいる
両方の存在意義はあってどっちが上とかはないと思うんだ
問題は年数でSEを名乗ったり、初心者=PGのような誤った認識があるからではないかと思う。
SEを弁護士のように資格制度にし、PGをランク制度にする。
そうすりゃでたらめなSEはいなくなるし、PG=開発者は薄まらずに技術の高さを維持できる。

292 ：

俺も免許制に賛成だね
情報処理試験の制度が確立してるんだから、
あとはこれをベースに資格から免許に格上げすればいい

293 ：

そんなことになれば真っ先に淘汰されそうな奴に限ってそういうことを言うのなw

294 ：

淘汰されそうな奴が言っても淘汰されるだけだから問題ないんじゃない？
それとも淘汰されそうな奴を気遣ってるのかね

295 ：

>>293
まあお前みたいなアマチュアには都合の悪い制度だよね

296 ：

卑屈な奴ばっかりだな
プログラマーってこんなもんか

297 ：

>>296
人を見下して優位に立とうとしてる奴しかいないこの板で得るものはないねｗ

298 ：

>>291
>PGは現場で働いて設計図見ながら家を作る大工さん
家の設計図からならどの大工でも殆ど同じ家が出来るが
プログラムの設計書からだとプログラマ毎に間取りも違うし耐震強度も違う。

299 ：

>>291
どこぞのサイトでは
コーディング作業 <- 建築士の仕事
ビルド作業 <- 大工の仕事
ってたとえてた。
こうなると、SEはどこにあてはまるんだろう？

300 ：

営業じゃね？

301 ：

>>297
必死さから、SE＞プログラマーだというのはよくわかった

302 ：

>>298
新人さんに宮大工と同じことをしろというのは無理でしょ
新人PGにセキュリティを期待するのも無理
そういう意味では似てると思うよ
しかしシステム業の設計書は軽視されすぎな気がする
ビル建てました。設計図ありません。とか言ったら何ふざけてんの？ってならん？(笑)

303 ：

客は動かすシステムとマニュアルにのみ金を出す。
設計書には金を出さない。
マニュアルと設計書を統合することができないもんかな。

304 ：

>>302
ビルの場合は建った奴を見てからやっぱ三〇階建てにしてくれとか
地下あと三階増やしてくれとかまず言わないからだろな。

305 ：

まあ大工だけじゃ複合施設は作れんわな・・・

306 ：

>>304
それを実際のビルでやって崩れたビルが隣の国にありましたな。
日本の建築業界では姉歯が似たような事をやってタイーホされた。
ソフト業界には姉歯以上のことをやるＳＥが大量にいるがタイーホされた話は聞かぬ。
おかしな業界ですよ。w

307 ：

建築士向こうは法の下の資格だから
やはり免許制にせねば

308 ：

>>302
ソースコードが設計図に相当するものでございます。 >>299の言うようにね。

309 ：

プログラマは設計図(=コード)を書いているっていう自覚がなさすぎ。
自覚ないヤツは、読みにくいコードを書いて平気なんだよ。

310 ：

>>299
コーディング作業 <- 大工の仕事＋建築士の仕事
開発環境 <- 各種自動化大工道具
ビルド作業 <- 雨降って地固まる or 接着剤の乾燥

311 ：

最近、ソースコードが設計書だって主張する奴が増えてきたなｗ
誰が言ってたんだっけ。ほらあの有名人。
まあとにかく、面倒だからわざわざ用語の定義をしなおさなくていいよｗ

312 ：

設計図とはあくまでも論理的作業であるべきだろ。
設計図＝仕様書＝論理的作業の成果
建築物＝ソースコード＝物理的作業の成果

まあ、「ソースコード＝事実上の仕様書」になってるダメプロジェクトばかりだけどなorz
それは悪い例だからｗ

313 ：

>>311
> 最近、ソースコードが設計書だって主張
ちょっとニュアンスがちがう。
コーディングは設計作業。という主張。

314 ：

>>312
> 設計図とはあくまでも論理的作業であるべきだろ。
yes.
でも、ソースコードもまだまだ物理には遠い。
ビルド設計をしてビルドして、吐き出されたバイナリがようやく動く物理的な物。
なので、ビルドのみが、大工仕事＝物理的作業。
そして、ソフトウェアの世界ではビルド(大工仕事)は全て機械まかせ。

> まあ、「ソースコード＝事実上の仕様書」になってるダメプロジェクトばかりだけどなorz
> それは悪い例だからｗ
ワルくない。仕様書とコードは補完し合う関係。

315 ：

ソースコード←→設計書（UML等）変換が１００％なら同意。
できれば設計書は「ソースコードのパースペクティブの１面」
と言えるところまで一意性を突き詰めたいよね。
建築物など作り捨ての製造物は、設計→→→製造の一方通行でも
毎回同じコスト掛けてゼロから設計して作ればいいんだけど、
ソフトウェアでそれやると、積極的に再利用性を高めて作ってるところと、
圧倒的にコスト差付けられて、終わるだけだもんな。
ま、理屈だけ分かってる会社はあるけど、
結局UML→→→ソースコードの一方通行で意味無し
みたいなとこばっか…

316 ：

設計書は、作ろうとするもの、出来上がったものの目的を明確に仕様化するもの。
ソースコードは、目的通りに処理するための手順を記しているに過ぎない。
手順が書かれているだけの物からその目的に到達するには、
手順全体を解析して想像するしかなく、
参照する度にそれだけの作業が発生する分効率が悪い上、
解析者ごとに定義が生まれ不明瞭になる。

317 ：

根底にあるのは、コーディングできるやつは偉いやつという考えだろ。
確かに偉いよ。すばらしい職人魂。プライドを持つことはいいことだ。
Google日本語入力なんて「ソースが設計書」の論理で作られてるし。
でもここで騒いでるのは、スキルもやる気もなく、SEを目の敵にしてアイデンティティを
保ってる底辺君だけだから、根本的に異なる。

318 ：

仕様書=機能単位
コード=オブジェクト単位
どうやったらうまいこと書き表せるでしょうか…
コードを機能単位にすると再利用できないし、仕様書をオブジェクト単位で書ける？
┐('〜`;)┌

319 ：

要件を定義する仕様書（自然言語で記述）と、コードを書くための設計書の二通り作るんだ。

320 ：

機能設計なんて偉そうな名前が付いてても、実体はお客視点からの機能を根拠とした縦割りでしかなかったりなｗ
そんな仕事で銭沢山取れるんだから、ＳＥなんてボッタクリ商売もいいとこだな。
ＳＥなら業務仕様を分析して、キッチリ中の中まで機能定義しろってんだよ。
そしたら機能単位＝オブジェクト単位＝設計書単位＝コード単位
全部揃うだろ。

321 ：

お客と話ができるようになってから言え、ってつっこみそうだがねｗ
それはそうと、機能をオブジェクトにするのってプログラマじゃないのか？
それが仕事だとてっきり。
コード単位にまで落としてもらうんじゃコーダじゃね？

322 ：

ここまで読んだけど、プログラマは
・文句jばかり言って改善策を提案しない
・お客と会話ができない
・変なプライドを持っている
・部下がいない底辺職種
・SEを見下してるが、現実ではヒイコラ従っている
でおｋ？

323 ：

>>320
何を言ってるのか、いまいち解らん。
質問
オブジェクト間のIF、
機能間のIF、
他システムとのIF、
ネットワーク、
ハードウェア構成、
ソフトウェア構成、
なんかは、誰が設計してどこに書くの？

324 ：

>>322
あれ？俺もここまで読んだけど、このスレタイに引かれてやって来るのは、
SE呼ばわりされる事に不満を持ってて、組織制度や営業(人売り)方法を何とか変えたい人たち。
に見えてたが？
まあ、中には「お前program出来ないからSEね。」なんて事言われて
チームに押し込まれてくる残念な人もいるけどね。

325 ：

>>321
ＳＥの仕事だろ。
でなきゃ、だれが機能を知ってるんだ？
ＳＥは聞いた話を書面にまとめるだけの代筆業か？

なんか日本のＳＥ業界がダメと言われる本質が見えてきた気がする。

326 ：

いまどきコーダーを飼ってる悠長なソフト屋があるのか。
ある意味うらやましいぜ。

327 ：

まあ、誰が業務分析やるべきかとかこの際どうでもいいけど、少なくとも誰かやってくれよｗ
業務音痴なプログラマーに丸投げしようって発想もアレだが、まあそれでもいい。
理に適った分析がなされているかどうか、誰かが責任もって判断してるならば。
現状はと言うと、誰もやろうとしないし、やって評価される仕組みもないし、
だから分析されないまま起こされた設計書から、機械的に作られるダラダラコードの製品を、
毎回ゼロから作ってるのが現状だよね。
全てが作り捨て再利用不可能で高コストな上、メンテナンス費用も増大。
ちゃんと分析して再利用性を高めようとしてる海外と差が付くのは当然。

328 ：

立場や主張が明確じゃないから、こうやって議論が発散するんだろうな。
スレタイからは、
スキルもないくせに偉そうに丸投げして高い給料貰ってて、
実質プログラマーだけでやってるんだからSEなんてあらない。
プログラマー最高！
に見えるんだが。

329 ：

とくいげだな

330 ：

お客の要件を機能単位にまとめるのを御用聞きだとか文書屋とかいう
自称ブログラマがいるうちはＳＥの下がコーダという体制は必要かもね。
経済的理由で先に切るのはコーダのほうで、ＳＥがプログラマの役もするんだろうけど。

331 ：

実装したことない奴もいるだろ

332 ：

>まあ、中には「お前program出来ないからSEね。」なんて事言われて
>チームに押し込まれてくる残念な人もいるけどね。
SEって、そんな奴しか見ないけどな。
酷いのになると、キーボードアレルギーの老害がSE名乗ってる。
実装?はぁ? キーボード恐怖症なんだぜw

333 ：

あるある
小学生の頃デブの奴にゴールキーパーやらせてたのと何も変わってない

334 ：

「おまえ銃使えないから士官な」ｗ

335 ：

>>332
> >まあ、中には「お前program出来ないからSEね。」なんて事言われて
そうそう。
更にそれでも務まらないと、
「お前、何にも出来ないからproject管理者ね。」となる。
実際には 「管理に向いているから。」などと嘘つかれて回されて来る訳だが。本人は真に受けてるから始末が悪い。
さっさとクビにするのが最も効率的なんだが。

336 ：

>>334
士官ではなく、衛生兵となりたいですね。

337 ：

じゃ俺、楽隊でペット吹くわ。

338 ：

俺は国旗を振ってみんなを戦場に送り出すよ

生きて帰ってこいよ！

339 ：

ああわかった、みんなスレタイを真に受けてるんじゃなく、
愚痴りたいだけなんだね・・・

340 ：

マ板は愚痴と下ネタと憂さ晴らしで成り立っているのです。

341 ：

SEなくしてみんなプログラマーになるってことなのか

342 ：

アメリカでは普通のこと

343 ：

自分で客先に出向いて
自分で無理難題聞いて
自分で仕様作って
自分でコード書くんだぜ
俺は面倒だから最後の1つだけやる仕事の方がいいわ

344 ：

あんまりにもうんちなSEがいるから困ったねぇ┐('〜`;)┌
って皆愚痴るの

345 ：

エセSEはなくしてプログラマーだけで理想の開発体制を！
そうすれば、JALの発券システムはトラブらないし、銀行合併に伴うシステム統合も問題なくなるし、
東証システムも止まらないし。

346 ：

>>345
誤解すんなよ。
projectをこなすには、
*seが要らない だけで、
*プログラマ の他に、
*開発側のマネージャ
*商品戦略側のマネージャ
は必須。そして、
*品質保証的な腐れドキュメントを専門で書く担当
が要るぞ。

347 ：

アメリカにSEがいないのは、アメリカのプログラマーが優れているから。

348 ：

>>346
そうなんだ。
じゃあハード選定とかネットワーク、運用設計はだれがやるの？

349 ：

スミマセンエンジニアは必要だな。
俺が直接行くと客と喧嘩になるかも知れん。

350 ：

>>348
ハード選定もネットワーク設計も
マネージヤとプログラマが一緒になってやる。
+++hardやnetのスキルも無くてマネジメントやプログラムが出来るのかよ。って話しだ。
運用設計は更に商品戦略マネージヤも含めてやる。
昔のひとに解りやすく言うと、seがやってた仕事を皆で分担した感じだと思えば良いよ。

351 ：

>>350
商品戦略マネージャって、自社製品開発じゃない場合もいるの？
あと、例えば銀行合併の場合、勘定系統合でシステム以外の業務フローの整備も
併せて依頼されたらどうするの？
あと、コーディングなしシステムの場合はプログラマーはなにするの？

352 ：

「マネージヤ」だらけだなｗ
超不自然

353 ：

>>351
>>346,350 の言ってる商品戦略マネージャってのはたぶん顧客側チームの人
じゃないかな。作って欲しい物を決めるのに責任を持つ人。
それに対して、開発側のマネージャは物の提供に責任を持つ人だと。
業務フローの整備はきっと銀行側チームの商品戦略マネージャが
各部門から人を集めてプロジェクトチームを作って決めるのが理想じゃない？
つまり、顧客側の仕事かと。
コーディングなしシステムの場合はプログラマーはコーディングしないだけで
ほかの事をやると思う。コーディングしかできない人は洋ナシだな。

354 ：

>>353
作る時だけプロジェクトチーム作っても、運用はどうするんだ

355 ：

ここまでがバクテリアの鞭毛運動によって発生する静電気を
変換して言語化したサンプルである。
と言われても信じてしまうくらい、共感も理解もない。
これが底辺というものか。

356 ：

>>354
プロジェクトチームは解散（派遣は解雇）だけど、プロジェクトチームが所属した部署はなくなるわけじゃないから。

357 ：

>>356
となると該当部署の正社員プログラマーが運用するの？
次期システム構想とか、定常的にシステムを担当するのはどんな職種の人？
あと、インフラとか全社にまたがるシステムを企画・開発・運用するのもプログラマー？

358 ：

>>357
多分、運用専門の安いオペレータを雇うのでは？

359 ：

>>358
情報システム部の正社員はみんな安いオペレータなの？
オペレータが次期システムの企画・開発もするの？
上場企業だと社員数50人に一人ぐらいの割合で情報システム部員がいるみたいだけど、
みんなプログラマーかオペレータなの？

360 ：

>>359
あなたは最近仕事がないといわれてる、金融系汎用機SEですか？
残念です。

361 ：

金融の汎用機なんて、若い世代が全く育っていないからそれなりに食っていけるだろ。
それより、ITバブル入社の製造系SEがヤバイ。

362 ：

>>359
ユーザー企業側の情報システム部は、
2割が厚遇＆激務プロパー、残り8割はどっかからの外注とかそんな状況。

363 ：

例えば森永乳業の情報システム部は正社員44人
外注19人だけど、どの辺が2割なの？
例えばウォルマートはアウトソーシングせず内製を徹底しているみたいだけど、
みんなプログラマーかオペレータなの？

364 ：

質問調で書いてるけど本当に知りたいんじゃなくて
揚げ足取りだよねソレ。楽しいならなら別にいいけど
揚げ足を取ったうえでどういう結論にもっていきたいの

365 ：

質問調のヤツは日頃叱られてばかりのダメSEで、そのくせプログラマーを見下していそう。
ただの論破好きかもしれんが。

366 ：

？の人はSEって(たぶん自分の)職種を正当化したくて、環境の変化を認めたくない。地位を守りたい。って人。そうold-type。

367 ：

おっさん･･･

368 ：

だよな。
大卒＝SE
専門卒・高卒＝PG
って決まってるらしいしな。
その決まりを知らなかったから大卒SEからリンチされまくった。

369 ：

プログラマー＝工場のライン工ｗ

370 ：

>>363
おまえの人生有意義そうだなｗ

371 ：

Google:
「ウチにはSEなんて居ません。ウチが欲しいのはプログラマ(宮廷博士卒)www」

372 ：

SEって役に立っているとこ見たことないのだが

373 ：

見えないところで役に立っていたりするものです

374 ：

だれか>>363答えてあげたら？

375 ：

オマエモナー

376 ：

>>371
宮廷よりNAISTの方が日本人の場合比率高くね？

377 ：

Googleは、プログラマも出来る研究者だろ。
研究者がプログラミングしてる所。
SEとかPGとかいうお話ではない。

378 ：

その区別の仕方が実に日本的なんだな

379 ：

日本的プログラマの方が先に絶滅するだろ。

380 ：

頭いい奴にコード書かせた方が効率的だよな

381 ：

たとえば誰ですか？

382 ：

ゲームならジョン・カーマック
OSならタネンバウム
システムならデイビット・カトラー
検索エンジンならラリー・ペイジ

馬鹿のおもりならリヌース

383 ：

うーん、この人達をみると、SEとかプログラマーという日本的な区分が古いのかもしれない。
ITSSレベル4を全部兼務した研究者というべきか。

384 ：

ジョン・カーマックって誰だ？って思ったら
DOOMやQUAKEの人か・・・・。懐かしい・・・。
家のガレージで数人で作ってたらしいな。
ひとりであのプログラムを組んでたらしい。
そういう話を聞くと、うちのプロジェクト、あれだけ人間投入して
成功しないのは、もう馬鹿かと思えてくるわ・・・。

385 ：

プログラマがそういう一部の職人にしか出来ないなら、お前らは今頃無職だぞ？
お前らが飯を食えるのは、馬鹿でも誰にでも仕事が出来るようにした仕組みのお陰。
どうしようもない人間を使う為に、管理者が必要で、その会社を管理する為の管理者が必要でｒｙ
そして、質を数で補う雇用体系、それを管理する人間が必要。と
まぁ、なるべくして今のPGの地位低下とSEが偉そうにしてる世界になってるわけだな。
それをこわすということは、お前らが失職するということ。

386 ：

>>384
それが日本だと神主になってしまうという。

387 ：

最強のプログラマは、戦略からプログラミングまで出来る研究者だと思う。
役職の細分化は、ロスが大きすぎる。

388 ：

>>384
人数多いからでかいこと出来るかって言えば、全然そうじゃないってのがかなり
初期の段階で判明してるからな。 人月の神話でとりあえず人を投入するのが
ダメと分かって、闘うプログラマーで人数を投入する場合はロスが多くても
優秀な人間を投入して乗り切れっていう感じになったからｎ。
そういう大きいプロジェクトほどSEというか、全体を見回せて調整が出来るのが
いる必要があるが、テトリスのごとく隙間を無駄に埋めようとするだけの能無し
ばかりだからうまくいかない。

389 ：

>>388
仕切ってるのはピンハネ目的で現場が炎上すればするほど儲かる連中だぞ。

390 ：

>>389
酷い話だかが正解だなぁ。
でも、この不況でそういう組織はようやく叩かれるようになってきた。
そういうやつらはだいぶ減るんじゃないかな。

391 ：

>>390
いや、不況で最初に切られるのはオフショア開発で
いらなくなった人達だ・・・

392 ：

>>391
オフショア開発は余り安くなんないんじゃね？
コーディングから単体テストまでを出すつもりだろうが、
厳密な仕様書作成と、プログラム受け入れの工数がばかになんないから。

393 ：

>>391
大丈夫。このまま順調にいけば、中国に出すより日本人にやらせたほうが
安く済むようになるから＾＾

394 ：

>>393
ははは、そうだね。
でも第二・第三の中国が出てくるよ。

395 ：

大丈夫。このまま順調にいけば、どの国に出すより日本人にやらせたほうが
安く済むようになるから＾＾
経済力も伝統も国際的な信用も失いそうだし

396 ：

ブリッジSEｗ

397 ：

>>393
洒落に成ってないwww
ポルナレフのAAじゃないけど、ウチも安月給を通り越して
マイナスの賃金に成る月も有るもんな…。

398 ：

ウチ残業付けたら減俸だよ

399 ：

>>395
そうすればスレタイが実現して、日本は頭を使わない労働集約型になれるか。
中国やインドのブリッジSEに使われるPG。
あ、でも、中国語も英語もできないから無理か。

400 ：

そのためのブリッジSEだろ？

401 ：

中国人やインド人のブリッジSEに支配される日本人PG

402 ：

>>401
> 中国人やインド人のブリッジSEに支配
むしろそれは望むところ。
日本のPMの遅れ具合をかんがみれば。

403 ：

ヒト売り営業に支配されるよりは…

404 ：

>>402
またもや外圧頼みかｗ
つくづく日本は自己改善能力の無い国と実感するのであった。

405 ：

まあ海外にSE、PGがいないわけじゃなくて、呼び方が違うだけなんだけどな。
ITアーキテクト、アプリケーションエンジニア、テクノロジースペシャリスト、
プロダクトマネージャ、インダストリーマネージャ、エバンジェリスト・・・
日本はこれらをザックリ「SE」「PG」と分けているだけだと感じた。
外資の俺の感想。

406 ：

そういう意味で言ったら営業も同じで、アカウントリプリゼンタティブ、アカウントエグゼクティブ、
パートナーマネージャ、ソリューションスペシャリスト・・・
まだまだある。
そもそも海外との職種定義の違いはIT業界に限ったことじゃないのに、
無知無能君に限ってスレタイみたいなこと言うよね。

407 ：

言いません。

408 ：

>>405-406
その職業名の部分が全部英語表記だったら嫌味な感じでよかったのにｗ

日本だとエバンジェリストって、提灯ライターみたいなイメージ。

409 ：

お前のイメージなどどうでも良い

410 ：

>>405
呼び方だけでなく内容も違うだろ。
ゆいいつ
SE＝プロダクトマネージャ
が近いぐらいで、あとは該当無し。
PG＝コーダー
でバッチリか？向こうにもコーダーぐらい居るだろ。
そう考えると日本は、プロダクトマネージャ＋コーダー
だけで作ったシステムで成り立ってるわけで、
もうアフォかとｗ

411 ：

>>409
エバンジェリスト乙

412 ：

逃げちゃだめだ

413 ：

>>410
君の回りに当てはめるとそうかもしれない。
でも世の中は広いよ。

414 ：

私が死んでも代わりはいるもの

415 ：

PG「私が死んでも代わりはいるもの」

416 ：

自分の代わりなんていくらでもいるだろうと思うのだが、他の奴が出来なかった
仕事をオレに積むのは止めてもらいたいと思ったり。

417 ：

あんたバカぁ?

418 ：

わたしはたぶん三人目だから

419 ：

エヴァンジェリストでここまで引っ張るお前らって・・・

420 ：

営業「予備が使えなくなった。もう一度だ。」
PG「………………ﾊｲ……」

421 ：

ワロタwww

422 ：

使徒・・・顧客
ゲンドウ・・・PM
ミサト・・・SE
シンジ、綾波・・・PG

423 ：

>>405-406
「自称」が抜けてるな、日本の場合。

424 ：

デニス・リッチーは今でも
自分はプログラマだと言い続けているのかな

425 ：

ああ、追加だけど外資や海外にも自称が多いよ。
ロールが決まっててそういう職種でいますけど実は違うんです、みたいなやつはゴロゴロいる。
あと融通が効かない。いや、それは私の仕事ではありません、みたいな感じ。
恩も義理もあったもんじゃない。
日本はそういうとこれがいいね。

426 ：

日本のそういうとこが、SEという職種を駄目にしている気がする

427 ：

まあ隣の芝は青いんだよ、お互いｗ

428 ：

「俺はコッチをやったんだから、お前はあっちをやるべきだろ」
みたいなのも、ある意味杓子定規の一種だよ。
つまり、結局は融通は利いてないんだよ。
あと、SEという職種以外の分野では、融通を利かせれば
上手く仕事がまとまる職種は多いだろうが、
SEは人間を相手に仕事しているようで、実際にはシステム相手の仕事だ。
システムを設計するのが目的であり、システム中心で考えねばな。
つまり人間ではなく、機械的手順相手の仕事な訳で、
本質的に融通は利かなくて当たり前だろう。
日本人はそういうとこ理解できてないから、
最初に言った話みたいに、人間関係の都合に合わせた
設計になるところが良くないな。
で合理的な設計になる訳がないと。

429 ：

>>428
まだまだ考えが足りないねぇ。
システムは目的じゃないよ。目的を実現するための手段。
(システムを使って金を儲けるとか、団体の知名度を上げるとか、ね。)
システムを作ること自体を目的だと勘違いするところから悲劇がはじまる。
>>428もこの線から考えなおしてみ？自分がいってることのおかしな部分に気付くよ。

430 ：

俺は>>428,>>429両方とも極論だと思う。
システムは手段でもあり目的でもある。
SEとして技術屋の誇りは持つべきだけど、
それがなんのため使われてに、どんなことに貢献するか常に意識することは必要。
とりあえず>>429はまだ若いから、いろんなこと吸収して
がんばってね。

431 ：

こっちは意図があって隠蔽してるのに、何度説明しても
「テーブルの定義が出せないなどSEの仕事としてありえない」
の一点張りで、聞いちゃくれない。
太古からのやり方を受け継いでる人達は、自分のやってきた方法を
ガンとして曲げようとしないので、新しいやり方の導入なんて無理。
日本はこんなPJばっかだし。
どっちが融通利かないんだか。

432 ：

>>431
どうみてもおまえのアカウンタビリティ不足だろ

433 ：

じゃあそもそもが、どう考えても>>425のアカウンタビリティ不足だって結論だな。

434 ：

アカウンタビリティーってなに？

435 ：

無理して横文字使わなくてもいいのに。
文脈からすると、説明能力不足ってことだよなあ。

436 ：

日本のSEがなんでだめか分かった気がする。
語学もガラパゴス・・・

437 ：

頭の中はエロマンガ島

438 ：

逆だろう。
日本のSEは、話術に長けた者が勝ち残り過ぎだ。
中身が無くても話が上手い奴が通る世界。
逆に言えば、聞き手が相手の中身を読み取る能力が無いとも言える。
一般職なら少々中身が無くても誤魔化せるけど、SEの仕事はなあ…
駄目なシステムは駄目な通りにしか動いてはくれない。

439 ：

つまり、できあがったものが良いか悪いかは問題じゃないのさ
作る前の折衝のほうが重要なのさ

440 ：

そして糞なシステムが大量生産されるとｗ

441 ：

そのダメなシステムを動かすために何柱もの人柱が立つと、、、

442 ：

外資だが、話術に長けたやつが残るのは外資のほうが多いよ。
日本の会社とつきあっててわかる。

443 ：

・中身があるものを、分からない人に上手く説明する技術
・中身がないものを、分からない人に、分からないのを利用して良さげに見せる技術

海外は知らんが、日本のSEは後者だけしか居ない気がする。
日本の場合は、中身が無いのを知ってて…という詐欺的なものではなくて、
理解できないので、中身が無いことに気づかないだけな気もするが。
で過程や建前はどうあれ、コンピューターさんは中身だけしか見ないので、いざ動かすと…

444 ：

騙される側が悪いとしか言えんな。
問われているのは聞く側のスキルだろ。

445 ：

>>443
むしろ外資は後者がものすごくうまいよ

446 ：

結果としてアメリカ産の方が使えるモノを残してるんだから、
中身がちゃんとあったんだよ。たぶん。

447 ：

そもそも日本では、ネガティブなことを言う奴は採用の時点で無条件に落とされてるってのがあるな。
駄目システムになりかけてる場合、本当に必要な人材はそういう奴の中にこそ居るんだけどな。
自分の下にはイエスマンばかりを揃えたSEが居て、どうにもならなかったプロジェクトもあったｗ
駄目な方向に向かって爆進してるのが分かっていつつ、誰も止められない…みたいなｗ
これがデスマーチってやつさ。
日本人てそういうの多いけど、そういう民族？
でもね、インド人に付き合えってのは無理だと思うのさ。

話が逸れてしまったので戻すとする。
そうだね確かに問題は、出された対案の良し悪しを判断する眼が無いことだろう。
だから、糞な対案しか出せないのに駄目出しだけ上手い奴（つまり単なる破壊者）と、
優秀なSEとの区別が付かず、両者が同じに見えてしまう。
結果としてイエスマン好きになってしまう気持ちも分からんでもない。

448 ：

ていうか、おまいら海外のなにと比較して日本のSEは・・・って言ってるんだ？
妄想？
隣の芝は青くみえるものだよ

449 ：

井の中の蛙自慢ですかｗ

450 ：

ダメなシステムを作ることに意義があるんだ
いいもん作ってどうする

451 ：

>>450 が核心を突いたｗｗｗ

452 ：

素晴らしいシステム作っちゃうと俺ら失業するもんなｗ

453 ：

自分がやらなくても誰かがやるんだ
だったら……！！

454 ：

空気を読んで行動し、裏切り者は暗黙の内に排除され、
全体として破綻せず機能させるのが得意な、
日本でしかありえない統率力だなｗ

違う意味で破綻してるけどｗ

455 ：

>>454
そして、自宅待機者はどんどん死ぬんだｗ

456 ：

ＳＥは、客のやりたい事を聞きだし、要件書をまとめるだけにしてくれ。
技術的なことも提案だけにしてくれ。
工程も希望を言うだけにしてくれ。　勝手に決められても、守れない。　

457 ：

上に言われたのだが、開発職とSEは違う職種なのか？
プログラム好きで入社したのにおまえはSEなんだから
トークセンス磨けとか、客のご機嫌取りばかり要求される
営業やカバン持ちするくらいならIT業界なんて選ぶわけねーだろ

458 ：

プログラミングが好きなら、なんでPGにならなかったの？
そりゃSEになったら、そうなるのは当然だろ

459 ：

>>457
じゃあおまえは向いてないな
社会人として

460 ：

トークセンス磨いて客のご機嫌取りばかり要求される営業やカバン持ち
と
プログラマー
だけで、まともなシステムが組み上がると思ってる、経営側の問題なんだよ、要はな。

461 ：

>>406
ん？あとどんな職種が必要なの？

462 ：

>>460
COBOL全盛の時代は、それだけだったな。
システム規模に比例して級数的に大量のSEとPGと期間を必要としたが、
大量の金継ぎこんで、物量作戦でなんとかなっていた。
だがこれはいまや古典だ。
これによりソフトフェアクライシスとかいう言葉が生まれ、ソフトウェア工学なるものが出来、
効率よく生産する術を我々は得たのだ。
逆に言えば古典がいかに行き当たりばったりで、設計と言えるレベルではないのかが伺える。

金を出す側もそれを知っているので、古典を今やると絶対採算が合わない。
だが、いまだに古典なプロジェクトはある。つか多い。
ソフトフェア工学のスペシャリストってのが日本で育たないってのもあるだろうが、
経営者がCOBOL時代の頭だと、>>460の職種しか知らないんだからしょうがない。
で採算が合わないのに、古典方式でやってるってことは、どこに皺寄せが逝くかというと…

463 ：

そういう老害コボラー上がりのヒト売り人事が、就活板で
工作活動しまくっててウザいわけだが…。
カバン持ちSEとPGの違いをgdgd書いて得意に成ってる。
Googleみたいなプログラマは理解不能らしい。

464 ：

gdgd書いてないで、さっさと「Googleみたいなプログラマ」になれば？

465 ：

それをやろうとすると、上司に怒られるのが日本です。

466 ：

じゃあgoogle行くか独立しろ

467 ：

独立しようとすれば、国が障害になるのが日本です。
googleみたいな事をすれば、利権団体にフルボッコにされるのが日本です。

468 ：

じゃあ日本出てけ

469 ：

実際、優秀なSEは活躍の場を求めて日本を出て行っちゃうんだよな。

470 ：

つまり日本に残っている95%のIT技術者は無能だと

471 ：

優秀な技術者が日本にいても力を発揮できる受け皿となる組織がない

472 ：

それどころか、人間仕様書として駄目システムに寄生して儲けるビジネスモデルを破壊する存在として廃絶されてしまう。
もし優秀な技術を持っていたとしても、それを見せては駄目だ。潰されるぞ。

473 ：

日本は奴隷教育は熱心にやったけど、エリート教育はかけらもやってないので上に達人がいないんだよね。
ま、仮に帝王なんとかを受けた人がいても、金主が強盗を元手にした金貸ししかいないからな。

474 ：

だから文句があるなら日本出てけって
優秀なプログラマー様なんだろ？ｗ

475 ：

どこに出て行くの？ｗ
イエローモンキーを実力のみで受け入れてくれる国は無いと思うぞ。
ヘタにでしゃばると、暴動にあうし

476 ：

優秀なプログラマなんだから問題ないだろ

477 ：

優秀なプログラマであっても、優秀な人種ではないので無理です。
日本人を辞めるしかありません。肌の色レベルで

478 ：

そういうのも超えるのが優秀なプログラマ様であらせられるよ

479 ：

なんだ、だめなのは日本じゃなくておまえらか

480 ：

日本を褒めても何も出ないぞ

481 ：

日本だけじゃなくて、どこの国もダメ
どこもかしこも、利権にまみれてる。

482 ：

仕事はそこそこまぁまぁ適当
趣味で作るときは本気出す

483 ：

日本もだめ、海外もだめ
イエローモンキーだからだめ
エリート教育してないからだめ
受け皿となる組織がないからだめ
上司に怒られるからだめ
経営者がCOBOL時代の頭だからだめ
・・・・無能、他力本願、積極性なし、協調性なし
本当にだめなのはおまえら自身じゃ

484 ：

お前ら飼い慣らされすぎなんだよ。
歴史を見てみろ、多少強引でなければ自分の理想に何日近づけないんだぞ。
明日からはもっと強引にやれよな。

485 ：

>>484
とりあえず、人事に頭下げたくないので
就職活動辞めてみた。

486 ：

>>485
いや、俺がいいたいのはそういうことじゃないんだけどさ…笑
文句言ってないて現状を変えろ。
強引さが必要なら強引に変えろ。
敵を作らない方がいいなら時間をかけて変えろ。
馬鹿な営業とか人事とかに負けるとか、絶対許さないからな。最後は勝てよ。

487 ：

>>485
それは素晴らしい考えだが、残念ながら文明のある世界では死を意味する。
素人と平民にはお勧めできない。

488 ：

まあ、馬鹿な営業とか人事とかに飼われて毛を毟られて肉となるだけの羊ちゃんが多いから、
いつまで経っても馬鹿な営業とか人事とかが淘汰されないのは事実だな。

489 ：

何も知らない新卒が次々と「供給」されて来るからな。
飛んで火に入る夏の虫。

490 ：

顧客の開発室に、協力会社として入ってるＳＥなんだけど、
なんか去年の暮から、ウチのプロパーのリーダーが、
作業指示を出してくれなくない。
代わりに協力先の会社の人から作業指示してもらってるんだけど、
これって問題じゃないのかな？どっちに問題があるか解からないけど。

491 ：

＞作業指示を出してくれなくない。
　　　　　　　　　　　　＾＾＾＾＾＾＾＾＾＾
いいじゃん。そこそそ出してくれてるんだろ？ｗ

492 ：

そこそそってなんだｗ
みんな日本語が危険が危ないな

493 ：

＞そこそそ
女の子が言ったとしたら、なんかエロいなｗ

494 ：

>>490
あんた何年目？
いつまで指示待ち人間？
自分で仕事見つけろって事だと思うよ。

495 ：

ルーティーンワークだけでアップアップの線表しか引いて来ないので、
自分で仕事増やす奴は馬鹿を見る構造ってのもあるけどなｗ

496 ：

>>494
「協力会社として入ってるＳＥ」が勝手なこと出来んだろ。
所詮、人足なんだから。

497 ：

前のカキコはどうも入力ミスです。ｽﾏｿ
>>494
３年目に入っています。
基本、>>496の言うとおりです。
僕が居て、リーダーがいて、その上に協力先の取りまとめ役が居ます。
これまで作業は、協力先の取りまとめ→リーダー→>>490
だったのが、契約が変わり、協力先の取りまとめ→>>490
が可能になった。 途端に指示なし。。。
リーダーとして給料貰ってるのに、ほっといて良いんだろうか。。。。

498 ：

明らかな偽装請負ですな。思い切り労働基準法違反。

499 ：

証拠集めて労働局にチクれ！
でないと業界全体がブラックに汚染されてしまう。

500 ：

請負なので指示は出せない
↓
請負リーダーが駄目で、これじゃデスマ確実ｗｗｗ
↓
発注側が仕方なく実質リーダー
↓
偽装派遣の黄金パターン完成ｗ

501 ：

皆さんありがとうございます。
実はこれまで契約が一括だったのが
リーダー、>>490共に契約を派遣に切り替えられています。
だからといって、上司が部下の面倒を見ないのは、
やっぱり違法なんですよね。
ちゃんと証拠を集めて、退職勧告された時にでも出せるようにします。

502 ：

ん？
偽装だってチクられたら捕まるから、派遣に切り替えたってこったろ？

503 ：

それを先に言えよアフォウ
だったら違法でも何でもねえよ

504 ：

派遣だって言うと嫌がるから、請負で面子を集めといて、
回りだしてから派遣に切り替えるという、新手の手法じゃねえか？？ｗ
確かにこの手は使えそうだなｗｗ

505 ：

SEと言う名のセールスエンジニアなら沢山知ってる。
そいつらは確かに要らない。
ちゅうか、誤解を招くからSEって言うのやめれ。

506 ：

言葉ってのは、本来の定義より、よく使われる意味の方が残っていき、
最後には本来の定義に置き換わっていくもんですよ。
実態がそうなら、そっちがいずれ本来の定義になるんじゃないかな。

507 ：

そのうち「携帯」の意味も、「持ち歩く」から「電話みたいなもの」の意味に変わるよ。

508 ：

そのうちマイコンの意味も、パソコンになっちゃうよ

・・あ、それは20年前に通った道かｗ

509 ：

>>507
漢字で意味が固定されてるから変わらないよ
あくまで俗語

510 ：

新語なんて、最初は何でも俗語だって

511 ：

MSといったらマイクロソフトでもモビルスーツでもなく
シュレッダーだべ常考

512 ：

メイプルストーリーのことかとおもた

513 ：

ご主人様と奴隷だろ

514 ：

つーか
拘束プレイだろ

515 ：

確かにMS案件は拘束プレイ多い罠w

516 ：

とりあえずSierの大部分を解体しちゃえばいいんじゃない？こんなゼネコン体質じゃ、いつまでたっても世界にリーチできるサービス作りなんて無理。そんでだれかGoogleを作れ。はなしはそれからだ。

517 ：

>>510
最近じゃ、レンズが交換できるカメラのことを「一眼」と呼んでいる事実を知ったとき、
驚愕したｗ
しかも一流大手メーカーが直々とｗｗ

518 ：

なんで驚愕するのかわけわからん

519 ：

レンズ交換式≠一眼

520 ：

なんか良くわからんけど、お前の一眼の定義は何なんだ？

521 ：

デジカメの中で、一眼レフカメラに外観がよく似た奴をデジタル一眼って言ってるんだろ。
俺も何で驚愕するのかわからん。

522 ：

え？一眼レフって、カメラのレンズ部分が１つ目のやつじゃないの？
そうじゃないのは、2つ目でステレオ的に取るとか？

523 ：

寧ろ、デジタルなら普通は一眼じゃないのかと。

524 ：

カメラ付き携帯電話も一眼だよな

525 ：

>>522
昔は二眼だったのよ。
http://images.google.com/images?sourceid=chrome&q=%E4%BA%8C%E7%9C%BC%E3%83%AC%E3%83%95%E3%82%AB%E3%83%A1%E3%83%A9&um=1&ie=UTF-8&ei=X8FWS9amOYyTkAXzoKiPCg&sa=X&oi=image_result_group&ct=title&resnum=4&ved=0CCoQsAQwAw
それに対する一眼。

526 ：

お前ら、カメラ板行け

527 ：

>>521
見た目の問題かよｗ
ガンダムによく似た「カソタム」みたいなの作って売っちゃうみたいなｗ
ディズニーキャラモドキなキャラがたむろってる中華遊園地でさえ、
「ディズニー」とは名乗らないのに、それ以下だなｗ

528 ：

>>517
で、「一眼じゃないのに、レンズが交換できるという理由で一眼と呼んでいる」
実例をあげてみてくれ。

529 ：

Wikipedia見りゃ、一眼がどういうものなのかわかる。
それがお前の認識と違うというなら、お前の認識不足だ。

530 ：

「一流大手メーカーが直々と」って変だろ

531 ：

さあ、だんだんとツッコミどころが苦しくなってきましたｗ

532 ：

というか、一眼って他になにを指すの？

533 ：

二眼レフも普通、レンズ交換可能。
Cマウントの監視カメラだって、一眼だしレンズ交換可能。
自動監視システム組んだり、デジカメのファームウェア
組んでたSEなら、今時の呼称には疑問を感じずにはいられない。

534 ：

写真に少しも興味がない俺でも、
たぶん小学校高学年の時点で一眼レフの意味ぐらい知ってたし、
それが理科系タイプの人間の標準だと思うんだけどな。
しかし>>517みたいな人って時々いるよな。
どういう神経してるんだろう。

535 ：

ごめん>>517に噛み付いてる人、の間違いね。

536 ：

517が本当かどうか走らないが、
本当ならびっくりするわな。「一」の意味無いしな。

537 ：

ＥＶＦを使ってるカメラを一眼レフって呼ぶとかなら
確かに間違えだが、「一眼」って言葉自体に既にレンズ交換式の
ゴツイカメラのコノテーションがあるからレンズ交換式の
デジタルカメラを「デジタル一眼」と呼ぶのは別に不思議じゃない。
そもそも、単語の意味の変化や誤用なんて言語学的には正常な
事象なんだから理系ならこれを嫌悪するってのは違和感を感じる。
実際に普遍的に起きている事象を認めず、教条的な定義に
固執するのは科学ではなく神学じゃん。

538 ：

はぁ？

539 ：

仏蘭西語では「ポルターブル」(portable)と言えば
すでに「ケータイ」の事を指すそうだ

540 ：

その調子で
>違和感を感じる。
これも正当化してみてくれ。

541 ：

>「一眼」って言葉自体に既にレンズ交換式の
>ゴツイカメラのコノテーションがあるから
無いよ。

542 ：

で、SEという職業をなくしたい話と、一眼がなんの関係あるわけ？

543 ：

言葉が一人歩きして本来の意味を失っているところとか

544 ：

んなもん大概の言語で相当数あるだろ
日本語だっていろいろ変化して今の意味になった単語はたくさんある
今現在変わりつつある単語だけ血祭りにあげても何の意味もないよ

545 ：

taxi なんかもそうだな
本来tax（税金・料金）から来た「運賃表示器」の意味なのに
（客を乗せて）走る、移動する、という意味に取って変わられちまった
飛行機が地上を自走するのもタキシングなんて言うようになった

546 ：

という訳で、やがら長くなっちまいましたが、
>>505-506の説の正しさを理解していただけたでしょうかね？
てことで、この話題はお開きに。

547 ：

適当だな

548 ：

「適当」という言葉もそもそも「すごく合ってる」という意味から
「いいかげん」という意味に使われるようになってだな（以下話題ループ

549 ：

「良い加減」という（ｒｙ

550 ：

いい加減にやって失敗したら、悪い意味だけど
いい加減にやって成功したら、それは素晴らしい効率

551 ：

昔の武士は「一所」懸命に頑張ればよかったのに
今の企業戦士は「一生」懸命に頑張らなきゃいけなくなった

552 ：

「頑張る」は我を張るという否定的な意味だったのに
努力するという肯定的な意味に（ｒｙ

553 ：

有名どころではデフォルトだな
金融用語で「支払不履行」だったのが
「何もしない」という意味の拡大解釈から「動作指定省略」となり
さらに省略時動作の設定、「初期設定」の意味となり、さらに意味が拡大して
「設定」という行為（いわば「コンフィグ」と言われていた範囲）にまで侵食している
「何も指定しない」という意味から使われ方が一まわりして
初期値を設定する行為そのものがデフォルトと呼ばれるようになった

554 ：

おめーらまとめて言語学板R

555 ：

え？この職業言葉遊びするのが仕事だろ？ｗ

556 ：

それはSﾖと困猿の特権だ。

557 ：

>>553
デフォルトは省略時動作、まではいいけど、
初期設定はinitialを使いたい/使ってほしいし、
設定する行為はデフォルトと呼びたくないなあ。
……と思ったがOSXのdefaultsコマンド

558 ：

defaultを、設定という意味で使わすかー？
んなもん潜在バグの温床として、即行没だわ。

559 ：

　.defって拡張子のファイルがあって
なんかいろんな初期値が書いてあるからデファイン（定義）の略かなと思ったら
そこの運用SEが「いやデフォルトの略ですよ」と・・・
他にもPCの講習ビデオなんかでも
講師が「それではデフォルト画面を開いてください」
なんじゃそりゃと思ったらコンフィグ画面だったでござる、とか・・・
なんか膝が抜けるような場面に出くわすよ

560 ：

一般人にも
暗黙の了解とかお約束の展開みたいな意味で
デフォって言いかたが広まったな
要は元の意味が「何もしないこと」そのものじゃなくて
「特別な事がない場合どうするかの取り決め」に意味がシフトしてきてる

561 ：

デフォルトのファイルなら.orgでもつけろタコ
でもデフォルトを「既定の」と訳すのは嫌い

562 ：

俺は不本意な使われ方をしてる事例を挙げただけ
何でタコ呼ばわりされなきゃなんねえんだ畜生

563 ：

謝れ! タコに謝れ!
SE<<<(超えられない壁)<<<タコ

564 ：

ターコタコタコタラコの子〜

565 ：

くれってくりゃるかくりゃりんこ〜

566 ：

NoPerson プログラマ = new NoPerson();
while(プログラマ.正常な精神を得る()!=NULL){
　プログラマ.仕事する();
　　if(プログラマ.胃潰瘍){
　　　プログラマ.寝る();
　　}else{
　　　プログラマ.食べる();
　}
}
プログラマ.辞める();
プログラマ.死ぬ();

567 ：

うんhttp://pc11.2ch.net/test/read.cgi/prog/1182393849/こ

568 ：

まあ>>553はいろいろ勘違いしてそうだなw

569 ：

てｓ

570 ：

おまいら！アメリカで一番ボロい仕事はSystems Engineerだそうだぞ。
>ttp://www.focus.com/images/view/7362/

571 ：

　↑
うらやましいけど、何で？？？？？

572 ：

アメリカのSystemsEngineerと、日本のSEが同じ職種だと思うから、不思議に思えるだけだろｗ

573 ：

＞アメリカのSystemsEngineer
説明kwsk
アメリカのSEと日本のPGが同じ職種なら、ますます不思議になるお

574 ：

プログラマ職業紹介
http://www.youtube.com/watch?v=CFZiil0DfMc&feature=fvw

575 ：

日本のSEってセールスエンジニアのことだろ？
コードの書けないSEなんて世界のどこにも居ないのに、だから世界最低レベルだとかって馬鹿にされんだよ。

576 ：

いや、それはいいから、
「”アメリカのSE”に目本でなれる方法」が
知りたいｗ

577 ：

>570のリンク先にはITでは別に下から
Telecommunications Network Engineer
Business Analyst
Software Product Manager
Software Developer
Computer/Network Security Consultant
IT Project Manager
があるな。給料はよくてもキッツい仕事はランクが下ということか。
それにしても、これだけ別にあって
じゃSystems Engineerってなにする仕事なのか謎だな。
いわゆる請負の業務アプリ屋はSoftware Developerに入らないのか？

578 ：

>>573
System Engineer≒システムエンジニアですらない
大規模なプロジェクトに係わる工学系大学院を卒業した人というイメージ。
惑星探査ロケットを飛ばす人とか新しい送電システムを開発する人とか
そりゃあ「システムエンジニア」と比較にならないくらい良い仕事なんじゃね

579 ：

>惑星探査ロケットを飛ばす人とか新しい送電システムを開発する人とか そりゃあ「システムエンジニア」と比較にならないくらい良い仕事なんじゃね
ttp://nensyu-labo.com/gyousyu_jden.htm
ttp://nensyu-labo.com/gyousyu_car.htm
ttp://nensyu-labo.com/gyousyu_denki.htm
ttp://nensyu-labo.com/gyousyu_iryo.htm
そうか？
平均見る限りそうでもないような。。。
>System Engineer≒システムエンジニアですらない
ttp://nensyu-labo.com/gyousyu_jyoho.htm
Ｓヨって仕事は氏滅気味とｵﾓうが、大して変わらんお。
ましてや、Ｓヨよりマのんがこれより低い希ガスｗ

580 ：

>>579
「良い仕事」≠「給料の高い仕事」

581 ：

＞「良い仕事」
>惑星探査ロケットを飛ばす人とか新しい送電システムを開発する人とか
ホリエモン？？？

582 ：

アメリカの場合
「良い仕事」＝「給料の高い仕事」

日本の場合
「ホスト時代の実績だけが頼りの古典的手法による仕事」＝「給料の高い仕事」

583 ：

その結果→ ttp://business.nikkeibp.co.jp/article/manage/20100305/213172/

584 ：

>日本のSEってセールスエンジニアのことだろ？
>コードの書けないSEなんて世界のどこにも居ないのに、だから世界最低レベルだとかって
↓優秀な若手　　　　　　　　　　↓希望の星　　　　　　
188 ：仕様書無しさん：2009/10/22(木) 18:39:55 　　　　　　　　　　←天才
底辺=業界の標準みたいなのやめてくれるかな
俺は時給契約特定派遣だが3300あるぞ 　　　　　　　　　　　　　　　　←優秀なエンジニア
ソフ開持ってて1000以下なんて死んだ方がいいレベルの無能なんだろ　　
↑　　　　　　　　　　　　　　　　　　　　↑
技術立国日本の鏡　　　　　　　　日本にも優秀なSEは居る！　

585 ：

技術立国日本とか、IT系の人間でそんな幻想を信じてる大馬鹿野郎がまだ居たんだ・・・。

586 ：

で、つまりアメリカのSystems Engineerってなにしてるの？
逆に日本でSE/PGとか言い出したどうしようもない奴はそもそも誰？
CSKだかTCSだかあべしだかFだか知らんが。

587 ：

英語を輸入したら、似たようだが全く違うもんに使われ出したなんてのは、五万とある話。
文化が違うんだから、あたりまえじゃん。

588 ：

顧客の業務も知らなければ稼動しているシステムの中身も知らない。
顧客から毎月6人月の保守サポート料を貰い、その時間を3人の下請けパートナーにやらせる。
(すなわち、1人で2人月分の作業をこなさなければならない)
もちろん、パートナーとは1人1人月の契約。
そりゃこんなヤクザなことしてれば、家も外車も買える給料で笑いが止まらないよな。

589 ：

>>588
ＮＴＴデータのコンサル部の事ですか？

590 ：

>>588
それ根本的に考え方が間違ってるよ。
もともと３人月分の作業を６人月分としてるだけ。
６人分の作業を３人にわりふってるわけじゃないから。

591 ：

で、結局アメリカのSystems Engineerって何をしてて社会で一番な仕事なんだ？
なのに日本のシステムエンジニア(笑)をコードも書けないクソ御用聞きにしたのは
いったい誰なんだよ。

592 ：

今までは理学部とか文系とかの高学歴の受け皿として機能してたんだよ、その時点でおかしいわけだけども。

593 ：

「ソフトはマーケットシェア的にトップが全部持っていく傾向があるのは確かなので、トップ
であるアメリカのSEだけが良くて、日本も欧米もだめである」という見方でいいんじゃないの？
日本人のハード系の偉い人の書いた本とかでも、「ソフトはアメリカに歯が立たなかった」
という回想／反省みたいなことがよく書いてあるよ。

594 ：

成果主義に疲れと不安
　４０代男性。妻と子の３人暮らし。ＩＴ（情報技術）企業で勤続２０年。ここ２年の個人業績が悪く、先日、早期退職を勧められました。
退職の意思がないことを伝え、もう１年頑張る決心をしましたが不安です。
http://www.yomiuri.co.jp/jinsei/shinshin/20100324-OYT8T00188.htm

595 ：

コピペ君って馬鹿だな、まで読んだ。

596 ：

>>586
> で、つまりアメリカのSystems Engineerってなにしてるの？
強いて言えばMCSEとかかねー。
あとさ、アメリカあたりだとソフトウェア開発者の
大きな部分にOSの作成者ってのがある。
そういう人もシステム関係と言えないことはない。
要するにアプリよりはインフラっぽい人が
システム技術者なんじゃねーかな。

597 ：

>>591
> FIIFでは、日本企業が押さえていた国内マーケットを、
> いかに開拓するかという研究会が重ねられた。FIIFが考えたのは、
> 「米国商工会議所」を巻き込んで貿易摩擦問題と連動させることであった。
> つまり、日本車の輸入を米国に緩和してもらう条件として、
> 外資系IT企業製品を日本の官公庁へ導入してもらおうという取引である。
> 当時、この取引はマスコミに大きく取り上げられた。
一言で言えば、日本のITはトヨタの犠牲になったと言うことだな。

598 ：

ソースは
http://summit.ismedia.jp/articles/-/165

599 ：

>>578
SEとプログラマの違いって日本のマンションとアパートの違いみたいなもんだな
「アパートなんかじゃありません、マンションに住んでます」
外国人「何、mansionだって!!」
http://images.google.co.jp/images?q=mansion

600 ：

アメリカでは理工系の大学を卒業しないと
ＳＥと名乗れなかったと思います。
つか、採用されませんから。
わが国など高校中退とかでもプログラマやってるし。

601 ：

高校中退でプログラムやってる奴はプログラム自体は多少できるんだろ？
少なくとも未経験のアホよりは。

602 ：

日本では刑務作業
ttp://www.itmedia.co.jp/enterprise/articles/0705/01/news053.html

603 ：

>>600
アメリカのSEはシステム工学のエンジニアでコンピュータソフト開発と無関係の
SEもたくさんいる。
コンピュータソフトの開発だったら高卒でも開発者の頂点に立つやつもいる。

604 ：

>>603
理系大卒のダメプログラマもいるが。
ソフト開発はたいして予備知識が必要がないから学歴はいらない。
中には大学で画像解析の研究して仕事で画像解析のプログラム組んでる人とかもいるんだろうけど
プログラマはプログラミング技術がいるけどSEの方はさらに知識不要。

605 ：

＞SEの方はさらに知識不要
だからそれが日米の決定的な違いなんだって。
向こうは、SEというとソフトウェア工学に基づいた
優れた開発技法を駆使する能力が問われる。
日本みたいにお客さん騙す資料作成のための
ワープロ能力が問われる業種とは全く違う。

606 ：

>>605
でも大学で専門にするほどのことはない
理解するのに微分積分も経済学セオリーもローマ帝国の詳細な歴史も必要じゃない
一般リーマンでもプロジェクト管理とかマネジメント技術は必要だし、一般常識的なことだろ
高度なソフトウェア科学はOS作ったりグーグル検索エンジンとかのアーキテクトを作る研究者のためのものだしな

607 ：

大学出たからといって、ＳＥとして
優秀かどうかは不明。
それは日米共通。
できる奴は高卒でも、文系でもできるようになる。
大きな違いは、米国だとＳＥとしては
採用されないってこと。

608 ：

>>605
だがその一般常識の技術レベルがない現場もあるのはわかる
やっつけ終電徹夜で仕上げて元請けのご機嫌取って結局作り直しとかバカかと
でも開発人月が増えて客からは頑張ってると評価されて誰も損しない

609 ：

日米の違いは、大学の違いにもあるな。
日本みたいに代返してもらいまくってほとんど授業に出てないのに、
ソフトウェア工学を大学で学びましたみたいな学歴がゲットできるようなことは、
アメリカでは絶対ありえない。

610 ：

FizzBuzzの件もございますことですし....

611 ：

工学部卒のSEだが
高卒が作った会社の資格を必死で取得して
高卒が作ったOS上でソフト開発しているのであった。

612 ：

だからさ、Software DeveloperやIT Project Managerっつのが
日本でいうPG/SEのことだというのでいいのか？違うよな。
きっとこのランキングに入らないとこにProgrammerがいるんだろ。
System EngineerはOS書いたりするヒトのことか。
だとするとそんなに数いないから、全米でボロい仕事の一位にはならんよなぁ？

613 ：

>>612
OS書いたりする人はプログラマでは。プログラム書くんだから。
基本設計〜コーディング〜総合テストまで出来るのが本来のプログラマ
SEというのがよく分からないけどＳＥ能力が全くないプログラマはいないはず

614 ：

坂村先生の日本人論はあまり役に立たないけど、「独自技術の開発をやめたら終わりだ」という
のは正しいと思う。ハード／ソフト論も理論家／技術家論もあまり意味はない気がする、というのは
「ソフトウェアのモジュールの界面は粘土のように切れたりくっついたりするので、標準というものに
重みがない」という話のように、そもそもソフトがあることによって境界がどんどん変わっていくのが
ソフトなんじゃないんですか。

615 ：

>>612
> きっとこのランキングに入らないとこにProgrammerがいるんだろ。
外人はソフトウェア部品を買ってくるのが上手いし
ソフトウェア部品を作る、小さな会社がいっぱいある。
フルスクラッチな日本ほど、プログラマの人数が要らない。
またプログラマは、プログラマ兼　部品デザイナ・販売の人になる。

616 ：

>>607
大学うんぬんもあるけど
アメリカは俳優にしても、新聞記者にしても、医者にしても
素人を許さない。日本みたいに肩書で許してもらえない。
例えば、アメリカの医者は大学を出た後に
何年も下積みを重ねて、ようやく専門家となる。
日本みたいに医師免許だけ取れば、誰でも専門医を名乗れるのとは
ワケが違う。
新聞記者もアメリカは、地方紙からだんだん成り上がって
ようやく一流紙の記者になる。
その後も一流紙という看板ではなく、個人の署名記事で勝負しなければならない。
アメリカの俳優は、どんなに有名でも毎回オーディションに出て
競争をして役が決まる。日本みたいに大手プロダクションが決めるわけではない。

617 ：

アメリカは日本以上に学歴主義だけど
それは専門性を追求するためで
専門家としての目に見える修行プロセスを
求められるし、専門家になれば専門家として優遇される。
仕事も専門性の範囲内で割り振られる。
日本は素人主義で、学歴の評価はおおざっぱ。
学校を出れば、それでお仕舞い。
どんな専門家でも、専門性より一般性を求められる。
何でも屋を求められる。

618 ：

>>613
> SEというのがよく分からないけどＳＥ能力が全くないプログラマはいないはず
SE能力だけで済むようなものは、パッケージで済ましてしまう。
ユーザー企業はパッケージに業務を合わせてしまうので
カスタマイズも不要で、プログラムせずに終了。
逆にプログラミングが必要なものは、特殊なものだから
アジャイルで作りながら、設計もする。
プログラミングが出来ないSEとか要らない。
また人材派遣も関係ない。ユーザー企業が直接雇う。
不要になったらクビにする。
中間搾取がないから、高給取りだし
雇う目的がはっきりしているから、それ以外の仕事はしない・させない。

619 ：

インハウスのプログラマはアメリカにゃいねぇってか？
んなわきゃねーだろ。

620 ：

>ttp://cruel.org/freeware/magicpot.html
>ほとんどのインハウス開発のコードは、その環境と密に統合されているので、
>それを再利用したりコピーしたりするのはとてもむずかしい（ここでいう「環境」
>というのがビジネスオフィスでの事務手続きであっても、コンバイン刈り
>取り機の燃料噴射システムであっても話は同じだ）。だから、環境が変わるに
>つれて、ソフトをそれに適合させるために、たえずいろんな作業が継続的に>必要になってくる。

>　これは「メンテナンス」と呼ばれていて、どんなソフトエンジニアでも
>システムアナリストでも、これがプログラマの賃金の大部分（75% 以上）を占め
>る点には同意するはずだ。

621 ：

アメリカのIT業にバラ色の夢を見るスレはここですか？

622 ：

日本のソフトウェア業界からSystem Engineerを追い出して、
Software Engineerだけの世界を作ればいいだけ

623 ：

>>621
http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h20/html/k1222000.html
とか見ちゃうと、アメリカのあまりの凄さと
日本のあまりのダメさが歴然としているからな。
まさにガラパゴス。これぞガラパゴス。
>>622
受託開発オンリー状態を止めれば
システムエンジニアとプログラマの多重請負構造なんて
要らないんだけどねー。
業界秩序が自由化される（既得権益から見れば滅茶苦茶になる）から
そういう区別は残しておいて、上流の俺たちを優遇しろ的な主張。
・・・この１０年間で、政府からぶんどった金は10兆円以上で
９９％無駄金にしているけど、誰にも叩かれないという
不思議ガラパゴス。
まあこの国はあと１０年かそこらで滅びるよ。

624 ：

でも受託開発も誰かがやらないと困るよねぇ

625 ：

パッケージでいいじゃん。
特に政府系の仕事なんて
日本全国で仕事のやり方を統一して
同じシステムを使えば良い。
韓国みたいにオプソのパッケージにして
ばらまけば、同じものを１２兆円もかけて作る必要はない。
どんだけアホかと。

626 ：

公共事業は大切だよ

627 ：

同じものを作ることに
金をかける意味はない。
政府や大企業が支えてきたシステム開発費だが
流石に限界。世界で年間１００兆円を使っている。
これ以上は金額を増やすことは出来ない。
かと言って、システム開発は続く。
となれば、重複を減らすしか無い。
車輪の再発明で商売しているようなところには
潰れてもらって、googleみたいなのを何百社も作って
オリジナリティあふれる製品を作ってもらう。
受託しか出来ない会社や技術者はイラネー。

628 ：

だが受託開発も誰かがやらなければならない

629 ：

政府がこの１０年間で無駄にした１２兆円があれば
事業仕分けでスパコンの費用をたかだか３００億円削る
なんて話は出てこなかった。
１０兆円の資金と、著作権法の改正などで
googleに負けない国産検索エンジンだって
作れたのに。
NTTデータに吸い取られた。
SEとプログラマなんて身分制度を作って、もたもたしている内に
勝ち目が無くなった。

630 ：

>>628
別に受託必要ないよ。
全部業務フローを
パッケージに合わせれば
それでおしまい。
どうせコンサルをかけても
役所の業務フローなんて弄れないんだし
リストラできないのなら
金をかける意味がない。

631 ：

ほかと差別化したい顧客がいる限り受託開発は無くならない

632 ：

>>631
現状は意味のある差別化なんて出来てないし
今後は金がないから、差別化なんて言っていられなくなる。
クラウドだなんだと、外人さんと同じものを使う間に
統一されて、受託開発なんて流行らなくなる。
今のままだと、全部外人に持っていかれて
日本のITはオシマイになる。お陀仏。

633 ：

既に死んでね？

634 ：

自民党と同じで
負けて残るのが、お爺ちゃんばっかりという状況に
なりそうだから、怖いんだよな。
お爺ちゃんはコボルくらいしか想像できないから
SEだのプログラマだのキーパンチャーだのを
今でも信じている。

635 ：

富士通の秋草とか、まだ会社にしがみついているし。
いつまで経っても、ジジイが消えない。

636 ：

公共事業そのものは悪くもなんともないわけで。
昔は大手ゼネコンが音頭取って中抜きしてキックバックしてってのが常態だった
わけだけど、今は法令で決まってるのか可能な限り地元の業者を優先して大手は
大手にしかできないような仕事を割り振るっていう状態になってるわけで。
地元の企業にできる仕事は地元の企業に振って、実績を作らせてっていうような
よい方向に循環させようとなってきているわけで。
IT関連の場合はこの地元の企業に振る部分が役所の能力不足や地元企業の
力不足でうまくいっていないわけで。 土木課みたいな部署はあってもIT課の
ような部署は普通ないからね。 若い企業も多いわけで、役所の40、50のおっさん
相手に30に手が届くか届かないかの若造が相手をしなければならないってのも
原因の一つだろうね。
このスレでも年寄りを老害扱いしてるのが沸いてるけど、IT関連の企業なんて
30過ぎれば老害扱いするような異常な業界だから難しいんだろうな。

637 ：

おいおい、土木関係といっしょにするなよ。
日本のIT関係の公共事業（特にソフトウェア系）で
上手く行ったものなんて１つも無い。
現実逃避はよくない。

638 ：

土木業の業態を持ち込んで、人売りで儲ける形にしたから
馬鹿でも入れる日本のソフトウェア業。いいじゃないか。

639 ：

このガラパゴスでは、ちっとも良くない。
富士通も、日立も、NECもボロボロで
NTTデータは海外逃亡に一生懸命だし。
５年後が恐ろしい。
国産なんちゃってクラウドが
大負けして、皆がっくりじゃねーの。

640 ：

モノ作りが上手い日本は、職人を集めて中間搾取という
やり方のみで社会を形成してきた。
従来のアナログな産業でこそ、それが長期間維持できる。
だが、上で管理してるモノ作れない連中達が、
昔通りの高コストなやり方しか知らない状態で、
既得権益にしがみついているという日本社会のスタイルは、
なんでもかんでもデジタルに変わっちゃった時代においては、
めまぐるしく変わるモノ作りの変化に対応できないのさ。

ことITに関しては、肝心のモノが作れる職人の地位が最低ランクにあり、
そこが育たなかったのが全ての敗因だな。
かたや外国には職人がいっぱい！　しかもまだ円は高い水準。
だから外国に逃げるって安直な方向へ進むのさ。
で、モノ作れない奴らが仕切ってるような会社が、
PGだけ海外に委託なんて成功するハズないし、
結局事業全部○ごと海外へ投げるしか成功する術は無いんだよなｗｗ

641 ：

datte

642 ：

使えないPGがSEや営業にまわる。
これが本質。

643 ：

俺たちは日本のSIer業界の終末に
立ち会っているんだ。

644 ：

>>642
そのSEや営業より給料安かったり、見下されるPG
これが現実
今のプロジェクトリーダーがそんな感じの人だから困る

645 ：

プロジェクトリーダーに必要なのはカリスマ性のみ

646 ：

プロジェクトリーダーに必要なのはカリダカ性のみ

647 ：

パリダカに出ないといけないのかー

648 ：

プログラマーをなんか特殊能力者だとおもってるやつが居るな
コード書くだけじゃん、あんなの。設計の方が偉いのはあたりまえじゃん

649 ：

そうだよ。コード書けること、あるいは設計できること自体は、大してスゴくないよ。
「動けばいいや」的な稚拙設計＆コードでは、デスマや保守地獄プロジェクト必至。
その程度の開発者が飯食えてたってこと自体が不思議だが、
使う側に人を見る眼が無いってのが諸悪の根源なんだろう。
「プログラムを書ければ凄い」とか「設計できれば凄い」程度の判断しかできねえんだろうな。
その辺りにも多分「人月神話」ってやつが絡んでくるんだろう。
何日でどれぐらいの量を設計、あるいはコードを組んだから凄い…みたいな。
そんな評価でいいのなら、レベル低ければ低い奴ほど、高いパフォーマンス出してくるだろうさ。
で、案の定、使い込めば使い込む程障害が沸いて出てくるようなブツになっちまうと。
さらにメンテナンス性は最悪と来たもんだ。
そんなプロジェクトの火消せって言われても無理だってば。
何度「作り直した方がいいですよ」って台詞が喉まで出かかったことか。

650 ：

じゃ作り直してみっか、ってやるともっとひどいもんになったりするがな。

651 ：

作り直し系のプロジェクトってタマにあるけど、大概
予算も納期も元の1/3とかあればいい方って感じだよね。
よっぽど自信あるとこが引き受けるんだろうけど、
えてしてプロジェクト管理者に体育会系が採用されて、
全てを台無しにしちゃうｗｗ
デスマ確実＆予算納期は元より厳しい→もっとひどいもんになったりする
あるあるｗ

652 ：

何でも自分のせいじゃねーって言える立場でいいよな、コーダーは。

653 ：

不具合は全部人のせいにするSEがいるくらいだからな

654 ：

作り直しならいちから仕様考えなくていいんだから
1/3あれば十分だよね

655 ：

それは、作り直しじゃなくて、単なるプログラムし直しｗ

656 ：

仕様まで変えるなら新システムじゃん

657 ：

最近のクライアントも学習してるので、同じ設計書使ってPGフェイズからやり直したって、
同じ結果にしかなんねえだろってのが分かるようになってるから、そんなのゴーすら出して貰えん。
また、最近は完全な買い手市場で、設計までやった時点でクライアントがノーと言うケースが多いから、
同じ要求仕様のまま設計からやり直しなんてプロジェクトは非常に多いな。

658 ：

カットオーバーに前後して燃え上がって人がんがんつぎ込んで予算の3倍をばらまく結果になるんですね

659 ：

で、注ぎ込めば注ぎ込む程、仕様策定の鬩ぎ合いが激しくなり、
挙動が不安定になっていくんだよなｗｗ
そして客からの一言で、全てが終了
「金は出せない」
そして、振り出しに戻り、第二の犠牲者探しへとｗ

660 ：

他人の糞コードいぢりたくないから、
とかいう奴ほどろくなもんじゃねぇしな。

661 ：

海外
コンサルタント
チーフアーキテクト
ソフトウェアアーキテクト
ソフトウェアエンジニア
この体系を導入すると、専門性の低い国内SEの何割かは営業職にでもなるしかない。
まあ、海外の場合、それなりの学位という資格取得者の仕事で、プログラミングができないということはない。

662 ：

日本は最初から専門性とか技術力なんかで勝負してないから

663 ：

日本人はPGでもSEでもPMでも
教養としてMBAの基礎程度は身に付けるべき。

664 ：

>>648
家と一緒じゃね？
設計が下手なら大工が良くてもいい家は建たない。
設計が良くても大工が下手だったらいい家は建たない。
いい家を建てるには設計も大工も良くないとダメだな。
あと、どっちが偉いって話じゃない。

665 ：

アメリカに憧れる人は多いみたいだけど、そんなに甘い話はないさ
自分の技術に自信があるなら渡米してみるといいよ
あっちの学歴差別は半端ないぞ

666 ：

ただし単純明快だから日本みたいな理不尽さはない
キミは技術も実績も乏しいから解雇、とズバッと言われて終了
日本の場合は納得のいく説明が得られることはほとんどない

667 ：

>>665
>あっちの学歴差別は半端ないぞ
逆だろ。日本の学歴無視は、世界的に見ても異常。

668 ：

教育の仕方が違うのに、何を逝ってるんだろ

669 ：

教育の仕方云々じゃなくて、
院まで行ってなきゃ相手にされないところもおいし
大学のランクも非常に重要
まあPGの世界でどうかはしらんが非常に学歴をみる社会なんだしそれなりに学歴によりさべてはされるだろう
低学歴の俺らじゃむこうでも通用しないよ

670 ：

英語がしゃべれないと相手にされないの間違いでは？

671 ：

>>665
＞アメリカに憧れる人は多いみたいだけど、そんなに甘い話はないさ
自分も外資系で稼げるほど実力に自信があったわけじゃないんで、あえてこの道を選んだ。
159 名前：1[] 投稿日：2011/03/01(火) 17:17:29.27
親父に「もう出て行け」と言われたのに号泣して、「頼みますか
らここに住まわせてください」と土下座。んでこの大都会の
マンションの一室で、今日もパソコンに向かってブツブツ独り言。
社内失業〜企業に捨てられたﾌﾟﾛｸﾞﾗﾏｰ
http://hibari.2ch.net/test/read.cgi/prog/1297248142/

672 ：

実は日本のIT企業でも、富士通とか日立製作所とかは、外資に劣らず優良。
能力に自信あるならそっちへ行けばいいだけで、ここでブー垂れる必要無い。
富士通グループって、優良でまともなじゃん。
http://hibari.2ch.net/test/read.cgi/prog/1305010886/
日立グループって、優良でまともなじゃん。
http://hibari.2ch.net/test/read.cgi/prog/1129376704/
リーマンショック以前なら、できる人は大手か外資に転職していったことだろう。
できる人から辞めていく
http://hibari.2ch.net/test/read.cgi/prog/1126181692/
俺？　残りカスｗｗ

673 ：

>667
嘘つき

674 ：

F2とか目立ちと言っても、団塊世代のPMとか普通に「高卒」が
幅効かせてるもんな。学歴無視と言うよりむしろ逆学歴社会。

675 ：

【社会】女児の尻触ったＳＥ逮捕・・仙台
http://raicho.2ch.net/test/read.cgi/newsplus/1307264215/

676 ：

>>670
英語が話せるのが前提だろそもそも
向こうで稼ぎたければ向こうの名の知れた大学の学士か修士を取る必要がある
一度俺もアメリカにあこがれていろいろ調べて絶望した

677 ：

嘘かもしれないけど、通訳付きってのを聞いたことがある

678 ：

>>649
上流工程のSEさん(お客様)は数字で「生産性」見てるからな
コーディング　ステップ/月　とか仕様書ページ数/日とか　テスト　バグ数/ステップとか
ほとんど同じコードをコピペして5本10本と水増しするのが一番生産性と利益が上がる結果に

679 ：

よく見たら二年近く前のカキコにレスしてしまったwww

680 ：

構造化だのオブジェクト指向だのすればする程、ステップ数が減るので、
生産性、単価が下がる、奇妙な日本のIT業界。
COBOLやBASICをコピペしてる猿が評価される結果に…

681 ：

ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R
ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R
ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R
ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R ど田舎富山肉体労働男R

682 ：

まじでSEをなくそう
プログラマが全部やればいいだろ

683 ：

>>682
ていうか、実際ほとんどの現場でプログラマが全部やってるし。
結局間に挟まって仕事増やしてるだけ
そんな会社は無駄が多いことを客にバラして、さっさと潰した方がいい

684 ：

キミはプログラムの実装が出来ないからＳＥやってねw
的な会社が多いぞwww

685 ：

設計は実装の事も分かってないとできないからな。
当たり前の事だけど。

いかにしてユーザの要求をコーディングに実現するか。
どうすれば、短期間で最高の品質を確保できるか。

要求定義からコーディング、それにかかわる周辺知識など、
あらゆる知恵を総動員させて初めてできるのが、設計だと思うのだわ。

686 ：

なんかこのスレ病んでる人多いね

687 ：

>>685
顧客の要求に対して常にＹＥＳマンであることが一番求められる事だな。
それをそのまま実行したらどういう結末になるかが
予想できるようでは良いＳＥとは言えない。

688 ：

つまり、先が読めない馬鹿がSEに向いてる、と。

689 ：

馬鹿は自然にSEになれる・・・ってことなのか？

690 ：

そうだよ

691 ：

炎上プロジェクトの火消し役でこれで4回目なんだけど、
これだけやると炎上プロジェクトの共通点が見えてくるんだよね。
・監督しかいないサッカーチーム
みんな「あれだよねこれだよね、こうすればいいんだよね」と
解決策は饒舌に語るが誰一人としてそれをやろうとはしない。
そして毎回同じ問題と同じ解決策の話が繰り返される。
・具体的な指示のできない親SE
技術的な問題などに直面していても「頑張れ」とか
「気合入れて」とかしか言えない。応援団かよ。
・意味のないスケジュール
なんで3.0人日の作業が1日で3つも4つもあるんだ？
スケジュールの線が滅茶苦茶になってるぞ。
通勤ラッシュ時の地下鉄運行表かよ。

692 ：

>>691
こんな奴とかプロジェクトもやばいよ
安請け合いする
見積もりがいつも楽観値
客のわがままを飲んでしまう
客の曖昧な要望をのんでしまう
仲間への仕事の振り方が雑
そのわりに出来た物に文句を言う
そして一人で全部やろうとする
結局終わらずに責任のなすりつけあいをはじめる
口は出すが手は出さない
口を出すとやらされそうだから知らないふりをする
仕事は依頼するが情報は隠す
自分だけ成果が出る状況を作ってできるやつアピールをする
会社の利益を考えていない
頭が悪い性格も悪い顔も悪い
指揮系統がなく相談もしない
陰口を言う

693 ：

選手の居ないサカつく、だな。
(派遣)SEを要請する客先上司なんて、サイコパス狂人ばっか。

694 ：

業務アプリのＳＥなのにＳＱＬを知らないと言うアフォＳＥ
早く撲滅してほしいものだ。

695 ：

>>694
いるよな、生データを見れないＳＥは例外なくダメＳＥ
ＳＱＬ使えなくてもアクセスやらＤＢツールやらで中身を必死で見るならＳＱＬを使いこなせなくてもいいんだけど
生データが見れない奴は妄想を語るようになる

696 ：

>>680
コピペしてる猿が評価されるのは生産性がよいからじゃないのか？
オブジェクトは経験積むほど過大評価されすぎている事に気づく
程度にもよるがガチガチのオブジェクト指向は可読性や生産性がものすごく悪い
メンテとか保守性が高いだけだぞ

697 ：

>>695
アクセスやパーシステントストア使っている奴は
サロゲート・キーが基本のバカが多くてダメよ。
覚える順番はどうでも良いと思うが、従来技術の
SQL や ER図 を踏まえた上でないとタイトな
DB 構造にはならんと思う。

698 ：

http://itpro.nikkeibp.co.jp/article/COLUMN/20130314/463434/?ST=cio&P=3
　自動車メーカーや精密機器メーカーのエンジニアたちと話をすると、
彼らがSEをエンジニアだと認めていないことがよく分かります。
残念ながら、日本のSEは「エンジニア」と言えるほどの技術力を持っていない人が多い、
という見解らしいのです。
　海外からもそう思われているようです。私がITproで『ダメな“システム屋”にだまされるな！』を
連載していた時に、米国帰りのSEから電子メールで意見をいただいたことがあります。
「日本のSEとはデータモデリングのような込み入った議論ができない」と嘆いていました。
日本の他の分野のエンジニアからも、米国基準のSEからも、日本のSEは
「ちょっとおかしい」と思われているようなのです。

699 ：

>>696
そのメンテとか保守性は見積りに一切含めないんだよな
糞が

700 ：

大量のコードを書くのが生産性高いとか思ってるのが少なくないからな。
トリッキーじゃ無い短いコードを書くように心がけてると作ってないと思われるしな。

701 ：

それ何て三菱MDIS?
3000回ループ1行を書いたら仕事してないと叱られて、マウスでコピペ3千回
やってたコピペ猿が褒められてた。

702 ：

そんなレベルの低い話してどうしたいのかわからん

703 ：

ステップ数(笑)
人月単価(笑)

704 ：2013/06/10

>>701
俺ならそこでは3000行のプログラムを吐く、数行のプログラムを書くな。