メインフレームCOBOLプログラマーの母へのインタビュー（2016）
(ezali.substack.com)メインフレームCOBOLプログラマーの母へのインタビュー
- 母は私が生まれる前から、EU域内で最大級の銀行の一つで働いている。
- 銀行プログラミングの世界は、ほとんどの人が慣れ親しんでいるものとはまったく異なる世界だ。
- 母と彼女のチームが仕事をやめれば、その銀行は数週間以内に立ち行かなくなるだろう。
1991年
- 母はNordbanken（現在のNordea）で社内研修を始めた。
- さまざまな試験を受け、IQテスト、心理検査、マルチタスクテストに合格した。
- IBMメインフレームのCOBOLプログラマーとして始め、25年後も同じ銀行で同じ職務に就いている。
COBOL
- COBOLは、関数型のHaskellや並行性に優れたGolangのような華やかなプログラミング言語ではない。
- COBOLは命令型・手続き型の言語であり、2002年からはオブジェクト指向にも対応している。
- メインフレームプログラミングの文脈では、COBOLを知っている人はほとんどいない。
データベース
- 主なデータベースはIMSと呼ばれ、IBMがアポロ計画のために作った階層型データベースだ。
- DB2への移行を試みているが、これには何年もかかる作業となる。
- DB2データベースは現在およそ10TBのデータを保持している。
バッチ
- システムの約80%はバッチジョブで構成されている。
- バッチジョブは特定の時刻または間隔で実行され、データ処理や他の銀行・機関へのデータ送信を行う。
銀行が直面する問題
- メインフレームを使用している銀行には、対処しなければならない多くの問題がある。
- プログラマーの高齢化が進んでおり、新しい社員が独力で働けるようになるまで2〜3年かかる。
- 何十年も前のプログラムがあり、誰もそれが何をしているのか分からない。
最後の言葉
- Nordeaや他の銀行が今後数年間でどのような新技術を導入するのか、とても興味深い。
Q & A
- なぜIBMメインフレームのCOBOLプログラミングを選んだのか？ コンピューターと一緒に働きたかったから。
- 一日の中で最悪だった出来事は？ 同僚が重要なシステムモジュールのピリオドを抜かし、銀行が16時間ダウンしたこと。
- 銀行の未来はどうなるのか？ メインフレームをより現代的なものに置き換える必要があると認識している。
- 90年代に女性プログラマーとして直面した課題は？ 問題はなかった。
- 20年以上同じコードベースで働くのは退屈にならないか？ 新しいシステムを作るのはいつも楽しかった。
- 銀行向けのコードを書くのは怖いか？ とても怖いが、テスト環境が堅牢なのでたいていは円滑に進む。
- 銀行のために大きなミスをしたことはあるか？ 1997年に、退職貯蓄口座から違法にお金を引き出せるようにしてしまうミスをした。
- 作業環境はどうか？ 個人デスクの環境からオープンスペースに移り、それをとても嫌っている。
GN⁺の見解
- メインフレームとCOBOL言語は今なお金融業界で重要な役割を果たしており、この技術に関する専門知識は非常に価値が高い。
- 銀行システムの複雑さと古い技術への依存は、新しいシステムへの移行を難しくしており、これは大きな課題だ。
- このインタビューは、技術が急速に発展している一方で、一部の業界では今なお古い技術が使われ続けていることを示しており、興味深い対比となっている。
1件のコメント
Hacker Newsの意見
2016年の元のHN投稿はhttps://news.ycombinator.com/item?id=12096250だった。
「銀行プログラミングの世界は、私たちの多くが慣れ親しんでいるものとはまったく別世界」というテーマでもっと読みたいなら、An oral history of Bank Pythonもよい: https://calpaterson.com/bank-python.html
以前HNにも投稿されていた: https://news.ycombinator.com/item?id=29104047
https://news.ycombinator.com/item?id=12097032
「20代のメインフレームプログラマーなら年齢そのものが大きな価値になるので高給を取れるはずだ」とよく考えられがちだが、現実はたいてい平均的か、場合によっては平均以下で、人材パイプラインの問題が生じる。
本当に価値があるのは「COBOLが分かる」といった技術そのものではなく、COBOLの中に蓄積された膨大な業務ロジックに関する組織知だ。平均的な開発者でもCOBOLは学べるが、引退したCOBOLプログラマーが年50万ドルの契約で呼び戻されるのはCOBOLのためではなく、蓄積された機関知識のためだ。
もし銀行や各種機関が若いメインフレームプログラマーに本当に高額を払っていたなら、今の人口構成の問題はここまで深刻ではなかっただろう。
プロジェクトはほぼ終わったと見なされ、書き換えチームはCOBOLに十分慣れたので残りは彼抜きでできると判断したが、実際にはCOBOLを理解していても彼の機関知識が切実に必要だった。結局彼は移行完了まで非常識なほど高いコンサル単価でパートタイム復帰し、その間に大学院にも通って能力を伸ばしていた。
まともなプログラマーならCOBOLプログラムを読んで追うことはできる。だが、10-K申告用のデータ抽出中になぜ重要なエクスポートが落ちるのかは分からない。誰かが特定のレコード数は3000を超えないだろうと見込んで、その値を超えたら単にエラーを出すようハードコードしていたからだ。
実際には前職の物理ケーブル設備工事、つまり光ファイバーや銅線イーサネットの敷設よりずっと少ない給料で、その仕事を選んだ理由もオフィスにエアコンがあるという程度だった。キャリアにしたい仕事ではなかった。
クラウド事業者で顧客対応の電話サポートをする中堅Windowsシステム管理者として働いていたときのほうが、銀行/保険会社でジュニアのメインフレーム担当をしていたときよりほぼ30%多く稼いでいた。希少なスキルで高付加価値の業界なのに、メインフレームの仕事のほうがはるかに低い報酬だったし、その会社ではメインフレーム開発者が全キャリアレベルで開発者の中でもっとも低い報酬だった。きちんと報われていたのは、引退前に30年間働いていた独立契約者だけだった。
だが、その種の役割の賃金は他の技術で得られる報酬と比べて悲惨で、現代の生活はもっと高い給料を追うよう強く圧力をかけてくる。
このプログラムでは業界の初級職として「公正な」市場価格を提示し、1年目に2〜3のチームや部署を経験させた。終わる頃に会社をなお気に入っていれば、候補者は正社員として行くチームを選べたが、昇給はなく、その時点ではすぐ成果を出せなかった人たちはすでにふるい落とされていた。
会社にとって結果は素晴らしかった。新しい同僚たちよりCOBOLに長けた若手プログラマーを年6万〜7万ドルで使えた一方で、シニアや長期勤続の同僚たちはケースによって20万〜40万ドルを受け取っていた。
祖母はパンチカードでプログラミングしていたが、どんなハードウェアだったのかは分からず、今となっては聞くには遅すぎる。父はソ連のメインフレームでFortranとCOBOLを多く書き、その後は米国でY2K対応もたくさんやっていた。
その中でいちばん素敵なのは、父が昔撮った山の写真の64mm大判フィルムを包むために、3枚に裂いて使ったFortranプログラムの出力だ。たぶんMinsk-32メインフレームから出たもので、プログラム名はMATR1、行列操作を行い、コメントには地形への言及がある。今は作業台の近くの壁に額装して掛けてある。
自分も一生いろいろな言語でコードを書いてきたし、今では10代の子どもが高校でJavaやPythonをやり、コーディングに関心を示している。4代目のプログラマーへ
技術的な観点から見て銀行で最も重要なポジションだというのが本当なら、Nordeaのスウェーデンおよび北欧市場でのシェアを考えると、そのチームが消えたらスウェーデン、ひょっとすると北欧経済まで揺らぎかねない。そうなればEUにもかなり影響しそうだ。
この記事を読んで以来、こうした銀行を動かしているCOBOLプログラマたちは、世界のさまざまな経済圏でひどく過小評価されているバス係数なのではないかと気になり続けている。そういう事態に対するバックアップ計画が何なのかも気になる。
[0] https://en.wikipedia.org/wiki/Nordea
あの惨事では、組織知の喪失が大きな要因だったのではないかと思う
歩行者や自転車利用者にとってより危険なSUVの販売増まで加えると、銀行が死んだプログラマのせいで崩壊するのではなく、ひどい会計や詐欺で崩壊するという事実のほうがむしろ驚きかもしれない
「自分専用の机があったのに、今は好きな席を選んで座るオープンスペースに移されて本当に嫌だ」というくだりは、メインフレームの仕事をしたことがなくても妙に強く響く
椅子、モニタの位置や明るさ、机の高さなどが自分向けに調整されているので、ホットデスキングという概念自体がばかばかしくなる。いっそ公式にやめてほしい
金融サービス分野でシステム統合コンサルタントとして働いていたとき、こうしたコアバンキングシステムとの統合を数多くやらなければならなかった。
たいていは、まったく新しいインターフェースを交渉すると技術面・事業面・規制順守面での摩擦が大きく、プロジェクトが1〜2年以上簡単に遅れてしまうので、以前のプロジェクトにあった既存の統合ポイントを再利用しようとしていた。
統合はたいてい、夜間バッチ処理のために夕方の決まった時刻までに構造化文書を渡す方式だ。オフセットベースのデータ文書には、将来の更新や利用のためにまだ割り当てられていない領域が設計上含まれており、新しい情報が必要になると、そのうちどのバイトを使えるかを交渉する。
データ抽出側では、もう少し「モダンな」APIを探すこともあるが、細粒度のRESTのようなものをあまり期待してはいけない。コストの大きい新規開発を避ける方法を見つけるため、規制担当やコンプライアンス担当と会議することが多かった。
付け加えると、コンプライアンス担当者のほうがITよりもずっと実務的で解決志向なことが多かった。規則の文言は必ずしも最も制限的に文字どおり解釈しなければならないわけではない、と自分たちのチームを納得させるほうが、コンプライアンス担当者と合意するより難しいことがよくあった。
こうした統合レイヤが数十年にわたり何百ものプロジェクトで積み重なってきたと想像すれば、なぜコアシステムの置き換えがそこまで難しいのか、初めて実感できるはずだ
義母は保険会社のIT部門で一生働いていた。プログラミングをたくさんしていたわけではないが、時がたつにつれてドメイン知識の源泉になっていった。
昔の話がいろいろある。ちゃんとしたコンピュータシステムが導入される前は、当然ながらすべてが紙の文書で保存されていて、大学卒業後の最初のプロジェクトは、本社が打ち出した新しい戦略に合わせて支社のファイルシステムを再編するため、各地のサテライトオフィスを回る仕事だった。
チームが文字どおりすべての書類を取り出してラベルを貼り直し、また戻しているあいだ、その支社の業務は止まり、プロジェクト全体は1年以上かかった。自分の仕事に対する見方が少し変わった
祖母が認知症になる前に、もっとたくさん話を聞いておけばよかった。数学者でありプログラマだったことは知っていたが、数年前に少し話したとき、ソ連で衛星軌道の計算をしていたと言っていた。
少なくとも衛星だったと願いたい
20歳で3年で数学の学位を取り、1970年代にはパンチカードでコンピュータをプログラミングしていた。
今では靴ひもすら安定して結べない。手遅れになる前に、愛する人たちの業績や人生の物語を記録しておいてほしい
使いやすく、あらかじめ用意された質問も多いし、自分で質問を作ることもできる。スマホに直接録音できて、望むならそのインタビューを米国議会図書館にアップロードすることもできる。
https://storycorps.org/participate/storycorps-app/
祖母は今年95歳になった。今でも旧ソ連圏の研究所に毎日通い、FortranとMapleで数値シミュレーションを書いている。
同僚たちもいまだに引退を望まず、祖母も毎年引退を先延ばしにしている。数値解析と数学の知識が卓越していて、本当に誇らしい
最初のプログラミングの仕事先は運輸会社で、15〜20年以上働いているプログラマーが多く、そのかなりの数が事業を支えるCOBOLを主に保守していた
そのシニアプログラマーたちの中には女性が多く、シニア層では50%を超えているように感じられた。悲しかったのは、若いプログラマーにもまだ女性はかなりいたものの、全体としては男性が多かったことだ
その会社は主に地元の工科大学から採用していたので、時間がたつにつれてソフトウェア工学専攻に進む女性の数がどのように減っていったかを示す興味深い事例のように見えた