紙の本
体験的プロジェクトマネジメント論。ユニークな格言にあふれている
2005/04/16 21:25
1人中、1人の方がこのレビューが役に立ったと投票しています。
投稿者:k-kana - この投稿者のレビュー一覧を見る
日経コンピュータによれば、プロジェクトの成功率——品質(Q)、コスト/予算(C)、納期(D)を満たしたもの——は3割にもとどかないという。著者はプロジェクトの失敗要因を「曖昧性」に求める。そもそ要求仕様が曖昧なのだ。ユーザー/ベンダーが仕様をそれぞれ自分流に解釈してプロジェクトが始まる。プロジェクトが進むうちに解釈が大きくずれてついには破綻を来す。
曖昧性を打破するために、著者はプロジェクトの見積りがもっとも大切だと考えている。見積りはSEの開発業務の中で一番難しく、しかも一番重要な業務であると。見積りは必ずしも見通しが立っていない未来——プロジェクトのさきざき——を予測し、あたかも確定しているがごとく未来を表現しなければならない業務であると。したがって、見積りには想像力、勘といったあらゆる知的能力が要求されるのだ。
見積り能力向上のためには、見積りと実績の差を反省し発生責任を追求するのではなく、何が原因でそのような差が生じたのかを、冷静かつオープンに見極めることが大切である。そして、正しい実績データを自分なりに蓄積しなければいけない。
本書の底流となっているキーワードは間違いなく「設計」だろう。例えば、見積もりという日常行為に対しても、ひとつの作業としてではなく「見積設計」と表わしている点にも、著者の真骨頂があるではないか。とにかく考え抜くことだと言う。それも身体をつかって、五感をフルに働かせて。重要な課題だったら「夢に見るほど考えよ」。考え抜いて、一歩でも曖昧さを正確に近づけることだと。
——IBMの企業標語「THINK」を思い出させますね
隅々にまで著者の体験が書き込まれている。机上の空論ではない。柔軟で多面的な発想にも目を開かされる。プロジェクト計画段階から、「人は間違える」「機械は故障する」「ソフトウェアのバグはゼロにできない」で、取り組めとか。また、著者独特の切れ味のよいアフォリズム(格言)にもドキッとする。「良い名前は幸せの始まり」や「公倍数的リーダーと公約数的リーダー」とか。
SE向け教科書としては新人にはちょっとピンと来ないかもしれない。若手管理者がプロジェクトに行き詰まったとき、ぱらぱらとページをめくるという読み方もあるだろう。処方箋のヒントが見つかるはずだ。
SMARTサイトはこちら
投稿元:
レビューを見る
実体験に基づいているという意味では有益なのかもしれないけど、本としての価値はどうなの?という内容。
経験豊富なのはわかるけど、実体験がこうだったから、こうすべきだって言われてもねえ…理論としてのプロジェクトマネジメントと紐付ける部分が欠落し、エンジニアリングになっていない点がこの本の問題なのかも。
投稿元:
レビューを見る
国鉄時代の座席予約システムなど日本を代表するような大規模なシステム開発プロジェクトをまとめてきた著者が書いた、非常に役に立つ実践的なプロジェクト管理の本で、涙が出るくらいためになります。
著者のプロジェクト管理方針が随所に感じられます。
投稿元:
レビューを見る
3月30日読了。日立社にて旧国鉄のシステムのPMなどを手がけた著者が自体験からとく、実践的なプロジェクト・マネジメントの「コツ」やあらかじめ想定しておくべき問題、手を打つ際のポイントなど。お題目ばかりのPM論ではなく、実際の現場でどのようなことを想定し、どう動くと有効か(有効だったか)について説かれており、参考になる。システムというものが抱える特性(システム化しないことが最高の業務効率化/顧客にもベンダーにも「あるべき姿」は見えないもの/立ち上げ当初の労を惜しみ、手を動かすことから着手しがち、など)によりプロジェクトの発足当初から「曖昧さ」を抱え、またその曖昧さを参加当事者たち自身が自明のものとして認識してしまい、とかく「走りながら考える」「後になって火を噴いて後悔する」事態に陥りがちなものだが。打てる手は事前に打っておくべきだし、それがPMの仕事であり醍醐味なのだな。
投稿元:
レビューを見る
プロジェクトマネジメントを学習する際に役立つ一冊。
著者は国鉄時代のマルス(みどりの窓口)鉄道予約システムを成功させた。実体験からのプロジェクトマネジメントをまとめてある。プロジェクトには必ず曖昧な部分があるので、それをどうコントロールしていくかというところを考えさせられた。
投稿元:
レビューを見る
JRの「みどりの窓口」を開発を担当し、その後も多数のプロジェクトを経験した著者によるプロジェクトマネジメントの解説本
受注、見積、開発、顧客との信頼関係と解説していくが、「体験的プロジェクトマネジメント論」と書かれているとおり筆者の体験や感想、教訓が各フェーズで記載されている。システムの開発工程をひととおり体験しており、システム開発の困るポイントを押さえている人が読むと教訓やこうすべきと書いてある内容が理解できるけど、システム開発をやったことのない人が読んでも実感が湧かないだろう。
逆にシステム開発で困っている人にとっては筆者のノウハウがてんこ盛りなのが嬉しい。考え方の整理やノウハウのいいとこどりができる。特にシステム提案、見積、契約、受注は上流工程を仕切るPMには重要な工程だが、このあたりを詳しく説明してくれる本は少なく貴重な一冊である。特に「顧客にも同じ船に乗ってもらう」と称して顧客との信頼関係の構築に章を割いているのがPMBOKなどのきれいごとの論理だけでなく顧客や設計者と渡り合わなければならない現場PMの実感を表わしている。他に修羅場となったプロジェクトを担当した経験が多いせいか、デスマーチとなったプロジェクトからの対処法も各工程の中で説明されている。
『真の理解は「心で理解する」こと』とか、『工程とは承認するものではなく指示するもの』、といった精神論に近い内容も散見されるが、当事者として一人称で考えると納得できるものが多い。
プロジェクトの受注前の段階で悩んでいたり、デスマーチからどう抜け出すかを模索しているPMにはおススメしたい。また、PMはどのように考えているのかを知りたい人にもおススメ。
結びに代えてで『前向きに粘り強く、泥沼をかき分けて』とか、『命をとられるわけではない』と書いているが、これがスマートさよりも何が何でもシステムを稼働させようと考えるITゼネコンの日立らしい発想だなあ、と感じた。
投稿元:
レビューを見る
結びに代えて、が役に立つ。遭遇してしまった危機にどうしたらよいかについての著者の提言。"Muddling through" 「泥の中を通り抜ける」か、、、。良い言葉!
投稿元:
レビューを見る
ITプロジェクトの三大業病、「仕様の曖昧性」「仕様の変動性」「仕様の膨張性」の原因分析と、その対応についてわかりやすく書かれた本。歴戦のプロジェクトマネージャーの経験から多くの知見を学べます。
投稿元:
レビューを見る
これは設計開発、特にソフトウェア開発を行う人にとっては必ず読んでいただきたい本です。開発プロジェクトを実行する上で意識すべきエッセンスが網羅されています。