3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

COBOLを何に載せ替えるべきか(PL/1とかじゃねえのかって?(笑))

Posted at

COBOLとか所謂レガシーを何時まで、どれに移行するのか議論するのですかね?

もう聞き飽きた(笑)
よく言われるし、良く聞く話ですが、所謂レガシー言語で作られた業務システムなどを、どのようにマイグレーションするのか。


できない(やらない)理由

できない理由は、費用対効果が少ないからと言われます。
移行というのは、実は新規開発より莫大な費用かかるって知ってました?
(PMIの統計だったかな?IPAだったかな。。。)新規開発の3倍は掛かります。

新規開発を1とすると、レガシー調査1、移行1と考えて頂ければ(新規開発は、最近効率が良いので0.3とかかも)

これじゃあ、移行する気にもなりませんよね


では、どうするか。3つの案が考えられます。

案1 案2 案3
移行ツールを使う 現行解析して移行設計して移行 塩漬け(移行しない)

案1 移行ツールを使う

2013年頃に流行りましたね。COBOLからJavaへのマイグレーションツールとか。
私も、参画したことがあります(お手伝いで、しかもJCLがメインでしたが(笑))

大手メーカーも、何とか頑張って移行されて、現在は新規アーキテクチャなどに対応も容易になっています。
次々と新製品を出しているところを見ても、そうなんだろうなーとおもいます。情報システム部は、クソでしたがね(笑)
大企業で、当時先進的な企業であれば、既に完了済?ここに、落とし穴が潜んでいました。

「4GLツール」です
当時としては画期的な設計手法と自動生成されるソースのお陰で、開発効率も格段に上がり便利なツールでした。
私も、某プロジェクトで参加して使いましたが、**「便利なもんだなぁ」と感心したのを覚えています。
しかし、著作権の問題やそもそも設計書から変換されてソースになっているため、何故そうなっているのかが
著作権で保護されているので、仮にストレートコンバートしても
「設計書には、どう書くの?」**となって
移行がチグハグになってしまいます。頑張って、移行された企業は、業績がそこそこ良いのであれからなんとかしたのでしょう。

今、この手のツールの話しは聞かなくなりました。手間の割に高い(個人的には、そうは思わないのですが)ので
使われにくくなったのかもしれません(事例あったら教えてください<(_ _)>)

案2 現行解析して移行設計して移行

一番、綺麗なスタイルと思います。ところが、最初にも話した通り費用対効果が少ないからやりたがりません。
情報システム部やSIerにも、COBOLは読めてもJCLは読めない人が多いので、連携が理解できないのも理由に上げられます
(昔の大手さん移行の時、JCL+FTPとCOBOLだけが私に回ってきた時は、上司を怨みましたが(笑))
PL/1は、其の手の時間が掛かる部分は、アセンブラで書いたルーチンを呼び出すようにしてあります。
Substrとかね(賢い!!)
COBOLも有るところもありますが、大部分は言語内かJCLのユーティリティかどちらかです。
COBOLは、ちょっと前まではやっていた人もいらっしゃったので読解可能でしょうけど、JCLはプロでないと読めません。
ユーティリティ使っていれば、尚更プロが必要です。しかし、そんな方を探すのは至難の業で、SESとかSIerでは探せません
何故なら、彼ら自身がその方々をぞんざいな扱いで2000年問題以降切った=クビにしたからです
中には、COBOL専用の会社さんもあるようですが、最近聞きませんね

案3 塩漬け(移行しない)

業務システム(或いは他にしても)重要なのは解ります。しかし、案1や案2ができないならば
いつまでも、CPU課金で高い保守料を支払ってお使いください。やらない=やらないリスクを取ったということですから。
「そのシステムが会社業務改革しようとしても足枷になっているんじゃないか!!」と

そんなことは、こちらの知ったことじゃあ有りません。時代について行けないなら、社会的責任は負えたので大企業と言えどもとっとと潰れてください

法人税減税で恩恵受けておいて、その言い草か!!としか言い様がありませんね(笑)

移行しないのなら、新システムと塩漬けシステムのハイブリッド構成です
塩漬けシステムには区切りの良いところでデータ登録は中止して、新システムに乗り換えてください。
古いデータは旧システム、新しいデータは新システムから出せば良いだけです。

ただし、新システムに合わせるのが前提条件になります。つまり、アドオンとか改造とかは一切無しです。

今回、このような自体を招いたのは、たかが業務システム如きに莫大なカスタマイズやアドオンを作りまくったことが原因です。
「客先に合わせるために」とか「今までこうだったから」とか、色々当時は理由があったでしょう。経済成長著しくもあり
それだけの余裕もあったのも事実です。
1.「客先に合わせるために注文書をカスタマイズ」→Excelで付ければ良いじゃんか。転記すれば、問題ないっしょー
1.「今までこうだったから」→法制度改正で、何度修正したか覚えていますか?特に固定資産とか。その費用だけで、他に色んな事できましたよ(笑)

コンサルティングファームに丸投げしてるんじゃねぇ!!自分の会社のことだろ。

情報システム部も、会社来てるだけか?(笑)コンサルティングファームが、答えだしたか!!💢

最近は、最後まで面倒見てくれるところのあるので良くなりましたね

マスタ連携とかあるので、ETLとか使えば良いでしょう。コード変換も楽でしょうし。
業務を変えるのは、貴方たち自身が決めることですよ。決してコンサルティングファームは決めません(決めて潰れ出てもしたら大事ですからね(笑))
古いデータは旧システム、新しいデータは新システムからの運用は、数年は使いにくいし費用も上がるでしょうが
できもしないことを悩んでいても仕方ない、やれることを急いで実施して下さい

時間は残り少ないです。今や、クラウドどころかHCIとかで、先進企業はどんどん時代を先取りしています。
良くて2023年、COVID-19が落ち付くであろうと言われているころが、タイムリミットです。

IoTなんてとっくに当たり前、MLで色んな自動化をして人は創造的な所に力をいれて、次々と新製品を出してきますし、新アイデアも出してきます。
製造すれば儲かる時代は、とっくにおわっています。自動車業界は、悲惨な目を見るところとそうでないところと2極化するでしょう。
(泣き言言っているところは、前者。何も言わないところは、後者)
「フレームの物理的な設計とか製作は、長年の蓄積が~」、Twitterで見かけますが、無ければ買えば良いだけです。ビジネスチャンスを物にすると言う事は、時期(タイミング)が重要なのです。
何時までに何を出すか、3番目以内に。これは、マーケティングでは常識でしょ?昔、大学生の時に習った時は、4位以降は「その他大製」です。

皆さんの会社が、3位以内に入れることを祈ります(多分、無理だろうけど(笑))

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?