Joel on Software

  • オーム社
3.90
  • (73)
  • (52)
  • (88)
  • (3)
  • (0)
本棚登録 : 688
レビュー : 55
  • Amazon.co.jp ・本 (387ページ)
  • / ISBN・EAN: 9784274066306

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • ソフトウェア開発をしていて気が滅入った時に読むと勇気付けられる本。プログラマとしては確かに個室が欲しいな。

  • Joel テストを満点にしよう! と思うのは、ある意味、「いいことは全部極限までやってみよう」という XP と通ずると感じました。

    Joel さんは書いているほど XP を遠ざけていないと思うし、ましてや全否定は絶対してないと感じました。学ぶべき事の多い本でした。

    kdmsnr さん、レビュアーだったのでつね。

  • <目次>
    著者について
    謝辞
    日本語版への序文
    訳者序文
    イントロダクション

    PART01 Bits and Bytes:プログラミングのプラクティス
     第1章 言語の選択
     第2章 基本に帰れ
     第3章 ジョエルテスト:いいプログラムへの12ステップ
     第4章 すべてのソフトウェア開発者が絶対確実に知っていなければならなうUnicodeとキャラクタセットに関する最低限のこと(言い訳なし!)
     第5章 やさしい機能仕様
      パート1:なぜわざわざ書く必要があるのか?
     第6章 やさしい機能仕様
      パート2:仕様書とはどんなものか?
     第7章 やさしい機能仕様
      パート3:だけど……どうやって書くの?
     第8章 やさしい機能仕様
      パート4:ヒント
     第9章 やさしいソフトウェアスケジュール
     第10章 デイリービルドは君の友達
     第11章 手強いバグ修正
     第12章 5つの世界
     第13章 ペーパープロトタイピング
     第14章 アーキテクチャ宇宙飛行士たちに脅かされるな
     第15章 射撃しつつ前進
     第16章 クラフトマンシップ
     第17章 コンピュータサイエンスの3つの誤ったアイデア
     第18章 二文化主義
     第19章 ユーザからクラッシュレポートを自動的に取得する方法

    PART02 開発者のマネジメント
     第20章 採用面接ゲリラガイド
     第21章 報奨金有害論
     第22章 テスタを雇わない(間違った)理由、ベスト5
     第23章 人のタスク切り替えは有害であると考えられる
     第24章 あなたが絶対にすべきでないこと PART1
     第25章 氷山の秘密、明らかに
     第26章 漏れのある抽象化の法則
     第27章 プログラミングにおけるロード・バーマストン問題について
     第28章 測定

    PART03 Being Joel:それほどランダムでもないトピックに関するランダムな考察
     第29章 リック・チャップマンによる愚かさの探求(あるいは「アホでマヌケな米国ハイテク企業」)
     第30章 この国では犬はどんな仕事をしているの?
     第31章 下っ端でも何かを成し遂げる方法
     第32章 2つの話
     第33章 ビッグマック 対 裸のシェフ
     第34章 何ごとも見た目ほど簡単ではない
     第35章 「ここで発明されたものじゃない」症候群を擁護する
     第36章 ストラテジーレターⅠ:Ben & Jerry's 対 Amazon
     第37章 ストラテジーレターⅡ:鶏と卵の問題
     第38章 ストラテジーレターⅢ:もとに戻してくれ!
     第39章 ストラテジーレターⅣ:ブロートウェアと80/20の神話
     第40章 ストラテジーレターⅤ:オープンソースの経済学
     第41章 マーフィーの法則が吹き荒れた1週間
     第42章 MicrosoftはいかにしてAPI戦争に負けたか

    PART04 .NETについての少し行き過ぎた論評
     第43章 Microsoft、羽目をはずす
     第44章 私たちの.NET戦略について
     第45章 申し訳ありませんが、リンカをいただけないでしょうか?

    PART05 付録
     付録 「ジョエルに聞け」選集
     索引

    ***

    ソフトウェアプロジェクトを上手くマネジメントするテクニックが存在する。
    最先端では、釘とタップシューズよりずっと進歩しているのだ。私たちには金槌とドライバと、スライド式の電動丸ノコがある。この本のゴールは、私が考え付く限りたくさんのテクニックを、スケジュールを見積もっているチームリーダからソフトウェア会社の競争戦略を練っているCEOまで、あらゆるレベルで紹介することだ。
    (本書折り返しより。※原文は本書「イントロダクション」)

    ***

  • 納得できるプラクティス満載。特にマーケティングや、利益に言及しているあたりは、さずがにCEOである。ソフトウエアをベーススキルとするマネージャーには必読だと思う。ただし、XPに対する誤解(XPが必要ないといっている仕様とは、詳細(動作)仕様であり、Joelが必要であるといっている仕様は要求仕様である)はいただけない。要求仕様の無いソフトとはただのくずであり(仕様書があるかどうかは別のトッピック)、ベックがこのような誤りをしているわけ無いのだが。

  • 当然面白い。

  • 最初Web上で公開されていた日本語訳のエピソードを読んだことがきっかけで、書籍を購入しました。
    読み物として面白いです。特に以下のエピソードは面白いと感じました。
    ・ジョエルテスト
    ・Unicodeとキャラセットに関する話
    ・射撃しつつ前進
    ・人のタスク切り替えは有害であると考えられる
    ・漏れのある抽象化の法則
    ・ビックマック 対 裸のシェフ

  • 【開発者マネジメント論+IT業界での戦略論】
    開発者のマネジメントの方法を学べると思って購入したのだが、蓋をあけてみれば、おまけとしてIT業界での戦略論がくっついていた(双方に関係性はまるで無いので、たぶん興奮して書いちゃったのかな?)。

    『ジョエル・テスト』と呼ばれる12の質問に答えることで、自社の開発体制がどれだけ適正になっているかを判断できる。12の質問の詳細は、各章で説明されているため、具体的にどういうことを言っているのか理解できる。

    スタートアップでは当然となった『MVP』の話などがこの本で登場している。きっと当時のIT業界では当然だったのだろうが、まだ2000年当時(本書が執筆された年)はITでのスタートアップが多くなかったことから、あまり知られていなかったのだろう。

    翻訳の質はあまり高くないけど、楽しく読める一冊。

  • 一章が神。なぜ、誰も読まない機能仕様書ができるのか。それは退屈でつまらないからだ。それなら、シナリオを必要以上に具体的に書けば面白くなるし、仮想のユーザーが見えるようになる。よく見る仕様書は正確さを追求しすぎて、そもそものところが分かりにくい仕様書になっているのではないか。

  • 筋が通っていて面白い。ソフトウェアに関する文字コード、採用、戦略など著者の経験から幅広く書かれていて面白い。気づきをあたえてくれる。

    ささっと読めるが、すすすっと抜けてしまう。

  • 仕様書のあり方やスケジュールマネジメント、評価など、多くのソフトウェアにまつわる示唆に富んだ内容だった。
    この一つ一つのエピソードを覚えることは困難だが、知恵として役立つことは間違いないな、と思う。

全55件中 1 - 10件を表示

Joel Spolskyの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
ブライアンカーニ...
高橋 登史朗
デールカーネギ...
益子 貴寛
トム デマルコ
ジェームズ・スロ...
ジェラルド・ジェ...
有効な右矢印 無効な右矢印

Joel on Softwareを本棚に登録しているひと

ツイートする
×