金融・COBOL・保守要員でエンジニアの成長は積むのか
新卒で入社したITベンダーでCOBOLを教え込まれ、金融機関にシステムの保守運用要員として送り込まれたら、一巻の終わり。「失敗は犯罪的行為」という金融機関のIT部門の文化にどっぷりつかり、要求された通りに保守作業などを続けていれば、ビジネスパーソンとして、技術者としての成長はおぼつかない。
「 一巻の終わり」なんだそうだ。一巻の終わりとはエンジニアとしての成長がおぼつかないのだそうだ。まあ、そういうエンジニアもいるのでしょうね。
この記事では、エンジニアの成長には失敗をすることで成長するのが前提らしいけれど、失敗をしなくていいならしない方がいいじゃない、と思うのだけれど。
それは挑戦をしないということではなくて、用意周到に準備をするとか、進むステップを刻んでピボットするとか、やり方を工夫して、という意味で。
なんとはなく、記事の背景には、
それなりの失敗を重ねること＝エンジニアの成長
という図式があるのではないかしら。
例に突っ込んでも記事で言いたいだろうと思われることと外れるかもしれないけれど、「失敗は犯罪的行為」の犯罪的という表現はともかく、金融、例えば銀行の勘定系で失敗、計算が間違っていたら犯罪というより、一預金者として預けておいたら気が気じゃないのではないか、と思うんですが。少なくとも嫌ですよ、そんな勘定系システムは。
失敗＝エンジニアの成長ではない
これまで「失敗をしよう」というテーマでエントリを書いてきているけれど、失敗の前に「小さな」としているのです。
あえて「小さな」としているのは、小さな失敗なら軌道修正してリカバリをできるようにするためです。
金融・COBOL・保守要員であれば行内NWに閉じられた閉鎖空間だから、新しい技術やツールを気軽に導入することはできないけれど、エンジニア自身の仕事の仕方の工夫などテクニック的なものやマインドセットのようなものまではいくら金融だとしても制御できないです。
小さな失敗と二度と繰り返したくない失敗と取り違えてはいけない
小さな失敗をしよう。なぜなら、エンジニアとしての改善を続けることに繋がるからだし、プロセスを見直す習慣にもなるからです。さらに、小さく進めることで期待する結果と期待していた結果を測定する習慣も身につくのです。
一方、二度と繰り返したくない失敗というのもあります。その経験で得られるものはリスクを識別する能力を学習することです。
まあ、トラウマになる経験ですね。
そんな経験はしなくでいいです。ほんと。身の危険を感じますよ。進退も。
失敗する機会、タイミング、程度があるのです。
金融・COBOL・保守要員は積むか
金融は技術的な閉鎖空間の意味合いがあるのでしょう。分散系であってもIE6とかjavaの古いバージョンが重荷になっていた時期があったものです。枯れている技術を採用する傾向が強いので、プロジェクト開始時点で安定しているバージョンを選びますから。
COBOLは古い言語だからシンボル的に挙げられていますけど、じゃあCはとかアセンブラとかはどうなんでしょう。分散系の言語の更新の方が早くないでしょうか。廃れてしまう言語を学ぶのもいいですが、使い切る前に新しい言語を学ぶようでは、使いこなすという習熟をどこで学べば良いのかしら。
保守要員ほど他人が書いたコードを読み取って新たな要件を追加することで影響を見切るのはそれなりの技量が必要だと思うのです。
金融・COBOL・保守要員で積まないエンジニア
経験から言えば、金融ほど標準化が進んでいる業種はないと思うのです。ある時期はどのベンダーも金融に一番優秀なエンジニアを配置していました。今は違うのでしょうか。
学ぶ情報、プラクティスは金融がいいのではないか、と。色々と継ぎ接ぎだらけなのかもしれませんが、そうしたプラクティスから自分なりに体系を抽象化することで得られるものは他のインダストリーにはないと思います。
言語も学習方法を学ぶことで対応力の幅が付いてきます。
多重請負であるとアクセスできる情報できる裁量は限られますが、それは他のインダストリーに行っても同じことです。
少しパラメータは違えど、超大型案件の中の時間が確保できるプロジェクトでプロジェクトマネジメントの体系的な学習と実務で使うツールを身につけた経験から言えば、このまま埋もれたくないとエンジニアが行動するだけで結果は付いてくるのです。
