プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（予算領域）をサンプル論文とともに公開します

　この記事では、プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（予算領域）をサンプル論文とともに公開します。

　サンプル論文を掲載する理由は、「予算領域における論文のパーツ」を提供するためです。なぜパーツを提供するのかというと、午後Ⅱ試験の具体的な対策として、論文をパーツを準備しておくことが有効な方法だからです。

　プロジェクトマネージャ試験の午後Ⅱで、問題文を見てゼロから2000字超えの論文を書き上げることなんて不可能だと思いますよね。しかも、問題文に合わせる必要があるので、予め作っておいた論文を書いてもテーマに沿わない可能性が高く、それでは合格の確率は極低いです。

　アママネくんのこの感覚は正しいです。プロジェクトマネージャ試験のプロでないかぎり、「準備無し」で合格論文を書くのは無理です。

　ではどうすると良いかというと、準備をしておくんです。具体的に準備というのは、使い回しできる論文のパーツを用意しておくことです。

　私は都内の上場IT企業で、プロジェクトマネージャ試験対策の社内勉強会を2016年から主催しています。その活動の中で午後Ⅱ論文の添削をやっています。年40本として、合計で250本は添削しました。

　ここでは、私が添削した午後Ⅱ論文の中から、「合格レベル」と言い切れる水準の論文をいくつかピックアップしてみます。ぜひ、午後Ⅱ論文のパーツとして使用してみてください。つまり、つかえそうなところがあったら、パクってみてください！

プロジェクトマネージャ試験 平成26年 問1 システム開発プロジェクトにおける工数の見積りとコントロールについて

平成26年 問1 問題文

　プロジェクトマネージャ(PM)には、プロジェクトに必要な資源をできるだけ正確に見積り、適切にコントロールすることによって、プロジェクトの目標を達成することが求められる。中でも工数の見積りを誤ったり、見積りどおりに工数をコントロールできなかったりすると、プロジェクトのコストや進捗に大きな問題が発生することがある。

　工数の見積りは、見積りを行う時点までに入手した情報とその精度などの特徴を踏まえて、開発規模と生産性からトップダウンで行ったり、WBSの各アクティビティをベースにボトムアップで行ったり、それらを組み合わせて行ったりする。PMは、所属する組織で使われている機能別やアクティビティ別の生産性の基準値、類似プロジェクトの経験値、調査機関が公表している調査結果などを用い、使用する開発技術、品質目標、スケジュール、組織要員体制などのプロジェクトの特徴を考慮して工数を見積もる。未経験の開発技術を使うなど、経験値の入手が困難な場合は、システムの一部分を先行開発して関係する計数を実測するなど、見積りをできるだけ正確に行うための工夫を行う。

　見積りどおりに工数をコントロールするためには、プロジェクト運営面で様々な施策が必要となる。PMは、システム開発標準の整備と周知徹底、要員への適正な作業割当てなどによって、当初の見積りどおりの生産性を維持することに努めなければならない。また、プロジェクトの進捗に応じた工数の実績と見積りの差異や、開発規模や生産性に関わる見積りの前提条件の変更内容などを常に把握し、プロジェクトのコストや進捗に影響を与える問題を早期に発見して、必要な対策を行うことが重要である。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

平成26年 問1 設問文

　設問ア あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴と、見積りのために入手した情報について、あなたがどの時点で工数を見積もったかを含めて、800 字以内で述べよ。

　設問イ 設問アで述べた見積り時点において、プロジェクトの特徴、入手した情報の精度などの特徴を踏まえてどのように工数を見積もったか。見積りをできるだけ正確に行うために工夫したことを含めて、800 字以上 1,600 字以内で具体的に述べよ。

設問ウ 設問アで述べたプロジェクトにおいて、見積りどおりに工数をコントロールするためのプロジェクト運営面での施策、その実施状況及び評価について、あなたが重要と考えた施策を中心に、発見した問題とその対策を含めて、600 字以上 1,200 字以内で具体的に述べよ。

平成26年 問1 サンプル論文

１－１　プロジェクトの特徴(357字)

　私はシステム開発ベンダーZ社でプロジェクトマネージャーとして働いている。今回私が担当したプロジェクトは、外食チェーン店A社の店舗販売状況の可視化システムのリプレイスである。Z社としてはA社の初案件であり、失敗は許されなかった。体制は2チーム最大8人・総工数約60人月・PJ期間は10ヶ月（2020年4月～2021年2月）であった。

　特徴は、新可視化システムは、Z社にとって未知の技術であるSaaS型の可視化システムだったことである。このSaaS型の可視化システムは、Z社が同様の案件でよく扱っているパッケージソフトウェアのSaaS版である。Z社はパッケージソフトウェア版とSaaS版の詳細な違いは把握できていないものの、今後の商機があると見て、SaaS版の構築ノウハウを獲得しつつ本プロジェクトの成功を目指した。

１ー２　見積もりの時点と、見積もりのために入手した情報(373字)

　見積もりの時点は、プロジェクト開始後3ヶ月経った2020年6月末の要件定義完了後である。2020年3月の計画段階でも概算見積もりを提示していたが、要件定義完了段階で詳細な見積もりを提示した。この理由は、要件定義で3ヶ月を使い、プロトタイプを用いてユーザーの要求をシステム要件に反映させられていたためである。結果、システム要求の変更が頻発するリスクは低いと判断した。また、A社都合ではあるが、コロナ禍により、2020年の早めに予算を確定させたい顧客の希望もあった。コロナ禍は天災であり、コロナ禍による背景の変更に、A社の帰責性は無いと判断している。

　見積もりのために入手した情報は、大きく以下の２つとなった。

　(1)SaaSベンダに要求して得られた、機能別のアクティビティ一覧表

　(2)プロトタイプを作成することで得られた、アクティビティ別の必要工数

２ー１　工数見積もりの方法（593字）

　ここでは、１－２で述べた２つの情報を用いて、トップダウンとボトムアップの手法を組み合わせ、PJに必要な資源および工数を見積もった。具体的な流れとしては、１－２で記載した(1)SaaSベンダから得た機能別のアクティビティ一覧表でシステム要件をアクティビティまで分解し、１－２で記載した(2)プロトタイプ作成で得たアクティビティ毎の必要工数を積算していくことで、全体に必要な工数を見積もった。ここで、トップダウンとボトムアップの手法を組み合わせた理由は、両方の視点で見積もりを出すことで、抜け漏れを防ぎ、見積もりの精度を上げることができるためだ。

　トップダウン見積もりでは、類推法を用いた。社内において、システム要件の観点で本プロジェクトと同規模・同内容のプロジェクトを９つ抽出し、機能別に平均値や中央値を分析して見積額を算出した。この結果、外部設計以降の見積額は4,000万円と判断した。

　ボトムアップ見積もりでは、ワークパッケージを分解したアクティビティ単位の必要工数を積算し、トータルの見積もり額を決定した。この結果、外部設計以降の見積額は3,600万円と判断した。

　Z社の社内標準では、トップダウン見積もり額とボトムアップ見積もり額の差が、プラスマイナス10％以内に収まった場合、抜け漏れの少ない、高精度な見積もりであると判断している。今回は、プラスマイナス10％以内に収まった。

　

２－２　見積もりを正確に行うための工夫点（638字）

　見積もりを正確に行うための工夫点は、要件定義でプロトタイプを用いたことである。プロトタイプを用いた理由は以下の２つである。

　理由(1)　外部設計以降で、A社による要件の変更要求を減らせるため。A社ユーザー部門は、プロトタイプを触ることでシステムのイメージが具体化され、早い段階で詳細化した要求を挙げることができるようになる。また、プロトタイプを見ることで、A社とZ社との認識の相違が減る。これらにより、主にスコープ変更による工数見積もりと実態の乖離リスクを軽減することができる。

　理由(2)　プロトタイプを作成する際に、アクティビティ別の生産性の基準値を計測するため。通常、Z社標準の手法では、社内に知見として溜まっている可視化システムのアクティビティ別の生産性の基準値を用いて見積もりを用いる。しかし、今回はZ社にとってSaaS型の可視化システムは未知の技術だったため、見積もり精度が低くなるリスクを抱えてしまうことから、既知の生産性データは活用しないと判断した。

　また、ここで、生産性は、「工数１単位あたり、あるアクティビティをどの程度進捗させられるか（要するに、あるアクティビティを完了させるために必要な工数）」を示す。SaaS版の可視化システムにおける生産性の基準値を得た結果、アクティビティ毎に必要となる工数を得ることができた。例えば、可視化システムにおける分析軸（時間帯別や地域別）の追加というアクティビティには、実装・テストで１人日が必要となる、といったものである。

３－１　工数をコントロールするためのプロジェクト運営面での施策（529字）

３－１－１　まず、開発標準の整備と周知徹底を行った。開発標準としては、社内の可視化システムの開発標準に則った。一般的に、可視化システムでは、ユーザーインターフェースに対する変更要求が膨れ上がりやすい。理由は、可視化システムはその名の通り、データを可視化した後の外観（ユーザーインターフェース）に価値があるためである。そのため、分析軸や色合いなど、優先度がバラバラの変更要求が相次ぐのである。そこで、変更管理を中心に、開発標準の整備を行った。(1)変更要求は変更管理台帳で管理する(2)変更要求は変更管理委員会で判断する、などである。

　また、周知徹底としては、週次の各チーム合同の進捗確認ミーティングにおいて、開発標準への準拠の必要性を確認し、逸脱しているところがないかのチェックを行うことを、２つのチームリーダに指示した。

３－１－２　また、工数を適切にコントロールするために、外部設計以降はEVMを採用した。具体的には、作業の出来高（EV）をベースにSPIとCPIを週に一度、進捗確認会議で確認した。SPIとCPIを異常の兆候と判断する指標値は、過去の社内標準のデータを用いて決め、具体的にはSPI1.1以下、CPI1.1以下が静観する下限値であると定めた。　

３－２　実施状況と評価（625字）

　評価は率直に言って良かったと考えている。未知の技術を使いつつも計画通りの品質・納期・コストを実現できたためだ。また、EVMによる異常の兆候の管理が奏功した。外部設計が始まって1ヶ月が経過した2020年8月1周目に、CPIとSPIが両方とも1.1を下回った。状況を調べると、計画通り、要員8名が100％の工数を投下しているにも関わらず、EVが計画を下回っている状態だった。

　原因は、外部設計において、設計が詳細化していくに従い、機能数が増加してきたことだった。例えば、外部設計開始前は、分析軸として、チェーン店の店舗形態ごと（駅前・住宅地・ロードサイド）を想定していたが、駅前という軸を詳細化すると、東京山手線内、郊外、地方といった細分化が必要となる、ということだ。

　こういった設計の細分化に伴う要件の変更は、実質的には要件の追加に相当する。しかし、設計の細分化に伴う要件の変更は、変更管理委員会ではカバーできていない領域だった。そこで、変更管理委員会では、要件の追加だけでなく、設計の細分化に伴う要件の変更も、委員会で判定するようにルールを見直した。

　結果、変更管理委員会が適切に機能するようになり、2週間後の2020年8月3週にはSPIが1.1を超え、さらに2週間後の2020年9月1週にはCPIも1.1を超えるようになった。プロジェクト完了の2021年2月4週時点では、最終的にSPIとCPIは1.15付近となり、成功を裏付ける値となっている。

まとめ

　午後Ⅱの解き方そのものは、プロジェクトマネージャ試験対策として最強の参考書であるはみよちゃん本こと、翔泳社の「情報処理教科書 プロジェクトマネージャ」で勉強しましょう。

　このブログでは、あくまでパーツの用意に特化していきます。他のマネジメント領域のサンプル論文も用意していますので、ぜひご活用いただければ幸いです。