「プログラマーのジレンマ」：スコット・ローゼンバーグ著

〓　戦わないプログラマーたちのドキュメンタリー　〓

　日本では1988年ごろに表計算ソフトの代表格であったロータス１２３というソフトウェアの開発者ミッチェル・ケイパー。彼はその後ロータスを辞めてオープンソースアプリケーション財団(OSAF)を創設し、チャンドラーというPIM（個人向け情報管理ソフト）の製作に夢と資金を託します。チャンドラーの開発を開始したのは、2001年ごろの出来事です。
　集まったメンバーはいずれも過去の実績をもつ、名のあるプログラマーばかり。当然1年か2年でチャンドラーが画期的なソフトとしてリリースされると思いきや…。プロジェクトは最初から躓き、まったくコーディングに手がつかずに一年を経過してしまう。その後も遅々として開発は進まず、データベースの仕様さえまとまらない始末。さらに、モジラの開発者が加わりWebベースでの開発を促すにもかかわらず、Pythonという言語での開発にこだわり続ける。集まったメンバーにJavaの開発者が多かったにもかかわらず、なぜ彼らは自らの能力を発揮しづらい開発環境を選択しなければならなかったのでしょうか。

〓　船頭多くして船山に上る
　この本は、ソフトウェア開発の現場におけるドキュメンタリーです。この本に近い内容の本としては、最近復刻された「戦うプログラマー」を揚げることができます。しかし、「戦うプログラマー」で登場する、WindowsNTの開発プロジェクトを進めたデビット・カトラーは、物事を強引に推し進め、時には怒りに任せて壁に穴を開けたりするタイプのリーダーでした。一方、チャンドラーのプロジェクトオーナーとして登場するミッチェル･ケイパーは冷静で理論的であり、めったに怒ることは無かったようです。しかも彼はDOSベースでの開発しか経験していないような、業界的には古い人。かつ集まったメンバーはボランティア的に仕事をしていたりと…。
　しかし、物申すプログラマー集団に対して、トップ強いリーダーシップを発揮しない限りプロジェクトが失敗するのは目に見えています。そのことが要因の全部とは言いませんが、しかしこのことは、新しいものを開発したり製作する場合には当てはまることだと思います。結果的に、リーダーたちをまとめるだけの力が、ケイパーには無かった。そして船は迷走を続けたということではないでしょうか。その迷走の様子を、著者は取材を続け、この本に著しました。そして、チャンドラーのバージョン１がリリースされる前に取材をやめて、本書の執筆に取り掛かったようです。

〓　プログラミングに関する考察
　終盤の9章と10章は、ドキュメンタリーからは外れて、プログラミングに関する考察を進めます。特に「第10章　エンジニアとアーティスト」の章では、プログラミングが科学なのか芸術なのかといった命題に触れます。内容的に大変面白いです。例えば、天才プログラマーであるビルジョイが、本を執筆した後にそれをやめてまいます。その理由は、ビルジョイにとっては「コンピュータが理解できるように書くのはたやすいが、人間が理解しやすいように書くのは難しい」からでした。この事実を述べた少し後に、次のような記述があります。

409ページ
クヌースは、TEXとメタフォントを開発したことで、ビル・ジョイとは正反対の結論に達した。ソフトウェアを書くことは、本を書くより「はるかに難しい」

　私自身はこの本を楽しく読めました。私がこの本を読んで得たのは、例えばPythonがモンティ・パイソンという番組名から取られているというゴシップ的な内容から、GTD（Getting Things Done）という仕事の進め方に関するノウハウの存在など、多岐にわたります。それは、以前私はプログラマーをやっていて、この本に出てくる一般的ではない用語や事象に興味をもてるからに他なりません。なおさらのこと、いま現在システム開発を生業としてる方にはぜひとも読んで欲しいと思います。この本に、プロジェクトを失敗させない教訓がうずたかく積みあがっていることを知ると同時に、数々の教訓が生かされえない現実を知ることができるでしょう。

　おそらくこの本は読者を選ぶと思います。私は、以下のような方々にこの本をお奨めします。

1. 『戦うプログラマー』を楽しく読んだ人
2. ブログラマーとして戦っていたので、『戦うプログラマー』を読む暇がなかった人。
3. もし、『戦わないプログラマー』という本があったら、読んで見たいと思っている人。