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

Anonymous Coward曰く、

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

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

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

ひたすら長大なコードを紙ベースでデバッグする言語

[Arc Cosine (35004)]

死ぬかと思った。
紙ベースのデバッグって一体何十年前の話だよ。
レビューを紙でやるのは別に構わないけど、デバッグが紙って……orz

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

Re:ひたすら長大なコードを紙ベースでデバッグする言語

[shiba (273)]

ここでいう 紙ベース とは

(1)プリンタ出力したLP用紙
(2)紙カード
(3)紙テープ
(4)コーディング用紙
(5)ラインプリンタで印刷した(1)の裏紙

のどれなんだろうか?

Re:ひたすら長大なコードを紙ベースでデバッグする言語

[Arc Cosine (35004)]

自分の場合は(1)でした

Re:ひたすら長大なコードを紙ベースでデバッグする言語

[Anonymous Coward]

でかいディスプレイを、複数面持つようになっても、わたしゃ今でも他人の書いたコードを解読するときは
いったん印刷して、電子データの参照と両方利用しながらしながら進めていくけど。
いすにふんぞり返りながら読めたり、図や覚書などを簡単に書き込めたり、俯瞰的に見るのにかけては、やはり紙のほうが便利。
帰りの電車のなかで気軽に読んだりもできるしね。
帰宅の電車でバグを見つけて「あー～～～！！！」と叫んで、周囲の耳目を集めることも時々ｗ

まあおかげで机には紙資料が散乱しているんだが。

つまり

[Anonymous Coward]

>旧システムからのプログラムの流用ができた

ここがミソなんじゃないの？
スクラッチから作るのと、既存のシステムを流用した場合のトレードオフ。
部品化なんてオブジェクト指向言語ならどれでもできるわけだし、
そもそも言語なんて手段に過ぎない。
プログラム言語の性質で開発手法を語るのはどうかと思うのだが。。。

Re:つまり

[Anonymous Coward]

僕が所属している企業グループの新人向け教育では、
JavaとCOBOLを教えますが、何か．．．

はっきり言えばいいのに

[Anonymous Coward]

理由は慣れだって
COBOLしかやってこなかった連中に他の言語勧めるのは難しいでしょ
年齢的な意味でも

Re:はっきり言えばいいのに

[yellow tadpole (7084)]

＞理由は慣れだって

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

今時メインフレームでCOBOL使ってるって事は、COBOLと勘定系を両方知ってるって事なんだよね。
（業務系はさすがに少ないと思う）
JAVAやCのエキスパートなら、これは確実に知ってるだろう、慣れてるだろうって業務はないでしょ？
その差が大きいんだと思うよ。

--
〜◍

COMP-5

[Anonymous Coward]

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

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

このため同社は部品化とシステム構成のシンプル化に最も重きを置く。「COBOLはそれを最も実現しやすいと実証している。なぜなら5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。

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

モデルはベテラン中心にCOBOLで開発していく

からそれで済んでいるんだよね。 でも、この体制で開発したんじゃ

「開発1年・保守10年」

なんてできるのかな。大いに疑問。

COBOLの将来はまだまだ明るい

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

「25年の間，システムの利用範囲は外に外にと広がっていった。そのたびに改修を加え，システムは本館の横に別館を建て増し，それを渡り廊下でつなぐような複雑な構造になった。保険商品も保険料の支払い方法もどんどん増え，それに伴いシステムは複雑さを増した」という。ビジネス面でこれらをお客様目線で見直し，シンプルにわかりやすくするのが，今回の抜本改革だ。

って、要はリファクタリングをもって抜本改革なんて呼んじゃっているわけだし。

フレームの元承知で、COBOLのいやなところを語ってみる

[Anonymous Coward]

Callのように使えたり、Gotoだったり、ループ制御だったりする、PERFORM

# ひとり一項目縛りです

いやなところ：例のジョークの日本語訳が成り立たない

[TarZ (28055)]

　有名なジョーク「COBOLで自分の足を撃つ方法」を、ネタ的に日本語に訳せないところ。

How to shoot yourself in the foot in COBOL

Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place
ARM.HAND.FINGER. on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN
to HOLSTER. CHECK whether shoelace needs to be retied.

Re:いやなところ：例のジョークの日本語訳が成り立たない

[TarZ (28055)]

そうなのですか。それで、ジョークの中身を実際に日本語に訳すとどうなるのでしょう。

「自分の足を撃つ方法をCOBOLで言うと」とすれば、日本語に訳してもジョークとして成り立つ、ってことですよね？

Re:フレームの元承知で、COBOLのいやなところを語ってみる

[Anonymous Coward]

IDENTIFICATION DIVISION.

Re:フレームの元承知で、COBOLのいやなところを語ってみる

[saab9000 (31344)]

03 SO-GOKEI PIC(09).

＠桁数の見積もりが甘くて数年後に桁あふれでABEND

ほんとに言語の優位性ってあるの？

[Anonymous Coward]

PerlだのPHPだのが中心でちょっとJavaかじった程度の者ですが・・・。
あるシステムに対する特定言語の優位性ってほんとにあるんですか？
慣れや扱いやすいさ、関数の充実などはもちろんあると思うのですが、
なぜ「金融系はCOBOL」なのかとかよく分からんのですよ。

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

いろんな意味での環境（人、ものなど）が基因で
案件毎に特定の言語の優位性があるってのは分かるんですけど。
何をもって「この言語がいい！」となるのか是非知りたいです。

Re:ほんとに言語の優位性ってあるの？

[Anonymous Coward]

×「ビジネスロジックの書きやすさにおいては右に出る言語はない」
○「ビジネスロジック*以外*の処理に気を遣わなくていい(から書きやすい)」
と言うところが本意でしょうね。

Re:ほんとに言語の優位性ってあるの？

[Anonymous Coward]

複素数が扱えるfortranは、科学技術計算で他の言語に比べて優位。

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

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

Re:ほんとに言語の優位性ってあるの？

[amaki (35983)]

CにもC++にも，組み込みの複素数型がありますよ． Cしか使わない人も，complex.h をインクルードして，cos(1.0i)を表示させてみては．

--
-- 甘木

Re:ほんとに言語の優位性ってあるの？

[127.0.0.1 (33105)]

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

初心者がちょっとかじっただけで「どれでも一緒じゃん」と思うのと
達人がいきついた果てに「どれでも一緒じゃん」と悟るのはたぶんなんか違う。
本物の達人なら「適材適所」と言うと思うけど。
達人にはなったことないから脳内シミュレーションね。

Re:ほんとに言語の優位性ってあるの？

[Anonymous Coward]

とりあえずTck/Tkをやってみなさい。言語のシンプルさがグルー言語として特化していることを感じられるから。
Cは組み込みで使ってみなさい。コンパイラの作りやすい言語系のおかげでCPUを選ばないから。
C++は極限性能を求める大きなプログラムを書くときに使いなさい。テンプレートマクロによる高速化が使えるから。
C#はWindows GUIプログラムに使いなさい。綺麗さと汚さのバランスが実用的だから。
VBはGUIの使い捨てプログラムに使いなさい。作成速度の初速は一級品だから。

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

# 言語が環境を作るのか、環境が言語を作るのかは分からないが、環境と言語は不可分なんだと思う

Re:ほんとに言語の優位性ってあるの？

[Anonymous Coward]

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

その三つであればよほどの信者以外は「どれでも一緒じゃん」と思うのが普通です。しかし、あまりにも似た三つだけ(Javaは置いといて)を知っているからといって、他の言語も一緒か？などとは思わないように。

資産の流用のみ

[hogetsuyoshi (14204)]

今更COBOL使うのなんって、現在の資産の流用以外メリット無し。

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

今利用されている言語は、COBOLの遙か上にいるので、右にも左にも対抗言語はいません。

Re:資産の流用のみ

[ksiroi (24990)]

そもそもビジネスロジックって単語を持ち出して言語比較すること自体がナンセンスじゃないの？とは思う。
あれってbuzzwordじゃないの？
仕事上で何度が聞いたことあるけど 大抵それを喋る奴って二流だし、自分が何言ってるか把握してないし。

// 馬鹿とハサミは使いようと申しまして・・・(:>^

MOVEとIFとPERFORM

[shadowfire (6584)]

もう20年以上前、新人の頃に少しだけCOBOLの仕事をやりましたが、
先輩曰く
「COBOLは、MOVEとIFとPERFORM知ってりゃ何とかなるよ」
と。
新人で重要な処理の部分は任されなかったのでまさにその通りでした。

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

--
--------------------
/* SHADOWFIRE */

代償

[shoji12 (14093)]

大金をはたいてメインフレーム以下ＯＳやＲＤＢＭＳを購入すると、いわゆる高級言語を使わざるを得ない、ということかな。
心臓部の統計処理は、ＣＯＢＯＬで書いているのか？
おかげで、見た目のシンプルさは実現できるし、メインフレームメーカは儲けるし。
しかし、どう転んでも、全ての資金源はお客さんが支払う保険料だから、お客さんにとってＣＯＢＯＬを使うとどんなメリットがあるかという話が聞きたいな。
保険料がお安くなりますようーみたいな。

この手のトピを読んで思う事は

[yukichi (12361)]

COBOLを使う事は必ずしも推奨される事ではないが、COBOLについて語り合う事は多くの人が好きなんだ、ということですね。

取締役の言葉ではないな

[Anonymous Coward]

>「30年システムに携わっているが，COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言語はない」
という開発人員を沢山抱え込んでいて、切り捨てられないというのが、本音だろう。

疑問なんですが

[Anonymous Coward]

COBOLの何がそんなに事務処理に良いんでしょうか？
実績が最大の評価なのはわかるんですが。

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

ちなみに仕事で使ってないだけで(試験用として)COBOL自体は知ってます。

Re:疑問なんですが

[Tig3r (17335)]

私見ではありますが、COBOLの何が事務処理に向いてるのかと申しますと、
COBOLの持つ機能ではなく、COBOLが持たない機能が多いおかげで、事務屋が
事務屋の目線で使える言語である、ということなのではないかと思います。

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

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

--
-- Tig3r on the hedge

Re:疑問なんですが

[USH (8040)]

そもそも、会計処理というそこそこ複雑な処理を、紙という非常に制約のきついハード上で記録したり処理したりするために、台帳とか伝票とかが摩訶不思議なものが産み出された。でもって、その摩訶不思議なものを、紙という制約がない計算機にわざわざ構築したのが COBOL って感じかなぁ。

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

役所に出す書類、なぜこの数字がここなんだ、というのが、あちこちあって困る。
しかも問い合わせても、すんなり分かる説明を受けたためしがない。

Re:疑問なんですが

[Anonymous Coward]

禿しく同意します。
昔、メインフレームのダウンサイジングで盛り上がっていた時に、Java バッチとか作ったことがありますが、帳票出力だとかがめんどくさいことこの上ない。
Java が「なんでも出来る」おかげで、実際の処理とは無関係な手続きの方が長いんじゃないか？ってくらいに。
# クラスライブラリなりを整備しろよってな話ですが。

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

まぁ、メインフレームでやるならの話ですが。UNIX 環境なら Perl なり Ruby で書いちゃった方が楽ですし。
# やっぱり COBOL はいらない子？

Re:疑問なんですが

[Anonymous Coward]

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

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

# いくつかは知ってますが。

Re:疑問なんですが

[Anonymous Coward]

BCD演算がベースな言語だから金勘定では他の追随を許さない安定性がある。
他の言語でもできない訳ではないが、初めからそれと、後付けの差は大きい。
まあ画面周りとかは他の言語でもいいけどさ。

Re:疑問なんですが

[Anonymous Coward]

一番大きいのはやっぱこれだろうな
何も意識せずとも二進数由来の制限と無縁でいられる
要するに「そろばんや電卓での処理」をそのままプログラムに落とし込めるのよね
だから金融系のビジネスロジックと非常に相性がいい

Re:疑問なんですが

[Tatenon (20311)]

私もここに一票。

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

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

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

Re:疑問なんですが

[aquablue (6469)]

「優れている」のではなくて「向いている」なのですよね。

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

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

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

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

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

大昔のGOTOバリバリのスパゲティを理解できるかっていうと、
それはそれで別問題ですが。

Re:疑問なんですが

[the.ACount (31144)]

COBOLのようにテンプレート風のフォーマットができる言語なんて知らないな。
(一応、Mac の ResEdit は知ってるが、言語か？)

--
the.ACount

COBOLが化石というよりも

[n_ayase (36873)]

ＣＯＢＯＬ「しか」つかえない技術者に化石が多いのが問題のような。
全 員 と は 言 い ま せ ん が 、ＣＯＢＯＬ技術者って「ＣＯＢＯＬ以外覚える気がないし必要ないからいいや」というスタンスの人が多いように思えます。

# 巷で色々騒がれてるシステム障害の原因も、ＣＯＢＯＬにあるというより、ＣＯＢＯＬ全盛期の方法論しか振りかざせない人にあるような。そういう意味では「システムがＣＯＢＯＬだったから障害が起きた」もあながち間違いではない・・・？

--
神社でC#.NET

Re:COBOLが化石というよりも

[Sukoya (33993)]

コボル技術者は化石なんで、掘り出せばいくらでも出て来ます
開発が土方になる前の世界のニンゲン達なので、個々のスキルも高かったりするわけで

作った後の引き継ぎさえちゃんとやれば問題無いんじゃないんですかね
開発はともかく、現代っ子に理解出来ないロストテクノロジーで設計されちゃって、それ以上手が付けられないのが問題なんだし

COBOL職人が取締役

[Anonymous Coward]

上司が偉そうに説教たれれる言語で開発。

派生クラス？オブジェクト言語？抽象化？オーバーライド？
俺のわからない事をいうなと。

基本設計がいい加減だったから

[duenmynoth (34577)]

基本設計がいい加減だった頃にCOBOL全盛期だったからでしょう。
そのあと追加追加で今となっては手を付けられないほど全体が巨大化というか肥大化してしまっていて
手直し程度ではどうにもならないんだけど丸きり作り直そうにも
そもそも全体を把握してる人どころか仕様書すら残っていない（もしくは最初からそんな物は無い）ので
仕方なくCOBOL使ってるだけ、という感じがします。

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

Re:金の計算と帳票処理なら

[naruenosekai (13637)]

まあそうなんでしょうけど、COBOLのメンテできるプログラマが少ない
ということの方が問題かと。

#自前でメンテナンス要員育てるならいいけど、生保は外注がほとんどだからなぁ

Re:金の計算と帳票処理なら

[Anonymous Coward]

「プログラミングと単体テストを5カ月で終了しなければいけないスケジュールを乗り切るには，これまでのノウハウや人材を生かしきらなければならないと判断した」

ってことだから、要員はそれを生かすことに依る効率化を考えられる程度は居るってことでしょうね。

二進化十進

[NOBAX (21937)]

と言えばCOBOLで決まりです。
良いものは良い。
なんか文句がある人がいるんでしょうか。

Re:二進化十進

[tietew (6130)]

知らない人も多そうだが実はx86も持ってる二進化十進演算ニモニック。
# ただしCOBOLを実装するに当たって有用かどうかは知らない :p

Re:二進化十進

[aruefu (34582)]

では”ぴゅう太　日本語ＢＡＳＩＣ”で。

１０　シキ　ＳＵＭ＝０
２０　マワレ　４０　Ｉ＝１　カラ　１００００　カンカク　１
３０　　　シキ　ＳＵＭ＝ＳＵＭ＋０．１
４０　トジル
５０　カケ　１，ＳＵＭ
６０　オワリ

・・・しまった、「ジッコウ」しようにももう実機もってない・・・。

Re:二進化十進

[TarZ (28055)]

C82-BASIC (CASIO FP-1100)

ＬＩＳＴ
１０　ＳＵＭ＝０
２０　ＦＯＲ　Ｉ＝０　ＴＯ　１００００－１
３０　　　ＳＵＭ＝ＳＵＭ＋０．１
４０　ＮＥＸＴ
５０　ＰＲＩＮＴ　ＳＵＭ
ＲＵＮ
１０００
ＯＫ
■

Re:金の計算と帳票処理なら

[shiba (273)]

4GL と言っていた言語は?

あっ.そこのオジサン FORTH じゃないよ.

Re:金の計算と帳票処理なら

[love-m4 (10412)]

NEC [nec.co.jp]も日立 [hitachi.co.jp]もCOBOL2002やってんじゃん。
.NET対応 [hitachi.co.jp]もあるみたい。

＃富士通なんかはCOBOL->Javaなんてのもあったような・・・

Re:COBOLerが

[jacques (32858)]

確かに、確保が割と難しい言語だと自分も思います。

自社だけを見てるのでサンプリングとして少なすぎますが、COBOL要員募集案件は異様なまでに多いですよ。人員の高齢化に伴い、総数が減ってるのだとお客や上司からよく聞いています。むしろ、「Javaかじった」程度は溢れかえってる様で、要求スキルレベルの中～低程度のJava要員募集は皆無に近いです。

Javaに比べるとCの方が安定して仕事があります。

#そんな自身はRubyist.

--
puts "This user is a beginning Ruby programmer."