リスト：デスマーチから逃れるための本 を表示しています。（全 3 件）

プログラムマネージャーとして働くことが多いため、どうやって円滑にプロジェクト、特にチームを率いていけるだろうかと考えていたころ出会った本です。
仕様書の書き方（なるべく面白く書く）、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）

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

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

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

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

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

■非常にわかりやすくて、かつ、内容も充実している好著。
■あらゆる組織等のリーダーや管理者になった場合の基本的な心得を、
「７つの知恵」として紹介している。
■リーダーシップなどに関する本は沢山あるが、
本書の場合、羊の群れの管理を例として説明されており、
これが意外にわかりやすくて説得力がある。
数時間で一気に読み終えてしまった。
■私のように既に多くのリーダーシップの本を読んでいる人が
今一度確認するために読んでも多くの新たな発見や気付きがあるし、
また、初めて部下を持つ人が
短時間でリーダーシップの基本及び真髄を理解しようとする上でもお奨めだと思う。（ / 2005-11-05）

最初は「何の能もない部下を羊として見ることでうまく操縦しよう」
という、リーダーの独善的な本かと思い、読み始めたのですが、
内容は全く逆でした。
これは、上司が部下をうまく使う際のリーダー哲学を、タイトルの通り
好き勝手に草を食べたりする頑固な羊を動かす、『羊飼いの知恵』から
吸収しよう、という、珍しくも、大変わかりやすい本です。
物語は、部下を持つことになったＭＢＡの学生テッドが、リーダー
哲学を学ぶために大学教授ニューマンの特別授業を、羊の牧場で
受けることから始まります。
しかもその内容は、本当に「羊飼い」の仕事を学ぶことでした。
なぜ『羊飼いの知恵』がリーダーシップにつながるか？
それは読んでいけばわかる事ですが、ちょっとだけ紹介します。
Ｑ どうすれば羊たちに自分を飼い主だと認識させられるか？
Ａ それは毎日牧場に顔を出して、自分がいるだけで羊たちが
　 病気なく満腹なら自然と信頼すべき飼い主だと思うようになる。
羊と人間は同じじゃないハズなんだけど、「望んでいること」は
同じだと言うことをハッと気づかせてくれます。だから、
「羊飼いの知恵」からリーダー哲学を学び取ることができるのです。
思えば組織論、リーダー哲学といったものの多くは、戦争や政治や
スポーツなどハードなシチュエーションを下敷きにしたものが多いの
ですが、この本は実に平凡（といったら失礼ですが）な「羊飼い」
という仕事から、それを紹介しています。
地味に思うかもしれませんが、だからこそ、（正しい努力さえすれば）
誰でもリーダーになれるということを感じさせてくれるという意味
でもいい本と言えるでしょう。
特に最終章の「リーダーにいちばん大切なもの」は才能とか技術の
問題でないことを我々に教えてくれるかのようです。
「究極のリーダーシップとは、ただ進むべき方向を示せるかどうかだけ
にあるのではない。その方向に群れを動かせるかどうかにあるんだ」（tkiyoto / 2005-12-08）

リーダーを羊飼いにたとえた物語。平易な内容で、センスの良い挿絵もあり、読みやすい。
羊飼いと羊の関係というシンプルな情景は、リーダーシップのとり方をイメージしやすくしている。たとえば、荒れた牧草地にやせ細った羊が半ば放置されているというシーンなどは、快適な職場環境を作ることがリーダーの仕事のひとつであることを、誰にでも理解させてくれる。人を活かすポイント「ＳＨＡＰＥ」は読んでのお楽しみとしておこう。（どうせなら「ＳＨＥＥＰ」としておけば、もっと面白かったかも。）
このような「７つの知恵」を羊飼いはリーダーシップを学ぶ読者に与えている。「５つの○○」とか「７つの△△」の類の本は多いが、本書は押し付けがましくなく、好印象を与えている。
基本的にはニューマネージャ向きだが、「一人ひとりに目を向ける」「それぞれの個性を引き出す」「自分の哲学を伝える」など、「そんなこと分かっている」といえるリーダーがどれだけいるだろうか。クラシックな指摘にどこまで耐えられるか、ベテランマネージャにも、一読をお勧めする。（六等星 / 2006-07-01）

私は生命保険会社のマネージャーをしてますが、
この本の内容は、（羊を例にしてますが）現実もまさにそのとおり！！
特に女性を部下に持つ人は読むべきです。
短時間で要点を押さえた、いい本だと思いますよ。
あらためて自分の行動を反省させられました・・欝
（masafumi25 / 2006-01-26）

頑固な羊の動かし方」
　　　　　ケヴィン・レーマン
　　　　　ウィリアム・ペンタック
　　　　　草思社
目次
プロローグ
1、自分の群れを知れ
　　　１人ひとりに目を向ける
２、羊たちの強みをつかむ
　　　それぞれの個性を引き出す
３、羊と信頼関係を結ぶ
　　　自分の哲学を伝える
４、安心できる牧草地をつくる
　　　部下が力を出せる環境をつくる
５、杖でそっと彼らを導く
　　　人を導く４つの方法
６、毅然とした態度で守る
　　　本気で怒らなくてはならないときがある
７、羊飼いの心を身につける
　　　リーダーにいちばん大切なもの
インタビューを終えて
訳者あとがき

１
□　素直に何でも学ぼうという心構えがない者に、考えるつもりは
　　ない
□　まかせた仕事のことだけではなく、彼ら自身の状態をつねに
　　知っておかなくてはいけない。
□　多くのマネジャーは仕事のことで頭がいっぱいで、一人ひとり
　　をしっかりと見ていない。
□　部下たち一人ひとりに、個人的な興味を持つ
　　部下たちにとって、いま何が一番の関心ごとなのかを、つねに
　　把握しておく。それには、積極的にかかわること。

２
□　自分と部下のＳＨＡＰＥ（強み・長所・心・仕事に対する姿勢
　　個性・経験）を知ることが成功への第一歩。

３
□　自分が導こうとする人たちに、自ら近づき心をひらかなければ
　　ビジョンが伝わること。

４
□　部下にいい仕事をしてもらうには、不安や恐れを取り除くことが
　　大切。
　　悪い知らせでも真っ先に知らせる。
□　対立を避ける３つの秘訣
　　@それぞれの仕事の大切さ、意味をわからせること
　　A群れのなかの悪玉分子を取り除くこと
　　Bメンバー間で様々な仕事やチャンスをローテーションさせる

５
□　部下が犯したあらゆる問題にリーダーは真っ先に出て行き、
　　それを解決する。
□　良いリーダーは、部下たちをつねに元気づけことを忘れない

６
□　部下が非難されそうになったら、自らが矢面に立つ。
□　失敗は「学びの機会」としてとらえる
□　定期的に「問題はないか」と声をかける

７
□　リーダーの犠牲
　　　　時間・エネルギー・情熱
□　平凡なリーダーと偉大なリーダーを分ける違いは、部下のこと
　　を真に思う心があるかどうか。

ｎａｎａｒｕの感想
強い組織の作り方が書かれています。強い組織をつくるには、あたり
前のことですが、人を育てなければいけません。
人を育てるには、まず自分自身がリーダーにふさわしい価値観や意志
を持たなければ、人はついてこないし、育ちません。
「人を変えるには、まず自分を変えろ」
本を読んでいるうちに、自分が
普段どれだけ、アルバイトさん一人一人を見ているか？
その人たちの状態を見ているか？と聞かれたようで、振り返るのに
いい機会を与えてくれます。
毎日の業務の忙しさで、頭がいっぱいの自分に反省させられました。（ｎａｎａｒｕ / 2008-03-03）