アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

著者 : Scott Berkun 村上雅章

• オライリー・ジャパン (2006年9月7日発売)

作品紹介・あらすじ

本書では「ものごとを成し遂げるためには何を行う(あるいは行わない)べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケーション、トラブル対策、リーダーシップ、政治力学といったさまざまな角度から考察しています。マイクロソフトで多くの巨大プロジェクトを成功へと導いてきた著者の豊富な経験とノウハウが凝縮された一冊として、マネージャやチームリーダーだけでなく、プログラマ、テスターなど、プロジェクトに関与するすべての人にお勧めです。

感想・レビュー・書評

[dekadannaさんの感想 · 2018年11月12日]

タイトルに負けない、プロジェクトマネジメント全体を扱う本。内容はエッセイ風にまとめてあり、読みやすい。ボリュームはかなりあるので、ざっと目を通した後、自分が困っているところを熟読してヒントを得るという使い方が良いと思う。プロマネとはどういうことをするものなのか、自分のイメージしていたものと近い。プロマネとは、プロジェクトを管理していく人ではなく、推進していく人であることを改めて認識をした。メンバーがいかに気持ちよく、悩まずに仕事できるように環境を整えるか、これがプロマネの仕事と言える。自分が納得いかないからといって、部下を問いつめるような輩はプロマネ失格だと言えよう。

[みなさんの感想 · 2024年4月2日]

大規模開発時のプロジェクトマネジメントのノウハウが詰まっている。

[桜美林大学図書館さんの感想 · 2023年9月25日]

https://cool.obirin.ac.jp/opac/volume/386020
多摩にもあります

[tabathyさんの感想 · 2021年12月25日]

20211205読了。
プロジェクトマネージャーがなすべきことについて書かれた本。計画、スキル、マネジメントについて。
ボリュームがあって読むのに苦労するが、各章のまとめを読めば概要は分かる。

以下、個人的なメモ

・プロジェクトマネージャーはプロセスではなくチームに注力すべき。いい仕事をしよう。

・優先順位によって物事が成し遂げられる。ノーというのがプロマネの仕事。

・スケジュールは見積りによって作られる。見積は確率。よってスケジュールも確率。

[sokuさんの感想 · 2021年4月18日]

その時その時に応じて、腑に落ちる本と思われる。

[suさんの感想 · 2020年10月14日]

ずっと手元に置いている。プロジェクトマネジメントといえばの名著。タイトルからして秀逸。

[morizo1000さんの感想 · 2019年10月28日]

20191027
マイクロソフトでブラウザ戦争時代のIEのプロジェクトマネージャーを務めていた経験をもとにした実践的なPM論
・PMにはバランスが求められる。PMの使命はプロジェクトを成功させることであり、さまざまな状況において適切な態度を求められるから。独裁と委譲、曖昧さの許容と安全性の追及、複雑さの容認と簡潔さの支持、勇気と恐れはPMが主に直面するジレンマ
・スケジュールは下記の役割をもっており、その効果が発揮されるように作るべき
-いつまでに誰が何を完了させるのかを約束させる
-依存関係から成果物の想定読者を明らかにし協調を促進する
-進捗を管理できるようになる
・ソフトウェア開発のプロセスはいろいろあるが、工程は、設計、プログラミング、テストの３つにわけられる
・プロジェクトにおける主な作成物は下記4つ
市場要求ドキュメント:市場分析とプロジェクトがその機会をどう利用できるか
ビジョンスコープのドキュメント:プロジェクトの存在目的と目標、高レベルの機能と要求
仕様書:技術的な実現方法を定義
WBS:タスクの一覧
・プロジェクトの検討においては、ユーザー、ビジネス、テクノロジーの3つの観点が必要
・目的にむけた手段の検討にはアイディアが求められる。アイディアには発散と収束があり、それぞれアイディアの洗いだしと選択肢の評価というタスクに相当する
・仕様書の目的は、設計を忘れないための記録と他の人に伝えるコミュニケーションであり、レビューとフィードバックを可能にするもの。副次的には進捗管理のためのマイルストーンともなる。
・仕様書には要求仕様、機能仕様、技術仕様がある。仕様書は設計が完了したのちのドキュメンテーションとして捉えるべきでそうしないと非効率な設計となり、不明瞭な仕様書となる。
要求仕様:実現方法に言及しないプロジェクトの成功の条件。ビジョンとスコープのドキュメント。実現したいシナリオ
機能仕様:特定のシナリオにおける挙動の定義であり、画面要素定義と挙動パターン
技術仕様:機能仕様を満足させるエンジニアリングアプローチ、テックのコンフルでシステム配置・参照API・参照DB。機能仕様から自明である場合合わせてもよいが、混同はせずどうコーディングすればよいのかに直接答えるドキュメントは必要
・意思決定においては、何を意思決定すべきかのメタ意思決定が重要。重要な意思決定においては、Procon評価が強力
・コミュニケーションはPMの全て。特にWBS、組織図、スケジュール、プロセスによる役割の定義が重要で、PMがそう役割定義すれば作成物を一切作らなくてもよい
・最も効果的なコミュニケーションは双方向の対話であり一方的な命令は悪手。コミュニケーションのステップは大きく5つあり想像以上に長く高い、発信→受信→理解→合意→有益な行動
・プロセスは有用だが人を不快にさせる可能性がある、ローカライゼーションが重要。
・難題は必ず発生する。気を落ち着けてタスクをブレークダウンし、毅然と責任をとるのが最善
・信頼は有言実行によって生み出され、それによって獲得した力は付与された力よりも強力
・ビジョンの一覧、機能の一覧、作業項目の一覧は紐づけられ優先順位がついているべき。機能削減などの調整が容易に行えるため
・政治とは分配をめぐる争いであり現実に存在するもの。プロジェクトの目的に照らし必要ならば影響力の関係を見極めアプローチすべき

[端淵縁さんの感想 · 2019年7月16日]

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

[gyamanさんの感想 · 2019年1月27日]

1

[ykikuchiさんの感想 · 2018年11月25日]

"マイクロソフト社で培われたプロジェクトマネジメントスキル、幅広い視点のノウハウを体系的にまとめたもの。
ユニークな点は、社内の政治についても触れている点。
プログラミングをまとめる人の参考になるのでは。"