2009年05月29日 18:30 [Edit]
他山の宝石 - 書評 - プログラマーのジレンマ
日経BP高島様より献本御礼。
はてなブックマーク - 【書評】プログラマーのジレンマ：シロクマ日報：ITmedia オルタナティブ・ブログ
個人的に id:dankogai さんの感想がすごく聞いてみたい本。日経BPは献本してないんだろうか。
お待たせしました。
結論から言うと、プログラマーに限らず、まだこの世に存在しない製品を作ろうとしている人はぜひ目を通しておくべき一冊。それだけに翻訳の質の低さが目に余るが。本書の価値はそれを補ってあまりある。
本書「プログラマーのジレンマ」というタイトルだけ見ると本書は Brooks の「人月の神話」の系列に属する本に思われ、また実際に本書には「人月の神話」からの引用が頻繁に登場するが、原題は"Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software"、直訳すると「コードで夢見て：２ダースのプログラマー、三年の月日、たった一つの超克的ソフトウェアの探求」であり、むしろ「闘うプログラマー」以来の、実際のソフトウェア開発の希有なドキュメンタリーというのが正しい。
目次 - 日経BP書店｜商品詳細 - プログラマーのジレンマより- プログラマーのジレンマ
- 第０章 ソフトウエア時間［一九七五年〜二〇〇〇年］
- 第１章 絶望［二〇〇三年七月］
- 第２章 アジェンダの魂［一九六八年〜二〇〇一年］
- 第３章 プロトタイプとパイソン［二〇〇一年〜二〇〇二年十一月］
- 第４章 レゴの国［二〇〇二年十一月〜二〇〇三年八月］
- 第５章 犬とギークの扱い方［二〇〇三年四月〜八月］
- 第６章 デザインへのこだわり［二〇〇三年七月〜十一月］
- 第７章 プログラマーとデザイナー［二〇〇四年一月〜五月］
- 第８章 ホワイトボードと付箋［二〇〇四年六月〜十月］
- 第９章 開発手法をめぐる旅
- 第10章 エンジニアとアーティスト
- 第11章 ドッグフードへの道［二〇〇四年十一月〜二〇〇五年十一月］
- エピローグ 未来への掛け［二〇〇五年〜二〇二九年以降］
- ペーパーバック版あとがき［二〇〇六年一月〜二〇〇七年九月］
- 訳者あとがき
- 参考文献
本書は、Chandlerという名のソフトウェアプロジェクトを、一人のジャーナリストが三年に渡って追い続けてきた記録である。その過程で、読者はなぜソフトウェアの開発には「ソフトウェア時間」がかかるのか、素直に言えば「絶対に納期に間に合わない」のかを追体験していく。実際、Chandlerは本書の完成前にVersion 1.0が出ることはなかった。
こういった時のいいわけには、ほぼ100%「不足」が理由として取り上げられる。プログラマーの不足、予算の不足、そもそも時間の不足。その点において、Chandlerプロジェクトほど恵まれたプロジェクトはそうはない。
【書評】プログラマーのジレンマ：シロクマ日報：ITmedia オルタナティブ・ブログあえて一言で言ってしまえば、『プログラマーのジレンマ』はよくあるデスマーチのドキュメンタリーです。しかし他の類似書と異なるのは、取り上げられているチームがまさに「ベスト・アンド・ブライテスト」であるという点。ロータスデベロップメント設立者/ロータス1-2-3開発者/OASF（オープンアプリケーション財団）創立者などなどの華々しい肩書きを持つミッチ・ケイパーが、同じく華々しい経歴を持つ天才プログラマー達（Mac OS開発者のアンディ・ハーツフェルドや、ネットスケープ創業時メンバーで「クッキー」考案者のルー・モントゥリなど）を集め、「チャンドラー（Chandler）」というPIM（Personal Information Management、個人情報管理ツール）の開発に乗り出すというストーリー。しかも予算は潤沢にあり、商用ソフトを開発しているわけではないのでリリース時期も自由、という恵まれた状況です。これで最良にして聡明なチームが失敗するはずがない――と思いきや。チームは迷走に迷走をかさね、本書の副題にある「夢と現実の狭間」でプログラマー達は苦しむこととなります。
こういってしまうのも何だが、Chandler Projectが遅れた一番の理由は、この「不足の不足」だ。そこには「渇望」というものがまるで見られない。何がなんでも「これ」が欲しいという意欲が著しく欠如していたのだ。これで納期どおりに出来ると思う方がおかしい。
しかも、その「納期」というものが、 Chandler Project ではきちんと設定されていない。「納期」は英語で"deadline"というが、「死線」という厳しさはそこには見られない。皮肉にもそれは Chandler Project にミッチ・ケイパーという「ものわかりのよすぎる旦那」がいたことが原因となっている。そもそもオープンソースでものごとを進める時点で納期の厳格性は幻覚になってしまうというのも事実だが、それを差し引いてもケイパーのものわかりのよすぎさは目に余る。
それでも、 Chandler Project は失敗とは言い切れない。実際現在 Version 1.0 が出ている。これまた皮肉にも、 Chandler Project がオープンソースプロジェクトだからだ。オープンソースプロジェクトであるがゆえに、金の切れ目がプロジェクトの切れ目とはならない。リポジトリさえ生きていれば、プロジェクトは死んだことにはならない。そしてリポジトリの生命維持にかかる費用は、現代では驚くほど少ない。そういう「死に損ない」のプロジェクトは、オープンソースプロジェクトにはごまんとある。
しかし、「死んでない」からといって Chandler Project が失敗ではないとは、さらに言えない。Chandler がやろうとしていたことは、Mac OS X Leopard がほぼ実現してしまったようにも思えるし、カレンダーだけなら Google Calender をはじめてとする Web アプリケーションがすでにある。もはや Chandler はユーザーから見てお呼びではないのだ。
そう。Webアプリケーション。Chandlerにとっての不幸は、まだWebアプリケーション、というよりそのプラットフォームたるWebブラウザーが未熟だったうちに開発がスタートしたことだ。早すぎたのである。こうした「早すぎた」例というのはITの世界ではごまんとある。ハイパーテキストというのは実はかなり昔から存在した概念であるが、Web以前のものは、今から見ればすべて「失敗」に入るだろう。
しかしその失敗の、なんと豊穣なことか。本書の価値は、まさにそこにある。これほど豊富かつ包括的な失敗例というのは、そう簡単には手に入らない。失敗は教訓の宝庫であるが、それだけにそれがプロジェクトの外に出てくることは少ない。他山の石、いや宝石である。
それだけに、本書の邦訳のひどさは目にあまる。いや、日本語がこなれていないということではない。この点に関しては本書は合格点だ。しかし、用語はひどい。なんでもカタカナにすればいいってもんじゃない。「パイソン」「パール」はまだかつて見たことがあるが、「ルビー」かよ、ルビー。
それでも、まだ全部カタカナになっていれば、「そういうポリシーで行きます」という確信犯ということだからまだ許せる。なんで FORTRAN と COBOL はアルファベットなんだ？なんで「ジャバ」でも「ジャヴァ」でもなくて Java なんだ？そして極めつけに、
P. 307のちにAjax（非同期JavaスクリプトとXMLの略)と呼ばれるようになる
だよ、Javaスクリプトですよ orz。ここまで翻訳によって臨場感が損なわれる例も珍しい。訳者はネットサーフィンというものを知らないのだろうか。なぜ「今、そこにある」言葉で訳さなかったのだ。
人は、成功よりも失敗からの方が学びやすい生き物であるという確信を、私は年々強くしている。その意味において、本書ほど豊穣な失敗録は、ITの世界ではかつてなかった。本書は、ものごとづくりに関わるものであれば一度は目を通しておくべき他山の宝石なのだ--その翻訳の失敗をも含めて。
Dan the Programmer
この記事へのトラックバックURL
意外と多い
どっちかというと、編集者がきちんと指針を示すべきだと思うが。
もっと根拠のある問題かと思った。
Rubyだって普及すれば一般向けにフォートランとかベーシック
みたいにカナ書きもありなんじゃない？
# 私もよくやる
"Javaスクリプト"は誤った用法だよ。(非公式なコトバという意味ではなく。)
"Javaスクリプト"と"JavaScript"では"Indiaな島々"と"Indonesia"ぐらいに違う。
JavaScriptはそれで一つの単語であって、Java + Scriptなんて風に分割したら意味が全く通らない。
インドネシアをインド諸島って呼ぶのと同じくらい愚かなことだと思うよ。
実際この名前のせいでJavaScriptをジャバジャバ呼びよるアマグラマーが絶えない訳で。
・・・Javaじゃねぇっ！JavaScriptだっ！
# だから、Java + Scriptを連想させない「ジャバスクリプト」ならまだ許容範囲…かな？
・・・が、"ルビー"と"Ruby"に関しては、あまり執着がないので分からない(笑)
教えて、詳しい人
