レガシーを追放せよ！ 167
ストーリー by yoosee
これも時代の流れか 部門より
これも時代の流れか 部門より
von_yosukeyan曰く、"日経コンピューター5月23日号の記事(閲覧には無料の会員登録が必要)によると、独立行政法人日本貿易保険(NEXI)は、COBOLベースで稼働している基幹系システムをJavaで再開発する予定だ。
現行システムは1992年に稼働したもので、250万ステップのCOBOLコードがNECのACOS-6メインフレーム上で動作していた。しかし長年の機能追加などで、コード量は現在550万ステップまで肥大化し、保守性が悪化していた。
今回、NEXIが日本IBMに発注したシステムは、このうち保険業務システムと呼ばれる基幹系システムの核となる部分で、400万ステップのCOBOLコードをJavaに置き換える。興味深い点は、このプロジェクトは自民党のe-Japan重点計画特命委員会によるレガシーシステム改革指針に基づき刷新が決定された第一号システムで、ハードウェア調達とソフトウェア調達が分離して行われる。IBMが受注したソフトウェア部分は、ハードウェアやミドルウェアに固有の依存性を極力排除することが要件とされる。
ハードウェア入札は今後行われる予定だが、この新入札方式が公共系システムのコスト削減と、レガシーシステム追放に繋がるかどうか注目されるだろう。なお、欧米でも同様のレガシーシステム追放政策が進められている(過去の記事)"
別にCOBOLが (スコア:4, すばらしい洞察)
JAVAにすれば絶対的に保守性がよくなるとか、安全だとかって確信（自信？）
あるの？
悪いのはシステム／開発管理をいいかげんにしてきた事が悪いわけで、言語
やシステムを換えたからどうなるというのでもないだろうに。根本から変え
ないと結局JAVAでスパゲティボール作るだけになるんではないか。
非常に胡散臭い話に思える。
Re:別にCOBOLが (スコア:4, 興味深い)
でも、受け入れ側が工程管理する際、オブジェクト手法の開発手法が
理解出来なくって、二重線表や二重ドキュメントを要求してきて、現場が
混乱するんじゃないかと。
＃実際某所の期間システム開発で、言語は新旧ともにCOBOLだった
＃けど、開発手法を変えた(ウォーターフォールモデルから構造化
＃手法)時、そういう線表とドキュメントを要求されて、無茶苦茶
＃になった経験あります。;-(
Re:別にCOBOLが (スコア:3, すばらしい洞察)
すさとか、開発環境の充実度とか周辺が違ってきたりするじゃん？
そういうのも考えるとここらで移行しとくかって事じゃないのかな？
まあ私の妄想ではあるんですが。
(I can't get no) satisfaction
Re:別にCOBOLが (スコア:1)
2007年問題 (スコア:2, 参考になる)
中小企業IT110番 [it-planning.jp]の解説がわかりやすそうですが、COBOLはもう既に若手がぜんぜん参入しないので、技術者の高齢化どころか、COBOLベースのシステムの基本部分を作った初期の人に至っては、2007年頃には定年退職で引退する人すら出始めるのだそうです。
で、誰もメンテできなくなる前に今時の言語で再構築ということをやり始めるところが出ているようです。
Re:別にCOBOLが (スコア:2, すばらしい洞察)
Re:別にCOBOLが (スコア:1)
それはどうでしょうね。特に最近のJava屋さんは、クソみたいなコードを量産するレベルの人間が多いですから。保守性最悪、機能に比べて巨大なコード、そういうJavaプロジェクトが多かったりします。
私見とすれば、Javaの開発効率はＣなどと比べて決して良いとは言えません。ぼく的な体験とすれば、クソではないコードで同等な機能を実装する場合、Javaのコード量はＣの1.5から４倍ですね。Ｃと比較するとJavaは冗長な、持って回ったコーディングを強いられる場合が多いと思います。エラーハンドリングがexception主体である事も、利点よりもコード量を大増加させる欠点の方がより強く出るでしょう。
もちろん、cobolの開発効率はお世辞にも良いとは言えず、Javaの方がマシは言えると思います。ですが、Javaを選択する事は少なくとも開発効率の面からすれば、最適解では無いでしょう。良くないものは一層良くないものよりもマシ、これが「Javaと比べて、相対的に悪いだけです」の真意だとすれば、それは御意！でしょう。
もっともＣが大規模開発に向くかと言えば、それは多分に否でしょうね。言語仕様が柔らか過ぎるＣ、あるいはJavaは、コードのレビューに十分な時間を取らないと危険だと考えています。PL/Iなぞが向いているのではないでしょうか。
Javaで開発を行う事に大きなメリットがあるとすれば、それはOOP的な開発手法を取り入れる事でしょう。という事は、開発対象の機能を実装する場合にその下支えとなるクラスライブラリが揃っていて、かつそのクラスライブラリは相当に信頼出来る、が大前提となるでしょう。NEXIのプロジェクトがどういうものはは知りませんが、今から下支えのクラスライブラリを作って行きます、なら、担当者には相当な能力が要求されますし、大変な過酷労働を強いられる事になるのではと、思います。
まあしかし、以上の事はプロジェクト立案段階では基本的な事ですが、プロジェクト推進段階では些末な事と言えるでしょう。テクニカルな事よりも管理運営手法の方が遥かに重要なのですから。JavaだからOK、cobolだからNG、と言うPMが居れば、そいつは首にすべきですね。
Re:別にCOBOLが (スコア:3, 興味深い)
もちろん、CとJavaでは得意分野が違うので、Cのほうが優れている部分もあると思います。
Re:別にCOBOLが (スコア:2, 興味深い)
とはいえ、OOP無しでJava、と言う非現実的な条件（そんなのはJava使いとは私は認めません）であればCの方がいいかもしれませんね。
# そう考えると、Javaも大衆化してしまったのか・・・
Re:別にCOBOLが (スコア:3, すばらしい洞察)
これには頷く反面、「タコが書くとひでぇことになる」度合いは、COBOLの方が苦しいというのが実感。
コーディング規制をきっちりとして、その規制に則ったコンパイラへの規制ルールの追加といったことをきっちりやれば、それなりになる..
つまり、そこらのタコで書けるんです。そういう面では、人数を大量導入しやすいという、工数不足を補うという実際面ではCOBOLもそれなりなんだ。
だけど、そのルールについてを決めることが出来るレベルの人の枯渇というのが、すんごい問題。
保守性と書きやすさのトレードオフという面での調整は、「出来る人がやれば」強制的に出来るというCOBOLに軍配があがるわけなんだ。
でもね、それを出来る人がほとんどいない、それが出来る人が偉くなっちゃって現場にいないということが、COBOLの今の悲劇なんだよね。
そして、「なんでこういったルールでこういったコードが？」という、継承者のスキルの問題もあったりするわけなんです。
でも、それなりに「量に負けちゃうことがあるけど、それなりにわかる」コードを生成しえているわけです。
JAVAが優れた言語かどうかは、JAVAの技術が廃れた後、別の言語を多少かじった程度の人でもメンテできるか？
というところに、「長い目で見た保守」という場では判定の基準があると思う。で、個人的な感想では、その面ではCOBOLの領域にはJAVAはいたってないね..といったところです.
Re:別にCOBOLが (スコア:2, 興味深い)
保守性の高さってどういう風に評価するんでしょうか？
いや、評価方法をうちの仕事にも応用できないかなーと。
って製造業なんですけど。
--------------------------
そろそろ時間です。
Re:別にCOBOLが (スコア:1)
OracleのPL/SQLなども、設計やコード規約がしっかりされて
いないものに、出くわすことがあり正直めまいがします。
誰にも治せないので、アドホックな継ぎ足しが、
延々となされてさらに悪循環が増強されたものでした。
反面、適度にパッケージ化され、適切な設計に基づくコードは、
実際にJavaストアド以上の保守性がある場合がある事も
確かに納得できるところです。
たしかに、Javaでも、冗長なコードが延々と続き、
手続き言語ですらない状態になったのも見たことがありますけど。
やはり、品質自体は設計に依存するもので、言語はあまり関係ないと
思いますが、現在のオープンなアーキテクチャーに対応できない
言語であれば、選択肢がどうしても少なくなり、コストもかさみます。
IDAが全面的に良いわけではありませんが、Eclipseの導入により
効率が上がる事例は今ならいくらでも出てくると思います。
そういう意味ではCOBOLに固執するなら、NetCOBOL [fujitsu.com]
みたいなものでも良いのかもしれませんが、
人材の確保の点でも、COBOLを選択するケースは
ほとんどないでしょうね。
Re:別にCOBOLが (スコア:1)
Javaの上でCOBOLのインタ(ry
# おもろないね。
Re:別にCOBOLが (スコア:1, 参考になる)
・浮動小数点の取り扱いの違いを意識しなくて済む
・モニタなどの言語レベルでの排他制御などがついている
というような利点があります。僕は面倒なセマフォなんぞに
戻りたくないです。それに、
・COBOL人員はコスト高
になっていくのは、時代の背景からして明らかです。
別にうさんくさい話でもなんでもないと思います。
技術者(またはプログラマ)の心得として、現場からの叫びとして
なら同意します。:-)
Re:別にCOBOLが (スコア:3, すばらしい洞察)
うそつけ。
Re:別にCOBOLが (スコア:1)
事務処理に浮動小数点計算って、金勘定に浮動小数点計算を使うって話ですか？
# まさか、ね
Re:別にCOBOLが (スコア:1)
・ まともに金銭計算に使える数値型が用意されていない。
・ クラスに対して演算子を定義できない。
という欠点があります。
ここをどう対処する予定なのかなぁと........
Re:別にCOBOLが (スコア:2, 興味深い)
狭い場合にのみではないですか？
個別機能実装部分というかが大きい場合、どこぞのコメントのように
5～10年のスパンで作り直しの方が安くなるのではないでしょうか。
…という話は別件でした。失礼。
こうするのには理由は一応 (んとに一応ですが) あります。
全体的なコーディングルールとしてコードをどのように書くかを
決定するとき、当然気にするのはバグの追跡が楽であることになると
思います (すくなくとも私はソコが一番重要な点です)
そこで上の
を考えると
例えばaがnullであったときとcがnullであったときは、問題の発生箇所は
違うのに、同じ行でNullPointerExceptionが発生したとStackTraceに
吐き出されますよね。
また、今回はBigDecimal#add(BigDecimal)ですからいいのですが、
指示の簡略化の観点から「どのメソッドでも統一的」という問題も
同列に扱いますと、当然BigDecimal#add(BigDecimal)メソッドも
NullPointerExceptionの発生原因となりえます。
そこで、どんなクソミソなテクニックの持ち主がコードを書いても
バグの追跡は同じように行えるように…という観点からすると、
・メソッドは一行に一個だけにせよ
という指示を出すのが、結果わかりやすくていいってことに…。
そこで悲しいかな、あのようなコードになっちまうのです。
当然、こんな方法は小規模プロジェクトでは不要ですけど。
# 元コメントでBifDecimalと書いてました。
# ぎゅ、牛丼くいたかったもんで…。
COBOLもあなどれない（Re:別にCOBOLが） (スコア:1, 興味深い)
とくに通貨を取り扱う場合においては、
・普通に10進演算が使えて、言語レベルで数値計算の精度が保証されている
というCOBOLの利点のほうが重要ではないかと思いますが。
COBOLも最新の標準仕様では、オブジェクト指向を取り入れているようなんですよね。クラスやらメソッドやら継承やら、可能になっているらしい。
オープン系COBOLでは、GUIビルダーやIDEなどとの連携も可能だったりするようだし。
Java一辺倒、Javaマンセー、では、足元をすくわれるかもよ。
Re:COBOLもあなどれない（Re:別にCOBOLが） (スコア:1)
＞オープン系COBOLでは、GUIビルダーやIDEなどとの連携も可能だったりするようだし。
えーとその場合、COBOLでオブジェクト指向を前提とした
開発をするんですよね？
・・・・COBOLでするメリットは？
# 結局新しいパラダイムを使ってシステムを作る場合
# 従来のCOBOL技術者が皆オブジェクト指向を理解しなきゃだめなんですよね・・・？
Re:COBOLもあなどれない（Re:別にCOBOLが） (スコア:1)
ENVIRONMENT DIVISION.
OBJECT-COMPUTER.
本当は COBOL 使ったこと無い人.
非効率さの認識 (スコア:2, 参考になる)
どうも省庁の方ってコスト意識が低くて(そもそもコストなんて無いと言われたらそれまでなんだが)、判子一個押してもらいに遠くの省庁まで半日出張して、その後終電後まで残業してみたりとあまり良い印象が無いです。
そういう方々に何が問題なのか認識できるのでしょうか。中の個々人は変だなと思ってたって、結果としてやり方が変わらないならねえ。
レガシー追放たって今ある業務をそのままjavaにするならあまり意味は無くて、業務の無駄を分析して(業務自体の廃棄とかも含めて)そのやり方を改善できるあたりに意味がある様な気がしています。
あまりに巨大だと分析…っても鎖にがんじがらめってのも分かるのだけど。
Re:非効率さの認識 (スコア:1, おもしろおかしい)
っていうのはおいといて、お役所で「プロデューサー」って認めてもらえる人って、どうせ現場の苦労をしらない大学教授かなんかでしょ。そのこと自体が非効率だったりして。
見たくないところから目をそらしている (スコア:2, すばらしい洞察)
そういう部分に手をつけるのがこわかったので、増築に増築を重ねて、老舗の温泉旅館のごとく、旧館新館本館別館アネックス本家新家分家みたいな複雑怪奇な状態になってしまって、どうしよう！？と悩んでいるのが現状では？
ということで、COBOLかJavaかという言語レベルでの議論は本質的なものじゃないでしょうね。
複雑怪奇なシステムにあわせた人間の業務をみなおす部分から手をつけるのが正解だと思うけど、これは人間が痛みを伴う作業だし、保守的な組織だと業務見直しには相当の抵抗が出てくるだろうから、現状の仕様維持で終了でしょうね。システムの保守性はなにも改善されない、に一票。
---- 末は社長か懲戒免職 なかむらまさよし
COBOLをスケープゴートにしてるとも取れる (スコア:3, すばらしい洞察)
やっぱ、
・GUI要望が高度化した
・他所とのデータ連係やオペレーション連係が爆発的に増えた
・要員の流動性が上がりシステム習熟度が下がった
・実現方法の選択肢が増えすぎてニーズにあった人材が集まらない
・そもそもPG担当者のレベルが下がった（汗
・バブル期に比べるとコストにシビアになった
・丸投げ保守が敬遠されメンテナンスフリーを要求されるようになった
などなどが原因で、保守を考えない「作りっぱなし」コードが増えたり、つぎはぎの頻度が上がっているのでしょう。間違いない。
まぁよっぽどの事情がない限り、3年後から1～2年かけて再構築する「5年周期」くらいが実情にあってると思います。
# 90年代だと10年経過で3～5年かけて再構築ってのが主流だったかも
---- 何ぃ！ザシャー
「レガシー」の定義 (スコア:2, 参考になる)
COBOLだからレガシー、Javaだから非レガシー、なのではなくて、事実上ハードとソフトが一体で調達され、運用開始後も特定ベンダー１社にずっと依存してしまっている形態が「レガシー」だと考えられているのではないでしょうか。
だから、ハードとソフトの分離調達が要件とされているのでしょう。
Re:「レガシー」の定義 (スコア:3, おもしろおかしい)
・有識者(異動した担当者(退職者含む))を探して拝み倒して聞き込みを行い、歴史の闇の謎を解析する作業
番外：たまに埋蔵物の呪いにかかって死ぬことも折り込み済み
このシステムって (スコア:2, すばらしい洞察)
短時間で大量に複写紙の帳票出力するためだけに、結局メインフレームが残ったりして。
Re:このシステムって (スコア:3, 参考になる)
たとえば、通関業務などは典型的なのですが、現状のシステムは他システムとの連携が前提となっていないため、通関手続きでは大量の帳票出力が必要で、手続きを行う側からしても、大量の書類を、各行政庁の窓口に直接出向いて提出しなければなりません。もうひとつの決済も、手数料や税の支払いなどを、印紙や金融機関の窓口で書面で行う必要があるなど、非効率性が高い分野でもあります
こういった非効率性は、航空貨物や海上コンテナなど、世界的に見れば24時間化されている通関手続きが、日本だけ古いままになっているというところがあって、日本の国際競争力を低下させる要因にもなっています。決済に関しては、今年から稼働しているマルチペイメントネットワーク [jampa.gr.jp](ペイジー)の活用により、インターネットバンキングやATMなどによる支払い基盤を整備している最中で、電子申請に必要な公的認証制度の整備も進んでいます
ただ、こういった基盤整備に手間取っているところと、既存の書類での申請システムも残しておく必要があるので、平行して古いシステムを稼働させたり、新しい基盤に旧来のシステムを移植するなどの過渡的な処置はある程度あると思います
伝えてある…？ (スコア:2, すばらしい洞察)
＞構成にかかわらず稼働するようベンダーには伝えてある」と語る。
ここで吹き出してしまった私は未熟者なのでしょう。
ならば (スコア:1)
Re:ならば (スコア:1)
Re:ならば(オフトピ) (スコア:1)
Re:ならば (スコア:1)
素で(死
春に3.0Rに買い換えたばかりなのでドキッと(汗
結局 (スコア:1)
おまいら、汎用機じゃなくサーバっていいたいだけちゃうんかと小一時間
レガシー？現代的？ (スコア:1)
Re:レガシー？現代的？ (スコア:1)
何でもあるから、書き換えの圧力は少ないと思っていたが？
ツールでＣＯＢＯＬ→Ｊａｖａ変換で、見た目はＪａｖａで中身は
ＣＯＢＯＬなら安上がりにハードをできるかも。
まさか１ステップづつ移行するのでは．．．．． (スコア:1, おもしろおかしい)
日本IBM＋大規模案件＋オブジェクト指向言語 (スコア:1, 興味深い)
Re:日本IBM＋大規模案件＋オブジェクト指向言語 (スコア:2, 参考になる)
Re:日本IBM＋大規模案件＋オブジェクト指向言語 (スコア:2, 興味深い)
http://www.sra.co.jp/smalltalk/SML/archives/1996-November/000910.html
# し、しかし、ここまで書いてあるのはある意味スゴイ。
Re:いらないものは捨てよう (スコア:3, 興味深い)
たいてい SQL文 一発で出るようなもの。
それを帳票かするからステップ数が膨大になる。
Re:いらないものは捨てよう (スコア:2, すばらしい洞察)
という悪循環。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:いらないものは捨てよう (スコア:1)
IBMの，お見積もり。 (スコア:3, 興味深い)
メトリックの数値は下記から。
http://www.theadvisors.com/langcomparison.htm
COBOL 107 LOC/FP
JAVA 53 LOC/FP
・・・で。
400万ステップ÷COBOL/FP = 37.4kFP
191万ステップ÷JAVA/FP = 同上
日本IBMが落札し、開発費用は39億7950万円。
FP単価=1万円
・・・・うぉ。やすっ！
斜点是不是先進的先端的鉄道部長的…有信心
Re:それ以前に (スコア:3, 参考になる)
あまりその心配は無いかも。
Objectiveな開発も大分あちこちでやっているし。
って、JavaだろうがVBだろうがCOBOLだろーが
どーしよーも無いシステムにするのは作る側の問題…
某*T*が作ったソースがモジュール強度とか境界値の考慮を
全くしていなくて泣きそうなんですが(；；
いや、泣いているんですが。
なんとかしてくれ。いやまぢに(；；
kusanagi shin
Re:それ以前に (スコア:2, おもしろおかしい)
その時、一人の男が立ち上がった。Basic を持ってきた。 これなら誰にも気兼ね無く goto が使える。 男達はそう思った。現場に明るさが戻った。 次の日から、COBOL を一行一行 Basic に直す作業が 始まった。 みんな遅くまで働いた。しかし、誰一人不平を言うものは いなかった。
プログラムの最初には
10 REM IDENTIFICATION DIVISION.
と書いた。みんな、心の中では COBOL を愛してた。
-- 哀れな日本人専用(sorry Japanese only) --
Re:レガシー云々ちゅ～より（木亥火暴） (スコア:2, おもしろおかしい)
こういうのは追放せずに保護して欲しいぞ
Re:新しいVM (スコア:1)
Re:新手の公共事業 (スコア:2, 興味深い)
やってた対談の中で読んだことがありますが、錯綜したビジネスロジック
や、そうせざるを得ない原因である法制度が最大の負債なんだから、
そこをなんとかしない限り、作り替えるのに保守費用と同じくらい
掛かるでしょう。
#山中貞則が死んで、税制の全体を把握してる人間は日本にいないのかも