「自分の無知を知る」ことの大切さ
「自分の無知を知る」ことの大切さ
最近は試験勉強が忙しく、更新が停滞している。
「第二種電気工事士」の本番は何と言っても「技能試験」の方だということを、最近、身を持って体験している。
普段、ドライバーなどの工具もろくに使うことがない生活をしている者にとっては、ごくごく基本的な電工の実技も、たいへんだ。最初はものすごくつらい。
でも、強電を扱う者としての最低限の注意点などが、頭というより、手で覚えられるようになっている点がすごい。
あと一週間なので、山場である。
７月に入って、いろんな職場では、新入社員が現場に配属される季節になっている。
この季節になると、いつも、
「自分の無知を知る」ことの大切さ
を考える。
「わかっています」「知っています」と言う人にどうやって先を目指させるようにするのか
人に仕事などを教えることがよくある。
やはり、その仕事を長年やっている人の方が、いざというときの引き出しの数や、知識の深さが違っている場合が多い。
その意味では、入社数年の若手や、異業界からの転職者の人は、その道で長い人に比較すると、いろいろと「わかっていない」場合が多い。
しかし、プライドが高い者などは、「わかっています」と言う。
さらに精神的にこじれている場合、「わかっていない」ことから目をそむけ、自分がこれまで得意としてきた領域にこだわり過ぎて、まったく新しいことを覚えようとしない者もいる。
若手で、「本当は深くはわかっていない」のに、それに気づかない者ならば、「自分が実はまだまだわかっていないんだ」という事実に、気付きさえすれば、成長できる。
なまじ、社会経験がある程度ある人の場合、プライドのせいで「わかっていない」ことから目をそむけてしまう。
これだと成長する機会をどんどん失っていくだろう。
「自分の無知を知る」
これは本当に大切である。
私はいま、電工試験に集中しようとしているが、こっそり電験三種（第三種電気主任技術者）の勉強もやっている。
電験三種がいかに難しいか、それを最近、少しだけ実感してきた。
正直、合格できる気がしない。
でも、こういう実感は大切にしたいとも思う。
世の中には土日でも勉学に励んで頑張っている人が多くいるのだ。
見習わねば。
第二種電気工事士の技能試験にむけて
第二種電気工事士の技能試験にむけて
ネット上に多くある「資格ランキング」とか「資格難易度」などの情報は、実はとてもいい加減である。
はっきり言うなら、ウソばかりだと思える。
その記事を書いている人間が、実際に受験勉強をして試験を受けた訳ではなく、
「受験者数」、「合格者数」、「合格率」、などという、ふわっとした情報だけから判断している。
そういう情報は信用できない。
（企業の人事の人などもこういう情報を鵜呑みにしないでほしいものである）
第二種電気工事士（２電工）などは、そうした「資格難易度」のネット情報では、「初心者向き」で、「簡単」な資格と書かれている。
筆記試験は、そこまで難易度が高いとは言えないだろう。
しかし、工事士の試験なので、技能試験がある。
これは本当に簡単な試験なのだろうか。
少なくとも、７月の本試験に向けて、かなり頑張って「練習」を行わない限り、合格はできないだろう。
本職がシステムエンジニアの私にとっては、「工具」を使って「電線」をむいたり切ったり接続したり、という作業は、まったくもって未知の世界。
この試験を簡単だとはとても言えない。
準備がたいへんなこの試験。
準備がたいへんなだけに、合格したいものである。
勉強が多忙なので、記事も短めであります。
第二種電気工事士筆記試験を受けてきた(実は二度目)
第二種電気工事士筆記試験を受けてきた(実は二度目)
先週は、弱電系(通信系)の「工事担任者試験」があり、
本日は、強電系の登竜門たる「第二種電気工事士」の筆記試験だった。
ここ最近の土日では、受験対策をしていたため、この記事も久しぶりの更新となった。
昨年までは、上期か下期のいずれか一回しか受験できなかった。つまり上期と下期があっても事実上、一年に一度しか受験機会がない試験だった。
今年から、上期と下期、どちらも受験できるようになった。
それだけ、需要もある試験なのだろう。
しかし、近年は難化傾向があると聞いている。
実は昨年、私は初めてこの試験を受けた。結果はちょうど５０点で不合格。
電気系に関する下地の浅さと、試験対策が全く足りていなかった。
普段の自分の仕事で関わっている分野とは異なる領域の勉強の難しさを知った。
この一年間で、電気系に関する知識の下地は、かなり作って来られたと思う。
試験対策は、どうしても日々の疲れで、なかなかできなかったが、昨年とは下地の部分がまったく違ったためか、本日の筆記試験は、まぁ、なんとか通過した感触はある。
さて、問題は約一ヶ月後に控えている、「技能試験」（実技）である。
これは本当に試験対策をしないと合格できないだろう。
さすがに規模が大きな国家試験はいろいろ違う
昨年もそうだったけれど、試験地に行く道すがら、いろんな電気関係の教習所や出版社の関係者が、チラシを配っている。
消しゴムや、シャープペンシルをくれる会社もある。（オーム社さんシャーペンありがとう）
本日は６月初旬にしては猛暑だった。
皆様、お疲れ様でした。
いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫
いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫
「会議」とか「打ち合わせ」とか、名前はそれぞれで、何でも良いのだが、とにかく、人が集まったからには、何かしらの目的がある。
情報の伝達とその結果（連絡）
知恵の出し合いと何らかの結果（検討）
意識や認識の確認とその結果（確認）
プロジェクトにおいては、規模が大きくなればなるほど、コミュニケーションの数が爆発的に増大する。
結果として、打ち合わせが多くなる。
そして、本来、打ち合わせとは、上記の三種類に大別できる。
「連絡」「検討」「確認」の三種類である。
ちゃんと機能した打ち合わせであれば、必ず何らかの「結果」が存在する。
そして、参加者は各々で、その「結果」を持ち帰り、自チームや自社メンバーに伝達する役割を担う。
この、「結果」を持ち帰り、自チームや自社メンバーに伝達する、ということができていないプロジェクトが多い。
プロジェクトの規模が大きくなればなるほど、本来は、上記の打ち合わせひとつひとつの重要度も増大する。
しかし、現実としては、大規模プロジェクトほど、打ち合わせがうまく機能しない。
何故か。
皆が忙しいことを言い訳にして、モノを書かないからだ。
メモでもいいから必ず書きものにして相手に渡せ！
うまく機能しない打ち合わせで、最もよくあるのが、
すべて口頭で情報が伝えられ、書きものとして結果が残らない
という状況である。
情報を伝えた方は、口頭で言ったので「伝えた」気分になっている。
情報を受け止めた方は、口頭で言われたことを一応は理解して「わかりました」と言う。
しかし、情報を受け止めた方は、その後になって、自分のノートの不完全なメモから、「どう決まったんだっけ？」という状態に陥る。
また、本来は正しい情報を自チームや自社メンバーにフィードバックしないといけないのだが、自分のノートの不完全なメモしか残っていないので、また、テキストにまとめる手間も惜しいので、またもや口頭でのフィードバックとなる。
口頭で伝えられたメンバーは、非常に劣化した情報が伝えられたこととなり、あいまいな情報がますますあいまいになっていく。
フィードバックされるならまだ良い方で、忙しさやメンバーとの時間が合わなかったりして、フィードバックすら行われない状況にもなる。
打ち合わせで口頭で言う予定のことは、メモでも良いので書きものにして渡す。
打ち合わせに参加した者は、その書きものを持って帰り、「こんな事をいわれた」と、その書きものを流せば良い。
たった、これだけのことで、情報の伝達不全は、かなり解消できるのである。
「IoT」や「AI」という名の本を読むくらいなら「情報工学」「電子工学」の本を読むほうが有益だと思う
「IoT」や「AI」という名の本を読むくらいなら「情報工学」「電子工学」の本を読むほうが有益だと思う
IoT (モノのインターネット) , AI (人工知能)
いま書店に行くと、これらのキーワードをタイトルに使った本であふれているように見える。
書店だけではなく、企業の経営者なども、こうしたキーワードを盛んに使用している感がある。
もちろん一部には本物の専門家や有識者が、そういった本を書かれていたり、そういう言葉を使ったりしているのだろう。
しかし、大半の場合、「その筋の専門家ではない人」、「充分な知識を持っていない人」が、上記のような本を書いていたり、言ったりしているように思える。
言っては悪いが、「時流に乗っているだけ」の人もいるように見える。
どれもかなり昔からあった概念であり、その延長線上にある
IoT (モノのインターネット)
これは、１９９０年代に盛んに言われた「情報化社会」や、２０００年代に盛んに言われた「ユビキタス社会」からの延長線上にある。
AI (人工知能)
これも、古くは「Lisp言語」の成り立ちの頃から研究されてきたものであり、エキスパートシステムの歴史を見れば、いまにはじまったものではない。
ビッグデータと関連付けて語られることが多いのも、膨大な物証がそろってはじめて実現できる理論も多いからである。
そのビッグデータの基盤にあるものは、データベースであったり、ネットワークであったり、従来のコンピュータシステム工学である。
技術領域のマッピング図を作成してみた
(技術領域マッピング図) Copyright FUJIWARA775
IoT ( モノのインターネット ) とは、こに示している技術領域のすべてに関係している。
AI ( 人工知能 ) も基礎は既存の情報工学のうえに立脚している。
これが私の自論である。
いまおきていることは革命ではない。
いまの時代、既存の知識や概念が完全に塗り替えられるようなことは発生しづらく、いままでの積み重ねのうえに不可能だったことが可能になっただけなのである。
上記の図を見ればわかるように、IoT、AI、などは、どちらも既存の技術領域を抜きに語ることはできないはずなのである。
基本に立ち帰るほうがかえって理解には近道となる
何事も、基本、基礎から地道に学習することが大切であると思う。
いまの時流に乗ったような、「IoT」や「AI」という名の本を読むくらいなら、「情報工学」や「電子工学」、「無線工学」などの本を読むほうが、よっぽど有益だと思う。
IoTと名が付いた本を読んでわかった気になるくらいなら、電気工学、電子工学、無線工学、情報工学（コンピュータ工学）の基礎の学習書を読んだ方が理解は進むと思う。急がば回れではないが、IoT本の大半は中身が薄くて価値が無い。
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2018年5月3日
本当に理解できるまでには時間がかかるように脳はできている(勉強論)
本当に理解できるまでには時間がかかるように脳はできている(勉強論)
脳科学の本を読んで知ったことである。
脳において記憶に重要な役目を担っている器官が「海馬」である。
勉強したときの記憶はまず、とりあえず「海馬」に格納される。
その後、「短期記憶」として処理するか、「長期記憶」として「大脳皮質」に送るか、峻別される。
ここで「長期記憶」とされるか否かは「生物として生きていくうえで重要な情報かどうか」で決められる。
なので、「こういう臭いの食物は食べない方が良い」などという情報は、長期記憶になりやすい。
一方で、勉強した情報などは、生物としての生き死ににとってはどうでも良い情報なので、長期記憶にはなりにくい。
勉強をしたり、研修や講義を受けたりして、「覚えた」「わかった」「理解した」と思ったとき、その情報はまだ「海馬」にある。
そのままでは「短期記憶」として処理されて、忘れてしまう。
海馬に留まる期間は最大でも一カ月。それを過ぎると記憶は消えてしまう。
脳は、そのようにできている。
脳は、学習したことを「忘れる」ようにできている。
では、忘れないようにする方法はないのだろうか。
ある。
それは、「覚えた」「わかった」「理解した」と思ったことでも、再度、「覚える」「わかる」「理解する」を行うということ。
これを「くりかえし行う」という地道な努力しかない。
それをすることで、「海馬」にある記憶が「重要な情報である」と脳をだますことになり、「長期記憶」になりやすくなる。
レミニセンス効果 (時間が経ったほうが記憶が定着する)
レミニセンスという言葉がある。
「レミニセンス効果」とも言われる。
脳は睡眠をとっている時間に「夢」をみる。そのほとんどは覚醒した時点で覚えていないが、ほぼ必ずといって良いくらい脳は「夢」をみているそうである。
その「夢」をみているときに、脳では「記憶の整理」を行っている。データベースの索引を再作成しているようなイメージだろうか。
いままで、いくら本を読んでも「わかった」という感触がつかめなかったことが、ある日、ふと「わかってしまう」ことがある。
いままで、他人が書いた昔のソースプログラムを追いかけていても、なかなか意味がわからなかったものが、ある日、ふと「わかってしまう」ことがある。
これが、「レミニセンス効果」である。
（これは、当然のことながら、一度以上、しっかりと「わかろう」という努力をして学習するということが前提となる）
一夜漬けが最も時間をムダにしている勉強法である
上記の考え方からすると、何事も「早いうちからはじめる」ことが重要であると言える。
そして、「本当に理解できるまでには時間がかかるように脳はできている」と言える。
脳は大量の情報を一気に学習することには向いていない。
例えば一夜漬け勉強のような、短期間での詰め込み学習は、結果として「短期記憶」として忘れてしまう確率が高くなる。また、睡眠時間を削ってしまうことで、「レミニセンス効果」も働かない。
勉強をしっかりと時間をとって行った人は、それだけ深い理解をしている。
自分も心がけていきたいと思う。
「しくみマニア」からみたコンピュータ関連の良書とは
「しくみマニア」からみたコンピュータ関連の良書とは
IT業界には、ITを専門に学んでこなかった人も多数、入ってくる。
IT業界で必要となるスキルや知識は、IT系に限らない。例えばプロジェクトの中でうまく立ち回るとか、そういった場面には、IT専門知識などよりも、もっと基本的なコミュニケーションスキルが必須である。
なので、ITの素人が入ってくること自体は、むしろ必要なことでもある。
しかし、IT業界で仕事をするうえでは、そうはいってもIT系の基礎的な知識が、本来なら必要である。
基礎の基礎の部分は、いまや会社の新入社員研修では教えてくれない。（まぁ、昔からそうではあったが）
何故か。
当座の仕事をこなすだけであれば、IT系の基礎の基礎、つまり「コンピュータのしくみ」を知らなくてもこなせるからである。
逆に、とにかく何らかの「プログラミング」ができないと、IT業界では仕事に支障が出てしまう。
これはつまり、「コンピュータのしくみ」を全部は知らなくても「プログラミング」はできてしまう、ということである。
仮にもIT業界に数十年もいるというのに、「コンパイラ」や「リンカー」の動作内容を説明できない人。
JavaVM（Java仮想マシン）の動作内容を説明できない人。
こんな人は、実に多い。(エンジニアという職種なのに！)
IT系のそれなりの規模の企業でも、いわゆる文系(※1)の新卒者を、２ヶ月間だけプログラミング研修を受けさせた後に、現場に送り込む。
(※1)私は本来は「文系」「理系」という区分で人を語ることが大嫌いであるが。
２ヶ月間の研修で、「コンピュータのしくみ」がきちんと理解できるだろうか。
答えは、Noである。（人にもよるがほとんどはNo）
学校でしっかり学ぶ場合を想定しても最低６ヶ月は要する内容だからである。それを研修ではたった数日間から数週間しかかけない。これでは「研修の内容だけ」からは絶対に本当の理解はできない。
一方で、
２ヶ月間の研修で、「プログラミング」ができるようになるだろうか。
これも、本当は、Noである。
だが、上述したように、何らかの「プログラミング」ができないと、IT業界では仕事に支障が出てしまう。
だから、とにかく形だけでも「プログラミング」だけはできるという体(てい)にするのである。
「プログラミング」も、本来なら、学校でしっかり学ぶ場合を想定しても最低６ヶ月は要する内容である。しかし、本来ならアルゴリズムなどの基礎から積み上げることが必要であるが、「まずは動かす」ことを主体に学習を進める。統合開発環境（IDE）の使い方から簡単なプログラムを動作させることを優先する。
私は、本来は以下の２点の学習は不可分であるという持論なのだが、賛同してくれる人は少ない。
コンピュータのしくみ(動作原理)の基礎
プログラミング(アルゴリズム含む)の基礎
本当の基礎を学習しないままプロになる業界はIT業界だけではない
本当の基礎を学習しないままプロになる業界はIT業界だけではない。
これは自分自身、電気関係の勉強や国家資格を取得したりした経験から言える。
例えば「電気工事士」が、その基礎分野である「電磁気学」をちゃんと理解しているかというと、必ずしもそうではない。むしろ理解していない人の方が多い。
電気の資格の教本に出てくる「原子のモデル」は、いわゆる「惑星モデル」である。
「惑星モデル」は、既に数十年も前に「量子論」によって否定された古典モデルである。
だが、電気回路を計算する上では、原子のモデルを「惑星モデル」で理解していても何の問題もないのである。
しかし、私は「しくみ」を正しく理解することにこだわる。
「しくみマニア」なのである。
「しくみマニア」が良書と思えるコンピュータのしくみの教科書
オーム社 図解 コンピュータ概論［ハードウェア］（改訂4版）
オーム社 図解 コンピュータ概論［ハードウェア］（改訂4版）
オーム社 図解 コンピュータ概論［ソフトウェア・通信ネットワーク］（改訂4版）
オーム社 図解 コンピュータ概論［ソフトウェア・通信ネットワーク］（改訂4版）
この二冊は姉妹本である。
また、「概論」とあるように、内容的にはそんなに高度ではない。
それでも、情報処理の入口の教科書としては、そこそこ網羅性もあり、良書であると思う。
この二冊の内容をきちんと学校の講義形式で学習するなら、６ヶ月はかかるだろう。
もしも、IT基礎をあまり学習しないまま、新入社員研修に放り込まれた自覚がある人や、ちゃんと基礎を理解したいと思う人は、手元においておくのも悪くないと思う。
基礎のふりかえりにも使えると思う。
Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほどわかりやすい言葉だ
Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほどわかりやすい言葉だ
三年間も病気療養のために仕事を離れていた私が、現場に復帰して、１年半あまり。
歳を食った平社員にすぎない立場ながら、別に変に守りに入る必要もなく、立場を超えての言動を割と許容する社風なこともあり(※1)、これまで好きに仕事をさせてもらっていた。
昨年度は、数十人月規模のプロジェクトを実質的に全部主導的(実質リーダー)に回した。
(※1)IT系はどこもそうだと思う。何故ならば、結局は「できる人がやる」しかなくなるのが「システム開発プロジェクト」だから。
新年度に入り、数年前から進行中の大規模プロジェクトに「現行/既存システムを知る有識者」として参画することを命じられ、また仕事の環境が変わり始めた。
この５月の連休明けからは、一気に本腰を入れて参画することを余儀なくされそうである。
大規模プロジェクト「あるある」を垣間見る
連休直前の日。臨時のプロジェクト全体会議をやるから出ろ言われ、参加してみた。
大規模プロジェクト「あるある」を垣間見た。
PM,PMO側が発表する全体方針（スケジュールや体制）の受け止め方がチームや会社によってバラバラ
現場を必死に回しても回しきれずにいる若手リーダーが困惑しつつ冷めている
各社リーダークラスは必死に高稼働状態のようだが末端クラスへの意識/知識の展開ができていない
みんな、各個人を見ると、必死で頑張っている。
それでも、「深刻な人手不足」だとリーダーは悲鳴を挙げる。
『会社のＩＴはエンジニアに任せるな！(白川克著)』を手にとってみる
プロジェクトに対し、何か良い貢献ができないものかと考えて、
という本が非常に評判が良いようだったので、読み始めた。
私は基本的にコンサルタントのお仕事はあまり良い印象を持っていない。何故ならば、世の中の多くのコンサルタントの方々は、無知なユーザー企業の経営者たちを、決して良い方向に「教育」してはくれないからである。
しかし、この本は、まさに「無知なユーザー企業の経営者たち」を「教育」するためのことが書かれているようである。
Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほど
この著者の言葉によると、ITには大きく「ツール型IT」と「プラント型IT」があるという。
「プラント型IT」は、その企業の固有業務そのものであり、他に類を見ない知見のカタマリである。
まさに、基幹系業務システムのことである。
なるほど、こういう言い方もあるのだな。感心した。なるほどわかりやすい言葉だ。広めたい。
IT系、もっと言うとシステム開発プロジェクトの中で、この「プラント型IT」の仕事は、いろいろと嫌われ者になっている印象がある。
プロジェクト規模がとにかく巨大なものが多い
ユーザー企業からSI企業、さらにはその下請けなど、多重請負構造が多い
IT面での新技術とはあまり縁がなく、ユーザー企業独特の業務仕様が優先される
サイロ化してしまう
しかし、この社会の重要なインフラ部分を支えているのが、この「プラント型IT」（基幹系システム）なのである。
銀行の日々の取引や振替、電気やガスの供給や料金支払、鉄道の日々の運行、莫大な個数が行き交う流通配送業。
こうした社会インフラは、「プラント型IT」（基幹系システム）の上で動いている。
（この中には皆さんに嫌われているCOBOLを使用したシステムも多くある）
誰もがIT（特にプラント型IT）を軽視しすぎている
ユーザー企業や官公庁の担当者は、ITを本業とは思っていない。故に関わりたくないと思っている。
（PCのオフィスソフトは非常にうまく使う人もいるがシステム開発の本質を見ようとしない）
ITベンダー側のエンジニアの多くは、ユーザー企業の業務内容になど興味がない。
（業務知識などより最新のIT技術ばかりを追いたがる）
この、ユーザー側とITベンダー側との距離の遠さが、ますますITプロジェクトを失敗させる要因になっている。
まだ読み始めたばかりだが、良い本のようなので、精読したいと思う。
（関連記事）
何かを書くことが好きだという人や割と得意だと言う人はもしかするとIT系に向いているかもしれない
何かを書くことが好きだという人や割と得意だと言う人はもしかするとIT系に向いているかもしれない
ITエンジニアの主要業務のひとつは確実に「ドキュメントを作成すること」であると思う。
IT系の技術者（エンジニア）を呼称する場合は、何を使えばよいかわからない。
人や組織や立場によって、「その呼称で呼ぶな」と思われていたりする。
本質的な意味でプログラマーを名乗る人は、システムエンジニアという和製英語は嫌いであるようだ。
私は、呼称にはこだわらない。もしも書くなら「情報処理技術者」と書くだろう。
なお、IT業界には、多重請負構造などの闇があって、新卒採用されて以来、プログラムを組むことも、システムデザイン（システム設計）をすることもなく、ひたすら「テスト要員」（テスター）ばかりをやらされているという現場もあると聞く。
テスト作業は確かに重要なのだが、テストの設計ではなく、単純労働的なテスターばかりをやらされているというのであれば、その組織・企業に問題がある可能性が高い。
（閑話休題）
極端なテスターは除外するとして、
一般的な技術者であれば、日頃やっている作業を分類するならば、
設計書やプログラム、その他資料を、読み解く作業
設計書やプログラム、その他資料を、書く（描く）作業
上述した成果物を確認（レビュー）する作業
に大別できると思う。
特に、プロジェクトの規模が大きくなると、二次関数的に他のメンバーとの「意識合わせ」「認識合わせ」という、コミュニケーションコストが増大する。
認識合わせには画期的な解はなく、できるだけ「ドキュメントベース」もしくは「エビデンスベース」で、きっちり合わせる努力が欠かせない。
ITエンジニアの方が本職の文筆家よりも多くのドキュメントを書いているかもしれない
上記のように、実はITエンジニアは、日頃から様々な成果物（ドキュメント）を作成している。
「そういう行為を嫌う人」は、けっこう多い気もするが…。（そういう人は、もっとプログラムを書いたり、システムデザインに直結する作業をしたいと思うようである）
しかし、好き嫌いは別として、顧客や上司、他メンバーとの「認識合わせ」というコミュニケーションは避けることができない。
知らない人は、コーディング作業ばかりしていると思うかもしれないが（もちろん組織や企業や立場によっては、そういう人もいるが）、私の観測範囲では、日本語の資料を読んだり書いたりすることの方が、時間としては圧倒的に長いと思われる。
そういう意味で言うならば。
何かを書くことが好きだという人、割と得意だと言う人は、もしかすると、IT系に向いているかもしれない。
「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない
「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない
勉強をするうえで、インプットすることよりも、アウトプットすることを大切にした方が良いと、よく言われる。
それは、アウトプットすることで、自分の中にある断片化された知識が明確になり、あいまいであったり、穴があったりする部分が「見える化」されるからである。
そして、そのあいまいな部分や穴の部分を、埋めようとする。そして知識を体系立てて整理する。
つまり、アウトプットすることで知識がより「強化」される。
インプットだけだと、これができないからである。
人に「１」を教えるためには「１０」の知識が必要
これは感覚論になってしまうのだが、人に何かを「教える」「説明する」ためには、対象にたいする知識量が、「教える」量の何倍も必要であると思う。
私の感覚では、１０倍くらいは必要だと思う。
人に「１」を教えるためには「１０」の知識が必要
即ち、「１０」を教えるためには「１００」の知識が必要
そして、
- 「１０」を教えて、実際に「伝わる」のは、せいぜい「５」も行けば良い方
である。
ズブの素人に何かを教える場合と、かなり知識を持っている人に何かを教える場合とでは、伝わる効率が全く違う。
これは、同じ内容を、新入社員に対して伝える場合と、経験年数がある社員に伝える場合とを比較するとわかるはずである。
それでも、どんなに効率的に伝えることができたとしても、１００パーセントを伝えることはできない。
生徒でいるうちは先生を超えることはできない
生徒でいるうちは先生を超えることはできない
上述したように、「教える側」は教えるたびに知識を強化していく。
「教わる側」は、１００パーセントを理解することはできない。
だから、先生役をやる機会があったら、面倒がらずにやるべきである。
この真実は、案外、知らない人が多い気がする。
情報工学を勉強するということとは
情報工学を勉強するということとは
このブログでも記しているように、近年の私は敢えて自分の専門領域以外の『電気工学』『無線工学』などを勉強している。そして、それらの基礎となっている『電磁気学』周辺の『物理学』も必然的に勉強することとなり、さらにそれらを知るための基礎となる『数学』も必然的に勉強している。
『電磁気学』を学ぶということは、１９世紀頃からの古典物理学の歴史を学ぶということと、結果としては同じである。何故ならば、学問を理解するということは過去の発見や理論の積み重ねの歴史を理解することだからである。
『プログラミング教育の義務化』というものが２年後くらいからはじまりそうな情勢である。
私はどうしても、「コンピュータの動作原理」などの基礎を飛ばして、「プログラミング」というものだけを教育する考えには、違和感を覚える。こういうことを言うと老害認定されそうであるが…。
よくネットなどで見かける意見として、
「Java言語は最初に学ぶ言語に良いとは思うが、統合開発環境の使い方などを勉強しなければならないハードルがある」
「まずはプログラミングの楽しさを早く体感できる言語が良い」
…などというものがある。
率直な私の意見としては、
「裏側のコンピュータやネットワークやファイルシステムなどのしくみを理解しないままプログラミングだけを学習させたなら、何かトラブルが起こったときに根源的な解決が独力ではできないという、使えない人が大量に生み出されると思うので、同時並行的に裏側のしくみについても学習させるべきだ」
…と思っている。
そもそも、裏側のしくみの理解がないと、プログラムが動作するイメージを頭の中で組み立てることが困難ではないかと個人的には思えてならない。
そして、そう考えて、「それを教えられる人が絶望的に少ない現状がある」ために、無理だとも思うが…。
裏側のしくみを理解することの大切さと、コンピュータやシステムの歴史を理解することの重要性
IT業界は本当に『車輪の再発明』(reinventing the wheel)が横行してきた世界である。
『オブジェクト指向』や『リファクタリング』も、その原理や発想はものすごく昔に生まれていた。それを改めて「そういう固有名詞で」表現したり体系的にしたりしたのが、それよりもだいぶ後年になってからだというだけである。
そして、そうしたプログラムやシステムを開発する上での工夫は、かなり昔から実施されてきた。別にOOPに対応していない古典的な言語であっても（それこそCOBOLとか昔のC言語などであっても）、開発者の工夫で似たようなことはやってきた面もある。
「バージョン管理にSVN(Subversion)を使っている職場などイケていないから辞めたい」
などという意見を目にすると、残念な気分になる。的外れもいいところだ。
重要なのはそんな部分ではないだろう、と…。
最新の統合開発環境ではなく、テキストエディターでコーディングをしている職場だとしても、ただそれだけの理由でそうした職場を悪く言うのは早計であるし、自らの成長や学習の機会を逸することになるだろう。
もしも敢えて同じようなレベルで近年の若手のツールの使い方に対して、私が言うならば、「FTPのGUIツールをエクスプローラーのように使うなよ」とか言いたくもなる。こんなことを言うと老害認定されそうだが…。
どんな環境や、どんなツールにも、生まれた理由があり、使われる理由がある。それぞれの特徴がある。良い面と悪い面がある。
いちばん問題なのは、そうした「しくみの理解」をしないまま、ただブラックボックスとして利用しているという姿勢である。
近年、非コンパイラ言語のみを新人研修で習ってきた若手が、コンパイルやリンケージのしくみをよくわかっておらず、それに起因するバージョン管理トラブルがあった。
これは本当に裏側のしくみの理解の問題であり、バージョン管理ツールに何を使っているかは問題ではない。
プログラムやシステムを開発するという点において、例えばこうしたバージョン管理などの構成管理の知識は、その言語によるプログラミングの知識以上に重要となる場合がある。
バージョン管理やプログラム生成環境の理解は、結局のところ、「プログラムがどこで動くのか」「プログラムがどうやって動くのか」という「しくみの理解」に行き当たる。
日本のIT業界には、「情報工学を何も学んでこなかった素人」の人であっても新卒一括採用で入ってくる。それ自体は仕方のないことだし、悪く言うつもりはない。
ただ、教える方も、教わる方も、「古い」「新しい」とか、「トレンド」「非トレンド」とか、そういったことにとらわれず、好き嫌いなく、貪欲に、公正に、教えてほしいし、学習して欲しいと思う。
オトナはみんなうそつきだから自分自身で実際に見たものを信じて自信をつけて行こう
オトナはみんなうそつきだから自分自身で実際に見たものを信じて自信をつけて行こう
（関連過去記事）
『車輪の再発明』という言葉を知っているだろうか。
IT業界においては、本当にこの『車輪の再発明』がくりかえされている。
主に食物とされているのが、IT系の知識や経験を本当は全く持っていないズブの素人なのに、年功序列で決裁権が回ってきた大企業の経営者たち、そして、世間知らずの若者たちである。
それでうまい汁を吸って生きているのが、世の中にゴマンと居る自称コンサルタントの皆さん。
いや、コンサルの中でも若手の人は、どちらかと言うと食い物にされた若者に入るかもしれない。
私も以前、自分がまだ子供の頃にあたる時代について記事を書いたことがあった。
その時に強く思った。
「人間は自分が社会に出る前や、生まれる前の、昔のことは本当に何も知らないものなんだ」
と。
ITエンジニア（技術者）が新しいものに飛びつきたくなる本当の理由
これは、考え詰めれば非常に利己的な理由である。
- 自分が主役（先駆者）になりたいから
特にIT分野は、未だ成長しきっておらず、発展の余地が大いにある分野である。
そのため、とにかく新しいことを先にやった人が注目されやすい。
また、競争相手が少ない方が、儲かる。
ここで注意したいことは、新しいことを先にやり、競争相手が少ない方が良いのだが、まったく参入者が居ないのもマズイということになる。
だから、何も知らない大企業の経営者のおじいさんたちや、同じく何も知らない若手に対して、参入を促すのである。
特に若手は、「自分が主役となって活躍したい」と漠然と思っているから、余計に新しいものの良い面だけを見て信じる。
こうした人たちが、単に古いものを悪だと決めつけるのは、本当は、単なるマウンティングでしかない。
IT産業もある程度成熟すれば先駆者利益も減るだろう
私は思うところがあって、電気工学や無線工学などを勉強している。
電気や無線の世界は、少なくともITの世界よりは成熟していて、単に『車輪の再発明』をやるだけで注目されたり儲かったりはしない。
替わりに、純粋に電磁気学などの「しくみ」を理解している者が少ないので、そうしたホンモノの知識を持っている人が重宝されているようである。
COBOLプログラマの不足が心配されているという情勢は、ある意味で、ようやくIT産業が成熟に近づいてきた傾向を示しているのかもしれない。
ITエンジニアは一生勉強していかないといけない。これは確かである。
どんな環境もどんな領域も、どんな言語も。
必要とあらば、どんどん経験して自分のスキルにして行くのが正しい。
私自身も、新入社員だった頃は、当時は「COBOLなんてすぐになくなる」という風説を信じ込み、けっこう辞めたい気分だった。
いまは、大型汎用機（メインフレーム）のOSや環境を、いろいろと使うことができて、本当に良い経験になったと思っている。
大型汎用機（メインフレーム）の環境を、好きにできる職場って、そうそう存在しないと思う。
なんで皆、特定のプログラミング言語やプラットフォームを一種類覚えると、それだけでやっていこうという発想になるの？それが本当にわからない。好き嫌い言わず、出会った環境をどんどん修得していけば良いだけだよ？ #プログラミング言語
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2018年4月7日
Windows環境における大量ファイル（フォルダ構成）のコピーをする際の留意点
Windows環境における大量ファイル（フォルダ構成）のコピーをする際の留意点
下記の過去記事にも記したが、Windowsに限らず、UNIX/Linux系OSを含めて、現在の主流ファイルシステムにおいては、ファイルをカタログすることをユーザーに意識させない。つまり、コピーなどの処理と同時に、「存在しなければカタログ化してから書き込む」ということを自動的に行う。
これは、考えればきわめて当然なのだが、下記のことが言える。
ファイル（フォルダ）が存在しない状態に対して大量コピーを行うと処理時間がものすごく長くなる（処理コストが高くなる）
一度ファイル（フォルダ）が作成された状態に対して内容だけを更新しようとすると処理時間はそんなにかからない（処理コストが高くない）
特にWindows系OS環境では、ファイルやフォルダの新規作成（カタログ化）がものすごく重い印象である。
下手すると秒間２～３ファイル程度の速度かもしれない。
これでは、数万ファイル以上のコピーにはものすごく時間がかかる。
数万ファイル以上のファイル（フォルダ）のコピーを行う予定がある場合は、事前に余裕を見て本番前までに一度、コピー処理を実施しておくのが賢明である。（つまりファイルやフォルダのカタログ化を事前に済ませておく）
また、数万ファイル以上という大量コピーは、ファイルエクスプローラーによるコピーではなく、
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 Basic と COBOL を同じような言語だとする意見があるようだが、全く違うと思う。VBは保守性から見ても、悪いが最悪と言って良い）
たぶん20年後も同じことが言われているだろう
「新人にCOBOLの案件をやらせるのはいけないことだ」
たぶん、20年後も同じことが言われているんじゃなかろうか。
何せ、これまで20年以上も同じことが言われ続けて来たのだから。
世の中の社会インフラや、金融業界などの業務基盤を支えている、裏側のシステムにおいて、COBOLは根強く使われ続けている。
仕事をやるもやらないも自由だが、自分が縁あってアサインされた仕事で、たまたまCOBOLを扱う案件であるという理由だけで、経験もせずに辞めるというのも、もったいないとは思う。
年度末ということで、こんな事を敢えて書いてみた。
多額の借金までして大学に進むくらいなら、進学せずにとりあえず就職してしまうという選択もありだと思うんだが…
多額の借金までして大学に進むくらいなら、進学せずにとりあえず就職してしまうという選択もありだと思うんだが…
今日のネットニュースで、下記のような記事を拝読した。
自己破産者も急増「私はこうして奨学金を返せなくなった」
就職すれば大丈夫と思っていたのに
奨学金制度という言葉だと実感がわかない人もいるみたいだが、これは借金そのものなのだ。
借金は、可能な限りしない方が良い。
これは社会人になると本当にそう思う。
すべては情報が足りないのが問題
２１世紀に入って、大学進学率が急激に上昇し、現代では高校卒業者の半数くらいが、大学に進学する時代となった。
大学に進学する理由の多くは、本来の「学問をもっと追究したい」という理念からは程遠い、「今どき大学くらい出ていないと良い就職先にありつけない」という理由のようだ。
本当にそうだろうか。
あくまでもネット界隈での書き込みを見ての感触なので、どこまで本当かはわからないが、下記のような状況が見える。
(1) とにかくやみくもに「大手有名大企業」に入ることが成功だと思っている
(2) 上記(1)のためには、とにかく有名でいわゆる高偏差値の大学に行かないとダメだと思っている
(3) 仕事や職業についての具体的なイメージは何も持っていない。知らない
(4) 上記(1)とセットの考えとして、中小企業に入ると「ブラックな職場」や「現場仕事」になると思い込んでいる
一言で言うと、世間知らず。何も知らない。
そして自己分析もしていない。
人の性格や特質によって、大企業に向いている人、中小企業に向いている人など、様々であるのが本当なのだが…。
もちろん、中小企業がすべて「ブラック」であるということは真っ赤なウソであるし、大手有名大企業であっても「ブラック」は存在する。
「現場仕事」は企業の大小に関わらず重要である。また、そうした仕事のほうが性に合っている人も多い。
実際の例を挙げよう
例えば、私の実際の勤め先のことを少し書く。
これは本当のことだが、私の先輩社員の中に、同じ高校を同学年で卒業した二人がいる。
その二人は、それぞれ、大学卒業、専門学校卒業と、学歴は異なる。
年齢は同じだが、専門学校卒の方が、早く入社したので、そちらが先輩社員になる。（不思議なもので先輩後輩という事実は、ずっと変えられない事実になる）
両方ともに、現在、入社して３０年近くになるベテランだが、専門学校卒の人の方が、職位としては上でやっている。
学歴や入社年次の問題ではなく、その専門卒の人の方が、技術的な知識を多く持っていたりする面が、評価されている。
無論、両方の人ともに、これだけ長く勤めているわけだから、実績の評価もあり、仕事ができないわけではない。
入社されたのが３０年近くも前なので、現代の就職事情とは異なるかもしれない。
しかし、上記の状況は、ひとつの厳然たる事実である。
いまの学生の人の多くは、「学歴ですべてが決まってしまう」と思い込んでいるようだが、実際にはそんなことはない。
実際に働いてみないとわからないことが多い
学生の段階で、充分に自己分析を行うことは重要だが、それでも、実際に社会に出て働いてみないとわからないことも多い。
上述したように、「学歴だけ」で、すべての「優劣」が決まってしまうことはない。（そう思いたい、もしくは、そう思い込んでいる学生が多いようだが）
借金までして無理して大学に進学するくらいなら、もっと早めに社会に出てみるのも、選択肢としてはありだと思う。
