ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】「ハッカーと画家」を読んで。二流の証明。

読書感想文です。今回読んだ本はこちらです。

 

ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

 

 

読もうと思った理由

年末年始で積読タワーを消化しようと思って手に取りました。そもそも買った理由をもう覚えてないですが、確か内容や書評を見てではなくタイトルと装丁で何となく買いをした本だったと記憶しています。私が憧れる「ハッカー」と、凄くイノベーティブな雰囲気を醸し出す「画家」の組み合わせですからね。

私は読み物系の本は移動中や隙間時間に読むことが多いんですが、本書はオサレな装丁で、オサレなタイトルなので、人前で読むことが憚れ、お家で一気読みすることにしました。

 

全体の感想

買ったときは気づかなかったんですが、この本、ボールグレアム氏の本でした。前に以下の読書感想文をこのブログで書いていますが、このYコンビネータというシードファンドを作った人です。私的にはこの「Yコンビネーター」は大当たりな本だったのもあって、本書もとても楽しく興味深く読むことが出来ました。「Yコンビネーター」読んだ!超アツかった!という人にはとてもオススメできる本です。

(以下、「Yコンビネータ―」と記載した場合は書籍を指すことにします。ファンドとしてのYコンビネータ―の場合は括弧無しで記載します。)

 

本書は著者がウェブ公開しているエッセイをまとめて構成されているそうです。たぶん↓が本家。

http://www.paulgraham.com/articles.html

 

内容を振り返って考えてみると本書は「概ねIT系の自己啓発本」と分類するのがいいんじゃないかと思います。「ハッカーと画家」というタイトルに自己啓発っぽさは皆無ですが、読めば「自分ならどう考えるか」とか「コード書きてぇ」という気持ちになります。本を読んで考える、触発されてモノ作りをするモチベーションが生まれる、これって本来自己啓発本が備えていなくちゃならない要素だと思うんです。書いてある通りにやってみようとなるのはハウツー本ですし。なので私は本書のような内容を含んだ書籍こそが、自己啓発本と呼ばれるべきものなんだなぁと思いました。

 

全体の評価としてはとても面白く、以前読んだ「Yコンビネーター」と並ぶ面白さがありました。本書はエッセイという形をとっているので静的な読み物という印象です。対して「Yコンビネーター」はドキュメンタリー形式というのもあって動的だったという印象です。読中読後の熱量は「Yコンビネータ―」の方が強いと感じました。「Yコンビネーター」は本を読みながら本当にコードを書きたくてウズウズしちゃいました。「ハッカーと画家」は読中読後にコード書きたい欲が溢れ出てくるというよりも、より脳ミソを強く揺すられたという印象です。巻末にある監訳者のあとがきにこう書いてあります。

ポール・グレアムのエッセイは挑発的だと言われる。(中略)賛成にせよ、反対にせよ、彼のエッセイには人の頭の中にある「一言いいたくなる」ボタンを押す何かがあるようだ。いや、むしろ彼のエッセイが押すのは「何かやりたくなる」ボタンなのかもしれない。

 

正にこれだなと思いました。著者は本書で書きたいことを書いていますが、そこにはそのように考える根拠として、そこに至る論理を開けっ広げに書いています。その論理のところが論理的に正しいとは言えない部分があって、そここそが「一言言いたくなる」の源泉になっているのだと思います。こう書くと誤解されそうですが、論理的に正しくないと書いているのは、論理的に間違っているという意味ではなく、証明しきれない部分を自身の知識や経験から補って結論付けているところにあります。(まぁエッセイですからね)ポールグレアム風に書くとこんな感じです。

 

日本は労働生産性が低いと分析されているが本当にそうなのだろうか。時間を守り、勤勉で、ロボットのように働く彼らの生産性が低いというのは直感的には誤りだと感じる。きっと彼らが仕事をする環境だったり、周りにある他の外部要因に原因があるはずだ。例えば……

 

といった書き方がされているんです。何か一言言いたくならないだろうか。私はとてもなりました。読み進むたびに「いやいや、そこはこうなんじゃないのか」とか「自分の周りならきっとこうだ」というように思考を促される感覚がありました。良い本を読んだ時によく思うことですが、良い本は”本全体”から強いメッセージが発せられている気がします。良いことが書いてある章や節、センテンスがあるのではなく、本全体から出てくる魅力があるのだと思います。だから良い本であるほど、感想文を書くのが難しい。内容の薄っぺらい本だったら感想を書くのって楽なんですよ。著者の言いたいことが大して無いし、大したものでも無いですから。

 

二流の証明

本書の感想文(このエントリ自体)を書いている途中で思い付いた、ある種メタ的な感想です。 

ハッカーと画家を読んでいると、読中とても心地よい感じがしていました。先に書いた通り「一言いいたくなる」部分もそうですが、自分の思考回路と似ている感じがしたんです。だけど、一流の人が言語化した内容に対して「そうそう、俺もそう思ってた。」なんてことを言うのは正に二流の証明だと思ってしまったわけです。本書の中でデザインに関する話があるんですが、その中にこう書いてあります。

 

いくつかの偉大な発見はあまりにも単純に見えて、「これなら自分でも思いついたよ」と言いたくなることがある。発見者はこう言うだろう。「じゃあ君が思いつけばよかったじゃないか」

 

本書を読んでいると「そうそう俺もそう思ってた」と思うところがあるんですが、じゃあそれを本書を読む前に言語化できたかというと、まぁできなかっただろうなぁと思います(これこそ読書の良い所ではありますけど)。つまり上記の引用文中で「これなら自分でも思いついたよ」と言う人間と同じってことです。心地よく読むことが出来て、感想を書いていったら、その感想文自体が本書の中で言及されている二流どころの表現になってしまいましたというお話です。

 

意図せずつながった自分の興味

私は読中この本の著者がポールグレアムだと気づかずに読み始め、オモロイオモロイと思って読んでいました。でも実はもう1つ私から見た興味の繋がりがありました。本書で何度か引用されているエリック・レイモンドのところです。

私はこのブログのタイトル通り、ホンモノのエンジニアに憧れていて、ホンモノのエンジニアってどういうエンジニアなんだろうかと調べていたことがありました。そのときに見つけて思わずブックマークし、繰返し読んでいるエッセイ(というべきか?)があります。これ↓ 

How To Become A Hacker: Japanese

 

なんとまぁ自分が気に入って繰返し読んでいたエッセイが本書で紹介されているじゃないの。何かこれがすごくうれしかったです。自分でこうやって書いていて恥ずかしいなと思う部分もあるんですけど、まぁ感想文ですから素直に書かせてください。

  

「美しい」の答え

本書には「美しさ」に対して深堀していく章があります。私もこの美しさという概念の存在について疑問に思っていたことがあって、その点に触れられていたところは特に面白かったです。(うーん、後出しで「俺もそう思ってた」って書いてますね)

ずっと疑問に思っていたことなんですが、美術系の人は置いておいても、学者、プログラマ、その他色々な分野のトップクラスの人って、「美しい」という表現を使うんですよね。この美しいという表現が私には理解できないものなんです。トップクラスの人たちがよく使う表現なので、どんな分野でも突き詰めていくことで、最終的に分野を問わず得られる感覚なんだとは思ってるんです。

いきなり「美」の対極にある例となりますが、ゴキブリやムカデといった虫は、それが気持ち悪い存在だと教えられたわけでもないのに、大勢の人が嫌悪感を覚えます。嫌悪感ってのは感覚的なものです。なので真に共有できないはずだし、そもそも「ゴキブリは気持ち悪い」と教わったわけでもないのに、多くの人が同じ感覚を覚えるってのはすごく不思議なことだと思っていたんです。

「ゴキブリは気持ち悪い」というのは教育を受けなくても何かの能力を高めなくても感じることができます。でも、「美しい」という表現は分野のトップクラスの人しか言いません。(たまにこれを利用して美しいという表現を使ってマウントを取ろうとするクズみたいなのはいますけどね)

ということは、人間は醜いものを感じ取るセンサーはみんな持っていて、美しいものを感じ取るセンサーは一部のトップクラスの人しか持っていないのか。でも醜いと美しいは1つのベクトル上にある評価基準だとも思えます。ならば負の方向への感覚はみんな持っていて正の方向への感覚を持っていないということか。もしそうならなんかこれってすごく嫌な感じがしますよね。

 

話を読書感想文に戻します。本書では「美しさ」に対して分析を行っている点がすごく面白かったです。美しさについて、そこに共通している要因がわかれば、他の分野に応用できるのではないかという考えで、「美」の共通項を14個挙げています。例えば「良いデザインは単純である。」といった感じで、いづれも興味深く読めました。

 

そしてこの章の最後に書いてある結論がまた良いんですよ。美の共通項を挙げて解説した章なんだけど、最後は、

醜いものを許せないだけでは十分ではない。どこを直せばよいのか知る嗅覚を得るためには、その分野を十分に理解していなければならない。しっかり勉強しなくちゃならないんだ。

と書いています。美を分解してそこに共通している因子を取り出したんだから、今度は逆にその因子を組み込んでいけば美しいものが出来上がる、と言うのかと思ったら全然そんなことはなかった。私の感覚的な理解ですが、原因と結果の話に似ていると思いました。美しいものや、それに共通して存在する因子というのは結果なんだと思います(因子なのに結果と書いているのでわからづらいですが)。あくまでも上手くいっているものから抜き出した共通因子でしかなく、それ自体で美の全てを説明することができない。美しいと言われるものが結果として備えている共通因子なわけです。

結局この章で書いているのは、あくまでも美しさを構成する因子を説明しているだけで、美しいものを作るプロセスはまた違うものだということです。最終的には「しっかり勉強しなくちゃならないんだ」という険しい道のりを結論としているところが美しいなと思いました。

 

これキタ!ポイント

「これキタ!」ポイントを引用しながらメモっておきます。

 

第0章

フォーカスグループはその時流行りのうわべの装飾を欲しがるかもしれない。だが本当に欲しいのは、洗練された買い手の真似をすることだ。

これ冒頭の0章にさらっと書いてありましたけど、すごく本質的なことだと思ったのでメモっておきます。ブランド好きな人たちってのは、そのブランドが優れているから買うのではなく、そのブランドを身に着けている自分の姿が好きなんだと私は思っていました。最近のインフルエンサーの異常な盛り上がりを考えると、みんな何かそういう真似たいと思う誰かを求めているのかもしれないなと思いました。

 

第1章

時を遡って13歳の自分にアドバイスできるとしたら、まず頭を上げて回りを見てみろと言ってやりたい。当時は気づいていなかったのだが、自分たちがいた世界のすべては張りぼての偽物だった。

文章がカッコイイなと思ったのと、すごく考えさせられたところです。著者は13歳のときにいた世界のすべては張りぼての偽物だったと書いています。私が13歳の頃はと考えたんですが、いやむしろ今も私は張りぼての偽物の世界にいるような感じがしています。これを書いている2019年1月は厚労省の統計問題が盛り上がっていますが、あれなんかはモロ張りぼての偽物なわけです。でも張りぼてであろうとも全ての面を作りきってしまえば意外とバレないし、張りぼてでも世界は回っていくんだと思いました。だから今この世界にある例えば統計問題みたいな張りぼてだけど世界は回っているという何かを見つけて、それをぶっ壊すという考えが大事なのではないかと。

 

第2章

作家や画家や建築家が創りながら作品を理解してゆくのと同じで、プログラマはプログラムを書きながら理解してゆくべきなんだ。(中略)プログラミング言語はプログラムを考えるためのものであって、既に考えたプログラムを書き下すためのものじゃない。

 

プログラムの仕様に完璧さを期待するなんて非現実的だ。そのことをまず認めて、仕様がプログラムを書いている最中に変わっていっても、それを受け入れられるような書き方をすべきなんだ。(大企業の構造にはこれをやりにくくさせるものがあり、これもベンチャー企業の利する点だ。)

哀しい事に私は普段の業務でコードを書きませんが、SIerにいる人間として忘れてはいけないことなんだと思いました。これを忘れてしまうと完全に終わったエンジニアになると思います。だからやっぱりIT企業にいて、コードを書かないとかサーバに触らない人って、何かを作り続けないと感覚がおかしくなっていってしまうんだろうなと思いました。

 

第5章

プロジェクトに人員を追加することは、プロジェクトをかえって遅れさせがちだ。開発者間の可能な連携の数はグループの大きさに対して指数的に増大する。

これは実感として確かにあると思いました。遅れているならリソース追加だ、となるケースってわりとあると思いますが、現場ではそんな単純な足し算で遅れを取り戻せたりはしません。

 

サーバが問題を起こすのは、私たちにとって何が何でも避けるべきことだった。ちょうど、おもちゃ屋にとっての危険なおもちゃとか、食品業者にとってもサルモネラ菌などと同じようなものだ。

サーバ屋の顔を持つ私から見て、これも確かにあるなぁと思ったのでメモとして引用しています。金融系や公共系のシステムをやっていると、サービス停止=死刑みたいなところがあって、それは確かに食品業者にとってのサルモネラ菌なのかもと思いました。

 

大会社にとってWebベースアプリケーションを使うことはITをアウトソースするということになる。

ここでいうWebベースアプリケーションは今でいうパブリッククラウドのことですね。感覚的な話ですが、アウトソースという言葉を使うとどうも人に委託するというイメージがありますが、パブリッククラウドを使うってのも一種のアウトソースなんだなぁと逆に新鮮に思ったので引用しました。

 

入門レベルのユーザは、どこを簡単で明快にすべきか教えてくれる。最も進んだユーザは、どういう機能を足したらよいかを教えてくれる。最良のソフトウェアは簡単であるものだが、それはデフォルト設定がそうなっているためで、ユーザが望めばその選択に限界があってはならない。

 

第6章

大学を卒業しようとしている学生は、就職しなくちゃならないと周りから言われるし、自分でもそう考える。まるで組織のメンバーになることが重要であるかのように。でももっと直接的に言えば、人々が欲することを始めることが必要なんだ。人々が欲することをすることが重要なのであって、集団に属することは問題じゃない。

真理だと思った。就職ってのはあくまで手段であって目的ではない。就社ではなく、文字通り就職することが大事ということですね。ただこれは真理である一方で日本で流行るかというと難しい気がします。超大手企業に入るためには良い大学を良い成績で卒業して、更にどの会社にも洗脳されていないプレーンな人材であることを求められるし、卒業後に起業してみたけどダメでした御社に入りたいんですが、という異端人材はなかなか受け入れられない傾向が強い。安定した会社に入るためには素直なフリして新卒で門戸をたたかないといけない。ここでいう「集団に属することは問題じゃない」と考えて我が道を突き進むことは見識を広げることには繋がるが、日本では入れる会社を狭める行為に繋がってしまう。でも真理。

 

私は恐ろしく困難な技術上の問題に丸一日がかりで皆で取り組み、精も根も尽き果ててしまった時のことを覚えている。それでも私は嬉しかった。私たちがこれだけ苦労するような問題なら、きっと競争相手は誰も解決できないだろうと思ったからだ。(中略)競争相手が真似するのが難しすぎるような技術を作りさえすれば、他の防御に頼る必要はない。難しい問題を選ぶことから始め、決断が必要な場面では常に難しい方を選べばよい。

冒頭で紹介した「Yコンビネータ」にも似たようなことが書いてあった。「Yコンビネータ―」では「他の連中より真剣に考え抜いた点だけが優位点になる」とあった。これはやっぱり仕事をする中で忘れてはいけないこと。

 

 

第9章 

良いデザインは再デザインだ

熟練者は初期の仕事を捨てるつもりでやる。計画が変更されることを予定してかかるのだ。

 

第12章

もし、他の誰もが使っているからという理由で技術を選ぶなら、Windowsを走らせておけばいいのさ。技術を選択する時は、ほかの人がどうやっているかなんて無視して、何が最適かを見極めることだけを考えるべきだ。

 

第13章

この世にある多くのプロジェクトの要求はさして高くない。おそらくプログラミングの殆どは、既存の部品をつなぎ合わせる小さな糊付けプログラムを書くようなものだ。それならもう手に馴染んでいて、目的に合わせたライブラリが充実している言語を使えばいい。

個人開発をやる時に常に考えたいメッセージです。糊付けで開発したアプリケーションはアイディア次第で面白いものが作れるけど、真似するのが簡単です。やっぱりIT業界にいるとなると、いずれは起業して金儲けしたるどー、と漠然とした妄想はするわけで、その時に忘れちゃならない内容だと思います。

 

大きな組織では、このアプローチを「業界のベストプラクティス」という言葉で表される。その目的は髪のとんがった上司を責任から守ることだ。彼が「業界のベストプラクティス」である何かを選んでそれで会社が競争に負けたら、悪いのは彼じゃない。彼が選んだのではなく、業界が選んだのだから。

「業界のベストプラクティス」はあなたをトップにするのではなく、単に平凡にするだけだ。

 

第16章

素晴らしいハッカーはまた、一般的に、オープンソースソフトウェアを使うことを主張する。そちらのほうが良質だというだけでなく、自分で多くをコントロールできるからだ。良いハッカーはコントロールしたがる。それが彼らを良いハッカーたらしめている理由の一つだ。何かが壊れたら、自分で直したいんだ。

 

オフィス環境というのは、その中で仕事をするためのものであって、そういう環境にも関わらず仕事をする、というものじゃないはずだ。

以前読んだピープルウェアという本にも似たようなことが書いてあった。エンジニアの集中力を無くさせるような環境はいかんというもの。

 

 

用語解説

システム管理者症候群

システム管理者が、監視しているシステムがユーザにとっての道具ではなく、それ自体が目的であるかのように思い込んでしまうこと。より一般的には、顧客を、それが自分の存在理由のはずなのに、単に煩わしいものと感じてしまうこと。競争に晒されていない職種に特有の病である。

 

 おわり