青木靖のレビュー一覧

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

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

kdmsnr さん、レビュアー...続きを読むだったのでつね。

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

全ソフトウェアエンジニア、開発リーダー必読！！
すばらしいの一言。 買ってソッコーで読み終わったけどただ今２回目読み直してます。
開発者なら絶対読むべし。

ユーモアにあふれた文章センスで、読んでいても退屈にならない内容。
その上、ソフトウェア開発プロセスにおける、ジョエルの経験談や考察から導き出されたベストプラクティスやテクニックが紹介されており、実践でも十分適用できる内容になっている。

中でも、自分が一番参考にしようと思ったのは、技術者の採用面接に...続きを読む関する話題。プロジェクトの要員面談や、自社の採用面談で実践してみようと思う（ちなみに自分に決定権はないけどね）。

そのほか、機能要件書の書き方なんかは、読んでもらう・読みやすくする実践的なテクニックが示されており、今まで自分が書いてきた機能要件書の退屈さ加減を思い知らされた。

まだ読んだことのない人には、ぜひ一読して欲しい本。絶対おすすめ！
開発経験者にとってはニヤリとしてしまう内容が多いし、まだまだ経験の浅い若手にとってはよい参考書になると思う。
なにより、ジョエルの文章センスにハマること間違いなし。

みんな大好き、joelの辛口ぼやき集です。

批判的なコトバって、いつでも楽しいものです。
さらに切り口がちょっと目新しかったりすると、それだけで賢そうにも思えちゃって、自分も賢くなれそうな気までしてきちゃう。

そういう煽動的なコトバであっても、自分自身がじゅうぶん批判的であれば、イイカンジに有用...続きを読むな知識や知恵をすくいとれるんじゃないか...なんて思ったりしちゃいますよね。

はたして、ぼくはこの本から、シニカルさ以上のなにかを得ることができたのでしょうか？
はてさて。

ま、面白いからいいんですけど。

ソフトウェア開発をしていて気が滅入った時に読むと勇気付けられる本。プログラマとしては確かに個室が欲しいな。

プログラム、もしくはそれに近い事をやった事がある人にとっては
何度読んでも楽しめる本。
単に読み物として、また「Joel Test」解説書として
はたまた開発としての参考書としても読めるいい本です。

面白くて、ためになる。
繰り返し読んで実践していきたい。
この手の風刺が効いた本って本当に楽しい。こんな文章が書けるのはとても素敵だと思う。内容について一切触れていないのはまぁ、読んでみて、ということで。

元MicrosoftのExcel開発を行っていた著者のブログを書籍にまとめたのが本書です。ソフトウェアについて、プログラムの書き方から組織のあり方についてまで幅広く扱われています。エンジニアとはかくあるべきと思える良書でした。

なんて言うか、書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。
たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読書かれている事にすごく共感が出来、そういう本は読んでいて...続きを読む楽しい。
たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読んでいてすごく共感できる。
まぁ日経ソフトウェアだとか、ソフトウェアピープルだとか、＠ITとかばっか読んで、いったい僕は(私は)どんなふうにこれからソフトウェアを作っていけばいいのよって思っている、方法論中毒患者(かわいそうに)の方は読むと多少すっきりするかも。

後、良くわかったの僕はXPが嫌い。（W

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

‪なぜソフトウェア開発は往々にしてスケジュールが遅延し、思い描いていたのと違う製品が出来上がり、そして少なからず失敗に終わるのか？その原因を非技術系の人向けに解説した一冊。翻訳の癖は少々あるものの全章が必読。逆にエンジニアである自分は「ここに壁があったのか！」という視点を得られた。‬

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

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

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

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

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

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

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

ソフトウェア開発に関する面白読み物。それでいてすごくためになる。ジョエルの言う「5つの世界」のうち、パッケージについての話が主だけど、それ以外の世界にも参考になることが多い。
以下、特に参考になりそうなところ。

・3章 ジョエルテスト
ソフトウェア開発環境の善し悪しをチェックする12のテスト項目。...続きを読む
ソフトウェア開発に限らず応用できるところも多い。
もし自分が、テスト項目がほとんど満たされない環境にいて、自分が環境を変えられない立場にいるのであれば、「31章 下っ端でも何かを成し遂げる方法」を読むといい。

・4〜8章 やさしい機能仕様
まあ、機能仕様と技術仕様を分けてるような現場は経験したことがないわけですが。ここで紹介されてる書き方なら、書く方も読む方も楽そう。テンプレートの項目をびっちり埋めて各機能ごとに膨大な量の文章がありながら、読んだところで何を作りたいのかさっぱりわからない仕様書を撲滅したい。

・9章 やさしいソフトウェアスケジュール
「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」は至言。自分の作業時間を見積もるのが苦手な僕ですが、その精度を上げていくための管理方法も書いてある。これは実践したい。

ソフト開発における方法論などが書かれています。
著者は元マイクロソフトでエクセルの開発をおこなっていた人らしく、
書き綴ったブログが本になっている。

プロジェクトにまつわるいろいろなTips。現実的ではないものも多い（仕様書を面白く書け、とか。理由は面白くないと読まないから）かとおもえば、タスク管理はプレーンテキストがいいだとか、いろいろ考えさせられるものもある。大規模開発ではまた別の手法が必要かもしれないが、小規模であればこれを読めば十分だ。チ...続きを読むーム単位で作業をしてるときにもいいだろう。

筆者のセンスについていけなくて微妙に読みづらい感はありますが、それさえ除けばいい本。大企業で働いていただけあって、理想と現実の落としどころのバランスがうまいのは、参考にしたい。

文字数が多すぎるのか、後半になるに従って読むのが大変になっていった。「アジャイルをいつ使うべきではないか」という章はちょっと興味深かった。「プログラマの場合、職を変えることが汚点とならない」というのは、まだ日本では、そういう時代になっていないかもと思った。