-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_PMPExamCommon
共通、環境、役割関連の試験対策
-
プロジェクト(
PMP:共通の該当節) -
プロジェクトか?定常業務か?を理解する。
-
キーワード
- 独自性と有期成
- 不確実性と段階的詳細化
-
集合(上位)
- プログラム
- ポートフォリオ
-
時間軸
- プロジェクト・フェーズ
- プロジェクト・ライフサイクル
- プロダクト・ライフサイクル
-
プロジェクト・マネジメント(
PMP:共通の該当節) -
大規模プロジェクトだけで有用。と言うのは大きな誤解でもある。
-
これによりプロジェクト・マネジメントの効果が発揮されないケースが多い。
-
※ 単にマネジメントと言った場合、以下に該当することがあるので注意する。
-
プロダクト・マネジメント
-
OPM(組織的プロジェクト・マネジメント)
-
- プロジェクト・マネジメントのスキル
- リーダーシップ(チーム・マネジメント)
- 戦略的・ビジネスのマネジメント
※ 「PMは技術者上がりが多いので技術的問題にフォーカスし過ぎる。」
という問題に対する言及がある。必ずしも、技術者上がりである必要は無い。
-
コミュニケーション
-
最も重要なスキル
-
実務時間の90%
-
コミュニケーション率
言葉以外の重要性が高い(メール < 音声会議 < TV会議 < F2F)。- 言葉:7%
- 音声:35%
- 表情:55%
-
効率と効果
- 効率 : 必要な情報の伝達
- 効果 : 対象、タイミング、チャネル
-
-
倫理・職務規定(
PMP:試験 - ガイダンスの該当節)- 顧客(スポンサー)に対して、PMに何が期待できるか?を明示する。
- 責任 = 顧客(スポンサー)の期待に応える。
-
贈賄関連
- その国の習慣であれば、スポンサー、法務などに相談してから考える。
- 問題のコンテキスト上、贈賄に見えるが正規の費用であることがある。
- 特に、納入者選定(
PMP:試験 - 実行の該当節)関連では注意が必要。
-
種類
-
機能型組織(中央集権)
-
マトリックス型組織(
PMP:環境 - 組織のシステムの該当節)
※ 指示系統がうやむやになりやすい。-
弱いマトリックス型組織
PMが弱い。プロジェクト・エクスペディター, コーディネーター。 -
バランス・マトリックス型組織
上司:機能部門M & PM -> メンバ、上司が2人になり、指示系統に混乱することもある。 -
強いマトリックス型組織
上司:PM -> メンバ、マトリックス型だが、PMが強い。 -
タイト・マトリックス
コロケーション、コンカレント・エンジニアリング(同時進行技術活動)
-
-
プロジェクト型組織(タスクフォース型組織)
メンバはプロジェクトにコミットしているため、解任に関して問題が出ることがある。
-
-
類似の組織構造
-
PM権限が弱い
- 機能型組織
- 弱いマトリックス型組織
- 多部門組織
-
PM権限が強い
- プロジェクト型組織
- PMO型組織
-
-
方法論の採択に対する責任( -> スポンサー)
-
長期的戦略計画、プロジェクト目標(スコープ・コスト・スケジュール)
との統合をチェックする( -> プロジェクト計画書、文書)。 -
PMOの組織タイプ
- 支援型: コンサルティング(最重要)
- コントロール型: コンプライアンスの要求
- 指揮型: 直接的コントロール
-
プロジェクト・マネジメント・プロセスをテーラリング
- ライフサイクル
- フェーズ
- I・TT・O
-
以下のマネジメント手法をステークホルダーと協力してテーラリング
- 制約条件
- プロジェクト目標
-
考慮事項
- 組織文化
- ガバナンス・レベル
- 顧客が組織の中か外か
-
プロジェクト・マネジメント方法論
-
PMBOKのように、汎用的ではなく、
特定分野の実務慣行(技法、手続、規則体系) -
プロジェクト・マネジメント方法論の入手方法
- 組織の専門家によって開発
- 協会(専門家の組織)から購入
- ベンダから購入
- 政府機関から購入
-
方法論のテーラリング
- 組織から特定のプロジェクト・マネジメント方法論の利用を強制されることがある。
- しかし、プロジェクトの独自性のため、PMにある程度のテーラリングは認められる。
- プロジェクトに合わせて、各知識エリアで適用される方法をテーラリングする。
-
口頭よりメールを選択。なんてケースもある。
-
プロダクト・ライフサイクル
- ビジネスの計画から始まり、市場の撤収まで(マーケティング用語と同じ)。
- 複数のプロジェクト・ライフサイクルからなる。
-
プロジェクト・ライフサイクル
-
立上から終結までのフェーズ分け
-
フェーズは、プロセス群の分類とは異なる、
成果物を生成するアクティビティの集合体で、
プロジェクトだけでなく、
フェーズ完了の後に終結に至ることもある(PMP:試験 - 終結の該当節)。 -
フェーズ分けは業界により異なる(プロジェクト・マネジメント方法論)。
(要件定義 -> 基本設計 -> 詳細設計 -> 開発 -> UT -> CT -> TT -> ST)
-
-
以下、漢字と横文字の対応付けに注意
(特に逐次型と漸進型、共に順に進む意味を持つので解り難い。)。-
予測型(逐次型: 順に進む)ライフサイクル
ウォーターフォール型(完全計画駆動型手法) -
反復型(漸進型: 少しずつ進む)ライフサイクル
イテレーティブ&インクリメンタル(Iterative and Incremental) -
適応型ライフサイクル
アジャイル型(変化駆動型手法)
バックログのある反復型スケジューリング -
オンデマンド・スケジューリング
カンバン・システムで一般的に使用される
制約理論とリーン開発由来のプルベースのスケジューリング概念。
-
-
-
アジャイル型・適応型
-
ポイント
- ステークホルダーを会議に招く(透明性の促進と迅速な支援)。
- ...。
-
考慮事項(いずれも PMP:共通 の該当節を参照)
- 統合マネジメント
- スコープ・マネジメント
- スケジュール・マネジメント
- コスト・マネジメント
- 品質マネジメント
- 資源マネジメント
- コミュニケーション・マネジメント
- リスク・マネジメント
- 調達マネジメント
- ステークホルダー・マネジメント
-
-
漢字
-
逐次
≒順次・逐次・随時≒予測・ウォーター・フォール -
漸進
≒(急がないで)段階を追って少しずつ進んで行くこと。≒反復・イテレーティブ
-
-
弱いマトリックス型(
PMP:環境 - 組織のシステムの該当節)の役割。- エクスペディター(プロジェクト促進役)
- コーディネーター(プロジェクト調整役)
-
コーディネーターの方が権限がある。
プロジェクト・エクスペディター型(促進者) < コーディネーター型(調整者)
違いを問われるので違いを意識しておく。
- 組織体の環境要因(EEF):環境的なもの。
- 組織のプロセス資産(OPA):資産的なもの。
BABOK用語らしい(要求事項 = スコープだけの話ではない)。
-
ビジネス要求事項
- ビジネス目標およびプロジェクト目標
- 母体組織に関係するビジネスルール
- 組織と指針とする原則
-
ステークホルダー要求事項
- 他の部門への影響
- 母体組織および外部組織への影響
- ステークホルダーのコミュニケーション要求事項と報告要求事項
-
ソリューション要求事項
- 機能要求事項と非機能要求事項
- 技術と標準へのコンプライアンス要求事項
- サポート要求事項とトレーニング要求事項
- 品質要求事項
- 報告要求事項など
-
プロジェクト要求事項
- サービスレベル
- パフォーマンス
- 安全性
- コンプライアンス
- 受入れ基準
-
移行要求事項
-
その他
- 要求以上の成果
- 金メッキと呼ばれる。
- ステークホルダーが多様な場合はNG。
- 要求以上の成果
-
ネットワーキング
- チーム・メンバ
- ステークホルダー
-
積極的傾聴
- ステークホルダー監視
移行メモ
- 元 Wiki で見出しそのものが他ページへのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
- PukiWiki のページ内アンカ(
#xxxxxxxx)は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜(ページ名の該当節を参照)」の形に置き換えた。- 元 Wiki の赤字強調は太字にした。
- 元 Wiki の「カバナンス」「イテレーディブ」「変化駆手法」は、 それぞれ「ガバナンス」「イテレーティブ」「変化駆動型手法」の誤記と判断し修正した。
Tags: 移行, 資格, PMP, 試験, 共通, 環境, 役割, 組織構造, PMO, テーラリング, ライフサイクル, ステークホルダー
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。