2004年2月2日
Jeff Atwood / 青木靖 訳
2004年2月2日
|
Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための｢楽しい料理｣本だ。この本を読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。この本を読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこの本がすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。この本ではやるべきでない悪い例には"coding horror"アイコンで印が付けられている。そして読んでいてcoding horrorほど可笑しいものはない——自分でそれに対処する羽目に陥るまでは。そして突如としてそれはそんなに可笑しい話ではなくなる。だから何よりも前にこの本を読むことだ。そして同僚にも、何よりも前にこの本を勧めることだ。
更新 2004/6/27: Version 2.0がリリースされた! |
|
|
|
|
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) [ 人月の神話―狼人間を撃つ銀の弾はない ] おそらく我々の分野で唯一古典と呼べるのがこの本だ。まだ読んでないなら恥ずかしいと思った方がいい。 人月の神話を手に取ったとき、そのとうに存在しないOSと、それを開発したとうに存在しないチームの話が、現在にも驚くほど当てはまることに気付かない開発者はいないだろう。この25年も昔の本は１つのことをはっきりと示している。 コンピュータは変わっても、人間は変わらないのだ。 この古典を読むことが、今日の1000ページもある技術本にかじりついているよりも、いい時間の使い方であることは間違いない。 |
|
|
|
|
Don't Make Me Think: A Common Sense Approach to Web Usability [ ウェブユーザビリティの法則 改訂第2版 ] 私が読んだ中で一番いいユーザビリティの本がこれだ。タイトルに｢ウェブユーザビリティ｣とあるが、Webに限った話ではない。スティーブ・クルーグはこの本でユーザビリティのあらゆる重要なコンセプトをカバーしており、しかもとても良くカバーしている。読 んでいてとても楽しい本だ。ユーザビリティについて1冊だけ読むつもりなら、この本を選ぶといい。すばらしい情報がぎっしり詰まっていて、それが簡潔で取っつきやすい形で提示されている。技術系、非技術系、ユーザ、開発者、マネージャ、そのほか、どんな立場の人にもお勧めできる。
まあ、確かに、こんなミーティングに出たことはない。しかしこの問題に対する解法が何かというなら、通常はユーザビリティテストをすることだ。終わりのない議事妨害スタイルの宗教論争をするかわりに、実データに基づいて決断をするのだ。 そうすれば全然変わる! |
|
|
|
 |
Rapid Development [ ラピッドデベロップメント―効率的な開発を目指して ] この本の正式なタイトルは"Rapid Development: Taming Wild Software Development Schedules"(ラピッドデベロップメント: 野生のソフトウェア開発スケジュールを飼い慣らす)だ。これは長ったらしくてばかみたいというだけでなく、残念な誤称でもある。 ｢ラピッドデベロップメント｣はラピッドデベロップメントの話ではない。これは失敗の現実についての話なのだ。ソフトウェア開発プロジェクトは大多数が失敗する。スケジュールを超過し、成果は水準が低く、あるいは完成さえされない。これは議論しているのではない。単なる統計的な事実だ。ありがたくない真実を言うなら、あなたのチームは、成功どころか失敗を避けるだけのためでも非常に優れている必要がある。これはがっかりする話に聞こえるかもしれないが——って言うか、がっかりする話だが——それでもあなたはこの本を読みたくなるはずだ。 なぜか? それは成功の半分*は、自分や他の人たちが犯した誤りを繰り返さないことで得られるからだ。この本で示されている洞察は、誤りは犯して構わないということだ——それがすべて新しい誤りである限りは。 しかし毎度お馴染みの誤りを犯すなら、始める前から失敗していたことになる。そして恐らく今の時点では 、そういった誤りを犯す可能性がどれくらいあるのか見当もつかないだろう。 我々がいるのは、変わらないことは変化することだけという数少ない分野の１つだ。だから変化を受け入れて、違った｢ラピッド｣デベロップメントテクニックを試みるのももっともなことだ。 しかし逆は正しくない。最新のホットなテクノロジーといえど、1970年 以来の古いソフトウェア開発の教訓が意味をなさないほどに変わっているわけではない。いつものごとく、コンピュータは変われど、人は変わらないのだ。少なくとも、始める前に何がうまくいき、何がうまくいかないかのアイデアを持っておく べきだ。マコネル言葉で言うなら、｢塗り始める前にペンキ缶に書いてある指示くらい読め｣ということだ。そんなことは当然のことのように思えるだろう。この本を読んで、我々の分野ではそれが実際のところ滅多になされていないことを知るまでは。 * この本によると、正確には1/4だ。しかし私はそれより多い気がする。 |
|
|
|
|
Peopleware : Productive Projects and Teams, 2nd Ed. [ ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵 ] スポーツのオールスターチームがまずい監督のためにひどい成績に終わるのを見たことがあれば、この本の言わんとするところが分ると思う。｢コーディングのスーパースター ｣が何人いようと、彼らが互いにコミュニケートできず、何も同意できない場合には機能しない。そしてどんなに才能があろうと、絶えず細かい邪魔が入り続けるなら、開発者は効率的に仕事することはできない。開発者が認められているのは対人スキルによってではないが、皮肉なことに、プロジェクトの成功がかかっているのはそこなのだ。名前だけでな い、本物の ｢チームリーダー｣になりたいという望みを持っているなら、この本を読む必要がある。 この本にはまったく優れている当を得た議論がいっぱい詰まっているが、社員が職場環境をあるレベルでコントロールできることを前提としているところがあり、それは多くの企業では純然たるファンタジーだろう。しかしこの本を読めば 、少なくとも仕事環境やチームに本当の問題があるときにそれと気付くことができ、そしてさらに重要なのは、それに対してどうすべきかが分るということだ。 |
|
|
|
|
The Design of Everyday Things [ (ハードカバー版"The Psychology of Everyday Things"の日本語訳) 誰のためのデザイン?―認知科学者のデザイン原論 ] ソフトウェア開発は非常にフラストレーションのあるものになる可能性があり、それはあまりに多くのことがまずくなり得るからだ。そのため私達のすることの多くは防御的なものになる。何かがまずくなりそうなとき、そうなる前に気付けるようにするのだ。これは心理的に疲れることであり、結局ネガティブな形 となって現れやすい。私はこのことを非技術的な人に説明するときに、よく何千という可動部品からなる時計を組み立てようとしていることに喩える。あらゆる部分がほんのちょっとしたことでランダムに故障しかねないのだ。 ソフトウェアをデザインするのは確かに難しいが、ドアをデザインするのだって難しいのだ。デザインのニュアンスはあなたの触るあらゆるものに及ぶ。新しいホットなSQLエンジンであろうと、質素な靴であろうと 、それは変わらない。この本は｢細部に宿る悪魔｣についての新たな理解をもたらしてくれる。ドアのデザインが私達の考えていたように簡単なことでないのであれば、私達がソフトウェアを完璧にデザインできないとしても大目に見てやっていい時かもしれない。 |
|
|
|
 |
About Face 2.0: The Essentials of Interaction Design [ (初版の日本語訳) ユーザーインターフェイスデザイン―Windows95時代のソフトウェアデザインを考える ] Visual Basicの父であるアラン・クーパーは、ユーザビリティの祖父でもある。正直に言って、私はこの本を読んでから何年もたつ。1995年頃に出たときに買ったので、私が持っているのはこの本の｢古い｣1.0バージョンだ。(自分の本を改訂版を出すことで陳腐化させてしまうのは悪いユーザビリティじゃない?) この本は、GUI Bloopers同様、一貫したGUIを提供するためのどちらかというと堅苦しいルールブックだ。しかしこの本はもっと広く適用可能なガイドラインもたくさん含んでいる。実例として挙げられているGUIの問題——古いWindows 95 UIから取られている——には、おおむね解決されているものと(ダイアログでの選択の結果どうなるかを、実際に適用する前に視覚的に例示する)、いまだ解決されてないもの(モーダル処理の中断)があり、比較してみるのも 面白い。 GUI Bloopersとは違い、この本はすべてweb以前の話であるため、webのイデオムやそのGUIデザインへの影響についての話はない。しかしそうであってもすばらしく有用な本だ。私の最近の.NETプロジェクトでも、どのエラーメッセージをモーダルで出すべきかについての章が役に立った。 |
|
|
|
|
The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity [ コンピュータは、むずかしすぎて使えない! ] これはペルソナというコンセプトを世界に紹介した本だ。ユーザを抽象的で記述困難で無定型な人の集団と考える代りに、ペルソナでは名前を持ち、個性を持ち、ニーズを持ち、目的を持つ具体的なユーザを考える。我々のユーザはプリントプレビュー機能を欲しがるだろうか? ひょっとしたらね。しかし会計担当部長のゲリー・マンハイムなら仕事で週次支出レポートをプリントアウトしなきゃならないので、プリントプレビュー機能は彼には必要だと思った方がいい。ここに魔術的なことは何もない。いつものように、問題はユーザは誰で、彼らが実際していることは何かということに帰着 されるのだ。そしてペルソナのテクニックはそのためのすばらしい手段になる。 それからまた、ここでは開発者たちが自分を｢普通の｣ユーザの代りにユーザビリティ上の決断をする資格があると考えがちだという興味深い分析もなされている。開発者というのは、変わり者で極端なユーザというのがせいぜいだ。 ｢ホモ・ロジクス｣対｢ホモ・サピエンス｣だ。書いているのがたまたま開発者をエンドユーザとするコンパイラだというのでもない限り、そういうことにはならない 。 この本の隠れた教訓に、デザインがどれほど良いかは時に問題でないというのがある。アランが取り組み、そしてこの本で例として使われているスキャナのソフトウェアとWeb開発ソフトウェアは、いずれもユーザビリティとは関係のない理由によってマーケットで失敗した。ユーザビリティがはっきりと優れたものであったにもかかわらずだ*。ときに優れた製品が、開発者の手の届かないところで、いかに努力しているかに関わりなく失敗することがある。この事実を、時にうぬぼれたこの本のトーン の釣り合いを取るのに使うといい。 ともあれ、これはクーパーによるもう一つの優れた本であり、About Faceの論理的な延長となっている。About Faceでは、クーパーは｢永遠の中級者｣を対象読者としてい た。ここではより具体的で、したがってそれを対象として開発するのがより容易なペルソナへと純化されている。 * 私はこの本で描写されている｢舞台裏｣のUSBスキャナとちょうど同じモデルのスキャナを持っていたが、バンドルされたスキャナソフトには非常に感心していた。私はそのうちこのスキャナを父に譲ったのだが、ある時電話で話していて、父がなんの脈絡もなしにそのスキャナソフトがすごく気に入っていると言ったことがあった。この本が出版される前の話だ。 |
|
|
|
 |
GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers Windows 95とApple System 7の古き良き昔には、本物のGUIルールがあった。そしてこれは筋金入りのGUIデザイン本だ。メニューの省略記号、ダイアログ上のボタンやテキストボックスのアラインメント。ユーザがそれらのルールをどこまで理解しているかは疑わしいものだが、少なくともそれによってアプリケーションAのUIがアプリケーションBのUIと とても良く似た振る舞いをするようになることは期待できる。 ｢古典的｣GUIデザイン原理の再教育コースを受けるのはいいことだと思う。新進のFlashデザイナが日々自分で新たなGUIをスクラッチから(カスタムサウンドトラック付きで)作ろうとしている今日のWebの荒れて雑然とした現状と比較してみるためにも。 クラシックなGUIの世界とブラウザの世界は、両者の一番いいところを取って融合しつつあるというのが現実だ。ブラウザのようなUIを持ったアプリケーションの大きな一群があ り、これはInductive User Interfaceとして知られて いる。私が最初に目にしたのは、2000年頃に出たMicrosoft Moneyだった。Windows Vistaでは2者のより多くの収斂が見られるだろう。 |
|
|
|
|
Programming Pearls (2nd Edition) [ 珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造 ] ｢珠玉のプログラミング｣をこのリストに含めるのにはためらいを感じた。ごくローレベルなコーディングテクニックを扱っているためだが、この本にはソフトウェアクラフトマンシップの ｢珠玉｣が十分たくさん埋め込まれており、すべての開発者にとって価値あるものとなっている。このグラフを含む本には、同じ重さの金の値打ちがある。
48nアルゴリズムとn3アルゴリズムの違いを見せるために、TRS-80 と DEC Alphaを対比させている。これ以上にうまく表すことはできないだろう。珠玉のプログラミングを読むことは、プログラミングを学ぶための方法として、プログラミングの達人の側で1年かそこら仕事するのに次いで優れた方法だ。ここには多くの職人コーダーたちの集合的知恵が、簡潔で飲み込みやすいコラムの形で抽出されている。 私はあなたに嘘はつかないことにしよう。この本にはまったく無視して構わない章がいくつかある。たとえば、11、14、15章にあるソートやヒープやハッシュアルゴリズムを実装するという話は、 そのような基本的なものに対する成熟したライブラリがある今日の環境では考えにくいことだ。しかし教科書的で退屈なエクササイズの１つ１つにも、実践的なアドバイスが添えられている。この本をただ通して眺めてみて、コードの部分は読み飛ばしたとしても、失望することはないだろう。コラム7の｢封筒の裏｣は 特に重要であり、私が知る限りパフォーマンスの見積に対する最高の方法が示されている。それから企業が私達を煩わせる狂った面接質問に対しても、 すごく役立つだろう。 まだ決断できないというなら、この本の一部がオンラインで読めるようになっている。私は最近この本の文字列についての章を、空のデータベースを埋めるデータの生成にマルコフ連鎖を使う方法を解説するときに使った——これは ｢封筒の裏｣で扱われているパフォーマンス見積のテクニックだ。 |
|
|
|
|
The Pragmatic Programmer: From Journeyman to Master [ 達人プログラマー―システム開発の職人から名匠への道 ] この本は珠玉のプログラミングを思わせる部分が多くあるが、実際もっと良く、それはコードに首を突っ込むことが少ないからだ。コードについて気にする代りに、著者らは実世界で 役立つことが分った実践的なアプローチをこの一冊の中に集約している。その全部がプログラミングの話というわけではない。一例を挙げよう。
こういうところこそ、達人プログラマーを非常に優れた本にしているのだ。 この本についてもう少し詳しく知りたければ、本に入っている折り込みのリファレンスカードをHTMLにしたものを作ったので、それを見てみるといい。概要が掴めると思う。 |
|
|
|
|
Designing Web Usability : The Practice of Simplicity [ ウェブ・ユーザビリティ―顧客を逃がさないサイトづくりの秘訣 ] ヤコブ・ニールセンは彼のユーザビリティについてのサイトと、最初の本が出た1989年以来のユーザビリティ専門家としてキャリアによって広く知られている。この本はもっぱらWebユーザビリティを扱った入門書で あり、そのためクーパーのGUI指向の本とはちょっと違っ たものとなっている。 |
|
|
|
|
• The Visual Display of Quantitative Information
情報は美しい。そして良くデザインされたGUIもまた美しい。 完全主義者(あるいはマゾヒスト)でもない限り、シリーズを3冊ともそろえる必要はない。しかし最初の2冊は必須だ。 クリス・セルズは、彼自身が2004年6月に参加したタフティのセミナーに基づいて、タフティの本に 関する興味深い洞察を示している。 |
|
|
|
|
Mastering Regular Expressions, Second Edition [ 詳説 正規表現 第2版 ] UNIXは複雑で不可解だという評判を受けている。正規表現もしかり。 私は"Keep It Simple Stupid"を信条としているが、正規表現については隕石サイズの例外をもうけている。適切に書けば、正規表現は文字列操作で驚くほど時間を節約してくれる。そしてどこかに正規表現の使いどころがないようなプロジェクトというのは 、いまだかつて見たことがない。自分で確かめてみるといい。 ひとたび正規表現の世界に足を踏み入れると、あなたはその驚くべきパワーとポテンシャルに酔いしれ、Perlみたいなことになるかもしれない。覚えておいて欲しいのだが、絶対的なパワー(権力)は絶対的に腐敗するのだ。しかしそれが最高にいかしていることも確かだ。 |
| home rss | ||
|
© Copyright 2004 Jeff Atwood. All Rights Reserved. |
||
