「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」 とその関連商品

主にソフトウェア開発者に向けたプロジェクト管理のための１冊です。内容は多岐に渡り、一回で読んで全てを理解するのはなかなか難しいと思います。そこでお薦めなのは、自分の現在の状態、仕様検討段階であるのか、コーディング段階であるのか、リリース前であるのか、その段階に応じてその部分について書かれた箇所を読む方法です。前に読めば予備知識になり、後で読めば振り返りになると思います。また、著名な書物からの引用も効果的でなかなか楽しいものでした。
マイクロソフトで、とありますがマイクロソフトに特化したところはなく、一般的な手法として参考になります。 (limegreens/2006-11-07)

文字も小さく400ページ以上もあり簡単には読めるものではないが、プロジェクトマネージャを目指すあるいはその職にある者にとって最良の1冊となるのは疑いない。
現場のプロジェクトマネージャが必ず悩み懸念する事が章建てとして構成されており、他のPM本とは一線を画す。
美辞麗句な言葉はなく、全て著者の実体験に基づいた金言が散らばっている。

この書籍のおかげで、これからも随分と助かる気がする。 (blue/2008-11-16)

ITコンサル・プロマネ（職歴18年）視点でのコメントです。

システム開発やプロジェクト管理に関連した書物は、これまで数百冊を読んできました。

その中で三本の指に入る素晴らしい本です。絶品です。感謝です。

特に内容にはコメントしません。

私がこの本に支払ってもよいと考える金額は・・・

８０００円

しかし絶版だったら・・・金額はつけられませんが、何が何でも手に入れたい本です。 (pluto/2008-11-17)

タイトルのプロジェクトマネジメントと聞くだけで嫌なものだと誤解して、食わず嫌いだった。しかし、アートオブとついているので、管理が技術だという視点からすれば、ちゃんと読めば良かったと後悔している。
第１０章は、特によい。人の仕事の邪魔をしないで、人の助けをするのが管理の基本である。しかし、多くの管理者、管理本は、人の仕事の邪魔をするようなことを平気でやったり書いたりしている。基本を外した本が多いなか、本書は要点を得ているので読む気になる。

飜訳が日本の文化への移転を十分していないのは、外資系の企業だけでなく、日本の企業でもソフト系の企業はカタカナ語が氾濫しているので仕方がないかもしれない。 (kaizen/2008-02-16)

プロジェクトマネジメントに興味があり本書を手に取りました。
なにか合理的な内容を求めるときは、いつも外国の書籍を読みます。
英語がもつ構造的な論理性に惹かれるのかもしれません。

実用性重視で書かれた多くのプロマネ本に対して、本書は
経験ゼロの人でも理解しやすい内容になっています。
それは数多くの実例と、著者のユーモアに依るところが大きいでしょう
私の本業はITから遠いので、実践的なソフトウェア、Web開発の章は
とばし読みしました。
それでもなお、目の覚めるような内容が含まれています。

１０章「メンバーの邪魔をしない方法」では、チーム内のコミュニケーションに
おける不快さの削減方法が記されています。メールや電話、あるいは立ち話
について、すぐにでも取り入れられることが多いです。
あるいは、１６章「社内の力関係と政治」は、組織に所属する
全ての人がぶつかる問題でしょう。
本章には「政治とは汚いことを表す言葉ではない」とあります。
政治が問題解決の１ツールであるという考え方は、風通しが良いです。

ソフトウェアおよびWeb開発に関する知識が乏しいため、私は本書の
価値を理解できていません。そのための星３つです。
もし知識があれば星５つではないかと思います。
(trafk/2007-03-25)

プロジェクト管理の各フェーズで役に立つTipsを集めた一冊という感じです。
内容的には、なるほど、と思わせられるものが多いのですが、
訳がこなれていない上に、翻訳もの特有の笑えないジョークが鼻につくのが、
ちょっと残念、星一つマイナスです。 (palemoon/2007-04-22)

疑問を投げかけ前提に挑む。
そんなプロマネの存在理由が明らかに。

機能的な書籍というよりは、如才無いプロマネの心構え。

著者のScott Berkun （スコット・バークン）さんは、
マイクロソフトで、OfficeやVisual Basic、IE等の
プロジェクトに関わってきたようだ。

プロマネの経験がある人なら、それらのプロジェクトが
どれほど壮大か想像できるだろう。
その場で、吐き気をもよおす人もいるかもしれない。

プロセスに取り憑かれ、方法論への執着が
間違った方向へ行っている場合、力が大きいほど、修正はきき難い。

チームメイトに心配を抱かせないためにも、
プロジェクトマネージャーだけではなく、チーム全員が読んでいただきたい。

スケジュールが狂うのは何故か？

「スケジュールが遅延するということは、
誰も把握していないコストが隠されていた、
あるいは無視されていたということを意味しているわけです。」

以下の2つ、笑えるけど、自分がやっているとしたら、
まったく笑えない。　その詳細も解説

* 「よく見かける悪い手段」
* 「質の低いビジョンのドキュメントに見られる特徴」

大胆さ、図太さがプロジェクトを邁進させる。
あなたへの命令が大切なコトか試す方法

「私は、自分が理解できない、遠回しで曖昧かつ官僚的で組織的な
プロセスは無視するようにしています。」

無視した事案が大事な場合、偉い人がスッ飛んでくるハズ。
重要でない場合は、当然、誰も来ない･･･

現場を守る、プロマネの領域

「誰かが優先順位を無視した指示をしてきたと思った時には、
『ノー』と言ってください。

あるいはその指示をした人に対して、私が『ノー』と言っていたと伝えれば、
その人は私のところに来るはずです。

もし彼らが文句を言ったとしても、
議論して時間を無駄にしないようにしてください。

とにかく私のところに来るように、その人に伝えてください。」

"計画すること"が目的ではない。

「計画に従うことで勝利できるような戦いはないが、
計画なくして勝利できるような戦いもない。」

ドワイト・E・アイゼンハワー（ドワイト・D・アイゼンハワーのこと？）

それでは、何故計画をするのか？

「戦闘というものは計画通りに行えるものではない。
計画は変化に備えた共通の基盤でしかないのだ。

重要なことは、全員が計画を知っておくことで、
容易に変更が可能になるということなのだ。

近代戦は非常に流動的であり、
意思決定は迅速に行わなければならない。

そしてそのほとんどは計画に従ったものとはならないのだ。

しかし全員が少なくとも、自分はどこから来て、
（その後）どこに向かっていくのかということを知っているのだ。」

イスラエル防衛軍司令官 ダン・ラネル陸将補


つい、行うタイミングを逃しがちな、プロジェクトの検死報告（反省会）

打ち上げの偉大性、組織を構成するメンバー、個別の利害にも目を光らせる

皆さんが気になるのは、16章の「社内の力関係と政治」ではないだろうか？

* 「政治的な理由で･･･」
* 「大人の事情で･･･」

と言った言葉は、逃げの言葉だ。
語る者同士の思考を停止させてしまう魔力がある。 (ウェブ担当/2009-06-12)

会社で新しいことをやろうとすると、いろいろな障害に遭遇します。
この本に書かれている、イノベーションに関する10の神話(思いこみ)達もその障害のひとつです。

この本を読んで、神話に惑わされない人が増えてくれると新しいこともやりやすくなりそうです。
なので、是非たくさんの人に読んでほしいと思いました。

内容は濃く、重要なところに線を引こうと思うと本が線だらけになりそうでした。
冒頭にはそうそうたるメンバーの謝辞が並んでおり、海外でのこの本の評価が高そうなことを感じました。

アートオブプロジェクトマネジメントも良かったですが、この本も良いです。
すごい人が現れたものだと感じました。 (nekot/2007-12-21)

「イノベーションとは一人の天才がひらめきに基づき作り出した物で、時代を一気に変えた物だ」というイノベーションに対する誤解（神話）を解いていく本です。

（１）一人の天才が
→あくまでそれまでの技術の積み重ねがあってこそ

（２）ひらめきに基づき
→正確な問題設定に基づいて考え続けた結果、最後の一瞬にひらめきが来ただけ。

（３）一気に時代を変えた
→あくまで時代に受け入れられたからこそ商業化を経てイノベーションとして成立した。

言われてみれば当たり前のことなのですが、多くの事例を用いて具体的な検証をしているので説得力が有ります。



また、著者はイノベーションの「神話」が世の中に流布される原因がメディア・歴史家が単純化した情報を伝えざるをえないこと、読者がシンプルでドラマティックなストーリを好む事、といった社会的要因を上げています。


最後に内容とは別に、著者のユーモアに富んだ語り口は読んでいて非常に面白かったです。 (リョウタ/2008-10-26)

歴史に残る発見, 発明(イノベーション)にまつわる神話を斬っていく本です.
論議の明確さに感動しました! (読んだだけで頭が良くなったような気がします).

科学上の進歩, 発明(ベルの電話とか)が, いかに神格化されがちなのか (ある意味宗教ですね)
実際の証拠から, 神話の間違いを暴いていきます.

実際のところ, イノベーションの際に起きているのは地道な努力で.
それを神話化することは, 害にしかならない, ことがよくわかりました.
(いわゆるカーゴカルトになってしまう, というわけです).

プロジェクト Xがもてはやされている割りに,
同じような成功例が起こらない理由が分かる, すごい本です.
(儲かったNHKは, 成功してますが)

すべての技術者におすすめです! (magazhine/2008-09-16)

内容ですが、技術者なら普段からあたりまえに感じてるようなことがベースになっています。つまり、日々の地味ぃぃぃな研究こそがイノベーションの真の姿であり、間違ってもニュートンのように「リンゴにぶつかったら閃いた」なんてもんでは無いと。

ですが読む価値が無いかというと、決してそういうことはなく、むしろ色々な方に読んでいただきたい。

まず、上記以外にも論旨は多岐に渡り、その一つ一つに詳細な論証が加えられています。これは、一部の人が感じていることを多くの人で共有できることを意味しています。
さらに、読み物として非常におもしろく、全編を通してユーモアにあふれています。前著の「アート オブ プロジェクトマネジメント」が若干退屈になりがちだったのに比べ、この点で格段に進歩があるようです。

また、日々イノベーションと格闘している方は、「ほとんどの試みは失敗する」という内容のことがはっきり記されているにも関わらず、「少なくとも自分の道はまるっきり見当違いってわけではないんだ」と勇気づけられる内容でもあると思います。

日々つらい思いで働いている中間管理職の方などは若干不快になるような内容ではありますが、それ以外の多くの方にお勧めです。
(vanilla/2008-05-25)

イノベーションに関するビジネス書の大半が浅薄なものであることを痛感させられる本です。

とかく宣伝されがちなイノベーションの光の部分（神話）に隠れた影の部分について、
人の本性、文化、社会、経済、政治等の様々な観点からイノベーションが如何に困難な諸行であるかを提示しています。
更に、著者の思い付きやアイデアではなく、イノベーション研究に関する過去の優れた知見を数多く紐解きながら、
これらを上手く整理しているため、イノベーションに関わる多くの人に対して有益な示唆を与えてくれます。

また、参考文献の提示方法も、よくある羅列ではなく、
文献そのものの解説や、文献の引用回数を提示するなど、著者が本書で何を重視しているかが推察できるものとなっています。
なお、引用回数第３位（１位はドラッカーの「イノベーションと起業家精神」）である、
Everett M.Rogers Diffusion of Innovationsは本書と同時期に邦訳版が出版されています（「イノベーションの普及」）。
(seed&inspire/2008-02-10)

数学的な背景を持った見積もり技法を「サイエンスとしての見積もり」、経験則と単純な公式による見積もりを「アートとしての見積もり」とマコネルは区分けしている。本書では両方を取り扱うが、より「アートとしての見積もり」に重点を置くとしている。
プロジェクトのサイズを大中小と分けるなら、中小プロジェクトが圧倒的に多数を占めるものと思う。こうしたプロジェクトでも当然見積もりは必要とされるが、「サイエンスとしての見積もり」を行うのは少々スペックオーバーに思える。ほとんどの現場では経験則や貧弱な根拠による見積もりが行われ、プロジェクトに混乱をきたしているのではないだろうか。
第1部では、良い見積もりとはなにかの考察が行われる。マコネルは、見積もりとターゲットとコミットメントが異なるものであることを最初に示し、様々なデータを元に見積もりに対する考察を行う。その中で良い見積もりと適切なプロジェクトコントロールは不可分のものであるというメッセージが度々語られている。
第2部では、プロジェクトの規模や種類、ステージに応じた具体的な手法がまとめられている。
第3部では規模、工数、スケジュールなどのそれぞれの見積もりごとの手法と課題がまとめられている。

本文はわずか300ページ足らずなのだが詳細な見積もり技法の本を何冊も読むよりも。現場に立つ開発マネージャーにとって（ただし、中小規模のプロジェクトの）、この本を読み込んだ方が役に立つ実践的な知識と考察が得られるように思う。
(赤戌/2006-11-16)

常に提示される見積もりに疑問をもっていたので、じっくり本書を読んだ。
最初に提示される見積もりとコミットメントの違いの説明で、その疑問の半分は解消される思いがした。通常提示されていたものは見積もりそのものではなく、コミットメントではないかと。　この調子でアートとしての見積もりに関する知見にふれていくことで、見積もりの在り方の理解が進んでいく。
ただしここで提示される見積もりはそれなりにしっかりとしたバックデータに裏付けられた見積もりであり、通常の日本のベンダーではこの様な定量的な分析ができる体制になっているのか疑問であり、残念な気持ちにもなる。
その様な現実的な側面はあるものの、中小規模の開発案件を企画管理する立場の人には見積もりの在り方を考える上で必読の書であると思います。 (tabopapa/2008-03-09)

アジャイルなやり方に興味がある人、すべてに、おすすめの一冊です。

アジャイル開発を実践する３１の方法を
・考えること
・協力すること
・リリースすること
・計画すること
・開発すること
の５つのカテゴリ別に説明しています。

「何人くらいだと、こう」「長くても１５分」「こう言われたら」など、具体的な説明が豊富なので、とても参考になります。

アジャイルやＸＰというと、プログラミングが強調されがちです。この本は「リリース」や「計画」も具体的に説明している点がすばらしい。

どの方法も「陥りやすい点の注意」と「実施に障害がある場合の代替案」が示されています。実際に、現場で起きがちな状況への良いアドバイスですね。

読んでみて印象に残ったのは、
・とにかくコミュニケーションすること
・みんなで同じ言葉を使うこと（ ユビキタス言語　）
の２点です。
アジャイルのやり方とは、この２点に集約されるのかな、というのが私の個人的な感想です。 (masuda220/2009-03-08)

本書を最初に手に取ったときの感想は「XPもずいぶんデカくなったもんだな!」。自分の中のXPのイメージと言えば、シンプルな12のプラクティスだけをMAXにして、登場人物はプログラマとオンサイト顧客のみという軽量の極みだ。初期のXPが持っていた刺激的な謳い文句に誘われて、試しに導入してみた人は少なくなかったと思うけど、おそらくほとんどは失敗しただろう。

そうして失敗した事例の噂を見聞きして、「やっぱアジャイルだめじゃん」と結論付けた人も多かったと思う。隠れた本質について知ることなく失敗のレッテルを貼ってしまった人たちが。本書には、その誤解を解くだけの情報がたっぷりつまっている。

なにより、プラクティスが増えて、登場人物も専門職を含めてバリエーションを増している。実際の現場で、たった12のプラクティスと2種類の登場人物だけでコトが進むわけがないので、すごく現実に歩み寄ったという印象。導入初期にはとても生産性が落ちることをちゃんと白状し、困ったときに相談できるメンターを用意するようにというアドバイスもある。奇麗ごとばかりを並べていないのはいいことだ。

さらに、「計画」についてかなりの紙数を割いている。XPといえばペアプログラミングやTDDばかりが取りざたされがちで、目にする機会も多い。しかし本当にXPをやってる人たちによれば「XPの醍醐味は計画ゲームにある」らしいのだ。にも関わらず計画ゲームは今まで、ちょっと魔術っぽい部分があった。それが本書ではかなり明瞭になっていて、なるほどこれなら……と思える。

具体的な事例や練習方法、想定問答が各節に用意されていて、フォーマットがよくでいている。通して読まなくても、いま直面している問題への解決策が見えてくるだろう。ただ、終盤の展開が少し駆け足なのは、まだ深く探求されていない部分なのかも知れず、今後に期待。

あと、とても読みやすい現代日本語になっているのがすばらしい。翻訳者・監訳者に拍手。 (ただただし/2009-04-20)

「はじめに」にもあるとおり, 本書はアジャイル導入のよい練習曲集です. いろいろな方法がある中で, XP を中心に破綻のない, 洗練された練習曲が集められています. しかもそれぞれに先生の丁寧な書き込み付き! 中には自分にとって退屈な曲も, 苦手な曲もあるでしょうから, 練習が進めば取捨選択すればいいでしょう. 先のステップに進んでも, お気に入りの曲はときどき弾いてみたくなるかもしれません.
ケント・ベックの最初の本から10年, 量的にも3‾4倍ありますが, もはや「エクストリーム」ではなく, ソフィスティケイトされたプロセスとなったことを, 本書は示しているように思います. (花とアリス/2009-02-28)

今まで購入したXP、アジャイル本で最も具体的でした。
実践している、実践を検討している、
どちらの立場にも問題解決のヒントがいっぱいあると感じています。
また、比較的拾い読み可能なので、読み易いとも思います。
(tommy/2009-06-14)

タイトルには「エンジニア」とあるが、実際にはいわゆる「システム管理者（しかも専属）」の業務を対象に書かれている。と聞くとタイトルに惹かれたエンジニアの方は「役に立たないのでは？」と思われるかもしれないが、ある程度経験を積み「腕っこき」と頼りにされ始め、「掛け持ち業務」が常となりつつあるような「普通のエンジニア」を脱皮し始めた人に取っては役に立つ内容が結構あると思う。

一通り読んで振り返ってみれば書かれている内容は有能なシステム管理者に従事していれば自然と身に付くであろうモノが多いのであるが、そういった「師匠」となる上司や先輩に出会えず、悶々とただ忙殺されてしまっている人にとっては是非本書を読んでもらいたいと思う。 (コモヒコ/2007-01-28)

「エンジニア」となっていますが、機械系と言うよりはSEやSAの方向けの本です。
私は社内の情報システム部門に在籍していますが、本書は具体例も多く、非常にためになりました。
紹介している方法も、決して奇をてらったものでなく、
「デジタルツールの駆使」
というより
「アナログツールも活用した時間管理と仕事の進め方」
と言った内容が多いです。「これならすぐに始められる」といった方法も多いです。
プロジェクトマネージャが「多くのメンバーを管理」するには向かないですが、プロマネ自身の時間管理、そしてメンバー自身の時間の管理などには充分参考になると思います。 (アキンド/2006-11-30)

確かにエンジニアに特化した内容も一部ありますが、事務系のサラリーマンにも役に立つノウハウが一杯です。対人関係や調整の多い仕事では、自分の時間は人任せと考えがちですが、逆説的に自分で時間を管理する効率化の余地は大きいと思います。

「自分の記憶力を信用しない｣、「ルーチンとは、一度だけ考え、何度も実行するための手段である｣、「この世には優先順位は３つしかない｣など、簡潔で鋭い指摘がいいですね。 (XP/2008-01-04)

本書はオライリーシリーズだし、ということで購入。
が、これをぜーんぶ守った場合、どうなっちゃうんでしょうね？（笑）

実例チックなトピックスがいろいろ出てくるのですが、事例が極端すぎて参考になりません。それはまだ自分が本物の修羅場を知らないだけかもしれないしれませんが。

で、とにかくすべてを計量化するわけですよ。
１時間毎に自分のPCからビープ音が鳴るように設定し、音の都度、自分の活力と気力を０から１０の段階で数値化。両方の数値が高い時間帯にあわせてスケジュール調整。
これは・・・（笑）
この本の筆者の場合は若い時は午前２時、今では午後２時が頭が冴えているそうです。

最終的に掲げた目標に一歩でも近付く、そのために何でもする、という場合はいろいろと参考になりそうです。個人的に「おわりに」にあるあいた時間の有効利用、という箇所に心を打たれました。地域に還元するさまざまな提案があったからです。

自分だけが良ければいいのではなく、自分がまず何らかの生活の基盤なりパワー（地位、お金、立場等）なりを確立し、最終的に余力を使って人助けに向かうという健全な姿勢。すばらしいと思います。体力は相当いりそうですが（笑） (夜の翼/2007-08-28)

元々、オライリー出版というのはエンジニア向けの技術書を
書いている良い出版者です。

この本は、一風変わっていて、その、
特定の技術に関する「How to」ではなく、
SA(System Administrator=システム管理者)のタイム・マネジメント術
について言及されています。

ＩＴ業界は、常になんだかいそがしいー、というカンジの世界です。
近づく納期、次々に変化する最新技術、、
いろんな意味で、時間との競争という側面をもちます。
ときに、なんで、こんなにいそいでいるのだろう？と
時間を管理しているのではなく、時間に管理されている自分に、なんだか凹みます。笑

面白いのは、
ＰＤＡっていう、チッチャイコンピュータがありますが、
時間管理には、メモ帳を駆使した「ＰＡＡってのもつかえる！」
ってかいてあることです。

限られた時間内で「片付ける」術を、システム管理者の視点でかかれてあり、
精神衛生面についてのケアもなされています。

何より著者の、同業者への愛情が感じられて、そこが何よりの
著者からのギフトとなっています。

オススメです♪
(やーまん/2007-07-29)

シチュエーションがシステム管理者というだけで、ビジネスマン向けの手帳術にあるような目標設定やTODO管理が「いますぐｘｘを用意しよう」みたいな感じで具体的に紹介されています。
TODOの重要度付けや目標を実現するためのノウハウなど、理論よりは実践的な内容が多いです。
内容はこの手の本と同様の事例であるため、おそらく王道だと思います。
読みやすいので、時間管理なんてやってない　という方には良いと思います。 (UMEOKAKA/2009-05-16)

タイトルにはエンジニアと書いてあるが、内容はシステム管理者に向けたものです。
スクリプトを利用した処理の自動化は、一般のビジネス書にはまず載らないので、
参考になる人もいると思います。
内容の多くは、実行可能な予定を立てろ、優先順位を付けろなど、
一般のビジネスパーソンにも通用するものです。
事前の予想よりも、アナログ・紙面重視の管理スタイルを推奨していました。
残念ながら、アナログ手法主体であれば、
一般ビジネス書の方が日本企業の実情にはマッチしている気がします。
(おにい/2008-12-01)

システムエンジニアが時間を管理する上でのポイントなどを知りたくて購入、通読
読んでみると、SEがプロジェクトを達成するためのポイントについてまとめたものではなく、システム管理者（複数のサーバー、ネットワークなどの最終管理者）が日常から直面するクリティカルな問題も含む様々な問題と、プロジェクトを管理するする上でのポイントをサイクルシステムというシステムを利用しての提案になっている。システム管理者が持っている能力や義務は確かに他の人たちとは異なることが大きい。その能力を利用して、タスクを自動化したり、義務をどのようにさばいていくかを具体的に記載してくれている。脳内の能力を記憶に使わずに外部装置を利用するべきというのは、様々な本で共通的に提案されていることだが、本書をよんで改めて感じた。
システム管理者として、業務に追われていると感じているのなら、本書を読んでみることを勧める。筆者の提案しているものそのまま完全に利用するのは様々な環境を想定すると難しいかもしれないが、効率よく仕事をこなしていくためのヒントが多々ちりばめられている書籍になっている。
(sickboy/2008-07-02)

まず最初に。この本の英語のタイトルは「Time Management for System Administrators」。日本語タイトルと違って、これはあくまでも System Administrator のための時間管理術。

シスアドというのは、ものすごく「on demand」な仕事が多い。ユーザーはマシンが動かないと悲鳴をあげ、マシンは部品が壊れたとアラートを上げる。どれもこれも「書類入れに積み上げておく」ような対処の仕方は出来ない。問題が起こった所に飛び込んで問題を解いてあげるしかない。

しかし、そのような仕事の仕方は作業効率を著しく下げる。事前準備が出来ないからだ。これは人間だけの話ではなく、RTOSと呼ばれるOSはそうじゃないOSを使った場合の60%ぐらいしか処理性能を出すことが出来ない。「緊急時対応」のためにリソースを一部残しておくと、どうしても100%リソースを使うわけには行かないのだ。

この本を読んでいて思ったのは、この本に書かれているやり方はRTOSのリソース管理方法とそっくりだ、ということ。別の言い方をすると「ちゃんと実践すれば、本当に成果が出るに違いないと思われるし、内容は汎用的だ」ということ。

ただし、60% は 60%。この本を読んだら、無茶なスケジュールを立てても大丈夫、とはならないが、その点だけは警告されていなかった。この本を読む前に、念頭に置いて貰えるといっそう効果が上がると思う。 (fjの教祖様/2008-03-18)

本書は、要求の導き出しから仕様化、要求の変更管理までを網羅している。
システム開発において、的確な要求を導き出すという永遠のテーマについて書かれた良書。
ＨｏｗＴｏ本と読み物としての二つの側面をもつ。
要求導き出しのテクニックなど、具体例をあげ解かり易く書かれているので、これから上流工程へ携わるビギナーの方にもお奨めできる。
また、訳本ではあるが、文章は平易で読みやすいのが大変良かった。（日本語訳、監修の方のご苦労が伺える仕上がりになっている）
本書では、要求の導き出しから仕様化の間に「要求のトリアージ」を行うことを推奨している。システム開発において、予算と納期、要求のバランスをとることは大変重要である。
この時点でボタンの掛け違いをすると、大抵の場合、納期遅延や予算超過などプロジェクトの失敗を招くことになる。
本書の第３章で取上げられている「要求のトリアージ」では、要求を選び出すための技術について触れられており、参考になった。 (ＫＩＴＴＹ/2007-01-08)

内容が前に出たソフトウェア開発者採用ガイドとかなりかぶっています。かぶっていない部分は前作と比べると面白くありませんでした。ソフトウェア開発者採用ガイドを持っていない人なら買ってもいいんじゃないでしょうか。 (やすます/2009-05-20)

本書ではRelease後に発生するであろう障害に備えて設計時点でどのようなことを行っておくべきか、またどのような設計が障害を招きやすいのかということをさまざまな角度から示しています。
　開発者ならばここで紹介されている内容の１つくらいは実体験し、それに対する対策も考えていることでしょう。
本書ではそうした障害を仮想的に経験することで、開発者としての経験値を上げ、将来の障害に備えたデザインパターン、アンチパターンを多数理解することができます。

開発者必携の１冊と考えてよいと思います。 (Turtle/2009-05-10)

「ふりかえり」の手引きというのはとてもよいものだと思います。
反省というと、何か悪いことをしたときだけの意味に使われることが多いからもです。
よい思い出を、思い出そうという趣旨では、振り返りというのはよいと思います。
それも、漢字ではなく、「ふりかえり」というひらがなで表現するのがぴったり感があります。
名古屋アジャイル勉強会でも、ふりかえりの訓練をいろいろやっているようです。 (kaizen/2008-07-11)

アジャイルなチームが、イテレーションごと、リリースごとに行うべき「ふりかえり」について、ふりかえりのはじめかた、やること・進め方、まとめかたなどを説明しています。

本文は200ページに満たない薄めの本ですが、著者らが「アクティビティ」と呼んでいる諸活動（言い換えると、「ふりかえりミーティングの議題」のようなもの。または、議論のすすめ方、意見の表現のしかた、共有のしかたをまとめたもの）が豊富に紹介されていて、大いに参考になりました。

これまで、KPT（Keep、Problem、Try）だけでふりかえりをしていましたが、紹介されているアクティビティから他の工夫も取り入れてみたいと思います。 (izagon/2007-10-06)

”レトロスペクティブ”はいわゆる「ふりかえり」なわけですが、これを読むとその可能性が、ぐーんと広がった。
ここまで活用するか！というぐらい、さまざまなワザが詰め込まれています。

　・チェックイン
　・フォーカスオン／オフ

と呼ばれる、簡単な場の設定方法から始まり、

　・555
　・カラーコードドット
　・ヒストグラム

などのデータ収集，アイデア出しの手法、
さらには、レトロスペクティブ終了時の

　・KPTとか（他にもたくさん！）
　・プラス／デルタ

と呼ばれる気づきの共有方法まで。

他にも、50近くの実践が詰め込まれています。

小飼弾さんの書評で、「カタカナ化過多」と言われてたのはその通り。でも、これで読むのを敬遠するのはもったいないです。（たしかに、読みなれるのにページを要したが。。）

「レトロスペクティブ」に問わず、チームのあらゆるプロセスにおいて活用できる。リーダー、メンバーを問わず、プロジェクトを進める役割を持つ人にとって、チームを活性化させるためのアクティビティを得られます。 (mnishikawa/2007-10-16)

プログラムマネージャーとして働くことが多いため、どうやって円滑にプロジェクト、特にチームを率いていけるだろうかと考えていたころ出会った本です。

仕様書の書き方（なるべく面白く書く）、WindowsとUNIXの考え方の違い（これはすごく同意します）、ペーパープロトタイピング（この本でそういうUIデザインの技術があることをはじめて知った）、エクセルの共有機能を使ったスケジュール管理、テスタ（QA）を雇わないと大変、マーケティングの人間にプログラムマネージャーにしない、開発者の面接の仕方、などなど

この本に書いることは全部ためしている。

ぼくが以前はプログラマーであったので、ジョエルの開発者からの視点はすべてに納得がいきます。

でも、結局はビジネスの人はシステムをドラえもんが作っていると思っているんだろうなぁと良く感じる。
今のところ四次元ポケットを作れといわれていないのが救いか？ (紅天太郎/2007-01-30)

メソドロジやプロセス、プロジェクトマネジメントなどを扱った書籍って、最近多いですね。そういう書籍って、読後に「結局現場で使えるのかなぁ」といったモワモワした感じが残りがちです。そういう本に飽きが来ている人に、この本をお勧めします。この本はソフトウェア開発にまつわる様々なことが書かれた著者のブログを集めたものですが、いろいろな「気付き」を与えてくれるだけでなく、内容がとても「地に足着いて」います。前述したモワモワ感が残りません。著者が現場で得た生きた経験に基づいているからだと思います。

また、訳書ですが、十分自然な日本語であり、とても読みやすいのも GOOD です。 (rerun/2006-02-20)

プロジェクト管理に関する45のエッセイを人気Webブログサイト「Joel on Software」から収録した本。多くの章は読み物として読んだが、中には実務で使いたいと思う方法や考え方を見つけられたのは収穫。一時有名になった「Joel Test」（プロジェクトを成功に導き、コードの質を高めるための指標）に始まり、仕様書の書き方、スケジュール管理、テスターの重要性、ペーパープロトタイピング、開発者の面接方法、チーム管理などなど、ユーモアたっぷりに、現実的ですぐ実践できる指針を示しているのがよい。ブログサイトでのQA集を最終章として収録。 (鈴木純一/2007-09-29)

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

Webサイトに公開したエッセイをまとめたものです。

内容は、仕様書はどうあるべきか、プログラミングに関するtips、人の採用やプログラミングチームのマネジメント、自分自身の仕事の方法、取組み方、IT業界の歴史や各社の戦略、競争に関する考察、以前にいたマイクロソフトの開発の様子などです。技術技術した話題は少なく、マネジメントやIT業界に関する話題が多かった気がします。

独立した話が４５個程度あり、順序もなく、興味のある内容だけ読めるようになっています。

アメリカと日本の違いなどもあり、「明日からそのまま使える」という本ではなかったですが、その考え方は、ソフトウェアプロダクトの生産現場やプログラミングチームを率いるときに、役に立つことが多い印象でした。

勉強のため、というより、読み物として、と思うと、楽しく読める本であると思います。 (lemonerika/2006-09-24)

ソフト開発に携わっていながら、本当の意味でわかっていない人によんでもらいたい本です。泥臭さを本当の意味で理解し、考えようとする気がある人には、納得できる内容ばかりです。

なお、本書には、随所にいろいろな情報がちりばめられています。
新入社員だけでなく、日ごろなんとなくソフト開発している人に、お勧めかもしれません。

個人的には、自分たちのソフト開発チームに参加する方全員に、よんでもらう予定です。
(まみむめ/2007-10-08)

かつてExcel(VBA)開発のマネジメントを行い、現在Win用ソフト開発会社を
率いる著者が、人事採用、環境整備、品質管理、経営戦略等々、縦横な視点
から語ります。
内容は総じて具体的で面白いのですが、もってまわった言い回しが論旨を
ぼかしていて、結局何を言いたいのか結論が見えないことも。
またWordに必要な機能を考え出したのは?年前だと批判するわりに、
自身が開発に関わったExcelの巨大さは必要な機能だと言い張ったり、
.NETのランタイムの巨大さとプリインストールされないことを批判するわりに
VBを開発言語のメインに据えていたり、
アンチエイリアスが読みにくいという著者の主張を通すために、
AAをかけたフォントにわざと読みにくいフォントを使用したりと、
著者の強引な誘導に気づいて鼻白むことも。
しかし、そういった癖の強い著者にあるときは共感し、あるときは腹を立て
るのが、この本の魅力になっています。 (mononoke/2006-04-30)

著者はXPをはじめとするアジャイル手法にやや懐疑的なスタンスを表明しているが、じっさい本書に書かれている内容は、かなりアジャイルである。

重要なのは彼がそれを実体験から独自に編み出して実践していることで、ご立派な「方法論」の本とはわけがちがう説得力がある。そして怖いのは、同様な手法をMicrosoftが長年実践しているという点である。Microsoftには、ちょっとやそっとじゃ追いつけない理由がここにある。 (ただただし/2005-12-25)

コの仕事に限った話ではないけど、いかにして場の空気を読むのが重要で、どうして生産性が上がらないのかとか、経験則に基いた話がたくさんで読んでて楽しく且つタメになる本です。これからプロジェクトマネジメントとかやりそう、またはプロジェクト管理に不安がある人向けかな。もちろん一端のプログラマが上司はこういうことを考えてるのかなあと想像しながら読んでもよし。 (浦郷圭介/2006-01-12)

マイクロソフトに勤めた後自分の会社でも開発者として活躍するジョエルのwebサイトの内容を本にしたのが本書である。
プロジェクトマネージャの真実、マイクロソフトの裏側、ソフトウェア開発の方法論など、ジョエルが普段感じていること・考えていることが軽い文体で書かれている。
面白いエッセイ。おすすめ。 (amazon_hk/2006-05-07)

米マイクロソフトや米大手ISPのJunoで、ソフトウエアの設計・開発に従事してきた筆者によるソフトウェア開発などに関連するエッセイ(同名サイト)を書籍化したものだそうです。

ソフトウェア開発やプロジェクトマネジメントや、業界の論評などについて、優秀なソフトウェア開発者が考えたことを、アメリカ人らしいユーモアのある軽い文体で書かれています。

個々のテクニックなどは、専門書を読めばいいので、エッセンスや考え方みたいなものを理解すればいいというものでしょう。

ただし、このアメリカ人の軽い文体を、日本語訳した文章の日本語っぽくなさが読みづらくてしょうがないので、☆3つにしておきます。 (ヴィヴ/2007-01-04)

すばらしい。
細かく見ていけば不満点もないわけではないが、全体的に見たとき、これほど（いろんな意味で）面白く示唆に富んだエッセイはなかなかない。しかも、自分の知識が増えるほどに面白くなることは請け合いだ。思い当たる節が諸所にあるのも、面白さを倍加させる。

日本の風潮と合わないために採用は難しいが、「読みたくなる仕様書」は心底書きたいと思う。

電車など、公共の場で読む場合は注意。噴き出して奇異な目で見られても自己責任で。 (みりん/2009-05-15)

プログラマーなら気楽に読めるし、ユーモア満載でとにかく面白い本です。

決してかたっくるしい本ではないけれど、色々興味深い話題もありますよ。

joelonsoftware.comのサイトに掲載されていて本に収録されていない記事も多いので、ぜひ改訂版を出してほしいです。 (ミカトイ/2008-12-02)