流石にタイトルが酷かったので修正しました。(2018/2/5 2018/2/15)
新人にCOBOLをやらせてはいけない
先日、Twitterでこんな話題がありまして。
新卒にCOBOLをやらせるとか本当に何を考えてるんだと言わざるを得ませんね。私なら全力でそんな会社は回避しますね。内定出たとのことですがまだ大学3年生なら私なら他の会社探します。 #peing #質問箱 https://t.co/eV9wt3MxCU
— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) 2018年2月13日
COBOLって駄目なんですか?
ぼくもこの話題に対してこんな感じで反応しまして。
えっ、、、、、マジ・・・・?
— える.jar(deploying) (@ellnore_pad_267) 2018年2月13日
こぼる・・・? https://t.co/ij8tvNtoXz
するとこの反応に対してこのような質問を頂きました。
COBOLってダメなんですか?
夏に参加した合説でCOBOLやるって言ってた企業がありました
なるほど。
合説ってあれですよね、企業合同説明会。
去年の夏に合同説明会に参加した就活生って事でしょうか。
(実はぼく合同説明会とか新卒就職活動ってやった事が無いので、この辺ちょっと良く解らないんですよね)
閑話休題。
とは言えぼくも仮にもこの業界のエンジニアの端くれであり、このような質問をすると言う事は僕にとっての後輩でもある訳ですよ。
未来ある若者の為に、真面目に回答しなければなりません。
と言う事で、この質問に対してちょっと真面目に書いてみたいと思います。
COBOLって駄目だと思います。
ハッキリ言ってCOBOLはダメだと思います。
COBOLがダメって言うか、正確に言うと少し違くて。
今このタイミングで新人にCOBOLをやらせようと言う企業はダメだと思います。
つまり正確には、COBOLと言う言語が何か問題あるって言う訳では無くて、新卒にCOBOLをやらせると言う事に問題があるという話なんです。
新卒にCOBOLをやらせるのがダメな理由
と言う事で、新卒にCOBOLをやらせる事が何故ダメなのかに関して、何となくぼくの見解を述べてみます。
前提
なお、ぼく自身は世代的な理由もあって、実際にCOBOLでの開発をやった事がある訳では無い、と言う事実を先に明記しておきます。
また、もう一つ事実を述べておくと、ぼくはCOBOLが嫌いです。(個人的な感情)
今この会話見て思い出したけど、おれ昔「明らかにCOBOL出身者が作った、COBOL用と思われるコーディング規約を適用されたC++」の案件やらされて軽くトラウマになったんだよね・・・・。
— える.jar(deploying) (@ellnore_pad_267) 2018年2月13日
あれはほんとトラウマ、COBOL嫌い。大嫌い。 https://t.co/7WqmflG0rR
まぁ、多少見解が偏ってるであろう事はお察し。
そもそもCOBOLとは?
概要から要点だけ幾つかピックアップして来るとこの辺がポイントかな。
つまりVBに近い思想の言語って事ですね。
VBも確かあれだよね、確かC系が苦手なおばちゃんが「自分が事務処理の手続きを記述し易いように」ってコンセプトで作ったBASIC言語がベースになってるんだよね。
何かそんなような話を聞いた事があります。(昔話の伝聞なのでこれも良く知らない)
COBOLのメリット
COBOLには幾つか利点があって。
- 言語構文的に記述自由度が低い為、逆に「誰が書いても同じようなコードになる」と言う特徴があるので、可読性・保守性が自然と担保される言語である。
- 言語のデフォルトで正確な数値を扱える型が存在する。
幾つかって言うかゴメン、二個しか挙げられなかったわ。
スマン許せ。
保守性・可読性
言語構文的に制約が多く、自由度が少ない。
この為「誰が書いても同じようなコードになる」ので、個人差や好みによる揺らぎが少なく、COBOL技術者であれば他人の書いたコードを比較的簡単に読める。
高級言語はコードに自由度が高い為、同じ事をやるにしても人によって書き方が全く異なるので、他人の描いたコードを読むのにある程度のコストが掛かるのが普通ですが、COBOLに関して言うとそのコストが限りなくゼロに近い。
これは大きなメリットと言えます。
正確な数値
Javaであれば BigDecimalクラス
、C#であれば decimal型
と言うのがあるんですが。
金額のような「正確な数値計算」が必要な場合、演算誤差やら小数点処理やらで、実は結構めんどくさい話があります。
で、COBOL時代の古い言語ではこれを標準でサポートしているのは珍しいと言えるんですが、COBOLにはそれがあるんですよね。
これは非常に優秀な点。
COBOLの多い業界
前述したメリットと物凄く親和性の高い業界があります。
いわゆる「金融・証券系」と言う業界です。
この業界が良いか悪いかっていう話はまぁ主観問題だと思うので特に言及しませんが。
ただ、Web系に比べて開発期間が長く工数がかなり積まれる傾向にあるが、そのぶんテストがガチガチで1円どころか1銭のズレも許されず、バグはゼロが当たり前みたいな世界です。
そう言うのが性に合っていると言う人も少なからずいると思うので、自分の性格と要相談って感じじゃないですかね。
COBOLの問題点
一言で言うと、古い。
必ずしも「古い」イコール「悪い」って訳じゃないって話は勿論あるんだけど。
この業界に於いて一定レベル以上の「古い」と言うのは物凄いリスクになると言うのは一つの事実です。
まぁ、COBOLの問題点なんて挙げてけば多分キリが無いのでバッサリ割愛しましょう。
今回の主題である「新卒エンジニアにCOBOLをやらせるうえで」と言う範囲に絞って話をします。
新規開発はもうない
基本的に現状でCOBOLの案件ってのは、既に開発が終わったものが殆どで、いわゆる「保守案件」が大半のようです。
(前述の通り、ぼく自身はCOBOLの実務経験が無いので、これは単なる伝聞なので実際の市場を知ってる訳では無いが)
保守をメインにやってるエンジニアを悪く言う訳じゃないですが、どう考えても設計・開発に関わるチャンスが無いとエンジニアとしての開発スキルの伸び具合には差が生まれます、それも圧倒的な大差です。
(実装殆どやった事ないくせに要件定義と設計だけやってて上流工程エンジニアでござい、ってやつはカスなのでそれは無視)
コードは書かなきゃ経験値にならんのですよ。
これはもう純然たる事実。
COBOL技術者の高齢化問題
前述した通り、COBOLと言う言語は保守性と可読性が高い、と言ったんですが。
でも読む人間居なくなったら意味ないっすよね。
幾ら言語が読み易い言語とは言え、それを知ってる人が絶滅したらもうロストテクノロジーな訳ですよ。
簡単に言うと、COBOLと言う言語が置かれている現状はそう言う状態です。
現時点で生き残っているCOBOL技術者ってもうほぼ例外なく現役引退を目前としたオッサンだけなんですよ。
つまり絶滅危惧種なんすよ。
COBOL資産を持っている企業にとってかなり切実な問題が、その資産を扱える人間が居なくなりつつあると言う負の遺産問題です。
負の遺産を抱えた企業の思惑
COBOLを捨てて、新しい言語で作り直し、延命したい。
と言うのが企業側の思惑です、まぁ当然です。
捨てると言っても完全に「ポイッ」と捨てる訳じゃなくて、COBOLが解る技術者を集めてCOBOL以外の言語で書き直しさせるみたいな、いわゆるリプレース・マイグレーションと言う案件がまぁCOBOLの最後の特需になるであろう、と言われて久しいようです。
(繰り返しますがぼくはCOBOLの実務経験が無いので、もう寿命を全うしたのか、ギリギリ生きてるのかは知りません)
※実際に、確か2000年問題の時だったかなぁ、COBOL出来る人が必要だつって一時的な特需があった気がします。まぁあの時はぼくはそもそも現役エンジニアじゃなかったんで「伝聞の伝聞」と言うかもはや「伝説」なんですけど。
でね。
なんだ、特需があるなら良いじゃないか、って思う人も居るかも知れないんですけど。
その特需を最後にそこから先は無いと思われます。
つまり、それが終わったらもう用済みなんですよ。
未来に繋がらない。
複数言語扱える事で見えて来る事や理解出来る事、いわゆる「引き出しが増える」って状態になるので、そう言う意味でCOBOLを知っておくと言う事は決して無駄では無いですし、これは別にCOBOLに限った話では無いです。
これはまぁ、事実。
逆に、単一言語や単一フレームワークしか使えないなんて人は、その単一すらまともに理解しているとは思えないので似非技術者の可能性が非常に高い。
なので、多くの言語を経験する事は良い事です。
うん。
ただ。
今、COBOLをやる事が、今後のWebが主流のシステム開発時代に於いて、大きな財産になるか?
と言われると、答えは圧倒的にNOです。
結論
新卒にCOBOLをやらせる会社は、その新人の未来なんざこれっぽっちも考えていない、目先の金儲けをしたいだけのクソ企業なので入ってはいけません。
関連する日記
なお、この手の話題については木村さんの極限暴論に詳しいので、それを熟読する事をおすすめします。