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