人の心を動かすインタビュー

■ コンピュータサイエンスはこう学べ (2) 14:27

http://d.hatena.ne.jp/ryocotan/20090919/p1 の続きです。

• ひげぽん (http://d.hatena.ne.jp/higepon/)
• omo (http://steps.dodgson.org/)
• 天才プログラマA氏

---- 勉強をしている人は、「リファクタリング (ASIN:4894712288)」を読んでるイメージがあります

omo: 主にこの人でしょｗ

A: そうかなぁｗ

omo: アジャイル信者の。

A: そういう所はあるかもね。リファクタリングは、2000年ぐらいですかね。ソフトウェアの開発スタイルを変えた一大事件で。2000年以前と2000年以降というのは、リファクタリングをベースに開発するというのと、そうじゃないというのが、大きな時代の区分としてあったんじゃないかな。

---- テクノロジーによって変わったんですか？ 元々思想的なものがあった？

A: 半々ぐらいだよね。やっぱりJavaとかが主体になるというのがあって、C++では厳しかったけどJavaなら、っていうのがあって使いやすくなったというのがある。あとはプロセスとかもリファクタリング向きなものになっていったっていうのがあるから、そういう外側の要因と、ただ純粋にリファクタリングに焦点を当てたという、マーティン・ファウラーの功績なんじゃないですかね。「その前からあった」とはみんな言うけど、少なくとも自分はそれを意識して開発してなかったんだけど、リファクタリングを読んで影響を受けて、意識するようになった部分はあるね。

A: 新人が来て、コーディングの文法は知っているという人間に、一番最初に読ませようと思うのはリファクタリング (ASIN:4894712288) かなぁ、と思うけどね。まず、本の出来が素晴らしい。

ひげぽん: うん。

omo: そうだね。薄い！ｗ

一同: (笑)

A: 薄い、ってほどでもないけどねｗ でもまぁ薦められるよね、あの厚さだったら。特に、後半のケント・ベック (Kent Beck) なんて良い事を言ってるけど別に読まなくてもいいし。

omo: そうそうそうｗ 構成がいいんですよね。

A: 別に最初の方だけちゃんと読んでおけばいいわけだし。

omo: 最初にモチベートする例を示して、こういう風にやんだぜ、って。

A: あれは素晴らしい本だね。後になって読むほど「あ、こんなこと書いてあるんだ」って気付く事が多いね。知らない時は知らないなりに学ぶことがあって、知ってくると知ってくるなりに学べるという、とても良く書かれた本だと思う。

omo: やっぱマーティン・ファウラーすげーって思う。

A: 思うね、あの本はｗ マーティン・ファウラーはろくでもない、ってアナリシス・パターン (ASIN:4894716933) は読んでいて思うけど、リファクタリング (ASIN:4894712288) を読むと「あ、こいつ凄い奴なんだな」って、いつも思うよ。

---- 作者は何をやってる人なんですか？

A: Javaの受託じゃないですかね。

omo: アジャイル開発をプッシュする、受託＋コンサルみたいな会社のCTO。

A: Channel9とかにたまに出てくるんだけど、人の話を聴かないで自分の話を延々とするというｗ あんまり華がある感じじゃないんだけど、

ひげぽん: そうなんだ。文章は素敵なのに。

A: そうなんだよねぇｗ　全然あんなタイプには見えないのに。「ギークとはこういうものか」って気もちょっとする。最近はDSLがお気に入りなんですかねぇ。

リファクタリングは良いんじゃないんですかね。「コードのクリンナップとリファクタリングは違う」って事を明らかにして、リファクタリングのやり方でコードを変更していくという事によって、それまで出来なかったスタイルの開発が出来るようになった、というのが「偉大だなぁ」って思いますね。「試してみて結果を見てから判断する」というのが、それまでには出来なかった事なんだよね。

---- なるほど

A: 設計とかで、Aって設計とBって設計があって「どっちが良いか？」って時に、「こっちが良いんだよ！」って勝手に進めていたところを、リファクタリングが出来るようになってからは、Aを試して、Bを試して、良かった方を選ぶように、実際に試して進められるようになったのが、それ以前とそれ以後の大きな違いなんじゃないんですか。

「プロトタイプをちゃんとやってた」って人にとっては、似たような部分があるかもしれないけど、そこを連続的に進められるようになったというのが大きい。現実の案件とかだと、プレッシャーとかもあるからさぁ。「実施するのに大きなジャンプが必要なテクノロジとか手法」ってあんまり使えないけど、リファクタリングは漸進的に導入できるからね。プロトタイプとかに比べて、大きく開発スタイルを変えたんじゃないんですかね。

omo: (図説中…)

A: リファクタリングの肝っぽいところは、「既に上手く行くと分かっている手順」だけを組み合わせて目的の場所に行く、ってところがクリンナップとの大きな違いだね。「変形できるパターン」というのは、限られた個数のパターンしかなくて、それだけを使って目的の場所に行くというのが肝なんだけど……まぁ、そうじゃない手順もちょっと混ぜたりするけどね。面倒くさいから。

---- 洗練された変形していく手法があると

A: そうだね。それが2005年になってIDEで自動化されて、凄い速度で出来るようになったんで、またそこで5年前とは大きく違ったギャップがあって。2005年以前と以後でね。人によっては2004年かもしれないけど。そこらへんの前後ってのは、プログラミングのスタイルも違うし、出来上がるコードも品質が全然違う。

omo: C++にはあまり関係ない話だよね。

一同: (笑)

A: これは一部のIDE信者的発言なんで（笑）。JavaとかC#が好きな人だけって感じ。「じゃあLLはどうなんだ？」って言われると、LLも劣るとは思わないけどね。そこは良く分からないんだよね。理屈で考えると、「型付きの方が良い」って思うんだけど。実際に書いてそうなのか、って言われるとそうでもなくて。この理論と現実の違いというのは埋めがたいけど。

omo: 抽象化能力は高いですよね、LLは。だから何とか補えるんじゃないんですかね。

A: 「小難しい本」というと、「役に立たない本」ってのがあるんだよね。例えば数学寄りな本？ 意味論とか。SICPとかそういうノリがあるけど、あれは半分ぐらい役に立つところもあるんだけど、そういうのもたまに読むけどね。ただ、そういうのはこういう場で話すものなのかなぁと思って。一方、「そんなに読んでるの？」と言われたら、そんなには読んでないので（笑）。「型付きラムダ計算は終了する」とか。おっ、終了するのか、だから何なんだよとか思うわけだけど（笑）。

ひげぽん: (笑)

A: 一部の人には大切らしい（笑）。「有限型のベータリダクションで」みたいな。「だから型付きラムダ計算以外はダメだ！」みたいな人も世の中には居るわけで。そういう本を読んで、だから何なんだと言われると別にね。

ひげぽん: 趣味の世界ですよね。

一同: (笑)

A: コンピュータサイエンスだと、コンパイルより後はそういう世界に入っちゃうけどね。LALR(1)の話とかは、数学っぽいけど現実的な世界なのにねぇ。それより一歩先に進むとろくでもない話になるよね。

omo: 本を読むってのもあるけど、現実の仕事からフィードバックを受けるというのもあると思うんですよ。そのバランスをどう取っていくのか、っていうのが。本を読んで、使ってみて、やってみて、勉強して、またやってみてみたいな。

A: 今やってる事に近い本を読んでる場合は、そういう感じになるよね。凄い良い本に、凄い良い時期に出会った時は、そういう風になるけれど。あんまり多くも無いけどね。

omo: 読む本のチョイスって、割と仕事で困った時に決めるよね。

A: そういう本が丁度あるってのは、良い時だよね。

omo: まぁね。

A: 「勉強が楽しい」と思えるパターンなんじゃないんですかね。例えば、見積もりとかを丁度やってる時に、見積もりの本が出たりして、「あぁ、良いタイミングで良い本が出たなぁ」とか思ったけど。そう多くある事じゃないよね。

omo: なかなか解決しない大きな問題とか……ほっといても進むんだけど気に食わない、ってことあるじゃないですか。そういうのを一年とかの単位でテーマを決めて読む、みたいな。

A: 私はそういう事はあまり無いかなぁ。でもそれは良い話って気がするけどね。

ひげぽん: 僕はもう仕事で役立つとかじゃなくて「貯金型」ですかね、今は。穴埋め型というか。ここが弱いから、あの時に困ったんだろうなぁ、と思いつつ読むみたいな。

omo: 一年ぐらい、性能関係を読んでるんだけど、あんまり読むペースは速くないんで。年に２，３冊なんだけど。

A: いい話じゃないですか。

omo: そういうのがあると仕事で「あぁ、あの時に性能を測っておけばよかった！」みたいなフィードバックがあるな。

A: 性能については言いたい事が沢山あるけど……性能の話は勉強とは全く関係ないね（笑）。

omo: (笑)

A: でもまぁ関係あるところもあるかもね。やっぱり、前は大きい会社に居たんで、大きい会社の良い所はそういう最新の研究成果とかが社内だけに出ている時に、それに触れられるというのがあって。性能というのは自分が居た時はホットな話題だったので、世の中では本にもなっていないような最先端のスタイルみたいなものを沢山読めて、それを実践できたというのは、性能に関して自信があると思える所だね。

---- 性能って何ですか？

A: きゅっと立ち上がって、きゅっと早く見えるとかじゃないの？ うちはウェブサイトだったんで、そのページに移ってから出るまでの時間と、いじった時にきゅきゅきゅっと動くという（笑）、そういうのが性能じゃないですかね。色々あるけどね。

omo: 落ちない、とか。

A: 性能っていうのは、今時っぽい開発スタイルを要求するもので、リファクタリングブラウザとかを使って凄い速度でリファクタリングが出来るという前提じゃないと、色々と達成できない方法が前提となっているので。

ひげぽん: へぇぇ。

A: 「IDEないとダメだよなぁ」というのを、そういうのを通して思って、「ダメだC#以外は」みたいな（笑）。

一同: (笑)

A: まぁ別にJavaでもいいけどね（笑）。「Emacsなんか使ってる奴はダメだ」って話になるわけですよ。

omo: OSをまたいだりネットワークをまたいだりすると、ボトルネックって何だかよくわからなかったな。

A: プロファイルはやっぱり色々あって、計測することにどれだけ時間を掛けるか…ってのは今時と一つ前の世代では違うと思うけどね。性能を測るのに凄いコストをかけて、プロファイラで取る以上の事を色々やるというのは、今時の速さのソフトを作る肝になっていると思うけど。まぁ、そういう話というのは表に出ているものでもないので。

omo: (笑)

ひげぽん: 気になる！

---- Emacsの話が出ましたが…

A: めちゃアンチですよ。

---- 使ってますよね？

ひげぽん: 使ってますね。Aさん、昔Emacs使ってた人ですよね？

A: まぁそうですねぇ。

ひげぽん: 「Emacs最高！」とは最近は言わなくて、道具の一つなんで、まぁいいよね、ってぐらいです。「リファクタリングブラウザ」とかの話は、反論のしようがない。

omo: (笑)。Emacsの所為でなくて、C++の所為だと。

A: Schemeとかもあるけどね。そこらへんはIDE信者も歯痒いところだよね。「IDE素晴らしいんだよ！」って言っても、でも「仕事でC++なんだけど」って言われると、そこで会話が終わってしまって。

omo: （笑）

A: 「何それ。仕事でPS3なんだけど」って言われたら「知らんがな」って話になってしまうので（笑）。そこから先は分かり合えないので、どうしようもないんだよね。

---- リファクタリングブラウザがあってからこそのIDEなんですね

A: それ以前とそれ以後では違うよね。ただ、ボタン置いて、ダブルクリックして、ハンドラ書いて、ってのも良いじゃん、って思うよ（笑）。

---- コード補完とかいいですよね

A: インテリセンスとか良いよね。IDEとかは、インテリセンス無しだとやってけないよね。長いメソッド名とか打てないから。頭文字が散らばってる方が良いよね（笑）。

一同: (笑）

---- メソッド名の付け方も変わってきますね

A: 長くはなるよね。まぁ、Emacsでも…メタMだっけ、スラッシュだっけ。viだとCtrl-Pとか。その頃も、それなりにあったけど。インテリセンスは別物ではあるけど。

---- 名著五冊みたいなのを挙げて欲しいんですけど……

A: それは難しいねぇ。「新人に読ませたい」とかもあるね。

---- 「自分から勉強しないプログラマ」とかもいるわけですよね

omo: コース別ってことね。

---- とりあえずプログラマとして食っていくための五冊とか（笑)

A: 難しいなぁ。何も読まなくてもいいんじゃね？とかｗ

ひげぽん: それでも構わないんじゃないですか。

omo: 一緒に働いてるか、って前提がどれくらいかだよね。

---- 一緒にコード書いてるぐらいかなぁ。不勉強な人に苛立ちませんか？

ひげぽん: 自分はないです。周りが優秀なので、何も文句ありません。

A: 私はありますね。やっぱり、前提として知っておいて貰わないとコミュニケーションが成立しない会話とかがあって、設計とかの話をする時とかに、対等に話をしたい場合に知っておいて欲しい事って膨大にあるけど。それは抑えておいて欲しいけど、抑えていてくれる事ってあまりない。自分が思う前提を抑えている同僚ってのは、あんまり多くない。

---- どこら辺を抑えておいて欲しい？

omo: 膨大なんでしょ（笑)

A: 膨大ですね。

---- それを概ねカバーできる名著、みたいなのは難しい？

A: 今まで出てきたような本は良いんじゃないんですかね。リファクタリング (ASIN:4894712288) から始まって、DDD (ASIN:0321125215) を読んで、Working Effectively With Legacy Code (ASIN:0131177052) を読んで、xUnit Test Patterns (ASIN:0131495054) を読めばいいのか？……って言われると全然足りないけれど（笑）。

omo: なんか偏ってるよねぇ。

A: 今仕事をしていて困るのは、そこらへんが多いような気がする。

omo: 最近思うのは、他人に迷惑を掛けないコードを書く、ってのと、自分の中の満足度を上げていくのは別の軸で。

ひげぽん: 他人に迷惑を掛けるコードって、どんなのですか？

omo: バグってるとか、保守しにくいとかですよ。

A: 他人に迷惑を掛けるコード、ってのは多いんじゃないですかねぇ。

---- 他人に迷惑を掛けないようにする、というのは難しいですか？

omo: それは簡単で、Code Complete (ASIN:489100455X) とか、そういう方向だよね。チームで仕事をする時に、同僚の邪魔をしない為のコード、ってのはあるんですよ。最低の品質を保証するためのコード。OSとかコンパイラの本ってのは、読んで無くても割と大丈夫で、そういう本を読んでないとローレベルなレイヤーのものは作れないけど、それはそれで大丈夫で、仕事だとそういう仕事は作れる人に回っていくので。それがただ回して貰えないだけで。誰もが普段書くコードの品質ってのは重要で、そいつにインパクトのある本と、そうじゃない奴ってのは別なんだよ。コンピュータサイエンス寄りなやつってのは、自分の満足度とかハイテク路線。チームとか仕事としてコードを書く時に、他人に迷惑を掛けない為の本というのは、主にデザインとかプロセスの話。

omo: Code Complete (ASIN:489100455X) は、他人に迷惑を掛けないラインの本だよね。

A: 最低限だったら、「Code Complete (ASIN:489100455X)」と「リファクタリング (ASIN:4894712288)」ぐらいかな。「Writing Solid Code (ASIN:4756103642)」を入れるかどうかは、ちょっと微妙。

omo: もうね。

ひげぽん: もういいんじゃないんですか。

omo: 絶版だしね（笑）

A: 俺はあの本好きだけどね（笑）。あれは良い本だよ。迷惑を掛けない、となるとその辺のラインになるのかな。でも足りないような気もするけどねぇ。今言った本を読んで、そこそこのコードを書けるようになるかと。

omo: デザインパターンはどうなのかと。

A: デザインパターン……GoF (ASIN:4797311126) ？

omo: デザインパターンって難しくてさ。デザインパターンは要るけど、「あれか？」って。

A: でも悪くないよ、読み直してみると。どう思います、GoF。

ひげぽん: 僕は読んでないです。結城さんの本 (ASIN:4797327030) しか読んでないです。

A: お、読んでないんだ。へぇぇー。GoFを読んでない人がいた。衝撃。ひげぽんはGoFを読んでいなかった。GoFは、結構早く翻訳された本として思い浮かぶ本だね。あの頃は、原書が出て一年か二年で小難しい系の本が翻訳されてたよね。ああいう本が翻訳されるのは素晴らしい。GoFは、今時の本があると良いんだけどね。「Visitorとかねぇよ！」って誰かが言えばいいのにね。

omo: （笑）

A: Visotorパターンってのがあるんだよね。「ダブルディスパッチはこうやるんだ！」とか。「やるなよ！」ってみんな思っていると思うんだけど、そういう事が書いてある本なんで。「そっか、これがオブジェクト指向か！」とか思われると、大変たちが悪い（笑）。

omo: 間違ってるのも混じってる、って話なんですよ。

A: まぁ、良い事もあるんじゃないんですかね。

omo: パターンとして紹介されてるんだけど、使える場面がとても限られている。よく使われるようなものとして紹介されると困る。

A: たまに使えるシーンもあるので、一概にダメかというとね。GoFぐらいまでは読んでいいと思うけどね。あれ、何だっけ。

omo: Pattern-Oriented Software Architecture (ASIN:4764902834) ？

A: そうそう。そこら辺まで行くと、読まなくてもいいかなって思うよ。

omo: 何度挑戦しても途中で眠くなっちゃうんだよね。

A: あれは読んだら読んだで「へぇ」ってぐらいだけどねｗ

■ コンピュータサイエンスはこう学べ (1) 14:26

コンピュータサイエンスの勉強法について、情熱を持って取り組まれている方々にお話を伺ってきました。

• ひげぽん (http://d.hatena.ne.jp/higepon/)
• omo (http://steps.dodgson.org/)
• 天才プログラマA氏

---- 最近はどんな本を読んでいますか？

ひげぽん: Aさんに薦められた "Domain-Driven Design" (DDD) (ASIN:0321125215) という本と、"Programming Pearls" (ASIN:0201657880)」ですね。

---- DDDを薦めた理由は？

A: コーディングに関する新しい本ってあんまり無かったので、最近あまりコーディングに関する本をひげぽん氏が読んでない気がして。あとは、割と良い本なので、みんな読んでおいた方がいい「必読系の本かな」と思っているところがあって。

---- 読んでいてどうですか？

ひげぽん: 日記にも書きましたけど、「ハートオブソフトウェアは何か？」という話に割と感動しましたね。

A: 「ハートオブソフトウェア」ってどんな話でしたっけ？

ひげぽん: ユーザーの生活するドメインの中で叶えたいことを実現するのがソフトウェアのハートの部分であって、テクノロジというのはそれを実現する手段だよ、ハートオブソフトウェアを作るために DDD をやっていきましょう、みたいな導入があって。

---- Domain-Driven とはどういうことですか？

A: DDDというのは、顧客の方の世界を中心としたデザインの事で、例えば、銀行の勘定系だとか、電子回路のシミュレーションをするものだとか「現実の世界の何かを達成するのに作るソフトウェア」で、その時に現実の世界を中心にしてデザインをする、というものですね。

ひげぽん: 自分がSE時代はそういうことをやっていたなぁ、と思いました。ものすごく稚拙でしたが。つまり、お客さん側の世界から考えて、それをソフトウェア側にマッピングする。逆じゃなくて。

A: まぁ、あんまりソフトウェアサイエンスの本じゃないけどね（笑）。こういう展開としては適切かは分からないけど……DDDというのは「話し合いとかコーディングを重視する」っていう方法論で、これは結構、好みなところがあるんですよね。UMLのダイアグラムだとか仕様書だとか、そういうものではなくて、「コードを重視する」というのは好きな方なんで。で、どういうコードを書くか、というのがずっと語られているので、あの本は好きだな。「実例」みたいなものが沢山載っていてですね。「対話をしながらちょっとずつコードを書いていく」というスタイルなんですね。

コードを書くんだけど、話をしているとどうも話の内容とコーディングのモデルが違うと。モデルというのは、クラス名とメソッド名ですね。なんか違う、と。クラスの切り方が話してる内容と合わない、と気付いてちょっとずつ変えていくというのが、物語風に延々と続くという本なんですけど、これが非常に最近の自分の仕事のスタイルに似ていた、と読んでいて感銘を受けてですね、「おー、こうだよ、こう！」と思ったんですね。最近といっても、２，３年前の話ですけどね。「みんなこういう風に仕事したらいいのに」と一人盛り上がって薦めてたんだけど、誰も周りで読む人はいなかったと……。

---- 洋書しかないですよね

A: 洋書しかないですね。これがあんまり内容を読んで話をしている人がいなくてですね。「はし書きしか読んでないだろ！」みたいな人が偉そうに語っていたり、「これはデザインパターンの本である」とか言っていたりと、凄く不満なんだよね。「違うよ！」って思うんだけど。「対話をしてコーディングの質を上げていく」というところが中心なのに、それについで誰も話をしていない。

---- レビューの話ではないんですよね

A: レビューの話ではないけど、似てるね。「ペアプログラミング」をレビューの一種として考えるとすると、あれも広い意味でのレビューに近くて、ドメインスペシャリストと対話をしながらコーディングしていくということで、プログラマと話しながらではないんだけど。ドメインスペシャリストというのはコードを読めるわけじゃないので、コードの中心的な部分を抜き出して、自然言語にしなくちゃいけない、という所が違うところで、自然言語を使って話をして、自然言語を洗練させていく。それをコーディングに反映していくというのが、DDDの肝ですね。いい話だとは思うんだけど、ドメインスペシャリストと仕事をすることは多くなかったので、自分の仕事とはちょっと違うなぁ、とは思うけど。

omo: XPが前提なんですか？

A: XPは前提だし、ある程度リファクタリングベースで開発するという……つまり、発展的デリバティブじゃないけど、ちょっとずつ変更してリリースして変更してリリースして、というサイクルを繰り返していってソフトウェアを成長させていく、ってのが前提になってるね。2003年に書かれた本なんだけど、2003年を感じさせない本だね。2005年ぐらいにIDEのリファクタリングブラウザとかが普及してきて、プログラミングの世界が変わったなぁ、と思うんだけど、2005年より後に書かれたような本が2003年に書かれているので、あの本はいつ読んでも違和感があるんだよね（笑）。「なんで2003年なんだろう……こいつ本当に手でやってたのか？」みたいな。

omo: smalltalkerだったとか。

A: いやー、Java使いっぽいけどねぇ、エヴァンズ (Eric Evans) は。

---- 著者は何の専門家なんですか？

A: Javaの普通の受託の専門家っぽいですねぇ。マーティン・ファウラー (Martin Fowler) が前書きを書いてるんだけど、何処でも「マーティン・ファウラーが書いた本」って書いてあって「書いたのはエヴァンズだ！」っていつも思うんだけどｗ

omo: それは酷いｗ

A: 本当に内容を見てないよなぁ、みんな。

omo: マーティン・ファウラーのキャラじゃないしね。もっと情熱的なんですよ。

A: エヴァンズの方が、そこはいいよね。マーティン・ファウラーは人の話を聞かないよね、基本的に（笑）。そういう感じではない。「コンピューターの勉強」的な話に戻ると……私は最近そういう本を全然読んでないけどね。

ひげぽん: 前提として、Aさんはこれまで凄い量の本を読んでるんですよ、と読者の人に伝えないと。

---- 凄いんですよ、Aさんは

omo: (笑)

A: そんなことはないですが。何故そういう本を……そういう本って区切りも難しいですが、なぜ「教科書的な本」を読んだ方がいいと思ったかというと、そこには、過去に色々と経験をした結果、良さそうだと思ったひとつの答えが書いてあるからで。「体験をすると経験は得られる」んだけど、それが正しいか間違ってるかは、それだけじゃ分からない、という欠点がある。本になっているのは、もう少し多くの例を見た上で、良さそうなモノをピックアップしているので、「経験よりは少し正解に近いもの」が載っている。それを知らずに自己流にやっていると、沢山の例の中からピックアップされたものに比べると、やっぱり劣っている事が多い。

だから、正解を知っていた上で……まぁ自分の場合上手く当てはまらない事が多いので、合うようにアレンジして、それに近い、でもちょっと違うものとして開発していく方が、正解を何も知らずにランダムに当たっていって「良さそうになれ！」と祈るよりは、随分効率が良いと。そう思っていたので、「正解集め」のような事をしていたのが理由ですかね。

---- 実際活かしていけました？

A: そういうのを活かすのは上手い方じゃないかなぁ、とは自分では思うね。「そういうのを読んだらみんな活かせるか」と言ったらそうではないと思うけど、そういうのをちょっとアレンジして適用するのが上手い人はいると思うし、自分はまぁまぁ上手い方だと思う。例えば、OSの本とかコンパイラの本を読むってのは、「色々作ってきた結果、これが良い設計なんだ」ってことなので、OS以外のモノを作る時にも、そういうのを真似して何となく作る方が割と良いものが出来やすい。そういうひとつの正解例を知れるわけで。OSは作らないけど、OSの本は読むという。

ひげぽん: でもそれって、ヒット率が高くないと意味がないですよね、さっきの話からいくと。ヒット率を上げるためにしている事ってあるんですか？ つまり「当たりの本を引く」とか「当たりの分野を引く」とか。

A: 本の選び方でいえば「有名な原典に当たる」ってのを重視してますね。そいつを読んだ後にそれに影響を受けて書いた本よりは、最初に書かれたような本をなるべく読むようにはしてます。そうするとやっぱり分厚い本に当たりやすくて、洋書だったりする事も多いけど、遠回りのようで早いと思う。

omo: ハズレは引いてるんですか？

A: ハズレは結構引いてるねｗ

一同: (笑)

A: そこはやっぱり数を読む事でカバーしている、って所はあると思う。

ひげぽん: 「ハズレを引いた」ってのは読み終わった後に気付くんですか？ それとも途中で気付いてやめるんですか？

A: 途中で気付くけど、やめずに最後まで読む事が多いですね。途中でやめてもいいんだけど。

ひげぽん: おー、それは熱いな。今、さらっと流れたんですけど、「洋書を読む」という壁がいまここに出てきたんですよ。そこは越えておくと楽ですよね。

omo: そこは洋書ブームが来ている人に聞くのが生々しい声が聴けていいんじゃない？

ひげぽん: 仕事とかで論文を読まなきゃいけない、論文は英語で書かれていて、しかも数式も難しい、ダブルで難しい……みたいな事で苦しんだ時に「まずは洋書の技術書から」みたいな事をやってみて。もう翻訳出ちゃいましたけど、"Working Effectively With Legacy Code" (ASIN:4798116831) を英語で読み始めたら、意外と読めるし、翻訳と違う雰囲気を感じ取れますよね。「翻訳待ち」ってステータスがなくなるのも大きい。

A: 最近は良い本の翻訳が出てないって印象があったので、プログラマは洋書を読まなきゃいけなくなりつつあるんじゃないですかね。"Working Effectively With Legacy Code" (ASIN:0131177052) なんてずっと出てなかったしね。最近日本語版が出た (ASIN:4798116831) けど。あんなもん、それこそ2005年に読むから色々と学ぶ事があるんであって、今あれを読むと……別に学ぶことはあるけど、ちょっとまたあの時代とは事情が変わっているので、コーディングも変わっているし、プロセスも変わっているので。

omo: 人によると思うけどねぇ。

A: そうだけどね。ちゃんと先端を追っていれば、あれは時期を逸している感があって。

omo: いやでも、あれねぇ……読んでると当たり前になってる事が色々あって、「あれ？ なんでコレできないの？」って事もあるわけですよ。サブクラス化してエクストラクトすればすれば終わりじゃん、ってところが分かって貰えなかったりすると「おっ」ってのがあるわけですよ。

A: リファクタリングブラウザを使い始めの頃は凄く良い本だと思うんだけど、散々それを使うようになって、それを前提としてその次に進んでいる人には、「まだここにいるのかお前は！」っていうところがあって、やっと日本語訳で出たって言われると、日本語で技術書を読んで一線で働くのは無理じゃないかな、って。

ひげぽん: 一線の定義がなかなか厳しそうだ（笑）。

一同: (笑)

A: 「自分は一線だったか？」と言われると、一線ではなかったと思うけどね。DDDなんて未だに和訳出ないしねぇ。2003年に出て必読書だと思うけど。

omo: あれは多分、翻訳者がつかえてると思うんですよね。

A: 一方でまぁ「読みたい」って本当に思ってる人は少ないのかもしれないね。

omo: いやー、割と引用されてるしさ。"Art of Agile Development" (ASIN:0596527675) って本が日本語になってます (ASIN:4873113954) けど、あれって普通にXPのプラクティスにユビキタスランゲージが入っていて、ユビキタスランゲージって。

A: あの本に出てくるからね。ユビキタスランゲージっていうのは、自然言語に翻訳して専門家と話すという、自然言語がユビキタスランゲージって言われてるものだね。なんか……自分が進歩しただけかもしれないけど、95年とか96年ぐらいは、必読書はもっと翻訳されていた気がするんだけどね。最近は堅い本は翻訳されにくくなって。どんどんと、「英語を読まざるをえない」という度は上がってるかなという気はするね。

ひげぽん: どうせエンジニアって英語のリファレンスを読まなきゃいけなかったりするじゃないですか。その延長で本も気楽に読めるようになったら幅が広がりますよね。

---- 英語に抵抗がある人が慣れていくにはどうすれば良いんでしょうね？

A: 分かんないねぇ。最初に読んだ時は辛かったけどね。最初に読んだ洋書は何だっけ…… "SICP" (ASIN:0262692201) でしたっけ（笑）。あれは最初読んだ時辛かったねぇ、何だこの本、って（笑）。

一同: (笑)

omo: スパルタ系ですねぇ。

A: 「英語版はタダだ」って言うからさぁ。しょうがねぇ、じゃあ英語版読むか、ってプリントアウトして大学時代に読んでてさぁ。何セントかを分けるプログラムとかを、英語が分からないんだかプログラムが分からないんだかよく分かんないなぁ、とかｗ

omo: 学生の頃は、金銭的動機で英語を読む事はあるよね。OpenGLのRedBook (ASIN:0321552628) 日本語は12000円だけど洋書は5000円だよと。じゃあ読むかと。

A: あー、そういうのはあるよねぇ。英語はタダで配られてるのも多いし、安いってのも多いから。

---- 読みやすい洋書と、読みにくい洋書ってありますよね？

A: すごいキツい類のってのはあるよね。

omo: 技術書ってのは、日本語になるから簡単になる、ってことはないと思うんですよ。

A: 今まで読んだ中で一番難しいのは、"Software Factories" (ASIN:0471202843) だね。

omo: (爆笑)

A: 日本語 (ASIN:489100472X) で読むとどうなのかね。俺、読んだことないけど。

omo: いやー、しんどいですよ日本語でも（笑）。

A: あれは何か「しんどいなぁ」って思った本ナンバーワンだけど。でも、ああいう本は必須の本のひとつだと思うんだけどさぁ。

omo: Software Factories?

A: そう。あれは全部読まなきゃダメでしょう、エンジニアは。何の役にも立たないけどねぇ。

一同: (爆笑)

A: 物事をちゃんと理解することは出来るけれど、ちゃんと理解しても書くコードは変わらないという。そういう類の本なんじゃないかな。

一同: (爆笑)

omo: ホントそうだけどさぁ。

A: 「SICPが役に立つか？」って言われた時の一瞬の間と同じだよね。

ひげぽん: 悟りは開けますけどね。

A: 役に立つと言いたいが……みたいなｗ

omo: コンフィデンスを得るんですかね。

A: 例えば "Software Factories" (ASIN:0471202843) をちゃんと読めば、「抽象化」ってものの正体をちゃんと突き詰められるわけで。そこからちゃんと理解している人と、そうじゃない人っていうのは、やっぱりソフトウェアの話をしたり、抽象化の話をしても全然別な事を本当は言っていて、それは本当は大切なことだと思うけど、コードにあまり違いが出ないので。

"SICP" もそういう所はあると思うんだよね。普通にコードを書く時に、C言語でも常識的に綺麗に書くってことが、ただSchemeで綺麗に書かれているだけ、って部分はあるけど、順を追って抽象化の思考みたいなものが書かれていて、そういうのをちゃんと理解していると、C言語でも心の底でそういうのがあって、それがそういう表現になってるのか、ただそういうコードになっているのか、ちょっと違う所があるような気がするので、読んだ方がいい、というけど、新人が今ここにいたとして、全然コードが書けなくて最初に読む本がこれか、と言われると違うなぁと。

ひげぽん: それは違うな（笑）。

omo: どうですか、SICPを読んだ身としては。

ひげぽん: どうですかねぇ。自分は直接の利益としてインタプリタとかコンパイラが書けるようになった、という利益があるんで。

A: あれを見るとSchemeのインタプリタとか書くよね。

omo: 恩恵を得ているレアな例なのかもしれない（笑）。

ひげぽん: コンピュータサイエンスの本ですよね、Schemeの本というよりも。

A: そうだね。

---- 海外の大学では最初にあの本を読むという話ですが

A: そういう噂だよねぇ。

ひげぽん: 最近は読まなくなった、って話もありますよね。無駄に難解なんですよ。

---- 読書会をやってる人が多いですよね

A: 読書会はよく見るよね。「SICP読んだぜ！」ってのがいいんですかねぇ。

---- 三人とも読んでますよね

omo: 僕は途中まで。

A: 俺読んだよ。わーい（笑）。

---- 何をもって「読んだ」なんですかね

A: 最後まで読めばいいんじゃない？ｗ

ひげぽん: いや、「ここの章のアレが」って語れないと（笑）。

A: ダメですかｗ

---- 例題とかやってます？

A: 例題は俺あんまりやってないねぇ。それはひげぽん先生の方が偉いですね。

---- 例題やると違います？

ひげぽん: 違いますね。読み飛ばしたのがもろバレますからね（笑）。

一同: (笑)

ひげぽん: 「全然分かってなかった俺！」みたいな。でも、基本、コンピュータ本の例題はやりませんけどね。

A: アルゴリズムの本だと例題とかやったけどね。

omo: 本の中身を忘れないために、マインドマップを書いてるじゃないですか。あれと例題やるの、どっちが良いと思います？

ひげぽん: それはマインドマップの方が僕は好きですね。見返すとマインドマップを書いて時の感情が思い出せるんですよ。……宗教的になってきましたけど。

一同: (笑)

A: マインドマップの話は宗教的になるんだよね。

ひげぽん: 「マインド」って付くからいけないんですよ。

A: いつもこの話をするとねー、痛い信者みたいになるので俺は最近しなくなったんだけど。

一同: (笑)

---- 痛いところを見せて欲しいですｗ

A: マインドマップの歴史は長いからね、俺は。大学一年の頃とか。コンピュータ触る前から描いてるので。

---- マインドマップを知る前から、それらしいものを描いてた？

A: いや、トニー・ブザンの "頭がよくなる本" (ASIN:4489005261) は受験生必読の本ですよ（笑）。

ひげぽん: 「マインドマップ」じゃなくて「頭脳地図」ってことにすると、印象が変わりますね（笑）。

A: マインドマップは良いけど、この会話の趣旨とは外れる気もする。最近コンピュータの本を読んで描いてないけどね。

omo: 本の中身を忘れるんで、忘れないようにしたいなと思って、マインドマップを描いてる人を見ても、なかなか真似できないんですよね、面倒くさくて。

ひげぽん: でも、ある本を読んでマインドマップを描くとすると、本を読んでる時間の方が明らかに長いんで。

omo: そうなの！？

ひげぽん: 最後の何分の一かの工程をマインドマップに注いで。

omo: どういう粒度で描いてるの？

ひげぽん: 章かセクションぐらいですかねぇ。

omo: 章かぁ。やっぱり章ぐらいだよねぇ。なんかマインドマップってレイアウトとかが上手く行かなかったりするじゃないですか。「あれ、こっちに寄っちゃったよ！」とか。

ひげぽん: それは、慣れないうちは下書きマップを描いて、本ちゃんマップに清書するんですよ。

omo: 最近はもうやらないんですか？

ひげぽん: 「頭の中に書いておいて、最後に」みたいな。

omo: (感嘆)

A: 同じ方向に広げるってのは、慣れが必要だよね。同じ方向に広がられるようになるというのは、マインドマップを使いこなしている事になるという。

omo: 持って来てます？

ひげぽん: ありますよ。最近は手抜きが多いですからね。段々自己流になるんですよ。

omo: お、PCだ。写真に撮ってるんですか？

ひげぽん: 写真に撮ってます。最初は気合入れて書くんですけどね。段々適当に。

A: 俺はあんまり時間掛けないねー。

omo: カラー？

ひげぽん: カラーですねぇ。例えばコレですね。これはDDDのServicesのマインドマップ。これぐらいの粒度ですね。あんまり細かく描いても覚えられないんで。

omo: 覚えるの前提なんだ。

A: マインドマップは、描けば割と覚えるけどね。

ひげぽん: それはAさん記憶力がいいんですよｗ

A: そういう問題じゃないとも思うけど。

ひげぽん: この一番太い枝は覚えますね。細かい部分は、ここを思い出してから何となく「うんうん」唸って思い出すみたいな。

omo: 「何％」とか書いてるじゃないですか、日記に。

ひげぽん: あれは、復習用の単語帳みたいな紙を引いてくると「これを復習しろ」って書いてあるんですよ。その復習しろと書いてあるマインドマップをこれを見ずに書いて、どれくらい一致しているかと。

omo: へぇーっ。ここが復習ワードなんですね。

ひげぽん: 「Servicesって何だっけ？」みたいになって。「どのオブジェクトにも所属しないアレだよ」みたいな所から始まって、「背景はこんな感じ」っていうのを思い出すみたいな。でももうルールを守ってないんです。例えば、絵をもっと描きなさいとか。中心では三色使いなさいとか。色々ルールがあるんですが、段々守らなくなる（笑）。でも色は重要ですね。

omo: 色は重要なんだ。色で覚えてるの？

ひげぽん: 一番重要そうな所は赤くしたりとかするんで。

---- 全部の本でやってるんですか？

ひげぽん: 「マインドマップを描く」と決めてる本だけやってます。

omo: 描かない本もあるんだ。

ひげぽん: あります、あります。軽く読むような本は描かないですね。"Realtime Rendering" (ASIN:1568814240) とかはやってますね。100円ショップで色ペンを買っておいて。会社と家に置いておいて。理解度を試すのに良いですよね、マインドマップは。「見て思い出せるものは描かない」って基本ですね。

omo: 僕は目次が木になってるだけだからダメなんだろうな。

---- 最初に始めた時は、どんな失敗をしてました？

ひげぽん: 最初は、本の作者の思考の流れに沿って描いてたんですけど……つまり、作者が言いたいことがあって、結論が先に書いてある場合もあるんですよ。「こういう部品がある」とか。「これにはこういう背景があって、こういう失敗があって、こうなりました」みたいな流れがあるんですけど、作者の心の流れは自分では思い出せないので、自分の心の流れに変えて描くと。

omo: へぇー。

ひげぽん: 自分だったら、背景がこうあって、困っている事がコレだったからコレが出てきました、みたいな順番の方が分かりやすいんですよ。

omo: そうやってリレイアウトするんだ。

A: マインドマップを描く本は「ちゃんと復習したいなぁ」って本だよね。さらっと読んで終わり、って本ではあまり描かないな。

omo: (自作マインドマップを見せつつ）これは "詳解TCP/IP" (ASIN:4894713209) かな。

ひげぽん: こんな感じですよね。

A: うん。

omo: 描くと凄く疲れるんだよね。あと、これって出てくる順番なんですよ。出てくる順番に、見ながら描いてるから、多分違うんだよね。見終わった後にバンと描いてます？

ひげぽん: どっちもですね。頭の中に入りきらない量だったら、読みながら描きますし。

A: 大学の講義とかはマインドマップでノート取ってたけど、その時は聞きながら描いてたけどね。終わりまでにどういう形になるのか分からないけど、均衡になるには色々と推測しなきゃいけないんで、理解して先を読みつつ描かなきゃいけないという効果はあるね。

ひげぽん: 一発で書けるのが理想ですよね、手間も考えると。

omo: 復習ってフェーズがないからね……。

---- 復習をするようになった理由は？

ひげぽん: 自分が「記憶力が悪い」と分かっている前提で、せっかく本を読んで自分の引き出しが増えたのに、とある会話で聞き覚えのある言葉が出てきた時に「あれ、なんだっけ？」って事がよくあるので、だったら本当に重要な事は覚えよう、って事で復習フェーズを入れました。

---- 復習方法もマインドマップの本に書いてあるんですか？

ひげぽん: 「いつ復習すべきか」とは書いてありますね。翌日、一週間後、二週間後、一ヵ月後かな。「これは何月何日に復習した、次は何月何日」みたいな感じで紙に書いておいて、箱に放り込んでおきますね。

omo: ちゃんと守られてるんですね。

A: それは偉い。俺はそこまで守ってないねぇ。次の日の復習はやるけど、何となく忘れてくる一週間後にもう一度やるぐらいかな。ぴったりじゃないけど、一ヵ月後ぐらいにも復習はしてる。

omo: 復習するんだ、やっぱり。

A: コンピュータの本は最近は復習しないねぇ。語学とかの方が多いかな。

ひげぽん: 語学は効きそうですね。

A: コンピュータの本は、読めば読むほど自分の知らない量ってのが一冊の中で減っていくんで、「殆ど知っていて、ちょっとだけ知らない」ってなっちゃうので、頑張って復習、って感じじゃなくなってくるんだよね。

ひげぽん: 僕は貯金がないんで覚える時期だと思うんですよ。読むと殆ど知らないことばかりなんで。

A: それは「良い本を読んでいる」ってことだと思うけどね。私も知らない事はいっぱいあるはずだけど、知っているような本を引いてしまってる、という事があるからそうなるのかも。

---- トニー・ブザン著の本から入るのが良いですか？

ひげぽん: 原典なので良いとは思いますけど、最近は商売っ気があるんで（笑）、全部まともに読むのはどうかなぁ、って気がします。

A: いっぱい出してるよね。「頭がよくなる本」(ASIN:448900740X) だけでいいと思うけどねぇ。

ひげぽん: 僕もそう思います。

---- 大学の頃というと、だいぶ昔の本ですよね

A: 新しいのが出てるよ。

ひげぽん: マインドマップは宗教っぽいんで、あんまり広げるのは良くないと思います。「あー、こいつらキモいよ」で終わりますよ。

---- 実際そう言われる事は多いですか？

ひげぽん: 「誤解してた」って言われることはありますね。熱く語ると「あー、そうなんだ」って分かってくれますけど、分かってくれたのか、そろそろ切り上げよう、ってことなのかは（笑）。

omo: カードを使う復習の仕方って、オリジナルですか？

ひげぽん: だと思いますが……どうだろ（笑）。

omo: そろそろ本が書けると思うんですよね。「スーパープログラマのための」……じゃない（笑）、「スーパープログラマによる勉強法」。

ひげぽん: そういうのはちゃんと成果を上げてる人じゃないと (笑)。

A: 成果を上げてない人も書いてるよｗ 勉強の本ってのは結構あって、どれも似たような結論が出てるよね。

ひげぽん: それは僕も思いました。僕はある時期Aさんに「ひげぽんは勉強の効率が悪いよね」って言われて、「それはもっともだ」と思って、図書館で「勉強の仕方本」をいっぱい借りて読んだんですよ。そうするとやっぱり共通部分が見えてきて。マインドマップも復習もそうですけど。

---- 勉強の仕方を変える前と後で、違うと感じたことは？

ひげぽん: 復習が足りなかったですね。インプットは足掻いてたんでしょうけど。どんどん頭から抜けていって、何も残らず「あの本は読んだよ」って言えるだけ（笑）。

A: 本のチョイスが気になったね。CPUの勉強をしようと思ったら、ヘネパタを最初に読むものだろうと常識的には思うんだけど、違う本をいっぱい読んでたりしてたじゃん。そういうのが何か違ってたのかなぁ、と思ったんだけど。

ひげぽん: いや、純粋に自分は知らなかったし、周りにそういう人もいなかったという。"はじめて読む486" (ASIN:4756102131) とか読んでましたね。あれも良い本ですけどね。でもあれにはパイプラインストールとかは書いてないんで。

A: 初期の「OSを作ろう」スレでは、"Intel Developer's Manual" を読めよ、って言われてスルーしてた記憶があるけどｗ

ひげぽん: あれはダウンロードして「無理だ」と思ってｗ

A: "Intel Developer's Manual" って分かりやすくない？ 必要最小限のことだけで。

ひげぽん: 今でも厳しいかなｗ

A: ヘネパタってそんな難しいわけじゃないよね、そんなに。

ひげぽん: そうですね。

A: そういう本もあるんだよね。「分厚いけれど難しくなくて定番な本」と「厳しい本」があるんだよな。

ひげぽん: そういう良い本を選ぶ方法を知りたいですね。今はAさんチョイスをパクってるだけなので。

http://d.hatena.ne.jp/ryocotan/20091231/p3 続きの(2)です

補足

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/ryocotan/20090919/p1

id:natsutan ヘネパタとパタヘネは違うと何度言えば

ご指摘ありがとうございます。申し訳ありません、「これかな？」と適当にASINを貼ってしまいました。念のためリンクは外されて頂きました。ヘネパタとパタヘネがあるんですね。