パスワードを忘れた? アカウント作成
7523263 story
プログラミング

70~80年代のCOBOLシステムを支えたプログラマの引退が近づいているが、システムは動き続ける 114

ストーリー by hylom
そしていつかはロストテクノロジーに 部門より
taraiok 曰く、

1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。実際に1970~1990年代に書かれた細かなCOBOLプログラムのほとんどは新しいシステムと新しい技術に置き換えられている。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。

ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという(ITWORLD本家/.)。

今は大学のプログラム講座などでは教えることがなくなったCOBOLだが、今後数年間でCOBOLプログラマは高い需要が発生する可能性があるとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 本当に必要だった物 (スコア:5, すばらしい洞察)

    by Sukoya (33993) on 2013年02月15日 18時25分 (#2326138) 日記

    本当に必要なのは、COBOLを扱える人じゃなくて、
    COBOLで書かれた業務を把握している人なのであります。

    業務を把握している人がいなくなる前に何とかしてください……

    • by Anonymous Coward on 2013年02月15日 18時51分 (#2326161)

      ほんとこれ。
      別にCOBOL自体は難しい言語じゃないんだけど、気の利いたことができない言語だから、
      複雑な業務が整理されないままプログラムになっていることが多い。
      (当時と今とではコーディング理論の成熟度が違っていることも重要なポイントかもしれない)
      なので、ロジックは読み解けても、何がしたくてこんなロジックになっているかが分からんのよね。

      親コメント
    • Re:本当に必要だった物 (スコア:5, すばらしい洞察)

      by SteppingWind (2654) on 2013年02月15日 20時28分 (#2326223)

      実は業務を把握している人はいなくて, 目の前の業務を場当たり的に電算化していったものの集積が, 現在の「システム」と呼ばれているものの可能性も.

      20数年前に大手製薬会社のシステム再構築の分析工程で下働きをしていたおりでさえ, 最も苦労していたのが業務を「分かっている」(「知っている」じゃないのが大切なところ)人を各部門から集めることだったので, リストラとかで知識散逸が進んだ今となっては, もはやロストテクノロジーと化しているのではないかと.

      親コメント
    • と言うか、PGやジョブと業務の紐付けがちゃんと出来て、他人に説明が出来る人が欲しいのでは。
      親コメント
    • 現状のCOBOLソースやジョブから、業務仕様書を復元するサービスもあるらいですしね。

      親コメント
  • 大昔にみんなが掘れるだけ掘ってうち捨てられた金鉱に住み続けて、
    金の価格が上昇してまた採掘がペイする時期をじっくり待つような感じかな。
    その仕事をやる人が減れば減るほど希少価値が出ておいしくなる。

    保守部品のゲルマニウムトランジスタとか、
    カッターに駆逐されたはずなのに1社だけ作り続けられている「肥後守」とかも似てますね。

    でも、構造化もオブジェクト指向も無かった時代に作られたCOBOLのメンテナンスは厄介だろうなぁ。

  • COBOLみたいな初等的な(しかも理解が易しい)言語は、いざとなったら誰でもできるんじゃないの?C++やJavaなんかと比べると言語仕様は圧倒的にコンパクトなはずだよね。一時的な上昇はあったとしても、そんなに進んで修練するほどの言語だとは思わないなあ。

    • by nmaeda (5111) on 2013年02月15日 19時48分 (#2326194)

      平均的なプログラマなら、2,3日あれば、とりあえずコードは書けるようになる。大学や工業高校・商業高校における教育は、平均的なプログラマの2,3日以下の内容だ。(プログラマに向いていない人は、諦めて別の職業に就くわけだ)

      けれども、大昔に書かれた大量のコードを読んで、それを理解することは、それとは別の次元の話。大昔のメインフレームに合わた、今では廃れたテクニックも多用されているだろうし、それは泥臭い仕事。

      親コメント
    • by Anonymous Coward on 2013年02月15日 20時09分 (#2326209)

      10年位前に某金融機関のシステム更新でCOBOLの部分を追っかけた事があるが、ぶっちゃけこんな感じ。

      「やってることは判るが
       やってる意図が分からない」

      で、いろんなところを訪ねてまわると、「ああ、それは○○の××さんに聞けば判るよ」と。
      タクシー飛ばしていくと、遙かな昔の会議の席上でのやりとりで○○さんの顔を立てる為に云々って
      アンドキュメントな事が理由だったと…。
      仕様じゃ無いけどしょうがないからみたいな。
      そんなんばっかり。

      親コメント
    • 言語自体はわりと簡単だけど
      何したいのか理解し難い言語かも?
      だらだら回りくどく書いてるし、時代によっては難解なGOTO文の使い方したり。
      なんつーか読む気力が失せてくるかんじ。

      昔はCOBOLで書いたときもあったけど、
      オブジェクト思考言語で慣れちゃってから読むのはとても辛いです。

      Cも同じく回りくどいし難解な部分もあるけど、
      Cじゃないとってところで使われているからテンション下がらないんだけど。

      親コメント
    • COBOL自体は簡単なんですよ。
      比較的自然言語(英語)に近い構文で、何をやってるか理解しやすいですし。

      ただ、仕事でCOBOLにかかわった人にのみ解る、新の恐ろしさがあるんですよ。

      それは・・・変数が 英字+連番 で、台帳管理されていること・・・

      せっかく構文が英語なのに、変数が記号なんですよね。
      おかげで可読性が高いというメリットが完全に殺されて、
      記述が冗長なデメリットがさらに強調されている。
      もうアホかと・・・

      親コメント
    • by SteppingWind (2654) on 2013年02月15日 21時57分 (#2326297)

      COBOL言語を覚えればCOBOLプログラミングが出来るように語るのは, 実用的なプログラミングを作ったことが無い証左のようなものです.

      COBOLは確かに初等的な言語であるゆえに, システムにアクセスする部分, 例えばデータベースアクセス, 通信, ユーザインターフェイスといったところは, 全てメーカが提供するライブラリに依存します. そのため, COBOLで実用的なプログラムを書くためにはCOBOL自体に加えてそれらライブラリが何をするのか分かっていなければなりません. しかもライブラリはメーカ・OS毎に互換性が無く, 性能や実装に基づくバッドノウハウが山盛り. また言語が初等的であるがゆえに抽象化や隠蔽などのテクニックが使えず(せいぜいマクロプリプロセッサが使えるくらい), 呪文化されたバッドノウハウコードがダイレクトに散りばめられていることが多々あります. データベースに至っては, 下手すりゃCODASYL型DB [nikkeibp.co.jp]だったりRDBであってもSQLを使わない独自APIだったりするので, 今日的な技術知識では歯が立たないことも.

      # というのを傍から見ていただけなのが私の幸運

      親コメント
    • まあ、COBOLそのものは大したことないってのは同意ですが、

      そんな初等的な言語で、複雑な業務をこなせるようなソースコードが書かれ、
      初等的な言語にありがちな小手先のテクニックで最適化され、メンテされていた。

      と想像すると、結構怖いです……

      親コメント
    • 40歳前後の人なら、2000年問題対応時にCOBOLプログラムの改修やテストをを担当した人も結構いるのでは。
      自分もCOBOLのソースを追いかけたことがあるけど、REDEFINESには結構泣かされました。
      親コメント
    • by Anonymous Coward

      COBOLをVB6に置き換えて考えてみよう…
      COBOLやVB6に比べればC++やJavaの方がよっぽど優しいかもよ
      #すごくうんざりした気分になった

  • その引退するというプログラマに、最後の仕事としてそのシステムの仕様書を書かせればいいだけでしょ

    #結局、問題の原因はCOBOLじゃなくて、仕様がハッキリしないことでしょ
  • by Anonymous Coward on 2013年02月15日 20時42分 (#2326238)

    前も、2007年問題とか言って、ほとんど同じ話が出てたよね。
    確かにその前あたりから、COBOL置き換え系の仕事は、多いと言えば多いかな。

    最近も、COBOLのプログラムを解読してデータを移行したりしてたけど、どっちかと言うと言語以外のところの方が苦労は多かったかな。計算の精度が妙に低いロジックになってて、結果が合わないとかね。
    (仕様書っぽいものはあったけど、ご多分に漏れず、理由の分からない謎仕様が多い)

    #次はRPGらしい。負けるな、俺
    #このコメントは、ただの愚痴なんだ。すまん

  • by Anonymous Coward on 2013年02月15日 21時42分 (#2326285)
    当時は総ステップ数で価格が決まっていたりすることもあり、エレガントに書くと実入りが減るとか、
    システムによる効率化もユーザーがよくわかってなかったり、
    あんまり効率よくなると人要らなくなるじゃんとかそういう理由であえて不便さを残したりしている場合もあり、そういうのがソースコードの混乱に拍車をかけている気がするよ。

    #COBOLがすべてそうって訳じゃないけど、そういうところは確かにあった
  • 自分はCOBOLなんて観たことも触れたこともありませんが・・・(大学の図書館の廃棄本の山から本だけ拾ってきたが触らずじまい)
    「ちゃんと動いている」ような環境の保守の継続が必要という、ひとつの需要があるならば、そういった言語を動かせるハードの需要なり、ソフトそのまま移行できるような手法なり用意して専業にする人も一定数は出てくるんじゃないでしょうか?

    #
    何にせよ置き換えって難しいですよね。
    『その要求は何の為にあるんですか?』
    客「前のプログラマはつべこべ言わず全部やってくれたぞ!」⇒スパゲティ。みたいな、、、
    --
    ----- ド素人につき突っ込み歓迎 アルミ製なので叩くと凹みます
  • by Anonymous Coward on 2013年02月15日 18時27分 (#2326139)

    あのときの若手のIT土方たちはどうした?

typodupeerror

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

読み込み中...