「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
プロジェクトの定義 †
プロジェクトか？定常業務か？ †
独自性 †
プロジェクトの存在理由は、今までなかったプロダクト / サービス / 所産を産み出すこと。
- 変化を駆動できる。
- 組織をある状態から別の状態へ移行できる。
- プラン・ドリブンからチェンジ・ドリブン（PDCAからOODA）
- 事業価値（ベネフィット）を創造できる
ビジネス・アナリストの分野、BABOK
- 有形
- 金融資産
- 株主持ち分
- 実益
- 市場シェア
- 備品
- ツール
- 無形
- のれん
- 商標
- 評判
- 公益性
- ブランド認知度
- 戦略的提携
有期的 †
有期的（開始日・終了日がある）。
- 完了
- ステークホルダーの目的・目標の達成により完了する。
- 目的・目標の達成が不可能な場合にも完了する。
- 若しくは、必要性が無くなった場合にも完了する。
段階的詳細化 †
- 初期段階：大まか
- 完了に至るまで段階的に詳細化される。
- 要件などから機能特性や機能要件などが決定される。
マネジメント・スキルの差異 †
ライフサイクル †
- プロジェクトがプロダクト・ライフサイクルの終了段階までに及ぶ。
- プロジェクトが定常業務化するので、プロジェクトに定常業務の要員を入れる。
立ち上げの要因 †
- PMBOKによれば、7つの「ニーズと要求」の内の
１つが発生した結果、プロジェクトは生まれる。
- これらは、
- ビジネス機会 / ビジネス・ニーズ、問題解決に結び付く。
- また、プロジェクトのリスクにも結び付く。
- 経営陣は、これらのニーズと要求にどう対応するか、
決定する必要がある（これがプロジェクト立上の契機になる）。
市場の需要 †
戦略的 / ビジネス・ニーズ †
- 例
- 処理性能の高いコールセンタが基幹業務に必要
→ サービスの応答時間が悪くなることが収益に影響するため。
顧客要求 †
- 顧客が明確に要求する。
- 顧客には組織内の顧客と組織外の顧客がいる。
- 市場の需要よりミクロ
- 例
技術的進歩 †
- 問題はソレを解決する手段が登場して初めて問題と認識される。
- 技術的進歩が問題解決をする場合、その導入がプロジェクトに繋がる。
- 例
業務にXXXを導入
- 衛星通信
- モバイル端末
- タッチ・スクリーン
- 動画ストリーミング
- , etc.
法的要件 †
- 新しい法案が可決される毎に、
政府・民間共にプロジェクトを立ち上げる。
- 例
- マイナンバー
- 消費税の引き上げ
- 医療関連の新しい法律の制定
- 食品の産地・原料・カロリー・許容摂取量など表示の義務付け。
環境への配慮 †
社会的ニーズ †
企業の目標と戦略 †
↓↓↓
↓↓↓
↓↓↓
ポートフォリオ †
ココでは事業ポートフォリオの意味。
プログラム †
- 関連プロジェクト、サブプログラム、サブプロジェクト、作業グループ。
- 類似のプログラム・マネジメント技法を使って調和がとれるようにマネジメントされる。
- 例
生活・仕事・ショッピングが揃った職住一体型団地のプログラム
ステークホルダー †
- プロジェクトに利害関係を持つ人や組織
- ステークホルダーの特定は１回だけではなく、常に問い続ける。
コンフリクトの解消 †
- 早期に主要ステークホルダーを特定しニーズと契約条件を理解する。
- 利害関係の不一致の解消に努める。優先順位は顧客を最大にしておく。
特性 †
完了の判断材料 †
ステークホルダーの期待に応えたかどうか。
満足度を測る手段 †
ステークホルダーの期待は計画プロセス中で文書化される。
- 成果物
- 独自かつ検証可能なもの。
- 有形 or 無形のもの。
- プロダクト / サービス / 所産ではない中間生成物
マネジメントの定義 †
組織的プロジェクト・マネジメント（OPM） †
OPM：Organizational Project Management
母体組織の戦略目標を達成する。
プロジェクト・マネジメント †
組織の目的、及び目標の達成を可能にする。
領域 †
プロダクト / サービス / 所産の引き渡し。
プロジェクト・アクティビティ（プロセス）の集合体を、
PMI承認のプロジェクト・マネジメント・プロセスに従って
- 記述・体系化する。
プロジェクトとチームを体系化。
- 監視する。
知識・スキル、ツール・技法を適用。
プロジェクト・マネージャー（PM） †
- プロジェクトは有形・無形のプロダクト / サービス / 所産を産み出し、
このプロダクト / サービス / 所産は事業に価値を高める。
- このプロダクト / サービス / 所産を産み出すための要求事項を満たすために、
プロジェクト・アクティビティ（プロセス）に、
プロジェクト・マネジメントの知識・スキル、ツール・技法を適用する。
- それ以外にも以下のようなスキルが必要になる。
- 知識
マネジメント技法に関する知識
- 執行能力
PMーとしての役割を遂行する能力
- 人間性
リーダーシップを発揮する能力/態度/倫理観などの行動特性
ベネフィットを実現するために、サブプログラム、プロジェクトの
相互依存関係をコントロールする（調和させる）。
領域 †
相互依存関係の規定と制約条件の調整
によるプログラム間の問題の解決。
ポートフォリオ・マネジメント †
ポートフォリオ全体の戦略的目標を
- 達成することが目標。
- 集合体のマネジメントが必要になる。
※ ポートフォリオ中のプロジェクト・プログラムは相互に依存関係を持たなくても良い。
領域 †
- 目標達成の効率性（範囲）
- 時間、原価/資源、リスク
- プログラムの評価、取捨選択、リソース確保などによるバランス調整。
- プログラムが全体の戦略的目標を順守しているかの監視。
マネジメントのスキル †
- スペシャリストではなくジェネラリスト、問題解決者。
- スペシャリストをチームに入れ、必要に応じてスペシャリストに頼る。
一般的スキル †
適用分野のスキル †
分野 †
- 業種（自動車、医療、日式SI）
- 部門（会計、マーケティング）
- 技術（ソフトウェア開発、工業技術）
- マネジメント専門分野（調達、研究開発）
関係 †
適用分野のスキルは以下に関係する。
- プロジェクト
- （特定の）ニーズ
- 顧客・業界の規範・法規
- 調達規則（政府系 <---> 建築系）
- 法規 （医薬品 <---> 自動車）
人間関係スキル（ソフト・スキル） †
コミュニケーション †
- プロジェクト・コミュニケーション
以下を明確/明瞭/完全なものとして作成・管理
組織化/計画スキル †
- トラッキング
- プロジェクト文書
- 要求事項情報
- メモ
- プロジェクト報告書
- 人事関連の記録
- 業者の見積書
- 契約書
- その他の情報
- その他
- 会議の開催
- チームの編成
- メディア発表のスケジュールの作成・管理
タイム・マネジメント・スキル †
物事を整理された状態に保つため優先順位を決定する。
コンフリクト・マネジメント・スキル †
コンフリクト・マネジメントでは問題を解決する。
- 定義の方法
- 内部 or 外部の問題か？
- 技術的な問題か？
- 人間関係の問題か？
- マネジメントの問題か？
- 影響や結果の大きさや範囲
交渉力/影響力スキル †
- 権力/政治力
- 権力は人に否応なく何かさせる能力。
- 政治力は利害関係（対立・混乱）を創造的に協力させる能力。
リーダーシップ・スキル †
- リーダーとマネージャー
- リーダー≠マネージャー
- リーダー <---> マネージャー（切り替える）
チーム形成/動機付けスキル †
- 動機付けスキル
- 長期、障害が多いプロジェクトで重要になる。
- 配下に無いチーム・メンバの動機付けも必要になる。
- 方法
- 期待していると伝えるのではなく、
- 機能部門マネージャに依頼してチーム・メンバの
パフォーマンス・レビュー（ = 評価の事）に参加させてもらう。
（期待より、評価の方が動機としては大きくなる。上長承認も取り易い。）。
マネジメントの組織 †
PMO：Project Management Office †
- 組織のプロジェクト、プログラムのマネジメントを監督する集権的な組織。
- COE（Center Of Excellence）とも呼ぶ。
目的 †
- パフォーマンス向上と競争上の優位性維持のため、組織的実務敢行を横断する。
- 人的資源（調達）
- テクノロジー（生産技術）
- 文化（スキーム再検討）
- プロジェクト内・外のコミュニケーションの促進
- 資源のマネジメント
スコープ・責任 †
- 傘下のプロジェクトの
- 文書の維持・保管
- 目標と進捗のパフォーマンス監視
- 目標のマネジメント
- 是正措置を提案
- チームやステークホルダーにフィードバック
- プロジェクト横断の
- 資源のマネジメント
- 依存関係のマネジメント
- 戦略的目標に合わせた調整
- 完了後の評価
- 期限内に完了したか？
- 予算を超過しなかったか？
- 品質は適正だったか？
PMOの組織タイプ †
| # | 組織タイプ | 役割 | 統制レベル |
| 1 | 支援型 | コンサルティング
・テンプレート提供
・リポジトリ提供 | 低 |
| 2 | コントロール型 | コンプライアンス
・枠組みの準備
・方法論への準拠 | 中 |
| 3 | 指揮型 | コントロール
・PMO自身によるマネジメント | 高 |
PBO：Project-Based Organization †
- プロジェクト作業実施のための一時的な体制。
- 組織の政治力や地位などの体制上の影響を無視できる。
- 最終的なプロダクト / サービス / 所産の成功の度合いをPBOが測定する。
組織構造 †
理解する意味 †
影響 †
組織構造に依存する
がプロジェクトの実行・結果に影響を与える。
見極めの方法 †
上級管理職がPMへ権限委任する度合い。
（様々なレベルのマネジメント層とのやり取りによって決まる）
- 権限
- 権限レベル、役割
- リソース利用可否
- 予算管理
- チーム編成
機能型組織 †
- 最古、伝統的手法
- 専門分野（機能）で形成（グループ分け）
- 階層型構造を持つ（CEO -> 部長 -> 課長 -> 担当）
- 命令系統が存在、逸脱しないように注意が必要になる。
| # | 利点 | 欠点 |
| 1 | 持続的 | PMに権限が無い |
| 2 | ・専門スキルが伸ばせる。
・明確なキャリア・パス。 | 複数の部門が同じ資源を奪いあう。 |
| 3 | 明確な指揮系統 | チーム・メンバは機能部門マネージャに忠実 |
人的資源 †
- 似通ったスキルと経験
- 効率的で簡単
- キャリアパスが明確
欠点 †
- PMにとっての欠点
- 公式の権限をほとんど持てない。
- プロジェクト・リーダー / 調整者 / 促進者のレベル
- 実際の権限を持っているのは、部長
マネジメント †
特徴
- 分離型の手法でプロジェクトが遂行される。
- 例えば、プロジェクトがマーケティング ---> 製造という工程を持つ場合、
- プロジェクトの工程は、マーケティング部から製造部へリレーされる。
- 各工程は、以下のように（部門毎に）呼ばれる。
- プロジェクト全体ではなく、機能部門の階層に忠実
- 機能部門のマネージャーにパフォーマンス・レビューの責任があるため。
- 経験を積む機会はプロジェクト・チームではなく自機能部門にあるため。
- リーダーシップを駆使
- 共通のビジョンの形成、チーム・メンバの意欲をかき立てる。
- 機能部門マネージャに依頼してチーム・メンバの
パフォーマンス・レビュー（ = 評価の事）に参加させてもらう。
プレッシャー（資源） †
資源とプロジェクトの優先度を巡る競争が激化することがある。
- 例：複数の部門が同じ資源を奪いあうプロジェクト要求を出す。
- 対策：外交能力
- ステークホルダーの賛同を得る
- 問題を避けるためコミュニケーション
プロジェクト型組織 †
- 機能型組織の対極にある。
- 組織の中心は機能部門ではなくプロジェクト。
- 組織の資源は、プロジェクトとプロジェクト作業にのみ投入される。
人的資源 †
- チームが形成されると、コロケーション（同床化）される。
- 機能部門のマネージャーではなくPMの配下に置かれる。
- 支援機能部門もPMに直属することがある。
- 忠誠心は機能部門ではなくプロジェクトを中心に形成される。
- PMにパフォーマンス・レビューの責任があるため。
- 経験を積む機会はプロジェクト・チームにあるため。
欠点 †
- このため、人的資源の活用に非効率性が存在する。
- 仕事がない期間がある。
- 解雇 / 再雇用は容易ではない。
- 計画時に非効率性（遊休時間）を最小化するよう、
チーム・メンバのスキル / 能力の把握が必要になる。
マトリックス型組織 †
- 機能部門に干渉されずに、プロジェクトとプロジェクト作業に専念できる。
人的資源 †
１人の機能部門のマネージャーと１人以上のPMの配下に置かれる。
- 機能部門のマネージャー
- プロジェクトに対する人的資源の
- パフォーマンス・レビューの責任を持つ。
- PM
- 人的資源の見積・配属を機能部門のマネージャーに依頼する。
- プロジェクト・アクティビティに対する人的資源の割り当てを行う。
- パフォーマンス・レビューの責任を持つ。
力の均衡 †
| # | タイプ | PMの重点 | PMの上司 | PMの地位 | PMの権力 | PMの時間 | 組織のスタイル |
| 1 | 強いマトリックス型 | プロジェクト・プロジェクト作業 | PM | PM | 大きい | プロジェクトに常勤 | プロジェクト型組織 |
| 2 | パランス・マトリックス型 | プロジェクト・プロジェクト作業 | 機能部門のマネージャー | PM | パランス | プロジェクトに常勤 | 中間 |
| 3 | 弱いマトリックス型 | プロジェクトと機能部門 | 機能部門のマネージャー | プロジェクト・リーダー / 調整者 / 促進者のレベル | 小さい | 非常勤でプロジェクトに従事 | 機能型組織 |
強いマトリックス型 †
- 横串にPM専門組織がいて、プロジェクトをPMが纏める。
- マトリックス型だが、PMが強い。
パランス・マトリックス型 †
- 横串に機能部門が立って、中心となる機能部門の担当がPMを務める。
- 機能部門のマネージャーとPMが均衡している。
- 人的資源はニーズによって配属される。
弱いマトリックス型 †
- 横串に機能部門が立って、中心となる機能部門の担当がリーダー / 調整者 / 促進者を務める。
- 機能部門のマネージャーに権限があり、リーダー / 調整者 / 促進者にはほとんど権限が無い。
ライフサイクルとプロセス †
プロジェクト・ライフサイクル（フェーズ） †
プロジェクト・ライフサイクル（フェーズ）では、
各フェーズのプロジェクト作業を完了させる方法を定義。
概要 †
- プロジェクトには段階的詳細化など、フェーズがある。
プロジェクト・マネジメント・プロセスの体系化のためのプロセス群とは異なる。
- 基本的には、以下の形で構成される。
- 開始：プロジェクトの開始
- 計画：組織編成
- 実行：作業実施
- 終結：プロジェクトの終結
- ITでいえば、要件定義 -> 設計 -> 実装 -> テスト
ライフサイクル区分 †
- 予測型サイクル（完全計画駆動型手法、ウォーターフォール型）
- スコープ
- 開始時の早い段階で定義され、スケジュール・予算も決定される。
- 変更は、入念に監視される。変更の際は、
プロジェクト・マネジメント計画書の見直しと承認を行う。
- フェーズ
- フェーズ作業は明確に区分され、繰り返されない。
- 各フェーズでは、プロジェクト・アクティビティの異なる部分が強調され、
それぞれ、異なるプロジェクト・マネジメント・プロセス群が実行される。
- 成果物
- 開始時の早い段階で定義される。
- 段階的詳細化により、次第に完成度を増す。
- これに伴い、スケジュール・予算も詳細化される。
- 適合するプロジェクト
- 大規模、複雑
- 目標やスコープが不明確
- 成果物の段階的引き渡しが必要
- 適用型ライフサイクル（アジャイル手法、変化駆手法）
- 成果物
- 反復型、漸進型ライフサイクル的
- より短い期間（2-4週間）で成果物を生成する。
- 適合するプロジェクト
- 要求が不明確で変化する場合。
- ステークホルダーの積極的参加が必要な場合。
フェーズの完了 †
成果物を生成し、検証・承認する。
- レビューにて誤りを発見し是正処置を実施する。
- 次のフェーズへ進むかどうか判断する（引き渡しと別？）。
- 別名（PMBOK）
- フェーズ・レビュー
- フェーズ・ゲート
- ステージ・ゲート
- マイルストーン
- 中止点
マルチフェーズ・プロジェクト †
- フェーズ間の関係
- 直列関係：フェーズ完了後に次フェーズが始まる。
- 重複関係：フェーズ完了前に次フェーズが始まる。
引き渡し（技術移管） †
- フェーズ間の繋ぎの部分。
- 成果物を見て次フェーズに進むかどうか判断する。
- 例：開始フェーズでフィージビリティスタディ（PoC）
実行可能性調査 / 企業化調査 / 投資調査 / 採算性調査（概念実証 / 実証実験）
- プロジェクト遂行の価値があるかどうか。
- 組織に利益をもたらすかどうか。
- プロダクト / サービス / 所産が業界の標準や法規を満たすかどうか。
- 重複関係（マルチフェーズ・プロジェクト）にある場合は、引き渡しできない。
ライフサイクルの特徴 †
- 段階的詳細化
- チーム・メンバとコスト
- 開始時点では、チーム・メンバも少なく、低コスト。
- 進行するにつれて、チーム・メンバ、コストが増加。
- 成功率とリスク
- 開始時点の成功率は低いが、進行するにつれ成功率が高まる。
- 開始時点のリスクは高いが、進行するにつれリスクが減少する。
プロジェクト・マネジメント・プロセス †
プロジェクト・マネジメント・プロセスは、
- 各フェーズのアクティビティを記述・体系化して、
- マネジメントするツールと技法をまとめている。
- これにより、各フェーズのアクティビティを完了させる。
| PMプロセス1 | →
→
→
（フロー） | PMプロセス2 |
| インプット | プロセス
（ツールと技法） | アウトプット | インプット | プロセス
（ツールと技法） | アウトプット |
プロセス群 †
PMBOKガイドに記載された、プロセスの作業を体系化する下記の5つのプロセス群がある。
- 立上
- プロジェクトの開始時や、大規模プロジェクトのフェーズ開始時
- 開始の承認：プロジェクトを承認し、組織の資源をプロジェクトに割り当てる権限をPMに与える。
- アウトプット：プロジェクト憲章、ステークホルダー特定
- 計画
- プロジェクト・マネジメント計画書の作成
プロジェクト・マネジメント・プロセス（実施、監視・制御の方法）を選択・定義する。
- アウトプット：各知識エリアを考慮し、段階的に詳細化を行う。
そして、各プロセス群のプロジェクト・マネジメント計画書と、それらを統合した計画書を作成する。
- テーラリング：小規模プロジェクトなどで、プロジェクトに適合するプロセスを判断し、実際に実行するかどうかを決める。
- 実行
- 目標達成のためプロジェクト・マネジメント計画書に従いリソースを調整・分配。
- 最も多くの時間と資源を使用する。対立の経験。承認された変更の実施。
- アウトプット：プロダクト / サービス / 所産
- 監視・制御
- 計画どおりか作業を追跡（トラッキング）し、パフォーマンスを測定・分析する。
- 「問題の特定」と「是正措置の実施」（アクティビティを再計画、再実行する）。
- アウトプット：是正措置の実施
- 終結（中止された場合にも実行される）
- 省略されることも多いが、プロジェクト情報の収集は重要。
- ステークホルダーの公式の承諾・承認が得られる。
- アウトプット：収集されたプロジェクト情報の文書
特性 †
| # | 特性 | 立上 | 計画 | 実行 | 監視・制御 | 終結 |
| 1 | コスト | 低い | 低い | 最大 | やや低い | 最低 |
| 2 | スタッフ数 | 少ない | 少なめ | 多い | 多い | 少なめ |
| 3 | 成功の確率 | 最低 | 低い | 中間 | 高い | 最大 |
| 4 | リスク発生の確立 | 最大 | 高い | 中間 | 低い | 最低 |
| 5 | ステークホルダーの影響力 | 最大 | 高い | 中間 | 低い | 最低 |
※ 1, 2のリソースは実行時が最大
※ 3, 4, 5は、立上 → 終了に向けて大きくor小さくなる。
※ 5のステークホルダーの影響力は、要求事項を決める迄が最大。
フロー †
インプット・アウトプットは成果物で、有形 or 無形で、独自かつ検証可能。
| # | インプット | | プロセス | | アウトプット |
| 1 | ‐ | → | 立上 | → | 計画 |
| 2 | 立上 | 計画 | 実行 |
| 3 | ・計画
・監視・制御（再計画） | 実行 | 監視・制御 |
| 4 | 実行 | 監視・制御 | ・再計画
・再実行
・終結 |
| 5 | 監視・制御 | 終結 | |
※ 監視・制御によって計画・実行が反復的に行われる。PMBOKでは「反復的なプロセス」と呼ぶ。
根底には、PDCAサイクル（PDCA cycle、plan-do-check-act cycle）がある。
「反復的なプロセス」の計画は前フェーズの作業中に開始される。
※ IPECC : Initiating, Planning, Executing, Controlling, Closing.
データと情報 †
- 作業パフォーマンス・データ
実行プロセス群で成果物を作成する際に収集される作業パフォーマンスの生データ
- 作業パフォーマンス情報
作業パフォーマンス・データを各、監視・制御プロセス群で変換したもの。
相互作用 †
- PMは、各知識エリアを考慮し、適切なプロセスを決定する。
- 段階的詳細化により情報量が増えるのでプロジェクト計画書を適宜更新する。
知識エリア †
統合マネジメント †
概要 †
- 作業の統合（定義と組み合わせ）を行う。
- プロジェクト・マネジメント計画書の調整。
- 関連するプロセスは密接な依存関係がある。
- プロジェクト遂行中に継続的に繰り返される。
- 得失評価の実施
- 顧客、ステークホルダーの要求事項を満たすための、期待のマネジメントを行う。
- 成功裏に終わらせるための、目標と代替案の比較を行う。
- ツール
- EVM（アーンド・バリュー・マネジメント）
- プロジェクト・マネジメント・ソフトウェア
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 立上 : プロジェクト憲章作成
- 計画 : プロジェクト・マネジメント計画書作成
- 実行 : プロジェクト作業の指揮・マネジメント
- 監視・制御 : プロジェクト作業の監視・コントロール, 統合変更管理
- 潜在的な問題を予測し、問題が危機的状況に達する前に対処する。
- スケジュール変更を伴う（作業とプロジェクト・マネジメント計画書に影響）
- 下記知識エリアのプロセスとも密接に関連し相互作用する。
- 終結 : プロジェクトやフェーズの終結
スコープ・マネジメント †
概要 †
- 成功裏に終わらせるため、必要な作業だけの定義を行う。
- １回、時には複数回（多くの場合、何度も）実行される。
スコープの種類 †
- プロダクト・スコープ
- プロダクト / サービス / 所産の特性に関連する。
- 要求事項に照らし合わせて測定され、成功/失敗を判断する。
- プロジェクト・スコープ
- 作業に関するマネジメントに関連する。
- プロジェクト・マネジメント計画書に照らし合わせて測定される。
- スコープ・ベースラインの構成：プロジェクト・スコープ記述書、WBS、WBS辞書
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : スコープ・マネジメント計画、要求事項収集、スコープ定義、WBS作成
- スコープ・マネジメント計画の作成
- プロダクトの要求事項の定義と詳細化
- プロダクトの成果物の定義と詳細化
- WBSの作成
- 監視・制御 : スコープ妥当性確認、スコープ・コントロール
- 測定技法を使用した成果物の検証
- プロダクト・スコープの変更管理
スケジュール・マネジメント †
概要 †
- プロジェクトを適切な時間で完了させる。
- １回、時には複数回（小規模プロジェクトの場合１人で１回）実行される。
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : スケジュール・マネジメント計画、アクティビティの色々、スケジュールの作成
- スケジュール・マネジメント計画書の作成
- プロジェクト・アクティビティの定義/順序設定/資源見積/所要期間見積
- プロジェクト・スケジュールの作成
コスト・マネジメント †
概要 †
見積、予算の設定・承認、予算を超過しないように監視・制御。
- スコープに関連深い（スコープが早期に決まればコストも早期に決まる）
- 早いタイミングの方がコストのコントロールが容易
- 他のコストとして、保守運用フェーズのコストがあり、調べておく必要がある。
技法 †
代替案を比較・選択、提示する。
- 価値工学（技法）
プロジェクトの費用対効果を下記の観点で最適化する。
- 資源の活用度
- スケジュール（短縮）
- 品質（向上）
- 利益（追加の財務分析）
回収期間分析 / 投資収益率 / 割引キャッシュ・フロー
- ライフサイクル・コスト（技法）
コスト・グループを総合的に考慮する。
- 取得コスト（イニシャル）
- 運用コスト（ランニング）
- 廃棄コスト
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : コスト・マネジメント計画、コスト見積、予算設定
見積、予算の設定・承認
- 監視・制御 : コスト・コントロール
予算を超過しないように監視・制御。
品質マネジメント †
概要 †
プロダクト / サービス / 所産の要求事項を満たす各種の取り計らい。
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : 品質マネジメント計画
品質計画（品質基準）
- 実行 : 品質保障（QA）
品質の作り込み（例：レビュー、管理（変更/構成/リリース））
- 監視・制御 : 品質管理（QC）
測定・監視し、品質基準と比較する（例：バグ収束曲線）。
人的資源マネジメント †
概要 †
- 人的資源
- 人的資源が最高のパフォーマンスで利用されるようにする各種の取り計らい。
- 早期参加が望ましく、積極性に繋がる。
- 人事管理と人間関係の側面がある。
- リーダーシップ
- コーチング
- 対立への対処
- パフォーマンス評価
技法 †
- スキル
- コミュニケーション・スタイル
- リーダーシップ・スキル
- チーム形成スキル
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 :
人的資源マネジメント計画- アクティビティ資源見積(6)
- 実行 : プロジェクト・
チーム編成 / 育成 / マネジメント
コミュニケーション・マネジメント †
概要 †
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 実行 : コミュニケーション・マネジメント
- プロジェクト情報の収集 / 体系化 / 保管
- プロジェクト情報の適切なタイミングでの配信
リスク・マネジメント †
概要 †
- リスクには外からのリスク、内からのリスクがある。
- また、脅威（マイナス）のリスクと、好機（プラス）のリスクがある。
- プラス・マイナス両極の潜在的リスクの特定 / 分析 / 計画に関連する。
- リスク（マイナス・プラス）の確率と影響を（最小化・最大化）する。
- 影響を利用し、目標・パフォーマンスの改善もできる。
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : リスク・マネジメント計画、リスク特定、定性的/定量的リスク分析、リスク対応計
- 監視・制御 : リスク監視
調達マネジメント †
概要 †
- プロジェクト・チーム外から物品を購入するプロセス
- 物品の購入者の立場から論じることを前提とする。
納品者の立場からすると、購入者がプロジェクトの
ステークホルダーになることがある（SCM）。
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : 調達マネジメント計画
契約・調達手段の交渉
- 監視・制御 : 調達コントロール
契約・作業指示の変更
ステークホルダー ・マネジメント †
概要 †
- 組織の内・外の、すべてのステークホルダーの特定に関連する。
- ステークホルダーのニーズ / 期待 / 関与の評価を行う。
- ステークホルダーとの（率直かつ明確な）コミュニケーションの状態を維持する。
当該 知識エリアのプロジェクト・マネジメント・プロセス
- 計画 : ステークホルダー・マネジメント計画
ステークホルダーのニーズ / 期待 / 関与の評価
- 実行 : ステークホルダー・エンゲージメント・マネジメント
- 良好なコミュニケーションの状態の確立・維持。
- ステークホルダーの愛着心の管理。
- 監視・制御 :ステークホルダー・エンゲージメント監視
- 良好なコミュニケーションの状態を維持。
- ステークホルダーの愛着心の制御。
その他 †
コミュニケーション †
業務全体の90%
スキル †
- PMに最も重要なスキルとされる。
- 交渉力、影響力、問題解決より重要
- 上記の全てのベースとなるため。
制限があった場合 †
それを覆さず、別の選択肢を模索
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
