Skip to content

DNET_PMPInitiating

nishi_74322014 edited this page Sep 11, 2026 · 1 revision

PMP:立上

  • 戻る(PMP)

概要

立上プロセスの主要な役割

プロジェクトを承認し、資源をプロジェクトに割り当てる権限をPMに与える。

プロジェクトの開始点

マネジメント・スキル

  • コミュニケーション

    • 経営陣
    • スポンサー
    • ステークホルダー

インプット・アウトプット(ITTO)

各項目の詳細は、それぞれのページの該当節を参照。

# プロセス インプット ツールと技法 アウトプット 知識エリア
1 統合
プロジェクト憲章作成
★プロジェクト作業範囲記述書
・ビジネス・ケース(6)
★(p) プロジェクト・マネジメント・ビジネス文書(6)
  (p) プロジェクト・ビジネス・ケース
  (p) プロジェクト・ベネフィット・マネジメント計画書
★合意書
----------
・組織体の環境要因
・組織のプロセス資産
・専門家の判断
・人間関係とチームに関するスキル
  ・ファシリテーション技法
  (p) コンフリクト・マネジメント
  (p) 会議のマネジメント
・データ収集
  (p) ブレーン・ストーミング
  (p) フォーカス・グループ
  (p) インタビュー
★プロジェクト憲章
(p) 前提条件ログ
プロジェクト統合マネジメント
2 ステークホルダー
ステークホルダー特定
★プロジェクト憲章
★(p) プロジェクト・マネジメント・ビジネス文書(6)
  (p) プロジェクト・ビジネス・ケース
  (p) プロジェクト・ベネフィット・マネジメント計画書
(p) プロジェクト・マネジメント計画書
  (p) コミュニケーション・マネジメント計画書
  ★(p) ステークホルダー・エンゲージメント計画書
(p) プロジェクト文書
  (p) 変更ログ
  (p) 課題ログ
  (p) 要求事項文書
・合意書
・調達文書
----------
★組織体の環境要因
★組織のプロセス資産
★専門家の判断
(p) データ収集
  (p) アンケートと調査
  (p) ブレーン・ストーミング
  (p) ブレーン・ライティング
(p) データ分析
  ・ステークホルダー分析
  (p) 文書分析
(p) データ表現
  (p) ステークホルダーのマッピングや表現
・会議
★ステークホルダー登録簿
(p) 変更要求
(p) プロジェクト・マネジメント計画書更新版
  (p) 要求事項マネジメント計画書
  (p) リスク・マネジメント計画書
  (p) コミュニケーション・マネジメント計画書
  ★(p) ステークホルダー・エンゲージメント計画書
・プロジェクト文書更新版
  (p) 前提条件ログ
  (p) 課題ログ
  (p) リスク登録簿
プロジェクト・ステークホルダー・マネジメント

プロジェクトの発生

立上とは

以下を公式に承認する。

  • 新規プロジェクト、既存プロジェクトの次フェーズが開始されること。
  • 資源を上記の開始されたプロジェクトに投入する必要があること。

ニーズと要求

立ち上げの要因についてはPMP:共通の該当節を参照。

ニーズ評価

フィージビリティ・スタディ

プロジェクトが実行可能であるかどうかを判断する。

  • 目的
    成功する確率を求める。

    • 市場性はあるか?

    • ヒットするか?

    • 技術面で

      • 実現可能か?
      • 信頼性は高いか?
      • 既存体制への組み込みが可能か?
  • 実施
    義務付けている組織もある。

    • タイミング

      • 別プロジェクトとして実施
      • サブ・プロジェクトとして実施
      • 第一フェーズで実施
    • 実施チーム
      プロジェクトに携わらない(偏見の無い)チームが実施する。

    • 評価
      会議を実施

      • 顧客
      • スポンサー
      • 専門家
      • PM(※ 役割に含まれないが参加することはある。)

※ 「初めての試み」などの場合は、特に重要になる。

プロジェクト選定と評価

選定プロセスは、フィージビリティ・スタディと同様に、

  • PMの責務は無い。

  • 以下に責務が有る。

    • 顧客
    • スポンサー
    • 専門家

評価プロセス

  • 組織の大半は、選定、優先度付けに関する
    公式、準公式の評価プロセスを持っている。

  • 例

    • 会計年度の始まる前の予算立案時期に
      選定委員会はプロジェクト案の提出を求める。

    • 書面には、以下が記載される。

      • ハイレベル概要(PMP:共通の該当節を参照)
      • 成果物(プロダクト / サービス / 所産)(PMP:共通の該当節を参照)に関する記述
      • ビジネス上の存在理由
      • 望ましい成果物(プロダクト / サービス / 所産)の導入日
      • プロジェクトにより組織が得るもの。
        (影響を受ける機能部門リストと、費用便益分析)
    • 評価
      会議を実施

      • 顧客
      • スポンサー
      • 専門家
      • PM(※役割に含まれないが参加することはある。)
    • 優先度付けされる。

      • 重要性
      • 利益
    • プロジェクト・リストに追加される。

      • 正式に文書化される。
      • 選定委員会に、月次進捗報告を行う。

プロジェクト評価方法

下記の要因でプロジェクトによって評価手法は異なる。

  • 会社

  • 選定委員会のメンバ

    • 上級管理職
    • 中間管理職
  • 選定の基準

    • 財務的基準
    • 営業的基準
    • 社会通念
    • 政治的見解

プロジェクト選定手法

  • 以下を測定して選定する。

    • 測定の対象
      プロジェクトの産み出す成果物(プロダクト / サービス / 所産)

      • の価値
      • が組織に与える利益
    • 測定の軸
      経営者の戦略的目標とのマッピング

      • マーケットシェア
      • 金銭的利益
      • 投資収益率
      • 顧客維持率
      • 顧客忠誠度
      • 社会通念
  • プロジェクト選定手法
    プロジェクト選定手法には、以下の2つ区分がある。

    • 数学的モデル(算定技法、制約条件付き最適化法)
      工学、統計学、数学の知識が必要。以下のアルゴリズムを使用する。

      • 線形計画法
      • 動的計画法
      • 整数計画法
      • 非線形計画法
      • 多重目的計画法
    • 利益測定法(意思決定モデル)

      • 成果物(プロダクト / サービス / 所産)の利点・利益を検討する。
      • 大半のプロジェクトでは(、数学的モデルではなく)、こちらを採用する。
      • 費用便益法、得点モデル、キャッシュ・フロー分析手法などがある。
      • 大規模・複雑なプロジェクトでは複数の利益測定法を組み合わせて使用する。

プロジェクト・マネジメント・ビジネス文書(6版)

  • ビジネス・ニーズを理解し投資に価値があるかを判断するための文書。

  • 承認

    • プロジェクト憲章作成プロセス開始のきっかけになる。
    • 承認アクティビティは、プロジェクト外部で行われる。
  • 用語

    • シーズ(種)
    • ---> ニーズ(想い)
    • ---> ウォンツ(意欲)
    • ---> デマンド(需要)
    • ---> ベネフィット(提供された価値)

プロジェクト・ビジネス・ケース

ビジネスの理解

ビジネス・ニーズ評価を行い、

  • 目的
  • 目標
  • 課題
  • 好機

などをまとめる。

提案の文書化

経済的な実現可能性検討を文書化したもの。

プロジェクト・ベネフィット・マネジメント計画書

概要(ベネフィット・マネジメント計画書)

プロジェクトから得られるベネフィットを

  • 創出
  • 最大化
  • 持続

させるための、プロセスを定義した記述書。

主要要素

  • 目標ベネフィット
  • 戦略との整合性
  • 時間枠(短期/中期/長期)
  • ベネフィット・オーナー
    (プロダクト・オーナー)
  • 評価尺度
  • 前提条件
  • リスク

プロジェクト憲章作成

インプット(プロジェクト憲章作成)

プロジェクト作業範囲記述書

プロジェクト作業範囲記述書 = プロジェクト SOW(Statement Of Work)

  • 作成者

    • 内部プロジェクト

      • 組織内部で発足するプロジェクト
      • スポンサー
    • 外部プロジェクト

      • 契約に基づくプロジェクト
      • 購入者(プロジェクトをPMに発注した顧客)
  • 記述内容 : 成果物(プロダクト / サービス / 所産)

  • 考慮内容

    • 戦略計画を考慮する。
      企業の戦略計画とプロジェクトの関係

    • ビジネス・ニーズを考慮する。

    • プロダクト・スコープ記述書
      (PMP:計画 - 範囲の該当節を参照)を考慮する。

プロジェクト・マネジメント・ビジネス文書(インプット)

プロジェクト・マネジメント・ビジネス文書(6版)

合意書

  • プロジェクトの意図を定義した=合意書が、
    実施条件や、期間、作業、などの記述のために利用される。

  • 合意書には以下のものがある。

    • 法的なもの

      • 契約(書)
      • NDA(秘密保持契約)
    • その他

      • 了解事項の覚書(MOU)
      • 電子メール
      • 政府間協定
      • 口頭約束

組織体の環境要因

PMP:環境の該当節を参照。

組織のプロセス資産

PMP:環境の該当節を参照。

プロセス(ツールと技法)

専門家の判断

  • 多数のフェーズ、プロセス群でも、ツールと技法として使用される。

  • 主に、インプットの評価を行う。

  • 専門家(個人/グループ)

    • プロジェクト・メンバ(ステークホルダー/コンサルタント、過去のチームメンバ)
    • 組織内(組織内の他部門、PMO、・・・)
    • 組織外(当該分野専門家、業界の専門家、専門家集団、技術機関)

ファシリテーション技法

多数のフェーズ、プロセス群でも、ツールと技法として使用される。

  • ブレーンストーミング
  • コンフリクトの解消
  • 問題解決
  • 会議のマネジメント

主要なステークホルダー

主要なステークホルダーを早期に特定して、
プロジェクト憲章作成に参加してもらう。

  • プロジェクトマネージャー

    • プロジェクトの成功に対して責任を負う人。

    • できるだけ早い段階で特定すべき。
      (プロジェクト憲章作成には参画すべき。)

    • ただし、プロジェクト憲章の作成に参画しても、作成者の欄に、
      記名しない(作成者が自身に権限付与することになるため)。

    • プロジェクトの計画後に各作業を実行しマネジメントする。

      • プロジェクトの標準と方針を設定し、プロジェクト・チームとステークホルダーに伝える。
      • コミュニケーションと文書に習熟し、関係者に情報を絶えず提供する。
        文書:要求事項、コスト、アクティビティ、パフォーマンス評価の尺度
        関係者:プロジェクト・スポンサー、プロジェクト・チーム、その他。
    • 機能部門マネージャ に協力して支持を得る。

  • プロジェクト・スポンサー

    • プロジェクト・スポンサーも一般的なスポンサーと同様に、
      ステークホルダーと経営陣の支持を取り付け、強力な推進者となる。

    • また、プロジェクトの最終的な権威者および意思決定者である。

    • 突き詰めるとPMと同じく、プロジェクトを成功に導く責任を負う。

    • プロジェクト・スポンサーは、

      • 通常は、組織内の論争や対立に決着をつける権力・権限を持った経営幹部。
      • プロジェクト位置付けの向上のため、プロジェクトの宣伝活動を継続的に行う。
      • プロジェクトにスポットライトを当てて、プロジェクトの一切を取り仕切る(資金、成果)。
    • フェーズ毎の関わり

      • 立上・計画フェーズには積極的に関わる。
      • 実行、監視・制御フェーズでは関わりは減り、問題発生時の意思決定を行う。
  • 機能部門マネージャ

    • 組織の管理業務に従事する。

    • 組織の部下

    • 以下の機能部門マネージャは、
      プロジェクト憲章作成で特定しておいた方がイイ。

      • プロジェクトのタスクに携わる。
      • プロジェクトの責任が割り当てられている。

アウトプット(プロジェクト憲章作成)

プロジェクト憲章

  • プロジェクト憲章には、経営陣やステークホルダーが読める、
    ハイレベル概要(PMP:共通の該当節を参照)の
    ビジネス・ニーズが文書化される。

    • 目的または妥当性
      ビジネス機会、ビジネス・ニーズ、問題解決

    • 成果物(プロダクト / サービス / 所産)に関する記述

      • (顧客の成果物に対する)要求事項
      • ステークホルダーの期待
      • 測定可能なプロジェクト目標、成功基準
    • プロジェクト

      • 記述と境界
      • 開始日 / 終了予定日
      • 前提条件 / 制約条件
      • リスク
      • 承認要求事項
        成否の判断材料(事項)と、成否を判断する人、受け入れの承認者。
    • 要約

      • 予算
      • マイルストーン・スケジュール
    • 人

      • ステークホルダー一覧
      • プロジェクト憲章を認可する人名と地位
      • 任命されたプロジェクト・マネージャと責任/権限
  • これにより、ステークホルダーの期待をプロジェクトの

    • スコープ
    • 成果物(プロダクト / サービス / 所産)

に反映することができる。

  • プロジェクト憲章は、

    • プロジェクトを依頼する組織
    • プロジェクトを遂行する組織

との間に、協力関係を形成すると書かれている。

  • このため、必ず計画プロセス群を開始する前に実行する。
  • また、反復プロセスにより署名含め内容を改訂する事も可能。

前提条件ログ

  • ハイレベル概要(PMP:共通の該当節を参照)の
    戦略的、業務上の前提条件・制約条件をプロジェクト憲章に反映。
  • ライフサイクル全ての前提条件・制約条件を記録する。

公式化と発行

プロジェクトの存在は承認済みのプロジェクト憲章という公式な書面によって承認/確認される。

  • 承認プロセス

    • (キックオフ・ミーティングなどで)
      プロジェクト憲章の内容に合意後、署名してもらう。

    • この後に、プロジェクト憲章が公式文書として発行される。

      • コピーなど印刷物として配布
      • Eメールやイントラネットで電子形式で配信
    • 署名者

      • 上級管理職(立上の人物 / 組織)
      • プロジェクト・スポンサー
  • 承認の結果

    • 組織にプロジェクトを紹介するために利用できる。
    • 組織の資源をプロジェクトに割り当てる権限をPMに与える。
    • プロジェクトの諸作業を組織の定常業務に結び付ける。

ステークホルダー特定

  • プロジェクトの成功はステークホルダーの期待に応えること。故に、

    • 早い段階でステークホルダーとの協力関係を築けば、プロジェクトが遂行しやすくなる。
    • ステークホルダーの役割を理解することがプロジェクト・マネジメントに重要になる。
  • このため、ステークホルダー特定を行う。

    • できるだけ早い段階で行う。また、継続的に行う。以下に注意する。

    • 主要なステークホルダー含め、プロジェクト期間中に変動することがある。

    • ステークホルダーによって難易度が変わる。

      • 主要なステークホルダーの特定は容易。
      • 上記以外の利害関係者というステークホルダーの特定は難しくなることがある。

インプット(ステークホルダー特定)

プロジェクト憲章(インプット)

関連するステークホルダー、事業部門の名称が記されていることがある。

調達文書

PMP:計画 - 資源の該当節を参照。

関連するステークホルダー、事業部門の名称が記されていることがある。

組織体の環境要因(ステークホルダー特定)

このプロセス中で特に注意を払う必要がある項目。

  • 企業文化

  • 組織構造
    影響力と権力を持っている人を、所属部門の地位から特定するのに役立つ。

  • 国家標準/業界標準

組織のプロセス資産(ステークホルダー特定)

このプロセス中で特に注意を払う必要がある項目。

プロセス(ツールと技法)(ステークホルダー特定)

ステークホルダー分析

  • プロジェクト期間中に定期的に見直し、必要に応じて更新する。

  • プロジェクト全期間に渡って、ステークホルダーの関心ごとや期待を分析する。

  • 特に影響力の強いステークホルダーの関心・期待の特定は満足度のマネジメントに役立つ。

  • 分析の対象

    • ステークホルダーのプラス or マイナスの影響力の分析

    • ステークホルダーの関心・期待、ニーズ、要望(要求事項)を理解

    • 関与レベル

      • 不認識:関与していない。
      • 抵抗:支持しない。若しくは強い抵抗の可能性がある。
      • 中立:支持・抵抗なし。関与度合いは低い可能性がある。
      • 支持:前向きの期待。関与による支持がある。
      • 指導:積極的な関与により、成功を手助けする。
# 不認識 抵抗 中立 支持 指導
1 ステークホルダーA 現在のレベル 望ましいレベル
2 ステークホルダーB 現在のレベル 望ましいレベル
3 ステークホルダーC 現在のレベル
  • ステークホルダー自体の

    • 役割

      • 所属部門の地位
      • ・・・
    • 理解
      プロジェクトの成果物(プロダクト / サービス / 所産)により、
      得るものと失うものを持っている故に、

      • ステークホルダー同士、協力関係や対立関係がありお互いに影響を与えあう。
      • プロジェクトに強い関心を持ち、プロジェクトの結果に大きな影響を与える人または組織がある。
  • 分析ステップ

    • 1:潜在的なステークホルダーを特定し、一般的な情報を収集する。

      • 部署、連絡先情報(電話番号、メアド)、知識レベル、期待、影響レベル
      • これらをステークホルダー登録簿のテンプレートに記入。
    • 2:ステークホルダーの潜在的な影響力とプロジェクトへのサポートを、
      以下を使用して明らかにする。

      • グリッド(x軸 → y軸)
        (1)権力と、→関心度
        (2)権力と、関心度→関与度
        (3)権力と、関与度→影響度

      • 突出モデル(セイリエンス・モデル)
        権力、(参画の)正当性、緊急度(注意を払う頻度:即時/随時/稀)

    • 3:ステークホルダーの様々な状況への反応と影響の評価
      過去プロジェクトでの行動(について非公式インタビュー)等を行い評価。

  • その他

    • 権力とXXXのグリッド

      • 権力と関心度のグリッド
        権限レベル(権力)と利害レベル(関心度)に基づいて、ステークホルダーを分類

      • 権力と関与度のグリッド
        権限レベル(権力)と参加レベル(関与度)に基づいて、ステークホルダーを分類

      • 関与度と影響度のグリッド
        参加レベル(関与度)と影響力(影響度)に基づいて、ステークホルダーを分類

                     ^
                     │
     常に情報共有    │ 密接にマネジメント
                     │
 --------------------┼--------------------> 権限レベル(権力)
                     │
       監視のみ      │      満足の維持
                     │
             利害レベル(関心度)
  • ステークホルダー可能性グリッド
    プロジェクトに対しプラス or マイナスのステークホルダーか4象限に分類

    • 横軸:妨害する可能性
    • 縦軸:支援する可能性
                     ^
                     │
     リソースフル    │ キー・プレイヤー
                     │
 --------------------┼--------------------> 妨害する可能性
                     │
     マージナル      │ ショー・ストッパー
                     │
               支援する可能性
  • ステークホルダー・キューブ(6)
    上記に、姿勢(肯定的か否定的)を加え8象限に分類

    • 横軸:妨害する可能性
    • 縦軸:支援する可能性
    • 奥行:姿勢(肯定的か否定的)

専門家の判断(ステークホルダー特定)

  • 上級管理職
  • 主要なステークホルダー
  • ステークホルダーと仕事をした経験のあるPM
  • コンサルタントや業界の専門家

会議

以下に対するプロファイリングと分析

  • プロジェクトにおけるステークホルダーの

    • 関心
    • 関与
    • 役割
    • 知識レベル

アウトプット(ステークホルダー特定)

ステークホルダー登録簿

以下が記載されている必要がある。

  • 識別情報

    • 部署

    • 連絡先情報(電話番号、メアド)

    • プロジェクトにおける役割

      • 知識レベル
      • 期待
      • 影響レベル
  • 評価情報

    • 影響力
    • 背景:関心・期待、ニーズ、要望(要求事項)
    • 重要な参画時期に関する要素
  • ステークホルダー分類

    • 組織の内部 / 外部
    • プロジェクトに肯定的 / 中立 / 否定的

戦略(ステークホルダーに対する対処に関する機密情報)

→ 一部のステークホルダーは、プロジェクト文書にアクセスできるので、
この機密情報が、公になる可能性がある点に注意を払う必要がある。

プロジェクト・マネジメント計画書更新版

必要に応じて更新する。

プロジェクト文書更新版

必要に応じて更新する。

移行メモ

  • ITTO の表は、元の PukiWiki で各項目がそれぞれの詳細ページの節アンカへ リンクしていたが、GitHub Wiki ではアンカが再現できないため、 表中の項目は素のテキストとし、参照先ページを表の直前に一覧として書き出した。 &br; は <br> に置き換えた。

  • 元の PukiWiki では「プロジェクト憲章」と「公式化と発行」の2つの見出しが 同一のアンカ(#c6b11201)を持っていたが、 GitHub Wiki では見出しから別々のアンカが生成される。

  • 「経営者の戦略的目標とのマッピンク」は「マッピング」に正した。

  • ファシリテーション技法の「開示のマネジメント」は、 PMBOK の同技法の構成(ブレーンストーミング/コンフリクトの解消/問題解決/ 会議のマネジメント)から「会議のマネジメント」の誤記と判断し正した。

  • ベネフィット・マネジメント計画書の主要要素の「戦略との成功性」は 「戦略との整合性」、「前提知識」は「前提条件」に正した。

  • 「関与度と影響度のグリッド」の説明が「権限レベル(権力)と影響力(影響度)に 基づいて」となっており見出しおよび直前の(3)の記述と食い違うため、 「参加レベル(関与度)と影響力(影響度)に基づいて」に正した。


Tags: 移行, PMP, 立上, プロジェクト憲章, ステークホルダー, ITTO, ビジネス・ケース

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONE / TODO

Clone this wiki locally