「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
6版で大幅改定。
- 環境 - 組織のシステム
- 組織の管理職の責任
- PMは組織のシステムを理解する。
- 組織のシステムの制約条件内でプロジェクトを運営。
ガバナンス †
概念 †
- 要員/役割/構造/方針について考察。
- フィードバックと監督（枠組みの方向性を示す）。
枠組み †
「規則/方針/手続き/規範/関係/プロセス/システム」により以下に影響を与える。
- 組織の目標を設定して達成する。
- リスクを監視し評価する。
- パフォーマンスを最適化する。
領域 †
- 整合性
- リスク
- パフォーマンス
- コミュニケーション
機能 †
プロジェクト・マネジメント活動をガイドする枠組み/機能/プロセス
組織構造 †
理解する意味 †
影響 †
組織構造に依存する
がプロジェクトの実行・結果に影響を与える。
見極めの方法 †
上級管理職が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が均衡している。
- 人的資源はニーズによって配属される。
弱いマトリックス型 †
- 横串に機能部門が立って、中心となる機能部門の担当がリーダー / 調整者 / 促進者を務める。
- 機能部門のマネージャーに権限があり、リーダー / 調整者 / 促進者にはほとんど権限が無い。
その他(6) †
有機的か単純 †
機能型（中央集権） †
多機能 †
バーチャル †
ハイブリッド †
PMO：Project Management Office †
- 組織のプロジェクト、プログラムのマネジメントを監督する集権的な組織。
- COE（Center Of Excellence）とも呼ぶ。
目的 †
標準・枠組の確立・維持 †
組織的実務慣行の横断 †
パフォーマンス向上と競争上の優位性維持のため、組織的実務慣行を横断する。
- 人的資源（調達）
- テクノロジー（生産技術）
- 文化（スキーム再検討）
PMの支援（最も重要） †
スコープ・責任 †
プロジェクトに対する †
- 文書の維持・保管
- 目標と進捗のパフォーマンス監視
- 目標のマネジメント
- 是正措置を提案
- チームやステークホルダーにフィードバック
プロジェクト横断的な †
- 資源のマネジメント
- 依存関係のマネジメント
- 戦略的目標に合わせた調整
プロジェクト完了後の評価 †
- 期限内に完了したか？
- 予算を超過しなかったか？
- 品質は適正だったか？
実施事項 †
提言 †
リード †
処置 †
中止 †
PMOの組織タイプ †
| # | 組織タイプ | 役割 | 統制レベル |
| 1 | 支援型 | コンサルティング
・テンプレート提供
・リポジトリ提供 | 低 |
| 2 | コントロール型 | コンプライアンスの要求
・枠組みの準備
・方法論への準拠 | 中 |
| 3 | 指揮型 | 直接的コントロール
・PMO自身によるマネジメント | 高 |
PBO：Project-Based Organization †
- プロジェクト作業実施のための一時的な体制。
- 組織の政治力や地位などの体制上の影響を無視できる。
- 最終的なプロダクト / サービス / 所産の成功の度合いをPBOが測定する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
