読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

ウェブデザイン2013年2月号 「忙しいITエンジニアのための超効率的勉強法」について

読書ノート

文系あがりのSEの人が、試行錯誤の末獲得したらしい勉強法について。

僕も文系あがりのwebエンジニアだから分かるのだが、技術職というのはとかく意味不明な言葉のオンパレードなうえに、
手取り足取り教えてもくれない業種なのだ。

そしてエンジニアの力量は、知識量と理解度に比例すると常々思っている。
とはいうものの、技術系の専門書はやたらページ数が多く、専門用語が頻出するので、
多くの本をより効率的に勉強し、理解するにはどうしたらいいのだろうか。

エンジニアのための超速読法

このコーナーでは「500ページの本を明日までに読んでこい」みたいなエピソードが出てきたが、そんなん物理的に無理や。
そもそも、本というものは三種類に分別される。

  1. 通して読む(小説 マンガ)
  2. 都度調べる(辞書)
  3. ざっと読んで、部分的に何度も読む。

技術書というものは、この3番目の部類に入る。(というか、400ページを越えるような本は文理関係なくそうだと思う)
3番目の部類の本を読むときのフローは、以下のようになる。

  1. はじめ
  2. 読む目的を明確化する
  3. 目次を見て、どこの何が書かれているかを見極める
  4. 重要事項を書き留める
  5. 新しいキーワードが出てきたが、まだ時間がある(Yesなら3に戻る)
  6. おわり

まず目次を読み込んで、重要だと思う箇所を拾いだして、そこを重点的に読みこむ。
読んだらポイントだけメモする。
分からないポイントは抜き出してメモする。索引も活用のこと。

「はじめに」「おわりに」「第一章」「最終章」はわりと重要である(基本的に本の最初と最後は重要)
→最終的にA4の用紙1枚くらいにはまとめること。

ノートの取りかた

知識の獲得は本を読むだけではちょっと限界があると思う。
本にも書いてなくて、ネットで調べても存在しないおそろしくニッチな世界というものもこの世に存在するから。
授業とかプレゼンとかレクチャーとかで得られるものも多いだろう。
そういうレクチャーにノート取りは必須だが、効率的なノートの取りかたで、理解度に大きな差が出る。

だが板書をただ書き写しただけでは意味がない
というのも、パワポや教科書の文章をただ読み上げてるだけのプレゼンならともかく、
重要なことを板書せずに言ってることもあるからだ。

というわけで、ノートを取るときは、「愚直に書き写す」ことが推奨されている。
でもただ書き写すだけでは後で読んだときに要点が分からなくなってしまうので、
「四色ボールペンメモ法」なるものが紹介されている。

  1. 黒 相手の言ったこと
  2. 青 見出し テーマ
  3. 赤 重要事項(その場で判断するのはしんどいから、あとで丸で囲む)
  4. 緑 自分の思ったこと、アイデア

自分のアイデアと相手が言ったことがごちゃまぜになるとトラブルになるので注意。
どれを何色にするかはどうでもよくて、これら4つが区別されてればよい。

人に教えてはじめてわかる

教うるは学ぶの半ば
という諺があるけど、まあその通りだと思う。
とはいうものの、僕は塾講師をやったことがあるが、教えるほうが下手だったら教わるほうも不幸である。

講義の組み立てかた

  1. 軸を決める(3時間で1つか2つ) 軸とは、最重要ポイントの言語化
  2. 軸ごとに5W1Hを考える
  3. 記憶を定着させるための演習問題を考える
  4. まとめの言葉を考える (これも記憶定着のため)

教えるときの5W1H

why 技術が出てきた背景
what 技術そのものの話
how 技術の使われかた、方法論
where どこで使われているか、事例
who why whereなどで派生的に使う (VTAMはIBMが考案した)
when why whereなどで派生的に使う (1987年のアプリケーション間接続の事例)

重要なポイントを何度も言うことが重要だ。

追記 というかまとめ

基本的に僕は人付き合いが少ないほうなので、
本を読む時間は人より多いと思っている。
暇があったら家だろうが移動中だろうが本を読んでいるわけだが、
それでも読むべき本は多い。勉強することも多い。
というわけで、そこらへんの「速読法」とは別の方法があるのは、とてもいいと感じました。