今日紹介する本は「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法―」です。
本書は、著者スコット・バークン(Scott Berkun)が、マイクロソフトに長年プロジェクトマネージャーとして勤務し経験してきたことを、一般化してまとめたものになります。
著者の実体験をふんだんに取り入れて書かれていますので、実感がこもっているところがよいろ思います。
クリティカル分析の仕方やガントチャートの組み方といったプロジェクトマネジメントの技術的手法そのものではなく、プロジェクトマネージャーの心構え、コミュニケーションのとり方、よいアイデアの生み出し方といった、より実践的なスキルについて書かれた本になります。
原著の題名は日本語のカタカナ英訳と同一で「The Art Of Project Management (Theory in Practice (O'Reilly))」です。邦訳の題名には著者の経歴を踏まえて「Microsoft」を入れたのだと思います。
原著の方は新版が発行されていました。ぜひ機会があれば読んでみたいと思います。
「Making Things Happen: Mastering Project Management (Theory in Practice (O'Reilly))」
本書は、優先順位付けの大切さ、ものごとを成し遂げるためには「ノー」といえるようにならなければならない、社内政治から逃げてはいけない、など、私に初めてプロジェクトマネジメントとはどういうものかを教えてくれた思い出深い書籍です。
特に当時の私は社内政治という言葉を毛嫌いしていました。本書の著者の言葉をかりていうならば、
著者は、本書で様々な視点から、どのようにすればよりよくプロジェクトをマネジメントできるかを説明しています。本書で一貫しているのは、方法論よりも信頼・実践という点であると私は感じました。そのことは以下の一文からも読み取れます。
本書は、著者スコット・バークン(Scott Berkun)が、マイクロソフトに長年プロジェクトマネージャーとして勤務し経験してきたことを、一般化してまとめたものになります。
著者の実体験をふんだんに取り入れて書かれていますので、実感がこもっているところがよいろ思います。
クリティカル分析の仕方やガントチャートの組み方といったプロジェクトマネジメントの技術的手法そのものではなく、プロジェクトマネージャーの心構え、コミュニケーションのとり方、よいアイデアの生み出し方といった、より実践的なスキルについて書かれた本になります。
原著の題名は日本語のカタカナ英訳と同一で「The Art Of Project Management (Theory in Practice (O'Reilly))」です。邦訳の題名には著者の経歴を踏まえて「Microsoft」を入れたのだと思います。
原著の方は新版が発行されていました。ぜひ機会があれば読んでみたいと思います。
「Making Things Happen: Mastering Project Management (Theory in Practice (O'Reilly))」
本書は、優先順位付けの大切さ、ものごとを成し遂げるためには「ノー」といえるようにならなければならない、社内政治から逃げてはいけない、など、私に初めてプロジェクトマネジメントとはどういうものかを教えてくれた思い出深い書籍です。
特に当時の私は社内政治という言葉を毛嫌いしていました。本書の著者の言葉をかりていうならば、
政治力(名詞): 邪悪で、弱虫で、自己中心的な人々が利用しようとするものと認識していました。この章で著者(Berkun)の上司がある行動をとったことにより、著者は「政治」に対する認識を大きく改めます(上司がどんな行動をとったかは是非、本書を読んでみてください)。私は、この部分を読んで「政治」に対する自身の認識の未熟さと傲慢さを痛感し、社内政治もしなければ、物事は成し遂げられないと強く思うようになりました。
(399ページ)
著者は、本書で様々な視点から、どのようにすればよりよくプロジェクトをマネジメントできるかを説明しています。本書で一貫しているのは、方法論よりも信頼・実践という点であると私は感じました。そのことは以下の一文からも読み取れます。
プロジェクトマネージャは、プロセスや方法論に注力するのではなく、チームに注力するべきなのです。著者はマイクロソフト出身なので、本書は特にソフトウェア開発系のプロジェクトマネジメントに関わっている方にお勧めです。またソフトウェア開発のエンジニアの方にとっても、本書を読むことで少し違った視点で自分の仕事を見られるようになるのではないかと思います。
シンプルな計画や追跡システムも確かに使用するべきですが、それらはプロジェクトの複雑さやチームの文化に応じたものであるべきです。
計画や追跡システムは、チームがプロジェクトの目標を達成するために役立つものでなければならず、邪魔するものであってはならないのです。
PMがチームに注意を払い、チームの信頼を得ている間は、作業、プロセス、報告書、チェックリスト、その他プロジェクトマネジメントに必要となるものが漏れていたとしても、問題が深刻化する前に自ずと明らかになるのです。
(17ページ)
コメント