hatena
<body>
*1407034086*gihyo版「エンジニアの学び方」を公開しました
技術評論社のWEB+DB PRESS Vol.80に掲載した、特別企画「エンジニアの学び方」がWeb上で無償で読めるようになりました。
僕は、自分の学び方をよく観察して、改善すべき問題点を見つけ、それを改善する、というサイクルを続けていくことがとても重要だと感じています。そのため、今後もブログなどでこの手の話題を書くのですが、そこから雑誌の記事に言及しても読者さんは入手がしにくいので何とかならないかと相談したところ、快くWebでの公開という形になりました。技術評論社さん、ありがとうございます。
技術評論社のウェブサイトgihyo.jpで読むことができます: <a href='http://gihyo.jp/lifestyle/feature/01/engineer-studying'>エンジニアの学び方─効率的に知識を得て，成果に結び付ける：特集｜gihyo.jp … 技術評論社</a>
公開時の筆者のブログ記事: <a href='http://d.hatena.ne.jp/nishiohirokazu/20140427/1398524475'>「エンジニアの学び方」を執筆しました。</a>
Web版公開時の筆者のTweet:
>>
WEB+DB Pressの特別企画「エンジニアの学び方」第1章がWebで読めるようになりました！
<<
>>
WEB+DB Pressの特別企画「エンジニアの学び方」の第2章「最初の一歩をどう踏み出すか」がWebで読めるようになりました！
<<
>>
「エンジニアの学び方」第3章が公開されました。第1章で注目すべき3つの軸と3つの段階について俯瞰し、第2章では情報を自分の中に取り込むことにフォーカスしました。第3章では取り込んだ情報をどう咀嚼するかがテーマです。
<<
>>
どんな栄養たっぷりの料理でも、口にぎゅうぎゅう詰め込むだけでは血肉にならない。適度な分量を口に入れ、よく噛んで飲み込み、消化に時間を掛けなければ吸収することはできない。
<<
>>
「エンジニアの学び方」第4章が公開されました。第2章では情報を取り込む方法、第3章では取り込んだ情報を咀嚼する方法でした。しかし情報は取り込んだだけでは価値を産みません。第4章ではどう出力し成果につなげるかを考えます。
<<
>>
まさか雑誌の特集がWebで公開されて、それで終わりのはずがあるまい（ティザー
<<
*1407035579*「抽象から学ぶ」に具体例を追加
<a href='http://gihyo.jp/lifestyle/feature/01/engineer-studying/0003'>gihyo版「エンジニアの学び方」の第3章</a>で、抽象化の必要性とその方法について学びました。その中の一つ、「抽象から学ぶ」が実例が足りなくてわかりにくいようなので、ここで具体例を追加してよりわかりやすく解説してみます。
「抽象から学ぶ」は「読者の抽象化を助けることを目的とした文章」を読んで、それによって自分の中での抽象化を促進する方法でした。では「読者の抽象化を助けることを目的とした文章」とは具体的にはどのようなものでしょう？
たとえば「Xには3つの要素A、B、Cがある」などの記述は、これに該当します。具体的には「学び方には広い視野軸・深い理解軸・応用軸がある」などです。具体的な学び方にはいろいろな要素があり、いろいろな方法があり、個別の事例それぞれ違ったところがあります。その違いの一部をバッサリ切り捨てて見せることで、読者の中での抽象化を助けるのです。
[f:id:nishiohirokazu:20140803121050p:image]
このような文章を読んだ人は、その反応で2つに分かれます。片方の読者は、この文章と読者の経験との間に相互反応が起こります。
例えば：
- 「自分の経験からすると、Xはたしかにその3つに分類できる。今まで言語化できてなかった。なるほど、今後はそういう名前で呼ぶことにしよう」
- 「今までの経験で、AとBは意識していたが、Cの存在には気づいてなかった。盲点だった。なるほど、今後はCを見落とさないように気をつけよう」
- 「自分の経験ではCはあんまり重要ではない」
- 「自分の経験からすると、この他にもう一つ大事なものDがあることを忘れてはならないと思う」
[f:id:nishiohirokazu:20140803121101p:image]
いずれのケースでも、自分の経験を整理し、構造を見出し、抽象化してモデルを作ることを助ける方向への変化が起こっています。具体例：読者さんが書いた書評ブログ「<a href='http://takuan-osho.hatenablog.com/entry/2014/05/08/book-review-about-webdbpress-vol-80'>WEB+DB PRESS vol.80の特集「エンジニアの学び方」の書評を読んで気になったので該当書籍買って読んでみた - プログラマ行進曲第二章</a>」では「2,3に当たる部分を疎かにしていることは何となく自覚していたのですが、「抽象化」フェーズといった明確な名前と位置づけを与えられたことで「今自分がしている学びはどのフェーズに当たるもので、現在の自分に足りない知識はどの軸のものか？」といった判断がしやすくなった」という記述があります。
一方で、こういう抽象的な文章を読んだ時に「自分の経験」が出てこない読者もいます。
例えば：
- 「何を根拠にそんなことを言っているんだ？」
- 「なんか抽象的でよくわからない話だな～」
- 「よくわからないけど、大事なことらしいからノートに書いておこう」
筆者は自分の経験から、抽象化を行って、抽象的なモデルを作り、それを文章に書いています。しかし、そのモデルにフィットする経験が読者の中にないと、読者は「しっくりきた感じ」を得ることができません。この状況ではノートに書いたりしてもすぐ忘れてしまい、なかなか有効活用することができません。これは読者が悪いわけではありません。著者と読者の経験に大きなミスマッチがあることが原因です。
[f:id:nishiohirokazu:20140803121114p:image]
著者はなるべく多くの読者に理解してもらおうと、具体的な例をたくさん出して「降りていく」ことをします。しかし、事前にすべての読者の持っている経験を把握し、すべての人に分かる例をあげることはできません。ミスマッチはなくせないのです。
[f:id:nishiohirokazu:20140803121029p:image]
結局のところ、書籍などを読んでそこに書かれた抽象的なモデルを学べるかどうかは「運」なのです。
「よくわからないけど書き留めたもの」が、運良く別の知識とつながって有効活用されることもありますし、運悪く思い出されないまま忘れ去られることもあります。
運は努力しても改善できません。だからこそ「抽象から学ぶ」ばかりに時間を使うのではなく「作って学ぶ」など他の方法も試してみることが大事なのです。
</body>