14.プロジェクトマネージャ対策ノート

情報処理技術者試験の高度区分にあたるプロジェクトマネージャ試験はPMBOK(ぴんぼっく)に準拠しています。

PMBOKとは、プロジェクトマネジメント知識を体系化したガイドです。

試験概要

対象者像

・高度IT人材として確立した専門分野

・システム開発プロジェクトの管理・運営

・プロジェクト計画立案、要員・資源確保、予算・納期・品質達成についての責任者

業務と役割

・個別システム化構想・計画の策定支援、当該プロジェクト実行計画立案

・必要となる要員や資源の確保、プロジェクト体制の確立

・予算・工程・品質・進捗の管理、課題の早期認識と適切な対策実施

・プロジェクト上位者及び関係者への実行計画・進捗・課題・対策の報告、支援・協力を得て円滑に運営

・プロジェクトの工程及び全体終了時、実績の分析・評価、その後のプロジェクトの運営に反映

期待する技術水準

・組織運営及びシステム全般に関する基本的な事項の理解

・個別システム化構想・計画及びプロジェクトへの期待を正しく認識、実行可能なプロジェクト計画を立案可能

・前提・制約条件の中で、プロジェクトの目標を確実に達成可能

・要員・資源・予算・工程・品質などを管理し、プロジェクトの全体意識を統一し、プロジェクトを運営可能

・プロジェクトの進捗状況や将来見込まれるリスクを早期把握し適切に対応可能

・プロジェクトの計画・実績を適切に分析・評価可能

◎まず午前対策ノートでPMBOKの基本を理解すること

プロジェクト全体

・スコープ管理

→予算・納期・品質を把握、プロジェクト目標達成影響の最小化、変更時の関係者周知

・変更管理

→予算・納期・品質への影響を把握

→業務開始日の納品が間に合わない場合:開発段階毎の対応、タスクを追加・中断し、段階的な導入を検討

→関係者・エンドユーザへの十分な調整

・プロジェクト評価

→目的:完了後分析(作業工数、不具合発生件数)、管理ノウハウの抽出

→プロジェクトの特徴を踏まえた評価項目

※計画段階の「目的」:問題発生の予防

進捗(Delivery)

・Plan:スケジュール作成

→プロジェクト固有のスケジュール:開発標準、過去PJを参考

→タスク順序調整

→日程変更不可タスクに着目

→長期間タスクの並行実施、タスク間整合性確保

・Do:状況把握、情報収集の工夫

→質問解答遅延件数、要件定義指摘件数、レビュー指摘件数、バグ発生件数

→要員負荷、会議出席率、メンバの声(不平不満)

・Check:クリティカルパス遅延の早期把握と原因分析(定量分析)

→問題領域と影響度見極め(Q:品質、C:費用、D:納期)

→本質的原因の掘り下げ

・Action:対策(リカバリ)

→適切な手続きと処置

→予防措置

※課題を残したままの本稼動開始

→影響範囲、解決日程の明確化

→実現不可機能の暫定運用手順・ルール提供

→暫定運用支援提供

・承認を得ずに次工程へ進むリスク:手戻り発生

予算(Cost)

・見積りに伴うリスク

→高リスクの場合:開発フェーズ分割契約、段階的開発

→前提条件の変化、当初見積りとの差異追跡

→リスクを加味した見積り手法:CPM、COCOMO

・コストマネジメント

→見積り精度向上の工夫:過去実績、生産性標準値を参考

→低精度の場合:バッファ設定(幅、予備を持たせる)

⇒マネジメント予備:不測リスクへの備え、PM上位層要承認

⇒コンティジェンシー予備:想定リスクへの備え、PM判断可

→コスト差異把握の仕組み:Activity完了時の予実比較

→コスト差異発生時の対応:原因・影響度分析、プロジェクト完了時のコスト予測

→予算超過防止:生産性改善策実施、スコープ調整

・工数見積りとコントロール

→トップダウン:開発規模と生産性から

→ボトムアップ:WBS各アクティビティから積み上げ

・予算超過時の対応

→スコープ変更

→ユーザ起因:追加費用請求

→開発側起因:原因分析(難易度見積り誤り、他作業の影響など)、対策

品質(Quality)

開発標準:品質の作りこみ確認するプロセス定義

⇒予算・納期短縮(ウォークスルー絞込み、プロトタイプ作成、ツール、過去データ使用)

・品質を作りこむ技術的工夫

⇒レビュー・テスト体制整備

⇒開発技術教育

⇒操作性確認方法・環境

・工夫が確実に生かされるPJ運営施策

⇒チーム編成、作業間連携、スケジューリング

・品質確認:午後Ⅱは以下の2パターン

⇒成果物評価指標とその目標範囲定義

品質目標策定:信頼性、性能、操作性

・設計レビュー

⇒リスク予想、レビュー重点項目明確化

⇒質問表

⇒レビュア選定、絞込み、進め方

⇒評価項目・基準設定(性能、拡張性、実現可能性)

⇒シミュレータ、プロトタイプ

※設計標準:設計手順、考慮ポイント

<評価指標>

レビュー実施時間率=実績時間/目標時間

レビュー実施規模率=実施済みページ数/総ページ数

指摘率=実際の指摘件数/目標指摘件数

・テスト

⇒テスト順序組替え

⇒方法変更

⇒環境強化

⇒進捗状況データ収集と分析

<評価指標>

消化時間率=実績時間/目標時間

消化件数率=実績数/項目数

網羅率=実行ステートメント数/全ステートメント数、実行分岐数/全分岐数

テスト密度=項目数/行数

不良率=不良件数/不良予測数

解決不良率=解決不良件数/発見不良件数

・問題の早期察知、品質作りこみプロセスの改善

⇒質問解答遅れ日数、要件定義変更回数、レビュー指摘件数、作業負荷

⇒請負契約での進捗確認機会・方法、中間成果物提示などの事前合意

⇒原因分析:パレート図、特定要因図

⇒他への波及有無机上確認、スケジュールや開発体制見直し

⇒管理帳票、記録帳票の改訂

要員・ステークホルダー

・プロジェクト編成

→役割分担の明確化、メンバーへの周知徹底

チームリーダー:変更管理での承認、進捗管理での対策指示、調達管理での候補選定

→仕組みの確立:作業手順、コミュニケーション手段

→経験の浅いチームリーダーへの指導

・要員交代、プロジェクト再編成

→問題把握※、対応策の検討と実施

→計画・実績差異明確化、既存体制での影響予測

→新規要員投入(立ち上がり時間考慮)、他要員の兼務や応援

→新たなリスクの観察、臨機応変な対応

※問題把握

→問題:仕様変更多発、想定外作業過負荷コミュニケーション不足(*)要員スキル見込み違いなど

→把握:進捗管理、成果物管理(作成状況とレビュー反映状況)、要員管理(体制、要員配置状況)

→対応:欠落、不足事項を重点的に実施

(*)コミュニケーション

→他部門責任者、予算承認者、技術支援責任者

→進捗や問題を積極的に説明

→それぞれに対するコミュニケーションの工夫

・交渉による問題解決

⇒利害関係が対立している場合

⇒双方とも非がないor非がある場合

<解決手順>

①状況認識合わせ

②問題の本質理解

③複数解決策立案

④優先順位付け

⑤解決策の関係者提示

⑥調整、合意のための交渉

リスク

・プロジェクトリスクの早期兆候認識

リスク特定:リスクとリスク要因(リスクを引き起こす原因)の明確化

リスク分析:定性的リスク分析、定量的リスク分析

→リスク回避・軽減・分離するための予防策(プロジェクト計画、リスク対応計画、リスク管理)

事後対策:リスクが現実化した際の対応

高頻度の発生、影響大:リスクヘッジ策が必要

調達

・請負契約:成果物の完成責任を負う、作業場所指定なし、指揮命令なし

⇒進捗・品質・リスク・課題の日々把握が困難、直接作業管理不可

⇒把握方法の工夫、適切な対処が必要

⇒中間結果マイルストーンの設定、双方主要メンバのレビュー

⇒発注者とサプライヤとの間で管理の仕組みを実施

⇒最終責任:発注者側のPM

・委任契約:成果物の完成責任は負わない、善管注意義務を負う、作業場所指定なし、指揮命令なし

・派遣契約:作業場所指定あり、指揮命令あり

※予算リスクヘッジのため、分割契約も検討

⇒要件定義・外部設計:委任契約

⇒詳細スコープ確定後:請負契約

・売買契約:所有権移転あり、固定資産計上あり

・リース契約:所有権移転する場合のみ固定資産計上

⇒ファイナンスリース:中途解約不可、コスト全負担

⇒オペレーティングリース:上記以外

・レンタル契約:所有権移転なし、固定資産計上なし(経費清算)

・請負会社の選定

⇒経営方針、事前調査の評価

⇒RFPに対する提案結果の評価:提案内容価格

⇒評価基準:妥当性(見積業務量・金額)、充足性(技術・業務水準)、健全性(財務状況)

⇒評価結果の検証(実績検証:業務状況、トラブル対応に関するユーザの声)

スクリーニング:最低限必要な基準点を設け、それを下回る提案を排除

・リーダーの採用

⇒要求条件:知識、経験、技能

⇒チーム事情:経験の浅さ、チームワークが苦手

⇒書類、面接での力量判断