システム開発あるある
■ このスレッドは過去ログ倉庫に格納されています
ーシステム開発あるある
http://livedoor.blogimg.jp/yukawanet/imgs/5/a/5a5addc4-s.jpg
ということで、一発でシステム開発がよく分かるこちらの図「Richard's guide to software development」です。
クライアントが欲しいものは「ネコっぽい何か」。
仕様書はざっくり、見積もりは甘すぎる、テスト前とテスト後では全く形態がかわり、実装イメージは「トラっぽいなにか」ですが、結局何がほしいのかがよく分かりません。
様々なバージョンアップを重ねようやく形が見えたものの、仕様書ともイメージともかけ離れた、とんでもない生物。
でも客は喜んでいるからいいか・・・。
ただこの後よくあるのが、こんなものを作って何の役に立つのか・・・と思うも、いざ使ってみると物凄い便利だったり、消費者の反応がよかったり。
やっぱり客の意図は間違っていなかったということになります。
これを見た人はこの画像を思い出すのではないでしょうか。
http://livedoor.blogimg.jp/yukawanet/imgs/9/1/9147c6cd-s.png
システム開発はいかに客の意図をさぐるかですね、結局分からずじまいでしょうけど。
http://www.yukawanet.com/archives/5290977.html 引き受けたはいいができる人がいなくて下請けに丸投げ 2ちゃんの訳知りみたいなご意見を言ってくるコンサルがいる。しかも伝聞で時間掛けて確認したらクソみたいな意見。 鼻くそほじりながらアクセス作ったツールが定番化して困ったことになった経験はある WebはNodeとReact
モバイルはReact nativeでWebと共通化しましょう Nodeはreactのサーバーズサイドレンダリングして高速化します、 >>8
あるある
バカみたいな手順書使って何日もかけてやる手作業めんどくさいから一時的なツール作って終わらせたら
ツールのアウトプットの方が正確だったので次回から本番作業のフローに組み込まれることに。。
このツールの設計書はどこだ？テストケースは？引き継ぎは終わったのか？これを作ったのは誰だ？→えーと、、もう居ないんじゃないですか？ SIerとか基本的な頭硬いコミュ障みたいな人間ばかりだから、相手の要望を上手く引き出す、必要なものが何か捉える能力が低すぎる。
後から新しい要望言われたとか、実物見たら違うって言われたとか、それ以前になぜ先に聞き出せなかった原因を突き止めるとか改善できない、自分のやり方しかできない人間の集まりだからしようがない。
そのくせこの業界に居たがる。
嫌ならAppleみたいに、顧客は本当に欲しいものは顧客自身知らない、を念頭に、自分達でサービスする事だけ考えればいいのにね >>10
これと、客に持って行く前にシステム部に値引き交渉してきた営業 >>10
顧客: えっ、同じ値段と納期で素晴らしいシステムを！？ >>10
これだわ、営業は詐欺師の才能あるやつだよ >>10
ユーザ企業だけど、出来もしないことを引き受けるのは辞めろ。
あと、システム部門を排除して調達部門と重役だけでゴルフに行くな。
うちの部長を中国の展示会とやらに連れて行くな。 >>10
「素晴らしいシステム」という何一つ具体的でない表現が無能営業ぽくて秀逸 京都市のシステムマイグレーション頓挫事件は自治体の無能職員の頓珍漢なニーズ聞いてる内に訳分からん様になった様なモノ 明らかに使われないシステムで開発のモチベーションが上がらない >>31
NAOKO = AKINA + SEIKO
とか書かれてるプログラムをメンテしたことあるわ というか、奴隷商売を禁止したり、二次請け以降は認めないなど
行政が入ってがっつり法規制敷くなどしなければ、いつまでも日本からGoogleやAppleが誕生しないってコケにされつづけるんじゃねえの 毎月人が失踪しまくるプロジェクトや三徹を経験させてくれたプロジェクトをこなして来たワイなら何が来ようがもう怖くない(キリ 「それ、EXCELの差し込み印刷でやっちゃ駄目なんですかね？」ってシステムが８割 >>41
開発室の窓から人が落ちていくのを見ないうちはひよっこ 「遅れを取り戻すために人を投入するわ」
成功したこと一度もない クライアント側だけど伝えてる事が一向に反映されなかったり、やっと反映されたと思えば他が改悪されたり、死ぬ程疲れた事ある おれは火消しのプロだ(ドヤァ
とか言ってる奴に最初からプロジェクト任せると炎上する不思議 俺の彼女はプログラマーだけど毎日終電近くに帰ってくるってのがずっと続いてるわ
一方、俺はシステムを発注する側で仕事の大半は社内決裁を取ること
残業は殆ど無いし大手だから収入は彼女の2倍 保守担当「…何が設定変えました？」
エンドユーザ「いやぁ、何も変えてないけどね〜」 開発が目的になって効果に見合わないものを作る。結果、作ったシステムは使われず、Excel運用にたどり着く。 俺が見て来た中で一番良く出来てた会計システムはなんとEXCEL VBAで作られてて、お値段200万で保守2万。
開発者をスカウトしたいと思った。 営業は「それは本当に必要ですか？」って言葉を覚えろ >>48
わざと火付けて自分で火消し
これで契約延長に持ち込む別の意味でプロ プロジェクト参加者全てが何を作っているのかちゃんと理解していない >>58
同じ同じ
デスソース使ったコアラのマーチみたいなもん >>54
ちぇ、何だよ
心配して損した
休日はパンパンしてるんだろうな クライアントが「コンセプト」という言葉を100回使う >>48
火消しのプロは火起こしのプロでもあったりするからなー 営業俺「先方が何とかって部分を使いやすくなるように何だったかな〜？何とかってやつに変更してってさ。専門的な部分分からんから先方に聞いといてよ。誰さんか忘れたから代表に電話して聞いてー。ヨロシク！」
すまんな >>31
だって業界用語とかイチイチ訳すのめんどいじゃん >>10
これで納品したらこれが当たり前になっちゃう >>54
おめでとう
彼女が結婚後も仕事続けたいと言い出さないことを祈ってる >>29
だってシステム部門は休日も仕事してるじゃんww ハード屋さんとソフト屋さんが仲悪いと
大変なシステム屋さん みずほ終わったらコボラーがあふれるって話だけどどうなんだろ？ >>89
銀行業務だとコボル以外が浮かばねえ。
兆円規模の誤差の許されない数値演算。
膨大なファイル数と気の遠くなる項目数。 >>87
自治体システムがほとんどCOBOLだし仕事には困らんよ 上司が文系でプログラム自体がわからない。
うちのことだが。 >>89
定年で消えてサポート出来なくなる言語ほど実は美味しいんだがな >>10
今時こんなアホな発言に付き合う客いるの？ 自治体のシステムでCOBOLやったなー。まだ使えるんだ。
もしかしてCOBOL使えると食いっぱぐれなかった？ >>44
入った人の仕様なんかの勉強期間を考慮するか優秀な人を入れないと無駄なんだけど大抵どっちも出来ないからなぁ >>31
消費税の変数が、shohizeiと、syohizeiが混ざったソース解析して発狂しそうになった
yとhで登録先のトランご違うの
仕様書には、「消費税」ってどちらも同じ日本語
死ねよ >>102
えー、だってキーボードでカチャカチャっとやれば出来るんでしょｗｗｗ >>71
若いときこの人凄いなと見てたが、ある日この人が問題大きくしてるなと気づいた。
でも一番の問題はその人に変わる旗振りが居ないことだと更に気づいた。 とりあえず新しい開発手法は社内システムで評価してからやれ 天皇が死ぬ度に元号の変更とテストさせられる
いい加減西暦にせえや、時代遅れも大概にしろ さすがに日付系は30年前のアレで懲りてるだろう
問題はEXCELパッチがどのバージョンまで出るかだ >>26
99%の営業は恥知らずの脳足りんだよ
厚顔無恥 >>111
飯の種を頭下げて取ってくるのは誰だい？パソコンとにらめっこしても飯は食えないで？ ファイルメーカーで自分でつくれば最近クラウドも使えるようになったんで便利。
まあ中小限定だけど。
ＦｉｌｅｍａｋｅｒＣｌｏｕｄのサーバーはＡｐｐｌｅじゃなくアマゾンなんだよねー。 >>102
そう言う時は躊躇なく、grepで置換して見易くしている。
shohizei=>sHohizei
syohizei=>sYohizei
置換前にファイルをバックアップしておいて、修正が終わったら、元の変数名に戻して、バックアップとマージ。
インド人の偽英語ソースを治している時に編み出した方法。 求人出すと雑誌の知識で知ったかぶってるレベルの低知能が大量に応募してくる。 「今の」天皇誕生日は祝日だけど、
新元号になったら平日になるの？祝日になるの？ まさにこの絵に同感だ
ただし、システム屋が過剰な演出で客のイメージを膨らませてるのもヒドイわ
システム屋にしたらネコだが客からしたらネズミ程度の小物レベルのクオリティー 日本人には抽象能力ないからシステム開発は無理だよね。モジュールのコーディング程度はできるだろうけど >>102
そういうの明確に変数綴り規定しないと無理だよ >>100
今でも無い
銀行系の派遣にも行けるし、自治体システムのメンテ作業も定期的に有る ユーザーが納品10日前にコード仕様を変更して来た時は殺意を覚えた。 >>99
残念ながら、その可否を決める立場が何も解ってないの。 ボス「ほんとに出来んの？」
リーダー「やってみせます！なぁお前ら」
馬鹿ども「意識！向上心に責任感！」
おれ「しねばいいのに」 >>78
ちゃんとオブジェクト化できていればほとんどそんなことにならんやろ >>132
違う違うｗ
客先の業界用語って意味
業界用語が仕様書にそのまま乗ってるから、そのまま変数名に使っちゃうような感じ
こんなん
http://www.aogyorui.co.jp/products/dictionary.html >>10
これ、営業は成績ついて苦労するのは他の人間って本当に糞な業界 >>134
いやちゃんとオブジェクト化できていれば
変数なんてほとんど
target
とかになるやろ 肉体労働よりも根が深い疲れ方してる方多い
マッサージ屋より >>10
営業とSEの成績評価を一蓮托生にしないとこんなのばっかで営業・システム開発部門の対立が続いてしまうんだよな
受注件数と受注額で評価するんでなく、原価率まで含めて勤務評定せにゃダメだわ 技術勉強して言語頑張って凄腕プログラマになったとすんじゃん
料理人で言えば三ツ星レストランのフレンチシェフ的な存在
そうすっと営業がお客さんに、うちのシェフならすごい料理作れますよ、今度会わせますよ、詳しい話を聞きに行かせますとかやんの
んでお客さんに何が食べたいんですかって聞くと、良くてイタリア料理が食いたい、普通で寿司食いたい、悪くて何が食いたいかわからんから想像して作れっていうの
最後のパターンが最悪、作ってみて不味いって訴訟になって死ぬ >>141
その最悪に近づく方が多分面白い。
生産系プログラマか、開発か、先行開発かの差。 >>143
自称できるヤツの謎コード位厄介なモノはない。 >>141
そんな最悪なのは普通受けない
客と争いになってもいいから
きちんと何がしたいか決めさせる
決まんねーならやるかボケ
で終わらせる
少なくともうちはそう >>141, >>146
でも、シェフのおまかせコースは許される不思議 まあ営業に文句言う奴は独立でもして自分のやりたい仕事だけを、好きなだけ、好きな単価でバリバリこなすのがオススメ
苦労もするだろうが、実際楽になる部分だってある。何よりやりがいがある >>87
COBOL、z80とかは継続的な需要があり、当面は安全だよ
ただし、会社が正社員として雇うのはしんどいからフリーランスになって
数少ない仕事の中から取ってこれるだけの営業力、
お客さんを満足させるだけの技術力が必要 >>6
そりゃ新卒がコンサル入ってそのまま仕事してるからな >>10
納品させて頂くとかいうキモい言い回しも再現してる エライ人たちが逆のことを言い出す。
そして言ったら言いっ放し。 >>141
最悪は素人が作った料理を手直しして食えるようにしろ、だろ。 見覚えのある近所のコンビニ店員が技術者として入ってくる >>75
(-.-#)
>>108
今度は氏なないでもテストが増えるYo♪ 次の元号が、M,T,S,H始まりだったら、軽く死ねるなぁｗ >>16
おまえはバカか。ソフト屋はソフト作りは得意だが、受注する会社の業務内容や業務のやり方などは知らない。
顧客が本当に欲しいものを知らなかったとしても、その会社の業務を知らなければ何も作れない。 下請けを集めすぎたせいで
顧客との顔合わせの場で大半のメンバーが「今は名刺を切らしていまして」とか言っちゃう >>45
あれって、基本部品の大きさとかレイアウトは数パターンしかなくて
変えられないけど、出来ないことも無いって説明受けて意味不明だった。 >>160
ワロタｗ
「そこの会社所属と言うことになっている名刺は切らしておりまして」、の略 WEBサービスの開発エンジニアになってからマジ気楽
ニーズが無いと作っても金にならんけどおかげさまで毎月売上入ってる 名刺もらっても活用したことない
活用されたことも多分ない >>167
そんなんじゃ各部門が納得しない
アクセスでツール作っても、あそこをあーしろ、ここをこーしろとうるさいのなんの
問い合わせだの要望だの要求だのがわんさか来て仕事にならん 仕様打合せで一通り決まって会議終了って時に偉い人が入ってきて
決定事項にまた何か言い始める >>115
共有開発者が容赦なくストリングブッ込んでくるパターンw >>172
CVSがWikipediaの編集合戦みたいになりそうwww >>149
COBOL資産有る間は仕事には困らんわな
VBもね
乱造された資産多い言語技術者は需要有るよ
Javaとかもそうなって行くかも知れんが、流石に出来が悪い資産が多いな できるやつはなにやらしてもできるし
できんやつはほんまにできん >>10
営業は仕事を取ってくれば自分の手柄となり、後は野となれ山となれ、だ。
ま、そうした社内制度が殆どだろうし、技術的成立性や難易度を理解する知能も持ち合わせていない。
そうしたオバカと体育会系のノリに加ええ、甘言や騙しの巧みさ、責任転嫁の技が彼らの武器になる。
で、大抵は問題発生の構造的原因はその種の社内制度にある。
結局、こうしたことの関して、関して見識も観察眼も哲学も無い無能な管理者トップがブラックの根源。
しかし、言い訳とｶ、責任転移とか、世渡りとか、人を煙に巻く議論とか、巧みなんだな、これが。 >>178
お前が自分で仕事取ってくればいいだけの話なんやで
技術屋上がりの営業は重宝されるぞマジで
会社になんかあっても潰し利くしな。むしろ最終的には自分から会社イラネってなる。 >>178
現場経験のない奴にいきなり営業担当させる会社のせいなので
営業は何も悪くないわ >>182
「自称」できるヤツってトコが>>145のキモ >>174
CVSって、一体何年まえからタイムリープしてきたん？ 会社の情シスにアスペの人が居たんだが、最初そうと知らずに話してたら、
まるで自分がアスペなんじゃないだろうかという錯覚に陥ったことがある
窓口役やらせるなら、一目でそうだとわかる仕組みを導入して欲しいなぁと思いました
以上、チラ裏 >>175
COBOLを無理矢理JavaやC#、VBに移行すると手間かかるだけで結果的に利益出ないプロジェクトになるパターン多いわな
賢い営業はLinux(or Windowsサーバー)+Open COBOLにするか富士通のNet COBOLにする COBOLからの置き換え理由にCOBOLを読める人がいなくなってきているからって言うのは
ホントかね？どこかに騙されて無理やりCOBOLから置き換えさせられているんじゃないか >>190
あんな英文法そのままの言語読めないって、ただのガイジでしょ COBOLって結局永遠に残り続ける気がする
たぶんJavaの方が先に滅びる >>184
ダイアルアップが主流で、1メガ程度のJavaアプレット落とすにも
相当時間がかかるから、客にフロッピーでアプレット配ってた頃かなw マジで。 契約終了間近になると目に見えてテンションが落ちるIT土方 ちょうど今、会社のシステムの3ヶ月かけて要件定義やってる最中だわ >>192
COBOLは黎明期からの三大言語の一つだしな これ毎回how the project was documentedで笑う 期間3週間のちょっとしたヤツだったんだけど、仕様出てきたのが納品前日の夜 >いざ使ってみると物凄い便利だったり、消費者の反応がよかったり。
ないない
顧客は、責任回避のため、上層部には便利になったと、適当な報告して
手作業加えて何とか回す感じか、システムは資産と存在しているが
利用しない感じが多いんじゃないか 作業終盤で仕様を変えるなバカヤローーーーーーーーーーーーーーーーー
マジでこれ喰らうとは思わなかった
この業界を舐め過ぎてた >>207
組み込みグラフィック開発だと年中行事だな。
完成してから「うーんちょっと違うな」的なw
それもあって昨今は大半がアジャイル化してきてる。
それ以外にもライバル他社さんがショーなどで画期的な表現をすると、もうすぐ発売の製品に追加要件が、、、 >>10
カチャカチャ ﾎﾟﾁｰ
// お前も早く逃げろ ttp://i.imgur.com/sWco4kY.jpg
顧客と営業 >>212
>>75
で既出だろーが。ノーチェックで納品すんじゃねーよ。 嘘か真か
保守業務をなくすことで費用をおさえる！ってフレーズにお偉いさんが同意してめちゃくちゃになったって書き込みを掲示板でみたことある >>214
ret = malloc(1024);
if (ret == 0) {
fprintf(stderr, "いやん、大きすぎて入らない\n");
exit(253);
} >>219
コボルは兆円クラスを誤差なく扱うのに便利だけど、FORTRANにはこれって言うメリットがないもんな。 >>210
業務ツール開発や簡易システム開発でも同じだな
仕様変更なんて当たり前だし
出来上がる直前に業務のやり方が変わって必要なくなったとか泣ける
こっちは金もらえればいいんだけどさ… >>219
>>220
スーパーコンピュータではまだまだFORTRANが主役だぞ
FORTRANが最速のコードを吐いてくれるからね
一家に一台スーパーコンピュータの時代が来たらFORTRAN復活だ スケジュールが逼迫すると人員が増加されるが
使えない奴ばっかり回ってきて結局リスケされる >>220
大学の研究では小数点以下十数桁の値が重要なことがけっこうある。
8倍精度の固定小数点演算ができるFortranが必要。 >>210
仕様書に「AI機能付き」とか一言書かれただけで現場は大混乱になるだろうな。 >>225
そう言う大規模なのは「無理ポ」が通るんで驚かねえ。
ちょっと頑張ればできそうなのが厄介w
作るのは数日でも、レビューとかテストとか評価とかサイクルとか、もーめんどくせえし、リコール出すのはこの手のやっつけが多い。 お前らSEはいつもそうだ
l顧客が詳細内容を知らないのをいいことに
やれボタン1つに3ヶ月かかるだの・・・・甘える なっ・・・ >>220
いや、あんた浮動小数点と整数型の区別がなんとかかんとか、、、
しかし、COBOLてあの時代に構造型みたいなことができたて奇跡 >>227
要件決まる前なら二つ返事でＯＫでるぞ
だがテスト終わり際でそんな要望出されても他への影響確認やらでかかる手間は尋常ではないんだよ
要望があるなら、最初に全部出しきってくれ >>228
浮動小数点数を扱える言語はいくらでもあるけど、巨大な整数を扱える言語は少ないって話じゃね？ ■ このスレッドは過去ログ倉庫に格納されています
