仕事でコード書いてた頃の話。
机上に「本」というメディアは無かった。プログラミングといえばお手本のコピペ&手直しで仕上げてた。だから、せいぜい入門書やリファレンスといった辞書的なやつだけで、3年もすれば「古い」と引き出しの中へ。
だから、いつまでたっても上手なのは「お作法」だけ。あたりまえだ。仕様を実装したコードに「似た」コードやパターンを探し出す→コピペがプログラマの仕事だと思ってたから。ネットの情報が「全て」であって、「考える」とは、「いかにお手本に合わせるか」だったから。
プログラマというよりも、むしろ「コーダー」。その辺は「プログラマになれなかったわたし」[参照]に書いた。
ここでは、「コンピュータの名著・古典100冊」の既読リストで恥さらし。いかにちゃんとした本を読んでいないかがよっく分かる、なさけない。
本書はプログラミングに限らず、ソフトウェアエンジニアとしての liberal arts に相当する書籍を紹介している。時間を経て価値が残る「古典」もある。全部オススメというわけにはいかない(なんせ初めて知った本も沢山ある)。しかし、IT業界で働くあなたの足腰を鍛えてくれる良書がたくさん見つかることは請け合う。
ITだWebだと浮かれ騒ぐのは世間サマだけにしておこう。表層がいかに変わろうとも、コンピュータの原理は変わっていない。Webがどんなに進化しようとも、コミュニケーションの根っこは変わらない。現場の本質は変わらないのだ。変わることに浮ついて、根っこまで流されないように自戒を込めて。
全滅。ぜんぶ未読。コンピュータの起源だの歴史だの知ったって、目の前のコードには役に立たない。だからこの分野は全くチェックしていなかった。インターネットの起源が軍事用だなんてトリビアネタでしょうに、と考えていた。研究材料かトリビアか、あるいは「そんな時代もあったね」といつか笑って語り合うためか。
しかし、これからどっちへ向かうかは、どういう経緯で今に至るかの演繹だから、俯瞰的に状況を把握するため役立つ…のか、分からない。
仮に、「コンピュータ史」という分野があるのだとしたら、それは、コンピュータを分解して→「ハードウェア」「ソフトウェア」の両面から起源と変遷をたぐるものになるだろう。そんな視座なら上記のリストは妥当かもしれないが、あまりにも学問的。むしろビジネスの視座を取り込んだ「ソフトウェア企業の競争戦略」から見たソフトウェア企業の歴史の方が興味深い[参照]。本書は、ビジネス競争戦略の観点からコンピュータ企業をリサーチした集大成。「日本のプログラマの品質は世界最高の水準以上にも関わらず『良いものを作れば売れる』主義を信奉するあまり、ビジネスの本質から離れてしまっている」が強烈なり。
■人物・企業
これも全滅。「ビル・ゲイツ未来を語る」じゃダメ? 時代や技術と人がシンクロして、その技術の代名詞としてのみ記憶に残っている。「闘うプログラマー」でWindows-NTを開発したデビッド・カトラーがスゴいアツい。
■ドキュメンタリー
「コンピュータ犯罪」にソソられる。それも一般の愉快犯からのクラッキングではなく、インサイダーの方。マスゴミが嬉しそうに垂れ流す「コンピュータ犯罪」は稚拙なものばかり。スゴ腕のプログラマがマジメに取り組んだなら、痕すら残さないから、真の意味で完全犯罪なんだろーなー…とぼんより考えたり(もちろんわたしましませんぞ、良い子だから)。
「欺術」は読みたいリストにある。コンピュータやネットワークの脆弱性を狙った、いわゆる「正攻法」のクラッキングではなく、ソーシャルエンジニアリングのクックブックとして読みたい。ハードウェア・ハッキングからショルダーハッキングまで、「非」正攻法はどういったものがあるか、非常に興味あり。以前のエントリをもっと深堀りできそう。
悪のプログラマ[参照]
悪のプログラマ―――もっと冴えたやりかた[参照]
■思想
[東大教官がすすめる100冊]でリストを作ったが、ここにも「ゲーデル、エッシャー、バッハ(10位)と誰のためのデザイン?」(93位)が出てくる。コンピュータを思想的な面からとらえるには外せない書なんだろう。非常に挑戦的な題の「コンピュータには何ができないか」はぜひ読みたい。
「ゲーデル、エッシャー、バッハ」は、いわゆる reflexive(再帰)および自己言及がテーマ。
ゲーデルの不完全性定理、チューリングの定理、人工知能の研究が渾然一体と結び付けられているとのこと。エッシャーのだまし絵やバッハのフーガはこれらをつなぐメタファーとして位置付けられている。分かったようなフリして書いてるが、手にとって眺めたことぐらいしかなく、読んでも頭に入っていない。何度も味読して自分で噛み噛みしなけりゃ「読んだ」ことにならないだろう。これ読んで面白がる人は、いわゆる「頭がいい人」、知性的な人なんだろうなぁ…
「誰のためのデザイン?」は、ぐっと敷居が低くなってユーザーインタフェースの本。ようやく既読本が。
誰だって心当たりがるに違いない→「引いて開けるドアを押してしまったり、押して開けるドアを引いてしまったり、横に滑って開くドアに正面から突っ込んでいってしまったり」 ←これらは普通の人の「うっかり」なのだろうか? ドアなら突き指やデコのコブで済むが、電話機だと? コンロなら? 人間による「操作ミス」でくくられてしまうが、本当にそれが原因なのだろうか? という疑問に真正面から取り組んでいる。
これが類書より頭一つ抜きん出ているのは、コンピュータのGUIや標識の記号論に限定していないところだろう。「動作や機能の本質は、その形態に表れる(のが良いインタフェース)」を、ドアノブからパソコンまで、徹底的に追求している。認知科学者のデザイン論として、あるいはアフォ-ダンスの実論として読める。
「コンピュータには何ができないか」は、人工知能研究の可能性と限界を、哲学的な根本問題にまで遡って論究した、反AI論の古典。
世の中の、それこそありとあらゆる事象は批判にさらされているにもかかわらず、コンピュータについてはあまり聞かない。やれやれドンドン、「できること=やれること=やってもいいこと」の三段論がまかり通っていて、ストップをかけている(かけようとしている)人は見当たらない。あ、「ネット有害論」のような限定化されたやつじゃなく、もっと哲学的な視点からの批判のことよ。本書がこれに相当するのじゃないかと期待。ちなみに、「コンピュータには何ができないか」とは、「コンピュータは何ができないのか」(能力)のことではなく、「コンピュータがしていいことと、してはいけないことがあるのか? あるならその境界は何か?」(許可)のことだと勝手に読み替えている。
■数学/アルゴリズム
これも全滅。これは、わたしが「コーダー」だったことをハッキリと明らかにしている。かっちょいい言い方をしてもいいなら、仕様をコードに書き写すのがコーダー、仕様から最適なアルゴリズムを創りだすのがプログラマ、になるのか。
「いかにして問題をとくか」は原書が1940年、翻訳が1954年出版と、どえらく古いモノ。問題解決の本質はテクノロジーがいかに進もうと、変わっていないことを確認するために、読むべ。宣伝文句は、「問題を解く態度とその喜びを説いた不朽の古典的名著」とのこと。amazonレビューアーによると、マイクロソフトの新入社員は本書を必ず読むことになっているそうな。
プログラミング現役の頃に読んでおけばよかったと思っているのが、「アルゴリズムとデータ構造」。プログラミング学習の王道にして必読書、だそうな。名著100冊にある紹介文が耳に痛いが引用する。
プログラマ的能力のない人間が書いたプログラムは、「だいたい正しく動く」が、非効率だったり、特殊な状況で誤動作するものだったりする。場当たり的なコードがツギハギで入っており、「アルゴリズムとデータ構造を整理して考えろ」と諭されても直るものではない。これは現場での試行錯誤で簡単に身につく能力ではないのである。
■コンピュータサイエンス
これも全滅。記号学や認知論、言語処理といった、体系的にコンピュータサイエンスに取り組むなら、必ずたどりつくラインナップ。見方を変えると、上記のリストを起点として掘り下げていってもいいのかも。ただ、実利を求める立場からすると、なんだかガクモン的なにおいがする。現場にまみれる前にやっておけ、というやつなのかも。
「やさしいコンピュータ科学」は、米国大学で最初にコンピュータ全般を学ぶ講義の教科書とのこと。特に難しい数学があるわけでなし、情報科学や情報工学に興味がある高校・大学生に向いているそうな。使用言語はPASCAL。即効性はないかもしれないけれど、わたしたちがノイマン型から脱却しない限り、いつまでも「読める」テキストであるにちがいない。
■アーキテクチャ/OS
これも全滅。わたしは何をやってきたのだろう、ぢっとキーボードを見る。大学でキチンと情報処理科目を選択した奴が読む「教科書」だよ、とうそぶきたい。アーキテクチャのオーバービューなら、「コンピュータはなぜ動くのか」と「プログラムはなぜ動くのか」を押さえておけばよいのではないかと(てか、その奥の良本を知らない)。
■コンパイラ/言語
■プログラミング
いくつか既読が出てくるけれど、本当に読んでおくべき「プログラミング作法」「The Art of Programming」は未読。なんとも中途半端。
「デザインパターン」は読んだが頭が追いつかない。読んだ、じゃなくて眺めた、だね。分かったツモリ君になるのもシャクに触るので、分からねぇと触れてまわってたら結城さんの「Java言語で学ぶデザインパターン入門」をオススメされる。これは分かった!「パターン解説→コード→発展」と読むのではなく、いきなりコード読んで「なんでそう書くの?」という疑問を解説で確かめるやり方で読んだ。パターン厨が「GoFにあらずんば…」と本書を攻撃するけれど、あたしにゃこれで充分。
オブジェクト指向「らしさ」を学んだのは「憂鬱なプログラマのためのオブジェクト指向開発講座」のおかげ。今じゃそれこそ山ほどのOO解説本が出回っているが、当時はこれにかじりついてた(3回くり返して読んだ)。いわゆる「教科書的」でないところがよく、後編のミサイルゲームを用いた解説は非常に面白く読めた。OOの本質は「ミサイルの当たり判定をミサイルそのものに持たせる」あたりで目が開いた。
■ソフトウェア開発
ワインバーグ、デマルコ、人月の神話とメジャー級が並ぶ。開発方式、方法論は沢山書籍が出ているけれど、わたしが選んでもやっぱりこれらは外せない。ただ、「ワインバーグ(あるいはデマルコ)ならコレじゃないの?」というツッコミはある。
「人月の神話」は原書が発行されて20年以上経つが、全く古びない。いや、読むたびに気づかされる点が増えてくるのが面白い。初読ンときは「構造化無用、OO万歳」だったのが、そもそもOOを銀の弾丸と見なす時点で、ジ・エンドだと気づかされる。また、「遅れているプロジェクトへ要員を追加することは、は火に油」とあるが、実践では押し付けられた追加要員をどうやって上手くまわすかを学んだ。古典・名著だからガクセーさんにオススメする人がいるが、むしろ実践で酷い目に遭ってきたPMこそ味読して欲しい一冊。
■データベース/ネットワーク
これも全滅。「初心者のための~」とか「○○入門」といった本なら読み散らしてきたが、基本に相当するこれらは一切読んでいない。言い換えると、入門から一歩も先へ進んでいないとも。入門だけは沢山カジって、あとは実践投入で鍛える。今から考えるとそら恐ろしい冷や汗モンだな。それでもチームリーダーがスゴいプログラマだったので、こんなわたしでも駒として動けたんじゃないかと。
名著100冊の紹介はこれにて終了。このリストに「ない」名著が沢山あることは急いで指摘しておかねばならない。なぜなら、このリストを見たら「ソレを名著というなら、コレは?」というツッコミをしてくてウズウズするだろうから。
例えば、どのジャンルに入るか迷うが、UMLも入るだろ。原典なら、UMLによる統一ソフトウェア開発プロセス(イヴァー ヤコブソン)だけど未読。ファウラー氏の「UMLモデリングのエッセンス」を何度も読んだが、名著100冊に入るか微妙。
こうしてみると、オブジェクト指向開発の書籍が少ないことが分かる。アジャイルなんてまるでない!「ハッカーと画家」なんて入れたくなるね。あるいは、知識体系をまとめたガイド(SWEBOK)もない。それでも、新しめの書籍は各章最後のコラムで紹介されており、名著100冊と謳いながら100冊+αとなっている。OOの良本はここで拡充できる。
何を入れ何を外すかは意見の分かれるところ。「今から10年経っても読むべき」基準で考えると、また違ったリストができあがるかもー

この記事へのトラックバック一覧です:コンピュータの名著100冊:
»JavaプログラマのためのUML [もぼなもな書房]
JavaプログラマのためのUMLこれとargoumlのコードジェネレータでUMLを覚えました。って、まだ一部だけだけど。UMLは結局コードに...[続きを読む]
受信: 2009.03.30 15:37
»C++によるXML開発技法 [もぼなもな書房]
C++によるXML開発技法XMLというとJavaばっかりで、C++からどう使うのか情報を求めていた。C++とXMLという組み合わせではこの本が唯...[続きを読む]
受信: 2009.05.26 01:00