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

システム開発体制・開発技法 [無断転載禁止]©2ch.net

1 :
仕様書無しさん
2016/12/25(日) 08:54:48.95
勉強しろ勉強しろっていうけどさ…
そのほとんどが、日本の開発体制だと通用・適用できないじゃん!!!!!
2 :
2016/12/25(日) 09:00:05.43
耳障りのいい流行りのキーワードぶっこんだパワポ作る作業に戻るんだ
3 :
2016/12/25(日) 09:08:09.50
>>1

メリットデメリットを数字にして
真面目に考えると
適用なんてできる場面はない
オサレ開発は雑誌の提灯記事になりやすいが実用性は皆無
4 :
2016/12/25(日) 10:12:56.00
こういう言葉は自分達に適用するためででなく
客に都合よく物事を運ぶためにあるんだよ
言葉も客も使われる側じゃなく使う側になろう
5 :
仕様書無しさん
2016/12/25(日) 10:37:38.22
でもテストの自動化とかやってるところ増えたし、徐々に浸透していくんじゃね?
6 :
2016/12/25(日) 10:55:38.42
テスト自動化すると…
日本以外:納期まで余裕ができ利益も増える
日本:納期が短くなり利益も減る
7 :
仕様書無しさん
2016/12/25(日) 12:39:31.70
これはいろんなスレで指摘されてるね
でも日本初の開発スタイルなんて今の日本のITの体制を見たら世界で笑われるだろ?
8 :
仕様書無しさん
2016/12/25(日) 13:37:49.54
>>5
仕様がネジ曲がって伝えられてる
9 :
仕様書無しさん
2016/12/25(日) 15:51:38.24
>>8
これ
これがダメだとテスト無意味
10 :
2016/12/25(日) 20:21:49.53
>>5
そもそもテストの自動化コードが正しいことを誰が証明できようか?
そしてそれを作るコストは明らかに本体を作るより高い
プログラマをタダでこき使える時代はもう終わったんだよ
11 :
2016/12/25(日) 20:24:10.01
it業界が3kどころではすまないという事実は世間に浸透し過ぎた
いまだと真面目に土建屋のバイトのが給料高い
12 :
仕様書無しさん
2016/12/25(日) 20:52:31.74
日本のプログラマは全員首にして
一度業界を作り直さないとだめ
13 :
2016/12/25(日) 21:45:28.02
>>12
同じ奴が作り直して元の木阿弥に1票
14 :
2016/12/25(日) 22:07:26.34
>>10
> そもそもテストの自動化コードが正しいことを誰が証明できようか?

それを言ったら、

  そもそも手動でやったテストが正しいことを誰が証明できようか?

って話になるだろ?


正しいことを証明するのは、自動化とは関係ない。それはどちらでも必要なこと。
自動化で解決するのは、行ったテストを「完全な形で記録できること」と「再実行なこと」だよ。

手動で完璧にやりました!っていってもその証拠が残ってないとだめだろ?
(スクリーンショットは最終結果しか残らないから証拠にはならない)
15 :
2016/12/25(日) 22:16:51.38
テストの自動化をしたとしても
エクセルとかに日本語で書いた文章をコードに
置き換えてるようじゃだめなんだよな。

正しくコードに置き換えられているか?という問題が発生する。
だから、テストコードが唯一のテスト仕様書でなければならないし、
そのテスト仕様書(=テストコード)を読めなければいけない。

テスト仕様書を書く人も読む人もね。

ってことで当たり前のことになるんだが、
テストに関わる人は技術者でなければいけないんだよ。

そうすると上流がテスト仕様書をエクセル作って〜
上流だからコード読めなくていいんだ〜とかいいだす。

はぁ。日本だめだわw
16 :
2016/12/25(日) 23:50:00.82
テストの自動化=下請けに丸投げ

日本はすでに完全自動化できてるじゃん
17 :
2016/12/25(日) 23:53:10.61
>>16
そういうのは自動化って言わないんだよ。

自動運転=タクシーとか言うつもり?w
18 :
2016/12/25(日) 23:57:53.26
>>15
意図とコードを分離しておかないと
コードの修正が不可能になってしまうんじゃないか?

仕様書(=コード)をリファクタリングしたいとき
そのリファクタリングが正しいことの担保をどうするの?
テストコードをリファクタリングするときは?
テストコードに対するテストコードを書くのか?
19 :
2016/12/26(月) 00:04:35.07
> 仕様書(=コード)をリファクタリングしたいとき
意味がわからん。

リファクタリングは動きを何も変えない修正のことを言うんだよ。
矛盾してる。


> テストコードに対するテストコードを書くのか?
書かねーだろ?

お前、エクセルに書いたテスト仕様書の
テストをどうやってるんだよ?

仕様書が正しいことのテストは?
それと同じなんだが。
20 :
2016/12/26(月) 00:52:14.62
>>19
実際に動きが変わってしまったらどうするの?
逆の言い方をすると、どうやって変わってないと言い切るつもりなの?
リファクタリングは何も変わらない修正じゃない
変えない修正なんだよ
ソースを見ただけじゃ「変えない」ってのは不可能なんだ

いや、不可能って言い方だと納得しないかもしれないから言い換えると
無駄な時間がかかるんだよ
++1を1++に変更したとしよう
見た目を変えるありがちなリファクタリングだ

な、これだけの情報だと何も変わってないかどうかは「場合による」としか言えないだろ?
21 :
2016/12/26(月) 00:55:37.10
ちなみに想定してるのは
func hoge(a)
++a
return a

ぐらいの話な
一部表現に変なところがあったとは思うが意図は通じただろうか?
22 :
2016/12/26(月) 01:11:15.88
>>20
> 実際に動きが変わってしまったらどうするの?
> 逆の言い方をすると、どうやって変わってないと言い切るつもりなの?

自分の胸に手を合って考えればいいじゃん?

お前は仕様書かテストかしらんが、日本語で書いているんだろ?
その日本語を修正するとき、どうやって意味が変わってないと言い切るつもりなの?

そもそもそれを読んだ人すべてが同じ意味で捉えるとどうやって
言い切るつもりなの?

できないよな?

まず反論の前に、こうすればできるって言うものを言いなさいよ。
23 :
2016/12/26(月) 01:13:09.00
>>20
> 見た目を変えるありがちなリファクタリングだ
それは見た目を変えるリファクタリングじゃない。


> な、これだけの情報だと何も変わってないかどうかは「場合による」としか言えないだろ?
実際にはこれだけの情報しか得られないことはないので意味がない。
24 :
2016/12/26(月) 08:22:47.43
仕様の利ファクタリング
人はそれを仕様変更と言う
25 :
仕様書無しさん
2016/12/26(月) 12:13:34.28
>>10
なるほど、今は手動テストのためにSEをタダでこき使える時代なんだな。
26 :
仕様書無しさん
2016/12/26(月) 12:55:13.06
リファクタ馬鹿がマ板にはいるんだから相手にすんなよw
27 :
2016/12/26(月) 14:54:22.70
自動テストコードの仕様書は絶対必要になっちゃうよね
組んだ人間以外絶対わからんわ
28 :
仕様書無しさん
2016/12/26(月) 15:05:16.10
>>27
普通は仕様書書くか、既存のフレームワーク使うだろ。
29 :
仕様書無しさん
2016/12/26(月) 21:23:18.07
客側に回って思った。

検収・納品時のテスト期間をもっとくれ。
納品日=最終検収日
とかふざけんな。
30 :
仕様書無しさん
2016/12/26(月) 21:52:01.54
自動テストコードの仕様書www

ジャップの開発糞ワロタ
31 :
2016/12/26(月) 22:32:18.31
>>30
少なくともそれがないと手を入れるにしても俺は動けないと思うが、お前はどう行動するのか教えてくれ
32 :
2016/12/26(月) 22:40:24.38
>>31
自動テストコードの仕様書が正しいことを
どうやってテストしてるの?
33 :
2016/12/27(火) 07:40:12.02
仕様が最初からないんだy
34 :
仕様書無しさん
2016/12/27(火) 08:26:32.45
>>29
全然要望の品ではないって現場でバレて拒否されちゃうじゃん
35 :
2016/12/27(火) 10:24:51.38
>>33
仕様がないなw
36 :
2016/12/27(火) 19:09:06.27
>>29
うるせぇ
検収入ってからクリティカルな後だし要件追加すんなうんこ
37 :
2016/12/27(火) 19:24:57.52
テストの自動化っていうのはテスト仕様書を手作業でやっていたのを
その手作業をマクロで保存して再生するとか、スクリプトで自動実行するとかのことだよね?
それとも単体テストのことを自動化っていってるの?
38 :
2016/12/27(火) 19:37:15.75
>>37
日本語で書いてくれ
39 :
仕様書無しさん
2016/12/27(火) 21:17:57.46
>>36
最初っから言ってんのにハンコ押した仕様書とちげーの下に配ってんじゃねー!
40 :
2016/12/27(火) 21:23:45.99
>>37
とりあえずJUnitやRSpecとか見てみたら?

あなたの質問は例えるならば、
「バイオリン演奏は手で弾くのか?何か道具を使うのか?」
そんな初歩の質問です
41 :
2016/12/27(火) 22:07:28.98
>>37
> テストの自動化っていうのはテスト仕様書を手作業でやっていたのを
> その手作業をマクロで保存して再生するとか、スクリプトで自動実行するとかのことだよね?

そういう考えでいると失敗する。

なぜなら人間は優秀なので、どんな難しいことでも時間をかければ手作業でやれてしまうから。
複雑な手作業をそのまま置きかえるとマクロも複雑になりテストがメンテナンスできなくなる。

まずテストの自動化の前提として普通はテストの見直しという工程が必要
大ざっぱに書かれていてマクロで保存したくなるような長いテスト仕様書を小さく分ける。
大部分なテストをシンプルな単体テストで終わらせて、手作業でやっていたであろう
シナリオがあるような長いテストは正常系を通せば十分なレベルにまで持っていく

それを実現するにはコードも小さなテストが可能なように設計する必要がある。
例えば数百行もあるような関数はテストできない

テストの自動化っていうのは、テストを自動化することではなくて
テストのメンテナンスがしやすいようにシンプルなコードにするという作業

?テストを自動化する
○テストを自動化できるようにコードを修正する

もちろん最初からテストを自動化できるようなコードになってるのならば、
あとはテストを自動化するだけなんだが、そうなっていることはまずない
42 :
仕様書無しさん
2016/12/28(水) 15:06:41.85
自動化するために手動よりも遥かに多くの労力が必要
ってパターンも多々あるよねw
43 :
2016/12/28(水) 15:14:39.20
継続的なプロダクトでもないのに、コストかけて自動化するのはただのバカだ。
だが自動化の自己満足度は高いので、使い捨ての自動化でも手動のときの1.2倍
くらいのコストまでだったら許す。
44 :
2016/12/29(木) 01:50:23.56
>>42
本来はテストを自動化することと
コードを正しく設計してメンテナンス性を上げることは
まったく別のことなんだけどね。

テストの自動化以前にできていなければいけないこと

だからその「遥かに多くの労力」というのは
テストの自動化のための労力ではなくて
低い技術力を最低ラインにまで上げる労力
45 :
2016/12/29(木) 01:51:33.77
>>43
コードが正しく設計されているのなら、
手動のときのコストよりも下がるよ。

ただ、コードを正しく設計するのは
ただの馬鹿だと言われるとそれはおかしいと思うがね。
46 :
2016/12/29(木) 08:40:44.62
>>45
正しいの定義に疑問が残るね
俺が気に入らないからこのコードは間違ってるとか言い出しそうお前
47 :
仕様書無しさん
2016/12/29(木) 08:42:58.57
そもそも客の要望が正しく伝わってない
48 :
2016/12/29(木) 09:11:27.31
おまえらって手動テストだと要所だけテストするのに
自動テストだとカバレッジ100%を目指すよね
49 :
仕様書無しさん
2016/12/29(木) 09:20:00.96
検収テストの期間をもっととればいい。
もしくは仮運用試験期間を1年くらいとる。
50 :
仕様書無しさん
2016/12/29(木) 11:31:36.60
ユーザー様のテストを受けたら納品が出来ない
だって注文の品じゃないんだもの
51 :
2016/12/29(木) 12:26:58.46
>>46
> 正しいの定義に疑問が残るね
> 俺が気に入らないからこのコードは間違ってるとか言い出しそうお前

そんなのコードメトリクスツールを使えば
客観的に判断できるじゃん。
52 :
2016/12/29(木) 12:33:44.70
>>48
> おまえらって手動テストだと要所だけテストするのに
> 自動テストだとカバレッジ100%を目指すよね

自動テストとカバレッジ(レポート)というのは関係があって、
カバレッジレポートを出力するには、テストコードがなければできない。

手動テスト、つまりカバレッジレポートがない状態でどうやって100%を目指す?
自動テストだとカバレッジレポートでテストしてない所が簡単にわかるから
100%目指すのも難しくないが、カバレッジレポートがなければどこをテストしたかしてないかわからない。

手動テストは要所だけテストしてるんじゃないんだよ
思いついたところだけテストしているだけ。
カバレッジがわからないから抜けがたくさんあるし、
レポートもないから今何パーセントかもわからないというだけ
53 :
2016/12/29(木) 16:43:24.20
>>51
あんなのコードが長いか短いかしかみてないだろ
54 :
2016/12/29(木) 21:04:44.42
>>53
コードの長さを見てるんじゃないよ。
長くても処理が一直線ならば問題ない
文字書くても条件やループが多すぎて複雑ならだめ
55 :
2016/12/29(木) 22:30:22.72
>>54
いややってみた感じそんな風にはなってない
長いか短いか
56 :
2016/12/30(金) 02:39:11.08
>>55
じゃあ使用しているコードメトリクスの計算方法言ってみ
何を計算しているかちゃんと書いてあるからさ
57 :
2016/12/30(金) 08:07:14.60
>>56
デフォルトのまんま
58 :
2016/12/30(金) 12:07:29.47
>>57
コードメトリクスの計算方法を聞いてるのに
その答えは、やっぱり知らないってことじゃんかw
59 :
仕様書無しさん
2016/12/30(金) 13:11:33.56
>>58
いま一生懸命検索している
60 :
2016/12/30(金) 13:53:16.15
テスト以外にネタないかね……
61 :
2016/12/30(金) 15:45:09.62
>>58
だからデフォルトのまんま
62 :
2016/12/30(金) 15:55:28.48
>>61
じゃあそのデフォルトの値言ってみ。
63 :
仕様書無しさん
2016/12/30(金) 15:58:17.81
>>60
だってそれ以外は全部日本では適用不能なんだもん
64 :
2016/12/30(金) 17:29:06.64
>>62
しらね
いじってないから
65 :
2016/12/30(金) 18:03:28.47
やっぱり知らないってことじゃんw
66 :
2016/12/30(金) 18:05:31.32
? いじってないから知らね
○ 無知だから知らね

いじってないくても調べることはできるので
知らない理由にはなりません。
67 :
2016/12/30(金) 18:05:48.76
×
68 :
2016/12/30(金) 19:13:26.91
富国生命、AI導入で査定部署の人員の約3割にあたる34人を削減
http://news.tv-asahi.co.jp/news_economy/articles/000091183.html
どんどん無人化されていく
69 :
仕様書無しさん
2016/12/30(金) 21:32:26.36
>>68
それってただの業務系システムとどう違うの?生保じゃないけど
そういうの判定するシステム作るPJやったことあるから違いが気になる。
70 :
仕様書無しさん
2016/12/30(金) 21:35:38.21
>>1
サッカーの戦術と同じで優秀なメンツを揃えないと火を噴くだけだからな
71 :
仕様書無しさん
2016/12/30(金) 22:04:53.70
>>69
派遣で一部のパーツ作るのは「やったことある」とはいわないぞ
設計から全部やって初めて「やったことある」って表現しろ
72 :
2016/12/30(金) 23:02:40.76
>>69
「こんな簡単なことも分からないのかね、ワトソン君」

これは酷いwww
73 :
仕様書無しさん
2016/12/30(金) 23:08:11.35
>>71-72
なんだ、お前達も分かんないのか、レベル低〜
74 :
仕様書無しさん
2016/12/31(土) 07:24:23.11
>>71
これスレ立ててもいいよね
これでマジでスキルアップや業界経験したと思ってる派遣多すぎ
75 :
仕様書無しさん
2016/12/31(土) 10:53:50.95
>>69だけどマジで教えてほしい
76 :
仕様書無しさん
2016/12/31(土) 14:15:57.23
偽装請負多重派遣業界SEと離婚
両親や親戚に反対されましたが、高稼働低収入業界のSEと結婚してしまい、耐えきれず中絶と離婚をしました。
今は別業界の相手と結婚して幸せです。
・常識がない
・モラルがない
・モテない
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・ITスキルが高いほど貧困
・高度情報技術者ほど貧困
・会社員なのに短勤続年数
・人手不足なのに無職意識
・人手不足なのに低収入
・高生産なのに低収入
・高利益なのに低収入
・高需要なのに低収入
・多学習なのに低収入
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・偽装請負多重派遣損害なのに稼働
・裁判官が技術判定不能で賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://potato.2ch.net/test/read.cgi/bizplus/1479096711/
77 :
仕様書無しさん
2016/12/31(土) 15:42:21.97
>>75
いや、お前はなりすまし。
でも俺も知りたい。
78 :
2016/12/31(土) 15:46:08.49
>>77
いや、お前はみずすまし。
でも俺も知りたい。
79 :
2016/12/31(土) 19:47:59.95
>>77

>>69(の質問について)だけどマジで教えてほしい(俺も知りたい)

別になりすましするつもりはなかった
誤解スマソ
80 :
仕様書無しさん
2017/01/01(日) 09:08:46.23
>>1の指摘は事実
81 :
仕様書無しさん
2017/01/01(日) 21:25:10.38
日本のプログラマの勉強しろは無視していい
どーせ新しい環境と言語のこと言ってるだけだから
82 :
2017/01/01(日) 22:20:06.05
プログラマ「勉強しろよ」
バカ「日本のプログラマの勉強しろは無視していい」
バカ「どーせ新しい環境と言語のこと・・・」
プログラマ「設計とテストと保守性の話に決まってるだろ」
バカ「うるせばーか。勉強なんてしねーよ」
83 :
2017/01/01(日) 22:20:10.50
日本のプログラマはJavaとVB.NETとPHPぐらいしか使わないのに
どうして色んな言語を覚えようとするんだろうね
仕事で使う言語すらまともに扱えていないのに・・・
84 :
2017/01/01(日) 22:22:11.16
バカ「どーせ新しい環境と言語のこと言ってるだけだから」

プログラマ「お前は今使ってる環境と言語すらつかえねーよな」
85 :
2017/01/01(日) 22:22:48.52
>>83
仕事で使う言語ぐらい勉強しろよ?
86 :
仕様書無しさん
2017/01/02(月) 10:15:30.95
>>82
設計テスト保守性いずれも流行の手法・工法が日本の開発スタイルでは適用不能
それを>>1が指摘してるんだが?
>1のほうが、お前よりも、それらについて一度は勉強して考えたって証拠だよ
87 :
仕様書無しさん
2017/01/02(月) 10:16:33.69
>>83
圧倒的多数が派遣プログラマという奴隷状態だから
派遣は派遣先の言語を使えないといけない

だから日本では新言語の勉強が最重要という愚かな思考になる。ならざるを得ない。
88 :
2017/01/02(月) 10:57:29.70
言語っていうかライブラリの使い方だな
89 :
2017/01/02(月) 23:02:56.84
派遣ってだいたいJava、PHP、VB.NET、C#あたりじゃないかな
あとデータベースまわりも知識があれば尚良し
フレームワークも必須だけどだいたい言語ごとに定番あるからね
歳とるとリーダー経験が問われる

新しい言語って覚える必要ある?派遣で投入される現場でまず新しい言語って使わないと思うけど・・・
WEB系だと話が変わってくるけどさ
90 :
2017/01/03(火) 01:51:49.58
> 派遣ってだいたいJava、PHP、VB.NET、C#あたりじゃないかな

なんで派遣に限ってるの?

派遣先にも正社員いるだろ?
その正社員がJava、PHP、VB.NET、C#使うから
派遣も同じものを使うんだよ。
91 :
仕様書無しさん
2017/01/03(火) 02:39:20.26
>>89
.NETの進化は早いよ。割りと多くの企業がついていってない。
あと上流工程は社員がやるべき。
92 :
2017/01/03(火) 08:01:24.46
>>91
上流と下流を無駄に分けても上手くいかない
上流で決めるべきことを決めてくれないと下流で動けない
企画や販売計画ぐらいは社員がやるべきだけど要件定義からはプログラマに任せたほうがいい
93 :
仕様書無しさん
2017/01/03(火) 08:04:33.16
>>91
上流工程を社員がやるのは当然
つーか振るわけがないだろ
もし振るようなところがあれば糞会社だわ

会社の業務を派遣なんぞに教えるのに数年の代金を支払うとかありえないし。
94 :
仕様書無しさん
2017/01/03(火) 08:05:35.49
>>90
日本のプログラマの大半が派遣・偽装請負派遣社員だからだろ
派遣先の正社員は言語は最重要ではないから。
95 :
2017/01/03(火) 08:05:51.72
下流風情は無理だった企画設計を上流がやってみせる [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1483398324/
96 :
2017/01/03(火) 08:08:02.26
>>94
言語は重要でなくても、
そこから生み出されるシステムは重要でしょ?

で、重要なシステムの開発を
なんで派遣に委ねてるの?
97 :
仕様書無しさん
2017/01/03(火) 08:19:33.13
>>96
は?人手が必要なら外部の人員を招集して使ってもなんの不思議も無いだろ。
98 :
2017/01/03(火) 08:31:43.67
>>97
なんで外部の人間に合わせて、自分たちが
使う言語を変えるの? 逆だよね。
99 :
2017/01/03(火) 08:32:46.95
人手が必要なら、正社員を雇えばいいじゃない?

本当は金が無いだけだろ?
100 :
2017/01/03(火) 09:51:43.58
金がないというか、派遣なら必要なくなれば切ればいいだけなので
金と不要要員維持リスクの節約だな。
101 :
2017/01/03(火) 10:49:49.00
>>98
おまえ流れを理解してないだろ
派遣の人は、正社員が使っているJava、PHP、VB.NET、C#言語のいずれかを使うことになるので全部覚える必要がある。よって派遣は言語勉強最優先。
社員はJava、PHP、VB.NET、C#のうちその会社で使っている1つをとりあえず使えればよく、新言語を覚えることは再優先事項ではなく、手が空いた時に修得すればよい程度。
102 :
2017/01/03(火) 10:50:55.58
>>99
あほすぎw
>>100のいうとおり、その開発が終わったらあとは一人でもこなせるから人員があまる。よって不要な時期は人を調整する。
そのための派遣だろが。
103 :
2017/01/03(火) 14:59:08.57
>>102
それってシステム開発を外注しているのと何も変わらないよね?
そんなんじゃ社内に開発のノウハウがたまらないよ。
104 :
2017/01/03(火) 15:06:08.42
日本のシステム開発の成功が「運」だのみになるわけだよねw

技術力が高い人が派遣されてくるかどうかでシステム開発の成功が決まる。
人を育てるという考えがない。育てた人を手放さないという考えがない。

全ては派遣にかかっているw
105 :
2017/01/03(火) 15:19:54.60
でもそういうのって販売戦略の時点で考えるものであって社内のノウハウや技術力なんて純利益に直結しないよ
長い目で見ることが出来なくなったというか長い目で見ることが利益に繋がらないことがわかっちゃった結果が今なんだよ
106 :
2017/01/03(火) 15:30:59.29
開発が追いつかなくてバグだらけで苦労してるくせに何言ってるんだ?
107 :
2017/01/03(火) 15:46:35.04
つーか派遣に可読性が高いコードなんてかけるか?
それ社員以上の能力だぞw
108 :
2017/01/03(火) 15:55:01.03
自社の技術力が低くて(高い人がいてもスグ逃げてしまう)
派遣に頼ってる所って普通に多い
109 :
2017/01/03(火) 15:58:46.98
あるプロジェクトで優秀だった人は
他のプロジェクトでも優秀である。

人は成長する。

という当たり前のことを知っていれば、
プロジェクトごとにリセットすることの
損失が理解できるはずなんだけどねぇ
110 :
2017/01/03(火) 17:51:46.84
>>103
相当バカだろw
システム開発の主軸部分は全部結局社員がやってんだからノウハウ残るに決まってるだろが。
派遣に依頼しているのは、単純なパーツやデバッグやらテストデータの作成やら操作説明書の作成やら時間が地味に取られる作業等々だ。
111 :
2017/01/03(火) 17:58:19.58
>>110
派遣の募集要項みてみ。
そんなこと書いてある所はごく僅かだから。
112 :
仕様書無しさん
2017/01/03(火) 19:22:38.02
>>110
なんでもかんでもそうやって抱え込むから
社員は残業しまくりなんだよ。
ざっくりしたクラスを書いといてそれをテンプレートにして
派遣に振れば似たような大量のクラスも
書いてくれるよ、
お前一人で抱え込む必要はない。
113 :
2017/01/03(火) 19:57:58.88
>>110
社員が出来なさ過ぎて全体の技術力がいまいち
マネジメントはできるけど、肝心のコードが書けない
で、仕方なく派遣を雇ってるケース結構あるよ
仕様とスケジュールは決めるけど、後は派遣におまかせ状態
114 :
2017/01/06(金) 00:52:26.51
上流は技術者気取り
それで、日本で出来てるのは何?
某銀行の時期システム?
これが日本の業界をよく表してる
投げまくりで利益に繋がるどころかお金が飛んでいくという
115 :
仕様書無しさん
2017/01/06(金) 06:43:11.19
日本で働くな
無能になる
116 :
仕様書無しさん
2017/01/06(金) 12:55:40.66
>>114
下があほすぎっからじゃね?
117 :
仕様書無しさん
2017/01/07(土) 21:18:09.92
開発スタイルを研究してる連中が内製でやってるとこのエンジニアだからな
日本スタイルの開発体制の論文でも作らないとな
118 :
2017/01/07(土) 21:52:12.58
web系は俺一人体制。
コーディング規約なし、バージョン管理なし、すべて自由ですでにプログラミング3ヶ月突入よ。
119 :
仕様書無しさん
2017/01/08(日) 08:12:23.70
偽装請負多重派遣業界SEと離婚
両親や親戚に反対されましたが、高稼働低収入業界のSEと結婚してしまい、耐えきれず中絶と離婚をしました。
今は別業界で結婚障害残業のない共働きしやすい相手と結婚して幸せです。
・常識がない
・モラルがない
・モテない
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・ITスキルが高いほど貧困
・高度情報技術者ほど貧困
・会社員なのに短勤続年数
・人手不足なのに無職意識
・人手不足なのに低収入
・高生産なのに低収入
・高利益なのに低収入
・高需要なのに低収入
・多学習なのに低収入
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・偽装請負多重派遣損害なのに稼働
・裁判官が技術判定不能で賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://potato.2ch.net/test/read.cgi/bizplus/1479096711/
120 :
2017/01/08(日) 23:19:21.92
>>118
バージョン管理なしが信じられん
121 :
2017/01/10(火) 02:54:31.16
工場の生産技術担当
普段はシーケンサとタッチパネルとC#とMYSQLとExcelVBA
で日曜大工的DIYなプログラムやってる
作った後から操作手順書作る程度なんで
世間一般の要件定義書とか設計仕様書とか見たこと無い
参考までにどういうものか誰か見せて♪
122 :
2017/01/10(火) 03:57:52.40
なんで2chに書き込む前にググらなかったの?
123 :
2017/01/10(火) 07:40:46.92
でも俺もそれはまともなもの見たことないね
124 :
2017/01/11(水) 00:16:45.28
まあ他所がどんな風に書いてるかどこも知らんからなあ

つまんねえ技術しか持ってない所ほど秘密にしたがるよな
125 :
仕様書無しさん
2017/01/15(日) 09:06:15.16
偽装請負多重派遣業界SEと離婚
両親や親戚に反対されましたが、高稼働低収入業界のSEと結婚してしまい、耐えきれず中絶と離婚をしました。
今は別業界で結婚障害残業のない共働きしやすい相手と結婚して幸せです。
・常識がない
・モラルがない
・モテない
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・ITスキルが高いほど貧困
・高度情報技術者ほど貧困
・会社員なのに短勤続年数
・人手不足なのに無職意識
・人手不足なのに低収入
・高生産なのに低収入
・高利益なのに低収入
・高需要なのに低収入
・多学習なのに低収入
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判定不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://potato.2ch.net/test/read.cgi/bizplus/1479096711/
126 :
2017/01/20(金) 20:58:24.89
外注が作ったコードを
外注がメンテして、また
外注がメンテして
ってやってるうちに、可読性が低い保守に工数がかかるシステムが出来上がりました。
そしてその間、中の社員はコードを書くことがなかったためスキルが上がらず、さらにどうしようもできないコード群になってしまったため、どうにもならなくなりました。
127 :
2017/01/21(土) 01:37:08.86
>>126
まだその程度なら筋肉で解決できる
128 :
仕様書無しさん
2017/01/27(金) 20:04:24.53
俺が偽装請負多重派遣業界SEを辞めて人売りやる理由

・人売りは大儲けだから家族に奉仕できる
・SEは結婚障害者だから家族に迷惑かかる
・SEの大半は料金以上に無能開発してくれる
・SEの大半は多重派遣を訴えない
・SEを多重派遣すると責任問題を誤魔化せる
・SEを人身売買しても民事不介入の警察に捕まらない
・SEに機密誓約させるから不法行為は警察や裁判官に隠せる
・SEに分量以上の作業強要しても開発内容がわからない警察や裁判官を騙せる
・SEに料金以上の作業強要しても開発内容がわからない警察や裁判官を騙せる
・SEに契約以外の作業強要しても開発内容がわからない警察や裁判官を騙せる
・SEの鬱病や過労死も立証困難で警察や裁判官を騙せる
・SEの報酬を強奪しても立証困難で警察や裁判官を騙せる
・システム未完成のせいにして立証困難で警察や裁判官を騙せる
・偽装請負に従うSEに制裁を与えられる
・結婚相手を苦しめるSEに制裁を与えられる

何よりもプログラム作らないで大儲けできるからな
129 :
2017/01/28(土) 23:42:15.12
>>126
>可読性が低い保守に工数がかかるシステム
新規を外注で安く作っている
保守費用は固定
つまり、発注元は何も損をしていない

>中の社員はコードを書くことがなかったためスキルが上がらず
未来永劫、コードを書くことは無いのでスキルがないことは問題にならない

視点が新卒プログラマの愚痴レベル
もしくはWEB系からSI系に転職した中途採用の感想文
130 :
仕様書無しさん
2017/01/29(日) 08:38:06.12
偽装請負多重派遣業界SEと離婚
両親や親戚に反対されましたが、高稼働低収入業界のSEと結婚してしまい、生活困難で中絶と離婚をしました。
今は別業界で結婚障害残業のない共働きしやすい相手と結婚して幸せです。
・モラルがない
・モテない
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・ITスキルは使い捨て
・ITスキルが高いほど貧困
・高度情報技術者ほど貧困
・会社員なのに短勤続年数
・人手不足なのに無職意識
・人手不足なのに低収入
・高生産なのに低収入
・高利益なのに低収入
・高需要なのに低収入
・学習多いのに低収入
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判定不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://potato.2ch.net/test/read.cgi/bizplus/1479096711/
131 :
仕様書無しさん
2017/01/29(日) 09:04:09.03
>>162
それ某銀行のこと?
132 :
2017/01/29(日) 09:09:23.76
多くの外注システムのところが>>126になってて
仕様の把握はプログラムから・・・。
ってパターンになるから、どんどんめちゃくちゃになっていくんだよな。
設計時:内製
開発時:内製+一時的な派遣
運用時:内部オペレーター3名
でいいんだよな
133 :
仕様書無しさん
2017/01/29(日) 20:19:47.93
>>126
元請けはエクセルで工程表管理できれば
プログラム知識なんて全く不要だし
時間の無駄

元請け会社の求人じゃ
プログラム経験なんて全く問わないよ
134 :
2017/01/29(日) 22:59:28.99
126です。

某銀行ではないです。

結果として、重複コード・重複ロジックが多数存在することになりました。
で、大規模な既存システムへの対応が必要なときに、工数が増大するわけなんです。コード変えたらテストが必要なので。
情報システム部からグループ本体への対応予算回答時に、対応資源数を根拠に人月工数で回答するので、なんでこんなに毎回工数がかかっちゃうの、って言われるわけです。
中の上の人は、ガリガリコードを書くわけではないけども、根拠を精査するためには最低限のプログラム知識が必要なわけです。
これはグループで問題となり、内製できるように基盤を整えるよう方針が出されました。具体的には、中の人と外注の比率を大きく変えれるよう、若い男社員をたくさん採用して、将来的には外注と置き換えれるようにと考えてるみたいです。
135 :
2017/01/29(日) 23:03:26.28
>>134
リファクタリング待ったなし
136 :
2017/01/29(日) 23:07:43.02
修正にコストがかかるシステムとコストがかからないシステムがあります。
これはコストがかかるシステム

そして "あなたが" 修正にコストがかかるシステムで
OKといったんですよ。検収でOKだしたでしょう?

え? プログラム読めないから修正にコストがかかるかどうか判断できない?
えぇ(笑)無知はぼったくられるのが世の常ですよ(笑)
137 :
2017/01/30(月) 19:50:55.06
内製人員増強とともに、リファクタリングも少しずつ進めています。
ぼったくりも含め、いろんな外注さんの言うがままにやっていた結果、このような状況になってしまった、という反省もあるので、改善しようという考えです。
成果がでるには、まだまだ時間がかかるとは思いますが。
138 :
2017/01/30(月) 20:38:11.76
内製って要するに必要なものをその場で作るのが肝ってことでしょ?
外注への予算のつけ方をちょっと変えるだけで似たようなことが実現できるんじゃないか
139 :
仕様書無しさん
2017/01/30(月) 20:48:38.72
>>138
詐欺師の手口を知るってこと。

偏差値40にも満たないやつが9割以上のプログラマ業界
そんな奴らに作れるのに、先入観から作れないと思って、言いなりの金払う
というバカな行為からの離脱
140 :
2017/01/30(月) 21:36:16.30
プログラムはかんたんに水増しできる。

ある処理と似たようなことことをしていれば
すぐにコピペすればいい。

コードが二倍になるだけじゃない。

コードのレビューのコストも二倍、
テストのコストも二倍、修正にかかるコストも二倍

あっという間にコードを膨れ上がらせることができる
言い換えるとコストを膨れ上がらせることができる

湯水のように金を出してくれる会社を見つければ、
あとはちょろい商売やでw
141 :
2017/01/30(月) 21:55:36.36
「ステップ数どれくらい?」 (笑)
142 :
2017/01/30(月) 22:07:49.38
LINQ涙目やな
143 :
2017/01/31(火) 00:30:14.11
>>140
ハイ、ダウト
コピペでコードは二倍になっても仕様に変化が無ければテスト数は変わりません
144 :
2017/01/31(火) 00:44:14.97
>>143
変わるよw

全く同じモジュールを別々の人が作ったと考えればいい。

モジュールが一つしかないのであればテストは一つでいいが、
別の人が作ったものがあればそっちもテストをする必要がある。
145 :
2017/01/31(火) 00:56:15.84
>>144
変わんねーよ
算数もできないのかよ
そもそもテメーは何に基づいてテストすんだよ
146 :
2017/01/31(火) 00:58:31.40
>>144
処理Aから呼んだときと処理Bから呼んだときと共に正しい動作をすることをチェックするにはどうしたらいい?
147 :
2017/01/31(火) 01:16:12.79
ソースコードからテスト仕様書を作ったときはコピペで変わるけど
設計書から作ったときは変わらないよね
148 :
2017/01/31(火) 02:04:19.54
>>146
標準ライブラリがあって、
処理Aから読んだときと処理Bから
読んだときがあったとしても

標準ライブラリはすでにテストされているから
テストしないですむよね
149 :
2017/01/31(火) 02:12:41.17
>>147
普通はテストが減るように設計をするのでね。
言い換えるとモジュールを再利用するように設計する。

お前が見てるのは処理を重複させてしまっている
無駄が多い設計ってこと。設計そのものが違ってる。
150 :
仕様書無しさん
2017/01/31(火) 08:15:47.15
技術を安く売ってはならない理由

・偽装請負多重派遣中間搾取の業界損害がある
・契約外期限遵守の業界損害がある
・客先指示遵守の業界損害がある
・知的財産譲渡の業界損害がある
・時間外労働違反の業界損害がある
・低予備工数見積の業界損害がある
・残業見積の業界損害がある
・無料追加の業界損害がある
・学習不足の業界損害がある
・裁判苦手の業界損害がある
・対人障害の業界損害がある
・健康障害の業界損害がある
・技術者使い捨ての業界損害がある
・孤独死の業界損害がある
・低収入の業界損害がある
・低技術の業界損害がある
・非婚離婚多数の業界損害がある
・鬱病早死多数の業界損害がある
151 :
2017/01/31(火) 08:17:39.92
>>143
関数が1つだったのが2つになったらテストコードは2倍必要
つまり、関数は少なければ少ないほどテスト工数を削減できる
152 :
2017/01/31(火) 08:19:13.85
コピペの場合はコピペがあってるかどうかのテストが必要
モジュール再利用の場合は少なくともモジュール単位まではテストを省ける

コピペと再利用は大きく違う
153 :
2017/01/31(火) 08:29:32.17
>>151
だからそれはソースコードからテスト仕様書を作った場合でしょ?
普通はそんなことしないんだよ
154 :
2017/01/31(火) 09:37:21.22
>>153
ソースコードは設計書から作る

コピペが発生するというのは、設計書の時点で処理がコピペされているか
設計書に何も書かれていない(からソースコードをコピペする)
のどちらか

どちらにしろ設計に問題があるということで
コピペをしないということは設計を修正することにほかならない

テストが減るように設計するのだから、テストコードの数は減る
155 :
2017/01/31(火) 09:43:14.66
もし設計がテストが減るように考慮されていないのであれば
それは設計能力が足りないということ

また設計にコピペがないのに、ソースコードにコピペがあるのであれば
それはソースコードのレビューがされていない

ソースコードがコピペされるのを前提としてテスト仕様書を作るのであれば
それはテスト工数の無駄があるということ

逆にコピペされてしまっているのにコピペされないのを前提とした
テストを行っているのであれば、それはテスト漏れというよくある問題が発生する。

これは本来はソースコードの問題であるがテスト漏れと言ってしまうことで
テストが足りない、テストを追加しよう。ということになって
テストの数が増えてしまう。
156 :
2017/01/31(火) 19:42:00.16
>>153
仕様書・設計所に対してテストを作成する
そんな教科書通りの現場なんてどこにもないんだ

ソースが仕様という主張が大勢を占めたとき
逆にテストコードも仕様だということになる

つまり、テストはソースを見ながら作成され
ソースのごきげんをとるようなテストしか作成されなくなる
157 :
2017/01/31(火) 21:19:58.90
例えばあるGUIアプリがあったとして、画面の上のexportボタンを
押すと内部データをファイルに出力する機能があったとする

昔のVBプログラムのようにボタンのclickイベントに
ファイルに出力するコードがずらっと書かれている

これをウインドウのメニューバーからも行いたくなった。
この時、メニューアイテムのclickイベントに
ボタンのclickイベントの内容をコピペしたとする

コピペした最初は全く同じかもしれないがある時修正が必要になり
ボタンの方だけ修正してしまったとする。そしてボタンだけをテストしていたら
当然メニューバーから実行したときバグとなる。

このことからもわかるように、コピペするとテストが二倍になってしまう。
だからコピペをしてはいけない。

そしてもし同じ機能をボタンとメニューバーの両方から実行できるとき
コピペしてなくても、この2つを同じようにテストしないと行けないと
思っているのであれば、それはテスト工数の無駄。他に優先すべきテストがある。
両方やってるから真面目ということにはならない。無駄なことをやってる給料泥棒である。
158 :
仕様書無しさん
2017/01/31(火) 21:30:28.51
要するにテストしたくないコーダーの言い訳w
159 :
2017/01/31(火) 21:34:38.76
テストは効率的にしなければいけないといったら

なぜかテストしたくない言い訳だと
勘違いするのはなぜなんだろうねw
160 :
2017/01/31(火) 21:37:59.68
テストは効率良くした方がいいよ

コピペをなくせばテストは一回でよくなる
その時間を他のテストに回せる
161 :
仕様書無しさん
2017/01/31(火) 21:50:32.66
言い訳が言い訳でないという言い訳w
162 :
仕様書無しさん
2017/02/01(水) 03:03:38.14
システムのそこら中にコピペされたメソッドとか最悪だな
歩きスマホや信号無視などと一緒で、なぜ、あんな恥ずかしい行為を堂々と出来るんだろうな
コピペされたものが全部同じ記述ならまだ救いがあるが、個別に所々改変してあったりするともうね
163 :
2017/02/01(水) 14:31:07.16
変な規約の縛りがあったらやむを得ない
164 :
2017/02/01(水) 18:35:52.43
>>156
イミフ
165 :
2017/02/01(水) 21:31:51.88
ちゅーか、ソースからテスト仕様書作ったら不具合でねーじゃん
まあ、わかるよ
でもさ、それって人に作業振るときどうよ?
ソース要素70%設計書要素20%ありがちな良識要素10%を上手くミックスさせて作業しろって言うんだろ?
だから疲れるんだよてめぇの指示は
お前の言うとおりやったらテストできないじゃんって一言文句を言ってから作業したいわ

そもそもだよ
ちゃんと設計書書いてそこからテスト仕様書作れるように作業やったら
問題なんかはじめから出ないのに
ソースからテスト仕様書作る作業なんか発生させるからこのザマだよ
166 :
2017/02/01(水) 21:40:50.22
そもそもだよ
お前の書いたクソコードが信用ならないからテストをしようって作業なわけよ
それなのにクソコードから作ったらクソから石鹸作ってるようなもんじゃん
どんなに一生懸命擦ってもクソ塗りたくってるようなもんだよ
普通はさ
要求仕様書からシステムテスト作って
基本設計書から結合テスト作って
詳細設計書から単体テスト作るわけよ
こういうのV字開発って割りと有名だと思ってたんだけど
最近はググっても全然出てこないんだね
IT○ro役に立たないな
167 :
仕様書無しさん
2017/02/01(水) 21:48:16.44
なぜクソから石鹸という喩えにしたのか気になりすぎて言いたい事が全く伝わってこない
168 :
2017/02/01(水) 21:52:20.21
ウグイスの糞なら作れるらしいな
169 :
2017/02/01(水) 22:02:40.49
>>167
お前の限界はそんなもんだろ
170 :
2017/02/01(水) 22:03:51.37
プログラマーってCPUに直接理解できるコードを書く低級言語を理解している人のことを言うのかと思っていたら
IF文で分岐できるコードが書けたらそれだけで良いのね、それ頭が腐ってるわ。

SEって各部品がどんな動きをしているのか気にしないのか。
遠くから眺めて、目的に対して結果だけ出力すればいいのか?
理想の流れだけ語ってシステムエンジニアと名乗るの恥ずかしくないのかな。
171 :
2017/02/01(水) 22:18:55.65
>>165
> ちゅーか、ソースからテスト仕様書作ったら不具合でねーじゃん

あ、そこがお前が完全に間違ってる部分だw
お前が理解してない理由が、理解できたよ。

まずなソースの動きからテスト仕様書を作れって話はしてない。
いいかい? してない。わかった?

ソースの構造からテストする場所を決めろと言ってる。
違いわかる?

同じ関数を呼び出している構造なら、そこは一回しかテストしなくていい
コピペされていれば両方テストが必要。

そのテストの内容は当然仕様書からに決まってる

スッキリしたね
172 :
仕様書無しさん
2017/02/01(水) 22:35:30.41
石鹸はクソからに決まってる
173 :
2017/02/02(木) 00:32:16.19
>>171
は?
だからソース要素と設計書要素と良識をお前の脳内の黄金比(うんこ)で混ぜ合わせると
オリハルコン(うんこ)ができるって気張ってんだろお前
おkおk( ´∀`)b
174 :
仕様書無しさん
2017/02/02(木) 00:34:35.22
自分、コピペプログラマだけど
ボタンクリックで呼び出したやつと
メニューバーから呼び出したヤツが
同じ処理なら、2つに分けないよ。
そんなのどっから呼び出されたものかフラグに設定して、
同じ処理呼び出して処理させて、細かいことはフラグで分岐させればいいじゃん。
175 :
2017/02/02(木) 00:43:34.65
フラグがなにを指しているかで別の恐怖がありそうだ
176 :
2017/02/02(木) 01:44:16.91
>>174
2つにコピペした場合、テストは2つとも必要かどうかという話をしている
177 :
2017/02/02(木) 01:51:26.56
>>176
全然問題を認識できてないな
コピペしようが関数を呼び出そうが呼び出し先のテストは必要か否かだ
178 :
2017/02/02(木) 02:00:57.25
>>177
コピペをしていないならテストは一回でよくなるよ
コピペしたら二回必要になる。

コードのすべてに「この行はテストしました」って
マークでもつけてみればわかるんじゃないかな?

コピペをしなければテストは一回ですむけど
コピペをしたら、それぞれテストしないといけなくなる
179 :
2017/02/02(木) 06:54:17.18
>>178
テストしてからコピペしたら?
180 :
仕様書無しさん
2017/02/02(木) 07:20:53.07
やってもやらなくてもお前らのテストなんかどうせ役にたたんのだからテストはユーザーに任せとけよw
181 :
仕様書無しさん
2017/02/02(木) 08:13:43.39
【主な偽装請負多重派遣業界結婚障害者の作業】
[文系多数の貧困非婚スキル]
コマンド
スクリプト
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[技術不要の主婦対象ソフト]
ノンプログラミングツール
フレームワーク
Web
COBOL
VB
.net
Java
DB
ERP
SAP
182 :
2017/02/02(木) 09:39:24.52
>>179
その後に修正が入るのが普通だから
その順番に意味は無いよw
183 :
2017/02/02(木) 12:56:05.11
>>182
普通って何で?
184 :
2017/02/02(木) 21:20:45.57
>>183
将来はわからないからね
185 :
2017/02/02(木) 22:31:22.92
>>184
開発中止
70KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: