プロマネ午後Ⅱ論文の書き方がわからない人へ｜一発で合格した実務経験者のサンプル解答【令和３年度：問２】

プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　システム開発プロジェクトにおけるスケジュールの管理について

　プロジェクトマネージャ（ＰＭ）には、プロジェクトの計画時にシステム開発プロジェクト全体のスケジュールを作成した上で、プロジェクトが所定の期日に完了するように、スケジュールの管理を適切に実施することが求められる。
　ＰＭは、スケジュールの管理において一定期間内に投入したコストや資源、成果物の出来高と品質などを評価し、承認済みのスケジュールベースラインに対する現在の進捗の実績を確認する。そして、進捗の差異を監視し、差異の状況に応じて適切な処置をとる。
　ＰＭは、このようなスケジュールの管理の仕組みで把握した進捗の差異がプロジェクトの完了期日に対して遅延を生じさせると判断した場合、差異の発生原因を明確にし、発生原因に対する対応策、続いて、遅延に対するばん回策を立案し、それぞれ実施する。
　なお、これらを立案する場合にプロジェクト計画の変更が必要となるとき、変更についてステークホルダの承認を得ることが必要である。

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

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴と目標、スケジュールの管理の概要について、８００字以内で述べよ。

設問イ

設問アで述べたスケジュールの管理の仕組みで把握した、プロジェクトの完了期日に対して遅延を生じさせると判断した進捗の差異の状況、及び判断した根拠は何か。また、差異の発生原因に対する対応策と遅延に対するばん回策はどのようなものか。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた対応策とばん回策の実施状況及び評価と、今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトの特徴と目標、スケジュール管理の概要

１．１．プロジェクトの特徴と目標

　私が担当したプロジェクトは、大手製造業の基幹システムである生産管理システムを、オンプレミス環境からクラウド環境へ再構築するプロジェクトであった。私は開発ベンダー側のプロジェクトマネージャとして参画した。

１）プロジェクトの特徴
・既存システムはドキュメント不備等でブラックボックス化が進み、現行調査に時間を要する
・複数部門・システムとの複雑な連携があり、ステークホルダが多岐にわたる
・会計年度切替に合わせたタイトな納期と、抑制的な予算制約がある
２）プロジェクトの目標
・１２ヶ月後の顧客会計年度開始に合わせて新システムを本番稼働させる
・高い可用性・正確性の品質目標、契約金額内でのコスト目標達成
・スコープは現行機能の踏襲を基本としつつ、一部機能改善を含む

１．２．スケジュール管理の概要

　スケジュール管理においては、プロジェクト全体のＷＢＳを作成し、タスク間の依存関係やマイルストーンを設定した上で、ガントチャートを用いて可視化した。これを基にベースラインスケジュールを策定し、進捗を監視する仕組みを構築した。
　具体的には、週次でチームリーダーから作業時間、残作業、完了見込み、課題・リスクについて報告を受けた。私は報告内容を集約・分析し、出来高・品質も評価した。主要工程はＥＶＭを導入し、スケジュール差異やコスト差異を定量的に把握した。ＳＰＩが１．０を下回るタスクは詳細な差異分析の対象とした。情報は週次レビューでチームリーダーと共有し、遅延やコスト超過の兆候を早期発見し、処置を検討した。隔週の顧客向け定例会議では、主要マイルストーンと全体スケジュール状況を報告した。これにより、ベースラインからの乖離を早期検知し、遅延リスク抑制を目指した。

（８００文字）

設問イ

２．進捗遅延の状況、原因、挽回策

２．１．進捗差異の状況と遅延判断の根拠

　プロジェクト開始約５ヶ月後の詳細設計終盤、外部システムとの連携部分に関する設計タスクでの遅延を把握した。当初計画から約３週間遅れる見込みで、後続の開発工程・テスト工程開始に直接影響し、結合テスト開始遅延による品質目標未達も危ぶまれた。

　プロジェクト完了期日遅延に繋がると判断した根拠は次の通り。
１）当該タスク完了率が計画より３０パーセント以上低く、残作業が増加した
２）対象工程のＳＰＩが０．８５まで低下した
３）遅延タスクがクリティカルパス上に位置し、完了期日に間に合わない可能性が高い

　この判断に基づき、顧客へ状況を速報し、定例会議で報告・対策協議をすることにした。

２．２．遅延の発生原因に対する対応策

　遅延の発生原因を特定するため、担当者ヒアリング、ドキュメントレビューに加え、特性要因図で分析した結果、主な原因を２つ特定し、対応策を実行した。

１）既存システム調査不足
　特に古い外部連携部分に関するドキュメントが皆無に等しく、当時の担当者も既に退職していたため、仕様の正確な把握に想定以上の時間を要した。
＜対策＞現行システムのログを詳細に分析するためのツールを導入し、実際のデータフォーマットや連携頻度を定量的に把握する。さらに、関連業務部門のキーマンに、過去のシステム改修履歴や運用上の注意点について集中的にヒアリングを実施する。

２）顧客とのコミュニケーション不足
　顧客側の販売管理システムおよび物流システム担当者との、仕様確認におけるコミュニケーション不足があった。顧客担当者が多忙であったことと、こちらからの問い合わせが散発的であったため、回答が得られるまでに時間がかかり、設計作業がブロックされることが頻繁に発生した。
＜対策＞顧客とのシステム連携仕様確認に特化した週２回の３０分間定例会議を別途設定する。会議の目的、アジェンダ、必要な情報を事前に共有し、議事録を即時配布することで、効率的なコミュニケーションを図る。また、会議設定や資料準備をサポートする専任者を配置する。

　これらの対応策は根本原因の排除と再発防止に重点を置き、特にコミュニケーション不足改善を最優先とした。

２．３．遅延に対する挽回策

　発生した３週間の遅延を挽回するため、経営資源の制約（予算、リソース、納期）を踏まえ、以下の挽回策を採用した。

１）応援要員アサイン
　他プロジェクトからシステム連携設計の経験があるエンジニアを１名、短期間（２週間）限定で応援要員としてアサインする。これにより、遅延している設計タスクのうち、特に調査や資料作成といった負荷のかかる部分を分担してもらい、担当エンジニアの負荷を軽減する。
２）バッファ活用とリソース集中
　ＷＢＳ上のクリティカルパス上のタスクに対するバッファを再評価し、可能な範囲で活用する。また、同時期に進行している非クリティカルパス上のタスクの一部優先度を一時的に下げ、遅延している設計タスクへチーム全体のリソースを集中させるよう、作業分担や計画を見直す。
３）工程の並行実施
　設計完了部分から順次、後続工程である開発・単体テスト工程の一部を先行して開始する。これにより、工程間の待ち時間を短縮し、全体期間の圧縮を図る。ただし、設計変更による手戻りリスクを伴うため、設計レビューをさらに厳格に行う。

　これら挽回策の実施には計画変更が必要なため、ＷＢＳ・ガントチャート修正、影響範囲（スケジュール、リソース、コスト）をまとめた変更提案書を作成した。これをリスク・懸念事項と共に顧客へ提出し、複数協議を経て、新たなベースライン計画の承認を得た。

（１５９３文字）

設問ウ

３．対応策と挽回策の実施状況、評価、今後の改善点

３．１．対応策と挽回策の実施状況

・既存システム調査不足対策
　現行システムの稼働ログを専用ツールで詳細に分析し、想定していなかったデータ連携のパターンや特殊な処理タイミングを把握した。また、顧客社内の過去のシステム担当者や、現行システムの運用に詳しい業務部門のベテラン社員に集中的にヒアリングを行い、ドキュメントにはない暗黙知や過去のトラブル事例を収集した。
・顧客とのコミュニケーション不足対策
　顧客の販売管理・物流システム担当者との間で、週２回の３０分間のシステム連携仕様確認専門のオンライン定例会議を新たに設定した。会議では事前に確認事項リストと関連資料を送付し、不明点を具体的に提示することで、短時間でも効率的に確認が進むよう工夫した。
・応援要員アサイン
　別プロジェクトから期間限定でシステム連携経験のあるエンジニアを１名アサインしてもらい、既存システム調査で得られた情報の整理や、他システム担当者との事前調整といったタスクの一部を依頼した。
・バッファ活用とリソース集中
　ＷＢＳ上の非クリティカルパス上のタスクのうち、優先度の低いもの（内部管理用レポート機能の詳細設計）を一時保留とし、該当メンバーを遅延タスクの資料作成や調査サポートに回した。
・工程の並行実施
　外部連携設計が完了した部分から、依存関係のないモジュールの開発・単体テストを先行して開始した。これに伴い、テストチームは先行してテスト設計やテストデータ準備に着手した。また、少しでも設計変更が発生した場合は直ちに開発・テスト担当者と共有するために、毎日朝会で担当者間での情報共有を行った。潜在的な手戻りリスクの早期検知が狙いであった。

３．２．実施状況の評価

　外部連携設計タスクの遅延を計画から１週間遅れまで短縮でき、最終納期への影響が１週間未満で吸収できた。工程の並行実施は、リスク管理により大きな手戻りはなかった。
　特に顧客とのコミュニケーション改善策が効果的で、仕様確認リードタイムが短縮され、以降のタスクにおいて、顧客との連携に起因する手戻りや遅延は発生しなくなった
　以上から、対応策と挽回策はおおむね有効に機能したと評価する。

３．３．今後の改善点

　今回の経験から、以下の課題を今後の改善点とする。
１）ドキュメント不備等情報不足リスクに対し、十分なバッファ確保や先行調査を計画に含める。顧客側ステークホルダとの詳細なコミュニケーション計画も早期に策定する。
２）クリティカルパス上のタスクを担当する要員のスキルを計画段階で評価し、リスクが高い場合は複数名担当、専門家早期アサイン等の予防策を計画する。緊急時の社内リソース融通プロセスも整備する。

（１１８３文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。