「抽象から学ぶ」に具体例を追加

「抽象から学ぶ」に具体例を追加 (from Hatena2014-08-03 エンジニアの学び方)

• gihyo版「エンジニアの学び方」の第3章: 第3章 どうやって深く理解するか―比較、歴史から学ぶ、作って学ぶ | gihyo.jp

• で、抽象化の必要性とその方法について学びました。

• その中の一つ、「抽象から学ぶ」が実例が足りなくてわかりにくいようなので、ここで具体例を追加してよりわかりやすく解説してみます。

• 「抽象から学ぶ」は「読者の抽象化を助けることを目的とした文章」を読んで、それによって自分の中での抽象化を促進する方法でした。では「読者の抽象化を助けることを目的とした文章」とは具体的にはどのようなものでしょう？

• たとえば「Xには3つの要素A、B、Cがある」などの記述は、これに該当します。

  • 具体的には「学び方には広い視野軸・深い理解軸・応用軸がある」などです。
  • 具体的な学び方にはいろいろな要素があり、いろいろな方法があり、個別の事例それぞれ違ったところがあります。
  • その違いの一部をバッサリ切り捨てて見せることで、読者の中での抽象化を助けるのです。
  • 

• このような文章を読んだ人は、その反応で2つに分かれます。片方の読者は、この文章と読者の経験との間に相互反応が起こります。

• 例えば：

  • 「自分の経験からすると、Xはたしかにその3つに分類できる。今まで言語化できてなかった。なるほど、今後はそういう名前で呼ぶことにしよう」
  • 「今までの経験で、AとBは意識していたが、Cの存在には気づいてなかった。盲点だった。なるほど、今後はCを見落とさないように気をつけよう」
  • 「自分の経験ではCはあんまり重要ではない」
  • 「自分の経験からすると、この他にもう一つ大事なものDがあることを忘れてはならないと思う」
  • 

• いずれのケースでも、自分の経験を整理し、構造を見出し、抽象化してモデルを作ることを助ける方向への変化が起こっています。

  • 具体例：
    • 読者さんが書いた書評ブログ「WEB+DB PRESS vol.80の特集「エンジニアの学び方」の書評を読んで気になったので該当書籍買って読んでみた - プログラマ行進曲第二章」では

    • 2,3に当たる部分を疎かにしていることは何となく自覚していたのですが、「抽象化」フェーズといった明確な名前と位置づけを与えられたことで「今自分がしている学びはどのフェーズに当たるもので、現在の自分に足りない知識はどの軸のものか？」といった判断がしやすくなった

    • という記述があります。
      • #ラベリングによる再現

• 一方で、こういう抽象的な文章を読んだ時に「自分の経験」が出てこない読者もいます。

  • 例えば：
    • 「何を根拠にそんなことを言っているんだ？」
    • 「なんか抽象的でよくわからない話だな～」
    • 「よくわからないけど、大事なことらしいからノートに書いておこう」

• 筆者は自分の経験から、抽象化を行って、抽象的なモデルを作り、それを文章に書いています。

  • しかし、そのモデルにフィットする経験が読者の中にないと、読者は「しっくりきた感じ」を得ることができません。
  • この状況ではノートに書いたりしてもすぐ忘れてしまい、なかなか有効活用することができません。
  • これは読者が悪いわけではありません。著者と読者の経験に大きなミスマッチがあることが原因です。
  • 

• 著者はなるべく多くの読者に理解してもらおうと、具体的な例をたくさん出して「降りていく」ことをします。

  • しかし、事前にすべての読者の持っている経験を把握し、すべての人に分かる例をあげることはできません。
  • ミスマッチはなくせないのです。
  • 

• 結局のところ、書籍などを読んでそこに書かれた抽象的なモデルを学べるかどうかは「運」なのです。

  • 「よくわからないけど書き留めたもの」が、運良く別の知識とつながって有効活用されることもありますし、運悪く思い出されないまま忘れ去られることもあります。
  • 運は努力しても改善できません。
  • だからこそ「抽象から学ぶ」ばかりに時間を使うのではなく「作って学ぶ」など他の方法も試してみることが大事なのです。