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

東京海上日動の新システムはCOBOLを採用 181

ストーリー by hayakawa
COBOLに問題があるのではない、COBOLでかかれたコードに問題があるんだ 部門より

Anonymous Coward曰く、

日経ITproの記事によると、東京海上日動が2008年5月に完成させた新自動車保険システムでは、開発言語としてCOBOLを採用しているそうだ。このシステムは処理量や信頼性,既存システムとの連携面からメインフレームで稼働させ、システムのビュー部分はJavaで、モデル部分はCOBOLで開発しているとのこと。COBOLを選択した理由は、部品化とシステム構成のシンプル化を実現しやすいからだそうだ。

東京海上日動システムズの稲葉取締役によると、「30年システムに携わっているが,COBOLは規格として長期間安定し,ビジネスロジックの書きやすさにおいては右に出る言語はない」とのことで、旧システムからのプログラムの流用ができたことも開発の効率化に寄与したそうだ。また同氏は「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは化石”などと話している人を見ると,ビジネスに携わる技術者として見識を疑う」とも述べている。

確かにCOBOLといえば古くさいイメージはあるが、金融業界ではまだまだ現役なのも事実。/.erの皆さんは、COBOLについてどのようなイメージを持たれているだろうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 死ぬかと思った。
    紙ベースのデバッグって一体何十年前の話だよ。
    レビューを紙でやるのは別に構わないけど、デバッグが紙って……orz

    今はWeb系の仕事をしているので幸せです。
    #一応補足として、ちゃんとコンパイル通る/通らないのチェックぐらいはできましたよ
    #でも、コンパイル通す「前」に一旦ソースを印刷してデバッグしてました
    #当時の上司が、何度もコンパイルかけるとホストの負担が大きいからやめてねって言ってました
    #そりゃあ、あんだけ長くマシン使ってればねぇ……。
    --
    あなたとコンビにふぁみりま~と♪
  • つまり (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2008年09月09日 12時30分 (#1417879)
    >旧システムからのプログラムの流用ができた

    ここがミソなんじゃないの?
    スクラッチから作るのと、既存のシステムを流用した場合のトレードオフ。
    部品化なんてオブジェクト指向言語ならどれでもできるわけだし、
    そもそも言語なんて手段に過ぎない。
    プログラム言語の性質で開発手法を語るのはどうかと思うのだが。。。
  • by Anonymous Coward on 2008年09月09日 12時58分 (#1417908)
    理由は慣れだって
    COBOLしかやってこなかった連中に他の言語勧めるのは難しいでしょ
    年齢的な意味でも
    • by yellow tadpole (7084) on 2008年09月09日 15時45分 (#1418036) 日記
      >理由は慣れだって

      まったくそのとおり。COBOLの人は事務処理ばかりやってた。だから他の言語の
      エンジニアより事務処理の事を非常によく知ってる。
      COBOLerの下に付くとCOBOLと同時に事務処理も教えてもらえるよ。

      今時メインフレームでCOBOL使ってるって事は、COBOLと勘定系を両方知ってるって事なんだよね。
      (業務系はさすがに少ないと思う)
      JAVAやCのエキスパートなら、これは確実に知ってるだろう、慣れてるだろうって業務はないでしょ?
      その差が大きいんだと思うよ。
      --
      〜◍
      親コメント
  • COMP-5 (スコア:3, 興味深い)

    by Anonymous Coward on 2008年09月09日 13時04分 (#1417912)

    COBOLの数値って、十進数が直接扱えて必要な精度を指定できるから金計算向けだとはいいますけどね。
    でも言語仕様としてはCOMP-1, COMP-2, COMP-3, COMP-4, COMP-5なんて謎の処理系というかハードウェア依存な形式がまかりとおっていて互換性は低いしわけわかんないよね。

    この東京海上日動システムズの稲葉茂 取締役のおっしゃることに関してはさ、

    このため同社は部品化とシステム構成のシンプル化に最も重きを置く。「COBOLはそれを最も実現しやすいと実証している。なぜなら5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。
    ってのは、結局その会社のローカルコーディングルールを厳密に定めてごく狭い範囲の機能・パターンしか使用しないことに限定することでシステムをシンプルにして保守性やモジュールの流用可能性を確保したってことだよね。 それって言語の問題ではないと思う。 強いて言語に関係ある点をあげれば、その言語の持っている機能が貧弱すぎるか、もしくはその言語をフルに使いこなしたがる技術者がいないってことかな。 これは Java や C++ では確かに無理だわ。みな好きに書きたがる。 COBOLが主流だった時代はコンパイルどころかパンチの前にコードレビューするのも普通だったからそれでよかったんだろうし、今となっても

    モデルはベテラン中心にCOBOLで開発していく
    からそれで済んでいるんだよね。 でも、この体制で開発したんじゃ

    「開発1年・保守10年」
    なんてできるのかな。大いに疑問。

    COBOLの将来はまだまだ明るい
    なんて、この人の話を信じる限りはありえないでしょ。 せいぜい限定用途では生き延びていく、くらいかな。この人の場合はサラリーマン人生そのものがその限定用途の中にすっぽりおさまっちゃってるからそれでいいのかもしれんけどね。 まあ、

    「25年の間,システムの利用範囲は外に外にと広がっていった。そのたびに改修を加え,システムは本館の横に別館を建て増し,それを渡り廊下でつなぐような複雑な構造になった。保険商品も保険料の支払い方法もどんどん増え,それに伴いシステムは複雑さを増した」という。ビジネス面でこれらをお客様目線で見直し,シンプルにわかりやすくするのが,今回の抜本改革だ。
    って、要はリファクタリングをもって抜本改革なんて呼んじゃっているわけだし。
  • by Anonymous Coward on 2008年09月09日 12時23分 (#1417867)
    Callのように使えたり、Gotoだったり、ループ制御だったりする、PERFORM

    # ひとり一項目縛りです
  • by Anonymous Coward on 2008年09月09日 12時39分 (#1417891)
    PerlだのPHPだのが中心でちょっとJavaかじった程度の者ですが・・・。
    あるシステムに対する特定言語の優位性ってほんとにあるんですか?
    慣れや扱いやすいさ、関数の充実などはもちろんあると思うのですが、
    なぜ「金融系はCOBOL」なのかとかよく分からんのですよ。

    ついでに言うとPerlだRubyだPHPだというのも
    最終的には「どれでも一緒じゃん」と思ってしまうのはダメな人なんですかね?

    いろんな意味での環境(人、ものなど)が基因で
    案件毎に特定の言語の優位性があるってのは分かるんですけど。
    何をもって「この言語がいい!」となるのか是非知りたいです。
    • by Anonymous Coward on 2008年09月09日 13時05分 (#1417913)
      ×「ビジネスロジックの書きやすさにおいては右に出る言語はない」
      ○「ビジネスロジック*以外*の処理に気を遣わなくていい(から書きやすい)」
      と言うところが本意でしょうね。

      親コメント
    • by Anonymous Coward on 2008年09月09日 13時06分 (#1417915)
      複素数が扱えるfortranは、科学技術計算で他の言語に比べて優位。

      c++だと複素数のクラスライブラリーとか作れるわけだが、あまり使ったことはない。

      # ちなみにcしか使わん私は、複素数の計算はすべて手計算で実数に展開する。

      親コメント
    • by 127.0.0.1 (33105) on 2008年09月09日 14時55分 (#1418007) 日記
      >ついでに言うとPerlだRubyだPHPだというのも
      >最終的には「どれでも一緒じゃん」と思ってしまうのはダメな人なんですかね

      初心者がちょっとかじっただけで「どれでも一緒じゃん」と思うのと
      達人がいきついた果てに「どれでも一緒じゃん」と悟るのはたぶんなんか違う。
      本物の達人なら「適材適所」と言うと思うけど。
      達人にはなったことないから脳内シミュレーションね。
      親コメント
    • by Anonymous Coward on 2008年09月10日 7時44分 (#1418475)
      とりあえずTck/Tkをやってみなさい。言語のシンプルさがグルー言語として特化していることを感じられるから。
      Cは組み込みで使ってみなさい。コンパイラの作りやすい言語系のおかげでCPUを選ばないから。
      C++は極限性能を求める大きなプログラムを書くときに使いなさい。テンプレートマクロによる高速化が使えるから。
      C#はWindows GUIプログラムに使いなさい。綺麗さと汚さのバランスが実用的だから。
      VBはGUIの使い捨てプログラムに使いなさい。作成速度の初速は一級品だから。

      その他にもハードウェア系の言語(VHDLとか)もやってみなさい。
      言語で「配線」を記述することで、同時実行の極地に至れることが分かるでしょう。

      # 言語が環境を作るのか、環境が言語を作るのかは分からないが、環境と言語は不可分なんだと思う
      親コメント
    • by Anonymous Coward on 2008年09月09日 14時35分 (#1417989)
      > ついでに言うとPerlだRubyだPHPだというのも
      > 最終的には「どれでも一緒じゃん」と思ってしまうのはダメな人なんですかね?

      その三つであればよほどの信者以外は「どれでも一緒じゃん」と思うのが普通です。しかし、あまりにも似た三つだけ(Javaは置いといて)を知っているからといって、他の言語も一緒か?などとは思わないように。
      親コメント
  • by hogetsuyoshi (14204) on 2008年09月09日 12時48分 (#1417898)
    今更COBOL使うのなんって、現在の資産の流用以外メリット無し。

    「ビジネスロジックの書きやすさにおいては右に出る言語はない」って言わなきゃ良いのにね。

    今利用されている言語は、COBOLの遙か上にいるので、右にも左にも対抗言語はいません。
    • by ksiroi (24990) on 2008年09月09日 13時12分 (#1417920) 日記
      そもそもビジネスロジックって単語を持ち出して言語比較すること自体がナンセンスじゃないの?とは思う。
      あれってbuzzwordじゃないの?
      仕事上で何度が聞いたことあるけど 大抵それを喋る奴って二流だし、自分が何言ってるか把握してないし。

      // 馬鹿とハサミは使いようと申しまして・・・(:>^
      親コメント
  • by shadowfire (6584) on 2008年09月09日 13時30分 (#1417936) ホームページ
    もう20年以上前、新人の頃に少しだけCOBOLの仕事をやりましたが、
    先輩曰く
    「COBOLは、MOVEとIFとPERFORM知ってりゃ何とかなるよ」
    と。
    新人で重要な処理の部分は任されなかったのでまさにその通りでした。

    しかし、それから幾つか言語を覚えましたけど、
    どの言語の仕事でも、結局やってることのほとんどは
    MOVE(値の移動)とIF(条件分岐)とPERFORM(関数等の呼び出し)だなあ、
    なんて思います(後はLOOPくらい?)。
    まあ、私のところにそんな難しいロジックのいる仕事が来ないってこともありますが。

    --
    --------------------
    /* SHADOWFIRE */
  • by shoji12 (14093) on 2008年09月09日 13時52分 (#1417954)
    大金をはたいてメインフレーム以下OSやRDBMSを購入すると、いわゆる高級言語を使わざるを得ない、ということかな。
    心臓部の統計処理は、COBOLで書いているのか?
    おかげで、見た目のシンプルさは実現できるし、メインフレームメーカは儲けるし。
    しかし、どう転んでも、全ての資金源はお客さんが支払う保険料だから、お客さんにとってCOBOLを使うとどんなメリットがあるかという話が聞きたいな。
    保険料がお安くなりますようーみたいな。

  • by yukichi (12361) on 2008年09月09日 17時09分 (#1418105) ホームページ
    COBOLを使う事は必ずしも推奨される事ではないが、COBOLについて語り合う事は多くの人が好きなんだ、ということですね。
  • by Anonymous Coward on 2008年09月09日 12時30分 (#1417880)
    >「30年システムに携わっているが,COBOLは規格として長期間安定し,ビジネスロジックの書きやすさにおいては右に出る言語はない」
    という開発人員を沢山抱え込んでいて、切り捨てられないというのが、本音だろう。
  • by Anonymous Coward on 2008年09月09日 12時35分 (#1417887)
    COBOLの何がそんなに事務処理に良いんでしょうか?
    実績が最大の評価なのはわかるんですが。

    文字フォーマットのしやすさ?固定小数点演算?
    そんなの使えない言語探すほうが難しいと思うんですが。
    あえて確保と教育が面倒なCOBOLを選ぶほどのメリットがあるとも思えないんですが。

    ちなみに仕事で使ってないだけで(試験用として)COBOL自体は知ってます。
    • by Tig3r (17335) on 2008年09月09日 12時43分 (#1417893) 日記
      私見ではありますが、COBOLの何が事務処理に向いてるのかと申しますと、
      COBOLの持つ機能ではなく、COBOLが持たない機能が多いおかげで、事務屋が
      事務屋の目線で使える言語である、ということなのではないかと思います。

      台帳と伝票を中心とした、画面も印刷も一時記憶も、すべてレコードの
      概念で取り扱うことができ、
      「この画面で入力された内容が、この伝票の一行になる」
      「この伝票をこういう風に転記しつづけると、この台帳になる」
      「この台帳の一行が、レポートの一行になる」
      のが、見やすいのではないかと思います。

      基本的には、とにかく伝票から台帳、台帳から台帳へ転記するルールのみを
      延々と、しかも自然言語に近い冗長な記述で書いていく言語ですから。

      --
      -- Tig3r on the hedge
      親コメント
      • by USH (8040) on 2008年09月10日 4時27分 (#1418459) 日記
        そもそも、会計処理というそこそこ複雑な処理を、紙という非常に制約のきついハード上で記録したり処理したりするために、台帳とか伝票とかが摩訶不思議なものが産み出された。でもって、その摩訶不思議なものを、紙という制約がない計算機にわざわざ構築したのが COBOL って感じかなぁ。

        別に歴史ある会計処理を全否定する積もりはないが、なぜそうなっているか考えもせずに「ビジネスロジック」とかいう言葉で、そのままコピー・延命させるのもどうかと。

        役所に出す書類、なぜこの数字がここなんだ、というのが、あちこちあって困る。
        しかも問い合わせても、すんなり分かる説明を受けたためしがない。
        親コメント
      • by Anonymous Coward on 2008年09月09日 13時27分 (#1417935)
        禿しく同意します。
        昔、メインフレームのダウンサイジングで盛り上がっていた時に、Java バッチとか作ったことがありますが、帳票出力だとかがめんどくさいことこの上ない。
        Java が「なんでも出来る」おかげで、実際の処理とは無関係な手続きの方が長いんじゃないか?ってくらいに。
        # クラスライブラリなりを整備しろよってな話ですが。

        適材適所って大事だなと痛感した一件でした。
        ただ単にファイルの内容をあっちやったりこっちやったりするなら、やっぱり COBOL は楽です。何も考えなくて良い。
        この程度なら、JCL + COBOL Script 的なものがあれば便利かも…って微妙かな。

        まぁ、メインフレームでやるならの話ですが。UNIX 環境なら Perl なり Ruby で書いちゃった方が楽ですし。
        # やっぱり COBOL はいらない子?
        親コメント
    • by Anonymous Coward on 2008年09月09日 13時02分 (#1417910)

      文字フォーマットのしやすさ?固定小数点演算?
      そんなの使えない言語探すほうが難しいと思うんですが。

      標準で(外部ライブラリなどを使わず)、十数桁の金額の計算を、想定外の丸めなどを起こさずに十進で銭単位まできちんと計算できる言語って、そんなにたくさんあります?

      # いくつかは知ってますが。
      親コメント
    • by Anonymous Coward on 2008年09月09日 12時57分 (#1417906)
      BCD演算がベースな言語だから金勘定では他の追随を許さない安定性がある。
      他の言語でもできない訳ではないが、初めからそれと、後付けの差は大きい。
      まあ画面周りとかは他の言語でもいいけどさ。
      親コメント
      • by Anonymous Coward on 2008年09月09日 13時08分 (#1417918)
        一番大きいのはやっぱこれだろうな
        何も意識せずとも二進数由来の制限と無縁でいられる
        要するに「そろばんや電卓での処理」をそのままプログラムに落とし込めるのよね
        だから金融系のビジネスロジックと非常に相性がいい
        親コメント
      • by Tatenon (20311) on 2008年09月09日 13時21分 (#1417927) 日記
        私もここに一票。

        コンピューターの知識が十分に無い人にとって、2進数とか16進数がもっとも難解なもの。
        しかも符号とか型とかが関わるともうなにがなにやら。

        帳票の扱いやすさも大きいですが、アレは自由度の低さが逆にモノを言ってる世界ですからね。
        プロポーショナルな不等幅フォントなんて悪魔の産物としか思えません。

        後は過去の資産というよりは、実績じゃないですかねぇ。
        お金関連の人は結構こだわりますから。

        親コメント
    • by aquablue (6469) on 2008年09月09日 14時16分 (#1417966)
      「優れている」のではなくて「向いている」なのですよね。

      特に何もしなくても、デフォルトの状態で金勘定と固定幅フォント帳票に
      最適なモードに設定されているわけですから。
      もちろん、ほかの言語でも可能な処理でしょうが、変数の型宣言などの
      (ある意味)煩雑なことを気にしなくて良いというのはメリットだと思います。
      #融通が利かないという事とのトレードオフではありますが。

      きちんと(これ重要)コーディングすれば、素晴らしく見通しの良いコードになりますよ。
      そういう意味で、金融系のバックボーンとしては悪くないと思います。

      今のプラグラム言語と同列に考えるから「何でCOBOL?」となるのであって、
      「BCDコードベースの金勘定に特化したスクリプト言語」くらいに
      捉えておけば良いかと思います。

      優秀なデバッガさえあれば、メンテもそう難しくないんじゃないかなぁ…
      #見たこと無いけど

      ただ、技術者としてそれに甘えていて良いかというのは別問題。
      特性を理解してCOBOLを選択する事と、COBOLしか使えないってのは
      雲泥の差ですから。
      Cをまともに使える人なら、2時間も仕様とサンプルソース眺めれば
      COBOLはそれなりに理解できるはず。

      大昔のGOTOバリバリのスパゲティを理解できるかっていうと、
      それはそれで別問題ですが。
      親コメント
    • by the.ACount (31144) on 2008年09月09日 12時41分 (#1417892)
      COBOLのようにテンプレート風のフォーマットができる言語なんて知らないな。
      (一応、Mac の ResEdit は知ってるが、言語か?)
      --
      the.ACount
      親コメント
  • COBOL「しか」つかえない技術者に化石が多いのが問題のような。
    全 員 と は 言 い ま せ ん が 、COBOL技術者って「COBOL以外覚える気がないし必要ないからいいや」というスタンスの人が多いように思えます。

    # 巷で色々騒がれてるシステム障害の原因も、COBOLにあるというより、COBOL全盛期の方法論しか振りかざせない人にあるような。そういう意味では「システムがCOBOLだったから障害が起きた」もあながち間違いではない・・・?
    --
    神社でC#.NET
    • コボル技術者は化石なんで、掘り出せばいくらでも出て来ます
      開発が土方になる前の世界のニンゲン達なので、個々のスキルも高かったりするわけで

      作った後の引き継ぎさえちゃんとやれば問題無いんじゃないんですかね
      開発はともかく、現代っ子に理解出来ないロストテクノロジーで設計されちゃって、それ以上手が付けられないのが問題なんだし
      親コメント
  • COBOL職人が取締役 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2008年09月09日 12時57分 (#1417907)
    上司が偉そうに説教たれれる言語で開発。

    派生クラス?オブジェクト言語?抽象化?オーバーライド?
    俺のわからない事をいうなと。
  • 基本設計がいい加減だった頃にCOBOL全盛期だったからでしょう。
    そのあと追加追加で今となっては手を付けられないほど全体が巨大化というか肥大化してしまっていて
    手直し程度ではどうにもならないんだけど丸きり作り直そうにも
    そもそも全体を把握してる人どころか仕様書すら残っていない(もしくは最初からそんな物は無い)ので
    仕方なくCOBOL使ってるだけ、という感じがします。

    最初にたまたまハズレ引いただけかと思ってたら、次もその次もずっとそんなんでしたよ。ええ。
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...