「怒り」の感情を否定するな！
「怒り」の感情を否定するな！
書店をめぐるのが昔から好きである。
近年はオンラインで書籍を購入することが増えたが、オンラインでも書籍を検索するのが好きである。
近年、売れている本を見るに、ある傾向が見える。
(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産業の有名人たちは、その事実から目を背けている。
やがて、社会を裏側で支えている基幹系システムの保守という地味な仕事の担い手が、圧倒的に足らなくなる時代がやってくるだろう。
そのときになって、後悔しても、すでに遅いのだ。
第二種電気工事士に合格はかなりうれしい
第二種電気工事士に合格はかなりうれしい
この５月から７月のプライベート時間のかなりを費やして受験した「第二種電気工事士」（筆記／技能）。
正式な合格通知が届いた。
正直、ものすごくうれしい。そしてホッとした。
この試験の本質は技能試験（実技）にある。
強電の仕事で最低限知らなければならない必須知識が技能試験の対策をやることで身につく。
そういう「しくみ」になっている。
うまいことできていると思う。
これで、一応、「IT」「弱電（無線通信）」「弱電（有線通信）」「強電」の４分野について国家資格を有したことになる。
（ITは、国家資格（免許）というより国家認定に過ぎないことは以前に書いたとおり）
もっとも、それぞれの資格の中では最高位ではないのだけれど…。（昔のものもあるし…）
この中で、実技試験が課せられているのは、強電の電気工事士だけである。
強電の世界では知識が無いことが人命に関わるためである。
技能試験は専門家に習ったほうが良い
合格率のデータだけを見ると、第二種電気工事士は、さして難しい試験ではないように思えてしまう。
現に昨年の私は、そう思ってしまった。それで不合格だったわけだが…。
しかし、工事作業を本業としているような人や、電気工学科などで実習をしたことがある人ではない限り、独学で挑戦するのはおすすめしない。
普通のド素人が、独学で突破できる試験ではない。
電気工事の基本単位作業を、頭で考えることなく「身体で覚えている」くらいのレベルに持っていかないと、なかなか合格は難しい。
なぜなら、本番での試験の時間がとても短いからだ。
専門家である講師に実習を教えてもらうことで、お手本を生で見ることができるし、本当に基本中の基本の疑問も聞くことができる。
電気工事士もそうだが、電気関係の知識では、本当に独学よりも先生に教わるほうが良いことを実感している。
ただし、まったくの無知識状態で先生に教わるのは、非効率である。
新人研修でも、教えたことのほとんどが残らない。
それは、まったくの下地がない状態では、いくら知識を頭に入れようとしても入らないからである。
その意味では、電気工事士の技能試験対策については、私は、あえて２回以上の講習を受けることをおすすめしたい。
１回めの講習で、電気工事士の基本的な作業を体験し、頭に回路を作る。
２回めの講習で、一度できた回路に改めて知識（体で覚える知識も含む）を、再度頭に入れる。
ほっとしたのは、「これで第一種電気工事士にもチャレンジできる」と思ったからでもある。
第一種にも挑戦するつもりでいる。
みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに
みんなアセンブラを必修科目にすればよいのに……しくみを理解していれば古きも新しきも同じことを言っていると気づくのに
以下のような流言がいつまで経っても消えない。
DOA (Data Oriented Approach) で新たに開発すれば生産性／保守性が高まる
オブジェクト指向言語で新たに開発すれば生産性／保守性が高まる
現行システムの維持に費用がかかるのは上記を採用していないからだ
いかにも、当該のユーザー企業の外側にいる（当然現行システムの中身など知らないし興味もない）コンサルタント業の人が言いそうなことではある。
そして、未だに大企業や官公庁といった大規模ユーザーで決裁権を持っている「偉い人達」は、そもそもＩＴには疎い者ばかりで、システム開発のことなんて「ド素人」である。
日本企業には、こうした「偉い人達」の側近には「イエスマン」しかいない。
上記のようなことを鵜呑みにして、様々な思惑も絡んで、難易度の高い大規模システム開発がくりかえされ、その多くが何らかの失敗をしでかして、欠陥の多いシステムが作られていく。
- DOA (Data Oriented Approach) で新たに開発すれば生産性／保守性が高まる？
現行システムが開発されて四半世紀。すでにOracleなどのRDBを中心に使用して回っている。
RDBを使用するだけでも、ある意味強制的に、部分的にはDOAを実現している。
逆にRDBの機能に頼り切ったシステムでは、保守性という面で問題が生じることは、もうみんなが知っている。
- オブジェクト指向言語で新たに開発すれば生産性／保守性が高まる？
こんなことを言うと一部から反論されそうではあるが、敢えて正直に言うと、オブジェクト指向と生産性や保守性は、直接的には関係性は無いと思っている。
要は、生産性や保守性を意識したシステム設計を、ちゃんとするか、しないか、それだけである。
そこに、「オブジェクト指向か否か」はあまり問題にはならない。
オブジェクト指向言語が実装としてやっていることを、ちゃんとコンピュータのしくみのうえで説明できる人が、そのプロジェクトに何人いるだろうか。
例えば「継承」がやっていることが、実メモリ空間の中でどう処理されているのか。
そういったことを理解していない人たちが設計してしまうと、結局、生産性や保守性が低いシステムができあがってしまう。
- 現行システムの維持に費用がかかるのは上記を採用していないからだ？
以前にも下記の記事で少し紹介したように、特に基幹系システムというものは、その企業の競争力を生み出す業務そのものと一体化した、「プラント型ＩＴ」と呼べるものである。
確かに実際のプラントと同様に、全体のアーキテクチャーが古いままであると、時代の流れに追従できないという問題も出てくるだろう。
しかし、それは、上述のような開発手法などの問題とは、また次元が異なる問題である。
上でも言ったが、どのように設計を行うか、という、設計スキルに帰着してしまうのである。
しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない
しくみを理解している人は簡単にJavaが良いとかCOBOLが悪いとか言わない。
問題の本質はそういう部分ではないことを知っているから。
近年、ようやく、Java言語の世界において、共通化がされてこなかった「バッチ処理」について、共通的なフレームワークの必要性が叫ばれるようになった。
少なくとも、日本の基幹系システムの心臓部は、すべてバッチ処理の部分に存在している。
これだって、中身を見ると、なんの真新しいことはない。ごくごく当たり前のことを標準化しただけである。
「自分の無知を知る」ことの大切さ
「自分の無知を知る」ことの大切さ
最近は試験勉強が忙しく、更新が停滞している。
「第二種電気工事士」の本番は何と言っても「技能試験」の方だということを、最近、身を持って体験している。
普段、ドライバーなどの工具もろくに使うことがない生活をしている者にとっては、ごくごく基本的な電工の実技も、たいへんだ。最初はものすごくつらい。
でも、強電を扱う者としての最低限の注意点などが、頭というより、手で覚えられるようになっている点がすごい。
あと一週間なので、山場である。
７月に入って、いろんな職場では、新入社員が現場に配属される季節になっている。
この季節になると、いつも、
「自分の無知を知る」ことの大切さ
を考える。
「わかっています」「知っています」と言う人にどうやって先を目指させるようにするのか
人に仕事などを教えることがよくある。
やはり、その仕事を長年やっている人の方が、いざというときの引き出しの数や、知識の深さが違っている場合が多い。
その意味では、入社数年の若手や、異業界からの転職者の人は、その道で長い人に比較すると、いろいろと「わかっていない」場合が多い。
しかし、プライドが高い者などは、「わかっています」と言う。
さらに精神的にこじれている場合、「わかっていない」ことから目をそむけ、自分がこれまで得意としてきた領域にこだわり過ぎて、まったく新しいことを覚えようとしない者もいる。
若手で、「本当は深くはわかっていない」のに、それに気づかない者ならば、「自分が実はまだまだわかっていないんだ」という事実に、気付きさえすれば、成長できる。
なまじ、社会経験がある程度ある人の場合、プライドのせいで「わかっていない」ことから目をそむけてしまう。
これだと成長する機会をどんどん失っていくだろう。
「自分の無知を知る」
これは本当に大切である。
私はいま、電工試験に集中しようとしているが、こっそり電験三種（第三種電気主任技術者）の勉強もやっている。
電験三種がいかに難しいか、それを最近、少しだけ実感してきた。
正直、合格できる気がしない。
でも、こういう実感は大切にしたいとも思う。
世の中には土日でも勉学に励んで頑張っている人が多くいるのだ。
見習わねば。
第二種電気工事士の技能試験にむけて
第二種電気工事士の技能試験にむけて
ネット上に多くある「資格ランキング」とか「資格難易度」などの情報は、実はとてもいい加減である。
はっきり言うなら、ウソばかりだと思える。
その記事を書いている人間が、実際に受験勉強をして試験を受けた訳ではなく、
「受験者数」、「合格者数」、「合格率」、などという、ふわっとした情報だけから判断している。
そういう情報は信用できない。
（企業の人事の人などもこういう情報を鵜呑みにしないでほしいものである）
第二種電気工事士（２電工）などは、そうした「資格難易度」のネット情報では、「初心者向き」で、「簡単」な資格と書かれている。
筆記試験は、そこまで難易度が高いとは言えないだろう。
しかし、工事士の試験なので、技能試験がある。
これは本当に簡単な試験なのだろうか。
少なくとも、７月の本試験に向けて、かなり頑張って「練習」を行わない限り、合格はできないだろう。
本職がシステムエンジニアの私にとっては、「工具」を使って「電線」をむいたり切ったり接続したり、という作業は、まったくもって未知の世界。
この試験を簡単だとはとても言えない。
準備がたいへんなこの試験。
準備がたいへんなだけに、合格したいものである。
勉強が多忙なので、記事も短めであります。
第二種電気工事士筆記試験を受けてきた(実は二度目)
第二種電気工事士筆記試験を受けてきた(実は二度目)
先週は、弱電系(通信系)の「工事担任者試験」があり、
本日は、強電系の登竜門たる「第二種電気工事士」の筆記試験だった。
ここ最近の土日では、受験対策をしていたため、この記事も久しぶりの更新となった。
昨年までは、上期か下期のいずれか一回しか受験できなかった。つまり上期と下期があっても事実上、一年に一度しか受験機会がない試験だった。
今年から、上期と下期、どちらも受験できるようになった。
それだけ、需要もある試験なのだろう。
しかし、近年は難化傾向があると聞いている。
実は昨年、私は初めてこの試験を受けた。結果はちょうど５０点で不合格。
電気系に関する下地の浅さと、試験対策が全く足りていなかった。
普段の自分の仕事で関わっている分野とは異なる領域の勉強の難しさを知った。
この一年間で、電気系に関する知識の下地は、かなり作って来られたと思う。
試験対策は、どうしても日々の疲れで、なかなかできなかったが、昨年とは下地の部分がまったく違ったためか、本日の筆記試験は、まぁ、なんとか通過した感触はある。
さて、問題は約一ヶ月後に控えている、「技能試験」（実技）である。
これは本当に試験対策をしないと合格できないだろう。
さすがに規模が大きな国家試験はいろいろ違う
昨年もそうだったけれど、試験地に行く道すがら、いろんな電気関係の教習所や出版社の関係者が、チラシを配っている。
消しゴムや、シャープペンシルをくれる会社もある。（オーム社さんシャーペンありがとう）
本日は６月初旬にしては猛暑だった。
皆様、お疲れ様でした。
いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫
いちメンバーにもできる大規模プロジェクトを少しでも成功に持っていくためのたったひとつの工夫
「会議」とか「打ち合わせ」とか、名前はそれぞれで、何でも良いのだが、とにかく、人が集まったからには、何かしらの目的がある。
情報の伝達とその結果（連絡）
知恵の出し合いと何らかの結果（検討）
意識や認識の確認とその結果（確認）
プロジェクトにおいては、規模が大きくなればなるほど、コミュニケーションの数が爆発的に増大する。
結果として、打ち合わせが多くなる。
そして、本来、打ち合わせとは、上記の三種類に大別できる。
「連絡」「検討」「確認」の三種類である。
ちゃんと機能した打ち合わせであれば、必ず何らかの「結果」が存在する。
そして、参加者は各々で、その「結果」を持ち帰り、自チームや自社メンバーに伝達する役割を担う。
この、「結果」を持ち帰り、自チームや自社メンバーに伝達する、ということができていないプロジェクトが多い。
プロジェクトの規模が大きくなればなるほど、本来は、上記の打ち合わせひとつひとつの重要度も増大する。
しかし、現実としては、大規模プロジェクトほど、打ち合わせがうまく機能しない。
何故か。
皆が忙しいことを言い訳にして、モノを書かないからだ。
メモでもいいから必ず書きものにして相手に渡せ！
うまく機能しない打ち合わせで、最もよくあるのが、
すべて口頭で情報が伝えられ、書きものとして結果が残らない
という状況である。
情報を伝えた方は、口頭で言ったので「伝えた」気分になっている。
情報を受け止めた方は、口頭で言われたことを一応は理解して「わかりました」と言う。
しかし、情報を受け止めた方は、その後になって、自分のノートの不完全なメモから、「どう決まったんだっけ？」という状態に陥る。
また、本来は正しい情報を自チームや自社メンバーにフィードバックしないといけないのだが、自分のノートの不完全なメモしか残っていないので、また、テキストにまとめる手間も惜しいので、またもや口頭でのフィードバックとなる。
口頭で伝えられたメンバーは、非常に劣化した情報が伝えられたこととなり、あいまいな情報がますますあいまいになっていく。
フィードバックされるならまだ良い方で、忙しさやメンバーとの時間が合わなかったりして、フィードバックすら行われない状況にもなる。
打ち合わせで口頭で言う予定のことは、メモでも良いので書きものにして渡す。
打ち合わせに参加した者は、その書きものを持って帰り、「こんな事をいわれた」と、その書きものを流せば良い。
たった、これだけのことで、情報の伝達不全は、かなり解消できるのである。
「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業界には、「情報工学を何も学んでこなかった素人」の人であっても新卒一括採用で入ってくる。それ自体は仕方のないことだし、悪く言うつもりはない。
ただ、教える方も、教わる方も、「古い」「新しい」とか、「トレンド」「非トレンド」とか、そういったことにとらわれず、好き嫌いなく、貪欲に、公正に、教えてほしいし、学習して欲しいと思う。
