本記事は、プロジェクトマネージャー試験の論文対策の特集記事その②です。
その①は、1. 組織・コミュニケーション・ステークホルダマネジメント、2. タイムマネジメント、3. 品質マネジメント について取り上げています。
まだお読みでない方は、そちらも合わせてお読みください。
4. コストマネジメント
コストマネジメントについて考えてみます。
前回記事のタイムマネジメント・品質マネジメントと合わせ、QCDを構成する知識エリアです。
実際のPJ管理の現場では、コストのマネジメントも重要ですが、最終ジャッジはプロジェクトオーナーに委ねられることが多いため、プロジェクトマネージャーとしての采配は実は小さい分野であると言えます。
プロジェクトマネージャーに求められることは、予算の管理（監視）ということとなります。
そのため、字数を書ききるには、管理ツールへの言及が必須となるでしょう。
出題例を見てみます。
出題の例：
- 設問ア：プロジェクトの特徴およびコスト構成
- 設問イ：コスト見積もり手法について
- 設問ウ：プロジェクト遂行中のコストマネジメント
知識エリア特有の出題ポイントは赤字で示しています。
では、このエリアの出題ポイントを例に出しつつ、解説します。
具体的には、
- かかっているコストの把握手法
- 現時点での計画コストと差が生じていることを検知する手法
- 現行のままだとプロジェクト完了時の総コストがどうなるか予測する手法
これらを管理するツールが必要でしょう。
典型的・代表的なものがEVMになります。
EVMは午後Iでも問われることが多いので、午後IIにも活用できればとても有効な知識となるでしょう。
次に論述ポイントです。
初めに、EVMでどうコスト異常を検知したかの記述例を述べます。
コスト差異を検知するために、定点的にEACを観測していたが、15週目にさしかかると80人月に上昇した。プロジェクトとしてコスト超過するリスクが鮮明化したと言える。私は直ちに原因を調査した。
EAC・・・Estimate At Completion。完成時総コスト見積もり。
原因としては、担当者の工数不足、利用者の参画で微修正要望が頻発している等、様々考えられます。
対策としても、担当者の工数確保を上司に徹底してもらう、利用者の微修正要望を一覧化してもらい効率化を図る、などが考えられるでしょう。
ここでは、本知識エリアであるコストマネジメントによってどう分析・リカバリするかという論述例を述べます。
対策を施したため、今後は当初予定の生産性で進められることとなった。したがって、EACも今後は80人月から増加しないと考えられる。もともと想定していたバッファの4分の1を消費することになるが、顧客にも説明できる内容であるので、BAC に 2 人月加えて80人月とした。
BAC・・・Budget At Completion。完成時総予算。
BACはEVM管理開始当初から策定されている予算であり、基本は変わりませんが、上述の対策では、バッファの1/4を消費することで、BACを増やして対応した、ということになります。
何をやったかは単純ですが、EVMとして記述する事が、マネジメントのアピールポイントにつながります。
5. プロジェクト統合・スコープマネジメント
プロジェクト統合マネジメントとスコープマネジメントについて記載します。
両者は論文を書く上では重複するところも多いので、まとめて説明します。
プロジェクト統合マネジメントとは様々な知識エリアのマネジメントを統合してプロジェクトを管理するというところから来ています。
そのため、多くの知識が必要ですが、逆に単独として問われることは少ない分野です。（原理的にはありえない）
一方、スコープマネジメントも、様々な状況を加味した上でスコープの定義や変更を決定することになります。
プロジェクト統合マネジメントと同様、単独の知識だけを問われることはありません。
この点で共通するので、両者はまとめて解説します。
出題例をみてみましょう。
出題の例：
- 設問ア：プロジェクトの概要
- 設問イ：業務仕様の変更を考慮したプロジェクトの運営方法について
- 設問ウ：評価と改善点
知識エリア特有の出題ポイントを赤字で示しています。
では、このエリアの出題ポイントを例に出しつつ、解説します。
統合管理は、さまざまな状況を予測・加味して、プロジェクトの目的・スコープを決定・調整します。
出題例では、業務仕様の変更が発生する可能性を考慮しつつプロジェクトを進める上での注意点を問われています。
プロジェクトとしては、変更の可能性が低い方が望ましいので、なぜ変更可能性があるのにローンチするのか明確な説明が必要でしょう。
たとえば、社長の強い要望、〇周年のキャンペーンの一環である、などが考えられます。
こうした説明は設問アのプロジェクトの特徴として記載するのがよいでしょう。
次に論述ポイントです。
業務仕様の変更が発生する場合にどうするか、PMとしては予め決めておく必要があります。
変更が発生した場合にどういう基準で変更要求を受け入れるのか、予め整理しておく必要があるでしょう。
業務仕様の変更の検討項目の例を挙げておきます。
①利用部門から見た変更の緊急性や度合い
②変更しないことによる不便さの度合い
③開発部門から見た開発期間や費用への影響の度合い
上記の観点から評価します。
実際に検討する具体的な機能について、検討の末、却下する例を挙げてみましょう。
反対に、変更を受け入れる場合は、工数・費用・要員などの追加が必要となるので、しかるべき承認を取り付けるなど、PMとして必要な措置をとりましょう。次のような業務仕様の要望があった。
- 利用者が毎回、自分の住所や電話番号を入力するのではなく、過去に一度登録した利用者は、次回からはそれを呼び出すだけにしたい。
予め作成していた変更受け入れ基準に従って検討した結果、次のようになった。
- 変更による売り上げ向上：毎月60万円にのぼると試算された。
- 変更によるコスト：利用者の情報をどこかに持たさなければならないので、セキュリティを加味した設備増強で、1,100万円程度の追加費用と、セキュリティ確保の運用コストが月額120万円増額すると試算された。
検討の結果、コストが売り上げを上回るため、変更の依頼を却下してもらった。
6. リスクマネジメント
リスクマネジメントは、実際のプロジェクト管理で最も重要な概念と言えるでしょう。
ただ、その本質はリスクのコントロールなので、システム監査技術者で問われることと表裏一体です。
PMにおけるリスクマネジメントとは、システム監査技術者が監査する対象の、被監査主体の活動であるととらえると分かりやすいでしょう。
システム監査技術者に関する対策記事はこちら。
それでは概要から述べましょう。
プロジェクトにおけるリスク要因とは、QCDへの影響要因に他ならないので、他の知識エリアへの言及も必然です。
また、登録セキスぺの知識を持っていれば、応用の利く分野でもあります。
リスクが存在しているからと言って、全てのリスクに十分な対策をとることはできません。
コストをはじめとする制約があるため、制約の中で実現可能な対策、最適な対策をとるには、個々のリスクに対する分析が不可欠です。
プロジェクトマネージャーとしては、リスク分析（定性的・定量的）、抽出したリスク要因に対して予防的対策と発生時対策を整理しておくことが必要です。
では、出題例です。
出題の例：
- 設問ア：プロジェクトの特徴と目標
- 設問イ：私が行ったリスク分析
- 設問ウ：リスク対応計画について
知識エリア特有の出題ポイントを赤字で示しています。
では、出題ポイントをみてみましょう。
論述対象とするリスク要因は、プロジェクトの背景として含めてもよいでしょう。たとえば、初めて取引することになる会社が保守を担当する、など。
あとは適切なリスク管理をしたかという点ですが、具体的にはほかの知識エリアと同様、事前の準備と実際の対応が問われます。
- 事前にどのようなルールでリスクを管理するか
- リスクが表面化したときにどう対応したか
これらを頭に入れて、論述に臨みましょう。
論述ポイントを述べます。
まずはリスク管理手法の例です。
リスク洗い出しフェーズで特定したリスク毎に、発生確率と影響度をあらかじめ決めておいた基準に基づき3段階に分け、「リスク評価マトリックス表」に落とし込んだ。そして、そのセルによって、優先順位を3段階に分けた。
表形式で管理するのは、典型的な管理手法です。
次にリスク予防策と実際の対応を合わせて述べます。
予防的対策として、技法をレクチャーするとともに管理ツールも提供することとした。事前の教育で時間とコストがかかるが、予算内に収められそうであった。また、実際に生産性が一定の基準を下回った場合、要員を投入する計画とし、予算を組んでおいた。このことはプログラム製造工程において功を奏し、要員を1人投入することで、スケジュール影響なく工程を完遂できた。
7. 調達マネジメント
最後に、調達マネジメントです。
それでは概要から。
「調達」はプロジェクト遂行の一要素なので、この部分だけが問われることはないとは思いますが、現実では重要なプロセスです。
プロマネの論文では、請負契約などで協力会社からの調達、という構図で作成することがほとんどと思われます。
※ハードやソフトのみの調達もあり得ますが、論文の主題になりにくい
請負契約の場合、どの工程なのかを明確にしたり、直接の指揮命令ができないことから納品物を検証するフェーズを設ける必要があります。
キーワードとしては、RFPをもとに取引先（調達先）を募る、というケースが多いと思われます。
出題例です。
出題の例：
- 設問ア：プロジェクトの概要
- 設問イ：協力会社の選定について
- 設問ウ：評価と改善点
知識エリア特有の出題ポイントを赤字で示しています。
出題ポイントです。
協力会社の選定には、評価項目を洗い出した後、各項目別に、最低限の水準を設定する必要があります。
これは、一定水準以上の企業を探すことが、第一義的な目的になるためです。
また、契約知識（請負か委託か）や選定のプロセス（RFP作成、修正、選定理由）が問われます。
こうした知識のアピールは、設問イの論述で含めていくのがよいでしょう。
論述ポイントです。
ここでは、RFPの作り方に関する論述例を挙げておきます。
協力会社を選定するために、まずは私は、
①協力会社として必要な要件
②今回依頼する内容上必要な要件
をそれぞれ分けて明確にすることにした。そのうえで要件をRFPにまとめ、各項目の評価基準を設定し、最適な取引先を選定することにした。
実際に会社自体の要件として設定されるのは、設立年数、過去〇年内に赤字決算がないこと、従業員数、などが考えられます。
プロジェクトとして必要な要件は多岐に渡るので書ききれませんが、一般的には提案内容、新技術（特定技術）の採用有無、同業他社の実績、などが考えられます。
おわりに
いかがでしたでしょうか？
知識エリア別にみることで、論述のイメージを持つとともに、
横断的に知識エリアを覗いてみると、内実は、ノウハウが共通化されている部分も少なくありません。
特に、プロジェクトマネジメントでは、
プロジェクト遂行時に発生する問題に対して、基準に基づき対応する
といった2点を分けて考えなければなりません。
具体的な論述、思いつきますか？
思いつかない、という方は、各知識エリアの論述ポイントをぜひもう一度参考にしてください。
また、論文試験に臨む際は、自分だけの"論文パーツ"を多く準備することが大切です。
以下の記事では、"論文パーツ"を整理して、どのような出題に対しても応用が利くための、"論文事例マップ"の作り方を説明しています。
合わせて、参考にしてください。
前回に引き続き、PMBOKに沿った論文対策を説明して参りました。
いかがでしたでしょうか？
今後も、こういった知識を説明してほしい、特集してほしい、という要望があれば、ぜひコメント欄や問い合わせフォームからご連絡ください。
「読者になる」ボタンで、本ブログの更新時に通知されるようになりますので、ご検討ください。
それでは、皆さんの合格の報告を楽しみにしています！
ではそれまで。
