Skip to content

DNET_AdvancedAMProjectManagement

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

高度午前 - プロジェクト・マネジメント

概要

  • プロジェクト・マネジメント（高度：午前Ⅰ、午前Ⅱ）
  • 「PMP」が参考になる。

共通

ライフサイクル

段階的詳細化

初期段階では、不確実性が高い

影響力

  • 初期では、

    • プロジェクト・スポンサー
    • ステークホルダー

  • 終盤では

    • プロジェクト・マネージャー

プロジェクト要員

  • 中盤に最大になる。
  • 初期と終盤では少人数。

変更コスト

初期では低コスト、終盤では高コスト。

アジャイル

※ 元 Wiki では見出しのみで、本文は書かれていない。

利益測定法（意思決定モデル）

知識エリア

統合

プロジェクト憲章

プロジェクト開始の公式な承認

変更要求

  • あらゆる変更。

    • 要件、品質、スコープ、仕様、設計、文書の変更。
    • PMBからの乖離に関する対応、成果物の修正対応。

  • 発生と対応の

  • 対応を伴う場合

    • 是正処置
      PMBから乖離した状態から戻す。

    • 予防処置
      PMBから乖離しないように予防。

    • 欠陥修正
      成果物の問題の修正

    • 更新
      文書などの更新

※ PMB : Performance Measurement Baseline
　パフォーマンス測定ベースライン

アーンド・バリュー・マネジメント（EVM）

  • PMP：アーンド・バリュー（EV）

  • アーンド・バリュー・マネジメント（EVM）
    アーンド・バリューでマネジメント

  • アーンド・バリュー分析（EVA）
    アーンド・バリューを分析

  • アーンド・スケジュール（ES）
    価値ではなくスケジュールの観点で分析。

  • 差異分析と傾向分析

    • 差異分析
      EVAで計画値との差異を分析する。

    • 傾向分析
      EVAで継続的な比較により傾向を分析する。

範囲

構成管理の対象

（元 Wiki では「コチラが参考になる。」とあるが、リンク先の記載は無い）

スコープの変更

変更要求によって行う。

WBS (Work Breakdown Structure)

ローリングウェーブ計画法

アジャイルのスコープ

  • プロダクト・バックログ(PBL)
    プロダクトに必要な項目・作業をリスト化・順序付けして管理。

  • ユーザ・ストーリー
    ソフトウェアで実現したいことを顧客価値を明確表現して書き出す。

時間

クリティカル・パス、チェーン

パート技法

進捗管理のチャート類

※ トレンド・チャートは、

  • 縦軸が予算消化率
  • 横軸が開発期間

で、≒ EVM分析グラフ

スケジュール短縮

原価

IFPUG法

ファンクション・ポイントを用いた規模の見積もり方法

  • 以下、５つの機能を数える。

    • トランザクション・ファンクション

      • EI : 外部入力
      • EO : 外部出力
      • EQ : 外部参照

    • データ・ファンクション

      • EIF : 外部インターフェイスファイル
      • ILF : 内部論理ファイル

  • 上記の未調整FPに調整係数を乗じ、調整済みFPに変換する。

アジャイルの生産性

  • ベロシティ（PMP：監視・制御 - その他の該当節を参照）と言う。
  • 規模はストーリー・ポイント（PMP：実行の該当節を参照）と言う単位を用いる（相対的な量とされる）。

全体の生産性

  • 以下の条件下での全体の生産性

    • 工程毎の生産性（ステップ/人月）
      • 設計 : X ステップ/人月
      • 製造 : Y ステップ/人月
      • 試験 : Z ステップ/人月

  • （単位ステップあたりの）
    工程毎の生産性→工程毎の工数→全体の工数→全体の生産性

    • 工程毎の単位ステップあたりの工数（人月/ステップ）

      • 設計 : 1/X 人月
      • 製造 : 1/Y 人月
      • 試験 : 1/Z 人月

    • 全体の単位ステップあたりの工数（人月/ステップ）
      1/X + 1/Y + 1/Z

    • 全体の生産性（ステップ/人月）
      1 / (1/X + 1/Y + 1/Z)

開発コスト見積もり

  • 440時間の作業に40時間/週の寄与率で対応する場合

  • チーム開発では生産性が落ちる。

    • コミュニケーション・ロス

    • コミュニケーション・パス毎に
      ４時間 / 週で、１人辺りに換算すると２時間/週

    • 社員あたりのコストには差はない。

    • 上記以外の条件は無視できる。

  • 10人チームと１人開発時のコスト差

    • コミュニケーション・パスは１人９本で
    • コミュニケーション・ロスは１人9 * 2 = 18時間/週
    • 実作業時間は、40 → 40 - 18 = 22時間になるので、
    • コストは、40 / 22 = 1.81倍になる。

※ コミュニケーション・パス数もとめると
　訳が解らんくなるので１人辺りで計算。

資源

RACIチャート

要員割当

上級SEは初級SEと比べ、PG、UT工程で２倍の生産性らしい。
（当該工程で、上級SEが２倍ではなくて、初級SEが２分の一）

  • 工程見積もり
開発工程 見積もり工数
設計 ６
PG, UT １２
結合 １２
合計 30

  • 割当プラン

    • A
開発工程 要員：上級SE 要員：初級SE 工期
設計 ２ ０ ３
PG, UT ２ ２ ４ (2n+120.5n=12, n=4)
結合 ２ ０ ６
合計 30（見積もり工数） － １３
  • B
開発工程 要員：上級SE 要員：初級SE 工期
設計 ３ ０ ２
PG, UT ３ ２ ３ (3n+2*0.5n=12, n=3)
結合 ３ ０ ４
合計 30（見積もり工数） － ９

※ プランA → Bで、13 - 9 = ４人月の工程が短縮可能。

ブルックスの法則

  • PMP：試験 - テクニックの該当節を参照。

  • 遅延に要員追加で対応すると、コミュニケーション・パス増加で更に遅延を生む。

  • 他にも色々な法則があるので、知っておくとイイかも。

タックマンモデル

成立期 → 動乱期 → 安定期（信頼関係の構築） → 遂行期 → 解散期

資源カレンダー

リスク

計画プロセス

  • リスク特定
  • 定性的リスク分析
  • 定量的リスク分析
  • リスク対応計画（各種戦略：対脅威、対好機、コンティンジェンシー）

リスク戦略

EMV（期待金額価値）

品質

品質マネジメント

ソフトウェアの評価指標の例

  • 信頼性

    （最終成果物の）誤り件数 / 量

  • 保守性

    （最終成果物の）修正時間合計 / 修正件数

  • 移行性

    （最終成果物の）修正ステップ数 / 移行対象ステップ数

  • 機能性、使用性

    （最終成果物の）改善要望件数 / 出荷後経過時間

調達

契約タイプ

  • PMP：試験 - 計画の該当節を参照。

  • 納入者と購入者を間違えない。

  • 「完全定額契約」と漢字で書かれると「？」となり易い。

PCレンタル費用

  • 条件

    • レンタル料金は５千 / 月

    • 月初から月末までの一カ月単位の清算

    • 開発要員は、

      • 月初に着任、月末に離任。
      • 役割に関わらず、１人１台を使用。

    • 以下はレンタル期間に含まれる。

      • セットアップ：２週間
      • 返却後のデータ消去：１週間
      • 作業は別の開発要員が行う。

    • 他の開発要員へ引き渡す場合、
      セットアップ、データ消去は不要。

  • 開発要員投入計画

区分 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 合計（台） 合計（￥）
設計 - 2 4 4 4 2 2 2 2 2 2 - 26
PG - - - 3 3 5 5 3 3 2 2 - 26
テスト - - - - - 4 4 4 6 - - - 18
使用合計 - 2 4 7 7 11 11 9 11 4 4 - 70
レンタル合計 2 4 7 7 11 11 11 11 11 11 4 4 94 470

ステークホルダー

顧客、母体組織、納入者

  • 顧客
    プロジェクト成果物に対価を払いベネフィットを受ける。

  • 母体組織

    • プロジェクト運営の主体となる組織
    • プロジェクトを遂行する主体が所属する組織

  • 納入者
    プロジェクト成果物、またはそれを構成する
    コンポーネント等を供給するサプライヤー

コミュニケーション

ストーリー構成法

プレゼンテーションを行う。

  • 演繹的構成法
    一般的かつ普遍的な事実
    （ルール・セオリーなど）
    から論理的に結論を導き出す。

  • 帰納的構成法
    事例の共通項から原理・法則を導き出す。

  • 重点順位構成法
    重要度の順にストーリーを作る。

  • 難易構成法
    難易度の順にストーリーを作る。

課題の「発見」は帰納的で、
「解決」については演繹的に
行っている気がする（＠ブログ）。

参考

移行メモ

  • 見出し「要因割当」および表の「要因」は、要員の配分の話であるため 「要員割当」「要員」に正した。
  • IFPUG法のトランザクション・ファンクションの「EI : 外部出力」は、 EO（外部出力）と重複するため「EI : 外部入力」に正した。 「EQ : 外部参照」は原文ママ（一般には外部照会）。
  • 「構成管理の対象」は、元 Wiki に「コチラが参考になる。」とあるだけで リンク先の記載が無いため、その旨を明示した。
  • 「※ プランA → Bで、13 - 9 = ４人月の工程が短縮可能。」は原文ママ （表の「工期」の差であり、単位は月と思われる）。
  • 元 Wiki の結合セル（> / ~）を含む表は、GitHub Wiki では再現できないため、 セルの内容を展開して平坦な表にした（割当プラン A / B、開発要員投入計画）。
  • 元 Wiki の行頭空白による式は、フェンス付きコードブロックにした。
  • 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は多数あるが、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • 本文の無い見出し（「アジャイル」）は、その旨を明示した。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, 高度午前, プロジェクト・マネジメント, PMBOK, PMP, ライフサイクル, EVM, WBS, クリティカル・パス, IFPUG法, ファンクション・ポイント, ブルックスの法則, タックマンモデル, リスク戦略, 契約タイプ

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

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally