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

著者 : Scott Berkun 村上雅章

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

感想・レビュー・書評

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

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

[ichiro.marinersさんの感想 · 2018年10月23日]

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

[furuwoさんの感想 · 2016年6月27日]

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

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

[kumaさんの感想 · 2015年11月9日]

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

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

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

[yumu19さんの感想 · 2013年3月16日]

いままで読んだプロジェクトマネジメント本で最もすばらしい本


--
厨房を見学してみるといい
PMはプレッシャーから逃げない
「PMは、プロジェクトとの溝が深まるにつれて、不必要なまでに図表、チェックリスト、報告書に依存していくことになるのです。」
チェックリストではなくチームをマネジメントする
リスクへの取り組みは早めに行う
ユーザビリティエンジニア、製品デザイナを早いうちから参加させる
仕様書、適切な情報が適切なメンバーによって記述され、メンバーが有効活用できる形になっていること
作業項目一覧：WBSとほぼ同じ　プログラミング上のタスクを分割したもの
多くの優れた設計書では、設計が階層に分けられた上で記述されている
ウェブのリンクの記入を推奨する
士気を高めるイベント　午後を休みにする、ランチ、ビール一週間無料
仕様書レビューの目的2つ「開発の指針となるくらい詳細に書かれているか」「成果物はプロジェクトの要求と目的を満足するか」
優れた仕様書はシンプル
PMの時間の大半は、順序付けられた表の作成
ノーと言わなければプロジェクトをマネジメントできない
優先順位がどれほど大切か
打ち合わせのダウト
作業を捨てる仕様変更がある場合は、その該当工数も含めた上での意思決定であることを伝える
「計画に従うことで勝利できるような戦いはないが、計画なくして勝利できるような戦いもない。」ドワイト・E・アイゼンハワー
鶴の一声の取り扱い
そのバグ番号(チケット番号)を尋ねる。チケット化されていないものは議論しない。


--
プロジェクト終了後の反省チェックリスト
・メンバー全員の病欠や休暇予定が何らかの形でスケジュールに反映されていたか
・メンバーは好きな時にスケジュールを閲覧、報告できるようになっていたか
・日次、週次ベースで進捗確認する担当者はいたか。調整の権限を持っていたか
・チームはスケジュールを自らのものと感じ、それに全力を傾けようとしていたか？
・チームリーダーは、機能の削減よりも追加に力を入れていなかったか
・目標やビジョンに合わない追加作業の要求に対してノーということを推奨していたか
・見積もりを作成する際に用いた確率は90%？70%？50%？
・定期的にリーダやマネジメント側によるスケジュール調整が組み込まれていたか
・連休や天候がスケジュールに考慮されていたか
・仕様や設計の計画はエンジニアリング側からみて問題なかったか
・優れた作業見積もりを作成するため、エンジニアに何らかの訓練機会を与えたり、経験豊富なエンジニアを採用したか






--
未読：3,4,5,6,15,16

[kaizenさんの感想 · 2011年6月19日]

タイトルのプロジェクトマネジメントと聞くだけで嫌なものだと誤解して、食わず嫌いだった。しかし、アートオブとついているので、管理が技術だという視点からすれば、ちゃんと読めば良かったと後悔している。
第１０章は、特によい。人の仕事の邪魔をしないで、人の助けをするのが管理の基本である。しかし、多くの管理者、管理本は、人の仕事の邪魔をするようなことを平気でやったり書いたりしている。基本を外した本が多いなか、本書は要点を得ているので読む気になる。

飜訳が日本の文化への移転を十分していないのは、外資系の企業だけでなく、日本の企業でもソフト系の企業はカタカナ語が氾濫しているので仕方がないかもしれない。

[とんぴょさんの感想 · 2011年5月10日]

読み始めたばかりです。前回読んだ著者の「パブリックスピーカーの告白」が個人的にツボにはまったので、Berkun氏はいったいどういう仕事をしているヒトなんだろうと興味を持っていました。そう、私はプログラミングの専門家ではないんですよ。私は絵を描くヒト。

この本は買って良かった！もう最初の１ページから（個人的に）オモシロイ。オライリーの棚にありますが、基本的にはビジネス書のくくりかと思われます。（ちなみに、この本は章が始まってからページがカウントされています。「はじめに」も超オモシロイですが、目次と共に、ページ数は数字でカウントされていません）

物作りに関わったり（一人でも大人数でも）、プロジェクトに関わったり（学校の係活動からなんかデカイ構想まで）、そういう経験のある方ならば「あーーーー、うんうん」みたいな？カンジが書籍のそこかしこから香ってきます。

何でこんなに面白く感じるのかうまく説明できません。ささやかな経験から来る懐かしさなのか、単に個人的にツボにはまっているだけなのか、今こういうのが流行ってるからなのか（流行に乗れたことは一度もありませんが）。少なくとも「流行」という点から言えば、「表紙が地味で買いやすい」ので、この点は皆さんに堂々とお勧めします。

また、「プログラミングの知識が無くても読める」点も広くお勧めできるポイントかと思われます。

読み進んでガッカリまたは歯が立たなかったら、書評書き直しますね・・・。

[さよこさんの感想 · 2011年4月18日]

一遍通りプロジェクトマネジメントの本ではないですね、この本。かなり文章がぎっしり詰まっています。おおむねPJの流れが理解でき、PMやPMO経験あるいはPLクラスの人であれば、PJのマネジメントの方法論以外のノンバーバルな部分をしっかりと教えてくれる本という位置づけで読まれるとかなり理解が深まると思います。
　著者のScott Berkunは、以前MS社で仕事をされていた方で、そこで習得したことをわかりやすく丁寧に記述してくれています。MS社の宣伝でももちろんなく、MSで習得したマネジメント方法を自分なりに実践し、その中で自身で積み上げていった経験値をプラスしてレクチャーしてくれています。中でも私が大好きなコンサルタントのトム・ピーターズがでてきたのにはちょっとびっくりしました(笑)。
　この本では、PJマネジメントではなく、コミュニケーション術とは?を問う本であるということがよくわかります。結局、PJの成功はチーム構成とコミュニケーションが十分深くなければ無理なんですよね。『人』がいればいいのではなく、その人がどういう意識でここにいるか・・が問題だといつも思います。
　PMなどの仕事はステークホルダーとの調整や訳わかんないエンジニアとのやりとりであんな仕事は誰もやりたくないと思っている若い人たちが多いと思います。著者も書かれていますが、マネジメントクラスになると、『資質』というものも重要になり、実は誰でもなれるものではないということ、そして、向いている人が必ずいるということがわかります。
　いろいろな意味でこの本は特にIT業界の人でなくても、これからリーダークラスになるかもしれない層の人にもお勧めです。

[quoliさんの感想 · 2011年1月12日]

システム開発のみならず、計画を立てる上で、学ぶことの多い良書。
IEの開発チームのプロジェクトリーダである著者が、様々な角度からプロジェクトを捉え、生きた経験を記述している点が素晴らしい。

この本を大学の時に読んで、特に良かったと思うのが12章から16章で、プロジェクトの指標になることばかりで感服した。
また、読み返してみて、再発見することが多いぐらいのボリュームがあるため、一気に読むより、関心のあるところから読んでいく方がいいかもね。

12章～16章で特に良かった所の抜粋
・リーダーシップが信頼に基づく理由
　権力と言う付与された力に頼らず、信頼をもとに説得する
・物事を成し遂げる方法
　抜け目なく振舞い、場合によっては、正当でないゲリラ戦術も活用すること
・終盤の戦術
　終盤になると苦しくなる理由として、人ではやりたくない物、プログラムのバグでは複雑なものがタスクとして残るため。
・社内の力関係と政治
　必要なものを与えてくれる力を把握し、彼らの観点を理解すること。

目次
1章　プロジェクトマネジメントの簡単な歴史（なぜ気にかける必要があるの
2章　スケジュールの真実
3章　やるべきことを洗い出す
4章　優れたビジョンを記述する
5章　アイデアの源
6章　アイデアを得た後にすること
7章　優れた仕様書の記述
8章　優れた意思決定の行い方
9章　コミュニケーションと人間関係
10章　メンバーの邪魔をしない方法：プロセス、電子メール、打ち合わせ
11章　問題発生時に行うこと
12章　リーダーシップが信頼に基づく理由
13章　ものごとを成し遂げる方法
14章　中盤の戦略
15章　終盤の戦略
16章　社内の力関係と政治

[Hideさんの感想 · 2010年11月23日]

プロジェクトマネジメントについて、PMBOK的な教科書的ではなく、筆者の経験に即した現実的にプロジェクトをどう進めるべきか、一般的にどのような問題がおこってどのように対処すべきかについて記述されています。
プロジェクトマネージャーとしてのキャリアを積もうとしている方は必読だと思いました。