全銀システムに使うプログラミング言語、あなたなら何を選びますか？
先日、全銀のシステム障害について書いたが、その際、フォローさんからとても興味深い記事を紹介いただいた。
先日書いた記事はこちら。
紹介していくいただいた興味深い記事とはこちら。
全銀の2023年3月16日のプレスリリースである。
https://www.zengin-net.jp/announcement/pdf/20230316_basicpolicy_8Z.pdf
プレスリリースって、本当の本当に概要レベルしかないことが多いんだが、こちらはほぼWGの議事録といった様相である。32頁のボリュームだ。
書いてあることは、
1973年から運用し続けてきた全銀のシステムを一新したい
というものである。
これは、もう、全くもって、とてつもない開発になりそうである。
断っておくと、この「一新する」という事業は、先日2023年10月10日に発生したシステム障害とは関係しない。「一新事業」は、まだベンダの選定段階であり、開発に着手さえしていない。だから、これによるトラブルは発生のしようがない。
全銀のシステムは1973年に稼働して依頼、定期的に更新されてはきたようだが、メインフレームは変わっていない。言語はCOBOL。実に50年に及ぶ。それを一新するというのだから、気が遠くなりそうだ。この50年間に開発更新されたプログラムも含めて、もれなく記載された文書はおそらくはないのではないか。前世紀の開発というのは、電子化されていないことが多い。右手にシャーペン、左手に定規を持ってカリカリと書いていた時代である。初期設計を仮にきっちり書いていたとしても、その後の不具合改修、あるいは数年毎の更新など、その都度前設計内容を文書更新できていただろうか。さらにはまた、それを電子化できただろうか。電子化する際に間違い抜けが混入することはなかっただろうか。
「○○さんの頭の中にしかない」
そういうような思いもよらない条件、処理があるのではないか。いや、誰の記憶にも残っていない処理さえあるかもしれない。次期開発に、それらをもれなくすくいあげることはできるだろうか。
COBOLを解析するチームが必要である。解析し、その内容に基づいて試験設計しなければならない。既存の設計文書通りに再設計すればいいと考えているのであれば、トラブルはおそらく避けられない。ソースコードを読むことは必須と思われる。
さて。
タイトルに戻る。
一新するとして、プログラミング言語には何を選択すればいいだろう。
PDFには次のようにある。
ハードウェアをオープン基盤、OS・MWを汎用的なSW（オープンソース・ベンダー製品）にシフト。開発言語はCOBOLからJava等を使用することを想定。なお、オープン化に伴う製品選定に当たっては、当該製品の実績や確実かつ継続的な保守を受けられることを重視。特定の製品ベンダーに依存しないことにも留意。
『次期全銀システム基本方針』
『OS・MWを汎用的なSW（オープンソース・ベンダー製品）』というのは、Linuxを使うということか。汎用的で24時間365日の運用に耐えるとすると、そのくらいしか思い付かない。
Linuxで使えるプログラミング言語はいろいろある。
その中で、どれがいいだろう。
PDFには「Java等」とあるが、Javaがいいんだろうか。
Javaはガベージコレクションがあるので、メモリ管理がいらない。だが、24時間365日連続で運転するシステムに耐え得るのか。フラグメンテーションを起こさないのか。フラグメンテーションを起こしてメモリ不足に陥ることはないのか。一時的に陥ったとして、回復できるのか。それがどうしても不安なのだ。
私は、C言語の標準関数を使わなかった。システム開発で「malloc」も「memcpy」「memset」も使ったことがない。自作してきた。と言っても、このレベルの処理はそれほど難しいものではない。それよりも、フラグメンテーションや、処理速度を懸念した。「memset」や「memcpy」を自作した頃はアセンブラで書いている。処理速度に対する懸念については、昨今のハードウェアの性能をもってすれば考慮に及ばないかもしれない。では、フラグメンテーションはどうだろう。24時間365日、動き続けるのである。確保して解放するたびに、メモリがどれだけまだらになっていくのか、想像しただけでゲンナリする。
あはいはまた、マルチスレッドの排他制御。Javaであればスレッドセーフなデータライブラリもあるかもしれない。だが一方で、安易に乱用するとデッドロックを起こしかねない。
24時間365日の運転に耐えるためには、しっかりした設計が必要である。いつ誰がメモリを確保し、いつ誰がメモリを更新し、また解放するのか。誰が誰のデータ更新を「待つ」のか。これらの設計は極めて重要だ。これを間違うと、ソフトウェアはあっという間に泥沼化する。最悪は手がつけられない。
言語に安易に任せると「後は大丈夫」となって、考えなければならないことまで考えることなく済ませそうだ。そうではなく、いっそ自分が一から設計すれば、言語の力を借りることなく全部を設計すればそういったことにも自ずと慎重になるのではないか。
COBOLを捨てる理由の一つにこのようなものがある。
COBOL技術者が高齢化しており将来の要員確保が極めて困難となる
『次期全銀システム基本方針』
COBOLは古い。もっと洗練されたプログラミング言語を、というのはわかる。しかし、「技術者がいない」ということを理由にしていいのか。必要なのであれば、技術者の育成が必要ではないか。それも、講義や実習といったレベルではダメだ。古参の技術者に若手技術者をつけて、ペアリングで作業するくらいのことが必要である。若手はそうして熟練技術者から吸収する。文字通り、学ぶのではなく吸収するのである。その吸収した技術を下地にして、新しい技術に移行する。
次世代全銀システムのプログラミング言語。
C、もしくはC++
メモリ管理もマルチスレッドも排他制御もきっちりできる技術者が必要だ。いや、どんな言語を選んだとしても、それらに精通した技術者が必要なのである。その設計を間違った場合、どうなるのか。それこそ、保守メンテナンスできる技術者はいなくなる。メモリ管理もマルチスレッドも排他制御も、それらに破綻したプログラムの保守は難しい。とてつもない繊細さが求められることになる。安易な開発は保守を難しくする。ソフトウェアの品質とは現動作に間違いがなければいいというものではない。保守拡張再利用に優れてこそ、真に品質の高いソフトウェアと言える。
全銀のように重要な社会インフラの位置にあって、かつ複雑であろうことが予想されるシステムに、どの言語を選ぶべきだろうか。技術者がいないという理由で選ぶのではなく、是非とも優秀な技術者達で開発してほしい。優秀な技術者を育ててほしい。
全銀はどの言語を選ぶだろうか。
この記事が気に入ったらサポートをしてみませんか？