プログラマーのジレンマ 夢と現実の狭間

著者 : スコット・ローゼンバーグ 伊豆原弓

• 日経BP (2009年5月21日発売)

作品紹介・あらすじ

シリコンバレーを舞台に、天才プログラマーのドリームチームが挑んだオープンソース開発プロジェクト「チャンドラー」立ち塞がる難題、時間の壁、去り行く同志-混迷する3年間に密着した長編ノンフィクション。

感想・レビュー・書評

[ふえるわかめさんの感想 · 2020年8月10日]

「Javaスクリプト」という表記は初めて見た。
「パイソン」「ルビー」など違和感のあるカタカナ表記をしているところを見ると、一応非プログラマに向けて書かれているようでもあるが、プログラミングの経験のないとなかなか理解できない内容だと思う。

Chandlerというオープンソースソフトウェアの開発に密着取材。物語は淡々としていて内部的にはそれほど劇的なことも起こらない。しかし、良く知られたソフトウェア開発に関する様々な知見を、Chandlerの開発で起こったことや、その最中に業界で起こった大きな出来事に適用して、ソフトウェア開発一般における問題に置き換えようとしている。そういった知識が得られるところが良い。

Chandlerの開発は終了しているよう。

[sou (08thse)さんの感想 · 2020年5月25日]

チャンドラー開発をもとにした開発現場の本。後半がためになる。

[hayato_1980さんの感想 · 2018年10月7日]

ソフトウェアが完成するという不自然さとの戦い。

[一橋大学附属図書館さんの感想 · 2014年12月19日]

【選書者コメント】テクノロジーの未来について考えるには良い本っぽいなと思いました。
[請求記号]0070:2270

[watarijinさんの感想 · 2013年12月23日]

14

[racdogさんの感想 · 2013年1月21日]

2003年頃の少し古いかもしれない部分はありますが、昔も今と変わらず、部外者の自分にも分かりやすく書かれています
コードに詳しい方ですと、もっと楽しめるかもしれません
副題と原題がしっくりくる内容ですが解決法が書かれているわけではありません

[kotripさんの感想 · 2012年6月8日]

ページ数が多く読むのに気合が必要だった。内容は一般の方に、という出だしではあるが理解は難しいと思う、同じような職種、知識を持っていないと難しい。しかし同じような人種にはなかなか面白かった。

[shi-chanさんの感想 · 2011年12月12日]

プロジェクトって大変だなと感じる本。
ただ、今後生かせる改善点や発見などが出来る良い本かと。

働いてないから多分としか言えない。

[yuki1090さんの感想 · 2011年5月8日]

序盤はおもしろかったけど、
発散してまとまりの無いまま終わった感がする。
ソフトウェアの困難な現場の雰囲気を知るにはいいかもしれないけど、
逆に言えば、そういう系の本を読んでいる人にはありきたりな話の一つかも。

[jo0723さんの感想 · 2011年5月7日]

　2011年12冊目。
　491頁。

　地元の図書館で借りる。



　
　シリコンバレーを舞台に、天才プログラマーのドリームチームが挑んだオープンソース開発プロジェクト「チャンドラー」立ち塞がる難題、時間の壁、去り行く同志―混迷する3年間に密着した長編ノンフィクション。
（Amazon内容紹介）


　本書を本当に理解できるのは、きっと僕がプログラマとしての経験を何年か積んだ後になると思う。しかしそれでも、本書を読んでよかったと思う。システム開発の過酷さやプログラマの抱える葛藤に触れることが出来た。それだけで十分だと思う。




≪本文引用≫

p.19
　米国標準技術研究所の2002年の調査によると、ソフトウェアプロジェクトの三分の二が大幅に納期に遅れるか予算をオーバーするか、あるいは完全に中止せざるをえなくなり、ソフトウェアの欠陥のためにアメリカ経済は年間約595億ドルを負担している。

p.31
　ブルックスは、「人と月を交換可能なものとして扱えるのは、多数の労働者の間でコミュニケーションをとらずに作業を分担できる場合のみである」としている。ソフトウェアのようにプロジェクトごとに性質が異なり、絶えず変化の起きる世界では、チームに要員を加えるたびにベテランが自分の作業を中断して新人の面倒を見なければならず、全員で作業を割り振り直して新人の仕事を作ってやる必要がある。

p.39
　「よいプログラマーは、何を書くべきかわかっている。偉大なプログラマーは、何を書き直すべきか（そして再利用すべきか）わかっている」。

p.79
　世界を変えたければ、イタリアの急進論者、アントニオ・グラムシの有名な言葉のように「知性の悲観主義、意思の楽観主義」が必要である。現代のソフトウェア開発者は、どういうわけかこの二極的な考え方を受け継いでいる。

p.85
　ソフトウェアは抽象的なものであるため、限りなく順応性があるはずだと思われやすい。ところが、ソフトウェアはエーテルのように柔軟でありながら、しぶとく腹立たしいほど扱いにくく、その融通のなさにはいつも驚かされる。

p.167
　「昔からこう言うんだ。早く作るか、安く作るか、うまく作るか。どれか2つだけ選ぶことができる、と」

p.206
　誰も気の毒なユーザーのためにものを言わない。この問題については申し合わせたように押し黙っている。……ちょっと気をつけてみれば、人びとはこの装置は難しくて使えないと言えずにいることがわかる。自分の方が悪いと思っているのだ。……私の知り合いはみな（私も含めて）、少なくとも週に1度は、この腹立たしい機械を窓から放り捨ててやろうかという衝動に駆られる。……。ソフトウェアが使いにくく、プログラムのデザインが貧弱なことは、この業界の隠れた恥部である。……何をすべきなのか。コンピュータの専門家自身が、すばらしいユーザー体験を生みだすことに責任を負うべきである。概念上、最も重要と思われる措置は、コンピュータという工芸品の創造にあたって、プログラミングと対等なものとしてのデザインの重要な役割を認識することである。そして、コンピュータにかかわる職業の最も重要な社会的進化は、ユーザー体験の擁護者としてのソフトウェアデザイナーという役割を作ることであろう。

p.326
　ベストプラクティスの処方箋は、2回目には効き目がない。銀の弾丸は、再充填できない。

p.357
　「柔軟性が過大評価されている。制約が自由を作るのだ」

p.404
　すべての作家が個人の「会社」をもっていて、メルビル会社の人間しか『白鯨』を読めず、ヘミングウェイ会社の人間しか『日はまた昇る』を読めないようなものだ。このような状況で、優れた文学が生まれることが想像できるだろうか。このような条件下では、文学のカリキュラムも組めないし、文章術を教える方法もない。それなのに、これと同じ状況でプログラミングを学ぶことを期待するのか。