  |
はてなキーワード: COBOLとは
前回: https://anond.hatelabo.jp/20211223003204
スーパーエンジニア様も期待通りにはいかず、細部の仕様も決めきれない、開発者も不慣れなフレームワークで四苦八苦
ということで進捗は芳しくなかった
(仕様に関してはそもそもコンセプトから決まってないからしょうがないが)
VCに何か言われたらしくCTOが段々イライラしてきたのが伝わってきた
その中にKさんと言う人がいた
CTOは「単金が安かったから、簡単な仕事をお願いするつもりで呼んだ」と言っていた
正直この人は厳しいだろうな
そう思っていた
心配してくれた人達、同じ境遇の人達、リアクションありがとう。
いつもニコニコ愛想よく、仕事も全力で取り組むのが気持ちいいに決まってるし、充実するのはわかっているけど
最近は、いじわるババアみたいに不機嫌そうにダラダラ過ごすのが一番楽という結論に落ち着いた。
なんなら30分で終わる仕事に1日かけて、報告は更に翌日に持ち越す。
調べればわかりそう、技術的にはできそうと思っても「難しそうですね、頑張ってください。知らんけど」で会話終了を心掛けている。
なんかね。
パソコン難しいからわからん→自分がわからない事は簡単なはず→簡単な仕事しかできないから非正規、なのか
ゆみちゃん？あいなちゃん？あー！しのぶちゃんだったか！がっはっは！いやもう、ちゃんって年でもないか？失礼失礼！(笑)と、毎回必ず言って来たり
マイクロソフトへの苦情
買ってきたデバイスやPCの初期設定全部やれ、パソコンの事なんだからそっちの仕事でしょ
気が付いた人がやるルールのコピー機の紙の補充やインクの交換は、気が付いた人が私に言うか、気が付かないフリで待つだけ。
新しく導入したソフトの使い方誰もわからんから簡単な手順書を作れ
電話に出るのは女の仕事、面倒な問合せやクレーム・サポートの対応は電話に出た人間の仕事
テレワーク用ソフトのセキュリティが「絶対大丈夫だよな？な？」と何度も確認してきたり
DXでクソ高いソフト導入したから後は簡単でしょ？よろしく頼むわとか（これは全力で逃げた）
うちは50↑のバブル世代以上が全員こうなので、若い世代も弱者に丸投げ文化が育ちつつある。
人生も終盤を意識する年齢になり、今の働き方を考えてなおしてみた。
そしたら思ったのよ。
今更正社員になれたとしても、家も車も家庭も老後資金も手遅れなので吹っ切れた。
いつも不機嫌そうで遠巻きにされていたお局様は正解だった！
私も面倒なお局様になる！
腫れ物に触るように扱われる！
本当は半裸で踊りながら料理して腹に火傷するような間抜けなのに
職場で身を守るために、世界が敵みたいなしかめっ面で過ごさなければならない。
属人化しないように気を使ってきたけど
もういろいろ作っちゃうし、使える仕様書もマニュアルも残さない。
【以下追記】
私は時給で働いているので。
金・時間・メンタルの全てを満たす職場を探すのは自分の条件では厳しすぎるので、私は時間を選んだ。
なので管理職含めた誰もが貧乏くじを引かないように、ルーチンワークだけを抱えて忙しい顔をしたがる。
誰も部下の仕事や全容を把握しておらず、トラブルも各自の責任で各自が対応する。
課長に頼まれた仕事の進捗を報告にいくと、そっちで勝手に終わらせたらいいのになんで報告にくるの？という顔をされる。
他企業を知ってるからその感覚で頑張ってたら、便利な使い走りとして浮いてしまったのだと思う。
現在最高位のお局様は二人いるので、牛頭と馬頭のような貫禄がある。
敵に回したくない…という共通認識があるから、部長レベルの人が
「彼女に頼むの怖いからな〜（苦笑）」で仕事を逃げる茶番が成立するんだよね。
事務職の女性達とはうまくやって、彼女らの後継者を目指したい。
仕事以外に自分が所属できる小さい趣味の世界を、できるだけたくさん増やそうと思う。
待遇が上がらないならちょっとずつ仕事の質を下げて、その分他に使いたいね。
Microsoftへの苦情について。
Windows Updateへの苦情がすごく多い。
そろそろサポート切れるから次のバージョンのテストしてねって言うとものすごく嫌がられる。
古いOS使ってても増田さんがサポートしてくれたらいいじゃんとか。
個人でサポート無理だし、リスクを説明してもその時は聞いてくれるけど
私の話は「なんかまたギャーギャー騒いでる」受け止め方しかされないので流される。
それと弊社は、仕事としての開発は未経験かつ大学でPython得意でしたみたいな人たちが
様々な言語で独自に作ったツールがたくさん転がっていて、仕様書もコメントもなければ製作者もわからない。
自分の仕事の範囲で使うならいいけど、それを基幹システムに組み込んでしまっている。
なのでOfficeやOS更新とかで動かなくなるとクレームがくるのです。
20年前に作られたVBAとか、かろうじて見つけた仕様書が30年以上前のCOBOLだったり。
それと彼らはDOSやTeraTermの黒い画面こそが一番偉く、その中でも難解なコードは一番偉いと思っているので
画面系は作った事がないしバカにしてるし簡単にできると思っている。
ユーザ－や事務職員用にどうしても画面が必要になったら制作依頼されるが
結局それを使ってデータ入力するのは私の仕事になったり、使われなかったりもする。
これ割とダメージある。悲しい。
いまもjQueryをWebアプリケーションの大事なライブラリとして使っている会社は少なくないと思う。
jQueryを会社で使っていると何が問題なのかを語っていこう。独断と偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。
採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。
また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人が可哀想なだけで、現役なわけではない。ラガード（遅滞者）の仲間入りをさせているだけだ。新人でもキャリアをデザインできる新人は「jQueryはオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。
そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードをメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。（jQueryでアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQueryに依存しておらず、jQueryに依存していないのであれば簡単にjQueryから脱却できるはずで、簡単にjQueryから脱却できるならもう脱却しているはずだからだ）
メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます！」とにこやかに言うようなものだ。
（ただし、さすがにjQueryだけでフロントをやっているという会社の求人をほとんど見かけることはない。無意識のスクリーニングで落としているのかもしれない）
jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているか、たまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。
「jQueryを使っていました」というエンジニアは、他社からはフロントエンドスキルが0とみなされる。つまり、フロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ（逆はできる）
jQueryを書ける人口自体は増えているだろうが、労働市場からは撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。
私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。
jQueryで入社するのは、昔からjQueryを使っている高齢のエンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。
そのため、需要と供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。
リプレイスはハッキリ言って難しい。モダンなフロントエンドを学習するだけでは足りなくて、それを使いこなせた上でしかもjQueryを使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。
時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。
jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。
何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。
jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合、既存の従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。（もちろん、「jQueryしかなかったサービスをモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある）
ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ？」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体は価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態でリプレイスしようとするのは、生活困窮世帯にリボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。
jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。
jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代で通用しにくいものになっていく。
bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンなインフラエンジニア（もしくはモダンなインフラ知識のあるエンジニア）がいないかもしれない。SREという概念がないかもしれない。
世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。
すべては憶測なので、実際は違うかもしれない。
さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体はメンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。
問題は、jQueryというライブラリを使ってきた時代からアーキテクチャが前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryのバージョンに反比例する。
jQueryを使っているアプリケーションには、jQueryが担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベント、SPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLにベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数、無視される変数のスコープ、サポートが終わったライブラリ、ドキュメントを見つけるのすら困難なよくわからないライブラリ、高齢者しか知らない伝説の機能・伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。
そのため、一定の基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。
そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。
そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。
（そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ）
jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか？」という部分が気になるところだと思う。
そこで、後編では「どうやってjQueryを全廃すればいいのか？」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。
お楽しみに！
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。