本記事は、プロジェクトマネージャー試験の論文対策の特集記事です。
なんだかんだ、プロジェクトマネジメントの事実上の世界基準である、PMBOKの知識はあるに越したことないでしょう。
本記事では、PMの論文試験で問われていることを改めて分析し、PMBOKとの付き合い方と、知識エリア毎の回答ポイントをまとめることを目標としたいと思います。
0. そもそもPMBOKとは
PMBOKとは、プロジェクトマネジメントの事実上の世界標準です。
IPAもプロジェクトマネジメントのシラバスにPMBOKの知識を前提としている記載があります。
- コストマネジメント・品質マネジメントなど、10の知識エリア
- 「立ち上げ」「計画」「実行」「管理・監視」「終結」の 5 のプロセス
- 「入力」「ツールと実装技法」「出力」の 3 のパート
に分かれ、10 × 5 × 3 の直方体をイメージして説明されることがあります。
本記事では、10 の知識エリアに着目して、PM試験の回答ポイントを整理します。
第 7 版は、それまでの第 6 版とはかなり異なるリリースということで、注目されています。
最も単純化した変化でいうと、
「ウォーターフォール」に適したPJ管理から、「アジャイル」に適したPJ管理に変わった
というところだと思います。
実際、ウォーターフォールとアジャイルの切り替わりはもっと以前から叫ばれたこともあり、「やっと対応したか（遅いな）」という向きもあるようです。
反対に、「そう簡単にアジャイルへ変化できない」という意見も多く、PMBOKで対応されたとしても、数年程度で実際のPJ管理が変わるということは無いでしょう。
ただし、IPA は PMBOK をこれまで意識してきたので、PM 試験の様変わりが数年以内に発生する、ということはありそうです。
もしかすると、旧版のPMBOKの知識エリアやプロセスが通用しない問題も出題されるかもしれません。
実際、最新版である第 7 版では、先に述べた 10 × 5 × 3 の直方体モデルは言及されていません。
本ブログ（記事）では、10 の知識エリアに沿ったプロセスが、条件を満たせば今後のアジャイル開発モデルにおいても活用できる、という立場に立ち、ノウハウを整理して説明します。
1. 組織・コミュニケーション・ステークホルダマネジメント
組織マネジメント、コミュニケーションマネジメント、ステークホルダマネジメントについてまず考えてみましょう。
プロジェクトマネージャーとして、人的な管理は最も能動的に手腕を奮いやすい分野と考えられるためです。
組織・コミュニケーション・ステークホルダは、いずれも人的管理であり、境目も曖昧になることが多いので、まとめて解説します。
では、どういった観点が出題されることが多いか、過去問を見ながら考えてみましょう。
出題の例①：
- 設問ア：プロジェクトの概要
- 設問イ：プロジェクト遂行中のチームの再編成について
- 設問ウ：評価と改善点
出題の例②：
- 設問ア：プロジェクトの概要
- 設問イ：交渉による問題解決について
- 設問ウ：合意に至った解決策
知識エリア特有の出題ポイントを赤字で示しています。
では、このエリアの出題ポイントを例に出しつつ、解説します。
プロジェクト遂行中に発生する問題に対応するのがプロジェクトマネージャーの役割です。
例①で問われていることは、プロジェクト遂行中に「チームの再編成」によって解決したプロジェクトマネジメントです。
本来、問題を解決できるならば、「チームの再編成」は最初に検討されるべきものです。
組織・コミュニケーションマネジメントによって、問題解決したプロジェクトを論述として用意しておきましょう。
プロジェクト中に発生した問題を解決するために、ステークホルダとコミュニケーションをとるケースです。
実際にもよくあるマネジメントであると思います。
例②のポイントは、交渉によって解決する問題というのが、問題の責任について、双方に非のない問題か、非のある問題になります。
（さもなくば、法的手段や裁判による解決となるためです。）
こうした出題ポイントに備えて、解決すべき問題というのは、あらかじめ想定しておくのがよいでしょう。
例えば、要員であるチームリーダX君が、対象を崩し、プロジェクトからやむなく離脱することになった、というようなケースが考えられます。
出題ポイントに対して、どのように論述すればよいかを次のようにまとめます。
チームの再編成を行ったという論述でポイントとなるのは、次の2点です。
- 原因分析（ツール、プロセス、要因）をどう行ったか
- チームの理解を得るために慎重に取り組んだか
交渉によってプロジェクトマネージャーは、ステークホルダを説得して問題解決にこぎつける必要があります。
この場合、いかに説得力を持って交渉するかが重要です。
一例として次の論述例を挙げておきます。
上述の例のように、プロジェクトの立ち上げの段階での想定していた範囲であるというアピールをすることで、冷静な交渉ができるようになります。私は、今回のプロジェクトを立案する段階から、リスクマネジメントはしっかりと行っていたことを主張した。合意した計画に、X 社も弊社も落ち度はなかったという点である。そのリスク管理表では、主要メンバの不測の事態による離脱という項目があり、その場合は、双方協議のうえ、対策を施すとしている。当時の議事録にも、主要メンバの病気や怪我、退職による離脱の場合、それを見越して余力を持った要員計画を立てるのは、コスト面から厳しいという記録が残っている。
具体的な解決策は、段階リリース、代替要員の補充などが考えられるでしょう。
2. タイム（スケジュール）マネジメント
タイム（スケジュール）マネジメントについて考えます。
「線表」というイメージがある通り、プロジェクトマネジメントの最も主要な要素の一つです。
「進捗管理」という言葉で表され、具体的なノウハウやマネジメント手法が最も蓄積・共有されている分野だと思います。
ポイントとしては、
- 進捗管理手法はプロジェクト立ち上げ時に明らかにすること
- 進捗遅れの兆候を発見する仕組みを盛り込むこと
- 実際に進捗遅れが生じた時の対策を講じること
3. は対策なので、優れたプロジェクトマネージャーに求められるのは、「未然に防ぐ」ための手法である 1. と 2. をいかに計画に含めるか、といえるでしょう。
では、同様に、どういった観点が出題されることが多いか、過去問を見ながら考えてみましょう。
出題の例：
知識エリア特有の出題ポイントを赤字で示しています。
では、このエリアの出題ポイントを例に出しつつ、解説します。
よって、当該アクティビティが、いかに重要であり、プロジェクト全体の進捗にも影響を与えるようなものであることを、「設問ア：プロジェクトの特徴」の中で論述しておくことがよいでしょう。
また、進捗遅れの兆候を早期に把握できる仕組みを講じていたか、が問われます。
これがないと、実際の進捗遅れの発生に対しただ対応するだけとなり、これでは管理（コントロール）にならないためです。
たとえば、要件定義フェーズの場合（どのフェーズか明記するのも重要）、次のような仕組みが考えられます。
要件確定項目（合意済みの機能数）の達成割合（全体機能数と合意済み機能数の比率）、合意できていない機能数とその理由をチェックすることにした。その狙いとしては、PM自らがその品質をチェックできるからである。また、全体会議の場で、要件定義フェーズを担当するメンバ間で相互チェックしてもらい、品質向上と要員教育の狙いもあった。
次に論述ポイントを述べます。
出題ポイントで述べた通り、進捗遅れを未然に防ぐ仕組みを講じているので、
- 実際に兆候が発生した場合にどのように対応するか
- 実際に進捗遅れが発生した場合にどのように対応するか
について論文を展開しましょう。
兆校を把握したあと、進捗遅れの予防措置を講じる方法の例を述べます。
実際に進捗遅れが発生してしまった場合の対応方法の例を述べます。状況を確認して、原因を特定する。その原因が、
①ユーザ側担当者のスケジュールが確保できないことに起因する場合、私がユーザ側の責任者と話をして、ユーザ側で調整してもらい、参画を確保してもらう。
②その原因が、ユーザ側で結論が出せないことに起因する場合、ユーザ側経営者と、スコープの変更を含めて私が交渉する。
③その原因が、弊社担当者側のスキルの問題の場合、プロジェクト内の他のメンバがリカバリする。
そのために、日ごろから情報を共有して全体作業を把握できるようにしておく。
ユーザ側の仕様決定を担う担当者の一人が、急遽別の業務の作業を命じられ工数が不足していることが原因であった。私は、ユーザ側の責任者に状況を説明し、次のような調整をしてもらおうと申し出た。
①ユーザ側の当該担当者の部下に、一部、仕様確定の権限を委譲してもらう
②ひとり要員を追加してもらう。
③担当者の参加日程と、所要時間を弊社で算出するので、その所要時間の徹底管理を責任者に実施してもらう
3. 品質マネジメント
品質マネジメントについて考えます。
タイムマネジメントに比べると、品質は定義も管理手法も多岐にわたるため、論述しきるにはコツと経験が必要です。
一般的に、与えられた予算や納期の内訳として、品質確保に要する部分だけを独立して管理することは困難です。
外部設計書のレビュー、結合テスト、システムテストあたりなら可能ですが、単体テストやプログラム仕様書のレビューは、しばしばプログラム開発工程に融合されてしまうからです。
そこで、品質を作りこむためのプロセスと品質を確認するためのプロセスを開発標準として定め、その活動計画を作成することがあるべき姿となります。
では、出題例を見てみましょう。
出題の例：
- 設問ア：プロジェクトの概要
- 設問イ：品質を確保するための活動計画について
- 設問ウ：評価と改善点
知識エリア特有の出題ポイントを赤字で示しています。
では、このエリアの出題ポイントを例に出しつつ、解説します。
背景として、与えられた予算や納期の達成の難易度を説明しましょう。
プロジェクトマネージャーとしては、いかなる状況のプロジェクトであろうとも、地に足のついた遂行計画を立案・管理することが求められます。
品質が重要なプロジェクトならば、プロジェクト憲章などにおいて、プロジェクトメンバーに対し、品質目標と制約条件（予算や納期）の両立を目指すことを納得させ、全員が意識するような工夫が必要でしょう。
そのうえで、実際にどうやって品質を維持するのか施策を説明する必要があります。
次に論述ポイントを述べます。
制約下において、いかに品質向上を維持するかという点を、臨場感もって論述しましょう。
制約下における品質向上を追求する姿勢を示す必要があります。
次のように例文を挙げます。
この例は、プロジェクトの各フェーズにおいて品質を維持しつつ工数を最小化することを意図したものになります。
外部設計書のレビュー、単体テスト（の結果確認）、結合テスト（の結果確認）に関しては、技術に精通した外注メンバを中心に実施することとした。
逆にシステムテストは、現有メンバで実施する。
こうすることによって、各自、自分の強みを品質向上に活かせることになる。
上述の例は、一つの組織マネジメントと言い換えることもできるでしょう。
次に、よくあるイメージである「品質＝テストの充実度」という経験則に基づいた論述例を挙げておきます。この例も、メンバの調整によって品質向上を図る施策となります。
すべてのメンバが、成功して終結できるためのテスト計画を立案できるとは限らない。そこで、ベテランのメンバを中心にプロジェクト内に、品質向上チームを設けた。各テストを実施する前に、徹底的にテスト計画書のレビューを行うことが目的である。
上述の論述例のほか、"設計標準" を作りこむ、というのも典型的な品質管理施策となります。
つづきます
長くなりましたので、続きは次回といたします。
次回は、残りの知識エリアである、
- コストマネジメント
- 統合・スコープマネジメント
- リスクマネジメント
- 調達マネジメント
について解説して参ります。
「読者になる」ボタンで、ブログの更新時に通知されますので、ご検討ください。
プロジェクトマネージャーは、難関ですがその分合格時に肩書に付与できることの意味も大きい資格だと個人的に思います。
読者の皆さんの合格の報告を楽しみにしています！
ではそれまで。
