『プロジェクトマネジメント標準 PMBOK入門』を読んだ

本 技術

急な秋ですね。
季節が変わるとカジュアルに服を捨てる癖があるため、深刻な服不足に落っている。凍えている。

薄い本を読んだ。メモと感想を書く。

プロジェクトマネジメント標準 PMBOK入門　PMBOK第5版対応版

プロジェクトマネジメント標準 PMBOK入門　PMBOK第5版対応版

なんで読んだのか

シャで新たなプロジェクトをマネジメントすることになった。暗中模索の見よう見まねだったぼくを見かねて、上司氏がオヌヌメしてくれた。神様。

PMBOKの入門書としては定番っぽい。

俺なりのメモ

第1章 プロジェクトに関する基礎知識

  • プロジェクト: 独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務(≠定常業務)
    • 有期性: 明確な開始と終了がある
    • 独自性: いままでに存在しなかった製品やサービスなどを創造するために行われる
    • プロジェクトの成功・失敗は、「スコープ」「スケジュール」「予算」などの制約条件内で、目標が達成されたか否かで判断される
  • プロジェクトマネジメント: プロジェクトを成功させるための活動
    • マネジメントされているプロジェクトは以下を満たす
      • 行うべき作業が開始時までに決まっている
      • 問題が発生した場合の対応方法が明確になっている
      • 進捗や費用の発生状況が逐次監視され、計画からズレた場合は適宜対応される
  • PMBOK(Project Management Body of Knowledge)
    • PMI(Project Management Institute)がまとめたプロジェクトマネジメントに関する知識体系
    • プロジェクトマネジメントに関する言葉の統一によりコミュニケーションミスを軽減できる
  • プロジェクト・マネジャー
    • 権限が組織によって大きく異なるため、プロジェクトごとに明確にしておく必要がある
    • 最低限守るべき振る舞い: 動揺しない、傲慢にならない、学ぶことを怠らない
  • プログラム: 複数の関連するプロジェクトや作業などを含む全体的な活動 - 会社が最終的に求めているものは、成果物ではなくその効果である
  • ポートフォリオ: 戦略的なビジネス目標を達成するために行う、プログラムやプロジェクト、作業などの集合

第2章 PMBOKの基礎知識

  • ステークホルダー: プロジェクトに積極的に関与している人や組織、またはプロジェクトの実行や完了により自らの利益に影響が出る人や組織
    • スポンサー/プロジェクトマネージャー/プロジェクトマネジメント・チームなど
  • 成果物: プロジェクトで作成する測定可能な成果や結果
  • プロジェクトマネジメント・プロセス: プロジェクトの目的を達成するために実行する一連のアクティビティ
  • プロジェクト・ライフサイクル
    • すべてのプロジェクトは、「プロジェクトの開始」→「組織編成と準備」→「プロジェクト作業の実施」→「プロジェクトの終結」というライフサイクルを持つ
    • その過程で、要員数、リスク、変更・訂正のコストなどは変化する
  • プロジェクトフェーズ
    • 長いプロジェクトを分割し、それぞれに成果物を定義する
  • PMBOKでは、各プロセスを、作業の位置づけにより、5つのプロジェクトマネジメント・プロセス群に分類している
    • 立ち上げプロセス群: プロジェクト憲章作成
    • 計画プロセス群: プロジェクトマネジメント計画書作成
    • 実行プロセス群: プロジェクト作業の指揮・マネジメント
    • 監視プロセス群: プロジェクト作業の監視・コントロール、統合変更管理
    • 終結プロセス群: プロジェクトやフェーズの終結
  • PMBOKでは、各プロセスを、マネジメントの対象により、10の知識エリアに分類している
    • プロジェクト統合マネジメント: プロジェクトの始まり、終わり、進め方をどうすればよいか？
    • プロジェクト・スコープ・マネジメント: 必要な成果物・作業はなにか？
    • プロジェクト・タイム・マネジメント: 限られた資源や制約の中で厳守できる期限はいつか？
      • 所要時間の見積もり法として、類推見積もり、パラメトリック見積もり、三点見積もり、クリティカルパス法などがある
    • プロジェクト・コスト・マネジメント: プロジェクト完了時までにかかるコストは？
      • コストの見積もり法として、類推見積もり、ボトムアップ見積もり、パラメトリック見積もりなどがある
      • アーンド・バリュー・マネジメント(EVM): 相互に関連するプロジェクトのスコープ、コスト、スケジュールの実績測定の結果を統合し、プロジェクトの現状や将来の見込みについて評価する手法
    • プロジェクト品質マネジメント: 要求された品質を実現するには？
      • 品質は計画、設計、作り込みにより達成されるものであり、検査によってではない
      • 顧客満足のためには、要求事項への適合性に加え、使用適合性が必要となる
      • QC7つ道具: 特性要因図、管理図、フローチャート、ヒストグラム、パレート図、チェックシート、散布図
    • プロジェクト人的資源マネジメント: 要員を調達し、活躍させるには？
    • プロジェクト・コミュニケーション・マネジメント: いつ、どんなプロジェクトの情報を収集し、配布すればいいか？
    • プロジェクト・リスク・マネジメント: 万が一に備えていつなにをすべきか？ - プロジェクト調達マネジメント: 外部リソースの利用をどのように決めるのか？
    • プロジェクト・ステークホルダー・マネジメント: ステークホルダーへの対応でプロジェクトにプラスの影響をもたらすには？

第3章 計画フェーズ

  • プロジェクト・マネージャーの役割: 全体像をつかむ
  • 作業手順
    • 目的確認: 文書化することが重要である
    • 計画の作成: ステークホルダーの話を整理し、スコープを定義し、開発の方針(技術、運用、移行など)を決める
      • 成果物をもとに、WBS(Work Breakdown Structure)で細かい成果物単位に分割する
      • 作業項目洗い出し→作業順序確認→スケジュール/コスト見積もり→体制検討→品質マネジメント計画→コミュニケーション・マネジメント計画→リスクマネジメント計画/実施
    • 承認: 計画書をもってスポンサー、ステークホルダーと合意する

第4章 要件定義フェーズ

  • プロジェクト・マネージャーの役割: 大枠を決め、環境を整備する
  • 作業手順
    • 開始前: プロジェクト・チーム・メンバーに計画書の内容を説明するkickOff会議
    • 作業中: 進捗確認、リスクの管理/回避、メンバーの後方支援、ステークホルダー対応
    • 作業後: 次フェーズに向けて各種体制や計画の修正
    • 承認: スポンサーやステークホルダーに対して要件定義を踏まえたプロジェクト計画書を説明し、合意する

第5章 設計・開発フェーズ

  • プロジェクト・マネージャーの役割: 生産性向上に寄与する
  • 作業手順
    • 開始前: プロジェクト・チーム・メンバーに対して、現在の状況と今後の作業、成果物の品質チェック事項について説明する
    • 作業中: 実行指揮・監視コントロールとリスク・マネジメント、定期的な品質チェック、メンバーの後方支援/調整、変更対応
      • 自身及びメンバーの健康管理
    • 作業後: 次フェーズに向けてWBSや作業項目の見直し
    • 承認: スポンサーやステークホルダーに対して説明する
      • スケジュール遅延やコスト増大あれば報告し、理解してもらう

第6章 テスト・移行フェーズ

  • プロジェクト・マネージャーの役割: 確実に作業を進める
  • 作業手順
    • 開始前: プロジェクト・チーム・メンバーに対して、現在の状況と今後の作業について説明する
    • テスト作業中: 実行指揮・監視コントロールとリスクマネジメント、コンティンジェンシープラン、品質チェック、バグ発生時の情報伝達/調整、変更対応
    • テスト作業後: 次フェーズに向けてWBSや作業項目の見直し
    • 承認と移行判定: スポンサーやステークホルダーに結果と移行のリスクを説明し、移行を予定通り行うか判定する
    • 移行実施: 計画通りに、着実に

第7章 運用・保守フェーズ

  • プロジェクト・マネジャーの役割: 障害を迅速に把握し、対応の手配をとる
  • 作業手順
    • 開始前: プロジェクト・チーム・メンバーに対して、気を抜くな、なにかあれば即報告してほしい旨を伝える
    • 作業中: 実行指揮・監視コントロールとリスクマネジメント(バグ対応優先)、メンバーの後方支援/調整、変更対応
      • ユーザが慣れてないだけなどあるため、仕様変更は慎重に、まずは安定稼働を優先
    • プロジェクト終了: 終了報告、反省会

思ったこと

定番入門書と言われるだけあり、網羅的かつ丁寧な説明でわかりやすかった。第1章、2章は言葉の定義やPMBOKの全体像について書かれている。自分の場合は自身のプロジェクトに当てはめて認識できたからよかったが、もしそれがなかったらかなりしんどかった気がする。そういう場合は、先に第3章から読み始めたほうが良いかもしれない。具体的なプロジェクトの例にそって説明されている。

最後の付録で、本書を理解しているかのテストがあるのだが、その内容がけっこうおもしろい。家族での海外旅行をプロジェクトと見立てて、夫がプロジェクト・マネジャー、妻子をプロジェクト・チーム・メンバーとしている。他にも様々な例があり手厚い。個人的には、思い出して別の状況に当てはめるという作業がかなり理解を助けると思っている。

本書を読んだ感想と普段の実感を踏まえ、コードを書き始めた時点で開発は終わっている感をひしひしと感じている。弊社がそうというわけではないが、一般的に、プロジェクトの開始時点でできること/やるべきことを怠った結果、それがプロジェクト後期において致命的なダメージになることが多そう。具体的には、プロジェクトの目的とステークホルダーの定義、スコープと計画の策定あたり。

流し読みになった箇所や消化不良も多々ある。というかほとんど。幸いにも機会があるため、プロジェクトにあたる中で身にしていきたい。闇雲に機能の実装にあたるのではなく、リスクを盛り込んだ計画を作成し、プロジェクトの状況を把握し、マネージされるべきものをマネージするなど、プロジェクト成功に向けた意識して頭を使いたい。マネをジメントしていくぞ。

会社が最終的に求めているものは、成果物ではなくその効果

それな。