情報処理技術者試験向けのプロジェクトマネジメント分野の知識をまとめた記事です。昔、社内勉強会向けに書いたものなのですが、せっかくなのでこちらにも公開させていただきます。応用にも役立つと思いますし、高度試験のプロジェクトマネージャでも使える知識群です。
試験で問われる知識はどちらかというと SIer 向けです。とはいえ、プロジェクトを成功させるのに必要な観点、考え方も多く含まれるので、Web 系の方にも役立つ知識があるかもしれません。
試験対策で必要な考え方
特にプロジェクトマネージャ試験の午後Ⅰでいえることですが、PMBOK の世界観で考えられているかどうかが肝要です。自分の経験の凄さから回答するよりは、文中の事例に当てはまるように PMBOK の知識から答えていくのが安全です。
通称「みよちゃん本」には試験のポイントがまとまっているので、特に高度試験のプロジェクトマネージャを受ける人は読むのをオススメします。
では、以下にプロジェクトマネジメント分野のまとめを書いていきます。
プロジェクトとは
プロジェクトは目的を達成するために実施する活動のこと。明確な開始日と終了日がある（サービスマネジメントと異なるところ）。プロジェクトの目的や目標が達成されたときに完了する。成功するプロジェクトは、ステークホルダーの期待を満足させるプロジェクトや期待を上回るもの。
PMBOK 的な発想で捉えると？
プロジェクト・アクティビティを記述し、体系化し、監視する目的に使用する一連のツールと技法をまとめたもの。要はプロジェクトでどのフェーズで何を管理するかを体系化する。そして、個々の管理項目を監視することで、プロジェクト成功を阻害する問題の検知につなげたり、次回以降のプロジェクトの成功率向上に活用できるデータとすることができる。
PM に求められる役割
PM はプロジェクトマネジメントの技法を用いつつ、 QCD（納期、予算、品質）を管理し、ステークホルダの利害を調整し、人・物のリソースを管理しつつ、プロジェクトを成功に導くことが使命。プロジェクトマネージャには、様々なスキルを卓越した水準で求められる。
- コミュニケーションスキル
- 利害調整スキル
- 交渉力
- 影響力
- リーダーシップ
- チーム形成スキル
- 動機付けスキル
- タイムマネジメントスキル
- 予算化スキル
そもそも、PMBOK とは？
プロジェクトマネジメント協会(PMI)が発行する、「プロジェクトマネジメント知識体系ガイド」（英語: A Guide to the Project Management Body of Knowledge、略称：PMBOK Guide、PMBOKガイド）のこと。PMBOKガイドは、国際的に標準とされているプロジェクトマネジメントの知識体系（ガイド、手法、方法論、ベストプラクティス）であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する。
https://ja.wikipedia.org/wiki/PMBOK より
※ 最新版(2018年1月時点)は第6版ですが、情報が枯れている第5版について書いていきます。
PMBOKガイド第5版は、47個のプロセスを、幅広いプロジェクトに適用可能な5個の基本的なプロセス群と10個の知識エリアとに分類する。
5個のプロセス群は次の通り。
- プロジェクトの立上げプロセス群
- プロジェクトの計画プロセス群
- プロジェクトの実行プロセス群
- プロジェクトの監視・コントロール・プロセス群
- プロジェクトの終結プロセス群
10個の知識エリアとは次の通り。
- プロジェクト統合マネジメント
- プロジェクト・スコープ・マネジメント
- プロジェクト・タイム・マネジメント
- プロジェクト・コスト・マネジメント
- プロジェクト品質マネジメント
- プロジェクト人的資源マネジメント
- プロジェクト・コミュニケーション・マネジメント
- プロジェクト・リスクマネジメント
- プロジェクト調達マネジメント
- プロジェクト・ステークホルダー・マネジメント
統合マネジメント
プロジェクトの立ち上げと終結を管理する。また、全体最適の観点から、他の全てのマネジメント領域を統括する。
スコープマネジメント
「範囲」のこと。「成果物」と「作業」それぞれの範囲を定義する必要がある。曖昧なまま進めてはいけない。
スコープ変更時の注意点。
変更することで、予算、納期、品質へ影響が及ぶ。プロジェクト目標の達成が可能かどうかを検証すること。関係者と調整したうえで、スコープ変更の要否を決定する。また、変更時は関係者に周知する。担当者間でのやり取りではなく、変更を決定する手続きをルール化しておくとよい。顧客側に起因する変更であれば、契約内容の変更を行い、納期・費用を見直すこと。
WBS
プロジェクトに必要な作業を明確にするために、トップダウンで作業を洗い出し、階層構造で表現したもの。大きな粒度の項目から詳細化を進めていくことで、作業の網羅性を確保する。MECEに（漏れなく、ダブりなく）作業を洗い出す。
タイムマネジメント
アクティビティとは、WBS の最下層の項目を管理しやすい作業単位に分解したもの。
スケジュールを立てる際の流れ。
- アクティビティの定義
- アクティビティの順序設定（順番や依存関係）
- アクティビティ資源見積り（要員、ハードウェア等、リソース必要量を見積もる。いつ使用可能になるかも確認する）
- アクティビティ所要時間（アクティビティの遂行にかかる時間を見積もる）
- スケジュール（上記を元にスケジュールに落とし込む。ガントチャートを作ってもいい）
スケジュール短縮技法
######ファストトラッキング
先行タスクが終了する前に、後続タスクを開始すること。
クラッシング
要員を追加投入し、スケジュールを短縮すること。予算の追加が必要となる技法。
その他の方策（ユーザと要調整）
一部分だけ稼働し段階的にリリース、要求機能の削減、代替策の調整。
タイムマネジメント
進捗遅れを「検知」できる施策を取り入れ、早い段階で検知し対処できるようにしておく。予定と実績の差を管理する。（各タスクの進捗。成果物のページ数、レビュー完了数、テスト実施数、等の消化数）。進捗遅れには様々な原因があり、経験から知見をためておくとよい。遅れを吸収できるバッファを用意しておくのが望ましい。
- 仕様変更（ユーザの仕様変更、設計ミスなどの開発側に起因するものに分類できる）
- 作業項目の漏れ、見積もりのミス
- 低い生産性
- 欠員の発生（病気、退職、など）
- 調達遅れによる、作業開始遅延
- 選定した製品・パッケージのバグ
- 進捗確認の問題（実は遅れているのに、進捗通りと報告している。確認の間隔が長すぎる）
クリティカルパス
プロジェクトの各工程を、プロジェクト開始から終了まで「前の工程が終わらないと次の工程が始まらない」という依存関係に従って結んだときに、所要時間が最長となるような経路のこと。よって、クリティカルパス上の工程が遅延しないように、重点的に対応することが重要。
品質マネジメント
レビュー計画
レビュー方法や、レビューに要する工数・期間、レビュー参加者を決めておく。チェックリストがあると、抜け・漏れの防止に役立つ。誤字・脱字の指摘に終始すると、本質を見落とす恐れがあるので注意。
テスト計画
テストに関する指標。過去のデータ・経験と比較しつつ品質を見極める。
- テスト密度（テスト項目数 / 規模）
- テスト項目消化数
- 解決不良件数。発見不良件数。
- テスト網羅性（カバレッジ）
- 信頼度成長曲線による確認（バグが収束傾向にあるか）
- 品質不良を招く原因
- ユーザへの確認不足（プロトタイプがあるとよい）
- 要員の能力不足
- 開発標準がない
- 枯れていない新技術の採用
- 負荷テストの不足
人的資源マネジメント
人的資源を管理するとともに、プロジェクトに関係する人が最大のパフォーマンスを出せるようにすることを目的としている。
チーム編成
チーム編成を行い、役割分担を決める。リーダ、キーパーソンは選任にできると理想。
離脱への対応
離脱要因は、他PJへの異動、協力会社の引き上げ、要員間トラブル、スキル不足等。残りの要員で進めるか、要員を追加するか、策を講じていく必要がある。
育成
スキルが十分でないメンバで進めていくこともよくある。要員の育成(OJT)の体制を整えたり、新技術の教育機会を設ける。
パフォーマンス
パフォーマンスが出ていない状況を検知し、手を打てるとよい。
- スキルが期待通りでなく生産性の出ていないメンバがいないか。
- 新規要員の立ち上がりに時間がかかっていないか。
- 兼業者の負担が高くなっていないか。
- チームの和を乱すメンバがいないか。
- モチベーションが下がっていないか。残業続きで疲れきっていないか。メンバの悩みを相談する雰囲気があるか。
コミュニケーションマネジメント
情報の精製から廃棄までを管理。情報を必要とするものに、最適なタイミングで伝えることを目的としている。ステークホルダは誰か、コミュニケーションニーズ（どのような情報をどういうタイミングで必要とするか）を明確にし、情報配布のルート、会議開催計画に落とし込んでいく。
- コミュニケーション手段、方法、間隔は？（ミーティング、テレビ会議、メール、チャット、紙面、等）
- コミュニケーション経路は？（メンバ → リーダ → マネージャ 等）
- アクセス権をどのように設定するか（ファイルへのアクセス権、メーリングリストに誰を含めるか）
PM は、コミュニケーション不足を検知したら、円滑化するようサポートしていくことが望ましい。また、情報の交通整理もすること。メンバは、体制の中での自分の役割を把握し、コミュニケーション経路に従った報連相を適切に行うこと。独自の判断で、対応しないこと。
リスクマネジメント
リスクをピックアップして特定し、分析する。その結果を受けて対策を策定し、リスクを適正にコントロールする。
リスク分析
定性的リスク分析
個々のリスクの発生確率と影響度を評価し、リスクに優先順位をつける。
定量的リスク分析
個々のリスクに対し、定量値で分析する。分析ツールは様々だが、例えば、リスク顕在時の結果がどうなるかを算出する。
リスク対応
分析したリスクに対し、どのように対応するかを決める。マイナスのリスクに対しては、次の中から決定する。
| 項目 | 説明 |
|---|---|
| 回避 | スコープの縮小、プロジェクトの中止などにより、リスクを回避する。 |
| 転嫁 | 財務的なリスクに対し、保険をかける。 |
| 軽減 | 安定したハード調達先（納入遅れがない）、テストケースを増やす、などリスク発生確率を下げる。 |
| 受容 | 影響が小さい場合は、受容も一つの対応策。一方で、他に手の打ちようがない場合もある。。。 |
コストマネジメント
コストを管理する。プロジェクトを承認済みの予算内に収めるために、見積もりを作成し、計画通り進んでいるか確認し、問題発生時に原因を分析し改善策を練る。
EVM(アーンドバリューマネジメント)は、予算および予定の観点からプロジェクトがどのように遂行されつつあるかを定量的に評価するプロジェクト管理の技法。
調達マネジメント
プロジェクトで必要な資源を、プロジェクト外から購入、取得する。具体的には協力会社の選定、開発ツール、パッケージの購入等。
ステークホルダーマネジメント
プロジェクトと関係する、組織、グループ、個人を明らかにすることが目的。なお、ステークホルダとは、利害関係者のこと。