5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

自社のシステムは自社で作らないと成功しない 4 [転載禁止]©2ch.net

1 :仕様書無しさん:2015/02/01(日) 21:17:53.91
伝言ゲームが、ゲームとして成立するのはなぜか?
それは、伝言を行う人の数が多くなれば多くなるほど、原文がどんどん改変されていくということ。つまりどんどん本来の形から変化してしまうということ。
これは、あらゆる開発の現場においても当然に発生する現象。
つまり原文・本来の形 = ユーザーの要望
これが、
元請け、2・・3・・・5・・次請。さらには、営業、SE、マネージャー、リーダー等々を経る過程において、どんどん微妙に変化して伝わってしまう。
つまり
ユーザー ⇒ 実装現場
もしくは
ユーザー ⇒ 開発リーダー ⇒ 実装現場
くらいの伝聞関係でないと、ユーザーの要望はまったく伝わらないということだ。

現代の開発業界の環境において、これを達成する方法は、
ユーザーが直接開発
ユーザーの所属する会社において自社開発
以外に存在していない。
この板で、多くみる愚痴を根本的に解決しようと思ったら、プログラマがユーザー側の会社にいないと解決しないということ。
自社開発(メインフレーム)⇒ダウンサイジング⇒アウトソーシング ⇒(そして)⇒ 自社開発
の道を選択する企業が出てくる企業は、経営陣がシステム開発の現場を理解している・理解を示している証拠。
プログラマは、愚痴るより、ユーザー側の会社に入るべきだ!
それが、できないプログラマは
無能  無評価  無価値(元請けで開発をしているケースはほとんどないから、どんなに作ってもユーザーにとって価値が無いに等しい)
であることを素直に認め、最終的に無価値なものとして使われる「技術!最新技術!」とか言ってないで、


前スレ
自社のシステムは自社で作らないと成功しない 3 [転載禁止]©2ch.net
http://kanae.2ch.net/test/read.cgi/prog/1416996537/

2 :仕様書無しさん:2015/02/01(日) 22:04:55.95
「前の人がなぞった線を、同じようになぞってください」
を500人でやってみた

https://www.youtube.com/watch?x-yt-ts=1422579428&feature=player_embedded&x-yt-cl=85114404&v=l-uNFaUJo5c

3 :仕様書無しさん:2015/02/01(日) 22:20:22.24
>>2
途中で急に大幅に変えてしまっている馬鹿を取り除くことが重要ってこと?

4 :仕様書無しさん:2015/02/01(日) 22:24:48.99
>>3
その馬鹿はこの業界ではSEをやってる事が多い

5 :仕様書無しさん:2015/02/01(日) 22:42:24.00
SEとは実に厄介な人種だね

6 :仕様書無しさん:2015/02/01(日) 23:11:43.33
事例や場所毎に問題と結果は違うけれど、

■標準的なシステムを無理やり今の自社の業務フローに合わせようとカスタマイズ盛り込んで失敗
・本当に自社業務の根本が自社の方法に依存するなら根幹に金かけて枝葉を我慢してでもフルスクラッチが正解の場合
・枝葉をカスタマイズしまくり無駄に金かけた挙句どっちつかずの使えないシステムで安定性や将来性に不安なので
 カスタマイズはユーザ企業内で厳選(業務の再認識と見直し)し、体を服に合わせる方が正解

まあ、糞システムだろうが、一般に良いシステムと言われようが、使っているうちに
効率化といって、システムを使えば答えだ出るということで、使い方しか知らない人間ばかりになる
そこはユーザ企業の問題だけれども
業務知識や理念どころか、使い方すらを引き継ぎをロクにせずに社内で人をかき回したり、
その所を派遣だとか自社にノウハウが残らないよう運用してるのも駄目な原因。

そんな所にシステムリプレースや改善にいっても聞こえるのは
・業務フローはしらない。このシステムと基本は同じで、フローに矛盾や他に問題があるか関係なく
 ここをこうしたいという局所要求がユーザ企業内で調整される事なくそのまま出る

この時点で既に失敗か金がかかるかが見えている。
システム化するまえに社内で失われた業務知識を再構築すればシステム化で失敗は減る。
現システムからどうこうでは、システム屋が現システムから仕様や業務知識を発掘する事になる

7 :仕様書無しさん:2015/02/01(日) 23:41:10.99
> 現システムからどうこうでは、システム屋が現システムから仕様や業務知識を発掘する事になる

しかもろくにドキュメントもない糞コードの場合がほとんどですわ
ユーザが業務を本当に理解している場合は、内製しようが外注しようが大ハズレにはならない
ゴミシステムを掴まされたって騒いでいる奴は、定例進捗会議や検収に意味も判らず出席してただけの馬鹿ですって
自己紹介してるようなもん

8 :仕様書無しさん:2015/02/01(日) 23:52:30.45
>>1が勘違いしてるのは、伝言ゲームは内製だろうが外注だろうが発生するということ
むしろ内製の方が、口頭と阿吽の呼吸で伝わって便利!これぞ柔軟な対応!みたいな勘違いがあるぶん
形として残らないので後々悲惨な目にあう

9 :仕様書無しさん:2015/02/02(月) 00:03:43.61
内製はいいものだ
だけど、開発に素人を混ぜるな

10 :仕様書無しさん:2015/02/02(月) 00:03:51.90
多重請負がダメなのよ
伝言ゲームっぷりが半端ないから

11 :仕様書無しさん:2015/02/02(月) 00:14:17.29
伝言ゲームになる時点で、要件を明確に示せていないユーザ側にも責任がある
そういうところが内製しても碌なシステムが作れるとは思えない
そもそも発注したものとかけ離れたシステムが納品されようとしても、検収を通らんだろ
どんな契約交わしてるのやら

12 :仕様書無しさん:2015/02/02(月) 00:26:12.58
要件を明確に示せるレベルになったら
いつの間にか内製できるようになってた、というケースもある

そんな内製部隊が居る場合でも、競争優位に関係ないような
しょぼい事務処理系のシステムは外注するけどね
つまんない仕事にせっかくの内製部隊を使いたく無いし

13 :仕様書無しさん:2015/02/02(月) 06:26:31.23
要件を明確に示せるよう
客を育ててはいけない

14 :仕様書無しさん:2015/02/02(月) 06:27:26.93
>>11
伝言ゲームはユーザー側には落ち度無いだろ
業界の多重構造が原因なんだから

15 :仕様書無しさん:2015/02/02(月) 06:30:54.19
>>12
つまるところそこに行き着くw
ユーザーが!!SEが!!レベルが低いっ!
っていう反論はすなわち、

ユーザーやSEが作れる能力を身に着けろと同義なわけ

要求や仕様をハッキリと表せるようになるにはシステム開発ができないとムリだから

結論として
内製をしなさいとなる

16 :仕様書無しさん:2015/02/02(月) 08:12:57.03
要件がまとまらないのは全てSEの責任だろ、ユーザーは別に悪くないと思う。

17 :仕様書無しさん:2015/02/02(月) 08:47:06.03
>>16
その理屈だと、SEには全ての権限も必要だが?

18 :仕様書無しさん:2015/02/02(月) 12:36:52.98
>>17
なんだ全て権限て?権限があると能力不足が解消するのか?

19 :仕様書無しさん:2015/02/02(月) 13:06:45.98
>>18
>なんだ全て権限て?権限があると能力不足が解消するのか?

この種のことを素で言うユーザばっかりだもんなあ・・・
物事の因果関係の理解の仕方から教える工数は有りませんぜ。

20 :仕様書無しさん:2015/02/02(月) 13:19:00.77
まず大前提として、社長相手の個人事業でもないかぎり
一人の人間にすべての権限があることなんて無い。

ありえない前提をもとに議論しても意味は無い。

21 :仕様書無しさん:2015/02/02(月) 13:22:57.29
>>16
君がSEだとして、俺がユーザーだとしよう。

要件をまとめてくれ。

テーマはなんでもいいぞ。だれでもわかるようなことなら。
それに合わせるから。

22 :仕様書無しさん:2015/02/02(月) 13:25:07.17
ユーザー「要件ですか?エクセルみたいな感じで、使いやすくて安いものです。難しいことはわかりません」

23 :仕様書無しさん:2015/02/02(月) 19:16:29.45
>>22
ユーザーなんだから難しいことわからないの当たり前だろ、何を言いたいの?

24 :仕様書無しさん:2015/02/02(月) 19:49:59.27
来年度からユーザー企業の情シスになりまーす
引き抜きです
うはー!

25 :KAC:2015/02/02(月) 21:20:21.73
>>21
横からすまん。

基本的に「ユーザーのやりたい事」をきき出すのがSEだから、
ユーザーのやりたいことをテーマにしないと話が進まないだろう。

この「ユーザーのやりたいこと」ってのは、
 ・いまのシステムではこんな事で困ってる。改善したい。
 ・今の仕事をコンピュータ使って楽にできないか
みたいに、話を聞くとユーザーの認識してる問題点が見えてくるのが普通。

そもそも「ユーザーのやりたい事」が無いのであれば
ユーザーがSEに話を持って行くことなんて無いんだから。
SEと話をするってことは、漠然とでも問題が認識されてるはず。

まずは、ユーザー役が具体的な課題を考えて、
その概要をSE役に伝えるところから始めたほうがいいんじゃない?

26 :仕様書無しさん:2015/02/02(月) 21:40:39.53
会議に現れるのは現場をしらない課長や課長代理とかだから
なにやりたいのかも表現できない
というより、そんくらい知ってて来てるだろ?くらいの勢い
内製でも現場の人を会議に連れてくるのが当たり前の状態を作るまでは結構大変

27 :仕様書無しさん:2015/02/02(月) 22:13:25.16
そりゃそうだろ、会議なんかに現場の人間出してたら仕事が回らなくなるからな。
SEってそんな当たり前の事から教えなきゃいかんの?

28 :仕様書無しさん:2015/02/02(月) 22:58:03.73
>>27

>会議なんかに現場の人間出してたら仕事が回らなくなる

こういう形で肝心のキーマン出さないから、
既に伝言ゲームでの乖離が始まっている

システム屋に頼む前に墓穴掘ってる。

忙しいから出さないんなら、
逆に暇な時にこそ物事の整理としてシステム化を進めるべきなのに。

29 :仕様書無しさん:2015/02/02(月) 23:23:46.65
なに言ってんの?そりゃ必要なら出すよ?
ただお前らと違ってうちらは素人だからな、システムを作ってくプロセスっつーのは何も知らん。
それなのにいきなり現場の人間を会議になんか出せんつー話だ。
まずは、どうやってうちらの考えてることを聞き出してくれるのか?
話はそこからだろ。

30 :仕様書無しさん:2015/02/02(月) 23:44:52.68
マ板にマじゃないのがきて、なにバカなこと言ってんだろうと思った。

31 :仕様書無しさん:2015/02/02(月) 23:47:54.82
> まずは、どうやってうちらの考えてることを聞き出してくれるのか?

聞いてもしょうがない人からは聞かない。
現場の人間の話を聞き出さないと意味が無い。

だからさっさと現場の人を連れて来い。

32 :KAC:2015/02/03(火) 01:43:12.96
いきなり現場の人間連れて来いとか言い出しても・・・

たとえば、業務フローごと改善することが目的なんだったら
現場の人間を一人連れてきてもありがたくないだろ?
(たまたま手があいてた新人が来たらどうするんだと)

それなりのまとめ役が来て、今回の業務での「やりたい事」を聞いて、
どう進めていくか決めてからだろ? 現場から意見を集めるのは。

ヒアリングの機会持ってもらってもいいし、
アンケートで全体の傾向をつかむのもいいだろう。
その職場と目的に合った方法で十分な意見を集めればいい。


目的をハッキリさせた上で手段を選ばないと失敗するぞ?

33 :仕様書無しさん:2015/02/03(火) 02:37:58.06
>>27
>会議なんかに

問題点が既にここに現れてる。
「会議と称した、無駄な時間つぶし」が日常的になってるから「会議なんかに」という意識になってるんだよね。
または、システム構築そのものを邪魔なものと思ってるかだ。
いずれにせよ、地雷クライアントである事は確かなので、システム開発側は、できるだけこういう客は避けるべき。
避けられない場合は、こういう意識を持っている担当者を替えてもらうよう交渉するしかない。
それもダメならデスマ確定。

34 :仕様書無しさん:2015/02/03(火) 08:25:22.06
>>33
> 問題点が既にここに現れてる。
中略
> できるだけこういう客は避けるべき。

それが問題点かどうかはさておき、これじゃ問題から逃げてるだけだろ。
客の問題を解決するのがシステム屋の仕事じゃないのか?
こんなんばかりだから内製を考えなきゃいけなくなるだよ。

35 :仕様書無しさん:2015/02/03(火) 11:30:02.74
>>34
>それが問題点かどうかはさておき、これじゃ問題から逃げてるだけだろ。

貴方は、「システム化したい業務課題」について話したいのですか?
それとも「自社のものの考え方についての問題」について話したいのですか?
後者なら、システム屋ではなく、コンサルに相談すべきですね。

36 :仕様書無しさん:2015/02/03(火) 11:34:47.07
>>33
補足。
担当を替えてもらえない場合に、出来る事が一つだけ有る。
リスクを見込んで、見積もりを高く出すこと。
当然、受注できない可能性が高まるが、デスマになれば寧ろ時間とカネと健康を失うんだから、失注の方がマシ。

>【IT】法外な開発料金の見積もり根拠、「客には絶対に言えません」 2014/12/03
ttp://itpro.nikkeibp.co.jp/atcl/column/14/463805/112800017/

37 :仕様書無しさん:2015/02/03(火) 12:37:47.92
論点はずれてるわ、見積りの根拠は出せないわ、お前ら一体何だったら出来るんだ?
もしかしてSEって本当にプログラム組むしか出来んのか?

38 :仕様書無しさん:2015/02/03(火) 12:42:45.26
SEはプログラムを組むことも出来ません。
プログラムを組むことが出来ないから、
見積の根拠が出せないんだよ。

39 :仕様書無しさん:2015/02/03(火) 12:57:15.05
>>37
報酬ケチる雰囲気満点だから、そういうレベルのしか来ないんじゃないの?

40 :仕様書無しさん:2015/02/04(水) 00:50:51.75
>>34
え?問題点を指摘されても改善しようとしない客こそ、問題から逃げているの間違いじゃ?

問題の解決を他人任せで能動的に行動しない客の問題の解決は高難易度。
システム屋は客の問題解決の手伝いをするのであって主体ではない。

それでいて上手く行かないと難癖つけてくるならリスク係数上がるに決まっている。
傷口を双方で広げる前に辞めるのが正しい選択肢の事もある。

システム化に幻想抱きすぎ、

弊害で柔軟性が減るとか、システム内に暗黙知が閉じ込められ、ノウハウが結果的に失われる。
システム化作業の時に、仕様の形で暗黙知が明らかになることがあるけれど、
どういう条件でどういう動きをするのが良いという結果は残るが、それに至る何故?のノウハウが残らない
※ある時点でのスナップショット的なものが残るのが精々。

41 :仕様書無しさん:2015/02/04(水) 07:04:15.43
幻想を抱いているとも気付いてないなのが客

42 :仕様書無しさん:2015/02/04(水) 07:24:22.26
そのことにすら気付いてないやつが客がSEがとホザいている

43 :仕様書無しさん:2015/02/04(水) 09:26:36.51
>>41
幻想を煽る連中も居るからなあ。

44 :仕様書無しさん:2015/02/04(水) 20:36:40.26
システム開発を他人事にしない・させない・できない。
システム開発に必要なことは何なのか?
システム化によってできることできないことを理解する。
システム化するのに必要な技術はどういうものなのか。
システム化に本当に必要な人材やコストはどのくらいなのか。
etcetcetcetcetcetcetcetcetcetc

それをさ自分で作らずわかると思うの?
伝言ゲームが大部分の要素だけど、それ以外の要素でも自分たちで作るという経験を経ないと、その要件を満たせない

内製にはメリットが本当にたくさんある
それを経営陣が理解できるかどうか・・・

45 :仕様書無しさん:2015/02/04(水) 21:18:30.84
>>44
小さいもんから内製して実績アピールしないの?

46 :仕様書無しさん:2015/02/04(水) 22:20:34.73
>>45
昔、ExcelのVBAというモンスターがいまして、、、

47 :40:2015/02/04(水) 23:48:26.65
>>46

そうそう、ケースバイケースとしての別の局面

システム化の能力が足りないと、個別の小さいうちは良いけど、集まったり大きくなってくると
本職が作るより早々に矛盾やパフォーマンス悪化、原因不明に感じるバグが出てお手上げになる。

それを、急に何とかしてと言われても、使っている客が理解していない仕様になっていて
袋小路に至ってしまっている事がある。

この場合も先述の本当のノウハウがマクロ利用者になったユーザから失われている事が少なくないから
綺麗に焼き直しただけのシステムしか出来ない事が有るので注意

企業は属人化を嫌うのに、属システム化は許す。しかし、その後にシステムと共に失われないようにする事を忘れる。

48 :仕様書無しさん:2015/02/05(木) 00:33:18.52
スレタイは全くその通りだと思う。
あと、目的が達せられれば、別にVB6でもバッチでも良いと思う。
余所の誰かに使ってもらうとかが目的じゃないから>自社のシステム

効率命!

49 :仕様書無しさん:2015/02/05(木) 06:48:36.31
>>46
あのモンスターやべぇw
VBAだけならマクロの記録でも読むけど
セルにもロジックがあって阿鼻叫喚

50 :仕様書無しさん:2015/02/05(木) 07:03:57.07
システムの劣化というが

外注するとシステムの劣化どころか現場人材が劣化すっからなぁ

それに現場の人がシステム作るとゼロから構築とか普通に躊躇なくやるからなぁ

51 :仕様書無しさん:2015/02/05(木) 07:31:05.23
属人化云々は非正規雇用部分の話
100%が非正規雇用の会社なんてあるのか?

52 :仕様書無しさん:2015/02/05(木) 07:36:14.01
>>50
現場の劣化は、今は良くても次が完璧にアウトだからね
お前も経験あるやついるだろ?
新システムの仕様は現行システムから起こして改善してくださいって注文
あぁ顧客と話した経験ないんだっけ?

53 :仕様書無しさん:2015/02/05(木) 09:11:09.49
お前も経験あるやついるだろ?
お前も経験あるやついるだろ?
お前も経験あるやついるだろ?

54 :仕様書無しさん:2015/02/05(木) 10:18:36.29
作業じゃなくてノウハウをパッケージ化しちゃうからなあ。
そのパッケージ化が、商品として外販するためならまだいいが、
自社従業員が「ボタン1クリックで処理出来るように」
とか言ってる所はまず間違いなく失敗する。
経営者が、単価の安いバイトに作業させようと考えてる所は、
自動化にこだわる。

55 :仕様書無しさん:2015/02/05(木) 19:33:15.81
ノウハウを失った後のシステム発注は無理
なにせ、正しく動いているのかすらチェックできない

56 :仕様書無しさん:2015/02/05(木) 19:35:18.57
伝言ゲームが始まるだけマシ
一度、外注システムに手を出すと、伝言ゲームすら始められない

57 :仕様書無しさん:2015/02/05(木) 21:32:49.48
非IT企業で、社内システムを自社で内製はしている情報システム部の社員です。
一応俺もコーディングはできるし、そのつもりで入った会社だが、
IT業界の悪い風習よろしく、要件定義やらスケジュール管理、ユーザーの対応に追われる日々。
実装やら詳細設計は全て派遣で来てもらっている人任せ。
会社としては長くいてもらいたいと言っているが、何かの拍子に彼らに辞められたり、
会社が派遣切り始めたらウチの情シスは終わりだな。

というか、この状況、自社で作ってるって言えるのか・・・

58 :仕様書無しさん:2015/02/05(木) 21:44:38.39
要件定義に追われる日々ってすごいな
サグラダファミリア級のシステムでも作ってるのかよ

59 :仕様書無しさん:2015/02/05(木) 22:25:24.69
>>57

>実装やら詳細設計は全て派遣で来てもらっている人任せ

この時点で自社で作っているとまでは言えない。

基本設計という名の「あんな事いいな出来たらいいな」かどうかも判断出来ていないかもしれない。

社内に実装まで手を入れる事が出来る状態を維持できる人材を継続して持たないのではね。
使い捨てで惜しくないなら問題ないが。

>>58
システムに不満や改善点要望が散発しているのでしょう。
運用と開発とヘルプデスクを掛け持っていると言う所か。
これは完全に連携を分けると問題だが一体でも駄目。

60 :仕様書無しさん:2015/02/05(木) 22:49:43.97
>>57
せめて実装を自分たちでやって、ユーザ対応を派遣にやらせればいいのに。

61 :仕様書無しさん:2015/02/06(金) 06:49:28.42
>>58
これがユーザーの実際のところ
要望は絶えない
これに対応できるのも内製だから

62 :仕様書無しさん:2015/02/06(金) 08:24:17.68
>>58
だから何回か

納品後数年は無料の仕様変更って話が出てただろ
ユーザーは絶えず仕様変更をもとめる

63 :仕様書無しさん:2015/02/06(金) 10:15:20.81
>>58
>>59>>61の言う通り。
外部への売り物なら、追加料金かかるぞ、と駆け引きも可能かもしれないが、
相手は社内の人間なもんで、良くも悪くも何でも言ってくる。

64 :靖国参拝、皇族、国旗国歌、神社神道を異常に嫌うカルト:2015/02/06(金) 10:19:46.63
★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
 偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
 誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い


10人に一人はカルトか外国人

「ガスライティング」で検索を!.....

65 :仕様書無しさん:2015/02/06(金) 10:54:08.54
だから自社で作る方が良い、ということですかね。
ケースバイケースで「要件を明確にしやすい」とか「堅牢性が求められる」とかだと、外注の方が良い場合もあるのかもだけど。
言い換えると「ウォーターフォールに合う開発」は外注で良いとか。
合わないのに無理矢理ウォーターフォールにあてはめて、お互い不幸になるということが多いと思われる。
外注依頼担当して失敗とまではならなかったけど、とにかく面倒臭くて2度とやりたくないと思った。
「良いものを作る為」より「契約不履行にならないため」の手続きが多過ぎなんだよね。SIによって違うんだろうけど。

66 :仕様書無しさん:2015/02/06(金) 12:25:56.01
>>63
社内だから、という甘え意識の問題だな。
その付けを外注に押し付けようとする。

67 :仕様書無しさん:2015/02/06(金) 12:26:31.64
四六時中仕様変更の要望が上がってくるのは、単に初期段階で要件定義がまともに出来てないだけだろ。

68 :仕様書無しさん:2015/02/06(金) 12:28:03.13
>>62
まあそういう非常識なのは時々有るよね。
マトモな事業やってる客は、保守フィーを払う。

69 :仕様書無しさん:2015/02/06(金) 12:32:14.30
>>65
SIが過剰防衛(過去に類似案件で火傷したとか)の場合と、客側が地雷クライアントのオーラ出してる場合とが有るよね。

70 :KAC:2015/02/06(金) 17:04:55.97
>>62
「納品後数年は無料の仕様変更って話」

これはいくら何でも酷すぎるだろ。

"納品後1年は無料のバグ対処"
これなら当たり前だから問題ないけど、
仕様変更がOKというのは歯止めがきいてない。

極端な話、客にしてみれば
やりたいことの一割を有償で開発してもらって、
残りの九割を無償で数年更新し続ける事もできる。

社外の客にそんな契約したら倒産するぞ。。。
社内だからそんなことになってるんだろうけど、
ズルズルと仕様変更引っ張るのは効率悪いし、
最終的にまともなものにならない事が想像できる。

要件はちゃんと初期段階でまとめないと痛い目にあうぞ?

71 :仕様書無しさん:2015/02/06(金) 17:14:31.38
>>62
根本的な疑問なんだが、無償で対応なんてやって遊んでる余裕が有るの?
だとしたら、ある意味うらやましい。

72 :仕様書無しさん:2015/02/07(土) 00:05:59.55
>>69
火傷もなにも今は↓みたいな判決が出るんだから、不熱心で金払いの悪い
会社相手の受託開発は契約をきっちり決めてもリスクがでかすぎて今後は
なくなっていくんじゃないかなあ。

ユーザーが資料をくれないのは、ベンダーの責任です
http://www.atmarkit.co.jp/ait/articles/1501/07/news014.html

SQLインジェクション対策もれの責任を開発会社に問う判決
http://blog.tokumaru.org/2015/01/sql.html

73 :仕様書無しさん:2015/02/07(土) 00:11:22.91
>>65

ちょっと違う。
客はSI屋からすればアヤフヤな状態でも先に期間と予算だけで一括契約を求めるからだ。

つまり、期間と予算で予定を組むからウォーターフォール型になる。
アジャイル開発のような形態で開発するには契約やその区切りや最終規模がわかり難く客が嫌う。

「契約不履行にならないため」
は、ISO他、良い会社である為には手順に契約スケジュール、議事録やエビデンスが重要に成る
そうなると大儀より目先の問題回避になりがちなのはSI屋も同じということ
ユーザ企業も政治的にとか値切りや機能ごり押しねじ込み成果が重要で、「良いものを作る為」
なんて本当に考えているなんか怪しい。

74 :仕様書無しさん:2015/02/07(土) 01:58:47.48
>>67
それが一番大きいとは思う。
だけどユーザーが「使ってみたけどやっぱりこれが良いな。修正して」って要望通りやすいのが内製でもある。

75 :仕様書無しさん:2015/02/07(土) 08:51:32.43
そゆことやね
これに応え続けられれば内製最高!
腰が重くなってきたらテコ入れ
外注始めたら地獄の始まり

76 :仕様書無しさん:2015/02/07(土) 08:54:40.58
>>70
残りの9割が期限内に完成する範囲ならね。

77 :仕様書無しさん:2015/02/07(土) 10:39:54.56
フリーウェアにしても、シェアウェアにしても
本人が欲しい機能をひと通り頭に入れてるのに、最初のうちはバージョンアップが短期間に繰り返される。

これは、プログラミングを本格的にできる人で、趣味でプログラミングをするような人でも
一回で完全に納得の行くものが作れない証拠。

いろいろ作ってみて試してみて、訂正ポイントに気づいてを繰り返す・・・・。
ましてや、プログラミングのプの字も出来ない人たちならなおのこと。

78 :KAC:2015/02/07(土) 11:00:23.13
>>76
「納品後数年は無料の仕様変更」ってのが契約書に書いてた日には
残りの9割が期限内に完成しないと訴訟問題になったりするわけだが。

真面目な話、10年ほど前にそういう契約書出した会社を見たことある。
サービスのつもりだったのかはしらんけど、指摘したら大騒ぎになったよ・・・

79 :KAC:2015/02/07(土) 11:11:03.56
>>77
それは要件定義ができていないだけ。

個人レベルで作るオンラインソフトは、
特定の顧客もいないし市場調査なんかも不十分なまま開発するので、
一度公開してから市場の意見を取り入れるのはよくあること。
ただ、この手法では品質が安定しない。

ちゃんと要件定義ができていれば、
最終形が見えた状態で設計して開発期間中に品質を高めることができる。
特定の客がいるなら、ちゃんと要件定義したほうがいいぞ。

80 :仕様書無しさん:2015/02/07(土) 11:27:48.57
> ちゃんと要件定義ができていれば、

大前提としてそれが不可能って
話をしないといけないのかな?

作りたい人が、どういう要件が
最適であるかを知らないんだから
ちゃんとした要件定義なんてできないよ。

さらに言うならば、時代が変わるの早いので
すぐに要件も変わってしまう。

81 :仕様書無しさん:2015/02/07(土) 11:43:26.61
要件定義って実は要件を把握する作業じゃなくて、契約のために必要なんだよ。
作ってみて思っていたのと違いました。作り直しでコストがかさみます。
ってのを避けるために必要なこと出来たものが思っていたものと違っても
最初に契約したのだから作り直しのコストは客が負担してね。って言うために必要なもの

コストのことを考えなければ、実際に作ってみて使ってみて
そしてそこから意見を集めて改良したほうが、要件にあったものが作れる。
要件に合っていなければ改善、最悪作り直すわけだから、
(コストを考えなければ)いいものが作れるのは誰も否定出来ないよね?

でもコストがかかるから、作りなおすことは出来ない。

さて、それは本当だろうか?

実は思ったほどそうではなくて、しっかりした技術基盤と開発フローができていれば、
作り直すコストは大幅に減らせるんだよ。

そこらへん、技術力が低い所がだめな所で、
技術力が低い → 簡単な修正でもコストが掛かる
→ じゃあ最初に間違ったものを作らないようにしよう
→ 要件定義をきっちりやる
こういう流れになっちゃう。

作るのはコストがかかるものという前提になっていて、そのかかるコストを
下げるために技術力をあげよう、技術基盤を作ろうという発想に思い至らない。
技術力が低いと認めることが怖いのか? 上の人に技術力が低いと認知させるのが怖いのか?

そして客にとっては、紙にかかれたよくわからないものを見せられて
それで無理やり納得させられて契約してそして望んでないものが出来上がる。

82 :KAC:2015/02/07(土) 11:51:08.57
>>80
要件定義をやったこと無いならできないのは仕方がない。
素人が簡単にできるようだったら、SIerとかがご飯食べられなくなるからな。

ちゃんとした要件定義ができない人もいる。それは事実だろう。
だからといって要件定義そのものを否定するのは間違いだぞ。

ざっくり言うと、いろんな事例を把握しておいて、客の状況きいて
その時点でわかってる範囲の最適解を求めるのが要件定義だよ。

はじめから諦めてどうする。

83 :KAC:2015/02/07(土) 12:02:28.50
>>81
前提から間違えてるから、そこだけ指摘しておく。

| 実は思ったほどそうではなくて、しっかりした技術基盤と開発フローができていれば、
| 作り直すコストは大幅に減らせるんだよ。

品質のことを全く理解できていない発言だな。
大きく二点。
 ・評価や品質保証のことが考慮されていない。
 ・発生する時間のロスが全く考慮されていない。

そもそも、「作りなおさないほうが良い」ということへの反論にすらなってない。
発生する可能性のある、作り直し工数を減らす努力は間違いではないが、
それをあてにして設計や要件定義をおろそかにするのは本末転倒。 

84 :仕様書無しさん:2015/02/07(土) 12:05:37.00
>>82
要件定義って一人じゃ出来ないんだよ。

話を聞く側、話をする側、両方がちゃんとできないと成り立たない。

そして要件定義に関わる人っていうのはプロジェクトの代表であって
実際のシステムを使っている人ではない。

よっぽどの幸運が揃わない限り、最適な要件っていうのは
でてこないんだよ。そもそも最適な要件というのを
知っている人がいないんだから

あんたも言ってるように「その時点でわかってる範囲」でしか
最適解は求められないんだから。

システムのことなんか知らないパートのおばちゃんが使って
本当の意見が出てくることも多い。

85 :仕様書無しさん:2015/02/07(土) 12:10:34.61
>>83
> それをあてにして設計や要件定義をおろそかにするのは本末転倒。 

設計や要件定義をおろそかにするなんてひとことも言ってない。

完ぺきな要件定義なんてできっこないんだから、
はじめから変更が入る前提にしておけって話。

要件定義をきっちりやっていれば、物事全部うまく行くなんて
絵空事を言っているから、現実見ろって言ってるだけ。

重要なのは、変更に強い技術基盤だよ。
そして動くものをすぐに作れる技術と
動くものをすぐに見せられる技術と
すぐに修正してみせる技術。

動くものがない状態で、完ぺきな要件定義をするなんて無理な話なんだから。
要件を聞く側(開発者)の問題じゃない。
要件を話す側(客)の問題。

86 :KAC:2015/02/07(土) 12:23:19.29
>>84-85
同一人物だよな?名前欄に番号入れるとかしないと誰だか判らんぞ。
そういうところから気を使えるようにならないと、客とのコミュニケーションも難しいだろうな。

>>84
まず、要件定義が全くわかってない。
 「話を聞く側、話をする側、両方がちゃんとできないと成り立たない。」
 「要件定義に関わる人っていうのはプロジェクトの代表であって
 実際のシステムを使っている人ではない」
こんな考えで要件定義しようとしてるなら、失敗して当たり前。
少なくとも、SIerやSEを名乗ってはいけないレベル。
つか、どうしたらいいか考えられないのか?

>>85
開発プロセスもまともに理解できてない。
 「完ぺきな要件定義なんてできっこない」
 「重要なのは、変更に強い技術基盤」
 「要件を聞く側(開発者)の問題じゃない。要件を話す側(客)の問題」
完全に個人開発者の意見だな。
会社で開発プロセスに沿って開発したことある?
 
直接は言ってないが、おろそかにしてるのは伝わってくるぞ。
 

87 :仕様書無しさん:2015/02/07(土) 12:25:51.26
要件定義をするにもコストがかかるからね。

どんなのがいいか?

なにもない中で、お互いの想像にたいして
あーだこーだ言いう時間のコストを考えろと。

要件定義をするコストよりも、修正するコストのほうが小さければ
さっさと動くものを作って見せたほうが話が早い。
技術力が低いから、さっさと動かすものが作れないわけ

例えば、ニコニコ動画なんて3日間で基本システムが作られた。
もしこの開発を企画してプレゼンして説得して承認を得てとかやっていたら
開発始めるまで1ヶ月以上かかるだろう。

そうではなくて、さっさと作って、そこから意見を集めて作りこめばいい。
ニコニコ動画で3日なんだから、要件定義であーだーこーだ言っている
時間があればその内容の動くプロトタイプは十分作れる。
それをベースにして開発を行って行って品質を上げればいい。
プロトタイプだから作ってだめなら捨てることもあるが、
それは要件定義でボツ案になったものを考えてる時間が捨てられるのと一緒。

要件定義にだってコストは掛かるんだよ。要件定義で
無駄なものを考えてしまうコストのことも考えろ

88 :仕様書無しさん:2015/02/07(土) 12:29:05.49
>>81
>そこらへん、技術力が低い所がだめな所で、

必ずしも技術力の高低の問題じゃないけどね。 作った人と直す人が別なことは
よく起きて、ここでも伝言ゲームが発生する。さらに運用は別だったりするし。
だからDevOpsなんて言葉を作って一貫性を保とうと考えるような人が出てきた
けれども、言葉が独り歩きしてバズワードになって前以上にダメになるかも
知れない。

89 :KAC:2015/02/07(土) 12:29:34.25
>>87
お前の考えてる要件定義の手法ってどんなものがあるんだ?

90 :仕様書無しさん:2015/02/07(土) 16:12:40.10
要求定義書は
客との第一義的な契約内容の確認書
ほかの仕様書や設計書も結局は客や開発会社間の相互間の契約書

んで。やってるとわかると思う。
2chのスレッドでもいくつかあるけど
その書類作成にムチャクチャ開発の時間を取られて、プログラミングそのものは全体の2割あるかないか。

この無駄な契約責任回避作業に割かれる時間が内製だと極限まで減らせる
何故かならばユーザー求めれば変更を行うことが大前提の体制だし、そもそも同じ会社だから気にする必要がない
実装2割書類作成8割が、実装8割書類作成2割にすることも内製なら可能

くれぐれも言っておくが、マニュアルを全く作らないということではない

91 :仕様書無しさん:2015/02/07(土) 17:18:13.01
要件定義と要求仕様との区別出来ない奴の意見って、参考になるの?

92 :仕様書無しさん:2015/02/07(土) 17:45:49.59
間違ってない
丸投げ構造の現実からして

93 :仕様書無しさん:2015/02/07(土) 17:45:55.68
だいたい仕様が出せない会社、ユーザーが悪いわけで、情報システム部門を軽視している経営陣に問題がある。

94 :仕様書無しさん:2015/02/07(土) 18:11:00.81
建築業界でも同じことが言われている
客は最初、自分で設計図まで作ってくるが、法律や機能性、快適性などから改善点を建築士が提示

最初は客もならこれで!と積極的。
ところが中盤になると客側がめんどくさがり出す。

ブライダルの打ち合わせもそう、、、

他にもいろんな業界で

人間とはこんなもの

これがITだと例外で客が頑張り続けると思うのが間違い

95 :KAC:2015/02/07(土) 18:31:13.25
>>92-94
だから名前書けって・・・

なんでもすべて客のせい とか、流石に世の中なめすぎだぞ?
もう少し自分の問題だと認識できないとまともな仕事はできないだろ。

96 :仕様書無しさん:2015/02/07(土) 18:43:26.18
客のせいというよりも、
その客が何も知らないんだよ。

じゃないの業務を熟知してそれを改善したいと思って
システム会社に仕事を頼んできている人は少ない。

システム化したら効率が上がるんじゃないか?と思ったお偉いさんが
部下にお前、適当な業者見つけてシステム化しろっていう。

頼まれた担当者はどうすればいいかわからず、商品発注する感覚で
システム化の依頼をする。

用件を聞かれても答えられず、開発会社の提案に
よくわからないけどプロの提案だし
それでいいんじゃないですかね?と返答する。

本当はシステム開発会社は、お前じゃ役に立たん
業務を知ってる人間をよこせ。と強く要求すべきなんだが。

97 :KAC:2015/02/07(土) 19:01:26.28
>>96
その事例の場合、話をする相手を間違えたら失敗するぞ。
まず話をすべき相手は
「システム化したら効率が上がるんじゃないか?と思ったお偉いさん」だ。

システムの仕様の話はしなくても構わないから、
売る側としてどういう方向の商品を提供するのかイメージを合わせろ。
( 業務改善を含むのか自動化だけなのか。など、得意なシステム売り込め )

そうすると、客から出すべき情報も見えてくるし、
出てくる担当者の人選も正しくなってくる。

98 :仕様書無しさん:2015/02/07(土) 19:04:10.05
> まず話をすべき相手は
> 「システム化したら効率が上がるんじゃないか?と思ったお偉いさん」だ。

話したってしょうがないぞ?

だって、思っただけなんだから。

思った → お前がやれ
と部下に命じるだけ。

99 :KAC:2015/02/07(土) 19:07:08.32
>>98
なにか勘違いしてるようだな。

商品を売る立場の人間が話をするのは、
「商品を買おうと思った人間」が大原則。
部下に命じたってことは、買う意思があるってことだよ。

その基本を見失ってるから、
わけわからん人と話をして訳わからんことになるんだよ。

100 :仕様書無しさん:2015/02/07(土) 19:08:45.14
>>99
わかってないのはお前だよ。

商品を買おうと思った人=パートのおばちゃん
なんだが、そのパートのおばちゃんが
システム化の提案なんかできないわけで。

101 :仕様書無しさん:2015/02/07(土) 19:13:28.72
>>100
流石に意味わからんぞ

102 :仕様書無しさん:2015/02/07(土) 19:14:54.48
>>100
なんでパートのおばちゃんなん?
アホ過ぎるwww

103 :KAC:2015/02/07(土) 19:19:44.41
>>100
えーと、お前さんが前提に出してきた
組織の概要がよく判らんようになったんだけど

> 商品を買おうと思った人=パートのおばちゃん
> なんだが、

とりあえず、↑について詳しく説明してくれ。

104 :仕様書無しさん:2015/02/07(土) 19:22:43.79
パートが決済権w
すごい会社だw

105 :仕様書無しさん:2015/02/07(土) 19:24:02.83
パートのおばちゃんに度肝をぬかれたww

106 :仕様書無しさん:2015/02/07(土) 19:40:16.56
>>100
コレはひどいwww

107 :仕様書無しさん:2015/02/07(土) 20:06:26.44
要件定義の件は、客も自分の事を知らないという形で完璧な物は無理な事が殆ど。

しかし、走りながら作る形では、過去の蓄積データを使いたいという要望のせいで
修正に制約がかかってくる、下手に昔の物に拘わるのは駄目だ。

そういう意味で、ある程度の基本データ構造他の基本部分はキモなので
実際に作って試すまえにもっと、客と共に手作業でのシミュレーションで洗い出すべきだ。

>>87
>要件定義をするコストよりも、修正するコストのほうが小さければ
>さっさと動くものを作って見せたほうが話が早い。

修正するコストのほうが小さいという事は少ない。
抽象想像力が足りない事が多く、叩き台というのを理解せずに話をするし、
もう出来ていると考えて値切る事を考えるからだ。

108 :仕様書無しさん:2015/02/07(土) 20:18:04.70
>>100の人気に嫉妬

109 :仕様書無しさん:2015/02/07(土) 20:26:03.04
マター=担当
コミット=責任を伴う約束
コンセンサス=合意
レギュレーション=規約
アジェンダ=議題、行動計画

110 :仕様書無しさん:2015/02/07(土) 20:32:27.62
アサイン オーソライズ コンバージョン サマ リー

ステークホルダステークホルダステークホルダステークホルダステークホルダステークホルダステークホルダ

111 :仕様書無しさん:2015/02/07(土) 20:32:28.38
ナジェンダ=CV:水野理紗

112 :仕様書無しさん:2015/02/08(日) 08:22:39.86
お前ら簡単に
現場で全てを把握している人間と話せ

というが、なら
なぜ、お前らを一度も現場で見かけない?

開発側も立場で役割が決まっているように、客側も立場で役割がきまっている

人様にこうあるべきだ
という割にお前らが実践してない

内製ならば担当課長に
あの人を開発の会議に出てもらえませんか?と指名も簡単
指名相手を探すこも簡単

113 :仕様書無しさん:2015/02/08(日) 08:52:54.49
自社の建物の中で開発すれば
全部丸投げでも内製化らしいぞ

114 :仕様書無しさん:2015/02/08(日) 09:12:56.89
>>112
同感。
そもそも>>1は外注そのものは完全否定していない。
ユーザー ⇒ 実装現場 or ユーザー ⇒ 開発リーダー ⇒ 実装現場 で作れと。
だけど、それが実質的に行われていないから、内製(ユーザーが作るor自社開発)しか手がないという主張

115 :仕様書無しさん:2015/02/08(日) 09:33:58.96
>>113
でもそれなら開発者とユーザーの距離が近いから問題はないんじゃない?
「まともなシステムを作るには」ということが問題なんであって

116 :KAC:2015/02/08(日) 09:34:56.24
>>112
言ってる意味がよく判らん。

> 現場で全てを把握している人間と話せ というが、なら なぜ、お前らを一度も現場で見かけない?

それは、お前が「全てを把握している人間」ではないからだろう。

というか、そもそも
「全てを把握している人間と話せ」なんて話はどこから?

117 :仕様書無しさん:2015/02/08(日) 10:45:30.59
>>112
このスレにいる外注さんは、奴隷階級の人たち(特定派遣、一般派遣)だから
なんで平民と奴隷が会話できると思うの?

118 :仕様書無しさん:2015/02/08(日) 11:07:42.40
>>117単語はどうかと思うがコレが真実だよね。
ココにいる大半が特定派遣(=一般派遣と実質変わらず)だから交渉なんてできるポジションではない。
特定派遣って正社員のつもりなんだろうけど、ものすごく騙されたポジションだって気づかないのかな?

119 :仕様書無しさん:2015/02/08(日) 12:46:47.73
酸っぱい葡萄なんだよねえ
派遣プログラマ、偽装請負プログラマで客と話をしたこともない人が想像で語る

120 :仕様書無しさん:2015/02/08(日) 13:28:27.46
ということにしたいんだろうねw

121 :仕様書無しさん:2015/02/08(日) 15:05:07.47
俺の場合はフリーで世話になってた会社があまりに不憫で入社しちまったw
まさにスレタイの思いだ。勿体ない>外注費と時間
外注時代に業務の粗方は判っていたから、後は中堅一人をOJT名目で育てながら
今、自社システムを自分たちで作り上げている最中

社畜→フリー→社畜の歩みだが、目的がハッキリしているとそれなりに楽しいし
なにより結果・成果が社内で(良いも悪いも)直接評価されるからやる気出るわ

122 :121:2015/02/08(日) 15:08:58.40
手取りは減ったが有給有るし基本土日休みだし
なによりシステム的なところでは主軸を握れるから話しが楽
今時のクラウド利用もすんなり承認されるし障壁となるモノが見当たらない
根底には「自社に為に!」ってのが有るけど、その土俵の上で好き勝手出来るのは楽しい
もちろん節度は守っているがw

自由に采配を任せてくれる環境ってのは心地よいぞw

123 :仕様書無しさん:2015/02/08(日) 16:11:22.47
俺も同じような状態になりつつある

俺の中で作ったルールで
後続が作り直しをしたいと言ったら、そこで否定的にならずに賛成する!
というのを立てたが今のところ発動してないw

出社時間とかあって無いような状態になってて楽ちん
なにせ、○○に行ってます。○○なので時間ずらしてます。で、誰も理解できないからダメ出しもないw
給料は30歳で800万だし、週休も当然あるし、有給もフル消化可能、残業もない。
企画すれば予算は出るし。マジで恵まれた状態
人員は極力増やさない予定

124 :仕様書無しさん:2015/02/08(日) 16:13:51.77
>>122
ほとんど興味本位、趣味の開発で会社から金が出るから最高だよな

125 :仕様書無しさん:2015/02/08(日) 16:32:16.65
自分が会社を起こしました。
もしくは自分が一般企業の課長になりました。係長になりました。室長になりました。
システムを構築します。
 発注する?
 自分で作る?
どっち選ぶ?そーゆーことだw

126 :KAC:2015/02/08(日) 16:44:38.08
>>125
なんで普通に「部下に作らせる」という発想にならないのか不思議

127 :仕様書無しさん:2015/02/08(日) 16:45:50.05
>>126
つまり内製だ

128 :仕様書無しさん:2015/02/08(日) 17:32:15.23
>>125
自分がいるなら外注なんてしないって皆思ってるよ
このスレの問題点のひとつに
 プログラミングは超高度なもので、一般人には使えない
というのは絶対条件!という脳内設定を適用してくること。
高卒、専卒、F卒の分際で、まともな企業にも入れなかったお前が非凡な存在なのかとwwwwwww

129 :仕様書無しさん:2015/02/08(日) 18:58:27.38
>高卒、専卒、F卒の分際で、まともな企業にも入れなかったお前が非凡な存在なのかとwwwwwww

まともな企業というものがどいういうものかだね
実態は大企業というのは外注に出すしかないからさ

金儲けというのは、パートのおばちゃんがいるかどうかで決まる
これが実態なの。搾取をしているのがまともな企業

こつこつ労働しているのが下請け(技術はここにあるけど)

130 :仕様書無しさん:2015/02/08(日) 19:03:04.40
・・・と、下請け従業員の妄想でした。

131 :仕様書無しさん:2015/02/08(日) 20:04:34.73
自社で作るって言ってもどうせ派遣入れるだろ。
結局作るのはいつも下請け派遣、なんも変わらん。

132 :仕様書無しさん:2015/02/08(日) 20:44:40.55
>>131
連絡系統が>>1の範囲だからOKなんじゃね?>>1の内容なら
ユーザー⇒情報部門(正社員)⇒実装者
なんだから

133 :仕様書無しさん:2015/02/08(日) 20:46:05.73
うーん。
結局は自社製作になるのかなぁ。
ただ、肥大化して何やるにも否定的なシステム部門を生まない方策も考える必要があるよね。

134 :仕様書無しさん:2015/02/08(日) 21:18:26.49
>>133
ある程度組織が大きくなると、評価が減点方式になるわけでどうしようも
ない部分ではあるよ。無限に拡張し続けれて要らなくなったものを気軽に
捨てることが出来るなら、現実はそうじゃないから。

135 :仕様書無しさん:2015/02/08(日) 22:02:32.58
>>132
情報部門(正社員)が癌になりそうだな
情シスに開発リーダーになれるスキルがあればいいけど、その形態だとたぶん無い

136 :仕様書無しさん:2015/02/08(日) 22:07:28.20
>>133

良くも悪くも、マイナス思考に成りがちな保守運用ヘルプデスク系と
新しい要望や試験開発などを行う所にあえて分けて
本当に必要なフィードバック他、前者のチームで厳選まとめて戻す形で連携すればいいかな

大企業でも挑戦的な部分をやる部署を分けるように。

>>134
後は、式年遷宮の考えで、業務も開発もノウハウが失われないように
経年劣化しきる前に、平行で再構築して乗り換える事
乗り換えないといけない締め切りがあると阿鼻叫喚に成りかねないし。
これは内製でこそ意味と意義が大きい事。

137 :仕様書無しさん:2015/02/08(日) 22:10:01.62
百姓には開発は無理だっちゅの、
ここに書き込んでいる主婦の皆さんわかったかね

138 :仕様書無しさん:2015/02/08(日) 22:13:18.54
>>128
> プログラミングは超高度なもので、一般人には使えない

その通りですが何か
こればっかりは適性が大きいから、向いてない人は邪魔になるだけですよ
適性、基礎知識、経験の3つが揃って初めて一人前の技術者なのです
基礎知識は大学等で身につけるものだし、経験はいかに多くのプロジェクトに参加したかで培われるのです
というわけで、正社員なんてステータスは無意味であることを理解しましょうね

139 :仕様書無しさん:2015/02/08(日) 22:26:29.97
学歴なんていうことを言っているのは、
価値観が学生のまま、頭がいいのが上というやつ
小学生から植えうけられたマインドコントロールなわけ

主婦は働いたことないから、社会の価値観をしらないわけ
で、投稿が学生の価値観のままなのだから、身分がばればれなわけ。

140 :仕様書無しさん:2015/02/08(日) 22:28:16.79
>>139
経験ないんだろ?
http://ecx.images-amazon.com/images/I/61EaJ1JQMQL.jpg

141 :仕様書無しさん:2015/02/08(日) 23:21:13.72
プログラマというのは、電話が嫌い。
どうせ電話のむこうにはアホなんだから

プログラミングの構築は百姓にはできない
やってみれば、失敗すうるからさ
うちらはそういうのを乗り越えてきた世界にいるともいえる。

142 :仕様書無しさん:2015/02/08(日) 23:24:19.16
なんで自分以外はみんな無能みたいな話をやってんの?
それ、ただ自分が無能だって宣言してるだけだから。

143 :仕様書無しさん:2015/02/08(日) 23:43:44.59
まあ、プログラマにとって、仕事をくれる人はいい人。
つまり、才能を分かってくれるみたいな感じかな
よそに頼んで、失敗した経験がある人が、仕事をくれるというのがいい
Only Oneになった気分だよ

144 :仕様書無しさん:2015/02/09(月) 05:06:18.57
日本に於いては、分析検証実践などの問題解決を大学までは訓練されない。
今までは現場に入ってから(現場の自己流で)訓練されていたが
いまは大卒が5割以上でありわざわざ高卒を採用するメリットは
皆無。
学歴を軽んずるものは学歴に泣くことになる。

145 :仕様書無しさん:2015/02/09(月) 05:43:28.68
大卒が「資格」であることを高卒は知らない

146 :仕様書無しさん:2015/02/09(月) 10:21:37.68
どゆこと?

147 :仕様書無しさん:2015/02/09(月) 10:51:59.92
また、学歴の話?
めっちゃ話がループしてるわ。

148 :仕様書無しさん:2015/02/09(月) 12:21:38.50
学歴以外に誇るものが無いからしゃあない

149 :仕様書無しさん:2015/02/09(月) 19:44:15.31
高卒は大学でなにやってるか知らないのが多いな。
単なる高校の勉強の延長とすら思っているのもいるw

研究・レポートの繰り返し。答えは自分で作る。
これらは、組織の舵取りを担える人材の育成だ。

大学出た25歳くらいでまだ白馬の王子様に憧れる娘でも、
高卒40代男性100人の将来を決めるくらいの力を授かる。

高等教育は作業員の育成。
大学は指導者の育成。

150 :仕様書無しさん:2015/02/09(月) 20:29:26.33
>>142DQNの根拠なき異常な自信と同じ
底辺は底辺で固まる。底辺の中でも一応優劣がある。底辺の中で勘違いしても不思議なことではないかと。

有能な人ほど、自分を有能とは思わない。
進学校にも落ちこぼれと言われる者がいる。全体から見れば実際は上位1%に入るほどの有能な者でも。

151 :仕様書無しさん:2015/02/09(月) 20:55:17.89
自信がない訳じゃないが、周りも凄いので、あんまり他者が無能と思うことが少ない
みんななんでもできる

152 :仕様書無しさん:2015/02/09(月) 21:42:54.76
正直ここ十数年、仕事で高卒と関わったこと無い。
見るのはコンビニやスーパーのレジとか
日雇いの土方さんくらいか?
中卒はすでに絶滅危惧種だが、高卒もそうなるな。

153 :仕様書無しさん:2015/02/09(月) 21:48:58.69
>>152
それは、言い換えると、あんたが関わったことがある人が
大卒の資格を持った高卒レベルになってきてるってことですよ。
どんどん大卒のレベルが下がってる。

154 :仕様書無しさん:2015/02/09(月) 22:12:15.48
>>152
で、おまえはどこの大学出てるの?
まさか日東駒専じゃねーだろうな?

155 :仕様書無しさん:2015/02/09(月) 22:49:44.17
>>153
> 大卒の資格を持った高卒レベルになってきてるってことですよ。
言い換えになってないww

大学にも差はあるけど、それとは関係なく高卒がヤバいことになるのは
もはや避けられんな…

156 :仕様書無しさん:2015/02/09(月) 23:02:25.42
>>155
本来は大学のレベルで判断するより、高校のレベルで判断した方がいいんだよな。

私立大なんてかなり阿呆高校から推薦で入れるからね。

157 :仕様書無しさん:2015/02/10(火) 00:00:47.63
http://jbbs.shitaraba.net/sports/42269/

158 :仕様書無しさん:2015/02/10(火) 01:08:20.53
そういや10年ほど前、現場正社員は大卒しか居ないんだが契約で来た短大卒の娘が
「高卒だと結婚式の経歴紹介で恥ずかしいから短大出た」
と言っていたw 10年前でこれだもんな。

159 :仕様書無しさん:2015/02/10(火) 02:26:33.86
学歴なんて関係ないよ
最期に生きのこった奴が勝ちだ


もちろんそいつもいつかは死ぬ

160 :仕様書無しさん:2015/02/10(火) 03:11:31.93
最期に生き残るかどうかに学歴は大いに影響する。
大学のレベルの差はあまり影響しないが
大卒と高卒では大きな差がある。

161 :仕様書無しさん:2015/02/10(火) 06:11:32.93
なにこの低レベルなスレ…
みんな人に恵まれなすぎだろ

162 :仕様書無しさん:2015/02/10(火) 06:48:22.40
類友って言葉しらんのか?

163 :仕様書無しさん:2015/02/10(火) 07:04:11.73
周囲の実力=自信の身の丈
だから
簡単に誰でもできると言ってる人=周囲の実力が高い
素人には無理と言ってる人=周囲の実力が低い

環境と己の実力は多くで比例する

164 :161:2015/02/10(火) 10:21:24.58
>>162
なるほど。
やっぱそういうことなのか

165 :仕様書無しさん:2015/02/10(火) 12:39:27.01
このスレで学歴の話をしてる人=伝言ゲームを盛り上げてる人

166 :仕様書無しさん:2015/02/10(火) 20:08:44.59
今日、内製をやってみることにした。
コツコツと課のシステムを丸ごと作ってみる。

大学からずっとやってる分野は画像解析・測量プログラミングなんだけどねw

167 :仕様書無しさん:2015/02/10(火) 22:09:10.21
>>166
理系理系言ってても数学のすの字も出来無い連中が僻みから標的にしそうだなw

168 :仕様書無しさん:2015/02/10(火) 23:30:35.32
内製あるあるだな
形式言語理論の本をカバンに入れてたら課員全員から神扱いされたよ
妬みもひどかった
文系なのに英語も読めない奴も普通にいるしな

169 :仕様書無しさん:2015/02/11(水) 00:43:45.96
それまじ?妬まれるんだったら今まで通り一人でこっそりやっとく事にするわ。

170 :仕様書無しさん:2015/02/11(水) 09:43:01.52
>>166
この手法が一番良い
システムなんてウチの会社の人間なら3ヶ月で作れるようになるわ

171 :仕様書無しさん:2015/02/11(水) 09:54:38.71
>>170
何を作るのかわからんが、まず三ヵ月と言ってるあたり怪しいもんだな

172 :KAC:2015/02/11(水) 10:07:12.64
>>166
自分一人で設計できる範囲なんてたかが知れてるぞ。
ちゃんと社内のプロジェクトにして色々な人を巻き込め。

基本的に、一人で考えたものはまともに使えるものにならん
ってことは覚えておいたほうがいい。

173 :仕様書無しさん:2015/02/11(水) 10:09:59.91
もう妬まれてるなwワロタw

174 :KAC:2015/02/11(水) 10:14:04.49
>>173
妬みって言うからどんなのかと思ったら・・・

ごく当たり前の指摘を受けて
「俺様を妬んでるwww」とか勘違いしてるだけか?
指摘を理解できないのは技術的なところだからどうにかなるにしても、
聞く耳持ってないのは致命的。将来が心配だぞ。

175 :仕様書無しさん:2015/02/11(水) 10:15:35.86
>>174
俺は>>166じゃないぞ馬鹿だなお前w

176 :KAC:2015/02/11(水) 10:18:36.59
>>175
「妬まれてるなw」と発言してるのはお前だろ・・・?
なに言ってんだ。

177 :仕様書無しさん:2015/02/11(水) 11:56:40.50
>>175
ところで、なんで>>166が出てきた?

178 :仕様書無しさん:2015/02/11(水) 12:24:53.90
内製初めました報告
→妬みから「うまく行くわけない」「技術がー」とかのレスがつく
→いつのまにか関係ない学歴の話題へ
→以下ループ

179 :仕様書無しさん:2015/02/11(水) 13:28:11.34
>>171
末端まで含めて偏差値平均65なんで。

180 :仕様書無しさん:2015/02/11(水) 15:10:13.01
>>172
大抵の業務系は単独では規模のでかいものはほとんどないということを知らんのか?

181 :KAC:2015/02/11(水) 17:23:36.02
>>180
べつに規模だけの話をしてるわけじゃないんだけど・・・

全体仕様をどうするかとか、どの程度まで適用するかとか
いろんな人の意見を聞かなきゃならんだろ?
細かい仕様の話になったら担当者へのヒアリングもいるだろうから、
その時までに話しつけとく必要もあるだろう。

このあたりはほんの一例だけど、
システムの導入は人を動かすところから始まると言っても過言じゃない。

182 :仕様書無しさん:2015/02/11(水) 17:47:38.63
>>181
横スマ
それって
外注だと1000000000000000%不可能って結論になるよね

183 :仕様書無しさん:2015/02/11(水) 18:44:05.41
>>182
RFPとか知らない人?

184 :KAC:2015/02/11(水) 19:00:15.34
>>182
お前さんの言ってる「外注」ってのは
どの程度外に出すことを前提にしてる?

完全に全て外部の会社にお任せとするなら、
普通はSEやSIerと呼ばれる奴が来ることになる。
この手のプロは、進め方や導入の事例を色々持ってるから
具体的にどう進めてどうするかなどを提案という形でもってくる。
あとは、社内の状況に合わせて選んだり、
関係する人間を集めてSE/SIer含めて調整していく形になる。

このあたりは社内の素人がやるよりは、
社外のプロに任せるほうがうまく行くことが多いと思ってていい。

185 :仕様書無しさん:2015/02/11(水) 19:00:53.10
>>183
外注の人が課員全員にヒヤリングでもしてると?
外注としてぶん投げる体制のところは、何もかもSE等々が把握していると思い込んでるんですが。

186 :仕様書無しさん:2015/02/11(水) 19:03:25.69
>>184
同時か。>>185と同じ回答。
外注に投げる体制をとっているところ⇒完全にSE等々が把握していて当たり前。
という考え。

そういった考えから変えるのも内製を経験して「システム開発は自分たちのこと」という認識に変えないと話にならない。
でも、それができるようになったころには、外に投げるのが疑問になる。
それでも外に投げるケースがある。それは課長等が異動したとき。

187 :仕様書無しさん:2015/02/11(水) 19:04:48.62
>>166
空いた時間に好きにやって良いということか?いい傾向なのかな

会社で使うようなシステムだと大体データベースを使う事になるので
それと、データの格納や正規化、整合性を考慮できていれば
イキナリ失敗はしないと思うので頑張ってください

188 :仕様書無しさん:2015/02/11(水) 19:15:49.00
>>187
このケースで発生する失敗=引き継ぎ不能になるケースだけ。
自分でシステム化したけど、公認にならず自分も公認ポジションに着けずに異動になってしまった場合。等
コレ以外は、自分が担当をしているうちは、それを使っていればいいだけだから。
問題はシステムを自分以外の人に使わせるようになってきた段階から出てくる。

189 :KAC:2015/02/11(水) 19:20:56.74
>>186
なにやら話が通じていない予感・・・
もう少し>>184の内容理解してくれるとありがたい。

あと、>>186に書いてることだけど
「外注に投げる体制をとっているところ⇒完全にSE等々が把握していて当たり前。という考え。」
これ、何が言いたいのかよくわからない。
あえて理解してみると、
「完全にSE等々が把握していて当たり前」
と客が思い込んでてSEに情報を出せないということを言いたい?

それなら、当たり前の話。
SEの立場から言わせてもらえば、そうじゃない客のほうが少ない。
さらに言えば、客が課題の本質をそもそも理解していないなんてのもザラ。

そういった客から情報を引き出して課題を解決するのがSEなりSIerなんだから。
その程度でねを上げるようじゃSEでお金もらえない。

190 :仕様書無しさん:2015/02/11(水) 19:27:36.46
>>189
システム開発の打ち合わせに、何十時間も膝付きあわせてくれると思う?
まぁ、毎回おねぇちゃんでも用意してくれれば、オヤジどもも喜んで参加するだろうけど

191 :仕様書無しさん:2015/02/11(水) 19:29:02.99
>>184
>外注に投げる体制をとっているところ⇒完全にSE等々が把握していて当たり前。

そんな認識しかない会社が内製できるか疑問なんだけど
内製できるような技術あったら外に出す部分の切り分けとかできんじゃないの?なんか話の前提違ってないか

192 :191:2015/02/11(水) 19:29:49.49
>>184じゃなくて>>186

193 :KAC:2015/02/11(水) 19:32:10.94
>>190
よっぽど変なSEしか見たこと無いのか・・・?
なんでそんな偏った前提を持ちだして全否定しようとするんだ?

194 :仕様書無しさん:2015/02/11(水) 19:36:08.25
なんなんこのすれ

195 :仕様書無しさん:2015/02/11(水) 19:40:31.04
あまりに現実が見えていないな
そんなこた分かった上でこのスレが立ったわけだが。
プロとして職務を全うするのがSEだって?
笑わせるね

196 :KAC:2015/02/11(水) 19:45:30.73
>>195
| プロとして職務を全うするのがSEだって?
| 笑わせるね

すごいセリフが来たな。
お前の中では、SEは職務を全うしない奴なんだな。

・・・お前には上流工程無理だってことはよくわかる。

197 :仕様書無しさん:2015/02/11(水) 19:50:52.36
某MBなんかは、まさに外部委託しまくって
情シス部門だけでなく会社全体がノウハウを失って、もはや仕様すら把握している人間が一人もいない状態
あれが外注やアウトソーシングの成の果て

198 :仕様書無しさん:2015/02/11(水) 19:52:33.41
本職のSEという人種は、なぜか常に自分が絶対的に正しいと思っている。
だから話も噛み合わんし、こんなんで外注システムが成功するわけがない。

という見本のスレ

199 :仕様書無しさん:2015/02/11(水) 19:54:53.59
>>194
内製に勝るものは現状無いようだけど。

それを認めたくない人。
俺様は天才(ただし低学歴・低偏差値)だからプログラミングできるけど、一般人は無理としたい人。(特定派遣・一般派遣)
無職の人。
内製はじめましたという人。
内製をやって超飛級出世しました。
内製放棄した情シスのボヤキ。

などが入り混じったスレかな。

200 :仕様書無しさん:2015/02/11(水) 19:55:27.06
SEに無駄な敵愾心を持ってる馬鹿が暴れるスレ
の間違いでは?

201 :仕様書無しさん:2015/02/11(水) 19:56:08.99
>>197
みずほか。

202 :仕様書無しさん:2015/02/11(水) 19:56:17.30
>>198
そうw
プログラマだけでもこんな状態。
これが会社間となり、部門間となり・・・・顧客と受注会社間となり・・・。
無理だって>>1が最初に言ったことを裏付け続けているw

203 :仕様書無しさん:2015/02/11(水) 20:20:45.59
このスレの話がかみ合わないことがまさに伝言ゲーム問題の存在を証明する

204 :仕様書無しさん:2015/02/11(水) 20:35:02.61
某銀行の場合は

メインフレームの独特な環境

という壁もでかい。
メインフレームでもTCP/IP通信とかソケットプログラムとか普通にできるんだけど
 できる人がいないw
メインフレーム上でC言語とかでソケット通信とかの実装をやろうという考えが完全排除されてしまっている。
まぁ、サンプルプログラムがないから「やってみよう!」と思っても口には出さないw
メインフレーム上でもRDBは普通にあるし、SQLも普通に使える。
けど、大抵の場合、RDB前の時代のツリー型DB等を延々と使っていたり、
RDBは使っていてもSQLを使わずに総舐めFindFirstとFindNextでデータをひたすら比較で探す仕組みw

205 :仕様書無しさん:2015/02/11(水) 20:41:49.83
内製
[利点]
・作るのが社員なので守秘が外注よりかなり確実
・それにより、情報伝達がスムーズで勘違いによる不具合の少ない開発が出来る
[欠点]
・ソフトウェア技術の新陳代謝があまり活発ではなく、自己流の「やったら出来たw」
 になりがち
・それにより、意味不明・保守困難なコードになりがち

206 :仕様書無しさん:2015/02/11(水) 20:52:23.00
>>204
そういう技術的な部分以前に既存機能や連携している外部との整合性は
どうするとかいう既存機能が手を入れたりするには大きすぎるんだよ。
後は機能追加は予算付けれるけど、リファクタリングみたいな作業に予算は
付かないからというのもある。 建前上、空いてる時間はないからね。

夜間バッチが一晩止まったらTVニュースやら新聞沙汰になる、ある意味
異常な環境だからねえ。

207 :仕様書無しさん:2015/02/11(水) 20:53:52.14
どいつもこいつも自分だけがまともだと思い込んでおるね

208 :仕様書無しさん:2015/02/11(水) 20:55:07.80
>>205
弱点

若いうちは、システムの再開発をむしろやりたい!仕様変更?!大歓迎!こうしちゃう!?!??!?こうしたほうが良いよ!!うひょー!
年取ると、え・・・・・・・・・・めんどくせ・・・・・・・・・。   メリットは?コストは?責任は?(企画をつぶすのが目的。)

になる仕方のない現象w

209 :208:2015/02/11(水) 21:04:25.28
後者に人はなってしまう。
だから、後続への引継ぎ時には新システムを一緒に作る。
作成が終了したら、引継ぎ完了。引退。という
今のシステムは自分が引退したときに一緒に引退する。という制度が一番良いのかもしれない。
システムリプレイスに時間がかかるとしても、仮に長く20年動かして終了したシステムがあったとして
15年目くらいから新担当とともに新システムの作成に取り掛かって、完成本番運用開始とともにシステムと自分が引退。
これが情シスの常識となるようにすべきだな。

210 :仕様書無しさん:2015/02/11(水) 21:23:49.52
>>206
> 後は機能追加は予算付けれるけど、リファクタリングみたいな作業に予算は
> 付かないからというのもある。 建前上、空いてる時間はないからね。

開いてる時間がないからこそ、その時間がかかる部分を
修正するんじゃないか。リファクタリングは別に予算を取るものじゃないよ。

開発するってことは修正するだろ?その修正の箇所を整理するだけ
開発したんだからどっちみちテストするだろ?
だからこの方が効率がいい

211 :仕様書無しさん:2015/02/11(水) 22:11:54.45
内製が良いって意見は、自分の技術力不足を理由にしてるんだろ?
なんで外部の有識者を使わないんだ?

212 :仕様書無しさん:2015/02/11(水) 22:24:40.76
>>210
>開発するってことは修正するだろ?

金融系の仕事したことないのかな? 不具合修正なんかも別に勝手にやって
いいわけではなく、スケジュール切ってやる必要がある。テストも自分がやって
OKだから即リリースも出来ない。 緊急性の高い修正なら途中のプロセスを
ある程度スキップ出来るけど、通常はそういうプロセスを経ることで担保される
品質が重視される。 メインフレームはここのハードルが限りなく高い。

こういう環境だからやらない人は全くやらないし、やるにしても次に開発に
混ぜれそうな部分でしか修正出来ない。

213 :仕様書無しさん:2015/02/11(水) 22:34:25.05
>>211
有識者が社内にしかいないから外部に頼むと伝言ゲームになるって話だろ?

214 :仕様書無しさん:2015/02/11(水) 22:36:36.72
>>213
致命的に無能の集まりって事?

215 :仕様書無しさん:2015/02/11(水) 22:39:19.45
>>214
あなたはなにをいってるの?

216 :仕様書無しさん:2015/02/11(水) 22:48:44.32
社外から専門家がきても、失敗させるくらい
自分の会社には壊滅的に使えない奴が揃ってるって話だよね?

217 :仕様書無しさん:2015/02/11(水) 22:56:59.91
>>216
あなたはなにをいってるの?

218 :仕様書無しさん:2015/02/11(水) 23:01:27.16
日本語が通じてない…

219 :仕様書無しさん:2015/02/11(水) 23:18:00.91
>>212
いや、金融業界の非効率な開発を自慢されても困るんだがw

220 :仕様書無しさん:2015/02/11(水) 23:40:33.60
>>214
例えば家を建てるとき地下室にヒミツの拷問部屋を作るとする。
地下室から調度品(三角木馬)備品(浣腸)を全てひとつの業者にお願いしたら
拷問部屋だなとバレてしまう。
だから、バレないように色々隠したり自分でやったりするわけだよ。

221 :仕様書無しさん:2015/02/11(水) 23:54:39.17
>>220
なるほど。
自分達は馬鹿の集まりだって主張ですね。

222 :仕様書無しさん:2015/02/12(木) 00:22:14.69
国内のプログラマーって本当にこんなレベルなのか?

223 :仕様書無しさん:2015/02/12(木) 00:25:19.01
三角木馬持ってるやつなんかそうそう居らんわw

224 :仕様書無しさん:2015/02/12(木) 00:45:30.83
>>221
俺を見ないで書き込みを見れよ。
要は、外注に対しては仕様を小出しにせざるを得ない面があり
伝言ゲーム失敗状態になることが多々あるってことだ。

225 :仕様書無しさん:2015/02/12(木) 00:46:40.10
>>224
馬鹿だろお前

226 :仕様書無しさん:2015/02/12(木) 00:49:53.19
倉庫だからと地下室を発注し
便秘がひどいからと浣腸を別の業者に発注し
健康のためにと三角木馬を更に別の業者に発注。

そうすれば拷問部屋だとバレない。
察することが出来て拷問用浣腸を供給できるのがプロの外注。
またはエスパー

227 :仕様書無しさん:2015/02/12(木) 06:51:14.36
例え話いらんw
外注は社内発の業務改善を放棄したのとかわらん
それでいいならそれでよか

228 :仕様書無しさん:2015/02/12(木) 07:02:31.97
>>227
くわしく

229 :仕様書無しさん:2015/02/12(木) 08:53:35.86
> 健康のためにと三角木馬を
くわしく

230 :仕様書無しさん:2015/02/12(木) 12:36:12.54
健康の為にラブドール使ってる

231 :仕様書無しさん:2015/02/13(金) 07:10:26.00
頚椎症になった。休む時間がとれなくて仕事ばかりしていた。
夜中に胸の筋肉がつる。そして左手がしびれる
精神を病まないが、体にストレスがきた

夜中に目が覚めるのでひたすらキーボードうつ
そのほうが気がまぎれるのだな。納期なんかとっくに過ぎている

232 :仕様書無しさん:2015/02/13(金) 07:35:51.46
ドックいけ

233 :仕様書無しさん:2015/02/14(土) 17:44:29.40
他スレでみっけたもんで、しかも中身見てないけど

運用でカバー
http://gihyo.jp/magazine/SD/archive/2015/201502

外注システムでは100%ないところはない「運用でカバー」運用
これのひどいところは、

外注システムを導入すると
 効率化どころか、非効率化が促進される
 中途半端に業務の流れがシステムでブラックボックス化するので、結局全体の業務が把握できず、次第に業務に精通するものがいなくなる。
という素敵な特典がもれなくついてくる

234 :仕様書無しさん:2015/02/14(土) 17:58:39.55
運用でカバー⇒糞みたいに業務の効率化の足を引っ張るお荷物をシステム導入したお偉方の顔を立てるために無理やり業務を増やして非効率化して使っている

ということ

235 :仕様書無しさん:2015/02/14(土) 18:03:17.61
業務の作業がブラックボックス化するっていうのはわかるが、
業務の流れがブラックボックス化することはないだろ。

そもそも業務の流れを仕様にして、
その仕様を人力じゃなくてコンピュータで実現しただけなんだから。

236 :仕様書無しさん:2015/02/14(土) 18:54:58.40
>>235
中間がわかんなくなると、全部がわからなくなる
全部がわからなくなると、自然といろいろとアヤフヤになる

237 :仕様書無しさん:2015/02/14(土) 18:57:30.60
>>236
無能な奴は、何やっても無能だって事?

238 :仕様書無しさん:2015/02/14(土) 18:59:44.02
>>236
自分が使ってるプログラムの中身を
知らないと、使えないって話か?

239 :仕様書無しさん:2015/02/14(土) 19:25:55.60
人間は追い詰められないと学ばないやつが多いからね。
だからシステム化されていると、そこを学ぼうとしない。
次第にシステム化する前のことを知っている人もいなくなり
どんどん人材が自分たちの業務について無知になり
ほかの人も言ってるけど2度目以降のシステム化の話で詰む。

240 :仕様書無しさん:2015/02/14(土) 19:28:23.42
>>239
だからお前は2ちゃんねるのシステムも理解できないんだな。

241 :仕様書無しさん:2015/02/14(土) 19:33:31.96
今日のNHKの教育でやってたけどプログラミングを学生(小中学生)に学ばせるというので、意外と内容がまともだったw
てか、ここで言語の勉強だけでスキルっ!キリッ!って言ってるやつより
中学生でお掃除ロボを自分で作ってる中学生のほうがはるかに雇用したい人材だったわw

242 :仕様書無しさん:2015/02/14(土) 19:42:14.57
>>241
お前は文章力というものを身につけたほうがいい

243 :仕様書無しさん:2015/02/14(土) 20:28:02.29
>>238
使えるが、使用者が唯の作業員(ルーチンワーカー)に成りかねないという事
システムを使う側の問題。

自分も前に書いたが
>>239 の言う通り

>>241
言語の勉強だけは論外で、ここでも多いと思わないが
その中学生の何処を良いと思うのかにも因るが
現実では、現状のプログラマ等にしてしまうのは会社の方の問題
つまり、雇用したいと言っている側の責任
若手を使い捨てにするブラック飲食業と同様の問題

244 :仕様書無しさん:2015/02/14(土) 20:30:44.21
>>243
お前も文章力というものを身につけたほうがいい

245 :仕様書無しさん:2015/02/14(土) 20:33:14.67
文章力というより、はっきり言って支離滅裂

246 :仕様書無しさん:2015/02/14(土) 20:45:18.13
>>239
それなんて東電…

247 :仕様書無しさん:2015/02/14(土) 20:46:17.38
ようこんなアホどもがシステム作ってるな
情シスの幼稚園児どもと良い勝負だわ

248 :仕様書無しさん:2015/02/14(土) 20:48:55.00
>>247
お前も文章力というものを身につけたほうがいい

249 :仕様書無しさん:2015/02/14(土) 22:51:20.40
システム化すると社員が馬鹿になるみたいな流れアホっぽいっすw

250 :仕様書無しさん:2015/02/14(土) 23:00:44.58
日本語すらまともに使えないやつの思考がまともなはずもなく・・・

251 :仕様書無しさん:2015/02/15(日) 08:15:28.35
>>249
事実だからな
お前らのような単純プログラムの派遣だとわからんだろうけど
こなしたプロジェクトの数がスキルの証明っ!キリッ!
え?w毎回毎回同じような超単純な四則演算と単純Read/Writeプログラムしか書いてないのに?w
しかもその一部

252 :仕様書無しさん:2015/02/15(日) 08:33:03.21
>>251
「帳票出力」という単語を知らない。

「単純プログラム」という、中身のない悪口。自分が扱うものが「プログラムである」ということ以外何も理解していないのでは。

「四則演算とRead,Write」という、視野の狭すぎる着眼点。言語をバカにする奴はたまにいるが、さらにそれ以下。


おそらく>>251は自分が割り振られた役割も理解していないし、言語もどれひとつ覚えていない。
VBすらまともに使えないのではないか

253 :仕様書無しさん:2015/02/15(日) 09:28:40.16
プログラマで派遣、特定派遣
ってタクシーの運転手にすらなれない人間の最後の就労先の砦だからな
そんなのとまともに会話が成立するわけがない

254 :仕様書無しさん:2015/02/15(日) 09:34:42.58
>>253
もっとマトモな派遣会社と会話した方が良いよ。
君の所はその底辺なる人に依存してるレベルだから。

255 :仕様書無しさん:2015/02/15(日) 10:41:59.07
>>251はここにいる馬鹿プログラマの言うことを鵜呑みにしたユーザーサイドの人っぽい

256 :仕様書無しさん:2015/02/15(日) 11:31:31.34
>>251みたいな人間に限って彼の言う超単純な四則演算と単純Read/Writeプログラムでありえないバグを出すんだよなぁ
でバグを指摘した際の決まり文句が「言語が悪い」w

257 :仕様書無しさん:2015/02/15(日) 11:55:15.66
>>254-256
図星で反論したくて仕方なくなった症候群の方ですか
仕方ないよ
君は底辺だから

258 :仕様書無しさん:2015/02/15(日) 11:58:38.74
でもこのての派遣のやつって例外なく
転職?どこで働いてたの?
って職歴を聞くと冠企業名を出すんだよなぁ
おまえ、ただそこに派遣されてただけだろ、派遣先の名前だしてどーすんだよw

259 :仕様書無しさん:2015/02/15(日) 12:02:59.90
どこで働いてたかといわれたら
働いてた場所の名前出すのは当たり前だろう…

260 :仕様書無しさん:2015/02/15(日) 12:05:20.09
一般派遣・特定派遣の人って、日本の9割以上が中小企業だから9割以上が中小企業労働者だから変じゃないって思ってるよな。
たしかに企業の割合でいうと9割以上が中小企業。
でも労働者全体では3割以上が大企業で働いている。
3割以上という簡単なハードルすら越せないのに一般派遣・特定派遣の人って自分は有能・スキルがある。
とか言っている。DQNとホントかわらない根拠のない異常なまでの自信。

261 :仕様書無しさん:2015/02/15(日) 12:05:59.34
>>259
ふつーーーーーーーーーーの人は、他社で働きませんわww
他社常駐が普通と思ってる時点で異常

262 :仕様書無しさん:2015/02/15(日) 12:11:05.16
>>261=極めて正常
>>259=感覚が完全に奴隷

263 :仕様書無しさん:2015/02/15(日) 12:17:51.92
えー?明らかにデカイとこほど
スキルの低い人間多いような気がするけど…

264 :仕様書無しさん:2015/02/15(日) 12:21:39.30
>>261
自社で仕事してる派遣なんて聞いたことないわwww
何が知りたくてそんな質問してるんだ

265 :仕様書無しさん:2015/02/15(日) 12:32:52.27
>>263
そうだね。
使えないのはいっぱいいるね。
でも、そいつが使えないことが、君が使えることにはならないんだよ?

266 :仕様書無しさん:2015/02/15(日) 12:46:58.25
>>257
底辺同士お互い頑張って生きましょう

267 :仕様書無しさん:2015/02/15(日) 12:47:28.31
超レベル高いねこのスレ

268 :仕様書無しさん:2015/02/15(日) 12:52:31.27
内製が最強
だ・け・ど!
 情シスがカス化する(ほっとくとシステムまでカス化する)
 バカ管理職が入ると変化を見せようと外注を提言し出す
の二大問題の解決策が必要
という感じで話がある程度まとまってるのに、
派遣社員のバカが「スキル」とかいうありもしない「スキル」で話を戻すからおかしくなる。

269 :仕様書無しさん:2015/02/15(日) 12:54:25.31
派遣の人も内製を推進したほうがいいような気がする
そうすれば大企業に内製の応援で派遣されて、本当に言うだけのスキルや能力があるなら、そこで引き抜き採用されるだろうし
それこそ学歴ではなく実力で採用してもらえる
いまのように外注システム方式だと絶対に底辺PGは底辺PGのまま。たとえスキルがあっても。

270 :仕様書無しさん:2015/02/15(日) 12:57:51.65
>>265
学歴も職歴もいろいろだが、出てくる成果見りゃ
誰が仕事できて誰が仕事できないかは明白だろw

自分より高級もらってる大勢の役立たずを目の当たりにしてれば、
彼らが自信と不満を持つのも至極当然というものだろう。

271 :仕様書無しさん:2015/02/15(日) 13:00:48.96
>>269ほんこれ
>>270これ>>269でいいじゃん?
直接評価してもらえるぞ

272 :仕様書無しさん:2015/02/15(日) 13:06:21.00
自分のスキルを正当に評価してもらえるよう折衝する能力も
エンジニアとして必要なスキルの一つなんだけどな。

273 :仕様書無しさん:2015/02/15(日) 13:07:32.06
>本当に言うだけのスキルや能力があるなら、そこで引き抜き採用されるだろうし

コレが大嘘なのが問題かな…
派遣の状態でも同じことやってくれるのに
何でわざわざ雇用せにゃならんのだ。

274 :仕様書無しさん:2015/02/15(日) 14:13:25.00
>>273
いや、嘘じゃないし
派遣状態で同じことをしてもらえるなんて思ってないよ
ほしい人材はやっぱりキチッと引き抜いてこちらの社員にする

275 :仕様書無しさん:2015/02/15(日) 14:18:41.56
>>273
お前がその場所から「離れる」かもと飲み会でもどこでもいいけど、派遣先の役職付きに言ってみろ。
本当に必要なら引き抜きの声がかかるから。
声がかからないなら、代わりがいる程度だってことだよ。

276 :仕様書無しさん:2015/02/15(日) 15:04:56.23
月給:140,000~400,000 能力に応じる
正社員登用あり
フレックス制

277 :仕様書無しさん:2015/02/15(日) 15:05:26.26
本特に優秀なやつが引き抜かれるなら優秀なボクチンはとっくに引き抜かれているはずだー

とでも言いたいのかな?

278 :仕様書無しさん:2015/02/15(日) 15:06:06.66
>>275
> 派遣先の役職付きに言ってみろ。

派遣先の役職付き程度が、正しい判断できるんでしょうかね?

もし雇う側に技術者を正しく見る目があるのであれば、
もっと優秀なプログラマのみを集めているはずですがね。

279 :仕様書無しさん:2015/02/15(日) 15:07:43.80
本当に特に優秀なやつを引き抜ける
人事担当者がほしいよ。

人事担当が無能だから、口先ばっかりの奴を雇う。
技術テストすれば一発でわかるのに
なんでやらないんだろうな。

280 :仕様書無しさん:2015/02/15(日) 15:11:11.51
>>278
文句しか言えないなら声かからないのは当然

281 :仕様書無しさん:2015/02/15(日) 15:12:54.88
>>279
テストじゃ分かんないからだよ!

新しい知識の吸収力、対応力、
物事の説明能力、理解力、
自分の役割を把握しそれを拡大していく力、
長期にわたる一貫した考え方や構築力

これらはぺーパーテストや技術テストで計ることなどできない

282 :仕様書無しさん:2015/02/15(日) 15:15:02.90
>>281
> これらはぺーパーテストや技術テストで計ることなどできない

そのとおりだな。何をやってもそんなことを測ることは無理だと思うよ。
だから、そんな不可能なことまで見抜けなんて言ってないよ。

明らかにわかる部分を調べろって言ってるの。

283 :仕様書無しさん:2015/02/15(日) 15:16:45.83
プロ野球選手を、新しい技術の吸収力
対応力、以下略等、将来の期待で選ぶかってーのw

何よりも実績だよ。実績があれば
その後の伸びも推測できるっていうもの。

284 :仕様書無しさん:2015/02/15(日) 15:17:53.62
>>282
そんなの学歴と資格欄見りゃ十分じゃん。

285 :仕様書無しさん:2015/02/15(日) 15:32:21.34
実物を見て引き抜く
これ以外に最善の手法はない

声がかからない程度 別に変わりはいくらでも居る程度

の仕事しか やってない もしくは やらせてもらっていない(超人的なスキルを持っていても生かされないなら無意味)
前者でも後者でも、自分から俺様は超絶スキルを持ってるからほかの仕事もやらせてくれ!
とでも頼んで、それこそ実技テストしてもらえ
本当に優れた実績を残したなら引き抜かれるだろうさ

286 :仕様書無しさん:2015/02/15(日) 15:38:52.23
むしろそれは>>274にこそ聞いてみたいな
何人の会社で年何人引き抜いてるのか実績を。

たぶん夢とか希望とか言ってるブラック企業だろう。
人事のこと多少でも知ってたら間違ってもこんな認識にはならん。

287 :仕様書無しさん:2015/02/15(日) 16:22:33.36
引き抜かれない無能を社会や他人のせいにすんなや
恥ずかしい存在だな

288 :仕様書無しさん:2015/02/15(日) 16:28:23.97
俺が引き抜かれないんだから引き抜きなど存在しないってかw
どんだけ自分大好き、自分は有能と思いこんでるキチガイなんだよ
お前の周りのレベルがお前のレベルだ
名ばかり正社員の特定派遣がほざくわほざくわ

引き抜きは事実として行われている
お前に声をかけるバカはいないってだけだ
現実を受け入れろ

289 :仕様書無しさん:2015/02/15(日) 16:36:53.89
いつまでたっても引き抜いてもらえないから
仕方なく普通に転職して社員になりましたよ

この手の連中を信じちゃだめだ
自分に能力がないことを認められなくて、正社員であることが最後の拠り所になってる。
そしてそういうカス同士で結託して、カスの吹き溜まりみたいになってる。
大概一部のスーパーマンが全てを支えてる構図。

いくらそこで派遣として努力しようと成果を出そうと、善い様にむしられるだけだ
自分で行動起こさんとね…

290 :仕様書無しさん:2015/02/15(日) 16:36:59.94
こんな業界だから奴隷の取り合いみたいなのはしょっちゅう見掛けるけど
会社移るにあたって何千万みたいな人もいるのか?

291 :KAC:2015/02/15(日) 17:16:10.23
中国や韓国の企業に引きぬかれてってのなら最近ニュースによく出る話題。

292 :仕様書無しさん:2015/02/15(日) 20:33:26.11
>>291
それは情報の持ち出しを狙ってるだけ。

293 :仕様書無しさん:2015/02/15(日) 20:35:26.53
>>292
 ・・・ん?

294 :仕様書無しさん:2015/02/15(日) 21:12:46.46
少なくともこのスレの連中は要らんわ
会社が無茶苦茶になる
普通の業務が出来るかどうかも疑わしい

295 :仕様書無しさん:2015/02/15(日) 21:16:59.27
>>294
まったくだな兄弟!

296 :仕様書無しさん:2015/02/16(月) 01:01:45.49
>>294
そんなスレが気になってしょうがないんだね。
要らない人ってのは分かりやすい。

297 :仕様書無しさん:2015/02/16(月) 09:06:18.19
複数案件を同時にこなす請け負い >> 普通のサラリーマン >>>> 派遣

請け負いで複数案件を同時にこなせば年収2000万も夢ではない。

298 :仕様書無しさん:2015/02/16(月) 22:23:45.52
にっこにっこにー!

299 :仕様書無しさん:2015/02/16(月) 22:28:43.81
>>273
スケジュールがいっぱいいっぱいで調整つかずに
半分くらい指名断っていたら、直弾来たよ

まぁ何処の誰でも良い派遣業務なら確かに>>273の言う通りだと思うけど

300 :仕様書無しさん:2015/02/16(月) 22:35:12.57
何か珍しいスキルをお持ちで?

301 :仕様書無しさん:2015/02/17(火) 00:27:20.14
特にないと思うよ>珍しいスキル
普通に何でもやってただけだよw

302 :仕様書無しさん:2015/02/18(水) 03:47:09.82
【乞食速報】ビットコインバレンタインキャンペーン!【2/18まで】
http://j55.pw/fY7T

上記のURLから新規アカウント登録をすると
登録者全員にもれなく1000円分のビットコインが貰えます!
即時取引、円への換金が可能です!

303 :仕様書無しさん:2015/02/18(水) 18:42:48.18
内製もそうなんだけど
元請に実装能力がないことも問題

http://techpeople.jp/2015/02/apple-1/

結局は、可能な限り
あらゆることを自分たちでやるのが正しいということなのかもしれないね

自らの業務の根幹となるところは

304 :仕様書無しさん:2015/02/18(水) 19:36:35.35
*請負と労働者派遣の違いは・・・
 請負とは、「労働の結果としての仕事の完成を目的とするもの(民法)」ですが、派遣との違いは、発注者と受託者の労働者との間に指揮命
偽装請負の代表的なパターン
<代表型>
 請負と言いながら、発注者が業務の細かい指示を労働者に出したり、出退勤・勤務時間の管理を行ったりしています。偽装請負によく見られるパターンです。
<形式だけ責任者型>
 現場には形式的に責任者を置いていますが、その責任者は、発注者の指示を個々の労働者に伝えるだけで、発注者が指示をしているのと実態は同じです。単純な業務に多いパターンです。
<使用者不明型>
 業者Aが業者Bに仕事を発注し、Bは別の業者Cに請けた仕事をそのまま出します。Cに雇用されている労働者がAの現場に行って、AやBの指示によって仕事をします。一体誰に雇われているのかよく分からないというパターンです。
<一人請負型>
 実態として、業者Aから業者Bで働くように労働者を斡旋します。ところが、Bはその労働者と労働契約は結ばず、個人事業主として請負契約を結び業務の指示、命令をして働かせるというパターンです。
http://tokyo-roudoukyoku.jsite.mhlw.go.jp/hourei_seido_tetsuzuki/roudousha_haken/001.html

305 :仕様書無しさん:2015/02/18(水) 19:36:45.52
>>303
まず自分達でやってみる、というのは必要だと痛感する。
「やる」レベルは、机上シミュレーション、プロトタイプ作成など、状況によるが。
やってみた結果、自分達では無理なところを整理して外注している。

306 :仕様書無しさん:2015/02/18(水) 20:11:29.10
>>305
非常に良いことだと思うわ
「できない」という結論に至るまでの試行錯誤によって「できないこと」について詳しくなる
だから「できないこと」=「わからないこと」ではなくなる
これは発注する際に、無知な状態、技術力ゼロの状態で交渉に望まないとイケない状態が避けられる
営業が嘘をついているのも見抜けるようになる(糞会社をつかまされないで済む)
相手のいいなりの金額にならなくなる
逆に無知ゆえに明らかに無理難題の予算を提示して粗悪品をつかむなんて馬鹿な結果を避けられる

内製をして失敗するなら失敗してもいい
その失敗までの過程に得られる知識や技術が、外注を選択した際に武器になるから

307 :仕様書無しさん:2015/02/18(水) 20:19:08.83
なんで自分達が無能だって前提で話するの?

308 :仕様書無しさん:2015/02/18(水) 20:59:30.62
>>307
根拠なく自分たちが有能と思ってるよりは遥かにマシかと・・・

309 :仕様書無しさん:2015/02/18(水) 21:01:51.09
てか、元請け企業が馬鹿なんじゃないだろうか?
自分たちで実装しちゃったほうがトータルの取り分多いし、顧客満足度も高いし、結果として次の受注まで見込める。
良い会社として認識されているんだから人材は来る
なんで文系の馬鹿とるのか?

310 :仕様書無しさん:2015/02/18(水) 21:30:46.12
>>308
え?

311 :仕様書無しさん:2015/02/18(水) 21:38:58.22
>>307
無能なんじゃなくて専門外(非SIのユーザ企業)なのでは

312 :仕様書無しさん:2015/02/18(水) 22:08:17.40
>>311
なら「じゃあ自分たちで作ろう」って結論はおかしいだろ・・・

313 :仕様書無しさん:2015/02/19(木) 01:51:13.69
>>306
概ね同意

出来ない事や問題点があぶりだされているから、正しい取捨選択ができる。
アヤフヤな状態で外注しても、「騙されてるんじゃないのか?」と不信に成りやすく、
不信に思われる相手は、相応の強硬な態度になり易く、WinWin等無い。

>>309
何を持って馬鹿とするかだが、年功序列的に上がる給与や昇進させる事などから、
上がる給与体系に対して下支えするはずの人間を維持出来なくさせてるのだと思われ。
結果、効率よく上前をはねる集団になろうとする。
長期的に維持できるかは別問題として

314 :仕様書無しさん:2015/02/19(木) 12:37:05.25
>>313
そもそも見積りに根拠がないんだから、技術力とか関係なく不安にならん方がおかしいだろw

315 :仕様書無しさん:2015/02/19(木) 19:28:29.72
超回り道だらけのスレだけどたまーーーーーーーにマトモになるw

316 :仕様書無しさん:2015/02/19(木) 21:09:13.00
>>312
ほんと超弩級のバカですね

317 :仕様書無しさん:2015/02/19(木) 21:24:20.09
>>316
だね。そんな結論出すとか馬鹿もいいところ。

318 :仕様書無しさん:2015/02/20(金) 06:25:07.07
>>312みたいのがひとり間にいるだけで伝言ゲームの酷い失敗が確定

319 :仕様書無しさん:2015/02/20(金) 07:54:53.66
>>318
そんなに悔しかったのかw

320 :仕様書無しさん:2015/02/20(金) 08:33:15.67
今はある意味幸せな時代だと思うよ
何も分からん情シスを知ったかぶりで煙に巻いて検収のハンコ押させりゃ
実際上何の意味もないシステムでもカネが入ってくるんだから。
そんなだからコピペコーダーが勘違いしてのさばる

321 :仕様書無しさん:2015/02/20(金) 10:13:15.76
>>320
なにいってだおまえ

322 :仕様書無しさん:2015/02/20(金) 18:15:14.05
確かに
価値に見合うだけの売り物なのかどうかを判断できない情報システム部門があることは事実
ただこの観点は、最終的にはだからこそスレタイってことに行き着くと思う

323 :仕様書無しさん:2015/02/21(土) 10:13:47.92
>>322でもそれに気づけない>>319みたいな驚異的な白痴がいるけどね

324 :仕様書無しさん:2015/02/21(土) 11:06:02.11
>>323
お前が馬鹿だということはよくわかる

325 :仕様書無しさん:2015/02/21(土) 11:11:51.02
>>323
>>319は無職winさんだから
すべての思考が無職にふさわしい思考しかできてないでしょ

326 :仕様書無しさん:2015/02/21(土) 11:24:37.09
>>325
お前が馬鹿だということはよくわかる

327 :仕様書無しさん:2015/02/21(土) 11:27:54.60
一般的な企業情シスのアホなところは
何も分からんくせに下手なアイデアもどきを押し付けてくるところ
それが自分達の存在意義だと思いたいんだろうが
大体の場合、本質的な要件を満たさないままただ複雑に分かりにくくなるだけ

利口な人はほどシンプルに作るもんなんだがね

328 :仕様書無しさん:2015/02/21(土) 11:41:46.34
現場はシステムも組めないアホ
情シスはシステムも現場も分からんアホ
SIはシステムしか知らんアホ
現場の優秀なのに作らせるのが一番近い

329 :仕様書無しさん:2015/02/21(土) 12:04:23.44
>>328
ところが情シスがセキュリティーポリシーを現場も見ずに設定。
セキュリティー違反でできません。だらけ。
現場開発も不可能にw

330 :仕様書無しさん:2015/02/21(土) 12:05:42.37
>>328
ど素人らしい意見だなwww

331 :仕様書無しさん:2015/02/21(土) 12:13:31.66
>>330
お前のプログラムなんてど素人とかわらんだろw

332 :仕様書無しさん:2015/02/21(土) 12:36:32.74
ド素人未満ですが

333 :仕様書無しさん:2015/02/21(土) 13:12:17.64
>>332
イ`

334 :仕様書無しさん:2015/02/21(土) 14:12:02.29
内製でやるのが一番効率が良い。
内製でやるのが一番現場の成長になる。
外注は可能な限りしない。ただし絶対ではない。

ココまではまともな頭を持っていたら否定できない。
ただ、三大問題が残っている。

情シス(人材)の糞化問題
情シス(システム)の糞化問題
経営陣が内製・外注のメリットデメリットを理解できない

この3つは解決しないと駄目だ。

335 :KAC:2015/02/21(土) 14:19:15.66
>>334
前提条件から間違ってるぞ。

「内製でやるのが一番現場の成長になる。」
これは否定しない。経験積むことは成長につながるから、
他人がやるよりは自分がやったほうが経験としてはいいものになる。

間違えてるのは「内製でやるのが一番効率が良い。」←これ。
極端な例だと、やりたいことのパッケージ商品があった場合。
導入するだけで済むので、効率なんて比較にならないほどいい。
パッケージのようなものが見当たらないとしても、
普通、外部に委託する場合はその分野に長けているところを選ぶので、
フレームワークやノウハウなど、効率化の手段はいくらでも用意されている。

経験を積むために内製をするという判断はいいと思うが、
効率がいいからとか間違った判断材料で望むと失敗することになるぞ。

336 :仕様書無しさん:2015/02/21(土) 14:21:57.87
>>335
あれ? パッケージを使うという案は
元から対象外の話なんじゃないの?

パッケージがあるのなら、それは
「自社のシステム」ではないわけで。

337 :仕様書無しさん:2015/02/21(土) 14:23:24.54
>>335
パッケージ代5000万円(導入までにかかる期間半年)
内製200万(導入までにかかる期間1週間)
これウチの実際の話です。

338 :仕様書無しさん:2015/02/21(土) 14:26:41.61
パッケージが高いのは、
パッケージが売れないから。

Officeが安いのは、大量に売れているから
それだけの値段になるわけで、
もし2万円のOfficeが1/1000しか売れないならば
2000万円にしないと成り立たない。

パッケージはOfficeの1/1000よりもはるかに売れないでしょう?

339 :仕様書無しさん:2015/02/21(土) 14:27:35.69
パッケージの機能全部なんて使わんからな普通

340 :KAC:2015/02/21(土) 14:29:04.26
>>336
まるまる全部パッケージってのは極端な例だけど、
多かれ少なかれ部品はあるもんだよ。
細かいところではライブラリとか利用したりするでしょ?

>>337
笑えないけどありがちな話だねぇ・・・

パッケージってのは、想定する規模や品質など条件まで一致しないと
やたらと無駄なところに金を使うことになるから。
だからこそ、外部の経験ある会社に委託して選定やカスタマイズまで任せるわけだけど。

まあ、内製200万ってくらい小規模案件なら外に出さないのは正解。

341 :仕様書無しさん:2015/02/21(土) 16:38:48.83
>>4
この線はこうあるべきです(キリッ

342 :仕様書無しさん:2015/02/21(土) 16:41:14.48
>>335
半パッケージのカスタマイズが日本の主流じゃね

343 :仕様書無しさん:2015/02/21(土) 17:50:36.45
半パッケージのカスタマイズほど無駄なものないよなw

すでに出来たものを、壊しながら作るんだぜ?
矛盾でまくりでバグ多すぎ。
融通きかずに費用だけがかさむ。
導入してしまった手前やめることも難しい。

それが半パッケージのカスタマイズの現実なんだが。

344 :KAC:2015/02/21(土) 19:20:09.57
>>343
半パッケージのカスタマイズを色々誤解してるな・・・

ここで言われてる「半パッケージ」ってのは
適用先に合わせてカスタマイズできるように考えられたものなんだから、
お前さんが思っているような問題は全く当てはまらない。

・・・というか、具体的にどんなものだと思ってたんだ?

345 :仕様書無しさん:2015/02/21(土) 19:31:12.30
> 適用先に合わせてカスタマイズできるように考えられたもの

それ日本の会社が苦手とする分野じゃんw

ソフトウェア工学をわかってないから
"拡張可能な設計" にするという考え方が出来ない。

拡張=ソース書き換え。

ベースを書き換えることなく、プラグインで拡張するということが
できない。発想すらないことが大半だが、そもそも発想はあっても技術力がない。

346 :仕様書無しさん:2015/02/21(土) 19:32:19.49
このシステムではカスタマイズにおいくら万円かかります。

じゃあ、運用でカバーで。

これが日本のシステム開発におけるカスタマイズの現状だからなw

347 :KAC:2015/02/21(土) 19:33:27.89
>>345
自分が苦手だからといって、
日本全体で苦手だと勘違いするのはいかがなものかと思うが・・・

348 :仕様書無しさん:2015/02/21(土) 19:55:48.61
>>337
たとえゼロカスタマイズでも、この5000万ってなんの根拠もない金額なんだよなw
いろんなとこから、うちの会社にパッケージ売り込みによく来るんだけど、
うちの会社で使ってるって実績がほしいからって最終的に無料になるケース多々。
まぁ、無料でも蹴るんだけどw

349 :仕様書無しさん:2015/02/21(土) 19:57:33.32
>346
運用でカバーしちゃだめって記事は
先月のSoftware Design にのってたな

350 :仕様書無しさん:2015/02/21(土) 20:02:18.91
>>348
おまえは>>338も読めない無能なのか

351 :仕様書無しさん:2015/02/21(土) 20:24:55.36
運用でカバーとかいう発想が

やはりモンゴロイドの限界なんだろうな

352 :仕様書無しさん:2015/02/21(土) 20:42:57.54
運用でカバーしきれるなら、最初からシステムいらないよな

353 :仕様書無しさん:2015/02/21(土) 21:05:40.29
カスタマイズを否定してるバカがいるけど。
仕事というのはニーズがあるから成立するであって、そのニーズに愚痴を言うとかバカのすぎ。
パッケージにカスタマイズが普通なら、カスタマイズに対応できるように作っておくのがプロの仕事。

カスタマイズがあるから。更に言えば可能なら100000000000回の迅速なカスタマイズをやりたいというユーザーのニーズがあるから、内製を選択しているところも多々ある

354 :仕様書無しさん:2015/02/21(土) 23:06:31.53
カスタマイズなんて海外じゃほとんどしないけほとんどしないけどな。無駄な仕事と金がかかるだけ。lose-loseだが、頑張ればよしとする風潮w

355 :仕様書無しさん:2015/02/21(土) 23:12:35.95
>>354
「海外じゃほとんどしないけほとんどしないけどな」
のソースよろ

356 :仕様書無しさん:2015/02/22(日) 00:18:31.94
ソースは俺
俺にできないことが外人にできるわけ無いだろ

357 :仕様書無しさん:2015/02/22(日) 00:26:37.12
>>334
> 情シス(人材)の糞化問題

これが本当に解決しがたい問題
必要なのはしっかりとした基礎知識を持っていてかつ広い技術的視野と経験を持ってる人材なんだが
そんな人材ともなるとわざわざユーザ企業で飼い殺しになるために転職したりはしないだろう
新卒となると、最低でもコンピュータサイエンスの学士を持ち在学中に何らかのプロジェクトに関わった経験くらいは必要
数年前にSIerからウチに2名転職して来たらしいんだけど、どっちも糞だった
ちなみに工業高卒と専門卒

358 :仕様書無しさん:2015/02/22(日) 00:42:25.42
>>357
自己紹介乙
自覚有るなら頑張って

359 :仕様書無しさん:2015/02/22(日) 09:09:48.32
2つ前の会社が誰が考えたのか意地の悪いトラップを仕掛けて交渉しているw

営業が最初はうちの技術はすごい!って感じでどんどん来るんだけど、
「じゃ、一応うちの情シスとも話を・・・」ってなって、情シス(嘘)の部屋に案内するんだけど、

1、その瞬間だけ偽情シス員全員に白衣を着てもらっているw(人間はなぜか白衣という謎の権威に弱いらしいw)
2、腕に筋電センサーで動くアームロボ(⇒これ、実は簡単w もちろん精度や微妙な動きはむずかしい)
3、脳波でロボットを動かしている。開発現場をわざと通る。(実は全部決め打ちで動かしているw)
4、映像解析処理を動かして、その営業が入ってくるといろいろと解析結果が表示されたりするw
  これも、実は事前に調査済みのデータを表示しているだけ。ただのアニメーションの部分も多数w
5、こういうのをわざと奥の会議する部屋に通すまでにいくつか見せる。

たったこれだけの工程をするだけで、
最初は、「内製では、開発フェーズ終了後のランニングコストが!最新技術についていけない!」とかいろいろ
言ってた営業が完全にビビってしまうw
もう、こっち側に主導権は握られているので、価格は、相手側の最初の言い値の20分の1以下で行く。
「まぁ、御社のシステム程度ならこのメンバーならスグ作れるので・・・。このくらいの値段ならまぁ、考えないでもないです」と。
この程度でビビって帰ったりするようなら、導入価値はないだろう。という考えらしい。

下手な情シス導入するくらいならこっちのダミー情シスのほうがマシかもしれんw

360 :仕様書無しさん:2015/02/22(日) 09:13:52.73
>>353
お客様のためのシステムなのに、お客様の根本的ニーズを理解していない奴がこのスレは語ってるんだよなw
プロのプログラマが組めば、保守性や移植性、拡張性等々も当然優れてるんだろ?
ならなんで追加費用を払ってくれるカスタマイズを否定するのか?
答:無能だから。プロプロ言ってるほどの技術力の差が、サンデープログラマと比べて無い。むしろサンデープログラマのほうが実力が遥かに上。

361 :仕様書無しさん:2015/02/22(日) 11:12:29.64
ユーザー:運用でカバーしたほうが安い。開発・修正の責任取りたくない
販社:運用費と開発費どっちでも入ってくるお金は一緒
開発会社:新規開発したいなぁ・・・でも開発できる人間いないしなぁ・・・
派遣会社:運用も開発も同じ人間を送り込むだけ。開発のほうが単価高いけど、運用のほうが安定してるしメリット大

こんな感じじゃねーの
ついでにいえばソフトウェア改修したって運用の人間を削れるわけじゃないから節約にならんからね

362 :仕様書無しさん:2015/02/22(日) 11:24:05.57
アニメーターは好きで絵を描いてスキルで稼いでいる。
プログラマも好きでプログラミングしてスキルで稼いでいる。
だからプログラマもアニメーターと同じ給料にしよう。時給100円で。

363 :仕様書無しさん:2015/02/22(日) 11:27:35.68
べ、べつにプログラミングなんて好きじゃないんだからねっ!!

本当にプログラムに興味ない奴が増えすぎだわ

364 :仕様書無しさん:2015/02/22(日) 11:55:44.38
>>361
まともなシステムなら削れるよ
昨今99%は失敗してるからそう思うのも無理ないけどね

365 :仕様書無しさん:2015/02/22(日) 12:46:04.14
アニメーターは待遇はアレでもある程度の絵が書けるのが就く仕事だからなあ。
クラスとか学校で絵を書くのが一番うまかったような奴が多いから、好きで
いられるわけで、未経験者未能力者OKのマでそんなこと出来ないって。
下手するとフリーフェアだのオープンソースだので稼げるところも稼げない
ようにするのが多いところで賃金下げるのは自殺行為だよ。

366 :仕様書無しさん:2015/02/22(日) 13:54:34.39
アニメーターがスキルっ!キリッ!
っていうのはわかる。
でも今のプログラマがアニメーター達のようにスキル!キリッ!
って言うほどの他者が習得困難な技能をとは到底思えない

367 :仕様書無しさん:2015/02/22(日) 13:56:51.83
>>362
1オブジェクト250円でええやん
不採用なら支払われない方式で

368 :KAC:2015/02/22(日) 13:58:52.91
>>366
自分が技能持ってないからといって、
業界全体で技能不要だと勘違いするのはいかがなものかと思うが・・・

369 :仕様書無しさん:2015/02/22(日) 14:18:43.13
>>368
アニメーターは少なくとも最底辺ですら一般人がまったく歯が立たないレベルだけどね

370 :仕様書無しさん:2015/02/22(日) 14:24:36.30
スキルが違いすぎるとはいえ
敷居の高さがもはや比較にならん

プログラマは就職できない奴の最後の砦くらい簡単になれる

371 :仕様書無しさん:2015/02/22(日) 14:32:05.24
絵はマジで1年2年で身に付くもんじゃないからな
本当に絵の好きな奴はずっと描いてる
習得までに要する期間を考えたら比較するのが失礼なレベル

372 :仕様書無しさん:2015/02/22(日) 14:58:36.29
>>369
妄想はいいから

373 :仕様書無しさん:2015/02/22(日) 15:00:38.76
>>372いや少なくともコレは事実だよ

374 :仕様書無しさん:2015/02/22(日) 15:02:24.07
未経験OKの業界と、採用試験で実技がある業界

そら土台差がありすぎるわな

375 :仕様書無しさん:2015/02/22(日) 15:31:27.60
絶対数ではどうなんだろうな
絵を描くのが好きな人間とプログラミングが好きな人間、どっちが多いんだろ
まあ需要はプログラマーの方が多いから現状なんだろうけど

376 :仕様書無しさん:2015/02/22(日) 15:45:07.91
>>375
数で言えば絵を書くのが好きな人間の方が圧倒的に多いよ。そうじゃないなら
コミケみたいなイベントが成立しないって。

377 :仕様書無しさん:2015/02/22(日) 15:45:53.60
妄想はいいから

378 :仕様書無しさん:2015/02/22(日) 15:48:06.68
プログラマに実技試験あるわけないじゃん
自社で働かせるわけじゃないだし

379 :仕様書無しさん:2015/02/22(日) 15:48:51.07
ないだし

380 :仕様書無しさん:2015/02/22(日) 16:00:35.20
内製だろうがパッケージだろうが委託だろうが
途中で止めてデータを弄れないなら却下だわ

現場じゃ何時もと違う処理なんて希に良くあることだからw

「基本的に〜」とか言う奴は一昨日きやがれってんだ!

381 :仕様書無しさん:2015/02/22(日) 16:07:17.03
そうだな
資料を改竄したり脱税したりするとき困るもんな!

382 :仕様書無しさん:2015/02/22(日) 16:37:39.11
>>376
いや、明らかにプログラマのほうが多いだろw
人様に出せないプログラマもプログラマを名乗ってるくらいや

383 :仕様書無しさん:2015/02/22(日) 16:41:22.02
>>380
それ全権網羅できてないだけじゃ・・・・。

384 :仕様書無しさん:2015/02/22(日) 16:43:20.46
どうして君らは無駄話ばっかなの?

内製最強。
情シスのあり方どうすっぺ。

これが今のところの議題だっぺ。

385 :仕様書無しさん:2015/02/22(日) 16:45:15.20
こいつら会社でもこんなピントの外れた話してるんだろうな

386 :仕様書無しさん:2015/02/22(日) 20:45:23.67
>>384
一律に、内製が是か否かを決めようとすると、無理があるんじゃないか?
どういう状況なら内製が意味が有るか?
という問題設定なら関心が有る。

387 :仕様書無しさん:2015/02/22(日) 20:53:13.38
>>369
仮にそれが事実だとしても、証明の半分でしかない。
残り半分の証明方法を自力で考えられるなら、プログラミング出来る。

388 :仕様書無しさん:2015/02/22(日) 21:44:20.32
まーた論点ぼかしだよ

389 :仕様書無しさん:2015/02/22(日) 21:47:31.22
>>386
業務系はほとんど該当

390 :仕様書無しさん:2015/02/22(日) 22:25:03.66
どういう状況、って
今の外注システムの惨状を知らねーのかよ
本当にプロか?

391 :仕様書無しさん:2015/02/22(日) 22:42:01.10
スルガ銀行、東京ガス、みずほ銀行
表に出てこないものまで含めたら失敗プロジェクトがどれだけあるか

392 :仕様書無しさん:2015/02/22(日) 22:42:45.07
なんだ妄想か

393 :仕様書無しさん:2015/02/22(日) 22:50:23.94
昔はシステムなんかなくても上手くやってたんだ

Excelで管理すればいいじゃん

394 :仕様書無しさん:2015/02/22(日) 22:57:00.50
excel管理にすら届いていないところは意外と多い。

395 :仕様書無しさん:2015/02/22(日) 23:00:56.60
クソwebシステムだと手書きの方が早い場合すらある

396 :仕様書無しさん:2015/02/23(月) 00:39:46.01
>>357
問題の認識は正しいと思うが、解決策はまた違うと思うよ
内部にスキル無く、現場の御用聞きとは名ばかりの雑用係になったり、
外注するにも現場の問題をSI的な解法へある程度見越し立てて話をすることが出来なくなり、
また、技術も無く、外注の能力も判断できず、見積もりも数字見て値切る購買部に成り下がる
コレは、情シスを使う側の顧客会社内の無知無理解が根本
ついで情シスの上司の行動。

>>395
システム化の目的はデータ蓄積とその検索の容易化、管理にあることが多いから
手書きの方が早い事に囚われるとね
折角登録しても、そこが使えないシステムは論外だけど

397 :仕様書無しさん:2015/02/23(月) 02:19:49.62
銀行だって本気だせば手書きで処理完了できる
本当にコンピュータなど必要なのか?

398 :仕様書無しさん:2015/02/23(月) 02:25:30.06
本気を出さなくても処理できるならそっちを使うだろ

399 :仕様書無しさん:2015/02/23(月) 02:45:53.31
プログラマに払う金を自社の社員の人件費や残業代にあてたほうが安いんじゃねーのって事

400 :仕様書無しさん:2015/02/23(月) 06:29:10.90
社内プログラマとして若い派遣を使う。40歳で強制引退。
35歳から新システムの開発を後任とやる。
んで終了とともに契約切れ。
これで代謝が良くなる。

401 :仕様書無しさん:2015/02/23(月) 06:31:12.06
実際、今働いてるやつらの大半は手作業のほうが効率がいいケースが大半だからな。
無駄にグラフや絵やカラー使って書類作成してるけど、そのために膨大な時間を費やしている。

402 :仕様書無しさん:2015/02/23(月) 06:40:28.53
>>400
派遣を使う時点で代謝が良くなる以前にただの劣化じゃん・・・

403 :仕様書無しさん:2015/02/23(月) 10:42:43.53
パワポ不要論

404 :仕様書無しさん:2015/02/23(月) 11:51:13.66
>>390
現状ベースでしか物を考えられないから問題なんだろうな。

405 :仕様書無しさん:2015/02/23(月) 12:08:03.27
全てをひっくり返して理想のシステムを構築してやる!!

全て破たんしました

406 :仕様書無しさん:2015/02/23(月) 18:53:38.18
ある大手は過去に開発者が居なくて困ったので内製でもやっている
しかし、大半の大手は請負、派遣に出している
やっぱ金額か

407 :仕様書無しさん:2015/02/23(月) 21:06:27.92
>>383
お前さんは未来に決められる法律など
森羅万象を今まさに見極めているとでも?

408 :仕様書無しさん:2015/02/23(月) 21:09:08.22
法律変わったらアップデートしろよw
ずっと運用で対応する気か

409 :仕様書無しさん:2015/02/23(月) 21:18:15.39
>>408
こういう運用もあるな。
http://i.imgur.com/urGB2PQ.jpg

410 :仕様書無しさん:2015/02/23(月) 21:34:39.43
>>409
なぁ、そういう画像を集めるのが好きなの?

411 :仕様書無しさん:2015/02/23(月) 21:38:15.08
>>407
普通は施行前に調べて施行日からロジックがきり変わるようにする

412 :仕様書無しさん:2015/02/24(火) 01:43:30.49
>なぁ、そういう画像を集めるのが好きなの?

俺のレスにも貼られたことある

413 :仕様書無しさん:2015/02/24(火) 17:20:18.11
うちに一人派遣35歳、いろんな現場を回ったというのが自分のスキルの根拠のように言っているやつが居て
新卒高卒10ヶ月より作業能力やプログラムのソースの質が圧倒的に劣っているのを自覚したのかイジメをはじめた
まぁ、相手よりレベルが劣っていることを認識できるだけまだマシなほうなのかもしれんが・・・
(というより、そいつが3ヶ月かかっても終わらずに逃亡図ろうとしたものを、ゼロから3日で終わらしてきたから誰の目にも明らかなんだけど)
いっせいにフロアーの人全員(40名)が「てめーがいらねーんだよ!」「だせー!1年目に負けて、腹いせにイジメかよ!」ってそいつを口撃
うぁぁぁぁ!って言いながら、走って逃げていきましたw
アホの置いていった荷物どうすべき?

414 :仕様書無しさん:2015/02/24(火) 17:22:26.53
>>413
お前もはやく辞表提出すべき

415 :仕様書無しさん:2015/02/24(火) 17:30:19.91
40人もいて誰もその35歳を助けてやらなかったのか
正社員による派遣イジメって怖いね
でも、技術を買ってるんだから出来ないなら金返せって事だよね

416 :仕様書無しさん:2015/02/24(火) 17:40:30.36
派遣は自己のスキルとやらを売りにしてるんだから、高卒18歳の1年目に負けりゃ、もはや何も語る資格はないわなw

417 :仕様書無しさん:2015/02/24(火) 17:50:09.24
正社員だったらスキルはいらないっと・・・(メモメモ

418 :仕様書無しさん:2015/02/24(火) 17:50:28.78
いくら凡人以下の人間が努力したところで、
天才がちょっと勉強しただけにも勝てないんだよな

35歳はたいした努力もせずに歳だけ食ったんだろうから、
凡人にも負けかねない

419 :仕様書無しさん:2015/02/24(火) 17:55:53.88
40人全員が派遣という可能性も否定できない

420 :仕様書無しさん:2015/02/24(火) 18:01:53.31
荷物は派遣会社に着払いで送ればいいよ
どうせ次の派遣を連れて挨拶に来るだろ?その時に着払いで送らせてもらいますって一言いれときゃいいよ

どんなもの作らせたか知らないけど、3日で終わるのは手が早いよ。かなり優秀なんだろう
逆に3か月も成果がでない派遣を使った管理者は責任を問われるべきじゃないかな

>>419
同じ派遣元で助けてないなら問題だし、別の派遣元なら余計な口出ししてトラブル引き受けないよ
その高卒と35歳が別会社で、高卒の仲間が攻撃しかけてきたっいうならあり得るけどね
派遣の椅子の取り合いで攻撃しかけるのは珍しい話じゃない

421 :仕様書無しさん:2015/02/24(火) 18:06:45.74
生まれ持った才能の差や、DNAや環境の差っていうのは確かにあると思う
でもおまえらはそれを言えるほど努力をしたのだろうか?

422 :仕様書無しさん:2015/02/24(火) 18:12:11.40
一人派遣って、一人親方みたいなセルフ派遣かと思った

423 :仕様書無しさん:2015/02/24(火) 18:17:44.85
それは一人請負だろw

424 :仕様書無しさん:2015/02/24(火) 19:00:18.46
>>422
一人派遣とフリーの区別もあんま無いかもしれんな

425 :仕様書無しさん:2015/02/24(火) 20:48:35.17
内製をやる企業で、採用人事にあんまり権限を及ぼせないところは
派遣で試用して引き抜くのが一番いい。
人間的に終わってるやつか?
言われたことちゃんとこなせるタイプか?
相当程度の社会性を持っているか?(内製だと必須)
現時点で使われている技術以外を吸収しようとするタイプか?
etc..........
実際一緒に長期で働いてみないとわからんもんは、引き抜きしか手はないからなぁ

426 :仕様書無しさん:2015/02/24(火) 20:56:14.55
やりすぎると派遣してくれなくなるぞ

427 :仕様書無しさん:2015/02/24(火) 20:58:45.40
引き抜きなんてただの妄想だろ

428 :仕様書無しさん:2015/02/24(火) 21:17:58.81
>>426
100万くらい払えばいいって話は聞いたことある

429 :仕様書無しさん:2015/02/24(火) 22:12:19.33
派遣引き抜きがダメっていうのがまずわからんな
どうせ30代半ばで捨てるんだから引き取ってもらったほうが後腐れがないじゃないか
恩も着せられるしな

430 :仕様書無しさん:2015/02/24(火) 22:17:57.88
妄想はもういいから

431 :仕様書無しさん:2015/02/25(水) 00:02:31.92
>>411
それは網羅じゃ無いでしょ・・・

432 :仕様書無しさん:2015/02/25(水) 06:52:33.02
>>426
そんなに頻繁に取ることはないよ
5年に一人とか10年に一人とかだから。
内製なら。

433 :仕様書無しさん:2015/02/25(水) 08:20:35.04
訴えないから使い捨て派遣
お前らも告発者を見習え

三菱UFJ銀行、偽装請負疑惑で訴訟 社内で暴力事件発生、日立子会社は告発者を解雇
http://biz-journal.jp/i/2015/02/post_8796_entry.html

434 :仕様書無しさん:2015/02/25(水) 18:31:16.22
http://hunter-investigate.jp/news/2015/02/23-saga-pc.html

こんな要求や内容が簡単なシステムでも実用に耐えられないシステムを平然と導入させるのが、この業界。

これは大規模な実験としてやったから結果が知れ渡ったけど
現実の大半は、実務に耐えられないシステムを押し付けられて泣き寝入り

435 :仕様書無しさん:2015/02/25(水) 19:00:03.18
>>434
泣き寝入りせずに損害賠償請求できそうな案件だが

436 :仕様書無しさん:2015/02/25(水) 20:29:02.22
>>434
そんな記事鵜呑みにするのが馬鹿

437 :仕様書無しさん:2015/02/25(水) 20:43:18.71
>>434
こんなの要求を相手から聞かなくても、やりたいこと当てられるレベルなのに失敗www
どうなってんだよwwwIT業界はwwww
って笑ってるけど
実際>>434の言うとおり、外注が「役に立っていると思ってるシステム」で、実際はこんな状態のお荷物。
マジでお蔵入りか業務を圧倒的に非効率化させて運用しているところ沢山ある。
餅は餅屋というが、餅屋はちゃんとした餅を売ってくるけど、
ITはインフォメーションテクノロジーを売ってこないでインチキテクノロジーを売ってくる

結果、ユーザー側が不満を抱いてついに内製回帰なんて話題が出てくる

438 :仕様書無しさん:2015/02/25(水) 22:16:34.88
>>434
システム内製とはあまり関係ないな
コンポーネントの組み合わせに関する情報収集は、まだ人買い大手ベンダの方が得意だろ

439 :仕様書無しさん:2015/02/26(木) 06:51:32.72
構築したのは紛れもなくIT業界の

プロ

だよ

440 :仕様書無しさん:2015/02/26(木) 07:31:54.39
目的を達成するための仕組みがシステム開発。
プログラミングがなきゃシステム開発ではない。なんてことはない。

このケースもパソコン大好き先生に職務としてやらせて責任負わせてやらせたほうが絶対うまく行っただろう。

441 :仕様書無しさん:2015/02/26(木) 07:50:54.61
しかしフォローのしようがないほどお粗末な結果だな
すべての学校にシステム導入できるチャンスを潰してしまったな
ひとつの会社のミスがIT業界から学校ビジネスを奪った

442 :仕様書無しさん:2015/02/26(木) 08:35:54.97
まあ、予算がいくらで納期がどれくらいだったか気になるところだな。

443 :仕様書無しさん:2015/02/26(木) 12:48:09.13
型落ちのバッタもんPC売りさばいて、システム導入しました!

444 :仕様書無しさん:2015/02/26(木) 12:54:38.31
自社で作りたいなら自社で作ってくれ
外注を惑わすな
企業の社長達から、自社のIT技術者が何してるかわからない。
自社のIT技術者減らしたいと言われ
システム作っても
社長さんシステムわからんから、結局自社のIT技術者に聞いて
嘘並べられ、結局stop
金貰ってるが、面倒くさいだよ
はっきり言うが、企業の経営者は、専任技術者なんて不要としか思ってないぞ
経営者にとって、会社が機能すれば面倒くさかろうが関係ない
それより、数年専任技術者置く費用を気にするんだよ
頑張って首切られないようにしてくれや
企業に専任してた技術レベルじゃ、外注に再就職も無理だろうし
頑張ってや

445 :仕様書無しさん:2015/02/26(木) 13:27:32.90
外注の方がレベル低いのに何言ってんの?

446 :仕様書無しさん:2015/02/26(木) 13:32:13.12
>>443
たぶんそこが失敗の原因だな
運用の負担減の為にパソコン統一するのはわからない話じゃないけど
まず納品ありきの商売だったんだろう

447 :仕様書無しさん:2015/02/26(木) 15:55:33.90
技術力なんて、技術者個々の問題で
常駐だろうが、外注だろうが
派遣だろうが、年齢や職種すら
関係ないだろ、その技術者の技術力なんだから
会社を経営する者からして
外注は、仕事を受け売上を上げるから、お金を生み出す者で
社内IT技術者は、浪費する者だよ
浪費する者か、売上を生み出す者になるのは、大変な事だ
失敗した技術者を一杯みてきたよ

448 :仕様書無しさん:2015/02/26(木) 15:57:30.44
技術力でお金は稼げないよ

449 :仕様書無しさん:2015/02/26(木) 16:11:30.56
>>447
社内技術者は非生産部門か
それは確かにそうだな
外注管理を任されてるにすぎない

450 :仕様書無しさん:2015/02/26(木) 17:54:56.87
>>444
誰一人として

クソ化した情シスを擁護してる奴なんてこのスレにいないわけだが?

451 :仕様書無しさん:2015/02/26(木) 17:57:00.90
というか、今の論点は
クソ情シス対策
だし

452 :仕様書無しさん:2015/02/26(木) 18:02:56.89
技術者が経営者の場合、安くてある物を使って労力を使って経費を少なくする。
技術がわからない経営者ほど、自社システムにこだわる。
正しいのはどちらかは、わからないが
自分が経営者でないのに、会社の為に技術・労力使ってもったいなくないか?
せっかく持ってる技術、自分の利益の為に使おうよ
サブビジネスとか、ナイトパワーとか
起業とかさ

453 :仕様書無しさん:2015/02/26(木) 20:01:34.25
俺はソフトハウスの人間だけど内製の傾向には賛成
理由はシンプル
内製やろうってことは、それだけ技術者に理解があるということだろうし
それは自分たちの価値を高く評価してくれている証拠
今みたいに人海戦術護送船団方式でシステム開発しているバカな状態より遥かによい

454 :仕様書無しさん:2015/02/26(木) 21:07:33.99
今日、情報システム部がぜんぜん修正してくれない(つーても外注のシステムだけど)から頭きて、逆コンパイルしていじって、自分修正したったわw
3時間も1回あたりかかっていた処理が4分で終わるようになったわ。気持ちよかったわwココまで差が出ると
同じ部屋の人もびっくりしてたわw同じ処理でなんでこんなに速度が違うの?ってwそりゃ無駄処理だらけじゃ遅いわ
しかしまぁ職業プログラマを引退して15年も経ったけど自分のプログラミング能力めちゃくちゃ衰えたなぁと感じたw
一回で綺麗なアルゴリズムが浮かばないwwまぁ、下手糞だらけの業界の平均よりは遥かに上にはいるようだわw
まぁ下を見るべき業界じゃねーけどw下はプロなのにシステム組めないからw

455 :仕様書無しさん:2015/02/26(木) 21:33:19.74
確かに、最近の外注業界は技術がない
26年この業界に居て、下請け個人事業主で今現場に居るが
要は、人不足
若い技術者や未経験を教育もせず現場に放り込む
SEも経験不足で、炎上現場ばかり
俺みたいな経験豊富、営業能力有り
リーダー能力有りが
火消しに短期で飛びまわってるよ
腰を据えて一つの職場なんて無理です
依頼が多くて

456 :仕様書無しさん:2015/02/26(木) 21:42:35.85
オブジェクト指向やコンピューターの高速化
いずれも悪いことではないんだけど、そのおかげでプログラマをギリギリ名乗っていられる。っていうプログラマだらけになった感がある。

457 :仕様書無しさん:2015/02/26(木) 21:43:08.13
【設問】
>>454を読み、彼の愚かさを最低3つ答えよ(20点)

458 :仕様書無しさん:2015/02/26(木) 21:45:35.45
なにか勘違いしてるな
派遣会社って派遣先が決まってからそこらの素人を採用するんだぞ
なんで技術なんて持ってるんだ

459 :仕様書無しさん:2015/02/26(木) 21:50:10.08
>>457
同じ処理と言うが、明らかに別物にしてるよな。

460 :仕様書無しさん:2015/02/26(木) 21:51:08.02
どんなに大手のソフトウェア会社だろうが
メーカーだろうが
大手人材派遣会社だろうが
経験の浅い技術者がやれば
クソみたいなシステムになるよ
経験積んだ下請けが居るから
納期が間に合い、品質を向上できる
町工場と同じ、良い下請けが参加したかで、システムの完成度がかわる

461 :仕様書無しさん:2015/02/26(木) 21:55:53.45
中卒だらけの町ソフトハウスが日本のITを支えている

462 :仕様書無しさん:2015/02/26(木) 21:57:54.48
技術・経験のある下請けなんて、そんなに居ないからな
だから、取り合いなのよ
取れない会社は、数合わせの若手入れるから、クソシステムのオンパレード

463 :仕様書無しさん:2015/02/26(木) 22:06:03.78
下請けのほんとにオンリーワンの手工業の方々と一緒に考えるなよ
下請けの高度な技術は
 ずーーーーーーーーーーーーーーーーーーーーーーーーっとおんなじ作業をやってる
 環境がまーーーーーーーーーーーーーーーーーーーーーーったくかわらない
だから感覚が神の領域に入る

この業界ってかお前らは、プラットフォームが数年ごとに変わってる
だから永久に初心者⇒中級者⇒また初心者の繰り返し。

464 :仕様書無しさん:2015/02/26(木) 22:13:26.74
>>457
・プログラマ(この場合、外注会社)に対して不必要に不信感と無能感を抱くようになる(このケースだと不必要ではなく正しい認識になるけど)
・3時間の仕事しているフリ休憩がとれたのに、4分になってしまってほかの仕事を押し付けられる
・2時間56分分の残業代が稼げなくなる
・情報システム部がヤキモチ焼いて外注会社にチクって保守対象外に故意にして問題化させようとする
 (ほっとけばその外注業者じゃ見抜けないだろう技術力だと推測されるにもかかわらず。)
・15年も前に引退したやつに>>457が負けてる感がして>>457がきぃ〜くやひー!と八つ当たりして周囲が迷惑する

465 :仕様書無しさん:2015/02/26(木) 22:13:54.08
高卒だけど
下請けを舐めてもらっちゃ困るな
機密保持契約があるから詳しく言えないが
新しい言語は一週間て実践レベルまで持って行く
現場に初日から馴染む
基本設計から詳細設計、コーディングからテストまで文句言わずこなす
新人教育までするよ
今最新の言語で、海外のエンドユーザの開発を外注リーダーでこなしてるよ

466 :仕様書無しさん:2015/02/26(木) 22:18:50.59
>>465
うむ。当たり前すぎてなんて言ったらいいのやら・・・。

467 :仕様書無しさん:2015/02/26(木) 22:25:38.07
俺なんか入るまえから現場に馴染む

468 :仕様書無しさん:2015/02/26(木) 22:27:13.69
入社してから一度だって同じ言語のプロジェクトに投入されたことないよ
そんな状態だから実戦の場のレベルが低くなっていってるんじゃないだろうか

469 :仕様書無しさん:2015/02/26(木) 22:48:05.77
>>466
当たり前だ、当たり前だがIT技術者は出来ない
知識があれば、要りもしない技術を使い
地位が高ければわがままで
長く居れば、面倒くさい事を嫌い
開発だけできればコミニケーション能力も不要とか
一癖二癖もあるのが、IT技術者よ
俺は、下請けIT土方自営業だから
面倒くさかろうが、嫌いだろうが
実費、売上になれば良いのさ
だから、当たり前の事ができるのが売りなのさ

470 :仕様書無しさん:2015/02/26(木) 22:58:05.17
>>463
おっさん技術者を舐めてもらっちゃ困るな
windowsも無い時代からやってるんだ。
ビット知識からos知識、メモリ管理の基本は変わらんよ
でなきゃ一週間で実践レベルにならんよ
予習もしてるしね
ITの下町ソフト技術者は、基本知識から最新技術、応用力、適応力が要だ
ネジ一つからじゃなく、1ビットから丹念に品質良く作りまっせ
(´・ω・`)

471 :仕様書無しさん:2015/02/26(木) 23:01:04.27
windows95ぐらいでOSの設定がわからなくなり始めて
.NETぐらいでプログラミングもついていけなくなったわ
というか、速度ばかり要求されて「ここはこうに決まってるでしょ、勘だよ勘」みたいな手法になってきて
とことん確認する俺のスタイルじゃゴミ扱いされるんだわ

472 :仕様書無しさん:2015/02/26(木) 23:04:05.33
>>464
これが何をやっているか言ってみな
http://codepad.org/Ug6JotSZ
Java厨だったらすまんな

473 :仕様書無しさん:2015/02/26(木) 23:20:50.47
>>458
法律的にも本来ならスキルのあるのを派遣しなければならないのだが、
派遣が増えだした時に人手不足だったりでなあなあでやってきたり、
特定派遣だと出来るのと出来ないのを抱き合わせ出したりでモラル
ハザードが起きて今に至っているんだけどね。

スキルが足らない素人は派遣会社に突き返して問題ないんだけど、
そういうのが判別出来るのが上にいるかといえばそうでない場合も
少なくないし。

474 :仕様書無しさん:2015/02/26(木) 23:45:51.60
>>471
俺は、自己投資してきたよ
新しいosがでれば買って試すし
新しい言語は、本を読み予習する
知らない技術は、機械を買って試す
今じゃ自宅がソフトウェア会社並みの機械、資料が揃ってるよ

475 :仕様書無しさん:2015/02/27(金) 00:09:40.51
>>474
それはもちろんしてたよ
枝が増えすぎてそれぞれの深さがなくなっていったんだ

476 :仕様書無しさん:2015/02/27(金) 00:23:38.26
後は、経験の数かな?
初めは誰でもダメダメだから
何回も怒られながら、何回も失敗しながら覚えてきたよ
現場の数、言語の数、対応業種の数、見てきたソースの数かな
今は、感覚でソースの問題箇所がわかるよ
数こなすと、経験が勘になるから
解らなければ、若手だろうと頭を下げて聞くよ
わからないまま後の問題を起こすより、聞いて確実に仕上げる
それがプロさ
開発に時間が掛かっても、テストでバグ出さなければ、トータルとして早く終わった事になるよ

477 :炎上案件消火請負人仕様書欲しいさん:2015/02/27(金) 01:15:24.16
>>458
派遣の種類を勘違いしてるかな?
派遣には、人材派遣と技術派遣の2種ある
人材派遣は、事務員や工場労働者など一般的知識で出来る仕事の派遣だ
技術派遣は、看護師やit技術者など資格や専門的知識、実務経験者などの派遣だ
技術派遣にいきなり素人は、少ないと思う
まぁ、派遣先がOKならば良いのだろうが
ちなみに下請けは、契約形態にもよるが給料制でなく成果報酬だ
出来なければ金にならない。
例で言うと、コンパイラーのバージョンを上げたいからヨロシクねといわれ
一ヶ月一人で60万でやったことあるよ
客先は大手メーカーだがね、仕様書タウンページぐらいの厚さだったかな
あと、技術支援や技術指導、保守なんかもある
価格は、決まっているようで決まっていない
客先からすれば、派遣雇って5人月でやるより実績のある下請けに出したほうが安いらしい
基本名指し依頼、個人事業者だから客先口座無いから紹介会社通すがね
実務と金額が折り合えばうけるよ
商流まもって、依頼が早いもん勝ちでやってるよ

478 :仕様書無しさん:2015/02/27(金) 01:40:57.79
1. 派遣先が決まる
2. 適当な素人を契約社員として雇用
3. 客先に送り込む
4. 「この言語、本当はやったことないです」と泣き崩れる
5. 返品されてくる(2に戻る) or こき使われてすり減って契約満期
6. 契約満了につき解雇
7. 失業保険も貰えない状態で放り出される

雇用時には契約期間の話なんてしないから解雇は突然やってくる(人寄せの為に口頭で長期契約と吹聴)
社会保険かけておくといってたのに退社後にあわてて手続
解雇はせいぜい3日前に通告されるので転職先を探す暇もない
別の仕事とあわせて1年以上の雇用保険に入ってるから失業保険もらえると思ってたら
会社がいつまでも退社手続をしない為にハローワークで受理されず3か月以上たってから給付開始

以上。これが特定派遣会社の日常

479 :仕様書無しさん:2015/02/27(金) 07:17:12.10
>>477
プログラマの大半が派遣
新卒も。ならいきなり素人が、、、は現実離れしすぎでは?
実際、マトモにプログラマ名乗れる奴なんて何人に一人の確率か、、、

480 :仕様書無しさん:2015/02/27(金) 07:17:27.90
>>478
必ず無いとは言わないが
現場で働く自営業だから言わせてもらうが
商流を無視した話だな
実話か?デマでないだろうな?
技術派遣会社は、派遣して利益稼ぐんだよ、長く派遣すると利益がでるんだよ
良い人材を派遣しないと、依頼元から二度と依頼がこない
中間会社の存在しってるか?
派遣会社と中間会社は、都道府県単位て繋がりあるんよ
失敗した情報はすぐ流れる
失敗したら依頼元からも中間会社からもブラックリスト入り
依頼が来ないなら会社が潰れるだけ
そんなリスクをおかして技術派遣に素人送るわけないだろ。
本当に技術派遣の営業現場しってるか?
人材派遣なら有り得るが、技術派遣て今まで聞いた事も見た事もないな
たまたまかもしれないが
26年も見てないよ

481 :仕様書無しさん:2015/02/27(金) 07:40:38.08
商流って言葉、初めて聞いた

商習慣みたいなもの?

482 :仕様書無しさん:2015/02/27(金) 08:08:40.83
初めてというのもどうかと思うけど、使う言葉でもないなあ

483 :仕様書無しさん:2015/02/27(金) 08:15:55.71
新しいOSを試すって言っている人に限ってWindows限定なんだよな
UNIXやLinuxの話になると大抵血相を変えて逃げていくか、Windows以外のOSを叩き始める

484 :仕様書無しさん:2015/02/27(金) 08:17:56.39
商流とは、商売の流れ
IT業界では、暗黙のルールよ
経営者、営業レベルがしってる
流れを説明しよう
@元請け仕事を受け、元請けに口座をもつ外注会社に人集めを依頼する
A外注会社から、取引きのある紹介会社に、必要条件付きて各派遣、請負、個人下請けに人材紹介依頼する
B派遣、請負、下請けは、条件に合えばスキルシートを提出
C紹介会社は、スキルシートを見て
行けそうな人材のスキルシートを元請けに提出
D元請けが精査して、面接へ
この流れで商流は、Cで同じ人材のスキルシートがくる事がある
そこで早い者勝ちの商流が発動
金額でなく商流を元に決める
不公平ないだろ

485 :仕様書無しさん:2015/02/27(金) 08:32:56.24
>>484
でも、同業から見ても残念な学歴、残念な職歴、残念な実際の技術、残念な経歴詐称・・・・
これらが大多数を占めているよね
つまり、全体が糞なら糞を自浄する機能は働かないってことでしょ

486 :仕様書無しさん:2015/02/27(金) 08:34:20.33
>>483
今から新しいOSまで手を出したら
24時間のうち、8時間45分会社として、2時間食事等々として、1日10時間くらいやっても30歳くらいまでは、まったく追いつかないよな・・・

487 :仕様書無しさん:2015/02/27(金) 09:56:47.63
>>454
最近の言語は逆コンパイルするとかなりまんま戻るからなw
技術力の低いプログラマはバレないように難読化しとくべき

488 :仕様書無しさん:2015/02/27(金) 10:23:27.67
>>487
まぁ、そんなことをしてる時点でソースに自信がないってことを外部に表現してるんだけどな
そんな行動に出た時点で謙虚になれれば勉強しなおすんだろう

489 :仕様書無しさん:2015/02/27(金) 11:26:25.90
>>465
下請がそこまでやるから世の中おかしくなるんだよ
ちゃんと見合う収入になってるんだろうな

490 :仕様書無しさん:2015/02/27(金) 11:38:45.49
>>480
自営業受け入れるスキルのある現場とここの連中がいる現場って全然違うよ
商流の常識が違う
技術派遣なんてもの存在してるのは知ってるけど見たことはない

491 :仕様書無しさん:2015/02/27(金) 11:49:12.51
>>484
よりによってマ板で丸数字はどうだろう
これぐらい鈍感でないとダメってことかな

>元請けが精査して、面接へ
素人の元請けが何を面接するんだろ

492 :仕様書無しさん:2015/02/27(金) 12:13:25.58
>>491
丸数字失礼した。

元請け面接は、ヒーリング?
まぁ、元請け企業の受入れ手順みたいなもんだろう
実際外れも多いだろうし

493 :仕様書無しさん:2015/02/27(金) 12:35:06.62
>>489
個人自営業の収入については、それぞれ違うと思うが
低すぎても生活出来ない
高すぎても商流に引っかかる
難しいだよ
だから、マネージメント会社に一任してる
マネージメント会社の存在は、個人技術者にあまり知られていないが
まぁ、密かに存在してるんだよ
業界情報を元に、商流判断して
仕事の振分け、金額・待遇の交渉などなど
まぁ、海外に行ったプロのスポーツマンとかマネージメントが付いてるでしょ、そんな感じ
マネージメント会社にIT技術者のプロと認められないと、担当してくれないけどね
みんなの知らないIT業界だけの秘密みたいな物も有るんだよ
プロにならないとわからない世界が

494 :仕様書無しさん:2015/02/27(金) 13:07:21.03
>>493
単価60万とかふざけた額でやってるのとは次元の違う世界ってのはわかった
プロフェッショナルな下請が素人の元請け事務員よりはるかに高給であればいいんだけどどうなんだろ

495 :仕様書ください:2015/02/27(金) 14:26:44.08
>>494
仕事内容にもよるが
1ヶ月60万の仕事は、やっつけ
コーディングのみでテスト無し
保証も変更も無し納期だけ守る約束だから、妥当だよ
全部コミコミなら数百万円で2ヶ月仕事にするよ
まぁ、コミコミだと重いから断るかな

496 :仕様書無しさん:2015/02/27(金) 16:51:26.15
今の派遣の相場って40〜45万だぞ
派遣の子の手取りは20万届くかどうか
大手に優秀なSEを派遣に出したってせいぜい70〜90万だよ
本当に住む世界が違う人だな

497 :仕様書無しさん:2015/02/27(金) 17:14:42.01
やっつけ仕事でOKなんて了承取れるか????

498 :仕様書無しさん:2015/02/27(金) 17:39:42.68
>>497
そういう世界もあるんだろう

俺の見てる世界だと単価は作業内容じゃなくて仕事出す会社で決まるし
単価安い会社ほどアホなのでこっちでやるべき仕事が多くなる

どう考えても>>497の世界が正しいんだけど何とかならないかなあ

499 :仕様書ください:2015/02/27(金) 17:45:16.49
納期に間に合わせるのが目的の仕事だったからね
以前にも受けた仕事だからやっつけでもオッケーでたよ
仕事依頼時に
まぁ実績があるからよ

500 :仕様書無しさん:2015/02/27(金) 17:56:27.94
>>498
その世界は
ルイズがいるの?
長門いるの?
絵麻いるの?
にこにーいるの?

501 :仕様書ください:2015/02/27(金) 17:58:52.79
>>500
長門いたら、俺も嬉しいが
居ないんだな(´・ω・`)

502 :仕様書無しさん:2015/02/27(金) 18:02:24.11
>>496
派遣は厳しくなったね。
請け負いで複数案件並列でこなすのが生き残る道だが
それなりにスキルがないと出来ない

503 :仕様書ください:2015/02/27(金) 18:15:10.49
まぁ技術者が忙しくて
スキル足りず炎上したら
オイラの出番
間に合わせます
仕上げます
潰れそうな社員に明確なスケジュールを提示して、夜寝れる様にします。
但し、炎上価格を頂きます。
ぱっと燃えたら、サッと消化
短い期間で多く周ります
お問い合わせは、ヒ・ミ・ツ

504 :仕様書無しさん:2015/02/27(金) 18:18:55.67
ヤクザみたいな顔して線引くだけのおっさんいるけど
ああいうのが重要なんだよな
あと何でも解決する変態を1人ほど遊撃手に入れといたらまず大丈夫や

505 :仕様書無しさん:2015/02/27(金) 18:42:32.94
>>503
炎上プロジェクトで求められるのって大体消火じゃなくて火に耐えること
火消えたら儲からないじゃないですか
消火のために特別に金出すってやるところは炎上自体しないと思うよ

506 :仕様書無しさん:2015/02/27(金) 18:44:09.75
>>505
本当に足りないのは、人手でもなく納期でもなく、予算なんだよな。

507 :仕様書無しさん:2015/02/27(金) 19:09:06.11
というか、炎上の理由って
スケジュールもそうだけど、それ以上に仕様が明確でないってことじゃね?
アニメSHIROBAKOでもあったけど、原作者が明確に何が駄目なのか言わない(聞ける機会を作ってもらえない)
つまるところ>>1の論の根幹部分にいたる

508 :仕様書無しさん:2015/02/27(金) 19:15:49.96
>>507
「聞ける機会を作ってもらえない」は無能の言い訳。
つか、それが真なら内製だともっと酷い結果になるだろ。

509 :仕様書無しさん:2015/02/27(金) 19:16:22.65
仕様書なんて終わってから作るもんだ。
だって、作ってる間に仕様が変わるから。

510 :仕様書無しさん:2015/02/27(金) 19:18:52.14
>>509
こういう無能しかいないから内製は大失敗する。

511 :仕様書無しさん:2015/02/27(金) 19:21:45.43
10年間やり方が変わらない会社があるとでも思ってるのか?

512 :仕様書無しさん:2015/02/27(金) 19:24:19.31
>>511
300年くらい同じ方法で醸造している酒蔵とかあるんじゃね?
システム導入してるかどうかは知らないけど

513 :仕様書無しさん:2015/02/27(金) 19:40:32.25
>>508
?外の会社の人が聞けないのと、内部が聞けないのとが同列?

514 :仕様書無しさん:2015/02/27(金) 21:12:18.04
>>454
今日の俺のほうが上!
処理速度1500倍アップさせた!
SQLはホント理解してない馬鹿に使わすもんじゃないわ

515 :仕様書無しさん:2015/02/27(金) 21:23:34.30
だいたい無断でシステム弄るなんて懲戒ものだろ
>>454はどう見ても厨学生

516 :仕様書無しさん:2015/02/27(金) 21:38:44.06
クソ情シスとクソ外注が対応しなかったのが悪い

517 :仕様書無しさん:2015/02/27(金) 21:43:00.60
まぁ問題化しても下手すりゃ勝てそうな気がする
そのくらいわかりやすい処理速度の差と現実的に効果の高いと感じる時間差だからなぁ

情シスが無能なんですよ。

の一言を御前で言われたらどう転ぶかわからん

518 :仕様書ください:2015/02/27(金) 21:43:29.65
中小企業向けシステムて、開発者にもよるが
本当に無駄な処理と
無駄だけどこのパターンで正しい結果出す為に必要なんですってのもある
大手企業相手だと仕様書重視だか
中小企業相手だと動作重視
本当に変えて良かったか、後にならないとわからないよ

519 :仕様書無しさん:2015/02/27(金) 21:51:32.73
まぁ内部から不満が出てる情シスだと上の連中で情シスへの不満を持ってるのがいたら、展開次第では、ホント情シスから懲戒を求めても逆に情シスのリストラ展開も普通にありえる

520 :仕様書無しさん:2015/02/27(金) 21:52:58.69
で、結局>>454>>472には答えられないわけね
口先だけのJava厨ってのは当たりみたいだね

521 :仕様書無しさん:2015/02/27(金) 21:53:08.91
中小企業の管理システムしてて
アクセスでこの結果でてたんだ
オラクル版ならできるよね
とか言われて、無理矢理作ったけど
元のアクセスにそんな機能無いだろ
って後でわかる
営業しっかりしろや割れ
まぁ出来たんだからいいが
どう考えてもコード的に無駄だけど
無いとその特殊な集計だけ結果かわる
納品時満足したからそれでいいか
ってのもあるのよ
今考えると本当に必要な集計表か悩むがね

522 :仕様書無しさん:2015/02/27(金) 22:00:15.95
>>520
当事者じゃないんだけど
フシギだから教えて?
いみてみたけど、なぜアセンブラを出したの?
しかも、問題を出した相手が別のレス番になってるし

523 :仕様書無しさん:2015/02/27(金) 22:01:35.23
逆アセンブルってなってるならわかるけど、逆コンパイルとかかれてるのに?

524 :仕様書無しさん:2015/02/27(金) 22:08:55.88
>>521
454が何直したか知らんが、処理速度だけなら、まずその可能性はないだろ。
同期をとってて、それが3時間というならともかく。
でも、要望を出してたということは、そのへんの仕様もわかっててのことだろうに。

525 :仕様書ください:2015/02/27(金) 22:09:42.75
開発会社の炎上対応って
状況把握
全技術者の能力把握
客先の信用取得
線引き、担当者説得
客先説得、承諾貰う
自己対応+遅延作業の対応
不具合レベルの振分け
納品対応
引き継ぎ兼担当者教育
次の炎上現場へ
てな具合かな
出来るから高くても求められる

なぜ戦うの?そこに炎上現場が有るからだよ(´・ω・`)

526 :仕様書無しさん:2015/02/27(金) 22:12:43.90
口先だけの職場とロリだけの職場、やばいのはどっち?

527 :仕様書無しさん:2015/02/27(金) 23:35:27.35
女子中いいなぁ

528 :仕様書無しさん:2015/02/28(土) 00:18:53.32
どう見ても>>454==>>464だろうに
>>454みたいな馬鹿が2人以上いるなんて考えたくもないね
逆コンパイルって書いてあるからニモニック貼ったんだろ
逆汗って書いてあったらバイナリダンプでも貼るわ

529 :仕様書無しさん:2015/02/28(土) 00:25:43.86
逆コンパイルってアセンブリに直す処理だったっけ?

530 :KAC:2015/02/28(土) 00:54:54.63
コンパイルが何か考えたら、
逆コンパイルがどういう行為か分かりそうなものだけど・・・

Javaとかなら逆コンパイルはそれなりに動くけど、
C/C++なんかでは絶望的だからあまり有名じゃないのは確か。

531 :仕様書無しさん:2015/02/28(土) 08:29:57.01
受注系SEの皆様へ

期限強要偽装請負裁判情報
事件内容
NTTコミュニケーション受託開発
被告企業
1次受注 グローバルウェイ
2次受注 ビジネスインフォメーションテクノロジー
3次受注 アイピーロジック
被害を訴える際に、
3次受注 アイピーロジックと
2次受注 ビジネスインフォメーションテクノロジー
が警察までついてきて反論し、裁判となりました。
3社とも原告に指示した事を認めました。

皆様も生涯被害にお気をつけ下さい。

532 :520:2015/02/28(土) 08:56:34.74
正確にはコンパイル、アセンブル、リンク
が正順。
ただ、現在では、通常、コンパイルはアセンブルやリンクまで含んで表現する。
逆順では通常
逆アセンブルは実行ファイルからアセンブラに
逆コンパイルは実行ファイルから高級言語に
を通常指す。

正直そこはどうでもよくて。疑問を感じたのは、Java厨とか言ってるから、C、アセンブラやマシン語ができる=高位の技術者
とでも思ってるように感じられたから。

会社のシステムを勝手にいじるのもどうかと思う。ただ、業界から去ったヒトは俺にとってどうでもいい。
むしろ現役なのに、技術と価値、目的と手段、能力の評価と測定手段を盛大に間違えてないか?と言いたい。
言語は手段でしかないのに。

533 :仕様書無しさん:2015/02/28(土) 09:31:51.19
別にシステムいじっても責任とればいいよ
100人規模の会社の場合、メーカーの年間保証代60万ぐらいかな
改造した時点でメーカー保証切れるから、自己責任で会社に返還してね
一つの会社がシステムを10年使うとして600万ぐらいかな
まぁバカな社長じゃなければ、社員に直接請求しないだろ
メーカーと会社の裁判になっても
保証契約には、変更しないと記載されてるから、一社員がしでかしつも
会社の責任になるからね

534 :仕様書無しさん:2015/02/28(土) 09:41:40.20
自社で作れば、改造しても自社社員に怒られるだけだよ

535 :仕様書ください:2015/02/28(土) 09:52:54.18
技術者の価値を技術力で判断するのは間違いだよ
自営業になってわかったが
技術力なんて、お金にできなきゃ意味がない
バカでもチョンでもお金稼いだ者勝ち
技術力は知識であって
等価のお金稼いで初めて価値が有るんだよ
技術力を自慢するのでなく
持ってる知識で自分がいくら稼いだか自慢しよう
会社のシステム早くして、自分に会社からボーナスくれるかい?
会社が受けた開発を完璧なコードにして、会社が給料上げてくれるかい?

536 :仕様書無しさん:2015/02/28(土) 10:14:58.63
まぁ元業界人ならexeファイルのバックアップくらいとってるだろ
トラブル起きたらシレっと元に戻して終了
原因追求は、そこの情報システム部門ではきっと無理だろう

537 :仕様書無しさん:2015/02/28(土) 10:15:42.12
>>535
それを突き詰めていくと、いかに他人に責任を負わすかが腕の見せ所っていう方向に行くんだよな

538 :仕様書無しさん:2015/02/28(土) 10:56:30.19
>>537
悲しいことだがそれが大人の世界というもの・・・

539 :仕様書無しさん:2015/02/28(土) 11:00:49.34
>>537君はまだ業界3ヶ月だが優秀だ!主任を任せようと思う!管理職扱いだ!!!

540 :仕様書無しさん:2015/02/28(土) 11:08:09.08
>>528がニーモニックを貼ろうが、バイナリを貼ろうが、それで何を測れるのだろう??????

541 :仕様書無しさん:2015/02/28(土) 11:15:40.28
>>535
システム改善って、自主トレーニングみたいなもんだろ。
あんまり後ろ向きにばかり考えてると、目の前のスキルアップのチャンス逃すよ。

542 :仕様書ください:2015/02/28(土) 11:26:00.31
だからさ、サイドビジネスなり
ナイトパワーなりしようよ
せっかくの技術がもったいない
ラインのイラストや
YouTuberだって稼げる時代だぜ

543 :仕様書無しさん:2015/02/28(土) 11:28:00.72
>>535
金儲け、生きるための糧を得るための手段として「だけ」なら正しい。
会社のシステムを早くしてボーナス、完璧なコードにして給料アップはもらえるかもしれんがw

544 :仕様書無しさん:2015/02/28(土) 11:28:26.80
> ラインのイラストや
> YouTuberだって稼げる時代だぜ

稼いでる人は1%もいないよ。

545 :仕様書無しさん:2015/02/28(土) 11:31:48.96
>>542
完全にスレ違いだって気づかない?
それに気づけないのに本当に金稼げてるの?

546 :仕様書ください:2015/02/28(土) 12:21:44.38
俺は、自社システムを論議できるレベルの技術者に言いたい
今市場は、技術者不足なんよ
業界の流れ的ににここ1か2年間の短期ITバブル
自社だけでなく、自分の技術を活かし、みんな稼ごうよ
自社の仕事は自分の経験の糧にしてさ
IT技術者やってて、将来不安じゃない?
クビになったらどうするの?
一杯経験して、将来会社システムの
アドバイザー会社開いてもいいじゃない
俺みたいに、ただのサラリーマンプログラマーから、一杯経験して
本当のプロと呼ばれる、自営業技術者になった人間もいるんだから
日本の技術者は、会社に子飼いされた家畜技術者ばかりとか
嫌じゃん

547 :仕様書ください:2015/02/28(土) 12:35:04.42
サラリーマン技術者でも機会や人の繋がりて仕事できるんたよ
俺の例を挙げよう
ナイトパワーは、夜やる仕事だからナイトパワーて言うんだ
某会社の会員登録ホームページの更新作業、21時から23時までやって
20画面の20時間ぐらい
htmlとjavascript技術で、月8万になった
某メーカーのデータ解析ツール
3時間で5万になった
某メーカーのシステム診断修復ツール
これは、職場て作ったから無料で取られた。
家で作らないと権利主張できないと若い頃に勉強になったな
まだありが、まぁ簡単に挙げてみた

548 :仕様書ください:2015/02/28(土) 12:38:27.39
すまん、土曜出勤の休憩時間に慌てて書いたから誤字だらけだ
(´・ω・`)

549 :仕様書ください:2015/02/28(土) 12:49:48.59
俺は、経験豊富な下請け自営技術者が増えて
社畜は、若手や経験の浅いもの
ホローにプロの下請けが入る
こんなIT業界にしたいんよ
でも、まだまだプロの下請けが足りないんだ
みんな、経験積んでプロの下請けになってください。

550 :仕様書無しさん:2015/02/28(土) 13:04:57.04
>>546
その不足の原因が

仕様がわからんwwww おれら何つくってんの?www ちょwリーダー!俺ら何作ってんの?wwww

って状態だからだろ。

551 :仕様書無しさん:2015/02/28(土) 13:06:37.31
>>547
内製やって課長になった。ノウハウ活かして分社化して社長になった。のほうがええわ。
で数年で稼いで逃げる

552 :仕様書無しさん:2015/02/28(土) 13:14:17.61
>>549
そんなアニメーターの世界のようなプロ意識をもったやつなんて一握り
業界全体でプログラマ=ほぼ全員個人事業主
が当たり前の業界ならともかく
Sヨ等々が絶対阻止するからwwwww

553 :仕様書無しさん:2015/02/28(土) 16:15:17.26
>>546
>業界の流れ的ににここ1か2年間の短期ITバブル
俺はそれが嫌で社畜に戻ったよ。
一般企業のプログラム内製部門だ。
社内の便利屋さん的位置づけもまったりしてて楽しいw

搾取しておいて今更人が足りないからとか、寝言は寝て言えと言いたい>IT人材不足を嘆く企業

554 :仕様書無しさん:2015/02/28(土) 20:52:27.83
>>553
> 社内の便利屋さん的位置づけもまったりしてて楽しいw
羨ましいことだ。ウチは逆だ。

555 :仕様書ください:2015/03/01(日) 00:20:31.12
俺がこの板に自営業になりませんか?と書いているのは、色々な業界を見てきて
技術者の中でも最も自営業になれるスキルを持っているからだ
自社のシステムとは、会社の業務を正確に把握して
それをシステムに変換する頭脳と理解力、説明力が必要となる
これは、SEに必要なスキルであり
初めからプログラマーとして就職した者には、簡単に取得できないスキルだ
平凡なプログラマーから今のプロとしての地位を確立する上で一番苦労したスキルでもあり
全体を把握する事は、技術者に最も大事な事でもある
だから、一番近いスキルを持ち討論しているこの板に書き込みしている
まぁ、会社を起こすには他にも色々なスキルや下準備が必要になるがね
技術者が最も苦手とする人付き合いも、嫌な客にペコペコしなきゃいかん
金の為とは言え、気苦労も絶えないよ
まぁ、将来の事を考える時に一つの選択肢としてもらえればいいかな
若い技術者よ、苦労が絶えないが俺みたいな自営技術者も居ることを覚えておいて欲しい
そしてIT業界には、まだまだみんなが知らない事や
2chやネットでは知り得ない事がある事を知っていて欲しい
なぜ誰も書き込まないか?
儲ける方法をわざわざ教えるバカはいない!!
苦労して得たスキル、人脈、情報 タダで教えるわけないだろ
ただそれだけだ
長文失礼しました

556 :仕様書無しさん:2015/03/01(日) 01:37:40.76
教えないなら黙ってろよ

557 :仕様書無しさん:2015/03/01(日) 08:34:38.52
>>549
理想を目指すのは良いけど、ギルドとかの歴史を知らずにやると、99パーセントの犠牲の上に成り立つだけの陳腐な体制になるからね。

558 :仕様書無しさん:2015/03/01(日) 08:48:35.97
金を出して仕事をしてもらう側からすれば、自分で人を雇うよりも外注する方がずっと有利だからな。
実質的に社員みたいなものでも、自営に切り替えた方が税金で持って行かれる割合が小さくなる。
いくら正社員でも会社が潰れたらそこで終了だし、社員になるメリットが薄れてきていると思うよ。

559 :仕様書無しさん:2015/03/01(日) 09:48:27.19
>>558
まぁいわゆる一流企業に勤めていて、会社が倒産したら、それも運命と受け入れるよ
でも一流企業にいたから 執筆 論文発表 研究 もできたて名前も知られるようになったからなぁ
看板背負ってなかったら、自分に取材なんて絶対来ないだろうし

560 :仕様書無しさん:2015/03/01(日) 10:09:50.26
>>553
というより「育ててない」からな
で、このスレでも頻繁に出てきてるけど派遣されている自分たちも「経験したプロジェクトの数、現場の数=スキルの証明」と騙されている
幾度のプロジェクトを経験しようが、同じような一定の単純入力データに対して、単純な処理、単純なDB入出力、単純なアウトプットしかやってなければ
同じような一定の単純入力データに対して、単純な処理、単純なDB入出力、単純なアウトプットの技術しか身につかない
で、これは上り詰められる最高地点が低い。
(たぶんここで内製できる。って言ってる人も、こういったシステムの作成だからできると表現しているのだろう。)
だから幾度のプロジェクトを経ようが、同じことをやっているようなら、身につけられるものも同じ。
本人はプロジェクトをいろいろ経てスキルアップしたつもりかもしれないけど、実際はスキルアップしておらず止まっている。

561 :仕様書無しさん:2015/03/01(日) 10:23:46.08
>>560
そもそも一般の会社の業務システムに要求されるレベルって、その単純な処理のレベルなんじゃないかな。
あとは、業務のやり方の進化にどこまでついていけるか、程度。

562 :仕様書無しさん:2015/03/01(日) 10:54:46.93
>>561
> あとは、業務のやり方の進化にどこまでついていけるか、程度。

他部署が業務の進め方をコロコロ変えるようなところもある。ウチだ。
そして「システムが追い付いていない!不具合だ!」とやり玉にあがる。

563 :仕様書無しさん:2015/03/01(日) 10:55:13.70
>>561
そう思う。
ここで内製って言ってる人も、高度・専門部分の外注は否定してないし。
この単純プログラムで、素人には!って言ってるのが意味わからない。
一昔前の開発環境ならともかく、現在の開発環境だと頭のいい人なら数日で組めるようになって、数ヶ月で慣れて、1年以内にはバリバリになれてしまう。
業務の進化への対応は、それこそ現場を知っている現場の人が一番最適。ついで内製(情シス)。次に元請の専門家。終末点は現在の外注方式。
つまり現場の人が作る。これが一番いいのだ。

564 :仕様書無しさん:2015/03/01(日) 11:01:38.52
F1レーサーに宅急便の配達をさせると速いかっていうとそうでもないんだよな。
業務システムは業務の一部分でしかないんだから、その部分だけに特化して高度な事をするよりも、全体を見渡して、そのなかでシステムにどのような役割を要求すればいいか判断できる人の方が絶対にいい結果出せると思う

565 :仕様書無しさん:2015/03/01(日) 11:14:21.25
大半の業務プログラムなんて今の家具等々のDIYと同じレベルまで敷居は下がってるんだよ
確かに販売している製品(良い製品と比較して)のほうがいいんだけど、DIYってやり始めると不満点を発見してバージョンアップしまくりw
結果としてスキルが身についてしまって後半は製品を超えだすw
業務はそこまで大幅な変更はないから一度ノウハウを身につけちゃえば、外注で出す意味がまったくわからなくなる

566 :仕様書無しさん:2015/03/01(日) 11:24:11.37
>>565
不満発生→解決のサイクルがとことん短くなるよな。

567 :仕様書無しさん:2015/03/01(日) 12:08:27.26
情シス問題解決策は
現場が作る。
現場で一人マスターができたら、予備員も育成する。
現場で作る人はシステム作成を専従にしない。
これだけ。

568 :仕様書無しさん:2015/03/01(日) 12:39:49.69
情シスとベンダーの馴れ合いをどうにかしてくれ
BIだのクラウドだの、わかりもしねー癖にベンダーの言いなりで勝手に導入を決めて
使い物にならないシステムを現場に押し付けんな

569 :仕様書無しさん:2015/03/01(日) 15:44:49.59
>>559
>>執筆 論文発表 研究 もできたて名前も知られるようになったからなぁ
妄想ですかー
日本語もおかしいしー

570 :仕様書無しさん:2015/03/01(日) 16:04:44.34
>>569
>>559じゃないけど実際、会社名でオファーはあるよ
だれがやるか押し付け合いになるんだけどw

571 :仕様書無しさん:2015/03/01(日) 19:15:26.93
やりたくない仕事が来るんですかー
大変ですなw

572 :仕様書無しさん:2015/03/01(日) 20:40:16.83
>>571
そうだよ
めんどくさいしほとんど金にならんし

573 :仕様書無しさん:2015/03/01(日) 23:50:45.51
業務システムっていってもいろいろあるし、その内容によって内製が良かったり悪かったりする
まずどんな業務についてレスしてるのかを挙げないとループするだけだね
根拠法令が全国同じでバグの存在が致命的になる業務なら、内製は絶対止めた方が良い
行政事務や金融業務、医療事務、財務会計とかね
限界まで高レスポンス性高信頼性高可用性を求められるシステムなんかも現場内製の手に負えないだろう

それら以外の比較的小規模な業務システムなら、メーカーのお守り付きで現場内製できなくもないかもね
・ドキュメントなし仕様不明糞コードでも、捨てて一から作り直せるくらい単純である
・間違いがあっても笑って済ますことができる
・正解がない(ビッグデータ分析、経営戦略のためのデータ作成など)

574 :仕様書無しさん:2015/03/02(月) 19:20:36.92
え?
真逆だけど?
法令改正あるやつほど、外になんか任せられない

575 :仕様書無しさん:2015/03/02(月) 21:11:51.40
一般的な企業にとって内製に向かないもの
 =入力・出力データが一定でないもの。(自然現象や不確定な画像処理等)
 =物理系・数学系等のある程度極めた人じゃないとできない分野。(引継ぎができる人材が圧倒的に限られる)
とにかく、それなりの頭(といっても天才や秀才、異常な高偏差値ではない。)があれば引き継げる内容の範囲。
定型の数値、定型の計算、定型の報告書などの処理は全部内製可能。
というより、この手のものは全部もともと内製が発端。(内製といっても、メーカーと自社の共同制作)

>>574のいうとおり、むしろ法令改正なんかがあるやつほど、内製に向いている。

576 :KAC:2015/03/02(月) 21:35:42.45
>>575
「内製」じゃないものは何だと定義して話をしてる?

577 :仕様書ください:2015/03/02(月) 22:02:39.62
数多くの企業、業種を開発したが
同じ業種でも企業毎
必要かどうかわからない集計表を
上の方々が欲しがるからね
下に付く社員も大変だね
打ち合わせの資料のフォーマットぐらい統一にならをかなと思うよ

578 :仕様書ください:2015/03/02(月) 22:06:47.43
ちょっと詳しいシャチョさんなんて
俺だけ見るweb版の集計表作れって言ってたし
秘書付けて、メールした方が安くすむのにね
(´・ω・`)

579 :仕様書無しさん:2015/03/02(月) 22:07:38.70
ハードウェア開発は向かない
ハードウェアに近い部分も向かない
オンリーワン技術が要求されるものも向かない
内製とは普通人を1,2年育てれば一応できるようになり、さらに数年かければ一人で任せられる程度の範囲だろ

580 :仕様書無しさん:2015/03/02(月) 22:10:56.78
>>578
めんどくさくて、ピボットテーブルで実装したことがある。
ぱっぱっぱとほしい縦軸横軸に項目入れるとグラフでますよ!ってやったら大喜びだったw

てかね。
今、パソコンで作業している人の大半はパソコン取り上げたほうがいいw
マジで無駄な報告書(カラフル、絵いっぱい、図いっぱい、グラフいっぱい)を作るのに膨大な時間費やしてるから
それ表でいいだろが・・・と。
1%と99%の2項目の円グラフを一生懸命3D円グラフにしてたwいや99%ってグラフいらんだろwwwとwwww

581 :仕様書無しさん:2015/03/02(月) 22:17:25.25
>>580
グラフ自体が要らないよな、基本的には。
どんな数字も、突き詰めていけば損益等の分岐点より上か下かしかないと思う

582 :仕様書無しさん:2015/03/02(月) 22:21:14.48
>>581
その棒グラフとかに一生懸命「数値」を置いていってるんだぜw
丸1日何やってんのかと思うと「数値」のポジションと文字の色決め。
バカかと。その作業に使った時間使って飛び込み営業やってこいと。

583 :仕様書無しさん:2015/03/02(月) 22:24:35.37
そのうさんくさいグラフで世の中億の金が動いてんだぜ
飛び込み営業とかあほらしくてやってられんわ

584 :仕様書ください:2015/03/02(月) 22:38:53.58
とある会社の専務さんなんか
俺は、このExcelファイルの集計表じゃなかったら、わからん!!
とか言って手打ちしてたと思ったら
3ヶ月ぐらいで
このフォーマットで、Excelファイル出せるよね?とか言って
え、専務さんの為に集計表とExcelファイル出力機能追加ですか?
とか、もっと安くならんのとか

手打ちしてろや
センムしか使わんやろが!!

でも、専務シャチョさんの親とか
カンベンしてよ〜
とかあったな〜 (´;ω;`)

585 :仕様書無しさん:2015/03/02(月) 22:43:46.53
ぶっちゃけ、Excelにある機能なら、へんなもの作らずに、
初めからExcelでやるのが一番安くて速いよね

586 :仕様書無しさん:2015/03/02(月) 22:45:16.57
>>585
ほんとこれ
データの一元化と正規化とバックアップさえちゃんとやってれば、Excelだけで大抵の業務はこなせる

587 :仕様書無しさん:2015/03/02(月) 22:48:25.79
>>574
全国一律の法令に基づくような業務システムは、たいてい大手ベンダが吊るしや半カスタムで提供しているしシェアも大きい
こいつらの良い点は大きなバグを抱える可能性が低いことであり、それは何よりも重要なこと
内製だとそうはいかない
あと、大手ベンダが絡んでいると、法令改正に関する情報入手が異常に早い
マイナンバーの基礎となった某ネットの導入作業時なんかは、某社と取引があるかどうかで工程に大きな差が出るほどだった

588 :仕様書無しさん:2015/03/02(月) 23:11:35.74
そろそろscに移行します
俺の意見は今後あっちに書くよ

589 :仕様書無しさん:2015/03/02(月) 23:13:31.55
dat廃止は3ヶ月延長じゃなかったっけ

590 :仕様書無しさん:2015/03/02(月) 23:35:48.90
>>584
申し訳ないんだが
もう少し日本語を
勉強して書き込みしてくれ

591 :仕様書無しさん:2015/03/03(火) 04:21:41.17
専務しか使わない機能を実装しろと言われる
社長の親だから断りにく
むかつく

ほら、3行にまとまった

592 :仕様書無しさん:2015/03/03(火) 16:53:48.33
「プログラム 組めぬ大手が 指揮を執る」
「プロジェクト 決まったことは 納期だけ」
「プログラマ 工数算出 蚊帳の外」

593 :仕様書無しさん:2015/03/03(火) 17:57:33.43
【ネット】「プログラム 組めぬ大手が 指揮を執る」・・・絶望感漂うIT社畜川柳の投稿が始まる★2 [転載禁止](c)2ch.net
http://daily.2ch.net/test/read.cgi/newsplus/1425366389/

594 :仕様書無しさん:2015/03/03(火) 19:27:50.96
プログラマ 無能に限って 自信過多

595 :仕様書無しさん:2015/03/03(火) 20:13:33.72
ユーザが多いとエクセルじゃ無理だろ

596 :仕様書無しさん:2015/03/03(火) 21:04:49.48
SQLServerと連動すりゃいいよ
ただ、Excelは例外処理の作りこみが面倒
どこの現場にも物知り顔で余計な事をする奴がいるから

597 :仕様書無しさん:2015/03/03(火) 23:06:22.49
気がふれた方ですか?

598 :仕様書無しさん:2015/03/03(火) 23:28:06.94
気(き)が触・れる【気が触れる】

1 正気でなくなる。気が狂う。
2 心が動く。
「さもしい金に―・れた見世(みせ)女郎のあさましさと」

きがふれる【気が触れる】

精神の平衡を失う。

対訳 to go mad; to go crazy; to lose one's mind

気が「ふれる」は「気が狂れる」です。
ですので、何かに気が触れるわけではありません。

気: spirit, mind, air, atmosphere, mood
触: contact, touch, feel, hit, proclaim, announce, conflict

599 :仕様書無しさん:2015/03/03(火) 23:31:25.33
来月でプログラマ2年目だけど辞めたい
この仕事って楽しい人いるの?

600 :仕様書無しさん:2015/03/04(水) 01:14:08.90
>>599
何系ですか?

601 :仕様書無しさん:2015/03/04(水) 02:13:39.41
ガチョーン

602 :仕様書無しさん:2015/03/04(水) 02:44:32.03
技術職っていうのは、適正に大きく左右されるからな。

運動嫌いな人が、スポーツやって楽しいか?って
話と同じレベルの話だろう。

603 :仕様書無しさん:2015/03/04(水) 02:54:18.25
職場によって合う合わない大きいよ
この業界、何時間プログラミングしても苦痛にならないって人は多いけど
辞める原因は人間関係

604 :仕様書無しさん:2015/03/04(水) 08:07:16.30
現場のパソコン撤去したら急激に売上上がったって会社あるよね

605 :仕様書無しさん:2015/03/04(水) 08:12:47.53
プログラマからパソコンを取り上げたら生産性があがるだろうか?
いや、真面目に生産性あがる気がしてきた

606 :仕様書無しさん:2015/03/04(水) 08:13:20.39
http://www.dreamgate.gr.jp/knowhow/systemintroduction/id=1322

かるーく探すだけで出てくるね

607 :仕様書無しさん:2015/03/04(水) 08:14:45.03
プログラマからは個人個人の端末にインターネット回線を与えず、共有端末でしかインターネットできないようにした方がいい。

くだらないサイトを気づくとずっと見てたとか普通にある

608 :仕様書無しさん:2015/03/04(水) 08:17:23.27
まず手を動かす
っていうのは生産性あがるの?さがるの?

609 :仕様書無しさん:2015/03/04(水) 08:57:23.11
どっちみち手を動かさないと物は出来ないんだから
生産性は上がる。

610 :仕様書無しさん:2015/03/04(水) 09:31:58.38
営業から机を取り上げろ

611 :仕様書無しさん:2015/03/04(水) 11:14:20.87
プログラマーから椅子を取り上げろ

612 :仕様書無しさん:2015/03/04(水) 11:55:50.66
ずっと勃ってると効率いいらしいな

613 :仕様書無しさん:2015/03/04(水) 12:43:34.71
超ミニスカートの専属美人アシスタントをつけてくれたら千倍のパフォーマンスを発揮してみせる

614 :仕様書無しさん:2015/03/04(水) 18:34:58.22
スマホも禁止にしたほうがいいね
若しくは妨害電波で使えなくする

615 :仕様書無しさん:2015/03/04(水) 21:07:43.93
あと電話も禁止。
邪魔が入らない世界を作るべし

616 :仕様書無しさん:2015/03/04(水) 21:29:28.18
会議も禁止

617 :仕様書無しさん:2015/03/04(水) 22:14:48.76
オナニー禁止

618 :仕様書無しさん:2015/03/04(水) 23:53:21.54
>超ミニスカートの専属美人アシスタントをつけてくれたら千倍のパフォーマンスを発揮してみせる

ここのスレッドではないが2月28日に、このように述べられている

--------------------------
プログラマというのは、
マン子の前でカッコいいだろうと自慢したいがために
やっているもんだろ
--------------------------

プログラマは予測ができるということね

619 :仕様書無しさん:2015/03/05(木) 00:04:54.27
KACというような頭の悪そうな投稿者に解説するが

「超ミニスカートの専属美人アシスタント」という発言は3月4日
「マン子の前でカッコいいだろうと自慢したい」という発言は2月28日になされている
つまり、あらかじめ予測されたことが、後日に出てきたということだ
プログラマは見通しが利く人種というわけ

620 :仕様書無しさん:2015/03/05(木) 00:47:56.07
プログラマってモテるの?

621 :仕様書無しさん:2015/03/05(木) 01:21:32.06
モテるよ。

622 :はぐれIT土方:2015/03/05(木) 08:41:16.93
そこそこ

623 :仕様書無しさん:2015/03/05(木) 12:41:38.56
>>619
おいまて、俺は自慢したくて美人アシスタントが欲しいと言ったんじゃないぞ。
ただ性欲が強いだけだ。
人のレスをお前のオカルト趣味に巻き込まんでくれ。

624 :仕様書無しさん:2015/03/05(木) 17:01:10.47
>>619
詳しく

625 :仕様書無しさん:2015/03/05(木) 17:18:17.37
成果物に応じて脱いでいくアシスタントを配置したらどうだろうか?

626 :仕様書無しさん:2015/03/05(木) 19:36:57.85
>>600
通信系とだけ

627 :仕様書無しさん:2015/03/06(金) 08:23:56.74
>おいまて、俺は自慢したくて美人アシスタントが欲しいと言ったんじゃないぞ。

いや、ちょと待ってちょと待ってお兄さん
まん子とミニスカートちゃいますの?
意味わからんからとやめて言うたけど、もう、しもねたを待ってまっせー!

628 :仕様書無しさん:2015/03/06(金) 23:28:15.80
すごいプログラミングを考えた!どうよ?
http://fox.2ch.net/test/read.cgi/poverty/1425651890/

629 :仕様書無しさん:2015/03/07(土) 10:41:05.03
内製始めるということで

1年出向

お前ら雑魚すぎw
マジで下手くそすぎ

630 :仕様書無しさん:2015/03/07(土) 15:45:54.95
>>629
お前が趣味でプログラミングをしているタイプの人間であれば
技術力が
お前 > 職業プログラマの9割5分
になるのは仕方が無い。だが!下を見る世界ではない。
この残り5分がすべてのシステムを実質的に作ってるし保守してるし・・・。奴隷としていいように使われているし・・・。

631 :仕様書無しさん:2015/03/07(土) 17:45:00.65
俺が今まで、この人プログラミングうまいなぁ。しかも頭良いなぁと思ったのはソフトハウスの人ではなく、
内製で一人で会社1社のシステム開発をやっている人だった。

632 :仕様書無しさん:2015/03/07(土) 17:45:59.52
>>631
たぶん、おまえの基準はやばい。

633 :仕様書無しさん:2015/03/07(土) 17:46:39.31
プログラムというより設計が大事。

634 :仕様書無しさん:2015/03/07(土) 17:51:40.04
>>632
たぶん、お前の先入観のほうがやばい。

今、内製のプログラマでも、もともとは外でバリバリやっていた可能性だってあるわけで。
そういう先入観でしか見てるようなら、お前の器の限界を知れ

635 :仕様書無しさん:2015/03/07(土) 18:00:04.11
うちの情シス作成のシステムはフールプルーフプログラミングという考えが一切無い
1画面に入力するデータで矛盾になるか否かは処理的に判断可能なもの。でも、一切その手の処理が無く

間違えずに正しく入力しないのが悪い

という情シスのありがたい回答

おかげでシステムの中にたまっているデータはめちゃくちゃですw

636 :仕様書無しさん:2015/03/07(土) 18:10:44.79
>>635
たまに見かける、何でもできる画面とかもうシステムでも何でもないよな。

データベース直接いじってろと言いたい。

637 :仕様書無しさん:2015/03/07(土) 18:14:09.99
>>634
普通、設計がきれい、分かりやすい、メンテナンスのことを考えてるなってところをコードがすごいとか中二だろw

638 :仕様書無しさん:2015/03/07(土) 18:22:39.76
>>637
プログラマーの優劣をコードの善し悪しで判断するのは当たり前だろ
設計やメンテナンスなんてコードが書けない無能SEやPMの仕事だし

639 :仕様書無しさん:2015/03/07(土) 18:26:27.59
火星っつったら軍神だ。
客との戦い連戦連勝。
優秀な営業のおかげでどんなもの作っても文句が来たためしはない。

640 :仕様書無しさん:2015/03/07(土) 18:27:30.22
>>635
それ設計の経験がないPGにエントリープログラム組ませるとそういうの作ってくるよな。
一昨年うちに転職してきたベンダーあがりのマがそうだった。

641 :635:2015/03/07(土) 18:53:55.97
ちなみに、情シス作成とありますが、実際はFに丸投げですw

642 :仕様書無しさん:2015/03/07(土) 18:56:48.22
>>637
普通にコード見ればある程度実力はわかりますが?ww
むしろ、コードが見れる状況でありながら、コードを見ない時点で無能確定ですが?w

643 :仕様書無しさん:2015/03/07(土) 19:05:52.18
>>640
> 一昨年うちに転職してきたベンダーあがりのマがそうだった。

それベンダー上がりのSEだよ。

644 :仕様書無しさん:2015/03/07(土) 19:25:32.02
>>643
そいつは設計とかは全く経験がなく、5年間コーディングしか経験が無いので生粋のPGなのは間違いない。
一応コードは普通に書けているし。

645 :仕様書無しさん:2015/03/07(土) 19:28:08.09
>>644
だからSEのだろ。

646 :仕様書無しさん:2015/03/07(土) 19:36:52.45
>>645
SEはコードなんて書けないだろうに

647 :仕様書無しさん:2015/03/07(土) 19:38:07.74
>>645
コードが書けて設計が出来ないSEって・・・!?

648 :仕様書無しさん:2015/03/07(土) 19:40:18.87
>>644
それただのコーダー

649 :仕様書無しさん:2015/03/07(土) 20:11:39.97
>>638
おまえ、それじゃあ、経験浅いですって自己紹介になるぞw

650 :仕様書無しさん:2015/03/07(土) 20:13:42.54
>>642
コードの中にそのプログラマの考え方が出ているんだよ。

それが分からないのはプログラムがクソか、読んでいるプログラマがクソのどちらかだ。

651 :仕様書無しさん:2015/03/07(土) 20:30:32.46
>>650=>>637なら
おまえ誰か特定一人と戦ってるつもりかもしれんが、少なくとも俺以外の誰かがいるわけでw
お前の回答がめちゃくちゃに見えるからw

652 :仕様書無しさん:2015/03/07(土) 20:47:52.45
ID出ない板だと全員一人がレスしてると思って間違いない。全て自作自演。

653 :仕様書無しさん:2015/03/08(日) 00:46:38.56
病気かな。
設計ばっかやってると協調性のないプログラマの一人一人の人格が1つのクラスやメソッドに見えてしまう。
言い争いを見るとこういう性格の奴にはここ担当させた方がいいなーとか。

654 :仕様書無しさん:2015/03/08(日) 01:18:31.61
>>635
完璧に作ったらコストかかるからな
しかも例外に柔軟に対応できなくて使い物にならないシステムになりがち

ちゃんとソフト側でエラー叩き落としてデータベースでも弾いてという完璧なシステム作ったら
なにかあるたびに客に呼ばれるぞ

655 :仕様書無しさん:2015/03/08(日) 01:39:58.29
> なにかあるたびに客に呼ばれるぞ

なにかあるたびに客に呼ばれる VS 何かあっても客に呼ばれない(ただしエラーは起きている)


どちらがいいのか?

656 :仕様書無しさん:2015/03/08(日) 02:24:13.50
お金が発生するならいくらでも呼んでください
あと、客がデータいじってエラーでた場合の対応は料金いただきますのでよろしく

657 :仕様書無しさん:2015/03/08(日) 08:55:08.83
>>654
> ちゃんとソフト側でエラー叩き落としてデータベースでも弾いてという完璧なシステム作ったら
> なにかあるたびに客に呼ばれるぞ
ちゃんとしてないからやたらとなにかあるんだよw

658 :仕様書無しさん:2015/03/08(日) 09:16:43.39
>>654
これねw
「例外・イレギュラーに対応できない」
これって、実は、運用や現実に発生する事象のすべてを把握していない。誰も仕事わかってる人いません。って白状してるのとかわらないんだよね。

そもそも、そんなもの極めて稀にしか発生しないから「例外・イレギュラー」なんであって、
普通は、その例外も処理にキチッと入れるけど
本当に極々ごくごくごくごくごくごく稀なものは、別途運用の特殊権限を持った人で登録するなどで慎重に対応すればよい。

その例外のためにチェック機構を緩くしてしまって、めちゃくちゃなデータが入ってくる。
ユーザーはミスをするもの。というシステム開発者なら常識的に考えることすら考えられない不適格者ってこと

659 :仕様書無しさん:2015/03/08(日) 10:09:43.65
システムを完全に内製でやってると、その例外や法令改正とかで発生、しばらくたって発覚した、判例が変わったとかでも即日対応できる
これが外注だと、「運用で対応」になって、それがどんどん増えてきて、システム自体がお荷物に・・・。
単純な外注ならいいけど、糞情シスがいると、すべてに対応したシステムのリプレイスすら認めようとしない
理由は、自分たちの運用が変わるから

660 :仕様書無しさん:2015/03/08(日) 10:42:16.66
× 理由は、自分たちの運用が変わるから
○ 金が出せないから

外の会社に金を出すのは渋る。
社員はただで働いていると考えている。
だから内製すれば、ただで済むと考える。

661 :仕様書無しさん:2015/03/08(日) 11:35:25.35
>>660
固定費で出てるから、基本的にサービス残業にして修正させれば費用は変わらないよ

662 :仕様書無しさん:2015/03/08(日) 11:39:48.93
>>661
というより、永久に開発や仕様変更があるから内製の意味があるわけで
常に開発し続けてるからね
その順番の優先度によって変わるだけ
だから2000万年間人件費がかかっていたとして、外注で仕様変更等々をやったら、その2000万以上の額になるなら金額だけでもメリットあり
さらに修正速度も圧倒的に違うし、細かなカスタマイズも可能

外注に投げる情シスは、こういった点でもまったくもって害しかもたらしていない

663 :仕様書無しさん:2015/03/08(日) 12:10:52.21
>>662
2000万年間人まで読んで、2千万人×1年分の人件費かと思ってしまった。240,000,000人月。

664 :仕様書無しさん:2015/03/08(日) 14:08:59.51
不憫に感じるのは
技術レベルが
ユーザーのシステム担当>情シス

外注システム
のとこ。
ユーザーのシステム担当が問題点を指摘してるのに、情シスが理解できないから外注に伝わることもない
んで>>635のような状況だともうお手上げ

665 :仕様書無しさん:2015/03/08(日) 14:19:15.96
>>658
仕事のフローのほうが後から変わる事はよくある事
そのたびに修正なんてしていられない
チェックが厳格だったら「直接データベースいじって修正」すら出来なくなる

666 :仕様書無しさん:2015/03/08(日) 14:22:11.13
>>662
永遠に修正するにしても必要とされる技術レベルや規模は変わるんだから
内製でその柔軟性が確保できるのか疑わしいね

>>664
技術者が部門を超えて奴隷扱いされてる会社ならすぐ修正してくれるだろうな

667 :仕様書無しさん:2015/03/08(日) 17:38:07.23
>>666
ダウンサイジングが始まる前までは、内製ではずっとやっていたことだから
実績は内製のほうが遥かにあるんだけど

668 :仕様書無しさん:2015/03/08(日) 17:40:09.60
>>666
金がきちんともらえてるなら奴隷じゃないだろw
むしろ、金をもらえて、しかも自分の必要性が目に見えて結果としてわかる
こんなうれしいことはないYO!

むしろ派遣で自分が作ったプログラムをユーザーが使っているところを見たことが無い
自分のプログラムがどんなに役に立ったのか結果を見たことがない派遣プログラマほど可愛そうな存在は無いわ

669 :仕様書無しさん:2015/03/08(日) 21:08:11.67
>>668
結果を見れない仕事ってつまらない
そんな環境でよくやってられるなぁと思う
達成感も糞もない 納期に間に合わせた達成感?そんなしょぼいのは嫌だ

670 :仕様書無しさん:2015/03/08(日) 22:40:51.57
>>664
お前さんのレスを良く見かけるが、要は
・情シスに配属するほどの技術力はないと管理職・人事に評価されている
・開発会議や検収に出席できるほど偉くない
・情報システムに関して助言を求められるような人材でもない
ってことだろ?
本当に自分で言ってるような能力があるんなら、辞めて他の会社に行けばいいんじゃないの?

671 :仕様書無しさん:2015/03/08(日) 23:13:34.37
IDも付いてないのに
同一人物だと思うようになったらもう手遅れ

672 :仕様書無しさん:2015/03/08(日) 23:26:30.25
まあその前に、2chで世界が判った気になり始めたら、色んな意味でヤバイ。

673 :仕様書無しさん:2015/03/08(日) 23:38:28.88
くやしいのうw

674 :仕様書無しさん:2015/03/09(月) 06:50:19.43
てか
根本的に業界の開発形態が欠陥だらけなのは誰でもわかる事
欠陥業態から抜け出せないプログラマってどうなの?

675 :仕様書無しさん:2015/03/09(月) 07:33:08.71
>>661
残業中の光熱費だって無料じゃない

676 :仕様書無しさん:2015/03/09(月) 10:02:25.55
日本でプログラマが少ない理由は正当な対価を支払わないからである
http://anago.2ch.net/test/read.cgi/bizplus/1425792285/
「日本史なんかより、プログラミングを教えるべき」

三木谷浩史氏と夏野剛氏が日本の技術者不足を嘆く

677 :仕様書無しさん:2015/03/09(月) 10:58:41.99
数億で受けるべき仕事をたった数万程度で請け負って
相場を崩してきた人間たちが賃金を上げようとしても
今更無理w

678 :仕様書無しさん:2015/03/09(月) 17:46:19.69
未経験OKなんていってる業界に高待遇必要?

679 :仕様書無しさん:2015/03/09(月) 23:35:48.76
訂正

未経験OKなんていってる会社に高待遇必要?

680 :仕様書無しさん:2015/03/09(月) 23:58:54.18
未経験OKは、経験なし物覚えが悪くてもOKというわけではないぞ。
未経験だけど1日でなんでも覚えるスーパーマンならOKという意味だ。

681 :仕様書無しさん:2015/03/10(火) 00:04:08.53
未経験OK、年齢制限なし

これでも応募がないのが中小企業だよ
いや、うちだけかもしれん。いやいや、きっとうちだけだな
だって世間は就職先がなくて困ってるはずだもの

未経験はまず派遣して派遣先で教育してもらう
教育してくれて金までくれるなんて世の中はいい企業ばかりだよね
大企業はこれぐらい懐が深くなきゃね

682 :仕様書無しさん:2015/03/10(火) 00:37:29.87
>>681
当たり前の話なのだが、ある程度出来る人ならそういう経験なしの素人と
一緒に仕事したくないし、経験的にトラブルが多い会社と思ったりするから
よっぽどのうりがない限りそういう会社は無視する。 未経験は未経験で、
SIer関係の会社のブラックさが言われてたりするから寄り付かない。
他のサービス業や介護なんかに比べたらマシだけど、何もない人には
やっぱ辛い業界だからねえ。

683 :仕様書無しさん:2015/03/10(火) 06:21:42.96
経験なしでもOkなのに
内製だと素人では、、、、って矛盾だよね

684 :仕様書無しさん:2015/03/10(火) 06:33:28.62
派遣を売りとばす時は経験0でもOKだろ
困るのは客だ

685 :仕様書無しさん:2015/03/10(火) 06:49:38.89
でも作ってるのはその未経験派遣だという現実

686 :仕様書無しさん:2015/03/10(火) 08:31:57.51
☆コピペ推奨☆
【犯罪者追放のお願い】
派遣以外は指示禁止です。
発注者の指示に従うな!
受注報酬の搾取を許すな!
知的財産の譲渡を許すな!

刑法第246条 詐欺罪
虚偽による契約を締結された。

刑法第223条 強要罪
作成等の期限を強要された。

刑法第234条 威力業務妨害罪
威力によって業務を妨害された。

刑法62条 幇助罪
犯罪指示に従った。

職業安定法第44条 労働者供給事業の禁止
発注先から時間・場所・方法等を指示された。

労働基準法6条 中間搾取の禁止
実態が多重派遣で報酬を搾取された。

証拠を添えて提訴しましょう。 👀

687 :仕様書無しさん:2015/03/11(水) 18:49:53.66
受注系SEの皆様へ

期限強要・業務妨害・偽装請負裁判情報
事件内容
NTTコミュニケーション受託開発
被告企業
1次受注 グローバルウェイ
2次受注 ビジネスインフォメーションテクノロジー
3次受注 アイピーロジック
被害を訴える際に、
3次受注 アイピーロジックと
2次受注 ビジネスインフォメーションテクノロジー
が警察までついてきて反論し、裁判となりました。
3社とも原告に指示した事を認めました。

皆様も生涯損害被害にお気をつけ下さい。

688 :仕様書無しさん:2015/03/14(土) 10:11:55.58
スキルスキル言ってた奴が映像に派遣されて役立たずにw
そらそうだ、数学のすの字も出来ないんだから

689 :仕様書無しさん:2015/03/14(土) 11:31:43.56
>>688
やっぱりスキルって重要だな。

690 :仕様書無しさん:2015/03/14(土) 15:50:40.89
>>688
社会人向けの学校に行ってた時にみんなで快眠システムを作ろうって作ったとき寝ているときを画像や脈とかを解析するんだけど役立たずだった高卒プログラマを思い出した

691 :仕様書無しさん:2015/03/14(土) 15:55:24.90
>>690
で、お前は何も作れなかったんだろ?w

その高卒プログラマよりも劣ってるな。

692 :仕様書無しさん:2015/03/14(土) 16:28:03.85
>>691
高卒がつれたw

693 :仕様書無しさん:2015/03/14(土) 16:30:03.56
切り返しのパターン
 お前は何も作れなかったんだろ?⇒私は高卒です。私も作れません。ムキー!
 勉強すればできるようになるのに、勉強しないやつは学歴関係なく無能⇒まとも

694 :仕様書無しさん:2015/03/14(土) 16:30:50.05
で、最後に釣り宣言(笑)

お決まりすぎて笑いが出るwq

695 :仕様書無しさん:2015/03/14(土) 16:38:36.57
後釣り宣言でもいいじゃない、おもしろければ。
つまらんことで顔真っ赤にして後釣り宣言してもつまんないんだよ。

696 :仕様書無しさん:2015/03/14(土) 17:06:41.48
と、釣り宣言は恥ずかしくないんですよーって
言うやつw

697 :仕様書無しさん:2015/03/14(土) 17:13:49.63
まぁ、冷静に考えて反応できるのであば、
>>693

の言うとおりだな
小卒(というか現役中学生)でも画像処理やるやつはやる。
高卒でも実際に実装できるなら、高卒だからというフレーズは別にたいした煽りに感じない

698 :仕様書無しさん:2015/03/14(土) 17:33:20.81
そう。別に高卒でもできること。

ただ、なんでそういう当たり前で書く必要がないことを
書いたのかっていうのに書いている奴の人間性が現れてる。

699 :仕様書無しさん:2015/03/14(土) 17:47:11.29
試されてるんだろ

700 :仕様書無しさん:2015/03/14(土) 17:49:29.75
普通に
高卒って(Fランク卒、Eランク卒、短大卒、専卒、高卒以下)を全部含む表現だろ
採用試験に「大卒」とあっても、Eランク、Fランクなんて書類で即時落とすし

701 :仕様書無しさん:2015/03/14(土) 17:59:34.89
だからプログラマはバカバカなりなのか?
センスもないし、ただ動けばいいとしか思ってないコードを書く。
ちょっとリファクタリングしただけでも
動いている所を書き換えるなって怒るしな。

702 :仕様書無しさん:2015/03/14(土) 18:01:24.70
作ったもの(書いたコード)の良し悪しがわかんないんだろうね。

703 :仕様書無しさん:2015/03/14(土) 18:06:11.65
30年動いてるソースをなぜリファクタリングせにゃならんのだ
これだけ積み重ねてきた実績を大した根拠もなく変更するのはデメリットが大きい

実績を軽視しすぎではないか?

704 :仕様書無しさん:2015/03/14(土) 18:07:48.28
あ、まだリリース前のソースならリファクタリング賛成だからね
テスト前ならやっていいと思うよ
テストが終わってからだと「コメント変更」もダメだからね
バイナリ変わらないようにしてね

705 :仕様書無しさん:2015/03/14(土) 18:20:46.40
>>703
ほらなw

これだからいちいち学歴とか持ちだす奴はだめなんだよ。
コードで語れよ。

706 :仕様書無しさん:2015/03/14(土) 18:21:46.14
>>704
はい。リリースしたらコードは一切変更しません。
バグの修正も行いません。

バグの修正をしたら、テストにどれだけの時間がかかると思うのか?
何百人と人を集めないといけないからな。

707 :仕様書無しさん:2015/03/14(土) 18:23:15.05
リファクタリングができない=テストの自動化もできてないってことだから
そうとうレベルが低いよ。

デメリット0でメリットだけが有るのが
リファクタリングの特徴なのに。

708 :仕様書無しさん:2015/03/14(土) 18:45:12.35
そして、メリット0でデメリットだけ有るのが
>>707の特徴と

709 :仕様書無しさん:2015/03/14(土) 18:50:37.95
>>708
これだからお前みたいな低能はだめなんだよ。

710 :仕様書無しさん:2015/03/14(土) 19:00:53.44
リファクタバカ=無職winさんだからねw

711 :仕様書無しさん:2015/03/14(土) 19:04:48.15
>>705
実務で通年稼働したってのはそれだけで立派なテストだろ
それを30周してるんだ
うるう年対策も消費税対策も2000年問題も完璧ってこった

>>707
テスト自動化の設計と実装に工数くれよ
ソースがほんの少し見やすくなる程度でいくらかける気だよ
そもそも最初からきれいに書けよ
下手は何度書き直しても下手なんだよ

弘法が書き直した事あるか?利休が淹れ直した事があるか?ゴルゴがちょっと今の綺麗じゃないって撃ち直したか?

サザエさんですら同じ人生をやり直したりはしないんだよ
小さく作って大きく育てるのはテストコードをいじくりまわすって意味じゃないんだ

712 :仕様書無しさん:2015/03/14(土) 19:10:44.42
テストの自動化は別に銀の弾丸じゃないわけで、動いているシステムを
修正した時の工数削減には繋がるけど、それだけなんだよな。
他人が作ったテストでも無い限り自分の都合の良い結果しか返さない
ようなものしかたいていは作れないし。

713 :仕様書無しさん:2015/03/14(土) 19:19:52.46
今は自動車やラジコンヘリが自動制御で動く時代だし、人工知能が東大の入試問題に対して合格する回答を作成できる
クイズやチェスなんてもう人間が及ばないレベルになった
テレビゲームを与えたら、(ルールを与えなくても)勝手にハイスコアを目指す人工知能もある

テストの完全自動化ぐらい案外余裕で出来るんじゃないだろうか

ただ、Chromeのバグが減らない所をみるとまだ実用化はしてないようだけれども

714 :仕様書無しさん:2015/03/14(土) 19:53:24.83
>>711
> 弘法が書き直した事あるか?利休が淹れ直した事があるか?ゴルゴがちょっと今の綺麗じゃないって撃ち直したか?

何度もやってると思うが?

やってるから腕が上がってるんだろ。

前と同じことを何度もやっても腕は上がらないぞ。

715 :仕様書無しさん:2015/03/14(土) 19:59:24.39
ほらな、テストコードと実装の区別してないじゃん

716 :仕様書無しさん:2015/03/14(土) 20:06:40.09
思考回路が古いんだから仕方がないだろ
その区別すらできないんだから

717 :仕様書無しさん:2015/03/14(土) 20:08:32.11
どうもリファクタリングの成長効果っていうのを
理解していない人がいるようですね。

だめなものをだめだというのは簡単で、
実際に直さないと成長できないよ。
もちろんだめなものをそのままにしておくのも一緒。

718 :仕様書無しさん:2015/03/14(土) 20:17:24.54
リファクタリングは毎日のようにサービス内容がかわるWEB系に適用するものであって
30年も動いてるようなもんに適用するべきじゃないと思うよ
税率をリテラルで埋め込んでても数十年に1度の修正、新しい法律や在庫引き当ての方式が変わったとしても数十年に1度レベル
組み込みなんて修正する事すらできない

719 :仕様書無しさん:2015/03/14(土) 20:23:48.41
30年も仕事が無いのか?

720 :仕様書無しさん:2015/03/14(土) 20:24:42.21
まあ普通に考えたら、前のコードを使って
別の製品を作る時にリファクタリングするわなw
毎回一から全部書くとかアホな事してたら笑うけど。

721 :仕様書無しさん:2015/03/14(土) 20:28:28.43
最後に新規構築案件があったのはVB6の頃だ

722 :仕様書無しさん:2015/03/14(土) 20:32:09.70
うん。たいていは既存の修正がメインとなる。

最初から長年それを担当しているのなら
汚くてもどこに何があって、修正したときの影響が
どこに出るかはわかっているだろう。

だけど新しい人が入ってきた時に火を噴く。
修正するたびに新たなバグが生まれ、それを修正すると
また違うバグが生まれる。

新しくコードを書かずに、既存のコードを30年も修正し続けるからこそ
コードを複雑にしないで直すためのリファクタリングが重要になる。

723 :仕様書無しさん:2015/03/14(土) 20:33:26.98
もちろんリファクタリングというのは、
これから数ヶ月間、リファクタリング作業を始めます
なんて言ってやるものじゃないぞ。

そう勘違いしている人が多い。

コードを修正する時に常にやるものだ。
言われてからやるものでもないし、
わざわざ宣言するものでもない。

724 :仕様書無しさん:2015/03/14(土) 20:34:18.20
>>718
機能追加も不具合修正も何も起きてないならその通りなんだけど、追加分や修正分とその周辺を
ちょっとずつ良いコードで書き直すだけでも多少マシになる。修正やテストの工数が取れる部分なら
今まで通りのダメなコードの書き方や、ダメコードのコピペで済ませてはダメっていう。
リファクタ厨みたいに全部適用しろとかその逆で全く変えずに今まで通りにしろってのが問題なだけ。

725 :仕様書無しさん:2015/03/14(土) 20:40:27.74
修正すると全部テストしないといけないんですか?

そのためのコストがかかるから修正がだめだというなら
不具合も修正するんだから、そのために全部テストしないと
いけないってことですよね?

バグは放置するって考えでよろしいでしょうか?

726 :仕様書無しさん:2015/03/14(土) 20:41:56.09
>>724
リファクタリングって考えを持たない人がコードを書くと
こういうことが良くある。

俺「ここのコード、何の意味があるんですか?」

バカ「ここは、こっちのコードをコピペして動かない所を修正した。
これで動いている。このコードの意味は知らない」

まじでこれでプロやってるつもりだから困る。

727 :仕様書無しさん:2015/03/14(土) 20:48:01.59
古い人間に多いなマジで

728 :仕様書無しさん:2015/03/14(土) 21:04:03.01
>>725
基本的には対費用効果の問題になる。
その不具合で発生する不利益と直すのにかかるコストを考えて直すコストの方が
でかいなら放置もあり。 ナマモノと違ってバグは他に転移するわけじゃないからな。
潔癖症なのかなんなのか少しのバグも許さないって人は多いけどね。

729 :仕様書無しさん:2015/03/14(土) 22:07:30.44
>>728
全部テストする場合の費用はどれくらい?

膨大な金額になるけど、あんたそれだけの金だせるの?

730 :仕様書無しさん:2015/03/14(土) 22:10:54.63
> 潔癖症なのかなんなのか少しのバグも許さないって人は多いけどね。

客とかそうだよね。

こういったバグが有ります。
このバグを直すににいくらかかります。
お金を出してくれたら直します。

っていったら、そのバグを作ったのはお前のせいだろって怒るんだよ。
バグはソースコードの行数に比例して一定確率で発生するもんです。
このシステムの行数は数万行ありますって言ったら、
そんなに冗長なのはコピペばっかりしているお前の責任だろって怒るんだよ。

まったく、こっちは一行いくらで金貰ってるんだから
こっちが損することなんかしないっつーのw

731 :仕様書無しさん:2015/03/14(土) 22:51:55.10
>>729
そんなのシステムによるだろ。出せなきゃやらなければいいだけだし。
なんで全部テストするなんて発想になるの?頭おかしいんじゃない?

こういう奴もそうなんだけど、こっちだって都合があるし全部責任取れるわけでも無いし、
金だって調達出来るわけじゃないんだから言質を取られないような迂遠な表現で伝える
しかないんだけど、ちょっとでも自分の意見が否定されると全否定されたと思い込んで
すねて投げやりにやり始めるのが少なくない。20過ぎた同性がスネても可愛くもなんとも
無いんだから、そんな奴は面倒くさいと思われて相手しなくなるっての。

732 :仕様書無しさん:2015/03/14(土) 23:00:12.13
> そんなのシステムによるだろ。出せなきゃやらなければいいだけだし。
> なんで全部テストするなんて発想になるの?頭おかしいんじゃない?

な? お前もそう思うだろ? それはリファクタリングにも当てはまる話で
全部テストする必要はない。

733 :仕様書無しさん:2015/03/14(土) 23:13:51.19
影響範囲も分からない保守要員とはなさけないな。

734 :仕様書無しさん:2015/03/14(土) 23:17:43.03
影響範囲がわからないから、修正するなって言ってるんだけど?

735 :仕様書無しさん:2015/03/15(日) 02:17:32.99
影響範囲なんていきなり聞かれても分からんよ。 影響範囲一つとっても調べるのに時間が
かかるわけで、それはコストに他ならない。 ゆとりなのか何なのか知らんけど大抵の人は
ちょっと先に入っていて担当しているだけでソースコードの隅から隅まで知っている奴なんて
いる現場なんて無いよ。記憶のキャッシュにでも残っていればその場で答えを言えるかも
知れないけれども、間違えたらまずいから必要なら調べる時間もらうし。 自己中で頭が
回らないようなやつ相手にはそこまで手間かけ無い人の方が多いだろうし。

736 :仕様書無しさん:2015/03/15(日) 03:53:11.73
>>725
不具合修正は金がでるんだよ
客の都合で直すんだから

リファクタリングはこっちの都合で直すから金なんて出ない
どさくさに紛れてやるだけ
しかもそれが原因で何か問題が起きたらこっちの責任

自社内製や自分の所有物ならともかく外注・下請けの立場で余計な事をすると責任問題
それとがんばってリファクタリングしたってせいぜいコーディング規約にあわせて修正する程度だよ

ちなみに客に内緒でバグ修正したらダメだよ
客に教えたほうがいいのかどうかも結構難しいよ
いい関係だったら酒の席で修正を提案したらどうなるか探れるけどさ

場合によっちゃ客だって数千台のサーバーを修正する必要に迫られる
結構な金額になるし、構築時に担当だった客のSEも立場が悪くなるだろう
リプレースの時期までちょっと待ってという話になるかもしれない

737 :仕様書無しさん:2015/03/15(日) 03:57:00.69
>>726
そんなコードは新規構築時にレビューで叩き落とせよ
最初に適当な事するから、後からいつまでも修正が必要になる

738 :仕様書無しさん:2015/03/15(日) 04:13:53.83
自動化できないテストって何かあるの?
全部自動化できるならリファクタリングしない理由がない
その時の担当者の気分次第でいくらでも変えればいい

いや、リファクタリングそのものを自動化してはどうか?

Wordだって言い回しがおかしい箇所の指摘ぐらいはしてくれる
IDEもそろそろ「そのソースのここの行、何か意味あるんすかね?」ぐらい言ってもいいんじゃねーのかな
実際、ビルドする時に意味のない行は最適化で消しちゃうわけだしな

組み込み系の人は最適化オプションOFFだろうけど

739 :仕様書無しさん:2015/03/15(日) 05:03:49.12
>>736
> リファクタリングはこっちの都合で直すから金なんて出ない

723 自分:仕様書無しさん[sage] 投稿日:2015/03/14(土) 20:33:26.98
もちろんリファクタリングというのは、
これから数ヶ月間、リファクタリング作業を始めます
なんて言ってやるものじゃないぞ。

そう勘違いしている人が多い。

コードを修正する時に常にやるものだ。
言われてからやるものでもないし、
わざわざ宣言するものでもない。

740 :仕様書無しさん:2015/03/15(日) 05:19:25.17
>>739
プログラマが宣言せずにリファクタリングしたら損害賠償ものだよ

機能追加や不具合修正などの本来の依頼に紛れ込ませてやるわけだろ?
その部分に金を出してるわけじゃないし、工数として計上できる性格のものじゃない

しかも、本来の依頼の周辺だけリファクタリングしたら全体との整合性がとれなくなって改悪になってしまうじゃないか

プログラマが好き勝手にリファクタリングしたら全体としては見通しが悪くなる
個人の善意が巨大な悪を生むんだよ
それに何がきれいなコードなのかは個人差がある
仮にリファクタリングを積極推奨するにしても計画は必要だろう

リファクタリングなんてこういう結果を生むだけで誰も幸せになれない
https://sociorocketnews.files.wordpress.com/2012/08/fresco-photo.jpg

741 :仕様書無しさん:2015/03/15(日) 05:39:00.23
>>740
> プログラマが宣言せずにリファクタリングしたら損害賠償ものだよ

程度の低い開発してるなぁw

リファクタリングする必要がある場所でしなかったら
無理矢理なコードになってその分開発コストと不具合が増えるじゃん。

どんな仕事でも、既存のものを拡張する前に、まずその周辺を綺麗にします。
一階建て用の土台を使って二階建てに拡張しようとは誰も思わないわけで。

こんな単純なこともわかってないの?

742 :仕様書無しさん:2015/03/15(日) 05:40:35.25
> それに何がきれいなコードなのかは個人差がある

その個人差っていうのを見せてほしいねw

つか、汚いコードでも個人差あるんだから
何の意味もないことを言ってる。

743 :仕様書無しさん:2015/03/15(日) 05:46:43.51
汚いコードをリファクタリング綺麗にしたら、
きれいなコードと汚いコードが混ざって
汚いコードが目立つ。
だから汚いままにしておけばいいんだ。

なにが綺麗なコードかは個人差が有る。
だから汚いコードで書いていれば、
みんな汚いレベルで個人差など感じられない。

リファクタリングしなければ、全ての問題が解決する。
クソコードという言葉で一括りに出来る。

744 :仕様書無しさん:2015/03/15(日) 05:54:30.24
リファクタリングの工数が計上できないって意味不明な発言だよな。

AというものをBというものに変化させる。
その時、Aというものを間違ったB'ではなく正しいBに変化させる。
そのための工数を計上すればいいだけなのに。

ゴールが見えてないのに工数出せるわけないじゃん。
もしかして間違ったゴールへの工数を出してんのか?
正しいゴールへの工数を出せばいいだけの話なんだが。

745 :仕様書無しさん:2015/03/15(日) 06:07:22.49
Aさんがリファクタリングするだろ?
そしてBさんがそれは気に入らないとリファクタリングする
さらにAさんは勝手に直しやがってとリファクタリングする

これをエンドレスで繰り返して何かメリットがあるんだろうか?行き着く先は?

Aさんにとっての究極のコードはBさんにとっての糞コードで
Bさんにとっての至高のコードはAさんにとっての糞コードだよ

無限ループで工数は無限大だ

746 :仕様書無しさん:2015/03/15(日) 06:14:44.40
>>745
お前バカか?

汚いコードの話でいいよ。

Aさんがコード修正して、
それをBさんがコード修正して、
その話と何が違う?

同じ箇所を二人で修正するなよ。
コードの担当者が二人いるのが問題だろうが。
アホか。

747 :仕様書無しさん:2015/03/15(日) 06:17:53.66
普通にコードの可読性が高くてくてシンプルで無駄がなければ
どんな書き方でも良いコードだと思うけど?
別に良いコードであるならそれを書き換えようとは思わない。

どれが綺麗なコードがわからないレベルなら
ツール使ったほうがいいんじゃないの?

コード規約にあっているか確認するツールとか、
複雑度を計測するためのツールとかあるでしょ。

まずはそこから。

そうやって試行錯誤をしていけば
何が良いコードかわかるようになるよ。

>>745みたいなそういう心配をしているのは
単に技術的に未熟だからなだけ。

748 :仕様書無しさん:2015/03/15(日) 06:20:32.89
>>746
同時に修正する事はないだろう
だが、修正プロジェクトなんてせいぜい3か月で解散だ
次の機能追加をする頃にはすでに元のプログラマはいない

修正するたびにAさんBさんは増えていくんだよ

俺は時空を超えた話をしてるんだ
昨日今日のスパンでスパゲッティをかき混ぜる話をしてるんじゃない

749 :仕様書無しさん:2015/03/15(日) 06:22:23.47
おまえらってあたまいいなあ

もちろん皮肉です

750 :仕様書無しさん:2015/03/15(日) 06:25:45.15
>>748
元のプログラマがいないなら
Aさんが修正してBさんが修正て
いないはずのAさんが出てくるわけないやんw

751 :仕様書無しさん:2015/03/15(日) 13:11:31.07
>>748
新規や大規模追加ならともかく3ヶ月程度の規模のものなら人集めて
仕様理解させて、場合によっては教育して、実装してテストしてとか
考えると現実的じゃないだろ。その規模だと残っているのが対応して
いくから不幸なことにプログラマは残っているんだよ。

後は引き継ぎでどうにかしろとしか言えんけどな。

752 :仕様書無しさん:2015/03/15(日) 14:32:04.01
一部修正したなら全部テストしろよ!
テスト自動化してるなら可能だろ

753 :仕様書無しさん:2015/03/15(日) 14:39:58.94
>>752
無理です。客が金払わないからバグも放置です。

754 :仕様書無しさん:2015/03/15(日) 20:22:34.97
全部テストなんて可能なわけないだろ
アップルやGoogleやマイクロソフトでさえバグだらけだ

755 :仕様書無しさん:2015/03/15(日) 21:13:00.27
だから机上の空論だらけだからクビになって無職winなんだから相手にすんなって

テストの自動化wwww

756 :仕様書無しさん:2015/03/15(日) 21:26:27.84
テストを自動化するよりおまえらをクビにしたほうがバグが減る

757 :仕様書無しさん:2015/03/15(日) 21:41:24.97
自動化は可能だ
入力と出力をDBに入れとけばワンタッチで全機能テストできるだろ

758 :仕様書無しさん:2015/03/15(日) 21:43:22.45
それでテストできるような内容ならユニットテストで潰せるだろw
DBに入れるのはいいアイデアだけどさ

759 :仕様書無しさん:2015/03/15(日) 22:09:02.80
データ作りからしないといけないものはどうするんだろうねw

760 :仕様書無しさん:2015/03/15(日) 23:37:32.38
うちの職場にもツールによるテストの自動化を口にする奴がいたけど
プロジェクトのメンバーの中でそいつが一番バグを出してたんだよなぁ・・
テスト自動化云々を口にしていたのは単に自分のスキル不足の言い訳に過ぎなかったということ

761 :仕様書無しさん:2015/03/16(月) 06:42:39.28
バグをより多く出す奴ほどその欠点をカバーしようとする
当然の話じゃないか

762 :仕様書無しさん:2015/03/16(月) 09:13:08.60
そもそもバグを出しやすい人って、
アルゴリズムが頭の中にきちっと浮かんでない証拠

そういう奴に限って、テストの自動化とか言う

763 :仕様書無しさん:2015/03/16(月) 09:20:20.24
>>761
そして、そもそもバグを出さない方法を考えなくなり成長せずw

764 :仕様書無しさん:2015/03/16(月) 09:46:44.39
バグを多く出す奴程、
「俺様はバグなんか出さない」
なんて根拠のない自信持ってたりするけどな。

765 :仕様書無しさん:2015/03/16(月) 10:00:59.25
リファクタリング!
テストの自動化!

、、、、なんでこんな馬鹿になったんだろう無職winさんは

766 :仕様書無しさん:2015/03/16(月) 10:24:47.70
俺が原因のバグって今まで一度もないよ?

767 :仕様書無しさん:2015/03/16(月) 10:25:11.76
>>766
君自身がバグだった・・・・

768 :仕様書無しさん:2015/03/16(月) 16:50:47.40
そもそも、リファクタリングは突き詰めると、最初から上手いやつだけでやらないと意味が無い。
で結論出ただろ。
リファクタリングそのものより、完全なリプレイスをきちっとやれるうちにやる。
確かに、そのメリット等々をコスト等々で実際証明したりするのは難しい。でも、メリットは確実にある。
どのような方法で完全リプレイスをやるかは、検討するとして、
そもそも、現在目の前にいる糞情報システム部門をどうすんだ?という展開だったような・・・。たまにしか見てないから間違ってるかもしれんがw

769 :仕様書無しさん:2015/03/16(月) 17:18:03.48
1桁しかいないような少数精鋭チームならいいんだよ
特に継続的に同チームで保守していくようなね
暇があればリファクタリングするぐらいでちょうどいい
リファクタリングはメンバーのスキルアップや熟練度の向上の効果もある

ただ、短期間で入れ替わるような現場や数百人以上がかかわる大規模開発だと
バグが混入する原因を増やすだけ
リファクタリングに伴ってテストだって作り直す可能性あるだろ?
関数わけたりクラスを組み替えたり・・・。そこはリファクタリング推奨する奴は無視するけど
テストコードそのものすらリファクタリングしなきゃいけないんだよ

770 :仕様書無しさん:2015/03/16(月) 17:34:24.22
というか、数百人規模の開発ってのは、ホントやめたほうがいい。

それって一社丸々のシステムを指定の納期までに・・・っていう突貫工事のケースがほぼ100%。
少数精鋭で一つ一つ小さなシステムを組んで徐々に規模を拡大していく方式にしないと、結局一人できちっとゼロからすべてに携われないからシステム仕様もあいまいにしかわからない。
そんな奴が引き継ぐから後続はさらにわからない。気がつくと腰の重いだけの部門になっておしまい。
内製・外注問わず業務系システム開発では、最もやってはいけない過去の教訓でしょ。

771 :仕様書無しさん:2015/03/16(月) 19:19:59.44
>>770
ミズポ?

772 :仕様書無しさん:2015/03/16(月) 22:05:55.15
>>768
> そもそも、リファクタリングは突き詰めると、最初から上手いやつだけでやらないと意味が無い。

上手いやつじゃなくて、一人前のプログラマなら問題ないでしょ?

それとも何かい? お前の所は、半人前、どちらかと言えば
素人に近いプログラマばかりなのかい?

773 :仕様書無しさん:2015/03/16(月) 22:07:09.31
半人前とかプログラマは、何をやってもプロジェクトを崩壊させる。
リファクタリングをしなくても、結局一緒。
プロジェクトが失敗する原因はそういう使えない自称プログラマのせいであって
リファクタリングすらできないやつは、
仕事させないほうがいいんだよ。

774 :仕様書無しさん:2015/03/16(月) 23:18:12.71
リファクタリングはやめとけ〜
バグのないプログラムに手を入れてバグを作るほどアホなことなない!

775 :仕様書無しさん:2015/03/17(火) 06:27:04.19
コーディング規約を守る
それだけじゃダメなの?
リファクタリングで何を直したいのか今いちわからない

776 :仕様書無しさん:2015/03/17(火) 06:41:47.03
自称優秀なニートプログラマーの自己満足

しかし実態は新たなバグを生み出すソースの改悪

777 :仕様書無しさん:2015/03/17(火) 06:51:44.12
>>775
その規約をデフォ公式でIPAあたりが作ればなぁ
もしくはコンパイラ販売会社が

778 :仕様書無しさん:2015/03/17(火) 09:32:34.29
コーディング規約には多くの宗教問題、宗教論争を含むから
公式な規約なんてまとまるわけがない。
VHSとβ、Ble-rayとHD-DVDの戦争どころの話じゃない。

779 :仕様書無しさん:2015/03/17(火) 20:50:38.23
>>775
コーディング規約に「適切にモジュールを分ける」という決まりがあったとする。

では「適切に」とはどういうことか。

それが書いてあるコーディング規約はないんだよ。
なぜなら何が適切かは場合によるから。

こういうのは重要だが、コーディング規約に書かれることはないこと。

780 :779:2015/03/17(火) 20:54:48.57
>>775
分かりにくいかもしれないね。
もう少し具体的に説明する。

例えばマリオみたいなゲームを作るとする。
クリボーやノコノコこれらが有る決まりにそって動いているとする。

これらはおそらく、キャラクタークラスを継承して作られるだろう。

基底クラスに持たせるべきメソッドはなにか?
派生クラスに持たせるべきメソッドはなにか?

こういうことは、コーディング規約には書かれていない。

781 :仕様書無しさん:2015/03/17(火) 21:04:00.25
文書化できないならリファクタリングという工程でどうやってそれを実施させるのか

782 :779:2015/03/17(火) 21:10:25.23
ついでにリファクタリングの説明もする。

ノコノコには、赤いノコノコや青、黄、ハネが生えたパタパタなどの派生したキャラがいる。

ではキャラクタークラスを継承したノコノコをさらに継承するべきか否か?

もしかしたら当初の計画では緑と赤しかいなかったかもしれない。
この二つのためだけに、ノコノコクラスを作るのはやり過ぎな気もする。

だから最初はキャラクタークラスを直接継承して緑ノコノコと赤ノコノコを作っていた。
でもスーファミ版になってノコノコの種類が増えた。さすがに直接継承していると
重複コードが多くなりすぎる。よし、じゃあまとめよう。

こういう時にリファクタリングをするんだよ。

リファクタリングは決して汚いコードを直す行為じゃないよ。
最初のコードが、小さなコードでは適切だったが、大きくなるにつれて
無理が出てきた時にやるもの。

当たり前の前提として、どういうコードが適切かわかっている技術レベルが必要。
リファクタリングするとバグが〜というのは問題外の発想で、
それは技術力が低いやつが修正するとバグが発生するのと何ら変わらない。
そういうレベルの人は開発そのものをやってはいいけない。

783 :仕様書無しさん:2015/03/17(火) 21:15:14.28
>>781
> 文書化できないならリファクタリングという工程でどうやってそれを実施させるのか

文書化は出来るよ。
コーディング規約に出来ないって言ってるだけ。

なぜコーディング規約にできないのかは、
コーディング規約というのはコードがない状態で作るものだから。

それに対して、リファクタリングというのは、
AというコードをBというコードに変化させることだから、
まずAというコードがあることが前提。

「Aというコード専用のコーディング規約」って意味不明でしょ?w

AというコードをBというコードに変化させる。
その理由やメリットや手法は当然文書化出来る。

Aというコードは当初の予定を超えてコードが肥大化して
複雑化している。このまま放置すると制御不可能なレベルに膨れ上がるから
その複雑度を解消するためにBという設計に変化させる。
その為に、Aというコードのうち○と△の機能を分離(つまりクラスやファイルを分けること)
させることで複雑度を減らし、将来予定されている拡張に耐えられる設計にする。

こんな感じにね。

784 :仕様書無しさん:2015/03/17(火) 21:44:23.87
ニートPGってリファクタリングやらないだろ
本人一人しかソース見る奴いないんだし
だからやたらと否定するんだよね

785 :仕様書無しさん:2015/03/17(火) 21:54:02.37
リファクタ馬鹿はいい加減

Aが糞コード作りました。Bが納得いきません。Bが直しました。
Cが糞コード作りました。Bが納得いきません。Bが直しました。
AとCが糞コード作りました。Bが納得いきませんが、Bは自分の作業とAのリファクタ作業でCに手が回りません。
そうこうしているうちに、Dが現れて糞コード作りました。
さらにA,C,Dが糞コード乱発し続けます。
そうこうしているうちに、Eが現れて糞コード作りました。
さらにA,C,D,Eが糞コード乱発し続けます。
Bは完全にオーバーフローです。

という現実をどう解決するのか説明しろってw

登場人物A〜Eの5人。うち1名Bが使える人材。つまり20%も使える人材がいる高い割合なわけだ。
そんな、高い割合で使える人材がいる状況でもアップアップになる。
現実は、派遣だらけの使えない人材だらけの業界で、もっと悲惨な割合なのに、
大勢多数が生み出してくる糞コード製造バカの糞コードどうすんだよw

786 :仕様書無しさん:2015/03/17(火) 22:21:02.78
>>785の行き着く先の答えは少数精鋭でリファクタそのものが不要な環境でやるということになる

787 :仕様書無しさん:2015/03/17(火) 22:27:13.18
やっぱリファクタリングって人に依存しすぎてて信用できない
俺の書いたコードがいつの間にかわけのわからない形に変えられてそう

788 :仕様書無しさん:2015/03/17(火) 22:30:11.51
javaにはsun時代に作られたコーディング規約があって、javaのドキュメントにも
含まれていて、checkstyleっつー静的解析ツールにもルールの一つとして
組み込まれているんだけどな。

javaをdisるようなスクリプト言語マンセーな視野が狭い奴はそういうツールが
あることすら知らず、IDEなんてクソとか言ってテキストエディタでゴミみたいな
コードを原始的に生産し続けているのも少なくない。

道具を使えるのが人間の優位性の一つなのに、道具の使い方一つ学ぼうと
しない原始人がまじると割と終わる。

789 :仕様書無しさん:2015/03/17(火) 22:52:45.51
>>785
> という現実をどう解決するのか説明しろってw

話しあえばいいんじゃねーの?

いやさ、お前、コミュニケーション能力無いの?

790 :仕様書無しさん:2015/03/17(火) 22:59:26.84
Aさんが、Bさんがって言うけどさ、
じゃあ例えば、AさんはこういうUIが使いやすいと思いました。
BさんはこっちのUIが使いやすいと思いました。

話はそれと同じだよね?

それをどうやって解決してるんだよ?
話し合ってみんなで決める。最終的に誰か決定する人がいる。
そうでしょ?


ここから本当の問題が明らかになってるよね?

コードをどうするか決める人がいない。
個々のプログラマに任せてる。
誰も他人のコードを見ていない。

それが問題でしょ?

その問題があるがゆえにいつまでたっても
クソコードを量産し続けているって分からないの?
これはリファクタリング以前の問題だよ。

リファクタリングに問題が有るのではなく、
それ以前の最低限としてできていなければいけないこと。

791 :仕様書無しさん:2015/03/18(水) 08:18:31.45
>>790
最初からそれ聞いてるんだけど
かえってくる回答は「AさんもBさんもプロフェッショナルだから問題ない」って話だったじゃん?

結局、リファクタリングも通常の修正案件と手順は同じなんだね
機能の修正や追加はないけど、コードの修正や追加(もしくは削減)はある
それ以外の手順は同じ

792 :仕様書無しさん:2015/03/18(水) 09:04:14.82
>>791
えと、それで話しあえばOKってことでいいよね?

793 :仕様書無しさん:2015/03/18(水) 09:24:32.88
>>792
ああ、解決したな
じゃあリファクタリングは金にならないから就業時間外でヨロシク

794 :仕様書無しさん:2015/03/18(水) 12:43:52.19
一年:与えられた役割をこなすのがやっと。リファクタリング何それ?
二年:少し物を覚えてきてやたらと一年に説教したかる。それリファクタリングで改善しますよ?
三年:もう悟ってるので大抵の事には動じない。リファクタリング何それ?

中学生で例えてやった

795 :仕様書無しさん:2015/03/18(水) 12:52:32.59
リファクタリングとリプレイスの区別がついていない奴がいるな。

796 :仕様書無しさん:2015/03/18(水) 16:54:46.79
リプレイスは金が貰える
リファクタリングは金が貰えない

以上

797 :仕様書無しさん:2015/03/18(水) 17:33:45.64
>>796
そう考えてくれてた方が好都合。
心配ないよ、君の所はリファクタリング不要だ。

798 :仕様書無しさん:2015/03/18(水) 17:35:38.19
捨て台詞もリファクタリングしていけよ

799 :仕様書無しさん:2015/03/18(水) 17:39:43.56
>>796
>リファクタリングは金が貰えない

まさかリファクタリングを、テスト完了後にやってるわけじゃないよね?

800 :仕様書無しさん:2015/03/18(水) 17:43:38.83
>>799
テスト前って結論でただろ。過去ログ読めよ

ユーザー騙して余計な工数積み上げろって話のどこに正義があんの?誰が得するの?
無駄な残業してるやつほど給料もらってるっておまえの事じゃないの?

801 :仕様書無しさん:2015/03/18(水) 17:48:58.80
>>800
>ユーザー騙して余計な工数積み上げろって話のどこに正義があんの?誰が得するの?

周りがそういう低レベルの所に居るんじゃあ、しょうがないか。
リファクタリングしない場合の工数が正当だって根拠もないんだから意味不明だよ。

802 :仕様書無しさん:2015/03/18(水) 17:49:00.77
リファクタリングするくらいなら
完全リプレイにしとけ。
が、結論。

はぁ何回おんなじ結論に至ればわかるのか

無職winは

803 :仕様書無しさん:2015/03/18(水) 17:56:12.36
COBOL

804 :仕様書無しさん:2015/03/18(水) 17:56:58.65
>>802
その方が実績出せてるところならそれで良いんじゃね?
こっちの方が100%良いって言ってる奴は口先だけのが多いから無視推奨。

805 :仕様書無しさん:2015/03/18(水) 17:59:27.28
リファクタリングっていうのはポイント商売と同じなんだよ

・次に購入するときにポイント分だけ値引きします
・次に修正するときにリファクタリング分だけ工数圧縮します

806 :仕様書無しさん:2015/03/18(水) 18:03:59.41
>>805
普段から作業エリアを整頓しとけば、探しまわる無駄な時間を省ける、ってことだろうね。
だから、ごちゃごちゃにしてからのリファクタリングは、意味を理解してないからだし、
小規模なら構えてやるほどの事じゃない。

807 :仕様書無しさん:2015/03/18(水) 19:44:52.34
リファクタマンがどんなリファクタするのか見てみたいわ
元ソースとリファクタ後のソース見せてくれ

808 :仕様書無しさん:2015/03/19(木) 06:47:01.60
うちのチームは、きちっと最小部品化がきちっと出来てるから、リファクタリングなんかいらんわ

809 :仕様書無しさん:2015/03/19(木) 09:50:46.91
自社開発って、要は業務知識的な部分がマニュアル化されてないから外に出せないだけだろ?

810 :仕様書無しさん:2015/03/19(木) 09:55:28.91
自社開発っていっても開発採用でずっと開発してるんだから業務知識なんて外注と変わらんだろ

811 :仕様書無しさん:2015/03/19(木) 10:04:51.38
入社直後は業務知識得る為に、売り場に出て貰います。とか、工場のラインに入って貰います。とか、経理やって貰います。とかじゃね?

812 :仕様書無しさん:2015/03/19(木) 10:14:50.43
外注でも売り場やラインぐらいでるよね。まぁ、営業の仕事だけど

813 :仕様書無しさん:2015/03/19(木) 23:12:33.80
>>808
> うちのチームは、きちっと最小部品化がきちっと出来てるから、リファクタリングなんかいらんわ

それはいいことだけど、最初から「最小部品化」していると
設計やり過ぎになるよ。

いわゆるYAGNIってやつで、将来必要なこともない
過剰な設計をしてしまうことに鳴る。

そもそも将来どうなるかなんて誰にもわからないわけで。

そこでリファクタリングがでてくる。

リファクタリングっていうのは最初は小さく作っておいて、
それを大きくしていく時に、アホみたいにコードをつきたして
複雑にしていって手に追えない状態にすることとと真逆で
コードを付き足していくたびに、設計を見直して
「最小部品化」を保つこと。

こういう基本もわかってない奴が、リファクタリング作業にコストがかかるとか言い出すわけさ。
わかってない奴は、手遅れにしてからリファクタリングするものだと考えているから
要するに自業自得なわけ。

814 :仕様書無しさん:2015/03/20(金) 06:47:33.93
将来必要もない過剰なリファクタリングになっていませんか?

815 :仕様書無しさん:2015/03/20(金) 07:40:18.19
>>813
ない。
みんなうまい人だから、自然と最小部品で作るから。だれが言い出したでもなく。
負担でも何でもない。
むしろ、そういうふうに組まないほうがミスが増えて負担

816 :仕様書無しさん:2015/03/20(金) 07:43:11.44
リファクタリングしないと拡張で破綻する設計に問題があるのではないか?

817 :仕様書無しさん:2015/03/20(金) 07:43:19.77
SHIROBAKOでもなんでも、
物を作るという作業は
>>1の言うとおりなんだよな
源流が自分で作るか、作る人が源流と直接話す。
これ以上、これ以外に良い物を作る方法はない。

818 :仕様書無しさん:2015/03/20(金) 07:59:47.54
源流は忙しいんだよ

819 :仕様書無しさん:2015/03/20(金) 08:21:50.52
>>813
てか、最初からも何も
最小部品化で組むのは常識だろう
ひとつの部品に何でもかんでも詰め込むなよ

820 :仕様書無しさん:2015/03/20(金) 21:24:13.78
お前ら喋れないからなぁ
木下監督は喋れるけども

821 :仕様書無しさん:2015/03/21(土) 01:50:14.54
>>819
YAGNIって知ってますか?

Chromeが最初からプラグインの
仕組みを搭載してましたか?

どこまで拡張性を最初から持たせる気だよw

822 :仕様書無しさん:2015/03/21(土) 01:58:10.54
この業界で長年やっているが、
本当の技術力っていうのは
最初からきれいなものをかけることではなく
変化させていける力だよ。

一から書けばきれいなものがかけるとか、
安易に作り直したほうが早いというやつは
変化させる技術力が低いせい。

コードを一から自分一人で書ける機会はまず無いんだから
今あるやつを変化させていくしか無い。
正しい方向に変化させていく力が技術力の証で
コードに文句を言って置きながら直せないのは技術力がない証拠。

もちろんコードの善し悪しすらわからない人は
ソフトウェアの教育をうけてないということ。
もっと下である以前に、プログラマですらない。

例えれば味の善し悪しがわからない料理人(?)といえば
仕事させていいかどうか分かるでしょ?

823 :仕様書無しさん:2015/03/21(土) 06:50:31.52
>>821は盛大なアホ?

824 :仕様書無しさん:2015/03/21(土) 08:04:29.00
>>359
わろたw
似たような最近客に喜ばれている技。最近は.Netのプログラムが主流なんで、逆コンパイルするとほぼ戻る。そこを利用して
1 パッケージを売り込みに来た営業にサンプルプログラムを持ってこさせる。
2 逆コンパイラを走らせる
3 ソースを見て。あぁ煩雑ですね。コレは質の良くないプログラムだ。プログラマのレベルが低いんですね。と意味がわからなくてもいいから言う。
4 パッケージの金額が思いっきり下がる。か営業が退散する。
営業はプログラムのことなんて知らないことを利用する。
同じように値段が超大幅に下がるか、営業は二度と来ないか。
二度とこない営業は、やっぱりその程度のカスプログラムを売り込んでこようとしていたと判断。

825 :仕様書無しさん:2015/03/21(土) 09:13:14.68
人様のソースを勝手にいじって動きを再現できなくなって言い放った最後の言葉が「最初に作った奴が下手すぎる!」だった奴がいたわ。
いいからさっさと動くように戻せよ。もちろん自分で勝手にやったんだから給料とかいわないように。と21歳派遣の女の子にいわれて逃走したバカを思い出した。

826 :仕様書無しさん:2015/03/21(土) 09:45:52.78
350人の前で3時間もしゃべらないといけないから練習します・・・・
デスマーチより嫌な行事や・・・・・(ToT)

827 :仕様書無しさん:2015/03/21(土) 11:53:02.08
>>825
俺とは正反対だな。

最初に作った奴が糞する。客からの問合せで問題発覚。
問題自体は数年前から存在したバグ。
最近の別の修正でそのバグにぶち当たる確率が
高くなったから顕在化した。

相変わらずコードは汚くて複雑。しかもコードを確認していたらそもそも仕様からして間違っていたというw
正確にはそれでだめってわけじゃなくて、不要なことをしていてなんでそんな不要なことを
しているのかというと、案の定他のコードをパクって別の仕様を実装していた。というか消し忘れ?

つまり同じコードがコピペされてるわけで呆れなながらリファクタリングしたわ。
そしたら、また別のバグも発見(笑) よく今まで問題にならなかったものだ。

もちろんリファクタリングは動きを変えるべきものではないからテストコード書いて
動作が全く変わらないことを確認しつつリファクタリング。
そして最後にバグを修正するためのコードを追加。

リファクタリングしなかったら、新たなバグの発見も仕様の修正も大変だっただろうね。
そのリファクタリングによって、重複コードは削除され、
関数の複雑度も50を超えていたものが20前後の関数二つと10以下の小さい関数複数個にわかれた。

828 :仕様書無しさん:2015/03/21(土) 12:02:02.42
つか、修正とリファクタリングの違いを認識しろよ。

テストコードがないようなものは単なる修正。
修正によってバグが増えたり動作が変わってしまうようなら
それはリファクタリングじゃない。

それをリファクタリングと呼ぶな。

829 :仕様書無しさん:2015/03/21(土) 12:19:04.56
ここでもリファクタリングしてるようだね。

OpenSSLは実装スタイルに問題、コードベースから書換える - LibreSSL開発者
http://news.mynavi.jp/news/2014/05/09/452/

開発者の説明によると、現在のOpenSSLの実装はコードベースそのものに問題があるとしている。
コーディングスタイルにおいて、セキュアなソフトウェアを開発する目的からみると致命的な問題を抱えており、
このコードベースのままで安全なソフトウェアを開発することは困難だと説明。
よりモダンでセキュアなソフトウェアを記述するために、コードベースそのものを書き換える必要があるとしている。

LibreSSLではこれまでに9万行近いコードをOpenSSLより削除したこと、45万行ほどのdiffに到達したことなどを説明。
内部のAPIをよりモダンなものへ置き換えをはじめていることなども明かしている。
また、こうした作業の過程ですでにいくつかのバグを発見し修正したことも報告されている。

830 :仕様書無しさん:2015/03/21(土) 12:37:49.40
それはリファクタリングとは言わない。
こういうリファクタリングの意味も正しく知らないクズ人間が
リファクタリングリファクタリング騒いで、
作り直しをリファクタリングと言い張っているだけなのが現状。

831 :仕様書無しさん:2015/03/21(土) 12:45:38.29
本当に正しい意味でのリファクタリングが必要なら、作り直した方が早い。
つまり、結局リファクタリングいらね。

832 :仕様書無しさん:2015/03/21(土) 12:55:07.84
>>831
究極の無能乙w

833 :仕様書無しさん:2015/03/21(土) 13:02:15.44
>>826
ヒトカラ行って喉を一度潰したほうがいいぞ

834 :仕様書無しさん:2015/03/21(土) 13:09:13.38
>>831
正しい形にするなら、
最初から作り直すよりも
今あるものを変化させるほうが早いだろ?

どちらにしろ結果は同じだ。

835 :仕様書無しさん:2015/03/21(土) 13:10:35.71
本当の問題はプログラマ未満のやつが
ソフトウェアを作っているということ。

設計もリファクタリングも出来ない奴は
クビにするべきだ。

836 :仕様書無しさん:2015/03/21(土) 13:41:40.43
正しい形というより、清書とかペン入れという方に近いな。

テストにしてもカバレッジテストや単体テストの意識で結合やらその後のテストを考えれない
やつとか普通にいるし。 結合以降だとテストというよりリハーサルだろっていう。
テストガーテストガーって言っている奴は書いた値しか来ないカバレッジテストだけで全ての
要素を見つけれるとか思ってる頭悪い奴がほとんどだからな。 カバレッジテストでかなりの
バグを潰せるのは確かだか、100%潰せるってわけじゃないからな、100%潰せてたらこんなに
世の中に脆弱性の問題が出ないっての。 バグが出ても多少は問題ない職場と1件でも
バグが出ると上から下までえらくうるさい職場で同じことが出来るわけ無いのにな。

837 :仕様書無しさん:2015/03/21(土) 13:42:51.88
>>836
いや、100%になることはないの当たり前だろ?

そんなことだれでも知っていて、
より良くするための話をしてるんじゃないのか?

お前ずれてるよ。

838 :仕様書無しさん:2015/03/21(土) 14:10:26.08
>>835
その両方ができるやつだけの時点で、リファクタリング自体は不要になる現実w

839 :仕様書無しさん:2015/03/21(土) 14:17:23.41
まず、偏差値65未満はプログラミング禁止にすべき。

840 :仕様書無しさん:2015/03/21(土) 14:57:38.09
>>837
100%潰したってどう証明するの?
証明できるならそれを使っていればいいだけで、それが無いから現状があるわけで。

841 :仕様書無しさん:2015/03/21(土) 15:21:06.95
偏差値70未満はプログラマを名乗れないことにしよう

842 :仕様書無しさん:2015/03/21(土) 15:29:19.55
偏差値100超えてない奴なんているの?www

843 :仕様書無しさん:2015/03/21(土) 17:19:43.40
俺の世代は偏差値100は無理だった
問題が簡単すぎて

844 :仕様書無しさん:2015/03/21(土) 18:56:53.90
まず、朝鮮人が職場にいたら外すことからはじめたほうがいい

845 :仕様書無しさん:2015/03/21(土) 19:20:05.14
>>838
> その両方ができるやつだけの時点で、リファクタリング自体は不要になる現実w

お前リファクタリング分かってないじゃないかw

リファクタリングは、ソフトウェアの規模が大きくなる時に
構成を規模に応じて変化させることなんだが。

小さいときの作り方でずっと修正する奴がなんと多いことよ。
関数一つあったとすれば、機能が増えるたびに
関数の中にコードを追加するだけで分割しようとしない。

846 :仕様書無しさん:2015/03/21(土) 19:23:58.94
>>840
> 100%潰したってどう証明するの?

だから100%になることはないの当たり前って書いてあるわけ無いじゃないか。

それを知った上で、100%に近く
より多くのバグを退治するための話をしてるんだろ。

847 :仕様書無しさん:2015/03/21(土) 19:33:11.93
>>845
何千行もある関数だって、実は最初は数十行だったりするしね。

そこにちまちまちコードを追加していって、
何千行にも成長させる。

やっぱりリファクタリングは必要だよ。
それなしでどうやって関数を分割させるというのか?
数十行しかない最初のバージョンを最初から分割できるわけ無いし。

848 :仕様書無しさん:2015/03/21(土) 19:46:47.26
だからリファクタリファクタ言ってるやつは、さっさとサンプル見せてみろよ

849 :仕様書無しさん:2015/03/21(土) 19:47:24.67
リファクタマンは、一人で何役も大変ですなぁw

850 :仕様書無しさん:2015/03/21(土) 19:48:13.75
ビッ○カメラ札幌店の副店長の佐藤伸弦が暴行事件を起こしていた

佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦

佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦

佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦

佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦

佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦 佐藤伸弦

851 :仕様書無しさん:2015/03/21(土) 20:12:48.87
>>848
なんのサンプル?
本でも紹介すればいいの?
沢山載ってるけど。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
http://www.amazon.co.jp/dp/427405019X

852 :仕様書無しさん:2015/03/21(土) 20:16:46.69
リファクタリングを知っている人と知らない人の違い。

・知らない人

関数の機能が増えるたびに、引数をどんどん増やしていって
十個を超える引数をもった関数に成長させる。

・知ってる人

「引数オブジェクトの導入」のリファクタリングを適用して
複数の引数を一つのオブジェクトにする



これのサンプルコード必要ですか?

853 :仕様書無しさん:2015/03/21(土) 20:34:49.03
>>852
すでにその返しに対しては>>785が論破してるじゃん。
おまえが「知らない人」に分類しているのが、A、C、D、Eさんだろ?
Bさん間に合って無いじゃんw

だから、最初から上手いやつだけでやれって話。
そもそも、そんな引数大量の関数なんて作らんわwww

854 :仕様書無しさん:2015/03/21(土) 21:08:13.67
>>853
お前の提案する「最初から上手いやつだけでやれ」が何の解決にもなってないんだよ。

どうもお前リファクタリングをだめなコードを
直す行為だと勘違いしているフシが有るよね?

違うんだよ。自分が書いた良いコードを、自分で良いコードに直す行為の話でもある。
順を追って説明しようか?

まず、上手い奴、つまり最低限のプログラミング技術があることは大前提。
そんな技術がないやつは、リファクタリングを仕様がするまいがまともなコードは書けない。
そういうのはまず先に最低限の技術に到達するまで修行せろって話。

だから「最初から上手いやつだけでやる」というお前の条件を満たしていることを前提とする。

上手い奴が書いた、上手いコード。それはバグがないのはあたりまえだとして
コードに無駄がなく余計なことをしていないコード。この時点で将来どんな機能追加が
必要になるかはわからないから、過剰な拡張性を持たせてはいけない。

それから時がたって、機能追加の必要が出てきました。
前に書いたコードと、これから機能追加する人は同じです。だから意見の違いは起こらない。

それであったとしても、前のコードの構造のまま処理を単純追加すると、
複雑になるから、リファクタリングをするわけだよ。

前に書いたコードは当時の時点の要求では良いコード、それを要求が増えた時に
その要求を満たしても、良いコードに保つためにリファクタリングを行う。

な? 最初から上手いやつだけでやっても、一人しかいなくても
リファクタリングは必要になるだろ?

855 :仕様書無しさん:2015/03/21(土) 21:13:20.14
コードを成長させるって考えを持っていないから、

「最初から上手いやつだけで作っていれば」とか
「最初っからきれいなコードを書いていれば」とか
「最初から何年も使われる続けることを想定していれば」とか
「最初から高い拡張性を持たせていれば」とか

いう後悔だけして何も対処できない。

で、限界まで来ると
「作りなおしたほうが早い!」って言い出すんだよ。

修正が入るたびに、該当箇所を規模に応じた適切なコードに
変化させていく力がないからそうなる。
Think different? by 2ch.net/bbspink.com

856 :仕様書無しさん:2015/03/21(土) 21:43:37.01
つまり、自分のソースだけかw
無意味だな

その他99%がクソコード作るわけだから
Think different? by 2ch.net/bbspink.com

857 :仕様書無しさん:2015/03/21(土) 21:59:23.22
>>856
お前の会社はクソコードを書く人が
99%であるという主張はどうでもいいよ。

今は最初から上手いコードを書ける人間が
どうしてリファクタリングが必要になるかって話をしている。
Think different? by 2ch.net/bbspink.com

858 :仕様書無しさん:2015/03/21(土) 22:03:54.33
そもそもリファクタリング馬鹿は
業務系内製で簡単にソースの意味を理解できると思ってることが無能を証明してるようなもんだ。

そんなに簡単に理解して修正できるならミズホ助けてやれよw

859 :仕様書無しさん:2015/03/21(土) 22:06:07.48
リファクタリングをしないなら
ミズホをたすけられるって言うつもり?

なんでリファクタリング以前の話をするのかわからない。

今は最初から上手いコードを書ける人間が
どうしてリファクタリングが必要になるかって話をしている。

860 :仕様書無しさん:2015/03/21(土) 22:49:57.13
>「引数オブジェクトの導入」

危険な香りがする。
やばいにおいがプンプンする。
引数をオブジェクトにしようという考えを持っている時点で、その人は
物凄いハイレベルのスーパープログラマーか、とんでもないごみ人間の
どちらかだと思う。

861 :仕様書無しさん:2015/03/21(土) 22:50:56.17
>>860
普通のプログラマだろ・・・

多分お前の所のプログラマの定義が
標準よりはるかに劣ってる。

862 :仕様書無しさん:2015/03/21(土) 22:55:41.41
関数の引数が増えて行っちゃう→引数オブジェクトにしちゃえ

マジキチガイ以外の何物でもないが?

863 :仕様書無しさん:2015/03/21(土) 23:03:41.93
>>862
それをリファクタリング本を書いた人の前でいえんの?w

お前とどっちが信用できるかって話だが、
どうせお前は名乗れないだろう?

だから答えは出てるよ。
いくら言っても説得力はない

864 :仕様書無しさん:2015/03/21(土) 23:36:54.76
自分の意見や考えで反論するんじゃなくて、
本に書いてあった、だから絶対正しい、匿名の意見なんか聞くに値しない、
のような他人対他人の構図を取らせる反論ほど愚かで恥ずかしいものはないな。

865 :仕様書無しさん:2015/03/21(土) 23:41:49.34
>>863
>それをリファクタリング本を書いた人の前でいえんの?w

言えるけど?
連れてきてオフ会でもしてくれんの?
名刺交換したうえで意見言ってやるよ?

というかどうして言えないと思ったの?
自分が有名人()に負けるのが怖いから、他の人もそうだと思っちゃったの?

866 :仕様書無しさん:2015/03/21(土) 23:48:17.25
引数が多いってのはあんまり実害が少ないからどうでもいいな

867 :仕様書無しさん:2015/03/21(土) 23:59:31.47
引数が多くなったら構造体にして構造体を渡せばいいってこと?
確かにそういう思想のもとに作られたソース見たことあるけど、
関数によって構造体の値を入れるメンバが違っていて、恐ろしく
可読性も悪かったし、バグも潰しにくかったな。
必要な引数なら長くても関数の型としてあったほうが、コンパイラレベルで
潰せるから品質はよくなりそうなものだけど。

868 :仕様書無しさん:2015/03/22(日) 00:01:41.45
>>865
> 言えるけど?
> 連れてきてオフ会でもしてくれんの?
> 名刺交換したうえで意見言ってやるよ?

いいえ、ここであなたがどこの誰か
会社名と氏名を言ってくださいって言うことです。

本を書いている人はそれが明らかになっていますからね。

だから私は私を信用しろとはいいません。
本を書いた人を信用しろと言ってるのです。

869 :仕様書無しさん:2015/03/22(日) 00:05:55.49
どのリファクタリング本の事をいってるんだ?

870 :仕様書無しさん:2015/03/22(日) 00:06:29.06
コーダーは
設計しないできない
リファクタリングしないできない
テスト書けない書かないから
そら否定しかしませんわ

871 :仕様書無しさん:2015/03/22(日) 00:06:50.92
>>866
・引数が多い
・正規化されてない
・エクセルシートが横に長い

これって実害ありそうで全然ないよな

872 :仕様書無しさん:2015/03/22(日) 00:09:06.81
リファクタリングする言語
Python、Rbuy、C#

リファクタリングしない言語
アセンブリ、C、COBOL、VB、Java

873 :仕様書無しさん:2015/03/22(日) 00:12:01.72
>>869
既に書いた

874 :仕様書無しさん:2015/03/22(日) 00:16:43.22
>>865
ほら早く住所氏名年齢職業勤務先役職すべて晒してみろよ?
できないの?できないクズ人間の分際で実名出している本の作者貶したの?
まさかね。キチガイとまで行ったんだから当然全部晒せるよな。
早く晒せよ。

875 :仕様書無しさん:2015/03/22(日) 00:21:41.29
>>871
お前、引数の数が50とか100になっても同じこと言えんの?

876 :仕様書無しさん:2015/03/22(日) 02:33:51.90
>>872
Eclipseの機能で普通にリファクタリングっていうメニューが有るのですが?

877 :仕様書無しさん:2015/03/22(日) 02:36:02.25
まあ、最低限wikipediaに書いてあることくらい読んでから議論しようよ。
オレオレ理論じゃなくてさ。
http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

878 :仕様書無しさん:2015/03/22(日) 02:41:08.16
>>877
>リファクタリングはオブジェクト指向設計と深くかかわっている。リファクタリングのほとんどはオブジェクト指向の性質に沿ったものであり

これが結論じゃね?業務系でオブジェクト指向設計を採用してるとこ皆無だよ

879 :仕様書無しさん:2015/03/22(日) 02:57:18.72
>>878
いいからリファクタリングで定義されている手法の名前
一覧ぐらい見てからにしろ。

オブジェクト指向に特化したものもあるが、
それ以外のものも有るだろ。

そういう基礎的な知識もがないアマチュアがまじりこむから
間違ったこと言い出して困るんだが。

880 :仕様書無しさん:2015/03/22(日) 03:11:05.62
switch文をポリモーフィズムにするなんてコーディング規約で禁止するレベルだわ

881 :仕様書無しさん:2015/03/22(日) 03:50:17.99
>>880
はぁ。またか。

何が最適かは規模に応じて変わっていくもんなんだよ。
switch文も規模が少ない場合は問題ない。

だけど、それが大きくなってなんども同じ条件のswitch文が
でてきたら変えるべきだろ。

だから最初は小さく作っていって、それが大きくなって複雑化した時に変えるんだよ。
その変える行為がリファクタリングなわけ。

最初っからポリモーフィズムを使うべきだとか
思ってるからそういう勘違いをするんだよ。

882 :仕様書無しさん:2015/03/22(日) 03:55:21.53
リファクタリングのことをちゃんと勉強すればわかることなんだけど
あるリファクタリングと反対のことをやるリファクタリングがある。

例えば、Extract Method(メソッドの抽出)と
Inline Method(メソッドのインライン化)は正反対の作業。

ここからわかることは、リファクタリングはどちらが良いかを
決めてるものじゃないということ。

どちらがいいかは規模や内容によって変わるわけで、
より適切なものに安全に変化させるための手法が
リファクタリングなんだよ。

こんな基本的なことを理解していないから、
最初から良いコードを書けばいいとか汚いコードを直す作業とか
どっちが綺麗は人によって違うとか言い出すんだよね。

それはリファクタリング以前の基本的なプログラミング技術の問題。
リファクタリングは、基礎ができてプログラマが
コードの成長にともなって最適なものに変化させる行為のこと。

883 :仕様書無しさん:2015/03/22(日) 05:51:18.86
>>872
> リファクタリングしない言語
> アセンブリ、C、COBOL、VB、Java

C#1沢な今の時代にCやJava、ましてやCOBOLで開発しているところなんてあんの?

884 :仕様書無しさん:2015/03/22(日) 06:21:00.27
ウェブアプリ開発でC#とか聞いいたことがないがw

885 :仕様書無しさん:2015/03/22(日) 06:21:54.46
>>884
.NETを知らんのか?

886 :仕様書無しさん:2015/03/22(日) 06:23:44.83
>>884
ウェブアプリなんて趣味で開発するようなものじゃん
ビジネスの分野では普通使わないし

887 :仕様書無しさん:2015/03/22(日) 06:26:25.60
>>886
ウェブアプリがなにかわかってない?

具体的な話をすると、
Google、Amazon、Twitter、Facebook
などが自社サービスで作ってるものだよ。

888 :仕様書無しさん:2015/03/22(日) 07:39:27.45
これだから

ユーザーが求めてるものは
自分たちの求めるものを作って!

であって、おまえらがいかにあさっての方向見てるかがよくわかるスレだわ

889 :仕様書無しさん:2015/03/22(日) 07:56:02.61
>>887
> 具体的な話をすると、
> Google、Amazon、Twitter、Facebook
> などが自社サービスで作ってるものだよ。

それ全てWindowsじゃんww

890 :仕様書無しさん:2015/03/22(日) 08:02:10.74
【全ての分野においてWindowsが圧勝】
東京証券取引所の基幹システムとして稼動するWindows
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548
HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html
Windows上で稼動するメインフレーム
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html
NASパフォーマンス比較テストでWindowsがLinuxを圧倒!!
ttp://www.flexense.com/documents/nas_performance_comparison.pdf
BDレコのOSはやはりWindowsだった!!
ttp://it.slashdot.jp/story/12/04/24/0052242/

891 :仕様書無しさん:2015/03/22(日) 08:02:14.27
>>878
紙芝居レベルのなんちゃって業務アプリ開発は、これから無くなっていくよ。
気の利いたアプリを作ろうとすると、イントロスペクションとか、コールバックとかのオブジェクト指向的概念は便利。

892 :仕様書無しさん:2015/03/22(日) 08:09:01.96
だからぁ

リファクタリングさんは、無職winさんだって言ってるでしょ

なんで相手にすんの?
linuxスレ行ってくればこいつがどれだけ情けない人物か全部公開されているよ

893 :仕様書無しさん:2015/03/22(日) 08:10:49.91
しかも、最後の望みだったwindows(マ社)がLinuxに尻尾振ってる状態
もうOSシェア戦争では完全敗北だよwindowsは

894 :仕様書無しさん:2015/03/22(日) 08:11:24.75
>>892
Linuxスレでもとっくに"Linuxはゴミ"という結論が出ているわけだが?

895 :仕様書無しさん:2015/03/22(日) 08:12:02.92
>>893
妄想乙ww

896 :仕様書無しさん:2015/03/22(日) 08:12:22.72
>>894人物の指摘ですよw無職さんw

897 :仕様書無しさん:2015/03/22(日) 08:18:18.02
Linux使いはリファクタリングもまともに語れない、と

898 :仕様書無しさん:2015/03/22(日) 08:19:24.58
>>883
NetCOBOLでウェブアプリを作るなんて珍しくないでしょ

>>884
PHPの次の次の次ぐらいにはシェアあっただろ
VB系に負けてるとは思うけど

>>886
ビジネス分野はもうほとんどウェブアプリでしょ
インストールして使うようなの最近みてないぞ

>>891
このスレを見てるような経歴2桁年以上で熱心に勉強してきたり
教育を受けてきた層ならともかく、これから開発にアサインされるのは素人だよ
過渡期の技術を多用してもソースを負いにくくするだけ
コールバックなんてWindows初期から難読化の原因とずっと言われてるだろ

899 :仕様書無しさん:2015/03/22(日) 08:22:53.82
Webアプリは寧ろ.Net以外で開発しているところを見た事が無い

900 :仕様書無しさん:2015/03/22(日) 08:33:12.70
>>896に対して>>897を返す
こいつは、ホント自分を隠そうとするんだけど、ことごとくバレるwww

901 :仕様書無しさん:2015/03/22(日) 08:52:47.34
>>893
> しかも、最後の望みだったwindows(マ社)がLinuxに尻尾振ってる状態
> もうOSシェア戦争では完全敗北だよwindowsは

ソースは?

902 :仕様書無しさん:2015/03/22(日) 09:07:07.46
Linux vs Windowsの話題って尽きないけどさ、
おまえらLinuxが負けたら死ぬの?Windowsが負けたら死ぬの?
少ないパイをLinuxとWindowsで食い合っているんじゃなくてさ、
IoTで無限増殖バイバインしてるパイをLinuxが食おうがWindowsが食おうが
T-Kernelが食おうがBSDが食おうがOS2が食おうがN88BASICが食おうが
どうでもいいじゃん。どうせOSが何であっても仕事はしないといけないんだし。
いまはさ、Linux vs Windowsでどっちが勝った負けたよりも、
どうやってこの仕事地獄から抜け出すか考えたほうがいいんじゃないかな?

903 :仕様書無しさん:2015/03/22(日) 09:20:53.13
>>902
> Linux vs Windowsの話題って尽きないけどさ、
> おまえらLinuxが負けたら死ぬの?Windowsが負けたら死ぬの?

ただWindows独壇場の現在、未だにLinuxガーとか騒いでる人間をおちょくるのが楽しいだけw

904 :仕様書無しさん:2015/03/22(日) 09:31:09.63
Windows+Oracleなんて1000万超え確実じゃん
中小には関係ないね

905 :仕様書無しさん:2015/03/22(日) 09:50:03.21
>>902
そんなこと言っても、中略・・・Ubuntuマンせーwindowsだせー
とか言ってたけど売名でLinuxでの翻訳をやろうとして、おまえの翻訳めちゃくちゃだからといわれ参加拒否されてから一気に
linuxは犬とか言ってwindowsマンセーになって中略・・・、未だに無職の人には無理でしょw

906 :仕様書無しさん:2015/03/22(日) 10:10:57.47
>>898
> コールバックなんてWindows初期から難読化の原因

Cの関数ポインタを未だに使ってるからじゃね?

907 :仕様書無しさん:2015/03/22(日) 10:14:45.26
リファクタリングなんて、出来て当たり前の事じゃん。
もっと高度な話しようぜ。

908 :仕様書無しさん:2015/03/22(日) 10:32:06.41
LinuxかWindowsか、が課題になるのは、個人と大企業。
中堅企業の場合は、尖ったことをやりたくて特化するか、
間口を広げて、それこそMacだろうとなんだろうと出来るようにするか、だもんな。

あと、既にメジャーOSが有る現代では、非メジャーOSがシェアを上げるのは難しいよ。
まあシェア上げる必要も無いけどね。

909 :仕様書無しさん:2015/03/22(日) 12:57:35.42
すげえスレだ
どいつもこいつも天才ぶりっこで書き込んでる割に
100個に1個にくらいしかまともなレスが無いw

910 :仕様書無しさん:2015/03/22(日) 14:43:31.40
まあ人様に強要してるのはCOBOL現場に派遣されているクビになった人だけどね

911 :仕様書無しさん:2015/03/22(日) 16:13:44.39
>>902
話題尽きないじゃなくて、マ板だとwindowsが全てLinux死ねってのは
windowsさん一人が言っているだけで、IDが出ないからwindowsさんが
飽きるまでそれが続いているだけ。windowsさんみたいな壁打ちを
相手にするのも同じレベルだけどね。

912 :仕様書無しさん:2015/03/22(日) 18:20:25.52
>>909は一番役に立たないけどな。

913 :仕様書無しさん:2015/03/23(月) 19:57:31.86
無職の馬鹿いなくなった?
土日に久しぶりに書こうかと思ったけど馬鹿がいたからやめたんだけど

914 :仕様書無しさん:2015/03/23(月) 19:58:03.73
>>913
それはお前のことじゃね?w

915 :仕様書無しさん:2015/03/23(月) 20:23:08.44
無色は毎日が休日

916 :仕様書無しさん:2015/03/23(月) 20:55:12.93
誰のこと言ってるかは大体分かるけど
傍から見てると大差ない

917 :仕様書無しさん:2015/03/23(月) 21:52:42.28
五十歩百歩ってやつだな
大して違わない、と見せかけて実は倍違う

918 :仕様書無しさん:2015/03/28(土) 14:11:51.39
もうスレ4にもなってたんですね。
年末に用度システムを作成して総務システムに手を広げた者です。
一区切りがついたのでチラ裏報告します。結論からいうと6部門が現場内製をしています。
スタッフは教育をゼロから初めましたが、もう皆普通にプログラマとして名乗ってやってけるレベルにまで育ちました。
言語はC#。Linux云々も当然脳裏にはあったんで、それを見据えた言語を…と思ったんですけど、業務をこなすのが先かなと。

年に1ヶ月丸々情報システム課員として集合。予算も十分なくらいもらえます。
3DプリンタやCNCフライスなんかも入れてもらいましたw(完全に趣味w)
集合して全員で1つの業務システムの抜本的改革を企画するという方式になりました。
なので、決定権を持つ人が、企画を認めたら最低でも6年ごとに各システムは強制的に新システム化することになります。
こうやって、新技術の勉強や実験をしつつ、システムが古くならないようにしつつ、次のエンジニア育成の機会を作る。
ということになりました。Linux化は、そのときに、少しずつ導入して割合を増やしていけば皆アレルギー無くいけるだろうと。

情報システム課メンバーになるとその期間だけは基本給で月5万アップする方式にして希望するなら仕事の成果次第で未経験でも
登用。ひとつの課で同時期には最大2名までという誰でもシステムに参加できる方式になっています。
結果として、無駄な決裁とか慣習でやっていた無駄な作業をなくす機会が強制的に発生しているので、現場の評判も上々です。

919 :仕様書無しさん:2015/03/29(日) 02:45:24.44
>>918
おまえにしか分からない日記文だなw

920 :仕様書無しさん:2015/03/29(日) 11:25:37.10
>>919
まぁ確かに日記文だけど、お前より遥かに技術、行動力、社会性あるよこの人
ハードの調達からハードの実装、ソフトの実装を数日でやってのけてるもの平然と

921 :仕様書無しさん:2015/03/29(日) 12:05:58.43
>>920
おまえはエスパーか?
どこにそんなことが書いてあるのか。

922 :仕様書無しさん:2015/03/29(日) 12:21:55.47
ちゃんとハンコ貰ってたけど、メンバーを抱き込んだからなぁなぁで済ますようになったって事だろう
それがいいか悪いかの判断は結果次第

923 :仕様書無しさん:2015/03/29(日) 12:27:45.31
ここは夢日記のスレッドではありませんよ?
こちらへどうぞ http://kanae.2ch.net/yume/

924 :仕様書無しさん:2015/03/29(日) 12:55:25.33
この絵って、このスレより遥か前からあるよね
http://ntd.way-nifty.com/blog/20040516.gif
未だに現実を見つめられない人が外注のほうが優れている!キリッ!って言ってるわけだ。

925 :仕様書無しさん:2015/03/29(日) 13:29:23.92
お前らそもそも読解力が無いのな
で、他人の成功にはいちいちアヤ付けなきゃ気が済まないと。
クソだな

926 :仕様書無しさん:2015/03/29(日) 13:35:56.65
>>924
プログラマは言われた通りコピペすりゃ
後は知ったこっちゃないからな
間にベンダーと情シスが入るから
どんなクソシステムでもユーザーの反応なんて分からんし

927 :仕様書無しさん:2015/03/29(日) 13:41:42.62
>>924
Delphi6ぐらいのときにボーランドの広告に表示されてたやつだよね

928 :仕様書無しさん:2015/03/29(日) 17:28:58.43
>>921
過去スレみてこい

929 :仕様書無しさん:2015/03/29(日) 17:39:14.17
成功するかどうかは、わからないけど。
試みとしては面白い。
5年位したら結果を知りたい。

いずれにせよ、口だけでなんにも動けない奴やライン工と変わらない派遣の分際でシステム内製を語る奴なんかとは比較にならないほど有能だ

930 :仕様書無しさん:2015/03/29(日) 17:50:25.35
問題は二番手以降を育てられるか?だな。
一番手は、直接伝授できるが、二番手以降を誰が育てるか?

経営人が5,6年ごとのリプレイスに、理解を示せるか?

選抜にしたとして立候補したとしても不向きだった場合どうするか?

内製ができる会社はホント理想やなぁ
システムや開発者の重要性を理解してくれてるってことだから

931 :仕様書無しさん:2015/03/29(日) 18:16:12.49
何度目の書き込みか分からんけどさ。30年前ならともかく、
今の外注と情シスの低質化を考慮したら外注こそありえねーよ
表面的に契約履行してカネが回ってても肝心の現場の生産性がダダ下がりとか普通にある
ノウハウが残らないどころかベンダーロックで会社潰れる寸前までしゃぶられる
BIだのクラウドだのタブレットだの、
無知な経営者とうんこ情シスを騙すだけの言葉だけはフンダンに溢れてるしな

932 :仕様書無しさん:2015/03/29(日) 21:57:03.42
プログラマ自身が土方とか言ってる始末だしな
業務とやりたいことわかってれば、片手間にできるわ
今の開発環境なら

933 :仕様書無しさん:2015/03/29(日) 22:00:21.62
というか内製と外虫を比べること自体おかしい
かたや自分の所属する会社で一蓮托生の人が多い
かたや年齢が来たら切られるのがわかってる派遣で、まともな正社員になれなった人たち
これ、システムの質からして比較対象にならないのはやる前からわかること

934 :仕様書無しさん:2015/03/29(日) 22:37:07.70
>>931
何度目の書き込みを見ているのかも分からんけどさ。
君も>>918氏のように動いてみたらどうかね

935 :仕様書無しさん:2015/03/29(日) 23:48:48.66
>>933
>かたや自分の所属する会社で一蓮托生の人が多い

昭和の発想。

936 :仕様書無しさん:2015/03/30(月) 00:24:28.20
>>931
> 30年前ならともかく今の外注と情シスの低質化を考慮したら外注こそありえねーよ

若輩ですが、30年前は外注といえば請け負い会社の経営者(フリーの流し)の
猛者ばかりだったと聞きます。

確かにいまは烏合が多すぎる。
このご時世に大学行けなかった高卒のようなものとか、勘弁してくれ。

937 :仕様書無しさん:2015/03/30(月) 00:40:23.29
>>933
専門家として、プロとしての自負は無いわけだ
外注側がそれ言ったらおしまいだな

938 :仕様書無しさん:2015/03/30(月) 00:59:09.41
情シスとか派遣プログラマっていいよなー
情シスは頭を使う仕事は全部丸投げで会議とメールの中継しかやってねーし
派遣プログラマはわかりもしねー糞コードを継ぎ接ぎしてるだけだし
それで慢性的に大残業しちゃ
クソの役にも立たないシステム量産してんだから世話ねーよ
死んで欲しいね

939 :仕様書無しさん:2015/03/30(月) 02:25:36.04
お前らがそんなに優秀なら派遣プログラマなんて駆逐してみろよw

940 :仕様書無しさん:2015/03/30(月) 02:34:24.69
駆逐するまでも無いというか30年前のシステムでも十分生産性を上げられるんだけど
情シスのバカどもが一生懸命外注しようとするんだよね
システムの一本化だのエクセルレガシーだの聞き齧りばっかり題目に掲げるんだけど
その情シスが自らシステム分散させて、誰も使わないクソエクセル大量にバラ撒いてるんだから情けない
基幹システムは会社のものだから手を出す事は出来ないけど、
少なくとも今の派遣プログラマにお世話になる事は無いよ

941 :仕様書無しさん:2015/03/30(月) 03:47:16.80
>>940
大丈夫か? 言っていることが支離滅裂だぞw

942 :仕様書無しさん:2015/03/30(月) 14:59:56.52
自社システムが自社にとってコアな存在なのか
もし、どうでもいい存在であれば外注したほうがいいのでは?
もはや作らないという選択肢だってありえる

943 :仕様書無しさん:2015/03/30(月) 17:34:16.64
システムも一部向けだけにして、
パソコンも一部の人だけにして、
他はパソコン叩いてる暇あったら飛び込み営業しろということやね

944 :仕様書無しさん:2015/03/30(月) 17:36:59.03
営業「作る人いないけどうちに仕事ください!」

945 :仕様書無しさん:2015/03/30(月) 17:37:43.99
むしろ営業は外注でいい気がするw
だれでもいいしね。

946 :仕様書無しさん:2015/03/30(月) 23:12:34.83
JUAS『ソフトウェアメトリックス調査2014』を読み解く
http://brevis.exblog.jp/22912701/

ソフトウェア開発の品質は、次第に、だがかなり決定的に、向上しているのだ(バグをABCランクで
重要度の重み付けをした数値については、報告書を参照してほしい)。それだけではない、「品質に
ついては、要件定義・設計・実装の各フェーズがすべて請負・請負・請負の契約のものの品質が
明らかに悪い」(p.191)と大胆にも分析している。『業者にお任せ』型の開発は、よい品質を生まないのだ。

--------------
こんな感じで外注に投げっぱなしはダメなのが数字にも表れている。

947 :仕様書無しさん:2015/03/31(火) 12:15:41.97
>>946
そのレポート自体の”品質”はどうなの?

948 :仕様書無しさん:2015/03/31(火) 12:35:57.93
>>947
悪いというデータが有るのかい?

949 :仕様書無しさん:2015/03/31(火) 18:21:46.03
一度外に投げたら最後、次からは完全丸投げに嫌でもなるからなぁ
どんなに担当が優秀でも

950 :仕様書無しさん:2015/03/31(火) 19:02:56.37
>>948
図星か。

951 :仕様書無しさん:2015/03/31(火) 20:48:02.58
>>950
いや、図星じゃないから
聞いてるんだが?

952 :仕様書無しさん:2015/04/01(水) 00:09:20.15
>>947
http://www.juas.or.jp/servey/swm14/index.html
この調査につかった調査票がダウンロードできるから確認してみたら?
2004年から調査してると書いてあるから、まあそれなりにじゃないの。

953 :仕様書無しさん:2015/04/01(水) 03:10:41.95
わざわざ回答する動機を持っている会社だけが回答しているわけだから、
サンプルが偏っている可能性はあるな

954 :仕様書無しさん:2015/04/01(水) 07:04:44.53
間違っている可能性があるんだから
間違ってるんだよ。
反論終わり。

地球も回ってない可能性があるからな!

955 :仕様書無しさん:2015/04/01(水) 07:38:00.68
メインフレームの信頼性は認めるが、融通の聞かなさをなんとかしてくれ、、、、

956 :仕様書無しさん:2015/04/01(水) 08:11:39.18
>>952
それだけの情報があるなら正しそうですね。

957 :仕様書無しさん:2015/04/01(水) 08:14:49.32
統計データなんだから正しい答えがあるわけじゃないので他人がどうこう以前に
自分で読んでみて判断出来ないorしないってのは思考停止に近いな。

958 :仕様書無しさん:2015/04/01(水) 08:20:05.95
はい。読んでみて正しいと思いました。
間違っているという、具体的な反論もないことですし^^;

959 :仕様書無しさん:2015/04/01(水) 21:56:05.14
品質が良くて、バグか少ない

というのはありえない!
と言いたいが、バグとして認めなきゃバグは少なくなる

960 :仕様書無しさん:2015/04/01(水) 22:03:18.58
品質が良くて、バグか少ないのは当たり前。
品質が悪いと、バグも多い。

961 :仕様書無しさん:2015/04/01(水) 23:15:02.09
品質ってバグの数のことじゃないのか?

962 :仕様書無しさん:2015/04/02(木) 06:20:45.63
バグも品質の一つだね。それに加えて速度とか
メンテナンス性とか言うのも品質の一つ。

結局は開発時間に換算できるので、
短い開発期間でより多くのことができる技術力が有るほど
その期間でやれることが多くなるので品質が上がる。

963 :959:2015/04/02(木) 07:42:36.22
あ、品質低くて、バグ少ないだったw

964 :仕様書無しさん:2015/04/02(木) 08:08:03.40
軽いバグは残しておくんだよ。
客と関わりが少なくなる

965 :仕様書無しさん:2015/04/02(木) 08:23:52.08
そんな余裕があるわけない

966 :仕様書無しさん:2015/04/02(木) 23:23:52.67
バックアップデータが吹っ飛んだ〜
http://www.fbscorp.com/win_ex/

967 :仕様書無しさん:2015/04/03(金) 17:41:47.06
阿鼻叫喚?

968 :仕様書無しさん:2015/04/05(日) 10:40:02.68
>>918
マイクロソフトがVisualStudioでlinuxバイナリ生成を対応しはじめたぞ
もう、ほっといてもwindowsは廃れる
携帯やモバイルでのOS戦争に敗れたから

969 :仕様書無しさん:2015/04/05(日) 10:43:56.97
>>968
もう20年ぐらいから
同じようなことを聞いてますが、
いつ廃れるんですか?
100年後ですかね(大爆笑)

970 :仕様書無しさん:2015/04/05(日) 10:54:52.03
>>969すでに終わってるけどな気づいてないの?wマイクロソフト自身が気づいているのに

971 :仕様書無しさん:2015/04/05(日) 11:11:20.66
>>970
ああ、じゃあ今の状態があなたの言う
「終わってる」という状態なんですねw

良かったです。普通は今の状態は終わってるとはいいませんが
今の状態のことだったんですね。

お前がそう思うんならそうなんだろう お前ん中ではな

972 :仕様書無しさん:2015/04/05(日) 11:28:45.36
純粋にインストールベースで比較してもWindowsはまだトップでしょ?
古いOSも込みで卑怯っていうなら、最新の8.1とiOSやAndroidの最新で比較してもいいけどさ

973 :仕様書無しさん:2015/04/05(日) 11:29:53.56
哀れだな。
マイクロソフト自身が逃げろって言ってるのに。

974 :仕様書無しさん:2015/04/05(日) 11:35:32.15
デスクトップは今後もwindowsが主役だろう。
でも開発の場はクラウドに移っている。
だからマイクロソフトも商売の軸足をクラウドに移した。
従ってOSに拘る意味が無い。
実際WindowsAzure上ではlinuxも動く。

この流れで行くと、数年後にはWindowsServerの開発を打ち切るかもしれない。

975 :仕様書無しさん:2015/04/05(日) 11:41:19.22
>>973
お前がそう思うんならそうなんだろう お前ん中ではな

976 :仕様書無しさん:2015/04/05(日) 12:35:45.67
>>973
その発言みせて

977 :仕様書無しさん:2015/04/05(日) 12:51:48.38
>>973
俺も見たい

都合のいいところだけを抜き取るテクニックをw

978 :仕様書無しさん:2015/04/05(日) 12:53:14.71
>>975-977
おまいの自演には飽々だわ。

979 :仕様書無しさん:2015/04/05(日) 12:58:00.57
>>978
ばれたかw
そうだよ。そういう発言はないよw

980 :仕様書無しさん:2015/04/05(日) 13:11:42.64
>>972
特殊用途はおいといて、個人や一般ビジネスではWindowsが多いだろうね。
ちなみに、会社を売上高・会社数で二次元グラフ化すると、IT業界は建設業界と違って、二極分化していない。
つまり、優秀さと普及率との反比例関係が、小企業から大企業まで連続的になっている。
最も多いのは、OS無しの機器関連企業。
2番目がWindows関連。

981 :仕様書無しさん:2015/04/05(日) 13:19:47.59
OSとクラウドの両方を提供している会社が
Microsoftしかないんだよな。

982 :仕様書無しさん:2015/04/05(日) 18:55:53.15
揚げ足取りと後付けで人の意見を腐すことしか出来んのかお前らは

983 :仕様書無しさん:2015/04/05(日) 20:27:43.44
>>981
ちょっと古い記事だが

マイクロソフトがLinuxを「大好き」になった理由とは?[2014年11月06日 06時00分]
http://japan.zdnet.com/business-application/sp/35055935/

984 :仕様書無しさん:2015/04/05(日) 21:02:22.54
>>983
その記事はただ単にマイクロソフトが迷走しているようにしか見えない。

985 :仕様書無しさん:2015/04/05(日) 23:17:50.52
迷走じゃなくてビジネス上の戦略だよw

986 :仕様書無しさん:2015/04/06(月) 23:37:17.20
Microsofotの今の敵はLinuxじゃないよ
Googleだよん
やってること思いっきりかぶってるし

987 :仕様書無しさん:2015/04/07(火) 02:36:02.90
Googleは広告会社なんだが?

988 :仕様書無しさん:2015/04/07(火) 07:53:22.32
実際、グーグルからするとマイクロソフトなんか落ちぶれて、もうIBMコース確定と判断してるだろ

989 :仕様書無しさん:2015/04/07(火) 08:02:51.45
HoloLensとか見てるとマイクロソフトすげーてなるけどな

990 :仕様書無しさん:2015/04/07(火) 08:15:23.14
業界の軸では完全に亡くなった
モバイル落としたのが運命の分かれ道

991 :仕様書無しさん:2015/04/07(火) 09:08:13.03
>>988
> グーグルからすると

(笑)

グーグルからするとお前は浮浪者同然だろw

992 :仕様書無しさん:2015/04/07(火) 13:02:51.84
コンソール使えないお前は虫けら同然な訳だが

993 :仕様書無しさん:2015/04/07(火) 13:09:35.85
むしろMS-DOSのほうが安心する

994 :仕様書無しさん:2015/04/07(火) 19:47:09.63
>>991と実際ルンペンの>>991こと無職winさんが申しています

995 :仕様書無しさん:2015/04/07(火) 19:51:47.33
浮浪者から10円ずつ集めるのがグーグルの商売だよ
だからグーグル社員は俺らに感謝するべき

996 :仕様書無しさん:2015/04/07(火) 20:48:01.29
>>994
そのレスwww
図星だったかwww

997 :仕様書無しさん:2015/04/07(火) 23:00:16.70
ルンペンって方言w

998 :仕様書無しさん:2015/04/07(火) 23:18:54.32
>>997
方言じゃないよ。

古い言葉。

999 :仕様書無しさん:2015/04/08(水) 07:36:21.94
>>997バカすぎw

1000 :仕様書無しさん:2015/04/08(水) 07:37:34.16
このスレは無能の無職winが、馬鹿面さげで無職の分際で書き込んでくるから続きは不要

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

280 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)