「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
立上プロセスの主要な役割 †
プロジェクトを承認し、組織の資源をプロジェクトに割り当てる権限をPMに与える。
プロジェクトの開始点 †
マネジメント・スキル †
- コミュニケーション
- 経営陣
- スポンサー（オーナー、イニシエータ、顧客であることもある）
- ステークホルダー
インプット・アウトプット †
プロジェクトの発生 †
立上とは †
以下を公式に承認する。
- 新規プロジェクト、既存プロジェクトの次フェーズが開始されること。
- 資源を上記の開始されたプロジェクトに投入する必要があること。
ニーズ評価 †
フィージビリティ・スタディ †
プロジェクトが実行可能であるかどうかを判断する。
- 技術面で
- 実現可能か？
- 信頼性は高いか？
- 既存体制への組み込みが可能か？
- タイミング
- 別プロジェクトとして実施
- サブ・プロジェクトとして実施
- 第一フェーズで実施
- 実施チーム
プロジェクトに携わらない（偏見の無い）チームが実施する。
- 評価
会議を実施
- 顧客
- スポンサー（オーナー、イニシエータ）
- 専門家
- PM（※ 役割に含まれないが参加することはある。）
※「初めての試み」などの場合は、特に重要になる。
プロジェクト選定と評価 †
選定プロセスは、フィージビリティ・スタディと同様に、
- 以下に責務が有る。
- 顧客
- スポンサー（オーナー、イニシエータ、顧客であることもある）
- 専門家
評価プロセス †
- 組織の大半は、選定、優先度付けに関する
公式、準公式の評価プロセスを持っている。
- 例
- 会計年度の始まる前の予算立案時期に
選定委員会はプロジェクト案の提出を求める。
- 評価
会議を実施
- 顧客
- スポンサー（オーナー、イニシエータ、顧客であることもある）
- 専門家
- PM（※役割に含まれないが参加することはある。）
- プロジェクト・リストに追加される。
- 正式に文書化される。
- 選定委員会に、月次進捗報告を行う。
プロジェクト評価方法 †
下記の要因でプロジェクトによって評価手法は異なる。
プロジェクト選定手法 †
- 測定の軸
経営者の戦略的目標とのマッピンク
- マーケットシェア
- 金銭的利益
- 投資収益率
- 顧客維持率
- 顧客忠誠度
- 社会通念
- プロジェクト選定手法
プロジェクト選定手法には、以下の2つ区分がある。
- 数学的モデル（算定技法、制約条件付き最適化法）
工学、統計学、数学の知識が必要。以下のアルゴリズムを使用する。
- 線形計画法
- 動的計画法
- 整数計画法
- 非線形計画法
- 多重目的計画法
- 利益測定法（意思決定モデル）
- 成果物（プロダクト / サービス / 所産）の利点・利益を検討する。
- 大半のプロジェクトではこちらを採用する。
- 費用便益法、得点モデル、キャッシュ・フロー分析手法などがある。
- 大規模・複雑なプロジェクトでは複数の利益測定法を組み合わせて使用する。
- 得点モデル（重み付け得点モデル）
- 選定委員会で得点モデル（重み付け得点モデル）の基準を作成する。
- 基準の例：市場性、見込利益、開発力 / 生産力、サポート力
| # | 基準 | 重み | Pj1の得点 | Pj1の総得点 | Pj2の得点 | Pj2の総得点 | Pj3の得点 | Pj3の総得点 |
| 1 | 市場性 | 5 | 5 | 25 | 5 | 25 | 3 | 15 |
| 2 | 見込利益 | 4 | 4 | 16 | 3 | 13 | 4 | 16 |
| 3 | 開発力 / 生産力 | 3 | 4 | 12 | 3 | 9 | 2 | 6 |
| 4 | サポート力 | 2 | 4 | 8 | 3 | 6 | 4 | 8 |
| - | 合計 | - | - | 61 | - | 53 | - | 45 |
- キャッシュ・フロー分析手法
様々な、キャッシュ・フロー分析手法があるが、
「回収期間分析」は精度が低く、「正味現在価値」は堅実、
「正味現在価値」と「内部収益率（IRR）」は結論が同じになる。
- 回収期間分析
（初期投資と製品寿命までのキャッシュ・インフローから）回収期間を分析する。
しかし、将来のキャッシュ・インフローの価値（割引率：資本コスト分、下がる）を考慮しないので精度が低い。
- 割引キャッシュ・フロー
将来受け取る現金は、現在の現金より価値が割引率（資本コスト）分、低くなることを考慮に入れる。
以下の2番目の式を使用し、例えば、ｘ年でｙ円を稼ぐ2つのプロジェクトを比較する。
n
FV = PV ( 1 + i )
FV
PV = ------------
n
( 1 + i )
FV : 初期投資の将来の価値, PV : 初期投資の現在の価値, i : 利率, n : 期間の数
割引率（資本コスト）12 %,
2年で10万円 = 10/(1.12)^2 = 7.97万円,
3年で12万円 = 12/(1.12)^3 = 8.54万円
PV（初期投資の現在の価値）が高い方がイイ
- 正味現在価値（NPV : Net Present Value）
割引キャッシュ・フローのように均等割りではなく期間ごとに評価（≒利回り）。
NPV（正味現在価値）は高い方がイイ（プラスになれば、資本コスト以上の収益を上げていることになる）。
Pj1>
| 期間 | FV | PV |
| 1 | 10,000 | 10,000/(1.12)^1 = 8,929 |
| 2 | 15,000 | 15,000/(1.12)^2 = 11,958 |
| 3 | 5,000 | 5,000/(1.12)^3 = 3,559 |
| 期間合計 | 30,000 | 8,929 + 11,958 + 3,559 = 24,446 |
| 初期投資 | － | 24,000 |
| NPV | － | +446 |
Pj2>
| 期間 | FV | PV |
| 1 | 7,000 | 7,000/(1.12)^1 = 6,250 |
| 2 | 13,000 | 13,000/(1.12)^2 = 10,364 |
| 3 | 10,000 | 10,000/(1.12)^3 = 7,118 |
| 期間合計 | 30,000 | 6,250 + 10,364 + 7,118 = 23,732 |
| 初期投資 | － | 24,000 |
| NPV | － | -268 |
※ 割引率（資本コスト）12 %。
プロジェクト・マネジメント・ビジネス文書（6版） †
- ビジネス・ニーズを理解し投資に価値があるかを判断するための文書。
- 承認
- プロジェクト憲章作成プロセス開始のきっかけになる。
- 承認アクティビティは、プロジェクト外部で行われる。
プロジェクト・ビジネス・ケース †
ビジネスの理解 †
ニーズ評価を行い、
などをまとめる。
提案の文書化 †
経済的な実現可能性検討を文書化したもの。
- 状況分析：プロジェクトを取り巻く状況
- ≒ビジネス・ニーズ
- 問題と好機の特定
- 遂行能力に関するギャップ分析
- リスクの特定
- 重要成功要因の特定
プロジェクト・ベネフィット・マネジメント計画書 †
概要 †
プロジェクトから得られるベネフィットの
をさせるための、プロセスを定義した記述書。
主要要素 †
- 目標ベネフィット
- 戦略との成功性
- 時間枠（短期/中期/長期）
- ベネフィット・オーナー
（プロダクト・オーナー）
- 評価尺度
- 前提知識
- リスク
インプット †
プロジェクト作業範囲記述書 †
プロジェクト作業範囲記述書 = プロジェクトSOW（Statement Of Work）
- 作成者
- 内部プロジェクト : スポンサー（オーナー、イニシエータ）
- 外部プロジェクト : 購入者（プロジェクトをPMに発注した顧客）
- 戦略計画を考慮する。
企業の戦略計画とプロジェクトの関係
合意書 †
- プロジェクトの意図を定義した＝合意書が、
実施条件や、期間、作業、などの記述のために利用される。
- その他
- 了解事項の覚書（MOU）
- 電子メール
- 政府間協定
- 口頭約束
プロセス（ツールと技法） †
専門家の判断 †
- 多数のフェーズ、プロセス群でも、ツールと技法として使用される。
- 主に、インプットの評価を行う。
- 専門家（個人/グループ）
- プロジェクト・メンバ（ステークホルダー/コンサルタント、過去のチームメンバ）
- 組織内（組織内の他部門、PMO、・・・）
- 組織外（当該分野専門家、業界の専門家、専門家集団、技術機関）
ファシリテーション技法 †
多数のフェーズ、プロセス群でも、ツールと技法として使用される。
- ブレーンストーミング
- コンフリクトの解消
- 問題解決
- 開示のマネジメント
主要なステークホルダー †
主要なステークホルダーを早期に特定して、
プロジェクト憲章作成に参加してもらう。
- プロジェクトマネージャー
- プロジェクトの成功に対して責任を負う人。
- できるだけ早い段階で特定すべき。
（プロジェクト憲章作成には参画すべき。）
- ただし、プロジェクト憲章の作成に参画しても、作成者の欄に、
記名しない（作成者が自身に権限付与することになるため）。
- プロジェクトの計画後に各作業を実行しマネジメントする。
- プロジェクトの標準と方針を設定し、プロジェクト・チームとステークホルダーに伝える。
- コミュニケーションと文書に習熟し、関係者に情報を絶えず提供する。
文書：要求事項、コスト、アクティビティ、パフォーマンス評価の尺度
関係者：プロジェクト・スポンサー、プロジェクト・チーム、その他。
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）
- プロジェクト・スポンサーも一般的なスポンサーと同様に、
ステークホルダーと経営陣の支持を取り付け、強力な推進者となる。
- また、プロジェクトの最終的な権威者および意思決定者である。
- 突き詰めるとPMと同じく、プロジェクトを成功に導く責任を負う。
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）は、
- 通常は、組織内の論争や対立に決着をつける権力・権限を持った経営幹部。
- プロジェクト位置付けの向上のため、プロジェクトの宣伝活動を継続的に行う。
- プロジェクトにスポットライトを当てて、プロジェクトの一切を取り仕切る（資金、成果）。
- フェーズ毎の関わり
- 立上・計画フェーズには積極的に関わる。
- 実行、監視・制御フェーズでは関わりは減り、問題発生時の意思決定を行う。
- 機能部門マネージャ
- 組織の管理業務に従事する。
- 部下をプロジェクトに提供、割り当て、パフォーマンス・レビューを行う。
- 以下の機能部門マネージャは、プロジェクト憲章作成で特定しておいた方がイイ。
- プロジェクトのタスクに携わる。
- プロジェクトの責任が割り当てられている。
アウトプット †
プロジェクト憲章 †
- プロジェクト憲章には、経営陣やステークホルダーが読める、
ハイレベル（概要）のニーズと要求が文書化される。
- 目的または妥当性
ビジネス機会、ビジネス・ニーズ、問題解決
- プロジェクト
- 記述と境界
- 開始日 / 終了予定日
- 前提条件 / 制約条件
- リスク
- 承認要求事項
成否の判断材料（事項）と、成否を判断する人、受け入れの承認者。
- 人
- ステークホルダー一覧
- プロジェクト憲章を認可する人名と地位
- 任命されたプロジェクト・マネージャと責任/権限
- これにより、ステークホルダーの期待をプロジェクトの
に反映することができる。
- プロジェクト憲章は、
- プロジェクトを依頼する組織
- プロジェクトを遂行する組織
との間に、協力関係を形成すると書かれている。
- このため、必ず計画プロセス群を開始する前に実行する。
- また、反復プロセスにより署名含め内容を改訂する事も可能。
前提条件ログ †
- ハイレベルの戦略的、業務上の前提条件・制約条件をプロジェクト憲章に反映。
- ライフサイクル全ての前提条件・制約条件を記録する。
公式化と発行 †
プロジェクトの存在は承認済みのプロジェクト憲章という公式な書面によって承認/確認される。
- 承認プロセス
- （キックオフ・ミーティングなどで）
プロジェクト憲章の内容に合意後、署名してもらう。
- この後に、プロジェクト憲章が公式文書として発行される。
- コピーなど印刷物として配布
- Eメールやイントラネットで電子形式で配信
- 署名者
- 上級管理職（立上の人物/組織）
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）
- 承認の結果
- 組織にプロジェクトを紹介するために利用できる。
- 組織の資源をプロジェクトに割り当てる権限をPMに与える。
- プロジェクトの諸作業を組織の定常業務に結び付ける。
ステークホルダー特定 †
- プロジェクトの成功はステークホルダーの期待に応えること。故に、
- 早い段階でステークホルダーとの協力関係を築けば、プロジェクトが遂行しやすくなる。
- ステークホルダーの役割を理解することがプロジェクト・マネジメントに重要になる。
- このため、ステークホルダー特定を行う。
- できるだけ早い段階で行う。また、継続的に行う。以下に注意する。
- 主要なステークホルダー含め、プロジェクト期間中に変動することがある。
- ステークホルダーによって難易度が変わる。
- 主要なステークホルダーの特定は容易。
- 上記以外の利害関係者というステークホルダーの特定は難しくなることがある。
インプット †
関連するステークホルダー、事業部門の名称が記されていることがある。
関連するステークホルダー、事業部門の名称が記されていることがある。
このプロセス中で特に注意を払う必要がある項目。
- 組織構造
影響力と権力を持っている人を、所属部門の地位から特定するのに役立つ。
このプロセス中で特に注意を払う必要がある項目。
プロセス（ツールと技法） †
ステークホルダー分析 †
- プロジェクト期間中に定期的に見直し、必要に応じて更新する。
- プロジェクト全期間に渡って、ステークホルダーの関心ごとや期待を分析する。
- 特に影響力の強いステークホルダーの関心・期待の特定は満足度のマネジメントに役立つ。
- 分析の対象
- ステークホルダーのプラス or マイナスの影響力の分析
- ステークホルダーの関心・期待、ニーズ、要望（要求事項）を理解
- 関与レベル
- 不認識：関与していない。
- 抵抗：支持しない。若しくは強い抵抗の可能性がある。
- 中立：支持・抵抗なし。関与度合いは低い可能性がある。
- 支持：前向きの期待。関与による支持がある。
- 指導：積極的な関与により、成功を手助けする。
| # | | 不認識 | 抵抗 | 中立 | 支持 | 指導 |
| 1 | ステークホルダーA | | 現在のレベル | | 望ましいレベル | |
| 2 | ステークホルダーB | | | 現在のレベル | | 望ましいレベル |
| 3 | ステークホルダーC | | | | | 現在のレベル |
- 理解
プロジェクトの成果物（プロダクト / サービス / 所産）により、得るものと失うものを持っている故に、
- ステークホルダー同士、協力関係や対立関係がありお互いに影響を与えあう。
- プロジェクトに強い関心を持ち、プロジェクトの結果に大きな影響を与える人または組織がある。
- １：潜在的なステークホルダーを特定し、一般的な情報を収集する。
- 部署、連絡先情報（電話番号、メアド）、知識レベル、期待、影響レベル
- これらをステークホルダー登録簿のテンプレートに記入。
- ２：ステークホルダーの潜在的な影響力とプロジェクトへのサポートを、
以下を使用して明らかにする。
- グリッド（ｘ軸 → ｙ軸）
（１）権限→関心度
（２）関心度→関与度
（３）関与度→影響度
- 突出モデル
権力、（参画の）正当性、緊急度（注意を払う頻度：即時/随時/稀）
- ３：ステークホルダーの様々な状況への反応と影響の評価
過去プロジェクトでの行動（について非公式インタビュー）等を行い評価。
- 上級管理職
- 主要なステークホルダー
- ステークホルダーと仕事をした経験のあるPM
- コンサルタントや業界の専門家
以下に対するプロファイリングと分析
アウトプット †
ステークホルダー登録簿 †
以下が記載されている必要がある。
- 評価情報
- 影響力
- 背景：関心・期待、ニーズ、要望（要求事項）
- 重要な参画時期に関する要素
- ステークホルダー分類
- 組織の内部 / 外部
- プロジェクトに肯定的 / 中立 / 否定的
戦略（ステークホルダーに対する対処に関する機密情報）
→ 一部のステークホルダーは、プロジェクト文書にアクセスできるので、
この機密情報が、公になる可能性がある点に注意を払う必要がある。
プロジェクト・マネジメント計画書更新版 †
必要に応じて更新する。
プロジェクト文書更新版 †
必要に応じて更新する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
