あらすじ
※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。
※この電子書籍は紙版書籍のページデザインで制作した固定レイアウトです。
ソフトウェア開発にかかわるすべての人に贈る、世界的な人気を誇るWebサイト発の厳選コラム
かつてExcel VBAの開発を率い、現在ではソフトウェア会社を経営するJoel Spolsky氏は、自身のWebサイト"Joel on Software"にてソフトウェア開発やマネジメントに関する記事を発表し続けてきた。深い洞察力で物事の核心に迫り、それを軽妙な語り口で端的に表現するJoel氏の記事は、世界各国でも有志により翻訳が公開され、すでに日本でも多数の読者を得ている。原書は、それらの記事をJoel氏自身が編纂してまとめたもの。
はじめに
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. ユーザからクラッシュレポートを自動的に取得する方法
20. 採用面接ゲリラガイド
21. 報奨金有害論
22. テスタを雇わない（間違った）理由、ベスト5
23. 人のタスク切り替えは有害であると考えられる
24. あなたが絶対すべきでないこと PART I
25. 氷山の秘密、明らかに
26. 漏れのある抽象化の法則
27. プログラミングにおけるロード・パーマストン問題について
28. 測定
29. リック・チャップマンの愚かさの探求（あるいは「アホでマヌケな米国ハイテク企業」）
30. この国では犬はどんな仕事をしているの？
31. 下っ端でも何かを成し遂げる方法
32. 2つの話
33. ビッグマック 対 裸のシェフ
34. 何ごとも見た目ほど簡単ではない
35. 「ここで発明されたものじゃない」症候群を擁護する
36. ストラテジー･レターⅠ：Ben & Jerry's 対 Amazon
37. ストラテジーレターII：鶏と卵の問題
38. ストラテジーレターIII: もとに戻してくれ！
39. ストラテジーレターIV：ブロートウェアと80/20の神話
40. ストラテジーレターV：オープンソースの経済学
41. マーフィーの法則が吹き荒れた一週間
42. MicrosoftはいかにしてAPI戦争に負けたか
43. Microsoft、羽目をはずす
44. 私たちの.NET戦略について
45. 申し訳ありませんが、リンカをいただけないでしょうか？
付録：「ジョエルに聞け」選集
感情タグBEST3
Posted by ブクログ
Joel テストを満点にしよう！ と思うのは、ある意味、「いいことは全部極限までやってみよう」という XP と通ずると感じました。
Joel さんは書いているほど XP を遠ざけていないと思うし、ましてや全否定は絶対してないと感じました。学ぶべき事の多い本でした。
kdmsnr さん、レビュアーだったのでつね。
Posted by ブクログ
一章が神。なぜ、誰も読まない機能仕様書ができるのか。それは退屈でつまらないからだ。それなら、シナリオを必要以上に具体的に書けば面白くなるし、仮想のユーザーが見えるようになる。よく見る仕様書は正確さを追求しすぎて、そもそものところが分かりにくい仕様書になっているのではないか。
Posted by ブクログ
全ソフトウェアエンジニア、開発リーダー必読！！
すばらしいの一言。 買ってソッコーで読み終わったけどただ今２回目読み直してます。
開発者なら絶対読むべし。
Posted by ブクログ
ユーモアにあふれた文章センスで、読んでいても退屈にならない内容。
その上、ソフトウェア開発プロセスにおける、ジョエルの経験談や考察から導き出されたベストプラクティスやテクニックが紹介されており、実践でも十分適用できる内容になっている。
中でも、自分が一番参考にしようと思ったのは、技術者の採用面接に関する話題。プロジェクトの要員面談や、自社の採用面談で実践してみようと思う（ちなみに自分に決定権はないけどね）。
そのほか、機能要件書の書き方なんかは、読んでもらう・読みやすくする実践的なテクニックが示されており、今まで自分が書いてきた機能要件書の退屈さ加減を思い知らされた。
まだ読んだことのない人には、ぜひ一読して欲しい本。絶対おすすめ！
開発経験者にとってはニヤリとしてしまう内容が多いし、まだまだ経験の浅い若手にとってはよい参考書になると思う。
なにより、ジョエルの文章センスにハマること間違いなし。
Posted by ブクログ
みんな大好き、joelの辛口ぼやき集です。
批判的なコトバって、いつでも楽しいものです。
さらに切り口がちょっと目新しかったりすると、それだけで賢そうにも思えちゃって、自分も賢くなれそうな気までしてきちゃう。
そういう煽動的なコトバであっても、自分自身がじゅうぶん批判的であれば、イイカンジに有用な知識や知恵をすくいとれるんじゃないか...なんて思ったりしちゃいますよね。
はたして、ぼくはこの本から、シニカルさ以上のなにかを得ることができたのでしょうか？
はてさて。
ま、面白いからいいんですけど。
Posted by ブクログ
プログラム、もしくはそれに近い事をやった事がある人にとっては
何度読んでも楽しめる本。
単に読み物として、また「Joel Test」解説書として
はたまた開発としての参考書としても読めるいい本です。
Posted by ブクログ
面白くて、ためになる。
繰り返し読んで実践していきたい。
この手の風刺が効いた本って本当に楽しい。こんな文章が書けるのはとても素敵だと思う。内容について一切触れていないのはまぁ、読んでみて、ということで。
Posted by ブクログ
元MicrosoftのExcel開発を行っていた著者のブログを書籍にまとめたのが本書です。ソフトウェアについて、プログラムの書き方から組織のあり方についてまで幅広く扱われています。エンジニアとはかくあるべきと思える良書でした。
Posted by ブクログ
なんて言うか、書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。
たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。
たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読んでいてすごく共感できる。
まぁ日経ソフトウェアだとか、ソフトウェアピープルだとか、＠ITとかばっか読んで、いったい僕は(私は)どんなふうにこれからソフトウェアを作っていけばいいのよって思っている、方法論中毒患者(かわいそうに)の方は読むと多少すっきりするかも。
後、良くわかったの僕はXPが嫌い。（W
Posted by ブクログ
納得できるプラクティス満載。特にマーケティングや、利益に言及しているあたりは、さずがにCEOである。ソフトウエアをベーススキルとするマネージャーには必読だと思う。ただし、XPに対する誤解（XPが必要ないといっている仕様とは、詳細（動作）仕様であり、Joelが必要であるといっている仕様は要求仕様である）はいただけない。要求仕様の無いソフトとはただのくずであり（仕様書があるかどうかは別のトッピック）、ベックがこのような誤りをしているわけ無いのだが。
Posted by ブクログ
【開発者マネジメント論＋IT業界での戦略論】
開発者のマネジメントの方法を学べると思って購入したのだが、蓋をあけてみれば、おまけとしてIT業界での戦略論がくっついていた（双方に関係性はまるで無いので、たぶん興奮して書いちゃったのかな？）。
『ジョエル・テスト』と呼ばれる12の質問に答えることで、自社の開発体制がどれだけ適正になっているかを判断できる。12の質問の詳細は、各章で説明されているため、具体的にどういうことを言っているのか理解できる。
スタートアップでは当然となった『MVP』の話などがこの本で登場している。きっと当時のIT業界では当然だったのだろうが、まだ2000年当時（本書が執筆された年）はITでのスタートアップが多くなかったことから、あまり知られていなかったのだろう。
翻訳の質はあまり高くないけど、楽しく読める一冊。
Posted by ブクログ
筋が通っていて面白い。ソフトウェアに関する文字コード、採用、戦略など著者の経験から幅広く書かれていて面白い。気づきをあたえてくれる。
ささっと読めるが、すすすっと抜けてしまう。
Posted by ブクログ
仕様書のあり方やスケジュールマネジメント、評価など、多くのソフトウェアにまつわる示唆に富んだ内容だった。
この一つ一つのエピソードを覚えることは困難だが、知恵として役立つことは間違いないな、と思う。
Posted by ブクログ
ソフトウェア開発に関する面白読み物。それでいてすごくためになる。ジョエルの言う「5つの世界」のうち、パッケージについての話が主だけど、それ以外の世界にも参考になることが多い。
以下、特に参考になりそうなところ。
・3章 ジョエルテスト
ソフトウェア開発環境の善し悪しをチェックする12のテスト項目。
ソフトウェア開発に限らず応用できるところも多い。
もし自分が、テスト項目がほとんど満たされない環境にいて、自分が環境を変えられない立場にいるのであれば、「31章 下っ端でも何かを成し遂げる方法」を読むといい。
・4〜8章 やさしい機能仕様
まあ、機能仕様と技術仕様を分けてるような現場は経験したことがないわけですが。ここで紹介されてる書き方なら、書く方も読む方も楽そう。テンプレートの項目をびっちり埋めて各機能ごとに膨大な量の文章がありながら、読んだところで何を作りたいのかさっぱりわからない仕様書を撲滅したい。
・9章 やさしいソフトウェアスケジュール
「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」は至言。自分の作業時間を見積もるのが苦手な僕ですが、その精度を上げていくための管理方法も書いてある。これは実践したい。
Posted by ブクログ
ソフト開発における方法論などが書かれています。
著者は元マイクロソフトでエクセルの開発をおこなっていた人らしく、
書き綴ったブログが本になっている。
Posted by ブクログ
プロジェクトにまつわるいろいろなTips。現実的ではないものも多い（仕様書を面白く書け、とか。理由は面白くないと読まないから）かとおもえば、タスク管理はプレーンテキストがいいだとか、いろいろ考えさせられるものもある。大規模開発ではまた別の手法が必要かもしれないが、小規模であればこれを読めば十分だ。チーム単位で作業をしてるときにもいいだろう。
Posted by ブクログ
筆者のセンスについていけなくて微妙に読みづらい感はありますが、それさえ除けばいい本。大企業で働いていただけあって、理想と現実の落としどころのバランスがうまいのは、参考にしたい。
Posted by ブクログ
2005年と少し古い本だが、主にマネジメントの話なので、今でも通じる内容も含まれている。
とにかく文章が面白いので、あまり難しく考えずに読めるのが良い。
ジョエルテストという簡潔なプロジェクトが守るべき10の項目があるが、今でも確かに必要だと頷かされるものになっている。
Posted by ブクログ
ジョエルテストで有名なジョエルが書いた本。
こういうプロジェクトは失敗するよねーとか、
こういう状況よくあるけど、実はこうしたほうがいいんだよね、
とか「あるある」と思うようなことが結構書いてあったりする。
