2020年春試験のPM【プロジェクトマネージャ】に申込みましたが、勉強が全く捗りません。
ですので、最後の手段として、よく使われそうなキーワード(午後1)を羅列して忘備録として記載しておきます。
- 知識エリアの用語
- プロジェクトマネジメント・プロセス群の用語
- プロジェクトマネジメントの主要プロセス
- 過去問から拾ったなかなか覚えられないフレーズ集
- 覚えておくと良い問題と解決方法
- プロジェクト管理の一連の流れ
- 変更が発生する原因
- 変更管理手順
- 問題発生時の原因分析方法
- 進捗管理
- 進捗遅れの兆候管理項目
- 進捗遅れの早期発見方法
- 進捗遅れの原因・受注者側の起因
- 進捗遅れの原因・発注者側の起因
- 進捗遅延防止策(予防対策・見積り誤差)
- 進捗遅延防止策(予防対策・開発機器の納期遅れ・不具合)
- 進捗遅延防止策(予防対策・手配品の納期遅れ・調達ミス)
- 進捗遅延防止策(予防対策・要員の退職・病気)
- 進捗遅延防止策(予防対策・各工程の進め方が悪く生産性が低い)
- 進捗遅延防止策(予防対策・進捗確認が甘い)
- 進捗遅延防止策(予防対策・設計ミスによる仕様変更)
- 進捗遅延防止策(予防対策・ユーザー都合による仕様変更)
- 進捗遅延防止策(予防対策・ユーザー側作業の遅れ)
- 進捗遅延の事後対策
- アクティビティ所要時間見積りアプローチ
- 進捗計画の主要ツール
- 進捗管理表
- 進捗管理の主要ツール
- 進捗管理指標
- 費用管理を実施する
- 予算超過防止(予防的措置)
- 予算超過の原因
- 予算超過の事後対策
- 品質計画を立案する
- 品質管理を実施する
- 品質不良防止策(機能性)
- 品質不良防止策(信頼性)
- 品質不良防止策(使用性)
- 品質不良防止策(効率性)
- 品質不良防止策(保守性)
- 品質不良防止策(移植性)
- 品質不良の原因
- 品質不良の事後対策
- 品質管理項目と評価基準(レビューの終了判定条件)
- 品質管理項目と評価基準(テストの終了判定条件)
- 要員計画を立案する
- 要員管理を実施する
- 要員に対する問題の早期発見
- 要員管理の問題防止策
- 要員に関する問題の事後対策
- 要員調達の留意点
- 組織の制約
- リスク管理の流れ
- 定量的リスク分析で使用するツール
- 協力会社に依頼する理由
- 調達先の選定基準
- 協力会社と契約する
- まとめ
知識エリアの用語
- プロジェクト統合マネジメント
- プロジェクト・スコープマネジメント
- プロジェクト・タイムマネジメント
- プロジェクト・コストマネジメント
- プロジェクト・品質マネジメント
- プロジェクト・人的資源マネジメント
- プロジェクト・コミュニケーションマネジメント
- プロジェクト・ステークスホルダーマネジメント
- プロジェクト・リスクマネジメント
- プロジェクト・調達マネジメント
プロジェクトマネジメント・プロセス群の用語
- プロジェクト・立ち上げ
- プロジェクト・計画
- プロジェクト・実行
- プロジェクト・監視・コントロロール
- プロジェクト・統括
プロジェクトマネジメントの主要プロセス
プロジェクト統合マネジメント
- プロジェクト憲章の作成
- プロジェクトマネジメント計画書作成
- プロジェクト作業の指揮・マネジメント
- プロジェクト作業の監視・コントロール
- 統合変更管理
- プロジェクトや各フェーズの終結
プロジェクト・スコープマネジメント
- スコープマネジメント計画
- 要求事項収集
- スコープ定義
- WBS作成
- スコープ妥当性確認
- スコープコントロール
プロジェクト・タイムマネジメント
- スケジュール・マネジメント計画
- アクティビティ定義
- アクティビティ順序設定
- アクティビティ資源見積
- アクティビティ所要期間見積
- スケジュール作成
- スケジュールコントロール
コスト・マネジメント
- コスト・マネジメント計画
- コスト見積
- 予算設定
- コスト・コントロール
プロジェクト品質マネジメント
- 品質マネジメント計画
- 品質保証
- 品質コントロール
プロジェクト人的資源マネジメント
- 人的資源マネジメント計画
- プロジェクトチーム編成
- プロジェクトチーム育成
- プロジェクトチームマネジメント
プロジェクト・コミュニケーションマネジメント
- コミュニケーションマネジメント計画
- コミュニケーションマネジメント
- コミュニケーションコントロール
ステークスホルダー・マジメント
- ステークスホルダー特定
- ステークスホルダー・マネジメント計画
- ステークスホルダー・エンゲージマネジメント
- ステークスホルダー・エンゲージコントロール
プロジェクト・リスクマネジメント
- リスクマネジメント計画
- リスク特定
- 定性的リスク分析
- 定量的リスク分析
- リスク対応計画
- リスクコントロール
プロジェクト調達マネジメント
- 調達マネジメント計画
- 調達実行
- 調達コントロール
- 調達終結
過去問から拾ったなかなか覚えられないフレーズ集
- リスクを特定し今後の対応を検討する
- 各要素の内容を理解して進捗管理できる人材
- 多岐に渡るステークスホルダを統率や調整
- クリティカルパス上の工程の遅れ
- 遅延工程のリカバリ方法を定量的に報告
- 上流工程での手戻りのリスクを軽減する
- 上流工程は納期に近くリカバリの余裕がない
- 主要なステークスホルダに適切な対応をとる
- 利用部門に機能や効果を理解してもらい協力を得る
- 現状の業務が新システムでも運用できる事を確認
- 上流工程で発見したバグを内部設計を利用して手戻りを最小限にする
- 新たなプロセスを早期に検証してもらう
- 問題を早期発見し対処することで手戻りを最小限にする
- 現システムからの移行作業の見積もり
- 事前に正確な情報を開示して対策を共有する
- 追加要員の教育には時間が掛かる
- 分離開発は当初開発分への取り込み漏れのリスクがある
- 追加開発分は現状どおり手作業で処理するリスクがある
- 問題点の影響度から要件の優先順位を付ける
- 利用部門の抵抗はプロセスが定着しないリスクがある
- レビューの不足は成果物の品質低下となる
覚えておくと良い問題と解決方法
プロジェクト管理の一連の流れ
- 実施手順(アクションプラン)を作成
- 潜在的リスクの定義
- リスクの予防対策
- リスクを検知する仕組みを組み込む
- リスク検知による問題の早期発見
- 緊急的対応(事後対策)
- 原因分析
- 恒久的対応
変更が発生する原因
- 仕様変更(受注側のヒアリング不足)
- 仕様変更(発注側の要請)
変更管理手順
- 健康管理委員会(CCB)の設置・独自判断をしない
- 変更依頼書の使用
- 定例会議で変更時期・担当者を決定する
- 緊急時には臨時会を開催する
問題発生時の原因分析方法
- 担当者・関係者にヒアリング
- 傾向を分析する(QC7つ道具・パレート図・特性要因図等)
- 有識者や専門家を募り会議を開催
進捗管理
- 進捗遅れの兆候を管理する
- 進捗遅れを早期発見できる仕組みを組み込む
- 発見された問題の原因分析を行う
- 適切な対策を取る
進捗遅れの兆候管理項目
- 要員の残業時間
- 要員の生産性
- 設計レビューの指摘件数
- 兼任している要員の負荷
進捗遅れの早期発見方法
- 進捗管理表で予定と実績の差から検知する
- メンバの様子を観察・対話を心がける
進捗遅れの原因・受注者側の起因
- 見積り誤差
- 手配品や開発機器の納期の遅れ、不具合
- 要員の退職や病気による離脱
- 各工程の進め方が悪く生産性が低い
- 進捗管理が甘い(見逃し)
- 仕様変更(設計のミス)
進捗遅れの原因・発注者側の起因
- 仕様変更(ユーザー側の要請)
- ユーザー側に依頼した作業の遅れ
進捗遅延防止策(予防対策・見積り誤差)
- プロジェクトに適した見積り技法を取る
- 作業項目の遅れを防止するため、自社の開発標準を利用したり、標準WBSやSLC-JCF2007を参考にする
- 新人の多いプロジェクトや未経験プロジェクトの場合は、スケジュールに余裕を持たせる
- 上流工程に不確定要素が多い場合は、請負契約では無く、委任契約等で契約を分ける
進捗遅延防止策(予防対策・開発機器の納期遅れ・不具合)
- 手配遅れを防止する為に、スケジュール計画作成段階から専門家(テクニカルエンジニアやメーカーの技術者)を参画させておく
進捗遅延防止策(予防対策・手配品の納期遅れ・調達ミス)
- 新商品の場合、リリースが遅れたり、不具合が発見されたりする事が多い。そうした可能性がある場合は、余裕を見たスケジュールを立てることと、問題が発生した場合の対応方法を検討しておく
進捗遅延防止策(予防対策・要員の退職・病気)
- 無理なスケジュールにしない
- 不測の事態に備えてリスクへの対応をどこまでにするか(2人体制にする、代替メンバを想定して多めにメンバを確保しておく等)をコストの兼ね合いで決めておく
進捗遅延防止策(予防対策・各工程の進め方が悪く生産性が低い)
- 適切な要員を手配する
- 各工程の標準的な進め方を事前に指導しておく
進捗遅延防止策(予防対策・進捗確認が甘い)
- クリティカルパスにおける遅延の兆候の管理
- 進捗報告を週1にする
進捗遅延防止策(予防対策・設計ミスによる仕様変更)
- SEの能力不足の場合は、フォローできる体制を考えておく
- レビューチームに有識者が経験者に参画してもらう
進捗遅延防止策(予防対策・ユーザー都合による仕様変更)
- スコープを確定させユーザーと合意する
- 契約する段階で仕様変更について意思統一を図っておく
- 変更内容によっては納期の遅れ、追加費用の発生を事前に説明し理解を得ておく
進捗遅延防止策(予防対策・ユーザー側作業の遅れ)
- ユーザー側の体制が複雑であったり、多忙である等の事態が想定される場合は、ユーザー側の体制に参画することも考慮する
- ユーザー側の繁忙期を考慮したスケジュールを立てる
- ユーザー側が本当にできる作業であるか判断する
- 不可能である場合は、できるだけ負荷の掛からないように役割分担し、要員の派遣も考慮する
進捗遅延の事後対策
- 本番時期の変更
- 部分可動
- スケジュールの組み換え
- 追加要員の投入(PGの追加投入・人海戦術・SEの投入)
- スペックダウン(仕様の簡易化・要求機能の削減)
- 環境の改善(開発場所の移動・開発設備追加・代替品の利用)
- 進捗確認を強化
アクティビティ所要時間見積りアプローチ
- 三点見積り
- 類推見積り
- 標準工数の利用
- 要員を先に確定し、要員の自己申告工数を使用
進捗計画の主要ツール
- ADM法
- PDM法
- クリティカルパス
- スケジュール短縮技法(クラッシング・ファストトラッキング)
進捗管理表
- ガントチャート
- EVMS
進捗管理の主要ツール
- 完了状況管理表
- 工程管理表(マイルストーン)
進捗管理指標
- スケジュール(官業完了日/予定日)
- 操作説明書・要件定義書等(完成ページ数/予定ページ数)
- 外部設計書・内部設計書等(完了本数/設計予定本数)
- ドキュメントレビュー(レビュー完了ページ数/レビュー予定ページ数)
- プログラム作成(完了本数/作成予定本数)
- テスト(テスト実施数/テストケース数)
- 不具合改修(バグの改修数/バグの発生数)
- 仕様変更への対応状況(対応完了件数/仕様変更発生数)
費用管理を実施する
- 予算超過の兆候を管理する
- 予算超過を早期に検知できる仕組みを組み込む
- 問題が発見されると、原因分析を行う
- 適切な対策をとる
予算超過防止(予防的措置)
- 分割契約(上流工程は委任契約)
- 再見積りの可能性について言及しておく
- リスクを見込んだ予算設定(コンティジェンシー予備)
- 不測の事態を見込んだ予算設定(マネジメント予備)
予算超過の原因
- 生産性が低下している(難易度が高かった、他の作業に手をとられたなど)
- スコープが誤っていた、あるいは明確な取り決めがなかった(ユーザー側に起因する機能追加などの仕様変更、開発側に起因するヒアリング漏れ、見積り段階のミス、契約内容に問題があった、設計段階ではじめて発生した問題など)
予算超過の事後対策
- 生産性の低い原因を除去(要員の交代など)
- スコープ誤りでは、ユーザー側に起因する仕様変更や機能追加などは、追加費用の請求を行う。開発側に起因する場合は、その後のプロジェクト体制を見直し、後の費用を削減するしかない。例えば、単価の安い技術者にメンバを替えたり、外注したりしてコスト削減を図る
品質計画を立案する
- SLA(品質に対する要求事項)の確認
- レビュー計画の作成
- テスト計画の作成
品質管理を実施する
- モニタリングする(レビュー・テスト)
- 問題が発見されると、原因分析を行う
- 適切な対策を指示する
品質不良防止策(機能性)
- 他の類似のシステムの評価
- パッケージのデモ、プロトタイプによる確認など(イメージしやすい形で確認する)
品質不良防止策(信頼性)
- 新製品や新技術よりも、こなれた製品、技術を採用する
- 障害対応を含む運用面を考慮した設計(ISMSなどの基準を参考に)
- 運用設計書の作成
- レビューやテスト期間を十分にとったスケジュールにする
品質不良防止策(使用性)
- パッケージのデモ、プロトタイプによる確認など(イメージしやすい形で確認する)
- 既存システムの操作性を考慮(画面レイアウトやメッセージ、入力方法の統一)
- 誤操作の排除(運用管理システムによる自動化など)
品質不良防止策(効率性)
- 事前に行う効果的な負荷テスト
- ベンチマークの利用
- シュミレーション
品質不良防止策(保守性)
- 開発標準の作成
- 共通部分のモジュール化
- 変更管理が容易なライブラリ化
- ドキュメントの整備
品質不良防止策(移植性)
- 移植性を考慮したアーキテクチャを採用(オープンシステム、Java)
- ドキュメントの充実
品質不良の原因
- QC7つ道具を使って原因を分析
- 特定の要員に問題がある(技術力や経験不足、新人)
- 特定の原因に問題がある(設計ミス、プログラムミス、テストケース不備など)
品質不良の事後対策
- 要員の交代
- 経験者のサポート
- 前工程に戻って改善する
品質管理項目と評価基準(レビューの終了判定条件)
- レビュー期間(レビュー実績時間/成果物に対するレビューの目標時間)
- レビューの量(レビュー済みページ数/レビュー予定の総ページ数)
- レビューでの指摘件数(レビューでの指摘件数/経験値としての目標レビュー指摘件数)
品質管理項目と評価基準(テストの終了判定条件)
- テスト期間(テスト実績時間/テストの目標時間)
- テスト項目消化件数(実績数/テスト項目予定数)
- テスト網羅性(ガバレッジ、カバー数)(実行ステートメント数/全ステートメント数)
- テスト密度(テスト項目数/規模(総ステップ数))
- 不良件数(不良件数/kステップあたりの不良予測数)
- 信頼度成長曲線による確認(標準的な信頼度成長曲線と実際のバグ発見累積曲線とを比較)
- 解決不良件数(解決不良件数/発見不良件数)
要員計画を立案する
- プロジェクト体制を立案する
- TRMを作成する
- 要員を調達する
- 作業負荷の平準化を行う(山崩し作業)
要員管理を実施する
- 要員のモチベーションを維持する
- プロジェクト体制を見直す(要員の離脱、交代、増員に対する判断を行う)
- プロジェクト内で要員教育を行う(計画てきかつ効率的に)
- 要員に関する問題を早期発見する
- 問題が発見されると、原因分析を行う
- 適切な対策をとる
要員に対する問題の早期発見
- 勤怠管理で勤怠状況を確認(残業の増加など)
- 進捗管理表での問題発見
- 要員間のトラブルの有無をチェック
要員管理の問題防止策
- プロジェクトメンバも当然人間である。そのため病気や一身上の都合でプロジェクトから離脱することを余儀なくされる場合がある。そうした要員の離脱も考慮してプロジェクト体制を立てなければならない。
要員に関する問題の事後対策
組織見直し
- 要員が不足したまま、残りのメンバで何とかする(労働関係法令に違反する事無く、特定の要員に負荷が掛からない事が前提)
- 要員を追加する場合は、必要なスキル、経験を明確にし、該当する要員を確保する
- 要員を追加する場合は、引継ぎの間、プロジェクトを理解するためのの期間を見積もる
スコープ変更の可能性検討
- 納期を含めたスケジュールの見直し、追加予算の要求
- スコープの変更も検討しなければならない
要員調達の留意点
- キーになる要因は専任にする
- 命令系統の輻輳がないか確認する。命令系統に輻輳がある場合、プロジェクトマネージャは調整しなければならない
- 自社のノウハウ、コア技術などに関しては、自社の要員で固める
組織の制約
- 内部統制
- セキュリティ(ISMS)
- 個人情報保護
リスク管理の流れ
- リスクのピックアップ
- 発生確率×影響で優先順位を決める
- 必要に応じて定量的分析
- 個々に回避、転嫁、軽減、受容で予防
- 事後対応策も考える
- 監視と介入
定量的リスク分析で使用するツール
- 感度分析
- EMV(期待金額価値分析)
- デジジョンツリー
協力会社に依頼する理由
- 要員の不足(一時的に作業が重なる等が原因で、要員が不足)
- 要員の不足(戦略的に自社である工程の要員をかかえない)
- 必要とする技術力がない(パッケージ製品などで、その製品を扱う限り毎回依頼しなければならない、又は技術移転までは考えていない)
- 費用を抑える為
調達先の選定基準
- 作業内容、要求スキル、要員数、契約形態等を明確にする
- 内外製分析と内外製決定
- RFQ又はRFPの作成(評価基準は、重要度に応じて重み付けし、定量化しておくと客観的に比較しやすい)
- 発行先の選定(要件に合致しそうな企業に対して、上記のRFQ又はRFPを発行する企業を数社選定する
- 発注先の決定
協力会社と契約する
- 請負契約
- 委任契約
- 派遣契約
まとめ
PMの勉強方法最後の手段は良く使われる用語やフレーズを暗記して臨む
案外覚える事が沢山あって大変・・・
コメント