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

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

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

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

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

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

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

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

プロジェクトマネージャ試験 平成17年 問2 稼働開始時期を満足させるためのスケジュールの作成について

平成17年 問2 問題文

　情報システム開発プロジェクトでは,設計・開発・テストなどの各工程で必要となるタスクを定義し,タスクの実施順序を設定してからスケジュールを作成する。プロジェクトは個々に対象範囲や制約条件が異なるので,システム開発標準や過去の類似プロジェクトなどを参考にして,そのプロジェクト固有のスケジュールを作成する。
　特に,システム全体の稼働開始前に一部のサブシステムの稼働開始時期が決められている場合や,利用部門から開発期間の短縮を要求されている場合などは,プロジェクト全体のスケジュールの作成に様々な調整が必要となる。このような場合,システム開発標準で定められたタスクや,類似プロジェクトで実績のあるタスクとそれらの実施順序を参考にしながら,タスクの内容や構成,タスクの実施順序を調整して,スケジュールを作成しなければならない。
　その際,全体レビューや利用部門の承認などのように,日程を変更できないイベントやタスクに着目するとともに,次のような観点でスケジュールを作成することが重要である。
　・タスクを並行させて実施することが可能な場合には,タスク間の整合性をとるための新しいタスクを定義する。

　・長期間かかるタスクの場合は,サブタスクに分割し,並行させて実施したり,実
施順序を調整したりする。
　あなたの経験と考えに基づいて,設問ア~ウに従って論述せよ。

平成17年 問2 設問文

　設問ア あなたが携わったプロジェクトの概要と,稼働開始時期が決定された背景を,800字以内で述べよ。

　設問イ 設問アで述べたプロジェクトで,日程を変更できないイベントやタスクには何があったかについて述べよ。その上で,稼働開始時期を満足させるための調整をどのように行ったか。あなたがスケジュールを作成する上で,特に重要と考え工夫した点を中心に,具体的に述べよ。

　設問ウ 設問イで述べたスケジュール作成について,あなたはどのように評価しているか。また,今後どのように改善したいと考えているか。それぞれ簡潔に述べよ。

平成17年 問2 サンプル論文

　１－１　概要(251字)

　私はシステム開発ベンダーZ社でプロジェクトマネージャーとして働いている。今回私が担当したプロジェクトは、外食チェーン店A社の店舗販売状況の可視化システムのリプレイスである。具体的には、①現行版と同一機能の可視化システムのリプレイスに加え、②ダイシング等の分析システムを追加開発するものである。体制は2チーム最大8人・総工数約60人月・PJ期間は2020年4月～2021年2月の10ヶ月であった。

　特徴としては、システム全体の稼働開始の10ヶ月前である2020年12月1日に、現行版のリプレイス部分である①可視化システムの稼働開始が必要となったことだった。これはA社側も認識できていなかったことだった。計画立案時にこの問題が判明し、調整を行うことになった。

　また、コストの制約も厳しかった。計画を策定中の2020年3月時点で新型コロナウイルスによる緊急事態宣言が出され、外食業界は資金面で危機的状態が予見されていた。予備費は総予算の5%であり、同規模の案件の中では格段に少なかった。

　１ー２　稼働開始時期が決定された背景(368字)

　①可視化システムの稼働開始が9月1日に2ヶ月前倒しされた背景は、以下の２つである。

　(1)現行可視化ソフトウェアのライセンス期限切れによるリプレイスであるため。12月1日以降は、新版の可視化ソフトウェアのライセンスを用いる必要がある。

　(2)①可視化システムは、既存業務で使っているため。具体的には、販売部門および経営層が毎日の売上状況をリアルタイムで把握するためのものである。12月1日を遅れると、既存業務に大きな悪影響がある。

　２ー１　日程を変更できないイベントやタスク（558）

　PJ開始前の計画段階において、以下の2つの観点で調整が必要とわかった。

　(1)まず、同規模の類似案件を探し、トップダウンで稼働開始日を暫定で計画した。結果、システム全体の稼働開始日を2月1日となるように定めた。しかし、前述した現行可視化システムのリプレイス期限の観点で、12月1日を稼働開始日とする計画の修正・調整が必要になった。

　(2)次に、日程を変更できないイベントとして、サブシステム（ここでは①の可視化システム）に対する販売部門の外部設計の承認が挙がった。A社では、7月以降、コロナ禍対策として宅配の販売事業を開始する予定であり、販売部門が繁忙期に入る。結果、以後は部門長が時間を取れなくなるリスクが大きい。当初計画では、要件定義を4月～5月、外部設計を6月～7月に行うとしていた。このままでは、外部設計中旬で販売部門がボトルネックになり、承認が進まなくなる可能性がある。現行踏襲という基本方針に則り、可視化システムの画面レイアウトや挙動は、外部設計開始前からある程度定まっている。しかし、現行踏襲というあいまいな表現で利用部門の承認を十分に得ないまま進めると、テスト段階で仕様変更・手戻りのリスクを抱えることになる。よって、なんとしても6月中に①可視化システムの外部設計を終える必要が出てきたのであった。

　２－２　稼働開始時期を満足させるための調整（1075）

　まず、(1)の稼働開始日の前倒しのための調整を行った。第一に、システム全体の稼働開始日を12月1日に統一するスケジュールを検討した。これは、費用および要員調達の観点で困難だった。本プロジェクトは外部設計・内部設計に4ヶ月をかける計画だったが、2ヶ月の短縮には、主に設計に長けたベテラン3人が外部設計・内部設計で必要であり、その費用は追加捻出できなかった。そこで、①可視化システムの稼働開始日を12月1日に前倒しにして、かつ、②分析システムの稼働は2ヶ月後ろ倒しの翌年4月1日にするとした。この結果、要員の数は変更せず、コストを増加させずに二段階リリースが可能となった。この際、②分析システムを後発リリースとしたのは、①可視化システムの遅れは既存業務に影響を大きく与えるためである。既存業務への影響を鑑みて②分析システムのリリースを遅らせることをステアリングコミッティで伝え、コスト維持のために必要なことであると販売部門へ説得に回ってもらった。

　また、スケジュールの策定方法は、社内のBIシステムの開発標準を基にした。加えて、二段階リリースを行った過去の類似プロジェクトを調査し、該当プロジェクトのプロジェクトマネージャに詳細をヒアリングした上で策定した。結果、以下をポイントとしてスケジュールを策定した。

　4月、5月の要件定義フェーズと6月、7月の外部設計フェーズまでは①可視化システムも②分析システムも総合して進める。これは、外部設計完了までは両システムで整合性を取らないと、不整合により手戻りが生じるリスクが高いと判明したためである。

　8月以降は、12月まで①可視化システムの開発およびテスト、②1月以降は②分析システムという形で開発を進めることとした。

　(2)次に、日程を変更できないイベントである販売部門の6月末の外部設計の完了について調整した。具体的には、①可視化システムにおいて、要件定義フェーズの時期としていた4月～5月に、外部設計フェーズの作業を先行して行う形で、ファストトラッキングを用いた。要件が固まった部分から、外部設計に入っていった。この場合、整合性をリスクとして新たに認識する必要がある。要件定義完了前ゆえに、要件が明らかになるもしくは変わることがあるからだ。そのとき、策定していた外部設計の内容にも変更が生じうるのである。ここでは、対策として、タスク間の整合性確保を重点管理項目として設定し、監視することにした。具体的には、要件が明らかになったり変わったりしたタイミングで、外部設計書に影響がないか、必ずチェックする運用とした。

　３－１　私の評価（533）

　評価は高く感じている。理由は、修正した計画通りに納期遅延・コスト超過無く二段階リリースが完了したためだ。ファストトラッキングを用いることについて、コンティンジェンシー予備として確保していた総予算の5%分を使うことになったが、これは修正した計画通りである。計画外のコスト超過は無かった。結果、第一段リリースはリプレイス期限切れに適切に対応することが出来、業務影響はゼロだった。手段としては、以下の２つが特に奏功したと考えている。

　(1)ファストトラッキングの採用と整合性リスクのカバー

　ファストトラッキングにより、外部設計の販売部門レビューは、販売部門が繁忙期を迎える前の6月末に完了した。外部設計の着手は要件定義完了よりも2週間ほど早かったが、整合性をリスクとして捉えていたため、要件定義の内容修正に合わせて外部設計の内容を適宜行うことができた。軽微なものを含めると20回程度の修正が発生していた。要件定義の内容修正は、1日1回の朝会で発生するたびに外部設計部隊に伝えていたことが特に良かったと考えている。

　(2)二段階リリースの必要性をステアリングコミッティにて説得し、A社役員の協力を得られたこと

　ステアリングコミッティにて、コストを上げない方法は二段階リリースしかなく、二段階リリースしたとしても業務影響はゼロで済むことを説明できたことが特に良かった。業務影響が無いことが、A社役員が販売部門をはじめとするユーザー部門を説得する際の決め手となった。

　３－２　今後の改善点（524）

　今後の改善点は、ファストトラッキングを用いた際の原価上昇分を抑えることであると考えている。今回、一部の並行作業や整合性リスクに対する情報連携強化・設計書の修正により、作業のオーバーヘッドや重複が発生している。結果、外部設計工程を中心に、原価が5％上振れした。これは当初に確保していたコンティンジェンシー予備費の全額だ。ファストトラッキングによる効率低下に伴い、新たなリスクとしてコストも重点監視項目として捉えていたので、コストが際どかったことは把握していたが、危うかったとも言える。

　原価が5％も上振れした主な原因は、ファストトラッキングについて、社内の知見が少なかったことが挙げられる。今回、情報共有の方法や設計書の修正頻度など、効率を高められる余地はあった。Z社では今回のような納期・スケジュールに関する問題が生じた場合、クラッシングを採用することが多かった。コストの承認が得られれば、ファストトラッキングより低リスクであることが多いためだ。結果、ファストトラッキングの知見は少ない。これを機に、ファストトラッキングの手法についても知見を可視化し、標準化を進めていきたい。そうすれば、原価の上振れ分をより抑えることができるだろうと考えている。

まとめ

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

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