IT (情報技術) 学習記録

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

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


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


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


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

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

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

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


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


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


Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほどわかりやすい言葉だ


Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほどわかりやすい言葉だ


三年間も病気療養のために仕事を離れていた私が、現場に復帰して、1年半あまり。

歳を食った平社員にすぎない立場ながら、別に変に守りに入る必要もなく、立場を超えての言動を割と許容する社風なこともあり(※1)、これまで好きに仕事をさせてもらっていた。

昨年度は、数十人月規模のプロジェクトを実質的に全部主導的(実質リーダー)に回した。

(※1)IT系はどこもそうだと思う。何故ならば、結局は「できる人がやる」しかなくなるのが「システム開発プロジェクト」だから。


新年度に入り、数年前から進行中の大規模プロジェクトに「現行/既存システムを知る有識者」として参画することを命じられ、また仕事の環境が変わり始めた。

この5月の連休明けからは、一気に本腰を入れて参画することを余儀なくされそうである。


大規模プロジェクト「あるある」を垣間見る


連休直前の日。臨時のプロジェクト全体会議をやるから出ろ言われ、参加してみた。

大規模プロジェクト「あるある」を垣間見た。

  • PM,PMO側が発表する全体方針(スケジュールや体制)の受け止め方がチームや会社によってバラバラ

  • 現場を必死に回しても回しきれずにいる若手リーダーが困惑しつつ冷めている

  • 各社リーダークラスは必死に高稼働状態のようだが末端クラスへの意識/知識の展開ができていない

みんな、各個人を見ると、必死で頑張っている。

それでも、「深刻な人手不足」だとリーダーは悲鳴を挙げる。


『会社のITはエンジニアに任せるな!(白川克著)』を手にとってみる


www.diamond.co.jp


プロジェクトに対し、何か良い貢献ができないものかと考えて、

会社のITはエンジニアに任せるな!(白川克著)

という本が非常に評判が良いようだったので、読み始めた。

私は基本的にコンサルタントのお仕事はあまり良い印象を持っていない。何故ならば、世の中の多くのコンサルタントの方々は、無知なユーザー企業の経営者たちを、決して良い方向に「教育」してはくれないからである。

しかし、この本は、まさに「無知なユーザー企業の経営者たち」を「教育」するためのことが書かれているようである。


Web系は「ツール型IT」、基幹系は「プラント型IT」、なるほど


この著者の言葉によると、ITには大きく「ツール型IT」と「プラント型IT」があるという。

「プラント型IT」は、その企業の固有業務そのものであり、他に類を見ない知見のカタマリである。

まさに、基幹系業務システムのことである。

なるほど、こういう言い方もあるのだな。感心した。なるほどわかりやすい言葉だ。広めたい。


IT系、もっと言うとシステム開発プロジェクトの中で、この「プラント型IT」の仕事は、いろいろと嫌われ者になっている印象がある。

  • プロジェクト規模がとにかく巨大なものが多い

  • ユーザー企業からSI企業、さらにはその下請けなど、多重請負構造が多い

  • IT面での新技術とはあまり縁がなく、ユーザー企業独特の業務仕様が優先される

  • サイロ化してしまう


しかし、この社会の重要なインフラ部分を支えているのが、この「プラント型IT」(基幹系システム)なのである。

銀行の日々の取引や振替、電気やガスの供給や料金支払、鉄道の日々の運行、莫大な個数が行き交う流通配送業。

こうした社会インフラは、「プラント型IT」(基幹系システム)の上で動いている。

(この中には皆さんに嫌われているCOBOLを使用したシステムも多くある)


誰もがIT(特にプラント型IT)を軽視しすぎている


ユーザー企業や官公庁の担当者は、ITを本業とは思っていない。故に関わりたくないと思っている。

(PCのオフィスソフトは非常にうまく使う人もいるがシステム開発の本質を見ようとしない)

ITベンダー側のエンジニアの多くは、ユーザー企業の業務内容になど興味がない。

(業務知識などより最新のIT技術ばかりを追いたがる)

この、ユーザー側とITベンダー側との距離の遠さが、ますますITプロジェクトを失敗させる要因になっている。


まだ読み始めたばかりだが、良い本のようなので、精読したいと思う。

(関連記事)


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


kf7757.hatenablog.com


何かを書くことが好きだという人や割と得意だと言う人はもしかするとIT系に向いているかもしれない


何かを書くことが好きだという人や割と得意だと言う人はもしかするとIT系に向いているかもしれない


ITエンジニアの主要業務のひとつは確実に「ドキュメントを作成すること」であると思う。



IT系の技術者(エンジニア)を呼称する場合は、何を使えばよいかわからない。

人や組織や立場によって、「その呼称で呼ぶな」と思われていたりする。

本質的な意味でプログラマーを名乗る人は、システムエンジニアという和製英語は嫌いであるようだ。

私は、呼称にはこだわらない。もしも書くなら「情報処理技術者」と書くだろう。


なお、IT業界には、多重請負構造などの闇があって、新卒採用されて以来、プログラムを組むことも、システムデザイン(システム設計)をすることもなく、ひたすら「テスト要員」(テスター)ばかりをやらされているという現場もあると聞く。

テスト作業は確かに重要なのだが、テストの設計ではなく、単純労働的なテスターばかりをやらされているというのであれば、その組織・企業に問題がある可能性が高い。


閑話休題

極端なテスターは除外するとして、

一般的な技術者であれば、日頃やっている作業を分類するならば、

  • 設計書やプログラム、その他資料を、読み解く作業

  • 設計書やプログラム、その他資料を、書く(描く)作業

  • 上述した成果物を確認(レビュー)する作業

に大別できると思う。

特に、プロジェクトの規模が大きくなると、二次関数的に他のメンバーとの「意識合わせ」「認識合わせ」という、コミュニケーションコストが増大する

認識合わせには画期的な解はなく、できるだけ「ドキュメントベース」もしくは「エビデンスベース」で、きっちり合わせる努力が欠かせない。


ITエンジニアの方が本職の文筆家よりも多くのドキュメントを書いているかもしれない


上記のように、実はITエンジニアは、日頃から様々な成果物(ドキュメント)を作成している

「そういう行為を嫌う人」は、けっこう多い気もするが…。(そういう人は、もっとプログラムを書いたり、システムデザインに直結する作業をしたいと思うようである)

しかし、好き嫌いは別として、顧客や上司、他メンバーとの「認識合わせ」というコミュニケーションは避けることができない

知らない人は、コーディング作業ばかりしていると思うかもしれないが(もちろん組織や企業や立場によっては、そういう人もいるが)、私の観測範囲では、日本語の資料を読んだり書いたりすることの方が、時間としては圧倒的に長いと思われる。


そういう意味で言うならば。

何かを書くことが好きだという人、割と得意だと言う人は、もしかすると、IT系に向いているかもしれない。


「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない


「教える側」になる機会があれば買ってでもやろう…「教わる側」にいる限り「教える側」を超えることは絶対にできない


勉強をするうえで、インプットすることよりも、アウトプットすることを大切にした方が良いと、よく言われる。

それは、アウトプットすることで、自分の中にある断片化された知識が明確になり、あいまいであったり、穴があったりする部分が「見える化」されるからである。

そして、そのあいまいな部分や穴の部分を、埋めようとする。そして知識を体系立てて整理する。

つまり、アウトプットすることで知識がより「強化」される。

インプットだけだと、これができないからである。


人に「1」を教えるためには「10」の知識が必要


これは感覚論になってしまうのだが、人に何かを「教える」「説明する」ためには、対象にたいする知識量が、「教える」量の何倍も必要であると思う。

私の感覚では、10倍くらいは必要だと思う。

  • 人に「1」を教えるためには「10」の知識が必要

  • 即ち、「10」を教えるためには「100」の知識が必要

そして、

  • 「10」を教えて、実際に「伝わる」のは、せいぜい「5」も行けば良い方

である。


ズブの素人に何かを教える場合と、かなり知識を持っている人に何かを教える場合とでは、伝わる効率が全く違う。

これは、同じ内容を、新入社員に対して伝える場合と、経験年数がある社員に伝える場合とを比較するとわかるはずである。

それでも、どんなに効率的に伝えることができたとしても、100パーセントを伝えることはできない。


生徒でいるうちは先生を超えることはできない


生徒でいるうちは先生を超えることはできない

上述したように、「教える側」は教えるたびに知識を強化していく。

「教わる側」は、100パーセントを理解することはできない。

だから、先生役をやる機会があったら、面倒がらずにやるべきである。


この真実は、案外、知らない人が多い気がする。