アカウント名:
パスワード:
次世代に受け継ぎたいのは COBOLer じゃなくて業務知識を適用できる人材。
業務知識がある、COBOLが使える、安く使える発注側は選べるのは最大でを二つかなー
COBOLの頃の文書は手書き(鉛筆書き)で、業務知識のある程度以上の詳細な部分をきちんと書こうとは出来なかったと思う。なので仕方なくCOBOL言語自体に業務知識を書き込んでいた。
オープン化と時を同じくして文書も電子文書に出来る様になり、筆耕の出来る人以外でも文書を発行できる様になった。だから仕様文書を正にして、プログラムは従に出来る様になった。
ところが自然言語で書いた仕様文書はその意味を人間同士の相互理解によって成り立たせているので、その意義が明確な場合は「解りやすい」、「平易な」表現になるけれど、いったん業務知識のある程度以上の詳細な部分になると、一転して意義がつかめず意味が発散してしまう。
ああ、COBOLの様なプログラムの業務記述が正だ、の方が簡便だったなとか言う事もあるのでは無いでしょうか?
#今となっては引かれ者の小唄でしか無いですけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
顧客が本当に望んだもの (スコア:0)
次世代に受け継ぎたいのは COBOLer じゃなくて業務知識を適用できる人材。
Re:顧客が本当に望んだもの (スコア:1)
「人月」
COBOL知識も業務知識もない人でも1人月
# yes, fly. no, fry.
Re: (スコア:0)
業務知識がある、COBOLが使える、安く使える
発注側は選べるのは最大でを二つかなー
Re: (スコア:0)
COBOLの頃の文書は手書き(鉛筆書き)で、業務知識のある程度以上の詳細な
部分をきちんと書こうとは出来なかったと思う。
なので仕方なくCOBOL言語自体に業務知識を書き込んでいた。
オープン化と時を同じくして文書も電子文書に出来る様になり、筆耕の出来る
人以外でも文書を発行できる様になった。だから仕様文書を正にして、プログラム
は従に出来る様になった。
ところが自然言語で書いた仕様文書はその意味を人間同士の相互理解によって
成り立たせているので、その意義が明確な場合は「解りやすい」、「平易な」
表現になるけれど、
いったん業務知識のある程度以上の詳細な部分になると、一転して意義がつかめず
意味が発散してしまう。
ああ、COBOLの様なプログラムの業務記述が正だ、の方が簡便だったなとか
言う事もあるのでは無いでしょうか?
#今となっては引かれ者の小唄でしか無いですけど。