はじめに

PMとして勤務することもあり、体系的にプロジェクトマネジメントに関する知識を得ようと思い、プロジェクトマネージャ試験を受けることにしました。
ここでは、試験に必要となる知識や、学習方法をまとめて行きたいと思います。

午前I試験

午前I試験は、応用情報技術者の午前問題から抜粋して、全範囲の分野から出題されます。
個人的には、この午前I試験の勉強が一番億劫なので、落ちたら、応用情報技術者試験を受けようと思います。
応用情報技術者や、前の試験で、午前I試験を合格していれば、２年間は免除されます。

学習方法

午前I試験の学習方法は、応用情報技術者試験の過去問をひたすら解くことです。

午前II試験

午後II試験は、約７割がプロジェクトマネジメントの問題となっているので、プロジェクトマネジメントの分野を中心に学習していきます。

学習方法

過去問を解く

午前II試験で必要となる知識

午後IIで必要となる知識について、分野毎にまとめていきます。

ステークホルダ

チーム編成

• 階層型チームは、職務分担が明確で、指示伝達が行き届きやすい
• スペシャリストチームには、管理専門のマネージャは設置しない
• チーフプログラマチームは大規模プロジェクトに向いている
• 民主的チームは、メンバが平等の立場、自由に意見交換できる、統率力が弱い

要員計画

開発規模（総工数）と納期の制約に、過去の経験値（会社にあるプロジェクト管理に関するデータ、資産）から、各月の必要要員数を算出する。
単純に必要要員数を積み上げる山積みと、一定人数に調整するなどの山崩しという物がある。

　責任分担マトリクス

プロジェクトで必要な作業とメンバとの関係を表したもの

• Responsible:実行責任者
• Accountable:説明責任者
• Consult:相談対応者
• Inform:情報提供者

教育技法

• インバスケット・・・一定時間内に数多くの問題を処理させる
• OJT・・・日常の開発業務の中で、先輩や上司が個別に指導し、実体験から知識を習得させる技法
• ロールプレイ・・・参加者に特定の役割を演技させることによって、各立場の理解や問題解決力を高める技法
• ブレーンストーミング、KJ法・・・参加者のアイディアを批判することなく、またそのアイディアから新たなアイディアを導き出そうとする創造的問題解決に適した技法

文書構成法

• 帰納法・・・複数の事実から、共通する結論を見出す
• 演繹法・・・三段論法とも言われ、「2つの情報を関連付けて、そこから結論を必然的に導き出す思考法」
• 軽重順序法・・・個々の内容の軽重（重要性）に着目して展開順序を決める構成法

ステークホルダ

• 顧客・ユーザ・・・プロジェクトが想像するプロダクトやサービスを使用する
• サプライヤ・・・契約に基づいてプロジェクトに必要な構成アイテムやサービスを提供する
• スポンサ・・・プロジェクトに対して資金や現金などの財政的資源を提供する

• プログラムマネージャ・・・関連するプロジェクトの調和がとれるように、個々のプロジェクトの支援や指導をする

• プロジェクトガバナンスを維持する責任・・・ガバナンスとは、それによって組織を指揮しコントロールする枠組み。一般に、プロジェクトの適切なガバナンスを維持する責任は、プロジェクトスポンサー又はプロジェクト運営委員会に割り当てられる

• プロジェクトマネジメントオフィス・・・ガバナンス、標準化、プロジェクトマネジメントの教育訓練、プロジェクトの計画及びプロジェクトの監視を含む多彩な活動を遂行

• ステークホルダー・エンゲージメントのマネジメント・・・交渉やコミュニケーションを通してステークホルダーの期待をマネジメントする

資源マネジメント

• ブルックスの法則・・・遅延しているプロジェクトへの新規要員の追加は更なる遅れをもたらすだけである

• コンフリクトマネジメント

  • プロジェクトにコンフリクトは発生するものだとして、適切にマネジメントする必要がある
  • コンフリクトの解決にあたっては、過去ではなく、現在の課題に焦点を当てる
  • 個人の人間性ではなく、課題に焦点を当てる
  • コンフリクトは当事者間の課題ではなく、チームの課題である

• 組織とリーダーシップの関係

a・・・選手をきちんと管理する
b・・・うるさく言うのも半分くらい
c・・・選手と十分に話し合う
d・・・足を引っ張らない

• 集団思考・・・集団で意思決定を行う際に、集団の強い連帯感が、批判的思考を欠くことによって、マイナス方向に達してしまうこと。

• タックマンモデル・・・チームビルディングに関するモデル。チーム形成の過程を次の５つのフェーズに分けて説明

資源サブジェクトグループ

• 資源コントールのプロセス・・・プロジェクト作業の実施に必要な資源を確保し、プロジェクト要求を満たせるように資源を配分する。
• 資源の見積もりのプロセス・・・アクティビティリストのアクティビティごとに必要な資源を決定する。
• プロジェクトチームの開発のプロセス・・・継続的にプロジェクトチームメンバのパフォーマンス及び相互関係を改善する
• プロジェクトチームの編成のプロセス・・・プロジェクトの完遂に必要な人的資源を得る

コミュニケーション

• 顧客に提出した進捗状況の報告書に対して、成果物ごとの進捗状況についての問い合わせが繰り返しあった。　→コミュニケーションマネジメントの伝達すべき情報の内容、表現形式及び詳細度に問題がある。

リスク

リスク分析

-定性的リスク分析技法・・・発生確率・影響度マトリクス
https://ssaits.jp/promapedia/method/paim.html

-定量的リスク分析技法・・・感度分析、期待金額価値分析、デシジョンツリー分析
定性的→定量的と分析する

-感度分析・・・複数あるリスクのうち、どのリスクがプロジェクトに与える影響が最も大きいかを見る分析手法。具体的には、複数あるリスクの一つをとりあげ、そのリスクが顕在化した時、あるいは変動した時に結果がどうなるのかを算出する。感度分析の代表的な表示方法に、スパイダーチャートとトルネードチャートがある。
https://bizzine.jp/article/detail/136

-EMV（Expected Monetary Values:期待金額価値）・・・定量的リスク分析ツール。発生確率・影響度マトリクスを期待値を使って定量化するもの。
リスク事象の発生確率✖️リスク事象発生時の影響金額

リスク対応戦略

• マイナスのリスクもしくは脅威に対する戦略
  • 回避：リスクそのものを回避する
  • 転嫁：保険や保証、契約などの工夫で責任を転嫁する
  • 軽減：対応策をとってリスクそのものを軽減する
  • 受容：積極的に動くわけではなく、現場のリスクを受け入れる
• プラスのリスクもしくは好機に対する戦略
  • 活用：確実に好機を掴む為それを妨げる不確実性を除去する
  • 共有：好機を掴む確率を上げる為第三者と共有する
  • 強化：プラス要因を増加させる
  • 受容：積極的に動くわけではなく、現場のリスクを受け入れる

両方のリスクに使用される戦略は受容

• リスク対応計画

A:予防対策
B:受容
C：予防対策と発生時対策
D：発生時対策

リスク対応

• リスクへの対応・・・プロジェクト目標への脅威を軽減するために、プロジェクトの予算及びスケジュールに資源と活動を投入することによって、リスクを扱う
• リスクの管理・・・プロジェクトの混乱を最小限にするために、リスク対応の有効性を評価しながら、リスク対応の進捗をレビューする
• リスクの特定・・・プロジェクトのライフサイクルを通じて、プロジェクトの目標に影響を与えることがあるリスク事象及びその特性の決定を繰り返す
• リスクの評価・・・リスクの優先順位を定めるために、各リスクの発生確率及びそのリスクが発生した場合にプロジェクトの目標に及ぼす結果を推定する

デルファイ法

現在の動向から未来を予測したり、システム分析に使用したりする手法であり、専門的知識や経験を有する人の直感や推量を生かし、アンケート調査によって集団の意思を対象させながら調査を繰り返して、意見を収束させる手法

予算

品質コスト

品質コストは、品質を確保するためにかかったコストのことで、適合コストと不適合コストに分けられる

• 適合コスト
  • 予防コスト・・・要求事項に不適合にならないようにするコスト。トレーニングなど
  • 評価コスト・・・要求事項に適合したかどうかを評価するコスト。テストなど
• 不適合コスト
  • 内部不良コスト・・・プロジェクトにおいて発見された不良に関するコスト。手直しなど
  • 外部不良コスト・・・顧客によって発見された不良に関するコスト（プロジェクト終了後の支出を含む）。損害賠償など

生産性

工程別の生産性が以下の時、

• 設計工程：Xステップ／人月
• 製造工程；Yステップ／人月
• 試験工程：Zステップ／人月

全体の生産性は以下となる

\frac{1}{\frac{1}{X}+\frac{1}{Y}+\frac{1}{Z}}

工数計算

開発規模と工数のグラフ
ソフトウェア開発では、開発規模が大きくなるにつれ、調整工数や管理工数などが大きくなり、単に正比例的に増えていくのではなく、指数関数的に増加する

ファンクションポイント法

外部仕様からそのシステムが持つ入力、出力や内部論理ファイルなどの５つの項目に該当する要素の数を求め、さらに複雑さを考慮した重みをかけて求めた値を合計して規模を見積もる

• IFPUG法

ファンクションポイント法のカウント方法の一つ
データファンクションはデータを保持する機能、トランザクションファンクションはデータを取り扱う機能

• データファンクション
  • EIF:外部インターフェイスファイル
  • ILF:内部論理ファイル
• トランザクションファンクション
  • EI:外部入力
  • EQ:外部照会
  • EO:外部出力

COCOMO

ソフトウェアのソースコードでシステム開発の工数や期間を見積もる手法
https://ssaits.jp/promapedia/method/cocomo-model.html

開発規模と開発生産性の関係として、開発規模が大きくなればなるほど、開発生産性は悪化する。

EVM

EVM（アーンドバリューマネジメント）は、プロジェクトの進捗状況を定量的にリアルタイムに把握できる手法

• PV（Planned　Value：計画価値）・・・計画段階の予算
• AC(Actual　Cost：実コスト）・・・実際に費やされたコスト
• EV（Earned　Value:達成価値）・・・達成した機能数と、計画段階で求めた価値とを乗して求める

EVを元にPVやACと比較して作業の進捗に問題がないか、費用増になっていないかを以下の４つの指標でチェックする

• 重みづけマイルストーン法・・・設計書のレビューや承認などのマイルストーン完了事に重みづけした比率を決める（レビュー完了で、６０％、社内承認で９０％等）

進捗

進捗

• 資源カレンダー・・・各資源を投入可能な作業日及びシフトを示す日程表。

ADM

• クリティカルパス・・・作業の遅延がそのままプロジェクト全体に影響する余裕のない工程を繋ぎ合わせたもの。

PDM

・クリティカル・パス法（CPM）で使用される技法
・アクティビティをノード（要素）で表す。
・アクティビティ間の論理的な関係を矢印で示す。

トレンドチャート

縦軸に予算、横軸に工期を設定した折れ線グラフを用いてプロジェクト全体の費用と進捗を同時に管理する手法

クリティカルチェーン

クリティカルパスに資源の競合を加味した概念。

• プロジェクトバッファ・・・クリティカルパス上の最後のタスクの終了期と納期の間に、プロジェクト全体で使用するバッファを設定する。遅れが生じてプロジェクトバッファを消費し始めても、残量が安全区域にある場合は特に対策を講じない。

スケジュール短縮技法

• ファストトラッキング・・・工程が完了する前に、先行して次の工程に着手すること。
• クラッシング・・・メンバの時間外勤務や、業務内容に精通したメンバを増員したりする。クリティカルパス上に投入したりする。難易度が高い業務には向かない。

ガントチャート

作業別に作業内容とその実施期間を棒状に図示したものであり、作業の予定や実績を示す場合に効果的。
作業の相互関係の把握には適さない。

品質

随時追記していきます。