「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
組織的プロジェクト・マネジメント（OPM） 中の プログラム・マネジメント
詳細 †
プログラムの3パターン †
分割パターン †
大きなプロジェクトを細かく切った状態にして
スコープを分割すれば、大規模プロジェクトの成功率を高められる。
段階的パターン †
大きなプロジェクトを細かく切った状態にして
時間軸に沿って順次プロジェクトを立ち上げ、段階的に仕上げていく。
イノベーション・パターン †
コードネームを付けて「○○計画」と表現する場合など、新事業や新製品・サービスを創出するケース。
- 商品企画、研究開発、マーケティング、商品開発、プロモーションなど、
異なる部署間で有機的なつながりを持つプロジェクトが立ち上がる。
- しかも、することがある。
- あるプロジェクトの結果が他のプロジェクトに影響したり、
- 世の中の変化に対応して進む方向を変えたり、
- この場合、経営とプロジェクトをつなぐ役割として、プログラムマネジャーを置く。
関連するプロジェクトへのガバナンス、コントロール、打ち切りの判断が容易になる。
- フェーズゲート
あらかじめフェーズゲートを設定しておけば、適切に意思決定できるようになる。
- 研究開発プロジェクトの打ち切りや、競合相手など外部環境変化に伴い大きな方向転換を迫られるかもしれない。
- プロジェクト側は当然、続けたいと思っているので、実際に打ち切るとなると強い抵抗がある。
- リスク・マネジメント
イノベーション・パターンのプログラムでは外部リスクが増え振れ、且つ幅も大きい。
- 自分たちでは全くコントロールできないケースがある。
- それでもさまざまなリスクを洗い出し、対応策を考える。
- また、プラスのリスク（好機）のシナリオを描いて備えておくことも求められる。
マネジャー、チームメンバーの役割 †
プログラム・マネジャー、プログラム・チームメンバーは何をするのか。
分割パターン †
- チームメンバーはプログラムの初期段階から参加。
- プログラムマネジャーと一緒に計画を立てる。
- プロジェクトが発足すると、プロジェクトの中心メンバーとして加わる。
- 発注する場合は、ユーザー側ならカウンターパーソンのような役割に就く。
段階的パターン †
- チームメンバーは技術やノウハウを引き継いでいく人たち
- 中核メンバーは、計画段階からアサインする必要がある。
イノベーション・パターン †
- チームメンバーはコアとなる技術を持つ人で、いわゆる「尖った人」となるケースが多い。
- プログラム・マネジャーは、こうしたチームメンバーをどのように活用するか考える。
7大テーマ †
各プロジェクトをまとめるには、以下が必要
- 権限やコミュニケーション力、
- そして何にも増して意思決定力
明確なビジョンを持つ †
プログラム成功の鍵となる。
- プログラムは長期にわたるため、プログラムを取り巻く市場環境が大きく変わりやすい。
- それに伴って計画も大きく変動するが、この際、明確なビジョンが拠り所になる。
ベネフィットを追求する †
- プロジェクト・マネジメントは「プロフィット」を追求する。
- プログラム・マネジメントは「ベネフィット」を追求しなければならない。
- モノを作る過程だけでなく、プロジェクトやプログラムを通じて
作り出されたモノがビジネスの役に立つかどうかが評価の対象となる。
- 市場の拡大や競争力強化、ビジネスプロセスの改善、運用改善などを達成しなければならない。
- 直接金銭的な価値に結びつくものばかりではないのでベネフィットと呼ばれる。
多くのステークホルダーを巻き込む †
ステークホルダーマネジメントを行う。
- プロジェクトに比べてステークホルダーの数と種類が圧倒的に増える
- ステークホルダーごとにプログラムへの期待やニーズ、影響力などがそれぞれ異なる。
ガバナンスを利かせる †
「フェーズゲート」でプログラム傘下のプロジェクトにガバナンスを利かせる。
- 目的はビジョンやミッションからの逸脱防止やリスク軽減、経営的な利益最大化である。
- プログラムやプロジェクトをいくつかのフェーズに分け、次フェーズに移るときにゲートを設ける。
- 各ゲートでは、プログラムの立場からプロジェクトの「ゴー」「ノーゴー」の判定を下す。
- 「ゴー」
- 「ノーゴー」
「指摘された懸念事項や問題を解決してから進みなさい」という意味。
- プロジェクトの打ち切り。
- 「ストップ」
混乱しているときに止めて立て直させる場合
- 「ターミネート」
本当に打ち切る場合
- 経営やポートフォリオの立場からプログラムをモニタリング、コントロールする階層
- 期や年度の切り替わり、あるいは予算時期や重要なプロジェクトの開始/終了時期など、プログラムの節目に開催。
- 満たしているかどうかの意思決定は「マネジメントデシジョンボード」や「ガバナンスボード」と呼ばれる委員会で行う。
- プログラムの立場からプロジェクトをモニタリング、コントロールする階層
- プログラム内のプロジェクトの計画完了や設計完了などの時期に開催する。
- こちらのは、プログラムマネジャーが意思決定する。問題があればマネジメントデシジョンボードなどにエスカレーションする。
プラスのリスクに対処する †
- リスクとは振れ幅のこと。
- マイナスのリスクは押さえる一方、
- プラスのリスクを活かしていく
のが基本。
- リスク・マネジメントのやり方自体は、プロジェクト・マネジメントと変わりはない。
- リスク要因を洗い出し
- 影響度などを分析して優先順位を付け
- リスクへの対応策を検討する。
- 変わるのは、ベネフィットに影響を与えるリスク要因が対象になる点。
- 経済的な指標だけでなく
- ビジネスの役に立つかどうかがマネジメント対象となる。
残資金に目を向ける †
- コスト・マネジメント
プロジェクトマネジメントの場合、
- ユーザー側であれば予算金額を
- ベンダー側であれば受注金額を
ベースラインとしてコスト・マネジメントすればよかった。
- フィナンシャル・マネジメント
プログラムの場合、フィナンシャル・マネジメントが必要になる。
- プログラムを継続するための予算化や資金調達を自らやる必要がある。
- ITプロジェクトの場合、ファンドを募るようなケースは稀で、利用部門が予算化。
- 大規模なプログラムでは潤沢な資金が不可欠。
- 各プロジェクトの見積もりと資金繰りに目を向けて、
資金がショートしないように残資金を管理する。
- フィナンス（資金調達）に関する知識やスキルが必要。
支援体制（PMO）を作る †
プログラムマネジメントオフィス（PMO）の役割
- 二つめは、
影響力を持つステークホルダーへのレポート作成。
- プログラムは長期にわたるケースが多いので、フェーズゲートを形骸化させない仕組みが必要。
- これをプログラムマネジメントオフィスが担い、経営幹部など出席者のアサインや会議室/日程確保などを行う。
- その他の役割
各プロジェクトの
- 参加メンバーの育成
- ITアーキテクチャ検討
- ITインフラ整備
- 各種手法・ツールの標準化・推進
- ナレッジや教訓の吸い上げ、横展開
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
