とある動画で全銀システムの障害対する動画が流れていた。
そこでは、ひろゆきがコメントしていたが、WEB系の開発には強いのかもしれないが、
メインフレーム系の回答には疑問がのこった。
私は2007年頃、COBOLマイグレーションというビジネスに対して、
リーダとして参加していた。
なので、メインフレームのオープン化に対してはプロ意識をもっている。
さて、今回気になったところがいくつかあった
・なんでそんな古いものを使い続けているのか・・・
・古いから問題おこるんだよ！
・古いなら新しくすればいいじゃん・・・
・どうせ杜撰なかんりしていたんでしょのような・・・
このあたりの誤解を解いていきたいとおもう、ITエンジニアからだされた意見だとすると非常に残念と感じます。
COBOLは、ITエンジニアからすると下に見られがちです。
しかし、動画でひろゆきがいったように、
JAVAエンジニアで３０万ほどですがCOBOLエンジニアだと１００万とれます。
理由は、COBOLって需要と供給でいうといずれも低いため、
レア感が高いです。
そして、COBOLエンジニアの中には、最新技術に疎い人が多く、
開発界隈では役立たずというレッテルをはられることが多いです。
理由は、バブル期に開発がめっちゃあって、とりあえず人ふやせ！
ってなんか今ににてますが、使えないエンジニアでも1か月１００万以上の売上で開発に参加できた、興味もない意欲もない世代は、新しい事に恐怖を覚え、
脱COBOLを脱却できない人もおおい。そして、今オブジェクト指向の開発においては、
オブジェクト指向自身が彼らの概念にないので、2Dから3Dの世界になったようで
よくわからんと経験して、逃げ切った世代と逃げ切れなかった世代が残っています。
なので、COBOLは下に見られがちです。
COBOLに関する認識の誤解をすこしずつ解いていきたいと思います。
メインフレームとは主にCOBOLという言語を使用して開発されています。
メインフレームというものは、みなさんの知っているパソコンやインターネットなどとは全く違う考え方で構成されています。
さてCOBOLとはなんぞや、ということですが、
この言語には、特別な名前がついています。
「事務処理用の言語」といいいます。
事務処理用って何かといいますと、簡単に言うと、
会社に関わる数字の計算用ということで、
主に、給与や会計などに使われていました、その後、
入力を行える画面を提供できるようになり、手書きからシステムへ
事務処理は劇的な発展を遂げました。
COBOLはJAVAのように複雑なことは苦手で、COBOLのみだけでは、
何もできないため、JAVAでやりたいようなことをすると、
COBOLの中からJAVAのプログラムなど呼ぶみたいなことは今のCOBOLにはできます。
COBOLは数字をたくさん覚えて一気に計算することを得意としています。
では、計算ならJAVAでも他の言語でもできるじゃないか！
確かにそうなのですが、COBOLで実装されたプログラムからは、
事務処理の計算方法がそのまま書いてある感じなので、わかりやすいのですが、
まったく同じ計算を使用とするとJAVAでは、わかりにくなってしまい、
業務仕様を読み解くのは困難といえます。
COBOLは、計算などに特化していたり、実装に柔軟性はないので、
みんながルール通りに実装することから、きわめてバグが少なく動きます。
COBOLの特徴は言えばキリがないのですが、一旦はこの程度と思っておいてください。
COBOLは事務処理得意なんだ！
熟練の事務処理おばさんがCOBOLで
ITめっちゃ匠に使いますがJAVAとして、
これいくら？したとき、事務のおばちゃんはすぐに260円だよーと出すのに対して、
ITめっちゃ匠の子は、それって型番〇〇〇で、画像はこれで、・・・・・
で、１つ買うと260円ですと、かなり遅れて結果をくれる感じですね。
いや、その情報いらんし遅いわーなります。
さてなんでそんな古いシステム使いつづけているの？って
さぼりじゃん！怠慢じゃん！って
はい、恥ずかしいのでそんなことは言わないでね。
５０年前のシステムが動いていたとしても、
すくなからず１０年毎に、最新のメインフレームに入れ替えてますよ。
なので、少なくても１０年前の機械の可能性はあります、
ものによっては、数年前というメインフレームもあるでしょう。
さて、ひろゆきがいうようにいやー古いんだからさ新しいので作ればいいじゃん！って
そうですよね！そうなんですよ！
数百万程度のサーバマシンや、数千万で作れる程度のサーバだったらそれは
可能です。しかしながら、今回のへいきでひろゆきがつくりなおせばいいじゃん！って
正直、億の〇が何個つくかわからないですよ。
COBOLシステムの移行というものを私はビジネスとしていたのですが、
2007年当初でもほぼ儲かる小さ目のワークステーションや、小さ目のメインフレーム
をマイグレーションという言葉を使い、今つかわれてるようなサーバに移行することを
やっていました。
その当時で、ある程度食べつくして、マイグレーションブームは過ぎさりましたが、
今回の、全銀システムのような神域の化け物クラスのシステムがいまもCOBOLのメインフレームで動いています。ま、これをいま手を付けようと大規模なCOBOL人員集めをおこなっていますが、前述のべたような、使い物にならないCOBOLエンジニアを集めることになります（笑）
さて、その大規模なシステムはさておき
中堅のマイグレーションについて話をすることで、誤解が少し解いていきましょう。
メインフレームをCOBOLでできたシステムを新しいシステムで行う場合、
いくつかあります。
------------------------------------------------------------------
①新規で、設計書も新たに作って、新しい言語で作り直す
②COBOLプログラム解読、設計書を解読し、設計書を作成し、
その設計書を元に新しい言語で作り直す
③COBOL言語を、サーバで動くCOBOLに変換して、
サーバで実行する。
④メインフレームのリプレース
------------------------------------------------------------------
ま、この中で、大規模なシステムは④が選択しつづけて今にいたるという
感じです。
さて肌感がわかりずらいので、まー一概に言えませんがざっくり
金額をいれていきましょうか。
③を基準に金額いれいきましょうか
③COBOL言語を、サーバで動くCOBOLに変換して、
サーバで実行する。
１億円としましょう サーバやミドルウエアなど3000万としましょうか。
開発以降の保守料金は年間１００万程度とし毎年かかる感じとしましょう。
以降の費用は１億３千万と年間100万円となります。
④メインフレームのリプレース
メインフレームうーん価格もむずいのですが当時として
一旦ハードウェア１億円 プログラムファイルの移動とセットアップや、
そのプログラムが動くなど、わからんけど3000万としましょうか？
そして年間ホストの使用料金数千万支払います。
費用は、１億３千万と年間数千万の運用費用がかかるとします。
2007年頃のマイグレーションの取り巻く環境は、
IT化促進など飛躍的なIT化の波がある一方、バブル崩壊、リーマンショックと
企業には、経費節減の指向がつよい状況でした。
そうなった場合、賞味期限がきたメインフレームはいくつかの選択肢がうまれます、
このままメインフレームを使い続けると、バカ高い運用費をはらいつづけることになる。
IT化促進の中、企業の中には
①新規で、設計書も新たに作って、新しい言語で作り直す
さて一概に言えませんが、この金額が仮に開発が3億としましょう。
同じような機能をもっていて、新たな要望を取り入れた、使い勝手のいいシステム
となります。
を選択する企業も多かった。ただし、不景気で予算をとれない、企業は、I
②COBOLプログラム解読、設計書を解読し、設計書を作成し、
その設計書を元に新しい言語で作り直す
これを俗にリバースエンジニアリングというのですが、
正直この時代の設計書はあってないようなもので、
EXCELなどない時代ですから、方眼紙に鉛筆でかかれたものがほとんどで
電子化されたものはありません、また、KINGジムでうってるような巨大なバインダーで
図書館のような状態で設計書がならんでいます。
また、この時代の開発は、タイムイズマネーなので、
ほとんど、設計書を更新していません。なぜかというと、手書きなので、
手書きで書き直すとすごく時間がかかります。ここ直せばいいだけなので、
プログラムだけなおしちゃおってなり、設計書は開発当初のままとなっていることも多々あります。 さて、これが２億としましょう。
さて、②と③と④は①と違いは、お金をかけたけど
使える機能はまったく同じですね。
④とはIPHONEの機種変更同じです、
トラブルもなく、性能がよくて、まったく同じことが快適に
新しいメインフレームで動きます。運用もなにもかわりません。
さて、②と③は、機能は同じです。とくに便利になることはありません。
②に関しては言えば２億もかけたのに、おなじって！となります。
一番の問題は、メインフレームは、オールインパッケージであるため、
メインフレームの便利ツールは一切つかえなくなります。
例えば帳票が新しいミドルウエアと安価なプリンターに置き換わります。
めっちゃ出力に時間かかります。おそいです。通信エラーでます。
いままではでたーでたーとおもえばよかったが、
経費節減で格安、安価な環境になり不便なります。
当然ですメインフレームは高級品なので！
価格面はさておき、
我々の実行する③のマイグレーションでは、
世の中でめちゃくちゃ赤字プロジェクトが吹き出しました。
④のリプレイスに関しては、業者がすべてやってくれて
移行には日数はようするものの、同じソースを移植するだけで
正直に何もなかったように、快適に新しい環境で動き始めます。
当然処理時間も早くなります。これを繰り返しきたのが今のいきのこったシステムです。トラブルもなく、お金はかかるものの安定稼働したシステムを新しいハードで動かせます。特に新しい機能を必要としない場面では、操作しなれた環境は運用もかわらず安定です。
さて
③のマイグレーション、ソースを変換するプログラムつかうのですが、
ソース分析を失敗して、手作業の個別修正が発生、
パターン化できてない手修正したソースはあらゆるバグを発生させます。
また、ここに呼ばれるメンバーは、COBOLしかわかりません。
COBOLがわかればいいんじゃんとおもうでしょうか、
そうは問屋はおろしません。
プログラムはCOBOLでも、インプットはメインフレームDBから
ORACLEなどのRDBに代わります。ORACLE RDBでメインフレームのDBのコマンドを
実現する部品を作成しないといけません。
簡単にいうと、古いDBの理屈を理解し、新しい技術でそれと同じ安定した動作する部品をつくることが、マイグレーションエンジニアの実力の見せ所です。
前述述べたように新しい技術にビビってるCOBOLエンジニアには絶対無理です。
そして、ネット情報を頼りのいまのITエンジニアにも難しいです。
理由は、メインフレームの技術は資産なので、ネットにはのっていないので、
メインフレームのメーカーが提供しされた、広辞苑みたいな分厚い、頭がいい人がつくったお堅いマニュアルが、図書館のようにならんだなかから、該当のものを探しだし、
同じ結果になるなら、今の技術だとこれで代用できそうという、メインフレームの便利ツールのなかで、移行先でも業務で必要な機能を洗い出し、実現していく。
これ、COBOLしかわからなないエンジニアや、若手にやらせたけど、
正直どっちもできなかった。いやこの機能はこうだから、これでできんじゃんとわかればいいのだけど、いや、なにいっているのかさっぱりわからないと、
いやいや、マニュアルのここにこういう風にかいてあるよね、じゃこれを
実現するために、何つかえば実現できそう？っていってもいやわかりません。
結局、このあたりって、ネットにやり方のってるわけじゃないので、
エンジニアの古いマニュアルを読むセンスと、新しい技術への置き換え力がとわれます。
そして、センスない人間をめっちゃ集めてきました！「デスマーチ」！
正直、私も苦労してやってきましたが、その都度PDCA回して、改善するタイプなので、正直失敗はしたことないですよね。
周りのメンバーはめっちゃ赤字だしてました。
私は、結構、大阪や東京の火消し作業にいきましたね、
案件だすと身バレしそうなのでいわないですが、
皆さんが知っている企業の基幹システムのマイグレーションの火消しに回ってました。
最初は数千万ほどの案件だったのですが、
年々３億、４億、マルチベンダーで１０億のマイグレーションなどでてき、
コンペで負けたけど、うちのは試作も動いて評価よかったけど、
ま、世の中ですね、もう事前に発注先きまってましたみたいなことはよくありましたね。
さて、リバースエンジニアリングからの開発正直普通の開発でもありますよね。
でも、COBOLがよめなかったり、COBOLが読めるけどJAVAの仕様が書けないなど、
COBOLを単純にJAVAに設計して、オブジェクト指向も理解していない人が
つくるので、運用したときに、なんだこれ、なにやりたいの？という
COBOLぽいJAVAが生まれ、それが強引に動きこれが、COBOLリバースエンジニアリング問題です。こんなことやるのCOBOLエンジニアは馬鹿にされ、あいつら使えないなります。
COBOLをベースとした開発に開発に関しては、
非常に能力の高い人を主力に置く必要あります。
でもある案件には、技術力はあるものの一人よがりだった技術者が
すべて独りよがりにやっていたので、めっちゃ燃えてましたね。
リーマンショックで、仕事ないところで、ヘルプでいって
半年ほどで数千万売上あがったので非常によかったです。
動くシステムをもとに、リバースエンジニアリングや、
設計書を作らずにリバースエンジニアリングとかしているところもたいていは
内部の仕様がまったくアウトプットしか考慮せずにつくって、
空かすかになり、バグだらけのシステムができています。
さて、ひろゆきの言った①、いやー
お金がなくて、１億でもケチろうと思う企業に３億、４億だせますかね？
そもそも、４億かけたからって、本業にそれ以上の売上あがるならいいですが
不景気で将来の見通しもあやしい、状態で、IT投資にビビってる企業に、
そんな選択はできないです。
マイグレーションのプロとしてお金かせいでいたけど、
これなら、リプレイスを俺はすすめるねーとおもったことは何度もありましたね。
あと、マイグレーション選択する企業は本当に貧乏な企業がおおくて、
いやーこれいくらでも移行のチャンスあったでしょというなかで
それこそハードも２０年物など使ってる企業ありました。
そんな企業は、それこそすべて捨てて①の開発がベスト、
しかし①をやってもまーそもそも、コンピュータいるのってレベルもあったりする。
それEXCELでできるじゃんって（笑）
そんな小さなマイグレーションはさておき。
今回の全銀のシステム規模正直、これって、めっちゃくちゃでかいじゃないですかね。
金融系って比較的システムに対する予算は正直高いのに、やらないレベルの金額がかかるし、そのリスクを考えたら神の領域で手を出すほど天罰がくる。
正直想像できないですが、
開発費用、３桁億でたりるのかな？４桁億？
たぶん名だたるベンダーが３社頭に入り、その後ろに
ビックネームのベンダーが数社はいり、末端まで含めれば
どれぐらい人数いるだろうね、新規でつくりかえるですよね ひろゆきさん
じゃ！よろしく！（笑）私はそんな自国のプロジェクト名前聞いただけで逃げますね。
しかも、おそらく最短で３年で済めばいいですよね。
５０年蓄積された有効プログラム本数何本だろ！それをCOBOLしか読めない人にCOBOL時代の設計書つくらせて、オブジェクト指向の開発 まじで笑える。
そして作り上げた後ろにある問題が、
メインフレーム圧倒的な処理能力の高さ！
仮想サーバでめちゃ積み上げて、実現。
取引がリアルタイムにおわらないですけど！ってなる。
なんでこんな開発すすめようとしただ！
リプレイスが正解だろ、リプレイスしていれば
こんなに赤字がでることはなかった。
おそらく、巨額の負債をかかけて大手ベンダー一社がつぶれるかもね
さてさて、社運をかけてやってもらいましょう！
ということで私は。
全銀の①すすめれません。
それによってよのなか便利になるならいいけど。
同じ動きなら、５０年前のプログラム事故なく動いた方がいい。
ちなみに今回も全銀システムが問題ではなく、取り巻きの問題だったようだ。
結構金融系て事故おこれば、ニュースにニュースなるので、
かなり入念に、テストしたと思いますよ。
また、リカバリー手段も確立し、しかし、
リカバリー手段は確立されてるけど、怖くてリカバリーすることは
なかたったりしたんじゃないかな、だから
いざリカバリーしたときにできませんでした。というのが今回例じゃないないのかな？
本来の理屈的には、その中間がおかしかったので、
その中間をさっきまで動かしたやつにもどして、データ戻せばという世界感なのだろうけど、やはり、難しかっただろうなーとおもう。
対応にあたった人間の青ざめた顔が想像できる。
金融系のシステムって正直そこまでかかわったわけではないのですが、
絶対修正させないですよ、これ絶対バグじゃんそうだね、
だけど、そこを改修せずに、結果だけ合うようにつくれないかなーなります。
バグをバグ調整プログラムを返した結果があってるなら大丈夫となります。
バグは多く含んでいるが、バグを含んだ状態で、
沢山の費用をつかってテストを実施しているので、
用意な修正であっても、責任を負えないから、変更がみとめられない限り
修正はタブーなんですよね。
そんなシステムだからこそ、リプレイスし続ける。
おおきな、チャレンジや業務的要素が絡まない限りチャレンジできないですよね。
ま、正直多少大げさに表現したかもしれないが、
話を整理しよう
・なんでそんな古いものを使い続けているのか・・・
答え）つくらたプログラムは古いけど、いまでも99.999999999999・・・・以上の稼働率を誇り、これからも99.9999の数字がのびていくほどの確立で稼働をつづけ、
安定し、安全に、快適にめちゃくちゃ沢山の処理をリアルタイムする
・古いから問題おこるんだよ！
すいません稼働率からみてもめちゃくちゃ安定して稼働しているのですが、
システムがバグがなく完璧なものは夢物語のなか、いままでニュースにトラブルが報告されることもなく、いままで取引されてきたんですが、１組織、１チームのミスを大きな問題にとらえすぎてませんかね？じゃ代わりのシステムつくれるならどうぞ作ってください！低予算で！自腹はOKです。追加分ははらいません。
・古いなら新しくすればいいじゃん・・・
そもそも機械は新しくなっているのですが？
そもそもプログラム言語は、腐ったりしないし、ただの文字なので、
同じ動作をずっとつづけるだけなので！
で、新しくしたからってなんか便利になるですかね？
新しく作り替えてなんか便利になるですかね？
便利なるところ教えてください。
え？ないんですか？じゃ？新しくするの意味なくね？
その予算、別のシステムあてようよ！
・どうせ杜撰なかんりしていたんでしょのような・・・
いや、金融って一番厳しいチェック体制と管理体制でやっていたとおもうよ。
でも、ま、そこは、リカバリーも含めて神域化していたのなら、
技術者の問題ではないね。
たいてい大きなシステムは、メインとサブなどあって、切り替えたり、
戻す手順を確立して、しかもリハーサルや、予備機で練習して挑んでると思います。
その手順に抜かりはこの世の中、平成はじまったぐらいのよのなかありうるが、
PMOなどプロジェクト管理の特殊部隊で管理されるような案件と推測されるけど
問題あって、リカバリーすらできなかった状況だと、すごい疑問にはおもいますね。
失敗したから杜撰だったのか？バグというのは起こる理由あって起こるので
今回参加した技術者の及ばないところで発生したのでしょう。
システムがでかすぎて局所的にテストは成功したが、
そのつなぎのところまで把握できなかった、ではそれを防ぐための、
つなぎ目のテストが結果的に漏れいたのだとおもいます。
杜撰だったのかそうじゃないのか、それは当事者のみぞ知るという感じでしょうか。
これらをよんで、
いった言葉が自分が浅はかだなーと思ってもらいたいものです。
でも、金融系のシステムトラブルがニュースになるたびに、
やはり、我々技術者は、可能な限り完璧をめざさなければいけないので、
普通に動くを実現することは並大抵ではないのですが、
やはり、エンジニアとして、ユーザが困るような状況がおこる
システムは、正直いらないといわれても仕方ない、
だからこそ、失敗を糧に、より完全なものを理不尽につきつめていかないといけない。
こんなバカなコメントいうコメンテータにまけないように。
