「細かいことはわからない」と言うSE

実は大まかなこともわかっていない。

>>1
って言われつづけて１０年なんだろ（ｗオマエが

わからないのにわかると言うSEよりはまだマシかと思われ

んだ。「わかんない」いってくれる人はありがたい。
1でageを入れるよりまし。

>>1
ちょっとﾜﾛﾀぞ

PGの方で実装内容を完全に把握していれば、問題ないだろ。

現場から問題点が伝わって来ないのはもんだいだろ。

SEってようするに金の計算してるだけじゃん。

>>7

現場から問題点が伝われば問題ないだろ。

情報死すテム板荒らそうぜ！

>>10

どこにあるの？

>>6
んじゃSEいらないじゃん

>>12

工数管理・ユーザとの折衝。

お前らが上流工程までしっかり管理して
ちゃんと提案あげれば、おれらだって承認
してやるぜ

↑誰？

もうSEって言うなよ。
営業か、現場監督っていえよ。

仲介屋

現場監督はプロジェクトのリーダじゃないかな？

>>13
工数の管理じゃない。工数の確保がSEの仕事。

そもそもSEって何よ？
という展開になる悪寒

システム設計だろん

実際にはSEに期待されている仕事ってのはSE以外の人が
やってるケースがほとんど。

SEいらないと思うよ。正直。
事務系の中間管理職と、雑務のおねーちゃんと、テスターさん
を専業化してくれれば。
PGのリーダーがPG全体で話し合った結果をまとめて仕様を
策定していけばいいだけだし。
客の要望は営業が聞いてくればいいんだし。
工数の見積もりもPGのリーダーから営業が聞いて客に出せば
いい。
むしろ間にSEが入るから勝手に「できます」と言ってみたりして
ややこしいことになるんだから。

>>22
同時に走るプロジェクトが全社でそれ１つだけ、なら、それもアリだが…。

>>23
なんで？複数できるんじゃないの？

「設計」できないエンジニア　

セールスエンジニア

Special Engine

実は大まかなこともわかっていない。セールスエンジニア

>>1 するどい　さえてるねえ

そのうえにほんとに何もわかっていないけどプライドだけが超一流のコンサルが鎮座しておられます。

新人にいきなりSEやらせてる会社があったが
結果はボロボロだったな

新人にいきなりコンサルティン愚やらせている会社があったが
結果はボロボロだったな

新人にいきなりPGやらせている会社があったが
結果はボロボロというか、むしろスパゲティだったな

>>31
会社によっちゃ本当にそうなんだよ。
社内で「開発」って工程がないんだから。
開発やってんのは外注。
トラブった時に費用が大きくぶれるから、リスクヘッジの意味でも開発は外に任せるのが吉。
なんて、実際にはそのリスクを引き受けられないような技術力のくせに SI を名乗っているのが間違いだとは思うが。

>>32
そういうヤツラはそういう環境で育つので、
20代後半で稼ぎに見合った仕事をするようになる。

>>33
しっかり育ててやれ。

新人にいきなり溶接させている会社があったが
結果は５秒で部品がバラバラになったな

SEが成果物として作成するものを考えると、やはり必要な職種だと思われる。

あー、そういうＳＥに当たったら納品物件まで作らされるからやだー。
大抵伝えて来る仕様が滅茶苦茶で、物作りに時間がかかるのに、
資料まで全部こっちに依存してくるんだもん。
給料泥棒なら辞めちくりと思ったよ。

新人にいきなり手術させている病院があったが
結果は5秒で5体がバラバラになったな

お前ら、SEの重要な仕事が理解できていない。
SEはお客を接待するという重要な役割を担っているのだ。
SEはPGの胃と肝臓を命を削って守っているんだぞ。
ちゃんと覚えておけ。

>>37

そのSEは、どのような成果物を残しているの？

>>39

そうだよね。私もそう思うよ。
もちろん、ダメなSEがいることも事実だけど。でも、それはダメなPGがいるのと同じことだと思うけどね。
過去の経験から言うと、ダメなPGがいても先輩PGやSEがフォローできる。でも、ダメなSEの下では、優秀なPGも空回りするだけ。

　 ∧,,∧　　　SEってなんで"書類"とか
　ミ,,ﾟДﾟ彡　　"仕様書"に執着するんだろうね。
　ミつ日(ﾐ
　つか。執着するのはシステム自体について
　理解できないから、自分の仕事が書類にしか
　ならないからなんだろうけどなぁ。

　それを押し付けてくるのがウザイっす。

　プログラム仕様書かけっていうから書いたが
　モマエの思い描いているのと違うからって
　起こるなよ。気に食わないのならモマエ書けよ。

　いまどき、「ﾌﾛｰﾁｬｰﾄとか書いた事あるの？」とか、
　あきれさすような発言は頼むから辞めてください。

>>41

別に良いじゃん。
単なる製造要員じゃないんだからさ。
プログラムのUIとか、処理の流れぐらいなら参加すると思うけど。
仕事の中心がドキュメント作成なのは、当然だと思う。
システム自体を理解するのがPGの仕事で、それをユーザに理解できる言葉で表現するのがSEの仕事だと思う。
言葉を変換するのは、PG・SEの共同作業だと思う。

>>42
＞システム自体を理解するのがPGの仕事

違うだろ。
それこそSEの仕事だろ。

＞ユーザに理解できる言葉で表現するのがSEの仕事

これは営業だろ。

営業なんて自社の主力パッケージの機能さえ理解できないぜ。
（某外資系ベンダ）

>>41
関西にある会社か？
俺も前にそんな会社で働いた。
「こっちが求めてるのと違う。やり直し」とか言ってくるんだよな。

内部設計書を「素人でも分かるように説明しろ」って
当たり前のように言われたよ。
設計内容を「それでは、フローチャートで説明してください」
と経験10数年のヒステリーばばあが言ってた。
C++だぞ？それだから糞設計しかできないんだよ。

普通、素人に分かるようにするのは要求仕様だろ？
フローって・・・処理系の動作を考慮してないのな。
VBだってフローじゃかけねーよ。

しかし、書類や仕様書に拘るのは悪くないぞ。
プロジェクトが破綻したときにPLのサイン入りの仕様書と
変更依頼全部を上に出してバカを追い出せたし(w

　 ∧,,∧　　最近は外注業者ﾀﾝが以前と180℃違って
　ミ；ﾟДﾟ彡　まともなﾚｽなのでﾋﾞｸ-ﾘです。
　ミつ日(ﾐ　　

ちょっと口調が強すぎたっす。
>仕事の中心がドキュメント作成なのは、当然だと思う。
うん、それはそう思うんだけど、

執着というか、自分の仕事に対してこだわり。
誇りを持つものという対象を

システムに求めるか・あるいは・ドキュメントに求めるか、

って選択肢だと、ちゃんとした仕事をするつもりがあるなら
PGにしてもSEにしても、システムに求めてくれ
って事がいいたいんす。
SEだとしても、たとえコードを直書きしなくても
自分が書き上げたドキュ(ｿ)メントに対してコダワリもつのではなく
自分の仕上げたシステムにコダワリをもってもらいたい。

システムに関するドキュメントってのは、
プレゼンテーション資料ではないんだから
あくまでシステムそのものの
2次生産物というか副産物でしかなりえない。
そんなものに、コダワリを持たないで欲しいと思っている。

＞システム自体を理解するのがPGの仕事で、
これをSEが理解していないと、
とんでも仕様なシステムが作られていくよ。
(世間の大半で、今も行われているんだと思うけどさ。)

>>40
今は組んでないけど、当時は基本設計書（Ａ４３枚）だけだったにょ。
フェーズ２以降、詳細設計書からテスト仕様書から全部私が作ってた。
Ａ４を３枚持って客に行かされた営業が胃に穴開けた。
客先への技術説明には私らＰＧも同行させられた。
納品関係書類とかは当然営業。
上に渡す工数管理表は作ってたような気がします。

そんな私は派遣ＰＧ。時給２０００円ですた。

>>39
客先に行って交渉してきてりゃ、３年経っても恨んでたりしてまへんがな。
私は胃に穴開けてその派遣先リタイアしたですよ。
だから日●系の会社って嫌い。

下流工程をなめてるSEにかぎって、上流工程もできてない。

大声で他人に聞こえるように「〇〇はつかえねえ！」とプロジェクト
メンバーについて偉そうな評論してる管理職がよくいるが、無能、迂闊、
無思慮を自己宣伝している行為だと気がつかないのでしょうかね…

・無駄に回りの社員に不快感を与えている。プロジェクトマネジメント
の重要なファクタであるモチベーション管理について何も考えていない。
・話題の対象が本当に使えないなら首にしろ。権限がないのにそんなこと
をいうのは無駄。業務中にそんなことやっているのは馬鹿。
・話題の対象から恨まれる。怨恨は人生のリスク要因。
・切羽詰った時点(=今)までほっといたことが本人の無能の証拠。
利口な奴ならもっと早くに対処しているはず。

…数えあげればきりがない。

同種のヤツに「（言語、特定のツールなど）はつかえねえ！」という
PGがいるな。

>>50
痛い目を見るまで本人はそれに気づかないだろうな〜。

>>42
システムを理解せずして、何が「システムエンジニア」か。(w

>システム自体を理解するのがPGの仕事で、
>それをユーザに理解できる言葉で表現するのがSEの仕事だと思う。
>言葉を変換するのは、PG・SEの共同作業だと思う。

上記の事項は、全部SEが単独でもやれないとまずい。
システムの設計をするのに、
作ろうとしているシステムを理解していないなんて、ゴミもいいところ。

>>43

それは現場ごとの考え方だろ。

>>45

私も、「単体試験の項目を誰が見てもわかるようにしろ。」って言われたことがある。
少なくともユーザに見えない部分なのに。
とりあえず、現状では私に詳細設計書のメンテナンスが任されているので、開発者が困らないような書き方をすれば良いことになっている。

>>46

そうだよね。
ちょっと前まで、基本設計書の中にテーブル名とかカラム名とか抽出条件を当たり前のように書いてあった。
恥ずかしいので、詳細設計書を新設し、そっちに移行した。

>>47

うっさい。私は2chに参入した当時からまともだ。
何に対してこだわるか、などというのは抽象的だ。具体的にどういう弊害がある、という次元で発言するべき。

>>48

うわー
そのSE、本当にアホだね。
少なくとも、システムの目的とか機能分類ぐらいなら設計段階でも書けるはずなのに。
30歳以上の生産性低いオヤジをSE待遇にしておくことも問題の原因なんだろうな。
逆に言えば、みんな歳をとれば衰えるのかもしれない。
私の周りのSEは、大半がしっかりしているけど。

>>50

それって、自分の影響力でどうにもならないから、愚痴として言っている、ということだろうね。
上から命じられた人員配置でうまく切り盛りするスキルがないと、そうなると思う。

>>51

前の上司は、クビを宣告されて気付いた。

>>52

PGがシステムを理解して、SEがうまく聞き出す能力を持っていれば良いと思うが。
うまく聞き出せないとすれば、PGがシステムを理解していないか、実装がわかりにくいか、どちらかだろう。

歴史的に見ると、ただ単に一人ですべてこなせないから分業体制をしいただけ
ＳＥ，プログラマ、コーダ、テスタ、オペレータみたいな種類に別れ、それぞれ
スキルレベルで区分けしていた。はじめのころは規模も資金もでかかったから
それでよかったと思う。職種でわかれている会社で、よくもめるなら、分担を
きちんとするよう、会議体を作って新しい状況に対応する提言などをしてみたら
どうだろう。ＳＥとＰＧの関係がギクシャクしてちゃ、いいシステム作るのも
大変だろうし。ぼろがでないのは、だれかお人よしががんばってるんだろうね、
多分。

>>56

このスレッドで愚痴を言っている連中は、そういう話し合いをするスキルに欠けていると思う。

外注業者 ◆PVCAbsPHPEのSEとPGの定義がおかしいと思うのは俺だけ？

>>57
コードを書けるﾔｼであれば、スキルの問題ではないと思われ。
口下手でもよい提案は受け入れられるのでは？根回しが悪いとか本質的
でないところにも気を配るとか。ＰＧがもし手を打とうと思ったら
適切なＳＥを選んで、まずは飲みにいくことだね。え、酒はのまない？
ううむ、お汁粉屋へ誘うとか、おえ。

だからSEという言葉をもうつかうな。
アナリストとアーキテクト、現場監督（Ｗ）に分けろや。

>>60
ＳＥ→｛あなりすと、あーきてくと、？｝
現場監督は別のカタカナ名称きぼんぬ。統一したいでんな。
職掌範囲は定義できそうかね？
ＰＧはＰＧなのかね？

システム開発に落とす前に業務システムの改善もしなくちゃぁ。

某電機会社のＳＥは本当に馬鹿ですな。
俺もその某電機会社系の仕事をしていますが
技術よりも飲み会や人間関係を重視しますな。
なんかみんな上司のために仕事をしています。
開き直って作為的に人間関係に力を入れ始めたＳＥもいます。
新人時代の意気込みはどこへいったのやら。

>>63
上司のための仕事をする→上司がいいこになる→下へおこぼれが回ってくる
→給料アップ→ＰＣがチューンできる、うまい酒が飲める、など
こうなってほすい

システムを理解していない"システム"エンジニアってのは
間違ってるだろう・・・

>>62
>システム開発に落とす前に業務システムの改善もしなくちゃぁ。
これが一番重要だよね。業務を改善する為に、システム開発するもん
だと思うから。そして、それが難しい。
業務的な視点とシステム的な視点で、うまく妥協点を見出せる香具師
が良いSEだとおもうんだけど。

>>66
たしかに業務分析していると企業風土や慣例などで
業務フロー自体がおかしい場合が多々あるな。
このような業務をシステム化すると絶対苦情がくるんだよなー。

>>66
だから日本でSAPが儲けられない。

>>66
本当はそうなんだけどさ、
日本人の悪い癖で、業務そのものを改善したがらない企業って多いよ実際。

そんな状況でも営業は仕事とってこなきゃならないし、SEもその業務フロー
でシステム設計しなくちゃならない歯痒さがある。

>>68
SAPが儲かる＞＞業務改善
なのお？

お客さんがやりたいことを聞くだけが要求分析じゃないよ。
その時点でお客さんの本音や、業務において本当に困っていることを聞くのも
要求分析の一つだと思うのだけどね。実装するか否かは予算次第だけど。

この本音の部分を聞き出すためのコミュニケーション能力。
PGのおまいらにはありますか？
お客さんは本音の部分をなかなか喋らんぞ。また、本音の中に重要なことが隠れていたりする。
# こういうお客さんと、こういう本音を聞き出さないSEによってデスマへと・・・。

>>68
SAPはそれなりに儲けてるだろ。
SAPをカスタマイズして納める連中が赤出しやすいのと、
納めさせた連中が、全然効率の上がらないシステムに金だけ取られるのが問題なんじゃん。

業務改善？なしでSAPが使えるなんて思うなよ〜。＞顧客＆ウチの営業

>>72
SAPを利用する側がSAPを理解してないってことなのかな。
SAPを過大評価しているからこういう事になるのかもしれないね。

>SAPを過大評価しているからこういう事になるのかもしれないね。
違う、本来SAPは業務改善も含めてシステムとして成り立ってる。
それなのに日本じゃSAPを業務にあわせてカスタマイズするのが多すぎ。
そんな国、日本以外にないって逝ってた。。。

>>74
へぇ〜。正直SAPには関わったこと無いんだけど、そういう事だったのね。

>それなのに日本じゃSAPを業務にあわせてカスタマイズするのが多すぎ。
これって、SAPを導入するところはSAPに合わせる部分も出てくる、ってことなのかな？
これが日本で受け容れられるかどうかはちょっとギモンだよねぇ。

>>71
>PGのおまいらにはありますか？
自問はＯＫ。ＳＥとしての発言なら、役割分担をわきまえぬ世迷い言。
ふつーの人間はその立場にたてば、そこそこなことができるもんよ。
ま、まともなＳＥなら連携プレーが大切なことをわかっているから、いい
ＰＧには相応の敬意を払って当然だよね。これもひとつのシステム。

なんにしろパッケージはパッケージ。
それですべてＯＫということはほとんどありません。
業務をパッケージに合わせられるならしやわせだけどそうじゃないこと
もあり。なんでもかんでもパッケージってのはどうだかな？
使うときには長短あわせた説明をすべきだよね。

>>75
>これって、SAPを導入するところはSAPに合わせる部分も出てくる、ってことなのかな？
カスタマイズなど一切せずに業務を合わせるべきだったはず。
ただし、SAP *Japan*がそう言ってるかは知らない・・・。

>これが日本で受け容れられるかどうかはちょっとギモンだよねぇ。
それは確かにそうだ。そこまで考えてSAPは導入するものなんだが・・・。

>ただし、SAP *Japan*がそう言ってるかは知らない・・・。
なんか、ジワジワと面白かった！

SAP入れるから業務ワークフロー変えろと言うと、
情報システム系の部門 vs 営業・企画・契約管理系統の部門の間で
もめそうだなぁ。

トップの判断が必要になってきそう…

漏れが今関わってるお客は、
情報システムに関して権限を持ってるｵｻｰﾝが社内で結構偉いらしくて、
あまり>>79みたいな問題にはならないみたい。

でもSAPはやってないけどね。
（この判断が正しいという考え方もあるのかな）

>>80
所属の強さが逆だと大抵うまくいかないんだよねぇ。
漏れは逆のパターンが殆どなんだけど…

>でもSAPはやってないけどね。
ウホッ！っとワロタ。

客側の担当が複数いてしかも仲が悪いのか全員一度にそろわない・・・
話はバラバラ。。。もういやっ！

>>82
>客側の担当が複数…そろわない
それは…イヤだなー。

もう少し大きなパワーが必要な感じがする。
担当者を取りまとめている役職に鶴の一声を頼まないと
多分、なーんにも決まらない悪寒！

age

何で読んだか忘れたけど、（多分、初級シスアドに関するものかな？）
「業務を変えることが出来るのはお客さんであり、外部の者（つまり我々）が
変えることはできない。また、変えようとしても、エンドユーザーを動かすことができない」
と、いうような趣旨のことが書かれていた。
で、漏れの思う最高のSE像
「業務を変えるように、お客さんを動かすことができること」
>>83のいう鶴の一声を頼むことができるように、SEは動くべきだと思うな。
つまり、SEはお客さんの会社の顧問が出来るぐらいのスキルが必要。

スマソ・・・。飛躍しすぎた。

漏れの場合、偉いｵｻｰﾝ（正確には数人いる）に「うん」と言わせれば、
誰も逆らわない。でもって、何が起きても問題にならない。
全てはそのｵｻｰﾝｽﾞが責任を負ってくれる。

でもなかなか「うん」とは言わない。
物事の決定に時間がかかる。
SAPをやらないのも、そのｵｻｰﾝが保守的だからかも。

>>85
大体おなじような考えです。
これができるのは場合によっては営業職かもしれませんが、
営業職だけではポイントを押さえた確認ができないことが多いと思われ。
SEはこのへんに力を入れないと、SEの設計はいつまで立ってもあいまい
だということを意識して行動すべきかな、と。

>>86
うんと言わせるためには具体的な費用対効果が見えれば
いいんだけど、元を取る前にシステムのライフサイクルが
終了するケースも沢山見てきたのでやはり客のｵｻｰﾝたちも
慎重になるだろうなー。

質問ですが、配列がぎりぎりわかるくらいのレベルの僕がプログラマーの会社に受かりました
自慢じゃないですが、スロットマシーンのプログラムを組めます。参考書があれば。
そんな僕はこれからやっていけますか？また、ＳＥになれますか？

>>89
「細かいことはわからない」というSEにはなれるかもね♪

うう、マルチだったのか。つまらん。

スレタイの意味は理解しているつもりだけど、
「細かいことはわからない」というＰＧの場合、どの程度なら許されると思う？

PGの場合、「全体がどうなってるかわからない」じゃね？

なんだかよくわからないと言うPG

「わからないことがわからない」というPG

>>93
別問題としてそれもあるけど、
役割的にＰＧはどこまで知ってりゃいいのかってことだよ、
下流工程の範囲で。
制御系以外だとＷｉｎならＤＬＬまではあんまりつくらないだろ

わかったフリして作っちゃう奴が一番質が悪いと思われ。
わからないと言ってくれりゃまだましだよ。＜ＰＧの場合

>>96

・このシステム全体は何のシステムか（大雑把）
・自分が参加しているサブシステムは何の処理をしているのか（大体）
・自分が作るモジュールの仕様（しっかりわかっとけ！）

って所かと。

そこそこいいスレだったんだが、この辺をマネージするのが
コンサルの責任なはずだが、みなの周りのコンサルどもはどうですか？

うちはさっぱりなんだよなぁー。不満な点を書き出してくれ。

コンサル見たことないし…。
どこにいるんだろう？？

>>98
そりゃ自分の職掌範囲だね。それすら把握できてない、という問題提起か？
でもＰＧはＳＥに対して細かいこともある程度は理解するべきだ、と考えて
いるわけだろ。じゃあ、ＰＧはどうなのかな、と考えるわけよ。

>>100
○○総研とかいう穴蔵から這い出して来るんだよ。
背景に合わせて自分のカラーを瞬時に変えるから、なかなか見れないかもね。

コンサルを一匹見たら３０匹はいるな。

はぁ、、、なにがなんだかさっぱりだよ。＞先週渡された仕様書

外資のコンサルもかなり醜い。

基本的にPGはSEから言われた仕様通りのプログラムを組めれば良い訳で、
だからこそSEにはシステムをしっかりと把握してもらわないと困る。

社長はSEの設計とPGの設計の区別がつかないYO。
要件定義と基本設計した仕様書わたされて、詳細設計してたら
基地外のように怒ってた…。社長の設計が悪いのをPGの俺が
手直したと勘違いしてた。

こんさるってちょっとなー、ってことが多いのは何でなんだろうか。

バカで社長でSﾖな香具師の下で働いてるのか・・・

顧客と「なあなあ」で話してるだけで上流工程と勘違い。
実装フェーズを見下し、実装のことなどほとんど考慮してない設計を成果物と豪語。
実装時にすぐに破綻する糞仕様。
破綻する度に行き当たりばったりで変更し、更なる副作用を招く。
それをなぜかプログラマのスキルのせいにする。

こういう自称SEに心当たりありませんか？

>>110
あるよ。
だから次の時、糞仕様にダメ出ししたら切られちゃった(w ← 派遣PGかよ！
そいつも、しばらくして会社から切られたらしいけどな。

>>110
そこに、体育会系のノリで後輩は問答無用・絶対服従が加われば最強。

>>112

いるよね。
そういう上司にひどい仕打ちにあった。
でも、クビになってくれた。

>>113
こちらへどうぞ

http://pc.2ch.net/test/read.cgi/prog/1056410421/l50

>>112
そういう人間て本当にいるけど、
どういう精神構造をしているのだろうか？

そういうやつに言ってやりたい。
「せめて、人間らしく」

>>114

うっさい。

SEと呼べるヤシさえいない日曜プログラマの集まりですが何か?

>>110
今までに見たSEの大半（7割以上）がそうでつ。

　　　　　　 　 　 　 　 　 　 　 |
　　　　　　 -―-　 　 　 　 　 |
　　 　 〃　　　　　 ヽ　　　　 .|
　　 　 i　　 ノノﾉ)）) )）　　　　|　コンピュータのお仕事が好きなんですか？
.　　　 i　i （ 'ｌ_]　l]〈ﾘﾉ　 　 .＜
　　 　 ヽヽ ＞　 ／>　　　　　　＼＿＿＿＿＿
　　　　　Y/ヽ!ｪl〉　　　　　　　　/ヽ/ヽ
　　　　　 !!　l卯 l　　　　 　 　 / // /
　　　　　　ｉ　ll8| !　　　　　　 / // /
.　　　　 　 l　l「| l 　 　 　 , ´-‐ ‐- ヽ
　 　 　 　 /!_」l|_j､　　　　{　　 ｌ　,,　 }　ぅん
.　　　 　 / /ﾞ´l"ヽ >　　　ゝ.　‐　　ノ
　　　　　'ｰr‐ r r ´　　　　　　 l　!
.　　　　 　 l　 l. | 　 　 　 　 　 |　|
.　　　　 　 |　 ! | 　 　 　 　 　 l.　|

　　　　　　 -―-
　　 　 〃　　　　　 ヽ
　　 　 i　　 ノノﾉ)）) )）　　 ／￣￣￣￣￣
.　　　 i　i （ 'ｌ_]　l]〈ﾘﾉ　＜　でも、ソースコード書いてるところ見たこと無いです。
　　 　 ヽヽ ＞ ｎ／>　　　 ＼＿＿＿＿＿
　　　　　Y/ヽ!ｪl〉　　　　　　　　/ヽ/ヽ
　　　　　 !!　l卯 l　　　　 　 　 / // /
　　　　　　ｉ　ll8| !　　　　　　 / // /
.　　　　 　 l　l「| l 　 　 　 , ´-‐ ‐- ヽ
　 　 　 　 /!_」l|_j､　　　　{　　 l 　 U }　……
.　　　 　 / /ﾞ´l"ヽ >　　　ゝ.　っ　 ノ
　　　　　'ｰr‐ r r ´　　 　 ⊂ニl　!
.　　　　 　 l　 l. |　　　　　　　　|　|
.　　　　 　 |　 ! |　　　　　　　　l.　|

>>1
コレが口癖の香具師が昇格しやがった。
昇格するのは勝手だけどSEじゃなくて保守営業やらせろよ！
香具師の仕様で仕事する身にもなりやがれ！

みんな、まさかSEにコード書いてもらいたいと思ってるわけじゃないよな？
＞分業体制しいているPG

http://homepage.mac.com/hiroyuki44/hankaku10.html

>>121

さわんな！あっちいってろ！

きっとこれだけだろう。

漏れはSEという名の慰安要員。PGに気持ちよく稼いでもらう。
でも給料すこし多くもらってっからしょうがないかな。

>>123
かなり安心
>>124
多いと思ったらPGへ還元しろよ。

>>124
漏れは管理職という名の邪慰安要因。SEを気持ちよくこきつかう。
でも給料だいぶ多くもらってっからあたりまえだな。

>>126
リストラされねえようにな。
気配りは自分を助けるって言うぜ。

http://homepage.mac.com/hiroyuki44/hankaku10.html

うちはPC系の開発部隊ですが・・・
汎用機出身の正規化って言葉をご存じ無いSEが昇格した。
コードが書けなくても、設計が糞でも、
要望が歪んで伝わるから打合せ他の人でって客先から言われてもいいんだ！

>>129
頼む、もう少しわかりやすい日本語で書いてくれ。

>>129
私はＰＣ系のＡＰ開発部隊なんだけどよ・・
汎用機出身で、正規化という言葉を知りもしねえＳＥがＰＬに昇格しやがった。
コーディングもできず、システム設計も糞で、
要望が間違って伝わるから、客先から打ち合わせ他の人きぼんぬと言われてもいいのかよ！俺は悩む

以上、通訳ｗ

>>131 ｸﾞｯｼﾞｮﾌﾞ

ＳＥにＰＧがやりやすいような環境を作っていただくにはどういう方法が
効果的だと思う？
プロジェクトタイプだとメールのＣＣは全部投げておく。コーディング上
影響の少ない部分についてＳＥの意見を取り入れ、参加意識を高めてあげる
などが考えられるが。最終的にうまくいかせるのには、てことだが。
だめだ､といってそうか、そこは直そうってなＳＥならいいんだけれどねえ...

>>129
俺が今やってるシステムも、正規化どころかSQLも満足にかけない
人がテーブルの設計やってるから、ひどいことになってるな。

ペアプログラミングならぬ、ペアプロジェクトリーダを推進中。
相性がよければいいが、最悪の場合、「船頭多くして・・・」状態に陥る。
ただし、相性がいいからといって、同じようなタイプをペアにすると相互補完にならない罠。

>>135
PLではないが会社のトップ二人が非常に仲悪くて一般社員が迷惑してます。

となりの部屋にいるのに20km離れた部署経由の伝言で連絡取り合うなよ・・・

>>133
ちょっと似てるがやり取りはすべてメーリングリストにしてだな、
ログを保存しておくと。

「そんなこと言ったっけ」ととぼけたらログを示して「ほれ！」

>>134
漏れが今やってるシステムのSEはテーブル設計
の前に画面レイアウト作ってるぞ。

んで、画面にある項目でテーブルを作っていく
んだとさ。

も　う　だ　め　ぽ

詩が先か曲が先かって感じですな

http://homepage.mac.com/hiroyuki44/hankaku02.html

つーか、要素技術理解してないやつはＳＥと呼んでるものにさせるな。
以上。

プログラムできないＰＧがＳＥ。

　　∧,,∧l||l　 　
　 ミ,,　　彡　忙しすぎて
　ミ　　 ∪　　細かいことがわからないどころか
　,と,,と,,,) 　　大まかな所も、何もかもわからな.....




　　∧,,∧　ってか、
　 ミ,, ﾟДﾐ　人生そのものがよくわからなく
　ミ　　∪　　 なってきた。
　,と,,と,,,) 　

>>143
それでもイｷﾛ

SEが客先で自分の知らない技術用語とか出た場合の決まり文句

「すいません、勉強不足なもので…」

つーか、勉強する気なんかねーくせに何言ってんだか。
移動中にマンガ読む暇あったら、コンピュータ雑誌のひとつでも読んどけ。

「知らん」って言える香具師ならまだいい。
うちのSEにせめてそう言える勇気があればねぇ・・・（泣

わからないことをわからないといえるやつは、まだいい
むしろ見込みがある

>>147
分からないのに分かるフリをして安請け合いをして、挙句の果てに
どうにもならない時点になってから「やっぱりダメでした」という
ヤツは、社会生活不適応者ということで業界から追放してほしいね。

自分がわからない = 誰にも出来ない

と思い込んでるｱﾌｫもいるぞ。
簡単な客の追加要望に「それはシステム上無理ですねー」と
答えやがる。
会社の技術力が疑われるから辞めて欲しい。

>>149
俺が去年まで勤めてた会社、まさにそういうSEがいたっけ。

一言聞いてくれりゃいいのに、自分が具体像つかめないからって
見積もりもできない（やろうとしない）し、勝手にハイリスクだとか
決め込んで、取れる仕事もみすみす逃していた。

しかも、客先の担当者に「うちの会社は技術力が低いので…」
とか平気で言うらしい。もうｱﾌｫかと。

>>150
なんかウチの会社の香具師にもおったな･･･そんなのが。

>>134
テーブル設計の前に画面レイアウトというのは、間違ってもいないぞ。
もっと正確に言うなら、画面の入力と表示項目は決めるべきだ。

業務フローを決めたら、いつの時点でどのデータが揃うべきかが決まる。
画面の入力項目、表示項目、投入される外部データをもとに、テーブル設計ができる。

俺ならオブジェクトモデリングが先行して行われているはずだが、
そのあたりはUnified Process信者のやり方だから、まあ人によるところ。


> 画面にある項目でテーブルを作っていく

その結果が1画面1テーブルだったら目も当てられないけど。

>>152
そっか。。。
業務フローが決まれば画面の入力項目、表示項目が決まるというのは納得。
その後にテーブル設計しても話が前後するだけで本質的には変わらないもんね。

となると、変なところはテーブル設計を画面の項目を拾い集めるだけで
終わりにしちゃうところだけになった。

> その結果が1画面1テーブルだったら目も当てられないけど。
そういうシステムも見たことあるけど、今回は違いまつね。
正規化してないだけかな。

書き忘れた。
153==138ね。

顧客の要望はDBのﾃｰﾌﾞﾙより画面の方に現れる。てか

画面をある程度イメージさせて要件を出させたほうが、顧客も考えを出しやすい。

ただ、あまりにきっちりした資料なりハードコピーを作ってしまうと、
　「そこのフォントをもうちょっと大きく…」
　「ボタンは揃えてよ」
などと、議論の本質を離れていってしまう。

それをがっちり抑えこんで「いまは項目の議論をしましょう」と言えることが大事。

>>152
> テーブル設計の前に画面レイアウトというのは、間違ってもいないぞ。

？
画面レイアウトとかそんなことはオレは言ってないが。

> 画面の入力項目、表示項目、投入される外部データをもとに、テーブル設計ができる。

っていうか、設計の方法論以前の問題じゃね?
正規化を意識してないとか、SQLを理解してないとかって。

もう、あれだ。157は馬鹿、ということで。こんな奴も居るんだなぁ…。

>正規化を意識してないとか、SQLを理解してないとかって。
コーダーが方法論とか言うなよ。
アナライズやモデリングの時点で正規化なんか意識しねーよ。
コーダーは言われたとおりコーディングしてろ。

モデリングって基本的に正規化せんか？

http://homepage.mac.com/hiroyuki44/

>>159
下流の工程ができないのに、上流の工程ができるのかすごく疑問。
「モデリングツール」と称してるお絵かきツールで、線引いてるだけの
SEってよく話題になるよね。

>>159
お前はこの業界から去れ。話にならん。

>>162
疑問も当然だが、ある程度、普遍化観念化できるから下流工程の熟知は
必要ない。ただ評価基準がないと結局、指摘の通りお絵かき。

◆◇◆◇　海外サイトだから安心無修正　◇◆◇◆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html

　↑　
ココは丸見え！　今ならまだ消されてないよ。たぶん・・・

しかし「正規化」を知らないレベルのSEは、テーブル設計なんて下流の
工程は下々のコーダーに任せて、モデリングツールでもいじっていて
ほしい。

mspaint.exeで充分

　　　　　　　　　　　　　　　　　　　 　　 　 i⌒i　　　　　　　　　 i⌒i
　　　　　　　　　.　i ヽ　　　　　　 　　　 r‐|　〈　　　　　　 　　　|　〈　
　　　　　　　　　.　 |　i　　　　　　　　　　|/ .フ. 　　　　　　　　 / .フ
　　　　　　　　　　　し　ヽ　　∧＿∧　 /　 | ヽ　　∧＿∧　 /　 | 　　　　　
VB房って　　　　　 ＼　 ＼（　´_ゝ`）/.　 ﾉ 　 ＼（´<_｀　） /.　 ﾉ　　
　すぐ熱くなるね　　　＼ 　ヽ　　　　i　　 | ＼　　ヽ　　　　i　　 |　　　脳みそたりねーからな
　　　　　　　　　　　＿|￣ヽ 　 ＼∩ノ　　ﾉ |￣ヽ 　 ＼.∩ノ　　ﾉ 　　　正規化って言葉覚えて有頂天になってるよ
　　　　　　　　　　　＼￣￣￣￣(::)(::)￣ ＼￣￣￣￣(::)(::)￣ .＼
　　　　　　　　　　　　||＼　　　　　　　　　　 ＼　　　　　　 　 　 　 ＼
　　　　　　　　　　　　||　 ||￣￣￣￣￣￣￣|| ||￣￣￣￣￣￣￣||
　　　　　　　　　　　　||　 ||￣￣￣￣￣￣￣|| ||￣￣￣￣￣￣￣||
　　　　　　　　　　　　 　 .|| 　 　 　 　 　 　 　|| || 　 　 　 　 　 　 　||

>>168
そのAAキモイ。

ここのPGってホント現場知らないっていうか下っ端なんだね。
コーディングレベルの話ししかできないんだ。
てか、下っ端すぎてコーディングすらさせてもらってないのかな？
がんばれよクズども。

>>170

下っ端が上の人の悪い点を指摘するスレッドだろ。
昨日、SEが障害の現象と原因を混同していた。ユーザに説明する障害事象で、SQLの内容云々を書いていた。情けない。
しかも、別の現象もあって、2現象とも同じ原因に由来していた。
そのことを指摘しても、「どっちも同じだから。」と言われてしまった。
実際にコーディングする2年目坊主には、こんなおかしな説明を丸投げできない。私が現象と原因を切り分け、きちんと手書き資料を作成した。

今、私が読んでる機能仕様書

　１．○○機能
　２．××機能
　３．△△機能
　　：
と、延々と機能名が羅列してある。

でも、その「機能」とやらでどのような仕組みを実現したいのか

　ひ　と　こ　と　も　書　い　て　な　い

マジで「機能名」が羅列してあるだけ…

で、書いた人に「何ですか、これ？もしかしてまだ作成中でしたか？」って聞いたら

「これは『オブジェクト設計』ってやつだ、システムを機能毎に分割したのだ」といわれました。

この「機能名」(だけ)からプログラムを作るのが、私の仕事です。

わかりません、ほんとすいません、なんもわかりません
まじでぜんぜんわかりません
なにをしたいのかさせたいのか
もうありとあらゆることすべてわかりません
かんべんしてください

>>172がすごいことになってるのであげ。

>>172
それはSﾖが勘違いをしている。
そういうのは『オブジェクト設計』ではなく「エージェント設計」と言うんだ。
オマエがエージェント(代理人)として代わりに設計をするんだよ。
まあ、がんがって呉れ給え。


そうそう、それってまたの名を丸投げ設計って言うんだ。

仕様を教えてくれと言うSEが私の会社には居ますよ

>>172
コーディングするときは
関数名だけを羅列するんだ！

「自分で考える、自分で責任を取る」という、人生の上で必須であろ
う超基本的スキルを、小学校時代あたりにどこかにおっこどしたやつ
って、なんでだかイッパイいるよな。
そんなヤツラに給料払うの無駄だからクビにしてほしいにょ。

あと「相手に分かるように」文書化するとか、話すとか、
そういうことがﾃﾞｷﾅｲやつも多いな。なんでかな。

>>172のSヨの得意げな顔が目に浮かぶ。
きっと鼻の穴ひろげて、「オブジェクト設計」とか言ったんだろうな。

で、本当のオブジェクト設計ってどんなことをするんでしょうか？

>>180
まあ、そのSヨのやったことを物凄〜く好意的に解釈すると、
それは「ユースケースの抽出」にあたるかもしれない。

そこから、各ユースケースを分析し、再帰的により細かい
部品オブジェクトを抽出していって、最終的にソースコード
のクラス構成の基本となる構造をひねり出すのが、SEがやる
べきメインの仕事。

文書をそもそもちゃんと作れないやつもいるな。
てにをはの使用法がひどいとか。
ドキュメントをExcelで書いて、無駄に全セルの罫線が印刷されているなど文書の体をなしていないとか。

経験が是正してくれるかというとそうでもない。
そもそも「他人に気を使う」という考えがあるかないかの違いだけなんだと思う。

それができる人とできない人では、すべての物事に対する処し方が違ってきて、
すべての選択局面で積み重なって、
最終的なアウトプットが雲泥の差になるのだろう。

ユースケースと機能はまったく異なるぞ！
>>181 は好意的に解釈してやる必要はない。
何をしてるんですか、ハア？と問い詰めるべき。

失礼、風呂入ってました。
さっきまでのイライライライライラx100が無くなってちょっと楽になりました。
なんか、脊髄反射系のカキコで申し訳ないっす。

ココは「細かいことは分からない」って言うSεに囲まれてる人だらけのようなので
上記のような「目次しかない仕様書」を見たことある人いるかな？と
思ってついやってしまいました。

なんちゅーか
仕様書はWORDで作成されてます。で、表紙とか改定履歴のページを
飛ばして「目次」を表示。
目次のページ番号のとこをクリックして
仕様の本体部分に飛んだら、また「目次(みたいなの)」が並んでた…

修行が足りんのかもしれませんが、ダメージ大きかったです。

「他人の役に立つように、粉骨砕身、自分の能力をフル稼働してことに
あたる」って、やったことない奴結構いるんじゃないかな？

大抵の人にとって、くだらないことが多いであろう人生の中では、
比較的面白い作業なんだけどね。

馬鹿管理職オヤジどもは、そういうの忘れちまったかもな。

レスどうもです。

ちゅーか、「氏ね」とか書かれてたらマジ泣いてたかもしれないような
精神状態でした、ヤバかったです。

>>172
がんばれ。
機能一覧って、要件定義書にもなっていないぞ。

要件定義書の作成主体は顧客。SEが助けてあげることはあるかもしれないが。
そのSヨは顧客側作業さえも満たしていないのだよ。

でも、Sヨに少なくとも反論してあげられる程度の知識は >>172 も身につけたほうがいいかな。

>188 要件定義じゃなくて要求仕様だろ
要件定義まとめ上げる顧客がどこの世界にいるだ？
しったかPGめ

状況や言葉の定義次第でどうにでも変わるどうでもいいことに
噛み付かなくてもな

しかし、元請ってなにをしているんだろ？こんな糞なことだけはするけど、
いうことは、開発なんてだれでもできる、おれらはソリューションを考えるんだ！

おまえら何様なんだ？？？？？ばかな漏れにわかるようにおしえてほしい。

>>191
喪前らに仕事を与える側、つまり支配階級でつ（ｗ

>>192
その支配階級の仕様書を書いてくれ。どんな機能があるのか。

なんでSE板はないの？
あったら面白いのに

>>193
・金を出す。
・理解不能な言語を用いて仕様の断片らしきものを垂れ流す。
・納品物に文句を言う。

クライアントと変わらんね。

>>194

情報システム板があるけど実質業界板と化してる・・

プ！

ここは負け犬の集まりでつね。


悔しかったＳＥになればいいのに・・・。

あ、なれないのか。

バカだから。


プ！

何処を縦読みでつか

悔しかったＳＥに
悔しかったＳＥに
悔しかったＳＥに
悔しかったＳＥに
悔しかったＳＥに





プ！

これまた難しい要求仕様で

夏、か…

>>197
俺の会社はお前らのような糞会社じゃないので、SEなどいません。

俺の会社の階層は、以下のようになっている
クラーク < エンジニア < シニアエンジニア <<< アーキテクト <<<< フェロー <<<<< エバンジェリスト

昔はフェローまでだったのだが、俺の上司が会社を辞めると言い出してエバンジェリストができた
ちなみにクラークは、庶務のおねえさまのことです。

階層「だけ」しっかりしている会社の悪寒

>>203
社長がイギリス人で男爵の称号をもっており、階級にうるさいのです。

入社の面接で、俺はショーグンの家系だと社長に言ったら、おもしろいからお前は採用だと言われました。
でも社長は将軍のことをあまりよく理解していないようで、ニンジャとショーグンではどっちが強いのだと聞いてきました。

あいつはもう家に階層（帰そう）

>>205
サンキュ！
今日は蒸し暑かったのですが、おかげで涼しくなりました

>>204
ああそうか、よかったな。スレ違いだからｶｴﾚ

>>204


変な会社！

プ！


脳内会社でつか〜〜〜？

プログラマー＝人間のクズ


いや犬の糞！

いつかはＳＥに・・・・・






お前らにはなれねーよｗ



ププーー！

元気なのは面接の時だけ





あとは死人。




急にトーンダウンしてんじゃねーよ！



ビデオに撮って流してやりたいな（ｗ

友達のいないさびしさが伝わってくる。

｢難しいバグが・・・｣



お前はいっつもバグバグいってんな。


デグレなしでバグ潰せねーのかよ。


つーかほんとは寝てんだろ。


この給料ドロボーが！

行間２行あけるのは規定に書かれているのか？

仕様書を水増しするテクニックかな。作文の成績悪かったから。

喪前らは友達も


彼女もいない。


結婚もぜってーーーームリ！



能無しで不細工。



おまけにウ・ソ・ツ・キ。


かたつむりをプログラマーにしたほうがまだマシかも。

ﾋﾟ!

子供は早く寝なさい。

1時間ごとに休憩してんじゃねーよ！


おまえらには集中力ってものがないのか？


ほんとはこの仕事好きじゃないんだろ？


他にやることがない。


それだけだよな？


ていうか、しょうもないＴＩＰＳひけらかしてんじゃねーよ

ＳＥに言われるがままに開発するのが

どれほど楽かお前らにはわかってねーだろ。

疲れ自慢してんじゃねーーーーよ。


それはな、

能力の無さ自慢に過ぎねーんだよ。


本当に疲れているのは

お前らの尻ぬぐいをさせられてるＳＥだ。

よく覚えておけ！

自分で書けばいいのに。

風俗嬢の話ばっかしてんじゃne-よ

バーカ

日本人プログラマーという存在はこの世に要りません。

あなたがたの職業はもうすぐなくなります。


単価が安くて優秀な人材はいくらでもいます。

海外に。

>>222
既にSEも海外の人を使ってますが、何(略

あ、もっとも向こうの人はPGもSEもプログラマで統一だそうですけど・・・。

柱の繋ぎ目の構造もわからないでは建築家はやってられない。
細かい処理の構造もわからないではSEはやってられない。

>既にSEも海外の人を使ってますが、何(略
わざわざ海外から人雇ってその下で働いてる
おまいらって素敵すぎる。
おめでとう！

>225
なるほど、じゃおまえさん達は
クギくらいそこそ打てる大工で
犬小屋くらいなら一人でもつくれる。
だがそれ以上となると、
やはり言われたとおりクギを打つことしかできない。

細かいことには意見を言えるが
全体に対しては全くわからないので何も言えない。
ってとこだろ。

おまえらみたいの腐るほどいるよ。
犬小屋作って自信つけて、
おれはプロかもしんないなんて勘違いして、
そんな仕事ばっか何年もして、ますます勘違い。
で、まともな仕事ふられると身の程をはじめてしって
鬱病、自律神経失調症なんかのご立派な病気になって
会社辞めていく。

偉そうに言うからには仕事できるんだろ？
設計も。
だったらやれよ。
上司に「設計やらせてください」って言ってみろ。

>>227みたいな煽りは無視するとして。

>>225
分割統治、抽象と詳細の分離、層への分割。
デベロッパといわれるやつは、これらができないといかんのは事実。
「細かい処理」は設計の時点では考えないわな。
(考えなきゃならないとしたら、設計粒度がまちがってる)

コレなぜやらんかなあ、と思うことが多いのは、業務モデリングとデータベース設計を分けること。
業務モデルは、要件定義で作成するもの。
データベース設計は、定義された業務モデルを受けて作るもの。
データベース設計しかやらないやつが多い。

もしかしたら *結果として* 両者は同じ構造になるかもしれないが、どちらも実施するべきだ。
業務モデルはアプリケーションの抽象なのだ。
データベース設計はシステムの実現方式の設計なのだ。

「石鹸やらしくくだたい」

ﾜｰｲ　ﾜｰｲ


設計やれるならやってみろ！ＹＯ！

で、228の経験は？

伝言ゲームしかできない小学生以下の思考力のＳヨのいるスレ。

>>232
いつも伝言が正確に伝わってこないんですよ〜

「せっ○○やらしてください」

折檻やらしてください、か

ああ、思わずやりたくなる時もあるな

>>235
ｶﾜｲｲ女の子が入ると折檻とかしてみたくなるよね。



実際は親切にしちゃうんだけどね・・・漏れってﾀﾞﾒﾎﾟ。

そんな犯罪ギリギリな事すんなや。
ネチネチ説教して言葉攻めくらいにいとけ。

>>228

>>227、(ﾟзﾟ)ｲｲﾝﾃﾞﾈｰﾉ?
なんで煽りとかいうかな？
図 星 だからだね（ぷ

>>228
喪前みたいなノーリッパな脳内理論家はゴマンといるよ（ｗ
実務ではたいしたことできんのだろ？

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

細かいことはわからないとゆー、大まかな事も把握してないＳＥと、
機能も把握してない営業なのに、
ン千万〜ン億の契約とってくる・・・ある意味凄いと思う。
でも、いつもどっかかんか訴えてやる！って激怒してる顧客がいるけどナ（苦笑

>>241
騙されて発注する奴も責任あるわけだからな。

今いっしょに仕事してるヤツが、まさにこれ
「細かいことはわからない」

その後、こう言う
「ま、いいや。とりあえず、やってみて」

俺、Fuckin'外注としていろんな所で、いろんな人と仕事したけど
こんなに嫌な気分で仕事したの初めて

ある意味、運がいいのかね

>>241
そういう顧客からの怒りがそのままｺｯﾁ(技術)に来てます・・・
でもね、ウチは輸入代理店みたいなもので仕様はｺｯﾁが決めてるわけじゃないのよ
営業さんがちゃんと説明すればいいんだけど、良い事しか言わないんだよな
アフターフォローは全部ｺｯﾁに振るしズルイよー

ハッキリ言ってアメリカなどの多民族国家では黒人の方がアジア人よりもずっと立場は上だよ。
貧弱で弱弱しく、アグレッシブさに欠け、醜いアジア人は黒人のストレス解消のいい的。
黒人は有名スポーツ選手、ミュージシャンを多数輩出してるし、アジア人はかなり彼らに見下されている。
(黒人は白人には頭があがらないため日系料理天などの日本人店員相手に威張り散らしてストレス解消する。
また、日本女はすぐヤラせてくれる肉便器としてとおっている。
「○ドルでどうだ？(俺を買え）」と逆売春を持ちかける黒人男性も多い。）
彼らの見ていないところでこそこそ陰口しか叩けない日本人は滑稽。

http://www.tanteifile.com/tamashii/index3.html
まあ、語れや

>>244
営業という仕事は241みたいなｳﾙﾄﾗCを実現する仕事なのだから、
少しはいたわってやれよ。
仕事がある内が華さね。

>>247
営業もフォローするなら話は分かるが、営業が売りっぱなしという姿勢は
会社にとっても顧客にとっても良くない事だろ。

ちょっと手が空いた関係で、他の人の下請けで関数一つ書いたんですが〜
説明してくれた契約のママさんＰＧが驚くほどマトモで、悲しかったです。
あーゆー人がＳＥやってくれるといいのに！

　　 ____
ヾ (ΘΘ) ﾉ゛ ＜　SEは悪魔ー！
　` （─）/
　　（─）
　 （_）（_）
　 （）　（）
　~~　 　~~

>>249
>説明してくれた契約のママさんＰＧが驚くほどマトモで
スマソ、そのマトモって感覚を漏れ達が忘れないように、
もう少し具体的に説明してください。おながいします。

打ち合せ中、部屋のはじっこで黄色い液体を
全身から吹き出しながらケタケタ笑っていました。

◎無修正画像をご覧下さい◎無料パスワードをゲットすれば、もっと凄い画像とムービーがご覧頂けます◎
　　　　　　★見て見ておまんこ★
★http://endou.kir.jp/betu/linkvp2/linkvp.html★

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

ある超イソギ修正の仕事が、新人に与えられたんだけど、右も左も判らん新人には身に余ってるため、見兼ねて影で管理してる訳なんで、
今日中にこの機能が必要なら、あなたは何時までにコレやって。そしたら分けれるから、あなたがコッチ、他のコがアッチやれば間に合うでしょ？
って自分の仕事の片手間に、新人の仕事に建設的な計画を立てて、何も把握してない私に書けるようにフォローしてくれただけなんだけど、
日頃あまりにも酷いSEの下で働いてるから、マトモな人がいたよ(T_T)って思ったわけです。

いい人いてよかったね^^

いい人はこの業界では淘汰されて生き残れないけどね。

確かにいい人ほど思考がマトモなのでこの業界
の異常さに気が付いて辞めていく率が高い。

>>259
そですね。。。(´･ω･｀)ｼｮﾎﾞｰﾝ

やさしいやつから死んでいくのよ。

「どうでもいい人」ならいっぱいいるのだが。

「居ない方がいいひと」モナ〜

ＳＥ→　○ｙ一~~
　　　　（|,へ
　　　　 」　○|￣|＿ ←ﾌﾟﾛｸﾞﾗﾏ

大まかなことも判ってなくてもいい！
せめて、客先で有りもしない機能を有ると断言しないでくれ。しかも、それを仕方がないとか言うな！
おめーが話作んなきゃ運用で回避できたかも知れんし、少なくとも工数と金はとれただろ！

SEがあまりにも上等だと，我々はただのコーディングマシンになるし

>>266
その通りだねぇ

いちどでいいから ただのコーディングマシーンになってみたい物だよ。

>>268
主体性のカケラもない奴だな。逝ってよし。

細かいことはわからない >
当たり前じゃん。SEはPGみたく
コーディングにプライドなんて感じないんだよ。
どういう風に作るかはPGが好きに考えな！
俺の言ってる意味わからんやつで、
30歳超え、かつIT経験2年超えてるやつは、もういらねー

設計にくらいプライドをもって取り組んでくれたっていいと思わねぇ？

>271 おまいさんはプライドもってコーディングしてるのけ？

>>271 コーヒーにはブライト
ニドある事はクリープもあるが。

＞２７３
同じコードをニドも書くな

>>268
そ?
俺は、スレッド構成まで決めてくる発注元に
「ｵﾏｴの設計は糞だ!」と一度で言いから言ってみたい。

>>275
ただのコーディングマシンで済ませられるくらいすばらしい設計に出会ってみたいってことじゃないの？

>276
それをわかった上で>275は書いてるんじゃないの？

不可能なスケジュールを
「可能と言え」と言うSEが居るのですが。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

今まで腐ったSEの下に在っても、直の先輩はマトモだった。
違う先輩の下に付くようになって、
自分は今まで贅沢な悩みを抱えていたんだと痛感した。

何でもかんでも「ざっくり」と言う言葉で誤魔化すﾔｼ。

相手がこのｷｰﾜｰﾄﾞを言ったら、そいつのことは一切信用しないことにしている。

>>281
キーワードに対する過剰反応に注意だよ。

>280 それは先輩も同じ。
マトモだった先輩はおまいがいなくなって喜んでるだろーよ。

日本語おかしいよ？

>>281
しかしこの業界、ざっくりやっていかないとどうしようもない・・・
欝だ・・・

>>285
ざっくりな設計するやつは、ほとんどを実装のせいにする。
癪だな･･･。

保守

ざっくばらん

ざっくろ

>>286
ざっくり設計する奴は、殆どを担当させたプログラマのせいにする。

>>290
そういうヤツは日本刀でざっくり逝ってやれ。