【IT】「西暦2007年問題」の解決策を募集しますです。。。

団塊世代の退職により、老朽化・肥大化した基幹系システムの保守が
難しくなってきているようです。

詳しくはこちら。
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030408/1/

依頼：http://book.2ch.net/test/read.cgi/bizplus/1049275716/131

2

容易に引継ができないような雑なシステムくみやがって…

ま、大メーカーってのがお話にならないってお話ですな。

　　　　　　　　　　　　　と、はしょって読むテスト

やや、心配のし過ぎではないかと・・・
でもオサーンは大事にしましょ。

アルゴリズムからプログラムを組むって言う今までの普通の仕事から
プログラムからアルゴリズムを紐解くって言う仕事が生まれそうですな。


　　　　　　　　　　　無論、そんなのにお金払いたくないけど。

えぇっ？
また問題？

プログラムって性格が出るよね
きれいなお手本通りのプログラム書く人もいれば、自分にしかわからないような
雑かつ無駄の多いヤシ。。。
要するに後者の後始末の問題って事か?

つまりITにも年の功があるってこった

　　　,、,、
　　(ﾟ∀ﾟ)
　　 ﾟしJﾟ

>>6
業務系アプリのアルゴリズムなんてどーってことねーよ
何をインプットしてアウトプットするかが決まっていれば
なんのことはない。（業務系だからね

問題なのは、業務の流れを理解しているSEが少ないからだろ
コーディングレベルの話じゃないし設計レベルだよ。これは

コボルとか

団塊が大量に去る日は前から分かっていただろうに
続くものたちに引き継げなかった企業と団塊自身の責任ってどうなんだろう
素朴に疑問符

>13
ばかいえよ、やっとおいしい思いする年だとおもったところで、
いきなりリストラで事実上の指名解雇なんかするんだから
自主的にそんなことやる気になるわけないだろ。

自分だけは居座っていい思いしているトップの責任だよ

まあ作った人間もまさか２１世紀まで使うとは思ってもみなかったんだが。

>>11　そっか、普通に給料計算とか言っても、労基法の
　　　残業1時間に基本給時給換算の125％とかってわかっていないと
　　　基本として組むことも出来ないもんなあ。

>>13　新しい場所(品物)で頑張ります。


　　　巨額の赤字を出したことで、年金福祉事業団の理事長がつっこみくらいつつ
　　　おなじ人が年金資金運用基金の理事長になるときの挨拶。

そう言えば２０００年問題の時は泊まり込んだっけなぁ

あぼーん

>>14
まぁそりゃそうだ
しかしなあ、トップも団塊も若年から見れば力のあることには変わりないしなあ
共食い同罪って気もしないでもない
あくまで、こちら側からの見方だけど

コボルとかR3とか、地雷踏んだSEは可哀想・・・
折れの知人も、マニュアルやドキュメントがないって騒いでるよ。
かといってそいつはドキュメント作ろうとしないけど。

こういうのが続いて、今の状態になってしまうんだろうな。

>>21
ドキュメントが一番面倒でかつ手を抜きやすい所だからなぁ。

団塊の造るものにはろくな物がないね。

単純に言うと、会社の知られたくないところとかまで知っているわけだから、
信頼のできる人をもっていかないといけないだろう。

これを機会に、COBOLとかフォートランで書かれた基幹系のプログラムが、
Javaのような可読性のある言語に置き換えられていく予感。
そうすれば、Linux上でオープンなシステムを組むことも可能だし、将来
的にはｉモード携帯電話でも動くようになるしね。

SEの現場の立場からすると、いくら昔のシステムといっても、
現行改修や保守運用などで後続を鍛えるチャンスは結構ある。

問題は、そのベテラン連中が積極的に若手に伝えよう、育てよう
としていないこと。

特に「これは自分にしかできない」という意識がスムーズな技術移行の
妨げになる。突き放しておいて、噛り付いてでもついて来いっていったって
直接的に関わるところ以外は、案件に関係ないから深く身に付けようと
万人が思考するわけじゃない。それがタイトなスケジューリングだったら
なおの事。

そうして、特に基幹部分のブラックボックス化(PGで言うところの"おまじない")
が広がり、支障があると翻訳ソフトを使うかのように、
ベテランに聞く→場当たり的なアドバイス→なんとか事なきを得る
の繰り返し。

生き字引なベテランがいなくなったらなんて想像できないなんてことが
ざらにあるよ。

この手のナントカ問題って問題になったためしがないね。

>>27
そりゃ本当に問題になる前に
未然に防いでる人間がいるからよ

>>28
今回はどうやって防ぐんだろう。。
パッチあててもベテランは死んでいくだろうし、、。
いまからドキュメント作り直す気もないんだろ？
現役SE、PGだって。

会社よりも顧客最優先ってなSEがいなくなって久しいよな

まあ今後はﾊﾟｯｹｰｼﾞ中心でｼｽﾃﾑは再開発されていくのは間違い
ないし

>>27-29
2000年問題の時は世界中で祭状態だったが。
今回はソースからドキュメント起こすことになるんだろう。
そりゃお金もらえればやるけどさー。
こういうのに顧客は金ださんよ…。

金出さない所は問題抱えたまま潰れればいい

まぁ再構築せにゃあ仕方ないだろう。
もちろん再構築したものがマシであるという保証は全くないが・・・（経験上）

>31
ソースから起こしたドキュメントには、要件の”キモ”になる部分は必ずしも反映されない
ような気がする。
それこそドキュメントを起こす人間のスキルに依存するケド。

ITPROも、封建的な方法をつかうよなあ。
善意を当てにして「お上のために何とか・・・」みたいな。

そもそも年金問題は政府の問題。正確に言えば、与党の問題。
その与党を決めるのは国民。しかも多数決。
封建社会じゃないんだから。政府が1種類しかないと思うのは、
自民党政治に影響されすぎじゃないかと。

まずITPROが、今の野党にロビー活動するのが一番いい。

若手へのノウハウの伝承だって？
わざわざ自分の墓の穴を掘る馬鹿はいないよ。
自分がいないと困る、という状態をキープすれば安泰なのさ。

>>36
胴衣。
いつ自分の首が切られるか分からない実力主義のご時世で
手取り足取り教えて、わざわざ自分の存在価値を下げる馬鹿は少ない。

合成の誤謬かな
こうして知らぬ間に、皆が皆の首を絞めていく

３０年も前につくったシステムなんて、
今なら高性能パソコン１台で済むんじゃないのか？

>>36>>37
それが一番の問題だよな。
終身雇用システムっていうのはこの辺りを支えていたんだよね。
・終身雇用制度
　若手を育てる事により若手がレベルアップ＆自分も楽になる
・終身雇用制度崩壊
　若手を育てない。『理不尽な事をしても自分が残れる状況を作る』
まずいよな．．．日本が駄目になっていくよ。

>>39
お前は学生か異業種だろ．．．
そういう問題でも無いしスレの流れも読んでいない。
また大型汎用機上のシステムについてわかっていない。
取り敢えず馬鹿の巣窟ニュー速に言って馬鹿かましていろ。

>>39
そんなんで済んだら問題になってない

ちゅーかちゃんとドキュメントを書かせろよ。
まだ4年もあるんだぜ。
忘れた、できませんでいい加減なまねをさらす
DQN爺を甘やかしすぎだよ。

うちの会社の基幹システムもパッチワークと化しています。

>43

うちの会社は大規模基幹システム作ってから１０年ちょい経ったが、やはりそん時の主力は
団塊世代。

解決策としては、いっぺんゼロに戻って基幹系システムを作り直す（そん時に基幹系システムを
作れる人材も育成）しかないんだろうな。

http://ruffnex.oc.to/ipusiron/upload/6802.jpg
http://ruffnex.oc.to/ipusiron/upload/6803.jpg
http://ruffnex.oc.to/ipusiron/upload/6804.jpg

>>44
がっさり作り直しても、作りっぱなしで人材が残せない罠。
つーかそもそもそんな人材がいない罠。

そしてまた過ちを繰り返す・・・？

動いているシステムに手を出すなの格言を作ったのも団塊の連中だからな。
そのツケが回ってきただけ。

頑張ってなんとかしてくれ現役SE

あぼーん

なんか、アシモフの「ファウンデーション」の舞台の銀河帝国みたい
問題の質が似てる気がしまつでつな（ｗ

とりあえず、就活中の無職でSE職を受けまくり、落ちまくりのオレを採用してくれ｡･ﾟ･(ﾉД｀)･ﾟ･｡

>>49
こういうのに騙される奴って不幸だね

合併時の銀行のATMって、そのベテランがやって、失敗したんじゃないの?
新しい世代の人に、0からやってもらったほうが、障害が少ないと思う。
2007年どころか、去年色々問題起こしたのは、団塊の世代じゃないの?

>>53
そのくらいのベテランは請負の金計算するだけ。
人によっては経営判断するだけ。
物作ってるのは長髪ピアスの塗装工と見分けが付かないSE。

そういえば、1年前の今頃はみずぽ騒動の真っ最中だったな。
部外者なので激しく笑えた。

考えようによってはそもそもベテランにとっては
保身のためにシステムの最重要部分とかは
自分以外誰もわからない状態が理想のはず。
だれにでもできてしまったら年取ってる自分が
最もリストラ対象になりやすいわけだし。
だからこういう問題はなにも２００７に限ったことじゃないのでは。

>「システム障害はなぜ起きたか　みずほの教訓」
在庫多数に付きみんな買ってね、とか(w
現場に立ったことのない奴は好きなこと書けて気楽で良いわな。

>>56
これからは常にこの問題がつきまとうわけだ。

つーことは
こういうとこは常に人材を流動化させておけば
自分だけがしっているなんてばかな妄想はなくなるんじゃないの？
絶対定期移動の場所にするとか。

age

まんどくさいから、PC投げるべ、江戸時代の頃にあこがれてみるテスト

>>25
昔の処理系やOSは単純だった分、アプリケーションも含めて、
枯れるのも早くて、安定度最強。業務系のような単純技術
アプリケーションには最適。

Javaはまだ生々っぽい処理系で落ちまくりだし、
ゲイシOSなんて激しくだめぽ。リナちゃんもまだまだ。

システムのオープン化、標準化と言うのは
特定の技術者への依存を減らすと言う意味でメリットがあるが、

システムの構成要素相互の相性、不安定性、
システムの秘匿性の低減によるセキュリティの低下をもたらす。

なんか、”わざわざ自分のノウハウを伝授して自分の首を絞める奴はいない”っていう
意見が多いみたいだけど・・・そうかなぁ・・・
少なくともうちの会社では、自分の持っているスキル・ノウハウを”ちゃんと整理して”
下に引き継げる人間は、すごく重宝がられるし実際に評価も高い。
むしろ、いい年して自分の中に属人化したノウハウを抱え込んでる（＝満足に後進の
育成もできない）奴こそ真っ先にリストラ対象だと思うが。
（陳腐化したシステムは再構築すれば済むが、人が育たないのは中長期的に見て
ヤバいから・・・）

マイクロソフトは、企業秘密をオープンした。

>>64

>少なくともうちの会社では、自分の持っているスキル・ノウハウを”ちゃんと整理して”
>下に引き継げる人間は、すごく重宝がられるし実際に評価も高い。
理想はそうなんだけどね。悲しいかな、大半の企業は人間の評価が
できない無能管理職がはびこっているのでそれができないのが現状です。
うらやましいですね。

それよりも、年金問題のほうが深刻だと思うのだが。

日経なんだから、新しい需要の創出ってことでしょ。
知らん人の書いたシステム・プログラムを解読するほど、困難で苦痛な作業はない。

>66

「ＳＦの９０％はクズである。しかし、ＳＦに限らずなんでも９０％はクズである」

という格言は企業にもあてはまるのでつ

っていうか本気で引き継ぐとしたら、やはりソースコードを理解する必要があるだろ。
今までシステムの全てを完璧に記述したドキュメントなんて読んだことないよ。
そんなのあるとしたら、それはソースコードだけだと思う。

「世の男の90%はクズである。しかし、男に限らず、すべからく人の90%はクズである」

・・・なるほど、哀しいほど真理だ。

とりあえず>>51を雇う企業は、この問題は解決するな。

団塊自身が日本の癌。そいつらがいなくなるってことはむしろプラスじゃないの？

ネットできなくなったらいやだなぁ

>>73
おまいみたいなレッテル貼りしか能のないカスがいなくなった方がプラス

>>74
食う清め

ブラクラﾎﾞｸｰｽ

>>71
その理屈でいくと世の人間が全て男であるということになってしまい
明らかに矛盾が生じる。

いや単純に男女の区別はとくにないということだとおもいます>>78

>>70
ものにもよるが、下手するとバイナリでパッチが当たってる
ときもあるから、ソースコードが絶対正しいとも限らないのだが。

>>78
アホかお前？
男も女も90%がクズなら矛盾は生じないだろうが。
何が論理学者だ、厨房が。

つまり、日本は終身雇用を継続していた方が良かったかもしれない、と。

みんな自分のことばかり考え、同僚ですら裏で自分を蹴落とす準備をしてるかもしれ
ないと疑心暗鬼にかられ、他者を貶めることで自らの価値を維持し、馬鹿正直に企業
や社会へ貢献する者ほど損をする……今はそんな社会になったということですかな。

スレとは別な問題が内包され、それが次々と顕在化する平成という時代。
いよいよ本格的にツケを支払う時がきたわけだが、ツケを作った老人は知らん顔。

２ｃｈを見て絶望して寄り添い合っても、俺らの将来は誰も助けてはくれない。
何もせずに損をするより、選挙に行って、せめて文句を言える立場になろう。

>>64
職業人としての社会的責任ってやつかな。
見えない部分の仕事まで評価される会社なら
そういういうものありですね。
実際は>>66なんだろうけど。

ゼロサムゲームですな。

とりあえず、外資系のコンサルタント殿にご意見を伺いに行こう！

高い金を払って！


どんなきれいなおえかきをしてくれるんだろう・・・・

いまどきコンサルかよ
懐かしいな

ＩＳＯコンサルはまだまだ頑張っているのだろうか。

５年くらい稼働してるシステムのソースとか見ると
おいおい、よくこれで動いてるなってものが結構ある。
おれの周りだけかも知れないが、バブル世代の香具師が
作ったシステムはいい加減で手抜きが多い。

ま、常識で考えて解決法は

・全く新しいのを用意する。
・すべての箱をひっくりかえして、説明書を設ける。
・翻訳ソフトの翻訳ソフトの翻訳…(以下略
・ＯＢを別に雇う

　　　　　　　ま、いくつか組み合わせるぐらいがまともだけど。

昔使ってるシステムで、今は使われなくなったインデントも相当あるよな。

年よりのＯＢと若い女の子で別会社作って現在のシステムの分析をする
男は要らん
自社の仕事終わったら他社のも受注すればいい
空洞化で業務内容も変わってきてるからそんなに大変じゃないよ

みんな若いねえ

>>88
今も昔も大差無いと思うが・・・

スレタイを読んで、こういう問題の仲間かと思ってしまった。。。

2000年問題以外の「コンピュータの誤動作危険日
ttp://biztech.nikkeibp.co.jp/biztech/it/y2k/about/non-y2k.html

日本人がやっててもこれなのに、中国人やインド人に本格的
にやらせたら将来どうなんのかねえ。

これは、ﾋﾞｼﾞﾈｽﾁｬｰﾝｽ!






　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　なのか？

国民一人一人にパソ(コンパイラ含む)持たせて、
自主自助精神でさせればいいのでは。


　　　　　　　　　　　　と孫○○っぽい構想を述べてみるテスト

>>96　そのサービスに対し、金を払う人が一方にいれば、
　　　ビジネスチャンスといえるのではないでせうか。

>>96
SE引退した人たち集めて講師/アドバイザーとして派遣するとか。

マネーの虎(ってまだつづいているのか知らないけど)
の目が光りそうなネタなのにな。

企業の寿命は３０年というが、要するに「人が入れ替わったらおしまい」
というのがその原理だったんだねぇ

あぼーん

まぁ、何だかんだ言ったって、
お客さんから見て派手じゃない案件にまで
しっかり金が流れなきゃ解決しないわな。

結局経営側が情報部門をケアしてなかったから
しっぺがえしくらってるのだろ？

漏れは自分の持っているノウハウはすべて伝える。
それが伝えた相手が十分に理解したころには、
漏れはまた新しい技術やノウハウを習得している。
よって、保身を考えるインセンティブは働かない。

それが->それを

こんなの簡単じゃん！
ベテランを止めさせなければいい！

ただそれだけのこと！

・・・

>>107
その分、あなたの働く場所がなくなるかもよ

Ｙ２Ｋ時にシステムの見直しとかしてるんじゃねーのか？
Ｙ２Ｋを乗り越えたシステムだったら大丈夫なんじゃねーのか。
素人考えだが、システムの引継ぎもできなくて
2007年に「あぼーん」するような会社は
ＤＱＮということで。

>>105
いや、ぼくらの年代では、もう新しいことは正直覚えられない。
オープン系のことはさっぱりだ。今から追いつけるとは到底思えない。

だけど、基幹はメインフレーム、これは、保身のためだけじゃなく心底そう思ってるよ。
実際、基幹をオープンＥＲＰなんぞに移行しようとして断念した他社例は数限りないし、
社内でも、若手主体で取り組む３文字熟語の情報系システムの構築Ｐｒｊは、相当高い割合でこけている。（だいたいベンダーの口車に乗せられる）
僕らの目の黒いうちは、基幹はメインフレームを死守するよ。

そもそも若い奴ら、ホスト系技術なんぞ覚えようともしない。
ちゃんとドキュメントだって全部あるのにな。
オープンのプロジェクトこそ、ドキュメントなんて全然残ってないじゃないか！

マスコミのあおりとか受けやすい人間が>>1を本気にすることが怖い。
システム構築の経験ゼロの評論家、証券アナリストがいいそうなことだな。
なんでもかんでもメインフレームだめ、サーバーは万能だ！
笑っちまうぜ

「オープンシステム」なんて時代遅れの言葉を使ってるのは何とかならんのか。

>>1の記事をつらつらと読んでみたが、あまりにも記者が馬鹿すぎ！
ワイドショーのコメンテータと同じレベル

で、こういう問題の際の解決方法は？

無理やりプログラムから、アルゴリズムを理解しようとするから頭痛くなるのであって、
根本の業務から理解するっつーことしないとだめなんちゃうかなー。

まあデジ土方はますます大変になると・・・・

システムを3年ごとに廃棄することを保守と言う。

>>117
たしか、７・１１がそれに似たことをやっていると聞いたことがあるのだが…

結局、問題先送りにされるだろ。
であとの世代が泣きを見ると。

マジレスすると、開発現場では5年後のことなんてこれっぽっちも考えちゃいねぇよ。
どうせ新しい技術が出てきて今のシステムは総入れ替え。

団塊の世代とか言う奴らが全部この世から
去ってはじめて新生日本が生まれるんだよ。
２００７年問題？ぷっ

>SE引退した人たち集めて講師/アドバイザーとして派遣するとか。
たぶんおのおのも自分がくんだ部分しかわからないよな。

団塊の世代の得意技＝多数派工作

つーかさ、インタネ時代からやってきたＳＥ君たちって、
メールの送り方は知ってても、メールの受け方は知らないんだ。
と、爺臭いことを言ってみる。

んなことほざいてんのはヲタＳＥとＳＥ舐めくさってる連中だろ
営業いやならＳＥやめちまえ
雑務いやならＳＥやめちまえ

それより、人間も辞めたほうがいいと思う。

というか弱小下請けの身では弊社の新人アサインも出来ないので育てようが無いです。。。

SEになった時点で人間は辞めてるだろ

　　　　　　　　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　 　 　 　 　 | 　春厨ね。尻の青さがﾁｪﾚﾝｺﾌ光を放ってるワ。
　 　 　 　 　 　 　 　 　 | 　管理系のオバカな虚業家と現場職人肌の実務家の
　　　〃ﾉ~ヾ 。ｏ O ○ |　　価値の相違も分からぬ短絡厨って生きてて恥ずかしいナ。
　　 人 ﾟーﾟゝ　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 （⌒Y⌒）
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　終身雇用と年功序列を同一視して、止めるから管理系の虚業バカはダメなのよ。
　年功序列右肩上がり賃金を是正して平準化し、保守需要と育成能力も正当に評価して
　個別能力評価で加点主義で現場の活力を養う方向で企業経営しないと
　そんなＤＱＮ無能経営陣と無能銀行員と無能官僚に人材資源を食い潰されるのヨ。

年寄りの働ける環境が残って、いいじゃないか！
若者もがんばれよ(w

問題の先送りが問題なのではない。
問題を先送りしする選択をしたという自覚がないことが問題なのだ。

もとい
問題の先送りが問題なのではない。
問題を先送りする選択をしたという自覚がないことが問題なのだ。

2000年問題もなんとかなっちゃいましたし、
なんだかんだいって、なんとかなるんじゃないかと思ってる人が多いかと、、

でつ。
http://f8.aaacafe.ne.jp/~testest

莫大な金と時間と労力をそそいで作り上げた古いカスタムカーに乗り続けても
将来はないぞ。いつ壊れるかわからん不安にかられながら走るのはイヤだろ。
３年毎に新車のカローラに買い換えろ。そのほうが安心してドライブできるだろ。

資金計画が会社内部や株主にも理解できて信頼があがるぞ。
なおかつ、その時の最新のビジネスプロセスが使えるから、
業務改革までできてしまう一石二鳥。

基幹システムは最新のパッケージに置き換えろということ。
基幹システムの独自性で会社は儲からん時代なのさ。
文句をいう奴にはその部分だけ自前で作らせればいい。
作った奴がいなくなったらそこだけ捨てればいい。

メインフレームハードの永遠ともいえるレベルアップ・リプレースで儲けてるメーカの口車にのるな〜

この問題は「２００７年」ではない。頭のいい奴は大昔から気付いてるぞ。

新車には欠陥がつきものでつ。
必ずしも安心とは言い切れないでつ。
むしろ常に壊れるとわかっている車なら対策のしようがあるでつ。
と、屁理屈をこねてみるでつ。

２００７年問題は、大昔から気づいていた頭のいいやつらのしっぺ返しでつ。

そして、毎度の商売ネタになってくんだろうなあ
>>1も前振りなのかしら

米IBM，古い“スパゲッティ・コード”を最新技術に置き換えるサービスを発表

　米IBMは，旧式プログラムを新しい技術に置き換えて“スパゲッティ・コード”の
問題解決を支援するサービス「Application Portfolio Management Services」と
「Legacy Transformation Services」を米国時間4月10日，発表した。
「数十年間も使い続けている古いアプリケーションの維持は，コストと手間が増す一方だ。
当サービスで，この問題の解決を図る」（IBM社）

http://itpro.nikkeibp.co.jp/free/ITPro/USNEWS/20030411/12/

高給取りが大量に辞めるから、固定費は減るって事にはならない？

>136
故障を直せる奴がいなくなるっていうのを問題にしてるのに。。。

>137
なるほど、一応それらしいことは考えてるというアピールだな。
で、どこの部分に採算の皮算用があるか興味があるね。
2000年のときはソースコードから影響などを見付けてドキュメンテーションする「魔法のツール」
を根拠にしてたけど、イマイチだった。その程度のものだったら、やはり人材問題は残るのでは〜

まだ４年もあるじゃねぇか。

この数日、人材面っぽい記事もちらほら見せてる罠＞nikkei

「COBOL技術者はXMLとWebサービスを学べ」──米アキュコープ社長が訴える
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20030411/1/

「COBOLはまだ死んでいない」――米Acucorp社長兼CEOが語る
http://itpro.nikkeibp.co.jp/members/go.jsp?to=/free/NSW/NEWS/20030410/2/

結局金出したら解決するとしか経営トップは思ってないよ

>>141
そう言い続けた結果が、2000年問題につながったのだが。

昔のシステムはﾅﾆが問題かというと、変更・改変時の
影響範囲が分からないこと。

どこでなにがどうつかわれてるのかわからん。

今の会社をあぼーんさせて新しく会社をつくる
古いものにとらわれるな

　　　　　　　　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　 　 　 　 　 | 　ひろゆき　ｱﾏｱﾏ　まぁ素人はそんな認識しかムリね
　 　 　 　 　 　 　 　 　 | 　経験者なら>>145のように適切な認識があるけど
　　　〃ﾉ~ヾ 。ｏ O ○ |　　そうはいっても、このｽﾚに来たのはセンスあるけどね
　　 人 ﾟーﾟゝ　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 （⌒Y⌒）
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
>549 名前：仕様書無しさん 投稿日：03/03/12 19:41
> バグ放置＝Ｎ
> バグ無知＝Ｔ
> バグだらけ＝Ｈ
> おまいらは・・・
>551 名前：仕様書無しさん 投稿日：03/03/12 19:59
> バグは下請け次第＝Ｆ
>521 名前：仕様書無しさん 投稿日：03/03/03 15:52
> よーするにシステム間接続のテストをしてなかったってコトだろ？
> みずほと同じだな。
>
> 人は同じ過ちを繰り返す・・・
>509 名前：仕様書無しさん 投稿日：03/03/01 22:16
> >>506
> このＰＧを修正した香具師はこの業界から追放でしょうな。
> それにしても単体・結合テストを十分に行なわなかったからだな！！
> Ｊ束の駅総合販売システムと一緒ヤン！！
> これも単体・結合を十分にしなかった為に総合テストでバグが３００以上も出たからね。
> Ｎはホンマしょうもない連中ばっかやな。

＃冷遇されたＳＥが腹いせに、時限地雷仕込んだらきっとわかんない
　ソースは偽物を置いて、実行形式だけ仕込んでたらわかんない
　匠をある程度は大事にしないとダメよ（失われた記憶が悲劇を・・・）

>>146　全部には手が回らないでしょうね　
倒れたら二度と立ち上がれないｼｽﾃﾑたち　経営陣が気づく頃には時既に遅し　
アドバルーンをあげてしてるのね　その為に新しくお金をとる仕組みづくりを　巨人は

エンジニアを軽く扱った経営者の自業自得っていう論調は見え透いているので面白くない。

>新しくお金をとる仕組みづくりを　巨人は
ITに限った話でもなさそうなんだけどな
金融でも似たようなものでしょう

しかしなんだな、この問題を大きく捉え直すと産業の空洞化と言えないか？
別に外国に仕事が流れたわけじゃないけど。

「技術」や「知識」っていうものを真正面で捉えて考えてみる必要があるんじゃないかな。

ゴミっていうと語弊が有るけど、それからでさえ何らかを組むのは
昔やってた事なんだろうけどねえ

>>147
つか、ひ（以下略）は、「メインフレーム」なるモノを見たことがない、
に１万カノッサ。













ま、漏れも実物（ハードウェア）を見たことはないが。
端末エミュレータの画面なら見てるが。

メインフレームは人間様よりＶＩＰ待遇をうけとるぞ〜
空調のきいたシェルターの中に３重の鉄扉 Ｎ○Ｔデータ通信センターにて。。。。

団塊の世代の大量退社により、瀬戸大橋の保守が困難に
橋、陥落の危機

とかいう夢を見た。リアルで

そのときの、鳴門、しまなみじゃろうて

（＾＾）

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

>>154
それ以前に、山陽新幹線のトンネルがぼろぼろと
はがれ落ちるんじゃねえの？
瀬戸内海の塩が混じった土を使ってるらしいからな

COBOL撤廃するラストチャンスだな。残した会社が地獄見る

雇用問題を無理からに解決させようとしてないか？

これ勘違いする香具師いると思うけど、コードの問題じゃないよ。
あくまで業務全般の理解だよ。
コードなんてアウトプットまで何の言語使っても問題ない。
ただ業務の理解は並大抵のこのでは理解できないんだよ。


要するに設計がクソだったってことだよ。

>>161
仕様バグですか。

不治の病に瀕している人に
本人と家族が望むのであれば、安楽死を認める。
（安楽死の合法化）

安楽死の意思確認は、中学卒業時と自動車免許の更新時
パスポート作成時に強制的にかかせることとする。

>>161 業務が理解が大変なんだよ〜
と言うのは、プログラマとしては優秀なんだけど、期待してＳＥやらしてみたら使えん輩に多いな。
つまり、ＳＥ的に業務理解ができるスキルはセンス次第というわけやな。
過去の設計がクソだというが、作った当時はそれで十分だったのだ。
時間の経過で陳腐化した前提で設計を理解してくれよ。
それが出来るＳＥ集団を捉まえるのが、勝てる企業の命題です。
早く隠居させてくれよな〜

翻訳能力、包括的視野、柔軟性の欠如といったところか。

実際、プログラマーの能力とSEの能力って別物だよね。

本当に使えるSEは、コンピュータに頼らない方法を考える

この影響か知らんが仕事をたくさん貰えて大儲けだよ。

なんか危機感を煽ってるだけに感じる
これを煽って得する人って誰だろう

>>169
コンサルタントが「2007年問題ソリューション」をうりつけに
あなたのところに訪れる日もそう遠くはないでしょう。

このそりゅーしょんは完璧です！といって・・・・

COBOLより先にVBやDelphiが先に廃れることになろうとは

団塊なのだが、昔のことを考えてみると
コンピュータと名が付けば、業務のいかんを問わずに「任せる」だった。
任されたって分からないから、それこそ必死に勉強して、
任した本人が理解していない技術的（業務的）背景などを抽象化して
プログラム化したりしたもんだ。
それが、ＰＣを皆が使えるようになると、「○○は××使えば簡単でしょ、任せる」
などという言い方に変わった。
まぁ多少は話がこなれているから、簡単になったが出発する方向とか予算が
まるっきり嘘というか違っていたことも多々あった。
というわけで、やり直しするのでもかえって仕様を作るのに苦労するように気がする。
特に、昔のように無かったものを作るじゃないのだから「昔出来たものがなぜ出来ない」
という逆風はすごいだろうな。

会議ばっかで全然煮詰まらない。
オッサン世代は馬鹿ですか？？？？？？
なんで毎週毎週くだらん会議で仕様が変わるんだよ。
頭おかしすぎ。

>>173
仕様が出てくるだけマシだよ。
仕様の打ち合わせのはずが、独演会になっちまうんだから…

システム構築は、そういう会議で「明確な仕様となりえる発言」をした人の責任になるからな。
誰かが決めてくれるまで、ひたすら能書きを繰り返すというのが日本企業人の習慣。

経営者の意見だけ聞いて、細かい仕様は勝手に作って管理者〜エンドユーザに押し付けます。
「社長の指示で作りました」って言えば、イヤイヤでも使ってくれるからさ。
そのかわり仕様の作成には経験とカンをフルに活用しますけど。
↑
今までに成功したプロジェクトは皆このパターンでした 団塊と若手の中間のＳＥです

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　資本金
　　　　　　　　　　　　　　　　　　　　　　　3億円以下 　　　　　　　　　　　　　3億円超
率 　　　　　特別償却　　　　買取　　取得価額の50% 　　　　　　　　　　取得価額の50%
　　　　　　　税額控除　　　　買取　　取得価額の10% 　　　　　　　　　　取得価額の10%
　　　　　　　　　　　　　　　　　リース　リース総額60%相当額の 10% 　　　　　−
対象金額　ソフトウエア
　　　　　　　以外の設備 　　買取 　　　140万円以上　　　　　　　　　　　600万円以上
　　　　　　　　　　　　　　　　　リース　　200万円以上 　　　　　　　　　　　　　−
　　　　　　　ソフトウエア　　　買取 　　　70万円以上 　　　　　　　　　　　600万円以上
　　　　　　　　　　　　　　　　　リース　　100万円以上 　　　　　　　　　　　　　−

無駄な土建工事減らして、ゼネコンマンや大卒ﾌﾘﾀｰ、プーを強制的に国で教育汁。

>>177
ぜひそうなって（　ﾟдﾟ)ﾎｽｨ…

>「昔出来たものがなぜ出来ない」という逆風はすごいだろうな。
いいとこ突きますな

>>177
強制的に、現場にアホを送り込むわけですな。。

不便なら不便なりに現場で工夫して慣れれば、結果コストダウン
になるのだが・・・

現場(ユーザー)も開発現場も様々ですね

こんなニュースがある一方で

【経済】４社に１社がＩＴ人材不足　主要企業アンケート
http://news2.2ch.net/test/read.cgi/newsplus/1052169651/

なんてニュースがあるのをみると、
つくづく情報システムの重要性とか、そもそもシステムという物の概念が
世の中的に理解されてないなーなんて思う。

街中で聞いて見ますた

システムというのはコンピューターのことです。　６３歳自営業
システムというのはコンピューターを繋げるとできます。　５９歳飲食業経営
システムというのは怖い世界です。機械・ロボットのイメージが強いです。　６６歳不動産業経営

>>180
単純な若年失業の構図。×以降がプーとかﾌﾘﾀｰね。
○院　×院院（ポスドク含む）
○大大大大　×大（試験浪人含む）
○高高高　×高高高高高高
職の有る香具師は、職を選ぶから大卒プーとか大卒ﾌﾘﾀｰになるって言うが、
製造業海外移転で肉体労働の選択肢は狭い≒若さ重視、
サービス業は見てくれ≒若さ重視、それでも高卒でも「マトモな就職」は難しい。
各層で確実に就業先は無くなっている。大卒プーとか大卒ﾌﾘﾀｰで難しいのは、
ぶっちゃけ階層があってｷｭﾃｰｲ出とかはｵﾓｷｼ逆差別受ける罠。

http://www.home-country.com/
http://61.115.1.12/bigin/index.html

中小企業じゃ情報部門は「第２総務部」だもんな。
実際、単なる雑用を依頼されるところも多いだろ？

>>187
漏れが昔就職した会社では「総務部・管理＆コンピューター部門」
だったよ。本社の社員数が数百人（ピーク時）の小企業だった。
実際、コンピューター部門に配属されたけど、雑用の方が多かった
な。187は正解だよ。アホらしくて辞めて良かったと思っているヨ。

スペシャリストとゼネラリストの定義が曖昧すぎ。

スペシャリストは専門に長けている人で
ゼネラリストは何でもある程度出来る人だと思ったが

例、
国語、英語、数学が50,50,1000…スペシャリスト
国語、英語、数学が80,80,80…ゼネラリスト

>>190　実際の会社での話ね。

ゼネラリスト：この開発を成功させるには、○○専務をまず口説き落として、工場の製造課長を味方に付けておくべきだと考える人。
スペシャリスト：この開発を成功させるには、○○回路の設計をxxのコストで成功させ、両面実装が出来る製造装置を導入することだと考える人。

まあ両方必要だけど

>>190
>国語、英語、数学が50,50,1000…スペシャリスト
数学だけ1000点満点なのか？(w

後４年後かあー。日本国は東アジア地域の
大英帝国状態。国力衰退している

英は世界の番長アメリカに媚び売って副番気取りだけど、日本は奴隷から
パシリに格上げされた程度だからなあ。

公務員が一番多く退職するのも2007年前後。

自治体が退職金を払いきれず財政破綻する危機が
迫っているのも2007年問題と称されてまつ。。。

この前まで、国と地方の借金あわせて700兆円だと思ってたら、
750兆円くらいまで膨らんでるらしいね。
一人頭、500〜600万くらいかな？
労働人口で換算すると、700万くらいまで跳ね上がるか？

団塊以上の方達は死ぬ前に借金返して死んでいってほしいね。

よく分からないんだが、一人あたりといっても実際みんなが平等に払って返すものなの？
税金として取られたものが返済にまわされるとすると、収入の多い人が少ない
人より払う形になるわけでしょ。７００万なんてどっちにしても持ってない人は払えないし。
そこら辺はどうなの？実際個人ローンみたいに支払い義務はつかないよね？？

>>1
コンピューター全部やめて手作業にしる！
雇用ふえまつ

>>198
換算すると、の話。

>>1
すべてオープン化→サーバこけまくりで金融不安→日本アボーン（ｗ

２０００年問題もどうにかなった。
今回もだいじょうーぶだろ？
ていうか、もう俺には関係ないし。
まあ、がんばってくださいな。

>>202
コンピューターの西暦2000年問題は、アホなマスコミが何も調べ
ずに、騒ぎまくっただけの話。実際、ハードに組み込まれている
部分とか、パソコンやワークステーション等で被害が出た部分も
あったが、メイン・フレームのアプリケーションではほとんど被害は
出なかった。というのも、メイン・フレームの主たるユーザーであ
る金融機関は、実は1980年代には西暦2000年問題が既に発生
していてソフト・メーカーはそれに対処してきたし、通産省も1991
年に、西暦2000年問題に対処するようにコンピューターメーカー
に通達を出していた。（この事をちゃんと報じたマスコミあるか？）
パソコンやワークステーション等に被害が出たのは、実は純粋な
国産パソコンはちゃんと対応していたのだが、Windows への移行
でアメリカ製のハードやソフトが市場を取って代わったから。

>>203
一部のマシンでは「昭和100年問題」が起こっているらしいぞ

スティーブンキング の IT

>>204
昭和100年、つまり2025年に問題になる。
それはさすがにリプレースされていると思うが。
……甘いか。

金融系なんざ、害人を呼んでこないとシステム動かない。

ねー、どこかの銀行さん

>>204
VBとかACCESSでつくったシステムでは2000年問題より、
2001年問題の方が深刻だったという・・・。

>>208　　┐(´-｀)┌

>>14
自主的にできない人間だからリストラされる。

>>203
世紀末はネタがなくても騒ぐのは当り前だ、馬鹿もの。
パソコンオタめ。

西暦2007年問題は全ての業種、社会制度にかかわる大問題。
ここを上手く通り過ぎれば明るい未来が・・・・
あるいは日本倒産。

2007年までには就職できるってことですか？

>>204
ス、スマン。「昭和100年問題」って何？
どういった原因でどんなことが起きるの？

11

>>211
203を読んで漏れをパソコンオタと決めつけるなんて、スゲーYO！
パソコンオタには書けないようなことを書いているのに。

ちなみに漏れはメイン・フレームからパソコンまで対応している
けどね。まっ、今の時代、IT関連の仕事するんだったら当たり前
のことだけどね。
（だから、1991年に通産省が出した通達のことを知っているんだ
よ。パソコンオタは、このこと知らないヤシばっかりだゾ。）

＞ベテランSEには力があった

だそうだ。
能力と体力の区別がついていない人は困るなあ。

あぼーん

>>203
それはあくまで銀行系の勘定システムの話だけだろう。
制御系のチップに関する問題はまた別の話だ。
とくに監視制御システムの画面表示に異常がでた場合、
誤った情報を元に制御を行い、問題ない状態からかえって危機的状況を
創出してしまうということが起こりうる。

実際、原発の一つで画面異常が発生して、危うく制御を行って
同上の状況を創出し、最悪の事態としてメルトダウンの危機まで存在した。

それが発生しなかったのは、異常が発生するというアナウンスが徹底されて
いたからであり、画面の異常を実際の異常と早とちりせずに運用で逃げを
打つことができたからである。もしも、再確認もなく制御を実施していたら・・・

一部、ホームページを立ち上げ偉そうに２０００年問題など起こるわけもないと
無知をさらけ出したジャーナリストがいたが恥ずかしい限りだ。（ﾆﾜｶ知識のせいとも言うが）
もうすこしでスリーマイル島事故と同じ状況が創出された可能性はあった。
スリーマイルの時は、部外者の運用専門家が制御室を見回し、異常を発見した。
内部の運用担当者はそのアラームは故障しているから表示されていると
信じて疑わなかったが。（柳田邦男の「スリーマイル島原発事故」のドキュメンタリーに詳しい）

埋め込みチップの２０００年問題が相当に危険視されていたが、複合要因で
問題が拡大しなかったようだ。実際、報道されていた２０００年問題は
実態のほんの一部であろう。運用や再起動で逃げたシステムはどのくらい
あったのであろうか。再起動またはデータ修正で回避可能な軽度の不具合の
総数は把握しているのだろうか？　いまだに、２０年時間を過去に戻して
稼働しているシステムもあるというから、そんなに簡単ではない。

>>214
西暦の下2桁ではなく昭和の2桁で管理しているから
昭和99年の翌年は昭和00年、ということになるってこと
だいたいは2000年問題と同じ

>>217
いやー、少なくともここで段階氏ねとかいってる
連中よりは能力があったと思うよ。

>>203 >>216
偏った理解しかしていないオタだと思うが・・
というか、2007年問題解決のネックになるタイプともいえる

>>219
> >>203
> それはあくまで銀行系の勘定システムの話だけだろう。
> 制御系のチップに関する問題はまた別の話だ。
そうだよ。203の３行目の中程から４行目にかけて書いた
>ハードに組み込まれている部分
っていうのは、そういう意味で書いたんだもん。

ま、オレが203に書いたことは、言葉が足りなかった部分がある
ので誤解しやすかったかもしれないことは認めるよ。

あと、スペースの関係であそこには書かなかったけど、マスコミ
特にテレビの報道を見ていて気付いたことがあった。それは、そ
れまでさんざん「コンピューターの中では全て「0」と「1」で表現を
している、つまり２進数が使われている」って言っていながら、西
暦2000年問題の時には、そのことを言わなかったこと。10進数
で西暦の下２桁しか使っていなくて、99+1を計算した時に桁上が
りした１が無視されて答えが０になってしまうとしても、それを２進
数で扱っていた場合には桁上がりは起きないんだよね。10進数
の99と100が２進数ではどういう数になるのか分かればすぐに分
かることで、計算結果をもとに判定をしたとしても２進数のままなら
大丈夫なんだけれどもね。
2000年問題の実態は報道されていない部分が多いのも事実だ
ね。不具合の総数も、程度別の数も、把握しているかどうか…。

>>220
223にも書いたけど、内部10進数を使っているとその危険はある
だろうけど、内部で純粋な２進数（固定小数点数で良いよ）を使っ
て計算や判定をしているのなら、大丈夫でしょ？

>>222
そうまで言うなら、キチンと根拠を示してよ。
オレはちゃんと範囲を限定して話をしているんだからさ。

オレのどこがどう偏った理解なのか？
2007年問題解決のネックになるタイプと判断した根拠は何？

このカキコに対し「粘着キモイ」等としか書かないのはやめてね。

>>219ってネタ？
いや、コンピュータを一寸でも知っているなら...

原発の制御システムとか核ミサイルとか日付で制御しているわけないだろう？
しかも、コボル？(W
少しは常識を...あ、無いからああいうことが書けるわけね。

まあ、２０００年問題の時は、自称「専門家」に大笑いさせてもらったからね。
ネタとしては貴重ではあったよ。

ここコンピューターの技術的な話だったの？
てっきり人的資本の引継ぎの話かと思ってたよ。

>>229
この程度の議論しかできない人材ばかりなので、
未来はとても大変というお話。

情報死すの板も似たような反応なんだろう・・・


だれか立ててみるか？

おれ情報処理試験用にしかＣＯＢＯＬ知らないけど
ＣＯＢＯＬで９９０６３０とか日付を記憶する変数って
文字型しかなかったんじゃないの？

>>232
ネタだとは思うが一応マジレスしておく。
まず、COBOLでは「変数」という言い方はしない。あくまでも「領
域」という言葉を使う。（これはＪＩＳの88 COBOLからそう決めら
れた。これをはじめとした用語の変更はCODASYLの 85 COBOL
から行われたので、JISでもそれに従っている。）

で、日付を格納する領域は、年・月・日とそれぞれを分けて使う
場合にはそれぞれを数字項目の基本項目として定義する。
それらの基本項目はバラバラに定義するのではなく連続した領
域として定義するのが一般的なので、上のレベルを作る。この
上のレベルで見た場合には、それらの連続した領域は英数字
項目と同等の扱いになる。（英字項目ではない。）

尚、通産省は1991年にコンピューターの西暦2000年問題に対
応させる為に、年の部分を４桁にするように通達を出しており、
メイン・フレームではハード側でもＯＳ側でもきちんと４桁に対応
している。アプリケーション・プログラムをCOBOLで作成する場
合も、本来なら年を４桁に対応させていなければならないのだ
が、それを知らないＰＧが多いのも事実。

なあ、人足りなくないのか？　職なし多いから人雇ってよ。

　　　　　　　　(~-~)

>>234
　人を足りなくしているのは企業。
　教育する手間を減らして即戦力とか
　もとめるからますます、ドツボにおちいる。

　人を育てられない企業(研修外注の企業)
　が最近やたら増えているけど、あれ問題。

サルの下に１００人配置してもまともなシステムはできない。
数でごまかそうって考えているうちは永遠に人が足りない。

>>228
素人さん？

あまり被害が無かったから今は笑えるけど、SEの端くれとしてやっぱ
当時は笑えなかったよ。何が起こるか分からないのが2000年問題だ
ったからな。

今もそうだが、昔から動いているシステムに機能アップし続けている
わけで、システムが入り組んできて、全体把握が困難な状況。

誰かがミスっていて変な電文を垂れ流しつづけたりしたら・・・
システム全体の誤動作は微妙にしろ、異常ルーチンに突入してシス
テムダウンさせることになり得る。その恐怖と言ったら！！

まああの当時、何も起きない、と保証できる
やつもいなかったからなあ。なんだかんだで
俺の友人連中も結構２０００年の正月はとまりこんでたよ。

>>238
なんだ、SEか。あんまりいい加減なことばかり言ってると、仕様教えないぞ。
そういえば、10年以上前にOS（メインフレーム）をやってたときに、2000年対策やったっけ。
社内通達があったのは覚えているが、お役所から通達があったかどうか覚えてねーな。

あぼーん

>>225
メインフレームは銀行だけが使ってるわけじゃねだろう
中堅企業ではいつ誰が作ったかわからんような化石みたいなシステムを必死こいて直しとったぞ。
PIC 9(7) packe-decimalの１桁目に１をいれてみたりとか、
メーカーＯＳにオプション提供してもらって50以上の方が小さく判定されるソートつかったりとかさぁ。
つまり現在も騙しながらつかっとるところ本当に多いと思うよ。
中堅企業の担当ＳＥだったおいらはヒーヒー言って対応したさ。。。
でも、それは９１年通達とやらがあったところで解決できるものではなかった。
ハイソウデスカと取り組めるようなコストも余裕もないからね。
ただでさえ、スパッケティコードになっとるシステムに場当たり的対応してきたわけで、さらにスパゲッティになったことだろう。
２０００年ターゲットにリニューアルした企業もあったが、殆どテストなしで強行なんてのもあった。
おいらの２０００年越しは綱渡りでした。中堅以下のところはみんなそんな感じだったんだろうね。
話は脱線するが、システムが２０００年超えられんので廃業したとこもあったさ。
>>219 のいうところの社会インフラに近いところはそこそこうまくいったみたいだけど、
もの凄い数がある体力のない中以下はグチャグチャでした。
さて、スッパゲッティの山とかした古き良きシステム達はどうなっていくんでしょうね。。。

銀行・官公庁系はドキュメントや業務系セミプロＳＥがいてスムーズに引き継ぎができる可能性があるけど、
いちばんイタイのは一般企業だろうね。解析一筋さすらいのＳＥみたいのが活躍しだすのかいな？

>>242
なるほど。キミが文章をキチンと読む事ができない人間だという
ことがよ〜く分かったよ。
なにが？と思っているだろ？あのね、私は203で
>メイン・フレームの主たるユーザーである金融機関は、
って書いたんだよね。つまり、メイン・フレームを使っているユー
ザーは色々あるが、その割合の多くを金融機関が占めている
と言っているんだ。それに対してキミは
>メインフレームは銀行だけが使ってるわけじゃねだろう
と言っている。金融機関＝銀行と思い込んでいて、その上さら
に「銀行だけ」と決めつけている。
こんなんじゃあ、話にならないよ。こっちが挙げた一つの例を
曲解し、さらにそれがこちらの知っていること全てだと思い込ん
で話を展開させているんだもんなぁ。少なくとも上記の203から
の引用の部分から、メイン・フレームの主たるユーザー以外の
ところではどうだったのか？という疑問を持って、それをぶつけ
てくれるようだったら、話もかみ合っただろうけどね。
まぁ、キミが2000年問題で大変な目にあった、ということは分か
ったよ。でもね、オレも金融機関以外の、いわゆる中小企業に
導入されているメイン・フレームのアプリケーションでのトラブル
も体験してきているんだワ。ただ、それをいちいち書いたらそれ
こそ収拾がつかなくなるし、もちろんその企業との契約上、外に
出してはならない部分もあるから、あくまでも一般論的な話で、
特に大手のユーザーである金融機関のことを出しただけのこと
なんだ。そのへんも分かって欲しいんだけど、できるかな？

>>243
いやあ、中小企業が導入したメインフレームのシステムは
確かになかなかすごいよ。
パソコンシステムの延長線上みたいなところがあって。
多少トラブルがあっても、手作業でなんとかしますわ。みたいなさ。

>>243
>銀行・官公庁系はドキュメントや業務系セミプロＳＥがいてス
>ムーズに引き継ぎができる可能性があるけど
うーん。まぁ、可能性はあるかもね。多少なりとも…。
ハッキリ言って、そういうところは大抵、大手のコンピューター・
メーカーのどこかが入っているんだけど、これがメーカーによっ
て千差万別なんだよね。下手すると、営業はメーカーの人間な
んだけど、実際のＳＥやＰＧなんかは、実はそのメーカーとつな
がりを持っている会社（いわゆる下請けね。）の人が、そのメー
カーの社名の入ったＩＤカードを着けていて、挨拶の時も○○の
△△です。と言ったりしてるなんてことが多かったりする。（もち
ろん、○○の部分はメーカーの名前であって、下請けの会社名
ではないです。）まぁ、そういったメーカーは、納期を何年も過ぎ
ているのにシステムが完成していなかったり、なんてことを繰り
返して、終いには発注元から契約を切られてしまったりしている
んだけどね。でも、発注元にしてみれば、大きなトラブルが発生
しているんだから、たまらないよね。
また、別のメーカーの場合、ドキュメントが中途半端で、最初に
担当した人が分かるのは当然なんだけど、引き継ぐ人にはあま
りよく分からなくて、後々トラブルが発生…なんてところもあるん
だよね。
まぁ、社名を出しちゃうと色々と問題が発生するから書かないん
だけど、分かりにくくなっちゃったかな。ゴメンね。

>>244
せっかくマジレスしてあげたのに、単語のアゲ足どりで終わりかよ。
>>246
チミはいつもテーマからそれていくんだね。
だから、ネックのタイプだと。。。

「つまらん、お前の話はいつもつまらん」

>>246
>納期を何年も過ぎているのにシステムが完成していなかったり

それはシステムを発注する側も悪い場合もあるよ。
一時期そういう仕事（製造）もやったことがあるが、仕様上明かに
おかしい点があって、問題点をあげているのに答が戻ってこなかったり、
それで作ってくれとか返事が返ってきたり。
案の定、テスト段階で問題が多発して、結局オクラ入りになったけどね。
間にはいってるSEが悪いのかもしれないがね。

基幹システムって具体的にどんな構成になってるのか消防にも
分かるように説明してくれ。

>>247
中小企業向けのＳＥさん、死ぬまでがんがってくらはい。

おまえががんばれ

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

age

団塊の世代から、上下で知識や文化を継承するっていう文化自体が
断絶しちゃっているからな。下が育ちにくい。
その上、年寄り連中が自分の知っている開発工程押しつけてくるか
ら業界自体の進歩が停滞気味。団塊本当にいらんよ。

知識の共有なんて、アメちゃんとかはＸＰとかまでやり始める位に真
剣に考えようってときに（ありゃ、米海軍の二直制みたいなもんで、
日本的発想だと効率悪いが、トータルコスト的には魅力があると思う）、
大手の駄目IT企業なんかは、書式はOOだけど、実態は未だにWFモ
デルなんて手法を使っているんだもんなぁ。

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

まんこ

その党利