世界一わかりやすいプロジェクト・マネジメント【第３版】

著者 : G.マイケルキャンベル サニー・ベーカー 中嶋秀隆

• 総合法令出版 (2011年7月21日発売)

感想・レビュー・書評

[せなかたいさんの感想 · 2013年5月2日]

確かに皆が読んでほしい本
これだけで星４つ

何でもそうだが、現状を抜本的に良くしようとしても、既得権益ややる気のない、判例の虜になった上司に阻まれるもの
縦の列で建設的な積極的な構成を得られたときに発揮できる内容だろう

内容を細かく見ていくと、経験的に頷くことも多い
ただし、事例ではまだ具体性に欠ける
想像しながら、自分でとにかく実行し、昇華、さらなる改善しなくてはならない
そこまでいけたら、気付いたときには取締役、かな

繰り返し読み、自己チエックをしていくぐらいでないと、身につかないほどボリュームがあるので、気軽には手に取らない方が良いだろう

[gsg-9さんの感想 · 2013年2月25日]

なかなか読み応えのある一冊でした。
COMPLETE IDIOT'S GUIDEの名の通り、わかりやすく丁寧に書かれています。
全体の半分近くを計画部分に割いてあるので、ここを読むだけでも価値のある一冊だと思います。
定期的に読み返そうと思える一冊でした。

[ripenessさんの感想 · 2013年2月15日]

PMの基本について網羅的に理解するタイトル通りの内容。

[tomonobumasudaさんの感想 · 2012年8月19日]

確かに分かりやすい。idiotだからか。
エニウェイ、プロジェクトと一口にいっても、楽しい宴会の事務局から、巨大な駅ビルを作ったり、あるいは国防に関するネットワークを構築したりと、参加できるプロジェクトの難度は、技術が躍進すればするほど高くなります。
厄介なのは成果物が目に見えず、顧客とベンダの間の知識に大きな乖離がある場合で、こうしたプロジェクトが突入する悲劇の数々が、本書をはじめプロジェクトマネジメントを体系だてる礎になっているのだと思います。
プロジェクトマネージャを評価するのは、冷酷なまでに唯一成果のみです。それに対してプロジェクトを襲う魔の手の多いことよ！口だけの権力者の介入、前任者が隠しておいた重責、メンバーの離脱（または押し付け）…
金言は数多いですが最も重要なのは「もし、ビジネスケースが消滅したのなら、その理由がなんであれ、プロジェクトは中止すべきである」ではないでしょうか。

[hino4649さんの感想 · 2012年4月12日]

・原題は「idiot's guide = バカでもわかる」という刺激的なタイトル。でも、500ページ近くあるし、結構マジメな本だと思う。内容も実際のプロジェクトの進みに合わせて頭から解説しているので分り易い。

・TOCやクリティカル・チェーンも取り上げられていた。ゴールドラット博士の手法は小説でしか読んだこと無いけど、意外とメジャーなのかな。

・いかにも米国流という考え方が端々に出てくる
　・権限と責任の明確化
　　　→多国籍文化の米国では、役割分担を明確にしないと仕事が廻らないという事情もあるのだろう。日本の場合、逆に曖昧でも廻ってしまうため、担当者に変な無限責任が生じている様に思える。
　・変更は必ず文書で管理する
　　　→この辺も、日本は結構曖昧。馴れ合い文化。
　・組織、ステークホルダ、社内政治などへの対応
　　　→この辺は如何にもアメリカっぽい。

　→思うに米国では個人主義が発達している為、プロジェクトの様な非ルーチンワーク的な仕事を、多数の人と共同で行う場合、実施する作業は出来るだけ細分化、明確化（=WBS）する必要があるのだろう（でないと混乱して収集がつかなくなる？）
　　また、（個人主義の短所をカバーして、）個人をまとめ組織として機能するために、リーダーシップやコミュニケーションの重要性を執拗に強調するのだと思う。この事から、米国人だって、別に生まれながらにリーダーシップやコミュニケーションが得意な訳ではない事がうかがえる。逆に苦手だからこそ、努力しているんじゃないかと、微笑ましく思えてくる。

・本書では、SOWの重要性がすごく強調されている。（正直、初めてSOWという言葉を知った）
・「ＳＯＷ」（Statement of Work、作業範囲記述書）とは､プロジェクトの目標、資源要件、対立、前提条件、権限などをまとめた文書である。プロジェクトを定義し、プロジェクトの計画策定、実行の基礎となる。
・SOWの内容
　†目標文書：プロジェクトで解決を目指すビジネス課題に焦点をあてる。
　†プロジェクト・スコープ：プロジェクトでやらないことも明記する。
　†プロジェクトの成果物
　†目標：成功の判断基準とする。
　†コストとスケジュールの当初見積もり
　†プロジェクトのステークホルダーと指揮命令系統
　†初期評価でのメリットとリスク
　†プロジェクト・マネジャーが設定した前提条件と制約条件

・ＳＯＷの構成
　†目的
　†スコープ
　†プロジェクト成果物
　†プロジェクト目標
　†コストとスケジュールの概算見積もり
　†ステークホルダー名簿　←アメリカっぽい
　†指揮命令系続
　　　・責任分担表（ＲＡＭ）　←こういうの大事
　†効果とリスクの早期評価
　†前提条件と制約条件
　†コミュニケーション計画　←こういう資料も作るのか

・目標にはSMART （Specific=具体的、Measurable=測定可能、Agreed-upon=合意されている、Realistic=現実的、Time-limited=期限が明確）の基準がある。


・プロジェクト計画の建て方
　?WBSを作成
　　・作業を洗い出し、分解する　　大まかな作業→詳細な作業（ワークパッケージ）
　　・1週間以上の作業はより詳細なワークパッケージに分解すると、週間の進捗管理で、作業の遅れなどが把握しやすい
　?ネットワーク図を作る
　　・WBSのワークパッケージの依存関係を把握する
　　・クリティカルパスを見つける
　　・区切りの良い所（ユーザー報告など）にマイルストーンを埋め込む
　?スケジュールを作成する
　　・WBSから作業に掛かる時間、ネットワーク図から作業の依存関係は、既に分かっている状態なので、後は作業を配分するだけ
　　・ガントチャートを作る
　?更新を怠らない
　　・最初の計画通りに作業が進む事はまずない、作業を追加した場合、上記プロセスを繰返し、計画書を更新する
　　　→計画書はプロジェクトの最初の方で作ってそれっきり更新してないなんてことよくある話。

　→なかなか、ここまでちゃんと順を踏んでスケジュールを作る事ってないかも。
　　大体、既に決まった期間（納期）に対して、大まかな作業を当てはめていく事が多いというか…。（細かい作業の洗い出しはある程度工程が進んでから行われるので、もちろん作業漏れは頻発するw）

　→作業が多くなってくると、とてもエクセルでは管理しきれない。
　　プロジェクト管理ソフトを使おう。逆にエクセルでプロジェクトを管理してるから、大雑把な計画しか立てられないのかも。


【プロジェクト成功の12の黄金律】
　　黄金律1:成果物について合意を得る
　　黄金律2:最良のチームを育てる
　　黄金律3:しつかりしたプロジェクト計画書を作り、更新を怠らない
　　黄金律4:本当に必要な資源を判断する
　　黄金律5:現実的なスケジュールを作る
　　黄金律６:できる以上のことはやらない
　　黄金律7:常にヒトを大切にする
　　黄金律8:正式な支援を取り付け、継続して確認する
　　黄金律9:変更を躊躇しない
　　黄金律10:現状を周知する
　　黄金律11:新しいことに挑戦する
　　黄金律12:リーダーとなる


【寓話：最後の手段】　→いわゆるアメリカン・ジョーク。
　新任のプロジェクト・マネジャーが意気揚々と着任すると、前任者が部屋から出て行くのに出くわした。
　前任者が言うには、「3通の手紙を机の引き出しに入れてある。1,2,3と番号をつけておいた。プロジェクトがどうしようもない事態になったら、手紙を１通ずつ開いて中に書いてあるアドバイスに従え」とのことだ。

　数週間後、プロジェクトの状況が悪化し、手に負えそうにない。スケジュールが大幅に遅れ、プロジェクト・マネジャーは経営会議「で釈明しなければならない。困った彼は、会議の前に机の引き出しから１通目の手紙を取り出して開けてみた。すると、そこには、
　「すべて前任者のせいにしろ」と書いてある。
　プロジェクト・マネジャーは会議の席上で前任者を槍玉に挙げ、「あいつのやり方がまずかったから」と説明した。
　経営会議はその説明を受け入れ、期限の延長をしぶしぶ承認してくれた。

　さらに数週間が経って、プロジェクトはまた泥沼にはまった。プロジェクト・マネジャーは経営会議で予算の増額を依頼しなければならない。
　彼は２通目の手紙を開けた。すると、
　「すべてプロジェクト・チームのせいにしろ！」とある。
　これも功を奏して、経営会議は予算の増額を承認してくれた。しかし、「もうこんなことは繰り返さないように」としっかり釘をさされた。

　それから６ヵ月後、プロジェクトは二進も三進もいかない状態に陥った。スケジュールはいよいよ遅れ、予算も大幅にオーバーし、品質レベルは惨たんたるものだ。
　もう失敗は目に見えている。プロジェクト・マネジャーはため息をついて、３通目の手紙を開けた。
　そこに書いてあったアドバイスとは、
　「そろそろ３通の手紙を用意しろ！」


【用語】
・スコープ・クリープ　…作業を少しづつ追加することによって、スケジュールやコストなどの当初の見積もりが全く無意味になってしまうこと


【格言】
「大半の人が成功と失敗は正反対のものと考えているが、その実、どちらも同じプロセスの産物である」　ロジャー・フォン・イーク、「頭脳を鍛える練習帳」

グラハムの法則「あなたが何をしているか知らない人は、何もしていないと思うものだ」-R.」.グラハム、Under-standing Project Management

「創造性を発揮するには２つのやり方がある。自分が歌って踊ることと、歌い手やダンサーに活躍の場を提供することだ」　Ｗ・ベニス、米国南カリフォルニア大学教授


【引用】
・意思決定の役割
　†成果物の仕様と利益を区別する。
　†スケジュールが遅れたら、資源を再配分する。
　†コスト、時間、成果のバランスをとる。
　†「スコープ・クリープ」や予算オーバーを防く。

・メンバーの人選を「時間が空いている」という理由でするのは感心しません。プロジェクトには最良のメンバーを人選し、その人た
ちの日常業務は「時間が空いている」人にやってもらいましょう。
　必要なスキルを持つ人材が社内にいない時は、知識・経験のある外部コンサルタントを活用します。
　→日本では雇用の流動性が低く、かつ社員の質のバラつきが低い為、内部の「手が空いている人」にやってもらう事が多い？

・目標設定のもう１つのカギは、プロジェクトから何を除外するのかを考えることだ。目標設定では最終成果物に何を含むのかについて考えることは多い。しかし、除外項目をリストすることの意味は大きい。

・幸先の良いスタートを切るには、プロジェクトを批判的な目で分析することが特に重要です。

・WBSを作成する際、作業の順序づけや所要期間、予算の見積もりは一切やらないということです。こういうことは、もっと後で行います。

・ネットワーク図
　ステップ１ ：WBS で作業を洗い出す
　ステップ２：作業の依存関係を決める
　ステップ３：マイルストーンを特定する　プロジェクトの節目。WBSの第１レベルをマイクレストーンとしてもよい。


・標準のPERT手法では、作業の所要期間について「可能性が最も高い」見積もりは次の式から算出する。
　　見積所要期間＝［ＯＤ＋4（ＭＬＤ）十PD］÷６
　　　　　　　　　ただし、ＯＤ=楽観値（Optimistic Duration)
　　　　　　　　　　　　　MLD= 現実値(Most LikelyDuration)
　　　　　　　　　　　　　PD=悲観値（Pessimistic Duration）

・プロジェクト計画書を原案の段階で経営陣に見てもらう場合、「原案」「未完」のスタンプを全ページに朱色で押す。完成前の計画書を実行案だと誤解されるのを防ぐためだ。

・予算の古典的誤りを回避する
　†古典的誤り2
　　　WBS（作業分解図）を作らず、プロジェクトに必要な工数（作業量）を把握しないまま、予算額を決定するプロジェクト・マネジャーがいる。ここで問題なのは、プロジェクトの定義が不正確で、プロジェクトでするべきことについて過度に楽観的になる傾向があることだ。正しいやり方とは、まずWBSをワーク・パッケージまでしっかり作り、それから予算を作成することだ。プロジェクトに必要な時間やヒトを把握しなければ、予算と言っても単なるあてずっぽうにすぎない。
　†古典的誤り３
　　プロジェクト・マネジャーがプロジェクトのリスクについて考えない場合がある。つまり、第８章で触れたリスク評価をしっかりやっていない。その結果、リスクに効果的に対処するための予算（やスケジュール）の自由度がない。

・予算作成のその他の情報源
　†社内のモノのコストも計算に入れる。例えば、コンピュータやコピー機、プリンターなど。会社によっては、オフィスをプロジェクト専用で借り上げてはいなくとも、オフィス・スペースを考慮に入れなければならないということもある。

・予備資金を準備する
　プロジェクトにどれだけのリスクがあるのかよくわからない場合、バッファー（緩衝）として予算額の10~15パーセントの金額を別枠で確保し、一種の保険とすることがあります。この「コンテインジェンシー予備」は、プロジェクトでは普通のことです。すべてのリスクを完全に想定し、計算することなどできないからです。


【メンバー】
・上司が部下を教育目的でプロジェクトに参加させたいと言ってくることもあります。将来のために経験を積ませようというわけです。プロジェクト・マネジャーとしては押し付けと感じるかもしれません。しかし、見方を変えると、その上司と何らかの交渉をする必要がある場合、譲歩を引き出すカードを手に入れることでもあるのです。

・メンバーを押しつけられたら
　メンバーの人選やチームの構造を他のマネジャーから押しつけられることもあれば、手が空いているという理由だけでスキルを度外視した人選が行われることも少なくありません。理
由はいろいろありますが、ビジネスでは、メンバーを押しつけられるのはよくあることです。メンバーを押しつけられた場合のリスクは、必ずリスク分析に織り込み、リスクを移転する方策を考えておきましょう。
　メンバーを押しつけられた場合、やりくりする方法がいくつかあります。

　†与えられたメンバーでベストを尽くす。この場合、メンバーを押しつけられたことで問題が発生したら、そのつど必ず文書化する（別名「予防線を張る」と言う）。
　†チームのスキルは不十分だが研修には時間がかかりすぎる場合は、コンサルタントやサプライヤーの活用を検討する。もしその予算がないなら、「スキル要件表」を使って、資金の増額を依頼する。
　†必要な人材を獲得する交渉をする。この本で紹介した作業要件や「スキル保持一覧表」を作り、自分の論点をしっかり文書化しておけば、合理的に考える上司なら話を聞いてくれるはずだ。候補者全員は回してもらえないとしても、優先順位を示すことで、本当に必要な人については交渉しやすくなる。
　†代替案を用意した上で上司と話し合い、こちらの提案を受けてもらえば、チームの効率が上がり、プロジェクトを期限通り予算内に完了させる可能性が高まるという理由を説明する。


・プロジェクト計画書をクロス・チェックする手順
　1.ネットワーク図で、作業、所要期間、日程をスケジュール・ワークシートと突き合わせる。
　2.ネットワーク図で、資源をスケジュール・ワークシートと突き合わせる。
　3.ネットワーク図の作業をWBSと突き合わせる。
　4.予算ワークシートの数字を検証し、再計算して見積もりに合っていることを確認する。
　5.クリティカルパス上の作業を検討する。経路は正しいか？　所要期間がもっと長くかかる作業はないか？　各作業の実施時期に合わせて必要な人員を確保したか？
　6.マイルストーンは重要な期日を示し、作業を要約したものとなっているかを検証する。
　7.開始・終了の期日は依然として妥当か確認する。さらに、休日・休暇をスケジュールに盛り込んでいるかも確認する。 ａ
・見落とされがちな要因
　†スペースと設備：チームの活動に必要なオフィスや製造設備、睡眠をとる場所はあるか？　予算に計上したか？
　†交通手段：日常の通勤以外の交通手段は必要か？　例えば、出張費や宿泊費は予算に計上したか？
　†許可：特定の装置や場所の使用、国境を越える移動などに、文書や口頭による許可が必要か？
　†免許や許可証：危険物の使用、上地建物への立ち入り、政府施設への立ち入り、機密装置・材料の移動などに正式許可が必要か？

・更新
　プロジェクト計画書の中味は相互に関連があります。どれか１つを変更したら、それに合わせて他も変更しなければなりません。例えば、プロジェクト・スコープを変更したら、新たなスコープを成し遂げるために、その影響は実施する作業（ＷＢＳ）やスケジュール、予算、そしておそらくチーム・メンバーにまで及びます。プロジェクト計画書は常に更新しておかなければ、最初の計画がどんなに良いものであっても、無用の長物となります。更新されないままの計画書は未実施事項をまとめた文書にすぎず、将来の指針にはなりません。

・大規模プロジェクトのプロジェクト計画書の目次の例
　1.プロジェクトの要約（プロジェクトの全体像）
　2.プロジェクト目標
　3.前提条件とリスク
　4.マイルストーン
　5.予算
　6. WBS
　7.リスク分析
　8. 資源
　　a.人的資源
　　b.装置や機器
　　c.材料や備品
　9.プロジェクトの組織
　10.実行手順
　11.品質保証基準
　12.連絡先と情報入手先（該当する場合）
　13.プロジェクトの承認

・プロジェクト計画書のプレゼン
　プレゼンテーションでは説明不足も困りますが、細かすぎるのも禁物です。詳細を盛り込みすぎると、細かな点について経営陣から質問や反論を受けやすくなります。承認者が、よくわからない部分の資金の節約を目指し、自説を押し通そうとやっきになることもあります。こういう事態を避けるには、作業をマイルストーンに要約して示し、承認者が全体像を見失わないようにします。会議の時間は短く抑え（例えば１時間）、焦点を絞って進めます。経営陣は１時間以上の会議を嫌がるものです。テキパキと進め、質疑応答と承認の時間を確保します。アンテナを張り巡らせ、プロジェクト・スコープに変更をきたすような質問や意見には注意しましょう。もし会議の中でプロジェクト・スコープが変更されたら、予算やスケジュールにも影響するのです。

・リーダーシップ
　メンバーが問題を抱えあなたに相談する必要があるなら、いつでも解決の手助けをしてくれる存在でなければなりません。言ってもムダと思われて
はいけません。マネジャーは会議に出席し事務処理をこなす役回りですが、リーダーはチームから信頼と尊敬を勝ち取らなければなりません。メンバーには素直
に指示に従ってもらわなければなりません。さもないと、メンバーは自分勝手に意思決定をします。マネジャーとしては、作業が期限通り予算内
で完了するようにルールや管理手順を作らなければなりません。
　†相手の言うことに耳を傾け、多くの質問をする。
　†プロジェクト・チームのニーズに合わせ、信頼できる情報源になる。
　†観察し、記録する。
　†自分の知識の限界を認識する。
　†チーム・メンバーが相談したい時はいつでも応対できる態勢でいる。ある期間、席を離れる時は、メンバーに所在を知らせておく。
　†自分で意思決定をすべき時はそれをする。ただし、上位のステークホルダーに決定を委ねるべき時は、正しく判断する。
　†権限委譲を適切に行う。
　†細かな点にまで口を出す「マイクロマネジメント」はしない。プロジェクト・マネジャーはプロジェクトをマネジメントし、個々の作業のマネジメントはメンバーがする。

・「変革趣意書」を作成する
　多くの場合、プロジェクトの成果物により直接・間接に影響を受ける人は、既知から未知への移行を好まないものです。問題そのものより解決策
の方がひどいものになると恐れるのは、ごく自然のことです。情報技術（IT）プロジェクトのプロジェクト・マネジャーにはおなじみの抵抗です。変革趣意書はこういう懸念に答えるものです。
　1.ビジネスの観点で、なぜわれわれはこのプロジェクトをやるのか？
　2.プロジェクト終了時に、何か変わるのか？
　3.仮にプロジェクトが成功しなかったとしたら、どうなるのか？
　4.われわれとビジネスにとり、このプロジェクトを実施するメリットは何か？
　5.やり方を変える必要があるとすれば、どこか？

・マイクロマネジメントの害
　・専門知識のあるプロジェクト・マネジャーは、とか＜チーム・メンバーの作業に□出しして邪魔をしがちだ。プロジェクト・マネジャーの仕事はプロジェクトの指揮とマネジメントであり、作業のすべての詳細を承認することではないことを肝に銘じておこう。
　・技術力が抜群に高いプロジェクト・マネジャーが問題となることがある。ある時、私たちはスケジュール・コントロールがうまくいかないというプロジェクト・チームの手助けを
依頼された。そこでは、技術力が抜群に高いプロジェクト・マネジャーが問題であった。その人がきわめて有能であるため、彼の承認を得ずには誰も意思決定をしなかった。そこ
がボトルネックになっていた。そして、彼がすべての作業に首を突っ込むことをやめ、プロジェクトのマネジメントを始めると、プロジェクトはスムーズに動き出し、プロジェク
ト・チームも能力に自信を持つようになった。

・計画フェーズでは、自分たちは紙きれを量産しているだけだとチーム・メンバーが不平を言うかもしれません。その時には、その「紙きれ」が実行フェーズで大きな力を発
揮すると言いましょう。

・ある部門にＡさんを指名したのにＢさんを出してよこしたなどです。こちらが望む経験を持つ人を獲得できない場合には、駆出しの役者がセリ
フを憶える期間を見込んでスケジュールを調整しなければなりません。プロジェクトに特定のスキルを持つ人が必要で、ライン・マネジャー（ミドル・マネジャー）が人を出してくれた場合、よほど明確な根拠がない限りその判断を受け入れなければなりません。必要なスキルが当人に欠けていることがあとから判明したら、交渉するか別の方策を探します。
　プロジェクト・マネジャーがプロジェクトにヒトを調達する際には、他のマネジャーにこの種の譲歩をしなければならない場面が多々あります。喩えて言えば、映画製作で主演はショーン・コネリーと契約したのに、エディ・マーフィを代役でよこしたようなものです。当然、シナリオと方向に変更が必要となります。

・プロジェクトのメンバーが真のチームになるには、プロジェクト・マネジャーのコーチングと指導のもとに、いくつかの要件を満たさなければなりません。具体的に挙げてみます。
　†自分か担当する作業には複数の人が関係することを認識する。そこで、作業の完了のためにお互いがコミュニケーションをとり、協力する。
　†プロジェクトの現状についての評価と報告には、共通の方式とツールを使う。
　†問題の特定と解決は共に行い、結果も共に引き受ける。共に意思決定したことは、公の場では支持する。
　†誰かがミスをするとチーム全体が苦労するという事実を受け入れる。そして、ミスはできるだけ少なくするようお互いに助け合う。
　†時間の経過とともにメンバーが入れ替わることを頭に入れておく。ただし、プロジェクト目標とチームの全体構造はプロジェクト完成まで変わることはない。
　†変更が起こることを認識し、変更管理の手法（第24章で詳述）を駆使して柔軟に対応する。

・現状報告書
　コンピュータ・ネットワーク上にグループウェアの報告システムを整え、Iそれを使って関係者に現状報告書やその他の管理書類を提出してもらおう（紙でも同じことができるが、あまり効果的とは言えない)。現状報告書には次の情報を盛り込む。
　†前回の報告以降に完了した作業と期日
　†進行中の作業と完了見込み期日
　†予定している作業と完了見込み期日
　†予算の消化状況
　†注意すべき課題
　†プロジェクトを改善・変更するための推奨案
　†質問点や項目で他のメンバーからの承認や回答を要するもの

・報告書や手順を使い始める前に、次の２点を自問してみましょう。
　†この情報を知らせるのにはこの報告書や手順が最善の方法か？
　†別の方法で、もっと手っ取り早く同じ効果を期待できるコミュニケーションのとり方や打ち手はないか？

・プロジェクト日誌をつける
　会議で記録をとる、プロジェクトの参加者から情報を集める、報告書を作成する……などに加えて、賢明なプロジェクト・マネジャーは個人でプロジェクト日誌をつけることを習慣にしています。プロジェクト日誌には進捗の記録や問題点とともに、プロジェクトにプラスやマイナスの影響を及ぼす課題を盛り込みます。プロジェクト日誌は船長の航海日誌と同じです。１日１ページで日付を付し、プロジェクトの進捗や課題を文書化して残します。そこには、話し合いの論点や、決定事項、行動項目と期限を記録します。さらに、主要な会議の結果、達成事項、対立点やプロジェクトの健全さを脅かす出来事などを盛り込みます。

・ユーザー教育
　ユーザー教育の焦点は「成果物を使うのに、ユーザーは何を“できる”必要があるか？」です。“知る”どできる”の間には、天と地ほどの違いがあります。学習から仕事へ発想の転換が必要です。“知る”だけで十分なら、コミュニケーション計画に含めれば十分であり、ユーザー教育を計画する必要はないことになります。
　基本的に、人が“働ぐのですから、“知る”ではなぐする”に集中すべきです。プロセス変更もあれば、装置やツール、システムの新規導入もあります。ですからユーザー教育には、プロセス変更の情報から一例えばアプリケーション・ソフトの使い方のような一成果物の技術研修までを網羅する必要があります。
　作業委員会の主要ステークホルダーは、T1（製品研修）とT2（作業研修）の２種類を承認しなければなりません。
　†T1（製品研修）：プロジェクト成果物の技術な機能・特徴が中心
　†T2（作業研修）：プロジェクト成果物の“使い方”が中心

・プロジェクトに変更が生じる領域は、次の６つに集約されます。
　†そもそもプロジェクトを立ち上げる原因となった事柄で、プロジェクト目標としてビジネス・ケースの中に文書化したもの
　†プロジェクトに参画するヒト
　†プロジェクトに投入するカネ（予算）
　†プロジェクトを支援するために投人可能なモノや技術資源
　†プロジェクトの完成までに与えられる時間
　†最終成果物に要求される品質レベル

・プロジェクトに進捗遅れや予算オーバー、品質不良などの問題が発生したら、バランスの回復には次の方法があります。
　†作業スコープを削減する
　　プロジェクトを完成させる最善の方法は、やることを減らすことだという時もある。それにより、実現不可能とされていた作業リストを実現可能な（スコープを削減した）ものに転じることができる。
　　この決定をする前に、削減してもプロジェクトに価値があるかどうかを確認しよう。スコープ削減にはステークホルダーからも合意を取り付けなければならない。ステークホルダーが合意しない場合、プロジェクトの成功のために本当に必要なもの一期限の延長、資源の増加、予算の増額-について交渉する必要がある。
　†社内の専門家を活用して生産性を向上させる
　　　生産性には個人差がある。担当者を入れ替えることで、当初のスケジュールやコストを守れる場合もある。メンバーのトレーニングや新技術の導入で、常に生産性の向上を図ることが大切だ。
　†外部資源を活用する
　†時間外勤務を活用する
　　　プロジェクトのある部分を外注（アウトソーシン　グ）し、こちらの指針に基づいて完了してもらう。より生産性の高い外部の専門家に作業を移転することになる。しかし、社内からのコントロールが利かなくなるばかりでなく、外部専門家の能力は実際にやらせてみなければわからない。この点、リスクを伴う。
　†時間外勤務を活用する
　　　時間外勤務は慎重に判断しよう。残業や休日出勤が常態化すると、生産性や士気を低下させ、コストの上昇にもつながる。
　†スケジュールを短縮（クラッシング）する
　　　作業を早めるのに必要なコストの増加額が効果よりも高くっくこともある。

・トレードオフ分析で変更案を比較する
　トレードオフ分析は変更を処理する方法の１つで、複数の選択肢の影響を評価できます。「あれをやめればこれができる。どちらがより重要か？」を判断するわけです。　
　トレードオフ分析をすれば、変更の緊急度も把握できます。　トレードオフを明らかにすれば、どの変更を加えれば、下流の作業やマイルストーンにどんな影響が出るかがわかります。　トレードオフ分析で変更案を比較する際の注意点を列挙します。
　†変更の根本理由を明らかにする。合理的に考えた結果なのか、政治的理由によるのか？　変更には本当に意味があるのか？
　†プロジェクト目標は依然として適切か？　変更によってプロジェクトの最終成果物が変わることはないか？
　†各選択肢がプロジェクトの成功にどう影響するか？　選択肢がスケジュール、予算、メンバーの可用性にどう影響するかは、すでに検討を終えているはずである。変更によって失敗のリスクが高まるのなら、この点を慎重に分析し、関係者に明確に周知する必要がある。
　†選択肢はすべてのレベルで分析する。プロジェクト目標と予算を一定として、変更をどう取り込めるかを評価しよう。どんな選択肢があるか探ってみることだ。取りやめられる作業、期間を短縮できる作業、プロジェクト内での予算の移し替えなどだ。この検討はチームでするのがよい。選択肢を忍耐強く洗い出してみよう。最初に出たアイデアに飛びつくのがよいとは限らない。予算の増額や期限延長の提案は、すべての選択肢を検討した後に行う。

・スコープ変更を伝える
　1.プロジェクト・チームに伝える。変更は時々起こるものであり、チーム・メンバー全員に理解と支援をしてもらう必要がある。プロジェクト・メンバーが公然と、またはこっそり、変更についてぶつぶつ言うことほど、プロジェクトの評判を落とすものはない。
　2.コミュニケーション計画書を検討し、スコープ変更がどのステークホルダーに影響するかを確認する。
　3.変更を台帳に記録する。この章で紹介したプロジェクトと変更要求の書式では、変更の承認は台帳に記録することになっている。後日、プロジェクトとの振り返りをする際、変更記録があればそれをもとに最終報告書を作成できる。

　こういうことすべてには、プロジェクト計画書（ＳＯＷを含む）の更新が必要です。ここまでにも強調してきましたが、計画を変更することは、目標や作業、作業の流れ、スケジュール、予算、ヒトについて変更を加え、それを適切なステークホルダーに承認してもらうことを意味します。変更には備えておきましょう。問題は、変更が起きるかどうかではなく、変更が起きた時にどうするかなのです。

・変更について考える必要がある時は一理由が何であれ一影響を分析し、トレードオフと選択肢を理解しよう。
・課題ログを作成し、すべての課題と解決実績の記録を残そう。あとになってから役立つところが大きい。

・「品質」と「等級」という２つの語は混同されることが多く、それがプロジェクトの足を引っ張ることもあります。例えば、欠陥がほとんどないという高品質のソフトウェア製品が、実は、魅力的な機能が皆無の等級の低い製品ということもあるかもしれません。一方、各種の機能を満載したソフトウェアを手に入れたが、バグが多すぎて放り出したくなるという経験
は誰もがしていることです。その製品は等級は高い（各種機能を満載）が、品質は低い（問題が多発）ことになります。

・90パーセント完了症候群
　時間のロスはあとから取り戻せると楽観的に考えている人が多く、また報告書の中で自分をよく見せようと目論む人もいます。ですから、進捗報告書の「90パーセント完了」という表現は危険信号です。未完の10パーセントの背後に、誰も認めたくない事実が隠れているからです。

・プロジェクト目標が本来の姿より頻繁に変更されると思われることもあります。そうすると、変更のつど、日単位や時間単位で計画し修正する手間を考えたら、計画を更新することなどやめてしまおうという気になるかもしれません。しかし、これは誤りです。計画の更新を怠るのは、プロジェクト破綻への近道です。変更依頼が恣意的に頻発されるとしたら、当初計画への合意が不足しているか、プロジェクトの顧客や依頼者、プロジェクトそのもの、ステークホルダーなどの間に何らかの社内政治の問題が持ち上がっていることを示しています。こういう状況の対処法を挙げておきます。
　†変更の可否を判断する権限をプロジェクト計画書に明記しておく。
　†適切なレベルの経営陣やステークホルダー（顧客や依頼者）の全員から承認を取り付けるまでは、作業を開始しない。
　†変更について分析し影響を文書化するまでは、変更を実施するという約束はしない。その他、第24章で解説した変更のルールに従う。

・もしメンバーのスキルに問題があるのなら、外部のコンサルタントやサプライヤーを活用する手もある。その場合、問題のメンバーはスキルに合う仕事に担当を変える。
　パフォーマンスが不十分のメンバーに外れてもらうのは、ほとんどのマネジャーが後回しにしがちです。ビジネスにおいてプロジェクトの目標達成が優先課題なら、それに沿う扱いをしなければなりません。問題のメンバー（グループ）を個人的に気に入っているとしてもです。

・プロジェクト・スポンサーとの間で、作業範囲記述書（ＳＯＷ）とプロジェクトの完成の必要事項のすべてをはっきり確認しておく。
・リスク分析を入念に行い、プロジェクト・スポンサーや運営委員会とリスク軽減策を話し合う。
・不可能なスケジュールや予算を動かせないものとして、それを達成するには、どんなプロジェクト計画が考えられるか、複数の案を作る。それぞれの案のトレードオフを明確にし、成功確率が最も高い案を推奨する。スケジュールのクラッシングとファスト・トラッキングを検討する。

[miwayyさんの感想 · 2012年1月9日]

実際のプロジェクト（説明のための架空のプロジェクト？）も説明のために例示にいれつつ、プロジェクトの計画から実施、コントロール、終結まで、非常に分かりやすく書かれています。

プロジェクトの定義、計画のフェーズに非常に多くのページをかけており、後半の実行コントロールについては、それらの計画がしっかりと出来ているのを前提にプロジェクトを確実に進めていくという流れになっており、プロジェクトの成功は最初の計画時にかかっているといっても過言ではなく、しっかりした計画を立てることで、後の実行フェーズ、コントロールフェーズをスムーズに回していくことができ、次へのフィードバックへとつなげることが出来るのだということを感じることが出来ました。

1章あたりのボリュームも10数ページ程度でひとつひとつの章がコンパクトにまとまっており、少しずつでもでも読み進めやすい構成になっています。原著は英語のようですが、不自然な英訳もないところも良いです。


総じてＰＭについて、体系的網羅的に、書かれた良書かと思います。
大企業などで、ＰＭのノウハウをきちんと蓄積されている方はひょっとしたら知ってることばかりと感じるかもしれませんが、ＰＭをこれから経験される方や、ノウハウの蓄積がなく、経験と勘で仕事を進めてしまっている方にはリファレンスとして脇に一冊置いておくことをお勧めします。

[ntatsuyaさんの感想 · 2011年10月10日]

【読者】　大規模プロジェクトに初めて立ち向かう新任のプロジェクトマネージャーで、プロジェクト計画・実行の成功要因を学びたいという読者

【目的】　プロジェクト・マネジメントで物事をより早く、より低コストで、よりうまく進め、すべての関係者を幸福にする一連の流れを教える

【一押】　体系的に重要トピックを網羅しており、かつ実際の現場を意識して書かれているため、すぐに使えるアドバイスがある

【概要】　プロジェクト・マネジメントについて、組織構造、焦点の絞り方、弾力的対応、コミュニケーション、コントロールなどプロジェクト・チームを指揮して期限通り予算内でプロジェクトを完了させるための方法を広く紹介する。本書は以下の７つのパートに分かれ、プロジェクトのそれぞれのフェーズで必要な作業に関するアドバイスを提供する。
１．プロジェクト・マネジメントの威力　２．プロジェクト定義フェーズ　３．プロジェクト計画フェーズ
４．プロジェクト実行フェーズ　５．プロジェクトコントロールフェーズ
６．プロジェクト終結フェーズ　７．プロジェクト・マネジメントの効果を上げる組織とソフトウェア
また、以下のプロジェクト失敗の７つの主原因とプロジェクト成功の１２の黄金律を紹介している。
失敗原因１：プロジェクト・マネジメントやプログラム・マネジメントのやり方がまずい
失敗原因２：経営陣からの支援が不足している
失敗原因３：ビジネス戦略に結びつかない
失敗原因４：メンバーのスキルが不足している
失敗原因５：プロジェクト成功の判断基準がない
失敗原因６：しっかりしたリスク戦略がない
失敗原因７：変革をマネジメントできない
黄金律１：成果物について合意を得る
黄金律２：最良のチームを育てる
黄金律３：しっかりしたプロジェクト計画書を作り、更新を怠らない
黄金律４：本当に必要な資源を判断する
黄金律５：現実的なスケジュールを作る
黄金律６：できる以上のことはやらない
黄金律７：常にヒトを大切にする
黄金律８：正式な支援を取り付け、継続して確認する
黄金律９：変更を躊躇しない
黄金律１０：現状を周知する
黄金律１１：新しいことに挑戦する
黄金律１２：リーダーとなる

【感想】　プロジェクト・マネジメントについて学びたい方は、PMPのテキストより前にこちらを読んでほしいと思う。PMについて書かれた本はいくつかあるが、本書は適度の詳しさと実践性、そして読みやすい文章のために参考になる一冊であった。私自身もそうだが、まだプロジェクト・マネジメントを実践する立場になくても考え方を身につけておくと、広い視点でプロジェクトを見ることができるため、成長につながると思う。WBSとネットワーク図の作成方法も参考になった。