コードの外まで読む

学びがすべて授業の形をしている必要はない

技術書は必要です。APIを理解したいとき、クエリを直したいとき、あるツールの仕組みを学びたいときには、正確なドキュメント、実行できる例、難しいケースをごまかさない説明がほしい。小説はその代わりになりません。エッセイも、テストや実践、実際にソフトウェアを作る仕事の代わりにはなりません。

ただ、プログラマーが考えるべきことを、マニュアルに収まる範囲だけに狭めるのは貧しいと思います。

技術書はたいてい、道具やモデルを教えてくれます。物語を読むと、不完全な情報としばらく一緒に過ごすことになります。登場人物には公式ドキュメントがありません。動機は矛盾していることもある。第3章では不可解だった判断が、ずっと後になって別の意味を持つこともあります。私は観察し、覚えておき、まだ答えが全部そろっていない状態を受け入れなければなりません。

チュートリアルをなぞるのとはかなり違います。でも、無駄な経験ではありません。ソフトウェアでも、不完全な要件、同じ言葉を違う意味で使う人たち、誰も記録していない過去を抱えたシステムを相手に判断します。物語を読めば複雑なアーキテクチャが解ける、と言いたいのではありません。まだ筋が通らないものを急いで片づけずに待つ。その練習には価値があると思っています。

エッセイがくれるものは少し違います。誰かが考えをどう整理し、根拠を示し、反論を認め、どこまでを自分の主張とするのかを見られます。結論に同意できなくても、議論の組み立て方から学べることはある。私にとって、この違いは大切です。読書は他人の結論を集めることではありません。その結論にどうたどり着いたのかを見ることでもあります。

意見を変える気まずさ

私が薦めたい本の一冊に、アダム・グラントの『THINK AGAIN 発想を変える、思い込みを手放す』があります。考え直すこと、自分の意見を疑うこと、学んだものを手放すこと、謙虚さと好奇心を保つことに焦点を当てている点が気に入っています。知性があれば間違いを避けられる、とは書いていません。むしろ、頭の良い人ほど、間違った考えを巧みに守れることがあります。

これはプログラミングの世界で、とても見覚えのある話です。言語、エディタ、OS、フレームワークについての会話を覗けばすぐにわかります。いつの間にか、ある判断について話すのをやめ、自分のアイデンティティを守り始めることがある。プロジェクトに何が必要かではなく、自分の好きな道具こそ最初から正解だったと証明したくなるのです。

ある言語をからかう動画を見て以来、何か月も「その言語は駄目だ」と言い続けていたとします。その後、その言語を選ぶのが妥当なプロジェクトに出会ったら、意見を変えられるでしょうか。それとも、間違いを認めずに済む理由を20個探すでしょうか。経験豊富な人のアーキテクチャをまねたものの、自分のプロジェクトでは部品が噛み合わなかった場合はどうでしょう。見直すのか、それとも最初の判断を守るためにレイヤーを増やし続けるのか。

笑いものにするための例ではありません。意見を変えるのは難しい。私にとっても同じです。だから私は、見せびらかすための新しい確信ではなく、自分が知っているつもりのことを見直すための、より良い問いをくれる本を大切にしています。

小説を読んでも対人関係の超能力は身につかない

聞こえはいいけれど、あまりに簡単に繰り返される主張があります。その一つが、小説を読むと共感力が高まるというものです。わかりやすく、共有しやすく、読書を心のビタミンのように扱えます。ただ、そこまで強く言えるほど証拠はそろっていません。

ダイアナ・タミールとデイヴィッド・ドデル＝フェダーが2018年に発表したメタ分析では、フィクションを読むことと、社会的認知の一部の指標との間に、統計的に有意ではあるものの小さな効果が見つかりました。効果量は g = 0.15から0.16程度です。これは、小説を読めばその人の人格が変わると証明したことにはなりません。

その後のレビューでも結果は一貫しておらず、因果関係の特定や一部の結果の再現には問題が残っています。特定の読み方が、特定の測定値に少し影響する可能性はあります。一方で、もともと特定の能力や関心を持つ人が、フィクションを多く読むだけかもしれません。この二つを切り分けるのは簡単ではありません。

私は控えめな言い方を残したい。いくつかの研究では、社会的認知の一部の指標に小さな効果が見つかっている。それだけです。フィクションを擁護するために、証拠を大きく見せる必要はありません。物語に引き込まれたり、落ち着かなくなったり、考えたことのなかった視点に出会ったりする。その経験を自分の成長率として数字にできなくても、十分です。

結びつけられる記憶を増やす

何かを作ろうとするとき、私たちは何もない場所から始めるわけではありません。すでに記憶にある概念、イメージ、問い、経験を結びつけます。だから、違う分野やジャンルを読むことは、新しい関連を見つけるための材料になりえます。

大事なのは「なりえる」という部分です。小説を20冊読んでも、優れたアイデアが20個生まれる保証はありません。心理学の本を棚いっぱいに並べても、誰のことでも理解できる人にはなりません。創造性は、本を一冊読むたびに確実な報酬が加算されるポイントカードではないのです。

それでも、触れる情報が狭すぎると、使える比較も少なくなると私は思います。プログラミングのチュートリアルだけを読んでいれば、参照するものも別のプログラミングチュートリアルに偏るでしょう。歴史、物語、科学、エッセイ、心理学を読むと、対立を表す方法、時間を並べる方法、システムを見る方法、誰かがなぜそう行動するのかを問う方法が増えます。

そのつながりの一つが、わかりやすいインターフェースにつながるかもしれません。技術者ではない人に判断を説明するときに役立つかもしれない。目に見える成果は何もなく、ただ午後の時間に寄り添ってくれるだけかもしれません。どれも私には価値があります。

書くと、考えがどこで途切れているかわかる

読むと、他人の思考をたどれます。書くと、自分に本当に考えがあるのか確かめることになります。

頭の中にあるうちは、考えが完成しているように見えます。ところがページに書こうとすると、穴が見つかる。定義できない言葉を使っている。根拠がないから同じ結論を繰り返している。途中で何が起きたのかを説明せず、問題から解決策へ飛んでいる。書くことで、そうした欠けた部分が目に見えるようになります。

限られた研究ですが、興味深い方向を示すものもあります。2007年に大学の生物学専攻の学生を対象に行われた研究では、一部の作文課題によって、その文脈での分析力と推論力が向上しました。これは一つの具体的な結果であって、普遍的な法則ではありません。日記を書けば、誰でもどんな分野でも優秀になると証明したわけではない。それでも、書くことは完成した思考を見せるだけでなく、考える作業そのものにもなりうると教えてくれます。

数か月前、私はとても大切な人に捧げるため、El tiempo que compartimosを書きました。そして約1か月半前、同じ人のためにもう一冊、De mí para ellaを書きました。実績として持ち出したいわけではありませんし、成果の物語に仕立てるつもりもありません。自分のために書くことは、仕事や成績、出版とは関係のない場所にも存在できる。そのことを伝えたくて挙げています。

一つの場面を書いてもいい。送らないと決めた手紙でもいい。学んだばかりのことを説明しても、まだ答えのわからない問いを書いてもいい。有名な作家をまねることが目的ではありません。自分が何を考えているのかをもう少し長く見つめ、説明できることと、ただそう思い込んでいたことの境目に気づくためです。

これはコードにも関係します。難しい言葉に隠れず、なぜその解決策を選んだのか説明できないなら、まだその判断を十分に理解していないのかもしれません。書いたからといって、推論が正しくなるわけではない。ただ、考えが完成しているふりはしにくくなります。

読書がまた一つのスコアボードになるとき

読んだ本を記録したり、ページに印をつけたり、読書チャレンジに参加したりすること自体には何の反対もありません。問題は、記録することが読書体験を食い始めたときです。

連続記録があれば、忙しい週でも本を開くきっかけになるかもしれません。一方で、数字を途切れさせないためだけに短い本を選ぶようになることもある。リストは興味のある本を覚えておくのに役立ちます。でも、自分を責める未完了タスクの列にもなります。要約すれば考えが整理されることもある。ただ、その後にコンテンツを作ることばかり考えながら読むようになるかもしれません。

自己決定理論では、自律性、有能感、関係性が動機づけにどう関わるかを扱います。この枠組みでは、統制や一部の報酬が内発的動機を弱める場合があります。すべての目標が悪いという意味ではありません。好きで選んだ活動が監視されているように感じ始めたとき、何が起きているのか見た方がいいということです。

連続記録が助けになるなら、使えばいい。不安を感じながら読むようになるなら、手放していい。40ページで読むのをやめたくなっても、架空の法廷で弁明する必要はありません。次の本に進まず、知っている本を読み直したいなら、それも読書です。アプリが祝ってくれなくても変わりません。

人の営みを取り上げ、成果を証明するよう迫る指標にはうんざりします。一年に何冊読んだか。一日に何ページ進んだか。使えるアイデアをいくつ得たか。測ることでわかることはあります。でも、何に価値があるかまで数字に決めさせるべきではありません。

良かった点

• 物語の中では、疑問や矛盾、不完全な情報と、答えを急がずに過ごせます。
• エッセイでは、結論に同意できなくても、別の人が考えを整理し、議論を組み立てる過程を見られます。
• 違う分野を読むと、結びつけられる参照先が増えます。ただし、役立つ成果が出る保証はありません。
• 書くことで、まだ明確に説明できない部分と向き合えます。
• 楽しみとしての読書には、仕事にも学校にも指標にも属さない場所があります。

懸念点

• 読書の勧めが、プログラミングの学習に遅れていると感じている人への新しい義務になってしまうこと。
• 小規模な研究や結果の混在した研究を使い、共感力、創造性、批判的思考が自動的に身につくと約束すること。
• 技術書ではない本を、生産性を上げる秘密の道具として扱うこと。それでは同じ問題に別の服を着せただけです。
• ドキュメントと実践を軽視すること。コードの外を読むのは、それらを補うものであって、置き換えるものではありません。
• 多くの本を読み終えたことと、理解したこと、楽しんだことを混同すること。

今のところの私の考え

もしあなたが10代でプログラミングを学んでいるなら、本気であることを証明するために、毎日の午後をコースで埋める必要はありません。ドキュメントを読み、練習し、壊し、テストを書き、プロジェクトを作る時間は必要です。それは変わりません。

物語の続きが知りたいという理由だけで、小説を読んでもいい。頭から離れない問いがあるから、エッセイを開いてもいい。心理学を友人の診断に使わず、慎重に学ぶこともできます。誰にも見せない文章を書いてもいい。

そうしたことが、自動的にあなたを優れたプログラマーにするわけではありません。そうなる必要もない。視野を広げることで、考え直したり、概念を結びつけたり、自分の考えを説明しやすくなったりすることはあります。それでも、ときには一冊の本が、ただ気持ちのいい午後をくれるだけです。

それで十分です。すべての本が、指標を改善することで存在意義を証明する必要はありません。