『ファスト＆スロー』を読んで

『ファスト＆スロー』を読んだ。

ファスト＆スロー　（上）

ファスト＆スロー　（下）

上下巻に別れた大作でかなり読み応えがあった。

いろいろなところで、同じ内容が重複して書かれていて冗長に感じたが、『読みたい箇所だけ読めるように』という配慮からくるものなのだろう。

内容が多岐にわたり、かつ、示唆に富んでいたので本当は書きたいことはいろいろある。 けど、全部書くとかなり長くなりそうだ。最も印象的な『経験する自己』と『記憶する自己』についてだけ忘れないように書いておく。

喉元過ぎれば暑さ忘れる

ファスト＆スローでは人間の性質を３つの側面から論じている。

• 速くて直感型の『システム１』と、遅くて熟考型の『システム２』
• 完全に合理的な存在『エコン』と、合理的ではない存在『ヒューマン』
• 日々の出来事を経験する『経験する自己』と、それを記憶し思い出して評価する『記憶する自己』

３つめの『経験する自己』と『記憶する自己』について簡単に説明しよう。

経験する自己は日々の生活を経験する自己である。毎日、朝起き、仕事に行き、帰宅し、ご飯を食べ、ベッドに横になる、という日常を経験する役割を担う。 一方、記憶する自己はそれらの出来事を取捨選択して記憶する。また、後から出来事を思い出し、それを評価する役割を担う。

「喉元過ぎれば暑さ忘れる」という言葉が示すように、私たちは経験する自己を軽視し、記憶する自己を重視している。これは意図的に行われているのではなく人間に備わった性質である。そのため、この性質は根本的に変えることはできない。

その結果、長期間の緩やかな苦しみよりも、短期的な激しい苦しみを避ける傾向にある。経験する痛みの総和は後者の方が少ないにも関わらず、私たちは短期的な激しい痛みをとても嫌がる。

幸福に関しても、毎日の穏やかな少量の幸せよりも、短期的な激しい幸せを追求する。経験する幸福の総和は前者の方が多いにもかかわらず、短期的な幸福を選択しがちである。

人間の人生は一般的に長期であるため、総和を無視し、短期的な絶対量のみを追求するのは合理的ではない。この「合理的ではない」という点は本書のテーマの１つでもある。そう、人間は合理的ではないのだ。

（ちなみに、不合理という言葉はネガティブな印象が強すぎるため使わない、というのが筆者の考えである。経済的な合理性を真として、それで説明できない人間を不合理とするのはあまりに乱暴である、と筆者は主張する）

２つの自己の矛盾

確かに人間は記憶する自己を重視している。私が大学時代に所属していたサークルは練習が厳しく、理不尽な規則があることで有名だった。練習は強制参加で、自分の出場しない試合も応援として参加しなければならない。大学生活という人生で一番自由な時間を辛い経験に消費してなんの意味があるのだろう、と悩んだ。

先輩達は「卒業した時、絶対やってきてよかったと思える」と声を揃えていっていた。確かに、自分も振り返るとそう思っている節がある。最後の大会でサークルが優勝した時の嬉しさは格別だったし、今でもその光景は覚えている。

この本を読んでいて、あれがまさに記憶する自己の重視なんだ、と気づいた。

一方、年収750万円以上では生活の幸福度が上昇しない、という研究結果がある。これは直感に反するように思える。年収７５０万円の人と年収１億円の人が同じ幸福度なのか、と。

この研究での幸福とは『経験する自己』の幸福だ。大富豪も中流家庭も日々の生活はそれほど変わらない。朝起き、ご飯を食べ、夜寝る。これらの点は年収が750万円より上だとしてもそこまで大きな変化はない。

この研究結果を引用し、年収の増加による幸福を否定するような言説を目にする。しかし、この２つの自己にまで言及されていることは少ない。先に書いたようにこれはあくまで『経験する自己』の幸福であり、『記憶する自己』の幸福は明確に異なる。

『記憶する自己』は年収の上昇に伴ってより幸福になる、という研究結果が出ている。年収が10億円あればリゾートで素晴らしい体験を送ることができる。世界的な富豪であれば宇宙にだって行けるだろう。よりよい体験ができ、それらの思い出にふける時、記憶する自己はより幸福になる。

年収の増加によるこのような幸福の否定は、『記憶する自己』の否定でもある。

幸福になるには

人間の性質上、『記憶する自己』を過大評価する傾向は取り消せない。やはり『記憶する自己』は重要であり、年収７５０万円よりも年収10億円の方が幸福であろう。

しかし、『経験する自己』を過小評価しすぎると、日々のクオリティオブライフを下げることになる。私たちは『記憶する自己』を過大評価してしまうのだから、『経験する自己』をもう少しだけ大事にしてもよいのかもしれない。

Communicate!【The Pragmatic Programmer】

エンジニアとしてコミュニケーションは非常に重要だ。

エンジニアはコミュニケーションをとる必要があるし、上手にコミュニケーションできれば得るものも大きい。この章ではよいコミュニケーションを取るための心がけが挙げられている。

• 何が言いたいかを知る
• 相手を知る
• タイミングを選ぶ
• やり方を選ぶ
• 見栄えを良くする
• 相手を巻き込む
• 聞き役になる
• 素早く返答する

これらを意識してコミュニケーションすれば、きっと、素晴らしいコミュニケーションができるだろう。

---

最近、こういうことが書かれた他の本を合わせて読んでいて、コミュニケーションについてはすごく意識している。しかし、いろいろ考えすぎて自分の言いたいことがあまり言えなくなっている気もする。きっと、だんだん上達して慣れていくんだろうけれど、元来持った性質もあると思い、なかなか難しいなぁと感じている。

これで第１章は終わり。特に目新しいことは書いてなかった。あと、説明の仕方が少し回りくどいかな。２章以降も読もうとは思ってるけど、ブログにまとめようかは迷っている…。

Your Knowledge Portfolio【The Pragmatic Programmer】

知識ポートフォリオを構築して適切に管理しよう。 知識ポートフォリオは投資におけるポートフォリオと同じような視点で管理するとよい。各アイテムの間でバランスを取り、リスクの高いアイテムと低いアイテムを組み合わせよう。

ただし、もっとも重要なのは定期的に投資することだ。 定期的に知識に投資することが成功の秘訣だ。

具体的なアクションの一例を挙げる。

• 一年に一つ、新しい言語を学ぶ
• 本を読む。そして、それを習慣付ける
• 勉強会に参加し、ネットワーキングする
• 知識を常に最新に保つ

書籍や Web から得た知識を批判的に考察することも重要だ。 商業主義を甘く見てはいけない。

検索で上位に来るページが、必ずしも正しいとは限らないのだから。

Diversity

この本では、知識ポートフォリオにおける多様性の重要性を説いている。一方、Soft Skills では業界の専門性の重要性を説いていた。

業界の専門性を重視した方が自分をマーケティングしやすいからだ。

「Web の EC からエンタープライズまで手広く 10 年間やってました。」

というエンジニアよりも、

「不動産の法律業に関する IT 部門で 10 年開発してました。」

というエンジニアの方が自分をマーケティングしやすいでしょう、というのがその理由。

専門性を高めると需要は少なくなる一方、自分の価値は高まる。

専門化によって機会を失うことは増えるだろう。しかし、専門性を高めることでしか得られないチャンスが多くあるし、チャンスをものにできる確率が増える、とのこと。

自分は技術の多様性はある方だと思うが、業界の専門性が皆無なのでここはどうにかしないといけないと感じている…。

言語を学ぶ

一年に一度言語を学ぶことはとてもいいことだと思う。でも、同じような言語を学んでいると「学習」という観点からだと効果が少ないように思える。せっかくだから Go とか Swift ばかり触ってないで Prolog とかを触ってみるのがいいと思う。あと、「触ってみましたー」程度だと「何か新しい事をしている」という楽しみは得られる反面、技術的にはあまり得るものがないように思える時もある。

でも、『定期的に』新しいものを触る癖をつけるということがきっと重要で、ぐだぐだ言い訳せずに定期的に新しいものを触る癖をつけるべきだなぁ、と反省した。

Good-Enough Software【The Pragmatic Programmer】

完璧でバグのないソフトウェアはありえない。

だからといって悲観する必要はない。 ユーザーにとって、経営者にとって、そして私たちの心の平穏にとって、充分なクオリティというものが存在する。完璧でなくても充分よければそれでいい。

ユーザーは明日の完璧なソフトウェアよりも今日動く充分よいソフトウェアを欲している。 プログラマはいつプログラミングを終えるべきか常に考えなければならない。 充分よいソフトウェアを、今日ユーザーに提供しよう。

どうせ完璧なソフトウェアは存在しないのだから。

完璧を目指すのは悪か。

「明日の完璧なソフトウェアより、今日動くソフトウェアがほしい。」

この発想はこの本が書かれた当時よりも一般化していると思う。むしろ最近では『明日の充分よいソフトウェアよりも、今日の動くソフトウェア』を提供することが増えているように思える（根拠はない）。

完璧なソフトウェアを目指すこと自体は悪いことではないと思う。完璧を目指していれば、いつの間にか充分よいものになっていることが多い。とりあえず動くものを作っておけばよいというメンタリティで充分よいものはできない、と僕は思う。

ただ、この本が述べているように、「完璧なものになるまでリリースしない」という姿勢は良くない。常に完璧なものを目指しつつ、現実（納期や技術力）に負けて筆を置き、ユーザーの審判を受ける。というのが一番 Pragmatic な姿勢なのではないかと思った。

Stone Soup and Boiled Frogs【The Pragmatic Prigrammer】

石のスープ

戦争から帰ってきた兵士が村に帰ってきた。しかし、彼らは食料を恵んでもらえない。そこで彼らは湧いたお湯に石を入れ『あとは人参があれば美味しいスープができるのになぁ』とつぶやく。すると村人たちが興味を持ち、人参だけでなく様々な食材を持ち寄ってくれる。

最終的に兵士たちは石を取り除いて美味しいスープを食べました。めでたしめでたし。

この話が暗示するのは「何か面白いことの片鱗さえ見せることさえできれば車輪が回り始める」というものだ。すべてを自分で作り、見せる必要はない。自分が触媒（Catalyst）となり、周りを刺激しようという話。

茹でガエル

一方、触媒となるために一つのことに集中しすぎると痛い目にあう。熱いお湯にカエルを入れるとすぐに気づいて逃すだろう。しかし、ぬるいお湯からどんどん温度を上げていくと当のカエルは気づかない。気づいた時にはすでに遅し。茹でガエルの出来上がり。

常に周りに気をかけていないと環境が悪化してることに気づかない。割れ窓理論と違うのは『本人がそれに気づいているか』ということ。割れ窓理論は『よくない環境があると気付きながら、それが普通になり誰も気にしなくなる』という話。一方、茹でガエルの話では気づかぬ間に自分は死んでいる。

この話は結構示唆に富んでいるなぁと思う。自分は茹でガエルなのかも…とドキッとしてしまった。

『自分のしていることだけでなく周りを見渡そう』

はい。気をつけます…。

Software Entropy【The Pragmatic Programmer】

二つ目は "Software Entropy"。

割れ窓理論

ソフトウェアは物理世界とは隔離されているが、エントロピー増大の法則からは逃げられない。 どんなに素晴らしいソフトウェアであっても時間と共に朽ちていく。こういう状況を錆びに例えて "Software Rot" というようだ。

これを防ぐため『割れ窓理論』を応用しようと書かれている。割れ窓理論とは次のようなものである。

割れ窓理論（われまどりろん、英: Broken Windows Theory）とは、軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。アメリカの犯罪学者ジョージ・ケリングが考案した。「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。 （https://ja.m.wikipedia.org/wiki/割れ窓理論）

窓が一つでも割れていると、加速度的に環境が悪化していく。 一方、綺麗に装飾された家が建ち並んでいれば環境は悪化しない。

これをソフトウェアに応用しようという話だ。 割れ窓のようなコードが一つでもあると「ここもそうしてるしいいだろう」と思ってしまう。 一方、綺麗に整理されたコードではそういうことは起こらない。 「汚す」という行為に対して心理的な抵抗が現れる。

ソフトウェアの品質

ソフトウェアの割れ窓を見つけることはそれほど難しくない。 プログラマならば担当してるソフトウェアのイケてない点をいくらでも挙げられるだろう。 きっとそれが割れ窓だ。 クラス構成がいけてない。語彙が統一されていない。ビルドシステムが古い。

しかし、割れ窓やサビに注目しすぎるもどうだろう、と思うことがある。 割れ窓理論はソフトウェアの品質に寄与すると思うけれど、「ソフトウェアの品質」とはユーザーにとっての価値がベースである、とどこかで読んだ気がする（『テストから見えてくるグーグルのソフトウェア開発』だったかな？） 割れ窓に注目しすぎて、ユーザーを置いてけぼりにしないように注意したい。

テストから見えてくるグーグルのソフトウェア開発

The Cat Ate My Source Code【The Pragmatic Programmer】

明けましておめでとうございます。 2017年もすでに10日ほど経過してますが…。

一年半くらい書いてきた Effective Java シリーズが終わってしまって、イマイチ継続的にブログを書く感じにならない。 やっぱり、何かをシリーズ化してノルマにすることがブログを継続するコツですね。習慣付いてるとシリーズ以外のネタを書くことへの心理的障壁も下がるし。

The Pragmatic Programmer

以前から The Pragmatic Programmer は一度読んでみたいと思っていた。ちょうど rebuild で話題になってたし、これを読んで１章ずつまとめてみようと思う。rebuild では「古い部分が多い」という話だったので、なるべく「今ならどーするか」みたいな話を入れていきたい。

rebuild.fm

The Pragmatic Programmer は日本語版が pdf で読めるようになってるんだけど、残念ながら Kindle にはなかった。今回は、英語の勉強も兼ね原著を読もうと思う。（しかし、Kindleで4000円は高いと感じてしまうな…）

The Pragmatic Programmer: From Journeyman to Master

The Cat Ate My Source Code

１章は Take Responsibility について述べてる。簡単にまとめると、

• Take Responsibility しろ
• 失敗と無知を認めることを恐れるな
• クソな言い訳をするな
• 失敗した時のために対案をもっておけ
• 無理なら断れ

というところか。言ってることは至極真っ当である。うんうん、そうだよね。誠実さ。大事だよね。

でも、ここにたどり着くために実践するべき日々の行動をもう少し書いてくれれば、と感じた。あるべき姿だけ書かれていると大抵の人が「うんうん、そうだよね。誠実さ。大事だよね。」で終わってしまうわけだ。たとえば、「アクション：明日から自分のミスを毎日一つ書いて同僚と共有してみよう！」のように書いてあると少し違うのではないか。

こういう点は『Soft Skills』の方が手厚い印象を受ける（同じく『情熱プログラマ』も）。『Soft Skills』だと、"Chapter 10. Being a professional" でまさに同じことが書かれているし、取るべきアクションについても書かれているし。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

情熱プログラマー ソフトウェア開発者の幸せな生き方

もちろん、『Soft Skills』や『情熱プログラマ』は The Pragmatic Programmer に多くの影響を受けている、と明確に書かれているので、元ネタを基にしてさらによい方法で書かれているのは当然なのだろうけれど。

そして、まだ一つしか読んでないのでこう判断するのは早いのかもしれない。もしかしたらこの後に出てくるのかもしれないし。

次章は "Software Entropy"。