拙著「コーディングを支える技術」の没原稿(幻の第0章)です。書籍の第1章の手前に入っていた、著者が執筆にあたって真っ先に書いたことです。しかし抽象的過ぎる、プログラミング技術書が哲学と経済学の話で始まるのはどうなのか、との話で消えた幻の原稿を発掘しました。
- 2012-07-01 執筆
- 2017-05-31 Scrapbox上に公開
- 2018-09-15 少し見栄えを改善しました。これはエンジニアの知的生産術の冒頭部と比べると面白いですね。
- エンジニアの知的生産術の紹介記事として書いたなぜ知的生産術に投資するのかとも強く関連しています。
1 序文：この本で何を学ぶか
この本の目的はモヤモヤ解決による生産性向上
この本の目的は、「プログラミングに関するモヤモヤを解決すること」です。 みなさんプログラミングを学んでいて、「オブジェクト指向ってなんだろう？わかったようなわからないような…」などのモヤモヤを感じたことがあるでしょう。この本ではそんなモヤモヤを解決して、スッキリする手助けをしたいと思っています。
モヤモヤは、腑に落ちない、よくわからない、うまく理解できない状態です。 では理解とは何でしょう？ 長尾真は「『わかる』とは何か」の中で「文章を理解するということは、書かれている内容を読者が自分のなかに再構築することである」と書いています。 モヤモヤは、文章などで脳に入力された知識が、自分が持っていた他の知識と繋がらず、フワフワ浮かんでいるような状態です。 この状態でも、入ってきた知識をオウムのようにそのまま吐き出すことはできるかもしれません。しかし、別の知識とつなぎあわせて応用することができません。
つまり、この本の目的は「読者の皆さんの、まだ結合してない知識と、既存の知識と結合させること」とも言えます。一般的な教科書とは異なる視点を提供することで、結合を促したいと思っています。
.. *「わかる」とは何か (岩波新書) p.120 (TODO:名前の漢字が少し違うのは反映できますか？ http://ja.wikipedia.org/wiki/%E9%95%B7%E5%B0%BE%E7%9C%9F))
しかし、そもそも何のために理解する必要があるのでしょうか？ プログラミングの教科書では、例えばオブジェクト指向などいろいろな概念が言及されます。 プログラムを書く上で、その概念を理解する必要はあるのでしょうか？ あなたが理解している概念について「それ何の役に立つの？」と聞かれたらどう答えますか？
野中 郁次郎は「知識創造の方法論」の中で、プラグマティズムを紹介して「知識は本来、人々の役に立つものでなくてはならず(中略)有用性という目的を超えて真理はありえない」と述べています。 筆者もこの考え方に賛成です。自分の生活に役立てるためにそれらの概念を理解するのです。 この本では、大昔のコンピュータの話や、何十年も前のプログラミング言語の話が出てきます。しかし、それらの情報を単に覚えて欲しくて紹介しているのではありません。あくまで読者の皆さんの理解を促すことが目的です。「覚えなきゃいけないのかな」と不安にならないでくださいね。
ドラッカーも著書「ポスト資本主義社会」の中で「(知識は)知識であることを行為によって証明されなければならない。今日われわれが知識とするものは、行動のための情報、成果に焦点を合わせた情報である。」と語っています。たとえば、プログラミングに関する概念であれば、それを理解することであなたの書くプログラムの品質は上がるのかどうか？あなたがプログラムを書く生産性は上がるのかどうか？これが重要なのです。
つまり、この本の目的は別の言葉でいえば「重要な概念を理解させ、生産性を高める」です。 一般的に知識は抽象度が高まるほど応用できる範囲が広がるので、この章ではまずは生産性とは何かから考えなおしてみましょう。
.. 知識創造の方法論 P45 .. ポスト資本主義社会 P62
生産性とは何か？
================
生産性と知識の関係
生産性とは何でしょうか？話をわかりやすくするために、まずは大昔の「石を運ぶ」という仕事について考えてみましょう。この場合の生産性は「1日でどれだけの量の石が運べるか」で測ることができます。「他の人の10倍の石を運べる人」はいません。生産性に大差のない、平等な時代でした。
時代は進んで人類は色々なものを発明しました。例えばトラックです。トラックがあれば、単位時間あたりに他の人の10倍以上の石が運べます。* もし運んだ石の量に応じてお金がもらえるなら、トラックを持っている人は他の人の10倍以上のお金をもらえるわけです。 これが「装置による生産性向上」です。
この時代、装置はとても高いもので、お金持ちの資本家しか持つことができませんでした。そこで資本家は装置を労働者に貸して仕事をさせ、得られた利益の一部を受け取ることで働かずにお金を得るようになりました。この状況を見て、マルクスは「このままでは格差がどんどん広がり、階級闘争が激化して共産主義革命が起きる」と予測しました。 ** しかし、実際には大部分の国で革命は起きませんでした。これはいったいなぜなのでしょう？
こんな思考実験をしてみましょう。ここに経験豊富なプログラマAがいるとします。 彼と同じ体格・同じ頭脳で、ただしプログラミングの知識だけが全くない人Bを連れてきて、 プログラミングの仕事をしてもらいます。成果はどの程度変わるでしょうか？
Bさんが10時間掛けても、Aさんの1時間分の仕事すらできないことでしょう。生産性は桁違いです。この生産性の差こそ「知識による生産性向上」です。 マルクスの考えには「労働者に装置を与えればそれだけで生産性が向上する」という仮定が入っていました。 しかし科学の進歩に伴い、装置は複雑になりました。装置を適切に操作して成果を上げるために、知識が必要とされるようになりました。 同じ装置を与えても、知識がある人とない人では生産性が桁違いになるようになったのです。
.. * トラックより前に蒸気機関や馬車鉄道の発明があるのですが、鉄道を個人が所有することはイメージしにくいと考え割愛しました。 .. ** 「資本論」(1867年)
知識こそが経済活動の主役になる
装置は資本家の持ち物で、どんなに使っても資本家のものでした。しかし、知識は労働者個人の中に蓄積されます。 あなたが転職するときに、会社の所有している装置を持っていくことはできませんが、頭の中の知識は持っていくことができます。 ドラッカーは「テクノロジストの条件」の中で「知的労働者は生産手段を所有する。頭のなかにしまい込んだ知識は持ち運びできる。」 * と語っています。現代はそういう時代です。生産手段を持っているのは労働者自身なのです。
読者のみなさんは、「革命によって資本家を倒して幸福になる」のと「勉強によって知識を身につけ幸福になる」のと、どっちが簡単だと思いますか？もちそん、後者ですね。だからこそ、このような本を読んで知識を獲得しようとしているわけです。
ドラッカーはまた、これからの時代は知識こそが経済活動の主役になると述べています。そして知識労働者の生産性を向上させるための条件を挙げています。 **
- 知的労働者の生産性を向上させるための条件は大きなもので6つある
- 1) タスクの目的をみずから明確にする( [[目的の明確化]] )
- 2) 自分自身をマネジメントし、 [[自分の生産性向上に責任を持つ]]
- 3) 継続的に変化を起こす
- 4) [[みずから継続的に学び、人に教える]]
- 5) 「[[知的労働の生産性は量ではなく質]]」と理解する
- 6) 「[[知的労働者は組織にとって富を生み出す資本財]]」と理解し、みずから組織のために働くことを欲する
筆者はこの6つの中で、特に「目的の明確化」「自分の生産性向上に責任を持つ」「みずから継続的に学び、人に教える」が重要だと考えています。 この章でこの本を読む目的について書いているのは「目的の明確化」です。目的を生産性の向上としたのは、学習が「自分の生産性向上」のために行うものだという考えです。そして「継続的に学び、人に教える」こそが筆者がこの本を書いている目的なのです。
もしかすると、みなさんの中には「教育を受けるのは学生や新入社員がすることだ」と思っている方もいるかもしれません。 しかし、ドラッカーは「知識はその絶えざる変化のゆえに、知識労働者に対し継続学習を要求する」 *** とも述べています。 そして、今後ますます知識の重要性が高まり、それによって、高度な知識を持っている人が、他人に教育をし、かつ他人から教育を受けるような社会になるだろう、と述べています。
今、勉強会に注目が集まっています。 勉強会とは、簡単にいえば社会人が平日夜や土曜日・日曜日に自発的に集まって、自分たちの興味のある分野について情報を交換する会です。 まさに「高度な知識を持っている人が、他人に教育をし、かつ他人から教育を受ける」場です。 勉強会情報の集積サイト「IT 勉強会カレンダー」 **** を見ると、毎日どこかで勉強会があり、 土曜日などは30〜40件の勉強会が行われていることがわかります。 ***** きっと「自分の生産性を向上させるためには、みずから継続的に学ぶことが必要だ」と感じる人が増えてきているのでしょう。
.. * 「テクノロジストの条件」 P.85 .. ** 「テクノロジストの条件」 p.80 野中郁次郎「知識創造の方法論」p.16 を参考に一部わかり易い表現に変更した。太字は筆者による。 .. *** 「テクノロジストの条件」 p.118
.. **** IT 勉強会カレンダー
- https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com .. ***** この本を執筆している2011年12月時点での値
学習効率を高めるための学習
さて、ここまでは知識を得ることの目的や必要性を学びました。つまり「why」です。「なぜ学ぶか」です。 ここからは「how」を、つまり「どう学ぶか」を学びましょう。
プログラマの成長は指数的
「プログラマの成長は指数的なところがある。プログラミングができるようになればなるほど，単位時間あたりに学べることが多くなる．」
これはScheme処理系の一つ「Gauche」を開発した川合史朗さんの言葉です。筆者の好きな言葉の一つです。* しかし、一見ポジティブなこの言葉ですが、筆者はとても恐ろしい内容だと思います。 それは「単位時間あたりに学べることが増える」かどうかは、学び方によって異なるからです。 たとえば、まる覚えのような学習の仕方では、単位時間に学べることは増えないですね。 図1は指数的に成長しているAさんと、線形に成長しているBさんの知識量のグラフです。 Aさんの知識が指数的に伸びたために、Bさんとの知識量の比はどんどん大きくなっています。 同じように時間を割いて、努力して学習しても、指数的に成長できた人と、できなかった人では、大きな差がついてしまいます。
図: 指数的に成長する人と線形に成長する人
指数的に成長するには、単位時間に学べる量を増やさなければいけません。 どうすれば単位時間に学べることが増えるでしょうか？ つまり、学習というタスクの生産性を高めるにはどうすればいいのでしょう？ ここまでの章では、タスクの生産性を高める方法について学んで来ました。 ここからはより具体的な学習というタスクの生産性について考えていきます。
.. * “Route 477 - gauche.gongでLTしました , 第2回gauche.nightログ おまけつき” http://route477.net/d/?date=20080309
時間は有限、何を学ぶか
人生の中で学習に使える時間は限られています。学ぶ価値のあることすべてを学ぶことは不可能です。 つまり、目的達成のために何を学ぶか、そして何を学ばないか、という意思決定が必要になります。 これは避けられないことです。すべてを学ぶことは不可能なのですから。
「何を選んだらいいかわからない」という気持ち、 「誰かに正解を教えてもらいたい」という気持ち、よくわかります。 何を学べばいいかを教えてくれる人はたくさんいます。 例えば大学の情報科学の学科では、「情報科学の研究者になる」という目的のために学ぶべき知識をカリキュラムとして組んでいることでしょう。 社内教育があるなら「弊社の社員として成果を出す」という目的のために学ぶべき内容が選択されているでしょう。 ネット上では例えば「自分の使っている言語Xのユーザ数を増やす」という目的のために「言語Xを学ぶべき」と言う人もいるでしょう。
他人の行動は他人の目的に基づいています。他人の目的は自分の目的と一致するとは限りません。一致するなら採用すればよいでしょう。 一致しないなら捨てるべきでしょう。結局、自分の人生を生きるためには、自分の目的に合わせた取捨選択が必要なのです。
どの言語を学ぶか
「プログラミングを学びたいのですが、どの言語を学べばいいですか？」よく見かける質問です。
いろいろな人が「言語Xを学んでおけば安泰だ」や「今後はこの分野が伸びるから言語Yを学んでおくと有利」などとアドバイスをくれるでしょう。
しかし未来は誰にもわかりません。人が未来を予想する時、そこには願望が混ざりがちです。そして予想が正しいかどうかは、未来が来るまで誰もわかりません。
ここで、ある言語Xの紹介文を紹介しましょう。一部のキーワードは伏字にし、引用部だけで意味が取れるように言葉を補ってあります。
> (他の言語は)かなり専門的な知識を必要とするので、その利用には限界がある。これに対して、実務担当者や管理者が必要な情報を必要なときに短時間で得るための使いやすい道具として、Xなる言語が注目されるようになってきた。ここ2,3年の間に、エンドユーザー部門を中心として、言語Xを利用する企業の数が米国を始めとして急速に増加しつつあり、(先導的な役割を果たした会社)Yの社内では過去数年に年間50%以上の割合で言語Xの利用者が増え、米国Y社では全社員の16%に相当する25000名以上の社員が日常の業務に何らかの形で言語Xを活用している。(中略)企業の生産性向上の手段として言語Xがますます有効とみなされる。
この言語Xは何でしょう？将来有望そうな言語ですね。あなたが今もし「言語Xを学ぶといいよ」と言われたら学んでみますか？
この文章は、実は結構古く、1978年に日本情報処理学会の会誌に書かれたものです。1978年といえば、のちにC言語のバイブルと呼ばれるようになる「The C Programming Language」が出版された年です。その後C言語が広く使われるようになったことは皆さんご存知のとおりです。
この言語Xは、IBM(Y社)が1964年に公開した、APLという言語です。今となっては需要が激減してとてもマイナーになってしまいました。
あなたがもしこの時代に生きていて、誰かに「APLを学ぶといいよ」と言われたら学んだでしょうか？
.. APLがどれくらいマイナーなのかを、求人サイトDice.comで検索して調べて見ました。
- 2011年の現在では、APLに言及のある求人は2件しか見つかりません。
- Javaが17360件、Pythonでも3006件あるのと比べるといかに少ないかわかるかと思います。
歴史は繰り返す
~~~~~~~~~~~~~~
「[[賢者は歴史から学び、愚者は経験から学ぶ]]。」 これはビスマルクの言葉です。今も昔も人の世、人間が社会を動かしています。似たシチュエーションに置かれた人は似た行動をとります。その結果、歴史は似たパターンを繰り返します。歴史から学びましょう。未来はわかりませんが、過去ならわかります。
APLの話は古臭いと感じる人も多いでしょうから、もう一つ、比較的新しい例を上げましょう。Adobe Flashとスマートフォンについてです。
FlashはMacromediaが開発しAdobeが買収した、ウェブ上でマルチメディアを用いたコンテンツを作る技術の一つです。
一時期、とても盛り上がっていた時代がありました。広告、企業のトップページ、YouTubeでもFlashが使われていました。
2007年、Appleがスマートフォン(iPhone)を発売し、大ヒット、スマートフォンというプラットフォームが拡大しました。
そして、AppleはiPhoneにはFlashを搭載しないと発表しました。
代わりにオープンな規格であるHTML5、JavaScript、CSSを後押しする方針です。YouTubeも既にHTML5に対応済みです。
.. YouTube: 2005年に設立された動画共有サイト
このままFlashが衰退して、Flashのためのプログラミング言語ActionScriptを勉強してきた人が悲しい思いをするのでしょうか。
それともスマートフォンにFlashが搭載されるようになるのでしょうか。
結論がどうなるのか、まだ筆者にはわかりません。この変化は現在進行形なのです。 *
.. * 2012年5月現在で、iPhoneと競合するスマートフォンAndroidにもFlashが搭載されず、Microsoft Windowsの新しいMetro UIにもFlashが搭載されず、とFlashの旗色は悪くなるばかりですが…。
しかし、このような新しいプラットフォームが古いプラットフォームを駆逐する現象は何度も繰り返されてきました。
プラットフォームの利用にはメリットがあります。そのメリットを享受するために大勢の人がそのプラットフォームを使うようになります。しかし、プラットフォームのシェアが大きくなると、そのプラットフォームに独占されることを嫌う力や「そのプラットフォームではできないことをしよう」という力が働くようになってきます。そして古いプラットフォームから人が逃げて、新しいプラットフォームが作られます。
このように、言語もプラットフォームも変わりゆくものです。あなたの使っている言語も衰退するかも知れません。そしてそれを今知ることはできません。言語が衰退した時、その言語に特有の知識は価値を失ないます。「どの言語を学べばいいのか」という質問に対する答えは「どの言語を学んだとしても、その言語に特有な知識は、言語の衰退と共に陳腐化する。だから言語に特有の知識ばかりを収集するのではなく、他の言語と比較して、よりメタな知識へと昇華する必要がある」となるでしょう。
この本では「言語を比較して、特定の言語に特有の知識ではなく、よりメタな知識へと昇華していく」というプロセスも理解してもらえたらと思っています。 *
.. * この本で使われる「メタ」という言葉がわかりにくければ、抽象的・一般的・汎用的などと読み替えるとよいでしょう。元々は「上の」という意味の言葉です。
効率の良い学習方法とは？
------------------------
どうすれば効率の良い学習ができるのでしょうか？
例えば英語力をつけたり、速読を習得したりすれば、情報をインプットする速度は上がるでしょう。しかし、情報を脳に入れることと、理解して使えるようになることは別物です。目的を見失わないようにしましょう。目的は「たくさん覚えること」ではありません。あなたの生産性を高めることが目的です。
具体的なハウツーは、すぐに生産性を高めます。しかし、ターゲットが変わると使えなくなります。世界は今後も変わっていくので、具体的なハウツーばかり学んでいたのでは、どんどん失われてしまいます。応用範囲の広い、抽象的なメタ知識を身につける必要があります。深い理解が必要です。
一方で、抽象的なメタ知識だけをトップダウンで学んでも、自分の中でしっくりと落ち着きません。
桜の花が欲しいからといって、花の咲いている枝を切り取って持ってきても、それっきりです。
毎年花を咲かせ続けるには、幹や根がなくてはなりません。
----------------------------------------
抽象的な知識だけを取り込んでも、自分の中にしっくりと落ち着かない。
----------------------------------------
自分の中で他の知識と結合しなければ、
入ってきた知識をオウムのようにそのまま吐き出すことしかできません。
それでは状況に応じて知識を活用することなんてできません。
具体的な知識を集めるだけでなく、深く理解し、自分の中でメタな知識へと昇華していく必要があります。
どうすれば、知識をよりメタな知識へと昇華していくことができるのでしょうか。
ここでは理解のプロセスを以下の3要素に分けて説明します。この3つの要素を繰り返して理解が深まっていきます。
- - 噛み砕く
- - 結合する
- - 出力する
世の中の知識の大部分は関連し結合しあっています。
結合・関連しあった知識は、一度にまとめて入力することができません。
まずは噛み砕いて知識の断片に変え、飲み込み、自分の中で結合しなおす必要があります。
----------------------------------------
----------------------------------------
噛み砕く
--------
大きな肉を一口で食べることはできません。まずは口に入るサイズに切り取って、噛み砕き、飲み込む必要があります。
理解に関しても同じです。難しい概念や、複雑なシステム、不慣れな分野について、いきなり習得することはできません。
まずは一つ一つの情報の断片を自分の中に取り込んでいくことしかできません。
----------------------------------------
図: 噛み砕く
----------------------------------------
しかし、膨大な情報の中から何を取り込んでゆけば良いのでしょう？どうやって選べばよいのでしょう？
どの情報が重要かを判断するためには、その分野を深く理解する必要があります。これではニワトリとタマゴの関係です。
その分野に詳しい知人がいるなら、教えてもらうのもひとつの手です。
しかし、その人が本当に詳しいのかどうか、あなたはまだ判断する力を持っていないのです。
こういうときに使える戦略が3つあります。
戦略1: 必要な順に
目的のために必要なところからつまみ食いする、という戦略です。
多くの場合、本やドキュメント全体をしっかり読む必要はないものです。 目的が明確で、かつその目的達成のためにどこを読めばいいかがわかっているなら、 他のページのことは気にせずにそこを読んでしまいましょう。
全部読まずにつまみ食いをすることに罪悪感がある？ そうですね、ならば自分がその文章を10ページ読むのにどれくらい時間がかかるか計測して、 全体を読むのにどれくらいの時間がかかるか見積もってみましょう。 「全体を読む」という目標を立てる事自体は悪くありません。 苦痛なく全体が読めるのならそれもよいでしょう。 問題なのは、全体を読むのにどれくらいのコストが掛かるか考えないことと、 ただなんとなく「読むのが大変」と思って、読む気をなくすことです。 時間とモチベーションはお金を払って買ってくることができません。
この戦略を使うには読みたいものがどこにあるか、おおよその全体像がつかめている必要があります。 つまみ食いしようにも、どこを読んだらいいかわからないことも多いですね。その時は次の戦略です。
戦略2: おおまかに
おおまかに全体像をつかみ、徐々に細かく掘り下げよう、という戦略です。
たとえば、ポール・R・シーリィ は、本をいきなり頭から読むのではなく、
まずは目次などを読んで、ざっくりとイメージをつかむことをすすめています。
また、青木峰郎 は、ソースコードをいきなり読み始めるのではなく、
まずはディレクトリ構造を眺め、徐々に細かい単位に読み進めることをすすめています。
おおまかに読む戦略はなにがいいのでしょう？
前の節で解説した「必要なところから読む戦略」が使えなかったのは、どこに何があるかがわからなかったからです。
おおまかによむ戦略では、細かいところをじっくり読む前に、どこになにがあるかをざっくりとつかみます。
あとは必要になところ、じっくり読むべきと思ったところだけをじっくりと読むのです。
ポール・R・シーリィはさらに過激に「文字が識別できない状態で眺めるだけで無意識に情報が蓄積される」と主張しています。
この主張は検証できないので賛成も反対もしかねます。
しかし、教科書を買ってきても、読まずに積んでおいても何も得るものはありません。
放置するくらいなら「めくるだけでいいんだ、読まなくていいんだ」といいきかせて、
一通り全部のページを眺める方が、まだ得るものはあるかも知れませんね。
また、多くの本は重要なことを何度も繰り返して書く傾向があるので、
ざっと眺めた時に何度も繰り返されていて目についた内容が、
まさにその本の一番重要な情報であるということも多いです。
一方で、筆者はこの「おおまかによむ」戦略との相性が悪いものがあると思っています。
それは数学です。数学などは、1章で説明した内容を使って2章の説明を圧縮し、
1章と2章の内容を使って3章を圧縮し…と圧縮を繰り返して濃縮されています。
そのため1章の内容や導入された記号を理解せずに2章を読んでも意味のわからない記号の羅列にしか見えません。
意味のわからない記号の羅列は眺めていても頭に入りません。
「おおまかに読む戦略」も万能ではないのです。
.. あなたもいままでの10倍速く本が読める ポール・R・シーリィ (フォトリーディングを提案した書籍)
.. Rubyソースコード完全解説 青木 峰郎 / 絶版なのでこちらで読めます: [http://i.loveruby.net/ja/rhg/book/](http://i.loveruby.net/ja/rhg/book/)
戦略3: かたっぱしから
上の2つの戦略を知った上で、それでもまだどこから学び始めるかを決められない場合があります。
それは、あなたが決めるための判断材料を持っていないからです。 目的のために必要な情報がどこにあるのかわからない。 目的を明確に立てられるほどこの分野のことを知らない。 そういう状況では「何からやれば効率がいいか」などと考えるだけ無駄です。 それを判断するための情報を持っていないのですから。
そこで、まずはかたっぱしから読みます。
特にプログラミングの本であれば「写経」と呼ばれるテクニックが知られています。 教科書に出てくるソースコードを、理解できるできないに関係なく、とにかくキーボードで入力するのです。 未知のコードは意味不明な記号の羅列に見えることでしょう。 この状態では読んでいるつもりでも頭に入らずに素通りしています。 自分は読んでいるつもりでも、眺めているだけに過ぎないのです。 そこで、意味不明であっても手を動かして、キーボードで入力することで一度頭に入れるのです。 そうしているうちに、意外と理解できるようになっていたりします。
この泥臭い作業を続けるのは、けっこう心の強さを要求されます。 よく、途中で心が折れて投げ出してしまいそうになります。 努力と結果が比例しないからです。10時間写経をすれば必ず写経した言語の理解ができるかというと、そういう保証はありません。 どんなに努力をしても結局何もわからないかも知れません。これでは達成感が得られません。 そこで、時間やページで達成可能な目標を設定するのがおすすめです。 例えば「今から30分よそ見をせずに写経をする」や「今日は1章1節の数式を書き写す」などです。 これは努力によって達成でき、達成感を感じることができます。 理解を目標にしてはいけません。何も理解出来なくても、それは理解の難しいターゲットに挑んでいるのだから仕方がないのです。 むしろ、単に書き写しているだけでなにか理解できたら、それはラッキーだと喜びましょう。
結合する
さて、未知の分野について、情報を一口大に切り取って飲み込んだとしましょう。 この情報はどうやってあなたがもともと持っていた知識と結びついて理解されるのでしょう。
図: 結合する
これは謎です。 情報を飲み込んだ時に、すぐに持っていた知識との関連性に気付くこともあります。 しかし、しばらくたってから、全く無関係なことをしている時に気付くこともあります。 寝て起きたらなぜか理解している、ということも起きます。
理解は、どうも意識の外で行われているようです。 理解の材料を脳に詰め込むところまでは意識して行うことができます。 しかし詰め込んだら、それが結合するまでは、運を天に任せて待つしかありません。 焦っても意味がありません。
「今日は◯◯を理解しよう」という目標設定がいかにまずいかわかりますね。 理解が起きるのにどれくらいの時間がかかるのか、だれも見積もることができません。 どんなに頑張ったとしても、運が悪ければ理解に至れません。努力しても報われないのではヤル気がでません。 理解を目標にしてはいけません。目標は努力すれば達成できる、例えば「今日は◯◯を読む」などにするべきです。
情報の結合を効率化する方法はないのでしょうか？運に任せるしか無いのでしょうか？ はい、究極的には運に任せるしかありません。確実に結合を起こせる方法は知られていません。 しかし、まったく改善の余地がないわけではありません。 文化人類学者の川喜田二郎は、どうすれば情報の結合を意識下で行えるか、効率化できるかを研究し、KJ法を提案しました。 KJ法はカードや付箋に情報を書いて、それをテーブルなどの上に広げ、一覧して見ることができるようにします。 そして、関連がありそうなカードを物理的に集め、そのグループを表現するカードを追加します。 つまり、情報を脳の中に詰め込んで自然に結合が起きるのを待つ代わりに、 情報を見える化して、全体を眺めながら結合しようという戦略です。
忘れてはいけないことを忘れないようにすることは意外と脳の負担になっているのでしょう。 KJ法にかぎらず、脳の中にある情報をとにかく外に出して、紙などの消えない媒体に記録しよう、という戦略は 脳を忘れないようにする負担から解放することができます。
また、KJ法では物理的に並べられたカードから図を作り、それを文章で表現し、それをまた図にし、とフォーマットの変更を繰り返します。 筆者の経験では、フォーマットの変換も結合を促します。 図を文章にしたり、文章をスライドにしたり、日本語を英語にしたり、と表現の方法を変更する過程で、 今までとは違った視点で情報を観察することになり、その結果いままで気づいていなかったものに気づくのです。
.. 川喜田二郎「発想法 - 創造的開発のために」中公新書 P54
出力する
ある時、あなたは「理解できた」と感じます。さて、それは本当に正しい理解なのでしょうか？
「理解できた」という実感は、あなたの中で知識がつながったということしか意味しません。 その理解(つなぎかた)が正しいかどうかはあなたには判定できません。 正しいかどうかを判断できる能力がまだ存在しないからです。 理解が正しいかどうかは、あなたが正しく出力できるかどうかでしか測ることができません。
図: 出力する
あなたがどんなに「自分は理解している」と思っていても、 その理解に基づいてコードを書いて、実行してみて、 意図したとおりの結果が得られなければ、それは正しい理解ではありません。 もちろん、意図した通りの結果が得られたとしても、 だからといって理解が正しいという保証が得られたわけではありません。 たまたまあっているだけかも知れません。 出力とその結果の観察を通して、少しずつ「ただしそうな理解」に 精錬していくことしかできません。
出力はソフトウェアを作ることには限りません。ブログに記事を書くのも、勉強会で発表するのも出力です。 出力とは、自分の脳の中でつながった知識を、一度切り離して取り出し、自分の外でもう一度構造化することです。 プログラマは恵まれています。 コンピュータに「間違っている」と言われた場合、かなり高い確率で間違っているからです。
どんなに理解できたつもりでも、出力した結果が他の事実と矛盾するなら、その理解は間違いです。 また、出力をすれば「自分は何がわかってないか」がわかります。 自分の知識ネットワークの、弱いポイントがどこなのかがわかります。 そこを強化することで、理解はよりしっかりしたものになります。
まとめ
噛み砕いた知識を結合し、結合して得られた理解を出力して確かめ、そして外界からのフィードバックを元にまた知識を噛み砕く。 この3つの要素を繰り返すことによって、理解が深まるのです。
図: 理解のサイクル
この章の冒頭で引用した、長尾真の「「わかる」とは何か」から、あらためて長めに引用します。「文章を理解するということは、書かれている内容を読者が自分のなかに再構築することである。これは、再構築したものを他人に説明するといった形で外部に出すことによって、もっともよくおこなわれる。その過程で、理解できていなかった部分が明らかになり、再度もとの文章を読みなおしたり、質問したりすることが必要となる。つまり、対話という過程が大切となるのである。」 （長尾120～121頁）
次の章で実際にこの考え方をプログラミング言語の学習に適用するとどうなるかの実例を紹介します。