COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)
COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)
まず、結論から先に言うと、
むしろ、優れた後方互換性によって、数十年も前のプログラムが現在でも稼働しているという特徴がある
一周回ってCOBOL技術者が不足してしまったため、かえって高価値になってきている
COBOLで書かれたプログラムが、現在でも社会インフラを支える大企業・官公庁システムにおいて、数千万ステップから数億ステップは稼働しているし、この状況がすぐに変化することはない
したがって、
「COBOLは若手が覚えるべきではない」
とか、
「COBOLはもうすぐなくなる」
......と言った言説は、的を射ていない。
私が情報系の学生時代だった25年以上も前から、「COBOL」なんて古い言語はなくなるから、「C言語」を学習すべきだ、と言われていた。
(当時はJavaはまだ生まれたばかりで浸透しておらず、オブジェクト指向も同様に浸透していない時代だった)
学校の講師の普通にそんなことをいう有様だった。
当然、世間を何も知らない学生でしかない私は、それを真に受ける。「そうかぁ、COBOLなんて使われなくなるんだ」
だから、当時は珍しかった「C言語」「アセンブラ」を学習できる専攻コースに進んだ。
(確かに、学生時代に「C言語」「アセンブラ」といった低レベル言語系を学習できたのは、自分にとっては財産だったと思っている)
※ここでいう低レベル言語系とは「機械に近い」という意味である。
私が就職した当時は、折も悪くバブル景気が崩壊した直後で、「就職氷河期」に入ってすぐだった。
そんな中、いま勤務しているユーザー系のシステム会社に入った。
新入社員研修で、みっちり仕込まれたのが、COBOL、および、それに関係するドキュメントの作成だった。
採用面接のときに、「C言語やアセンブラをやってきました」とアピールしたのに、いわゆる汎用機系の研修に回されたことは、当時、とてもショックで、「会社を辞めよう」かと本気で思った。
紆余曲折もあったが、その後、実際の稼働中のシステム保守や、いくつもの大規模な新規システム開発に携わった。
かなり昔から業務に情報システムを組み込んできたユーザー企業だったので、COBOLプログラム資産はかなりの物量があった。
そして、保守にしても開発にしても、プロジェクト規模が大規模化する傾向があった。
プロジェクトが大規模ということは、ユーザー企業の業務特性や習慣など、まったく知らないプログラマーが短期間に大量に集められ、システムを構築せざるを得ない、ということである。
(日本的なIT業界の多重請負構造の是非などはここでは言及しないが)
また、開発が終わると長い保守フェーズに入るわけだが、保守としてプログラムを修正する人は、開発当時の人とは違う。
これが当たり前の世界。
こういう状況にあって、COBOLは、以下のようなメリットをもたらしてくれた。
記述や表現が「不自由」であるため、かえって人によるクセが出にくく、誰が組んでも設計さえちゃんとしていれば、同じようなプログラムソースコードになる
データ項目ANK名などの管理がしっかりできていれば、後日、第三者がプログラムを追跡したり、検索したりすることが容易である
記述や表現は「不自由」だが、1バイト以上の文字データや数値データの扱いは、きわめて低レベルにできる(逆に言うとプログラマーが実データを低レベルに意識しないと書けない)
上記の特性があるため、「見積もり」の誤差が出にくい
特に一番目のメリットについては、昨今、COBOLではないモダン言語による大規模開発プロジェクトでは、フレームワークで吸収しようとして、それがうまく行かず、炎上しているのを、けっこう見かける。
趣味で書くプログラムではなく、仕事でつくるプログラムであり、使うのは自分ではなく、ユーザー企業(のユーザー)である。
そこに対して、「COBOLの仕事は楽しくない」「クリエイティブじゃない」とかいう意見は、まぁ、わからなくもないが…。
でも、それは個人の「仕事」に対するスタンスの問題もあるので、それが即「COBOLの仕事は若手にはやらせるな」というのは、暴論だと思う。
私は、システム開発保守の仕事で30年近い経験がある訳だが、このような「COBOLの仕事は若手にやらせるな」などという暴論を目にすると、本気でIT業界から去りたくなる。
本質的ではない、バカみたいな暴論が、まかり通ると、その業界の現場で働く人のモチベーションが低下する。
私は近年、IT系以外にも軸足を持ちたくて、電気系・通信系の学習をしている。
例えば電気系の世界で、「あそこの会社は誘導モーターを使っているから行きたくない」などという技術者がいるだろうか。
まぁ、ホテルだとか商業施設だとかは、電気系以外にもボイラー設備があるから、そこの設備管理はやりたくない、とか、そういうことはあるようだが…。
冒頭でもいったように、いまだに大企業・官公庁を中心に、金融、電気・ガスなどの公共事業といった、社会を支える重要なシステムは、COBOLで書かれたプログラムで稼働している。
この事実を無視、もしくは、歪んだ目で見て、開発現場の経験もない「日○コンピュータ」などの記者さんが、「COBOLの仕事は若手にやらせるな」などと書くことによって、経験のある自分でもモチベーションが下がるのだから、経験のない若手が「COBOL」の案件に関係する会社や部署に行かされたら、辞めよう、という気持ちになるのも無理はない。
COBOLとは、良い面、悪い面、含めて、どういう言語なのか。または、適用プロジェクトによって価値はどう変わるのか。
そういったことを、自分の経験としてとらえたうえで、「COBOL案件はお断り」と言うなら、全然問題ない。
問題なのは、経験もないのに、まことしやかに上記のような言説を吹聴する輩である。
ちゃんとした経験を持つ人であれば、たとえ個人的には「COBOL案件はお断り」であるとしても、決して他人にそれを強要することはないだろう。
俗に言う「コボラー」とは、COBOLを知っている人のことを指すのではない。
「COBOLしかやったことがないし、それ以外知らないので、わかりません」
という、勉強をしない人のことを指す。
「勉強をしない人」が、嫌われるのは当然のこと。
それこそ、COBOLとはなんの関連もない。
他の言語の技術者だって同じである。
また、一方で、ユーザー企業から重宝されているCOBOL技術者もいる。
大企業や官公庁で情報システム化が進んだ当時、「業務をシステムに落とせる人」が、大活躍した。
その当時、いまでいう超上流工程である「要件定義」「検討」から話ができて、それを設計書やプログラムにまで落とし込みができるスーパープログラマーがたくさんいた。
その時の開発言語もまた、COBOLだったため、現在、大企業や官公庁で稼働しているCOBOLプログラムには、「業務をシステム化した」ロジックが大量に含まれている。
いま現在、COBOL技術者に望まれているのは、単なるプログラミングができるという側面ではなく、COBOLプログラムに大量に含まれている業務ロジックを正しく扱える能力ということでもある。
COBOLを悪者にすると結局ますますIT業界から人が去っていく悪循環(COBOLでの開発保守の経験もない人がCOBOL不要とか勝手に言うなよ)
くりかえして言うが、「COBOLなんてなくなるので勉強する価値はない」という誤った言説は「25年以上前」からずっと言われ続けてきたが、現実には、「COBOLはいまでも大量に稼働していて社会を支えている」のである。
【国家試験】電験三種(第3種電気主任技術者試験)の難易度
【国家試験】電験三種(第3種電気主任技術者試験)の難易度
電験三種はただいま学習中ですが、自分が今までに受験してきたさまざまな資格試験の中でも、最も難しいレベルだと改めて思います。
特に思い知る部分としては、過去問題をただ単に反復練習するだけでは、決して合格できないというところです。(無論、過去問の反復練習は必須なのですが)
問題の出題者の意図を掴んだ理解をしないと難しいような問題になっているところです。
かと言って、第二種電気工事士などが「簡単」と言う気もありません。
電気工事士もしっかり数ヶ月間、学習しないと合格できません。当たり前ですが。
特に電気系の「ズブの素人」からだと、数ヶ月は必要です。
ただし、電気工事士は、「電気工事士として最低限これだけは絶対に押さえておきなさい」という知識や技能をチェックする試験です。
逆に言えば、その要点さえ押さえておけば、合格するように設計されています。
電験三種は、明らかに違います。
問題が本当に考え抜かれていて、前述のように、「深い理解」があるかを見てきます。 そして「落とし」に来ています。
10人中1人くらいの合格で良いとされている試験です。
10人中9人は不合格で良いという試験です。
(以下は、自分が実際に受験したり学習したりして、ある程度の実感が持てるもののみを挙げています。電験二種などはまだ学習経験がないので挙げていません)
数字が大きい方が難易度が高いという意味です。
【電気系】
第二種電気工事士(筆記試験):20
第二種電気工事士(技能試験):30
第二種電気工事士トータル:50
第一種電気工事士(筆記試験):40
第一種電気工事士(技能試験):60
第一種電気工事士トータル:100
【通信系(有線系)】
電気通信工事担任者3種:30
電気通信工事担任者1種:120
電気通信工事担任者総合種:150
電気通信主任技術者:750
【通信系(無線系)】
第一級陸上特殊無線技士:180
第二級陸上無線技術士:500
第一級陸上無線技術士:1000
【IT情報系】(参考)
基本情報技術者試験:250
応用情報技術者試験:400
高度区分情報処理技術者試験:500〜800
ちなみに私の所属する企業体では、電験三種は非常に低く見られています。
IoT、5Gなどの新技術領域にとっても、基礎である電気技術を広く知っていることを示す資格なのに、残念なことです。
「5G」「IoT」「AI」などと言う前に、基礎理論となる「電気工学」「電子工学」「無線工学」を勉強しよう!
「5G」「IoT」「AI」などと言う前に、基礎理論となる「電気工学」「電子工学」「無線工学」を勉強しよう!
今年に入って、私は仕事の忙しさもあるが、何より、「電験三種」(第三種電気主任技術者試験)の勉強に時間を使っている。
(このブログもそれがあって更新が滞り気味になってしまった)
電験三種の試験範囲は本当に広範囲にわたっている。
電気工事士試験とは比較にならない。
電験三種の範囲をすべて人に教えられるくらいに知っている人なら、確かに誰からも一目置かれるだろう。
ウチの親などは全く無知なので、私が先日合格した「第一種電気工事士」のほうが、「電験三種」よりも上だと思ったようだ。
頭についている「一種」「三種」という数字から、そう思うのだろう。
ちなみにウチの会社の人事部も、同じくらいにしか思っていない。電験三種と第二種電気工事士が同レベルに社内的にはランキングされている。
愚痴はさておき。
ウチの会社の経営層が、盛んに「DX」(デジタライゼーション)とか、「AI」「IoT」などと言い出している。
そして、そういう領域の研修を受けなさいという。
研修を受けるのは良い。そういう領域について関心を持ち、学習するのも良いだろう。
しかし、「5G」「IoT」「AI」などという領域は、複数の領域が複合した「応用分野」である。
例えば、5Gにしても、ではそれより以前の、第一世代から第四世代までの無線通信システムについて、ちゃんとわかっているのか?……と言いたい。
IT系の分野でも、「データベースの専門家です」という人が、基礎となる「ストレージのしくみ」や「コンピュータの動作原理」を知らず、「SQLならわかります」などと言い出したら、それはニセモノだとわかってしまう。
回り道に見えるかもしれないけれど、応用分野をしっかり理解したいと思うなら、基礎分野から学習しないといけない。
第一種電気工事士合格証書GET!
第一種電気工事士合格証書GET!
「第一種電気工事士」の合格証書が届いた。
「第二種電気工事士」が一般電気工作物(低圧)の工事のみであるのに対して、「第一種電気工事士」は自家用電気工作物(高圧)の工事も対象になる。
正式な免状を得るには、五年間の実務経験が必要となる。
試験合格だけでは第一種の免状は得られない。そのため、この試験を受ける価値を見いだせないという人もいるようである。
だが、高圧受電設備などの高圧電気の勉強という意味では、第二種とは別物であるため、勉強する意義は大いにある。
電験三種(第三種電気主任技術者試験)を目指すうえでは、第二種からいきなり行くよりも、良い通過点になると思う。
電験と電工では、試験の難易度も範囲もレベルが違いすぎるので、電工から順番に受けるのは意味がないという人もいるようだが、私の意見は違う。
けっこう電験の講習会に電気の知識ゼロの状態でやってくる人がいる。
さすがに知識ゼロからいきなり電験はつらいはずである。(せめて電工や他の電気通信系の資格を経たほうが良いとは個人的には思う)
ちなみに、「認定電気工事従事者」の資格を得るのに、この「第一種電気工事士」の合格だけで申請できる。
「第二種電気工事士」、「電験」を保有する人が同じ認定を得るには、所定の講習を修了する必要がある。
とりあえず、今年は電験を頑張ろうと思う。
資格/試験 取得一覧 (2018年まで)
資格/試験 取得一覧 (2018年まで)
SEQ.取得年 資格/試験名称
01 1991年 情報処理能力認定試験A級
02 1991年 第二種情報処理技術者試験 (国家試験)
03 1995年 第一種情報処理技術者試験 (国家試験)
04 1995年 パーソナルコンピュータ利用技術認定試験4級
05 1995年 パーソナルコンピュータ利用技術認定試験3級
06 1997年 パーソナルコンピュータ利用技術認定試験2級
07 2000年 ORACLE MASTER Silver 7/8 共通 (旧制度)
08 2003年 IBM DB2グローバルマスター・エンジニア
09 2003年 IBM DB2グローバルマスター・エキスパート(管理)
10 2004年 UMLモデリング技能認定試験レベル1 (UMTP L1)
11 2008年 Cosminexus認定アプリケーション・エンジニア
12 2008年 Cosminexus認定プラットフォーム・エンジニア
13 2008年 Cosminexus認定アプリケーション・スペシャリスト
14 2008年 Cosminexus認定プラットフォーム・スペシャリスト
15 2009年 UMLモデリング技能認定試験レベル2 (UMTP L2)
17 2017年 ORACLE MASTER Bronze Database 11g
18 2017年 ORACLE MASTER Silver Database 11g (Oracle Certified Associate)
19 2017年 無線従事者 第三級陸上特殊無線技士 (国家試験,国家資格)
20 2017年 無線従事者 航空特殊無線技士 (国家試験,国家資格)
23 2018年 無線従事者 第一級陸上特殊無線技士 (国家試験,国家資格)
24 2018年 第二種電気工事士 (国家試験,国家資格)
(第一種電気工事士は、筆記試験/技能試験すべて受験した。結果待ち)
世間では「電気工事士」は決して難関資格として扱われていないのだけれど、やはり筆記試験だけではなく技能試験があるため、合格するには相当の苦労はあると思う。
「電験3種」は、はっきり言って、他の資格と比べるとものすごい難関資格だ。
いわゆる「士業」系の国家資格に匹敵もしくは凌駕する難易度だとも思う。
(試験内容自体の特出した難易度という意味では、無線従事者の「第一級陸上無線技術士」(上記の「一陸特」ではない「一陸技」の方)なども相当に難関だが、電験に比べるとマイナーだからなぁ…)
IT系・情報系には、厳密な意味での「資格試験」は存在しない。
あくまでも知識やスキルを「認定」するだけで、他の電気系・通信系のような法律に定められた「業務独占資格」ではないからだ。
そのことが、「情報処理技術者試験」自体や、合格者の地位向上につながらず、『こんな試験合格していても仕事には関係ない』という声がまかり通ることにもつながっている。
IT系・情報系に真の意味での「資格」できれば「国家資格」が誕生することを願いたい。
IT系の人は、なぜか自分のことをさかんに「エンジニア」と呼称するが、世の中には非IT系にも「エンジニア」「技術者」がたくさんいる。
非IT系の勉強をすると、本当にそれがわかる。
本当に勉強は大切だと思う。
まさかの電験三種科目合格…来年度に向けて始動!
まさかの電験三種科目合格…来年度に向けて始動!
昨年より、通信関連(有線/無線)の国家資格に挑戦しはじめ、今年は電気系の国家資格にも挑戦している。
これまでに取得した国家資格には以下のようなものがある。
現在、第一種電気工事士には挑戦中である。
そして、実は、準備不足も甚だしいものだったが、「電験三種」(第三種電気主任技術者試験)も、受けるだけは受けた。
電験3種に合格するためには1000時間もの学習が必要だという声もあり、とても合格するとは思えなかった。
現に、受験してみて、付け焼き刃ではとてもかなわないと実感した。
受験した感触では4科目全滅だと思っていた。…なので、自己採点もしなかった。
(法規だけは直前に集中的に勉強したが、本当に付け焼き刃ではかなわないことを実感した)
先日、試験センターから試験結果通知が届いた。
そうしたら…。
「理論」のみ科目合格。
まさかの科目合格である。
しかも、最も計算問題が多い「理論」
これは、合格できるかもしれないチャンスと捉えるべきだろう。
来年度は本気で狙わなければ……!
昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかも…
電験の「理論」科目は、多くの受験生の前に立ちはだかる壁である。
電験3種は、選択形式とはいえ、「5択問題」である。
4択問題と5択問題との難易度の差は、受験してみればわかる。
昨年からの電子通信系の国家資格受験の積み重ねが地味に効いたのかもしれない。
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業界も昔に比べて実は衰退しているのかもしれない。
資格試験の価値
資格試験の価値
昨日、「第一種電気工事士」の筆記試験を受験してきた。
平成30年度なので、平成最後の電気工事士試験となると思われる。
私は本業が情報システム開発/保守(SE)なので、電気系は実務経験が無い。
それでも、将来的なこともいろいろ考えて、本業以外の分野を積極的に勉強している。
先日、免状を取得できた「第二種電気工事士」の受験は、本当にたいへんだった。
電気工事士の試験の本領は何と言っても二次試験にあたる「技能試験」である。
実際に強電の世界で必要最低限、身に染み込ませて知っておかないといけないような注意点を、技能試験を取得する過程で、「身体で覚えさせる」というしくみになっている。
本当に、この資格試験のしくみはよくできていると思う。
過去問で対策ができる試験にも充分に価値はある
昨日受験した「第一種電気工事士」の筆記試験への対策では、自分ながら、そうとう猛勉強した。
直前にはもっぱら過去問題の繰り返しになる。
電気工事士の筆記試験は、過去10年間の問題をやりこんでおけば、まず合格できる内容である。
過去問で対策できる試験を、受験もしないのに侮る言説があるが、それは違うと思う。
当然のことだが、どのような試験でも、「一夜漬け」または「ほとんど無勉強」で合格できるものなど無い。
(仮にそのような試験が存在するとしたら、その資格試験には本当に価値が無い。(いわゆる民間の資格商法などの試験はこういうものだろうが…))
どのような試験でも、事前にしっかり対策を行った場合、つまり勉強をした場合にのみ、合格の目が出てくる。
過去問題で対策可能な試験が低く見られがちだが、過去問を解く、または覚えるにしても、前提知識は必要なのである。
人間の頭脳は機械とは異なる。前提知識もなく問題集の丸暗記など、やろうとしてもそうそうできるものではない。
それに、資格を与える側の思惑として、敢えて同じような問題を繰り返し出すという点もある。
上記の電気工事士筆記試験に関しては、「電気のことを深く知る」ことよりも、「現場技術者として絶対に把握しておかなければならない注意点を押さえる」ことを重要視していると思える。
強電の工事の世界では、設備や工事の取扱を間違えると人命に関わるためである。
故に過去問で対策できる資格にも一定の価値はある。
無論、例えば電気主任技術者試験(電験)など、過去問では歯が立たない、真の理解度が求められる資格試験もあるし、それには、より一層の高い価値がある。
情報系(IT系)の試験のほとんどが単なる知識認定であることが悲しい
資格資格と言っても、情報処理技術者試験のような国家試験でも、民間のオラクルマスターでも、実のところ、「その資格を持っていないと業務ができないという強制力が無い」ので、本当の意味では「資格」とは言えない。
この事実が、試験自体の様々な点での価値低下、試験内容や質の低下、現場エンジニアたちの試験離れの悪循環につながっていると思われる。(注1)
この事実が歯がゆいし、悲しいと思う。
前述した電気系の「資格」は、本当の「資格」なので、その免状を保有していないと業務ができない。
そして、そういう背景もあるためか、資格取得までに必要となる学習プロセスがしっかり根付いていて、電気工事士などは頭でというよりも身体に染み込ませるような「しくみ」になっている。
一方で、IT系は、下手をすると、ずぶの素人が「私は経験豊かなシステムエンジニアです」と名乗っても、それが本当かどうかチェックするしくみがない。(注2)
現に、経歴を詐称することが、中小IT企業の派遣の世界では常態化している面もある。
書店に並んでいる本や、インターネットにおいて、「少しでもプログラミングができれば即エンジニアと名乗れる」と書かれている風潮も、そういった背景と無関係ではないだろう。
IT系と電気系とでは、仕事内容も何もかも異なるので、一様に比較はできないが、本当に歯がゆい現実である。
(注1)それでもIT系の試験は人気自体はあり、毎年何万人も受験している。IT系の仕事自体、参入しやすい側面があるからだろう。
(注2)ここでやはり「参考」となるのは職歴以外では「国家試験」「公的試験」の合格歴だと思う。
「怒り」の感情を否定するな!
「怒り」の感情を否定するな!
書店をめぐるのが昔から好きである。
近年はオンラインで書籍を購入することが増えたが、オンラインでも書籍を検索するのが好きである。
近年、売れている本を見るに、ある傾向が見える。
(1)感情的にならないようにしよう
(2)怒らないようにしよう
(3)アホと戦って時間を無駄にしないようにしよう
人間の「喜怒哀楽」のうち、特に「怒」の部分を抑えたほうが良いという風潮にあふれている。
自分の感情を下手に抑え込むと病んでしまうこともある
私は、下記の言葉があまり好きではない。
「怒ったら負け」
確かに、理性を失って、怒りの感情に支配されてしまうと、いろいろと良くない。
それはそう思う。
しかし、一方で、
タイミングよく「怒れない」ことで損をする
という経験を、いままでしてきた。
そして、そういう人をたくさん見てきた。
「怒り」の感情をいけないものだと思い込み、自己嫌悪や、自己肯定感の否定につながってしまうこともある。
「怒り」の感情は、そんなにいけないものなのだろうか。
「怒り」の感情は、喜怒哀楽といった人間の感情の基本的なものである。
「腹が立ったら怒って良い」
「腹が立ったら怒って良い」
本当にそう思う。
自分の心に発生する感情にウソをついてはいけない。
- 作者: 和田秀樹
- 出版社/メーカー: 新講社
- 発売日: 2011/03/07
- メディア: 単行本
- 購入: 1人 クリック: 1回
- この商品を含むブログ (1件) を見る
腹が立ったら怒りなさい (WIDE SHINSHO182)(新講社ワイド新書)
- 作者: 和田秀樹
- 出版社/メーカー: 新講社
- 発売日: 2012/12/21
- メディア: 単行本
- この商品を含むブログ (1件) を見る
企業システムの真髄はバッチ処理にあり!
企業システムの真髄はバッチ処理にあり!
「基幹系業務システムの真髄」は夜間などにユーザーから見えないところ(バックエンド)で稼働しているバッチ処理にある。
銀行や保険会社などの金融機関における様々なお金の計算もバッチ処理で行われている。
製造業における生産数と在庫数と売上数の帳尻合わせもバッチ処理で行われている。
公的機関の様々な受付業務からはじまる工程管理の整合を取る処理やシステム間連けいもバッチ処理で行われている。
官公庁における戸籍などの個人情報のマスター化もバッチ処理で行われている。
あらゆる企業の毎月の経理精算や給与支払いもバッチ処理で行われている。
上に挙げたのはほんの一例にすぎない。
どれも非常に地味な印象を受ける処理である。
まず華やかな印象はない。クリエイティブな印象もまったくない。
しかし、これらのシステム処理が、ある日突然、停止したり、消えてなくなってしまったりすると、その企業そのものの活動のみならず、広く社会一般にまで悪影響を与えてしまう。
そういったシステムこそが「基幹系システム」なのであり、「プラント型IT」なのである。
Web系などの人の目につく部分(フロントエンド)のシステムは、「ツール系IT」であり、まるごとどこからか買ってきて入れ替えても、その企業の存続には影響しない。
しかし、バックエンドシステムのような「プラント型IT」は、その企業の競争力を生み出している業務そのものと一体化している。
そのため、簡単によそから買ってきて入れ替えることはできない。
そして、その「プラント型IT」の更に根幹部分を担っているのが、バッチ処理なのである。
例えばamazonなどにおいて、「バッチ処理」に関する書籍を検索してみても、ひっかかるのはほとんどが「Windows(MS-DOS)コマンドプロンプトにおけるバッチファイル」に関する書籍ばかりである。
こんな情勢では、世の中の若手のITエンジニアにとって、上記のようなバッチ処理の設計が、縁遠いものとなってしまっているという点も、肯ける部分がある。
睡眠時に脳がフル稼働しているのと同じく社会のバックグラウンドではバッチ処理がフル稼働している
近年の脳科学において、記憶の定着に、睡眠が重要な役割を果たしていることがわかってきた。
世の中のバッチ処理も、脳における睡眠と同じような存在なのである。
やがて迫りくる様々な基幹系システムのブラックボックス化
情報系の学校の授業や、IT企業の新人研修において、画面を持たないバックエンド処理であるバッチ処理について、ろくに教えないということが当たり前になって、かなり経過した。
「プログラミングは楽しい」ということばかりを、ネットや書籍では喧伝しようとしている。
それを否定するつもりはない。
しかし、一方では、社会を支えている地味なシステムが、人知れずバッチ処理として動いている。
「クリエイティブ」とか、「楽しさ」とか、そういった感覚とは、およそ無縁のシステムである。
こういったシステムの担い手も、本当ならば、育成しなければならない。
だが、多くの人々は、バッチ処理システムの存在すら知らないのである。
情報システムは、工業製品としての色合いも強く持っている。
しかしながら、何故かIT産業の有名人たちは、その事実から目を背けている。
やがて、社会を裏側で支えている基幹系システムの保守という地味な仕事の担い手が、圧倒的に足らなくなる時代がやってくるだろう。
そのときになって、後悔しても、すでに遅いのだ。
第二種電気工事士に合格はかなりうれしい
第二種電気工事士に合格はかなりうれしい
この5月から7月のプライベート時間のかなりを費やして受験した「第二種電気工事士」(筆記/技能)。
正式な合格通知が届いた。
正直、ものすごくうれしい。そしてホッとした。
この試験の本質は技能試験(実技)にある。
強電の仕事で最低限知らなければならない必須知識が技能試験の対策をやることで身につく。
そういう「しくみ」になっている。
うまいことできていると思う。
これで、一応、「IT」「弱電(無線通信)」「弱電(有線通信)」「強電」の4分野について国家資格を有したことになる。
(ITは、国家資格(免許)というより国家認定に過ぎないことは以前に書いたとおり)
もっとも、それぞれの資格の中では最高位ではないのだけれど…。(昔のものもあるし…)
この中で、実技試験が課せられているのは、強電の電気工事士だけである。
強電の世界では知識が無いことが人命に関わるためである。
技能試験は専門家に習ったほうが良い
合格率のデータだけを見ると、第二種電気工事士は、さして難しい試験ではないように思えてしまう。
現に昨年の私は、そう思ってしまった。それで不合格だったわけだが…。
しかし、工事作業を本業としているような人や、電気工学科などで実習をしたことがある人ではない限り、独学で挑戦するのはおすすめしない。
普通のド素人が、独学で突破できる試験ではない。
電気工事の基本単位作業を、頭で考えることなく「身体で覚えている」くらいのレベルに持っていかないと、なかなか合格は難しい。
なぜなら、本番での試験の時間がとても短いからだ。
専門家である講師に実習を教えてもらうことで、お手本を生で見ることができるし、本当に基本中の基本の疑問も聞くことができる。
電気工事士もそうだが、電気関係の知識では、本当に独学よりも先生に教わるほうが良いことを実感している。
ただし、まったくの無知識状態で先生に教わるのは、非効率である。
新人研修でも、教えたことのほとんどが残らない。
それは、まったくの下地がない状態では、いくら知識を頭に入れようとしても入らないからである。
その意味では、電気工事士の技能試験対策については、私は、あえて2回以上の講習を受けることをおすすめしたい。
1回めの講習で、電気工事士の基本的な作業を体験し、頭に回路を作る。
2回めの講習で、一度できた回路に改めて知識(体で覚える知識も含む)を、再度頭に入れる。
ほっとしたのは、「これで第一種電気工事士にもチャレンジできる」と思ったからでもある。
第一種にも挑戦するつもりでいる。
みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに
みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに
以下のような流言がいつまで経っても消えない。
DOA (Data Oriented Approach) で新たに開発すれば生産性/保守性が高まる
オブジェクト指向言語で新たに開発すれば生産性/保守性が高まる
現行システムの維持に費用がかかるのは上記を採用していないからだ
いかにも、当該のユーザー企業の外側にいる(当然現行システムの中身など知らないし興味もない)コンサルタント業の人が言いそうなことではある。
そして、未だに大企業や官公庁といった大規模ユーザーで決裁権を持っている「偉い人達」は、そもそもITには疎い者ばかりで、システム開発のことなんて「ド素人」である。
日本企業には、こうした「偉い人達」の側近には「イエスマン」しかいない。
上記のようなことを鵜呑みにして、様々な思惑も絡んで、難易度の高い大規模システム開発がくりかえされ、その多くが何らかの失敗をしでかして、欠陥の多いシステムが作られていく。
- DOA (Data Oriented Approach) で新たに開発すれば生産性/保守性が高まる?
現行システムが開発されて四半世紀。すでにOracleなどのRDBを中心に使用して回っている。
RDBを使用するだけでも、ある意味強制的に、部分的にはDOAを実現している。
逆にRDBの機能に頼り切ったシステムでは、保守性という面で問題が生じることは、もうみんなが知っている。
- オブジェクト指向言語で新たに開発すれば生産性/保守性が高まる?
こんなことを言うと一部から反論されそうではあるが、敢えて正直に言うと、オブジェクト指向と生産性や保守性は、直接的には関係性は無いと思っている。
要は、生産性や保守性を意識したシステム設計を、ちゃんとするか、しないか、それだけである。
そこに、「オブジェクト指向か否か」はあまり問題にはならない。
オブジェクト指向言語が実装としてやっていることを、ちゃんとコンピュータのしくみのうえで説明できる人が、そのプロジェクトに何人いるだろうか。
例えば「継承」がやっていることが、実メモリ空間の中でどう処理されているのか。
そういったことを理解していない人たちが設計してしまうと、結局、生産性や保守性が低いシステムができあがってしまう。
- 現行システムの維持に費用がかかるのは上記を採用していないからだ?
以前にも下記の記事で少し紹介したように、特に基幹系システムというものは、その企業の競争力を生み出す業務そのものと一体化した、「プラント型IT」と呼べるものである。
確かに実際のプラントと同様に、全体のアーキテクチャーが古いままであると、時代の流れに追従できないという問題も出てくるだろう。
しかし、それは、上述のような開発手法などの問題とは、また次元が異なる問題である。
上でも言ったが、どのように設計を行うか、という、設計スキルに帰着してしまうのである。
しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない
しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない。
問題の本質はそういう部分ではないことを知っているから。
近年、ようやく、Java言語の世界において、共通化がされてこなかった「バッチ処理」について、共通的なフレームワークの必要性が叫ばれるようになった。
少なくとも、日本の基幹系システムの心臓部は、すべてバッチ処理の部分に存在している。
これだって、中身を見ると、なんの真新しいことはない。ごくごく当たり前のことを標準化しただけである。
「自分の無知を知る」ことの大切さ
「自分の無知を知る」ことの大切さ
最近は試験勉強が忙しく、更新が停滞している。
「第二種電気工事士」の本番は何と言っても「技能試験」の方だということを、最近、身を持って体験している。
普段、ドライバーなどの工具もろくに使うことがない生活をしている者にとっては、ごくごく基本的な電工の実技も、たいへんだ。最初はものすごくつらい。
でも、強電を扱う者としての最低限の注意点などが、頭というより、手で覚えられるようになっている点がすごい。
あと一週間なので、山場である。
7月に入って、いろんな職場では、新入社員が現場に配属される季節になっている。
この季節になると、いつも、
「自分の無知を知る」ことの大切さ
を考える。
「わかっています」「知っています」と言う人にどうやって先を目指させるようにするのか
人に仕事などを教えることがよくある。
やはり、その仕事を長年やっている人の方が、いざというときの引き出しの数や、知識の深さが違っている場合が多い。
その意味では、入社数年の若手や、異業界からの転職者の人は、その道で長い人に比較すると、いろいろと「わかっていない」場合が多い。
しかし、プライドが高い者などは、「わかっています」と言う。
さらに精神的にこじれている場合、「わかっていない」ことから目をそむけ、自分がこれまで得意としてきた領域にこだわり過ぎて、まったく新しいことを覚えようとしない者もいる。
若手で、「本当は深くはわかっていない」のに、それに気づかない者ならば、「自分が実はまだまだわかっていないんだ」という事実に、気付きさえすれば、成長できる。
なまじ、社会経験がある程度ある人の場合、プライドのせいで「わかっていない」ことから目をそむけてしまう。
これだと成長する機会をどんどん失っていくだろう。
「自分の無知を知る」
これは本当に大切である。
私はいま、電工試験に集中しようとしているが、こっそり電験三種(第三種電気主任技術者)の勉強もやっている。
電験三種がいかに難しいか、それを最近、少しだけ実感してきた。
正直、合格できる気がしない。
でも、こういう実感は大切にしたいとも思う。
世の中には土日でも勉学に励んで頑張っている人が多くいるのだ。
見習わねば。
第二種電気工事士の技能試験にむけて
第二種電気工事士の技能試験にむけて
ネット上に多くある「資格ランキング」とか「資格難易度」などの情報は、実はとてもいい加減である。
はっきり言うなら、ウソばかりだと思える。
その記事を書いている人間が、実際に受験勉強をして試験を受けた訳ではなく、
「受験者数」、「合格者数」、「合格率」、などという、ふわっとした情報だけから判断している。
そういう情報は信用できない。
(企業の人事の人などもこういう情報を鵜呑みにしないでほしいものである)
第二種電気工事士(2電工)などは、そうした「資格難易度」のネット情報では、「初心者向き」で、「簡単」な資格と書かれている。
筆記試験は、そこまで難易度が高いとは言えないだろう。
しかし、工事士の試験なので、技能試験がある。
これは本当に簡単な試験なのだろうか。
少なくとも、7月の本試験に向けて、かなり頑張って「練習」を行わない限り、合格はできないだろう。
本職がシステムエンジニアの私にとっては、「工具」を使って「電線」をむいたり切ったり接続したり、という作業は、まったくもって未知の世界。
この試験を簡単だとはとても言えない。
準備がたいへんなこの試験。
準備がたいへんなだけに、合格したいものである。
勉強が多忙なので、記事も短めであります。