  |
はてなキーワード: Cobolとは
まだまだ一部のエンジニアにとって、という話だよね。
少なくとも英語の読み書きができないと最新のテクノロジー情報をキャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースにコントリビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。
でも日本にいる80万人以上のITエンジニアのうち、そうした能力を必要とされないエンジニアがこの日本の大部分だ。
なぜならSIerみたいな受託開発・運営がソフトウェア業界の売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから。
枯れた技術で安定性を担保ってのはわかるが、公式のサポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語を保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。
オレは新卒で入った受託ソフトハウスや大手SIerで計8年働いて、6年ぐらいはwebアプリのプログラマ・SEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードのコメント読むなり顧客のメール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。
コーディングで英語を使うと可読性が下がるから変数名・メソッド名・データベースのテーブルやカラム名もヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。
とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。
悲しい愚痴、以上。
この記事を読んだ。
http://anond.hatelabo.jp/20160619185731
元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。
この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。
汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。
今では信じられないほどの経験を当時（といっても2年前）はしていた。
改めて今、RubyというかRailsを始めてよかったなーと思う。
いやー、これが一番ひどかったな。
まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。
全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。
そしてインデントもレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。
定規で計るんだよ。半角スペースが5ミリだったっけな。
それで5ミリずれてたら指摘するんだよ。目がつかれたよね。
っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。
これもびっくりだよね。
専属の社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。
ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。
ネットは使えない。現場に入る時も持ち物チェックとかあるしな。
常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。
まだまだあるんだけど、これだけでもひどい現場だったなーって思う。
そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。
Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。
この先もっともっとブラックボックスなフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。
汎用系のエンジニアからRubyのエンジニアとして転職して1年。
コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。
その特徴はだいたいこの3つだ。
やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。
そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。
テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。
ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。
そもそも自分が行おうとしているソートが何ソートなのか知っているのか？計算回数を考慮した上での実装か？
便利なメソッドがたくさんあるのは知っている。
ただ、中身くらいは知っておこうよ。
新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。
「Githubで公開されてましたんで導入しました」じゃねーよ。
得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。
そんで都合の悪いところだけコードを読んでオーバーライドする。
影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの？
いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。
エンジニアもどき量産言語だね。どれか１つでも当てはまった奴は小学校からやり直せ。
追記
意見がたくさんもらえて喜ばしい。
文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。
「だいたい」とあるだろう。全てのだいたいだ。
＞フローチャート糞
精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。
＞カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける
あー、ここは誤タイピングだわ。
自動テストでカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。
単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)
五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee scriptが結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい！！みたいに言ってるんじゃないでしょうか。
まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります。特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ（≒JQuery）と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。
まあこれを突き詰めるとじゃあetaxもactivexで、銀行のシステムはcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、
とりあえずこんなところで、有識者の皆さんよろしくお願いします。
React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。
id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない？という感じです。
id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で（どのくらいの規模のプログラムで）domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。（もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。）なんかReactががりがり（かつユーザー目線から見て有効的に）使われている例がイメージ出来ないのが問題な気がしてきました。
id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。
id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domのメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。
id:manaten もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
自動車のエンジンで使われてるオットーサイクルは、1980年どころか1880年代（130年前）に開発された
バルブ開閉のタイミングだの燃料噴射装置だの電子制御と組合せて性能は向上してるにしても、
PC-98（30年前）よりCOBOL（50年前）よりENIAC（60年前）よりずっと前から本質的には変わってない
地球の裏側からタンカーで運ばれ、精製して消費地近くまで輸送しないと使えない化石燃料が、
これまではどうにか手に入ったとしても、これからは払うお金もないし競争相手も増えるし、
ずっとずっと手に入りにくくなるわけで、本当にどうすればいいんだろうね
perlが出来るのはkent-webのcgiで盛り上がってた時代にperlを書いていた人たちだけ。
perlでコードかける世代はもうおっさんだし、そのおっさんも出世してコードを書かない役職についてたりする。
おばさんプログラマーは結婚して退社してプログラミングすらしてないだろう。
movable typeとか終わってるよな。
開発できる人が減っていけば自然消滅間違い無し。
issueもないしperlで書かれたmovable typeってオワコンでしょ。
wordperssなら10年後も残っているだろうがmovable typeは消えているだろう。
何故movable type消えるか？
http://anond.hatelabo.jp/20160413023627 を見て触発されたので書く。
タイトルのようなことについて、実態というか現実というか、そういうのを当たり障りない範囲で書こうと思う。全ての企業や学生に当てはまるはずはない（むしろかなり偏見や単純化を混ぜてる）けど、参考になれば幸い。
ちなみにトラバ先は研究を志望したという話だけど、本エントリは研究志望というよりは一エンジニア志望向けかも。
あえて定義はしないけど、Github で公開されてるような OSS を使ってます/いじってますとか、LL 使って Web アプリ作ってますとか、アジャイルやらテストコードやら最近主流の手法使ってますとか、そんな感じで捉えていただければ幸い。あるいはメインフレームで COBOL とか周辺機能を全部車輪の再発明してるC言語製アプリとかそういう古い仕事ではない仕事、と捉えてもいいかも。
トラバ先のトラバの言葉を借りると「日本的な旧来型のIT大企業」という感じ。
ITという言葉には色々な意味がある。大手IT企業だとこれが特に広い。もちろん「モダンな開発」も含まれているけれど、そんなの全体のごく一部でしかない。（主観だけど数 % とかじゃないだろうか）
話は少しそれるが、大手IT企業は元々メインフレームなど「化石」で発展してきた経緯がある。何十年以上も昔、コンピュータといえば化石しかなくて（それでも当時は最先端）、それを個人やそこいらの企業では相手にできないような大組織に対して導入してきた。プログラミングの手法やノウハウが十分存在しない時代だったけど、それでもやるしかなくて、幸いにも昔は今ほど不景気ではなかったし人材も豊富だったから人海戦術で何とかなった。
そうやってつくられた化石コードと化石システムは今なお動いているし、時代に合わせてそれなりに機能追加もある。大手IT企業は化石から離れることができない。現代が化石で食べていけるほど甘くない時代だとしても。
そもそも化石に詳しい化石人が現役引退や昇進などによりいなくなったということもあって、実は現状維持ですら大変である。たとえばレガシーで汚い膨大なソースコードを知る者は誰もいない。もちろんネットで調べても答えなど出ないし、IT界隈のコミュニティに頼ったところで知る者はやはりいない。どんなに時間がかかっても読んで、理解するしかない。どんなに時間がかかっても。
以上のような現実があるので、化石のお仕事に新人を割り当てることも普通にあるし、むしろそうなる確率が圧倒的に高い。
大手IT企業にとって新人とは「専門的な技能や経験は無いが、地力(頭の良さ、伸びしろ、根気など)はあるため近い将来使える戦力になる卵」である。
対人コミュニケーションには自信ありますという遊んでばっかのリア充も、OSS に Contribute してました大学はほとんどパソコンと向き合ってましたという趣味グラマも、同じ「新人」でしかない。
「新人」は技能も経験もないので、いきなり一人前の仕事を任されることはない。電話応対、飲み会の企画運営など雑用全般を任されつつ、簡単な仕事がアサインされる。
この簡単な仕事というのが曲者で、手順書にしたがって環境を整えるとかテストをするとか、そういう仕事だ。手順書を読める程度のIT知識があれば誰でもできる。でもボリュームは多いし、手順書は不完全で不正確だからわからないところが多々あって、忙しい先輩や上司に何度も相談しにいくことになる。言うなれば「属人性の高い単調な手作業仕事」とでも言えようか。
ITを知らない素人新人ならこれが仕事だと抵抗なく受け入れられるが、ITを知る新人だったら、これはとてつもない苦痛だろう。配属先が「モダンな開発」を行う部署であれば苦痛具合も軽減されるし、なんなら「君結構詳しいんだね。じゃあ早速本格的な仕事任せてみようかな」なんてこともありえる。化石部署だとそんなことはない。だって、仕事で扱ってるシステムは化石だからモダンなIT知識なんて役に立たないもの。
この「新人」に、早くて数ヶ月、遅くて数年耐えると、次第に仕事を任せてもらえるようになる。設計やコーディングといった、エンジニアらしい仕事だ。といっても、配属先が化石部署であれば、当然扱うのも化石なわけで、いつまでたっても化石で苦しみ続けることになる。
一方で化石部署から異動し、「モダンな開発」を行う部署で働く者も存在する。これには色んなパターンがあるが、おおよそ以下のような状況が重なって異動するパターンが多い気がする。
大手IT企業では エンジニア→中間管理職(部長以下)→偉い人(部長より上) というキャリアパスがつくられている。特徴は
こんな感じ。
いつまでもエンジニアとして働いて、でも給料はそれなりにもらって、ということはありえない。成果を出せば昇進するし、昇進すればエンジニアから離れていく。成果を出さなければエンジニアとしていれるけど、いつまでたっても給料は増えない。大手だけあって新人時点での給料はそこそこ良いけれど、30代以上になってくるとそれでも苦しい(物欲無き健康的一人暮らしなら問題無いが、家族を養うつもりなら相当苦しい)し、そもそも無能な管理職に振り回されることに対して苛立つだろう。つまりエンジニアとして何十年も働き続けにくい。
「昇進するつもりだから問題無し」と考えている人も要注意である。というのも、大手IT企業は管理職で溢れかえっているからだ。新人が昇進するのは非常に難しい。昔は割と誰でもなれていたし、実際「こんな奴がなんで管理職になれてんだ？」っておっさんもたくさんいるけれど、今は違う。一握りの社畜（必死に仕事に食らいついてきた＆先輩や上司からのウケも良い）だけが昇進できる。たとえエンジニアとして優秀な仕事をし、正当な意見を主張してきたとしても、空気を読んでウケの良い社畜にならなければ昇進はできないのである。
大手IT企業の研究所は非常に狭き門である。トラバ先でも言及されているが、博士課程を終えたようなガチさに加え、当然のことながら学歴も必要になってくる。実際、研究所の人間は英語を当たり前に読み書きできたり、分厚い技術書を躊躇なく読み込んだりするような変態であり、裏を返せばそれほどの実力と熱意がなければやっていけない世界というわけで。とにかく多少ITに覚えのある凡人が入れる場所ではない。
また、入社後に研究所に異動するケースもほとんど無い。一般部署の凡人をわざわざ引き入れる理由が無いからだ。
ここまで色々書いたが、そもそもなぜ大手IT企業を目指すのか。それは以下のような理由や期待があるからではないか。
確かに上記のメリットはある。あるけれど、ここまで書いたように
といったこともあるわけで。
「モダンな仕事をバリバリしたいならベンチャー行け」という話もあるけれど、ベンチャーで通用するほどの人材ならそもそも大企業を選ぶことに悩みなどしないだろう。大企業を選ぶということは、実力なり待遇なり何かを求めているわけで、そうなってくると大企業以上に適切な選択肢は無い。でも、その大企業にも上記のデメリットがあるわけで。
世の中は甘くないですね。
自分自身の理想が高すぎる気がするし、その割に就職先がFなんて時点で間違ってる気がするし。
どっちにも落ち度があるかなあって感じが。
＞オープンプラットフォームにしてほしいとか、COBOLは嫌だとか
これなんてFなら普通に避けられないようなとこだと思うがな。そう思ってなかったなら知らなさすぎ。
まあ、気持ちはわかるが。
俺もH系でメガバンクのPL/1とかCOBOLとか書いてた時期有るけど、
日本語も怪しいような人たちを使って、面白みもないが必要なシステムを作り上げるSIerのほうが、
しょうもないアプリやらWEBサービスでガキから小銭巻き上げてる連中より尊いとは思うわ。
理由は簡単に言ってしまえば自分の目指すキャリアパスとのミスマッチ。
おそらく人事部の書類にも、今頃そんな感じのことが書かれているんだと思う。
なぜ好き好んでそんな会社に入社して、短期間で退職するはめになったのかを書こうと思う。
入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。
それもあって、同じ分野の研究を企業として行なっている同社に入社しようと考えた。
内定の前後にいくつかの職種のマッチングを行う機会はあり、自分の希望についてはしっかりと主張したつもりだったけれど、
入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。
当然この決定に対して人事に不服を申し立てたけれど、返ってくる答えはあらかじめ用意してあったような定型文と、「みんな我慢しているからお前も我慢しろ」というお説教だけ。
もちろん、規模の大きい会社だし、全員が希望通りの職種につけるとは思っていたわけではない。
でも、曲がりなりにも現代のIT企業に入社したつもりなのに、20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかったし、
綺羅びやかな会社説明の資料の中にそんな説明を見た覚えもなかった。
もちろん決定は全く覆らなかったのだけど、その後も思いつくだけの人脈を辿って色々な人に相談して助言を貰い、
せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、
できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。
それからしばらくの間新入社員研修をこなし（富士通に限らず、いわゆる日本的な大企業は研修期間がやたらに長い）、
そろそろ本格的に業務に携わりたいと思っていた矢先、上司に告げられた自分の担当業務はほかでもない、あの20万人月案件だった。
例によって守秘義務があるので詳しくは書けないのだけれど、業務を行うツールはもちろんMicrosoft Excel。
自分の仕事は言われたとおりにExcelシートに入力し、マクロを実行して成果物となるファイルを吐き出すことだった。
このマクロの挙動はとても怪しいものだったのだけれど、どうやら自分はこのマクロの修正はおろか、ソースを見ることもできない身分らしい。
SIの現場で日々行なわれている業務内容については詳しく知っているわけではなかったけれど、自分のやっていることが著しく非効率的であることだけははっきりとわかった。
そもそも、具体的な配属先については希望とズレがあったにせよ、少なくとも自分は開発職として入社したはずで、SI業務がやりたくてこの会社に来たわけではない。
とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。
確かに、Excelシートへの入力作業に情報学の修士号なんていらないし、キャッシュコヒーレンシの話なんてオタクの気持ち悪い自分語りみたいなものでしょうね。
結局これが引き金になって、転職を決意した。
しばらくの間働いてみてそれから考えるなんて、とんでもなく愚かなことだとようやく気付いた。
ただ、短い期間ではあるけども世話になった上司と、開発職の社員をSI業務に割り当てざるを得ない状況については自分も一定の理解を示しているつもりだったので、
多少なりとも会社への影響を軽減できればと思い、転職するつもりである旨を早い段階で上司に明かした。結果としてこれが大きな間違いだった。
転職の旨を伝えた週の金曜日、自席に上司から電話があり、「働く気がないならすぐに辞めてもらう」といった調子で一方的に退職日を設定された。
流石にこれは法的にも問題がある行為だと思い、すぐに折り返し電話をかけて抗議し、翌週時間をとって直接話すことになった。
翌週直接話してみると、上司はケロッとした顔で「なんだ、働く気がないわけじゃないんだ、勘違いしてた。じゃあ退職日はいつにする？」なんて聞いてきた。
自分が抗議しなかったらどうするつもりだったんだろう。
幸い、書類上は見栄えのいい学歴と、知人からの紹介と、"多少覚えのある"スキルのおかげで転職には全く困らなかった。
そろそろ就職活動が本格的に始まる頃だけど、今の就活生には是非とも就職先は慎重に選んで、貴重な若い時間を無駄にすることがないようにしてもらいたい。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
