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

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

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

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

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

前スレ
自社のシステムは自社で作らないと成功しない 2
http://kanae.2ch.net/test/read.cgi/prog/1410810583/

2 :仕様書無しさん:2014/11/26(水) 20:03:02.15
>>1
え?マジで?
もう、
 内製に切り替えるようにもってける奴は、相当優秀な奴だけだって、大体わかったんでは?!

3 :仕様書無しさん:2014/11/26(水) 22:48:17.71
>>2
その理屈だと、
内製が成功するかどうかは相当優秀な奴がいるかどうかになってしまい、
当たり前すぎて何の解決にもならない気がする

それに、優秀なんだったらその人の目の届く範囲で外注しても、
おそらく成功するんじゃないかな

4 :仕様書無しさん:2014/11/26(水) 23:15:41.92
「ユーザが作れば一番良いものができる」
これが実は眉唾なのである
著名映画評論家が自ら製作した「シベリア超特急」
某格ゲー有名プレイヤーが開発参加した「御意見無用」
なぜこれらが駄作となってしまったのかを理解できないうちは、内製に手を出すべきでない

5 :仕様書無しさん:2014/11/26(水) 23:39:09.46
他人から見たら変なものでも本人が幸福ならそれでいいんじゃないか?
シベ超を語る水野晴郎なんて、本当に幸せそうだったじゃないか。

6 :仕様書無しさん:2014/11/27(木) 00:28:31.94
俺は、一般人と話していているときに感じるのだが、
彼らは、なんて頭の回転が遅いのだろう、と思う
彼らは、記憶力も悪い

俺は、学歴によってプログラミングの差が現れる と述べた。947で
プログラムの作り方が、学歴の低いのはその場限りのロジック、
かたや将来の拡張性をもつコードというような差になるだろうと。

一般人にとって、ここで急に学歴の話が出ているように思うのでは?
しかし俺からいわせれば、のは唐突ではない、前スレッドからの継続である。

をい! 百姓。記憶の悪さに気付いたか?

7 :仕様書無しさん:2014/11/27(木) 15:41:42.64
>>6は高学歴ゆえに頭の回転が速くて記憶力もいいのかもしれないが、文章見てると
コミュニケーション能力や、文章の推敲の能力がかなり欠如しているように思える。

マとしては優秀なんだと思うけど、仕事していく上では色々問題がありそうだね。

8 :仕様書無しさん:2014/11/27(木) 19:48:52.11
>>4
ユーザーが作ればユーザーが満足するものが出来上がる

5000円のコップと、自分で3日かけて一生懸命作ったぶさいくな陶芸コップ。
どっちか壊して、残ったほうをを貰える。

どっちを破壊するか?
5000円のコップを破壊するだろう。

9 :仕様書無しさん:2014/11/27(木) 21:04:12.17
作って使ってみないと使い勝手が良いかわからない。
だから、業界の現在の納品方式は、絶対にユーザーの満足を得られるスタイルに、そもそもなっていない。

10 :仕様書無しさん:2014/11/28(金) 11:02:56.78
>>8
例え悪すぎ
ブサイクな陶芸コップを使う理由って愛着だけじゃん
内製したシステムは愛着が湧くから素晴らしいって主張なの?

11 :仕様書無しさん:2014/11/28(金) 11:09:53.08
プライドというコンプレックスが刺激されるんじゃね、こういうとこ見てると

12 :仕様書無しさん:2014/11/28(金) 12:02:49.89
>>10
最低限の求める機能を有してるものであれば良い

あくまで、ユーザーにはまともなものを作れないという脳内固定希望論を展開しているやつ向けの話だ

システムの場合は、5000円のコップはブサイクどころか穴まで空いてる

13 :仕様書無しさん:2014/11/28(金) 13:47:32.64
>>11
全くだな
そういう奴が変な例えと長文を書く

14 :仕様書無しさん:2014/11/28(金) 14:12:16.55
ユーザーは夢を語り出すに決まってる
あんなこといいなできたらいいな

15 :仕様書無しさん:2014/11/28(金) 17:44:18.26
まず、ユーザーと直接会ったことのあるやつが、まともにこのスレにいないのが致命的

16 :仕様書無しさん:2014/11/28(金) 20:13:55.07
何回もおんなじこと繰り返しだな
バカは自分が馬鹿だと気づくことができないから馬鹿のまま

どんなに有能かつ有益な技術を持っていても、
有能な技術を発揮する場所、有益な技術として提供する環境がなければ、それは技術が無いのと変わらない。
ユーザーと有能・有益な技術を持つお前らの間には、無能が大量に居て、現実その大量の無能の伝言ゲームを経る。
そんな伝達経路の構造である現在の業界は、ユーザーの要望も有能な技術者の提案もまともに伝わらない。
結果としてシステム開発は失敗する。
だから、有能なお前らはユーザーの最も近いところに行って、その能力を存分に発揮してくれ。
つまり、元請会社、もしくはユーザーサイドそのものに転職しろ。そして有益有能な技術を社会に生かしてくれ。
有能有益な技術を持っているなら転職な話しじゃないか。
そう>>1は最初から言ってるのに。

反論内容が、ユーザーは使えない。ユーザーは夢物語ばかり語る。情シスは使えない。etc.............

ハッキリ認めればいいのに。
自分は口で言うだけの技術を持ってません。なので、元請に転職なんてできません。ユーザー側の大企業に入ることも出来ません。
すっぱいブドウです。ってさ。

17 :仕様書無しさん:2014/11/28(金) 22:10:23.97
システム開発に失敗する原因を、ベンダに押し付けすぎ
ユーザと技術者の間にいる無能は、ユーザサイドの組織にも沢山いる

18 :仕様書無しさん:2014/11/28(金) 22:34:09.68
>>16
それはユーザー側の経営者に言うべきじゃね
結構な報酬とIT技術者としての身分を保証して求人を出せば、いくらでも応募する奴はいる
有能な技術者は大抵技術を愛しているから、技術者としての死を迎えることがわかっているレールには乗らんよ
ユーザーがプログラミングを覚えたらシステム開発は成功する!みたいな認識の組織は屍臭が臭うんだよ

19 :仕様書無しさん:2014/11/28(金) 22:51:01.25
内製のコップ:「穴が空いてる?指で塞げば使えるだろ。いちいち文句言うな。工夫する頭もないのか」
5000円のコップ:「穴が空いてる?そんなもん誰が買うんだ。ただで使ってやるから早く直せよ」

20 :仕様書無しさん:2014/11/29(土) 02:24:00.47
穴が空いているコップを指で塞いでつかったら、指がションベンでぬれるだろ

21 :仕様書無しさん:2014/11/29(土) 07:45:55.40
>有能な技術者は大抵技術を愛しているから、技術者としての死を迎えることがわかっているレールには乗らんよ

有能なのは、一人遊びが好き。これが原点

22 :仕様書無しさん:2014/11/29(土) 09:17:32.48
演劇の例えで話をすると、
演劇というのは監督がいてそれの指示で作られている
というのは表面だけの話。
実際はこうしたほうがいい、とか皆で議論がなされる。
そして演劇は創造の場だとかいていた。
で、レールの上だけを走っている人は、そういう議論ができないそうだ
そうした中(創造的な中)で、しゃべることができない。
小さい頃の一人遊びみたいなことをやってこなかった人は、
演劇にむいていないと。

小さい頃に大いに与えられてきただけ人は、創造性が摘まれれているみたいよ

23 :仕様書無しさん:2014/11/29(土) 10:43:38.76
>>18
口で言うほどの才能があるなら
要望飲ませるくらいできるだろ

24 :仕様書無しさん:2014/11/29(土) 10:47:31.29
>>17
だから
有能なお前がユーザーと直でやり取りすればいいだろ

有能なら
俺の言う体制で出来ないなら今辞める。
どうすんだ?どっちか選べ。
俺の技術力ならどこでも仕事はあるんだ。
俺様を手に入れたい会社は腐るほどあるわ。
と言えるだろ。

25 :仕様書無しさん:2014/11/29(土) 12:35:18.06
創造性なんていらない、想像力はかなり必要だけど。

26 :仕様書無しさん:2014/11/29(土) 22:33:57.12
>>23>>24
だから有能なお前がCIOにでもなるか起業して好きにすればいい
口でいうほどの才能があるなら要望飲ませるくらいできるだろ
下っ端がいくら喚こうが無意味
経営者の意向を無視してやれる仕事なんてない

27 :仕様書無しさん:2014/11/30(日) 08:42:15.45
なんかパート3始まっていきなり正論連発w
もうこのスレいらないんじゃない?無能かつ経歴もウンコかつ学歴もウンコが根拠なく自分は超有能と思ってる奴が混じりすぎだから

28 :仕様書無しさん:2014/11/30(日) 10:02:55.70
>>27同感。切り替えしのレベルが>>26だもん。「有能なお前ら」に言ってる話しで、これに反論するということは「有能でない」って自己紹介しているようなものなのに

29 :仕様書無しさん:2014/11/30(日) 11:48:26.03
有能になりたいなら、部下をもたないことである。
なんでもひとりでやる。渉外から設計、テスト、納品、現金回収、保守メンテだな
一人も部下は育たないが、部下を持たないことで力がつく

30 :仕様書無しさん:2014/11/30(日) 18:37:16.26
>>29
派遣なんて部下一生いないじゃん
でも雑魚だよ

31 :仕様書無しさん:2014/11/30(日) 20:14:10.76
>>29
下請けになれば、有能でなくても全部やらされるよ。

32 :仕様書無しさん:2014/11/30(日) 20:18:53.86
下請けはガチで設計が出来ない。
設計しないのにモノは仕上げるw下請けヤバすぎw

33 :仕様書無しさん:2014/11/30(日) 20:25:15.10
有能じゃなくてもやらされるからね。

34 :仕様書無しさん:2014/11/30(日) 22:03:23.75
>>28
君も「有能なお前ら」に言ってる話しに反論してるのです自己紹介なのです

35 :仕様書無しさん:2014/12/01(月) 00:23:33.58
いつもの優秀な正社員()の人かな
別に内製を否定してるわけじゃなくて、内製するのに技術力を軽視しすぎている点を指摘しているだけなんだけどね
優秀な技術者を雇用して内製する分には賛成だよ

36 :仕様書無しさん:2014/12/01(月) 07:30:11.20
1人でやると量に限界あるし、
UIだけ派手でドキュメントや内部構造が低品質のもの作っている可能性がある。
1人でしかやったことないやつにロクなやついない。

37 :仕様書無しさん:2014/12/01(月) 20:53:08.74
>>29
それやってるのって、完全内製の人しか経験者がいない現実・・・・。

38 :仕様書無しさん:2014/12/01(月) 20:57:17.28
あぁ現金回収はやってないか。
予算取りを代わりにやってるかもしれんが。

39 :仕様書無しさん:2014/12/01(月) 21:28:08.21
>>36
品質についてはそうなんだろうけど、ちゃんと現場で使われて成果が出てれば良いと思う。
現場業務知ってる人が自分達のためのものを作るのは、効率は凄く良いし。
このスレで問題視されている伝言ゲームも無いわけだしね。
品質や属人性が課題になったら、外注などしてリニューアルすれば良いと思う。
お手本があればこのスレで言われているような失敗のリスクも少ないだろうし。。

40 :仕様書無しさん:2014/12/01(月) 22:02:55.03
>>39
コードから仕様書起こすのはもうヤダよ。

41 :仕様書無しさん:2014/12/01(月) 22:02:55.54
>>39
自分達で自分達の仕事のために作ってるから、
システムが足をひっぱってきたら、ばーん!!って簡単に完全リプレイスやれるんだよね
だから意外に保守性っていらないんだよねユーザーが作ると
動けばいいのであって 動く途中の部分にこだわりなんて持ってない
プログラマがよくやるミス。目的のための手段なのに、手段を目的にしてしまう。
これがユーザーが作るとない。
もちろん腕の良いプログラマがユーザーの中にいることにこしたことはないけど

42 :仕様書無しさん:2014/12/01(月) 22:04:28.27
>>40
それは外注して、さらにシステムをリプレイスするパターンでしょ
外注してるもんだからユーザーが仕様(業務)を理解していないパターン
それは最悪になる
だから外注する情シスは超最悪の体制なんだ

43 :仕様書無しさん:2014/12/01(月) 22:06:42.29
いろいろ意見はあるだろうけど、伝言ゲームが業務レベルの複雑なものでは絶対に成功しないってのは、異論はないわ。
これだけはどうやっても否定するだけの実績がどこ探しても見当たらない。

44 :仕様書無しさん:2014/12/01(月) 22:30:38.01
伝言ゲームどころか、なぜか自分で仕様を決めたがる情シスのアホ。

45 :仕様書無しさん:2014/12/01(月) 22:35:45.85
>>41
> 動けばいいのであって 動く途中の部分にこだわりなんて持ってない

仕組みを理解しないで、どうやって意図通りに動いているかを判断するのかね
システム開発を甘くみるのもいい加減にしろ
やはり君はシステム開発に関わるべきではない
どうしても関わりたければ、自分の馬鹿さ加減を理解できるまで寝る間も惜しんで勉強しろ

46 :仕様書無しさん:2014/12/01(月) 22:42:23.41
>>42
内製だと、その人しか仕様を理解してないとかザラ。
リプレースでデータとか全部捨てるなら外部仕様の作り直しでも良いかもだけど。
ユーザに仕様を聞いてみなよ。今までと同じ+アルファと答えるから。

47 :39:2014/12/01(月) 23:41:14.21
>>40
コードから起こす必要はないかと

>>41
まず動いて活用されることが大事ですからね。
受託開発しているプログラマは要求を満足するシステムを作ることが使命であるが、
本当はシステムがきちんと活用され、効果が出ることが目的のはず。
受託開発での失敗でありがちなのは、β版リリースしてから大幅な変更の必要性に気付いたけど
諸々の事情で修正できず、使えないものが出来てしまう、などでしょうか。
ベンダーの責任ではないし、ユーザが賢くないと失敗するのが外注の悲劇だと思う。
内製は軌道修正しながら開発出来るので、あさってのものが出来上がる事が少ない。

うちの会社は馬鹿なので、外注で運用不能のクソシステムを作ってしまい、しょうがないから現場の人が内製したということがあった。そんな馬鹿はうちだけかもしれませんが。。。

48 :仕様書無しさん:2014/12/02(火) 00:39:14.98
動けばいいっていうのは確かにそうなのだが、それは1か月後?半年後?1年後?
それよりも先? その時だけで済むならいいのだが、そうじゃないことを知ってるからね、
愚者は経験に学び、賢者は歴史に学ぶといいますが、愚者以前が大量にいる
この現実。

49 :仕様書無しさん:2014/12/02(火) 03:15:27.27
動けばいいって言っている所は、
実は、動くのが精一杯 という意味であることがほとんどだよ。

動けばいいと言っている所に、修正を依頼すると
作り直し同然になっちゃう。

なぜなら動くことが精一杯でメンテナンス性が考えられてないから。
あと動けばいいと言いつつバグだらけで動かないことがよくある。

コードをシンプルに保つという基本的なことができてないから。
で、そういう動く以上のことが出来るっていうのが技術力なんだよね。

50 :仕様書無しさん:2014/12/02(火) 06:39:50.34
>動けばいいって言っている所は、
>実は、動くのが精一杯 という意味であることがほとんどだよ。
>コードをシンプルに保つという基本的なことができてないから。

フロー図も読めないようなのが、コードをシンプルにということを
プログラマに求めていないか?

おまえが、コードレビューしてやれよ

51 :仕様書無しさん:2014/12/02(火) 06:47:34.75
>>47
なんでないの?

52 :仕様書無しさん:2014/12/02(火) 07:02:47.46
今時フロー図なんて書いてるのか。察した。

53 :仕様書無しさん:2014/12/02(火) 15:33:07.64
>>52
大昔のフローチャートをイメージしてない?
輸出向けだと、SysMLで要求されることも有るよ。

54 :仕様書無しさん:2014/12/02(火) 17:45:47.09
ぐちゃぐちゃでクソシステムでもユーザーにとって価値がある段階には一度は入る
対して
一瞬たりともユーザーにとって価値を持たずにおわるシステムどっちがマシか?

55 :仕様書無しさん:2014/12/02(火) 17:53:41.92
>>54
ゴミ同士を比較してなにがしたいの?

56 :仕様書無しさん:2014/12/02(火) 19:00:14.55
>>55
同じゴミでも前者は成長や改善が期待できる。後者は、それもない。それどころか訴訟で無駄な費用無駄な時間を費やす。

57 :仕様書無しさん:2014/12/02(火) 19:14:03.56
ぐちゃぐちゃなクソシステムが外部仕様をきちんと満たしてるとは思えない。

バグだらけで穴だらけ、ちょっとイレギュラーなデータを投入したら、
データは壊れてデータベースの復旧もできず。そんな程度が関の山だろ。

58 :仕様書無しさん:2014/12/02(火) 19:41:15.32
>>57
本人達の業務に実際支障が出てないのが、少なくとも使えている証拠だろうがw

59 :仕様書無しさん:2014/12/02(火) 20:06:19.56
証拠ってww

60 :仕様書無しさん:2014/12/02(火) 20:23:34.28
>>53
ことも有るよなのに必要条件にしてるのがおかしい。

61 :仕様書無しさん:2014/12/02(火) 22:54:37.91
そもそも運用まで含めてやっていると、とりあえず動けばいいでやってると自分の
首を締めることになるから改心するはずなんだけどな。SIerなんかだとプロジェクトを
渡り歩くジプシーみたいな奴が多くてちょっとしたことで動かなくなるコードを
大量生産してくれてというようになっている。 内製だからと言って動かないから
捨てて一から作り直しますなんて言えるところなんて殆ど無いけどな。

62 :仕様書無しさん:2014/12/03(水) 03:08:03.78
>そもそも運用まで含めてやっていると、とりあえず動けばいいでやってると自分の
首を締めることになるから改心するはずなんだけどな。SIerなんかだとプロジェクトを

おまえの文は、主語がわからない

それから
>内製だからと言って動かないから
>捨てて一から作り直しますなんて言えるところなんて殆ど無いけどな。

おまえに教えるのだが、主語が変わるときは改行する。文の基本

63 :仕様書無しさん:2014/12/03(水) 07:06:49.72
「動けばいい」を否定するやつって、想定してる「動く」のハードルめちゃめちゃ低すぎだわw

64 :仕様書無しさん:2014/12/03(水) 08:09:51.83
>>63
その低いハードルで事足りる場合もあるからな。頭が固く経験も浅い奴にはわからないだろうけど。

65 :仕様書無しさん:2014/12/03(水) 08:19:33.12
>>64
俺に言うなw

66 :仕様書無しさん:2014/12/03(水) 09:06:26.73
>>54
馬鹿なの?

信頼性とメンテナンス性が高くて
ユーザーに価値を与える方がいいに決まってるじゃん。

なんで、ユーザーの価値しか達成できないの?
その後バグだらけで迷惑かけてるというのに。
技術力不足だから?

67 :仕様書無しさん:2014/12/03(水) 09:46:31.93
>主語が変わるときは改行する。文の基本
馬鹿そうw

68 :仕様書無しさん:2014/12/03(水) 11:04:41.65
>>67
触っちゃダメ。

69 :仕様書無しさん:2014/12/03(水) 17:54:11.53
>主語が変わるときは改行する。文の基本

頭よさそうw

70 :仕様書無しさん:2014/12/03(水) 18:24:46.86
>>66
伝言ゲームが不可能であることをお前が証明しているw

71 :仕様書無しさん:2014/12/03(水) 19:02:54.17
2chで文章がとか何言ってんだこいつ

72 :仕様書無しさん:2014/12/03(水) 19:34:25.70
>おまえに教えるのだが、主語が変わるときは改行する。
主語は「>>62

>文の基本
主語は「主語が変わるときは改行すること」

改行しろやww

73 :仕様書無しさん:2014/12/03(水) 21:51:46.59
>>66
> 信頼性とメンテナンス性が高くて
> ユーザーに価値を与える方がいいに決まってるじゃん。

正論。(当たり前のことですが正論は反論されません)

74 :仕様書無しさん:2014/12/03(水) 22:30:01.90
プログラマの言う信頼性とメンテナンス性は根拠のない自称にすぎんけどな

75 :仕様書無しさん:2014/12/03(水) 22:42:15.22
そう思うのはお前の能力と経験が不足しているせい
内製を成功させたかったら>>74のような馬鹿を開発から遠ざける必要がある

76 :仕様書無しさん:2014/12/03(水) 22:47:09.38
>>75
それもお前の思いこみ…というより願望だなw

77 :仕様書無しさん:2014/12/03(水) 22:47:12.18
>内製を成功させたかったら>>74のような馬鹿を開発から遠ざける必要がある

74は本質をついている。75が馬鹿そうだ

78 :仕様書無しさん:2014/12/03(水) 22:54:31.04
Effective C++, CERT C++ Coding Standard, C++ FAQ
これらは全て根拠のない自称と主張するのですね

79 :仕様書無しさん:2014/12/03(水) 23:05:48.06
>>78
揚げ足とったつもりかよw
お前みたいなゴミプログラマの話をしてるんだけどw

80 :仕様書無しさん:2014/12/03(水) 23:09:04.25
苦しいのうw

81 :仕様書無しさん:2014/12/03(水) 23:28:25.68
>>79
揚げ足取りって…
>>78のドキュメントは、エンジニアの一般常識だろ
本当にそんなんで内製に関わるつもりなの?

82 :仕様書無しさん:2014/12/03(水) 23:38:20.59
入門書レベルで数年突っ走って頭が硬くなって新しい知識が入らない、
新しいことにチャレンジしたがらないってのはよくいるからな。特に先に
出来る人がいると、やらなくてよくて成長しない。

83 :仕様書無しさん:2014/12/04(木) 00:09:50.06
いや、よくいるのは3年生レベルで止まってしまうやつ
そう、君みたいにね

84 :仕様書無しさん:2014/12/04(木) 00:22:14.06
>>82同感。切り替えしのレベルが>>83だもん。「入門書レベル」に言ってる話しで、これに反論するということは「入門書レベル」って自己紹介しているようなものなのに

85 :仕様書無しさん:2014/12/04(木) 00:39:52.00
お前らの技術力なんてどうせ五十歩百歩なのに、どうしてそんなにいがみ合うんだい?

86 :仕様書無しさん:2014/12/04(木) 00:42:35.31
百歩にとって五十歩はクソみたいに邪魔な存在なんだよ

87 :仕様書無しさん:2014/12/04(木) 00:54:16.41
どっちがより邪魔かの争いかww
ださすぎるなww

88 :仕様書無しさん:2014/12/04(木) 01:55:15.82
【IT】法外な開発料金の見積もり根拠、「客には絶対に言えません」 2014/12/03©2ch.net
http://anago.2ch.net/test/read.cgi/bizplus/1417607541/l50

89 :仕様書無しさん:2014/12/04(木) 12:29:02.53
>>66>>73
前後関係が完全に狂ってますが、、、

それはシステム成功させたさらに先のレベルの話

システム成功は達成できない
理由は伝言ゲーム云々って
話なのに。そういうことにすら気づけない低脳が伝言ゲームしてたり実装してるから、外注システムは成功しないと>>70で指摘されてることに気づいてる?

90 :仕様書無しさん:2014/12/04(木) 17:44:40.61
ユーザーの希望とは明後日の動きをするシステムを納品して、うちのは信頼性とメンテナンス性が高いっ!どやっ!!www

91 :仕様書無しさん:2014/12/04(木) 17:57:43.88
ユーザーは夢物語を言う

なんて反論するやついるけど、
この反論自体が自爆だろ。
伝言ゲームがオープニングで失敗確定って言ってるようなもの。
技術知識が無く伝えられる能力がないなら、自分たちで作って夢物語だと学んだり、技術知識を身につけないといけないということ。
現状のまま外注してたら永久にそれに気がつかずユーザーはクソシステムをつかまされたと想い続ける。実際、オープニングから失敗確定なんだと、お前らは言っているわけで。
内製をやって技術や知識を得ないと外注すらまともにできなきということ。
でも、試行錯誤しながら内製をやって知識と技術が身についた段階でシステムは出来上がっているから、発注の必要がないという現実。

92 :仕様書無しさん:2014/12/04(木) 18:17:01.01
内製やってうまくいく会社は、外注でもそこそこうまくいくようなところだろw
外注してクソつかまされてるようなところは、まあその程度の会社なんだから、
内製に切り替えればうまくいくと思うのはそれこそ夢物語ww

業務改善のためのシステム化が提案できて仕様をまとめられて、
開発もリードできるような優秀な技術者を雇えば解決するかもしれないけど、
そんな奴その辺にはいないし、そもそもそういう奴を探し当てて雇用するぐらいの
意識の高さがあれば、外注に頼むにしてもそれなりのものができるわけでw

93 :仕様書無しさん:2014/12/04(木) 18:26:07.25
>>92
内製で少なくともシステム作りを経験しないと、業界知識ゼロの人たちの多重伝言ゲームを経て成功させるなんて、もっと離れ業だろw

94 :仕様書無しさん:2014/12/04(木) 18:27:49.54
偽装請け負いでは派遣に出しておきながら
勉強会と称して自社に呼び戻してただ残業、
土日にもタダ働きさせる
大阪中央区安土朝鮮にあるなん茶ってシステムや。

95 :仕様書無しさん:2014/12/04(木) 18:27:52.00
>>91超ぐう正論w

96 :仕様書無しさん:2014/12/04(木) 18:38:15.39
内製に従事する開発者が意欲に満ち溢れていてどんどん技術を習得するという
前提であれば、内製もうまくいくでしょうなw
実際には>>83状態で終わる奴が大半なんだから、伝言ゲームさえなくせば
うまくいくと思ったら大間違いw

ていうか、まずはお前らがユーザとの距離を縮めることから始めろよw
いきなり内製万歳!外注はクソ!とか飛躍しすぎだろw

97 :仕様書無しさん:2014/12/04(木) 21:15:26.22
当たり前の話をすると、技術力が高いほうが
いいものを作れる。

技術力が低いものはいいものを作れない。

努力すればできるとかいっても無駄。
そんなのは幻想。

98 :仕様書無しさん:2014/12/04(木) 21:17:55.20
当たり前の話をすると、技術力が高いほうが
納期も短く、バグも少なくなる。
修正のコストも少なくなる。

逆に言えば、納期が短くてバグが少なくて
修正のコストも低いことが技術力が高いことの証。


そんなことより、動くものを作ることが重要だ
って言っている奴は、動くものを作るので精一杯と
告白しているようなもの=技術力が低い。

99 :仕様書無しさん:2014/12/04(木) 21:45:39.34
技術って何かね

100 :仕様書無しさん:2014/12/04(木) 22:09:36.83
動くものを作るのは最低限で、
顧客に価値がある物を、短い時間で
不具合無くつくり上げること。

ある機能が、顧客が満足するかどうかはその顧客次第だが、
早く作る、不具合がない。修正コストが低い。
これらはすべての顧客にとって言わなくても必要とする要件なんだよ。

そこんところ忘れて、そんなのこと(メンテナンス性など)より
まず動くことだ!って言ってるのを見ると、
あぁ、動くものを作るので精一杯なんだなぁって思う。

101 :仕様書無しさん:2014/12/05(金) 00:03:57.64
>>96
なんで技術者側からだけ歩み寄りが必要なんだと思うんだよ。必要なのは
双方の歩み寄りだよ。 システムを欲しがっている側が無知なままでいいわけ
ないだろ。お互いが双方の領域を理解する姿勢を見せ、リスペクトすることで
初めて動き出すんだよ。 出来上がったものがどんなにまずいものであっても
そこから知見やフィードバックを受け進める必要がある。

別にシステム開発に限らず、無知や無関心なんてものは他人に対して、
それが重要度が低い取るに足らないものという誤解を与えかねないから
慎むべきものなのだが、上に行けば行くほど、忙しくなればなる程そういう
ことを忘れていくんだよね。

102 :仕様書無しさん:2014/12/05(金) 00:46:17.82
>>101
そりゃ発注側からの歩み寄りも必要だと思うけど、使う人と作る人の距離が近いことが
メリットがよりわかってるのは技術者側だろw
そもそもここは技術者の板なんだから、「客がこうしてくれればいいのに」みたいな
理想を語るよりも、リスペクトが足りないならじゃあどうやってそれを得ていくか考えるべきw

103 :仕様書無しさん:2014/12/05(金) 15:26:25.94
社内SE談
自分も都内で
39歳720万
仕事は糞みたいだけど・・・の時間に帰ってきて2chやれるのが
救いかな

104 :仕様書無しさん:2014/12/05(金) 23:35:08.77
リスペクトなどいらない
毎日こき使われているのに、そこにある事すら意識されない
可もなく不可もなく、空気のようなソフトウェア
そういうモノをぼくは作りたい

105 :仕様書無しさん:2014/12/06(土) 01:28:45.22
>>88のスレが現実

106 :仕様書無しさん:2014/12/06(土) 02:34:51.08
>>104
空気なんだからタダだよね

107 :仕様書無しさん:2014/12/06(土) 08:49:56.67
まだやってんの?
外注の派遣と腕に覚えのある正社員
が言い争っても無意味だってわからないの?
片方は超無能、片方は口だけで責任取りたくないから動かない奴
無駄だと気づかないかな?

108 :仕様書無しさん:2014/12/06(土) 09:15:17.97
低学力が99.9%のお前らができる作業を、なんで中学力、高学力の人たちができないと思うのか?
根拠が全く分からんわ

109 :仕様書無しさん:2014/12/06(土) 09:39:34.77
情報システムだけ神格化しすぎじゃない?
独自業務スタイル、独自経営方法、独自開発手法、なんだって独自色を持ってる企業は強いよ
どこと代わり映えのない会社は、偽装請負とかやってるのが精一杯

110 :仕様書無しさん:2014/12/06(土) 10:20:33.07
>>109
独自色というか、他と差別化されていないビジネスモデルを持っていないところは
最終的に安売り合戦になるのは経済学の基本ではあるわけだけど。
ただ差別化されたビジネスモデルだとしてもそれが価格に影響を与えないような
ものだと結局安売り合戦に参戦する必要があるから差別化されている事自体が
マイナスになる。

111 :仕様書無しさん:2014/12/06(土) 11:53:10.74
>>109
「独自スタイルを持っている&成功している企業」をマスゴミが紹介するときに
独自スタイルが成功の要因であるかのように書いたりしているが、現実は全く違う。
成功している企業は労力の99%を、極当たり前の「企業として必須なこと」に注いでいる。
それが出来た上での、トッピングとしての独自スタイルが生きてくる。
利益の源泉は、スタイルじゃなく、当たり前のこととして日々やってる、いわば独自性のない部分だからね。

112 :仕様書無しさん:2014/12/06(土) 11:53:12.48
>>107
いえてる
実際、動いた奴の報告見ると、一人一社相当級の技術を超スピードで自由にのびのびと使ってシステム構築してる感がある

業務系に求められる技術なんて偏差値60くらいあるやつに半年やらせれば業界平均レベルの奴より遥かに使えるようになる
ただ実際にシステムを構築するには問題は業界知識と業務知識と運用知識が必須
これを習得するのに要する期間>>>>>>>>>>>業務系システムの作成技術を身につける期間
なら業界知識と業務知識と運用知識を身につけた奴にシステムの作成方法のノウハウを習得させたほうが圧倒的に早いし、品質も良くなる

113 :仕様書無しさん:2014/12/06(土) 12:51:10.25
圧倒的に早いのはわかるが、品質は関係ないぞw
あとメンテナンス性も。

そういうのは数年後に仕様変更や引き継ぎが
出てきた所から表面化するんだよね。

で、それこそが技術者との違いなんだよ。
ちゃんとした技術者が作ると、将来の変更まで
しっかりと考えられているから
長期間使えるシステムになる。

114 :仕様書無しさん:2014/12/06(土) 13:22:49.24
>>113
仕様の伝言ゲームが失敗するのにどうやったら、将来まで見据えた設計なんて出来るのやらw

115 :仕様書無しさん:2014/12/06(土) 13:27:02.12
>>114同感
というより「技術者」と呼べるほどお前らの能力も価値もねーから

116 :仕様書無しさん:2014/12/06(土) 13:31:28.45
>>114
えと、わからないかな?

見据えた設計をするんじゃないんだよ。
逆に見据えない設計といったほうがいいぐらい。

ダメな所は、将来アレやコレを使うかもしれないと言って必要にならないことにまで対応するが、
俺が言ってるのは、今必要ないものには対応しない。将来を見据えない。
重要なのは将来どうなるかわからないので、どんな設計にも最短で変更していける技術を持つこと。

将来どんな変更が起きたとしても、今の設計がその変更の妨げにならないように作るわけだね。

具体的に言うと、

1. 無駄なコードを書かない。場当たり的な対応をしない。(無駄なコードが多いと、それを読むんで理解するのに時間が掛かるから)
2. 各モジュール間を過度に依存させない。(依存するものが多くなればなるほど、変更時に考えないといけないことが多くなるから)
3. しっかり自動テストを書く。(自動テストがあれば修正時のバグをすぐに検出可能だから)
4. 色んな物を自動化しておく。(ドキュメントに漏れ無く書くのは無理。コードで自動化することでだれでも再現可能になる)

等と言った、ソフトウェア開発として当たり前のことをするだけ。

117 :仕様書無しさん:2014/12/06(土) 13:54:17.83
>>116
ユーザーが求めるものは、そーーーーーーーーーーーーーーーんな複雑な大規模なものじゃないってことに気づかないかな?
携帯電話の機能はいっぱい。使ってるのは?

メールとカメラとコミュ通信アプリと電話のみ。

そゆこと。

118 :仕様書無しさん:2014/12/06(土) 14:36:18.52
>>117
これマジ大事

119 :仕様書無しさん:2014/12/06(土) 14:46:28.85
>>117 は何を言ってるんだ。>>116 をしようとしてると、場当たり分のコストでいらない機能追加しようとして崩してくるのがユーザだろ。

拡張性と隠し機能を勘違いしてる、よくいるユーザなんじゃないか。

120 :仕様書無しさん:2014/12/06(土) 15:01:28.75
>>117
大量生産の製品とオーダーメイドに近い一品物を比べること自体がナンセンスだけどな。

無駄だと思っているものが本当に何の意味も無い無駄なのか、安全マージンや
保険として必要なものなのか正確に判断出来る人なんてそうそういないし。

特にオーダーメイドに近いものなら外注なら発注側が、内製なら依頼する側が
システムのライフサイクルまで含めて明確に出来てないと作る側は保険のため
とか、気を利かせたりで肥大化していく。 いらないなら最初からそう伝えておけば
良いわけで。

最近良く、日本文化はコンテクストが高いから空気や行間を読んで少ない指示
でも仕事をやるみたいなことが言われているが、無駄なやらなくても良い作業を
してるとも言えるんだよな。 無駄なく効率的にやれというなら想像したり気を利か
せたりが必要ないレベルまで落としこむ必要で依頼する必要がある。

121 :仕様書無しさん:2014/12/06(土) 15:20:04.08
>>117
> ユーザーが求めるものは、そーーーーーーーーーーーーーーーんな複雑な大規模なものじゃないってことに気づかないかな?

だから余計なものを作らず、シンプルに作れって話をしてるんあろ。
そのシンプルに作るっていうのが素人には出来ないこと。

場当たり的な対応で、シンプルなものを複雑に作ってしまう。
だから修正の時に大きな違いが出るって言ってんだよ。

122 :仕様書無しさん:2014/12/06(土) 15:34:14.93
お前はいつもコーディングの話やね

123 :仕様書無しさん:2014/12/06(土) 15:41:10.01
そりゃ、そこが技術者との大きな違いだからな。

124 :仕様書無しさん:2014/12/06(土) 15:42:55.45
あとコードっていうのは
設計書だってわかってるかな?

コーディングってタイピングのことじゃないぞw
コードを複数のモジュールに分けて
そのモジュールを結合させて機能させるのがシステムであり
これが設計。

それを素人はちゃんと出来ない。

ただの要件を仕様や設計と勘違いしてるでしょw

125 :仕様書無しさん:2014/12/06(土) 16:10:24.92
>>124
要するにお前が言いたい事はこうか?
ユーザーの要求→要件
コーディング→設計

それなら仕様とはなんぞや?

126 :仕様書無しさん:2014/12/06(土) 19:01:20.19
コードなんて「マクロの記録」を呼び出すだけでもOKだったりするわけで
そもそも仕様が伝わらないのにコードをどう書くのか教えてくれ
小学校の算数プログラムを要望しているのに核兵器のプログラムを作られても仕方ないの

127 :仕様書無しさん:2014/12/06(土) 20:00:04.32
プログラマ板のスレの大半の愚痴が
SIerは無能で仕様をまとめることが出来てない。客は仕様を伝えられない。
元請けは投げてるだけで仕様書が腐ってる。同僚のプログラマの技術が低い。馬鹿ばっかり。情報試験も受からない低脳だらけ。.......etc
そんな愚痴ばっかり
なのに仕様が伝わらないという反論が来ると「それは、お前の会社が仕様が伝わらない無能なところなんだろw」と返してくる
お前らの普段の発言と完全に逆の発言して、どんだけ発言がダブスタなんだよと思う

128 :仕様書無しさん:2014/12/06(土) 20:11:46.90
>ユーザーの要求→要件
>コーディング→設計
>それなら仕様とはなんぞや?

ユーザから要求が、画面サイズとか処理時間とかが、
なされない場合がある。
すると作り手から「画面構成が10枚の仕様なら100万円、
5枚の仕様なら50万円です」という
こんな感じかな


これでとどまっているなら

129 :仕様書無しさん:2014/12/06(土) 20:51:10.68
つまりマ板への書き込みは全てオレが書いていたってことかー!

130 :仕様書無しさん:2014/12/06(土) 21:20:10.77
このスレの技術者の皆さんへ
伝言ガー君が言ってる「自社のシステム」とは、技術者が想像するような全国200ヶ所の支店を結ぶ基幹系システム
などではなく、「マクロの記録」程度のもののようです

131 :仕様書無しさん:2014/12/06(土) 21:27:31.53
>>130
それでよくね?w

132 :仕様書無しさん:2014/12/06(土) 21:28:34.42
というより「マクロの記録」程度のものですら伝言失敗しているお前ら

133 :仕様書無しさん:2014/12/06(土) 21:31:21.01
技術者に何か伝えたい事があるならプログラミング言語で話すことだな

134 :仕様書無しさん:2014/12/06(土) 22:26:17.53
仕様=実現すべきこと。
設計=どうやって実現するか。
だから仕様書から設計書を作るのが順当。
勘違いが多いのは、設計書は、渡される側から見れば「仕様」になるという相対関係を理解していないため。
単なるミスや制限を「仕様」だと言い逃れするのが多いのも、混乱を増やしてる。

135 :仕様書無しさん:2014/12/07(日) 00:23:46.67
まず、特注のシステムを作る場合

要件定義・・・利用者がしたいこと。利用者が決めないといけないこと
        本来は利用者が決めることだが、丸投げする事が多いので
        代わりに作らされることもおおい

仕様・・・要件定義から漏れてるが、必須なもの(セキュリティとか)そういうのを補完したもの
      利用者が決めることもできるが、利用者が知らないことが多いため
      代わりにシステム会社が作って、ハンコをもらうもの

設計・・・プログラマがすること。設計したものは紙に書いたりコードに書いたりする
      紙に書いたものは最終的にコードに変換する
      技術力が高いプログラマになると、紙に書くことは最小限にして
      コードで設計書を記述することも出来る。
      この技術が低いと、読みにくく設計の意図がわからず後の修正がしづらくなる。

136 :仕様書無しさん:2014/12/07(日) 04:55:01.37
要望より問題点といって抽出しないとキツい。
自分に能力があると思っている奴は中途半端に解決した仕様を要望として出す。
画面のこの部分を赤に→ユーザが注意書きに気付かないことがある

137 :仕様書無しさん:2014/12/07(日) 07:43:44.04
>要望より問題点といって抽出しないとキツい。

問題点なんちゅものは、はじめから見えない
テストをやりながらでないと抽出できない
マニュアル人間だと、不測のまえでは
マニュアルに書いていないから解決できない、という

138 :仕様書無しさん:2014/12/07(日) 07:56:20.52
>>130でこいつはたいしたこと無いですよと指摘して終わらせようとしたが>>132で逆にひっくり返されたのか無職50歳専卒linux売名失敗winは

139 :仕様書無しさん:2014/12/07(日) 08:13:52.83
要件定義てシステム屋がやる事やで
そのためにユーザーから聞きださなあかんのは問題点ちゃう
現行業務の詳細そして「全貌」や、まず話はそこからやろが

140 :仕様書無しさん:2014/12/07(日) 08:43:34.09
システムを作ったことの無い人に
 システム構築に必要な内容を全部話せ。
なんて無理に決まってんじゃん。
お前らだって、注文住宅を依頼するときに
 建築に必要な内容全部話せている。
とでも思っているの?

内製でも外ででもいいけど実際に自分が作らないと、そんなものはわかるはずが無い。
だから外注という選択肢を取るには、自分達でシステム開発経験がないと話しにならないということだ。

141 :仕様書無しさん:2014/12/07(日) 08:49:15.58
>要件定義てシステム屋がやる事やで

ユーザはプログラマの言葉を聞くと、何言ってんだーろうと思うよ
宇宙人と話しているような感じだと思う
ユーザはプログラマに対してハァ、ハァとうなずいているんだけど。

打ち合わせのときは、プログラマの言葉がわかったような気になったが
打ち合わせが終わったあと、なんだったろうとなる

後日ユーザから打ち合わせのときと同じ質問がくるよ。
プログラマのほうが記憶がいいからおぼえているわけ

142 :仕様書無しさん:2014/12/07(日) 09:55:12.02
>>141
自分のフィールドの言葉と他人のフィールドの言葉
という立場上の違いがあるのに、「記憶がいいから」ってまとめるのはどうなの?
おまえも業界用語の部分は理解して無いだろ実際

143 :仕様書無しさん:2014/12/07(日) 10:13:21.20
>おまえも業界用語の部分は理解して無いだろ実際

ある会社のはなし、
今まで、業務系のフィールドに手を出しちゃいけないといわれていたのに
手を出して、受注してしまったという。悲惨だったそうよ

俺の場合、ユーザから先生といわれるぐらい、教えてやってのよ。

144 :仕様書無しさん:2014/12/07(日) 10:20:24.72
>>143
どこの業界だよ

145 :仕様書無しさん:2014/12/07(日) 11:27:56.41
>>144
社内情シスを持ってて外注しちゃってる最悪パターンの会社だとありうるよ
病院系の全員高学歴有超高難易度資格者しかいないところでも
だから外注はガンなの
現場なのに現場の業務がわからなくなるから

146 :仕様書無しさん:2014/12/07(日) 11:56:27.43
問題解決をするシステムを発注したいのか、
仕様通りのソフトウェアを発注したいのか。

147 :仕様書無しさん:2014/12/07(日) 12:21:10.09
>>145
レセプトとか会計とかなw
街角病院では、そこができないから絶対に定型の措置しかしないってところもあるよな
薬も決まった薬しかださないとこ

148 :仕様書無しさん:2014/12/07(日) 12:21:44.52
要件定義はユーザーがやることだよ。
それをシステム屋がやるから失敗するの。

「自社のシステムは自社で作らないと〜」というのは
要するに要件定義をシステム屋にやらせると失敗するという意味

言い換えると「自社の要件定義を自社で作らないと成功しない」ということ

要件定義てシステム屋がやる事といっている限り
失敗するよ。

149 :仕様書無しさん:2014/12/07(日) 12:29:13.55
>>148
それができないの。
システムを作ったことが無いと。
彼らは彼らなりに要求を出しているつもりなの。
彼らが無能なんじゃない。誰だってやったことのないことはできないんだよ。
だから内製をしないと経験つめないから結局失敗するって言ってるジャン。

150 :仕様書無しさん:2014/12/07(日) 12:30:11.35
けど内製で経験つむと、外注する必要性なくね?ってなっておしまいと。
つまり最初から外注なんてシステムが無理なもんだったってことやね。

151 :仕様書無しさん:2014/12/07(日) 12:43:17.90
いやそれはお前に何やらせても満足に出来ないだけだw

152 :仕様書無しさん:2014/12/07(日) 12:43:58.68
結論としては外注は内製を超える夢物語
というか内製では実装不可能な超高度な数学等々を用いるライブラリの発注等だけ外注が必要

派遣社員は内製をやる際のテスト要員として必要
実装は必要ない

153 :仕様書無しさん:2014/12/07(日) 13:09:00.95
物事の必要条件の前後関係をキチンと整理すると>>1の言うとおりですね。で終わりだろこのスレ。なんで3まで立てたの?
外注さんで文句言ってるのって派遣でしょ?まずまともな職位置に就けよ。

154 :仕様書無しさん:2014/12/07(日) 13:11:53.94
外注する時は社内の人間を開発チームに加えたら

155 :仕様書無しさん:2014/12/07(日) 13:20:42.14
社内システムの更新でも、一年に一回ぐらいやらないと
社内にノウハウがたまらない
で、社内のノウハウなんて人事異動でスッカラカンになる。
属人的なのよ。
人事異動で後任にまたシステムのド素人がくるというわけ

156 :仕様書無しさん:2014/12/07(日) 13:43:52.04
>>149
> それができないの。

自社のシステムを自社で作れるなら出来るだろ。
何を言ってるんだ?

157 :仕様書無しさん:2014/12/07(日) 13:47:04.19
>>155
> 人事異動で後任にまたシステムのド素人がくるというわけ

だからオープンソース等の有名なライブラリやフレームワークを使え。
社内で独自実装するなって言われるんだよね。

その会社自体のことは外部の人はわからないけど、
オープンになっているものなら、外部の人でも知っている確率が高いもの。

158 :仕様書無しさん:2014/12/07(日) 14:20:07.09
>>140
プログラムは建築より簡単な仕事だからだろ

159 :仕様書無しさん:2014/12/07(日) 14:30:06.38
社内で一人でやってると、技術者が自分しか居ない孤独を感じる。
どんな凝ったシステム作っても、ユーザーは「ふーん」て反応だし。

160 :仕様書無しさん:2014/12/07(日) 16:22:04.43
>>148
ユーザーが出来ないから作ります言うて出してきたシステムやがおったんやけど。
タイトルだけ要求仕様書、中身は機能仕様書でしたわ。
メモもまともにとらんやつやったから必要な要求事項抜けまくっていて笑たわ。

161 :仕様書無しさん:2014/12/07(日) 16:24:43.09
だから要件定義はユーザーが書くものなんだって

162 :仕様書無しさん:2014/12/07(日) 16:35:11.68
>>161
要求仕様書書く分の金もはらってよ、
出てきたもんが機能仕様書(タイトルだけ要求仕様書)なんだってよ。

163 :仕様書無しさん:2014/12/07(日) 16:55:17.71
>>156
内製はその訓練も兼ねるのだよ
それがわからんかね?馬鹿だから
で、訓練が終わったとき
外注が不要になっている

164 :仕様書無しさん:2014/12/07(日) 16:55:50.92
>>162
無知だから悪い。
要件定義はユーザーが書くものだってわかっていれば
その時点でおかしいってわかったはず

165 :仕様書無しさん:2014/12/07(日) 17:04:39.91
>>163
自分自身ができなかったのに、何年もやってようやく身に着けたことすらスグに忘れる馬鹿を相手にしても、そんなこと気づけないよ。
いや、正しく表現すれば。身につけていない。派遣の身分では身につけるのに必要な「ユーザーとの接点」がないから身に着ける機会すらない。
だから、その指摘をしても理解できないよ。そういう意味では彼は完全に人生を無駄に過ごした。
後から来た2年目に簡単に抜かれている。でも一生彼は気づかない。気づくために必要な環境に身を置けないから。
所詮、使い捨ての派遣。

166 :仕様書無しさん:2014/12/07(日) 17:13:30.78
>>165
一芸にでも秀でれば道が開けるもんだけどな。

167 :仕様書無しさん:2014/12/07(日) 17:16:09.02
派遣だろうが正社員だろうがSIはクソだ。
クソの上に立ってもクソはクソ。

168 :仕様書無しさん:2014/12/07(日) 17:20:41.03
>>166
プログラミングが秀でてると思ってるんだろう。確かに優秀だ。でもそこは無能が集う派遣の集団。
超大量な無能だらけの中でも順位をつければ上位がいる。確かに勘違いしてもおかしくはない。
でも社会の標準から見ると無能集団のゴミ捨て場のゴミでしかない。
技術力がズバ抜けている派遣社員なんて見たことが無い。
派遣されて数ヶ月で声がかからない時点でゴミ。
良い人材なら他社正社員でも引っ張る。超高待遇で。

169 :仕様書無しさん:2014/12/07(日) 18:08:14.57
>>168
そいつの不幸はお前含め、周りにチャンスを与えてもらえる環境が無いことだろ。
飼い殺しにするくらいなら放流しろや。

170 :仕様書無しさん:2014/12/07(日) 18:08:18.45
>>168
お前は何様だw

171 :仕様書無しさん:2014/12/07(日) 18:11:56.72
神様だけど?

それよりお前は何様?

172 :仕様書無しさん:2014/12/07(日) 18:16:14.27
お前が神様なら俺は界王神様だよ。

173 :仕様書無しさん:2014/12/07(日) 18:22:29.19
領収証には神様と書かせたり
外食で順番待ちのとこに神とか書くなよ

174 :仕様書無しさん:2014/12/07(日) 18:23:48.70
自分が人を使う立場だから神気取りとは
狭い狭い社会でお山の大将やのう。
おまいの立場肩書能力なんて、会社を一歩出れば通用せんだろう。

175 :仕様書無しさん:2014/12/07(日) 18:40:45.83
>>172
界王神の更に上とかあっただろ?
じゃあ、俺、それ

176 :仕様書無しさん:2014/12/07(日) 18:43:04.47
ここ見てると内製とか外注関係なくお前らには無理という事がよく分かる

177 :仕様書無しさん:2014/12/07(日) 18:43:25.55
>>172
Google検索

界王神
界王神 無能
界王神 ヘタレ
界王神様
界王神 弱い
界王神 役立たず
界王神 クズ

178 :仕様書無しさん:2014/12/07(日) 19:59:14.30
>>174
奴隷だからって嘆くなよ
お前のミスなんだから

179 :仕様書無しさん:2014/12/07(日) 20:07:14.38
>>168奴隷の身分にはキツイだろうが。コレ事実の指摘だよな。

180 :仕様書無しさん:2014/12/07(日) 20:54:13.72
派遣とか奴隷とか、ネット越しに相手の職業がわかると思い込んでるお子様が一人いますね

181 :仕様書無しさん:2014/12/07(日) 21:09:34.88
>>153
メインフレーム時代の内製の失敗事例を理解できない馬鹿がいるからだよ
ユーザにプログラミングを教えれば開発できる?
そういうのをメインフレーム時代はCOBOLerと言ったんだよ
で、そいつらがメンテナンス性皆無な糞コードを量産したおかげで、やがて内製システムは保守不能なお荷物となった
まともなドキュメントもないんで、コードから仕様を起こすか、廃棄して業務のやり方自体を変えるしかない
その後始末を泣く泣くベンダがやったんだよ
ユーザが作ったシステムはユーザが理解してる?
馬鹿いっちゃいけない。そんなことは絶対にないと断言できる
メンテナンス性はいらない?
そんなゴミみたいなシステムを何に使うつもりなのか

182 :仕様書無しさん:2014/12/07(日) 21:53:24.86
>>181
コンピュータ黎明期の50年代〜60年代に起きたことを、オフコン、ダウンサイジング化、
インターネット初期、そして今と繰り返しているからねえ。

本来なら学問として体系的に学ぶ必要があるのだが、現場原理主義というか、
ちょっとした学習で稼げるようになっちゃうから学問としてのCS軽視がまかり
通っている。 もちろんコンピュータそのものも進歩に追いつけていない部分も
あるし、学生の質もお世辞にも高いとは言えないからね。 それでも学校で
学ぶことを軽視しすぎなんだよな。

183 :仕様書無しさん:2014/12/07(日) 21:58:26.73
メインフレーム、COBOLで開発を一切やってないところもあるんだけどねw
>>181

184 :仕様書無しさん:2014/12/07(日) 22:15:36.87
>>183
だから何?
PL/IでもRPGでも同じことだよ

185 :仕様書無しさん:2014/12/07(日) 22:31:16.56
>>182
同意
まだ脳が若々しい時代に優れた環境で学ぶ意義は大きい

186 :仕様書無しさん:2014/12/07(日) 22:53:51.86
>>175
http://tiyu.to/image/news/21_12_25_02.jpg
お前の階級はこの中だとどれよ

187 :仕様書無しさん:2014/12/08(月) 00:03:04.56
>>186
その一番上当たりの
エロ・ハナターレってやつだ。

188 :仕様書無しさん:2014/12/08(月) 07:38:08.25
>>164
どっちが無知なんだ?
客に金もらって客が要求していることを
要求仕様書としてつくれないシステムや。が無知なんです。

189 :仕様書無しさん:2014/12/08(月) 12:35:53.53
要件とは俺たちにとって羅針盤のようなものだ
それを客まかせにしてたんじゃ
たどり着いたらいつも雨ふりで当然だ

190 :仕様書無しさん:2014/12/08(月) 13:58:31.24
しかし顧客は自分の示した道は明るく正しく、後は単純作業と疑わず、
さっさと作れと話を聴こうとしない。

191 :仕様書無しさん:2014/12/08(月) 15:29:08.16
雑誌で上っ面だけ書いた記事を読んで、分かった気になってるクライアントが厄介。

192 :仕様書無しさん:2014/12/08(月) 17:52:38.00
基本情報処理も受からないアホどもで混沌としたなんちゃってシステムや。ばかりだから。

193 :仕様書無しさん:2014/12/08(月) 18:00:10.39
高度いくつか持ってるが、関係ない。

194 :仕様書無しさん:2014/12/08(月) 18:02:47.34
>>181
メインフレーム時代からの崩壊をちゃんと知らない人が語っておるわw

メインフレーム創世記〜中期
 その会社の電算部の人間とメインフレームのメーカーのその業界専門の人が専属でやっていた。
 技術的な詳細な部分は、メーカーの専属の人に。
 業務部分のプログラミングは、その会社の人が組んでいた。何十年も。
 結果として、システム技術的な補佐をメーカーのプロがやって、その会社の人がプログラミングをやるから業務に精通した。
 これは、非常に上手くいっていた。

メインフレーム終期
 ダウンサイジングやアウトソーシング等々が大々的に叫ばれて、派遣社員で人員を埋める手法をとりだした。
 オープン化という文言の前にメインフレームメーカーの業界専門の人もどんどん端っこへ。
 結果、あっという間に、電算部門の縮小化等々もあり、誰も業務を知らない状態へ。
 そして崩壊。

派遣や外注を選択した情シスは即刻排除しないとガンにしかならない。
その最たる例が某銀行。

普通の技術レベルを持っている人なら、人数を大量に募集するなんて馬鹿げたことはしない。
必要なのは勘定系のシステム経験者を少数厚遇で迎えること。
もしくは、不要な人材の削除による情報伝達や役割の明確化。

195 :仕様書無しさん:2014/12/08(月) 18:28:55.05
お前らが長々と語ってるのは問題認識と理想論だけw
どう行動していくかという視点がないから、いつまで経ってもゴミクズなんだよw

196 :仕様書無しさん:2014/12/08(月) 18:38:52.32
>>195
どう行動していけばいいんだw

197 :仕様書無しさん:2014/12/08(月) 18:41:35.86
>>196
既に何人か動いてたジャン

198 :仕様書無しさん:2014/12/08(月) 18:50:54.55
>>197
Roger

199 :仕様書無しさん:2014/12/08(月) 18:52:16.06
COBOLをやっていた人を叩きたいだけじゃない?
ここの人達変
言語も、その言語で開発していた人は何も悪くない

200 :仕様書無しさん:2014/12/08(月) 19:07:11.89
>>199
COBOLerと馬鹿にするけど、メモリ32Kbyteしかなく、プログラムを手作業でセグメント分割して実行させるとか、今考えると離れ業やってるんだよなw

201 :仕様書無しさん:2014/12/08(月) 20:27:30.41
COBOLerはそんなことやってないよw
大企業の、金計算しているだけだけど

大企業だから金はあった。マシンも当時としては
いいものが使えていた。

202 :仕様書無しさん:2014/12/08(月) 20:43:51.32
心が病んでいるねw

203 :仕様書無しさん:2014/12/08(月) 20:47:55.95
>>201
普通にやってた
てかやんないと動かせないもの

204 :仕様書無しさん:2014/12/08(月) 20:50:12.75
cobolerは事務的な作業しかできないという前提が崩れるから言っても信じないw
まぁ、セグメントで分けて実行したりするやり方知ってるか知らないかだけだけど

205 :仕様書無しさん:2014/12/08(月) 21:11:57.65
>>203
やってないというか、メモリ32kbyteの
ハード自体がないから。

206 :仕様書無しさん:2014/12/08(月) 21:22:54.38
50年くらい前の銀行に導入されたばかりのシステムとか、

207 :仕様書無しさん:2014/12/08(月) 21:35:01.13
>>194
> 結果として、システム技術的な補佐をメーカーのプロがやって、その会社の人がプログラミングをやるから
> 業務に精通した。 これは、非常に上手くいっていた。

ダウト
メインフレーム時代の内製システムの崩壊はシステム技術的なものによるのではなく、純粋に適用業務プログラム
部分のお粗末さによるもの
メインフレームにおけるメーカーの保護は分厚く、デバグができないCOBOLERの代わりにコアを解析してくれたり
夜中の2時に内製部分に起因する障害が発生してもすぐに駆けつけてくれたりした
至れり尽くせりだったにも関わらず、お粗末なコードを量産している内製システムはそれゆえに崩壊した

208 :仕様書無しさん:2014/12/08(月) 21:58:46.19
>>207
内もできない奴に限って
こうゆうことを言い出すんだよな

209 :仕様書無しさん:2014/12/08(月) 23:14:19.66
能無しが夢を語るスレでそこまでいうか。
お前もそうなんだろ。

210 :仕様書無しさん:2014/12/08(月) 23:21:52.23
ほくのかんがえたさいきょうの自社しすてむスレだからね

211 :仕様書無しさん:2014/12/09(火) 06:21:22.99
きっくるばー

212 :仕様書無しさん:2014/12/09(火) 12:12:43.87
>>207
そういう契約してるなら当然だろうwww
馬鹿ですか?w

213 :仕様書無しさん:2014/12/09(火) 17:37:57.01
>>212
俺もそう思うw

214 :仕様書無しさん:2014/12/09(火) 17:39:28.82
内製したらバグが出た
ただそれだけのこと。
外注だとバグが出ないとでも?w

215 :仕様書無しさん:2014/12/09(火) 18:53:43.88
>>207
そういうのを上手くいっていたっていうのでは・・・・・・・?

216 :仕様書無しさん:2014/12/09(火) 19:23:32.79
>>215
「こうやったら(たまたま)上手く行った」事例を挙げてるだけなのか、
「こうやったら上手くいく」というノウハウとして考えてるかで、発言者によってすれ違ってる気がする。

217 :仕様書無しさん:2014/12/09(火) 19:53:10.71
>>216
そういうときのために専属で契約してるなら何の問題も無いと思うが?

218 :仕様書無しさん:2014/12/09(火) 21:54:20.43
文体とwで自演がよくわかるね
日中から2ちゃんなんてしてないでハロワにでも行くべきだね

219 :仕様書無しさん:2014/12/09(火) 22:03:52.08
>>215
システムが保守不能のお荷物になった時点で失敗だろう
技術サポートがどんなに手厚くても素人コーダーを補えるものではないということ

220 :仕様書無しさん:2014/12/09(火) 22:51:05.22
>>218
自笑エスパーさんこんにちは。
残念ながらあなたはエスパーじゃないよw

221 :仕様書無しさん:2014/12/10(水) 06:21:30.09
>>219
ある時バグが出た

それだけの思い出話にしか見えませんが?

222 :仕様書無しさん:2014/12/10(水) 17:01:23.11
>>32
設計書は本当に簡素なものでいいな
ドキュメントに書くべきことは限られてる

223 :仕様書無しさん:2014/12/11(木) 11:09:25.68
☆☆☆☆☆
               /  /     /   |      \ ヽ
               / /  /   / /    ||  |  i  ヽ i
              i /  / /  / / /    ||  ||  |│ |ノス
               |//  / /___, -一ァ|  /! |ト、|│ | | く」
                |,-‐¬  ̄---┘'7 |!  ハ! |,、-┼十|! | | |
          , -‐ ''"  し' '´_ /,ィ二l |ト、/!ヽト、\_ヽ!|!l | ハ |
       ,r/      __   ,イ|リ ヾハ! ヽ!  ,ィ⌒ヾミリノ!/リ  | ☆ 自民党、グッジョブですわ。 ☆  
      / ||ヽ  -'     / ̄ )` __      |ヒノ:} '` ,イ/ |  |  http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
    ,r '   ヾ、  ,-、____ , イ ̄,r==-      ==-'  レ' /|  |  
  / ヽ    `ーソ  ' | |ト、,ヘ ′""          "" / / || | ☆ 日本国民の皆様、12月14日(日)の
. /    \_  /  | ハ ヽ`゙'ヘ       ' '__. ィ  / / | |  |     『衆議院議員総選挙』に必ず投票にいきましょう。 ☆  
           /   / / |  ヽ 川\    ヾ三ニ‐'′//! |  | |  |   
        /    / / 八  \川| |`ト- ..  __ , イ‐ァヘ |  | ||  |!
      /    / / /  \  \ 「`ー- 、    /  .〉  ト、|  ヽ、
     ,イ    /-─=¬ニヘ、_  \   厂\ 厂ヽ /!|   | `ー=ヘ
 -‐  ̄ /─ '  ̄     ├- ヽ\  \ノ\ \ 人 ハ!ヽ ||  |-┤ ヽ
      /          /!‐-- | |\   ト、_`ヽ oヽ  ト、!  ||  |‐┤- ヽ
  // 〉      __ /  ├‐-  ||  | 川-‐  | |  厂7! ハ!  ├:┤  ̄ヽ
  / / ー ─    ̄       ├‐- リ  || ハ!ヘ   | |  ト┤|/′ ヾ,┤   ゙i_
  ‐ '              〉‐-    | / /\ .|o | /ヽ/(′    ∨     \
‐--─ ──-r、___-、    /ー_     {(   '´>、! /ヽ/       |\       \

224 :仕様書無しさん:2014/12/11(木) 17:50:02.44
冷静な返しの前に沈黙w

225 :仕様書無しさん:2014/12/16(火) 19:47:55.42
業務でやるプログラマは、基本的に伴奏者だということを理解しろ。
ソリストとしてやりたいなら、趣味や科学技術者として、その分野でやれ。

226 :仕様書無しさん:2014/12/16(火) 22:49:44.43
クリエイティブを求められる度合いは食堂未満だな

227 :仕様書無しさん:2014/12/16(火) 22:50:47.00
例えるなら理髪店か。
お客様のご要望に沿わなければ、失敗に属する。

228 :仕様書無しさん:2014/12/16(火) 23:07:38.85
>>227
ハゲの客に「ボリューム感を出してくれ」って無理難題突きつけられるんだろな

229 :仕様書無しさん:2014/12/16(火) 23:54:12.15
モヒカンでサイドは流す感じで

230 :仕様書無しさん:2014/12/17(水) 01:29:07.35
>>228には植毛を勧め、
>>229には逆モヒカンでサイドを流す

231 :仕様書無しさん:2014/12/17(水) 02:54:50.43
>>230
同じ言葉が入ってれば良いというもんじゃないだろ。

232 :仕様書無しさん:2014/12/17(水) 05:47:46.44
>>227
いろんな例が出てきたが、シンプルで一番わかりやすいなw
お前の例えがwww

233 :仕様書無しさん:2014/12/17(水) 18:24:23.25
ある大病院の中に長期入院患者向け理髪店があって俺もカットしてもらったんだが、
技術向上する気が全然感じられなかった。病院の中は、似たような髪型の患者ばかり歩いてるww
自社技術者に通づるだろうか

234 :仕様書無しさん:2014/12/18(木) 07:31:33.14
んなもん注文しないからだろww
勘違いが多いが、床屋と美容室で可能な髪型は変わらない。眉も。
床屋だと凝った髪型を注文しないのが多いというだけ。

235 :仕様書無しさん:2014/12/18(木) 12:40:38.64
なんだこの床屋ハカセ

236 :仕様書無しさん:2014/12/18(木) 16:57:26.80
床屋や美容院では実作業者と客が直。
これ間に人が入ってたら無理だよねー

しかも、完成後に訂正まで聞くし利くし。
これによって注文後に本完成した後ですら、仕様変更が利く。
よって顧客の満足が得られる。

ITは検品は許しても仕様変更で追加の金要求してくる。
だから不満だらけ。

237 :仕様書無しさん:2014/12/20(土) 03:03:18.37
>>236
丸刈りにした後に、ボリューム出せと言われても無理。

238 :仕様書無しさん:2014/12/20(土) 07:47:42.94
>>237
ウィッグつかってくるよw

239 :仕様書無しさん:2014/12/20(土) 08:41:34.38
うちがシステムを納品して保守もやっている得意先A社があって、そこの子・孫会社のシステムは他社製品
A社に3年出向して、さらにA社の子会社、孫会社へ出向してシステムの不満が多いから、それの実態調査ということでやることになった
(給料は元の会社から800万、A社から800万の折半)肩書きはA社の幹部候補社員

いままでは開発現場にしかいなかったから始めて知ったけど、
このスレで客側の立場の人の声がいっぱいあるけど、実際その立場になるとホントそのとおりだと思うことだらけ
内製をしていない情報システム部門(担当)が邪魔ということと、実装している連中がなんにも現場をわかっていないということ
できあがったソースから明らかにレベルが低いプログラマが実装していること
//ここを外すとなぜか上手く動かない とか本当にコメントで残っている
その変数の動きをトレースすると原因がスグに見つかる。これを見つけられないレベルか…と思う
現場の人に「こういう風なのがきたらエラー起きません?」って聞いたら「そうなんです」と返ってくる

2年目にシステムを作ってる会社の連中との中規模仕様変更・リプレイス等々の話しに参加
相手は、こっちがシステムに精通しているものがいないと思ってるから、話を盛る盛る
そこで素人のフリして、そのときお願いしているシステム変更の作業現場を見させてもらったら全員スーツ
しかもあきらかに着慣れていないので、客が来るからと体裁をとったのだと思うが、完全に派遣社員だらけ
直接、専門用語使って話しかけたら、「あ・・・あ・・・・えっと・・・」と一人も応えられない
これが客側の立場から見た現実なんだと思った

ウチが子会社孫会社のシステムも奪い取るつもりなので酷評を提出するつもりだったw
それを抜きにしても請けた会社が実装をしていない業態のところは悲惨だと思った
派遣社員がいる開発会社は使うな!というのは正しいと思う 業務知らずして実装なんてできるわけがない

240 :仕様書無しさん:2014/12/20(土) 12:29:31.63
末期のコーダーやね…

241 :仕様書無しさん:2014/12/21(日) 07:41:05.51
>>239 現在のIT業界がまともなシステムを作れない構造だってのは、両ポジションを取ったことのある人しかわからんのさ。開発の立場、受注の立場、客の立場。末端派遣、元請け経験なしのプログラマには永久にわからないこと。

242 :仕様書無しさん:2014/12/21(日) 11:00:40.23
開発を経験しなかったらなにもわからない
開発というのは、問題解決能力だ
開発にたずさわると、次々と起きる予測外の出来事を処理する能力が養われる

マニュアルに書いていないからできないというのは、開発という場ではいらない。
法律に則り行動するというのは論外。アホの典型だね。管直人みたいなもんだな

243 :仕様書無しさん:2014/12/21(日) 14:59:53.26
要は、開発というのは想定外の現場というわけさ
マニュアルがなくちゃできないというなら、開発にはマニュアルはないよ

244 :仕様書無しさん:2014/12/21(日) 15:55:29.09
開発と言ってもお前らのやってる開発はテキストどおりだろ

245 :仕様書無しさん:2014/12/21(日) 17:56:38.72
>>244
使いやすいUIの作り方なんてテキストに載ってないんだが

246 :仕様書無しさん:2014/12/21(日) 18:57:24.42
だからお前らの作るシステムは使いにくいのか

247 :片山博文MZ ◆T6xkBnTXz7B0 :2014/12/21(日) 19:10:43.65
「GUI ガイドライン」で検索

248 :仕様書無しさん:2014/12/21(日) 19:16:45.97
だいたい人間の操作自体省くべき。
人間は処理フローとデータのみ作成してあとはシステムがオートで処理してく。
これがシステム化というもの。

249 :仕様書無しさん:2014/12/22(月) 04:29:54.71
UIはデザイナー任せ

250 :仕様書無しさん:2014/12/22(月) 12:42:23.58
コードはコーダーまかせ

251 :仕様書無しさん:2014/12/22(月) 17:00:03.81
今どきコーダーとか居るの?

252 :仕様書無しさん:2014/12/25(木) 13:19:00.19
2人と言っても3Pとかではない。
店が終わり、客とホテルに直行し何度か抱かれた後に、別の客と待ち
合わせてホテルでSEX。
特に2人目の客がメチャ絶倫で5回もされてしまったからだ。
帰りが遅くなったのはその為だったのだ。
それで逝かされまくりクタクタに疲れてしまったのだった。
寝入るおそよ約5分間に、
「あなたダメ...もうだめ!ごめん...もうクタクタなの。
 何回もしちゃったの...」
こんな事を言いながら気を失うように寝入った。
ママには辞めるとは伝えていない。反対するのは目に見えているからだ。
年始は6日くらいから営業するとママは言っていた。
当然、瞳はもう出勤しないから年始の初営業には俺が言って真実を告げ
ママと話を付けるつもりでいたのだ。

253 :仕様書無しさん:2014/12/25(木) 13:45:58.30
なにこの誤爆。

254 :仕様書無しさん:2014/12/27(土) 02:08:31.64
社内SEの人って、毎日何をしてんの?

255 :仕様書無しさん:2014/12/27(土) 04:49:52.77
>>254
CapsLockを解除するお仕事です。

256 :仕様書無しさん:2014/12/27(土) 08:14:39.15
>>254
毎日、仕様変更対応
開発フェーズが終わったら・・・・・・・・って結構言われるけど、永久に開発フェーズなんだよね。内製をやってると。
微修正に微修正を重ねてるから、その会社にとっては最高のシステムになる。

それも、馬鹿な管理職・役員が一人入ると終了。
機能が超ダウンした新システム導入の話しを持ち出してきて。(自分が入ったことで職場が変わったことをアピールしたいのかなんなのか)
新システムを内製で行うのではなく、外部システム導入で実施する方向で確定済み。
社内SEとしては、そちらの予算でやるなら強くも言えず。勝手にどうぞ。
勝手にどうぞという気分だし、社内SEは仕様運用は完璧に知っていても、馬鹿管理職がほぼシステム仕様等々は外注のシステムを飲んでるから、
社内SEに発言のタイミング等々を与えないし、要求仕様等々を提出する機会も権限も与えない。そのクソ外注システムとの窓口担当だけの立場に。
外注システムの仕様書もソースもない状態で、システム管理者ではないので現場の運用状況を見ることも出来ず、そんな状況だから対応できるわけもなく、
外注システムへの不平不満は解消されることは当然なく。
気がつくと、その間にいる社内SEが無能という評価になっている。予算管理すべて、自分達でやると言っておきながら・・・・・。

コンサルでいろいろ見てるけど、このパターンがホント多い。
内製システムを使っていて、そこから完全新規システムを作る!というときに、改めて新システムを内製という発想になっている会社は1社も見たことがない。
仕様や要望、問題を全部把握している社内SEの人に、「ゼロから作っていいぞ」というお墨付きを与えれば伸び伸び作ってくれるだろうに・・・。

と何度思ったことか。

257 :仕様書無しさん:2014/12/27(土) 11:38:29.78
>>256
内製システムがあって、さらに内製でゼロから内製って確かに聞いたことがない。
内製スタッフも結構考えることだよね。今のシステムを一回捨てられたらって。でも今のシステムで実現できてるなら今のでいいじゃんで没。
ところが外注パッケージだとOKになる不思議w

258 :仕様書無しさん:2014/12/27(土) 11:54:47.08
運用実績重ねたシステムは仕様が肥大化してソースも汚れてくから
そいつを一から作り直す工数が肥大化するのは当たり前
そんで既存システムと比べてつぎ込んだ工数に対してのメリットが要求される
経験年数あるやつならすぐに理解できる地雷案件だし
動いてるもんでいいじゃんって発想は自然

契約結ぶ事だけ考えるやつはそれを隠して着工する
地雷案件何度も潜ってるやつと温室育ちじゃ勝負にならんから余裕で責任転嫁可能よ

259 :仕様書無しさん:2014/12/27(土) 12:05:49.18
リファクタ馬鹿がいたけど、あの馬鹿のレベルでは大反対

でもリファクタ自体は全く否定されるべきことではない頻度の問題
内製システムも極端な話し、超巨大システムでなくシステムを分割できるならば担当が替わるごとに、リプレイスを考えてもいいんだよね
担当交代にともなうシステムの仕様の把握とそれ以降の仕様変更への対応速度のアップがメリットになるかな
もちろん担当交代は正社員で最低でも10年くらいの周期はほしいけどね

260 :仕様書無しさん:2014/12/27(土) 12:14:54.29
突如発表された『拡散性ミリオンアーサー』 サービス終了の真相を訊く
ttp://app.famitsu.com/20141226_479007/
> そのタイミングでプログラムを1から作り直そうという話もあったんですが、
> 通常の運営をしながら並行して新規でプログラムを作るのは思った以上の難易度で、
> 想定していた作りにはなりませんでした。
> 結果、運営のしやすさはさほど変わらない状態で、新しい仕組みを取り入れることも難しくなっていました。

261 :仕様書無しさん:2014/12/27(土) 12:37:35.82
>>259
現実的じゃないじゃん。

最低条件として、担当者は数人〜数十人規模になるし
社員(開発者)としての周期は5年もないだろう。
そして、常にバージョンアップしていかないといけない。

この条件を満たさない案は役に立たないよ。

262 :仕様書無しさん:2014/12/27(土) 13:04:15.79
その不可能を情シスもたないでユーザーが好き勝手作ってるところは毎回やってるんだけどねw

263 :仕様書無しさん:2014/12/27(土) 13:51:22.47
>>256
うちは今その内製の再構築を内部でやり始めてるよ。
外注ゼロw
内容は詳しくかけないけど、社長のお墨付き。
ブツブツいう役員は居るけど関係ない(・∀・)

何を隠そう初版つくったのおいらだからワクワクしてるw

264 :仕様書無しさん:2014/12/27(土) 14:21:59.56
>>263
いーなー
ウチじゃ絶対無理。

265 :仕様書無しさん:2014/12/27(土) 18:06:33.17
>>257
内製に限らず長い期間やっているシステムの開発に携わるようになると一度は
今のごちゃごちゃなシステムを捨てて新しいので作り直したいと。

金融系なんかもホストそのものやオンラインまわりをどうにかしたいと思ったり
するけれど、開発を続ければ続けるほど業務以外に金融法や行政指導が層に
なってシステムに積み重なったりを見ていると一生を捧げるに近いものに見えて
このままでしか無理だなとはんば諦める。

266 :仕様書無しさん:2014/12/27(土) 18:19:14.03
>>263
>>内容は詳しくかけないけど、社長のお墨付き。
社長がいる間に完成させろよ。

267 :仕様書無しさん:2014/12/27(土) 18:38:19.23
一度捨てて、ていうのはほぼ無理だから。
日々の改修の中に、将来的な修正を仕込みつつ
今あるシステムを少しずつリプレースしていくしかない。

268 :仕様書無しさん:2014/12/27(土) 19:16:57.57
>>265
知れば知るほど、これ・・・・無理wってなるよなwwwww
そんなもんを業界人じゃない人にぜーーーーーーんぶもれなく説明して理解させて何人も伝言ゲームしてシステムを完成させる。
むりや・・・・。

269 :仕様書無しさん:2014/12/27(土) 21:09:34.48
>>265
× はんば
○ なかば

270 :仕様書無しさん:2014/12/27(土) 22:56:27.74
>>256
> 外注システムの仕様書もソースもない状態で、システム管理者ではないので現場の運用状況を見ることも出来ず

外注システムの面倒をみてやろうとしてソースを要求すると、難色を示すのは情シスの馬鹿管理職だった
当然ソース公開は契約に入ってる
なるべくシステムには触りたくないらしい
情シスの管理職にこんな馬鹿よこした馬鹿経営
社内SEに馬鹿が何人か混じっても持ちこたえることはできるが、情シスの管理職が屑だとそれで終了

271 :仕様書無しさん:2014/12/28(日) 00:03:16.53
今時のどの職業もそうなんだけど最低限以下の人数で回さなければならないから
その時点で出来ないだけならともかく、目を背けるようなのは害にしかならんよな。

272 :仕様書無しさん:2014/12/28(日) 08:05:28.82
>>270
ソースがあっても、修正したら保守対象外とかになるんだろ
他社のどこの馬ともわからん派遣が作ったシステムなんてやりたくねーだろ

273 :仕様書無しさん:2014/12/28(日) 18:15:24.14
伝言ゲームの件は、
当事者意識が有るか、開発失敗すれば自分も痛いなども含め、内製の方がマシだと思う

しかし、社内であっても縦割り、部門別で個別最適をと取ろうとする会社だと外注に等しい。

開発会社と対等の立場で要件定義から金を出すならば、内製に近い位には出来る。

問題はコレができてないこと、金を出す方が偉い(お客様は神様)や、上下関係や変な政治力が。
また、開発会社自身が多重下請け構造にする事、こっちの方が大問題

内製も理想だけれど、会社規模が小さい他、
SI会社でも駄目な所が少なくないのに維持管理まで上手く回せる所はレアだろう。

274 :仕様書無しさん:2014/12/28(日) 19:11:50.41
>>273
規模に関して言えば外部から買えないような数十人規模程度の小回りがきく
会社か、逆にでかくて内部に金を使える規模の会社位だと思うよねえ。

275 :仕様書無しさん:2014/12/28(日) 19:31:10.37
内製すべきって人はどれくらいを想定してるの?
オフコンはまず無理だろうけど
Accessみたいの使うの前提?

276 :仕様書無しさん:2014/12/28(日) 21:54:36.96
人気スマホゲーが終了した理由 「コアのプログラマが辞めたせいでプログラムがブラックボックスになってしまった(c)2ch.net
ttp://hayabusa3.2ch.net/test/read.cgi/news/1419749378/
> 316 名前: ダイビングヘッドバット(岐阜県)@転載は禁止[sage] 投稿日:2014/12/28(日) 20:10:42.04 ID:W1DLQP0S0
>  いま勤めてる会社がこの状態
>  社内システムのプログラム書くのもサーバー保守するのも自分一人
>  
>  最近うすうす辞めたいと思ってるけど、すんなり辞めれるとも思えない
>  でも後継雇って引き継ぎなんて話になったら、どんだけ掛かるか分からんしなあ…

> 351 名前: ハイキック(庭)@転載は禁止[sage] 投稿日:2014/12/28(日) 21:18:23.72 ID:A2pUIkiN0
>   >> 316
>   全く一緒

277 :仕様書無しさん:2014/12/28(日) 22:07:56.98
>>275
すでに内製開始した人たちはlinux使ってるようだしマイコン等々も使ってるようだし。
思っている以上に実力者がこのスレにはいる気配

278 :仕様書無しさん:2014/12/29(月) 01:13:47.17
>>275
クラウドとオンプレミス混在した自社システム
くらいかな?想定というか今着手してる奴は
オフコンは独立稼働してるけど、Windows&Linux混在や
C/S&Web混在は当たり前の状態ですわ

279 :仕様書無しさん:2014/12/29(月) 08:04:25.91
Accessしか環境がないからAccessという人はたくさんいると思うよ。
でも、Accessだからって規模は図れないでしょ。
同じデータだけど、それを手作業で分類して、ファイルを分散して処理する方法もあるし。
まぁ、頻繁の更新があるものは向かないわな・・・。唐突に壊れるから。

勘違いしている人が多いけど、今の時代で新規に作るシステムなら業務システムだから大規模・中規模とかないから。
もちろん過去のシステムなら分割不可能な状態になっているもの(ならざるを得ないもの)も多数あるけど。
モジュールの分割は当たり前の概念なのにシステムと表現するとなぜ大規模な一本のプログラムと思うのだろうか?
フリーウェアを連結してシステムを組んでもかまわないというのに。問題を解決すればいいんだから。

280 :仕様書無しさん:2014/12/29(月) 08:54:30.83
低脳だと何でも詰め込みたがるもの

281 :仕様書無しさん:2014/12/29(月) 09:00:30.30
問題を解決するための手段
ってのを正しく理解して実行に移しているプログラマの少ないこと少ないこと

282 :仕様書無しさん:2014/12/29(月) 12:31:20.18
アクセスで大規模はありえんわw

283 :仕様書無しさん:2014/12/29(月) 16:37:57.96
>>279
Accessしか無いってどういうこっちゃ
せめてMySQLとかPostgreSQL使えばいいと思うが

284 :仕様書無しさん:2014/12/29(月) 17:10:40.42
>>283
必ずしもシステム開発者だからといって開発部門にいるとは限らない
ユーザー端末にはまともに環境がないことは多々ある

285 :仕様書無しさん:2014/12/29(月) 17:52:21.60
M$信者なんだろ。

286 :仕様書無しさん:2014/12/29(月) 22:34:16.01
MS信者じゃなくても会社の端末じゃー。自分で選択できない人も普通におるだろ。

287 :仕様書無しさん:2014/12/29(月) 22:35:46.45
人気スマホゲーが終了した理由 「コアのプログラマが辞めたせいでプログラムがブラックボックスになってしまった(c)2ch.net
ttp://hayabusa3.2ch.net/test/read.cgi/news/1419749378/504+515+517+509+535
> 504 名前: キングコングニードロップ(大阪府)@転載は禁止[sage] 投稿日:2014/12/29(月) 10:46:10.66 ID:/C9Dx9FN0
>   ネットワークエンジニアかインフラエンジニアか、どっちに進もうか迷ってる俺にアドバイスくれ
>   20後半

> 515 名前: ジャンピングパワーボム(茸)@転載は禁止[sage] 投稿日:2014/12/29(月) 12:40:37.54 ID:5x3iq23t0
>  >> 504
>  日本のインフラ系の多くが国内志向だから、将来大規模リストラあるだろう
>  しかも日系企業は独自のシステム使いたがるから、スキルがよそで役に立たない

> 517 名前: 頭突き(SB-iPhone)@転載は禁止[] 投稿日:2014/12/29(月) 12:50:52.29 ID:0mx2fvHJ0
>   >> 515
>   SI系はそうかもしれないけど自社サービス系ベンチャーはわりと海外でもやってる技術を採用してたりするよ。
>   まあ、周りのレベルめちゃ高いから勉強を辞めたら死ぬけどな。


> 509 名前: バックドロップホールド(千葉県)@転載は禁止[sage] 投稿日:2014/12/29(月) 11:34:39.55 ID:JGcaHcmD0
>   >> 504
>   インフラに進んで社内SEとして働く退路を確保

> 535 名前: 閃光妖術(SB-iPhone)@転載は禁止[sage] 投稿日:2014/12/29(月) 14:55:02.39 ID:/SrLkr6r0
>   >> 509
>   社内SEはリストラされるんじゃないのかな

288 :仕様書無しさん:2014/12/29(月) 22:48:48.56
人気スマホゲーが終了した理由 「コアのプログラマが辞めたせいでプログラムがブラックボックスになってしまった(c)2ch.net
ttp://hayabusa3.2ch.net/test/read.cgi/news/1419749378/504+515+517+509+535http://hayabusa3.2ch.net/test/read.cgi/news/1419749378/430

> 504 名前: キングコングニードロップ(大阪府)@転載は禁止[sage] 投稿日:2014/12/29(月) 10:46:10.66 ID:/C9Dx9FN0
>   ネットワークエンジニアかインフラエンジニアか、どっちに進もうか迷ってる俺にアドバイスくれ
>   20後半

> 515 名前: ジャンピングパワーボム(茸)@転載は禁止[sage] 投稿日:2014/12/29(月) 12:40:37.54 ID:5x3iq23t0
>  >> 504
>  日本のインフラ系の多くが国内志向だから、将来大規模リストラあるだろう
>  しかも日系企業は独自のシステム使いたがるから、スキルがよそで役に立たない

> 517 名前: 頭突き(SB-iPhone)@転載は禁止[] 投稿日:2014/12/29(月) 12:50:52.29 ID:0mx2fvHJ0
>   >> 515
>   SI系はそうかもしれないけど自社サービス系ベンチャーはわりと海外でもやってる技術を採用してたりするよ。
>   まあ、周りのレベルめちゃ高いから勉強を辞めたら死ぬけどな。


> 509 名前: バックドロップホールド(千葉県)@転載は禁止[sage] 投稿日:2014/12/29(月) 11:34:39.55 ID:JGcaHcmD0
>   >> 504
>   インフラに進んで社内SEとして働く退路を確保

> 535 名前: 閃光妖術(SB-iPhone)@転載は禁止[sage] 投稿日:2014/12/29(月) 14:55:02.39 ID:/SrLkr6r0
>   >> 509
>   社内SEはリストラされるんじゃないのかな

289 :仕様書無しさん:2014/12/29(月) 23:03:54.74
>>284
>>286
なるほど。そこら辺のPCにMySQLとかApacheとか入れて、適当な現場用システム作ってるうち(ここでいうユーザ企業)がおかしいのか。。。

290 :仕様書無しさん:2014/12/30(火) 00:35:30.24
>>287-288 は書き込みエラーになってたんで


”Apache禁止” でググると中国語しか出てこないよ。
中国文字を除外しても除外しても中国語しか出てこない。
日本語に絞ると3件だけ残る。

システム専用端末を用意できない規模なんて知れてるよ。

291 :仕様書無しさん:2014/12/30(火) 10:00:39.54
>>289
おかしいね。残念ながら。
だって誰かが著作権違反するかもしれないし、誰かがウイルス感染したプログラム実行するかもしれん。
現在の企業で、まともなところ(有能という意味ではない。ある程度組織だっているということ)なら禁止されるから。
禁止が書面禁止程度で終わっているところも多々あるけどw

292 :仕様書無しさん:2014/12/30(火) 10:27:17.88
Windows なら UAC があるんだから迂回されない限りは禁止できるんじゃないの?

293 :仕様書無しさん:2014/12/30(火) 11:11:27.55
>>286
サーバーだったら関係ないだろ。

294 :仕様書無しさん:2014/12/30(火) 14:21:55.96
>>293の意味がわからない・・・・

295 :仕様書無しさん:2014/12/30(火) 15:01:45.04
>>294
そうだな、関係ないは言い過ぎだな。
非windowsサーバーとか普通にあるし、httpとか非MSなプロトコルでサービスするとか普通だろ。

296 :仕様書無しさん:2014/12/30(火) 16:30:23.24
>>295
公式に開発環境が与えられないけど開発能力がある人の話では?
わかりやすく言えば元プログラマが事務員やってるケース。

297 :仕様書無しさん:2014/12/30(火) 16:42:20.55
>>296
利用者の話はしてないと思うが。

298 :仕様書無しさん:2014/12/31(水) 10:11:17.55
今一体何の話してるの?

299 :仕様書無しさん:2014/12/31(水) 13:22:10.32
最初から開発の話だろ。

300 :仕様書無しさん:2014/12/31(水) 17:02:07.21
Accessじゃショボいシステムしか作れないという事実を指摘されて
発狂してる子が居るだけですよ

301 :仕様書無しさん:2014/12/31(水) 19:38:27.44
>>297
開発環境を持たないユーザーが、目の前にある環境だけでシステム開発してるケースは多々ある

302 :仕様書無しさん:2014/12/31(水) 19:47:38.78
開発環境なしで開発とかありえん
まあMS製品は多少の環境があったりするけど

303 :仕様書無しさん:2014/12/31(水) 21:25:05.54
Excel VBA だって立派な開発環境だ

304 :仕様書無しさん:2014/12/31(水) 21:43:04.07
>>301
それは外注するかどうか以前でスレチだろ。

305 :仕様書無しさん:2014/12/31(水) 21:46:34.67
VBAの行き詰まり 2009/07/02
ttp://itpro.nikkeibp.co.jp/article/OPINION/20090701/332992/

> 書籍に対する意見などを送ってくれたのは,普段から業務でExcelを使っている事務職の方,そして小規模な企業の方がほとんど
> 個人や小規模組織が期間限定で使うようなプログラム

> VBAはあまりに便利だったので,本来使うべきではないところにも使われてしまった。
> それが現在のVBAの行き詰まり感を生んでいるのかもしれない。

306 :仕様書無しさん:2015/01/01(木) 00:45:29.95
>>305
ゲイツ氏のもっとも愛したのが大衆向けBASIC。
それを具現したVBAは普通の事務員のねえちゃんでもシステム開発できる素晴らしいものだった。
「だった」

307 :仕様書無しさん:2015/01/01(木) 01:49:22.12
つづき

> VBAをバージョンアップする代わりに,オフィス・ソフトのアプリケーションを開発する環境
> 「VSTO(Visual Studio Tools for Office)」を2003年にリリース。
> 当初は開発ツールVisual Studio(VS)のオプション製品として販売していた
> VS 2008からは付属して提供するようになった。

VSTOとは何か? ソリューションとアドインの違い
ttp://www.atmarkit.co.jp/ad/ms/vs2008/03/vs2008_03.html
> VSTOの良さは何といっても.NET Frameworkのパワーを存分に生かせることだ。

308 :仕様書無しさん:2015/01/01(木) 12:19:06.23
アニメーターは在宅勤務と常勤のどちらも完全にできている。
プログラマという仕事はアニメーターより遥かに、在宅勤務でできるし。
勤務地からの距離すら関係ない。
通勤コストや会社という無駄なスペース等々の無駄を排除できる。
コミュニケーションだって遠隔でも余裕でとれる。

ところが、未だに在宅勤務方式はアニメーターより遥かに割合は低い。
ほとんどが自社出社、他社出社をしている。
自分たちの仕事すらまともに効率化できない連中が、なぜ他人の業務を効率化できるというのだ?

309 :仕様書無しさん:2015/01/01(木) 12:27:31.32
>>303
これマジおおい
ソースの良し悪し別として、実際これで業務を回しているケースはおおい

310 :仕様書無しさん:2015/01/01(木) 14:01:05.70
>>308
在宅勤務の話は、言うまでも無く、情報漏えい等や、勤務時間の問題もあり、
情報自体の持ち出しに制限や、持ち帰り仕事も禁止が前提なので一概には言えない。

しかし、

>自分たちの仕事すらまともに効率化できない連中が、なぜ他人の業務を効率化できるというのだ?

というのはマジ本当

311 :仕様書無しさん:2015/01/01(木) 22:36:28.77
自分たちの仕事どころか
大半が派遣社員
自分の職業すらまともな位置に立てない連中が9割
DQN・バカ・無能になればなるほど身の程知らずで自分の評価が高い

312 :仕様書無しさん:2015/01/01(木) 22:42:48.45
接続詞の使い方が変だな

313 :仕様書無しさん:2015/01/02(金) 09:10:09.02
>>310
そういった自分らの問題解決システムも構築できない連中が「素人の作ったシステムは・・・」と言っている笑える状況。

314 :仕様書無しさん:2015/01/02(金) 13:15:24.47
まとめると

自分の派遣先のシステムをまともに改善することもできない無能な派遣社員が偉そうに意見するな発言するな考えるのもやめろ

ってことですね。

315 :仕様書無しさん:2015/01/02(金) 13:25:37.54
俺の先輩が言うには昔は医療の患者の情報すら家に持ち帰っても良かったらしいなあ
Winnyが問題になったあたりから厳しくなったとか

316 :仕様書無しさん:2015/01/02(金) 13:37:12.54
>>314
ずっと面倒見れるわけでもないシステムの方針を決めるとかするのか? 社員がやるべきだろ。

317 :仕様書無しさん:2015/01/02(金) 13:52:25.21
>>315
Winny前は、ほんとセキュリティ規定なんてなかったからね。
私物パソコンとか持ち込みは推奨されてたくらいwwww

318 :仕様書無しさん:2015/01/02(金) 13:53:07.56
>>316
在宅勤務で余裕で通用するはずのプログラマ業界の勤務形態が未だにずーーーーーーーーっと出社方式システムなのをなんとかしろw

319 :仕様書無しさん:2015/01/02(金) 14:06:17.84
>>318
フリーランスになって在宅で受けたら。

320 :仕様書無しさん:2015/01/02(金) 14:20:23.44
>>319
そう。それでやればいいのに。
現実は、そうではなく派遣が絶対多数。
フリーランスもフリーランスを自称してるだけで実際は派遣ってやつも多数。


在宅勤務じゃない理由は基本的にそんな有能な奴が必要なケースがまず無いってことなんだけどな

321 :仕様書無しさん:2015/01/02(金) 14:26:23.02
開発担当「有能な人間は必要ありません」

そらゴミしかできんわ。

322 :仕様書無しさん:2015/01/02(金) 15:39:35.54
>>320
机に座ってる時間や態度でしか評価できない管理職ばかりだからでしょう。
運用が別にいないならネットワークトラブルのために、拠点ごとに1人は居てほしいというのはわかるけど。
起業する経営者は自社ビルとか場所を持つことが目的になっちゃってるのかも。クラウドでオフィス構えれば、かなりの固定費の削減できるのに。

323 :仕様書無しさん:2015/01/02(金) 17:30:21.86
「有能な人間」とは「天才」を意味しているんだろう。
現実問題、「天才君()」が書いたコードは保守が厄介だ。
普通の人間に理解できないのは困る。
「普通の人間」=「まともに意思疎通・人に理解できる表現の出来る人間」
以外要らん、ってことだ。

324 :仕様書無しさん:2015/01/02(金) 17:58:09.97
すぐに極論に走る人も意志の疎通が難しいわけですが、

325 :仕様書無しさん:2015/01/02(金) 18:25:07.69
>>323
トリッキーなコード書くのは有能とは言えないが、無能な人の中には
あたりまえのテクニックをトリッキーだと言って使わないのもいるからな。

本当に有能な人に会ったことが無いだけじゃないの?

326 :仕様書無しさん:2015/01/02(金) 19:17:22.60
テクニックとトリッキーの線引きがわからない

327 :仕様書無しさん:2015/01/02(金) 20:38:58.81
主観:テクニック
客観:トリッキー
とか

328 :仕様書無しさん:2015/01/02(金) 21:25:49.36
Cの関数テーブルが理解してもらえなかったプロジェクトがあったな。
あとデザインパターンとか使うと、判りにくいからやめろって言われたことがある。

こういうやつ?

329 :仕様書無しさん:2015/01/02(金) 21:28:54.62
ごめん、325=328だけど、文の最後にクエスチョンマークが入ってしまった。

330 :仕様書無しさん:2015/01/02(金) 22:30:52.00
>>326
コードの意図を説明できるかどうか

331 :仕様書無しさん:2015/01/02(金) 23:04:19.52
>>330
それはむしろコピペしたコードだろ
よくあるわ

332 :仕様書無しさん:2015/01/03(土) 00:06:24.33
俺はアーキテクトのルールに従うよ。
それが良くても悪くても。

こっちの方がいいからと、ルールを破る奴は、法律も破るのかと問いたい。
グローバル変数以外は_で始めるってのには、今時全てだろうってツッコミして改定した。
無能なアーキテクト、または不在の場合は無法地帯、矛盾地帯なんだろうけど。

333 :仕様書無しさん:2015/01/03(土) 00:20:47.71
アーキテクトが間違っている場合もあるから
ルールを変える方法がないならば、
従う前に、ルールを変える方法を作ってからだな。

悪いルールは変えないといけない。
でないと、だめだとわかっていて
対策を取らなかった責任を取らされる。

334 :仕様書無しさん:2015/01/03(土) 00:21:59.26
>>332
こっちの方がいいと思ったならルールを変えろよ。
ルールを破るんじゃなくて、ルールを変えるんだよ。

法律は絶対で変えることが出来ないものだと思ってるのか?
法律だって変えていくものだろ。

335 :仕様書無しさん:2015/01/03(土) 00:33:18.94
9条教の信者なんだろ

336 :仕様書無しさん:2015/01/03(土) 01:35:16.51
>>334
そう書いてあるだろ。
文盲なのか、ありがたいお言葉だから復唱したのかどっちだよ

337 :仕様書無しさん:2015/01/03(土) 09:08:48.83
>>321
凡人でも素人でもシステム開発できるってことの証明じゃん

338 :仕様書無しさん:2015/01/03(土) 10:01:46.63
お前らみたいなのが3人もいれば、どんなプロジェクトでも崩壊出来そうな気がする。

339 :仕様書無しさん:2015/01/03(土) 10:13:11.73
>>338
大丈夫
リアルでは、多重派遣の末端中の末端だからwww

340 :310:2015/01/03(土) 17:19:31.42
>>313
医者の不養生というか、そういうのがあるが

・金の入らない自社のシステムは後回し

という面もある様に見える

>問題解決システムも構築できない連中が「素人の作ったシステムは・・・」

これは上記も含め、能力の有無と、作り使うかとは別の話
「」内の部分は、システムの造りの部分だったりして、比較対象がシステムの機能とは異なる場合がある
問題解決のための解法が判っていて、システム化に向く類のものはシステム化出来るのであるが
自分らの問題解決の解法が判っていないのはシステム化しない、出来ないのもある。
そんなに単純化するのは良くない

それより、会社として一般に使うシステムと自社導入しない、使ってない(試験運用含む)、使わないのに
それを売り込んだりする事がある事についてが微妙に感じるかな

341 :仕様書無しさん:2015/01/03(土) 22:23:47.79
業務システムだろ?ここで言ってるのって。
なら、業務を正しく理解する難易度>>>>>>>>プログラミング技術を習得する難易度
なんだから、この場合、素人ってのは、業務を知らないプログラマの方だろ。
素人さんがシステム作るって無理に決まってんじゃん。

某銀行が証明してるだろ、業務を知らないSEやPGをいくらかき集めても無駄だって。
業務を全部正しく把握できている奴に権限を与えて、少数精鋭でやればあっという間に終わるのに
ド素人(業務を知らないという意味)SE・ド素人(業務を知らないという意味)PGを大量に動員しちゃうもんだから連絡で崩壊してしまう

342 :仕様書無しさん:2015/01/03(土) 22:44:18.27
少数精鋭はいいけど
一人当たりが把握できる量って物理的に限られるわけだし
なんかの事故とかで一人抜けたら業務がストップするようじゃ完成は不可能だし>>288
人数確保するには多少劣る人も入れないといけないし
人数増えるとやり取りに時間がとられて優秀な人は直接業務できないし
人が増えると人の入れ替わりが激しくなって部分的に最初からやり直しだし
デスマ突入するわけで

343 :仕様書無しさん:2015/01/03(土) 23:00:40.00
>>341
> なら、業務を正しく理解する難易度>>>>>>>>プログラミング技術を習得する難易度

んなわけねーだろカス
お前が言う業務システムってMS Officeで作ったしょぼい顧客管理システムとかだろどうせ

344 :仕様書無しさん:2015/01/03(土) 23:13:42.42
プログラミングは難易度というより資質だからな。
出来る人は簡単に出来るし、出来ない人はどうやっても出来ない。

んで、プログラミングの資質に関係なく、業務を正しく理解するのはやっぱり難しい。

345 :仕様書無しさん:2015/01/03(土) 23:15:38.73
業務つったってX線扱ったり画像処理したりするわけじゃねーべ?
知れてるだろ。

346 :仕様書無しさん:2015/01/03(土) 23:18:21.59
>>345
現状把握だけならそうかもしれんが、じゃあシステム化した時にどうあるべきか?ってのは
やってみないと分からん所がどうしても出てくるからな。

347 :仕様書無しさん:2015/01/03(土) 23:26:11.41
>>346
それを顧客が作れないんで、代わりにシステム屋が作ると失敗する
プログラミング技術を学ぶ前に、ちゃんとした要件定義を作れるようになってくれればいいシステムができる
ここのシステム作りたがり事務屋さんって、なんかプログラミングに憧れとコンプレックスをもってる気がするよホント
それより先にやるべきことがあるだろうに

348 :仕様書無しさん:2015/01/03(土) 23:51:01.12
うん、だからまあ「当事者だから業務を完全に把握してる」
程度の認識で内製を始めても、俺達よりマシなシステムを作る事は無理だと断言してもいい。

349 :仕様書無しさん:2015/01/03(土) 23:54:12.30
>>344
業務を理解されたくないやつがでたらめな説明するし、違う違う違う違うとにかく違うとしか言わないやつが世の中の半分を占めてるからね。

350 :仕様書無しさん:2015/01/04(日) 01:07:07.87
>>347-348
分業すると色々なコストが半端ないでしょう。
内製は駄目ならすぐに作りなおせるのが良いんじゃない。

351 :仕様書無しさん:2015/01/04(日) 01:07:17.64
システム屋が研修受けて業務を理解するのと、
顧客が研修受けてシステム作れるようになるので比べると、
前者のほうが早そうだが、
内作だと常に両方できる奴を確保できるんだよな

大企業なら10年に1回しか仕事がなくても、こういう人材を飼っておくのは意味がある。はず

352 :仕様書無しさん:2015/01/04(日) 01:10:05.70
システムってのは「目的を達成するもの」です。 コンピューターを利用して実現する
システムはコンピューターを使って目的を達成するものを実現するだけです。

業務に関してはこの目的が各個人違っていたり、人の入れ替えが多いような場所
だとマニュアル通りにやるってのが目的になっていたりします。 本来ならこういう
各個人の目的とは別にもっと本質的な目的があるはずで誰かが把握していなければ
ならないのだが、人の入れ替えで引き継ぐ際に徐々に劣化して誰も知らない、
気にしない状態になります。 目的なんて分からなくなっていても、行動すれば
結果が出る状態になっているので続けるだけなら大きな問題に発展しないから。

システム化で本来はこういうバラバラになった目的から本来の目的に軌道修正
したい思惑があるのだが、全体を見れる人がいないと破綻する。

業務が難しいという人はこういう各個人のバラバラの目的でがんじがらめになった
現場を見て言っているのが大半ですね。

353 :仕様書無しさん:2015/01/04(日) 01:16:53.30
本来システム化は実際の業務を見ないで、
データと処理の流れだけをみて
最適化するのが一番。

そして最適化した流れに、人を再配置する。


だけど、その再配置に人が文句言うんだよねw

ルーチンワークのプロ(笑)が長年やってきた
今までの地位がリセットされるから。

354 :仕様書無しさん:2015/01/04(日) 01:38:50.74
>>341

>業務を正しく理解する難易度>>>>>>>>プログラミング技術を習得する難易度

これは比較がいい加減過ぎる。

>この場合、素人ってのは、業務を知らないプログラマの方

これも、元の文脈ではシステム屋のが偉そうに言うセリフになっているので違うのでは

業務をシステム化するなら、どういう業務なのかを頼む側が把握説明できていないといけないのに
それを伝えていない事が最大の問題だろう。

業務を知らないSEPGの責任ではない。求める物は依頼者の頭にしかないのだから
それを伝えないで出来るものではない
伝えなくても出来る物なら、同業の他所と同じなので同じシステムを導入すれば良いだけの事

355 :仕様書無しさん:2015/01/04(日) 05:12:59.77
>業務を正しく理解する難易度>>>>>>>>プログラミング技術を習得する難易度

業務をシステム化する難易度は無視か。普通はそれが仕事なのに。

356 :仕様書無しさん:2015/01/04(日) 06:35:58.14
>>355
なにもできないんでしょ?
だから理解した!仕事終了。
何もすることがないというか何も出来ない。

357 :仕様書無しさん:2015/01/05(月) 18:57:55.88
>>345
X線装置を作るわけでも画像解析プログラムを必要としない。
その単純な業務をこなす程度のプログラミングがどうして、そんなにレベル高い。センスが必要だと思っているのだろうかココの連中は。

358 :仕様書無しさん:2015/01/05(月) 20:29:03.73
素人が作ったエクセル帳票マクロあっちこっち参照かけててつらいわ・・・・。
入力シート、出力シート、帳票シート
に分けてくれ・・・・。
入力シートに処理結果を上書きして、出力シートでも再度処理して上書きして、帳票シートでもあっちゃこっちゃで処理して・・・・。
やめてくれ・・。

359 :仕様書無しさん:2015/01/06(火) 06:26:20.37
>>357
なんで「業務」が単純だと思うのかな・・・
そうであれば全部バイトでも日雇いでも使えるが実際にはそうではない
製造にせよ発注・販売にせよ「業務」は難しいのだよ

X線装置だって対象物により様々な機能・性能を要求されるんだぜ!?

360 :仕様書無しさん:2015/01/06(火) 20:36:20.54
おまえらの大半は

単純な事務手続きのプログラミングしかしてないのに、なんで技術者だと思ってるの?

361 :仕様書無しさん:2015/01/06(火) 20:48:13.33
どういうこと?

362 :仕様書無しさん:2015/01/06(火) 21:02:29.00
>>361
できないものの僻みだ。
ほっとけ。

363 :仕様書無しさん:2015/01/07(水) 18:36:32.20
まぁ偏差値30台のお前らじゃー、今やってる作業が高等に思えるかもしれんがなwww

364 :仕様書無しさん:2015/01/07(水) 19:27:40.23
>>363小学生から見れば足し算引き算掛け算だって難題

365 :仕様書無しさん:2015/01/07(水) 21:51:33.77
うんうん
学力って大切だよね
文系事務屋がシステム開発したいなんて頭おかしいよね

366 :仕様書無しさん:2015/01/07(水) 22:52:57.43
難題は、客が足引っ張るのを何とか躱すこと。

367 :仕様書無しさん:2015/01/08(木) 21:37:16.58
お前ら文系理系言ってるレベルにも達してないじゃんwwww

368 :仕様書無しさん:2015/01/09(金) 10:03:40.50
>>367ぐうせいろん

369 :仕様書無しさん:2015/01/09(金) 12:37:56.03
文理をいうなら最低でも自分自身の偏差値は65以上のやつだけにしてくれ・・・・・・

370 :仕様書無しさん:2015/01/09(金) 12:41:36.98
文系て偏差値とかあるんすか?w

371 :仕様書無しさん:2015/01/09(金) 12:44:48.73
理系理系言ってる奴って現実はF卒専卒高卒なんだもんなぁ

372 :仕様書無しさん:2015/01/09(金) 13:51:24.00
>>370俺は発言権あるんだ。でいいじゃん。偏差値65程度もないの?

373 :仕様書無しさん:2015/01/09(金) 17:29:50.35
大人同士の会話には到底見えないなw

374 :仕様書無しさん:2015/01/10(土) 10:02:02.59
俺は一般人より記憶がいい
多分職業柄(プログラマ)、そうなるだろうと思う
引出しの多さという表現があるが、記憶のよさはそうした言い回しでもいい

で、アホにいちいち手取り足取りしてやらなくちゃならんから面倒だ
多くのメールのやり取りの中から、必要な情報を抽出とかさ
アホはもう過去のことを忘れちゃっているから

375 :仕様書無しさん:2015/01/10(土) 10:45:13.57
一方有能な技術者は覚えなくてもいいツールを作った。

376 :仕様書無しさん:2015/01/10(土) 11:25:35.09
QC工程表通りに仕事をしてくれれば
仕様は楽なんだがな

377 :仕様書無しさん:2015/01/10(土) 11:51:57.05
>>375
まさにそれw

記憶に頼ったプログラマが書くコードは汚い。
なぜなら、汚くても覚えているから。

で、そんなコードは他人は理解できない。
知らないからね。

何でも覚えて、手動でやってるのを見ると
凄いと思うけど、馬鹿だと思うよ。
自動化すれば、だれでも簡単にできるようになるのね。

378 :仕様書無しさん:2015/01/10(土) 12:19:39.29
>記憶に頼ったプログラマが書くコードは汚い。
>なぜなら、汚くても覚えているから。

一本道のルーチンならわかるというのでは、プログラミングできないよ
Widowsの場合イベントからはじまるから、一本道のルーチンは書けない
お前は、プログラマにプログラミングされたイベントの列挙を書いてもらうとよい。
紙に書いてしてもらったら、理解できると思うよ

379 :仕様書無しさん:2015/01/10(土) 12:30:32.29
>>376
> QC工程表通りに仕事をしてくれれば

それは不可能だね。

なぜならQC工程表自体に問題があるから。

QC工程表が間違っているのに、
その通りに仕事ができるわけがない。

380 :仕様書無しさん:2015/01/10(土) 12:34:33.37
>>378
やっぱり技術力低そうだな。

本質的なコードを一本道のルーチンにするためにあれこれ工夫するんだよ。
複雑でも理解できるから俺は凄い!って思ってるなら技術者としてアウト。
複雑だ。これはダメ。シンプルになるようにしないと。こう考えられるのがプロ。

それにね。イベントがあるからそれは一本道ではないという理解がアウトだね。
イベントがあるから一本道になってるんだよ。
お前は余計なところまで考え過ぎ。
考えなくていいイベントを送る所まで考えてるから
一本道ではないと思ってしまうんだよ。

考えなくてもいい所を考えるのは馬鹿であり
考える必要な所を仕組みを作って考えなくてもいいようにするのがプロ。

381 :仕様書無しさん:2015/01/11(日) 00:07:30.20
>>378
偏った記憶だなぁ。
その記憶に頼ってるから正されることもないんだろうな。

382 :仕様書無しさん:2015/01/11(日) 01:07:30.93
関数型言語的なライブラリを使うのも
ループや条件分岐をなくして
一本道にするためでもある。

383 ::2015/01/11(日) 04:28:48.29
   /:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ
    /:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::://ヽ:::::::::::::::|
    l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::// ヽ::::::::::::::l
    l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::/:::「'ヽ::::::::::://   ヽ:::::::::::|
    |::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ノl:::ノ l:::::::/      ヽ::::::::|
   ノ:::::::::::::::::::::::::::::::::::::::::::::::::::::/ ゙゙  ノ:::/ ,,;;;;;;,,    ,,,,ヽ:::::l
   ):::::::::::::::::::::::::::::::::::::::::::::::/    ノ/ __,'''i: ('''__):::l  
  )::::::::::::::::::::::::::::::::::::::::::::::::::/         ̄ ̄ン:. :「 ̄`ヾ   
 1:::::::::::::::::::::::「 `┤l:::::::::::::::::l          ̄   ,  ヽ ̄ l   
  `l:::::::::::::::::::::ヽ  :l li:::::::::::::/        ヽ  /´   `l  |
  ヽ::::::::::::::::::::::\_」 lヽ::::/         .l  !:-●,__ ノ  /  
  ノ:::::::::::::::::::::::::::ノ | l `゙゙           i ,,;;;;;;;;;;;;;;;;;;;;,  /ヽ      ヴッ!!
,/ ヽ::::::::::::::::::::::(  l l::::::::..         /.:''/´ ̄_ソ  /  `ヽ
     ヽ:::::::::::::::ヽ | l:::::::::::...      /::// ̄ ̄_ソ  /    \
        ヽ:::::::\| l::::::::::::::::...    / :::.ゝ` ̄ ̄/ /       ヽ
           ヽ:::l l:::::::::::::::::::..      ̄ ̄;;'' /         ヽ
              l l;;;;;;:::::::::::::::.....;;;;............;;;;;;''ノ            l
              l l '''''''''''''''''''''''''''''''''''''' ̄l |             |
https://www.youtube.com/watch?v=z2qK2lhk9O0

384 :仕様書無しさん:2015/01/11(日) 07:49:15.90
>>374
比較対象が周りに派遣のバカしかいないからだろ

385 :仕様書無しさん:2015/01/11(日) 11:38:31.91
>>380
まったくだな、シンプルに単純にというのが重要だと俺も思う。
自社システムに限らないけどさ。

386 :仕様書無しさん:2015/01/11(日) 21:37:24.30
要するに頭が悪いんだわ

387 :仕様書無しさん:2015/01/12(月) 12:10:41.32
いろんなとこでプログラミングを教えたが

低学力・・・自力プログラミングでシステムを作れるようになるのは、1割いるかいないか
中学力・・・みんな一応プログラミングはできてシステムを作れるようになるが、コピペ等々が6割。4割は自力。
        自力でやるように条件づけると、1回めは時間かかるが2回め以降は早くなる。6割以上ができるようになる。
高学力・・・最初から自力ででき脱落者はゼロ。1回目からそこそこのスピードで作ってくる。
トップ級・・・最初から自力ででき脱落者はゼロ。授業で教えるより先に自分で勉強をしてシステムを組んでいる。

これは、経験上間違いない。中程度は日東駒専の中ランクくらいからの話ね。
だから「業務を覚える」のと「プログラミングを身につける」のでは圧倒的に前者のほうが難しいことは経験上理解している。

388 :仕様書無しさん:2015/01/12(月) 12:12:15.69
業務を覚えるほうが簡単だよ。
だって周りを見なよ。
誰だってや・れ・て・る

お前のプログラミングのレベルが低いだけ。

389 :仕様書無しさん:2015/01/12(月) 12:33:56.46
トップ級のレベル低すぎワロタw

自力でできるっていうのは、プログラマの最低レベルよ。
競輪選手が自転車に乗れるようになった程度の段階。
その状態は全然身についてない。

身についているっていうのは、プログラム言語の言語仕様を把握はもとより、
ソートやサーチなどの基本的なアルゴリズムの理解、並列処理やトランザクション処理の基礎知識
セキュリティやバグを起こしにくく複雑度を考慮した書き方、複雑なものをシンプルに実装するための技術、
代表的なライブラリやフレームワークの習得。バージョン管理ツール等の各開発ツールの使いこなし。
開発とテストとリリース。それらを自動化させて開発サイクル全体のワークフローの確立。
そして長年の経験を伴ってそれらを自然に行えるようになってやっと一人前だよ。

390 :仕様書無しさん:2015/01/12(月) 12:39:48.02
>>389
お前の一人前もだいぶレベルが低いな

391 :仕様書無しさん:2015/01/12(月) 12:43:47.23
俺の場合は
自分のプロダクトをネットで公開して
一人前だと思ってる

392 :仕様書無しさん:2015/01/12(月) 12:44:12.23
>>388
ほぉ
なら、診療報酬のパターン全部羅列してみて

393 :仕様書無しさん:2015/01/12(月) 12:45:56.92
お前らの業務知識

 出社したらカードをピッとやる
 5個位上の会社からの仕様書を見る
 仕様書通りにひたすら意味もわからずプログラミング
 テスト

おしまいwwwwww

394 :仕様書無しさん:2015/01/12(月) 13:03:42.75
>>390
ほぉ
なら、お前が思う一人前を言ってみて

395 :仕様書無しさん:2015/01/12(月) 13:04:56.54
>>392
> なら、診療報酬のパターン全部羅列してみて

そんなもん、ドキュメントにまとめていればいいじゃないか?
覚えることじゃないし、そもそも
俺は資料を手に入れられないから、そんなもの知らん。

それと難しいって話は別問題だけど、
わかってるかい?

396 :仕様書無しさん:2015/01/12(月) 13:07:54.88
項目数が多いくて面倒なだけで、
やってる計算自体は四則演算程度だしなぁ。

単なる計算だからテスト作るのも簡単だし、
でもまあ、こういう所を人海戦術や記憶に頼るような
非効率な開発をしてると難しいって錯覚することも有るんじゃない?
錯覚だけどな。プログラム技術が低いために起きてる。

397 :仕様書無しさん:2015/01/12(月) 13:11:34.61
診療報酬みたいなのは(内容知らないけど)制度設計の段階でシステム設計する人間が関わっておくべきだわな。
制度上の矛盾とか抜け穴も早い段階で潰せるし

398 :仕様書無しさん:2015/01/12(月) 13:18:00.91
>>395
診療報酬は最低限のルールで、これに現場の運用、慣習、審査機関の解釈、法的解釈も状況状況によって求められる、
そういうのをお前ごときが、数年で覚えられると思うか?
少なくとも元請け会社として現場見てから発言しろ

399 :仕様書無しさん:2015/01/12(月) 13:18:25.21
>>395診療報酬なら常に公開されてるよ

400 :仕様書無しさん:2015/01/12(月) 13:18:33.89
>>397
俺もそう思う。

点数表?みたいなのがあって毎年変わるとかあるにしても、
その各種データと実際に動くコードをオープンソースにしてライブラリ化
そしてテストパターンでも用意しておけば各社で実装する手間は省けるんじゃないのか?
業界違うからしらんけど、それくらいできてないのかな?

診療報酬のパターン全部羅列してみてと言っている所からすると、
そのパターンを暗記することが、優れている証とか思ってそうなんだよなぁ。

単に効率が悪いってだけなのに。

401 :仕様書無しさん:2015/01/12(月) 13:20:02.63
>>399
だったら、そのとおりに実装するだけの話だよね?
なにか難しいところでも有るの?

暗記するのが難しいっていうのはやめてくれよ
小中学校のテストじゃないんだから、カンニングしていい。

402 :仕様書無しさん:2015/01/12(月) 13:20:54.24
>>398
後付で何言ってるのよw
恥ずかしい

403 :仕様書無しさん:2015/01/12(月) 13:21:43.38
>>398
> そういうのをお前ごときが、数年で覚えられると思うか?

覚えられるか?っていうのが、情けない話なんだよ。

覚える必要が無いようにしないとだめ。
なんでそれくらい分からないの?

404 :仕様書無しさん:2015/01/12(月) 13:22:40.29
やっぱり、暗記力が素晴らしいと
思ってるみたいだな。

405 :仕様書無しさん:2015/01/12(月) 13:23:01.27
>>396
その項目が条件分岐しまくり。ゲームプログラミングに近いレベルの分岐。
ゲームのような数学的な高度なロジックはほとんどないけどね。
ただ、 業務を覚えるのなんて簡単 なんて、一度でも経験すれば口が避けても言えない複雑さ。
そのうえ年二回は確実に法令改正で解釈変更やらなんやらが入る。
しかも、絶対に間に合わせないといけない。違法請求になってしまうから。
そのくせして、解釈等々は施行のギリギリまで伝わってこない鬼プラン。

406 :仕様書無しさん:2015/01/12(月) 13:23:43.98
ユーザーのためにシステム化する。
システム化して面倒なことは不要にする。

それが仕事なのに、

それを作る側が、システム化して暗記する必要を
なくせるようにしてない時点で、情けないよな。

407 :仕様書無しさん:2015/01/12(月) 13:23:53.48
ハードコーディングしてるの?
普通そういうのデータに落とし込まね?

408 :仕様書無しさん:2015/01/12(月) 13:25:19.15
おまえら、そんな言うならレセプトシステム作ってみろよw

それ一本無料で一回リリースしてみろ。
あっという間に、医療事務システム分野の第一人者になって年収5000万以上はかたいからw

409 :仕様書無しさん:2015/01/12(月) 13:25:23.65
>>405
> その項目が条件分岐しまくり。ゲームプログラミングに近いレベルの分岐。

だから「複雑なものをシンプルに実装するための技術」が
必要なんだよ。

ほんと技術力が低い奴は、複雑なものを複雑なまま実装しやがるからな。
それだけならまだマシで、複雑なものをさらに複雑にして実装する。
そしてテストもない。

で、そんなコードを見て、俺全部暗記して理解してるから
修正なんか簡単にできるぜ!が自慢だったりする。
もうアホかと。

410 :仕様書無しさん:2015/01/12(月) 13:26:42.98
>>409
ならゲーム業界行ってこいよwww
超深くなっている条件もおまえがやれば深度1〜2くらいになるんだろ?www

411 :仕様書無しさん:2015/01/12(月) 13:27:40.12
>>408
その点数表てのどっかで見れる?

412 :仕様書無しさん:2015/01/12(月) 13:27:53.27
>>408
> おまえら、そんな言うならレセプトシステム作ってみろよw
仕様しらんし、勉強するつもりもない。

ただ言えるのは、お前が複雑なんだぞ!って言ってるだけで、
じゃあ、複雑ならシンプルに実装すればいいだけじゃんって
そういう話をしてるだけ。

それができんのだろ? 技術力不足だ。
そんなシステムよりOSの方が複雑だからな。

413 :仕様書無しさん:2015/01/12(月) 13:29:52.59
>>410
普通になるんじゃねーの?w

深度ってのが何を指すのかしらんが、
もう少しソフトウェア業界の
標準的な言葉で説明してくんない?

414 :仕様書無しさん:2015/01/12(月) 13:30:33.33
>>411
診療報酬 点数表 とかで調べられる。
お!簡単そうじゃん!と思って手を出したが最後ドツボにハマる

415 :仕様書無しさん:2015/01/12(月) 13:31:57.03
>>414
たぶん特例みたいなのを何とかすりゃデータ化できるんだろ。

416 :仕様書無しさん:2015/01/12(月) 13:33:43.23
技術力が低いやつだと、書いてある計算式を
そのままコードに落としこむからなぁ。
そして何百行にも長いコードになる。

どうせ計算式の値は、ソースコードに直接埋め込んでるでしょ?
うん、わかるよ。

417 :仕様書無しさん:2015/01/12(月) 13:35:14.72
>>415
特例だらけ。
こういう問題が発生しています。→政治家「じゃーこうしましょう。」→反対派「それじゃーこういう人の命が守られない」
→政治家「じゃー、こういう人は例外で」→反対派「線引きがおおざっぱだ!」
→政治家「じゃー細かくこうこうこう。このパターン例・・・よくわからなくなった」
→官僚「で・・・おれらがやるんかい。」→どんどん特例だらけへ・・・。

418 :仕様書無しさん:2015/01/12(月) 13:35:19.33
特例部分をスクリプトにしてしまえばええわな

419 :仕様書無しさん:2015/01/12(月) 13:36:26.74
んで各ケースにテストケース付けてやれば、完了と

420 :仕様書無しさん:2015/01/12(月) 13:40:37.23
特例が出るたびに、if文追加してるんだろうなって分かった。
そんなもの○○の値の部分を関数に置き換えて
その中で特例だけ処理すれば終わるのに。

どうせ関数作ってないでしょ?
ベタにそのままコード書いてるでしょ?
わかるよ。

421 :仕様書無しさん:2015/01/12(月) 13:43:47.07
要するにエクセルみたいなの作ればいいんだろ。

422 :仕様書無しさん:2015/01/12(月) 13:43:50.26
こういう、特例が多いようなものだからこそ
プログラム技術が必要なわけで。

技術力低いから、特例に対応するコードを
シンプルに書くことが出来ません!
じゃ恥ずかしいだろ。

で、複雑なものを複雑に書いておきながら、
つまり自分で落とし穴を掘って置いて
落とし穴を避けるほうが難しいんだ!じゃないだろw

423 :仕様書無しさん:2015/01/12(月) 14:06:37.57
>>422
コードをシンプルにすれば済む話でも無いような。

424 :仕様書無しさん:2015/01/12(月) 14:10:28.95
レセプトだけでなく特許とかも仕様だけ聞いてたら
何とかなりそうな気がするけど、実際には手をつけたら最後、
システムとしてまとまらないレベルでひどいことになるぜ。

425 :仕様書無しさん:2015/01/12(月) 14:12:30.41
シンプルなものを複雑にかく←バカ
複雑なものをシンプルにかく←大バカ

426 :仕様書無しさん:2015/01/12(月) 14:15:52.58
>>425
後者の具体的な例をどうぞ

427 :424:2015/01/12(月) 14:18:08.88
特例を関数にして〜とか言ってるやつが多いけど
特例にあたるかどうかも元の法律が自然言語で書かれてるから判断が難しいし、
そもそも複数の特例の適用順序で解釈が変わったりするし、
中身を知らないやつらの机上の空論としかいいようがない。

428 :仕様書無しさん:2015/01/12(月) 14:21:29.94
判断が難しいから何なんだ?

システムとして特例と判断したなら特例だし、
その都度人間の判断が必要なら
人間が入力するだけだろ。

特例の適用順序で解釈が変わるなら、
変えればいいだけの話だろ。

四則演算の順番で、答えが変わるのと
概念的には何も変わらん。

ほんと物事を単純に考えられんやつだな。

429 :仕様書無しさん:2015/01/12(月) 14:24:28.74
理解出来ないからって勝手に単純に考えんなや

430 :仕様書無しさん:2015/01/12(月) 14:33:23.24
単純で済む話を、何の説明もなく複雑って言うなや。
自分が詳しいと思ってるなら、その説明をしろ。

431 :仕様書無しさん:2015/01/12(月) 14:43:04.60
「物事をシンプルに考える」ってのは、本質的に単純な事を単純であると見抜く事が重要だという意味だ。
だが、本質的に複雑な事も世の中には沢山ある。複雑な事は複雑なまま理解せざるをえない。
それを字句通りに受けとって、何でも単純に考えたらいいというのは大いなる勘違いなんだよ。

432 :仕様書無しさん:2015/01/12(月) 14:45:03.64
うん。だからそれが正しいことをの具体例をだね?

433 :仕様書無しさん:2015/01/12(月) 15:33:32.57
机上の空論で語る自称有能なマが多いスレだなw

434 :仕様書無しさん:2015/01/12(月) 15:36:01.92
このスレは
妄想・自演馬鹿にのっとられたのかなー

435 :仕様書無しさん:2015/01/12(月) 15:48:07.75
よく分からんが、診療報酬は頭おかしい奴が作ってるから、
頭ただしい奴が解釈して効率よく作っても、
頭おかしい奴が変更するたびに解釈しなおす必要があって無駄だから、
頭おかしい奴が作ったとおりに実装するのが正しいんじゃないの?

436 :仕様書無しさん:2015/01/12(月) 15:48:41.38
>>392〜434
391は無視かよ
何書いても虚しいぞ

437 :仕様書無しさん:2015/01/12(月) 15:51:40.46
ここで技術技術言ってる奴はまともに主管となってシステム組んだり運用したりしたことない底辺派遣だろ
業務が簡単だと思うならM銀行のシステムを受けてやれ
勘定系だって基本的には簡単
数式だって手続きだってすべて決まってるんだから

438 :仕様書無しさん:2015/01/12(月) 15:59:29.26
>>433
十中八九、無職winだから。この単純化バカはw

439 :仕様書無しさん:2015/01/12(月) 16:04:04.65
とにかく
 派遣社員は発言しないで!派遣社員は発言しないで!派遣社員は発言しないで!派遣社員は発言しないで!
人様に対して意見具申する前に
 自分が社会で問題視されている非正規雇用という分類の人だって理解して!社会の足引っ張らないで!!

440 :仕様書無しさん:2015/01/12(月) 16:29:10.81
>>389
おまえら、対象の業務範囲も言わずに一人前がどーたらよく言えるな。
データベーススペシャリストはルーティングテーブル書けなくても一人前だろ。

441 :仕様書無しさん:2015/01/12(月) 16:30:15.25
仕様がわからないから・・・・・・・・って途中で出てくるけど
その仕様が正しく伝わらないからシステムは作れないと>>1は最初から指摘してるんだけどなあ
だから業務を教えるより、業務をわかってるやつをプログラマ化したほうが確実だって話なのに

442 :仕様書無しさん:2015/01/12(月) 16:31:03.38
実際簡単だと思うわ。

443 :仕様書無しさん:2015/01/12(月) 16:32:07.21
>>442
自己の能力を示すなら弁舌ではなく実績で示したら?
システム作っちゃえばいいじゃんレセプトの
でソースコードに名前刻んで公開してやればよい

444 :仕様書無しさん:2015/01/12(月) 16:34:25.88
>>443
全部作る時間は無いから
点数表の範囲限定してよ

445 :仕様書無しさん:2015/01/12(月) 16:36:26.59
んだんだ。
実際最初は無料提供でも本当に簡単に実装できて仕様変更も簡単に行けるならそこら中の病院やクリニックからオファーくる。
で病院あたりの仕様変更費用を安ーくしても年億は軽く稼げるだろ。
簡単ならなぜやらない?ビッグマネーがそこにあるのに。

446 :仕様書無しさん:2015/01/12(月) 16:40:24.27
>>444
Aをやっていて、過去に○日以上Bを受けていているケース。ただし○歳まで。
さらにAをやっていて、過去にCを○日以上受けていて、保険Cを持っているケース。ただし転院で通算して○日Dを受けている場合・・・・
とか範囲もくそもないからw 点数表の説明をぜ〜んぶ見て相関関係を調べあげないとだめ

447 :仕様書無しさん:2015/01/12(月) 16:41:38.33
特許系も悲惨

448 :仕様書無しさん:2015/01/12(月) 16:46:14.00
>>446
こういうやり方なら例外も対応できるよね、とプロトタイプを示すのが目的でしょ?
筋が良ければ、じゃあこの方法で作ってみようか、となる。

449 :仕様書無しさん:2015/01/12(月) 16:47:38.34
まあスクリプト組んでオブジェクトのプロパティを参照する形になると思うけどな。

450 :仕様書無しさん:2015/01/12(月) 16:50:52.66
なんでコーディングテクニックの話になるんだよw

451 :仕様書無しさん:2015/01/12(月) 16:51:54.85
>>446
これだけじゃん。
条件の数だけこんな感じに羅列するだけ。

function is適用() {
  if (履歴('A') && 受診日数('B') > ○ && 年齢<=10) return true;
  if (履歴('A') && 受診日数('C') > ○ && has('保険C') && 転院通算('D') > ○日) return true;
}

452 :仕様書無しさん:2015/01/12(月) 16:53:39.30
>>450
コーディング = 文章 と考えればいいよ。

わかり易い文章で書けば
複雑な文章も分かりやすくなる。

453 :仕様書無しさん:2015/01/12(月) 17:54:30.85
俺だったら、エクセルでマトリクス表作るかな。

|○の場合|Aの場合|・・・
|      |Bの場合|・・・
|      |Cの場合|・・・
|      |Dの場合|・・・
| △の場合 |Aの場合|・・・
|      |Bの場合|・・・
|      |Cの場合|・・・
|      |Dの場合|・・・

みたいな。

そしてそこからコードに変換。
普通の人にも読みやすいし、メンテナンスもしやすくなる。

たぶん、こういう別のもの(データ)からソースコードを
生成するという発想が出ない人なんだと思う。

でそこからたどり着く結論は、エクセル表相当のものを
作るのが大変と言っているだけw
めんどくせーなーとは思うが、難しいとは思わんな。

454 :仕様書無しさん:2015/01/12(月) 21:29:30.85
診療報酬はやったことないけど簡単だっていう人は金になることをやらんの?

455 :仕様書無しさん:2015/01/12(月) 21:32:03.74
勘定系のほうが診療報酬より簡単なんだけど古いソースが最大の壁・・・orz

456 :仕様書無しさん:2015/01/12(月) 21:41:35.67
そもそも診療報酬なんてのは
プログラムじゃなくてデータなんだよ。

データなのだから入力すればいい。
日本語で説明されていてそれを普通の人が理解できることからもわかるように
難しい作業じゃない。安いバイトでも十分対応可能な仕事

つまりね、これシステム開発の仕事じゃないわけよ。
給料の高い人間がやることじゃないことを
せっせとやってるだけ。

457 :仕様書無しさん:2015/01/12(月) 21:46:27.54
>>454
簡単と客を得られるかは別の話だからね。
いくら簡単でも客を得られなきゃ意味が無い。

こういう分野は需要が少ないから既に抑えている物の勝ち

もう一つ、既にシェアを奪っている所に就職するってのもあるんだけど、
それはそれで、簡単であるがゆえに、技術の低い人が人海戦術で
作ってる可能性が高い=ソースコードがぐちゃぐちゃ。
そのメンテナンスでストレス溜まるのが想像つくしね。

単純なことだよ。
簡単にできること=技術力が低い
難しいこと=技術力が高い。

下に合わせなきゃいけないのは、かなりの苦痛。

458 :仕様書無しさん:2015/01/13(火) 00:41:39.23
>>456
>データなのだから入力すればいい。
>日本語で説明されていてそれを普通の人が理解できることからもわかるように
>難しい作業じゃない。安いバイトでも十分対応可能な仕事

この部分がたぶん、一番難しい。出所(厚労省?)がデータを作って、もし間違っていても「データにあわせろ」で押し通すって形にしないとたぶん無理

459 :仕様書無しさん:2015/01/13(火) 01:58:11.96
難しいと面倒をごっちゃにしないでほしいね。
ごっちゃにすると足し算ですら、難しいってことになってしまうからさ。

460 :仕様書無しさん:2015/01/13(火) 10:05:31.81
どうしてやったことも無い仕事をこのスレの情報だけで簡単だとか単純化できるとか断言できるのだろうか?
そのセンスが怖いね。普段の仕事でも適当な見積りでやってるんじゃない?

461 :仕様書無しさん:2015/01/13(火) 12:37:38.64
設計書もらってコーディングするだけの人は大体そんな感じ

462 :仕様書無しさん:2015/01/13(火) 17:35:58.67
経験不足による想像力の欠如意外の何物でもない
こういう奴が見積もり取るとマジで詰む
底辺だろうからそれはないけど

463 :仕様書無しさん:2015/01/13(火) 18:05:13.91
責任あるポジションで仕事したことないやつはしゃべるなっつーの
何が単純化だよwwww

数学の問題すら単純化できなかった低学歴ドモが

464 :仕様書無しさん:2015/01/13(火) 19:07:10.18
>>460
能力や学力が低いものほど自分を高く評価し、能力や学力が高い人ほど自分を過小評価する
これは世界共通の現象だから

465 :仕様書無しさん:2015/01/13(火) 23:09:50.41
仕様書が手書きの汚い文字で書かれてて
解読するのが大変って言われてる気分

466 :仕様書無しさん:2015/01/14(水) 04:16:45.17
パワーポイントの線で綺麗に書いたこんな画面より、手描きのUMLがいい。

467 :仕様書無しさん:2015/01/14(水) 18:12:25.33
>>464
能力や学力が低いものほど根拠なく自分を高く評価し
能力や学力が高い人ほど評価を人に委ね おごらない

だと思う

468 :仕様書無しさん:2015/01/15(木) 04:10:21.92
わかってる人はそれとなく間違ってるとこを指摘してるんだけど
それやると逆ギレする人が・・・

469 :仕様書無しさん:2015/01/15(木) 08:54:02.80
能力のある人は指摘せず 本人に気付かせる

470 :仕様書無しさん:2015/01/15(木) 18:00:56.84
指摘せずに気付けるやつは、そもそも指摘対象ではない

471 :仕様書無しさん:2015/01/15(木) 18:21:58.94
戻り値でのエラー判定はしょりやがる害虫とか
正常系だけ、エクセル開いていて上書き出来なくても知らんぷりにになってた
バレなきゃええわという手抜き

472 :仕様書無しさん:2015/01/15(木) 20:19:04.12
> 戻り値でのエラー判定
本当にもうこんな事やめてくれ

473 :仕様書無しさん:2015/01/15(木) 23:57:50.01
しょうがないことだってある

474 :仕様書無しさん:2015/01/16(金) 00:42:19.34
例外使えない老害かぁ。

475 :仕様書無しさん:2015/01/16(金) 12:47:51.79
社外製品とかはエラー値返すだろボケ
社外製品の正常系しか考えてないサンプルソースそのままコピペして
納品する糞業者の話や

476 :仕様書無しさん:2015/01/16(金) 12:52:56.65
老害処理

477 :仕様書無しさん:2015/01/16(金) 15:15:04.88
今時は例外を無視するとコンパイルできない処理系だってあるだろ。テストが書けないなら、それ使え。

478 :仕様書無しさん:2015/01/16(金) 17:36:14.44
スローやキャッチがすべての言語にかならず実装されていると思っているのだろうか?

479 :仕様書無しさん:2015/01/16(金) 17:50:58.16
バレなきゃ幾らでもてを抜きやがる
バレたときにはその担当は別なとこ逝っとる

480 :仕様書無しさん:2015/01/16(金) 17:57:33.58
害虫システムでまともなソース見たことないわw

481 :仕様書無しさん:2015/01/16(金) 20:18:42.76
>>478
処理系が理解できない初心者か。

482 :仕様書無しさん:2015/01/16(金) 20:35:46.32
>>481
COBOLで例外処理書いてみて。

483 :仕様書無しさん:2015/01/16(金) 20:40:30.49
>>482
>>477には例外処理使える言語使えって書いてあるんだよ。選定の権限もテスト書く能力もないなら、辞めた方がいいよ。

484 :仕様書無しさん:2015/01/16(金) 20:42:02.70
                     /j
                   /__/ ‘,
                  //  ヽ  ', 、
                    //    ‘     
                /イ       ', l  ’     ゆとりJava厨がキレてるんで この話はやめよう
               iヘヘ,       l |  ’
               | nヘヘ _      | |   l    ハイ!! やめやめ
               | l_| | | ゝ ̄`ヽ | |〈 ̄ノ
               ゝソノノ   `ー‐' l ! ¨/
            n/7./7 ∧        j/ /     iヽiヽn
              |! |///7/:::ゝ   r===オ        | ! | |/~7
             i~| | | ,' '/:::::::::::ゝ、 l_こ./ヾ..     nl l .||/
             | | | | l {':j`i::::::::::::::::`ーr '         ||ー---{
              | '" ̄ ̄iノ .l::::::::::::::::::::::∧       | ゝ    ',
      , 一 r‐‐l   γ /、::::::::::::::::::::::::〉ー= ___  ヘ  ヽ   }
    / o  |!:::::}     / o` ー 、::::::::::::i o ,':::::::{`ヽ ヘ     ノ
   / o    ノ:::::∧   /ヽ  o  ヽ::::::::| o i::::::::ヽ、 /   /
   /    ノ::::::/    /::::::::ヽ  o  ヽ:::| o {::::::::::::::Υ   /

485 :仕様書無しさん:2015/01/16(金) 20:59:40.40
VBAしか選択肢がないんですが

486 :仕様書無しさん:2015/01/16(金) 21:05:37.07
プログラマは常に勉強!キリッ!
勉強=新プログラミング言語を覚えるだけ
で、旧言語の勉強はしないw
だから旧言語環境しかない世界はわからないし役立たず

487 :仕様書無しさん:2015/01/16(金) 22:51:16.14
どんな言語を使ってようが、つかってまいが。
うまい人が使えば綺麗なソースになるし。
下手な奴が組めば汚いソースになる。

488 :仕様書無しさん:2015/01/16(金) 23:01:04.99
うまい人は「使う」で、下手なやつは「組む」か
結構深いな

489 :仕様書無しさん:2015/01/17(土) 00:22:11.05 ID:HRmPsMMf
美しいコードとはシンプルで無駄がないものだが
そうしたコードを書けるかどうかは数学的センスの有無によって決まる
プログラミング"能力"とは、いろんな言語やフレームワークを知ってることじゃないんだよ
大学数学を履修しているかどうかってのも大きい

490 :仕様書無しさん:2015/01/17(土) 00:59:58.23
数学的素養は絶対関係ない。
そのレベルの人間になるともう綺麗に書けるとかは二の次になる

パンピーグラマーに必要なのは
一貫した考え方と要領の良さだ

491 :仕様書無しさん:2015/01/17(土) 01:25:35.78
>>485
onerror goto errしとけ

492 :仕様書無しさん:2015/01/17(土) 01:46:14.63
>>490
一貫した考え方と要領の良さは数学的素養の延長である

493 :仕様書無しさん:2015/01/17(土) 07:52:53.41
下手な奴でもそれなりに組める制約の多い環境使えってことだろ。
仕事で人の上に立つなら、自分で書けるだけでなく人に書かせるスキルが必要。

494 :仕様書無しさん:2015/01/17(土) 08:12:13.26
作ろうとしている方向性がずれてるのに、そんな話いくらしても無駄じゃね?

495 :仕様書無しさん:2015/01/17(土) 10:18:43.28
内製というか、ユーザー作成で一番やってほしくないこと
VBAのマクロの記録の延長線でプログラムを組むのはやめてくれwww

496 :仕様書無しさん:2015/01/17(土) 11:01:13.23
思うのさ
自社ってことは
正社員か経営者しか対象にならないのに、なんで派遣が自社スレで語るの?

497 :仕様書無しさん:2015/01/17(土) 11:27:11.61
派遣じゃなくて正社員だからだろ?
なにか正社員では困るようなことでもあった?

498 :仕様書無しさん:2015/01/17(土) 12:42:46.73
>>497
お前が正社員だったら会社としてはかなり困る

499 :仕様書無しさん:2015/01/17(土) 13:37:56.80
>>498
それはお前だと思うよ。理由は言わないけどw

500 :仕様書無しさん:2015/01/17(土) 13:42:59.13
>>496
そりゃ作った俺がブツの酷さを一番知ってるから

501 :仕様書無しさん:2015/01/17(土) 14:15:16.06
>>497
偽装請負は派遣だからね

502 :仕様書無しさん:2015/01/17(土) 14:26:48.24
ここでいう正社員とは
正職員、顧客会社の正社員、元請け、一次請、自社で企画から販売まで行う会社の正社員を指す。

それ以外は非正規社員扱い。

503 :仕様書無しさん:2015/01/17(土) 16:20:42.42
顧客側が仕様を全部伝えきれない
受託側が仕様を全部引き出せない
伝言ゲーム問題
派遣プログラマのレベルが著しく低い問題

たぶん、一番解決が困難なのは、最後の派遣プログラマ問題だとおもう。
これ解決させる方法は現時点、派遣プログラマ禁止だから
偏差値50に満たないバカはプログラマ業界から排除される
けど、社会的には数百万人の無職を生み出す

504 :仕様書無しさん:2015/01/17(土) 16:54:27.16
無能残業して時間報酬下げてんじゃねえよ
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
人格障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死

505 :仕様書無しさん:2015/01/17(土) 19:48:33.06
>>503
そんなあなたに朗報w

http://daily.2ch.net/test/read.cgi/newsplus/1421379347/

506 :仕様書無しさん:2015/01/17(土) 22:16:50.73 ID:HRmPsMMf
>>503
偏差値に加えて文系も排除しないと不十分

507 :仕様書無しさん:2015/01/17(土) 22:29:07.98
>>506
偏差値も排除するのか?おまえ文系だろw

508 :仕様書無しさん:2015/01/17(土) 22:31:44.86
>>506
何回言わせんだよ
おめーらの大半99%は文系理系云々語るだけの学力も学歴もねーだろが

509 :仕様書無しさん:2015/01/17(土) 23:27:46.56
>>508
低偏差値の文系なんだね…可哀想に

低偏差値なのはしょうがいないとしても、文系に入っちゃったのは悲惨としかいいようがない
あれは学問じゃない。自分から進んで脳みそ腐らせるようなもんだ。

510 :仕様書無しさん:2015/01/17(土) 23:58:14.67
>あれは学問じゃない。自分から進んで脳みそ腐らせるようなもんだ。

基本情報試験も相当に脳みそを腐らせるものだな

QC七つ道具とか、PDCAを回すとか、
ろくなもんじゃないのを取り扱っている。そして素人はそれを信仰するのだな

511 :仕様書無しさん:2015/01/18(日) 00:03:31.18
プログラミングは創造なのだ

QC七つ道具とか、PDCAを回すとか、 そんな信仰しても何も生まれはしない

512 :仕様書無しさん:2015/01/18(日) 00:38:08.34
文系に教えるのだが、QC七つ道具にブレインストーミングというやつがある。
みんなで解決策策を探るというやつだな。
しかしプログラミングの世界では、素人が集まってきてもウザイだけ
その世界では、烏合の衆は、一人のプログラマに勝てないのよ

513 :仕様書無しさん:2015/01/18(日) 01:21:03.56
QC七つ道具とか、PDCAを回すとか
そういうのはプログラマの世界では
アジャイルとかカンバンとかいう。
効率的に使われてるよ。

514 :仕様書無しさん:2015/01/18(日) 05:09:30.45
>>511
どちらも品質管理で、
生めるのは当然ってレベルの人が使うものだから、
君にはまだ早い。

515 :仕様書無しさん:2015/01/18(日) 08:00:58.20
>>511
君が基本や応用すら受かってないのは推測できるわwww
あんなもの合格できないなんてハッキリ言って犯罪者DQN集団よりお前は頭が悪い

516 :仕様書無しさん:2015/01/18(日) 08:21:23.93
>犯罪者DQN集団よりお前は頭が悪い

低脳さんいらっしゃい

517 :仕様書無しさん:2015/01/18(日) 08:26:35.08
また資格試験かよwww
合格できない馬鹿が永久にコンプレックス抱いて猛反撃しようと
「役に立たない」「時間の無駄」
とすっぱい葡萄論を語りだすだけだろうに
童貞が女なんていらないとか言いつつエロアニメで女見てシコシコしてるのと同じ

518 :仕様書無しさん:2015/01/18(日) 09:11:31.77
>また資格試験かよwww

おまえがプログラミングについて語れなくても
低レベルな話題についてなら語れるだろ

519 :仕様書無しさん:2015/01/18(日) 10:41:18.23 ID:foI60g/f
>>518
linuxで売名しようとして失敗したんだって?wwwww

520 :仕様書無しさん:2015/01/18(日) 11:08:24.81
文系にLinuxなんか使えるわけないだろ

521 :仕様書無しさん:2015/01/18(日) 12:21:32.90
>512
QC7つ道具は、
・特性要因図
・チェックシート
・ヒストグラム
・散布図
・パレート図
・グラフ・管理図
・層別
だけど。
あなたも文系?

522 :仕様書無しさん:2015/01/18(日) 13:14:19.62 ID:aH/telNH
>>521
ようやくここ数年で、ソフトウェア業界は
QC7つ道具を参考に、ソフトウェア開発向けにアレンジしたものを
取り入れてる段階だよ。

君はQC7つ道具を古いものだと思ってるのかもしれないけど、
逆でようやくQC7つ道具を取り入れる時代になったわけ。

アジャイル開発
http://www.venturenow.jp/column/ogawa/20120705018207.html
>  既に『Running Lean』の著者のブログ等では、Lean Canvas以外のフレームワークも紹介されており、
> 壁に貼って共有するようなポスターなども提供されている。これらの動きは、
> まさに日本の製造業のQCサークルで用いられたQC7つ道具(特性要因図やパレート図など)を彷彿させる。
> リーン生産方式から学ぼうとしているのだから当然のことではあるが、そのような活動がしっかり続いていくのであれば、
> 数年後に蓄積されている経験はかなりのものになっていくだろう。

523 :521:2015/01/18(日) 17:57:18.44
いや、QC7つ道具にブレインストーミングなんてないよと
いっているのだが。

ブレインストーミングは、どちらかというとQCサークル活動でしょ。

524 :仕様書無しさん:2015/01/18(日) 18:43:24.05
QCの道具なんていうもんは、百姓を相手にする時につかうものだ

基本技術者の問題がそんなんだから、その試験を受ける素人は勘違いする
プログラミングに必要だとね。

プログラマに必要なのは百姓には届かない才能だな
プログラミングでは、次から次と問題がおきる。
プログラマに必要な才能とは、それを次から次へと処理できる能力みたいなもんよ

525 :仕様書無しさん:2015/01/18(日) 20:22:30.74
>>524
お前はそんなに才能豊かなら実績を示して

526 :仕様書無しさん:2015/01/18(日) 20:26:48.47
俺は超凡人だからふっつーのことしかできないけど、
>>524は超人的なプログラムが組めるそうです。
見せてよwプログラムをw もしくはオープンソースへの記名や著書等々当然あるでしょ?w

527 :仕様書無しさん:2015/01/18(日) 20:38:57.07
いや、納品したあとで問題おこるのは分かるよ?
設計途中で問題が出てきて頭を悩ますのも分かる。

でもコーディングの最中に次から次へ問題起こすなよw
最初からある程度見通しとこうぜ…

528 :仕様書無しさん:2015/01/18(日) 21:48:42.48
>いや、納品したあとで問題おこるのは分かるよ?
>設計途中で問題が出てきて頭を悩ますのも分かる。

自分のプログラミングしたソフトを納めたユーザー先で、
社外の監査があるわけ。 そこで俺の作ったソフトについて指摘がされる。
おれのところにはユーザーから追加仕様がくる

俺のユーザさんは、偉い人から、次回の監査までに直しておけといわれているわけ
次回の社外監査までに指摘事項をクリアしておかなきゃならん。
俺のユーザもそれに必死に対応していのがわかる、そして俺も必死なわけ

というのがプログラマの世界だ。

529 :仕様書無しさん:2015/01/19(月) 02:44:32.09
そう。だからメンテナンス性が重要になる。

本質的なコードを最小にするためにライブラリを使ったり作ったりして、
絶対に変わることとがない部分と変わりやすいことにわけ。

そして変わりやすい所のコードを最小限に保つ。
それが技術なんだが、それができてない奴が多い。
そういうやつほど、仕様変更に文句を言う。

個人が文句をいうだけならまだいいが、会社全体でそれがはびこってると
絶対に仕様が変更されないように、作る前に要求を洗い出せと無茶を言う。
ユーザーが自身が何が欲しいか何が使いやすいかわかってないのに
作る前に洗い出せるかっつーの。

そしてソフトウェ会社がずるがしくなると、ユーザーも開発社も
それが最適なもの変わってないものに対して、これでいいですねと確約させ
変更に対して追加金額を要求してくる。最終的にいくらになるかわからない。

こんなやり方で満足できるシステムが作れるわけがない。

530 :仕様書無しさん:2015/01/19(月) 02:46:09.17
不具合なら修正して当然だが、納品後の追加仕様ってどんな契約だよ

531 :仕様書無しさん:2015/01/19(月) 02:58:44.10
>>529
メンテナンス性や分かりやすさってホント大切ですね。
自社システムって自己流のスパゲッティが多そう…。

そういうシステムは堅牢。
作るのには、場数を踏んだ経験か、センスが求められますね。
大抵の人はセンスが足りないので場数を踏んだ外注に頼ることになる

532 :仕様書無しさん:2015/01/19(月) 17:34:24.06
トライアンドエラー方式でないとまともなシステムなんか作れるわけねーだろ

つまり納品してはい終了の業界スタイルは客の満足は絶対得られない

533 :仕様書無しさん:2015/01/19(月) 18:43:00.28
>>532
なら、ちゃんとした保守契約結べよ
払うもの払ったら、対応してくれる会社あるだろ

534 :仕様書無しさん:2015/01/19(月) 19:19:52.41
>>533
そう。つまりそうなって開発費用が莫大なものになる。
だから、外注は事実上不可能ってこと。

535 :仕様書無しさん:2015/01/19(月) 19:44:24.17
プロトタイプ開発が顧客のレビューのためだと思っている顧客が多すぎる。
そんなのなら机上でやった方が早いだろう。
運用してデータをとってなんぼ。
ちょっと触ってホントに必要な要求がわかるような顧客なら、最初から要求聞き取れる。

536 :仕様書無しさん:2015/01/19(月) 20:53:25.98
>>535
なにが言いたいの?

537 :仕様書無しさん:2015/01/20(火) 05:44:17.83
>>536
なにがわからないの?

538 :仕様書無しさん:2015/01/20(火) 06:25:06.62
>>537
何もわからないよ

539 :仕様書無しさん:2015/01/20(火) 06:34:06.98
>>538
そんなヤツが聞いても何にもならないので、畑でも耕してるか、レジでも打ってればいいんじゃないかな。

540 :仕様書無しさん:2015/01/20(火) 06:37:46.53
うん、これじゃ御用聞きもできないのは当然だわ

541 :仕様書無しさん:2015/01/20(火) 06:48:18.36
>>540
だから顧客に聞かずにプロトタイプ使うのだろう。

542 :仕様書無しさん:2015/01/20(火) 06:50:12.56
顧客は自分がほしい物を知らないという前提を
みんな見ようとしないんだよな。

実際に動くものを使わせてみないと
正しい意見はでないよ。

使わないでいう意見は、
こんなのがあったら使いやすいんじゃね?という
"素人"の意見でしか無いからね。

543 :仕様書無しさん:2015/01/20(火) 06:54:15.03
使わせて意見を求めても、元々思ってたのを言うだけで愚策。
効果を測定して何が必要かを調べるべき。

544 :仕様書無しさん:2015/01/20(火) 07:16:49.55
効果を測定するのは不可能なのに
どうやって測定しろと?

545 :仕様書無しさん:2015/01/20(火) 07:38:58.55
バカには不可能

546 :KAC:2015/01/20(火) 07:42:40.89
そんな賢い顧客がいたら、
 そもそも"君のところに発注せずに客は自分で解決する"
とは考えないの?

547 :仕様書無しさん:2015/01/20(火) 08:44:40.58
>>546
そうなる可能性は高いけど、ロジックや段取りを考えるのは得意でも開発まではとても手が回らないって人も多い

548 :仕様書無しさん:2015/01/20(火) 08:47:12.98
>>546
何を言っている。
要件分析と開発技術が同じものだと思っているのか?
どんな家が必要かわかれば、誰でも建てられると思うか?

549 :仕様書無しさん:2015/01/20(火) 08:56:38.49
>>548
家の話なら、
大抵の客は「どんな家が良い家か」なんて理解してないだろ?
客の要望をきいて良い家を設計するのが建築士の仕事。

「家の何たるかを知らない客が多い。模型を見せるのは愚策。」
なんて建築士が言い出したらおかしいと思わないか?

で、
> どんな家が必要かわかれば、誰でも建てられると思うか?

に対する答えは、自分で設計できれば後は大工に発注する。ってこと。
ソフト業界で言えば、自分で設計書書いてソフトハウスに発注するってこと。
「設計」を受注してるって意味をもう少しまともに考えたほうがいい。

550 :仕様書無しさん:2015/01/20(火) 09:07:59.19
>>549
建築でそういう技法があるかはわからないが、モデルハウスを建てて実際生活してみればいいんじゃないか。

分析=設計ならそうだろうな。実際は違う。
そもそも設計を受注しているなんて前提はどっから?

551 :仕様書無しさん:2015/01/20(火) 10:44:30.18
>>542
の意見が正しい
客はボンヤリか、ボンヤリすらイメージがない。
だから何十回と試行錯誤しながら作る方式でないとないとダメ。
それでは費用は凄まじくかさむ。
だから、自社で作るしか成立しない

552 :仕様書無しさん:2015/01/20(火) 17:48:45.09
グダグダ言っても結論的に>>1が正論だったでおしまい
くだらんスレはおしまい

553 :KAC:2015/01/20(火) 18:47:43.63
>>551
客がぼんやりしてるからってそれに合わせちゃいかんだろ。
聞き出していいもの提案するのが仕事だろ。

客に「あ、それいいね!」と言わせるのが基本。
客の言う通りに作って試行錯誤なんて愚の骨頂だし、
最終的も結局「いい物」なんてできあがらない。

554 :仕様書無しさん:2015/01/20(火) 20:25:53.26
>>553
あ、それいいね。
で客が実物を見て、やっぱりこれで正解!と言うなら、通販で服買った客からの返品は発生せんわw

555 :仕様書無しさん:2015/01/20(火) 20:31:00.87
>>553
あ、それいいね!で発注しても実際使ってみたら良くなかった。=提案者の能力が低い=客は悪くない。
よって糞システム。これが客の思考だから。誰のためのシステムか?客のため。
客が満足を得ないならそれは失敗システム。

556 :KAC:2015/01/20(火) 20:34:40.24
>>554
なにか勘違いしてないか?

 ・話を聞き出す
 ・客にあったものを提案する
 ・客と詰めて「これいいね」と思える仕様にする
 ・仕様書やプロトタイプなんかで最終イメージの合意を取る。
 ・作って納める

こういうのが普通の流れ。
作り始めてからの手直しなんかほとんど起こらんし、
客のイメージと違うなんてことはほぼありえない。

557 :KAC:2015/01/20(火) 20:39:22.30
>>555
なにを主張したいのかよくわからんけど、
「制作サイドが無能なんだったら客は悪くない」って言いたいんだったら
それは当たり前の事だけど・・・・

ここはマ板なんだから、
自分達が無能だったらって前提立てる意味がよくわからん。

558 :仕様書無しさん:2015/01/20(火) 21:05:16.84
>>556
完成しました。実際に使ってみました。思っていたのと違いました。終了w
運用テスト期間を5年ほどとってくれ
5年間は何度でも修正可能で

559 :仕様書無しさん:2015/01/20(火) 21:06:51.09
>>557
ユーザーが最終的に「これは最高のシステムだ!」と言わない限り失敗だっつーの
極めてシンプルだろが

560 :仕様書無しさん:2015/01/20(火) 21:08:08.06
>>556
そのプロトタイプシステムを数年にわたって何度もやってくれるの?それなら成功するね。

561 :仕様書無しさん:2015/01/20(火) 21:13:35.21
>>556
>客のイメージと違うなんてことはほぼありえない。
システム開発の訴訟がいっぱいあるという現実がこれを完全否定していますが

562 :KAC:2015/01/20(火) 21:36:58.67
>>558-561
大体言いたいことがわかってきた。

「俺は無能だから客の要求なんて満たせん」
ってことが主張したいんだな。
それなら言ってることも合点がいく。

・・・まあ、がんばれ。 としか言えん。

563 :仕様書無しさん:2015/01/20(火) 22:43:38.98
どっちだろうと馬鹿がやれば失敗する。
社内だと障害点が減るから失敗がごまかされやすいだけ。
社外でもちゃんと頭から丸投げすれば同じようになる。

564 :仕様書無しさん:2015/01/20(火) 23:13:08.39
このスレはマ板にあるけど、どこぞの事務屋がグチを垂れるために立てたスレだからね
事務屋視点で語るレスが多いよ

565 :仕様書無しさん:2015/01/20(火) 23:50:33.41
まあ、システムありきの会社でない限りは「システム化成功=作業減る」に
なるわけで。 そうした場合は減った分の人を減らすか、より高いバリューの
ある仕事をしてもらう必要が出てくる。 システムにやらせるまでもない瑣末な
仕事をやるっていう選択肢もなくはないが、そういう無駄はかけないだろう。

マだったらプロジェクト終わったら全く新しいスキルセットの別のプロジェクトに
回されるのは普通で、出来ないなあと思うような人でも新しい環境に合わせて
多少は勉強して仕事はしてくれる。 勉強して新しいことに臨むってのはマに
とっては当たり前だったりするが、そうじゃない人のほうが実は圧倒的に多く
ギャップを生み出しているんだよな。

だから変化したくない、新しいことをしたくないとしがみついて失敗することが
多い。ただ自社開発だと変化しよう頑張ろうって人が身内になるわけだから
触発されて他人事じゃなくなって成功しやすくなる。 丸投げで他人事になら
ないなんて意識高い人はそんなにいないからね。

566 :仕様書無しさん:2015/01/21(水) 12:45:26.89
>>564
何目線だろうが客観的な事実として開発者の能力は圧倒的に足りてない
世の情報処理システムの9割以上はガキの使いレベルだという驚愕の真実

567 :仕様書無しさん:2015/01/21(水) 12:58:31.83
開発力あるやつ雇用しても運用とか割に合わない仕事させてたらもったいないよな。
プロジェクト管理と運用能力だけあるやつを情シスとして雇うのが一番いいんじゃないか。

568 :仕様書無しさん:2015/01/21(水) 19:30:21.68
体育会系「おう、プログラマの管理なら得意だぜ!」

569 :仕様書無しさん:2015/01/21(水) 19:43:22.55
根性論とか昭和の遺物。

570 :仕様書無しさん:2015/01/21(水) 22:40:33.80
>>567
運用を下に見ているみたいだけど、機能追加を含めての場合だと普通の
開発とそんなに変わらんというか、書捨てでプロジェクトをジプシーするより
よほどためにはなるけどね。 まあ、ポジションと自分のスタンスによるけど。

たまっていくデータやログ、利用者からの要望やそれの対応、取りきれなくて
出てくるバグ、機能追加に対するよい追加の方法の検討とか得られるものは
決して小さくはないし、劣ってもいない。

まあ、波風立たず5年も10年もやりたいものではないけどね。

571 :仕様書無しさん:2015/01/21(水) 23:11:31.25
>>570
下に見てないから、高い給与で下手な仕事しかせず、割に合わないんだろう。
半端な技術者ならどっちで使っても大して変わらないと思うが。

572 :仕様書無しさん:2015/01/22(木) 19:59:07.68
>>564
事務屋ならいいだろ
大半がなんちゃって正社員の実質派遣社員なんだから
自社で働いてるだけマシ

573 :仕様書無しさん:2015/01/22(木) 22:48:29.21
あんまり正社員とか派遣とか言わないほうがいいよ
そんなものにすがって生きている馬鹿に見える

574 :仕様書無しさん:2015/01/22(木) 23:52:18.56
【速報メモ】ITACHIBA会議「コスト削減のITはもう古い! 勝つためのITをみんなで考える」に行ってきました
http://dev.classmethod.jp/etc/itachiba03/

SEやマ以外がこれくらい意識高い系だといいんだけどなあ。

社長から「君たちは要らない」と宣告されたIT部門の4年後
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/012000165/

現実は上も下もこれより更に下な状態だからなあ。

575 :仕様書無しさん:2015/01/23(金) 00:49:28.24
>>568-569
案外、高卒自己流PGチームを上手に機能させるのは体育会系DQNだったりする事例もあるw

576 :仕様書無しさん:2015/01/23(金) 01:08:42.26
体育会系DQNはプロジェクトをめちゃくちゃにした例しかみたこと無いが?
成功しているようにみえるのは、体育会系DQNを適当にあしらって
いうこと聞かずに勝手にやっているチームぐらいだね。

577 :仕様書無しさん:2015/01/23(金) 01:29:31.54
気合や根性や上下関係でまともなシステムができるわけがないからね

578 :仕様書無しさん:2015/01/23(金) 01:47:54.00
権力を持った日曜プログラマが性能や依存関係無視の下手な意見出したりするより、全くの無知が何もしないほうが上手く回るというのは納得できる。

下手な意見を引っ込めさすのに全力で戦争するより、鵜呑みにして責任を逃れる方が楽だし。
超絶技巧で何とかする道もあるが、手柄はそいつのものだろうし。

579 :仕様書無しさん:2015/01/23(金) 03:33:47.68
困難の前で垂直思考で無限ループしてハングアップする文系より
体育会系の方が期日に間に合わせる統率力や機転や瞬発力などのセンスが
あると思える。

580 :仕様書無しさん:2015/01/23(金) 03:41:34.83
>>579
は?

581 :仕様書無しさん:2015/01/23(金) 22:09:56.01
馬鹿は罪悪感がないから強いんだよ。

例えば自分がつくったバグでも
こっちでは再現できないんですよ。
Windowsのバージョンのせいですね。
って言い切る。

馬鹿で無知だから、ほんとうにそう思って言い切る。

だから手に負えない。

客の方も賢くならないとだめというのはこういうときのため。

582 :仕様書無しさん:2015/01/23(金) 22:23:40.84
バグで罪悪感とか新人かよw

583 :仕様書無しさん:2015/01/23(金) 22:47:27.52
>>582
お前か。平気でバグ埋め込んどいて、
客にも自社にも損害出しておいて
俺は悪くない。って言う奴はw

584 :仕様書無しさん:2015/01/23(金) 23:03:02.70
たまに顧客情報が消えるだけだろ
ごちゃごちゃ言うな

585 :仕様書無しさん:2015/01/23(金) 23:07:46.98
お前らがごちゃごちゃ言わなホンマは成功やったんやで、、、

586 :仕様書無しさん:2015/01/24(土) 01:09:16.67
規模にもよるが全てのパターンを網羅してテストなんて現実的ではないし、
そういうのも考慮してクロスチェックの意味合いも含めてコード書いた奴と
テストする奴はなるべく分離するし、テスト期間を設けるわけだし。

時間がなければテスターに渡す前に満足にバグとりも出来んし、何人もの
目をすり抜けてなんてのはざらだし。 無限に時間があればバグ無しを
実現できるかもしれないけど、そんなのは現実的ではないわけで、こっち
だけに責任を押し付けられてもなあというのが正直なところ。

だから細かいところをグチグチと言ってるんじゃなくて、業務やら運用やらを
考えて、出たらヤバイのはきちんと考えてテストを作って、やれよと思うが、
そういう想像力のかけらもないのが担当だったりするからなあ。 お前ら
検収でハンコ押してんのに、何言っているんだってのはよくあることで。

587 :仕様書無しさん:2015/01/24(土) 01:33:32.02
最近(でもないか、数年前)に気づいたのはテストを書くことよりもまず
テストが不要なコードを書くということ。
テストを頑張ってやるのではなく、頑張ってテストを
しなくて済むようにすることのほうが重要だってわかった。

それから開発者からみると、やる意味が無いテストやってるなぁ
(同じ関数を呼んでるのでぜったいにおなじになる)とか
それとこれは同じように見えるけど、コピペされてそれぞれ
修正されてるから2つともやらないといけないよ。みたいなことがよくある。

こういったのって結局開発者にしかわからないことなので、
開発者にしか効率のよい(無駄なことをしない)テスト仕様書を
書くことが出来ないわけだが、開発者だとわかっているがゆえに
網羅テストになってしまう。(条件、A、B、C、D、Eがあった時
全組み合わせを試さないと完全にテストしたと言えないから)

こういうのは逆に内部を知らない人に任せて、それなりなテストだけど
それでテスターがOKって言ったでしょ? じゃあバグを見逃したら
テスターが悪いんだよwって責任転嫁したほうが楽

もちろんそれじゃいけないわけで、じゃあどうするかといえば
最初に言ったとおり、テストが不要なコードを書くということ。
これって仕様だけじゃテストは作れないってことなんだよね。
コードによってテストが必要か不要かが変わってくるから。

まとめると、コードを各プログラマがテストが不要になるような
綺麗なコードを書いて、そして重要な部分だけをテスターに依頼した方がいい
ってことになる。重複したコードを減らすことでこれがテストを不要にすることにもつながるから
結局、プログラマに求められる技術の一つであるコーディング力は重要ってことなんだよね。
その力次第で開発工数もテスト工数もが大きく変わってくる。

588 :仕様書無しさん:2015/01/24(土) 01:40:29.93
>>586
> そういう想像力のかけらもないのが担当だったりするからなあ。 お前ら
> 検収でハンコ押してんのに、何言っているんだってのはよくあることで。

そもそも検収でハンコを押すというやり方がおかしいんだよ。

このやり方っていうのは言い換えると、検収して問題がないことを
確認しろって言っているわけだが、じゃあ、あなた
確認項目を全て言えますか?

言えないでしょう? そう確認するべき項目が多すぎるわけで、
それらを現実の時間でやれるわけがないわけ。

不可能なことを要求して、ハンコを押させてるってことを自覚しないといけないよ。
このハンコは単に「バグがあっても文句は言いません」という契約のために押させているのであって
バグがないと認めたから押しているとは思わないように。
ハンコを押してもバグがないと認めたわけじゃないんだよ。

589 :仕様書無しさん:2015/01/24(土) 02:07:48.00
>>587
昔はどんなバカなテストを書いてたの?

590 :仕様書無しさん:2015/01/24(土) 02:12:24.08
>>587
テストを専門にやってた俺に言わせれば、
開発者にフロー書かしても絶対に漏れがあるから、
テスターは全部動作してみてフローを完成させるところから仕事

フローもまともに書けないのに、テストの要不要の判断なんか任せられない

591 :仕様書無しさん:2015/01/24(土) 07:40:40.25
>>588
本当にそんなこと考えてるなら仕事をナメてるとしか思えない。

検収ってのは、問題がないことを確認する事。
確認の仕方なんてのは時と場合によって様々だけど、
「全部確認できないから諦めてる」みたいな考えだと論外。
基本は"全部確認する"んだよ。
なんらかの理由で確認不要なものがあれば端折るだけで。

592 :仕様書無しさん:2015/01/24(土) 08:24:45.54
オンオフできる項目が100以上ある場合でも
全部の組合わせを確認してるのかな?

593 :KAC:2015/01/24(土) 08:44:24.62
>>592
あまりにも素人すぎる発言だと思うが・・・

本当に必要なら確認するに決まってる。
普通は内容見て必要性判断してから効果的に実施していく。

594 :仕様書無しさん:2015/01/24(土) 10:35:15.10
>>592
まともな会社は、普通はしない。
・100の項目が全て、他の項目と連動するような設計はダメ。
・よって、関連のある項目ごとに複数グループに分けた設計で、テストケースを減らす。
・仕様から、グループごとの設定値組み合わせを生成するツールを使う。
・それでも組み合わせが多い場合は、テストファーストにする。
・生成ツールは自作出来る。

595 :仕様書無しさん:2015/01/24(土) 11:45:43.65
社内エンジニアは知らないが、まともなエンジニアなら、テストの容易さも考えて設計する。
依存関係の排除は最たるもの。

596 :仕様書無しさん:2015/01/24(土) 11:55:30.62
>あまりにも素人すぎる発言だと思うが・・・

三点リーダーだから、素人がやる点の付け方とは違うな。
素人は四点になったり五点になったりだ

597 :仕様書無しさん:2015/01/24(土) 11:55:40.95
>>590
> 開発者にフロー書かしても絶対に漏れがあるから、
> テスターは全部動作してみてフローを完成させるところから仕事

大前提を忘れてないか?
全部動作することは時間的に不可能なんだよ。


テスターがいう「全部動作」っていうのは全部の
組み合わせてを試していない。一部動作でしか無いからな。

で、わかってないテスターは全機能を実行しました!って
自信満々に言う。いや8個のチェックボックスがあったとき、
テストするのは2の8乗で、256個でしょ?
あんた、8回しかテストしてないじゃん。

598 :仕様書無しさん:2015/01/24(土) 11:59:54.74
>>594
> ・100の項目が全て、他の項目と連動するような設計はダメ。

その通り。だからまずテストを頑張るのではなく
テストするべきものを減らすことが重要だって書いた。

あなたのいう設計が何を行っているかわからないけど、
仮に紙のドキュメントの設計が完璧でも
実装、つまりコードがコピペされているかもしれない
そうするとテストはコピペの分だけ必要になる。

実装を見ないとテストするべきかどうかわからないし、
それ以前に、コードのほうを修正してテストするべき数を減らせという話になる。

だから、テスターにできたものをぽんと渡して動かしてみてください。じゃだめなんだよね。
まずコードを精査しないといけない。テスターがコードを精査して動作確認の前に
まずコードのまずい所を指摘(これコードレビューだな)をするのであれば、そのやり方でもいいけどさ。

599 :KAC:2015/01/24(土) 12:01:33.03
>>597
> 全部動作することは時間的に不可能なんだよ。

そんなこと、いつ決まったんだ・・・?

> テスターがいう「全部動作」っていうのは全部の組み合わせてを試していない。

なんで?
どういう理由でそんなことを主張し始めたのか全くわからん。

> で、わかってないテスターは全機能を実行しました!って自信満々に言う。

やってないなら言わないだろ。
なんで言うと思ったんだ?


どこからツッコんでいいのか判らんくらいに支離滅裂だな。
思い込みで話を進めるのはやめてくれないか?

600 :仕様書無しさん:2015/01/24(土) 12:05:24.52
>>595
> 社内エンジニアは知らないが、まともなエンジニアなら、テストの容易さも考えて設計する。

そのとおりだけど、じゃあ設計して実装したのは「まともなエンジニア」なの?って話がある。

私はまともなエンジニアではないです。って自己申請する奴はいないので、
そのエンジニアがやった仕事がまともかどうかを、判断する人が必要になる。
その判断は、まともでないエンジニアよりも、技術力がなければできないことなわけで。

コードレビューをテスターがやるのなら話は別だけど、
この資料のとおりにテストしてください。と言われたものをやるだけじゃ、テストに漏れが出るし。
全パターンをテストしてください。そのパターンはあなたが考えてください。
といったら全組み合わせをやらないといけないかもしれないから時間が足りない。

だから現実には、やる必要がないテストをやっていて、
やらなければいけないテストが不足している。
というような無駄で不十分なテストが行われているんだよ。

601 :仕様書無しさん:2015/01/24(土) 12:10:15.62
>>599
> > 全部動作することは時間的に不可能なんだよ。
>
> そんなこと、いつ決まったんだ・・・?

計算すればわかる。

コードの中に含まれる、if文の数を数えてみればいい。
ある程度の規模なら、おそらく1000個ぐらいあるだろう。
少なく考えて100個としよう。

それが単純な真偽値による条件分岐であっても
組み合わせの数は2の100乗で
1267650600228229401496703205376個のテストが必要になる。
全部動作することを確かめるのが不可能なのはこれで明らかだろう?

だから、組み合わせでテストをしなくてもいいように、テストの数を減らすための
設計と実装(コード)を書く必要がある訳。

で、中身を知らないでテストするっていうのは、どれだけの数をテストすればいいかわからないわけ。
だから設計と実装(コード)がテストの数を減らすように作られているかという
コードレビューが必要になる。

もしコードが2箇所にコピペされてちょっと修正していたら、テストが二倍になるってのはわかるよね?
そういうのを指摘して、テストを半分にするための指摘が、まず必要になる。
これなしてテストしても、無駄で不十分なテストにしかならない。

602 :KAC:2015/01/24(土) 12:11:18.33
>>600
なにを主張したいのかすらよく判らんが・・・

とりあえず、お前さんの言ってる「テスト」というのは
どういう工程で行われる、なにを目的としたテストを指してるんだ?

603 :仕様書無しさん:2015/01/24(土) 12:12:46.33
>>602
プログラマ以外のテスターと呼ばれる人が
担当するテストのことだよ。

604 :KAC:2015/01/24(土) 12:13:59.80
>>603
「どういう工程で行われる、なにを目的としたテストを指してるんだ?」

605 :仕様書無しさん:2015/01/24(土) 12:20:24.55
>>604
工程は各会社でバラバラなので定義不可能。
目的も各会社でバラバラ。

だから、プログラマ以外のテスターと呼ばれる人が
担当するテストだと書いた。

コードを書いてない(見ていない)人が、テストするべき数を
正確に知ることは不可能という話をしている。

俺の主張は、(テスターが)テストを頑張るよりもまず、
テストの数自体を減らすことのほうがはるかに重要ということ

(なぜなら2の100乗のテストのように、下手なコードだと
テストの数は膨大になり、いくら時間があっても足りない)

そして、テストの数が本当に減っているか? 少ないテストで十分か?っていうのを
判断できる人=コードをよめる人がコードレビューをすることが重要だって話をしている。

その後だよ。プログラマ以外の人にテストをやらせるのは。
でないと、コードを見てない人は、どれだけテストすればいいかわからないし
全部やろうとしたら時間は足りない

606 :KAC:2015/01/24(土) 12:37:15.97
>>605
テストの目的も方法も全く理解していないのはわかった。

まったく話にならないから、せめて
http://itpro.nikkeibp.co.jp/article/lecture/20070209/261590/
くらいは読んで理解してくれ。

607 :仕様書無しさん:2015/01/24(土) 12:41:10.45
>>606
てめーの言葉で反論できないなら
レスするなよ。

無能だな。

608 :仕様書無しさん:2015/01/24(土) 12:44:53.15
>>606
そういうのは「テストの数」に焦点を当ててないからだめなんだよ

関数があって、その関数をテストする方法について
語っているだけ。

現実に発生する問題は「時間」

テストをするべき項目が増えると、倍々ゲームでテストする数は増える。
まず最初に、テストする数を減らすことの方が重要。

そうやってテストする数を減らして、やっと>>606の話になるんだよ。

609 :KAC:2015/01/24(土) 12:46:21.81
>>607
そもそも>>604に対してまともに回答できてないんだから仕方なかろ。

610 :仕様書無しさん:2015/01/24(土) 12:49:52.34
テストなんか大体でいいんや。
そもそも使えないもん作って必死でテストしてるの見てると、滑稽すぎて涙でるわ。

611 :仕様書無しさん:2015/01/24(土) 12:49:52.99
>>609
だから工程は関係ないって言っただろ。

逆に言えば、すべての工程に当てはまる話、
すべての目的に当てはまる話だと思えば。

お前が考える工程と目的であっても
プログラマ以外がテストするのなら当てはまることだよ。

どれだけテストすれば十分で無駄がないかは
コードを見ないとわからない。

612 :KAC:2015/01/24(土) 12:51:04.29
>>611
工程が違えば作業も目的も全く変わることすら知らないの?

613 :仕様書無しさん:2015/01/24(土) 12:56:34.52
>>612
だから目的が違った所で、
それを実現するための工数ってのは
どこにでもつきまとう問題なんだって。

だからどの工程でも目的にも当てはまると言ってる。

テストの工数というのはテストの数のことでもある
テストを頑張るよりも、まずテストの数を減らすことが重要。

関数がコピペされれていたら、テストの工数が二倍になることぐらいわかるでしょ。

614 :KAC:2015/01/24(土) 13:00:23.29
>>613
その主張が間違ってると言ってるのすら理解できてないのな。
せっかく教えてやった情報も理解できてないし。

とりあえず、おまえさんが最低限の常識を理解できるまで、
基本的に相手するのやめとくから、好きに騒いでてくれ。

615 :仕様書無しさん:2015/01/24(土) 13:01:11.49
>>614
間違っているのはお前の方だ。

お前は根拠なく、俺が間違っていると言うな。

616 :仕様書無しさん:2015/01/24(土) 15:43:40.28
>>600
>>>595
>> 社内エンジニアは知らないが、まともなエンジニアなら、テストの容易さも考えて設計する。
↑は必要条件。

>そのとおりだけど、じゃあ設計して実装したのは「まともなエンジニア」なの?って話がある。
↑は十分条件

何を主張したいの?

617 :仕様書無しさん:2015/01/24(土) 15:52:02.16
>>616
書いてあんだろ?

> 俺の主張は、(テスターが)テストを頑張るよりもまず、
> テストの数自体を減らすことのほうがはるかに重要ということ

618 :仕様書無しさん:2015/01/24(土) 16:39:58.81
テストに関して言えばテスターを含めもう少し勉強しろよとは思うな。
書籍なんかにしても数が少ない分、質が高いのも多いし。

書籍買う余裕がないならせめてJSTQBのシラバスに目を通すくらいの
ことはしてもらいたいくらい。
http://jstqb.jp/syllabus.html#syllabus_download

テストをやること自体は誰にでも出来ることだが、テストを作るのは本来は
ものすごく高い知識が必要になるのにするのと作るのとごっちゃにしてるから
どうしようもならんなあ。

619 :仕様書無しさん:2015/01/24(土) 16:43:05.15
納品前や検品時のテスターから言わせれば、
入力と出力があれば、間がどうであれテストするんだから、
1回のテストでの量を減らすのは、コーディングよりも仕様の方が大事

糞仕様でテストが膨大な量になることは良くある

バグを少なくしたいってのなら、コーディングは大事
糞コーディングで、自分でもコピペ箇所を把握してなくて
全部の箇所が直って来るまで、何回も修正依頼する必要があったりする

こっちはテスト量じゃなくて、テスト回数が増える

620 :仕様書無しさん:2015/01/24(土) 17:21:21.30
> 納品前や検品時のテスターから言わせれば、
> 入力と出力があれば、間がどうであれテストするんだから、

それって正常系のテストだけで、
機能があったらその全部の組み合わせのテストまでしないでしょ?

例えばオンオフスイッチが10個あったとしたら、
それぞれを単独でオンにして10回テストする程度だよね?

それで、AだけON、BだけONの場合はちゃんと動作して
AとBの両方をONにした時は動作しないってなった場合、
誰の責任になるの?

621 :仕様書無しさん:2015/01/24(土) 17:22:27.58
>>618
> テストをやること自体は誰にでも出来ることだが、

そのだれでもやれるテストというのは、
あらかじめテストする項目が一覧表になっていて
その通り手動で実行することを言っているんだよね?

622 :仕様書無しさん:2015/01/24(土) 18:17:29.42
>>620
なんでしないの?
当然するだろ?

しないって言う無理な設定だから、誰の責任になるか分からない事態が発生するわけでしょ

623 :仕様書無しさん:2015/01/24(土) 18:33:43.43
結局、自社開発なんかだと必然的に経験が少ないから、テストを減らすように設計するとかそういうノウハウが不足しがちなんだよ。
それと、社内だから無知からの無理な命令も通ってグダグダになる。

624 :仕様書無しさん:2015/01/24(土) 19:08:31.62
>>622
> なんでしないの?
> 当然するだろ?

え? するの?

オンオフスイッチが10個あったとしたら、
その組み合わせは、2の10乗で1024回のテストになるんだけど。

最初に俺が言ったように
> それぞれを単独でオンにして10回テストする程度だよね?
10回テストするだけだよね?

625 :仕様書無しさん:2015/01/24(土) 19:16:29.65
組み合わせ爆発を甘く考え過ぎ。
網羅テストなんかしたら、星の寿命が尽きるほどの
時間がかかるぞ。

626 :仕様書無しさん:2015/01/24(土) 19:21:48.76
直交表を使ってテストの数を減らす方法もあるけど、
これは、テストしないパターンがあっても
きっと大丈夫だろうという希望的観測にもとづいているしな。

627 :仕様書無しさん:2015/01/24(土) 19:26:12.83
猿みたいに愚直にテストしてるから毎日残業続きなんだろ

628 :仕様書無しさん:2015/01/24(土) 19:39:01.47
だから全パターンをテストするなんてアホなことはやめろという話

629 :仕様書無しさん:2015/01/24(土) 19:44:46.27
>>624
テスターとしては、まずテスト仕様として網羅テストを提案する
製作者ではない者が製品が正常であることを担保するには
これ以外の方法はない

期間や予算の都合でできないなら、何を省略するかを決める
例えば、フリーの数字入力なら、上限下限、指定された閾値とそれらの中間値だけテストするなど

省略した部分での不具合はテスターの責任ではない
省略しなければならない部分が多い仕様や予算や期間は、テスト不足でリスクが高い


例に出ている10個のオンオフスイッチなら、全部やらないほうがどうかしている。
機能として必要なんだから10個のオンオフスイッチがついているわけで、
不要なのにつけているのは只の馬鹿

630 :仕様書無しさん:2015/01/24(土) 19:48:29.04
10個のオンオフスイッチというのは例であって
たった10個でも1024回のテストが必要になるって話。

実際のソフトでは10個よりもはるかに多くの条件がつくわけで、
仮に倍の20個だとしても、テストの数は1048576回になる。

フリーの数字入力を上限下限など、4パターンにだけやることにしたとしても
その入力項目が10個あれば、その組み合わせは1048576個にもなる。

省略した所でテストの数が多い事には変わらないんだよ。

631 :仕様書無しさん:2015/01/24(土) 19:49:23.91
>>629
あくまで一般論だけど、10個のオンオフスイッチがあって、1024通り全てが有効ってパターンは少ないんじゃないの?
無効なパターンや重複があって、実際に起こりえるのは半分以下っていうのもよくある話。
そういうのを前もって絞り込むのは、仕様を作る側の仕事じゃないかな

632 :仕様書無しさん:2015/01/24(土) 19:51:17.81
>>624
>オンオフスイッチが10個あったとしたら、
>その組み合わせは、2の10乗で1024回のテストになるんだけど。

直交法とか知らんの?

633 :仕様書無しさん:2015/01/24(土) 19:51:40.61
>>632

626 名前:仕様書無しさん[sage] 投稿日:2015/01/24(土) 19:21:48.76
直交表を使ってテストの数を減らす方法もあるけど、
これは、テストしないパターンがあっても
きっと大丈夫だろうという希望的観測にもとづいているしな。

634 :仕様書無しさん:2015/01/24(土) 19:53:20.58
極端な例だと、UNIX系のパーミッションの設定。9ビット(+α)で、最低でも512通り以上の組み合わせがあるけど、実際に使うのは10数種類だったり

635 :仕様書無しさん:2015/01/24(土) 19:54:45.17
求められてるテストがなんなのかわかってないから
組み合わせは1048576個
とかアホな話になるんだよ。話にならん。

636 :仕様書無しさん:2015/01/24(土) 19:56:53.05
>>635
じゃあ、どうなるのか反論しろよ。

637 :仕様書無しさん:2015/01/24(土) 20:01:26.16
>>636
文盲かよ
今まで書かれてきた内容くらい読んでから発言しろ。ハゲ。

638 :仕様書無しさん:2015/01/24(土) 20:02:46.40
>>630
テスターとしてはポンコツ仕様ゆえにテストが膨大になってるなら、
只のいいお客さん

上で誰か書いているが、テスト仕様が決まっていて、ただテストするだけなら技術はいらない
必要に応じて人員を投入して代金をいただくだけ


>>631
全てが有効ってパターンは少ないとは思うが、ユーザーが触れるところにスイッチがあるなら、全通り試さざるを得ない
無効だと思っていても、思いもよらない出力があることはある

仮に、AとBの組み合わせだと壊れます、と言われても、それが仕様ならちゃんと壊れることを確認する
壊れるのでテストしないでください、と言われたらしないだけ

639 :仕様書無しさん:2015/01/24(土) 20:08:46.54
>>638
そういうことじゃなくて、無効な組み合わせを選べないように前以って弾いておけば、その分テストも減るんじゃね?って話

640 :仕様書無しさん:2015/01/24(土) 20:16:51.12
>>639
そんな話はどうでもいい

641 :仕様書無しさん:2015/01/24(土) 20:17:25.03
>>639
それはそう。仕様作る側の問題
テストにもコストがかかるってことを理解していれば避けられる話

オンオフスイッチが10個あって、
それぞれを単独でオンにして10回テストすれば十分なら、
その10個を選択するスイッチにすれば良い

なってない以上、テストせざるを得ない

642 :仕様書無しさん:2015/01/24(土) 21:07:27.73
>>641
んなわきゃねーって話をずっとしてるんだろうが
人の話聞けよ

自分の思い込みを修正する脳の機能が壊れてるんじゃないか

643 :仕様書無しさん:2015/01/24(土) 21:24:14.46
>>642
じゃあどういうわけなの?
2^1000の組み合わせ全部をテストするの?しないの?

644 :仕様書無しさん:2015/01/24(土) 21:24:44.15
誰が誰か判らん
名前欄に番号くらい入れろや無能ども

645 :仕様書無しさん:2015/01/24(土) 21:37:03.17
ようこんなアホどもがシステム作ってるな

646 :仕様書無しさん:2015/01/24(土) 21:38:32.25
テストって単語を最近覚えた素人が騒いでるだけにしか見えんが

647 :テスター:2015/01/24(土) 21:53:48.45
>>590,619,622,629,638,641
が俺な

>>642
で、そんな仕様の物があったら、どうするのさ?

俺の回答は
期間や予算の都合でできないなら、何を省略するかを決める
省略した部分での不具合はテスターの責任ではない

648 :仕様書無しさん:2015/01/24(土) 21:56:24.92
「アホどもがシステム」って言うけど世の中アホが動かしてんだぜ
システム屋にだけ無理難題押し付けんなよ

649 :仕様書無しさん:2015/01/24(土) 23:06:04.19
みんながそうだったらなんなんだ
幼稚園児か
さすが現代の〇〇〇〇どもはいうことが違うね

650 :仕様書無しさん:2015/01/24(土) 23:10:01.80
>>649
お前誰よ?

651 :仕様書無しさん:2015/01/24(土) 23:11:27.13
名乗ると馬鹿発言がバレるから名乗れないチキン

652 :仕様書無しさん:2015/01/25(日) 01:15:53.80
>>647
> 期間や予算の都合でできないなら、何を省略するかを決める
> 省略した部分での不具合はテスターの責任ではない

それWindowsでも同じこといえんの?

MS「期間や予算の都合でテストを省略した。それはMSの責任ではない」

653 :仕様書無しさん:2015/01/25(日) 01:18:43.37
プログラマ同士の会話が会話になってねーもんな

654 :仕様書無しさん:2015/01/25(日) 01:23:12.31
何をいまさら

655 :仕様書無しさん:2015/01/25(日) 01:37:14.28
開発会社「うちの技術力は高いです。不具合のないソフトを作れます」

顧客「じゃあ、あなたに開発を頼もう」

開発会社「テストにかかる金額は1兆円です」

顧客「ふぁ!?」

開発会社「1000万円の予算で仕上げるにはテストの数を0.1%に減らさなければいけません」

開発会社「0.1%のテスト対象ででた不具合は我が社の責任ですが、残りの99.9%で不具合が起きても我が社に責任はありません」

開発会社「予算がないあなたの会社の責任です。」

656 :テスター:2015/01/25(日) 01:46:57.22
>>652
テスターの責任ではないが、テストを省略したMSの責任だろ
それとも、MSはテスターで、別の会社が開発しているのか?

657 :仕様書無しさん:2015/01/25(日) 01:54:48.71
>>656
つまりテスターには責任がないが、
開発会社には責任があるってことだろ?

じゃあ、開発会社としてはどうすればいいんだよ?
テストを減らしてその結果バグが起きたときの責任は?

その責任をとりたくないから、検収という名のもとに
ユーザーに(テストしてないけど)これでいいですよね?って
ハンコを押させてるんだろ?

それひどくね?

658 :仕様書無しさん:2015/01/25(日) 02:08:40.38
結局のところ重要なのはテストの数を減らすことではなくて、
テスト自体が不要になる設計・実装にしないといけないってこと。

659 :仕様書無しさん:2015/01/25(日) 02:33:32.82
>>658
誰もそんな話してないだろ。

660 :テスター:2015/01/25(日) 02:36:48.70
>>657
単にバグが起きた時の責任については
ユーザーに対する責任は販売会社
販売会社に対する責任は開発会社

テストを減らしてその結果バグが起きた時の責任は、
テストを減らさざるを得ない状況を作った側にあるが、
結局のところ、不具合から逃げられるような契約にはなっていないことが多い

通常は契約で不具合に関しての取り決めをしていて、
開発会社からの納品後も一定の期間、
販売会社は開発会社に対して不具合の対応を求めることができるようになっていると思う

この契約があれば、やや開発会社が不利だが、
両社ともに対応する必要があることから、痛み分けともいえる

MSとユーザーの契約はよく読んでないが、たぶん不具合があっても知らない、くらいは書いてあるだろう
毎月のように修正が必要なポンコツをリリースしてもMS丸儲け

661 :仕様書無しさん:2015/01/25(日) 02:53:42.45
>>660
つまり責任のなすりつけ合いだね。
じゃあ不具合を無くすためにどうすればいいと思う?

662 :仕様書無しさん:2015/01/25(日) 03:01:00.35
>>655
契約後にそんな話になったら損害賠償ものだよ

663 :テスター:2015/01/25(日) 03:15:54.34
>>661
不具合がなくなるまでテストするしかない

テストをすることで不具合が減るから、それが商売になる
テスト以外の何かすることで不具合がなくなるなら、それ自体を商売にすればいい


ただ、テストのコストは仕様をよく考えれば軽減できる

664 :仕様書無しさん:2015/01/25(日) 03:27:36.02
>>661
アホか?

665 :仕様書無しさん:2015/01/25(日) 03:40:21.70
>>663
> 不具合がなくなるまでテストするしかない

コスト意識を持とうよ。

テストする=金がかかって当たり前
金を減らす=テストを減らすの当たり前

そんな考えじゃ、不具合は無くならないぞ。

666 :仕様書無しさん:2015/01/25(日) 03:41:09.57
>>663
> ただ、テストのコストは仕様をよく考えれば軽減できる

それじゃ遅すぎる

テストのコストを考えて仕様と設計と実装を行わないといけない。
あとからテストのコストを考えてちゃだめなんだよ。

667 :仕様書無しさん:2015/01/25(日) 03:48:47.68
>>666
で、お前誰よ

668 :テスター:2015/01/25(日) 04:19:40.16
テスターとしては、その製品の正常動作を担保するのに必要なコストを算出するだけだからな
企画や仕様の段階で呼ばれれば、何かコスト削減の意見を出すことはできるだろうが、普通は呼ばれない

テスターの仕事が世の中から無くならない以上、別工程で不具合がなくなるような技術革新は起きていないってことだろ?

>>665
別工程の話をしていいなら、プログラマが不具合作らなきゃいいだけじゃねーの?

>>666
619
> 糞仕様でテストが膨大な量になることは良くある
ずっと前からそれは言ってるけどね
もしかしたら、製品の仕様ではなく、テスト仕様の話だと思った?

669 :仕様書無しさん:2015/01/25(日) 04:40:32.79
>>667
俺は開発者だ。

670 :669:2015/01/25(日) 04:43:41.57
言葉が足りなかったな。

最近ようやくDevOpsとかいうのがでてきて
少しは理解されつつあるが、プロダクト全体を
見据えて開発する開発者だ。

だから当然運用もそうだし、テストも含めて
開発全般のことを考えてる。

だから、テストを頑張るのではなく、
まずテストを減らすように設計・開発するべきだと言ってる。
別々に分断して考えてたら、不具合は減らないんだよ。

671 :仕様書無しさん:2015/01/25(日) 07:47:50.75
テスターは自分の職域を守りたいだけじゃねーの?
開発も出来て一人前だぞ。

672 :仕様書無しさん:2015/01/25(日) 07:51:34.43
なんでだよ

品質を守ってるのはテスターだ
テストの設計hは誰にでもはできんが
開発は新卒でもできる

673 :仕様書無しさん:2015/01/25(日) 07:53:29.85
開発者は開発が出来て半人前、テストが出来て一人前かもしれんが
テストしか出来ん奴は橋にも棒にも掛からん。

674 :仕様書無しさん:2015/01/25(日) 07:54:14.36
橋にも→箸にも

675 :仕様書無しさん:2015/01/25(日) 08:00:58.40
>>672
お前が品質あげてるのか?
検査してるだけで、
直してないだろう。

676 :仕様書無しさん:2015/01/25(日) 08:11:06.08
建築物の監査をする人間より
砂利を運ぶドカタのほうが偉いんだ!

677 :仕様書無しさん:2015/01/25(日) 08:12:40.62
>>676
建設物の監査とドカタで
建設物が作られているとでも?

建設しているのはソフトウェア業界で例えれば
プログラマだよ。プログラマが一番偉い。

678 :521:2015/01/25(日) 08:57:23.01
個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例

なんてことになってるので、苦しいよね
開発者は

679 :仕様書無しさん:2015/01/25(日) 08:57:57.83
プログラマは偉くてもお前は特定派遣だろ

680 :仕様書無しさん:2015/01/25(日) 09:20:27.67
>>659
そこに考えが至らないからループしてるだけ。

681 :仕様書無しさん:2015/01/25(日) 14:23:06.71
>>678
あぁ、SQLインジェクションは特に要件に書かれていなくても
やるべきことで、それをやってないと開発社の責任になるという判例がでたからね。

SQLインジェクションとか、そういうのはテストで
完全に見つけるのは不可能だしね。
コード見ればすぐに分かるんだが。

682 :仕様書無しさん:2015/01/25(日) 15:56:35.12
ユーザーサイドの人間が居なくなると際限なくレベルが下がるな
ようこんなアホどもが(以下略

683 :仕様書無しさん:2015/01/25(日) 16:48:51.08
>>682
ユーザーサイドで実装できる奴はグダグダ言う前に自分で動いてシステム内製やっちゃってるみたいだしな
しかもソフトだけでなくハードもできて交渉までできる

684 :仕様書無しさん:2015/01/25(日) 18:09:07.64
プログラマーって勉強が出来る馬鹿でもなんとなく通用しちゃう所があるから勘違いしてる人多いよね

685 :仕様書無しさん:2015/01/25(日) 18:11:55.79
自己紹介乙

686 :仕様書無しさん:2015/01/26(月) 08:09:04.49
>>684
いや、大半が勉強もできないだろw
勉強ができる奴はプログラマにはなってない
プログラミングはやるけどプログラミングはシミュレーション等々で使うという途中工程の一作業でしかない

687 :仕様書無しさん:2015/01/26(月) 09:18:04.28
運用知識や業務知識なんて役に立たない
そんなもの誰でもできる!プログラミング技術があれば問題ない
そう豪語するやつに一切運用や業務知識を与えずにシステム作成を依頼した
(もちろん作成できるわけがないし使えないの確実だから並行で別の人に同じものを作らせていたけど)
当然システムは完成どころか何も作れない
奴「どういうデータをどういう処理をどういうタイミングでやればいいのか示せ!」
と普段声が小さいやつが振り絞って声を荒らげたから
俺「そういうのを運用業務知識って言うんだ!!!てめーが運用知識や業務知識いらねーって言ったんだろ!
  プログラミング技術だけで問題ない!ってほざいたのはどこの誰だ!!どの面下げてほざいてんだ!
  言ったからには実践しろがボケッ!」
と奴の倍以上の声量で言い返したら退出して二度と戻ってこなかった
というのがつい最近あった

688 :仕様書無しさん:2015/01/26(月) 09:24:59.02
>>687
それは運用知識じゃなくて、ただの仕様なんだが。。。

689 :仕様書無しさん:2015/01/26(月) 09:36:26.01
>>688
社内開発の話
業務運用知識があるから仕様を作れる

690 :仕様書無しさん:2015/01/26(月) 09:37:45.78
>>688それじゃコーダーじゃねーかwww

691 :仕様書無しさん:2015/01/26(月) 09:40:23.27
仕様渡さないとかアホですか?

692 :仕様書無しさん:2015/01/26(月) 09:41:09.48
処理の流れやデータの形式送受信タイミング等々はすべて完璧な書類を俺に渡せ!
ってことなんだろ。そこまで完成してたらシステム開発なんて99%以上終わってるだろ。

693 :仕様書無しさん:2015/01/26(月) 09:41:15.28
ここで技術が技術がって騒いでる人って
「仕様書貰わないとシステム作れません」
みたいなレベルの人多いよね

694 :仕様書無しさん:2015/01/26(月) 09:42:00.20
>>689
運用知識と仕様は別だろ。
お前が混同してるだけだから。

695 :仕様書無しさん:2015/01/26(月) 09:42:39.38
>>693
仕様なしで作り始める馬鹿よりましだが?

696 :仕様書無しさん:2015/01/26(月) 09:43:21.84
>>692
あまりにも無知過ぎる発言だな

697 :仕様書無しさん:2015/01/26(月) 09:43:34.24
>>695
いやお前が作れよ仕様書w

698 :仕様書無しさん:2015/01/26(月) 09:44:55.82
>>697
馬鹿発言すぎてツッコむ気も起きない

699 :仕様書無しさん:2015/01/26(月) 09:46:34.10
>>698
いや、そのとおりすぎるだろ
システム開発を命じられたならユーザーに会いに行って仕様書作れよ

700 :仕様書無しさん:2015/01/26(月) 09:47:14.66
>>699
話が変わってるの理解できない?

701 :仕様書無しさん:2015/01/26(月) 09:47:56.28
本気で仕様書はユーザーから貰うものだと思ってる人こわい

702 :仕様書無しさん:2015/01/26(月) 09:50:57.45
>>701
特定派遣の人で仕様書を作ったことがないんでしょ

703 :仕様書無しさん:2015/01/26(月) 09:55:22.33
>一切運用や業務知識を与えずにシステム作成を依頼した

この情報に対してのレスから優秀なのと馬鹿なのがあっさりわかるなww
【優秀な人】
 まずユーザーにあって要求定義・確認からか・・・(しかし業界用語とかわからず!?無理だなww)
【特定派遣】
 仕様書よこせよ!(すでにプログラミング工程!?!!?!?!??!!)

システム作成の依頼→即プログラミング というのがいかに馬鹿か気づかない馬鹿ども

704 :仕様書無しさん:2015/01/26(月) 10:00:06.01
>>703
お前が馬鹿なのはよくわかった

705 :仕様書無しさん:2015/01/26(月) 10:01:03.28
>>703
至極まっとうな意見でおしまいw
システム開発開始と言われて、どこから始めるかの視点が明らかに経験や立場から差が出てる

706 :仕様書無しさん:2015/01/26(月) 10:04:48.67
>>701「仕様書を貰う」「仕様書が手元に届かない」「仕様書が腐ってる」等々、「仕様書は他人が作っているもの」という経験しかないのだろう。

707 :KAC:2015/01/26(月) 10:11:45.04
>>687
落ち着け。
「運用知識や業務知識いらねー」と
「情報を一切渡さない」のは別物だ。

普通、業務知識や運用知識は「顧客から仕様を正しく引き出す」際に必要なんだが、
顧客の情報すら渡してないんだったら仕様を聞き出せないのはあたりまえ。
顧客と話させて、知識が入ることを思い知らせるのなら話は判らんでもないが
もう少しフェアに物事進めないと、ただのパワハラにしか見えんよ。

708 :仕様書無しさん:2015/01/26(月) 10:37:51.02
>>707喧嘩ふっかけなければよいだけ。
業務知識や運用知識が不要と個人的に思っても、社会人なら口が避けても対面で言わない。
謝罪してきて同じように叱責や怒声浴びせるようならパワハラだと思う。

709 :仕様書無しさん:2015/01/26(月) 10:45:14.63
要求定義書や仕様書って、未だに一度も貰うという経験がないわ
もちろん、過去や現在動いているシステムの同書類は当然もらったり引き継いだりするけど
これから作ろうとするもので、同書類を「貰う」なんて経験一切ない

710 :KAC:2015/01/26(月) 11:01:56.90
>>709
それはある意味特殊な環境にいるな。

ある程度の標準化が進んでいる業界や組織なら
仕様書ありきで受注するのはよくある話だぞ。
相手が大きい組織なら特に。

711 :仕様書無しさん:2015/01/26(月) 13:12:22.63
>>687
お前が運用知識や業務知識の意味を間違っているだけでワロタw

お前、馬鹿じゃん?

712 :仕様書無しさん:2015/01/26(月) 13:20:19.96
>>711
あってるよ>>687を合ってると見るか間違ってると見るか、そもそもシステム作成の仕様が決定しているとも断言していない状況まさに>>703が指摘する通り

713 :仕様書無しさん:2015/01/26(月) 13:22:56.61
上流工程からちゃんとやっている人なら
システム作成を依頼された⇒要求定義から
の思考になる
この発想に至らなかった人は自分がシステム開発の一部しか見ていない証拠

714 :仕様書無しさん:2015/01/26(月) 13:23:59.54
つーか、他人のシステム作るとか
つまらなくね? 負け組だと思うんだよね。
自社でウェブサービス作ってるとさ。

715 :仕様書無しさん:2015/01/26(月) 13:27:42.26
業務知識はいらない = 仕様書があればいい。

こういう意味なんだけどな。

必要なの知識じゃなくて資料。
こんなの記憶にたどることじゃねーよ・
覚えたってその会社でしか使えないだろ。

716 :仕様書無しさん:2015/01/26(月) 13:28:21.01
>>712-713
馬鹿だなぁ。
おまえ、707とか理解できないだろ?

717 :仕様書無しさん:2015/01/26(月) 13:28:22.45
運用も最近じゃ属人化をなくしましょうといって、
コードでインフラを作ったりするしな。

718 :仕様書無しさん:2015/01/26(月) 13:28:24.31
>>715
このスレは自社のシステム作成ですが?お忘れですか??

719 :仕様書無しさん:2015/01/26(月) 13:28:37.31
ウェブサービスてシステムのカバーする範囲が限定されてるから
やっててもあんま面白くないな、俺は

720 :仕様書無しさん:2015/01/26(月) 13:30:42.30
>>714
ここで仕様書を貰うものと思っている人の書き込み見てて、それ俺も思った。
仕様書まで貰って作る段階だと、問題や難題を解決した結果が出た!!!って感動がどっこにもないよな。
いったい何が楽しくて作ってるんだ?と思う。

721 :仕様書無しさん:2015/01/26(月) 13:33:39.66
>>716
馬鹿だろおまえw
正式にシステム作成の指示が出てるなら、どこのシステムかわかってんだから名刺とノート持って聞きに行けよ。
要求定義や各種仕様書の作成まで終わってないとなんにもできねーのかよ。考えて動けよ。

722 :仕様書無しさん:2015/01/26(月) 13:35:18.54
>>715が何を言いたいのか理解出来ん。

723 :仕様書無しさん:2015/01/26(月) 13:37:07.74
子会社孫会社ひ孫会社に派遣されている人と自社・元請・一次請企業の人との差がおもっくそ垣間見えるw

724 :仕様書無しさん:2015/01/26(月) 13:39:04.10
>>722
仕様書をユーザーがくれないっ!
仕様書を上司がくれないっ!
って駄々こねてますってことでしょw

いや、お前が作るんだよ!!!!と指摘されても気づかない
というか自分が仕様書を作るなんて想像もできないんだと思う奴隷派遣は

725 :仕様書無しさん:2015/01/26(月) 13:50:12.18
>>721
あほか。

726 :仕様書無しさん:2015/01/26(月) 14:23:55.24
>>725
あほか。とか言ってる間にさっさと客と仕様の打ち合わせしてこいやw

727 :仕様書無しさん:2015/01/26(月) 14:24:42.71
>>714
自分のためのシステムとかいくつか作ってるけど、一般人には使いにくくて仕方ないと思う。逆に仕事で作ったシステムは自分には使いづらい。

728 :仕様書無しさん:2015/01/26(月) 14:25:30.02
>>726
あほか。

729 :仕様書無しさん:2015/01/26(月) 14:40:27.74
>>724
なにがおかしいのか本当に理解できないのなw

730 :仕様書無しさん:2015/01/26(月) 14:52:23.51
>>715
つまりお前は業務知識を持ったエンジニアさんが仕様書を作ってくれなければ何もデキないクズってことを自己紹介してるの?w

731 :テスター:2015/01/26(月) 15:35:35.18
自分のところに来た仕事がどういうものかを精査しないと、後々トラブルになる
仕事の範囲、資料が足りているか、期間、予算など

それを真っ先に確認しないのは、
完全に一工程の作業員で、上司の言うことを聞いてればいいだけの人間か、
経験が足りなさ過ぎる

732 :仕様書無しさん:2015/01/26(月) 15:36:49.11
ココの連中は、要求定義書や仕様書等々すらまともに作ったことなかったのに社内SEの技術は…とか非難してたの!?
どっちが技術力ね〜ンダよ・・・呆れたわ

733 :仕様書無しさん:2015/01/26(月) 15:43:03.60
>>730
アホは黙ってた方がいいよw

734 :仕様書無しさん:2015/01/26(月) 16:13:17.03
仕様書すら作ってないのにプログラマって名乗っていいのか?
完全にコーダーレベルだろ

735 :仕様書無しさん:2015/01/26(月) 16:21:49.35
だから派遣語る資格がないってずーーーーーーーーーーーっといい続けてきたのに!
こういうことだよ!基本中の基本の工程すら経験がないんだから!!!こういう連中がまともなスレを破壊するんだから!
仕様書すら作ったことのないマなんて学生と変わらない

736 :仕様書無しさん:2015/01/26(月) 16:41:12.41
まぁ、こんな馬鹿は東北専門学校の無職winだけだから。

737 :仕様書無しさん:2015/01/26(月) 17:13:27.48
>>735
なに言ってんの?

738 :仕様書無しさん:2015/01/26(月) 18:02:10.14
やっぱり業務知識を勘違いしてるなぁ。
要求を聞いて仕様書を作りました。
でもそれ外部の人でもできることだよね?

社内SEってさ、自分が普段やってる仕事を効率化するの?
例えばコンビニなら社内SEが商品の発注とかしてるの?
それが業務知識でしょ。

739 :仕様書無しさん:2015/01/26(月) 18:11:33.92
勘違いねえ…君のカオスな頭の中は誰も理解出来ないと思うよ。

740 :仕様書無しさん:2015/01/26(月) 18:13:27.29
>739
てめえの頭がハッピーセットだよw

741 :KAC:2015/01/26(月) 18:15:11.85
自分で仕様書作れとか騒いでる奴がいるが、
基本的なことを全く理解できてないぞ。

 仕様をきいてまとめる窓口は必ず1つにしろ。

各担当者がバラバラに仕様を聞きに行くなんて論外。
相手にも迷惑だし、まともなものができなくなる。

少なくとも、>>687は「並行で別の人に同じものを作らせていた」
と書いてるんだから、仕様調整はすでに行っていたんだよな?
なのに、仕様を展開しないとか素人もいいところだろ。

他人に文句を言う前に、まともな仕事できるようになれよ。

742 :仕様書無しさん:2015/01/26(月) 18:15:53.20
>>740
そんなのはいいから、まず考えをまとめて理路整然と書いてみろよ。

743 :仕様書無しさん:2015/01/26(月) 18:31:02.09
>>741
> 仕様をきいてまとめる窓口は必ず1つにしろ。
基本が出来てないのはお前だわ。
仕様を聞くんじゃない、要望を聞いて仕様を作るんだよ。

744 :仕様書無しさん:2015/01/26(月) 18:33:47.39
プロジェクトリーダーがメンバーの誰かを嵌めることは簡単だから、
リーダーには歯向かうな

というパワハラ

745 :KAC:2015/01/26(月) 18:36:07.12
>>743
話すら理解できないのか・・・

「要望を聞いて仕様を作る窓口は1つにしろ」

これで理解できるか?

746 :仕様書無しさん:2015/01/26(月) 18:38:21.92
>>745
話が読めてないのはお前

今は窓口云々の話はしてない

747 :仕様書無しさん:2015/01/26(月) 18:39:06.36
>>743
アホすぎワロタwww
揚げ足採ってドヤ顔するとは流石です

748 :KAC:2015/01/26(月) 18:41:20.09
>>746
窓口のことに頭が回るなら、
「勝手に仕様を聞きに行け」という主張がおかしいことに気づくはずだが?

お前がずっと騒いでいる主張は根本的に間違ってるんだよ。

749 :仕様書無しさん:2015/01/26(月) 18:49:31.71
>>745
片方は失敗するのが目に見えてるし、窓口開く前に逃亡してるじゃんw

750 :仕様書無しさん:2015/01/26(月) 18:50:53.04
>>739
そんなのはいいから、まず考えをまとめて理路整然と書いてみろよ。

751 :仕様書無しさん:2015/01/26(月) 18:51:12.28
片方が聞きにいっても、相手側に電話一本入れておける立場なら問題ないだろ
「今から馬鹿がいくからw ちょっと迷惑かけるねw」で済ませられる人間関係築いてれば何の問題もない
でもその前に逃げた

752 :仕様書無しさん:2015/01/26(月) 18:51:44.34
>>749
話が理解できないなら参加しないほうがいいよ

753 :仕様書無しさん:2015/01/26(月) 18:52:11.12
勝手に仕様を聞きに行け



すいませーん。お仕事中すいませんーん。いまいいですかー?
私、社内SEやっているものですけどー。
あの、ちょっと話し聞いてくださいー。
仕様を聞きにしましたー。

754 :仕様書無しさん:2015/01/26(月) 18:52:35.86
>>751
後付の言い訳キタコレ

755 :仕様書無しさん:2015/01/26(月) 18:53:42.60
業務知識ないから仕様を聞きに行かないといけないんだろ。

業務知識があれば仕様を聞きに行く必要はない。
だから社内全体、システム化する所すべての業務を
経験してないといけないんだだ。

だからお前、今からレジ打ちやってこい

756 :仕様書無しさん:2015/01/26(月) 18:54:01.46
>>753
いい加減にしてくれ。昨日話したからそいつに聞け。

757 :仕様書無しさん:2015/01/26(月) 18:55:01.52
>>754
最初からかかれてるじゃんwww
逃げずに正式に命令が出てるならやればいいだろが
それで先方が怒ったら>>687が責任取る話
逃げの正当性にはならない

758 :仕様書無しさん:2015/01/26(月) 18:55:27.41
>>748
だからその話はまた別問題たし、そもそも「各々勝手に客に話を聞け」なんて事は誰も言ってない。
お前の話は、お前の勝手な解釈のせいで二重にズレてるんたよ。

759 :仕様書無しさん:2015/01/26(月) 18:55:34.20
>>755
業務知識があれば仕様を聞きに行く必要はない。

これについて詳しく

760 :仕様書無しさん:2015/01/26(月) 18:56:17.03
>>758
言ってるだろ。

じゃあ、どうすりゃいいって思ってんの?

761 :仕様書無しさん:2015/01/26(月) 18:56:54.62
>>757
自分が思ってただけだろwww

762 :仕様書無しさん:2015/01/26(月) 18:57:32.10
>>761
>退出して二度と戻ってこなかった

はい。在日朝鮮人には読めないですよね。

763 :仕様書無しさん:2015/01/26(月) 18:57:39.91
>>758
じゃあお前が仕様教えてやれよ。
アホなの?

764 :仕様書無しさん:2015/01/26(月) 18:58:15.33
>>759
社外の人がシステムを作る時、
業務知識はしらないのが普通。
それぞれの会社によって、業務知識は違うからね。
だから業務知識がある人に仕様を聞きに行く必要がある。

業務知識がある人であれば、仕様も知っているから
わざわざ聞きに行く必要はない。

765 :仕様書無しさん:2015/01/26(月) 18:58:40.66
>>762
は?
日本語読めない人きましたwwwwwwww
コピペミスですか?
ひどすぎwwwwwww

766 :仕様書無しさん:2015/01/26(月) 19:00:07.51
>>764
ちょっとそれは訂正入れたほうがいい文章だぞ
業務知識、運用知識まで持ってても、さらにユーザーが感じている問題がわかってないと要求定義はやらんと・・・。

767 :仕様書無しさん:2015/01/26(月) 19:00:57.86
>>766
要求定義と業務知識は別。

768 :仕様書無しさん:2015/01/26(月) 19:01:25.08
>>765
基点の>>687に書いてあるだろwwww
驚異的な馬鹿だな

769 :仕様書無しさん:2015/01/26(月) 19:03:13.95
>>768
せめて日本語は理解できるようになろうよ・・・

770 :仕様書無しさん:2015/01/26(月) 19:03:22.89
社内SEがレジ打ち(業務知識)を知らないのは当たり前で
業務知識は聞きに行けばいい。
マニュアル化されてるならそのマニュアルを見ても良い。

どちらにしろ聞きに行けばいいことなのだし、
聞きに行くべきことなのだから
業務知識は必要ない。

771 :仕様書無しさん:2015/01/26(月) 19:03:57.39
>>769
お前が馬鹿なんだよ。
逃げたこと について指摘してんだよ。
馬鹿なの?w

772 :仕様書無しさん:2015/01/26(月) 19:08:17.51
>>741
窓口の一本化は当然だが、そんなものは>>687の立場次第だから想像の域を出ない
ほかの者も言ってるけど、電話一本で終わらせられるかもしれない。そうじゃないかもしれない。

いずれにせよ、「仕様書は貰うもの」という考えのやつだらけなのがプログラマとしては大問題

773 :仕様書無しさん:2015/01/26(月) 19:11:52.12
>>722
要らないって言ってるのは業務知識だろ。
なんで仕様書の話にすり替えてるんだよ。

774 :仕様書無しさん:2015/01/26(月) 19:12:30.58
ぶっちゃけ、要らないのはSEかな?

プログラマが要求聞いて仕様書書けば
終わりだしね。

775 :テスター:2015/01/26(月) 19:12:36.66
>>687は意図的に嫌がらせしたわけだから、お互いがお互いを辞めさせるまで追い込むしかないわけだ

687はただの嫌がらせだが、嫌がらせを受けたほうが仕事ができる人間なら、
687とは別に、会社を代表して客なり何なりから仕様を聞き出すように動くべきだった

そうすれば、客は社内の統制が取れてないことに気付いて、クレームも来るし
仮に客側はもみ消したとしても、会社としては、無駄な人員を配置している687をどうにかしなければならない


ただ、嫌がらせを受けたほうはそれだけの知恵がなかったか、
こんな会社で働く必要を感じなくなったわけだ

776 :KAC:2015/01/26(月) 19:24:42.90
>>772
> いずれにせよ、「仕様書は貰うもの」という考えのやつだらけなのがプログラマとしては大問題

これ、このスレで何かと流行っているようだけど、意図がいまいち判らんのだが・・・?
例えば要求仕様書あたりはSEが書くもので、
プログラマとして「仕様書は貰うもの」と考えても不思議じゃない。
客の要望をきいて仕様に落としこむのをプログラマの仕事とするのは無理がある。

 「プログラマ」としては「仕様書はもらうもの、設計書は作るもの」

というのが一般的な解釈だと思うが、なにが問題だと思っているんだ?
SE的な意識を持てというのなら判らんではないけど、「大問題」って表現はどうかと。

777 :仕様書無しさん:2015/01/26(月) 19:25:49.20
>>776
だからSEはいらないって言っただろ。
役立たずなんだよ。あの手のクズは。
だから結局プログラマがやるの。
要求仕様のまとめから仕様書作成までね。

778 :仕様書無しさん:2015/01/26(月) 19:36:03.74
>>777
え?

779 :仕様書無しさん:2015/01/26(月) 19:45:19.42
>>776
じゃあ何か?仕様書もらってコードを書くだけの「プログラマ」がシステム成功のカギを握ってるのか?
このスレ何だか分かって言ってる?

780 :仕様書無しさん:2015/01/26(月) 19:47:59.02
>>779
え?

781 :仕様書無しさん:2015/01/26(月) 20:00:54.87
>>779
論点変えようとして必死だなwww

782 :仕様書無しさん:2015/01/26(月) 20:02:55.30
>>781
それはさすがに無理がある、もしくはナチュラルに馬鹿すぎるわ。

783 :仕様書無しさん:2015/01/26(月) 20:17:49.38
>>779
まあ握ってるだろうな。
仕様は素人でもわかることだしね。
(なぜなら素人が決めることだから)

784 :仕様書無しさん:2015/01/26(月) 20:22:06.72
どうやら>>779は設計をしたことが無いらしい

785 :仕様書無しさん:2015/01/26(月) 20:33:55.09
>>776
そういう分業的発想になっちゃうのは仕方ないけど
本当なら一人で全部出来たほうがいいよねえ
インフラも開発も運用も。

786 :仕様書無しさん:2015/01/26(月) 20:52:38.06
>>776
上流工程を経験していない。プログラミングしかしてない雑魚は語る資格なし。
そもそもやったこともないことを非難するなんてあほすぎ。

787 :仕様書無しさん:2015/01/26(月) 20:56:25.64
>>785
というより少なくとも経験は積むべき

788 :KAC:2015/01/26(月) 20:56:39.11
>>785
全部出来たほうがいいってのは同意するけど、
「仕様書は貰うもの」という本来の姿を否定する発言が気になった。

>>755でわかるように、仕様がどういうものか理解していない奴なので
いわゆる「俺様仕様」で突き進む、とんでも開発スタイルなんだろう。
自社システムしか作れない奴の発言だろうけど、一応意図を確認したがっただけ。

まあ、想定通りの回答しか返ってこなかった訳だけど。

789 :仕様書無しさん:2015/01/26(月) 21:01:17.05
下請け企業なら貰うしか手はないからね
でもこのスレはそもそも「内製」なんだよね
内製は全工程を場合によっては一人でやるのよね
プログラマだSEだとか言ってると最初は素人呼ばわりしていた人が全工程をこなしていく間にあっさり抜かれる
全部できるやつのほうがいいもの

790 :仕様書無しさん:2015/01/26(月) 21:02:17.79
電話も取らないやつらが仕様書とか要求定義とかできるわけがねぇw

791 :仕様書無しさん:2015/01/26(月) 21:06:43.00
自社システムたって
偽装請け負い不届け派遣だから
人足管理はエクセルで十分でしょ。

792 :仕様書無しさん:2015/01/26(月) 21:08:03.12
>>786
> 上流工程を経験していない。プログラミングしかしてない雑魚は語る資格なし。

逆逆。プログラミングが出来ない奴が、やらせるのが上流工程。

上流のミスは下流でカバーできるけど
下流のミスを上流でカバーすることは出来ないからな。

793 :仕様書無しさん:2015/01/26(月) 21:08:54.72
それで事足りるならそれでいいんじゃね?

794 :仕様書無しさん:2015/01/26(月) 21:12:51.97
>>792具体的にお願いします

795 :仕様書無しさん:2015/01/26(月) 21:16:36.03
>>792
プログラマ「(仕様を読んで)あのさぁ、ここの仕様矛盾してるよね?」

よくある話。

SE「プログラム読めません(T_T)」

よくある話

796 :795:2015/01/26(月) 21:17:15.60
>>792あてじゃなくて>>794あて

797 :仕様書無しさん:2015/01/26(月) 21:34:03.49
>>788
> 「仕様書は貰うもの」という本来の姿
何さらっと都合のいい事言ってんだよw
お前とことんズレてんな。

798 :KAC:2015/01/26(月) 21:35:58.32
>>797
プログラマーとSEの役割分担書いてみ?

799 :仕様書無しさん:2015/01/26(月) 21:37:07.64
>>798
そんなもんお前次第だし、そもそもスレ違いだっつーの。

800 :仕様書無しさん:2015/01/26(月) 21:41:43.73
PGとSEという役割分担は、SIの中で生まれたもので
本来は存在しない。
存在しないものを本来の姿と言ってしまうのは、業界に毒されてるねえ。

801 :KAC:2015/01/26(月) 21:42:58.22
>>799
わからないなら素直に言えばいいのに。

一度、まともなSE見てこい。
ちょっとでも理解できたら>>755みたいなとんでも発言しなくなるから。

802 :仕様書無しさん:2015/01/26(月) 21:48:59.50
>>801
そうだね、お前は大人しくまともなSE様の下で働いてろよ。
上流工程は、お前が口はさむとこじゃないですよ。

803 :仕様書無しさん:2015/01/26(月) 21:49:57.84
例えば小規模なECサイトを作って欲しいと頼まれた時に
プログラミングだけ出来ます、設計だけ出来ますっていう人間が役に立つと思う?
開発会社の中で分業に慣れてると、自分が半人前な事に気付かないんだよね。

804 :仕様書無しさん:2015/01/26(月) 21:54:00.64
人間分業して文明を築いてるんだぞ
石器時代に帰れ

805 :仕様書無しさん:2015/01/26(月) 21:54:53.31
>>803
分業に慣れているのではない
学歴、人望等々からその位置にしかいられないというだけ

806 :仕様書無しさん:2015/01/26(月) 21:56:08.25
>>804
お前歯車の一つでこれからの時代生きていけると思うの?

>>805
だから大手は駄目なんだ

807 :仕様書無しさん:2015/01/26(月) 21:58:55.88
>>806
そんなことやってるのは、大手になれなかったなんちゃって大手だけだから、気にしなくていい。

808 :仕様書無しさん:2015/01/26(月) 22:01:28.13
なんか50代スレで煽ってた奴と同じ匂いがするんだが

作ったアプリの紹介いつしてくれるの?

809 :仕様書無しさん:2015/01/26(月) 22:03:08.60
>>795
仕様のミスを指摘するのになんでプログラム?
仕様書でミスがわかるなら仕様書で示せばよくね?
即座に妄想だとわかる例ですねw

810 :仕様書無しさん:2015/01/26(月) 22:04:04.66
まあPGがSEのケツを拭いてやってるんだって言い草もおかしいんだけどね。
小さい箱の中でお互い罵り合ってる間に
箱自体潰れてしまったりしてね。

811 :仕様書無しさん:2015/01/26(月) 22:06:43.04
>>809
何を言ってるんだ?

仕様書は間違いがあっても、
プログラムのほうで正せば正しく動くんだよ。

プログラムは矛盾する仕様なら作れないわけで、
仕様を作っているプログラマは、仕様の精査を
していることにもなる。

だからプログラマは仕様が読めるし、理解できるし、
その問題を指摘できる。

だけどSEはプログラム読めないじゃないか

812 :仕様書無しさん:2015/01/26(月) 22:10:07.15
>>810
うむ、>>792
> 上流のミスは下流でカバーできるけど
> 下流のミスを上流でカバーすることは出来ないからな。
これとか

どうやったらここまで真逆の認識になるのか
煽りでわざと言ってるだけなら言いけど
本気だとしたら、もはや理解の範疇を越えている。

813 :KAC:2015/01/26(月) 22:13:12.09
>>802
なんか変な煽りばかりきてるから一応書いとくが、
普通にSE業務もやってるぞ?

だからこそお前みたいなSE未経験者が気になるわけで。

814 :仕様書無しさん:2015/01/26(月) 22:16:27.00
>>813
お前が変な煽りの張本人じゃねーかw

815 :KAC:2015/01/26(月) 22:18:58.96
>>814
変なところを指摘しているだけ。
ちゃんと理由も書いてるのに理解できない?

まあ、煽られてると思うのならその程度なんだろうね。

816 :仕様書無しさん:2015/01/26(月) 23:39:36.20
>>812
えとさぁ、煽りってお前のことだよ。
何も言い返してないじゃん。

まずさ、上流と下流って
上流のほうが偉いんじゃないんだよ?
それわかってる?

で、上流のミスを下流で食い止めることが出来るのは
当たり前の話じゃん。

下流でミスった時、そのあと上流が何かするのかよ?
よく考えて見ればわかるだろ。

817 :仕様書無しさん:2015/01/26(月) 23:46:13.61
モジュールの一部が停止しても、他のモジュールに影響しないよう設計するとか?

818 :仕様書無しさん:2015/01/26(月) 23:48:10.80
細かいところの辻褄合わせして、鬼の首取ったような気でいるのは
単に見えてないんじゃないかな。

819 :仕様書無しさん:2015/01/27(火) 00:14:31.12
>>816
お前がよく考えろ

820 :仕様書無しさん:2015/01/27(火) 07:43:33.32
てかさ、人様の仕事とやかく言う前に、せめて自分もやったことある状態にして欲しいと思う
やる前はあーすればいいこーすればいいだけ、とか言って実際やらせたらメチャクチャとか、某党じゃないんだから。

仕様書等々を作ったことないってことは客と話もしたことないんでしょ。
それでよく客はシステムを理解してないとか言うわ。まぁ実際理解してないけどwでも、想像を超えるレベルで理解してないことまで体験したから話してほしい。

821 :仕様書無しさん:2015/01/27(火) 14:39:37.26
なんで平日の昼間にこんなにスレ伸びるんだよ。
このスレの連中って学生かニートばかりなのか・・?

822 :仕様書無しさん:2015/01/27(火) 16:54:05.66
え?
お前しか書いてないぞ?

823 :仕様書無しさん:2015/01/27(火) 19:29:38.85
嘲笑したw

824 :仕様書無しさん:2015/01/27(火) 21:43:58.64
>>821
ほんコレ
未経験のくせになんの根拠があって自分の意見が正しいと思って発言してるのか
運動音痴を棚に上げて『脳筋』と言い、まともな学校も入れない頭のやつが『学歴なんて関係ない』とか言い、情試に落ちて『資格なんて役に立たない』とか言い、女とまともに話せないからって『2次元に限る』とか言ってる
すっぱい葡萄発言してる恥ずかしい奴らと同類

825 :仕様書無しさん:2015/01/27(火) 21:44:47.10
>>821が強烈過ぎてズレた>>820宛でした

826 :仕様書無しさん:2015/01/27(火) 22:37:30.24
学生かニートじゃあないと思うが、昼間っからこんなに書き込めるんだから
このスレの住民は余程暇な窓際族としか思えんな

話の中身は無限ループだし

827 :仕様書無しさん:2015/01/27(火) 22:44:41.24
窓際族って正社員なんだぜ派遣さん

828 :仕様書無しさん:2015/01/28(水) 00:24:51.92
学生、ニート発言でここまで食らいつくなんて図星突かれて余程悔しかったんだなw

829 :仕様書無しさん:2015/01/28(水) 00:29:10.63
平日の昼間に2chに入り浸れるなんて羨ましい限りだわ
うちの職場なんて2chへのアクセスが制限されている上、2chにアクセスしようとしたのがバレたら始末書ものという状況・・・

830 :仕様書無しさん:2015/01/28(水) 00:37:32.62
仕様書を作る段階での仕様バグや矛盾は少ない方が良いけれど
時間的制約で漏れる事もあるというのはある程度は許すしかないよね。
そこを完璧にする為に、それ以降の工程が遅れて間に合わないのも問題になるし。

でも、それでもプログラマ以下の思考力の人間に任せるのは間違い。
上流の間違いや取り決めを変えるのにはコストが大きい。
優秀なプログラマなんて殆ど居ない、使わない状況では余計に。

でも、問題の発覚が後工程なせいか、設計者にフードバックされ難いのか
駄目な設計者が色々な意味で逃げて責任転嫁が起こりやすい

831 :テスター:2015/01/28(水) 01:23:40.85
>>830
上流の仕事が雑なほど下流での工数が増えるのに、
上流は納期が来たら完成度が低くても次工程に流していいという風潮

832 :KAC:2015/01/28(水) 01:34:32.20
>>831
その手の風潮があるチームは不幸な結果が待ってるね。

とはいえ、>>830に書かれているのはそっちの話じゃなくて
「バグの発生を完全に無くすことは基本的に無理」という事実から、
工程移行判定の条件はある程度考慮しようって事かと。


個人的にはそんなことより>>811
| 仕様書は間違いがあっても、
| プログラムのほうで正せば正しく動くんだよ。
っていう考えの奴がいることのほうが怖い。

視野が狭い奴が勝手な仕様解釈すると酷い結果になるのに。
なんのための仕様書なのか理解できないんだろうか・・・

833 :仕様書無しさん:2015/01/28(水) 07:18:47.98
間違いをフィードバックしてきたマに八つ当たりしてるからそうなるんだ
自分を何様だと思ってる

834 :仕様書無しさん:2015/01/28(水) 08:18:02.81
>>833
変な言いがかり付けるから怒らせるんだよ

835 :仕様書無しさん:2015/01/28(水) 18:11:16.18
>>832
なんで、「勝手な仕様解釈」だと思ってんの?
仕様書が間違ってる場合の話だろ。

何のための仕様書ってその仕様書が
間違ってると判明した時の話なんだが。

836 :仕様書無しさん:2015/01/28(水) 18:40:22.55
>>835
え?

837 :仕様書無しさん:2015/01/28(水) 19:01:28.41
下流がミスるからバグとして表面に出る。
いい加減にしてほしいわぁ。
苦情こっちに来んのよね

838 :KAC:2015/01/28(水) 19:01:34.32
>>835
仕様書が間違っている場合は、
仕様書作ったところに修正させるのが正解。

もう一度書くけど>>811
「プログラムのほうで正せば正しく動く」という考えが問題。


・・・という当たり前の話すらもしかして通じない?
なぜかわからんかったら、どう判らんのか質問してくれ。

839 :仕様書無しさん:2015/01/28(水) 19:30:40.43
SEとプログラマーが分業制であるかぎり、この無益な争いはなくならない。

840 :仕様書無しさん:2015/01/28(水) 20:11:43.51
>>837
受け入れテストしないのか

841 :仕様書無しさん:2015/01/28(水) 20:13:46.07
>>839
そういうことも踏まえて>>1は最初から伝言ゲームで無理って言ってる
内製しか手はないんだよ

842 :仕様書無しさん:2015/01/28(水) 20:29:19.19
>>838
>仕様書が間違っている場合は、
>仕様書作ったところに修正させるのが正解。


実際の上流皇帝SE様のお答え>>834

843 :仕様書無しさん:2015/01/28(水) 20:35:20.84
>>838
な、どっちが間違っているかっていう観念論になるんだ
動きゃいいんだよ

844 :KAC:2015/01/28(水) 20:38:44.92
>>843
正しく動かないから問題になるわけで・・・

845 :仕様書無しさん:2015/01/28(水) 20:41:56.46
>>844
責任の所在を気にしてるだけだろ?

846 :仕様書無しさん:2015/01/28(水) 20:43:43.46
仕様書ガン無視したら
身が危なくなるのはプログラマーのほうだと思うけどなあ

847 :仕様書無しさん:2015/01/28(水) 20:47:06.08
ガン無視ワロタw

848 :仕様書無しさん:2015/01/28(水) 20:47:49.51
>>837
> 下流がミスるからバグとして表面に出る。

そうなんだよね。上流がミスっても、下流で直すから
バグとして表面化しない。

だからいつまでも質の悪くて量だけ多い
使いものにならない仕様書ばっかり出てくる。
それを平気で間違える。
バグのない仕様書書けや。

849 :仕様書無しさん:2015/01/28(水) 20:50:11.27
>>846
仕様書を無視するわけじゃん。
仕様書にバグが有るはなし、
その仕様書のバグを修正しないといけない。

だけど修正してといっても修正しない。
ひどい場合だと口頭で終わらせる。

この仕様書意味不明で可読性悪いですけどとか言っても
直そうとしないし、そもそもわかりやすい仕様書を書けない。

850 :仕様書無しさん:2015/01/28(水) 20:52:09.58
>>838
> もう一度書くけど>>811
> 「プログラムのほうで正せば正しく動く」という考えが問題。

その考えをしているのはSE(仕様書書いた方)なんだよ。
間違ってる? あ、ごめんね。
ここはこれが正解だから。とかいって
仕様書を直せないでプログラムを修正させる

851 :KAC:2015/01/28(水) 20:55:51.61
>>845
やっぱり理解できていないのか・・・

たとえば、ものすごく単純な例だけど
とある数値 a が間違っていたとしよう。

3箇所にaの記載があり、二箇所には aは2、のこりは aが4だったとする。
仕様書中の殆どはaが2の前提で計算されている。
この状況から、4は記載ミスだと判断して2で実装、試験を実施した。

こんな感じが、仕様書書いた人に確認しなかった場合。

これ、例えば仕様書完成間近に仕様変更(2→4)があって、
仕様の反映がミスっていた場合にありがちなバグ。
その場合4が正解なのに、読み手は2だと思い込む。
最終工程までバグが見つからないパターン。

ちょっとした値だけだからたいしたことが無いように見えるけど、
これが根幹の仕様の話になったら最後にどんでん返し食らうこともある。
もう少し頭使って影響範囲考えて予防策打てよってこと。

責任の所在なんて気にする馬鹿は放置してていいから、
どうやったら楽に品質上げられるのか考えたほうがいい。

852 :仕様書無しさん:2015/01/28(水) 21:02:30.54
業界人同士ですら意思疎通すらできないなら、内製・自製以外に一切手はないってことだね。

853 :仕様書無しさん:2015/01/28(水) 21:02:38.71
>>851
>>811は仕様の矛盾について語ってるけど、その例は矛盾じゃないじゃん。

854 :仕様書無しさん:2015/01/28(水) 21:10:34.83
時間がないときの仕様変更って、
いきなりコードのほうを変更させるんだよね。
時間がないからって。

仕様を変更するのなら、まず仕様書を修正してから
それをもって話に来いと。

855 :仕様書無しさん:2015/01/28(水) 21:12:41.58
仕様書ができる
→ 仕様書を元にプログラムを作成する
→ プログラム完成 → ユーザーに見せる → 意見が出てくる
★ → 仕様書を変更する
→ 仕様書を元にプログラムを変更する


この★の部分が重要なんだが、
これをやらない奴が多い。

そんなに仕様書を修正するのが面倒か?

856 :仕様書無しさん:2015/01/28(水) 21:14:19.97
> ★ → 仕様書を変更する

あと仕様書を変更するのはいいんだけど、
何がどう変わるのかを書かない奴が多い。

仕様書Ver1とVer1.1をプログラマが見比べて
差分を探すとか時間の無駄。

何をどう変えるのかもしっかり書いておくように

857 :仕様書無しさん:2015/01/28(水) 21:15:16.75
あと仕様書を変更したら、
その仕様でその他の部分に矛盾が生じないかを確認し、
その仕様で問題ないか、仕様のテストをしないといけない。

これもしない奴が多い。

858 :KAC:2015/01/28(水) 21:15:52.79
>>853
矛盾する仕様の例説明するのめんどうだから、
数値で表現した(同じはずの数値が場所によって違う)んだけど、、、
まさかそんなところから説明がいるとは。

とりあえず、>>811の具体的な仕様の矛盾とどう直したか書いてくれたら
どんなリスクが潜んでいたのかくらいは解説してあげるよ。

859 :仕様書無しさん:2015/01/28(水) 21:18:01.85
仕様書を書いたことがない人が仕様書について語ってないだろうな?

860 :仕様書無しさん:2015/01/28(水) 21:18:52.42
しかし何度も同じようなことやりとりして
結局は>>1が最初に結論を出していたとおりだったわけだ

861 :仕様書無しさん:2015/01/28(水) 21:26:26.75
>>1はユーザに間違いが無いというありえない仮定に基づいているからお話にならないよ

862 :仕様書無しさん:2015/01/28(水) 21:35:15.62
問題は完全に正しいユーザーが、完全に正しい開発者に直接伝えても
使えるシステムが出来上がらない事じゃないの?

863 :仕様書無しさん:2015/01/28(水) 21:42:16.99
それもありえない仮定だね

864 :仕様書無しさん:2015/01/28(水) 21:48:09.70
>>861
ユーザーが間違ってるとか、おまえユーザーに会える身分じゃないじゃん

865 :仕様書無しさん:2015/01/28(水) 21:50:08.69
>>863だから内製か自製になる

866 :仕様書無しさん:2015/01/28(水) 21:50:58.07
身分じゃないからなんだというんだ

867 :仕様書無しさん:2015/01/28(水) 21:51:38.04
もしくは数千回のトライアンドエラー
ただし納品から10年間は大規模修正から小規模修正まで深夜でも対応すること
お値段は今の一回ぽっきり納品の価格と同じ

868 :仕様書無しさん:2015/01/28(水) 21:52:51.85
>>863
そうなの?完全にユーザーの要望通りだけど使えないシステムって割とよくあるのかと思ってた。

869 :仕様書無しさん:2015/01/28(水) 21:54:01.93
>>866経験のない人は語るな

870 :仕様書無しさん:2015/01/28(水) 22:10:34.59
>>868
そりゃユーザは業務知識あっても、要件分析とか素人がほとんどだし。
プログラミングと違ってテストもないので、何となくで出来るから、特別な勉強をしないやつが適当にやって失敗する。失敗は後工程で発覚するのでタチが悪い。

871 :仕様書無しさん:2015/01/29(木) 00:49:48.29
おまえら(の大半)って
自分のせまーい経験にしがみつくしか能がないんだな

872 :仕様書無しさん:2015/01/29(木) 06:44:03.13
すべてが妄想よかなんぼかまし

873 :仕様書無しさん:2015/01/30(金) 06:51:21.21
プログラミングしかしてない人って日雇いとか偽装請負とか派遣の人でしょ?
本人がどんなに実力があると言っても、世間はプログラマはSEになる前の見習い扱い。
そうなると年齢で先細るのは確実。
それこそ、有名プログラマとか、著書があるとか、目に見えて誰でも確認できるものがないと、高齢者のプログラマなんてワザワザ使わないよね。
実力があると言うならとっくに引き抜かれてるわけで。

874 :仕様書無しさん:2015/01/30(金) 08:06:52.23
SEとプログラマの分担なんてプロジェクト毎に違うんだから、プログラマがプログラミングしかしてないとか短絡。
SEなんてのは日本だけって言うし。
画面イメージをエクセルの罫線で書いてるだけでSEと名載ってるやつもいるし。

875 :仕様書無しさん:2015/01/30(金) 09:45:47.37
SEなんて日本独自の職種で本来プログラマーはSEの能力も含まれるんだけど何故か日本だけ、

設計 SE
コーディング プログラマー

みたいに分業制になっているんだよな

876 :仕様書無しさん:2015/01/30(金) 09:51:55.20
バブル期以前、SEは上級プログラマーと呼ばれていたけど、
バブル期以降SEという職種がメジャーになっていつの間にかSEはプログラムを作成になくなった

877 :仕様書無しさん:2015/01/30(金) 10:30:53.04
今時の設計手法だと設計の時点でほぼプログラミング終わりだから、コーディングを専門にやる人なんていないでしょ。
そんなこと言うのはHTMLのマークアップをコーディングと言ってるような奴ら。

878 :仕様書無しさん:2015/01/30(金) 10:53:40.72
>>877
HTMLのマークアップはコーディングでも間違いじや無いが?

879 :仕様書無しさん:2015/01/30(金) 11:31:15.37
ダメだコリャ

880 :仕様書無しさん:2015/01/30(金) 11:36:12.13
はぁ? わからん奴もいるもんだね。

例えば小説家に例えるなら、小説を考える小説家がプログラマ
小説家が考えた文章をワープロで打ち込むのがコーダー

普通は小説家が自分でワープロを使って入力するものだって思うだろう?
でもね。昔は小説家は小説を考えて紙に書いて、それをワープロで打ち込む専門の人がいた。



かどうかはしらないが、昔はプログラマが考えて紙に書いたものを
コンピュータに入力する専門の人がいたんだよ。

小説家と同じで今はプログラマがコンピュータに打ち込むものだけどな。
プログラマ・・・職業
コーディング・・・作業

この違い

881 :仕様書無しさん:2015/01/30(金) 12:08:29.43
だったら
HTMLのマークアップはコーディングでも間違いじや無いが?

882 :仕様書無しさん:2015/01/30(金) 12:10:35.42
テキトーなあらすじから小説を起こす人はなんて呼ばれるの?

883 :仕様書無しさん:2015/01/30(金) 12:23:24.98
>>881
マークアップ = ウェブデザイン + α(コーディング )

884 :仕様書無しさん:2015/01/30(金) 12:45:42.37
>>880
>小説家が考えた文章をワープロで打ち込むのがコーダー

それはパンチャーだろ。

885 :仕様書無しさん:2015/01/30(金) 12:49:51.87
万能派←問題なし
設計も出来るプログラマ←置かれた環境によっては仕方ない
コードを書かないSE←お前なんで居るの?

886 :仕様書無しさん:2015/01/30(金) 13:44:31.50
こういう老害がいるとどこであろうと成功しない

887 :仕様書無しさん:2015/01/30(金) 20:39:11.59
>>885
書かないと書けないには恐ろしい差がある

888 :仕様書無しさん:2015/01/30(金) 20:52:45.49
まったくだな。コードを書けないSEのなんと多いこと。
例えるなら、日本語が読み書きできない奴が
日本で仕事しているようなものだ。

仕事をお願いできない。仕事をチェックすることも出来ない。
ただ単に進捗を管理するだけ。

889 :仕様書無しさん:2015/01/30(金) 21:27:25.39
>>888
管理が出来てるなら、それだけで凄い価値が有る。

890 :仕様書無しさん:2015/01/30(金) 21:39:31.52
進捗を管理しました!

納期を守るため、最初の要求を減らして
機能を落とし、コードレビューとテストを
省いて質を落としています。

でもなぜかお客様は満足してくれないのです。
納期を守ったのに変ですね!

自称価値のある管理者w

891 :KAC:2015/01/30(金) 21:55:52.96
>>890
それを「管理できていると」思っているのか?

お前さんが管理できないのは別にいいとして、
管理の評価すらできないのは致命的だぞ?

892 :仕様書無しさん:2015/01/30(金) 22:00:35.05
進捗は把握するものであって
管理はできねぇよ。

893 :仕様書無しさん:2015/01/30(金) 22:03:29.40
管理つーか コントロールするんだよ。放任してるように見せかけてな。

894 :仕様書無しさん:2015/01/30(金) 22:14:35.80
SHIROBAKOの制作進行がまさに進捗管理だね

895 :KAC:2015/01/30(金) 22:16:15.12
>>892
進捗は管理するもんだ。

「進捗管理」でググってみ?
色々な手法やツールが見つかるから。

896 :仕様書無しさん:2015/01/30(金) 22:16:46.36
【企業】社長から「君たちは要らない」と宣告されたIT部門の4年後 2015/01/22&copy;2ch.net
http://anago.2ch.net/test/read.cgi/bizplus/1421888211/l50

897 :仕様書無しさん:2015/01/30(金) 22:38:22.69
クラス図と補足図さえ書ければ、後は誰でも出来るから書かなくていいよ。

898 :仕様書無しさん:2015/01/30(金) 22:51:13.56
PMが書いていいのはユースケースと配置図まで。

899 :仕様書無しさん:2015/01/30(金) 22:54:29.18
>>898
それPMの仕事じゃないだろう。
>>897>>885の話だった。リロード忘れてて済まない。

900 :仕様書無しさん:2015/01/30(金) 23:05:05.91
>>891
作る側からしたら>>890は十分管理してくれているが?
時間や予算なんて無限じゃないんだから時間優先なら機能を削るしかない
わけだし、そういう対応をエンドユーザ側としてくれて実際に減らしてくれる
なんてかなり有能だぞ。 大抵のは仕様変更というか仕様追加を持って
くるからな。

901 :仕様書無しさん:2015/01/30(金) 23:20:33.46
実はさーカットオーバーの時期が前倒しになっちゃったんだよねー
うん、皆頑張ってくれてるからさー、俺も精一杯努力したけどダメだったんだ
でもさ、皆優秀なのは俺分かってるから!出来るよね!頼む!
皆で一丸となって俺達の本気見せてやろうぜ!な!な!

あと、体壊すといけないから、残業はほどほどにしとけよ…

902 :仕様書無しさん:2015/01/30(金) 23:22:10.81
普通、何もしなければ前倒しにはならんよな…?

903 :KAC:2015/01/30(金) 23:38:03.68
>>900
進捗管理に求められることはQCDなんだが・・・
Qが未達で客が不満を上げている時点でアウト。

「全く管理できていない」ってことを理解しよう。

904 :KAC:2015/01/30(金) 23:45:12.93
>>901
まあ、よくあるといえばよくある話。
基本的な対応はなにも変わらんよ。

「残業はほどほど」という指示があるんだから、
残業少な目な工数でスケジュール細かく引き直せ。
どの程度行けるのか目で見てわかればやる気も出るだろ。
どうしても作業時間足りないなら、それを報告すればいい。
その分、人員増やすなりして対応するだろう。

905 :仕様書無しさん:2015/01/30(金) 23:45:39.96
いるよね、少しでも自分の思い通りにならないと
「全くなんにもできてない」って言い張る奴

こういうのが上に立つと会社が崩壊する。

906 :仕様書無しさん:2015/01/30(金) 23:49:04.13
>>904
人月の神話とか読んだことないの? ギリギリで人増やすなんて最悪な
対応なんだけど。

907 :仕様書無しさん:2015/01/30(金) 23:51:53.85
見通しが立ってて、単に納期だけが変わったんならそうでもない

908 :KAC:2015/01/30(金) 23:55:32.56
>>906
おまえ、本の内容誤解してるぞ・・・
人員増加で対応できる場合もあるのは理解できないか?
つか、>>901が具体的な状況書いてないから一例上げただけ。
「人員増やす なり 」って書いてるだろ?

そんなどうでもいいところにしかツッコめないのか。
木を見て森を見ずって言葉知ってるか?

909 :仕様書無しさん:2015/01/30(金) 23:57:29.97
>>907
そうか?
規模にもよると思うけど10人のチームに2,3人増えただけでも確実に品質に影響出ると思うぞ。
んで、結果納期の短縮には繋がらない。

910 :KAC:2015/01/31(土) 00:08:09.70
>>909
それは場合によるだろ。
例えば試験工程ならテスター増やして対応とかよくある話。

911 :仕様書無しさん:2015/01/31(土) 00:19:06.24
>>903
進捗管理するだけでQCD向上とか奇跡の天才ですやんw

912 :KAC:2015/01/31(土) 00:38:41.19
>>911
本当になにも理解してないのな。
進捗管理は、QCD管理なだけだ。

なんで「QCD向上」とか思ったんだ?

913 :仕様書無しさん:2015/01/31(土) 00:47:30.19
はい「本当になにも理解してない」頂きましたー!

914 :仕様書無しさん:2015/01/31(土) 00:53:12.74
テストをテスト項目を埋めればいいって考えてるのが多すぎるからなあ、
テスターなんて増やしてもあまり有効じゃないのに。結局テストがNGなら
直して再テストになるだけなのに。 テストってのは項目を埋める工程じゃ
なくて、品質を作りこむ工程なんだってのを理解出来てないよな。

まあ、遅れたプロジェクトを元のスケジュールに戻すには結局のところ人を
増やすしか解決方法はないんだけどね。ただ学習コスト、コミュニケーション
コストを無視できるくらいの生産性の高い人を入れるしかないっていう。
windowsやms officeやらでマイクロソフトがとっているコスト度外視の方法
しかないわけなのです。普通の会社じゃ真似できない。

915 :仕様書無しさん:2015/01/31(土) 00:59:48.01
>>914
おまえ実務経験ないだろ…

ほんとに本の字面を鵜呑みにしてるだけなんだな
考え方が現実とリンクしてないというか

916 :KAC:2015/01/31(土) 01:02:05.07
テスター増やせないのは仕様書がろくに無いからだろ・・・
仕様書あれば試験くらいできる奴なんて社内にいるだろ。

・・・とここまで書いて思ったんだけど、
人員投入が無駄だって言ってる奴の会社って素人しかいないのか?
それならプロジェクトの増員として投入しないほうがマシかもしれん。

そんな時は、「プロジェクトメンバーの工数を減らす」って事だけに
主眼を置いて人員を投入しろ。
進捗報告が苦手な奴がいれば代わりに報告書書く奴いれたり
バグ管理作業をまとめてやらしたり。

917 :仕様書無しさん:2015/01/31(土) 01:23:45.38
>>916
>人員投入が無駄だって言ってる奴の会社って素人しかいないのか?

IT業界に限らず、追加要員のレベルは、それまでのメンバーの平均を下回るのがデフォ。
何故かと言うと、戦力の逐次投入が負けパターンだと知らない責任者が多いから。

あとソフト”製造”と呼んで、工業製品みたいに勘違いしてる人が多いが、
ソフト開発は、どちらかと絵画や小説制作に近い。
1枚のキャンバスに画家を追加したら、早く終わるどころかメチャクチャになる。

918 :仕様書無しさん:2015/01/31(土) 01:37:15.40
ねねね、結局これなに?

950 :名無しさん@恐縮です@転載禁止:2014/04/10(木) 23:03:15.53 ID:4WOZVd240
ねねね、会見してた加治佐俊一さんの、秘書と受付嬢のセクハラ解雇事件はどうなったんだっけ?

「 さ わ っ て も 減 る も ん じ ゃ な い か ら い い だ ろ 」

http://hayabusa3.2ch.net/test/read.cgi/mnewsplus/1397090689/950

919 :KAC:2015/01/31(土) 02:25:49.16
>>917
> IT業界に限らず、追加要員のレベルは、それまでのメンバーの平均を下回るのがデフォ。

まともな人員が確保できないのがデフォってのは不幸な職場だな。
あとは投入方法工夫して頑張ってくれ。。。


> あとソフト”製造”と呼んで、工業製品みたいに勘違いしてる人が多いが、
> ソフト開発は、どちらかと絵画や小説制作に近い。

このイメージが開発に影響出してないか?

(前にも書いたと思うけど、もっかい書いとく)
確かにプログラミングや設計作業は絵画や小説制作に近いと言えるだろう。
でも、会社で求められているのは「それをあえて」工業製品のように作成することだよ。
決まった手順があって、ある程度の人員を投入したら、期限までに製品が出来る。
そのためのプロジェクトなんだから。

絵画でも、工房で作成されるものには複数の人が携わるものもある。
漫画のように期限が決まってるものは完全分業制になってるところもある。

> 1枚のキャンバスに画家を追加したら、早く終わるどころかメチャクチャになる。

デザインなんかに悩んでいるのであれば、相談者として追加するのもありだし、
大きな絵なんかでは別の画家が一部を塗ることもある。
めちゃくちゃになるってのは、投入の仕方がおかしい時だけだろう。

920 :仕様書無しさん:2015/01/31(土) 03:15:21.33
テスターを増やすのは簡単
だけどテスト仕様書を作成するのは難しい
なぜなら本来仕様書を作成した人が作るものだから

921 :仕様書無しさん:2015/01/31(土) 03:16:02.18
>>919
>まともな人員が確保できないのがデフォってのは不幸な職場だな。

アホか。まともな人がプロジェクトにアサインされずに浮いているなんて稀だ。

人員を投入する時点で赤字か赤字確定になるのに売上を出せるまともな人を
投入するっていう決断を出来る人も稀です。 で、最終的には何人かの人が
壊れたりしますが上の方も顧客も、責任なにそれ?美味しいの?ってな具合で
何事もなかったかのように回ります。 何回か繰り返すと会社は潰れます。

922 :仕様書無しさん:2015/01/31(土) 03:17:45.15
テストをする
→バグが見つかる
→直してから最初から全部やり直し

この当たり前の事が出来てないところが多い

923 :仕様書無しさん:2015/01/31(土) 07:41:17.80
>>919
> 決まった手順があって、ある程度の人員を投入したら、期限までに製品が出来る。
お前はライン工だからそう思ってるのかもしれんが、ソフト開発の現場はまだまだその段階には到達出来ていない。
だからこそスレタイのような悩みが出てくるんだよ。

924 :仕様書無しさん:2015/01/31(土) 08:24:00.87
内職的なプロジェクトしかやったことないんじゃないか…?

925 :KAC:2015/01/31(土) 09:23:47.49
>>921
> アホか。まともな人がプロジェクトにアサインされずに浮いているなんて稀だ。

前提がおかしい。
まともじゃない人でもプロジェクトにアサインされずに浮いているなんてほとんど無いだろ。
どんな人材であれ、調整して投入するのが基本だろ。

926 :KAC:2015/01/31(土) 09:29:45.42
>>923
> ソフト開発の現場はまだまだその段階には到達出来ていない。

到達できていないと書いてるってことは、
理想がそうだってことは理解出来たんだな。

理想通りに仕事がすすまないなんてのは当たり前。
そのために、みんな改善を頑張ってるんだよ。
ISO 9001とかの内容理解してるか?

理想通りにならないからって全否定してたら伸びないぞって話だよ。

927 :仕様書無しさん:2015/01/31(土) 09:35:26.19
>>926
おまいのような単純な見方のせいでプログラミングは作業だと軽んじられる。

928 :仕様書無しさん:2015/01/31(土) 09:45:04.36
コンプライアンスやら品質管理やらはソフトを安定的に供給するのには良いんだろうけど
速く安く良い物を作るのにはあんまり貢献しないね

929 :仕様書無しさん:2015/01/31(土) 09:48:23.55
なぜならソフトは属人的なものなのに、属人性を廃そうとするから。
会社にとって属人性を廃するのは正しいが。

930 :仕様書無しさん:2015/01/31(土) 09:49:57.02
スケジュールの話ししてるけど

そもそも、
要望や仕様が伝わらない

931 :仕様書無しさん:2015/01/31(土) 09:52:34.12
管理云々以前に

すべての基軸となる部分が伝わらない

932 :仕様書無しさん:2015/01/31(土) 10:19:02.35
>>919
>でも、会社で求められているのは「それをあえて」工業製品のように作成することだよ。

求めるのは自由だが、方法論すら無い現状では無いものねだり。

933 :KAC:2015/01/31(土) 11:02:16.26
>>932
お前の職場はそうなのか?大変だな。
せめてISO9000認証取れるといいな。

934 :仕様書無しさん:2015/01/31(土) 11:13:50.52
>>933
ライン工はいい加減レスするのやめたら?

935 :KAC:2015/01/31(土) 11:15:30.88
>>934
ところで、お前の言う「ライン工」ってのはどういうものなんだ?

936 :仕様書無しさん:2015/01/31(土) 11:24:07.37
>>935
そもそもSIerが取るのはISO9000じゃなくてISO9001だぞ分かっているのか?
そういう大事な部分を間違えて訳知り顔でドヤって恥ずかしくないのかよ。

937 :KAC:2015/01/31(土) 11:35:14.39
>>936
おまえ、ISO 9000つったらISO 9001を含むシリーズを指すって事も知らんのか・・・
本当にISO9000すら取れてないんだな。

で、ライン工ってのはどういうもんなんだよ・・・ってのには反応できずか?

そらそうだよな。
「ライン工」ってのはソフトウェア作成において理想の形の1つなんだから。
本当にライン工みたいな生産管理ができるなら、それはものすごく高度な職場だよ。
その事自体がお前の言ってる主張を真っ向から否定することになるもんな。

938 :仕様書無しさん:2015/01/31(土) 12:00:39.27
プログラマなんて誰でもできるんだから月給5万でいいよ

939 :仕様書無しさん:2015/01/31(土) 12:11:02.43
>>937
いや文字通りの意味で、ソフトウェア開発をしたことのない工場勤務の
ライン工がここで頓珍漢なレスするなよって意味。

940 :仕様書無しさん:2015/01/31(土) 12:13:00.73
書ける奴が少なすぎる現実

941 :仕様書無しさん:2015/01/31(土) 12:15:31.32
誰でもできる、普通の学生生活すら送れず、ダメ集団だったやつだらけの業界
生活保護や受刑者の職業にすべき

942 :KAC:2015/01/31(土) 12:16:56.86
>>939
あぁ、そういうことか。
流石にそれはいくら何でも的はずれな煽りだろ・・・

つか、言ってることが自分の意見と違うと思ったのなら、内容指摘しろよ。
気が向いたらちゃんと説明してやるから。

943 :仕様書無しさん:2015/01/31(土) 12:31:50.02
テスター=ライン工だろうな。テスト仕様書に
書かれた内容を実行していくだけの簡単なお仕事

あ、もちろんテスト仕様書を書くのはテスターの仕事じゃないよ。
ライン工が自分で考えて無いのと一緒で臨機応変に考えるのは
テスターの仕事じゃない。テスター以外は自分で考える必要があるから
ライン工にはならない。

ライン工は自動化すれば必要なくなるのだが自動化するにも
高い技術力が必要なわけで自動化が出来ない所にテスターを使う。

テスターが多く必要なところほど、オートメーション化が進んでいない
旧世代の工場だってことだね。

944 :仕様書無しさん:2015/01/31(土) 12:35:22.66
ソフトウェア業界にとって
ライン工=自動化されたプログラムなので
ライン工は人間ではない。

ソフトウェア業界にとって同じことを何度も
繰り返す所は自動化して人間を必要なくすることが
理想の形の一つだって>>937は言ってるんだよ。

945 :仕様書無しさん:2015/01/31(土) 12:39:43.25
>>942
いや俺にはお前が頓珍漢にしか見えんぞ

946 :仕様書無しさん:2015/01/31(土) 12:47:57.51
>>945
     / ̄ ̄ ̄ ̄\
   ./ /フ        ヽ
   / o~  _    ___  |
   |   / ゚ ヽ  / ゚ ヽ |          ■ ■ ■ ■         ■
  ,--、  `ー〜'  `ー〜 /            ■ ■      ■ ■ ■ ■ ■
 ( 6   i―┬┬┬┬i 〈           ■ ■ ■■■       ■ ■
   ̄l  \_,二_二ノ ノ            ■  ■         ■ ■
    _\_  ̄ ̄ ̄_,/           ■     ■      ■  ■
  ./  \ ̄7ヾ~~7 \          ■       ■   ■   ■
  |  /⌒ヽVl_lV  /⌒ヽ
  |、 / ー'ー'  / |   | ー'ーf
  ヾニニニソ  .| |   |ニニソ

947 :仕様書無しさん:2015/01/31(土) 13:23:22.34
俺の幼馴染が内製をやって28歳で課長になった(ほかの課の課長平均年齢は52.8歳らしい)
そいつにプログラミングを教えたのは俺
だから俺のレベルを知ってるから俺を引き抜きたいと言ってきたが、さすがに嫌だw
年あたり2億くらいのコストがかかっていたシステムを現在は、年4000万まで落としたという評価からの大抜擢ということらしい
基本給も課長職と同等(今のほかの課長と同じ。ただし50歳くらいまでは周囲と比較して劣ることがない限り昇給はなしという条件)
28歳で年収1200万突破したと喜んでいた。ただ20年くらいは課長やるのかwwwとも言っていたが。

実力があるなら内製をやってないところに入って、
ただ働きでシステム作って一気に評価と待遇を勝ち取るのもひとつの手だと思ったわ

うん。残業代込みで年収600万の俺。悔しい(ToT)

948 :仕様書無しさん:2015/01/31(土) 13:55:16.96
このスレで技術力がある!って言って本当に自信と実力があるなら何故ユーザー側に行かないのか不思議だわ
やりたことやれるのに
新機能追加等々無しでも新技術へのシステムのリプレイスだって当たり前のようにやってしまえば普通にできる
慣例とは恐ろしいもので其れが当たり前の環境だとそういうことも簡単にやれる

949 :仕様書無しさん:2015/01/31(土) 13:56:27.02
どゆこと?

950 :仕様書無しさん:2015/01/31(土) 13:57:18.00
>>948
たぶんツテが無いんだろう

951 :仕様書無しさん:2015/01/31(土) 14:58:09.72
>>933
ISOで品質を担保するという勘違いしてるのがバレた瞬間であった。

952 :仕様書無しさん:2015/01/31(土) 15:02:01.66
>>950
>>949だってツテがあったわけではなく自分で切り開いている
グダグダこのスレでプログラミングスキルっ!!きりっ!!!!って言ってるよりイカに持っているプログラミング能力を現実に反映させられるかが勝負って証明でしょう

953 :仕様書無しさん:2015/01/31(土) 15:02:25.96
>>949じゃなく>>947だw

954 :KAC:2015/01/31(土) 15:20:57.65
>>951
どこをどう読んだらそんな解釈になったのか・・・
もう少し読解力つけないと色々大変だぞ。

955 :仕様書無しさん:2015/01/31(土) 15:26:35.48
プログラマが新しい言語や環境やアルゴリズムを学ぶのは当たり前
それをどうやって社会に反映させられるかが本当の技術力

956 :仕様書無しさん:2015/01/31(土) 17:20:24.50
>>955
> それをどうやって社会に反映させられるかが本当の技術力

それはSEの仕事だろ
プログラマーはコードが書くのが仕事だから社会に反映云々は必要のないスキル

957 :仕様書無しさん:2015/01/31(土) 17:20:40.23
>>948
>新機能追加等々無しでも新技術へのシステムのリプレイス
ここ重要
実は宣言して新システムを作ろうと企画すると「コストは?」「目に見えるメリットは?」etc..........
と口を出してくるやつが出てくる。
だから、新システムのたたき台も裏でこっそりはじめてしまうのが一番いいw

958 :仕様書無しさん:2015/01/31(土) 20:24:30.13
>>956
そうやって逃げるだけ
そしてあいつのプログラミング技術は低いと>>947を笑っていたら現実は1,2年でお前らなどあっさり抜いていく
なにせ全部自力で企業レベルのシステムを組んでれば嫌でも実力は実につくからな

959 :仕様書無しさん:2015/01/31(土) 20:28:55.61
>>958
企業レベルのシステムとか言ってるけど殆どはオモチャだぜ

960 :仕様書無しさん:2015/01/31(土) 20:42:09.37
>>958
まあPGがSEがって言ってる時点で負け組ってことだな

961 :仕様書無しさん:2015/01/31(土) 21:02:43.70
>>959
そうやって笑っていたら抜かれるって話がわからんか・・・というより認めたくないんだろう
責任を負ってシステムを作るというのは別次元だ
責任放棄した作りっぱなしのフリーウェアとは違う

962 :仕様書無しさん:2015/01/31(土) 21:41:39.94
学校で習うことなんて現場の一ヶ月とか言ったりするけど、
現場も狭いことしかやらない、やらせてもらえないのと、権限や責任をもらっていろいろやれるのでは、すごい差があるよね

963 :仕様書無しさん:2015/01/31(土) 21:48:06.15
>>961
じゃあ言い方を変えよう。
作ってる方は重責を負ってるつもりかもしれんが、それを使う方の現場では
「使いにくい」、「使われない」システムなんだぜ。

964 :仕様書無しさん:2015/01/31(土) 21:56:23.35
>>962
研修しても満足に書けない奴はプログラムを書く作業をさせてもらえないことも
あったりするから学校で出来るようになっておくのは無駄ではないけどね。

965 :仕様書無しさん:2015/01/31(土) 21:59:37.78
> 学校で習うことなんて現場の一ヶ月とか言ったりするけど、

それはそうなんだよね。
習うものが違うからね。

学校で、特定のベンダーの特定の技術なんて習わない。
でも仕事では、特定のベンダーの特定の技術を使う。

966 :仕様書無しさん:2015/02/01(日) 02:55:19.63
>>954
逃げパターンをもう少し増やしとかないと、色々大変だぞ。

967 :仕様書無しさん:2015/02/01(日) 03:18:24.84
こんなバカどもをユーザー側で受け入れるとか冗談いうな

968 :仕様書無しさん:2015/02/01(日) 08:01:05.95
大丈夫
こいつらの職歴では書類選考で落ちる

969 :仕様書無しさん:2015/02/01(日) 08:47:30.36
>>963
そう思いたいという願望だろうけど>>947のような状況だと
現場からの賞賛の声がないと絶対に課長職抜擢まで行くことはないぞ

このスレでの内製否定の人って
 作成者(ユーザー)はまともなシステムをつくれない
ということを絶対的条件にしてるよね
お前らが使いまくってるシステムやライブラリの多くはプログラマ製ではないよ
科学者だとか研究者だとかまったく別の職業名で呼ばれてる人たちの作品

970 :仕様書無しさん:2015/02/01(日) 09:16:23.11
>>969
お前なんか勘違いしてるな。>>963は内製を否定してるんじゃない。
内製だろうがシステム屋だろうが誰が作っっても結果は>>963だという事だ。

971 :仕様書無しさん:2015/02/01(日) 10:04:27.43
内製なら、「使いにくい」システムにはそうそうならないと思うがな。脆弱性があったり、全体として非効率(元々のその会社の仕事のやり方が非効率なため)とかはあっても

972 :仕様書無しさん:2015/02/01(日) 10:36:39.47
>>971
原因が伝言ゲームだけだったらきっとそうなんだろうけど
多分違うとこにも失敗の原因がある

973 :仕様書無しさん:2015/02/01(日) 11:08:58.16
内製の場合使いにくかったり現行より生産性が下がるようなシステムはそもそも受け入れられない
外注だと掛けたコストを正当化し関係者の体面を守るために如何なクソシステムでも無理やり展開せざるを得ない

974 :仕様書無しさん:2015/02/01(日) 11:09:10.92
>>972
使ってるユーザーそのものが作成してたら嫌でも本人や現場にとって使いやすいものになってるがな

外注の場合は基本的にその伝言ゲームでの失敗がとにかく大きなウェイトを占める
さらには、結局実装している連中が馬鹿だらけという現実

975 :仕様書無しさん:2015/02/01(日) 11:09:47.55
>>970
現場が作ってただろ
まえーーーーーーーに内製はじめたって報告してた人は

976 :仕様書無しさん:2015/02/01(日) 11:11:55.72
>>973
これ事実
で、不満たらたらになって、その部門で偉い人が鶴の一声で新システム導入の話になるんだけど
そのときには現場に知識がなくなっていて、要望すら伝えられない状態に・・・・
どんどんシステムは劣化していく

977 :仕様書無しさん:2015/02/01(日) 11:25:16.48
>>976
クソシステムに「業務を合わせた」結果(←これも現場を知らないアホがよく使う受け売りだが)、
あるべき業務の姿まで社内知識から失われてしまうんだよね

978 :仕様書無しさん:2015/02/01(日) 11:37:16.82
ポータビリティやスケーラビリティも使いやすさのうち。

979 :仕様書無しさん:2015/02/01(日) 11:51:06.31
関係者の思考が分断してるからな。

企業情シスは要件定義すら丸投げだし
経営陣は見栄えだけキラビヤカな提案書に騙されてハンコ押すだけだし
現場は自分たちのやりたいことすら良く分かってねーし
プログラマといえば技術だ資格だ企業レベルのクオリティだのと寝言言いながらクソコピペを繰り返すだけだし。

で、納品後は失敗した事実は隠蔽されて
ヘタすりゃ手書きでやった方が早いようなクソシステムと
無意味な作業で仕事した気になってるアホプログラマの無意味なプライドだけが残るわけだ
アホらし

980 :仕様書無しさん:2015/02/01(日) 11:59:56.96
ゲンバノヒトガーみたいなことをいう人はそれぞれの要求や不満が全て同じで
学習も慣れもしない人格であると思っているような書き込みだよね。
実際はあっちを立てればこっちが立たずみたいな矛盾した要求や不満は
よくあることだし、実際に高い金を払ってシステム化するのは特定の誰かの
ために作るわけではないから要求が聞き入れられないのは当たり前だし、
業務プロセスの改善、標準化、属人性の排除が目的に入っていたら必然
だったりするし。 乱暴な言い方だけど体に服を合わせるのではなく、服に
体を合わせるってのが属人化の排除だし。

981 :仕様書無しさん:2015/02/01(日) 12:02:45.97
>>977
>クソシステムに「業務を合わせた」結果(←これも現場を知らないアホがよく使う受け売りだが)、
>あるべき業務の姿まで社内知識から失われてしまうんだよね

知識がなくても使えるってのはある意味、良いシステムだよ。
知識が失われるのは、その知識が不要だったか、必要なら知識の保全を
考えなかった現場や会社が悪いってだけだから。

982 :仕様書無しさん:2015/02/01(日) 12:05:28.80
>>980
なにそれ?結局クソシステムでも我慢して使ってれば「住めば都」になるって事?

983 :仕様書無しさん:2015/02/01(日) 12:13:24.90
>>980-981
そんなことは分かった上で言ってるんだがね
現状は二律背反、全体最適にすら達してないシステムが大半だよ

984 :仕様書無しさん:2015/02/01(日) 12:18:14.37
現状、>>980-981のような論がシステム開発側の言い訳として罷り通りすぎている

985 :仕様書無しさん:2015/02/01(日) 12:22:27.84
>>983
だからこのスレタイにある自社で作らないと成功しないにつながるんだろ?
ただシステムは銀の弾丸じゃないから自社で作ったというだけではダメで、
使う人も作る人も改善坂を登り続ける必要があると。

986 :KAC:2015/02/01(日) 12:55:28.67
自社のシステムにこだわって作られたものは、
所詮自社システムの範疇における改善にとどまってしまう。

色々な会社にシステムを納めて、結果を見てきたところなら、
もっと広い視野で「業務改善」を含めた導入・運用が可能。

餅は餅屋なんだから、プロに任せるほうが良いものができる。


・・・ってのは普通に言われてることなんだけど、
内製のほうが良いってのはまともなSEを見たこと無いから?

987 :仕様書無しさん:2015/02/01(日) 12:58:48.51
>>986
本来そうあるべきだよな。プロなんだから。
現状がそうなってないからこんなスレが立つわけだ。
SEだけの問題ではないのだがね

988 :仕様書無しさん:2015/02/01(日) 13:01:11.00
伝言ゲームでは正しく情報は伝わらないんだから
様々な会社に導入したシステムも頓珍漢な代物だと考えられる

そんな間違った経験をもとに「業務改善」をされても
より酷い代物になるのは目に見えてる

989 :KAC:2015/02/01(日) 13:08:23.48
>>988
なぜか「伝言ゲーム」でSEに話を伝えることが前提なんだけど
SEなら最低でも「会話」くらいできるぞ?
まともなSEなら目に見える形で提案もするし、幅広い内容を調査もする。

SEに自社の情報を伝えられない というなら、
あまりにも自分たちが自社のことをわかっていないってこと。
そんな中で内製が成功する理由なんてどこにもないだろ・・・

990 :仕様書無しさん:2015/02/01(日) 13:17:26.69
IQが20離れると会話が成立しないと言うしね
SEってプログラミングも碌に出来ないアホばっかだから
会話しても通じてない可能性が高い

991 :仕様書無しさん:2015/02/01(日) 13:18:05.68
問題なく稼動していたシステムのリプレースですら失敗している現実事例が多々あるんだけどそれをどう説明する?

992 :仕様書無しさん:2015/02/01(日) 13:18:33.99
もう頓珍漢なSEにはお腹いっぱいです

993 :仕様書無しさん:2015/02/01(日) 13:20:37.64
リプレースの度に劣化する事って、本当よくあるな

994 :仕様書無しさん:2015/02/01(日) 13:20:41.69
>>991
自社でやって失敗しまくってる事例のほうが多いという現実

995 :仕様書無しさん:2015/02/01(日) 13:22:13.41
なんかウンコの投げあいだなこのスレ
幼稚園児が罵り合ってるみたい

996 :KAC:2015/02/01(日) 14:06:19.73
>>991
失敗の主たる原因が「外部の会社に任せたから」って事例があるって事?
内製にしていれば成功していたことが明白な事例って事でもいい。

あるなら参考までに紹介してもらえるとありがたい。
というか、そういう事例を出して話したほうがスレとしても盛り上がるだろう。

997 :仕様書無しさん:2015/02/01(日) 15:27:31.11
>>996
まさに>>1
と同じ結論に至って自社開発と開発のスタイルそのものを変えたとこなら。ハンズが有名。伝言ゲームの困難性と、業務知識の伝授の困難性から>>1と同じ結論に至ったもよう

998 :仕様書無しさん:2015/02/01(日) 15:33:23.85
内製回帰という言葉がでてきてるのも。
内製から外注を経て内製をとったところでないと使われない言葉

真剣にシステム開発を考えると、この結論に至る

999 :仕様書無しさん:2015/02/01(日) 15:34:08.46
テストがない仕様は、仕様ではない。

これで済むw

1000 :仕様書無しさん:2015/02/01(日) 15:38:05.30
底辺派遣プログラマだらけだから次無しで

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)