【読書log】図解入門 よくわかる 最新 PMBOK第7版の活用：第7章 計画パフォーマンス領域

読書log

最近読み進めている「図解入門 よくわかる 最新 PMBOK第7版の活用」の第7章です！

私が特に勉強になったと思った内容と個人的な感想を、備忘録としてまとめています。

あくまでも備忘録なので、詳しく勉強したい方は実際に書籍を手に取ってみてください🙇‍♀️

第7章 計画パフォーマンス領域

7-1 領域の概要と活動の目的

  • 期待される成果は以下の6つ
    1. プロジェクトは、組織化され、調整され、計画的に進む。
    2. プロジェクトの成果を提供するための総合的なアプローチがある。
    3. プロジェクトの進展に伴い、実施目的である成果物や成果を生み出すために、情報は詳細化される。
    4. この状況に見合うだけの時間を計画に費やす。
    5. 計画は、ステークホルダーの期待をマネジメントするのに十分である。
    6. 新たなニーズ、あるいはニーズや状況の変化に基づいて、プロジェクト期間を通じて計画を適合させるプロセスがある。
  • 計画の目的は以下の2つに大別される。
    • プロジェクト成果物を作成するための手法を決める。
    • 進捗を評価する基準を決定める。
  • プロジェクトの規模や特性に適した方法を計画に反映させる。
    • 一つとして同じプロジェクトは存在しない、という前提で計画する。
  • 計画の主な要素
    1. デリバリー
      • 要求事項を適切な作業単位に分割する。
    2. 見積り
      • プロジェクトの進行に伴い、見積もりが変更されることがある。
        • 見積りは本質的に不確かなので、リスクとしてマネジメントする必要がある。
      • 日本のビジネス慣行では、「確定見積り」として約束事になっている。
      • 三点見積り法の精度は、ベータ分布の方が三角分布よりも高い。
    3. スケジュール
      • プレシデンス・ダイアグラム法
        • 図7-5 論理的順序関係：FS・FF・SS・SFの各タイプ
          • リード（作業間の重複期間）と、ラグ（作業間の空白期間）を活用して、最適化する。
        • 図7-6 ネットワーク図の例：所要時間を考慮してクリティカルパスを算出できる
      • クラッシングでは予算に対するリスクを考慮する必要がある。
        • 人員を追加することで解決するのかを精査する必要がある。
      • ファスト・トラッキングでは、作業順序を変更するので、幅広い内容のリスクを考慮する必要がある。
        • アクティビティ間の依存関係を考慮する。
      • 適応型のスケジューリングは、⑥にスクラムを例にして解説されている。
    4. 予算
      • コスト・ベースラインを基にして、特定の予算期間に承認されている資金と予定されている作業のバランスを取る。
    5. プロジェクト・チームの編成と構造
      • メンバーのトレーニング計画も必要である。
    6. コミュニケーション
      • ステークホルダー・パフォーマンス領域とも重複するが、コミュニケーション計画が大事。
    7. 物的資源
      • 「人」以外の資源を指すので、ソフトウェアやライセンス等も含む。
    8. 調達
      • 調達計画の基盤は契約である。「図7-12 調達活動」を参照。
    9. 変更
      • 正当な理由があれば対応するが、全ての変更要求に対応するわけではない。
    10. メトリックス
      • 重要なことだけを測定する。
      • ベースラインからの際の許容範囲を決める。
        • 納期目標の場合は、しきい値分早く設定する。
        • コスト・ベースラインの場合は、しきい値上限で予算を申請する。
    11. 整合
      • プロジェクトの進捗に合わせて、資料類を最新化して、資料間の整合性を取る。
  • プロジェクトを通しての活動であり、計画と調整を扱う。

7-2 活動結果の評価

  • 評価項目の例
    • 段階的詳細化を示す文書類が構成管理されている。
    • 計画内容が、ステークホルダーにとって分かりやすく、最小限の量である。
    • 予測型では堅牢な変更管理プロセスが構築されており、適応型ではプロダクト・バックログが継続して洗練されている。

所感

期待される成果の6項目目が非常に重要だと感じました。ウォーターフォール型の場合、追加要求を元々の納期に無理矢理ねじ込もうとするマネージャーもいますが、確実に炎上（or 間に合うがメンバーがブチ切れ）しますしね。

デリバリーに関しては、タスクの分割をおろそかにしてしまい、作業量が大きいまま着手してしまうこともあります。結果的に終わっているから良いものの、担当者の作業負荷も大きいし、他のメンバーもそのタスクの状況や進捗を把握しづらくなるので、しっかりと分割したいです。

今のプロジェクトではありませんが、人を追加すれば遅延が解消するみたいな価値観の人は、昔はそこそこいたような気がします。特に、開発現場を知らないマネージメント層や営業部員などに多かったイメージです。

良いサービスを提供したいあまり、変更要求に過剰に対応してしまい現場が疲弊する、ということは稀に良く発生しますね。過去に非常に大変な思いをしました。遅延しているけどみたいに責められましたが、スコープ外だろと笑。
気持ちはわかりますが、そこを上手に調整することが腕の見せ所なのかもしれません。

炎上案件だと、進捗管理資料が放置されがちですね。裏を返せば、うまくいっていないプロジェクトを判別する基準の一つになりえます。

書籍全体として、ちょくちょく誤字はありそう。

以上

タイトルとURLをコピーしました