.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

立上プロセス群の試験対策

詳細

立上の流れ

立ち上げの要因

※ ここはPMBOKの立上ではない。

ニーズと要求、ビジネス・ニーズなどと呼ばれる。

↓ ↓ ↓

戦略計画

※ ここはPMBOKの立上ではない。

↓ ↓ ↓

ニーズ評価

※ ここはPMBOKの立上ではない。

ニーズ評価

  • フィージビリティ・スタディ
  • プロジェクト選定と評価

のアウトプットはプロジェクト憲章とも言われる。

↓ ↓ ↓

プロジェクト・マネジメント・ビジネス文書

※ ここはPMBOKの立上ではない。

↓ ↓ ↓

プロジェクト憲章作成

※ ここからPMBOKの立上プロセス群。

↓ ↓ ↓

  • プロジェクト作業範囲記述書、プロジェクトSOW ← 戦略計画、プロダクト・スコープ記述書
    • 契約に基づくプロジェクト ≒ 内部プロジェクトでは、購入者が用意する。

↓ ↓ ↓

  • プロジェクト憲章
    • プロジェクト・スポンサーが発行する(ステークホルダーの連名ではない)。

ステークホルダー特定

  • ステークホルダー登録簿
    • 識別情報
    • 分類情報
    • 評価情報
  • ポイント
    • 芋蔓式に特定できる。
    • 優先順位は付けても絞らない。
    • 優先順位 ≒ 影響度 ≠ 突出
      (突出していなくても影響度あるステークホルダーは居る?
    • ステークホルダー分析 > 分類(権力とXXXのグリッド

基礎知識

実現可能性(フィージビリティ)

選定の際に最も重要になるのは実現可能性(フィージビリティ)

  • ≒ビジネス・ケース
  • F/Sと略記される。
  • などがある。
    • 実行可能性調査
    • 企業化調査
    • 投資調査
    • 採算性調査
  • 業種
  • 製造業
    プロセス、設計、手順、またはプランが
    正常に必要なタイムフレームで実行できるという判断
  • ...

プロジェクト選定手法

実現可能性(フィージビリティ)の
投資調査、採算性調査に含まれる様な内容。

  • 数学的モデル(算定技法、制約条件付き最適化法)
    • 線形計画法
    • 動的計画法
    • 整数計画法
    • 非線形計画法
    • 多重目的計画法

コストとスケジュール

立ち上げフェーズ

選択肢の絞り込み

キャッシュ・フロー分析手法

  • 回収期間分析
  • 割引キャッシュ・フロー
  • 正味現在価値(NPV : Net Present Value)
  • 内部収益率(IRR : Internal Rate of Return)

ステークホルダー分析、分類

  • 突出モデル(セイリエンス・モデル)
    • 権力
    • 正当性
    • 緊急度
  • 権力とXXXのグリッド
    • 権力と、(→)関心度
    • 権力と、(関心度→)関与度
    • 権力と、(関与度→)影響度
  • ステークホルダー可能性グリッド
    • 横軸:妨害する可能性
    • 縦軸:支援する可能性
  • ステークホルダー・キューブ(6)
    • 横軸:妨害する可能性
    • 縦軸:支援する可能性
    • 奥行:姿勢(肯定的か否定的)

似たような言葉

ビジネス云々

  • アプトプット
    • プロジェクト・マネジメント・ビジネス文書(6版)
      • プロジェクト・ビジネス・ケース
        ビジネス・ニーズ
      • プロジェクト・ベネフィット・マネジメント計画書
  • 用語
    • シーズ(種)
    • > ニーズ(想い)
    • > ウォンツ(意欲)
    • > デマンド(需要)
    • > ベネフィット(提供された価値)

ポートフォリオ・マネジメント、OPM

  • OPM
    • 母体組織の戦略的目標を達成する。
    • PPP (Project, Program and Portfolio)を対象とする。

XXX要件、XXX要求

  • 測定 / 追跡 / テストが可能であるものであること。
  • 要求には、以下のカテゴリーがある。
  • ビジネス
  • ステークホルダー
  • ソリューション
  • 機能
  • 非機能
  • 移行
  • プロジェクト
  • 品質
  • 非機能要件要求
  • 日本情報システムユーザー協会(JUAS)
    非機能要件要求仕様定義ガイドライン
    • 機能性
    • 信頼性
    • 使用性
    • 効率性
    • 保守性
    • 移植性
    • 障害抑制性
    • 効果性
    • 運用性
    • 技術要件
  • システム基盤の発注者要求を見える化する非機能要求グレード検討会
    非機能要求グレード
    • 可用性
    • 性能・拡張性
    • 運用・保守性
    • 移行性
    • セキュリティ
    • 環境・エコロジー

前提条件と制約条件

  • 前提条件
    プロジェクト / ステークホルダーの本当だと信用できる情報(確定ではない)。
    • 制約条件を含まない。
    • 一般的に前提条件に見えるもの。≒ 目的に近いモノも含まれる。
    • また、プロジェクト計画の正確性も前提条件に含まれるようになる。
  • 制約条件
    • 契約条項や、スポンサーの指示など。
    • 三大制約条件(プロジェクト目標)≒ 範囲、時間、原価。
      • 範囲は意思決定の基準となる制約条件で、
      • 次いで、時間 > 原価となることが多い。
      • また、資源の調達は予め既知の範囲で限定しない。
  • 補足
    • 逆に覚えガチ。
    • プロセスの順序を考えると、前提条件から → 制約条件が生成される。
    • プロジェクト憲章作成時に特定され、前提条件ログに記録される。
    • 制約条件は、契約、PMBに含まれるイメージなので、制約条件ログと言うものは無い。

その他

プロジェクト・スポンサーって誰?

  • 立上の人物(オーナー、イニシエータ)
    • 社内プロジェクト:役員や上級管理職などの役職者。
    • 社外プロジェクト:顧客であることもある。

顧客とスポンサーの違い

  • 以下で呼び名が異なる。
    • 社内プロジェクトの立上の人物:スポンサー
    • 社外プロジェクトの立上の人物:顧客

組織内の立上の人物

社内プロジェクト、社外プロジェクト、どちらの場合も、
役員や上級管理職などの役職者とされている(PMの上司になる)。

ステークホルダー

  • 顧客とスポンサーはステークホルダーだが、
    ステークホルダーは、その他、ユーザなど、
    プロジェクトから±の影響を受ける人達。
  • なお、ステークホルダーの行動規範は、
    チーム憲章に記載される。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-03-10 (日) 16:46:09 (9d)