アート・オブ・プロジェクトマネジメント の商品レビュー

スコットバークン【著】,村上雅章【訳】

2021/12/25

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

以下、個人的なメモ

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

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

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

2019/10/29

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

2019/07/16

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

2018/11/25

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

2018/11/12

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

2018/10/23

村上さんの訳本なので、読んでみた。ソフトウエア開発のマネジメントのみでなく、一般的なプロジェクトマネジメントにも参考になるプラクティスてんこ盛り。消化吸収が難しいが、すごくためになる本であると思う。ソフト屋の書いた本で、７つの習慣を参考文献におしているものはたくさんあり、この本もその例に外れないが、カミュの「シューシュポスの神話」までを参考文献に押しているものは初めて。こんなソフト屋が書いた本なので、参考文献は良書の宝庫。読書のための本としても一級品。

2016/08/12

とにかくサラッとエッセンスだけを、と思い各章のサマリーを中心に読む。プロジェクトの構築、スケジュール管理等については、IT中心なので評価できず、その他のリーダーシップ論的なところは参考になる部分がありました。
残念なのは、文意が理解しにくい、具体例を含め、余分な冗談などがあり、ポイントが見つけにくい点。
訳もこなれていなく、読んでるうちに気持ちが離れていきます。読み込もう！と思わないと、理解できない部分がマイナス。

2016/06/27

ソフトウェアのプロジェクトマネジメントに関わる全ての人が読むべき本。ノウハウから、管理タスクとして何故それをする必要があるのかまで書かれており、非常に盛り沢山である。

副題の「マイクロソフトで培われた実践手法」の通り、メンバーへの質問という形でノウハウが得られる。

2015/11/09

書籍名がカッコよくて内容はイマイチかなと期待していなかったが、整理されていて、ポイントが分かりやすくすぐに実践できることが多く、よい意味で期待を裏切っってくれた一冊。

細かい部分はプロジェクトの状況やステークホルダーのよって変わるのは当たり前と思うが、目指すべきプロジェクト管理をブレることなく突き進める必要性を再認識することができた。

また時間が経ってから再読したい。

2015/02/20

かなり前出版直後に読んだときは、システム開発に特化して、それ以外の一般的なプロジェクトに汎化できるヒントはないという印象だったのだが、今読み直してみると、そうでもなく大いに参考になることが多いと感じる。
環境が変わったのか、それとも私が多少成長したのかは分からないが。