IT (情報技術) 学習記録-もしくは中高年(就職氷河期世代)の生き方-

IT系,または,電気通信系資格の学習記録を中心に。もしくは中高年(就職氷河期世代)の生き方,働き方,世の中。中高年の転職の現実。

まさかの電験三種科目合格…来年度に向けて始動!


まさかの電験三種科目合格…来年度に向けて始動!


昨年より、通信関連(有線/無線)の国家資格に挑戦しはじめ、今年は電気系の国家資格にも挑戦している。

これまでに取得した国家資格には以下のようなものがある。


現在、第一種電気工事士には挑戦中である。

そして、実は、準備不足も甚だしいものだったが、「電験三種」(第三種電気主任技術者試験)も、受けるだけは受けた。

電験3種に合格するためには1000時間もの学習が必要だという声もあり、とても合格するとは思えなかった。

現に、受験してみて、付け焼き刃ではとてもかなわないと実感した。

受験した感触では4科目全滅だと思っていた。…なので、自己採点もしなかった。

(法規だけは直前に集中的に勉強したが、本当に付け焼き刃ではかなわないことを実感した)


先日、試験センターから試験結果通知が届いた。

そうしたら…。

「理論」のみ科目合格。

まさかの科目合格である。

しかも、最も計算問題が多い「理論」


これは、合格できるかもしれないチャンスと捉えるべきだろう。

来年度は本気で狙わなければ……!


昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかも…


電験の「理論」科目は、多くの受験生の前に立ちはだかる壁である。

電験3種は、選択形式とはいえ、「5択問題」である。

4択問題と5択問題との難易度の差は、受験してみればわかる。

昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかもしれない。


kf7757.hatenablog.com


kf7757.hatenablog.com


ITはITだけでは存立できない


ITはITだけでは存立できない


ITはITだけでは存立できない。ITとはソフトウェアであり、制御系ならばハードウェアが、業務系ならば対象となる業務、それらがあってはじめて存在し得る。

「私はITの専門家です」「私はITエンジニアです」と言いながら、ハードウェアのことや(ハードウェア系に対しては同じ技術系として知らないことは恥じる傾向はあるが……)、ましてや「ユーザー側の業務」には何の関心も持たない者が居る。


プログラミングに固執する者たち


そういう者は、ITをきわめて狭い枠でしか捉えていない。そういう者は、プログラミングだけが真のITであると思い、プログラミングをしない役割の者を否定する。そしてプログラミング力こそが最強であると思い込む。

現実世界には、扱うシステムの規模が大き過ぎて、プロジェクトマネージャー、アナリスト、アーキテクト、DB管理者、プロジェクトリーダー、テストエンジニア、バージョン管理者など、様々な役割分担をしなければ絶対に完成しないシステム開発プロジェクトもある。しかし、そういったプロジェクトに参加した経験もない者や、参加したといっても最下層からしか見たことが無い者ほど、プログラミングだけが真のITであると信じている。(多重請負構造の中の最下層の立場でしか参加したことが無いなら大規模プロジェクトの全貌は絶対に見ることはできない。多重請負構造を積極的に肯定する気はないが……)


体系的な情報工学コンピュータサイエンスの学習を軽視する傾向


日本はユーザー側のITリテラシーが低い。より正確に言うならば日本人は一般的にITリテラシーが低い傾向が強い。リテラシーとは基礎力であり応用力でもある。これだけパーソナルコンピューター(PC)や、スマートフォンなどの情報機器が浸透している時代にありながら、それらの「しくみ」「何ができて何ができないのか」を知悉する者は少数派だ。「しくみ」を理解していない者が多い(理解している者が少ない)という事実は「ITエンジニア」を自称する人々にも言える事実である。

なぜならば、日本では欧米などとは異なり、基礎から情報工学コンピュータサイエンスを専門に学んだという学歴がなくても(いわゆる文系でも)ITエンジニア職には就くことができる。独学や我流でプログラミングなどを学び、経験した者でもそうした職種に就ける。無論、それは悪いことばかりではない。しかし、我流で学んだ自負が強い者ほど、体系的な情報工学コンピュータサイエンスの学習を軽視する傾向がある。

体系的な学習は軽視するが、プログラミング言語や開発環境、新技術の習得には逆にものすごく意欲を見せる。とにかく「自分の市場価値を高めたい」「時代に取り残されないように新技術を追い求めたい」という意欲だけは高い。

しかし、これはあまり知られていない事実だとは思うが、業界で有名なインフラエンジニアの多くは、若い頃に地道にしっかりと情報工学の基礎を学習し(学歴が文系であったとしてもその場合は職に就いてから体系的な学習を行い)、泥臭い業務系などのアプリケーション開発を極めた経験を持っているものである。そうした経験の下地があってこそ、経験の中から普遍的な部分を抽出することが可能となり、やがて優秀は真のITエンジニアとして信頼を勝ち取っていったのである。


本当に求められている人材/人財とは


上述したように、日本はユーザー側のITリテラシーが低い。経営者はもちろんのこと、若い担当者もITには疎い。PCなどの使い方には長けている者もいるが、本質的にシステム開発というものの性質には疎い。欧米ではITエンジニアはベンダー側よりもユーザー側の方に多くが所属している。だから、ユーザー自身が業務とシステムとの整合性を考えることができる。しかし、ベンダー側にITエンジニアが偏っている日本では、これが困難となる。

  • ユーザー側はシステム開発には疎く、自分の本業ではないという意識が強い。だから、ベンダー側に要件定義さえも「丸投げ」しようとする。

  • ITエンジニアの多くはユーザー業務には興味がなく、「IT技術力は自信があります」と言いながらも、要件定義に対する提案力が低い。「仕様は正確に言ってもらわないと困ります」「要求仕様通りに作りました」と言い続ける残念なITエンジニアが多くなってしまう。

このような「ユーザー側とITエンジニア側との距離が遠い」ということこそが、日本のIT業界の問題の本質だ。

本当に求められている人材/人財とは、上記の遠くなりがちな「ユーザー側とITエンジニア側との距離」を短くできる人財なのである。

ITはITだけでは存立できない。この言葉の意味がおわかりいただけただろうか。ITというものは常に対象が必要である。制御系なら設備や機械などのハードウェアが存在し、業務系なら個々のユーザー固有の業務が存在する。それらの「対象」への理解が不足している状態では、どんなに純粋なIT技術を学習したとしても活かすことができない。

仮に活かすことができるとしても、それは「与えられた仕様に基づいてプログラミングを行う」といったきわめて限定的な場面にしか活かせない。


何事も「否定」をする者は若輩者


「若いうちはとにかくコードをたくさん書け」「資格なんか価値は無い」と豪語している猛者がよくいる。その意見を全否定する気はないし、頷ける部分もある。

しかし、普通にこのように考えられないだろうか。

  • 情報処理の資格試験などに何百時間も費やしている暇があったらその分コーディングして腕を磨け

 → 情報工学コンピュータサイエンスの学歴などの「基礎知識をしっかりと体系的に学んだ経験がある」という証拠を持っていない者こそ、情報処理技術者試験などの試験は重要であり、そういう試験の合格歴でもって基礎的な知識の有無の第三者に証明をする必要があるのでは?(試験は試験に過ぎずいくら合格したからといって実務能力に直結しないことは皆が知っているし、そこが試験の価値ではない。試験の価値は「第三者への基礎知識の証明」である)

 → それに、いくらコーディングの能力が向上したとしても、前述のような「真に求められる人財」にはなれないですよ? 無論、コーディング能力も重要。本当に優秀な者であれば、プログラミング能力の向上と資格試験の取得とを両立することもできるはずでは?

  • 至高なのはインフラエンジニアなので、業務知識が求められる業務SEなどやめてしまえ

 → 上述したように、本当に実力がある有名なインフラエンジニアは、泥臭い業務系などのアプリケーション開発をたくさん経験しているものである。そうした経験がないと、業務系のSEや、ユーザー側の担当者に対して堂々と意見を言えたりはしないものである。


システム開発において本当に重要な事項などは、えてして何十年も前の開発現場と変わらない部分も多い。

また、時代はくりかえされるという傾向がある。レガシーシステムのインフラのしくみに驚くべき高度な技術が存在していたりするものである。

日本がすでに「技術立国」などではなくなって久しい。

IT業界も昔に比べて実は衰退しているのかもしれない。


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


資格試験の価値


資格試験の価値


昨日、「第一種電気工事士」の筆記試験を受験してきた。

平成30年度なので、平成最後の電気工事士試験となると思われる。

私は本業が情報システム開発/保守(SE)なので、電気系は実務経験が無い。

それでも、将来的なこともいろいろ考えて、本業以外の分野を積極的に勉強している。


先日、免状を取得できた「第二種電気工事士」の受験は、本当にたいへんだった。

電気工事士の試験の本領は何と言っても二次試験にあたる「技能試験」である。

実際に強電の世界で必要最低限、身に染み込ませて知っておかないといけないような注意点を、技能試験を取得する過程で、「身体で覚えさせる」というしくみになっている。

本当に、この資格試験のしくみはよくできていると思う。


過去問で対策ができる試験にも充分に価値はある


昨日受験した「第一種電気工事士」の筆記試験への対策では、自分ながら、そうとう猛勉強した。

直前にはもっぱら過去問題の繰り返しになる。

電気工事士の筆記試験は、過去10年間の問題をやりこんでおけば、まず合格できる内容である。


過去問で対策できる試験を、受験もしないのに侮る言説があるが、それは違うと思う。

当然のことだが、どのような試験でも、「一夜漬け」または「ほとんど無勉強」で合格できるものなど無い。

(仮にそのような試験が存在するとしたら、その資格試験には本当に価値が無い。(いわゆる民間の資格商法などの試験はこういうものだろうが…))

どのような試験でも、事前にしっかり対策を行った場合、つまり勉強をした場合にのみ、合格の目が出てくる。

過去問題で対策可能な試験が低く見られがちだが、過去問を解く、または覚えるにしても、前提知識は必要なのである。

人間の頭脳は機械とは異なる。前提知識もなく問題集の丸暗記など、やろうとしてもそうそうできるものではない。

それに、資格を与える側の思惑として、敢えて同じような問題を繰り返し出すという点もある。

上記の電気工事士筆記試験に関しては、「電気のことを深く知る」ことよりも、「現場技術者として絶対に把握しておかなければならない注意点を押さえる」ことを重要視していると思える。

強電の工事の世界では、設備や工事の取扱を間違えると人命に関わるためである。

故に過去問で対策できる資格にも一定の価値はある。

無論、例えば電気主任技術者試験(電験)など、過去問では歯が立たない、真の理解度が求められる資格試験もあるし、それには、より一層の高い価値がある。


情報系(IT系)の試験のほとんどが単なる知識認定であることが悲しい


資格資格と言っても、情報処理技術者試験のような国家試験でも、民間のオラクルマスターでも、実のところ、「その資格を持っていないと業務ができないという強制力が無い」ので、本当の意味では「資格」とは言えない。

この事実が、試験自体の様々な点での価値低下、試験内容や質の低下、現場エンジニアたちの試験離れの悪循環につながっていると思われる。(注1)

この事実が歯がゆいし、悲しいと思う。

前述した電気系の「資格」は、本当の「資格」なので、その免状を保有していないと業務ができない。

そして、そういう背景もあるためか、資格取得までに必要となる学習プロセスがしっかり根付いていて、電気工事士などは頭でというよりも身体に染み込ませるような「しくみ」になっている。


一方で、IT系は、下手をすると、ずぶの素人が「私は経験豊かなシステムエンジニアです」と名乗っても、それが本当かどうかチェックするしくみがない。(注2)

現に、経歴を詐称することが、中小IT企業の派遣の世界では常態化している面もある。

書店に並んでいる本や、インターネットにおいて、「少しでもプログラミングができれば即エンジニアと名乗れる」と書かれている風潮も、そういった背景と無関係ではないだろう。

IT系と電気系とでは、仕事内容も何もかも異なるので、一様に比較はできないが、本当に歯がゆい現実である。


(注1)それでもIT系の試験は人気自体はあり、毎年何万人も受験している。IT系の仕事自体、参入しやすい側面があるからだろう。

(注2)ここでやはり「参考」となるのは職歴以外では「国家試験」「公的試験」の合格歴だと思う。


平成最後の電気工事士筆記試験お疲れさまでした。


平成最後の電気工事士筆記試験お疲れさまでした。


平成30年度、第二種電気工事士(下期)、および、第一種電気工事士の、筆記試験の日でした。

真夏のような暑さの中、お疲れさまでした。

私は第一種電気工事士の方を受験しました。


電気工事士の試験の本番は何と言っても二次試験である技能試験の方とはいえ......

かなりの猛勉強をしました。

筆記試験で落ちているようでは絶対に合格できないので。

第二種電気工事士とは違い、高圧受電設備を覚えないと話にならない試験。

自己採点では通過したはず。


おそらく、平成では最後の電気工事士試験になりますか?

本当にお疲れさまでした。


「怒り」の感情を否定するな!


「怒り」の感情を否定するな!


書店をめぐるのが昔から好きである。

近年はオンラインで書籍を購入することが増えたが、オンラインでも書籍を検索するのが好きである。

近年、売れている本を見るに、ある傾向が見える。


  • (1)感情的にならないようにしよう

  • (2)怒らないようにしよう

  • (3)アホと戦って時間を無駄にしないようにしよう


人間の「喜怒哀楽」のうち、特に「怒」の部分を抑えたほうが良いという風潮にあふれている


自分の感情を下手に抑え込むと病んでしまうこともある


私は、下記の言葉があまり好きではない。

「怒ったら負け」

確かに、理性を失って、怒りの感情に支配されてしまうと、いろいろと良くない。

それはそう思う。

しかし、一方で、

タイミングよく「怒れない」ことで損をする

という経験を、いままでしてきた。

そして、そういう人をたくさん見てきた。


「怒り」の感情をいけないものだと思い込み、自己嫌悪や、自己肯定感の否定につながってしまうこともある。

「怒り」の感情は、そんなにいけないものなのだろうか。

「怒り」の感情は、喜怒哀楽といった人間の感情の基本的なものである。


「腹が立ったら怒って良い」


「腹が立ったら怒って良い」

本当にそう思う。

自分の心に発生する感情にウソをついてはいけない。


あなたはもっと怒っていい

あなたはもっと怒っていい



企業システムの真髄はバッチ処理にあり!


企業システムの真髄はバッチ処理にあり!


基幹系業務システムの真髄」は夜間などにユーザーから見えないところ(バックエンド)で稼働しているバッチ処理にある

銀行や保険会社などの金融機関における様々なお金の計算もバッチ処理で行われている。

製造業における生産数と在庫数と売上数の帳尻合わせもバッチ処理で行われている。

公的機関の様々な受付業務からはじまる工程管理の整合を取る処理やシステム間連けいもバッチ処理で行われている。

官公庁における戸籍などの個人情報のマスター化もバッチ処理で行われている。

あらゆる企業の毎月の経理精算や給与支払いもバッチ処理で行われている。


上に挙げたのはほんの一例にすぎない。

どれも非常に地味な印象を受ける処理である。

まず華やかな印象はない。クリエイティブな印象もまったくない。

しかし、これらのシステム処理が、ある日突然、停止したり、消えてなくなってしまったりすると、その企業そのものの活動のみならず、広く社会一般にまで悪影響を与えてしまう。

そういったシステムこそが「基幹系システム」なのであり、「プラント型IT」なのである。


Web系などの人の目につく部分(フロントエンド)のシステムは、「ツール系IT」であり、まるごとどこからか買ってきて入れ替えても、その企業の存続には影響しない。

しかし、バックエンドシステムのような「プラント型IT」は、その企業の競争力を生み出している業務そのものと一体化している。

そのため、簡単によそから買ってきて入れ替えることはできない。

そして、その「プラント型IT」の更に根幹部分を担っているのが、バッチ処理なのである。


例えばamazonなどにおいて、「バッチ処理」に関する書籍を検索してみても、ひっかかるのはほとんどが「WindowsMS-DOSコマンドプロンプトにおけるバッチファイル」に関する書籍ばかりである。

こんな情勢では、世の中の若手のITエンジニアにとって、上記のようなバッチ処理の設計が、縁遠いものとなってしまっているという点も、肯ける部分がある。


睡眠時に脳がフル稼働しているのと同じく社会のバックグラウンドではバッチ処理がフル稼働している


近年の脳科学において、記憶の定着に、睡眠が重要な役割を果たしていることがわかってきた

世の中のバッチ処理も、脳における睡眠と同じような存在なのである


やがて迫りくる様々な基幹系システムのブラックボックス


情報系の学校の授業や、IT企業の新人研修において、画面を持たないバックエンド処理であるバッチ処理について、ろくに教えないということが当たり前になって、かなり経過した。

「プログラミングは楽しい」ということばかりを、ネットや書籍では喧伝しようとしている。

それを否定するつもりはない。

しかし、一方では、社会を支えている地味なシステムが、人知れずバッチ処理として動いている。

「クリエイティブ」とか、「楽しさ」とか、そういった感覚とは、およそ無縁のシステムである。

こういったシステムの担い手も、本当ならば、育成しなければならない。

だが、多くの人々は、バッチ処理システムの存在すら知らないのである。


情報システムは、工業製品としての色合いも強く持っている。

しかしながら、何故かIT産業の有名人たちは、その事実から目を背けている。

やがて、社会を裏側で支えている基幹系システムの保守という地味な仕事の担い手が、圧倒的に足らなくなる時代がやってくるだろう。

そのときになって、後悔しても、すでに遅いのだ。


kf7757.hatenablog.com

kf7757.hatenablog.com

kf7757.hatenablog.com


第二種電気工事士に合格はかなりうれしい


第二種電気工事士に合格はかなりうれしい


この5月から7月のプライベート時間のかなりを費やして受験した「第二種電気工事士」(筆記/技能)。

正式な合格通知が届いた。

正直、ものすごくうれしい。そしてホッとした。

この試験の本質は技能試験(実技)にある。

強電の仕事で最低限知らなければならない必須知識が技能試験の対策をやることで身につく。

そういう「しくみ」になっている。

うまいことできていると思う。


これで、一応、「IT」「弱電(無線通信)」「弱電(有線通信)」「強電」の4分野について国家資格を有したことになる。

(ITは、国家資格(免許)というより国家認定に過ぎないことは以前に書いたとおり)

もっとも、それぞれの資格の中では最高位ではないのだけれど…。(昔のものもあるし…)

この中で、実技試験が課せられているのは、強電の電気工事士だけである。

強電の世界では知識が無いことが人命に関わるためである。


技能試験は専門家に習ったほうが良い


合格率のデータだけを見ると、第二種電気工事士は、さして難しい試験ではないように思えてしまう。

現に昨年の私は、そう思ってしまった。それで不合格だったわけだが…。

しかし、工事作業を本業としているような人や、電気工学科などで実習をしたことがある人ではない限り、独学で挑戦するのはおすすめしない。

普通のド素人が、独学で突破できる試験ではない。

電気工事の基本単位作業を、頭で考えることなく「身体で覚えている」くらいのレベルに持っていかないと、なかなか合格は難しい。

なぜなら、本番での試験の時間がとても短いからだ。


専門家である講師に実習を教えてもらうことで、お手本を生で見ることができるし、本当に基本中の基本の疑問も聞くことができる。

電気工事士もそうだが、電気関係の知識では、本当に独学よりも先生に教わるほうが良いことを実感している。

ただし、まったくの無知識状態で先生に教わるのは、非効率である。

新人研修でも、教えたことのほとんどが残らない。

それは、まったくの下地がない状態では、いくら知識を頭に入れようとしても入らないからである。


その意味では、電気工事士の技能試験対策については、私は、あえて2回以上の講習を受けることをおすすめしたい。

1回めの講習で、電気工事士の基本的な作業を体験し、頭に回路を作る。

2回めの講習で、一度できた回路に改めて知識(体で覚える知識も含む)を、再度頭に入れる。


ほっとしたのは、「これで第一種電気工事士にもチャレンジできる」と思ったからでもある。

第一種にも挑戦するつもりでいる。


みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに


みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに


以下のような流言がいつまで経っても消えない。

  • DOA (Data Oriented Approach) で新たに開発すれば生産性/保守性が高まる

  • オブジェクト指向言語で新たに開発すれば生産性/保守性が高まる

  • 現行システムの維持に費用がかかるのは上記を採用していないからだ


いかにも、当該のユーザー企業の外側にいる(当然現行システムの中身など知らないし興味もない)コンサルタント業の人が言いそうなことではある。

そして、未だに大企業や官公庁といった大規模ユーザーで決裁権を持っている「偉い人達」は、そもそもITには疎い者ばかりで、システム開発のことなんて「ド素人」である。

日本企業には、こうした「偉い人達」の側近には「イエスマン」しかいない。

上記のようなことを鵜呑みにして、様々な思惑も絡んで、難易度の高い大規模システム開発がくりかえされ、その多くが何らかの失敗をしでかして、欠陥の多いシステムが作られていく。


  • DOA (Data Oriented Approach) で新たに開発すれば生産性/保守性が高まる?

現行システムが開発されて四半世紀。すでにOracleなどのRDBを中心に使用して回っている。

RDBを使用するだけでも、ある意味強制的に、部分的にはDOAを実現している。

逆にRDBの機能に頼り切ったシステムでは、保守性という面で問題が生じることは、もうみんなが知っている。


こんなことを言うと一部から反論されそうではあるが、敢えて正直に言うと、オブジェクト指向と生産性や保守性は、直接的には関係性は無いと思っている。

要は、生産性や保守性を意識したシステム設計を、ちゃんとするか、しないか、それだけである。

そこに、「オブジェクト指向か否か」はあまり問題にはならない。

オブジェクト指向言語が実装としてやっていることを、ちゃんとコンピュータのしくみのうえで説明できる人が、そのプロジェクトに何人いるだろうか。

例えば「継承」がやっていることが、実メモリ空間の中でどう処理されているのか。

そういったことを理解していない人たちが設計してしまうと、結局、生産性や保守性が低いシステムができあがってしまう。


  • 現行システムの維持に費用がかかるのは上記を採用していないからだ?

以前にも下記の記事で少し紹介したように、特に基幹系システムというものは、その企業の競争力を生み出す業務そのものと一体化した、「プラント型IT」と呼べるものである。

kf7757.hatenablog.com

確かに実際のプラントと同様に、全体のアーキテクチャーが古いままであると、時代の流れに追従できないという問題も出てくるだろう。

しかし、それは、上述のような開発手法などの問題とは、また次元が異なる問題である。

上でも言ったが、どのように設計を行うか、という、設計スキルに帰着してしまうのである。


しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない


しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない。

問題の本質はそういう部分ではないことを知っているから。


近年、ようやく、Java言語の世界において、共通化がされてこなかった「バッチ処理」について、共通的なフレームワークの必要性が叫ばれるようになった。

少なくとも、日本の基幹系システムの心臓部は、すべてバッチ処理の部分に存在している。

java公式のバッチ処理の標準化仕様:jBatch

www.imagazine.co.jp

これだって、中身を見ると、なんの真新しいことはない。ごくごく当たり前のことを標準化しただけである。


kf7757.hatenablog.com


「自分の無知を知る」ことの大切さ


「自分の無知を知る」ことの大切さ


最近は試験勉強が忙しく、更新が停滞している。


第二種電気工事士」の本番は何と言っても「技能試験」の方だということを、最近、身を持って体験している。

普段、ドライバーなどの工具もろくに使うことがない生活をしている者にとっては、ごくごく基本的な電工の実技も、たいへんだ。最初はものすごくつらい。

でも、強電を扱う者としての最低限の注意点などが、頭というより、手で覚えられるようになっている点がすごい。

あと一週間なので、山場である。


7月に入って、いろんな職場では、新入社員が現場に配属される季節になっている。

この季節になると、いつも、

「自分の無知を知る」ことの大切さ

を考える。


「わかっています」「知っています」と言う人にどうやって先を目指させるようにするのか


人に仕事などを教えることがよくある。

やはり、その仕事を長年やっている人の方が、いざというときの引き出しの数や、知識の深さが違っている場合が多い。

その意味では、入社数年の若手や、異業界からの転職者の人は、その道で長い人に比較すると、いろいろと「わかっていない」場合が多い。

しかし、プライドが高い者などは、「わかっています」と言う

さらに精神的にこじれている場合、「わかっていない」ことから目をそむけ、自分がこれまで得意としてきた領域にこだわり過ぎて、まったく新しいことを覚えようとしない者もいる。


若手で、「本当は深くはわかっていない」のに、それに気づかない者ならば、「自分が実はまだまだわかっていないんだ」という事実に、気付きさえすれば、成長できる。

なまじ、社会経験がある程度ある人の場合、プライドのせいで「わかっていない」ことから目をそむけてしまう。

これだと成長する機会をどんどん失っていくだろう。


「自分の無知を知る」

これは本当に大切である。

私はいま、電工試験に集中しようとしているが、こっそり電験三種(第三種電気主任技術者)の勉強もやっている。

電験三種がいかに難しいか、それを最近、少しだけ実感してきた。

正直、合格できる気がしない。

でも、こういう実感は大切にしたいとも思う。

世の中には土日でも勉学に励んで頑張っている人が多くいるのだ。

見習わねば。


第二種電気工事士の技能試験にむけて


第二種電気工事士の技能試験にむけて


ネット上に多くある「資格ランキング」とか「資格難易度」などの情報は、実はとてもいい加減である。

はっきり言うなら、ウソばかりだと思える。

その記事を書いている人間が、実際に受験勉強をして試験を受けた訳ではなく

「受験者数」、「合格者数」、「合格率」、などという、ふわっとした情報だけから判断している

そういう情報は信用できない。

(企業の人事の人などもこういう情報を鵜呑みにしないでほしいものである)


第二種電気工事士(2電工)などは、そうした「資格難易度」のネット情報では、「初心者向き」で、「簡単」な資格と書かれている。

確かに、「電気主任技術者」(電験)などに比べれば、

筆記試験は、そこまで難易度が高いとは言えないだろう。

しかし、工事士の試験なので、技能試験がある。

これは本当に簡単な試験なのだろうか。

少なくとも、7月の本試験に向けて、かなり頑張って「練習」を行わない限り、合格はできないだろう。

本職がシステムエンジニアの私にとっては、「工具」を使って「電線」をむいたり切ったり接続したり、という作業は、まったくもって未知の世界。

この試験を簡単だとはとても言えない。


準備がたいへんなこの試験。

準備がたいへんなだけに、合格したいものである。


勉強が多忙なので、記事も短めであります。


第二種電気工事士筆記試験を受けてきた(実は二度目)


第二種電気工事士筆記試験を受けてきた(実は二度目)


先週は、弱電系(通信系)の「工事担任者試験」があり、

本日は、強電系の登竜門たる「第二種電気工事士」の筆記試験だった。

ここ最近の土日では、受験対策をしていたため、この記事も久しぶりの更新となった。


昨年までは、上期か下期のいずれか一回しか受験できなかった。つまり上期と下期があっても事実上、一年に一度しか受験機会がない試験だった。

今年から、上期と下期、どちらも受験できるようになった。

それだけ、需要もある試験なのだろう。

しかし、近年は難化傾向があると聞いている。


実は昨年、私は初めてこの試験を受けた。結果はちょうど50点で不合格。

電気系に関する下地の浅さと、試験対策が全く足りていなかった。

普段の自分の仕事で関わっている分野とは異なる領域の勉強の難しさを知った。


この一年間で、電気系に関する知識の下地は、かなり作って来られたと思う。

試験対策は、どうしても日々の疲れで、なかなかできなかったが、昨年とは下地の部分がまったく違ったためか、本日の筆記試験は、まぁ、なんとか通過した感触はある。


さて、問題は約一ヶ月後に控えている、「技能試験」(実技)である。

これは本当に試験対策をしないと合格できないだろう。


さすがに規模が大きな国家試験はいろいろ違う


昨年もそうだったけれど、試験地に行く道すがら、いろんな電気関係の教習所や出版社の関係者が、チラシを配っている。

消しゴムや、シャープペンシルをくれる会社もある。(オーム社さんシャーペンありがとう)


本日は6月初旬にしては猛暑だった。

皆様、お疲れ様でした。


いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫


いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫


「会議」とか「打ち合わせ」とか、名前はそれぞれで、何でも良いのだが、とにかく、人が集まったからには、何かしらの目的がある。


  • 情報の伝達とその結果(連絡)

  • 知恵の出し合いと何らかの結果(検討)

  • 意識や認識の確認とその結果(確認)


プロジェクトにおいては、規模が大きくなればなるほど、コミュニケーションの数が爆発的に増大する。

結果として、打ち合わせが多くなる。

そして、本来、打ち合わせとは、上記の三種類に大別できる。

「連絡」「検討」「確認」の三種類である。

ちゃんと機能した打ち合わせであれば、必ず何らかの「結果」が存在する。

そして、参加者は各々で、その「結果」を持ち帰り、自チームや自社メンバーに伝達する役割を担う


この、「結果」を持ち帰り、自チームや自社メンバーに伝達する、ということができていないプロジェクトが多い。


プロジェクトの規模が大きくなればなるほど、本来は、上記の打ち合わせひとつひとつの重要度も増大する。

しかし、現実としては、大規模プロジェクトほど、打ち合わせがうまく機能しない。

何故か。

皆が忙しいことを言い訳にして、モノを書かないからだ。


メモでもいいから必ず書きものにして相手に渡せ!


うまく機能しない打ち合わせで、最もよくあるのが、

すべて口頭で情報が伝えられ、書きものとして結果が残らない

という状況である。

情報を伝えた方は、口頭で言ったので「伝えた」気分になっている。

情報を受け止めた方は、口頭で言われたことを一応は理解して「わかりました」と言う。

しかし、情報を受け止めた方は、その後になって、自分のノートの不完全なメモから、「どう決まったんだっけ?」という状態に陥る。

また、本来は正しい情報を自チームや自社メンバーにフィードバックしないといけないのだが、自分のノートの不完全なメモしか残っていないので、また、テキストにまとめる手間も惜しいので、またもや口頭でのフィードバックとなる

口頭で伝えられたメンバーは、非常に劣化した情報が伝えられたこととなり、あいまいな情報がますますあいまいになっていく。

フィードバックされるならまだ良い方で、忙しさやメンバーとの時間が合わなかったりして、フィードバックすら行われない状況にもなる。


打ち合わせで口頭で言う予定のことは、メモでも良いので書きものにして渡す。

打ち合わせに参加した者は、その書きものを持って帰り、「こんな事をいわれた」と、その書きものを流せば良い。

たった、これだけのことで、情報の伝達不全は、かなり解消できるのである。


kf7757.hatenablog.com


「IoT」や「AI」という名の本を読むくらいなら「情報工学」「電子工学」の本を読むほうが有益だと思う


「IoT」や「AI」という名の本を読むくらいなら「情報工学」「電子工学」の本を読むほうが有益だと思う


IoT (モノのインターネット) , AI (人工知能)

いま書店に行くと、これらのキーワードをタイトルに使った本であふれているように見える。

書店だけではなく、企業の経営者なども、こうしたキーワードを盛んに使用している感がある。


もちろん一部には本物の専門家や有識者が、そういった本を書かれていたり、そういう言葉を使ったりしているのだろう。

しかし、大半の場合、「その筋の専門家ではない人」、「充分な知識を持っていない人」が、上記のような本を書いていたり、言ったりしているように思える。


言っては悪いが、「時流に乗っているだけ」の人もいるように見える。


どれもかなり昔からあった概念であり、その延長線上にある


IoT (モノのインターネット)

これは、1990年代に盛んに言われた「情報化社会」や、2000年代に盛んに言われた「ユビキタス社会」からの延長線上にある。


AI (人工知能)

これも、古くは「Lisp言語」の成り立ちの頃から研究されてきたものであり、エキスパートシステムの歴史を見れば、いまにはじまったものではない。

ビッグデータと関連付けて語られることが多いのも、膨大な物証がそろってはじめて実現できる理論も多いからである。

そのビッグデータの基盤にあるものは、データベースであったり、ネットワークであったり、従来のコンピュータシステム工学である


技術領域のマッピング図を作成してみた


(技術領域マッピング図) Copyright FUJIWARA775


f:id:KF7757:20180505173642j:plain


IoT ( モノのインターネット ) とは、こに示している技術領域のすべてに関係している。

AI ( 人工知能 ) も基礎は既存の情報工学のうえに立脚している。

これが私の自論である。


いまおきていることは革命ではない。

いまの時代、既存の知識や概念が完全に塗り替えられるようなことは発生しづらく、いままでの積み重ねのうえに不可能だったことが可能になっただけなのである。

上記の図を見ればわかるように、IoT、AI、などは、どちらも既存の技術領域を抜きに語ることはできないはずなのである。


基本に立ち帰るほうがかえって理解には近道となる


何事も、基本、基礎から地道に学習することが大切であると思う。

いまの時流に乗ったような、「IoT」や「AI」という名の本を読むくらいなら、「情報工学」や「電子工学」、「無線工学」などの本を読むほうが、よっぽど有益だと思う。



kf7757.hatenablog.com


本当に理解できるまでには時間がかかるように脳はできている(勉強論)


本当に理解できるまでには時間がかかるように脳はできている(勉強論)


脳科学の本を読んで知ったことである。

脳において記憶に重要な役目を担っている器官が「海馬」である。

勉強したときの記憶はまず、とりあえず「海馬」に格納される。

その後、「短期記憶」として処理するか、「長期記憶」として「大脳皮質」に送るか、峻別される。

ここで「長期記憶」とされるか否かは「生物として生きていくうえで重要な情報かどうか」で決められる。

なので、「こういう臭いの食物は食べない方が良い」などという情報は、長期記憶になりやすい。

一方で、勉強した情報などは、生物としての生き死ににとってはどうでも良い情報なので、長期記憶にはなりにくい

勉強をしたり、研修や講義を受けたりして、「覚えた」「わかった」「理解した」と思ったとき、その情報はまだ「海馬」にある

そのままでは「短期記憶」として処理されて、忘れてしまう

海馬に留まる期間は最大でも一カ月。それを過ぎると記憶は消えてしまう。


脳は、そのようにできている。

脳は、学習したことを「忘れる」ようにできている。


では、忘れないようにする方法はないのだろうか。

ある。

それは、「覚えた」「わかった」「理解した」と思ったことでも、再度、「覚える」「わかる」「理解する」を行うということ

これを「くりかえし行う」という地道な努力しかない。

それをすることで、「海馬」にある記憶が「重要な情報である」と脳をだますことになり、「長期記憶」になりやすくなる。


レミニセンス効果 (時間が経ったほうが記憶が定着する)


レミニセンスという言葉がある。

「レミニセンス効果」とも言われる。

脳は睡眠をとっている時間に「夢」をみる。そのほとんどは覚醒した時点で覚えていないが、ほぼ必ずといって良いくらい脳は「夢」をみているそうである。

その「夢」をみているときに、脳では「記憶の整理」を行っている。データベースの索引を再作成しているようなイメージだろうか。

いままで、いくら本を読んでも「わかった」という感触がつかめなかったことが、ある日、ふと「わかってしまう」ことがある。

いままで、他人が書いた昔のソースプログラムを追いかけていても、なかなか意味がわからなかったものが、ある日、ふと「わかってしまう」ことがある。

これが、「レミニセンス効果」である。

(これは、当然のことながら、一度以上、しっかりと「わかろう」という努力をして学習するということが前提となる)


一夜漬けが最も時間をムダにしている勉強法である


上記の考え方からすると、何事も「早いうちからはじめる」ことが重要であると言える。

そして、「本当に理解できるまでには時間がかかるように脳はできている」と言える。

脳は大量の情報を一気に学習することには向いていない。

例えば一夜漬け勉強のような、短期間での詰め込み学習は、結果として「短期記憶」として忘れてしまう確率が高くなる。また、睡眠時間を削ってしまうことで、「レミニセンス効果」も働かない。


勉強をしっかりと時間をとって行った人は、それだけ深い理解をしている。

自分も心がけていきたいと思う。


「しくみマニア」からみたコンピュータ関連の良書とは


「しくみマニア」からみたコンピュータ関連の良書とは


IT業界には、ITを専門に学んでこなかった人も多数、入ってくる。

IT業界で必要となるスキルや知識は、IT系に限らない。例えばプロジェクトの中でうまく立ち回るとか、そういった場面には、IT専門知識などよりも、もっと基本的なコミュニケーションスキルが必須である。

なので、ITの素人が入ってくること自体は、むしろ必要なことでもある。

しかし、IT業界で仕事をするうえでは、そうはいってもIT系の基礎的な知識が、本来なら必要である。

基礎の基礎の部分は、いまや会社の新入社員研修では教えてくれない。(まぁ、昔からそうではあったが)

何故か。

当座の仕事をこなすだけであれば、IT系の基礎の基礎、つまり「コンピュータのしくみ」を知らなくてもこなせるからである。

逆に、とにかく何らかの「プログラミング」ができないと、IT業界では仕事に支障が出てしまう。

これはつまり、「コンピュータのしくみ」を全部は知らなくても「プログラミング」はできてしまう、ということである。


仮にもIT業界に数十年もいるというのに、「コンパイラ」や「リンカー」の動作内容を説明できない人。

JavaVM(Java仮想マシン)の動作内容を説明できない人。

こんな人は、実に多い。(エンジニアという職種なのに!)


IT系のそれなりの規模の企業でも、いわゆる文系(※1)の新卒者を、2ヶ月間だけプログラミング研修を受けさせた後に、現場に送り込む。

(※1)私は本来は「文系」「理系」という区分で人を語ることが大嫌いであるが。


2ヶ月間の研修で、「コンピュータのしくみ」がきちんと理解できるだろうか。

答えは、Noである。(人にもよるがほとんどはNo)

学校でしっかり学ぶ場合を想定しても最低6ヶ月は要する内容だからである。それを研修ではたった数日間から数週間しかかけない。これでは「研修の内容だけ」からは絶対に本当の理解はできない。

一方で、

2ヶ月間の研修で、「プログラミング」ができるようになるだろうか。

これも、本当は、Noである。

だが、上述したように、何らかの「プログラミング」ができないと、IT業界では仕事に支障が出てしまう。

だから、とにかく形だけでも「プログラミング」だけはできるという体(てい)にするのである。

「プログラミング」も、本来なら、学校でしっかり学ぶ場合を想定しても最低6ヶ月は要する内容である。しかし、本来ならアルゴリズムなどの基礎から積み上げることが必要であるが、「まずは動かす」ことを主体に学習を進める。統合開発環境IDE)の使い方から簡単なプログラムを動作させることを優先する。


私は、本来は以下の2点の学習は不可分であるという持論なのだが、賛同してくれる人は少ない。

  • コンピュータのしくみ(動作原理)の基礎

  • プログラミング(アルゴリズム含む)の基礎


本当の基礎を学習しないままプロになる業界はIT業界だけではない


本当の基礎を学習しないままプロになる業界はIT業界だけではない。

これは自分自身、電気関係の勉強や国家資格を取得したりした経験から言える。

例えば「電気工事士」が、その基礎分野である「電磁気学」をちゃんと理解しているかというと、必ずしもそうではない。むしろ理解していない人の方が多い。

電気の資格の教本に出てくる「原子のモデル」は、いわゆる「惑星モデル」である。

「惑星モデル」は、既に数十年も前に「量子論」によって否定された古典モデルである。

だが、電気回路を計算する上では、原子のモデルを「惑星モデル」で理解していても何の問題もないのである。


しかし、私は「しくみ」を正しく理解することにこだわる。

「しくみマニア」なのである。


「しくみマニア」が良書と思えるコンピュータのしくみの教科書


オーム社 図解 コンピュータ概論[ハードウェア](改訂4版)

オーム社 図解 コンピュータ概論[ハードウェア](改訂4版)

shop.ohmsha.co.jp


オーム社 図解 コンピュータ概論[ソフトウェア・通信ネットワーク](改訂4版)

オーム社 図解 コンピュータ概論[ソフトウェア・通信ネットワーク](改訂4版)

shop.ohmsha.co.jp


この二冊は姉妹本である。

また、「概論」とあるように、内容的にはそんなに高度ではない。

それでも、情報処理の入口の教科書としては、そこそこ網羅性もあり、良書であると思う。

この二冊の内容をきちんと学校の講義形式で学習するなら、6ヶ月はかかるだろう。

もしも、IT基礎をあまり学習しないまま、新入社員研修に放り込まれた自覚がある人や、ちゃんと基礎を理解したいと思う人は、手元においておくのも悪くないと思う。


基礎のふりかえりにも使えると思う。


プライバシーポリシー/お問い合わせ