IT (情報技術) 学習記録

主に情報処理技術者試験等の、IT・ICT系、または電気系の学習記録を中心に。放送大学、働き方、世の中も。

「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない


「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない


勉強をするうえで、インプットすることよりも、アウトプットすることを大切にした方が良いと、よく言われる。

それは、アウトプットすることで、自分の中にある断片化された知識が明確になり、あいまいであったり、穴があったりする部分が「見える化」されるからである。

そして、そのあいまいな部分や穴の部分を、埋めようとする。そして知識を体系立てて整理する。

つまり、アウトプットすることで知識がより「強化」される。

インプットだけだと、これができないからである。


人に「1」を教えるためには「10」の知識が必要


これは感覚論になってしまうのだが、人に何かを「教える」「説明する」ためには、対象にたいする知識量が、「教える」量の何倍も必要であると思う。

私の感覚では、10倍くらいは必要だと思う。

  • 人に「1」を教えるためには「10」の知識が必要

  • 即ち、「10」を教えるためには「100」の知識が必要

そして、

  • 「10」を教えて、実際に「伝わる」のは、せいぜい「5」も行けば良い方

である。


ズブの素人に何かを教える場合と、かなり知識を持っている人に何かを教える場合とでは、伝わる効率が全く違う。

これは、同じ内容を、新入社員に対して伝える場合と、経験年数がある社員に伝える場合とを比較するとわかるはずである。

それでも、どんなに効率的に伝えることができたとしても、100パーセントを伝えることはできない。


生徒でいるうちは先生を超えることはできない


生徒でいるうちは先生を超えることはできない

上述したように、「教える側」は教えるたびに知識を強化していく。

「教わる側」は、100パーセントを理解することはできない。

だから、先生役をやる機会があったら、面倒がらずにやるべきである。


この真実は、案外、知らない人が多い気がする。


情報工学を勉強するということとは


情報工学を勉強するということとは


このブログでも記しているように、近年の私は敢えて自分の専門領域以外の『電気工学』『無線工学』などを勉強している。そして、それらの基礎となっている『電磁気学』周辺の『物理学』も必然的に勉強することとなり、さらにそれらを知るための基礎となる『数学』も必然的に勉強している。

電磁気学』を学ぶということは、19世紀頃からの古典物理学の歴史を学ぶということと、結果としては同じである。何故ならば、学問を理解するということは過去の発見や理論の積み重ねの歴史を理解することだからである。


『プログラミング教育の義務化』というものが2年後くらいからはじまりそうな情勢である。

私はどうしても、「コンピュータの動作原理」などの基礎を飛ばして、「プログラミング」というものだけを教育する考えには、違和感を覚える。こういうことを言うと老害認定されそうであるが…。

よくネットなどで見かける意見として、

Java言語は最初に学ぶ言語に良いとは思うが、統合開発環境の使い方などを勉強しなければならないハードルがある」

「まずはプログラミングの楽しさを早く体感できる言語が良い」

…などというものがある。

率直な私の意見としては、

「裏側のコンピュータやネットワークやファイルシステムなどのしくみを理解しないままプログラミングだけを学習させたなら、何かトラブルが起こったときに根源的な解決が独力ではできないという、使えない人が大量に生み出されると思うので、同時並行的に裏側のしくみについても学習させるべきだ」

…と思っている。

そもそも、裏側のしくみの理解がないと、プログラムが動作するイメージを頭の中で組み立てることが困難ではないかと個人的には思えてならない。

そして、そう考えて、「それを教えられる人が絶望的に少ない現状がある」ために、無理だとも思うが…。


裏側のしくみを理解することの大切さと、コンピュータやシステムの歴史を理解することの重要性


IT業界は本当に車輪の再発明(reinventing the wheel)が横行してきた世界である。

オブジェクト指向』や『リファクタリング』も、その原理や発想はものすごく昔に生まれていた。それを改めて「そういう固有名詞で」表現したり体系的にしたりしたのが、それよりもだいぶ後年になってからだというだけである。

そして、そうしたプログラムやシステムを開発する上での工夫は、かなり昔から実施されてきた。別にOOPに対応していない古典的な言語であっても(それこそCOBOLとか昔のC言語などであっても)、開発者の工夫で似たようなことはやってきた面もある。


「バージョン管理にSVN(Subversion)を使っている職場などイケていないから辞めたい」

などという意見を目にすると、残念な気分になる。的外れもいいところだ。

重要なのはそんな部分ではないだろう、と…。


最新の統合開発環境ではなく、テキストエディターでコーディングをしている職場だとしても、ただそれだけの理由でそうした職場を悪く言うのは早計であるし、自らの成長や学習の機会を逸することになるだろう。

もしも敢えて同じようなレベルで近年の若手のツールの使い方に対して、私が言うならば、FTPGUIツールをエクスプローラーのように使うなよ」とか言いたくもなる。こんなことを言うと老害認定されそうだが…。

どんな環境や、どんなツールにも、生まれた理由があり、使われる理由がある。それぞれの特徴がある。良い面と悪い面がある。

いちばん問題なのは、そうした「しくみの理解」をしないまま、ただブラックボックスとして利用しているという姿勢である。


近年、非コンパイラ言語のみを新人研修で習ってきた若手が、コンパイルやリンケージのしくみをよくわかっておらず、それに起因するバージョン管理トラブルがあった。

これは本当に裏側のしくみの理解の問題であり、バージョン管理ツールに何を使っているかは問題ではない。

プログラムやシステムを開発するという点において、例えばこうしたバージョン管理などの構成管理の知識は、その言語によるプログラミングの知識以上に重要となる場合がある。

バージョン管理やプログラム生成環境の理解は、結局のところ、「プログラムがどこで動くのか」「プログラムがどうやって動くのか」という「しくみの理解」に行き当たる。


日本のIT業界には、「情報工学を何も学んでこなかった素人」の人であっても新卒一括採用で入ってくる。それ自体は仕方のないことだし、悪く言うつもりはない。

ただ、教える方も、教わる方も、「古い」「新しい」とか、「トレンド」「非トレンド」とか、そういったことにとらわれず、好き嫌いなく、貪欲に、公正に、教えてほしいし、学習して欲しいと思う。


オトナはみんなうそつきだから自分自身で実際に見たものを信じて自信をつけて行こう


オトナはみんなうそつきだから自分自身で実際に見たものを信じて自信をつけて行こう


(関連過去記事)

kf7757.hatenablog.com


車輪の再発明』という言葉を知っているだろうか。

IT業界においては、本当にこの『車輪の再発明』がくりかえされている。

主に食物とされているのが、IT系の知識や経験を本当は全く持っていないズブの素人なのに、年功序列で決裁権が回ってきた大企業の経営者たち、そして、世間知らずの若者たちである。

それでうまい汁を吸って生きているのが、世の中にゴマンと居る自称コンサルタントの皆さん。

いや、コンサルの中でも若手の人は、どちらかと言うと食い物にされた若者に入るかもしれない。

私も以前、自分がまだ子供の頃にあたる時代について記事を書いたことがあった。

その時に強く思った。

「人間は自分が社会に出る前や、生まれる前の、昔のことは本当に何も知らないものなんだ」

と。


ITエンジニア(技術者)が新しいものに飛びつきたくなる本当の理由


これは、考え詰めれば非常に利己的な理由である。

  • 自分が主役(先駆者)になりたいから

特にIT分野は、未だ成長しきっておらず、発展の余地が大いにある分野である。

そのため、とにかく新しいことを先にやった人が注目されやすい。

また、競争相手が少ない方が、儲かる。


ここで注意したいことは、新しいことを先にやり、競争相手が少ない方が良いのだが、まったく参入者が居ないのもマズイということになる。

だから、何も知らない大企業の経営者のおじいさんたちや、同じく何も知らない若手に対して、参入を促すのである。

特に若手は、「自分が主役となって活躍したい」と漠然と思っているから、余計に新しいものの良い面だけを見て信じる。

こうした人たちが、単に古いものを悪だと決めつけるのは、本当は、単なるマウンティングでしかない。


IT産業もある程度成熟すれば先駆者利益も減るだろう


私は思うところがあって、電気工学や無線工学などを勉強している。

電気や無線の世界は、少なくともITの世界よりは成熟していて、単に『車輪の再発明』をやるだけで注目されたり儲かったりはしない。

替わりに、純粋に電磁気学などの「しくみ」を理解している者が少ないので、そうしたホンモノの知識を持っている人が重宝されているようである。


COBOLプログラマの不足が心配されているという情勢は、ある意味で、ようやくIT産業が成熟に近づいてきた傾向を示しているのかもしれない。

ITエンジニアは一生勉強していかないといけない。これは確かである。

どんな環境もどんな領域も、どんな言語も。

必要とあらば、どんどん経験して自分のスキルにして行くのが正しい。

私自身も、新入社員だった頃は、当時は「COBOLなんてすぐになくなる」という風説を信じ込み、けっこう辞めたい気分だった。

いまは、大型汎用機(メインフレーム)のOSや環境を、いろいろと使うことができて、本当に良い経験になったと思っている。

大型汎用機(メインフレーム)の環境を、好きにできる職場って、そうそう存在しないと思う。



kf7757.hatenablog.com


Windows環境における大量ファイル(フォルダ構成)のコピーをする際の留意点


Windows環境における大量ファイル(フォルダ構成)のコピーをする際の留意点


下記の過去記事にも記したが、Windowsに限らず、UNIX/Linux系OSを含めて、現在の主流ファイルシステムにおいては、ファイルをカタログすることをユーザーに意識させない。つまり、コピーなどの処理と同時に、「存在しなければカタログ化してから書き込む」ということを自動的に行う。


kf7757.hatenablog.com


これは、考えればきわめて当然なのだが、下記のことが言える。

  • ファイル(フォルダ)が存在しない状態に対して大量コピーを行うと処理時間がものすごく長くなる(処理コストが高くなる)

  • 一度ファイル(フォルダ)が作成された状態に対して内容だけを更新しようとすると処理時間はそんなにかからない(処理コストが高くない)

特にWindows系OS環境では、ファイルやフォルダの新規作成(カタログ化)がものすごく重い印象である。

下手すると秒間2~3ファイル程度の速度かもしれない。

これでは、数万ファイル以上のコピーにはものすごく時間がかかる。


数万ファイル以上のファイル(フォルダ)のコピーを行う予定がある場合は、事前に余裕を見て本番前までに一度、コピー処理を実施しておくのが賢明である。(つまりファイルやフォルダのカタログ化を事前に済ませておく)

また、数万ファイル以上という大量コピーは、ファイルエクスプローラーによるコピーではなく、

robocopyマイクロソフト製の堅牢なコピー)コマンドなどを使用する。


基本的なしくみを理解することの重要性


いま、私は非IT系分野として電気工学や無線工学の勉強をしている。

この手の勉強は何の勉強かと言うと「しくみの理解」ということに尽きる。

学生時代に文系だったか理系だったかといってことはたいした問題ではない。

どんな場面においても「しくみの理解」をしようとする姿勢があるかどうかである。


COBOLプログラムは工業製品としてはとても優れている


COBOLプログラムは工業製品としてはとても優れている


こういうタイトルを書くと一部の界隈の住民からバカにされそうである。

しかし、少なくとも、「実務でCOBOLで構築されたシステムの保守や大規模開発を経験したことがない」のにも関わらず、「新人にCOBOLの案件をやらせるのはいけないことだ」と言い切ったりしている人の言うことは、あまり信用していない。

COBOLは本当に不思議で不遇な言語で、企業システムにおいて大量に使い続けられてきて、いまでも使われている言語であるのに、私が知る限りでも「30年も以前から"COBOLは使われなくなるから学習する意味はない"と言われ続けてきた」言語である。

私がコンピュータ関連を専門に学んだ学生時代(1990年代前半くらい)の、25年前においても、学校の先生が真面目な顔で「COBOLを学習しても得るものはない。これからはC言語を学習しろ」と言っていた。(そして、それを信じて、C言語を学習するコースを専攻した訳であるが)

繰り返そう。少なくとも25年前からだ。たぶん30年前にもだ。

私の実体験だけで言っても、25年前から、現代と同じような事が言われていた


だが現実はどうだろうか。COBOLは消えただろうか


25年間、同じ事が言われ続けているという事実は、25年間、そう言われながらも使われ続けているという事である。

現に…。

私はこの平成29年度(2017年度)において、自分の仕事で、COBOLソースコードを数万行新たに生み出した


C言語(系)との比較で言うなら、COBOLソースの方が圧倒的に追いやすい


大規模システムの保守の経験をしたことがあるなら、「如何に他人が過去に作った設計書やプログラムソースコードを追うことが困難か」を痛感する。

  • どのような処理の流れになっているかが追いにくい

  • 処理がわかっても「意図」がわからない

仕様を知っている(べき)顧客は、実際には仕様などまるで知らず、平気で「この画面はどんな意味の画面か」「この帳票の項目に出ている数字の意味は何か」などと問い合わせしてくる。しかも「至急」などと言って。

新たにシステムを開発する場合にも、現行システムとのデータ連携は必ず発生する。現行システムを増築するケースも多い。

そして現行システムを組んだ人員は、たいてい離散してしまっている。

とても少数の人員で、限られた時間の中で、過去に見ず知らずの人が作った設計書やソースコードを読み解かないといけない。

「ソースを追えないのは、スキルが足りないだけ」

何とでも言うが良い。別に良いよ。スキルがないと思ってくれても。

そのシステムの仕様を追いかけるのは、基本的にものすごく困難な作業なのである。

前提知識として、ユーザー側の業務知識も必要だし、現行システムに対する広範囲な知識も必要となる。

そういう知識があったとしても、なお困難である。


  • C言語は、記述が自由で、人によるクセが出やすい。かなり不自由なルールを事前に作って運用しないと、無法地帯的なソースコードが量産される

  • COBOLは、もともと記述の自由度が低く、ルール化しやすい。そのため、人によるクセが比較的、出にくい。(あくまでも比較的だが)


私の職場で扱う言語はたくさんあり、大別すると、「C言語か、もしくは、C言語に近い言語」と、「COBOL」に分類できる。(近年はかなりJavaも増加してきた)

保守がやりやすいのは、圧倒的にCOBOLであると言える。

これは、「COBOLが非常に不自由な言語」であるという理由がある。

不自由で、かつ、できることが限られている言語である。

(ただし、10進数(特に小数点以下を多用する)の演算に限っては、実は非常に得意である)

「人によって差が出にくい」

この特性が、どれだけ業務システムの開発/保守現場で重要なことか。

こんな特性は「ちっともクリエイティブじゃない」と思うかもしれない。「技術を追究する姿勢とは程遠い」とも思うかもしれない。

そういうことは、クリエイティブな方面や、技術的な方面の、プログラミングでやれば良い。そういう方面の世界の話をしている訳じゃない。

COBOLでゲームは作れない。そんなことは当たり前である。そんな事を問題視している時点で話の土台がズレている)

(ちなみに、Visual BasicCOBOL を同じような言語だとする意見があるようだが、全く違うと思う。VBは保守性から見ても、悪いが最悪と言って良い)


たぶん20年後も同じことが言われているだろう


「新人にCOBOLの案件をやらせるのはいけないことだ」

たぶん、20年後も同じことが言われているんじゃなかろうか。

何せ、これまで20年以上も同じことが言われ続けて来たのだから。

世の中の社会インフラや、金融業界などの業務基盤を支えている、裏側のシステムにおいて、COBOLは根強く使われ続けている。

仕事をやるもやらないも自由だが、自分が縁あってアサインされた仕事で、たまたまCOBOLを扱う案件であるという理由だけで、経験もせずに辞めるというのも、もったいないとは思う。


年度末ということで、こんな事を敢えて書いてみた。


kf7757.hatenablog.com


kf7757.hatenablog.com


多額の借金までして大学に進むくらいなら、進学せずにとりあえず就職してしまうという選択もありだと思うんだが…


多額の借金までして大学に進むくらいなら、進学せずにとりあえず就職してしまうという選択もありだと思うんだが…


今日のネットニュースで、下記のような記事を拝読した。


自己破産者も急増「私はこうして奨学金を返せなくなった」

就職すれば大丈夫と思っていたのに

gendai.ismedia.jp


奨学金制度という言葉だと実感がわかない人もいるみたいだが、これは借金そのものなのだ。

借金は、可能な限りしない方が良い。

これは社会人になると本当にそう思う。


すべては情報が足りないのが問題


21世紀に入って、大学進学率が急激に上昇し、現代では高校卒業者の半数くらいが、大学に進学する時代となった。

大学に進学する理由の多くは、本来の「学問をもっと追究したい」という理念からは程遠い、「今どき大学くらい出ていないと良い就職先にありつけない」という理由のようだ。

本当にそうだろうか。


あくまでもネット界隈での書き込みを見ての感触なので、どこまで本当かはわからないが、下記のような状況が見える。

  • (1) とにかくやみくもに「大手有名大企業」に入ることが成功だと思っている

  • (2) 上記(1)のためには、とにかく有名でいわゆる高偏差値の大学に行かないとダメだと思っている

  • (3) 仕事や職業についての具体的なイメージは何も持っていない。知らない

  • (4) 上記(1)とセットの考えとして、中小企業に入ると「ブラックな職場」や「現場仕事」になると思い込んでいる


一言で言うと、世間知らず。何も知らない。

そして自己分析もしていない。

人の性格や特質によって、大企業に向いている人、中小企業に向いている人など、様々であるのが本当なのだが…。

もちろん、中小企業がすべて「ブラック」であるということは真っ赤なウソであるし、大手有名大企業であっても「ブラック」は存在する。

「現場仕事」は企業の大小に関わらず重要である。また、そうした仕事のほうが性に合っている人も多い。


実際の例を挙げよう


例えば、私の実際の勤め先のことを少し書く。

業種/職種はシステム開発/保守を行う、システムエンジニア

これは本当のことだが、私の先輩社員の中に、同じ高校を同学年で卒業した二人がいる。

その二人は、それぞれ、大学卒業、専門学校卒業と、学歴は異なる。

年齢は同じだが、専門学校卒の方が、早く入社したので、そちらが先輩社員になる。(不思議なもので先輩後輩という事実は、ずっと変えられない事実になる)

両方ともに、現在、入社して30年近くになるベテランだが、専門学校卒の人の方が、職位としては上でやっている。

学歴や入社年次の問題ではなく、その専門卒の人の方が、技術的な知識を多く持っていたりする面が、評価されている。

無論、両方の人ともに、これだけ長く勤めているわけだから、実績の評価もあり、仕事ができないわけではない。


入社されたのが30年近くも前なので、現代の就職事情とは異なるかもしれない。

しかし、上記の状況は、ひとつの厳然たる事実である。

いまの学生の人の多くは、「学歴ですべてが決まってしまう」と思い込んでいるようだが、実際にはそんなことはない。


実際に働いてみないとわからないことが多い


学生の段階で、充分に自己分析を行うことは重要だが、それでも、実際に社会に出て働いてみないとわからないことも多い。

上述したように、「学歴だけ」で、すべての「優劣」が決まってしまうことはない。(そう思いたい、もしくは、そう思い込んでいる学生が多いようだが)

借金までして無理して大学に進学するくらいなら、もっと早めに社会に出てみるのも、選択肢としてはありだと思う。


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


日本的な完全スクラッチ開発によるシステムインテグレーション(SI)はたぶんなくならない


日本的な完全スクラッチ開発によるシステムインテグレーション(SI)はたぶんなくならない


従来型の「システムの方を業務に合わせる」というスクラッチ開発が否定されて、「業務の方をシステムに合わせる」というパッケージ化が声高に叫ばれて久しい中、それの成功例をほとんど聞かない。

オフショア開発も同様。

少なくとも自分の観測範囲では。


この問題は、日本的な雇用のあり方が、とても関係している。

IT業界云々の話ではない。もっと根が深い。

よく言われているように、欧米では、一人ひとり、契約で行う仕事内容が明確化されていて、企業においては特定のポストに対して求人が行われる。

そういった背景から、仕事は可視化されやすく、専門性と汎用性を両立できる。

だからこそ、パッケージ化も比較的容易で、業務システムも汎用化されたパッケージをそのまま利用しやすい。

一方で、これもよく言われるように、日本では、新卒一括採用の文化や、大分変化してきたと言われるが、「就社」という長期雇用前提の就職文化があり、一人ひとりの仕事内容は明確化されていない。

企業などの組織間での人材流動性が低いことや、上記の仕事内容が曖昧であり続ける文化も重なり、同じ呼び名の仕事であっても各企業や組織毎に内容がバラバラであり、属人性を排除できない。

良いか悪いかの問題ではなく、そもそもこうした状況で、日本的な完全スクラッチによるシステム開発がなくなることは考えにくい。


官僚化が進行するユーザー側とシステム開発者の仲立ちができる人材(人財)こそが重要視される


  • システムの事などわかっていないユーザー側もしくは全ての経営者たち

  • ユーザー業務の事など興味がない上流工程を鼻で笑っているエンジニア(注1)たち

この両者の意識の隔絶は、どんどん広がっている。


開発言語などに変なこだわりを持っているようなエンジニア(注2)には、おそらくいくら言ってもわからないのだろう。

(注1) システム化の企画や検討/基本設計をエンドユーザー側と実施することなのだが、それを主としてやっている者はエンジニアではないらしい。やったことあるんですかね?

(注2) COBOLはやりたくないとか、Javaはもう古いとか、組んだこともないのに否定したりしている人々がいる


kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com


三年間は頑張ってみろの本当の意味


三年間は頑張ってみろの本当の意味


どんな仕事も「とにかく三年間は頑張ってみろ」という言葉は昔からよく聞く。

最近は、この言葉を否定する人が増えている感じがある。

  • 現代社会は変化のスピードが速いため、三年も待っていたら時代遅れになってしまう」

  • 「若い人にとって三年間は大きすぎる。そんなに我慢する必要はない」

この考え方も間違ってはいないだろう。否定するつもりはない。

最終的には、その人その人、ケースバイケースで答えは様々だ。

ここでは、少しだけ「三年間は頑張ってみろ」の本当の意味を考えてみる。


仕事(キャリア)には三種類のものがある


仕事、もしくは、キャリアには、大きく捉えると、三種類のものがある。


  • 1.専門性が高い、知識やスキルの積上げに長期間を要し奥が深い仕事(異年代差大・同年代差少)

エンジニアや専門職、特定の業界に特化した専門知識が必要な仕事。

悪く言えば潰しが効かない仕事。

下積み期間がとても長い。


  • 2.汎用性が高い、知識やスキルの積上げは短期間で済み深くはない仕事(異年代差少・同年代差大)

人材系/管理系ビジネス、ヒューマンスキルが重要視される仕事。

悪く言えば底が浅い仕事。

若くても素質があれば一人前になれる。


  • 3.専門性も汎用性もほどほどで、知識やスキルの積上げは短期間で済み未経験者でも可能な仕事(異年代差少・同年代差少)

定型的な部分が多い仕事。一般事務や比較的単純な作業など。

悪く言えば誰でもできる仕事。

自分の生活や性格に合えば長く続けられる。


無論、仕事の分類の仕方は上記がすべてではないし、上記だけが正しいとも思わない。

それでも、こういう分類もできるという例である。

仕事は、同じ呼び方の仕事であっても、入った企業や配属された部署によって、異なる分類になってくる。

「三年間は頑張ってみろ」というのは、

  • 自分が選んだ仕事はどんな種類の仕事か

  • 世の中のどういう仕事がどういう種類の仕事か

  • 自分が本当に合っている仕事はどういう仕事か

を見極めるのに、かかる期間だと思う。

それを見極めるときに、例えば、上記の3分類で考えてみると、どうだろうか。

「1.」に該当する仕事なら、下積み期間が長い仕事なので、はじめの数年間は仕事としてはつまらないかもしれないが、それは必要な下積みであると思える。

「2.」に該当する仕事なら、若くして能力次第で一人前の仕事ができるが、更にキャリアアップをしたい場合は、職種チェンジも考慮しないといけなくなってくる。


下積みの重要性を誰も教えない悪循環


世の中の大人が、下積みの重要性をうまく若い世代に伝えていない現状があるように思える。

それで、下積み期間が長い仕事が敬遠されてしまう。

人工知能(AI)が発達して食い込んでくる領域の仕事は、上記で言えば「3.」「2.」の順だろう。

日本全体で守っていかないといけない領域は、失われつつある職人の領域や、町工場などの現場の領域なのではないだろうか。

そういった領域こそ、「とにかく三年間は頑張ってみろ」の世界なんだがなぁ。


就活生へ。「情報の海に溺れるな」「とにかく調べろ」「思考停止するな」「他人と比較するな」「置かれた場所で咲くことも大切」


就活生へ。「情報の海に溺れるな」「とにかく調べろ」「思考停止するな」「他人と比較するな」「置かれた場所で咲くことも大切」


就活生へ。(就職活動をしている新卒予定の学生へ)

(高校、専門学校、短大、高専、大学その他すべて)

  • 情報の海に溺れるな

  • とにかく調べろ

  • 思考停止するな

  • 他人と比較するな

  • 置かれた場所で咲くことも大切(最後は縁も大切)


最近、興味深いブログ記事を拝読した。


takoyakitabetai.hatenablog.com


全面的に内容に賛同する気持ちはないのだが、少なくとも、

「2. 大手はやめろ」

「3. 調べろ!!!!!!!(圧)」

…などは、頷ける部分が多い。

本当、この逆を行っている学生さんの多いこと、多いこと。


情報の海に溺れるな


近年、「学歴フィルター」という言葉がすっかり定着した感がある。

私は、「学歴フィルター」は、学生層自身が作り出していると考えている。

本当に、一部の国家公務員キャリアの世界などを除いて、世の中の大部分では、学歴なんて誰も気にしていない。

そもそも、長年いっしょに働いている同僚であっても、その人の学歴なんて知らない場合がほとんどだし、仮に知ったとしても、それで態度が変わることなんてない。

学歴の価値なんて、世代や時代で変動するものであるし、過去の歴史よりも、いま現在その人がどんな知識と能力があって、どんな人間性か、ということの方がはるかに重要なのである。

何故、一部の大企業が「学歴フィルター」などを使っているのか。

それは、インターネットが普及したために、気軽に入社希望(エントリー)が行える環境が整ってしまったせいで、誰もかれもが有名大企業に「とりあえずエントリー」することが増加し、一企業に対して、何万ものエントリーが来ることが当たり前になってしまったためであろう。

一方で、学歴不問で人材を登用している優良企業も、本当はかなりある。

そういう優良企業は、一般人には知名度が低いというだけで、実は本当に良い企業だったりする。

優良企業で学歴不問、人物重視という企業はたくさんある。


とにかく調べろ


上記のような優良企業の情報は、待っているだけでは入ってこない。

無論、ネットの情報なんてウソばかりである。

自分の手足を使って調べるしかない。

世の中の、業界の、本当の仕組みを調べるのである。


思考停止するな


一般人でも知っているような超有名企業にエントリーが集中するという現象は、就職活動をしている学生自身が「思考停止」しているとしか思えない。

有名大企業に入ることが「勝ち組」とか騒いでいるのは学生だけである。

生涯年収が云々とか言っているのも然り。

主語がでかいのも然り。

自分が具体的にどんな仕事をしてどんな生活を送りたいのか、考えていない。イメージしていない。

大企業で官僚的な仕事をすることが「勝ち組」で、その委託企業などで実務的な仕事をすることが「負け組」などと、本当にそんなに単純なモノサシが正解なのだろうか。

単なる同世代に対する「見栄」だけじゃないのか。

同世代の意見など参考にする意味はない。

みんな自分と同じで世間知らずなのだから。


他人と比較するな


上述の「思考停止するな」とも関係するが、しょせんは社会経験がない者同士で、「勝ち組」「負け組」とか言い合っているだけでは、自分は幸せにはなれないだろう。

人は人。自分は自分。

自分にとってどういう道に進むのが良いのか。

問題はそれだけであり、他人と比較することは意味がない。


置かれた場所で咲くことも大切(最後は縁も大切)


これは受験などにも言えることであるが、第一志望には入ることができないこともあるだろう。

しかし、そこで腐ったりせずに、入ったところで頑張ってみることも大切である。

特に仕事なんてものは、「やってみなければ自分に合っているかどうかわからない」のだから。

第一志望とは違うところに入ったとしても、入ったら案外、自分としっくり合うかもしれない。

縁というものもある。


kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com


インピーダンス・抵抗(レジスタンス)・リアクタンス・アドミタンス・コンダクタンス・サセプタンス


インピーダンス・抵抗(レジスタンス)・リアクタンス・アドミタンス・コンダクタンス・サセプタンス


電気回路、電子回路の勉強をすると、まず、聞きなれない用語の壁にぶち当たる。

私は長年IT業界でシステムエンジニアをしているが、IT初心者もやはり初めは用語の壁にぶち当たるのだろう。

そんなことを思う次第。


数式は用いないで、電気回路・電子回路の似たような用語の意味を書いてみる。


電気の流れにくさに関係する用語(単位:オームΩ)


厳密に言うと、電気の流れにくさは抵抗(レジスタンス)だけだと思うが、単位がオームのモノを3種類まとめる。


インピーダンス(記号:Z)


回路のレジスタンス、リアクタンスを総じていう場合、インピーダンスという。

直流回路では、基本的にリアクタンスは登場しないため、主に交流回路の話に出てくる。

交流回路ということは、周波数を持つということ。

波の性質があるということを意味する。


レジスタンス(記号:R)(抵抗)


直流回路で最初に習う素子である。直流回路を豆電球と電池で作る場合、豆電球が抵抗にあたる。

「電気の流れにくさ」を示し、仕事をしてジュール熱を発生させる。

E=I・R または V=I・R の式は、オームの法則として知られている。

(ここだけ数式を用いてしまった)

レジスタンスは、交流回路においては、電圧と同位相となり、「有効電力」つまり「消費電力」に関係する。

レジスタンスは、インピーダンスの実部に該当する。


リアクタンス(記号:X)(Xc,XL)


語源はリアクション。コイル、または、コンデンサが持っている「抵抗のようなもの」を示す。

直流回路では、通常は出てこない。何故なら、コイルは単なる導線(短絡)であり、コンデンサは単なる非導線(開放)でしかないからである。

交流回路においては、電圧の変化に伴って、リアクタンスを持つ。

リアクタンスは、交流回路においては、電圧と90度異なる位相となり、「無効電力」に関係する。

リアクタンスは、インピーダンスの虚部に該当する。


コイル(誘導性リアクタンス)(記号XL)(係数の単位:ヘンリー)

電圧に対して90度遅れの位相となる。インダクタともいう。

周波数に「比例」して大きくなる。


コンデンサ(容量性リアクタンス)(記号Xc)(係数の単位:ファラッド)

電圧に対して90度進みの位相となる。キャパシタともいう。

周波数に「反比例」して大きくなる。


ここまでは、電気回路・電子回路の入門書によく出てくる。


以下は上記とは反対の意味を示すものである。


電気の流れやすさに関係する用語(単位:ジーメンスS)


単位がジーメンスのモノを3種類まとめる。


アドミタンス・アドミッタンス(記号:Y)


インピーダンスの「逆数」である。

つまり、インピーダンスが「電気の流れにくさ」の総体を示すものであるのに対して、「電気の流れやすさ」の総体を示す。

回路のコンダクタンス、サセプタンスを総じていう場合、アドミタンスという。


コンダクタンス(記号:G)


レジスタンス(抵抗)Rの逆数である。

「電気の流れやすさ」を示す。

コンダクタンスは、アドミタンスの実部に該当する。


サセプタンス(記号:B)(Bc,BL)


リアクタンスの逆数。

コイル、または、コンデンサが持っている「抵抗のようなもの」の逆数。

サセプタンスは、アドミタンスの虚部に該当する。


コイル(誘導性サセプタンス)(記号BL)

誘導性リアクタンスの逆数。


コンデンサ(容量性サセプタンス)(記号Bc)

容量性リアクタンスの逆数。


工業高校ではこういうものを普通に習っている


そう考えるとすごいよね。