アカウント名:
パスワード:
本当に必要なのは、COBOLを扱える人じゃなくて、COBOLで書かれた業務を把握している人なのであります。
業務を把握している人がいなくなる前に何とかしてください……
ほんとこれ。別にCOBOL自体は難しい言語じゃないんだけど、気の利いたことができない言語だから、複雑な業務が整理されないままプログラムになっていることが多い。（当時と今とではコーディング理論の成熟度が違っていることも重要なポイントかもしれない）なので、ロジックは読み解けても、何がしたくてこんなロジックになっているかが分からんのよね。
言語のせいで気が利かないのでは無く、時代的に構成管理や文書管理にDASDの1TRKだって使うのは正気の沙汰では無い頃で、
だから、わざと業務の整理をごちゃごちゃにしてでも、運用時に「一発で動く」事を優先にした作りにしているだけでは？（COBOLだって機能分割できる程度の事でも、構成で解らなくなるから、あえて別のロジックでもまぜこぜにしているとか）
古代のDevOpsの1つの到達点でしょう。（もちろんコーディング理論未成熟は認めますが。。。）
だから、わざと業務の整理をごちゃごちゃにしてでも、運用時に「一発で動く」事を優先にした作りにしているだけでは？
一応回答するとすれば、仰る通り情報資源上の制約によって複雑になっているものもあったし、そういうレベルじゃないものもあったね。色々な要因があったけれど、個人の経験として複雑な業務が整理されないままプログラムになっていることが多かった。金融系などの事情は知らないので、そこではまた別の状況があるかもしれないな。
実は業務を把握している人はいなくて, 目の前の業務を場当たり的に電算化していったものの集積が, 現在の「システム」と呼ばれているものの可能性も.
20数年前に大手製薬会社のシステム再構築の分析工程で下働きをしていたおりでさえ, 最も苦労していたのが業務を「分かっている」(「知っている」じゃないのが大切なところ)人を各部門から集めることだったので, リストラとかで知識散逸が進んだ今となっては, もはやロストテクノロジーと化しているのではないかと.
それって日本にたくさんいるらしいシステムエンジニアという人がやる仕事なのでは
# いるんだよね、そういう人？
現状のCOBOLソースやジョブから、業務仕様書を復元するサービスもあるらいですしね。
もう業務をパッケージに合わせてやり直したほうが早いんじゃないの？別会社を付くって運用してみて上手くいったらそちらに移管やったらいいのにね。手遅れになってからやっても、みづほみたいになるだけだし。
> もう業務をパッケージに合わせてやり直したほうが早いんじゃないの？
簡単に切り捨てられるもんなら、とっくにやっているｗ
> 手遅れになってからやっても、みづほみたいになるだけだし。
みずほの場合には、統合のため動いているシステムを短期間で置き換えたのが問題。なので、諸事情さえなければトラブルを出すことも無かった。つーか当時のJavaなんか使わなかったら、あんなトラブル起きなかったよ。。（あのスケジュールじゃ無理ってことで、断ったくちなんでｗ）
ちなみに、システム系だと新規物件でもCOBOLの需要があったりする。何件かやったけど、システム設計さえしっかりしていれば、他の言語よりCOBOLが採用されても不思議じゃないと思った。（後から手を入れたら、きっとひどい事になるんだろうけど）
>簡単に切り捨てられるもんなら、とっくにやっているｗ
必ずしもそうではないんだけどね。どの程度を簡単というかだけど、新しいトップと1年とか半年とか、そんなんでやりきっちゃう例が昨今もあるよ。
逆に「切り捨てられないわけがない」でしょ。そこに込められてるのは「なんかよく分かんないリスクがありそうだから触りたくない」であって、単なる思考停止に過ぎない。そういうこと自体がリスクであり、リスクを雪だるま式に増大させるわけで。
そんな独自性が高くて複雑な業務なんて有り得ませんがな。世界に似たような業務を行ってる会社がどれだけあるのか考えてみればいい。切り捨てられる例外を無理やりねじ込むから、無駄に複雑になってるだけだっつーのｗ
じゃあ金融業界来てみなさいな。
おまいさんが本物なら革命児になれるぜ
業務を変える →絶対に無理システム開発は無理 → やれ。
日本企業はここからしておかしいよね。
曾孫引用 [nifty.com]ですが。
IBMによって企画された6ヶ月にわたる調査で保守プログラマが「最も たいへんな問題点はプログラムの原作者の意図を理解することであった」 とわかった(Fjelastad and Hamlen 1979)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
本当に必要だった物 (スコア:5, すばらしい洞察)
本当に必要なのは、COBOLを扱える人じゃなくて、
COBOLで書かれた業務を把握している人なのであります。
業務を把握している人がいなくなる前に何とかしてください……
Re:本当に必要だった物 (スコア:5, 参考になる)
ほんとこれ。
別にCOBOL自体は難しい言語じゃないんだけど、気の利いたことができない言語だから、
複雑な業務が整理されないままプログラムになっていることが多い。
（当時と今とではコーディング理論の成熟度が違っていることも重要なポイントかもしれない）
なので、ロジックは読み解けても、何がしたくてこんなロジックになっているかが分からんのよね。
Re: (スコア:0)
言語のせいで気が利かないのでは無く、時代的に構成管理や文書管理にDASDの1TRKだって
使うのは正気の沙汰では無い頃で、
だから、わざと業務の整理をごちゃごちゃにしてでも、運用時に「一発で動く」事を優先にした
作りにしているだけでは？
（COBOLだって機能分割できる程度の事でも、構成で解らなくなるから、あえて別のロジックでも
まぜこぜにしているとか）
古代のDevOpsの1つの到達点でしょう。（もちろんコーディング理論未成熟は認めますが。。。）
Re: (スコア:0)
だから、わざと業務の整理をごちゃごちゃにしてでも、運用時に「一発で動く」事を優先にした
作りにしているだけでは？
一応回答するとすれば、
仰る通り情報資源上の制約によって複雑になっているものもあったし、
そういうレベルじゃないものもあったね。
色々な要因があったけれど、個人の経験として複雑な業務が整理されないままプログラムになっていることが多かった。
金融系などの事情は知らないので、そこではまた別の状況があるかもしれないな。
Re:本当に必要だった物 (スコア:5, すばらしい洞察)
実は業務を把握している人はいなくて, 目の前の業務を場当たり的に電算化していったものの集積が, 現在の「システム」と呼ばれているものの可能性も.
20数年前に大手製薬会社のシステム再構築の分析工程で下働きをしていたおりでさえ, 最も苦労していたのが業務を「分かっている」(「知っている」じゃないのが大切なところ)人を各部門から集めることだったので, リストラとかで知識散逸が進んだ今となっては, もはやロストテクノロジーと化しているのではないかと.
Re:本当に必要だった物 (スコア:2)
Re: (スコア:0)
それって日本にたくさんいるらしいシステムエンジニアという人がやる仕事なのでは
# いるんだよね、そういう人？
Re:本当に必要だった物 (スコア:1)
現状のCOBOLソースやジョブから、業務仕様書を復元するサービスもあるらいですしね。
Re: (スコア:0)
もう業務をパッケージに合わせてやり直したほうが早いんじゃないの？
別会社を付くって運用してみて上手くいったらそちらに移管やったらいいのにね。
手遅れになってからやっても、みづほみたいになるだけだし。
Re:本当に必要だった物 (スコア:2, 興味深い)
> もう業務をパッケージに合わせてやり直したほうが早いんじゃないの？
簡単に切り捨てられるもんなら、とっくにやっているｗ
> 手遅れになってからやっても、みづほみたいになるだけだし。
みずほの場合には、統合のため動いているシステムを短期間で
置き換えたのが問題。
なので、諸事情さえなければトラブルを出すことも無かった。
つーか当時のJavaなんか使わなかったら、あんなトラブル起きなかったよ。。
（あのスケジュールじゃ無理ってことで、断ったくちなんでｗ）
ちなみに、システム系だと新規物件でもCOBOLの需要があったりする。
何件かやったけど、システム設計さえしっかりしていれば、
他の言語よりCOBOLが採用されても不思議じゃないと思った。
（後から手を入れたら、きっとひどい事になるんだろうけど）
Re:本当に必要だった物 (スコア:1)
>簡単に切り捨てられるもんなら、とっくにやっているｗ
必ずしもそうではないんだけどね。
どの程度を簡単というかだけど、新しいトップと1年とか半年とか、そんなんでやりきっちゃう例が昨今もあるよ。
Re:本当に必要だった物 (スコア:1)
逆に「切り捨てられないわけがない」でしょ。
そこに込められてるのは「なんかよく分かんないリスクがありそうだから触りたくない」であって、
単なる思考停止に過ぎない。
そういうこと自体がリスクであり、リスクを雪だるま式に増大させるわけで。
そんな独自性が高くて複雑な業務なんて有り得ませんがな。
世界に似たような業務を行ってる会社がどれだけあるのか考えてみればいい。
切り捨てられる例外を無理やりねじ込むから、無駄に複雑になってるだけだっつーのｗ
Re: (スコア:0)
じゃあ金融業界来てみなさいな。
おまいさんが本物なら革命児になれるぜ
Re: (スコア:0)
業務を変える →絶対に無理
システム開発は無理 → やれ。
日本企業はここからしておかしいよね。
Re: (スコア:0)
曾孫引用 [nifty.com]ですが。
IBMによって企画された6ヶ月にわたる調査で保守プログラマが「最も たいへんな問題点はプログラムの原作者の意図を理解することであった」 とわかった(Fjelastad and Hamlen 1979)。