アート・オブ・プロジェクトマネジメント の商品レビュー
［ 内容 ］ 本書では「ものごとを成し遂げるためには何を行う（あるいは行わない）べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケーション、トラブル対策、リーダーシップ、政...
［ 内容 ］ 本書では「ものごとを成し遂げるためには何を行う（あるいは行わない）べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケーション、トラブル対策、リーダーシップ、政治力学といったさまざまな角度から考察しています。 マイクロソフトで多くの巨大プロジェクトを成功へと導いてきた著者の豊富な経験とノウハウが凝縮された一冊として、マネージャやチームリーダーだけでなく、プログラマ、テスターなど、プロジェクトに関与するすべての人にお勧めです。 ［ 目次 ］ プロジェクトマネジメントの簡単な歴史（なぜ気にかける必要があるのか） １部 計画（スケジュールの真実；やるべきことを洗い出す；優れたビジョンを記述する；アイデアの源；アイデアを得た後にすること） ２部 スキル（優れた仕様書の記述；優れた意思決定の行い方；コミュニケーションと人間関係；メンバーの邪魔をしない方法：プロセス、電子メール、打ち合わせ；問題発生時に行うこと） ３部 マネジメント（リーダーシップが信頼に基づく理由；ものごとを成し遂げる方法；中盤の戦略；終盤の戦略；社内の力関係と政治） ［ 問題提起 ］ ［ 結論 ］ ［ コメント ］ ［ 読了した日 ］
Posted by
一見して、特に新規性がなく当たり前で抽象的な訓示が羅列されているだけに見える。間違ったことは一切言っていないが、一切合切が既知。 その既知な推奨事項の実行は、プロジェクト毎に多種多様な趣を持つ、鵺のような諸種の制約条件によって阻まれる。よって如何にこれらの制約条件を正確に見極め...
一見して、特に新規性がなく当たり前で抽象的な訓示が羅列されているだけに見える。間違ったことは一切言っていないが、一切合切が既知。 その既知な推奨事項の実行は、プロジェクト毎に多種多様な趣を持つ、鵺のような諸種の制約条件によって阻まれる。よって如何にこれらの制約条件を正確に見極め、排除するかがキモなのであるが、本書はそういった部分を取り扱っていない。 当然である。まさに上で述べたように、そのキモの部分はプロジェクト毎に大きく異なり、一般例などないのであるから、本にまとめようがなく、実践で感覚的に学ぶほかない。 しかしながら、本書にまとめられた「既知の当たり前な訓示の羅列」を眺めることで、明らかになることもまたある。PMは、情報を必要な人間から吸い上げ、必要な人間に行き渡らせることで、実行部隊がオートポイエーシスとして機能することを担保するために存在し、またこれが（責任を取る主体、という部分を除けば）唯一の存在意義である、という点である。 実際に手を動かす人間の集団（実行部隊）がオートポイエーシスとして完全であるならば、手を動かさないＰＭなど無用の長物であり、いらない。ＰＭの存在意義は、実行部隊の、オートポイエーシスとしての機能不全を手当することであり、これらの機能不全は、情報の不足（例えばゴールの定義が曖昧）や偏在（例えば要件がうまく伝わっていない）によって発生する。ＰＭとはすなわち、必要な情報を見極め、必要なところに伝達する、情報伝達機械である。 個々の記述を見るとあまり有益性が見えないが、総体として見たときに気づきがある良書。☆４つ。
Posted by
ヘビーな本で、最近感想全然あげられてなかったんですけど、この本読んでたからです。これからもっと専門書籍読まねば。 ただ、どう考えても読んでおいてよかったです。これからいくらでも応用ができるから。 勤務時間中には宝物にしたい言葉ばかり。仕事のやり方を書いた本ともいえると思います。 ...
ヘビーな本で、最近感想全然あげられてなかったんですけど、この本読んでたからです。これからもっと専門書籍読まねば。 ただ、どう考えても読んでおいてよかったです。これからいくらでも応用ができるから。 勤務時間中には宝物にしたい言葉ばかり。仕事のやり方を書いた本ともいえると思います。 この本読みつつ実務やって思うのは、状況を打開するために、「これをすれば打開できる」なんてほとんど存在しないということ。 この本に書いてあるように、やるべきことを洗い出して、優先順位を一歩一歩進んでいくしかない。意思決定には労力をかけないとできない。肝に命じたいですね。
Posted by
題名にアート、とついているが、マネジメントはかなりの程度サイエンスだとこのごろ思う。 不確定要素の集合体である「プロジェクト」を、確率論的にとらえ、どうやって成功の確率を高めるか。 その引き出しとアクションが技術（アート）であり、とはいえ人がやることだから最後には感情的でちょっと...
題名にアート、とついているが、マネジメントはかなりの程度サイエンスだとこのごろ思う。 不確定要素の集合体である「プロジェクト」を、確率論的にとらえ、どうやって成功の確率を高めるか。 その引き出しとアクションが技術（アート）であり、とはいえ人がやることだから最後には感情的でちょっとした気遣いとか言い回しで変わってくる文科系（アート）の要素もある。 その意味で本書は、理論的な内容と経験論的内容のバランスも良く、ためになった。
Posted by
いままで読んだプロジェクトマネジメント本で最もすばらしい本 -- 厨房を見学してみるといい PMはプレッシャーから逃げない 「PMは、プロジェクトとの溝が深まるにつれて、不必要なまでに図表、チェックリスト、報告書に依存していくことになるのです。」 チェックリストではなくチーム...
いままで読んだプロジェクトマネジメント本で最もすばらしい本 -- 厨房を見学してみるといい PMはプレッシャーから逃げない 「PMは、プロジェクトとの溝が深まるにつれて、不必要なまでに図表、チェックリスト、報告書に依存していくことになるのです。」 チェックリストではなくチームをマネジメントする リスクへの取り組みは早めに行う ユーザビリティエンジニア、製品デザイナを早いうちから参加させる 仕様書、適切な情報が適切なメンバーによって記述され、メンバーが有効活用できる形になっていること 作業項目一覧：WBSとほぼ同じ プログラミング上のタスクを分割したもの 多くの優れた設計書では、設計が階層に分けられた上で記述されている ウェブのリンクの記入を推奨する 士気を高めるイベント 午後を休みにする、ランチ、ビール一週間無料 仕様書レビューの目的2つ「開発の指針となるくらい詳細に書かれているか」「成果物はプロジェクトの要求と目的を満足するか」 優れた仕様書はシンプル PMの時間の大半は、順序付けられた表の作成 ノーと言わなければプロジェクトをマネジメントできない 優先順位がどれほど大切か 打ち合わせのダウト 作業を捨てる仕様変更がある場合は、その該当工数も含めた上での意思決定であることを伝える 「計画に従うことで勝利できるような戦いはないが、計画なくして勝利できるような戦いもない。」ドワイト・E・アイゼンハワー 鶴の一声の取り扱い そのバグ番号(チケット番号)を尋ねる。チケット化されていないものは議論しない。 -- プロジェクト終了後の反省チェックリスト ・メンバー全員の病欠や休暇予定が何らかの形でスケジュールに反映されていたか ・メンバーは好きな時にスケジュールを閲覧、報告できるようになっていたか ・日次、週次ベースで進捗確認する担当者はいたか。調整の権限を持っていたか ・チームはスケジュールを自らのものと感じ、それに全力を傾けようとしていたか？ ・チームリーダーは、機能の削減よりも追加に力を入れていなかったか ・目標やビジョンに合わない追加作業の要求に対してノーということを推奨していたか ・見積もりを作成する際に用いた確率は90%？70%？50%？ ・定期的にリーダやマネジメント側によるスケジュール調整が組み込まれていたか ・連休や天候がスケジュールに考慮されていたか ・仕様や設計の計画はエンジニアリング側からみて問題なかったか ・優れた作業見積もりを作成するため、エンジニアに何らかの訓練機会を与えたり、経験豊富なエンジニアを採用したか -- 未読：3,4,5,6,15,16
Posted by
最初は翻訳が良くないのかなと思いましたが、それでは説明のつかない駄目さ加減がこの書籍にはあります。 シンプルが云々と言っておきながら質問リストが長たらしく一つの質問に複数の質問が含まれていたりするのは一体どういうつもりなんでしょうか。 長い文章を表にして見やすいと思ってるんでしょ...
最初は翻訳が良くないのかなと思いましたが、それでは説明のつかない駄目さ加減がこの書籍にはあります。 シンプルが云々と言っておきながら質問リストが長たらしく一つの質問に複数の質問が含まれていたりするのは一体どういうつもりなんでしょうか。 長い文章を表にして見やすいと思ってるんでしょうか。 図3-3と図3-4の違いはなんでしょうか。 どの言い回しももっと短く出来るはずです。 おそらくは面白さを損なわずに2/3くらいまでページ数を削減出来ます。 書いてある内容はどれも正しいとは思いますが、こんな状態では読む気が失せます。
Posted by
聡明な人々が快適に作業できる安全かつ公正な場を築く。 そのためには優れた、ビジョン、計画、要求定義、仕様書、意思決定、プロセス、コミュニケーション、トラブル対策、リーダーシップ、政治力学を理解する必要がある。 プロジェクトマネージャーでなくてもできることはたくさんある。 仕...
聡明な人々が快適に作業できる安全かつ公正な場を築く。 そのためには優れた、ビジョン、計画、要求定義、仕様書、意思決定、プロセス、コミュニケーション、トラブル対策、リーダーシップ、政治力学を理解する必要がある。 プロジェクトマネージャーでなくてもできることはたくさんある。 仕様書作成の適任者はプロジェクトマネージャーだとする筆者の考え方に、感銘を受けた。純粋な設計行為と仕様書の作成は別作業であるべきで、PMが意思決定の結果を一貫性を持って管理するにはPM自らが仕様書をまとめるのは理にかなっているように思える。 チェックリスト的で読み進めるのが重苦しい部分もあるが、壁にぶつかった時、リストに沿って思考を重ねるうちに、まだやれることが必ず見つかるだろう。できているつもりで、できていないことを暴き出すのにも役に立つはずだ。
Posted by
●アート・オブ・プロジェクト・マネジメント 序盤のマネジメント ・スケジュールは「1/3の法則」を活用する ビジョン ・すぐれたビジョンは覚えやすい（読み手の興味をそそる） ・信念を抱いている振りをしたとしても、ほとんど徒労に終わる ・自らに自信を持ち続けつつ、他人の影響を将来...
●アート・オブ・プロジェクト・マネジメント 序盤のマネジメント ・スケジュールは「1/3の法則」を活用する ビジョン ・すぐれたビジョンは覚えやすい（読み手の興味をそそる） ・信念を抱いている振りをしたとしても、ほとんど徒労に終わる ・自らに自信を持ち続けつつ、他人の影響を将来ビジョンに反映し、ポジティブな変化全てを受け入れる 設計/仕様書 ・うまく設計するには心の底からの理解が必要（Steve Jobs) ・スケジュール等他の観点が重視されれば、仕様書は完成したことになる コミュニケーション ・人や情報への投資。組織の動きに対する洞察を得るのに必要 ・活気のある打ち合わせはポジティブなプレッシャとなる ・話し手が賢く、自分たちを支援すると考える故に聞き手は耳を傾ける 中盤～終盤のマネジメント ・優先順位を保守することで、チームは重要事項に集中し続けられる ・活発にコーディングされていないのは、どの項目かを把握する ・バグ管理では、優先度、再現性、対応状況、タイトルを明記する
Posted by
欧米のマトリクス組織構造ならではの発想が多く、日本の組織構造での実践は難しそう。細かいTipsは役立ちそうだ。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
タイトルのプロジェクトマネジメントと聞くだけで嫌なものだと誤解して、食わず嫌いだった。しかし、アートオブとついているので、管理が技術だという視点からすれば、ちゃんと読めば良かったと後悔している。 第１０章は、特によい。人の仕事の邪魔をしないで、人の助けをするのが管理の基本である。しかし、多くの管理者、管理本は、人の仕事の邪魔をするようなことを平気でやったり書いたりしている。基本を外した本が多いなか、本書は要点を得ているので読む気になる。 飜訳が日本の文化への移転を十分していないのは、外資系の企業だけでなく、日本の企業でもソフト系の企業はカタカナ語が氾濫しているので仕方がないかもしれない。
Posted by