リスト：プロジェクトマネジメント を表示しています。（全 15 件）

プロジェクトマネジメントに携わっている人には、必須の書籍である。
本書は、企業の競争戦略を支援するPM戦略を支えるものとしてツールボックスの概念の提供に始まり、PM戦略の視点からツールと技法を捉えている点が特徴である。
プロジェクトの選定というポートフォリオマネジメントからはいり、立上げ、計画、実行、コントロール、終結のプロセスに沿って50を越えるツールが紹介されている。
本書は、ツールの解説のみにとどまらず、具体的な利用の仕方まで掘り下げた内容が魅力である。また、事例紹介もツールの理解の助けとなっている。付録に記載されているPMBOKとの対応、またプロジェクトの種類に応じたツールの分類は、実務への適用の大いなるヒントとなる。
PMBOKでは物足りないツールと技法の情報が本書では余すことなく紹介されており、PMBOKを補完するツールと技法の辞書としても利用できる。
かなりのボリュームの書籍ではあるが、PMIの最優良図書に選定されているのもうなずける質と内容である。
（umiumi,PMP / 2007-02-15）

PMBOKにある44のプロセスに対し、50種類以上の「ツールと技法」の解説やテンプレートが載ってます。１つのプロセスでも複数の「ツールと技法」が載っており、それぞれのメリデメや活用のヒントなどが細かく説明されてます。例えば「コスト計画」のツールとしてはScoring Modelなど５つ取り上げられてますが、小規模なプロジェクトであればScoring Model、大規模で利益を最大にしたい場合にはPortfolio選定での方法など、プロジェクト（組織）の特性に応じたSuggestionまで解説されてます。
内容は実践的で即使えるものがかなりありますので、現場のPMにとってはBibleになるでしょう。（Shigeo Awamura, PMP / 2007-03-08）

この手の本は、一度読んでしまうと、すぐに売却を考えてしまいますが、この本はちがいます。難解で抽象的なＰＭＢＯＫを読み込み必要なかたも、この本を参照にしながら、よめば、ツール例や運用イメージが掲載されているため、非常にわかりやすくなります。ＰＭＰ受験にも役にたちそうです。特に最後の方に掲載されている、ＰＭＢＯＫのツールと技法をプロジェクトの規模や重要度別に、使用する必要があるのか、ないのかが整理されている表がついており、このあたりも参考にしながら、自社のＰＪ向けにカスタマイズするときに役にたちそうです、あと１０００円だしてもいいですから、ツールのデータ（ＣＤ−ＲＯＭ）が付属していると助かります。やはり、翻訳がところどころおかしいので、１ページ目からじっくり読み込むような本でもないようです、（PMO_man / 2008-03-02）

プロジェクトマネジメント（ＰＭ）では、確かに人間関係を円滑にする
手法が必要である。しかし、その効果を得るためには、そもそも
ツールを意識せず使いマネジメントができているときである。
本書では、多大な資源と専門知識を必要とするツールを紹介している。
自分にとって使いやすいツールから意識して使うことでＰＭのスキルは
上がることだろう。
個人的には、細部に目が行きがちなので、マイルストーン予測図を
重宝している。
本書でも、「プロジェクトをコントロールするために高いレベルで
概要を示すに適した機能をもつ最も良いツール」として紹介されている。
（なか / 2010-03-18）

PM/PMO関連の他の書籍と一緒に購入したのですが、この書籍が一番まとめられていると思います。わかりやすく書かれており、個人的には満足しています。
しかし、これからPMをされる方が、この書籍を読んで全部理解できるか？というと、
厳しいと思います。何度かPMを経験された方が読む書籍としては、非常に良いと
思います。（kazu / 2009-08-09）

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

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

ＩＢＭの大成功したコンピュータのソフトを作った人の書く
　ソフトウェアエンジニアリングについて述べた本
１９６４年当時、何もないと言っていいほどの所から
大ヒットしたIBM 360システムのシステムソフトを作り上げた時の
知見をまとめたものです。
　１章から１５章までは、題名にもなっている２章の「人月の神話」
をはじめとして、開発に当たって実施したこと、および得られた知見に
ついてまとめています。
　１６章がこの本の副題にもなっている「銀の弾などない」であり
ソフトウェアエンジニアリングに対しての知見をまとめています。
　それ以降の章が２０年経ってから増訂された内容で、１７章が
「銀の弾などない」の補足、１８章が、１５章までのコメント、
そして１９章が全体の補足と、他の書籍へのレビューとなっています。
さすがに１６章までの内容は古くさいものがあるものの、現在でも
通用する知見の固まりになっており良くできていると思います。
そして、その古くささは、１７章以後の増訂により間違いは修正され
その後の良書との対比により、本書の位置づけがわかりやすくなっています。
タールの沼に陥らないために何を考えなければならないのかを
まとめようとした本書は、古典ではあるのですが、避けては通れない
重要な課題であることを認識できた良い本です。（親カッパ / 2009-08-29）

新しい技術に飛びつく人は多くても、本書で述べられているソフトウェア開発の「本質」に向きあっている人はほとんどいないのでしょうね。長く読み継がれているにもかかわらず、本書の教訓がいかされている気配はありません。今後もしばらく誤った認識が幅をきかせることでしょう。
ソフトウェア開発に悩んでおられる方は、是非読んでみてください。あなたが間違っているわけではないことを発見できると思います。（ヨーカンとカステラ / 2001-09-28）

最先端のソフトウェアエンジニア(のつもり)でいる人って、新しい技術や手法が山ほど押し寄せてくるので、どうしても「古典」につき合ってるヒマ、ないですよね。
しかし！このブルックスや、ワインバーグなど、時代を超え国を超えてエンジニアの脳を直撃する名著がたくさんあります。
新しい技術書を追いかけてもまさに「キリがない」ですが、ちょっと立ち止まってこういった古典に触れることで、本質的な理解が高まり、一気にパワーアップすることができる…かもしれません！
亡父もコンピューターエンジニアだったのですが、何と親子でこの本のお世話になっていました。
翻訳のせいか、ちょっと読みにくいのが難で、4点。（Tack / 2002-04-29）

プログラムにチームの一員として携わったことのある人ならば 「納期に間に合わないからと言って直前に人を増やされてもなぁ」 と思ったことがあるだろう。 この本の主題の一つは「納期直前に人を増やしたところでプログラムは完成しない」 ということだ。
プログラミングという最新の世界のようでも、実態は２０年以上前と ちっとも変わっていないことを痛切に感じられる。
プログラミングに限らず、チームでプロジェクトをこなすという場合に 考えておくべき事項が幅広くまとめられている。 古典であるかもしれないが、その内容は現在にも通じている。（ / 2001-03-25）

この本では人月で仕事を換算することの愚かさを説いているが、私の会社ではこの本でいうところの悪い慣行を続けている。しかし、現実には未だ人月ビジネスを行っているところは多いようで、一部の上級コンサル会社だけが成果で対価を得ている。ソフトウェアの見積りでファンクションポイントが定着しないのは、日本の人月ビジネス慣行が根強いからで、このような文化・風習を１つの会社だけでなく日本のソフトウェア業界から変えていかなければ理想にはたどり着けない。しかしながら、各所で当書籍は絶賛されており、ソフトウェア業界に携わるものは必読である。この書籍に興味がある方にはワインバーグの書籍も併せてお薦めしたい。 （ / ）

顧客の声を引き出すのが、システム設計の基礎中の基礎。
請負開発であっても、市場に投入するパッケージ品であっても、
顧客の要求が何であり、その要求をどのように手元で管理するか。
効率的なシステム設計には必須の事項だ。
人と人との相互作用については、要求引き出しの際も、
実際のシステムの運用の際も、同様の技術が必要だと思う。（kaizen / 2009-07-27）

要求工学の基本やIEEEなどの規格に忠実に、"要求とは？"から始まり、要求の引き出し、要求分析、SRS（要求仕様）のまとめ方、要求管理まで
じつに網羅的に、著者の経験談も交えて丁寧に解説されており、米国での評判に納得しました。翻訳も一般的な訳語(でもJISの訳語とはかなり違う)、"ですます調"で、良いと思いました。書籍の性格上、特に要求プロセスについて何か著者独特のものが示されているわけではありませんが、まず基本的な知識をと思っている方には最適だと思います。要求プロセスで何か読んでみたい場合は、ロバートソン夫妻の「要件プロセス完全修得法」（三元社 ISBN 488303111X ）が良いと思います。（有名で本書でも参考文献になってます。ただし日本版は翻訳が悪い）（neu-neu / 2004-01-04）

ソフトウエア開発に最も重要なのが、要求をとらえる（見いだす・理解する・構築する）こと。この本は、そのことを再任し視させてくれるし、要求をとらえ文書化するための様々なテクニックを網羅すると共に、関連づけ、使えるように手助けをしてくれる。ユーザに近い位置にいる人もそうでない人も、ソフトウエアは何のために作るのかを、日々確認するために、一度読んでおく方がいい。動かない（動かす価値のない）コンピュータシステムを再生産することのないように。（osm10 / 2005-05-21）

文章表現が若干堅苦しく、少し読むのに疲れるものの、記載されている内容は非常に素晴らしい。
何が素晴らしいかと言うと、SI会社やコンピュータメーカー等のSEやSAが、要求定義段階で見落としがちだが、本来やるべきことが明確に書かれており、要求定義の重要性を述べるだけのつまらない本ではない。
実践に応用する（実案件に置き換える）ことこそ必要なものの本質的に決めておかなければならないアイテムを述べ、なぜ必要かを説いている。
プロジェクトの成否に関わる重要だが、軽く見られがちな要求定義におけるSEやSAのバイブルとなりうる本であると思う。（velvetblue / 2003-08-28）

要求工学に関するトピックを網羅した良書で、これさえ読めば要求工学の知識は完璧と言えるでしょうが、問題は内容盛りだくさんなことで、なかなか全てをこなすことは難しいと思います。Part Iは必須でしょうが、Part IIからは、実際には拾い読みになるのではないでしょうか。
32ページに顧客と開発側が満たすべき10箇条がそれぞれ書かれていますが、著者が先ず言いたいことはここでしょう。この20箇条が満たされるのであれば、その後はかなりうまくいくと思います。でも、実際にはなかなか...
本書は厚すぎる、と思われる方には、同様の内容でよりコンパクトの、"The Software Requirements Memory Jogger"という小さな書物があります。Ellen Gottesdienerが著者です。
（加納 裕 / 2008-08-01）

確かに網羅的に説明してあるのですが、実際に、この場合は
どうすればいいのか？　を探して使うという利用法には向いて
いないようです。
（masabun / 2006-04-29）

マネジメントを覚えるなら優秀なマネージャにマンツーマンで教わるのが一番効果的でしょう。しかし、なかなか、その優秀なマネージャが存在していません。反面教師として見るのもよいですが、やはり自己流ではなかなか会得までの道のりは厳しいものがあります。
ソフトウェアテストを実際に進める上でも、教科書通りにテストを実施するだけではなかなか成功することはできません。テストプロセスをきちんと組み立て、それを上手に動かすことができて成功するのだろうと思います。
この本では、ケーススタディとして、ひとりのベテランマネージャが登場します。まあ、架空の世界ですし、なかなか敏腕なマネージャですからそのまま自分がやることはできませんが、ひとつひとつの手法の真似をしながら、人を動かす基本を学べるなかなか面白い手法の本です。
テストという作業はストレスが掛かり気味になりますが、ぎすぎすした職場を作らないためにも、お勧めしたい一冊。（ / ）

ソフトウェアテストフェーズというのは、ソフトウェア構築全体の遊びの跡が表現されるフェーズである。従ってそこでの結果はおもちゃ箱ということになる。箱の中に残ったおもちゃを良く分析・グルーピングすることで遊び手（ソフト作り手）が何故不具合を作ってしまったのかが仮説を含めて詳細に報告できる。この本はその助けとなる知恵が各章ごとにプロセスチェックリストとして纏められ、テンプレート、様々な事例が補足してくれている。それがタイトルの「１２の必勝プロセス」として活かしてほしいとの意志表示だろう。不具合を分析する際の教本では「ソフトウェア要求：Karl.Wiegers:上流部分」と「ソフトウェアの欠陥予防：Marc.McDonald 他：中流部分」が役だった。Rex Blackのテストの世界を是非堪能してほしい一冊だ。（川島文 / 2009-03-25）

ＰＭ関連の本は、本当にたくさんたくさんあります。
気をつけなければいけないのは、杓子定規でいわゆるセオリーやロジックが記述されているものを間違って購入しないようにすることです。
資格をとるのであればいざしらず、資格はフォローはしてくれるかもしれませんが、実践に直接的には役にたたないことは、実践している人たちはよくわかっていると思います。
この本は、示唆に富んだ具体的に共感できる本でした。
特にコミュニケーションや目標設定など＜ヒト＞の共感や理解を重視した箇所については、とかく指示的にいきやすいＰＭとしては、ありがたい教えです。
また、あちらこちらにあるＴＩＰＳのようなコメントは苦しいときや大変なときに、振り返って見ると、冷静になって対処できるような気がします。
「ＰＭの８０％の仕事はコミュニケーションである」
「勝者は目標を設定し、敗者は言い訳をする」
なんて、最高じゃないですか？？？
時々に再読することをお勧めします。
さすがＩＤＩＯＴ　ＢＯＯＫ（バカでもわかる本）シリーズですね。（パタ / 2007-03-20）

この手の本は、世の中たくさんあると思いますが、PM経験者、非経験者を問わすお勧めの一冊です。実務に即した内容で、プロジェクトを進めていく上で、起こりうる事象と、それに対する対処が細かく記述されており、特に、社内政治のケアまで書かれているのは、見事です。特に、海外と仕事をされる方は、日本と進め方が大きく違うので、会議などで、会話の文脈を合わせるのに非常に役にたつと思います。（takeshs / 2005-10-20）

プロジェクトマネジメント関連の本には、どうやって計画するか、どう考えるかというものが多いが、本書はどう解決していくかを理解できる本である。プロジェクトは生き物であり、そもそもの計画がそのとおりになることはない、問題が起きたときに実際に対応するのはプロジェクトリーダーでなくチームであり、関連する人たちの感情をも考慮にいれプロジェクトを成功裏に導く方法を総合的に理解することができる（99 / 2006-10-15）

先輩に薦められて購入しました。
具体的な事例を示し、初心者にも大変わかりやすい内容で記述されています。
はじめて学ぶ本としては最適だと思いました。
私はまだプロジェクトマネージャーの仕事をしていませんが、
これを読むことでプロジェクト全体の流れや、重要なポイントが
見えてきたと思います。
仕事をしていると、色々と悩むことが出てきますが、そういう時の指標になる
良い本と思います。
（真 / 2009-04-20）

Idiot's Guide（アホの為のガイド）とあるが、随所にワンポイントの言葉と絵が挿入されており、理解を助けてくれるのが良い。判り易く読み進むうちに専門的な知識が身につく実用書としてプロジェクトリーダー・メンバーに勧められる。これで期限通り・予算内でのプロジェクト打ち上げの美酒を味わえそうである。（MM / 2005-06-14）

初版は１９８７年だから、もう２０年にもわたって読み継がれているソフトウェア開発者の「古典」である。著者のトム・デマルコは、８０年代後半から９０年代にかけて活躍したシステムコンサルタント。構造化技法のひとつである「デマルコ法」の考案者としても著名である。
ドッグイヤーとかマウスイヤーと呼ばれるほど進歩の早いこの業界にあって、本書がこれだけ長い間読者を魅了し続けるのは、まさに書名のとおり、ハードウェアでもなく、ソフトウェアでもなく、それを作る「人」に焦点をあてた論考だからであろう。
最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はこれ以外にはなかったと思う。
現場のソフトウェア開発者の視点に立って、管理者や会社側の不条理を追及するというスタンスなので、当時プログラマだった筆者は「わが意を得たり」と密かに喝采を送ったものだった。チームで回し読みしては「パーキンソンの法則」「スパゲッティディナー効果」「チーム殺し７つの秘訣」「黒服チームの伝説」などなど、議論白熱して終電を逃したことも懐かしい。
当時の仲間はいまや皆管理職になり、本書からは攻撃を受ける立場になった。今、第二版を読み返してみると必ずしも肯ける話ばかりではないが、それは単に立場が変わったというだけではなくて、きっと初心を忘れてしまっているからなのだろう。
というわけで、筆者にとって本書は、この業界に身を投じた当時の初心に立ち返るための大切な本であるが、もちろん若い方にも勧めたい。頭のかたい上司、理不尽な上司の下で働いている方なら、きっと溜飲が下がること請け合いである。（丁三 / 2006-06-17）

いかなる仕事も，それを実行する「人」にかかっている。このあたりまえのことをあたりまえと放置せず，「人」の仕事の質を上げる，または下げる要素について広く深く分析している。特に阻害要因についての記述は，組織で仕事をしている人ならば誰しもが頷け，自分の組織にこうなって欲しいと希望を持ち，
あるいは自分の組織のダメ具合に暗澹たる気持ちになるような内容である。経営者やリーダーたち全員に読んで，本書の示唆通り実行して欲しい本。多数の読者の声によって，そのために復刊されたのだから。（kasm / 2001-11-26）

1987年に出版された第1版にプラスして「ピープルウェアの小さな続編」を設けたこと、それと電子メール環境の繁栄により一部の記述を変更した形となって第2版が出ました。実は第1版は読んでいないのですが、記述されている「プロジェクトにおける人」について如何に振舞うか、扱うかの内容は今も15年前も変らないです。特にプロジェクトにおける管理者の役割についてはプロジェクトマネージメントの精神論的な内容に思えて、「ここまで人を大事にすべきか！」と思われるほどです。作業環境について一人あたりのスペースについても記述されていましたが、目に見えない効果をどこまで管理者層が納得して動けるか・・・というのは大きな課題です。
これまでの日本において欧米に追いつけ、追い越せで実施してきて戦後（そのときは皆中流階級）、そして日本が世界に到達したときに得た次なる目標、次なる仕事の仕方が見えなくなり、それとともにITによる世界的なデフレ化。そのために「人」も他と同じように頑張れば食べていけた時代から、何時の間にか360度評価、実績主義へと変貌したかと思ったら、次は「整理解雇」に意味が取って代わったリストラが台頭してきている現在を思うと、「ピープルウェア」は誰のために？と悲しくなったりします。
お互いの利益を超えた（というか利益を考えずにお互いの幸せを供する）仕組みが近いうち訪れるのではないのかと考えています。資本主義は競争社会であり、かつかけがえのない地球を蝕んできたことを徐々に多くの人が気づき、良い方向に向かおうと努力しているように思われます。そのときには「ピープルウェア」の真髄が随所に発揮される世の中になっているのではないでしょうか。
「人」について一番幸せな方法を皆で考えましょうと訴えてくれた大切な一冊になりました。（やんちゃ青 / 2002-07-02）

旧版とあわせて、折に触れて手に取ります。

・・・プロジェクト成功の鍵は、「技術」「プロセス」「人」の３つ。
ＩＴ技術者にとって「技術」は生命線ですが、
プロジェクトの円滑な推進には「プロセス」と、
そもそもの「人」・・感情を持つ人間の営み、組織論の理解が
十分条件になると再認識し、
チームのあり方や
自身の行言動を振り返ることしばしばです。（papillon / 2007-08-21）

謳い文句としてはソフトウェアプログラマーの管理手法とそのあり方についてのお話。
だが、管理という概念について非常に考えさせられる有益な本だと思う。
実験結果もあり、童話のようなものもあり、説得力も高い。
ただ、内容的には「デッドライン」と多くの部分がかぶっている。
気になったのが、後半部から訳が直訳になっていて、
日本語としてというか文章として成立してないと感じる部分が
非常に多く、翻訳ソフトを通した結果でも見ているかのような
文章になっていた。
「デッドライン」のほうは完璧に日本語に感じられたので残念。（んにゃ / 2004-11-27）

「最高のプレイヤーがいるチームが最高のチームだ」
「スキル不足をプロセスで穴埋めする事はできない」
「バスに乗っている一部の不適格者のために官僚的なプロセスを適用すると、適格者がバスから降りてしまう」
「問題に慌てて対応してしまうと、後で技術的な負債が増大していく」
プロジェクトマネジメントオフィスからではない、現場からのリアリズムあふれる直言。
近道なんてない。ただ当たり前の事を当たり前に地道にやっていこうという本。アジャイルとはかかれているが、アジャイルには限らないプロジェクト管理の基本。
あなたが抱えている問題に、あなたに代わって答えを出してくれるHow to本ではないが、あなたが自分で考える手助けをしてくれる筈。（0xdeadbeef / 2005-10-23）

自らが参画するプロジェクト、その成功は？
対場によって目指すゴールにギャップを感じ、プロジェクトマネジメントの難しさに直面された方も多いことと思います。
この本で語られる「アジャイルプロジェクトマネジメント(Agile Project Management)」とは、競争力のある製品により「変化を作り出す」こと
チームで「変化に対応する」ことこの両者が一体となり、「変化を味方につける」新しいマネジメントの考え方である
　と示されています。
実際に読まれて「なんだ。自分の判断は正しかった。」と感じる方も多いのではないでしょうか？
実は（生意気かもしれませんが）私も「やはり、間違っていなかった！」と感じた一人です。
もちろん、新たに学ぶことも多く、よい意味で考えさせられました。
ここで解説されるアプローチは、日本の現場にとても親和性のあるアプローチです。
チーム作りのポイント「や「毎日のミーティングでリズムを作る」効き目のある「意思決定の枠組み作り」など、
今すぐにでも実践できそうな考え方や行動のポイントがわかりやすく書かれています。
また、事例も多く盛り込まれています。
加えて、付録の「アジャイルプロジェクトマネジメント(APM)の体系」に本書籍内の関連ページが記載されて使いやすさを増しています。
プロジェクトのゴールに発注者、ユーザーの笑顔が見える。
チームのメンバーがプロジェクトを通して成長できる。
そんなゴールを目指す方々（ソフトウェアの開発者や、様々な業種のプロジェクトマネジャー）にお薦めの一冊です。
（ / 2005-08-23）

詳しく書かれているのでしょうが、内容からすると少し文章が長く辛かったです。
プロジェクトマネジャーの立場としてアジャイルを解説しているので、
顧客とのやり取りに重点をおいています。
特に参考になったのが、意志決定で「Win-Win」を重視するために、
激しい議論の中にも、お互いに信頼し合い、尊敬し合ったうえでの、
礼儀ある議論という言葉でした。
熱くなると、自分さえWinになればと考えてしまいますが、冷静になれる言葉でした。
（なか / 2008-09-17）

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。
この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。
全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。（yu-ji / 2006-09-13）

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。
計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。
5章と11章だけでも読む価値があるかと思います。（tkcjun / 2005-12-03）

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。（ユングベリ / 2008-12-21）

私はIT業界でプロジェクトのサブリーダーをしている女性です。
プロジェクト現場では、次々と問題が発生して、
上手く対応できず、悩みが尽きません。
この本は、同じ悩みを抱える先輩から紹介されました。
はじめはあまり期待していませんでしたが、
読み進めるうちに、プロジェクト現場の問題に対して、
具体的な解決方法を提言している本だと確信しました。
私の会社ではPMBOKをもとにプロジェクトマネジメントの
標準化を目指していますが、
PMBOK流の理論と私が関わるプロジェクト
現場との乖離を感じずにはいられませんでした。　
まさにそのギャップを埋めてくれたのがこの本です。
（まるで痒いところに手が届くようでした。）
特に日本人である著者が、
アメリカの厳しいプロジェクト環境で得たノウハウは、
他の本にはない説得力があります。
（ノウハウだけでなく著者の体験談と主観的な判断
も散りばめられていて、私小説的と言えなくもない
けど。個人的には面白く読めましたが。）
そして、全体を通して著者の信念がにじみでていて、
実務者として共感できるところが多かったです。
絶対おすすめです。寿司ランチの特上
を我慢する価値あり！！（スシ姉 / 2005-07-12）

PMBOOKの知識だけではプロジェクトはうまくいかないと言っている本が多い。では何が必要なの？という質問に答える本は非常に少ない。
例えば、実際プロジェクトを計画しても、変更が多く、うまく推進することはままならない。
本書では、１５のプロセスが開始から終了まであると説明してます。特に、計画を立てるプロセスで抑えるべき急所が満載です。
プロジェクトマネージャーの具体的な仕事って何？という悩みを持っている人が多いかと思います。世話焼きが役割と考えている人も多いかと思いますが、この本は、プロジェクトマネージャーがしなければ、考えなければいけないルーティンとは何か？を教えてくれてます。（mago / 2003-12-18）

当たり障りの無いきれいごとの方法論を書いているPM本はたくさんあるが、この本には驚きを覚えた。筆者はアメリカで15年プロジェクトの現場にいたらしいが、その経験に基づく合理的で論理的なPM論と手法が濃密に書かれており、実に読み応えのある本であった。日本企業の馴れ合い的なPM現場に身を置く私としては考えさせられ、反省すべきことが多かった。今、職場に置いて手引きとして反復して読んでいる。筆者はPM研修会社で研修を行っているとあるが、是非一度ナマの声を聞いてみたい。（ / ）

私は現在PMの現場に身を置いており、幾つかのPJTを経験しているが現場では計画通りに進捗できず、悩みを抱える事が多い。この本は同僚に薦められ読んでみた。今まで多くのPM本は読んでみたものの教科書的な初歩的なものばかりで実際に役立つ本には正直出会えなかった。しかしこの本は一線を画しており、実務に役立つ情報が満載である。プロジェクトのフェーズごとの問題点や効果的なプロジェクト手法が詳細に述べられ、今後の業務に活かせることが網羅されているのである。私も我がチームのメンバー全員にすぐ読むように薦めた。PMに従事している人間には必読の書である。（ / 2005-02-10）

この本は、読めば読むほど味わいのあるプロのPM待望の書である。リソースプランの章では、「リソース管理部門と交渉し必要最低限のリソースを確保する」と書かれている。その中で「組織に安易に迎合するな」と言い、更に組織の問題として、「何より最大の不幸は組織が現実に存在する問題を学ぶ機会を奪い去ってしまうこと」と述べている。この部分だけでも本が1冊書けるほどの内容を、いともあっさりと記述してしまう所にこの本の恐ろしさがある。読むほどに味わいが出てくる本である。（ / ）

著者ははじめににおいて，「デスマーチプロジェクト（常態よりも５０％以上逸脱している
プロジェクト，死ぬほど大変なプロジェクト）は、常態であって、例外ではない」と述べている．
このような大変なITプロジェクトが避けられないならば，そこから生還するにはどうすれば
良いのかを書いている本．
中身は，アメリカのコンサルタントが書いてある本にありがちな，最初の章で定義を行い
その後の章が色々書いてあるという形態そのもののように思える．ちなみに２章以降は
政治，交渉，デスマーチ・プロジェクトの人々，デスマーチ・プロセス，プロセスのダイナミックス
クリティカルチェーンと制約条件の理論，時間の管理，進捗の管理と制御，デスマーチのためのツールと技術
シミュレーションと「戦争ゲーム」と１１章からなる．
特に難しい理論が展開されているわけでもなく，最後の２章は自分のツールのCMなので
気楽にまずは読むことができるのではないかと思う．そのなかから，トリアージ，時間の管理
チームの構成など，気になるものを探し出す方法が良いのではないかと思う．（親カッパ / 2007-11-29）

デスマーチの定義、デスマーチへ陥る原因のくだりは、共感する部分が多いのですが、
そうなってしまった場合の対策はあまり具体的に述べられてなく、別の本を探したほうが良いのかなと感じました。
また、純日本的な企業で働いていると、アメリカとの企業文化の違いもあり、
ちょっと自分の環境とは現実離れしている部分も気になりました。
- 本の中で出てくるアメリカのマネージャ・プログラマはハイリスク・ハイリターンで働いていて、
　失敗すれば首(ただし転職容易)、成功すれば多額のボーナス、長期休暇。
　マネージャがプロジェクトを請け負うか断るかの選択肢まであり。
　マネージャとプログラマで給料がかなり違う。
- 一方の日本的な企業ではローリスク・ローリターンで、
　失敗しても首の心配はなし。
　ただ、成功してもボーナスはほとんど変わらないし、休暇も桁違いに少ない。
　デスマーチを断る権利はほとんどなく、デスマーチに巻き込まれてる人はほとんどが仕方なく巻き込まれてる
　管理者になると残業手当がなくなり、場合によっては残業代つく部下の方が給料多い。
どちらの社会・会社がいいかは人によって違うと思いますが、こんなデスマーチを避けるにはどうすればよいか？というのは、もっと勉強と経験を積んで修得しないといけないのかなと思いました。（kura / 2006-10-23）

書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。
現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。
そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。
万能の解決策はないということではないでしょうか。
少なくとも、
１　有能な技術者を組織する（やる気にさせる）
２　お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないでしょうか。
割とありがちな問題と、割とありがちな解決策が体系的に書かれているので、時間があるときにのんびりと読むとよい。くれぐれも、デスマーチプロジェクトの時には読まない方がよいと思った。こまっているときには、原因を解決する方法か、対策が大事で、ありがちな解決策では解決しない。それは、公式プロセスの導入という、デスマーチプロジェクトに適用してはいけないと本書で書いていることと同じではないだろうか？
（kaizen / 2008-01-06）

本書で言う「デスマーチ」とは、主にソフトウェア開発を対象として「開発者に過度の負担を掛けながら破綻への道を突き進む」プロジェクトを指す。私はソフトウェア開発25年の経験を持つが、私の入社時には「遅れたプロジェクトに新たに人員を投入すると、そのプロジェクトは更に遅れる」という名言で有名なブルックスの「人月の神話」がプロジェクト管理の本として著名であった。
本書では、「プロジェクトのパラメータが正常値の50%以上のもの」をデスマーチと明快に定義している。例えば、納期、人員、予算等が見積もりに対して半分以下なら即デスマーチだ。逆に要求仕様が2倍だったらやはりデスマーチだ。著者はデスマーチが起きる原因を、経営、営業、楽観主義、不測の事故等に分類し、解説する。こうした分析嗜好はアメリカ人の性癖によるものだろう。簡潔に言うとアメリカでは職能(マネージャ、担当者etc.)主義が徹底しているのでそれに沿って、ある意味マニュアル化した方法で対処するのが良いと言う。
翻って日本はどうだろう。顧客との折衝でビジネスライクに事を進め、常に必要な予算を確保できるのであろうか ? 私はむしろマーフィーの次のような法則の方が現実に近いように思われる。「失敗する可能性のあるプロジェクトは必ず失敗する」。そして、失敗する可能性の無いプロジェクトなど存在しないのである。（紫陽花 / 2006-12-01）

ソフトウェア開発業界では、８０年代後半から９０年代にかけて「ＣＡＳＥ」や「構造化技法」が一世を風靡したが、著者のＥ．ヨードンは構造化技法のひとつ、ヨードン法の考案者として著名であった。筆者にとっては懐かしい名前である。
さて本書は、そのヨードンが長年の経験にもとづいて、デスマーチプロジェクト（＝開発メンバに非常にきつい労働を強いるプロジェクト）からの脱出方法を説いたものである。考察は広範に渡っていて、政治的圧力への対処方法、予算や期日の調整、リソースの交渉術、人の問題への対処法など、システム開発プロジェクトで直面する問題をほぼ網羅している。
とくに新しいアイディアとしては「トリアージ」という考え方を提出している。
「本書からたったひと言だけ覚えるとすれば、それは「トリアージ」である」P127
トリアージとは、戦場や被災地で限られた医療資源を、緊急性や効果に鑑みて、負傷者に割り当てること。転じて、数量の乏しい必需品を最大の効果が得られる人だけに割り当てるシステム、のことをいうそうだ。火を噴いているプロジェクトでトリアージを間違えると、時間と労働力という貴重な消化資源を浪費してなお火は鎮火せず、いよいよ燃え広がってしまう。いやはや恐ろしい。
ただ論文というよりエッセイにちかく、全体にやや散漫、冗長でまだるっこしい。デマルコに比べるとジョークもいまいち冴えない。もちろんおおいに勉強にはなるが、読み物としてのおもしろさ、という点ではデマルコに２，３歩譲るだろう。
ともあれ、ヨードン、デマルコ、ケン・オア、ワインバーグといった往年のコンサルタントたちに親近感のある方にはお勧めできそうである。（丁三 / 2006-06-17）

プロジェクト管理の要諦を、物語仕立てで描いたものである。
テーマは主にプロジェクトチームの活性化やプロジェクトメンバのケアについてで、
トムデマルコの著作のなかでは「ピープルウェア」に近い。
いつものようにその指摘は鋭く、切れ味はよい。たとえば、
　・一日をむだにする方法はいくらでもある。しかし一日を取り戻す方法はひとつもない。
　・プレッシャーをかけても思考は速くならない。
　・我々は味方同士である。敵は問題そのものだ。
などなど。ニヤリとさせられる箴言ばかりである。
ただし理論的ではなくあくまで経験論的なので、
プロジェクトマネジメントの初学者にはピンとこないかもしれない。
逆に言えば、経験に応じて光って見える言葉も違ってくるだろう。
何度も読み返して自分自身の成長を確認する、という読み方もよいかもしれない。
一読の価値はある。（丁三 / 2006-11-23）

ピープルウェアの作者でもある、トム・デマルコの思想は、徹底的に、人間を善人としてみていて、気持ちがいい。 それはしかし、単なる楽観主義ではなく、ソフトウェア開発コンサルタントとして長年働いてきた経験に裏付けされたものであろう。
管理者が管理するのは数字ではなく、「人」なのだ、という、ピープルウェアでも貫かれていた思想が、より強力に打ち出されている。 しかもそれがエッセイや論文でなく、なんと小説で！！ 小説になっていることにより、エンターテイメントとしても一級の作品になっている ただ、この面白さがわかるのはソフト開発者に従事する人間だけではあろう。
しかし、その分、ソフト開発者が読めばこんなに痛快で面白い本はないとおもう。一読の価値あり！（ / 2001-04-13）

著者はソフトウェアの世界では有名な人物のようであるが、いやいや小説家としても中々の腕前のようだ。
「ソフトウェアのプロジェクト管理に関する参考書」という捕らえ方もできるが、純粋に「小説」だと思って読んだ方がいいように思う。小説として楽しく読み進めながらも、そのなかで自然にプロジェクト管理に関するノウハウを知ることができる、参考書としては非常に優秀な本だ。
参考書とするには中で述べられる「１０１の法則」は概念的で具体性に乏しいものが多いのですぐに使えるものではない。かと言って役立たずではもちちろんないが･･･。
中で使われている言葉は専門的なものはほとんどないので、ソフトウェアの開発経験がなくとも十分に理解できる。何らかの開発経験があれば十分に楽しむことができるだろう。（本格派 / 2006-05-10）

この本の主人公「トムキンス」と同じ立場の人なんて、ほとんどいないでしょう。
なにしろ、国家プロジェクトである重要なソフトの開発総責任者という立場なのだから。
この本には主人公を助けるスーパーマンさながらの人物が沢山出てきて、次々起こる問題を解決していきます。
１週間あれば十分読めるほどの容量ですから、あまりの急展開に正直「そんなにうまくいくか！？」とか
「ありえない。。」と思う点もしばしば出てきますが（自分が普通の底辺プログラマ＆設計者だから
というのもあるかも知れませんが）、新発見や再確認など出てくるポイントが的を射ていてズパリな
「やや抽象的な」法則が出てきます。全てそのまま使える法則という訳ではありません。
ですので、法則をかいつまんで自分で咀嚼し、吸収する、ということをやらないといけないと思います。
その過程を経て初めて役に立つ本となることでしょう。
一通り読んだ感想として、ソフトを成功に導くためには「人を扱う力」「人に接する力」が大事なんだなと感じました。
あくまで自分にピッタリ！というわけではなかったので星４つです。（zico / 2005-12-13）

スイスイ読んでしまいました。ピープルウェアも確かに平易ですが、小説形式である分さらにこちらの方が読みやすいです。現実的にありえない設定でオイオイとツッコミ所満載ですが、理想論としては本当はこうできたらいいなと思うことが色々書いてあります。日々悩みもがくなかの、判断基準の一つ、リファレンスとして、別の著作のピープルウェアと同様価値があると思います。
ただし、こうできたらいいけど、なかなか難しいな、物によったら無理っぽいな、という状況が並んでいるのを読んで、読者が理想論に過ぎないと拒否反応示す場合もあるのでは？と心配になりました。（デッドラインは小説中の凄い設定が特にそう思わせる）
周囲の環境に恵まれた経験と、コミュニティとして機能していないチームでの!!経験がある人なら、うなずける部分がそれなりにあるのでは？と思います。表現が多少大げさだとか、定量化できないから上司を書いてある通りの方向に納得させにくいな、と思う部分を差っぴいても、一度は読むことをお勧めします。（悩み多き頭でっかち / 2002-04-18）

トム・デマルコといえば、80年代から90年代前半にかけて活躍したシステムコンサルタントで、構造化技法（ＤＦＤ法）の発案者としても著名だ。1987年刊の『ピープルウェア』はチームビルディングへの深い洞察を軽妙なユーモアで綴ったエッセイで、ソフトウェア開発者のバイブルとしていまも読み継がれている名著だ。
本書はそのデマルコの最近刊である。軽妙ユーモラスにして核心を突く警句の数々は依然健在だ。
リスク管理は「おとなのプロジェクト管理である（p15）」、とデマルコは言う。子供たちは普段、隣国の核兵器開発や治安の悪化、環境破壊などを心配しなくてもよい。が、大人はそうはいかない。子供たちを守るために、そうした「望まない結果」のことまで目を配って当然だからだ。このような巧みなアナロジーがリスク管理の本質を端的に指摘して新鮮である。
また本書には他に見られないユニークな方法論がひとつある。「ナノパーセント 日」という考え方である。
プロジェクトの完成予定日は実は確率分布である。まったく何の障害もなく完成する最楽観スケジュールと、どんなにひどくともここまでには完成する最悲観スケジュールの間のどこか。それが完成予定日の真の姿だ。もちろん、最楽観日に完成する確率はほとんどゼロ、すなわちナノパーセントである。「不確定性の幅は、その組織の開発プロセスにどれだけノイズがあるかで決まる（p67）」。にもかかわらず大半のプロジェクトはこのナノパーセント日を完成予定日にしてしまう。
リスクとは「望まない結果を生むかもしれないもの（p16）」のことである。人間は誰でも「望まない結果」から目を背けがちだ。しかし、何も起きるはずはない、と信じる権利は誰にもない。だからリスク管理が必要なのである。
ともかく800字ではとても書ききれない。ぜひ、本書を手にとって欲しい。（丁三 / 2006-06-09）

終わりよければ全てよし・・という考え方ではいけない、とこの本の冒頭
では言っている。
リスク管理をせずにソフトウェア開発プロジェクトが失敗すると、裁判に
なったら負けるのだ。一生懸命やって遅れたらごめんなさいではすまない
のだ。なぜ遅れるのだ。リスク管理をしないからだ。かいつまんでいうと
そういう話だ。
いままで、リスク管理の本といえば、「こうあるべきだ！」というべき論
しか書いてなかった。それができるんならとっくにやっているという話ば
かりだ。この本のおかげで、やっと本当のリスク管理とは何かがわかった
ような気がした。
いつも開発スケジュールが遅れるプロジェクト管理者にはぜひ読んでいた
だきたい。なぜなら、遅れる原因はあなたか、あなたの上司がリスクを負
わなかったからなのだから。（だんのりゅういち / 2003-12-21）

と喝破されて、不安になりました。最近、仕事で関係するプロジェクトで知らぬ間にリスクを減らしてゼロにしようとしてきたのではないか、それではプロジェクトとして立ち上げた意味がないではないか、ということです。
　リスクを無くすためにプロジェクトをやっているわけではなく、リスクをコントロールするのは成功のための手段ですね。
　リスクの評価を、たった一つの期待値ではなく確率分布で表現するやりかたは、興味深いです。たまたまですが、投資の費用対効果を同じような確率分布で表現してみたことがあります。手作業ではなかなか手間がかかりますが、原因と結果の確率分布をモンテカルロ法でシミュレートする市販のソフトを使ってみると驚くほど簡単にできます。その手間の心理的障壁が取り除かれれば、でてくる結果の質に目を向けられるでしょう。直感だけでなく定量的にも評価する、という見方もできますが、直感を定量的に表現し客観的に他の人にも説明できると考えたほうがいいと感じました。
　どこまで精緻にリスク分析を行うかは、時と場合によると思います。ただ、最近のツールを使えば、ＰＣでかなりのことができるようになってきています。「リスク分析・シミュレーション入門」という本が参考になると思います。（jimmy / 2004-04-30）

リスク管理の入門書として良い点が二つ
テクニックの紹介は標準的な内容を網羅している
リスクを愉しむ勇気を与えてくれる
リスク管理を後ろ向きなものとみなす組織ではなかなか実践できないかもしれません。
しかし先制攻撃的なプロジェクト管理をやらなくては後手に回って間違いなく火の車です。
さぁ、勇気を出してみましょう。（天然素人 / 2004-03-12）

危機管理の基本的性質は回避策。一方、リスク管理の基本的性質は受容策。タイトルの「熊」がリスクの比喩であることは明白ですが、「ワルツを」と言う部分から、これがリスク回避ではなく受容の本であることを暗に示しています。リスクと上手くやって行くと言うことですか。
特に目新しい考え方、捉え方と言うのは紹介されていませんが、デマルコ特有の軽い語り口（軽妙な翻訳）がその理解と認識を深めてくれます。特にRiskologyというプロジェクトのリスク分析シミュレーター（Excelワークシート）を利用したリスク分析プロセスが有用です。
トム･デマルコの本は、手法や方法論の紹介と言うよりも、考え方、ポリシーの紹介とその徹底が主旨なんだと捉えています。そういう意味では、プロジェクト管理に携わるかどうかに関わらず、みんなが読んでおいた方が良い、読むべき本だと思いますね。（espio999 / 2006-04-14）

原題の「Slack」は、ゆとりというよりもヒマな時間、何もしていない時間という、どちらかといえば否定的意味合いが強い言葉である。
　ムダ時間はほんとうはムダなのではない、
　実はムダ時間こそが真の生産性向上のために必要不可欠なのだ
というのが本書の主張であるから、原題のスラックは反語的な表現であろう。
効率性を求めてスラックを削っていくとイレギュラーを吸収する隙間がなくなり、組織から柔軟性が失われて結果的に変化に弱い組織を作ってしまう。
一方、組織の変化は原理的にトップでもボトムでもなく中間管理層からしか生まれない。
従って、中間管理職が働きすぎていて、スラックが乏しい組織には未来はない。
と、だいたいこういう論旨である。
「ピープルウェア」と「デッドライン」では、開発チームの視点から組織の活性化というテーマを扱ったが、本書では、組織における中間管理職の役割を解明することがテーマのひとつでもある。他が比較的経験論的に書かれているのに比べ、本書は理論ベースで議論を展開している点も特徴的だ。
　働きすぎている管理者はやるべきではないことをやっている。ｐ81
なかなか耳の痛い指摘である。
中間管理層のプロジェクトマネージャには一読の価値がある。（丁三 / 2006-11-23）

工業時代の効率化は、変化の激しい現代社会における知的労働者に対しては通用しないどころか悪影響を与えるとデマルコは主張している。リストラと称して、人員削減をはかることが、逆にコストを増大させていると主張している。その上で、現代の知的労働者の生産性を上げるために何をしたらいいのか、という点を論じている。
トム・デマルコは、何より「ゆとり」が大切だと言う。それは、人員、時間の両面であてはまる。中間管理職の存在意義やリーダーシップ論、学習の仕組み（それは新しい発想の仕組みと同義だと読み取れる）、リスク管理について、論を進めている。
この本で語っていることは、多くの知的労働者は既にわかっていることだ。しかし、競争相手やお客様や上司からのプレッシャーで実現できないのが実情だ。なぜ、できないのか、どうしたら、ゆとりを実現できるのか、について、もっとつっこんだ議論を展開してほしかった。（motofji / 2001-12-10）

デマルコ氏の考えが完全に正しいと言うことはできないが、少なくとも私は本書に書かれている数々の知見に対し異を唱えることはできなかった。
プロジェクト管理をこれから学ぼうとする人(私も含めて)にとっては良い参考書となるだろう。
本書の言葉を借りれば早期にリスクを発見するための道標となるはずだ。
また、プロジェクト管理者でなくとも、今までの自分がどうだったか、今後自分がどうあるべきかを考えさせられる。といっても自己啓発的な内容ではないので構えずに読み下すことができる。
万人にとって(明らかに本書の中で批判されている類の人で変化する意思の無い人を除く)良書である。（ / ）

タイトルは「ゆとりの法則」。しかし「ゆとりを作れ」ということが本題でなく、「正しく管理せよ」というのが本書の主題だ。「正しく」管理できない連中が、いかにも「余裕のない働き方」をしていて、それを批判的に考察してみれば「ゆとりを持て」ということになるわけだ。
私の属するIT業界において、いい加減な仕事しかできない人にゆとりがないというのは、かなりの確率であてはまる。
ゆとりなく、ダメな仕事人になる流れは以下のような感じだろうか：
■仕事の本質がわからず、話をまとめられない
■話がまとまらないので雑用ばかりが増える
■雑用をやっているうちに結局仕事は仕事としてまとまらない
でも（言うまでもないことだが）ゆとりがあれば仕事ができるというわけでもない。優秀な人材ならば効率的に仕事を行っていくためにゆとりが必要なことにはすぐ気付くし、そして必要なゆとりを作り出す。
たとえば、この本を読まねば気付かない人に「ゆとり」の大事さを説明して、それでその人が本当に「ゆとり」を有効に活用するだろうか。そういう意味で評価の難しい本だと思う。（とりさん / 2002-02-11）

　ソフト開発が環境に左右される脳の創造作業だという事を改めて痛感しました。当たり前のことですが中々これを理解されていない経営者やプロジェクト管理者の方々が多いのでは？。是非、そうした方々に読んでいただきたいと思います。
　狭くて時間にうるさい日本では中々ゆとりある環境や時間などは後回しになりがちですが、この本ではこうした環境や時間にゆとりがなければ効率は失われることを示唆しています。効率をツールや開発の仕組みに頼るのも良いですが、品質は中々確保できません。
　また、私はソフト開発に20年近く携わっていますが、ここ数年の短期の開発が若手の成長を阻み、品質が著しく低下している傾向に危惧しております。この若手の成長にも環境や時間が重要です。ITが華やかになり多くの若者が参入してきますが、熟練者の技術を学ぶ機会には中々ありつけません。ソフト開発は大工と同じで熟練者の技術を後世に伝えていかなければ、いずれ会社は衰退していくのではないでしょうか。（polarbear / 2004-06-10）