「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
立上プロセスの主要な役割 †
プロジェクトを承認し、組織の資源をプロジェクトに割り当てる権限をPMに与える。
プロジェクトの開始点 †
マネジメント・スキル †
- コミュニケーション
- 経営陣
- スポンサー（オーナー、イニシエータ、顧客であることもある）
- ステークホルダー
インプット・アウトプット †
プロジェクトの発生 †
立上とは †
以下を公式に承認する。
- 新規プロジェクト、既存プロジェクトの次フェーズが開始されること。
- 資源を上記の開始されたプロジェクトに投入する必要があること。
ニーズと要求 †
- PMBOKによれば、7つの「ニーズと要求」の内の
１つが発生した結果、プロジェクトは生まれる。
- これらは、
- ビジネス機会 / ビジネス・ニーズ、問題解決に結び付く。
- また、プロジェクトのリスクにも結び付く。
- 経営陣は、これらのニーズと要求にどう対応するか、
決定する必要がある（これがプロジェクト立上の契機になる）。
市場の需要 †
戦略的 / ビジネス・ニーズ †
- 例
- 処理性能の高いコールセンタが基幹業務に必要
→ サービスの応答時間が悪くなることが収益に影響するため。
顧客要求 †
- 顧客が明確に要求する。
- 顧客には組織内の顧客と組織外の顧客がいる。
- 市場の需要よりミクロ
- 例
技術的進歩 †
- 問題はソレを解決する手段が登場して初めて問題と認識される。
- 技術的進歩が問題解決をする場合、その導入がプロジェクトに繋がる。
- 例
業務にXXXを導入
- 衛星通信
- モバイル端末
- タッチ・スクリーン
- 動画ストリーミング
- , etc.
法的要件 †
- 新しい法案が可決される毎に、
政府・民間共にプロジェクトを立ち上げる。
- 例
- マイナンバー
- 消費税の引き上げ
- 医療関連の新しい法律の制定
- 食品の産地・原料・カロリー・許容摂取量など表示の義務付け。
環境への配慮 †
社会的ニーズ †
フィージビリティ・スタディ †
プロジェクトが実行可能であるかどうかを判断する。
- 技術面で
- 実現可能か？
- 信頼性は高いか？
- 既存体制への組み込みが可能か？
- タイミング
- 別プロジェクトとして実施
- サブ・プロジェクトとして実施
- 第一フェーズで実施
- 実施チーム
プロジェクトに携わらない（偏見の無い）チームが実施する。
- 評価
会議を実施
- 顧客
- スポンサー（オーナー、イニシエータ）
- 専門家
- 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 %。
インプット †
プロジェクト作業範囲記述書 †
プロジェクト作業範囲記述書 = プロジェクトSOW（Statement Of Work）
- 作成者
- 内部プロジェクト : スポンサー（オーナー、イニシエータ）
- 外部プロジェクト : 購入者（プロジェクトをPMに発注した顧客）
- 戦略計画を考慮する。
企業の戦略計画とプロジェクトの関係
ビジネス・ケース †
- ビジネス・ニーズを理解し投資に価値があるかを判断するための文書。
- ビジネス・ケースの承認
- プロジェクト憲章作成プロセス開始のきっかけになる。
- ビジネス・ケースの承認アクティビティは、プロジェクト外部で行われる。
合意書 †
- プロジェクトの意図を定義した＝合意書が、
実施条件や、期間、作業、などの記述のために利用される。
- その他
- 了解事項の覚書（MOU）
- 電子メール
- 政府間協定
- 口頭約束
組織体の環境要因 †
- 多数のフェーズ、プロセス群でのインプットになる。
- プロジェクトの成否を左右するプロジェクトの外部要因を指す。
- PMBOKによると、環境要因には以下の項目がある。
- 組織外要因
- 国家標準 / 業界標準
- 政治情勢
- 市場状況
- ステークホルダーのリスク許容度
- 組織内要因
- 人事管理
- 組織文化、体制、ガバナンス
- 企業の作業認可システム
- 組織内コミュニケーション・チャネル
組織のプロセス資産 †
- プロセスと手順
組織の作業実施の方針/指針/手順/計画/手法/標準で、多数ある。
- プロジェクトに影響を与える広範囲の要素
- プロジェクト・マネジメント方針、安全方針、
コンフィギュレーション・マネジメント（構成管理、形態管理、変更管理）
パフォーマンス測定手順、リスク・コントロール手順、作業認可手順、
- 企業知識ベース
過去のプロジェクト情報から失敗を回避し、成否を左右する。
計画プロセス群の、プロジェクト憲章、プロジェクト・マネジメント計画書、
スコープ記述書、アクティビティ定義/見積の作成などで役立つ。
- 過去の学習情報・保管方法。過去情報（知識資源）。
- 教訓、問題と欠陥、各種ノウハウ、プロジェクト・ファイル、
プロセス測定データベース、財務データ（予算、コスト）。
プロセス（ツールと技法） †
専門家の判断 †
- 多数のフェーズ、プロセス群でも、ツールと技法として使用される。
- 主に、インプットの評価を行う。
- 専門家（個人/グループ）
- プロジェクト・メンバ（ステークホルダー/コンサルタント、過去のチームメンバ）
- 組織内（組織内の他部門、PMO、・・・）
- 組織外（当該分野専門家、業界の専門家、専門家集団、技術機関）
ファシリテーション技法 †
多数のフェーズ、プロセス群でも、ツールと技法として使用される。
- ブレーンストーミング
- コンフリクトの解消
- 問題解決
- 開示のマネジメント
主要なステークホルダー †
主要なステークホルダーを早期に特定して、
プロジェクト憲章作成に参加してもらう。
- プロジェクトマネージャー
- プロジェクトの成功に対して責任を負う人。
- できるだけ早い段階で特定すべき。
（プロジェクト憲章作成には参画すべき。）
- ただし、プロジェクト憲章の作成に参画しても、作成者の欄に、
記名しない（作成者が自身に権限付与することになるため）。
- プロジェクトの計画後に各作業を実行しマネジメントする。
- プロジェクトの標準と方針を設定し、プロジェクト・チームとステークホルダーに伝える。
- コミュニケーションと文書に習熟し、関係者に情報を絶えず提供する。
文書：要求事項、コスト、アクティビティ、パフォーマンス評価の尺度
関係者：プロジェクト・スポンサー、プロジェクト・チーム、その他。
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）
- プロジェクト・スポンサーも一般的なスポンサーと同様に、
ステークホルダーと経営陣の支持を取り付け、強力な推進者となる。
- また、プロジェクトの最終的な権威者および意思決定者である。
- 突き詰めるとPMと同じく、プロジェクトを成功に導く責任を負う。
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）は、
- 通常は、組織内の論争や対立に決着をつける権力・権限を持った経営幹部。
- プロジェクト位置付けの向上のため、プロジェクトの宣伝活動を継続的に行う。
- プロジェクトにスポットライトを当てて、プロジェクトの一切を取り仕切る（資金、成果）。
- フェーズ毎の関わり
- 立上・計画フェーズには積極的に関わる。
- 実行、監視・制御フェーズでは関わりは減り、問題発生時の意思決定を行う。
- 機能部門マネージャ
- 組織の管理業務に従事する。
- 部下をプロジェクトに提供、割り当て、パフォーマンス・レビューを行う。
- 以下の機能部門マネージャは、プロジェクト憲章作成で特定しておいた方がイイ。
- プロジェクトのタスクに携わる。
- プロジェクトの責任が割り当てられている。
アウトプット †
プロジェクト憲章 †
- プロジェクト憲章には、経営陣やステークホルダーが読める、
ハイレベル（概要）のニーズと要求が文書化される。
- 目的または妥当性
ビジネス機会、ビジネスニーズ、問題解決
- プロダクト / サービス / 所産に関する記述
- （顧客の所産に対する）要求事項
- ステークホルダーの期待
- 測定可能なプロジェクト目標、成功基準
- プロジェクト
- 記述と境界
- 開始日 / 終了予定日
- 前提条件 / 制約条件
- リスク
- 承認要求事項
成否の判断材料（事項）と、成否を判断する人、受け入れの承認者。
- 人
- ステークホルダー一覧
- プロジェクト憲章を認可する人名と地位
- 任命されたプロジェクト・マネージャと責任/権限
- これにより、ステークホルダーの期待をプロジェクトの
に反映することができる。
- PMBOKガイドには、プロジェクト憲章は、
- プロジェクトを依頼する組織
- プロジェクトを遂行する組織
との間に、協力関係を形成すると書かれている。
- このため、必ず計画プロセス群を開始する前に実行する。
- また、反復プロセスにより署名含め内容を改訂する事も可能。
公式化と発行 †
プロジェクトの存在は承認済みのプロジェクト憲章という公式な書面によって承認/確認される。
- 承認プロセス
- （キックオフ・ミーティングなどで）
プロジェクト憲章の内容に合意後、署名してもらう。
- この後に、プロジェクト憲章が公式文書として発行される。
- コピーなど印刷物として配布
- Eメールやイントラネットで電子形式で配信
- 署名者
- 上級管理職（立上の人物/組織）
- プロジェクト・スポンサー（オーナー、イニシエータ、顧客であることもある）
- 承認の結果
- 組織にプロジェクトを紹介するために利用できる。
- 組織の資源をプロジェクトに割り当てる権限をPMに与える。
- プロジェクトの諸作業を組織の定常業務に結び付ける。
ステークホルダー特定 †
- プロジェクトの成功はステークホルダーの期待に応えること。故に、
- 早い段階でステークホルダーとの協力関係を築けば、プロジェクトが遂行しやすくなる。
- ステークホルダーの役割を理解することがプロジェクト・マネジメントに重要になる。
- このため、ステークホルダー特定を行う。
- できるだけ早い段階で行う。また、継続的に行う。以下に注意する。
- 主要なステークホルダー含め、プロジェクト期間中に変動することがある。
- ステークホルダーによって難易度が変わる。
- 主要なステークホルダーの特定は容易。
- 上記以外の利害関係者というステークホルダーの特定は難しくなることがある。
インプット †
関連するステークホルダー、事業部門の名称が記されていることがある。
調達文書 †
関連するステークホルダー、事業部門の名称が記されていることがある。
このプロセス中で特に注意を払う必要がある項目。
- 組織構造
影響力と権力を持っている人を、所属部門の地位から特定するのに役立つ。
このプロセス中で特に注意を払う必要がある項目。
プロセス（ツールと技法） †
ステークホルダー分析 †
- プロジェクト期間中に定期的に見直し、必要に応じて更新する。
- プロジェクト全期間に渡って、ステークホルダーの関心ごとや期待を分析する。
- 特に影響力の強いステークホルダーの関心・期待の特定は満足度のマネジメントに役立つ。
- 分析の対象
- ステークホルダーのプラス or マイナスの影響力の分析
- ステークホルダーの関心・期待、ニーズ、要望（要求事項）を理解
- 理解
プロジェクトの所産により、得るものと失うものを持っている故に、
- ステークホルダー同士、協力関係や対立関係がありお互いに影響を与えあう。
- プロジェクトに強い関心を持ち、プロジェクトの結果に大きな影響を与える人または組織がある。
- １：潜在的なステークホルダーを特定し、一般的な情報を収集する。
- 部署、連絡先情報（電話番号、メアド）、知識レベル、期待、影響レベル
- これらをステークホルダー登録簿のテンプレートに記入。
- ２：ステークホルダーの潜在的な影響力とプロジェクトへのサポートを、
以下を使用して明らかにする。
- グリッド（ｘ軸 → ｙ軸）
（１）権限→関心度
（２）関心度→関与度
（３）関与度→影響度
- 突出モデル
権力、（参画の）正当性、緊急度（注意を払う頻度：即時/随時/稀）
- ３：ステークホルダーの様々な状況への反応と影響の評価
過去プロジェクトでの行動（について非公式インタビュー）等を行い評価。
以下に対するプロファイリングと分析
アウトプット †
ステークホルダー登録簿 †
PMBOKガイドによれば、以下が記載されている必要がある。
- 評価情報
- 影響力
- 背景：関心・期待、ニーズ、要望（要求事項）
- 重要な参画時期に関する要素
- ステークホルダー分類
- 組織の内部 / 外部
- プロジェクトに肯定的 / 中立 / 否定的
戦略（ステークホルダーに対する対処に関する機密情報）
→ 一部のステークホルダーは、プロジェクト文書にアクセスできるので、
この機密情報が、公になる可能性がある点に注意を払う必要がある。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
