内製化の動きになってるけどお前らどこに行く予定？ [無断転載禁止]©2ch.net

**仕様書無しさん** · 2017/09/30(土) 08:12:12.96

優秀なお前らならそこそこの知られたユーザー企業にヘッドハンティングされるんだろ？

**仕様書無しさん** · 2017/10/18(水) 22:52:25.95

仮想非プログラマーとして最適な人材だったんじゃね？

**仕様書無しさん** · 2017/10/18(水) 23:01:44.12

>>127
システム管理してた派遣が猛プッシュしてノンプログラミングツール導入の後押しをするという変な事情があったんだ
プログラムも出来る派遣の俺が来たから焦ったのかも知れない
でも、当の派遣はほどなく転職してプログラム出来る俺がノンプログラミングツールを使うという訳の解らんことに
根本的に正社員の責任者がグダグダだっただけなんだけど変な話だ

**仕様書無しさん** · 2017/10/18(水) 23:17:20.89

>>128
非プログラマの奴が転職したから俺が犠牲になっただけ
つか非プログラマの奴はSQL知らないと使えないと知るや逃げた感じ

**仕様書無しさん** · 2017/10/20(金) 19:00:40.36

SQLの知識って構文くらいだけど？
GUIのエディタってのがどんなものか知らんけど普通にSQL知らなくても使えるだろそれ

**仕様書無しさん** · 2017/10/20(金) 23:07:17.35

最初にちゃんと設計してれば使い物になるだろう

とっつきにくいしコピペしにくいし操作しにくいしフラストレーションたまりまくりで
体感的にパフォーマンスいい感じは全くしないが
最終的な成果物の観点から見たら結構いい線いってたり

しないか

2017/10/22(日) 07:23:31.29

プログラマだけど、派遣でプログラミングを使わないところに行く＝正解

ものによっては、桁違いに効率化・自動化できるので、「無双神がきた・・・。」ってなるｗ
プログラマは、開発会社に行くよりユーザー企業に行ったほうが良い。

2017/10/22(日) 09:52:38.82

>>133
女が事務員でVBAが最強なんだよね

男は現場募集が多くて役に立たない

2017/10/22(日) 10:14:52.11

だいたいどこの現場でもVBAとマウス＆キー自動化ツールは役に立つよ
最近は簡単なスクレイピングも需要が高まってきた
本業のプログラミングより些細なテクニックのほうが人の評価を決めるよね

2017/10/22(日) 11:50:59.97

25年くらい前にEnd User Computingが流行ってた頃みたいな会話だな

2017/10/22(日) 11:53:59.63

内製化ってようするにそれだろ？

2017/10/22(日) 13:23:07.76

>>136
あのころは、winsockすらなかったからな・・・。

2017/10/22(日) 19:48:05.09

tcp/ipすら

**仕様書無しさん** · 2017/10/23(月) 00:34:10.63

いや、あっただろ

**仕様書無しさん** · 2017/10/23(月) 01:30:37.14

25年前なら92年
まだ普及してない
一応選択肢の1つとしてある程度で主流でもない

**仕様書無しさん** · 2017/10/23(月) 01:58:32.43

ああ、まだ愚民には開放されてなかった頃か

**仕様書無しさん** · 2017/10/23(月) 07:07:11.15

VBAが最適解な気がするけど、派遣先の無能指揮者がデータベースをExcelシートと見なしてVBAでデータベースシステム開発とか恐ろしい会話してるの聞いたからVBAは廃止して欲しい

**仕様書無しさん** · 2017/10/23(月) 07:09:35.22

VBAによって表計算ソフトがデータベース用いたシステムのように振る舞えるからヤバイ

要求が際限無くなる

**仕様書無しさん** · 2017/10/23(月) 08:01:56.51

ExcelのACID特性的に同時利用できないクソシステムにしかならなそう

**仕様書無しさん** · 2017/10/23(月) 18:12:35.65

ユーザ企業が本当に欲しいのは自分たちの仕事を知っている人
プログラム知識なんて二の次
水道使う人間の大半が加圧ポンプに興味無いのと同じ

**仕様書無しさん** · 2017/10/23(月) 22:22:33.39

ポンプ誰が直すんだよ

**仕様書無しさん** · 2017/10/23(月) 22:26:20.40

何が同じなのか全くわからんｗ

**仕様書無しさん** · 2017/10/23(月) 23:24:47.39

エクセルからDBに接続したらいいじゃん？

**仕様書無しさん** · 2017/10/24(火) 03:54:00.19

Microsoft Queryは結構つかう

**仕様書無しさん** · 2017/10/24(火) 06:14:46.15

>>146
そして、自分たちがそれであることを内製始めると気づく

**仕様書無しさん** · 2017/10/24(火) 13:42:47.70

自分の仕事の効率化なんて
自分でやろうと思わない限り、効率的なシステム導入してもサボるだけ

ところが

自分で企画や設計等々した場合は、成果をアピールしたくて、実は効率化してなくても的パキ作業をこなそうとして、結果、効率化される

**仕様書無しさん** · 2017/10/26(木) 02:22:57.74

>>146
それで問題になるのが

1. 業界の大体の仕事の流れわかるけど、あんたの会社特有のことなんか知らんで
2. あんたの会社の状況は察して手はあるけどナンボで買うの

のどっちかじゃないかなぁ

1の場合はSEとか
何となく話は合うけど実物見たらオカシイというアレ、欲しかったものじゃないってやつ

2の場合はコンサルだが
実務とITの両者を踏まえている人は人月単価高く、実務しかわからん人はゴミ設計（つまりリリースされない）、IT寄りは上記のSE状態になる

みたいなやつ
安価 or フリーかつカユイところに手が届いて俺ハッピー、なんてのはあんまりないんだろう

**仕様書無しさん** · 2017/10/26(木) 07:12:31.38

>>153
その場合

1.安価な有能()コーダーのお前

だとどうなるんじゃ？w

**仕様書無しさん** · 2017/10/26(木) 09:13:27.66

１　いつでも、気軽に仕様を聞ける。使って試してもらえる。
２　仕様を聞くのに５社くらい人を経由する。本番前に使ってもらうのは検収時のみ。

前者と後者では、当然前者だから内製が圧倒的に優っているのは確実
内製回帰は当たり前過ぎる話

**仕様書無しさん** · 2017/10/26(木) 12:27:14.24

受託でも「いつでも気軽に仕様を聞けて、使って試してもらえる」ような仕事の進め方はできるけど、技術力や調整力がないと厳しいな

**仕様書無しさん** · 2017/10/26(木) 17:47:31.69

>>153
○○の実務経験あり
JAVAフレームワークで2年以上の開発経験
サーバ選定から運用までできる人
フルタイム月給16万円

これで解決や
ハロワ行けばウジャウジャあるでこんな求人

**仕様書無しさん** · 2017/10/26(木) 17:51:11.45

>>155
内製だけど派遣で入ってて指示者は不在がち&瞬間湯沸かし器

挙句に瞬間湯沸かし器の上司から君は何をしたくてここに来たのかと怒られた

指揮者に言えよと思った

**仕様書無しさん** · 2017/10/26(木) 18:54:57.25

何させたくて呼んだんだよ
と言いたくなる事例

**仕様書無しさん** · 2017/10/26(木) 19:11:13.40

>>158
瞬間湯沸し器に対しては、徹底してこっちも瞬間湯沸し器になったほうがいい。

**仕様書無しさん** · 2017/10/26(木) 20:12:36.31

指示者が忙しいから
上司が派遣を雇った
って図だな

ただ雇っただけ

**仕様書無しさん** · 2017/10/26(木) 23:43:02.62

>>157
うじゃうじゃあるってことは、誰も応募しないってことだよね

**仕様書無しさん** · 2017/10/27(金) 08:05:17.31

求人で月給欄見てるやつは素人

**仕様書無しさん** · 2017/10/27(金) 12:31:33.23

>>162
3人応募ありやったで

**仕様書無しさん** · 2017/10/27(金) 19:25:05.86

>>17
ろくなのこねーのが目に見えてるからだよ

**仕様書無しさん** · 2017/10/27(金) 19:29:44.95

>>39
一般企業の社員というのはシステム以外にやる事たくさんあるんやで…

**仕様書無しさん** · 2017/10/27(金) 19:30:48.46

>>55
てなるわな

**仕様書無しさん** · 2017/10/27(金) 20:15:12.30

>>131
その構文がみんなわからんのや…

**仕様書無しさん** · 2017/10/28(土) 01:49:50.14

>>166
要するにIT以外の仕事もするんだろ？
店頭でハンドマイク片手に呼び込みしたり
ポップのデザインしたり
パソコンが壊れたーっていってるおばちゃんのコンセント挿しにいったり・・・

それってプログラマが嫌がることじゃないかな

**仕様書無しさん** · 2017/10/28(土) 01:50:55.55

>>131
業務の胆はSQLで表現して
プログラム側じゃインターフェースしか作らないのが今の流行りだろ

**仕様書無しさん** · 2017/10/28(土) 10:48:57.37

【貧困生活】派遣残業は結婚障害【家事困難】
両親や親戚に反対されましたが、低収入なのに時間外労働違反業界のSEと結婚してしまい生活困難で中絶と離婚をしました。現在は低稼働高収入で共働き可能な相手と結婚して数億円損失を防げました。
・モラルがない
・モテない
・キモい
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・プログラムの知的財産を人売に提供
・ITスキルが高いのに低収入
・高度情報処理技術者なのに低収入
・高利益なのに低収入
・高生産なのに低料金
・高需要なのに低料金
・学習多いのに低料金
・人員不足なのに早期退職
・会社員なのに早期退職
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・不利益なのに断らない
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判定不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf

**仕様書無しさん** · 2017/10/28(土) 14:05:17.67

>>170
ORMでSQLを書かないのが主流ですが？

**仕様書無しさん** · 2017/10/29(日) 10:34:40.80

効率を犠牲にするORMは糞

**仕様書無しさん** · 2017/10/30(月) 00:18:54.83

単純なとこはORMで書くのはいいと思うよ
単一テーブルにSELECT投げるだけでSQL書くのは効率悪い
ただ、SQLのほうが文字数少なくねって思うときはある

**仕様書無しさん** · 2017/10/30(月) 00:51:43.71

>>170
いつの時代の話だよ

**仕様書無しさん** · 2017/10/30(月) 00:52:37.04

身もふたもない言い方をすると負荷試験や運用でどうやっても
パフォーマンスが出ないところだけSQLにすればいいだけだよ。

ORM使ってるのにSQL書きたがる人は周りに自分のSQLﾁｶﾗを
見せつけたいだけで、本人が考えているほどSQLでよかったと
いう場面はないからね。

**仕様書無しさん** · 2017/10/30(月) 01:04:17.69

プログラム書けるけどSQL書けません、ってすげー変な話

**仕様書無しさん** · 2017/10/30(月) 01:08:30.05

SQL書けないからORM使ってるって勝手に決めつけて、SQLが書ける俺の方が上だと思い込む
そんなやり方で自尊心維持して満たされるのか？

**仕様書無しさん** · 2017/10/30(月) 01:22:05.30

複雑でパフォーマンスが必要なSQLは誰でも書けるわけじゃないからな。
誰でも書けるSQLなんてORM使ってるならわざわざ書く必要もないし。
そういうのが分からないのがSQL書きたがりなわけで、面倒だよねと。

**仕様書無しさん** · 2017/10/30(月) 07:14:55.51

組込ならともかくDB使ってるのにSQL書けないなら相当やばいと思うよ。
業界から足洗ったほうが良い。

**仕様書無しさん** · 2017/10/30(月) 07:20:30.93

>>179
なるほど書けない人はそう考えるのか勉強になる

**仕様書無しさん** · 2017/10/30(月) 07:54:16.35

ORMはすべて出来損ないのラッパーだ
すべてクソ
だが唯一.NETのLINQのみが新しい価値を提供している

**仕様書無しさん** · 2017/10/30(月) 07:54:42.94

クソを有難がるプログラマーもクソ

**仕様書無しさん** · 2017/10/30(月) 08:01:57.78

>>181
書けると思い込みたい人はそう考えるのか勉強になる

**仕様書無しさん** · 2017/10/30(月) 08:10:57.83

>>182
LINQはORMじゃねーよ

**仕様書無しさん** · 2017/10/30(月) 12:35:57.87

LINQってORマップしてくれるの?
俺はエンティティフレームワークで作ったDTOに使ってるけど

**仕様書無しさん** · 2017/10/30(月) 13:01:05.40

>>186
いろいろと混同しちゃってるんよ

**仕様書無しさん** · 2017/10/30(月) 15:36:59.88

ワイORM使い
SQL？多分そこらのアンチORMの連中より書けるよw

**仕様書無しさん** · 2017/10/30(月) 19:31:39.97

俺なんて足で書ける

**仕様書無しさん** · 2017/10/30(月) 19:34:47.21

セキュスペ持ちの内製開発リーダーが居るけどプログラムよく知らんから関数禁止だと

こんなのに寄生されたらお終いだな

**仕様書無しさん** · 2017/10/30(月) 20:21:20.42

プログラムと関数と何の関係が？？？？

**仕様書無しさん** · 2017/10/30(月) 20:22:29.28

というかセキュスペ程度で言い負けるの？ｗ
セキュスペなんてスペシャリスト系で最も簡単。しかも応用よりも簡単なんだから・・。

**仕様書無しさん** · 2017/10/30(月) 20:34:11.19

実行計画確認するのめんどくさい

**仕様書無しさん** · 2017/10/30(月) 21:22:07.66

>>185-186
あれLINQtoSQLは？

**仕様書無しさん** · 2017/10/30(月) 22:15:36.21

>>194
LINQ = LINQ to SQLではない

**仕様書無しさん** · 2017/10/30(月) 22:17:38.42

>>194
LINQって、単にIEnumarableを実装した型に対する処理を透過的に書くための仕組みやで

**仕様書無しさん** · 2017/10/30(月) 22:50:27.76

透過的てなんやで？

**仕様書無しさん** · 2017/10/30(月) 22:56:33.05

>>197
この場合は、実装を意識せずに、くらいの意味

**仕様書無しさん** · 2017/10/30(月) 23:06:10.21

ORMのほうが面倒臭くね？
シンプルに書けることをあそこまで複雑にするんだ？
それともPHPのフレームワークだけ特別クソなのか？

**仕様書無しさん** · 2017/10/30(月) 23:15:52.91

どちらのフレームワークで？

**仕様書無しさん** · 2017/10/30(月) 23:20:47.71

>>199
PHPじゃーしょうがない

**仕様書無しさん** · 2017/10/30(月) 23:23:57.96

実行時にSQL生成って効率悪いだけじゃない？

**仕様書無しさん** · 2017/10/30(月) 23:26:48.26

その前にPHP自体の効率が悪いからgoで書いた方がいい

**仕様書無しさん** · 2017/10/30(月) 23:37:49.77

50ページくらいのちっこいweb業務アプリ作るのにentity framework使ったがまあまあ良かったよ
コードファーストつよい
生成されるSQLは凄いことになってるけど…気にしないことにした

**仕様書無しさん** · 2017/10/31(火) 00:09:09.01

>>204
パフォーマンス求められるとこだけDapper使えばいいからね
他はEntityFrameworkでも十分

**仕様書無しさん** · 2017/10/31(火) 07:11:26.08

>>192
正社員リーダーの時点で派遣だから負けるわ

クラス設計禁止の品質のソフト納品してて大丈夫かなと思う

上の部長が組み込み畑出身でコードを評価出来ないのも酷い

**仕様書無しさん** · 2017/10/31(火) 07:14:12.88

>>205
俺は最初からダッパーにした

MSの簡単にする仕組みはトイプログラム超えると逆に使い難いイメージが強い

**仕様書無しさん** · 2017/10/31(火) 12:37:10.73

>>199
俺もそう思う
丸ごとコピペならそりゃ楽だろうが

**仕様書無しさん** · 2017/10/31(火) 16:34:53.62

DBのテーブルと1対1になってるDTOみたいなのがあって、そいつにクエリの結果を詰め替えるだけの用途なら、そりゃORMはオーバーテクノロジーだよ
オブジェクトグラフとDBのマッピングに使うもんなんだからさ

**仕様書無しさん** · 2017/10/31(火) 18:02:29.00

>>209
Dapperならそれでもオーバーだとは思わんけどね

**仕様書無しさん** · 2017/10/31(火) 19:53:52.43

>>209
正にその考え方がナンセンスなんだよ
異なるパラダイムは異なる物として扱えばいいのに
無理やり一緒にするからおかしくなる

**仕様書無しさん** · 2017/10/31(火) 21:51:29.22

>>211
ちょっとなに言ってるのかわかんないw
異なるパラダイム（オブジェクトとリレーション）を異なるものとして扱うためのORMじゃん
それとも、テーブルと1対1のDTOを用意するのが「異なるものとして扱う」ってこと？
それ、データ構造がDBに寄ってるじゃん
異なるものを異なるものとして扱えてないよ？

**仕様書無しさん** · 2017/10/31(火) 22:01:43.88

>>211
多分お前ORMがなんなのか理解してないわw
別に俺もORMが正義だとは思ってないし、常に使うわけでもないから、別に勧めはしないけど、
自分の用途に合ってない、そもそも用途もよくわかってないものを否定するのはイチャモンやで～

**仕様書無しさん** · 2017/10/31(火) 22:02:22.35

だからお前らは使えないんだよ
そんなとこユーザーは求めてね～から

**仕様書無しさん** · 2017/10/31(火) 22:11:43.54

>>214
ユーザーは「ORMを使わないこと」も求めてないやで～

**仕様書無しさん** · 2017/10/31(火) 22:14:42.82

SQLを内部発行するDaoをいっしょうけんめい手作りしてます

**仕様書無しさん** · 2017/10/31(火) 22:16:02.63

ユーザーは効率のよいシステムを求めている

開発者の自己満足は求めていない

**仕様書無しさん** · 2017/10/31(火) 22:22:03.05

ORMでコーディングするよりSQL書いたほうが文字数少ない（タイピング数少ない）んじゃない？

**仕様書無しさん** · 2017/10/31(火) 22:27:59.58

>>212
WHEREやJOINを一生懸命オブジェクト繋ぎ合わせて表現してるの見ると笑えるわ。
オブジェクトに拘るあまりシンプルな表現を見失ってる。
結局ORM自体が中途半端に頭の良い奴が考えた壮大な勘違いだろ。

**仕様書無しさん** · 2017/10/31(火) 22:31:27.35

RDBをオブジェクト指向で表現しようとしたものがORM。
異なるパラダイムを片方のパラダイムに無理やり寄せた結果だろが。

**仕様書無しさん** · 2017/10/31(火) 22:35:16.12

うーん、やっぱORMで書いたコードは汚いわ
雑魚プログラマにDB触らせないための苦肉の策にしか見えん

**仕様書無しさん** · 2017/10/31(火) 22:35:30.03

>>217
あんたのシステムがどんだけ速いのか知らんけど、俺は俺のシステムが必要十分な速さで動くことをよーく知ってるから余計な心配やで～

**仕様書無しさん** · 2017/10/31(火) 22:37:03.31

>>218
SQL書く手間を省くためのものじゃないからw
それは初心者にわかりやすくスゲーと言わせるための、本質じゃない部分やで～

**仕様書無しさん** · 2017/10/31(火) 22:37:52.88

チューニングを頼まれる場合
ORMのシステムは基本的なとこ出来てないけど
SQLのシステムはどうしようもない場合が多い
どっちもどっちだろ

**仕様書無しさん** · 2017/10/31(火) 22:38:14.32

そんなに異なるはずがない
クラスっていうデータのかたまりがあってそれを格納するインデックス付けされたストレージがあって
オブジェクト指向のほうが柔軟性があるのに
DBにできることがオブジェクトにできないはずがないんだ
なぜだ

**仕様書無しさん** · 2017/10/31(火) 22:38:42.54

自分の牙城を崩されまいと必死なやつら

**仕様書無しさん** · 2017/10/31(火) 22:38:50.30

ORMってACCESSでクエリ組み立ててるノリに近いんだよな