IT (情報技術) 学習記録

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

資格試験の価値


資格試験の価値


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

平成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