設計は評価されない

雑な設計でも誰よりも早く動くものを作ること。

作った奴も評価されない。
評価されるのは営業だけだ。

そして儲かるのは経営者だけ

>>1
>雑な設計でも誰よりも早く動くものを作ること。
設計が雑だと、テストでぼろが出る訳だが。

Java厨は設計する能力がないので
アジャイルとか騒ぐしな

要件のポリモフィズム

雑な設計
糞なJavaドカタ
すなわち暗黒の無制限デスマッチ

テストでぼろが出るが
そのテスト項目も穴だらけなJava厨

評価できる設計を使えばよか。EffelのDbcみたいなもんとか。

java.io.*より美しくないと認めません。

もうちょっとこう、建設的に議論できないかなー。

作った奴も評価されない。
評価されるのは営業だけだ。

つーか、おまいらが役立たずで評価されてないだけだ
まずは己を知れそして人を妬むな

では評価されるような設計とは

＞作った奴も評価されない。
評価されるのは営業だけだ。

じゃ、不良品作ったら営業が怒られるって訳か？

設計が評価されないのではなく
評価される設計をしていないのが現状。

単なる機能のメモ書きを設計書というな。
ユーザの機嫌で変化する画面を勝手にお絵かきするな。
オブジェクト指向開発と言うのなら、まずはオブジェクトを導出しろ。

と思うけどね。

別にモジュールでいいじゃん

おっさん、そのモジュールで業務プロセスをどのように実現するのか示すドキュメントがないんだよ。
いわば、そのモジュールは単にユーティリティクラスの元を出しただけなの。
仕事が足りないよ。

オブジェクトを導出するのは詳細設計あたりじゃないの？
ここでいう設計はもっと上流の設計じゃね？

詳細設計からだと手遅れだね。デスマ確定。
１９は上流の方だと思われるが、プロジェクトうまく行ってるのかな？
うまく行ってるとしたら、コボルやＣ風のプログラム構成をしていると思われる。
もっともＪａｖａ厨の顔したﾈ申でもいたら別だろうけど。
要件定義、業務分析するからオブジェクトが出てくるんだと思うのだが、
これを詳細設計のフェーズで尚且つ新規参入組みだとお手上げ。
でも、このパターンの案件が多いのは事実。漏れは迷わすパス。

>要件定義、業務分析するからオブジェクトが出てくるんだと思うのだが、

業務分析でオブジェクトが出てこないことは無いと思う。
（それを「オブジェクト」と認識しているかどうかはおいといて）

で、出てきたオブジェクトを「クラス」として設計するのはどのタイミング？

>コボルやＣ風のプログラム構成

基本設計がプログラム構成を決定するのか？

ＰＧとして派遣されたんだけど、クラス図ってないものなのか？
システム要件やら、システム要件、独自フレームワークをすべて理解して、
クラス設計を考えないとプログラミングを始められないんだが、
そのスケジュールは無理っぽいぞ>>ﾊｹﾞﾘｰﾀﾞ

>>16
評価される設計図というのは姉歯一級建築士の設計図のような物の事かと

姉は
設計図じゃないけどな

>23
クラス設計はプログラマの仕事だと思うけどな、、

>>23
おまいの能力みてｺｰﾀﾞとして使うことにしたんだろ
がんばれ

単価下げるためにむちゃくちゃ言われてるんだと思うがなあ

>23,27
クラス図というか、何のクラスを使うか、作るか
ってのはプログラマが決めること？SEが決めること？

ＳＥを募集して、使えそうだったらＰＧ単価に値切る、これ王道な。
外注にＳＥクラスの単価を払うのは不経済。
一応２３０Ｈ以上は時間清算するから、金が欲しけりゃ働けばいいんじゃ。

>>29
仮にＰＧだとすると、ＳＥは何をする。
小学生クラスの作文とお絵かきか？

小学生レベルかどうかは置いといてSEは分析〜設計だろ。
その成果を作文とお絵かきに落とすだけで本来それは目的じゃない。

>>32
多人数で作る時に「こうしてほしい」っていうことだけ書いてあって
それを元にそれぞれが勝手にクラス設計したら
まとまらないんじゃねの？
せめて基本クラスとモジュールくらい作ってくれてないと
デバッグのとき大変そうだと思うけど。

ＳＥって楽そうだな。　
結局具体化したときの問題や矛盾に責任もたないんだろ？

「25のセオリーで学ぶシステム設計の必修スキル―基盤システム、性能・品質、運用から業務プロセスまで」
て本はどうよ？

>せめて基本クラスとモジュールくらい作ってくれてないと
>デバッグのとき大変そうだと思うけど。

そりゃそうだけど、それはSEの仕事じゃなく、
共通クラスや共通部品はそれ用のチームなり担当を用意した方がいい。

>34
「責任を持たない」 とは？

>35
日経コンピュータに連載されてたやつでしょ
SEと言うか、PMを目指す人はこの手のを読んでてもいいんじゃねーの

よくできたと評価されるオブジェクト指向の設計は、実装には落としにくい。

例えば？

例えばWebServiceを使う前提の場合、あまりに部品化されると性能要件が満たせないものができあがる。

部品化厨って、まじウザい、、

部品化厨の作る部品って
部品ごとに使い方の「コツ」が必要だったりするんだよね。

DBだとER図があるんだけどな
そして、あまり完全に正規化すると性能が出なかったりする

SQLが長くなる。

>>そりゃそうだけど、それはSEの仕事じゃなく、
>>共通クラスや共通部品はそれ用のチームなり担当を用意した方がいい。

業務プロセスに依存しない共通クラスや共通部品は別に担当を割り当ててもいいかも
しれないが、業務プロセスに依存したもは業務分析、システム要件を考えたＳＥと
呼ばれる奴がしないとダメだよな。

でもたいてい、ＳＥは自分が夢想する業務プロセスの共通部分を作れと言うんだ。
だったら、その共通部分の仕様を出せと言うとまるで自分の仕事でないかの様。
こんなタコＳＥはどうやったら育つんだ？

>業務プロセスに依存したもは業務分析、システム要件を考えたＳＥと
>呼ばれる奴がしないとダメだよな。

業務プロセスに依存しない部分ってUIぐらいしかないのでは？

>業務プロセスの共通部分

業務プロセスは十分抽象化しないと共通化してもすぐにダメになる。
共通化しない方がいいことも多い。

>>48が書いていることが妥当なら、業務システムでJava使ってオブジェクト指向設計するという行為自体が矛盾を生む気がするのだが。

「十分抽象化しないと」という日本語が読めない奴は
どんな設計書を書いたとしてもダメだろうな。

ああ、俺には「十分に抽象化する」作業の具体的なイメージがつかめないわ。
誰か説明できる？

人にものをたずねるときは敬語使おう

抽象化はより汎用的ということ
インターフェイスクラスならメソッドや変数を選ぶ必要ありということ

基本でしょ

すみません。全然わかりやすくありません。

抽象化が分からんでOOPとか。。。

>>49
「答えがでたな、冬月」

問題集を配るのがSE、その問題を解くのがPG

採点するのは誰だ？

業務プロセスはUIも巻き込む場合もあるだろ

見積もりから受注状態に変わったらこのチェックボックスはfalseにして使えないようにする、
ただし納品後に差し戻しされたら再びtrueにするとか

ユーザーの出した概要が間違ってなければいいんだがな。

おっさんの頭の中にはＵＩとＤＢしかない。
業務プロセスという概念はない。
なのでＵＩのイベントごとにクラスまたはメソッドを作っていけばおっさんも満足。

みんな、いいかな。クラス設計なんて不要なんだよ。

おまえの言うおっさんがユーザのことを指しているなら
それは大正解だ

>>58は駄目な考えの典型。

>>62は学生の典型。

>>61
おっさんの正体は、汎用機系システムをＷｅｂ系へのリプレース開発プロジェクトに
居る主にＣＯＢＯＬを使ってきた面々だよ。
ＵＩ（画面のお絵かき）、ＤＢテーブル設計なるものを示し、
「さて、格安ＰＧども、Ｊａｖａとやらでオブジェクト指向やってみれや」だ。
予算はそのおっさん連中に３分２は取られている。

これは訓練じゃないぞ、れっきとした現実だ。すでに火は噴いている。

＞ＵＩ（画面のお絵かき）、ＤＢテーブル設計なるものを示し、

それ以外に何がほしいの？

OOL使うならクラス設計とか

システムにやらせたいことが何か
画面の紙芝居とDBを結びつける何か

PowerPointでのぽんち絵プレゼンがほしいって贅沢いってるだけなんだな？

>>64

おっさの相手はした事があるが、疲れるな。
設計よりも実装に時間かけたがる。
というか、ソフトウェアの開発作業時間＝実装時間だと思っている。

設計する時間与えなかったら、どんなに優秀な奴だって破綻に向かって突進。
見切り発車しておいて何故上手くいかないのかと吼えてた。

　お　ま　え　の　責　任　だ　。

クラス設計はSEの仕事？PGの仕事？
俺はPGだと思ってたけど

俺はSEだと思ってた。
大枠のクラス設計はアーキテクチャの息がかかるからクラス設計渡した方が早くないか？
でなければ、アーキテクチャの説明をマンツーマンで教えないといけなくなる。

PGグループ内に一番出来るPGってのがいるよな、
そいつ。
＃こういう奴って大体マニアックなクラス設計するけど。

でも、要件定義、概要設計、システム設計、
アーキテクト、クラス設計、詳細設計をSEが完璧にこなしたら


PGってほとんど頭つかわないよな。

ＳＥが作るクラス図
ＰＧが作るクラス図

がある。

>>74
ごめん、よくわからない。
基本クラスとクラス図をSEがキチンと作っていれば
PGは足りないクラスを付け足して、元からあるクラスは継承して実装すれば
システムできちゃうんじゃないの？

どうしてソフトウェア開発ってこんなにふわふわして浮ついているんだろう
なんでカチッとしたものが作れないんだろう

気づかないだけでほかのものつくり業界もそうなのかな

姉歯みたいに

なんでカチッとしたものが作れると思ってるんだ？

作りたいから

>76
ソフトウェア開発が浮ついているのではなく
要求が浮ついているんです。

>>79
正解

魔法だと思われてるからだな
カタチがないから特に

要求をカチっと固められればおｋ−




それが困難なんだが。

>>79
なるほど

要求も意識して開発するってのが正解か

例えば製造業などは要求が目に見える形になるから
要求を固めやすい。でもソフトウェアは >81 が言うように
見えないし、後からの変更も自由（御幣はあるが）だから
どうしてもカチっとならない。。。

>>84
変更する事に金が掛かるって意識が無いからな
結局最終的に出力されたステップ数を基準に物事考えてるからだろうな

変更に強い設計ってのはある。しかしやりすぎると無駄に複雑になる。
優秀な設計者は業務にも詳しいし、変更も拡張もある程度予測して作るから変更も楽なんだよ。
実際、AとBを接続するシステムで、Aに変更を頼んだら2週間かかると言われて、
しかたないからBでどうにかならないかと聞いたら3時間でテストまで完了させてたな。
その変更だけじゃなくてBの方は驚くほど早く修正してた。

だからみんなBに修正させてたってのは可哀想だったがな。

傍目から見るとAの方が優秀に見えてしまうのが、とんでもなくかわいそう

文系出身者と理系出身者の生涯所得の差は、最大で一戸建て１軒分に相当する５００
０万円になりうることが、松繁寿和・大阪大大学院国際公共政策研究科助教授（労働
経済学）らの約１万５０００人の大学卒業生を対象にした調査で分かった。

最大の話ならどうでもいいな

>>89は理系

「あんたらは何もわかっていない」
ttp://osaka.yomiuri.co.jp/tokusyu/dassen/jd50720a.htm

いや、評価できる設計をできるやつがいないだけ。

評価できる設計ってどんなんだろう

問題を解決すると評価されるんだろうが、
設計がうまくいくと問題が起こらない。

>>94
設計が上手くいっても問題が起きないとは言えないが、設計が上手く行かないと問題が起きる

インスパイアと言えば、日立のプラズマのCM
パナとどっちがインスパイア？
w

終盤にアクロバティックなプログラミングを組まなくてすむのが良い設計。
大きな問題が起こらないのが普通の設計。
どーみても設計書通りに作っても完成しないのが悪い設計。

ちなみに、世間一般は悪い設計書を臨機応変に解釈して完成する
ケースが多いと思う。

鼻持ちならない傍若無人な顧客のエゴで、まともな設計が
歪められていく。

上役のカスみたいなプライドのせいで、正論がスルーされる。

論理ではなく感情論によって、今日もどこかでデスマが続く。

なぜ君はいつも被害を被る方にいるんだい？

仕様書書き、ﾂﾏﾝﾈ

>>97
>ちなみに、世間一般は悪い設計書を臨機応変に解釈して完成する 
>ケースが多いと思う。 

一度、それの面白さを知ってしまったら
病み付きになるもんだがな。

基本設計ってしてもしなくてもいい仕事だからおいしい。
詳細設計というとおまえはＰＧレベルと見下されたうえに実装までの責任を課せられる。

でも、基本設計からの案件って派遣だとなかなかないね。

>基本設計ってしてもしなくてもいい仕事だからおいしい。

分析からいきなり詳細設計ってこと？

客にレビューしてもらえない設計書は
ただの自己満足なんだよね

客＝能力が上　とか勘違いしている馬鹿が言いそうな事だ

門外漢のくせに、なんでも自分達の方が正しい結論を出せると
信じられる脳ミソがうらやましい。

勘違いしてんのあんただけ

お猿さんにも理解出来るような設計書かかないとあかんな、おまいら。

マンガで読む○○システムとか描けってか？

>>11
Javaアーキテクトに恨みをもつC言語厨が
この板では「設計アレルギー患者」として暴れているから無理

>>109
俺のことか？ノ

妄想と幻覚のJAVASOFTの１０年とでもいう本書いてみてくれよ>>109

>>20
COBOLやC風にやればうまくいく？
Javaアーキテクトの顔をした神だとうまくいかない？
根拠は？
















そうか
お前がJava嫌いなだけだということはよくわかった。

JavaﾗｰでUMLやらﾕｰｽｹｰｽを活用して作られたｼｽﾃﾑ見ると
よくやってるなーと思う

でもこのｼｽﾃﾑに対して
こういうふうに変更して、と伝えると、いやな顔をして絶対にうんと言わない

なぜならそれがｼｽﾃﾑの当初のﾓﾃﾞﾘﾝｸﾞを超えていて変更不可能であり
可能にするには全部作り替えなきゃならないから

>>83
その要求がコロコロ変わるからな

>>113
度を超えた仕様変更要求ならどの場合にしても変更不可
あるいは作りなおしだが、そうじゃなければその人は反アジャイルというだけ。

>>113
>こういうふうに変更して、と伝えると、いやな顔をして絶対にうんと言わない
なかなか核心をついた考えだ。

変更しないの？うち、普通にしてるよ。
納期とかお金の問題っていうのはあるけど、お客に納品しても業務に使えない
もんだったらしょうがないじゃん。お客と自分の会社と話して解決する。

そんなのどんな言語で書いたってあたりまえ。

>>117
普通はしないよな。

それこそ、納期とお金次第。

だって、そうだろ？
例え使えないシステムだとしても、それを了承したのは客だよな？
少なくても、概要設計だ、基本設計だ、詳細設計だと書いて説明して、
客もOKだと思ったから検閲したという印鑑を押すんだよな。

でもって、俺らはそのOKを貰ったからそれにしたがって開発するんだよな。

俺らは、客が黒いものも白くしろって言われたらするだけ（勿論、それでいいのかは確認するが）であって、
その結果、業務に使えなかったとしても、俺らに非がある訳じゃない。

117の考えって典型的な日本企業って感じがする（実際どうか知らないけど

なし崩し的に開発側のコストが増えていくし、
一旦納品後にやっぱりこうしてっていうのを受け入れいていると、
要件定義をきちんとやらなくても大丈夫なんだと客が思ってしまい
次回から要件仕様がいい加減になる

考え方としてサービスを提供するんじゃないの？
使えないものを納品して、作り逃げするつもり？

システムってハッピーになるものを提供しないと意味ないじゃん。

ok出したのは客っていうのはその通り。
だから、相談して予算と納期と、業務へのインパクトを見てやる・やらない
の判断を決めるのではない？

やりたいかやりたくないかっていうと、そりゃ手間のかかることなんて
やりたくはないさ。

>>120
誰もそんなことを言ってない。

結果的に、システムが使い物にならなかった場合、誰に責任があるかといえば、
基本的に客とシステム会社側で半々だよな。

だから、納期と金次第。
作り逃げというが、客がOK出した以上、その使えないシステムが客の望んだシステムなんだよ。
だから、作り逃げにはならないし、俺達は客の要求を１００％満たしたって事。

だから、金と納期次第。
金と納期を出すと言われれば、面倒だろうが何だろうがやるけどな。

客がそれでいいっていうなら、仕様変更じゃないと思うけど。

はたでみて使えなくても使っているなら使えるモノじゃないの？

>>121
別にそういう風に「だって、
あいつらがヘマしてOK を出したんだろ？
俺達に銭が落ちてくれば、
客がどうなろうが知ったこっちゃないぜ。
ケケケ・・・」って態度で
>>121 が仕事をするのは勝手だけどさ。

５年先・１０年先を見据えた場合に、
そういう態度で客に望むのが、
会社の戦略として本当に良いのか？
ってのを「まともな会社」ならば考えるわけ。

「まともな会社」かつ
「まともな立場に立たされている
役職の人間」ならば、な。

ちなみに、>>121 のような奴に仕事を発注する場合に
顧客側の人間（発注者も、だが）が考えなくちゃいけない
項目として "TCO" ってのがある訳。

お前、また秋も "基本情報処理" 受けるんだろ？
試験に出るから覚えとけよ。

>>121みたいなやつは死ぬしかないよ

>>123
＞５年先・１０年先を見据えた場合に、
＞そういう態度で客に望むのが、
＞会社の戦略として本当に良いのか？
＞ってのを「まともな会社」ならば考えるわけ。

その考えってあぶないだろ

客が安くしようとして機能不足の要件定義で作らせて
やっぱり使えないから直してくれと言ってきたらどうするの

契約があるのにそれに関係なく追加開発したらだめだろ

契約があってそれに従ってお互いが同意した上でシステムを作り、
結果として客が望むものにならなかったらもう１度契約して作るだけじゃん

へへ、中国人、使用変更見止めないあるよ。

>>126
危ないも何も無い。これが「ゲンジツ」。
これがイヤならば、この仕事を止めろって事。

何故、IT 業界が多重派遣構造になっているか
分かっているのか？

大きな企業ならば「作り逃げ」しない（出来ない）から。

その結果、必然的に大企業に受注が集中し、
それをこなせなくなった大企業が
下請けを使わざるを得なくなった、
という理屈。

なんかビジネスの話が混じってきているな。

俺らはビジネスにコミットするのかエンジニアリングにコミットするのか苦渋の選択を強いられるときがある。両方はとれない場合が往々にしてある。

その時、どっちをとるのかが各人で違っているので意見が合わない。
これは正解なんて無いけどな。

「ゲンジツ」として受け止めている128はもうあきらめの境地にいるって意味？

この業界バカだな

>>128 それは結果であって理由じゃない。

多重派遣構造は上の管理者、天下りたい奴の思惑に人売りが乗っかって出来ただけのものだ。
どうしようもなく特殊で難易度が高ければ、できるところに発注されてるよ。

作り逃げする大企業は存在しますが何か？
曰く「その開発チームは解散してしまって・・・」
　　「別の製品にリプレースされて・・・」

そんなもんですがな。

「相手が了承したんだから」とか言っているけどさ、
お前、保険の契約する時、その契約書を熟読するか？

いかにも読みにくそうな半透明の紙に、
読みにくい薄いインクを使って、
難解な文章を書き込んでいるだろ？

顧客にとってみれば、SE とやらが出してくる
要件定義なんてものは、あんなものと大して
変わらないんだよ。
「UML? ﾊｧ? 何それ？」って感じでさ。

>客が安くしようとして機能不足の要件定義で作らせて 
>やっぱり使えないから直してくれと言ってきたらどうするの 

将来もその顧客と長く付き合っていくつもりがあるならば、
その機能不足の要件定義を作った奴のミスとなる。

そういう奴は、最初は「切れ者」扱いされているが、
長い目で見ていると、そいつの評価が段々落ちてくるのが
分かるようになる。
「確かにあいつは優秀かもしれないが、"運" がないからな。
あいつが扱う案件は、後で必ず火を吹くぞ」って感じでな。

>>127
おそらく、その中国人の態度は正しい。　元請も、自国の業者に
対してのみ居丈高になる内弁慶ばかりだから、外国の下請に発注
する時のみ、正常なプロジェクト運営が出来るようになる。

で、「日本の業者は使えない」と。　アフォか。

>>131
>作り逃げする大企業は存在しますが何か？ 
>曰く「その開発チームは解散してしまって・・・」 
>　　「別の製品にリプレースされて・・・」 

勿論、個々の担当者レベルではそう言うだろう。
しかしその結果のために、
会社レベルの付き合いを失うようになる事は
絶対避けようとする筈。
結局、最終的には作った側が何らかの形で
責任を取るようになる
（会社のお偉いさんから、お前らに
「業務命令だ、やれ！」
っていう勅令が下る、とかさ）。

それが「作り逃げ」しないって事。

＞将来もその顧客と長く付き合っていくつもりがあるならば、
＞その機能不足の要件定義を作った奴のミスとなる。

インタビューした時点で
客が意識してないものもあるわけで
それをどうやって盛り込むの（笑

それを要件定義作ったやつのミスとか言われたら
要件定義作ったやつもイヤになって辞めるか壊れるんじゃね？

上流工程担当者のみ、自分達の締め切りを平気で破る件について

>>134
いや、会社レベルでの付き合いをするからこそ、納期と金を払えないなら仕事を断るんだよな？
それが普通だし、ビジネスだよね？

最終的に作った側が責任を取るという事は絶対にない。双方が合意した以上ね。
これが契約なんだから、例え裁判になっても勝てる。（というかうちの会社は勝った）

それに、5年後10年後という意見もあったが、金も払わない・納期も延ばさないってのは、
5年後10年後も同じような事になるんだよね。
これが、会社レベルで付き合ったら、毎年、毎月、毎日がそういう状態。

会社にとっては、こういった客とは1日でも早く縁を切るのが、危機管理の1つだと思うんだが。

結果、設計しないでいきなりコーディングして、客にいちいち確認を取りつつ進行していく先の見えないドカタ仕事が
アジャイルと称されて蔓延し。


そしてだれもいなくなるんじゃないのかな。

>>137
＞会社にとっては、こういった客とは1日でも早く縁を切るのが、危機管理の1つだと思うんだが。

俺が常々思っていたことをズバッと指摘してくれた
全くその通りだと思う

もしそういうことを是とする会社ばかりで
そういう会社を相手にしないと食べていけない業界ならば
138の言うとおり、もう誰もやらないと思う

>会社レベルで付き合ったら、毎年、毎月、毎日がそういう状態。

そういう事が常態化している組織では、それが仕事なんだと
思ってるから、誰も改善しようと思わない罠。

疑問を投げかける奴は、軟弱者認定されてしまう罠。

世間を見渡してみよう年ないから、他の世界がある事にも気
付かない罠。

>>136
おまいらは、ＰＧ、ピグだ。
黙って働け、死ぬまで働け。
それが、ピッグの使命だ。

そういうことなんだと思う

【自動車】トヨタ、ソフトウエア開発を強化…横浜に拠点新設[04/25]
http://news18.2ch.net/test/read.cgi/bizplus/1145922659/l50

もはや工場の作業工と変わらない

作業工は、五体満足なら誰でもやれる。　ＰＧは、そうはいかない。

それなりの訓練が必要。　カネかかります。

>>145
ん？

本当に訓練してるのか？
金かけてるのか？

別業種から来た奴とか新人とか、ろくに教育も訓練もせず金も掛けないで
行き成り現場に投入。

OJTの名のもとに実践の仕事で覚えさせる。
自分で勉強するなりで仕事を覚えないと、あいつは使えない奴だと言われる。

そして、一番大切なのは五体満足な事。

まさしく、工場の作業工と同じじゃないの？

どの時点で払う事になるかはその組織次第だけど、ロクに訓練
していない新人を現場に投入する事によって、プロジェクトに深刻
なダメージを負わせる場合、そのダメージこそが、コストですよ。

工場の作業工って安全教育義務づけだろ、ひでえところ以外。
プログラマはなんにもしてもらえないのな。縛りもないから。

>>148
だから、プログラマも国の認可が必要にすれば良いんだよ。

初級シスアドを持ってないと、エンドユーザ側のシステム担当者になれない。
基本情報をもっていないとプログラムを組んじゃいけない。
ソフ開を持っていないとSEとして客から要件を聞いてはいけない。

とかな。
これで、この業界の無駄な人罪（人材ではない）の７割ぐらい減らせそう。

工場や設備関係のシステム納めてると、現場で安全教育受け
させられるけど、大した事やらないよ？

だって、ロクに教育受けてない建設作業員にも分かる程度の事
しかやらないから。

>>43
それは部品化したやつのオブジェクト指向設計スキルがまだまだ未熟だからだろうね。

>>44
まだそんな時代遅れな都市伝説を信じているのかお前は。
正規化すると性能が落ちるのは誤解だということが
証明されたわけだが。

古い知識しか知らないで新しい技術を批判する奴はさっさと死んで良いよ。

「DBを正規化すると遅くなる」は誤解，実証実験の結果が公開に：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/

>>152
馬鹿な実証検証を本気で信じてるの？
いかにも何も知らない人が実験しましたって感じの内容だね。

>>153
いいから反論しろよｗｗｗｗｗｗｗ

勿論、その実験の詳細は俺も知らんのだが、
少なくとも、俺と同じようにその実験の詳細を知らない奴に
「いかにも何も知らない人が実験しましたって
感じの内容だね」
と言われても、何の説得力もないな。

>>151
それは部品化で問題があったときに常に言われる言葉だが、
そもそもこれでOKってな完全部品化アプローチみたいな銀の弾丸は無いんじゃないか？

部品化なんて10年以上前から言われているが、きちんと具体化されたアプローチはない。
これだと部品化自体の必要性が疑問視されてもおかしくないと思う。

部品化は再利用されてこそ価値があるが、
再利用を前提とした部品化がうまくいったケースがいまだかつてあったのか

>>153
> >>152
> 馬鹿な実証検証を本気で信じてるの？
> いかにも何も知らない人が実験しましたって感じの内容だね。

お前必死だな。
そんなに信用できないなら
日経BPに苦情でもいったらどうだw

http://www.doaplus.com/html/bun03_20051101.html
これありえない非正規化だよ

非正規化っていうけど
こんな構造だったら遅いの当たり前ジャン

正規
http://www.doaplus.com/html/NormalizationR14.files/slide0211.htm

非正規
http://www.doaplus.com/html/NormalizationR14.files/slide0202.htm

ありえないsqlだよ

文句を言うならば、自分で
ありえる非正規化されたテーブルを
提示してから、だな。

目的は非正規化されたDBが遅いかどうかの検証なので、
非正規化に有利なテーブル構造で実験をするなんて馬鹿はしない

ヒルズで回転ドアを設計した奴も評価できない。
事故死が起きる前の回転ドアは。

非正規化なんて普通に正規化してて成り行き上どうしてもという理由があってやらなきゃならんわけで。
初めから非正規化で乗り込むことはないだろうに。

非正規化された時点でそれは絶対必要なんだよ。

>>164
というバカの為の実験なのだが・・・

設計屋が実装まで見通せてないと、そういう非正規化も起きるだろう。
いくら設計段間で正規化しておいても、動かすためには周辺の要因で非正規化を余儀なくされる。
要するに設計屋の怠慢だ。

だからといってあの馬鹿実験の検証結果を鵜呑みにできるわけじゃないがね。
あんなのを論文にして学会に発表したら嘲笑の的だろうね。

実験検証するなら、実際に稼動しているシステムをランダムにピックアップして、
それぞれのＤＢを正規化して実行してどの程度性能が上がるかを確認すべき。
いい結果がでるようなデータでテストして、ほらみろ、なんて小学生だよ。

>>162
だな。到達点が先に決まってるというか。
如何にも肉茎らしいというか。

>>166
第三正規化までしてから、実装上の都合で一部を第二・第一まで戻すのは普通にある事だ。
「テーブル5つもJOINすんのかよ」とか、
「これマトモにやったら何億レコードになるんだ…」とか。

普通はJOIN減らすために非正規化することが多いと思うんだがな
あるいは確定データとしてデータ自体を持ってしまうなど。
非正規化にしたせいでありえないほどJOINするなんて、
現実ありえない。
っていうかそんなテーブル設計するあほはいない。

つーかJOINしまくらないとダメな時点で正規化する意味がない
そんなありえない設計を思いつく時点で無能

プロジェクトのコスト増は現場の人間が無理して見えなくなってしまう。
新人の教育コストなどは、明確に数字として現れる。
経営側は数字として出てこないコストなどに興味はない。
結果現場の負担が激増していく。

教育不足、技術力不足で使えないためにコストが膨らんだという結果を出すと、
管理能力不足とかで評価が下がるだけ。
やってられっかぼけぇ

>>159
以前素人C言語厨が思いつきで作ったDBはひどいものだったぞ。
一ヶ所データを更新するとまたほかのヶ所も同時に無駄に複数ヶ所を更新しないと行けない。
正規化すればたったひとつ更新するだけで終わるものを
くだらない非正規化DBのために無駄にトランザクションを考えないと行けない。アホらし。

>>163
なるほど、

ヒルズの回転ドア　＝　非正規形DB

なるほどね

その比喩はわかりにくいが、
ヒルズの回転ドアは安全装置を切って運用していたのが問題だった

運用ミスじゃんか

ミスかな？
危険を承知でやっていた、はよくあること。
安全装置なんだから、切ってったら安全でなくなるよな。

安全装置が誤作動してよく回転が止まってたという布石があるんだけどな

あれは回転ドア自体が問題ではなく、
森ビル側の要求と三和側のソリューションが合致しておらず、
契約を曖昧なままにした典型的日本企業の悪弊

どういう周囲環境のなかで、どういう客層がどういう頻度で訪れ、どういう危険防止策が必要か
を明らかにした上で、どういう回転ドアがほしいのかを発注して契約すべきだったのに
それがぐずぐずになった

http://youzo.cocolog-nifty.com/data/2004/03/post_62.html
＞人が挟まる→挟まる位置から人が入らないようにさくを置いた→さくのリボンが
＞センサーに反応するので、センサーの感度を下げた。

森ビルがアホ

>>あれは回転ドア自体が問題ではなく、
えっ、激しく問題だろ。人が死ぬんだぜ。

とりあえず、サービスを提供していると言う意識があるのなら、顧客を教育していくのも必要
サービスだからサービス残業は当たり前と言う考え方は顧客を馬鹿にしているし顧客の成長が望めない
契約が全てとは言わないが間違っていることを間違っていると指摘していく事は重要

筋を通していきたいね

>>182
同意。でもまずは、自分が有能だと思い込んで
品質が悪いものをさっさと作って、サボっている派遣をどうにかしたいんだけど。

>>184
品質計画をきちんと策定し、それに沿った開発プロセスを行う
派遣のメンバーの評価基準もそのプロセスに当てはめてしまえば良い
もちろん契約時点でその事を通知して無いと駄目だけどな

他人に丸投げしてるだけのアホに、そんな事出来るかよｗｗｗ

技術的にも、使い勝手的にも無茶な設計をしてるところがあった。
無茶だということを指摘すると、お客様の要望だから絶対に
やらないといけないといわれた。

たまたまお客さんのところにいって話を聞いていると、
要求とかに無理がないかなど、適切なアドバイスを期待していると
言われた。
ただ言われたとおりに作るだけのことなど期待していないと。

お客さんと直接話しないからお客さんの期待していることが
分からないんだ、と人を小ばかにしていた本人が、
お客さんの期待をぜんぜん理解してなかった。

お客にとっても、話せるＳＥ，そうでないＳＥがいるんだよ。
１８７は出来るＳＥかもしれんが、どうにもならんＳＥは、
口もきけないし、挙句のはてに暴走、まともでないもん作る。
で、客のせいだよ。そういうＳＥはいくらでもいる。

１８７や１８８の言う能力がＳＥに必要なのか疑問です。

個人の能力も大事だろうけど、お客さんの要望をかなえられているかを
確認する方法を確立して、誰でも実践できるようにすることが重要なのでは？

基本的にはお客さんはＵＩやそれによって管理できるデータが重要なのだから、
最初にモックと仕様書で確認をとるようにすればそれほど外れることはないと思う。

発注したきっかけ、というか、
システムがほしいと思った根拠が薄い場合とかはもう
どうしようもないよな？

御社のビジネスプロセスを変えれば
システムを作らずに解決できるんじゃないでしょうか？ってね

ただのプログラマだけど、>187の客みたいなのが、普通の客じゃないの？
やりたいことはあるけど、抜けがないか自分で判断できない、作れないから、
外注するんじゃないの？

>>基本的にはお客さんはＵＩやそれによって管理できるデータが重要なのだから、
>>最初にモックと仕様書で確認をとるようにすればそれほど外れることはないと思う。
ＵＩ作って、客と打合せしても、客の要望したものでなかった、というのはよくあること。
脳内で理解し、ＰＧに丸投げ。懲りない、おまいら。

違うと分かったんなら成功だろ

>>192
馬鹿？
そうならない方法を考えてやっていくんだろ？
否定するだけの生き方ってのは楽でいいな。

PGから叩き上げの設計者は割といいんだが、設計しか知らない設計者が一番困る。

Sﾖ か・・・

厄介なのが中途半端なプログラマーな設計者。
最悪なのはコボラー上がりの設計者。

お前何がしたいんだという設計をこないだ見かけました。
あいつら関数憎んでいるんじゃないかっていう感じで。

他人がきちんと理解できる説明できない奴って痛いよな

当たり前の知識があれば理解できるはずの説明をしても
ぜんぜん理解できないやつも痛い。

こういうやつは人が理解できる話を云々言ってくるんだが、
そもそも今はお客さんとか素人相手に話してるんじゃねーんだよ。

最初に自分の不勉強さを思い知ってファビョるんだよな。

あとはもう、どう説明しても分かろうとしない。　いや、分かって
るんだけど、それを認めようとしない。

それすると、自分の自我が崩壊するからｗ

ヤンウエンリーも犀川耕平も言っていた。
自分の言っている内容を相手が理解できないのは
説明している本人も理解できていないから、だって。

いや、まえ初めて会った人にWEBにおけるデータベースの役割からDBの仕組みの概略までかいつまんで話した。
正直その理解度のなさにびっくりするほど何を言っても理解してもらえなかった。
それでITの営業ってありえなす。

斉藤孝の本だったかどうか忘れたけど、
あることについて内容を完全に理解していれば、
１分で説明することも１時間説明し続けることもできるらしい。
当然１分というのは概要レベルだし、１時間になると詳細に踏み込んだ説明になる。

データベースの役割からＤＢの仕組みについて普段から徹底的に考えていれば
小学生でも理解できるように説明できたと思うぞ。

>>203　ちがうんだよ・・・よくお年寄りの人がコンピュータわかんないっていうよね?
そのレベルで、理解して繰んないのよ･･･
小学生に説明したとして説明していけばいつか｢あっそうか！｣っていうところあるよね?
それがいつまでたっても出ないんだよ。たとえをしても、斜め上の理解してハァ？ってなる・・・
確か当時35ぐらいの人だったと思う。

世の中には、そういった年寄りに教えて、理解してもられる人が居る。

何が言いたいかというと、人に何かを教えるというのは確かにその知識は必要だが、
それとは別のスキルが必要。

例えば話をして斜め上の理解をされたのなら、それはその例え話が良くないって事。
小学生に説明して ”いつか” 理解・・・ではこれもスキルが無い。
1回説明しただけで、9割程度の人間が理解できるような、
単純明快な説明があるはず。

そうだねえ。わからない人には二種類いて

希望のあるわからない人/
希望のないわからない人

希望のあるわからない人は頭が確かに動いている。
理解しようと動いている。教養としても基礎がある。救いようがある。

希望のないわからない人は頭が動いていない。
メモリが8byteぐらいしかない感じ。超直前の文脈ならサポート。
それ以外は全てが揮発する。おまけにCPUは何もない。
酷い場合だと方角、ひらがな、九九すらわからない。
わかろうとしていない。頭が物事を理解できるように出来ていない。
わかることのありがたさも無い。何も無い。空っぽ。

ホントにそこまで揮発性だと、病気の範疇だろう。

そうじゃないのに、そういう状態なのは、それは話し手のせい。
最初に興味を惹く事に失敗してるって事さ。

>>205　だからさぁそういうはなしじゃないんだって・・・多分そのわからない一割がその人だったんだと思うよ?
>>206　あぁそんなかんじ。

>>207
元の話題とは独立してレスさせていただきますが、
世の中結構そういう病気の人はゴロゴロいるもんですよ。
家庭教師とかやっている人ならわかるでしょうけれども。

日常会話や生活は見た目支障なく出来るんですよ。

そういう人達に何かを教えようとすると、見えない絶対的な壁が
立ちはだかっているように見えるわけです。
まあ、脳に障害が無い限り根気よく
小学一年生からやり直せばなんとかなるかも…。
ただし彼らにとってはもっと適当な仕事があるかと思われます。

>>207　んー病気じゃないけど、飲み込みの悪い人っているよね?で、それは人それぞれで差があるよね?
その中の特別飲み込み悪い人だと思ってくれい。

飲み込みの悪い人には：

・早とちりして「〜〜だよね？」と的はずれを言う。最後まで話を聞くことがない。
・落ち着きがない。本を十分でも直視出来るだろうか？出来てもおそらく読んでいない。
・プライドが高いので、小学生のように素直に先生の話を聞かない。
・プライドが高いので、自分が賢いと信じている。アイムヘテロジーニアス。
・プライドが高いので、自分は学ぶ必要は無いと思っている。
・プライドが高いので、知ったかぶりをする。つっこまれるとウソにウソを重ねる。しかし自信満々。
・文章を見たら文章という情報しか入らない。復唱しない。
　脳でイメージしていない。論証しない。語感が働かない。ていうか字が読めない。
・どうやら分からないことが悔しくないらしい。

という特徴があると思うのだけれども、どう思うだろう？
でも、飲み込み悪くて希望すら無いけど、すんげー真面目に
頑張ろうとしている奴もいる。そういう人は何とか助けてあげたいし、
最終的にそれなりには理解するところまでこぎ着けられることもある。

>>182
うむ、言えている。「お客様は神様だから逆らえない」という
営業の言い訳にはウンザリ。


客をしごいて教育して間違った装置の使い方を正さなければ
こっちが大きな被害を受ける。

お年寄りに教えてんじゃないんだよ。
プロフェッショナル同士の会話なんだよ。
小学生に教えるのが仕事じゃないんだよ。
分かってる？

＞データベースの役割からＤＢの仕組みについて普段から徹底的に考えていれば
＞小学生でも理解できるように説明できたと思うぞ。
詳細を大方の小学生が理解できるとでも？
ありえないね。

>>201
養老孟司は違う事を言ってるけどなｗ

そんなどうでもいいこと議論するな

自分に都合のいい事実しか見えない無能が何言ってんだか。

217 名前： 仕様書無しさん [sage] 投稿日： 2006/05/02(火) 01:54:14
自分に都合のいい事実しか見えない無能が何言ってんだか。

218 ： 仕様書無しさん [sage] DATE:2006/05/02(火) 02:10:11
217 名前： 仕様書無しさん [sage] 投稿日： 2006/05/02(火) 01:54:14
自分に都合のいい事実しか見えない無能が何言ってんだか。

仕様書無しさん sage New! 2006/05/02(火) 02:11:27
218 ： 仕様書無しさん [sage] DATE:2006/05/02(火) 02:10:11
217 名前： 仕様書無しさん [sage] 投稿日： 2006/05/02(火) 01:54:14
自分に都合のいい事実しか見えない無能が何言ってんだか。

220 ： 仕様書無しさん 2006/05/02(火) 02:13:38
仕様書無しさん sage New! 2006/05/02(火) 02:11:27
218 ： 仕様書無しさん [sage] DATE:2006/05/02(火) 02:10:11
217 名前： 仕様書無しさん [sage] 投稿日： 2006/05/02(火) 01:54:14
自分に都合のいい事実しか見えない無能が何言ってんだか。

221 仕様書無しさん sage New! 2006/05/02(火) 02:15:25
220 ： 仕様書無しさん 2006/05/02(火) 02:13:38
仕様書無しさん sage New! 2006/05/02(火) 02:11:27
218 ： 仕様書無しさん [sage] DATE:2006/05/02(火) 02:10:11
217 名前： 仕様書無しさん [sage] 投稿日： 2006/05/02(火) 01:54:14
自分に都合のいい事実しか見えない無能が何言ってんだか。

>>213
お客様は素人同然。
プロを相手にしているわけではありませんからそれ相応の説明能力が必要。
身内のＳＥにすら理解させられない自分の能力を恥じよ。

>>214
概略の話だったと思うんだけど、よく読んでね。
ただ、小学生の能力を馬鹿にしすぎ。
興味を持たせて、丁寧に教えれば理解してくれる。
うちの子供は今小学５年生だけど、C#でDirectXを使ってゲーム作っている。
興味持てば恐ろしいほどの速度で吸収して理解していく。

＞今小学５年生だけど、C#でDirectXを使ってゲーム作っている
かわいそうに・・・・・

わりわり、概要は読み飛ばしてたよ。
けどねぇ。
出来るやつのこといってんじゃないの。
とくに出来ないやつのこといってんの。

それも、そもそも詳細を理解してなきゃいけない立場の人間なの
お客相手じゃないの

大体専門家レベルの話をしなきゃいけない場面と、
お客さんやら相手に大体イメージ的に分かってもらう、
あるいは分かったきになってもらう、分かりやすいと思ってもらうのとは
全然違う。

5人いたら4人は普通に分かるのに、
1人だけはどんなにかいつまんでも、
懇切丁寧に説明しても分からない。
普通に考えてその1人にも問題がある。

>>223　んだ。たぶん小学生のほうが順を追って説明したら理解すると思う。

>>212
そんな営業がいるのか・・・
悲惨だな。

お客によいと思うものを提案していくのが仕事だ。
（押し付けでは無くて）
客の言いなりになるのが正しいのではない。

営業に〜って話があったけどそいつはそもそも理解する気が無いんだろ
「うるせえな、早くその話は終わりにしろよ」位にしか思ってないよ

これこれこういう点は大丈夫なのか、どういう対処が取られてるのか
とか聞いてくる。お客さんに聞かれたから。
これこれこういう動作になるので大丈夫だと説明しても分からない。
細かい話はいいから（ぜんぜん細かい話じゃない）。
お客さんに分かるように説明してくれって言われて、
お客さんに説明したらすぐに通じた。
営業は最後まで分かってない。
だんだんお客さんの態度が営業を不審な目で見るようになっていった。
仕事としては失敗だ。

君が行ってからお客さんの態度がよくなくなったそうだ。
やっぱり直接お客さんと話すのは技術者には無理だねえって言われた。

なんだかな〜

>>215
それはいえている。
>>201は「バカの壁」「死の壁」を読むべきだ。
あの本の表紙に書いてあるとおり「話せば解るなんて大嘘」
なんだよ。

簡単にバカを理解させられるなら世界中の戦争なんて
簡単に終わらせることができるし近頃の何でも無さそうな
奴が突然人を殺すような治安悪化だってとっくに解消している。

イスラム教原理主義者にはただただ何を言っても無駄なんだよ。
自爆テロリストには説得なんて一切効かない。
最初から一般人を巻き添えにして人を殺して自爆することしか
頭に無いんだから。

>>223
> >>214
> 概略の話だったと思うんだけど、よく読んでね。
> ただ、小学生の能力を馬鹿にしすぎ。
> 興味を持たせて、丁寧に教えれば理解してくれる。
> うちの子供は今小学５年生だけど、C#でDirectXを使ってゲーム作っている。
> 興味持てば恐ろしいほどの速度で吸収して理解していく。

VB厨レベルでもそこそこのゲームは作れるぞ。
お前、我が子をC#厨にしちゃうのか。
ソフトウェア工学やJava、UML、LISP、アスペクト指向、数学についても勉強させてはどうだ？
我が子をエンジニアにしたければ、専門卒みたいな特定の分野のことしかしらない人間にならんように、
大学工学部情報工学科または情報学部に行って基礎理論を学べるように教育しておけ。

>>230
その営業、たんなる営業だけでなくて、
一応、社内にある別の会社の代表取締役社長という肩書きを持っている。
だからタチが悪い。
最近はろくに仕事しておらず、落ち込んでいて
窓際族みたいになっているがw

>>232
営業が自分の立場を維持したくて必死になっている
んじゃないのか？
営業ってのはとにかく時間内に客との交渉が成立したら
それがノルマとなって達成率が一定以上になると給料が上がるというからな。
その後に、営業が仕事をとってきてからその仕事をどう調理するかを
考えさせるように、その営業の上司がちゃんと監視しないといけないんだがな。
その監視がなく、営業の上司は営業の良いところだけを見て
落とし穴を覗かず、営業とエンジニアとの関係もろくに見ずにいることも問題。

会社が、その変な営業のことをかわいがっているようなら、
会社全体に問題がある。そんな会社さっさと捨てて転職くらいでないと
救いようがないケースもありうる。

営業って売ればいいと思って過ぎ

システム作っただけじゃ金にならないんだぞって言うのは確かにそうなんだけど
採算度外視して売るのはやめれ

システム作らなきゃ売るもんもないんだぞ。

おたがいに必要なんだけどね。いいシステム作る人、それを営業するひと。
まぁ自分はPGなんで勘違いしてる営業とはよく喧嘩してるが。

どっちがどうじゃなくてどっちも重要。
今更言うまでもない当たり前のことなのに、
なんでこういう言い合いは絶えないんだろうね？

営業が人を札束としてカウントしたがるから。

勘違いしてる馬鹿がいるからでしょう。
まえに複数システム掛け持ちしてて泊り込んで色々やっていたときに、営業が急ぎでない不具合持ってきて「こんぐらいちゃちゃっとやってくれよｗｗ」とかいったときは殴りあい寸前になったな
まぁ向こうから見たらまたいいたいことあるんだろうが。いいたいことは相手の事情をおたがいに考えろってこった

営業って、売り上げ（頭数）で月々コミッション入るんじゃないの。

客って騙されてるよな。
機能改善ごときでＰＧ２名増員とかな。
新規開発の時より人員が多いじゃん。

立場が上になればなるほど、なぜか考えなくてもいい仕組み
になってるからな。

>>237
＞営業って売ればいいと思って過ぎ
＞システム作っただけじゃ金にならないんだぞって言うのは確かにそうなんだけど
＞採算度外視して売るのはやめれ

そういうお前さんは、恐らく経営とか金の動きが分かってない。
言いたい事は分かるが、社会人としての一般常識程度の会社の知識があれば、
どうして、採算度外視してでも売るのかが分かるはず。

偉そうな奴だなお前

まるですべての経営者が神だと言わんばかりの主張だな

>>246
誰もそんなこと言ってない。

何故、採算を度外視してでも仕事をする場合があるのかを知ってるのか？

>>247　営業がみんなそういう高所から聡明な判断をしてくれてるんだったらいいんですけどね・・・
これが後に役立つんだといいつつ、安請け合いして結局元が取れないというより元本われの営業されても結局足が出るんですよね。

>>248
そういった考え方もあるが、採算度外視して仕事をするってのは、もっと違った理由があるんだよ。

ヒント：閉店前のスーパーで何故、採算度外視してまで特売をするのか。

だからね？そういうのを狙ったものもあれば、そうでないものもあるという風に文脈から読めませんか?

営業は「利益率」ではなく「売上げ」の額で
評価されるから。

難波金融どうの泥沼みたいにクレカで購入、現金化してお金が手にはいったぁ･･･と喜んでるのと大差ない営業がいるからな。後始末をどうするんだと。

>>249みたいに「理由があるんだよ」とばかり言ってていつまで経ってもその理由の説明をしないやつは、実は何もわかってないんじゃないか？自信がないんじゃないか？
と思ってしまうがな。

>>254
そういうあなたは何がわかっているの？

>>1
「設計は評価されない」
ではなくて
「設計を評価できる上司がいない and 会社にそれを評価してくれるシステムが無い」
って事だろ？

はっきり言うとこの業界採算度外視してよい事はほとんど無い
客のニーズを見分けて営業がきちんと仕事をしておけば良いケースがほとんどなのに
それをしない言い訳に誠意を見せないと仕事が取れないとか言い出す

>>255
反論するでもなく、ただ煽るだけの
頭の悪いﾚｽの見本ですね。

採算を度外視して仕事をする必要はあると俺は思うけどね。
既に、例として出されてるみたいだけど、スーパーの閉店間際の特売と一緒。

賞味期限ぎりぎりとか生物とかは、閉店すれば捨てるなり社員に配るなりするだけ。
つまり、会社としての利益には繋がらない。
しかし、商品を仕入れたんだから金は使ってる。
ならば、利益でなくてもいい・支払った金額全額でなくてもいいから、
少しでも損失をなくそうというのが普通の考え。

これと同じ事が営業にも言える。
仕事が引く手あまたなら話は別だが、仕事が無く、話が来ても採算に合わないものばかり。
でも、社員の給料は支払わないといけない。
（営業含んで仕事なかったら給料払わなくて良いとかだったら話は別だがな）

このまま、何も仕事しなければ、損失がでかい。
ならば、採算度外視してでも、多少なりのお金が入れば損失が少なくなる。

つまり、タダ飯食わせるつもりは無いって事。

富士通とかの大手がたまに採算がとれないような入札とかしてるのを知らないのかな。

まあ、あとからのメンテナンス費用で稼ぎ出そうって魂胆なんだろうけどね。

よい設計は、機能の追加や拡張の時に評価されるｷｶﾞｽ
つまり、作ってる最中は意味なし

>>259
作ってしまったパッケージソフトが「売れなかったら」採算度外視にしてでも売らないと
金が会社に入らないので困るという259の主張は理解できる

受託のシステムの場合は当てはまらないのでは？

やっすい受注してきて保守コストはサービスなんだからタダなんて契約とってきたら
何それ？て気分になる

後は、まずコストわれで受注して実績作って次につなげるとかね。
まぁそれはある程度体力ある場合にしてくれ。てんてこ舞いのときにそれをやった営業とはむなぐらつかみあいになったさ・・・

>>262
いやいや、受託開発でも当てはまる。

というのは、人件費そのもの。
営業が採算に合わないと仕事を選んでばかりで、開発の人間の仕事がなくなった場合、
そのまま、開発者の人数分だけ損失になる。

100％の損失より50％の損失の方がマシなわけで。

>>264
分かりそうで分からない・・・

開発に必要な仕事量をα、必要な時間をtとすると、単位時間の仕事量はα/t
時間単価をcとすると、開発コストはct

本来2人月の仕事に1人月分しか請求しないという状況でもαは固定なので、
一人が二月かけるべき仕事を一人が一月でやる場合は
かけられる時間がt/2なので、単位時間の仕事量は2α/t
時間単価cは固定なので、この場合の開発コストはct/2

つまり、通常より2倍も大変なのに半分しかもらえないという状況は
4倍損していることになると思うんだけど？

いつもより2倍も働いているのに普通の半額しかもらえなかったら
仕事ないよりましだろとかいって無理に営業とって来るやつが憎らしく思えるのは当然かと

営業は仕事とってくるだけだから2倍大変とかないし
客が無理だって言ったら請求額減らせばいいとしか思ってないし

>>265
難しく考えすぎ。

採算が合わないと言い、仕事が無いと収入は0。
だけど、2人月の仕事を1人月の金額で受ければ、少なくても1人月分の収入がある。

単純に1人の単価を100万考え、営業1人、開発2人居るとする。
営業が採算が合わないと仕事を断ると、収入は0だよな。
つまり1ヶ月300万の損失。

営業が2人月100万の仕事を取ってくるとする。
1ヶ月で換算すると50万の収入がある事になる。
つまり、1ヶ月あたりの損失は250万となる。

どっちの方が損失が少ないかは一目瞭然だよな。

まぁ、世の中には
遊ばせておくよりも、仕事させとけ！
勉強にもなるし、次の受注が取れるｶﾓ？
って考える場合がある。

しかし大抵の場合は、前回あれで出来たのだから今回も！ってことになる。

>>268
300万損するのも250万損するのも損は損だろ？
そんな営業はｲﾗﾈ

損する仕事を持ってくる営業って無能だろ？

>>270
だから、仕事が引く手あまたでって書いただろ。
こっちが選べる状況なら話は別だろ。

>>271
営業が無能だか、設計・開発者が無能で営業しても売れないのかは分からないがな。

>>247
赤字にして社員の労働力を犠牲にしてでも
実績が欲しいから注文したというバカ営業がいたけどな。
技術が欲しかったんじゃねえのかよと思ったが、
技術を習得できるどころか使い捨て技術で意味がなかったな。
実績と言っても実力ある社員は会社のやり方に嫌気がさして
何人も辞めてしまったがな。

そういう事情だったり、それでもやるって会社からGOがでてるんなら話は別だろ。
問題なのはそれをSE以下だけで受け止めなければならないような状況で
そういうことをされたとき。
ていうか最初からそういうときの話しかしてないだろうに。

>>245==>>247==>>249
手取り13万程度で社員を月400時間も
働かせて安い給料で無理矢理徹夜残業休日出勤させるような
ことしかできないお前が偉そうに言っても説得力がないぞ。

会社が銀行に借金をするという採算度外視ならわかるが、
多くの零細ソフトハウスのやり方はそうじゃないんだからな。

会社を倒産させたくないからといって社員に嘘をついて

次は昇給させてあげるよとか次はたっぷりとバカンスをあげるよとか
言っておきながら「ごめん！来年こそはちゃんとやるから！」と
毎年毎年同じことを繰り返す言っているんだからな。

とりあえず、採算取れない仕事でウチらに皺寄せ来る場合は、営業担当者もGOサイン出した上司も残業代0で付き合い残業させればいいじゃない。

>>260
それで不治痛は1500億円もの赤字を出したわけかw

>>261
おまえは『アジャイルソフトウェア開発の奥義』を読んだ方が良い。
営業のバカにも『アジャイルソフトウェア開発の奥義』を
読むことを非常にお勧めする。

もう、営業に読ませたい本のひとつだな

>>271
> 損する仕事を持ってくる営業って無能だろ？

無能。バイト先の会社のある営業は、その仕事が
簡単にできるものだと思いこんでいたらしく、
納期が半年以上も遅れて大赤字。
それからその営業は落ち込んで窓際族になった。

>>275
別に俺は営業でもないし、経営側の人間でもない。
俺も開発側の人間だ。

いくつか言えるのは、そういった仕事をしないと倒産するなり、
大規模なリストラをしなくちゃいけない。
これで困るのは、当然、社員だよな。

もう1つは、こういった状況が嫌なら、転職するって事。
職業選択の自由ですよ。

さらに言えば、自分で会社を起こせばいい。

会社に甘える姿勢しか見えないんだが？

ついでにもう1つ。

俺は別に採算度外視して仕事を取ってくる営業が無能じゃ無いとも言ってない。
有能無能で言えば、無能だろう。

しかし、営業というよりも経営者側からのトップダウン命令として、
そういった仕事を受けるというのは、どんな企業でもある事を理解しているのか？と。

>>281
あっていいけど、それを処理するのは技術屋の俺らではないず
少なくともサビしたり、無茶な工期で苦しむのは俺らじゃない。
責任と役割を考えてみろ

だから経営者と営業も同じくらい苦痛を味わってれば少しは気が晴れるじゃん。
やつらがのうのうと帰ったり休んだりしてるのが一番腹が立つ。

営業から来た仕事はちゃんと精査して、技術・開発で受けてないの？
うちは、金額・工期みて営業の採ってきた仕事を断ることもある。

部所単位で損益みて赤にはしたくないもの。

>>284
> 営業から来た仕事はちゃんと精査して、技術・開発で受けてないの？
> うちは、金額・工期みて営業の採ってきた仕事を断ることもある。
営業が取締役を兼ねていると断っても覆されることがある。
バイト先の会社がそうだった。
そんな会社はさっさと見切りをつければいいってことなんだろうけどね
さすがにあんな会社には就職したくないと思った。

採算度外視して受注する会社がいつまでもゾンビのように生き残るから
発注する会社が開発側の足元を見て安く発注する

勝ち目のない企業にはさっさと退場してもらって、
その人材と仕事を大手に回してほしい

そしてまた中抜きして（ｒｙ

>>286
そう、そこなんだよ
問題は採算度外視して実績作ったら採算ベースに乗せてなんて仕事が出来たのは今から10年以上前の話
今は一度採算度外視でとったら次も採算度外視しないとそこから仕事は来ない

往生際が悪い経営者は会社を一旦手放して売却するという
度胸が無いからな

いいんだよ、ＰＧ月２０万程度で買い付けるから。

断れられた、もしくは士気がさがったら本末転倒だが。
しかもプログラマに機密情報とられて退社したらどうするんだ。
給料が安いと平気でそういうことされるぞ

少佐、これからはサイバーテロが流行るよなぁ〜〜。
タチコマより待遇悪いんじゃねーか。

結構中小だと、顧客情報とかノウハウ集コピられて
バックレラレルよな。

経営者があまりにも不当に社員の給料を安くすると
サイバーテロどころか法的手段に訴えて
労働基準監督署の権力によって
会社を破産に追い込まれるぞ

>>294
念のため言っておくと、
「労働基準監督署の権力」
ではなく、
「法律」
だよ。

>>288
別に、採算度外視して作っても、次回以降、その会社と仕事する必要は無いよな？

採算度外視の仕事が損失軽減の物なら、その仕事してる間に営業が採算の取れる仕事を
見つけてくればいいだけで。

>>296
なるほど。
上の方で書いてあるように採算度外視単体が意味があるということなら、それも意味があるな。

>>296
それで？

>>296
だから、その前に採算度外視した仕事をする必要がないように営業をきちんとやっていれば問題が無いんだろ

仕事うまくいった場合なんか、次の仕事で
ハードルを上げるのは上司よか営業の方が多いと思う。

上司は最低限の面倒を見るので大変なのか大変じゃないのか
分かるけど、営業は正真正銘関係ないのに平然とハードル
上げるからな。

営業を叩くスレになりつつあるな・・・・

減らず口を叩くの　叩くか？　相手の面前で述べてないなら、叩いてもいないぞ

単なる負け犬の遠吠えか、せいぜい愚痴だな

なぜこの業界の営業はバカばかりなのか？
http://pc8.2ch.net/test/read.cgi/prog/1146570814/

営業には営業の愚痴があるだろうに。
お前らには相手の立場になって考えるって能力が欠けてるな。
いや、想像力が欠けてるのかな。ガキばっかだな。

営業は採算度外視の契約を取ってきても
自分の食い扶持が減るだけでへっちゃらだが
開発者は食い扶持が減るだけでなく仕事量が増える

>>304
お客に大きな声で言えないというのは理解している。
で、大きな声で言えなかったツケをこっちに回しているのは身を持って理解している。
板ばさみゆえに言いたい事が何も言えないだろうなと予測できる。

で、漏れらの願いは大きな声の代わりに知恵使えやということ。
営業周りで喫茶店よったり、朝遅れた時の”客先行ったんで”を止めて
最低限の協議を漏れらとしてから客先に営業に逝け。

行く前の１０分程度のﾊｧﾊｧｳﾝｳﾝで客先で適当な事抜かすからこっちがえらい目に
あうんだ。

営業が許される愚痴は事前の協議で言ったことができないじゃないか！という場合のみ
で、それは事前にﾃｽﾄ位させろやｺﾞﾗｧ！技術情報いっただけじゃわい。と上司に飛び火させて
上司が客先に謝りにいっておしまい・・・ならよくて役員が頭下げに行くケースがあり、
何故か開発班は平然としていて営業は冷や汗をかくっつー事位はこの業界２，３年いれば経験づみだろ？

営業は安くても案件を多くまわせばいいと思ってるからなぁ。
ねずみ算式に開発人数増やせられればそれでいいのだが、実際増えるのは今居る開発の残業だけ。

>>306
それじゃあ、聞くがね。
お前らに相談してもお前ら技術職のものしかわからない用語をまくし立てるように言う。
しかも、それでできるのか、できないのかって聞いても曖昧な返答しかしない。
どういうこと？
営業の説明をしても専門用語がわからない、とか文句いうわりには、
自分らも人にわからないような専門用語を使う。で、勉強不足だとかいう。
お前ら何様だ？


と営業の気持ちを想像してみた。

ああ、営業にも専門用語なんかあるんだね。当たり前だが・・・、
少なくともこっちは営業の何たるかを聞いた事ないし、
営業の営業の何たるかは言ってこなかった。

２，３で良いから誰か営業の専門用語を教えてくれない？
ついでに愚痴でも営業の説明をシミュレートして。

> しかも、それでできるのか、できないのかって聞いても曖昧な返答しかしない。

やったことが無いことを、できるのかできないのかと
いわれても分からんよ。どちらの答えもウソになる。
（その時点では）わからないという答えも、答えの一つだ。

円周率1000桁暗記、できるのか？ できないのか？
ほら？答えられんだろ？

>>310
お前マジで馬鹿だろ？
相談しろ、と言っておいて答えはそれか？
で、営業の俺らにお客様にどう説明しろっていうの？
やれるかどうかわからないけど、ン万円でやりますっていうの？
だからお前らに相談しても無駄なんだよ。
わからないなら調べろ、それでも技術職の誇りもってんのか？



と営業の気持ちを想像してみた。

ようはお前ら対話しろってことさ。うわべだけでなく。

>>311　やったことのないことを、出来るかどうか頭の中で決めろとはホントにお前は技術ってものをどう考えてるんだ?お前は、プロジェクトXでもGWぶっ続けで見ろと一時間問い詰めたい



とPGの気持ちを創造してみた。

イエローモンキーは何やらしても中途半端やな

出来るのか、出来ないのか？を質問すると曖昧な答えをするとか言う前に自分の売る商品の特性すら知らずに客に売るのか？

313は能力が低い技術者の代表って感じだな。
いついつまでに調べて返答します、とか言うもんだ。
わからない、とか言う前に動け！！

315はコミュニケーション能力が低そうな技術者の代表って感じだな。
だれが自社パッケージ製品の話をしてるのやら。
しかも、自社製品で出来るかどうか聞いて解答すら出来ない技術者はさすがにいないだろうし。

>>316
商品ときいてパッケージしか思い浮かばないのか？
受託開発なら開発メンバーが会社の商品だぞ

俺もパッケージだとは思わなかった
受託開発だとばっかり

>>317
どちらにしろ本質は変わらない。調べて回答しろってことだろ。
技術者は言い訳の技術だけは一人前なんだからな。



と営業の気持ちを想像してみた。

調べて回答するったって、どれくらいの期間調べればわかるのかなんてわかんないじゃん。
上司が期間くれて調べろって命令するのならともかく、
営業ごときの変なおしゃべりにいちいちつきあって調査なんてはじめてたら仕事になんないよ。
それだけの労力をさく価値があんのかと。

調査工数がかさむ→開発費が膨らむ→採算が取れない→現実的に出来ない

マジ言い訳ばっか。相談しろっていったのお前らだろ？
で、こっちで仕事決めてくると愚痴愚痴いう。
結局どうしてほしいわけ？




と営業の気持ちを想像してみた。

>>322
客の要件を聞いた上で
必要な期間とコストを開発側に打診し
それを元に客と相談するのが営業の仕事

>>322
簡単な事だろう
楽に簡単で儲かる仕事を取って来いって事だよ
後は後腐れの無い奴が良いね

お前が言ってるのは、Winnyみたいなシステム作れるとかいってきて、こっちがわからんて逝ってるのとおんなじなんだよ。ある程度作ってみないとどこに問題が出てくるか判らんようなシステムなんざいくらでもあるんだよ。それすら想像できない池沼ですか?

全く頭のカタイ営業の相手してると疲れる。だから業績のがわるいんだよ。
ダメなものはさっさと捨ててネタ探しに頭下げて駆けずり回りな。

>>323
要するに技術者のレベルが低いから可能か不可能か、妥当か妥当ではないかの判断ができなってことだろ？

>>324
それを相談してるのにわからんの一点張りじゃね。話になんね。

>>325
お前は自分の勝手な妄想で話を進めるキティ技術者ですか？
ほかの技術者はおまえに苦労してるだろうね。

>>326
お前馬鹿すぎ。まともな回答できないなら一生ＲＯＭってろ

>>327

>ダメなものはさっさと捨ててネタ探しに頭下げて駆けずり回りな。
とても模範的な回答だと思うが？これが理解できてないから頭がカタイといわれるんだよ。

>>327
>要するに技術者のレベルが低いから可能か不可能か、妥当か妥当ではないかの判断ができなってことだろ？

お前頭悪すぎ
お前にそれを判断できるわけない
お前にコントロールできるわけがない

>>327
はっきり言って、お前は営業じゃなくてただの使いっぱ
自分の所の戦力を把握せずに売りに言ったら、足元見られるのは当たり前
なんでそれが判らない？

>>328
だめかどうかの判断を下せない技術者がダメって話だろ。馬鹿は一生ＲＯＭってろ

>>329
技術者が判断できないっていってるだろ。だれがそれを判断できる？
少しの労力を惜しんで営業に協力しないくせにとってきた仕事には文句しか言わない。
腐った技術者はどっかいけ。

>>330
残念だったね。私は開発者だよ。営業を想像して書いてるだけだよ。

営業もPGも両方歩み寄らないと駄目だと思うんだが、
みんな歩み寄らないのな

営業技術を連れてけ

>>332
このふいんきが好きなんだから仕方が無い

>>322みたいなガキの使いにこられても言葉が通じなくて困るだけ
顧客の立場から言うと
操りやすいという利点はあるがw

>>332
そういうことは営業に言ってくれ。開発する側はいつでも営業の我侭を聞いてやってんだからな。

>>336
そういう態度が餓鬼なんだよ。
上であったように開発に相談すればわからない、って言う。
自分らがやる仕事なんだから真剣に考えろよ。
後から文句言うなよ。馬鹿ちゃうか？

>>331
要するに子供なんだな、お前ｗ

>>304
想像力が欠けている人間がソフトウェア工学を駆使して開発ができるとでも
思っているのか。営業こそ口先だけで技術も科学もなにもしらない、
科学に対する探求心も何もないひらめきも発想も何もできない馬鹿じゃないか。

>>337
相談なんかされたことないんだが（苦笑）
同行するとスケジュールまで決定してんのに何故かスケジュール外で決定してたりするしなぁ。

相談してくれたら、見積もりくらいしてやるよ。技術的に出来るかどうかくらいの判断も出来ない新人じゃあるまいし。

後から文句言われたくないのなら相談してくれって言ってるんだよｗ

それとも、会社組織無視して自分で受注から開発、納品まで全部やれとでも？

http://www.geocities.jp/nat_akinorijp2000/uirusudiary.html

>>339
そういう態度が人の立場にたって考えることができないってことだよ。
もっとも大事な想像力が欠けてる証拠だよ。

>>342
で、営業が人の立場に立っていると思っているのか？
自社の開発側の思惑も理解できてない奴に言われたくねーな

>>311
お前本当に口がうまい営業かと言いたい。
頭使え。
エンジニアは下手にチャラチャラと嘘をつくわけにはいかんのだよ。
相手を期待させておいて万が一できなかったら顧客を
間違いなくがっかりさせるだろ。それでは今後エンジニアとしての
信用を失う。だからできないことははっきりとできないと言う。
それからまだ未開拓のものはこうすれば確実にこの時間と予算で100%できるとは
断定できない。あくまで見込みだ。
たとえば、95%以上は成功するだろうという見込みがあるだけで
100%成功するとは限らない、など。営業が顧客と余計な交渉を行ったかどうか次第でも
そのパーセンテージは大きく上がり下がりし成功率50%以下に下がることや
納期遅れや赤字になる可能性もありうる。

だから顧客の前で安請け負いはするな。
顧客の前ではプラス面だけ見せろ。

>>327
技術者のレベルが低いと思うならさっさと上司に
それを報告しろや。
お前それでも営業か？

>>316
そもそも、お前のほうがコミュニケーション能力に問題があると思うが。
営業なのにやばいぞお前

>>331
なんだ営業SEか。

>>333
技術営業だろ。
今不足しているらしいな

技術が解らない営業ばかりで話にならないと

>>343
おまえ・・・人が悪いことやってるから自分もやっていい、と思っている子供だろ。

>>344
ただの言い訳にしか聞こえない。
技術的に可能かどうかなんて優秀な技術者ならあいた時間を利用して調べて
数日内に返答くれる。少なくとも私はそうしている。

営業の振りしてる開発者って･･･何のためにそんなことしてんの?つるしか休みにやることないのか。河合そーに

>>347
別名、無能SEとも言うがな。

今までのまとめ：

技術者「営業！お前が歩み寄れ！」
営業「いいや、お前が歩み寄れ！」

>>349
>ただの言い訳にしか聞こえない。
>技術的に可能かどうかなんて優秀な技術者ならあいた時間を利用して調べて
>数日内に返答くれる。少なくとも私はそうしている。

だーかーらー、その返答を求めてくれない営業が多いんだよ。

>>353
そういう場合は営業が悪い。
でもここの奴らの大半は、言い訳だけでできない、としか言わないやつだろ。

>>354
>でもここの奴らの大半は、言い訳だけでできない、としか言わないやつだろ。

その根拠は？
決め付けてるだけの様に見えるが？

その様子だと普段の業務もそんな調子で周囲に迷惑かけてるクチか？

つうか営業が休み中にマ板に居るとは思えない

>>356
金曜ならありえるけどな。営業の場合、普通に先週の土曜辺りから休暇入りしてる奴が結構多いしな。

今日辺り、自宅に戻ってくる連中は多いんじゃないか?

>>355
根拠はスレを全部読め。
なんだかんだといいながら出来るか出来ないかいえないって主張してるだろ。

>>358
個々の案件内容も見ていないのに判断なんか出来ない。営業じゃあるまいし。

>>359
はーい、言い訳はいりましたー

>>360
なるほど営業ってのは案件の中身なんか見ずに安請け合いしているんだなｗ

しょうじきGWにこんな小学生並みの粘着してるのって頭おかしいだろ

営業やってる俺から・・・

採算の取れない仕事を取るしかないのは、一言で言えば、日本人技術者の存在そのものです。

日本人PGとかでも単価100万近く掛かります。
でも中国人PGなら単価30万ですみます。

この業界で中国などの海外オフシェアは今では当たり前です。
なので、数社でのコンペになると、金額面で絶対に勝てないのです。

自分の会社にも言えるのですが、会社に在籍している日本人技術者の8割程度を
クビにして、残った技術者をプロジェクトリーダーとして残りを中国に仕事を出せば、
採算が取れる仕事ばかりなのです。

国レベルでIT技術や英語・日本語を教えてる中国に対して、
日本人は、英語すらまともにしゃべれない。IT技術のレベルも劣ってる。
今では、客に金額の説明をするとき、何故、日本人技術者をつかうのか？
この日本人技術者は中国人技術者の3倍以上（金額に見合う）の能力があるのか？
という事を説明しなくちゃいけないんですよ。


つまり、何が言いたいかというと、『給料泥棒の日本人技術者イラネ』

>>363
インドか中国、あるいは韓国辺りのオフショア専門の企業に転職したらいいんでないの？

それが出来もしないくせに俺ら技術者に文句言うの止めてくれる？

>>363　中国･インドに仕事投げた結果、出てくるもののクオリティが低くてまた日本に回帰しつつあるのを知らんのかお前は･･･
まぁうまくいってるのもあるんだろうけど、いってないのも多々あると思うよ。中国に出せば安くおさまるとしても色々と日本で作った場合では起こらないトラブルが起こるのは容易に想像できる。
英語がもっと日本で普及してれば、そういったトラブルも少なくはなるんだろうけど。
そもそも、中国で日本人よりも技術があり英語が出来るものがどれだけいるのか。いるとしても海外に流出してしまって中国国内にはとどまらないんじゃないかな?
結果としてそれなりに出来る技術者の下に有象無象がくっついてるという日本とかわらない状態になるんじゃないかと。

>>364
まとはずれなことを言って反論するあたりが無能の証

>>365
大抵なにかしようとするとあなたみたいな抵抗勢力が生まれるよね。
既得権益を守ろうとしているからなのかな。
能力さえあれば残れるけど、その自身がないからかな。

完全にスレ違いだか面白いから続けろ
【営業】仲良く喧嘩しな【技術】
でスレ立てても面白いかも知れん

>>366　いや、だからすきにすれば？別にあなたの会社が中国人に仕事出そうがかまわないですが。まぁでもお客と中国人をつなぐ仕事だけはしたくないな･･･激しくストレスになりそう。

インド人プログラマとか結構高いっていうけど。
日本人より、お得なの？

>>366
一部の日本人技術者＋大勢の中国人技術者でうまく言くという目算があるんでしょ？
なら別にここで愚痴る必要ないじゃん？

彼らと一緒に仕事した技術者だから言わせて貰うが、
中国人の人と仕事したけど地味に間違いが多かったなあ。
全くの無能じゃないけど・・・。

日本的な仕様書ぽんと投げてうまくいくとおもわんなぁ。
個人的には最初は技術者の比率は1対1から1対2で仕事するのが限界だと思う。

ちなみに、北米の人を下請けに使った事あるけど、
それなりにしっかりした仕様書を作って、画面だけのプロトを作って
動作もシミュレートしてそれも含めて送ったけど、なんやかんや言いつつ、
30回位メールのやり取りした。
仕様書の間違いは無かったけど不備は必ずあるからね
当たり前だが向うからの指摘が多かった。

中国人はそんな優しい事しないし、リリース後あっさりさよならする。
正直、一日毎の進捗ととりあえず動くようになったら日本でﾃｽﾄ
をやって、問題あるなら延長出来るようしておかないと駄目。

つまり、管理だけじゃなくて技術検証とﾃｽﾄ班は最低限必要。
ついでに疲労が大きいので2セット位必要。
おまけにそれなりに有能じゃなくちゃだめ。

一番の問題は火噴いた時に管理の人間がやられて、結局
営業だけになり、管理も含めて○投げして足元見られる事。

つーか中国人と一緒に仕事した事あったけど、あいつらの生産性はゼロどころか、マイナスだったぞ。
目先の安さだけで仕事受けて失敗した典型的な例って感じだった。

国内の下請けでも仕様書ぽんと投げてうまくいくことなんてありえないと思うが。

>>371
人をうまく使えないのを相手のせいにする典型的な人はっけーん

おまえら、そんなことよりゾォーンの話しようぜ

結局の所、設計は評価するに値しないって事だよな。
だって、中国ならず日本人にも上手くいかない設計しか出来ないんだからさ。

どうして、話が営業云々になったのか知らんが、
少なくても営業を責める前に、設計能力を磨けって事だな。

ゾォーンはあの世とこの世の間にあるものなんだぞ

>>372
>国内の下請けでも仕様書ぽんと投げてうまくいくことなんてありえないと思うが。 

うまくいかないから、日本人同士だと打ち合わせするだろ？

中国人は打ち合わせできないので(数日毎に北京にいけるなら別だが)
変わりに、

>正直、一日毎の進捗ととりあえず動くようになったら日本でﾃｽﾄ 
>をやって、問題あるなら延長出来るようしておかないと駄目。 

をしなきゃならん。
仕様書投げて、メールのみで問題点の指摘とかが出来るなら別だが。

問題は、中国人は仕様書道理に作って問題点を逝ってくれない事なんだが。

>>376
そうできるようにルールを作れよ。

>問題は、中国人は仕様書道理に作って問題点を逝ってくれない事なんだが。
むちゃくちゃ言っているね。設計書としては最悪の部類だ。

>>376
なんか違う気がする・・・

＞うまくいかないから、日本人同士だと打ち合わせするだろ？
＞中国人は打ち合わせできないので(数日毎に北京にいけるなら別だが)
＞変わりに、

規模によもるけどさ、２・３ヶ月ぐらいだったら、製造終わるまで中国行ったら？
物価安いから、それでも利益でるよ。

＞>正直、一日毎の進捗ととりあえず動くようになったら日本でﾃｽﾄ
＞>をやって、問題あるなら延長出来るようしておかないと駄目。
＞をしなきゃならん。
＞仕様書投げて、メールのみで問題点の指摘とかが出来るなら別だが。

いや・・・
進捗管理とか受け入れてテストとか日本でも一緒でしょ。
自社開発だろうが他に出そうが。

＞問題は、中国人は仕様書道理に作って問題点を逝ってくれない事なんだが。

これが一番意味不明。
プログラマにとってみれば、設計書どおりに作るのが仕事。
問題点を言ってくれないというが、黒いものでも白だといわれたら、その通りに作るのがプログラマ。

だって、仕様書通りに作らないと『仕様と違うから作り直せ』って言われるし・・・
ハッキリ言えば、問題のある設計をした奴が悪いに決まってる。
上流工程のミスを下流のせいにするな。

>>378
>これが一番意味不明。
>プログラマにとってみれば、設計書どおりに作るのが仕事。
>問題点を言ってくれないというが、黒いものでも白だといわれたら、その通りに作るのがプログラマ。

コーダーじゃあるまいし、問題点あるなら指摘ぐらいはするのもPGの役割だと思うが？

理想を言えば、そりゃ問題点ゼロの設計書なんだが、そんなもんどこにも無いからなぁ。

ちなみに俺も中国人と一緒のプロジェクトにいたことあるけど、設計書通りに実装なんかしてくれないね。
自分の意見の方が正しいとか思い出すと設計無視で実装しやがるし。

自分が引き継いで仰天したことがあるよ。顧客の欲しい機能の大半が抜けてんだもんｗ
結局、俺が実装のやり直しをやった。おかげで突貫作業もいいところでバグを出してしまい、客先で
徹夜するわ、SEには責められるわで、いいことなんか何もなかったな。

オフショアをどうしても成功させたいのなら日本人的な仕事のやり方を理解してる中国人を間にかまさないと無理。

実際、その馬鹿PGに問い詰めたことあんだが、日本人が上なのは嫌なんだとさ。

権限の問題なんだろうけど、俺も設計書なんか参考程度にしか考慮しないよ

>>378に同意
日本の常識は海外の非常識

>>379は無能SE

>>380
> 権限の問題なんだろうけど、俺も設計書なんか参考程度にしか考慮しないよ
実装漏れとかよく起こらないなｗ
もしかして関数単位でしか実装しないクチ？

システムまるごと実装する事も多いから走り書きでも設計書はおこしてからやるんだけどなぁ
ま、詳細設計まで行くと実装した後でおこす事も多いけどね

正直、機能設計もやれてないのに実装するのは怖いよ
１０年ぐらいはやっててもそう思う

そういえば、作業の標準化って全然されていないような気がする・・・
実は無駄が多いんだろうな。

>>382
> >>379は無能SE

いいな、納品を保障する立場にない奴はｗ

というより、仕様の問題を伝えたくても、言葉の壁があると、チョッと面倒になっちゃうんだよな

>>384
> そういえば、作業の標準化って全然されていないような気がする・・・
> 実は無駄が多いんだろうな。

ユーザー単位で納品物が変わるから仕方なかろ？

一応、自社での書式は決まってるけど、他社と組んでるとどうしたって変動する

>>379
＞コーダーじゃあるまいし、問題点あるなら指摘ぐらいはするのもPGの役割だと思うが？

だったら、設計者なんて要らないよな？
もしくは、設計者自らプログラム書けばいいんじゃないの？

＞ちなみに俺も中国人と一緒のプロジェクトにいたことあるけど、設計書通りに実装なんかしてくれないね。
＞自分の意見の方が正しいとか思い出すと設計無視で実装しやがるし。

これこそ、『仕様書通りに作れ。作らなきゃ金払わない』って言えばいいだけだろ。

＞自分が引き継いで仰天したことがあるよ。顧客の欲しい機能の大半が抜けてんだもんｗ
＞結局、俺が実装のやり直しをやった。おかげで突貫作業もいいところでバグを出してしまい、客先で
＞徹夜するわ、SEには責められるわで、いいことなんか何もなかったな。

進捗管理や受け入れテストしてなかっただけだろ。

＞オフショアをどうしても成功させたいのなら日本人的な仕事のやり方を理解してる中国人を間にかまさないと無理。

なんで、中国人に任せっぱなしなの？
自分が中国語覚えて、製造終わるまで中国行けよ。

＞実際、その馬鹿PGに問い詰めたことあんだが、日本人が上なのは嫌なんだとさ。

能力無いからナメられるんだろ。
そういう奴は、同じ日本人でも上なのは嫌だと思われてるよ。

>>388
設計書に矛盾があって実装できなかったらどうすんのさ？

お前ら外は天気いいですよ?

たしかリクナビって中国発注で40億ぐらい火吹かせたんだよね

まあ、ぶっちゃけこういった色々ある問題点が中国人とお仕事を
すると魔女の鍋のごとく噴出すわけで・・・、

営業さん頑張ってね。

あれれ。設計書を書いたのとは別の人がコーディングするの？

仕様書には仕様が書かれてて実装方法は書かない、
設計書はソースコードの解説みたいなもの、という認識は間違ってるのか…？

まぁ、現場によって、基本設計書、詳細設計書、プログラム設計書などの定義が全然違うし。

基本設計書に実装すべきSQLが書いてあるとか、結構無茶苦茶だよ。

SQLの実装なんてパフォーマンスの程度でコロコロ代わるから
基本設計で定義しても意味無いんだけどな

そもそも複雑なシステムを理解する万人が認める記述法なんてないからね。

何だかスレタイの流れに戻ってるぞ
無能営業＝プログラマ挫折無能SEは逃げ出したのか。仕事と同じく無能ですぐ逃げ出すんだな。

設計書読みながらプログラム組むとイベントドリブン
とかスレッドとか同期処理についていい感じに無視して
書いている事気が付く。

まあ詳細設計書とか書いてる場合スレッドも一関数として
記述しちまうわけだが。

ポンチ絵の方がマシの場合があるという悲しい現実が・・・。

前ソースとUMLと設計書相互依存して書けるツール作ろうと思ったけど･･･つーか誰か作ってくれ。

>>397
あなたみたいに粘着気質じゃないからだろ

雑な設計作ったら
上司に2時間ぐらいみっちりと指導された＿|￣|○

>>401
ざまーみろ

受諾開発の現場では、技術知識がない営業のやるこたぁお客さんと仲良くなっておくことかと。
仲良くなってもらえばSEの仕事がやりやすくなるし。

んで、設計する時に実装考慮しないSEなんて存在価値あるの？
分からなかったら普通PGに確認するでしょ？

って言うか普通PG数年やった後SEになるだろ
プログラム組んだ事の無いSEとか有り得ない

プログラム経験が浅い内にSEにさせられるヤツはいる。
当然プログラム一本のヤツよりコーディング能力は低い。

本当にスキルのあるプログラマーはそのままプログラムさせておく方が生産能力は上がる。
余所に逃さないように厚遇するのは当然だが。

VBですらプログラム組めないSEなら知ってる

VBを例に挙げる４０６の能力が知れたな

PG経験が浅いか全くなくて、脳内アーキテクチャで設計するSEは結構多いな。
PGが「ここは無理です」って言っても「できるはずだ」「無理じゃなくてやるんでしょ」と、何でもできるはずだと思っている。
そして、本人にやらせてみると何もできない。上位クラスとメソッドの殻まで作るだけ。

>>408
それはお前にも原因がある。
無理な理由をきちんと説明しろ。
相手を納得させられないのはお前の能力不足。
人の非難をする前に自分を非難しろ。

できないものは実際作れないからいいんだけど、
実装は可能だけど変なものっていうのがやっかいなんだよな。
「無理ではないけど、作りたくない」とかいうと設計者すねるし。

だから論理的にわかりやすく説明しろって。
人間なんだからまずきちんと話し合えよ。

>>409
まぁ、俺の説明力不足もわかっているが、相手の理解力不足も感じる。
しかし相手は全てわかっているつもりで一歩も譲らない。
客が言ったことには「できない」ではすまされないという。
つまり、最初からできようができまいが「やれ」って態度だ。

とにかく、できないならできないと馬鹿にもわかるように説明が必要な設計者はごめんだ。
給料と権限同じなら馬鹿にも教える気にもなるが。

>>412
やれやれ。第三者からすればお互い様にしかみえんのだがね。

説明責任を果たさないならお前さんはただのコーダーだよ。

説明責任なんか労働者には無いよ
それは営業だろうが設計だろうがプログラマーだろうが業種には関係ない。
accountability　は　強者（権力・権利の占有者）が　権利の代償としての義務なのだから

>>414
はいはい、労働したことのないお馬鹿さんはアニメでもみててね。

>>363
アメリカのエンジニアの需要が伸びて年収800ドル以上が
当たり前だというのに中国人をとるのか。
それもどうかと思うが。
ソフトウェアの品質がどれだけ下がるだろうか。
CMMレベルが低くなるぞ。

>>349
> >>344
> ただの言い訳にしか聞こえない。
> 技術的に可能かどうかなんて優秀な技術者ならあいた時間を利用して調べて
> 数日内に返答くれる。少なくとも私はそうしている。

>>349にとって都合の悪いことはすべて言い訳扱いか。
文句があるなら、>>349の希望通りの時間内に返答をくれる優秀な技術者を採用すればいい。
それができないから2chで愚痴を零しているんだろ。
それ相応の優秀な技術者と一緒に仕事がしたいなら
自分がそれだけ分相応な営業にならないと駄目だぞ。
世の中ギブアンドテイクだ。
>>349はまだまだ不相応だから技術者は>>349に何もギブしない。

>>366
仕事にもよるが、既得権益を守ろうとしている抵抗勢力は
どうみても技術もわからない営業に見えるんだが。

この仕事は金あってなんぼの世界だ。
あまりにも安くし過ぎると安い仕事はだれも引き受けなくなる
エンジニアは金を多くとれる仕事を取りたがって当然。
そのためには自社開発でソフトウェアの品質を高めることだね。
営業には品質もソフトウェア工学というものも意識できない人が
多く本当にドカタ作業員と同じようなものだとしか思っていない人間も
未だにいることが不思議。
それだから耐震強度偽装問題に触れることになる。

>>416
なぜ、日本人より中国人が劣ると言い切れるのだろう・・・

そして、CMMレベルが低くなるのは、結局のところ設計した日本人SEやら
受け入れてストする日本側なんだから、日本人のレベルが低いだけのような気がしてならない・・・

ソフトに不可能は無いよ。ハードの制約だけがある。無理だって
説明するならハードの所為にするしかない。
















建前はね

>>370
最近日中関係が悪いからね。
日本に対して明らかに敵を密かに持ったまま日本人と
仕事をしている変な中国人も多いからね。
その影響かね。彼らは仕事よりもプライドを優先する感じが
中国共産党の名残があるみたいで何か違和感がある。

>>372
じゃ、お前が中国人を直接うまくつかってみろよ。
結局中国語しゃべれる奴の協力がないとお前も
何もできないんだろ？

つうか、中国語しゃべれないって人として終わってるよな・・・

なにせ、世界中で一番使われてる言語だぞ。

>>379
> 実際、その馬鹿PGに問い詰めたことあんだが、日本人が上なのは嫌なんだとさ。

ってかもろ日本人を見下したがってる魂胆が見え見えだな。
そんな態度丸出しで日本人と仕事を上手にこなせると思いこんでる中国人も痛いな。
そんなに日本人を下に置きたければ、中国で会社を起こして日本人を雇えばいいのに、
中国人にはおかしな奴が多いんだな

>>404
あのいくつかの大手企業ですら、
大学でたばかりの新人がいきなりSEなんて肩書きを
貰ってたりする。そいつらは今20代後半。

>>408
> PG経験が浅いか全くなくて、脳内アーキテクチャで設計するSEは結構多いな。
> PGが「ここは無理です」って言っても「できるはずだ」「無理じゃなくてやるんでしょ」と、何でもできるはずだと思っている。

営業でそんな奴がいた。「できるはずだ」と偉そうに言って。
顧客に「できる」と先にいってしまったために、なんとかしてできる方法を探し出さないといけなかったみたいだが、
どうみても技術的に不可能だとわかってそのプロジェクトは頓挫した。
もちろん顧客からは信用されなくなった。

そして営業は社内ではみんなの嫌われ者となった。
それからその営業はおどおどするようになってしまったよ。
いままで威張っていたのに

>>425
ちなみに、どの大企業よ。

○B○、N○○とかはそんな事無いぞ。

入社して1年は研修。
研修の最後に試験があり、それに合格したもののみがSEの道へ進める。
落第した奴はカスタマーセンター行き。

SEの道に進んでも毎年テストがあり、それに合格できなければ同じくカスタマーセンター行き。

ハッキリ行って、SEとして残ってるという時点でそれなりに優秀な奴しか残ってない。
中途半端な奴らはみんなカスタマー行きだからな。

>>409
無理な理由をきちんと説明し証拠を見せても
通じない馬鹿な営業もいるんだが。
馬鹿な営業は失言をどうにか撤回しようとして論理が破綻しているんだよな。

>>410
実装が可能であっても予算が足りるか、限られた納期で可能かどうか？
という問題をクリアできないことがあるんだが。
ハードウェアなどによる制限がなく、時間と予算が無限にさえあればほとんどのものは
そりゃ作れるんだが、予算も納期もろくに考えずに「できるはずだ」、と言い張る
営業は頭がどうにかしてるね。

>>419
> >>416
> なぜ、日本人より中国人が劣ると言い切れるのだろう・・・

劣るとはいっていない。給料と予算を見て差が出ていると言っているんだよ。
中国に委託した方が安くできるから中国人に仕事をさせると言っているんだろ？
日本人だと金がかかるし、
さらにアメリカ人に頼んだら日本人プログラマの平均年収を上回る
年収800ドル以上もの給料を支払わないといけない。



> そして、CMMレベルが低くなるのは、結局のところ設計した日本人SEやら
> 受け入れてストする日本側なんだから、日本人のレベルが低いだけのような気がしてならない・・・

なぜそんなに中国人を庇いたがるのだろうか。
あんたは中国系か？

>>420
可能にするためにどれだけのコストがかかるか考えて言っているのか？
コストを無限にかけることができるならそりゃあんたのいうよに不可能は無いさ。
だが現実には顧客のお金も時間も限られている。
だから限られた金と時間とでは可能だと思われた
ソフトを作ることも不可能になってしまうのだよ。

>>423
> つうか、中国語しゃべれないって人として終わってるよな・・・
> なにせ、世界中で一番使われてる言語だぞ。

中国人にとってはな。
だが残念ながら、今のところビジネスに於いて
中国語の需要は英語よりもあまりにも少ないぞ。
世界で一番使われているものが優れているかというとそうでもないし
個人では人気があってもビジネスでは人気がなく実用性も
無いというものはいくらでもある。
中国語は中国人が多いというだけで中国語人口が多いに過ぎない。

中国軍の兵士数がアメリカ軍を上回るからと言って
中国軍の軍事力がアメリカ軍の軍事力より高いとは言い切れないように。

つうか、ITだけでなく、製造業では殆どが中国をつかうというのに、
ビジネスの世界で需要が無いとはこれいかに・・・

不思議でしかたない考え方だ・・・

質の低いソフトウェアは中国に丸投げし
日本だけでしか作れないソフトウェアだけ日本人が作る。
たとえばTron関係とか日本人が発明した製品対応ソフトウェア、
あるいはソフトウェアそのもの、とか。

サムスン電子みたいな会社に、日本の技術をのっとられては
たまらないからね。ソフトウェアでも同様。
下手にTRONやSoftEther、RubyやSeasar2などの技術を
中国や韓国に乗っ取られては日本人はますますみな貧乏になる。

だから俺たちは特許を出願したり自社開発で著作権を表明する。
そしてライセンスに違反する中国人は厳しく処罰する。

>>428
俺、元IBM社員だが、そういう嘘つくのはやめた方がいいよ。

【IT】経費節約は15％にとどまる〜「アウトソース(外注)で60％」は大げさ？[05/05]
http://news18.2ch.net/test/read.cgi/bizplus/1146870651/l50

>>437
これはプログラマにとってかなり朗報に見えるね。
しかしアメリカだけの話か。
日本でもこの認識が事実となって多くの顧客に
伝わればいいんだけど。
さもないとさらにつらい目に遭う人がますます増える

>>さもないとさらにつらい目に遭う人がますます増える
大抵のつらい目にあった人は、だまって他の人もつらい目にあうのを見ている

>>438
詳細がわからないのでなんともいえないと思うが。
仮に最大６０％のコスト削減に成功しているところがあれば、
他でもそうできる可能性はあるってことだ。
その場合は経費削減がむりなのではなく、効率的な害虫利用方法がまだ確立していないって問題になる。

>>440
元々原価が酷くて中間マージンを絞れた可能性も見るべき。
この業界値札がバナナの叩き売りだからな〜。
元受と玄孫は3倍近く違うというケースもあるんで、それ考えると
６０％しかとも解釈できる。

＞仮に最大６０％のコスト削減に成功しているところがあれば、
＞他でもそうできる可能性はあるってことだ。
そんなことはとてもいえない。
可能性はあったとしてもとても実現できない場合もある。

>>440
どうかね。下請けのプログラマがあまりにも酷い労働条件に
憤慨して賃上げしたためにコスト削減がうまくいっていないと思われるのだが。

>>428
え〜
あんなテスト意味無いじゃん
これっていう奴には最初っから答え渡してあるんだし
女の子は点数別計算だし

経費削減60%位は規模や難易度それと顧客や開発でのキーマンの稼動状況によっては達成できるだろ
でも、それはレアケースであって一般的には無理だって事を理解すべきなんだよ

>>1は結構いいところを突いていると思う。

開発が失敗したとしても、どこに責任があったか、なんてのは切り分けしにくいのではないかな。逆にうまくいったとしてもどこが良かったかは切り分けしにくそう。
結局、全部PMの手柄と責任になっちゃうとか。

設計に焦点があてられたら、まず減点法しか思いつかないしなぁ。

そもそもジャップがＳＥやＰＧなんてできるわけないのに
ここ20数年無理した結果なんだよアメリカや中国、インドのように
俺らは頭がよくない人種だ（天才はいるが、他の国に比べて極端に少ない秀才も同じ）
もう、日本で開発なんてやめて国内はコンサル業務だけにすればいいのにそのほうが
みんな幸せになれるよ絶対に

>>447
で、句読点もまともに使えない君はどこの国の人？

シナじゃねぇの？

>>447
Are you Chinease?

>>447
ニーハオ！

中学生未満の英単語能力の >>450 がいるスレはここですか？

お前はチーズだ

ハーイ、ガイズ

Ｙｅｓ！　Ｉ’ｍ　Ｂｉｇチーズ！

アルファビルの Big in Japan

を思い出したじゃないか。

当時はあの曲はユニークで面白かったなあ

ザルだらけの設計書を書くからだよ！ヘボ野郎！

姉歯神姉歯神

ていうか、今までちゃんとした設計文書残してこなかったくせに、
あれこれこっちの出した設計文書にケチつけんなや、ハゲ。

そもそもテメーはそういうの見た事ねえだろうが、ジジィ！！


って言えたらなぁ・・・

設計よりプログラミングの方が評価されない。。。

客が設計書をレビューするところは設計が評価される、
レビューしない糞なところは
脳内設計でソースのコメントが設計書なので
プログラムのほうが大事

ハード・機械寄りのところは、どちらも評価されない。

日曜大工で九龍城作るような事を、平気でやらかす。

まだまだソフトはハードのおまけって感覚なのか？

企画担当の名言
「ソフトはただなんだからさー」

プラントとか作る場合、ソフトにかける金額は、設備関連に比べて
圧倒的に少ないからな。

例えソフトの出来が成功の可否を握っているとしても、それに考えが
回る人間が、上層部に食い込めない。

>>465
>プラントとか作る場合、ソフトにかける金額は、設備関連に比べて
そうかなあ？　携帯端末くらすになると１機能の作り込みに失敗する
と１億ぐらいすぐに予算超過すると思うが。

1億なんかたかが100〜200人月でしょ

>プラントとか作る場合、
に
>そうかなあ？　携帯端末くらすになると
ってのはどういう頭なんだろう。

ドカタ作業だろうが上流設計だろうが、害虫の俺の手取りは変わらん。
だとしたら、単純作業だけで日がな一日のんびり働いた方が得だわな。

せやのになんでプロジェクトの最難関ばっかり俺に押しつけるかなあ。
ン百人も社員おるくせに、まともに設計できるやつおらんのか。
そりゃあ、「とりあえずアイツに押しつけりゃＯＫ」って評価はもろとるみたいやけど、
給料にも出世にも全く影響ないんじゃー

>>469　環境変えるか、納得するか好きにしてくれ。

>>469
脳がスカスカになるよりはマシ…　　　　うわぁぁぁんん！！！！

鬱になってから、ニートか、現在脳みそ溶けきってます････
今非常に精神的にやばいです。もうこのままどこにもたどり着けない気がする。

ニートに先はないよ。第一、親の経済力が０になったら一体どうすんの？
同じニートでも、芸のあるニートを目指せ。　前向きにな。

>>472
死ねばいいと思うよ

「どうにもならなくなったら死ぬ」と決めているNEETもいるみたいだな。
その場になって政府に泣きつくとか抗議するとかはやめる方向でお願いしたい。

>>475
死ねば死ぬで金が掛かるからどうせなr

>>475
「こうなったら死ぬしかない」という人は
いざそういう状況になっても
「いや、こうすればすぐに復活できるから」とか言い出して
挙句の果てに「俺のせいじゃなくて○○が悪いからだ」となって
結局死なない法則。

>>1みたいな旧日本陸軍に見られる営業的な
考え方だと、後にとんでもない悲劇が待っているだよな。

無計画な国(企業、組織)はアメリカには勝てないって

>>477
まぁ、何でも人のせいに出来るからな。
そっちの方がらくだし。それも一つの負荷分散ってやつだ。

そういう馬鹿こそ死ねばいいのに

設計しか評価されない。

>>481
プログラマにしか、が抜けている

「プログラマにしか」を
「設計しか評価されない」のどの文節に差し込んでも
日本語としておかしくなる件について。

議題を却下します

>>483
応用力無さすぎ

>>485
と言っておけば日本語の拙さを誤魔化せるとでも？

>>485が中田の鬼パスが繋がらないことを
「受けてのレベルが低いからだ」と言って聞かない件について。

「ビーンボールを打ち返せ」と言っているようにも聞こえる。

「ピンコ立ちで打ち返せ」っていってないか？

外部設計とか基本設計というもので、参考となる良書にはどんなものがありますか？。
昨日、ジュンク堂に行って来たんだけど、どうもよくわからない。
状態遷移図とか、ＣＭＭとかぼんやり色々書いてある入門書はあるんだけど…

どれがいいのかな。演習問題付きの教科書ような、概念から実習まである本だと嬉しい。
ご存じの方いらっしゃったら、よろしくお願いします。

> 外部設計とか基本設計
UMLになっちゃうけど モデリングの本質 がいいと思うよ

>>490
最近はそういうのは無くなったな
メーカーに入るとそういうの有るんだけど門外不出な上に最近のSEさん読んだ事無いらしいし

>490
あ、ちょうどオレも今探してた。ほんとに無いね。
UMLじゃなくてもっとカチっとした手法を
学びたいんだけどなー。。。

>>491
ありがとうございます。
ちょっと見てきました。残念ですが、ちょっと私の求める物とは違っていますね。

>>493
手法というか、ＣＭＭみたいな管理の手法からも透けて見えると言えば見えるんですけど、話が大きすぎて。
日本人だから形から…てな訳でもないけど、ＵＭＬも一応は勉強してみたんだけど、やっぱり書き方だけだから。

外人の作った教科書は翻訳のせいなのか、どうも今ひとつ・ふたつ・みっつくらい合わないし…
難しいですね。
もし良書を見つけたら教えてください。

アナアナパタパタ

>495
ヒントの出し方にwrs

こんなのは？
http://www.amazon.co.jp/gp/product/4798101273/250-7784619-4431450?v=glance&n=465392

俺の能力を見抜いて、チヤホヤしてくれる人（会社）を探す。
チヤホヤしてくれたら、もう、すごい設計してやりますよ。
チヤホヤしてくれなかったら、場当たり的な仕事しかしません。

>>498
きっとおだてられて、たくさん仕事まわされるんだなｗ

同僚が作った成果物の抜けを見つけても
指摘するだけで代替案なんてすぐ言えるもの以外は言わない。
同僚に対して一々調べてまで代替案なんかださねーよ。
自分の仕事が遅れる。

「調査しろよ」といって強要するムカツク同僚なんかいるけど
結局同僚の甘えであって、それを引き受けてしまうと
同僚が楽をする選択肢を与えてしまう事になる。

そういうのは、お客様だけで良い。

> 俺の能力
証明して見せろ

って言われて、もう、すごい設計しちゃう?

>>500
人にモノ頼むことって無い？
俺は仕事でもプライベートでも人にモノ頼む事って結構あるんだよね。
それも「お願いね〜」って感じの軽いノリで。
これが出来る人、出来ない人っていうのが居て、キミは出来ない人でしょ？

世の中って見返りを求め、求められるものだと思うよ。

>>502
絶対に側に居て欲しくない同僚だ

>>502
お互いに助け合うという考えならいいんだけど、なんか利用しあうって匂いがして嫌。

>>503 >>504
おまいらそんなんじゃ、マネージャにはなれませんよ

なりたくないし、ならないし

でも歳食ったら結局マネージャでしか役に立たなくなる、ってのが今までの時代。
これからはどうだろうな？

それって請負の会社とかユーザーでも業務系のシステム作るときの話だよね。
そういうのじゃないもの作ってるところとか人っていくらでもあると思ふ
前あった人は45ぐらいだったけど半分経営者としてベンチャーみたいなことやってる技術者だった。あついひとだたーよ。

>>502
結局そうだよな。
なんのメリットもない人って友達いないから。
人間関係の勝ち組、負け組みってはっきりしてるよ。

>>502が出来ない人って損すると思うよ。

だからその損とか得とかってのが下品
いってる意味はわかるけどね。

個人の損とか得じゃないんだよ。
ビジネス的に見たときの個人のパフォーマンスという感じ。
すなわち人的資源としての自分の価値に影響するよ。

出来る人が下らない作業に集中しちゃいかん。

「くだらない」じゃなくて「他と比較して金にならない」が正しい。
ほんとにくだらないなら、その作業を無くす努力をしろよ。

>>512
自分の価値を上げるために他人の価値を下げるという事に気づかない
その思いやりの無さが、俺たちから見れば最高に下品で俗物に見えるって事だよ。

死ねや、カスが。

確かに、仕事が出来ないくせに人に物を頼む馬鹿は死んでいいけど、
出来る人が仕事を全部やるようなのは最悪だよ。

あとね。嫌なら断りなさい。

>>516　パワハラけてーい

>>517
そこまで言うならどうしたいんだよ。
はっきり言っておくけど、俺は下っ端だよ？

糞な上司いるならそいつの上司に報告するなりすればいいじゃない。
文句ばかりだな。

ここまで設計の話がほとんどないので、
どうやら設計なんてどうでもいいらしい。

つか、役にたたん設計書書く暇があったら
その暇使って技術なり業務なり勉強せい。

家事はどんなに丁寧に美事に成し遂げても評価されない。場合が多い。

>>520
もちろん、表舞台に表れにくいすばらしい仕事である。
家族が困ってなければな。

上司もそんなもんだね。
コンサルタントも。

コンサルなんて飾りです。　偉い人には分からんのです。

えらいコンサルならコンサルが飾りか、あるいは空気のように振舞わなくては
いけないことはよく知っている。しかし給料は取る。安いとありがたみが薄れるからな。

某企業は営業のことをコンサルと呼んでいる。
それ以外の人材のことはすべてSEと呼んでいる。

身分不相応にもこの板に立ち入った、薄汚いコンサル野郎が
必死なスレはここですか？

プロジェクトの結果に最後まで責任を持つコンサルには会ったことがないな。
みんな火がつく前に居なくなっている。

どういう状況でコンサルが責任を持つの？

まぁ、取り分は責任に応じた額にしといてくれよ

コンサルに金をかけないのはDQNでしょ。
高額を提示しないコンサルもコンサル。SI屋とでも呼んでやればよい。

安いお金とサービス満点のコンサルタントから発せられる言葉には
まったく威厳や感動や有り難味が感じられない。
そんな言葉を受け入れる人はいない。
安いコンサルを受け入れる準備も適当になってしまう。

コンサル？
DQNでしょ。

最近は偽コンサルを見抜くために、プレゼンに優秀な現場の技術者を出席させる場合が多い。
そのためコンサルは激減し、今はほとんど見かけなくなった。

ま、そんぐらいの数ぐらいしかいないと思うなー。
コンサルなんて目指してなるようなものじゃないし。

いつのまにか業務やコンピュータに詳しすぎるぐらいになったし
コミュニケーション能力もあるから開業してみましょう、っていう職業だと思う。

先日電車の中で人材捜しの会話を耳にしたのだが

コンサルやるやりたいとかいうやつはもうｲﾗﾈ
今は実際にモノが作れるやつが欲しい

という内容だったようだ

前後の流れや発言者の立場を知らないのであとは想像するしかないが

そりゃマネージャーも要らなくなるわ。

ピンハネしようにも、この国は人が減ってきてるしなｗ

外国人技術者専門派遣業とか、もしかして今時狙い目？

コンサルの存在意義をだれか定義してくれ

抱えてると原価少なめでボリボリ儲かる。

>>538
ゴロやタカリに存在意義などない。

>>540
と思うから聞いているのだが・・・

ふっつーに考えて企業体質の改善でしょ。
ずーっと一社にへばりつくコンサルはヘドロ。

馬鹿を正しい方向に振り向かせるのは非常に難しい。
なぜなら物事の正しさを説明するだけではダメで、
彼らを動かすには権威が必要だからだ。

コンサルって言うのは権威を借用（偽造）して馬鹿を正しい方向に導く職業。
権威を全く信用していない下流工程の知性あるPGにとっては全く不可思議な事に思えるだろう。

俺も不思議だ。

>>543
>なぜなら物事の正しさを説明するだけではダメで、
>彼らを動かすには権威が必要だからだ。
能力不足なだけじゃね？

>権威を全く信用していない下流工程の知性あるPGにとっては全く不可思議な事に思えるだろう。
その前提どこから？


夏だなｗ

コンサルはクズ。　証明不要の絶対的な真理。

なんかコンサルを否定したいだけの人がいるような…。

俺にも否定するだけの価値しかないように見えるけど、
価格対性能比で言うとね。

コンサルは高い以外ありえないよ。
安いコンサルはいなくていい。一般社員にでもなってろ。

>>543
的を射てる。


上の方のレスを蒸し返すようで悪いけど、
この業界で真の「協力関係」はありえない。
元請けと下請けの立場で銭の関係がハッキリしているにも関わらず
何が協力だよ。更にこの業界は何社もの下請けが集まり、
ひとつのプロジェクトとなり物を作り上げるのが普通。
そういう中で仕事してて、相手への思いやりだとか本心で思ってるやつ痛い。本質的に無理。
契約更新で単金うｐ出来るかどうかが死活問題な状況で他人のことを思いやるなんて
戦場を理解してないもいいところだ。自社で囲ってるなら仲良くしな。
それ以外ならば上っ面で偽りの関係でいるべき。信じて痛い目に遭う前に。

本当に心を開けるのは家族と恋人にだけだよ。
他社混在プロジェクトで心開こうものならすぐに餌食。淘汰される。気付け。

>>549
>下請けの立場で銭の関係
下請けがそんな事言い出したら仕事こなくなるねｗ

>相手への思いやりだとか本心で思ってるやつ痛い。本質的に無理。
「思いやり」はないが出来るだけやりやすい環境を用意するのが、上に立つ人間の仕事だろう。

>信じて痛い目に遭う前に。
信じるのと管理する事は別なんだぜ？

>本当に心を開けるのは家族と恋人にだけだよ。
淘汰対象　m9(^Д^)ﾌﾟｷﾞｬｰ!

とりあえず >>1 でFA

>>551
動くものの定義が人それぞれだがなｗ

>>551
>>1の状態で作られた物を改修してみればわかる

システム会社っておかしい頭のヤツ多いよね。
変なところでキレて2時間くらい怒り狂って怒鳴ってるやつとか。
失敗くらいで怒るなら、そのエネルギーをリカバリに費やしたらいいのに。
だいたい失敗したくらいで怒るやつ理解できない。
反省して改善するかどうかは当人の問題なのに、他人がどうこう言うことじゃない。
もうちょっと余裕持って生きろよって言いたくなる。

とにかく、システム系で怒ってるやつはバカで仕事できないヤツ多いよ。
3クリックくらいで元に戻せるようなミスでイチイチ怒り狂うなって。

10年やってきたけど、やってらんないもう辞めて独立するわ。

>>554
10年やっててそんなミスすんなｗｗｗ
つか10年コーディング・・・

・・・ｶﾞﾝｶﾞﾚ

怒ってるやつに言いたいね。
このミスがどれくらいの損害になるのか数字で教えろ。って。
ミスの影響さえも数字で把握してないヤツに限って感情モロ出しだよ。

本当に数字抑えてるやつは利口だから、怒る時間があったら、
どうにか取り戻そうと既に次の行動してるから。

そうすると、「まあいいよ、大したことないから気にすんな」
なんて余裕の労いの言葉かけられる。
更にそういう人は人望もあるから、人が集まる。
この人に迷惑かけたくないなーってなる。良い循環だよ。


勘違いしてもらっちゃ困るけど、俺は別にミスして怒鳴られたわけじゃない。
ただ、周り見てて思ったからさ。

>>556
感情モロ出しだよ。

まあ10年やってて、>>554 の1行目だもんな。程度が知れる。

>>554,556
( ´Д⊂ヽ 　涙で前が見えないよう

評価されました。

>>560
おめでとう

>>560　　　　　　　

　　 ／￣＼　　なんという良設計…
　　|　＾o＾　|　　クラス図とER図とアーキテクチャを見ただけで勃起してしまった
　　 ＼＿／　　このアーキテクトは必ず伸びる

ER図すら知らないのにアーキテクトの肩書き持ってるやつ見つけたｗｗｗ

DFDすら知らないのにアーキテクトの肩書き持ってるやつ見つけたｗｗｗ

それはイタイ・・・

別に知らなくていいだろ。
知ってなきゃならない！って決め付けるのが馬鹿。
そのアーキテクトなりの方法論で実績あるんだからさ。

知らないと恥ずかしいレベル

オレ様方法論は・・・いらない

マグロ専門店の親父でも鮭のオスメスの区別の仕方くらいは知っている。
知っているけど使わないのと知らないのは大きな違い。

そりゃー、くそ設計でも良設計でも
マの腕ひとつでどうにでもなるからな。
ＳＥの評価は設計フェーズで客の要求をどれだけ拾えるかだろ。

>>570
あんた明日から仕事しなくていいよ。
邪魔。癌だよ癌。

俺は>>554の意見に激しく同意。

>>570
>ＳＥの評価は設計フェーズで客の要求をどれだけ拾えるかだろ
そうだね、やったことないからわからないよねｗ

俺も>>554に同意。

怒り狂う人って、そのミスが何で「いけないミス」なのか
説明できないんだよな。ミス＝悪　みたいな頭なんだよね。
ミス＝犯してしまうもの　って考えができないのかな。
その人がバグ出したことないなら素直に従うけど。

>>570

拾いっぱなし？
それを設計には反映させんのか？
てか、くそ設計でも良設計でもマ次第ってんなら、
全部マに任せちゃえばいい。

その流れが既に出来てるんだが。

アジャイルでつか？

設計に問題がなくても
作る人間のレベルが低くて実現できない、あるいはパフォーマンスが出ない。
結果、仕様変更や設計見直しなんて笑っちゃうけど現実にはしょっちゅうある話。
そのまた逆も然り。
だから俺はマ次第じゃないかと言ったんだがまあ別意見の人もいるだろう。

自分でコードを書かない人が携わるのは
要求定義とＵＩ決めるぐらいまでがよいと俺は思ってる。
それ以上は実装者には足かせや障害になることの方が多い。

>>578
UIっていつからコード書かなくて良くなったんだっけ？
あなたは50年後の人ですか？

>>578
> 自分でコードを書かない人が携わるのは
> 要求定義とＵＩ決めるぐらいまでがよいと俺は思ってる。

はぁ？コード書かないやつがそれ以外の何をできるんだw

>>579
おまえの考えてるUI設計ってなんだよ。
フォームにコントロールをぺたぺた貼り付けることか？w

要求定義って一言でいってくれるが、それなりに専門知識が無いと難しいぞ。
ナンチャッテＳＥには無理。

要求定義って本来客がするものだろう？
なんで該当業務ド素人のSEなんかがやるんだ？

http://www.borland.com/jp/company/news/press_releases/2006/20060712_caliberdefineit.html

>>582
仕事じゃないから判らないよねｗｗｗ

要件をまとめる事だと。。

>>580
俺の言い方が悪かったかもしれない。
普段コードも書いてるＳＥでたまに設計だけやらせると
設計書に余計なことまで書くんだよ。
>>582
客の窓口が情シス部門だと客がまとめてくれるみたいね。そんな経験ないけど。

要求定義は客が出来る場合もあるし、一緒にやる場合もある。
まあ、客の要求を鵜呑みにするのは死の行軍に第一歩だと思うが。

つうか、要求があっても入れる入れないの判断するだけだろ？
コストを考えろ馬鹿

これだから日本のベンダーは。ｗ
要求の取捨なんて要件定義・分析じゃねーよ。
そもそもの業務分析と改善があってこその要件定義だろうが。

素人ばっかｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>586
おまえ真性の馬鹿だろ？仕事やめたら？いや、まじで。
設計書に余計なこと書く？何のための設計書と思ってる？
書く人にとって余計なことが、読み手にとって余計ってわけじゃないだろ。

設計書のあるべき姿は、人が読んで正しく理解できる形だよ。
何言ってるかって？誰がその設計書読むか考えてみろよ。
その設計書をもとに作業する人にあわせて設計書の内容を書くべきだ。

>>591
586じゃないけどさ・・・ちゃんと読もうぜ
話はそれからだ

いやまじで、>>591みたいな勘違いちゃん職場にいっぱいいるよね。
ホント疲れる。

「いやまじで」はやってんのか？

流行ってるよ。いやまじで。

>>595
まじではやってんのか。いやまじで。

いやまじで流行ってるよ。いやまじで。

フツーにはやってるよ。いやまじょで。

>>598 あーあw

うちは
１．客がやりたいことを示した「要件定義趣意書」を出す。
２．こっちがそれをシステム化するとこーなる、という「提案書」を出す。
３．ヒアリング
４．こっちが各機能の概要を示した「要件定義書」を出す。
５．客先レビュー

でかいプロジェクトだとこんな感じなんだが、
みんなが言ってる「要件定義」ってのはどこのことを言っとるの?

１〜5

仕様書作成までの前段階で、
これから作成するであろうシステムについて
言及するもの

>>601-602
じゃあ>>582とかっておかしいよな。
客は業務のプロだがシステムのプロじゃないわけだし。
机上の空論だけで要件定義FIXされたら
設計・開発フェーズで「こんなのムリ」ってことになるかもしれない。

ていうか、そもそも客の9割はどんなシステムが
欲しいのか、必要なのか、わかっていない。

当たり前の話。

コンプライアンスの観点から開発に携わらないメンバーがコンサルするのが良いが
コンサルのほとんどが開発する観点を一切もたない(or理解できない)のが現状

>>605
そんなコンサルなら直接客に骨折ってもらった方が良い気がするが

>>605-606
今サルの話題は要らない

美容師見てみろ。
客の俺らがグダグダな要求突きつけても
なんとか髪切るだろ。俺らがどう切りたいか決めてなくても
美容室行ったら美容師がアレコレ聞き出して切ってくれるだろ？
要は同じだ。何もこの業界に限った話ではない。

>>605
そういうコンプライアンスとか聞くたびにウンザリしてくる。
それを遵守しない場合に比べて大きな利益を獲得しているとはとても思えない。

でも、嬉々としてそういう『大人ごっこ』をやりたがる連中がいるんだよなあ。

さーて、設計事務所立ち上げようかなぁ。
製造はその辺のゴロツキに回して。

すみません。僕がその辺のゴロツキでした。反省してます

>>610-611
どこがおもしろいのか・・・
笑い所を教えてくれ

>>609
コンプライアンス遵守ってのは利益云々というよりモラルの問題なんじゃ?

コンプライアンスの意味わかってていってんのかねー。
守らないとﾀｲｰﾎだよ？w

>>613
会社を失うと言う長期的にみて最も大きな利益の損失を防ぐ為だよ

といっても実際摘発は進んでないような。
正直者が馬鹿を見る感じ。
これがビジネスかよ。

小泉　「（貧民だけが）痛みを伴う改革」
アベシ「頑張った者が報われる社会に！（完全成果主義）」

　　 　 /　　　　　　　　　　　　　　　 /　 　 　 ﾞi,　 ヽ 　
　　　 j　　　　　　　　　 　 　 　 ,ｨ／　 　 　 　 |　　|
　 　 lｨ'　　　　　　 　 　 　 ,ｨ／j/　　　 　 　 　 |　iﾘ 　
　　　|　　　　　　　　 /l ／　　　　　　　　　 '"` |　j 　
　　　ﾘ!　　　　　 /,ノ　　　　　　　　　　 _,､-''''` /ﾘ 　　 小泉だ
　　 　 |　　 _.._　l/ 　 ,.--;==ﾐ ､ ___,.ﾉ /{.○-ﾞ‐rV 　　 私の「痛みを伴う改革」は大成功だ
　　　　ヽ,/｀ヽヽﾄ､　´　 {,.○-`‐‐ ､,.-ﾄ|　　　　,ﾉ 　　 痛いと感じるのは貧しい人間だけだからな！
　　　　 ∧　　ﾞi, 　 `ヽ,r'´　　　 　 ﾉ.　 ﾞ､--‐''´|　　　 団体の支持と富裕層を味方にできれば
　　 ,,.く　 ヽ 　 ﾞi　　 　 ヽ､ __,,､-'" 　 　 〉　　 /　　　 ヤツらの血税でウマー!!!
ﾊ'´　　|　 ﾞi　　 |　　　　　　　　　　　'　' 　 　 iヽ'"￣
ﾞ､ﾞi,_r'ｼﾆZ`ｰ┬ト'i　　　　　　　＿＿＿__ ,　 |　　＼
　　 _ﾞV　　ヽ,.レ''ヽヽ　　　　　`ー─''''"´ 　 /
　／./ ヽ／　　　　 ,」ヽ　　　　　__,,､-─‐-､j
　　/ r'´　 --‐‐'''"´ ヽ ＼　　 （.r‐'''""ﾞﾞ`ヽ,｀)　　　　 　　　　　　　今の議員は
　 l .|　　　　　＿_,,､--`ヽ ＼ ___ヽ　　　　 /´|　　　　 　　　　　　　　　　　　　　まさに　　”　吸　　　血　　　鬼　”
　j　|　　　　　　　　　　 ,⊥`ー ､　ﾞ!　　　 レ' |
|　 |　　　　　 　 -‐''"´ 　 ヽ､⊥ヽ|　　　 |彡'|

>>615
コンプライアンスを遵守しなくても
極論を言えば、バレなきゃ会社を失うことはない。

よってコンプライアンス遵守というのはモラルの問題。
利益追求が使命の企業はモラルを失いがちなので
国がチェックし、ペナルティを与える。それが法律。

俺以前設計だったけど評価されてたよ？
給料も社長の役員報酬と同額だったし。
乗っ取られて社長が交代したら出来もしない仕事を詰め込んでくるようになったんで辞めたけど。

>>619
ばれたらやばいからコンプライアンスなんだろｗ

やっぱ中国人は頭悪いな。

>>622
韓国人には勝つよ

営業はもちろん作ったヤツも評価されるぜ
バグだらけのコピペだろうと検収上げりゃな

そのメンテやらされるヤツと設計は評価されない。
節穴管理者は死ねよ