第１８回「４８のキーワードから学ぶ実践プロジェクトマネジメント」（深沢隆司著）

ＰＭＢＯＫとも併用すれば、より勉強になると思います。
著者の経験から言える注意点も参考になります。
この本に興味を持てば→
幹は５つ。
１．立ち上げ

仕様策定：顧客やＰＥの不安感を排除する様に心がける（具体的なものに）
プロジェクトマネジメント：バランスをとる仕事＝必ず一歩引いたところから全体状況を観察する
現場主義の徹底：一次ソース（情報発生源）からの直接情報が必須
プロジェクトの目的：システムを稼動した結果得られる利益
意思プロセスの明確化：何を基準に「決まった」とするかをはっきりさせておく
問題点：早い時期に代替案作成、顧客担当と話しあうサイクルの作成
システム開発の品質を落とす要因：設計漏れによる仕様修正、マネジメントの質の低さからくるモチベーションの低下
リスクマネジメント：リスクに気付くことが最も重要
日頃からものごとの本質を見極める
プロジェクトの初期段階で顧客との協力関係を築く
予想される状況：受注前に伝える、協力のための手続きを早く決める
不確定要素：実現可能性、影響範囲、期限、承認手続きなどの対処方法を明確にする
システム設計までの間：仕様変更ゼロ、ドキュメントミスゼロ、設計どおり完成したあとの顧客の不満ゼロを目指す
（ドキュメントの書きやすさより）プログラムがどれだけ作りやすいかが重要→ＰＥに聞く
問題点を隠すこと→良いアイデアや、得られたはずの協力も逃す
プロジェクト憲章：ＰＪの存在意義や目的、ＰＭの選定、権限、責任、成果物の明確化
ドキュメントに要求されるもの：内容、簡潔な表現、１００％を目指したもの（プログラムのバグよりドキュメントのバグ）
前提条件：何が前提条件かを気付くことが重要、繰り返しミーティングの議題とする（←自分の都合の良いように解釈させない）

２．計画

スコープ：プロジェクトにおける仕事の範囲
成果物スコープ：開発対象、開発対象範囲
プロジェクト・スコープ：開発作業範囲
顧客の理解を得たあとも、理解した内容を何度も確認することをあらかじめ顧客にも理解していただく。何度も同じ話をすると顧客が怒り出すのではないかと恐れていると開発は進まない。
マネジメントや交渉→プログラムのソース・コードの１行１行に関わってくる
プログラムを作ること自体が仕事ではなく→成果物から得られるサービスを提供することが仕事
スコープ記述書：プロジェクトで求められていることをすべて記述→記載されていないことは実施しない
「言わなくてもわかるだろう」→通用しない
直接実装を行うプロジェクトの進捗→０−１００％で計測すべき
進捗管理で必要なこと＝「いつ終わるか」ということ
ＰＭの仕事：必要なときまでに返答してもらえるように働きかけること
回答がきていないからその件は後回し→ＰＭがこの様な返答をすること＝仕事をしていないと言うこと
役割や作業割り振りが不明確→作業効率のモチベーション低下を招く
ＲＡＭの作成＝プロジェクト成功のカギ
品質方針：成果物の品質に影響を与える問題にどのように対処するかを明文化し承認を得る
バグゼロ、プログラムとドキュメントの非同期ゼロ：ＰＥの不要な労力や迷い原因と取り除く→ドキュメントの品質
トラブルゼロ、仕様変更ゼロ：情報はできるだけ早く正確に伝える、誤解のない表現、業務分析は現場主義で徹底的に・詳細に表現
納期どおり、コスト内：できないことはできないと伝える、交渉力でコントロール、「ビジネスは、小さく約束して、それ以上のものを提供することが鉄則」
リスク識別：プロジェクトに影響を及ぼす可能性のあるリスクを見抜き明文化する
前提条件が前提どおりに行かないこと＝リスク
リスクの洗い出し後→全体を眺め、どのように進めるかを決める
該当するリスク：チームで認識
期待される結果を意識する→今誰が何の作業をして、いつまでに何を作らなければならないのか、今何が必要か、具体的に考える
ＳＯＷ（作業範囲記述書）：発注内容を詳細に記述したもの

３．実行

Win―Winの関係を目指す
現場訪問：つらい作業であるが、これを実施しないとより深刻な状況を招く
現場主義：憶測で考えない、現場を確認する
現場を見ることができない＝プロジェクトにとって重大なマイナス要因
不安感：プロジェクトをうまく進めるために最も重視すべき感情、プロジェクトや成果物の品質を左右する
なぜ不安に思うのか、その原因を冷静に考え、広い視野で捉える
不安に感じること：「何が」「どうして」不安か、その根幹を考える
会議前：できるだけシミュレーション
顧客が求めているもの：安心感、そのために必要な情報を伝える
会議：議事録を作成するためにある＝会議をコントロールできる人が書記を担当、結論がでたら都度議事録に記載、記載後に誤解がない記述か確認してもらう、参加者全員が納得できる表現になっているか確認し次へ、記載中に次へ進みそうになる場合は中断してもらう
作業場所の終結：終結していれば楽になると期待しない、終結しているがゆえにいい加減になることもある
作業場所終結の効果を得る：役割分担の明確化、成果物の期限が明確、成果物で評価、個人の目的達成が全体の目的達成へ
プロポーザル：外部から資源（リソース）を調達する際、発注元の要求に従って提示する文書
引合い：発注先候補からプロポーザルの回答を得ること
調達計画：外部から購入しようとしているモノやサービスを識別すること
引合計画：各種調達文書類を作成し、入札資格を有するベンダーを審査するプロセス
品質向上→作り方の質を向上させる
PMの成果物：プロジェクトにおける行動のすべてと捉える
マネジメント：質の高い成果物を生み出すための、質の高いマネジメントとは何かを考え、それを実現するための行動すべて
上流工程に関わる人：仕様変更ゼロを目指す
マネジメント層：使うことと作ることに焦点をあててプロジェクトが進んでいるか常に見直す
変更ゼロの設計を目指す→なぜ変更要求が発生したのか、その原因をよく考える
ステークホルダーとの事柄の共有：顧客の現場をしっかり見る、顧客と開発とのコミュニケーションの時間を十分取る→実行に移す←しつこく感じられる確認作業の実施

４．コントロール

「今さら言ったら怒られるかもしれない。もう言えない。」という判断→絶対しない
プロジェクトの前提も定期的に見直す
EVM：プロジェクトの進み具合を金額で表現する、より正確に進捗把握できる、進捗を数字で伝えられる
スケジュール・コントロール、コスト・コントロール、品質管理、スコープ検証（納品検収にあたる作業）、教訓

５．終結

完了手続き：計画していた目標が達成したという承認をとること
契約完了：契約対象であるサービスがすべて完了したことを確認し文書化すること

気付き
PMBOKに関連して記載されており、PMBOKを一通り読んでいる人には、より理解しやすい。
著者の経験から得られたと思われる具体的な注意事項も参考になる。
現場を確認することの大切さ、コミュニケーションの大切さ、そのための仕組み作りの必要性を再認識させてくれる。
PM（プロジェクトマネジャー）は、強い決意を持つこと、１００％を目指すこと、不安感に気付いてその本質を考えることが、いかに重要かを認識する必要がある。
　
読みやすいのですが、エッセンスも多く、ボリュームもそこそこある本です。後半はマインドマップ作成も息切れしました。