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

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

問題文および設問

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

問題文

問２　情報システム開発プロジェクトの実行中におけるリスクのコントロールについて

　プロジェクトマネージャ（ＰＭ）には、情報システム開発プロジェクトの実行中、プロジェクト目標の達成を阻害するリスクにつながる兆候を早期に察知し、適切に対応することによってプロジェクト目標を達成することが求められる。
　プロジェクトの実行中に察知する兆候としては、例えば、メンバの稼働時間が計画以上に増加している状況や、メンバが仕様書の記述に対して分かりにくさを表明している状況などが挙げられる。これらの兆候をそのままにしておくと、開発生産性が目標に達しないリスクや成果物の品質を確保できないリスクなどが顕在化し、プロジェクト目標の達成を阻害するおそれがある。
　ＰＭは、このようなリスクの顕在化に備えて、察知した兆候の原因を分析するとともに、リスクの発生確率や影響度などのリスク分析を実施する。その結果、リスクへの対応が必要と判断した場合は、リスクを顕在化させないための予防処置を策定し、実施する。併せて、リスクの顕在化に備え、その影響を最小限にとどめるための対応計画を策定することが必要である。

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

設問ア

あなたが携わった情報システム開発プロジェクトにおけるプロジェクトの特徴、及びプロジェクトの実行中に察知したプロジェクト目標の達成を阻害するリスクにつながる兆候について、８００字以内で述べよ。

設問イ

設問アで述べた兆候をそのままにした場合に顕在化すると考えたリスクとそのように考えた理由、対応が必要と判断したリスクへの予防処置、及びリスクの顕在化に備えて策定した対応計画について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたリスクへの予防処置の実施状況と評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と察知した兆候

１．１．プロジェクト概要

　私が担当したのはＡ銀行の顧客管理（ＣＲＭ）システム刷新プロジェクトである。既存システムの老朽化対応と営業力強化のための新機能追加が目的だった。私はPMとして要件定義からリリースまで担当した。期間１８か月、予算３億円、体制３０名規模のプロジェクトだった。最終目標は品質・予算遵守に加え、法改正対応システムを４月１日に安定稼働させることだった。
　本プロジェクトには、以下の特徴があった。
１）システム特性と開発規模
　刷新対象ＣＲＭは複数の基幹系と連携しインターフェースが複雑だった。また、膨大な顧客データの移行精度と効率が課題だった。開発規模は約５００人月だった。
２）体制とステークホルダー
　開発は協力会社との混成チームだった。利用部門が多岐にわたり要求調整が必要だった。
３）経営資源の制約
　制約として法改正対応のための納期（４月１日）厳守があった。利用部門のＵＡＴ要員確保にも制約があった。採用技術の経験者が少ないスキル制約もあった。

１．２．プロジェクト目標達成を阻害するリスクの兆候

　結合テスト中盤で以下の、兆候を察知した。
１）特定モジュールの品質問題
　週次レビューやツール分析から、顧客情報連携モジュールのバグが突出して多いことが判明した。全バグの約３割が集中していた。さらに、修正後のバグ再発も散見された。バグ密度は目標値の２倍超だった。
２）担当メンバーの高負荷状態
　勤怠データとヒアリングから、担当メンバー２名の残業が、計画値比１５０％超で２週間以上継続していた。ヒアリングでは「連携仕様理解不足や考慮漏れ」「仕様の曖昧な点を自己判断で実装」などが原因との声があった。これはメンバー疲弊による品質低下や遅延を示唆する危険な兆候だと考えた。

（７９１文字）

設問イ

２．リスク分析と対応

２．１．顕在化すると考えたリスクとその理由

　前述の兆候（特定モジュールの品質問題、メンバー高負荷）を放置した場合、以下のリスク顕在化を強く懸念した。
１）品質の大幅低下
　バグ多発・再発は設計の根本欠陥を示唆し、本番での重大障害（業務停止、信用失墜）につながる。影響度「甚大」、発生可能性「高」と判断した。客観的データ（バグ密度、再発率）が欠陥の深刻さを示したためである。
２）致命的なスケジュール遅延
　バグ修正・再テストの工数増とメンバー高負荷により、結合テスト以降が大幅に遅延し、最重要目標の「法改正対応システムの納期内稼働」が不可能になる。影響度「甚大」、発生可能性「高」と判断した。問題の複雑性とメンバー状況から自然回復は見込めず、遅延累積が必至だったためである。
３）コスト超過
　残業代増や修正長期化、後工程でのリカバリ対応で予算超過の恐れがあった（影響度「中」、発生可能性「中」）。
４）モチベーション低下・生産性悪化
　メンバー疲弊によるミス増加や離脱、チーム全体の士気低下を招く恐れがあった（影響度「中」、発生可能性「高」）。

２．２．対応が必要と判断したリスクへの予防処置

　品質低下・遅延リスクはプロジェクト成否に関わるため、即時かつ根本的な対策が必要と判断した。コスト超過・モチベーション低下のリスクも考慮し、以下の予防処置を優先順位を付けて実施した。
１）予防処置１（最優先）：緊急品質レビューと根本原因特定
　対処療法脱却のため、設計・開発・テスト担当に加え、連携先の基幹システム有識者も招集し、３日間集中レビューを実施。レビュー対象は仕様書、設計書、コード、テスト結果とし、なぜなぜ分析で原因を深掘りした。関係者間で事実に基づき原因を特定・共有し、効果的な対策の土台を築く狙いがあった。
２）予防処置２（処置３と並行）：根本原因に基づく修正と再テスト
　レビューで特定した「連携仕様解釈違い」と「異常系考慮漏れ」に対し、設計・コードを修正。影響範囲を再評価し、不足していたテストケース（エラー応答、特定データでの異常系）を追加し再テスト計画を策定・実行した。原因に直接対処しバグ再発を防止、品質を抜本改善すると共に、デグレードを防ぐ効果を期待した。
３）予防処置３（処置２と並行）：開発支援体制の強化
　メンバー負荷軽減と修正・再テスト加速のため、上位承認を得て他チームから連携経験のあるベテラン１名を１ヶ月間、支援要員として緊急アサインした。人的リソース制約に対応し、負荷分散とスキル活用で作業加速・品質向上を図り、遅延を最小化するためである。

　実施優先度は、原因特定（予防処置１）を最優先とし、次に修正・再テスト（予防処置２）と体制強化（予防処置３）を並行して進めた。

２．３．リスクの顕在化に備えて策定した対応計画

　予防処置でもリスク顕在化の可能性は残るため、万一に備え以下の対応計画（コンティンジェンシープラン）を策定し、事前にステークホルダーと合意した。
１）対応計画１（品質リスク残存時）
　総合テスト完了時点で、当該モジュールに重要バグ残存や目標品質未達（トリガー）の場合、リリース判定会議で「（Ａ案）機能制限付きリリース」「（Ｂ案）リリース延期」を提案。経営層が最終判断できるよう、リスク評価と影響試算等の判断材料を準備する。
２）対応計画２（スケジュール遅延顕在化時）
　結合テスト完了が計画比２週間以上遅延（トリガー）の場合、まず後続テストを優先度で見直し短縮する。それでも納期遵守困難なら、最終手段として追加予算確保の上でさらなる要員追加や休日稼働を検討する。

（１５６２文字）

設問ウ

３．予防処置の評価と今後の改善点

３．１．予防処置の実施状況と評価

１）実施状況
　計画した予防処置を迅速に実施した。予防処置１の緊急品質レビューを３日間行い、基幹システム有識者も含む関係者で根本原因（連携仕様解釈違い、異常系考慮漏れ）を特定・共有した。次に予防処置２として、原因に基づき設計・コード修正、テストケースを追加し、再テストを約２週間で完了した。並行した予防処置３では、他チームの経験豊富な支援要員１名が１ヶ月間、修正・再テストをサポートした。

２）有効性評価
　一連の予防処置は、以下の点でリスク抑制に有効だったと評価する。
・品質
　根本原因への対策が奏功し、バグ再発率は約８０％減少し品質目標を達成できた。これにより後工程での重大問題発生を防いだ。
・スケジュール
　迅速な対応により結合テストの遅延を１週間に抑制できた。この遅延は後工程で吸収し、最終納期である４月１日稼働を遵守できた。早期判断とリソース投入が重要だった。
・コスト面
　追加要員費用は発生したが、品質問題長期化による深刻なコスト増大リスクを回避し、予算超過を１％未満に抑制できた。
・メンバー負荷
　担当者の残業は計画値内に回復し、モチベーション低下や生産性悪化を防ぐ効果があった。
　以上から、予防処置は品質・納期・コスト・メンバー健全性の観点から有効に機能し、プロジェクト目標を達成した評価する。

３．２．今後の改善点

　「計画・設計段階でのリスク特定・評価と予防策織り込みの重要性」「スキルミスマッチへの早期対応の必要性」を今回の教訓と捉え、今後の改善点を以下のように考える。
１）リスク評価プロセスの重点化と早期化
　今後のプロジェクトでは、計画段階でシステム連携部など特定リスク領域の評価を強化する。専門家を交えたリスク分析を行い、より実効性のある予防策を早期に計画へ組み込むプロセスを標準化する。
２）スキル管理とタスクアサインメントの最適化
　メンバーとタスクのスキルマッチング精度を高める仕組みを導入する。スキルギャップがある場合は、早期に教育計画やメンター制度などのサポート体制を確立し、スキル不足リスクを未然に防ぐ。
３）定量的データに基づくリスク兆候モニタリングの高度化
　バグ密度や稼働状況に加え、課題解決リードタイム等の指標も活用し、計画時に閾値を設定する。定量的データに基づく早期の兆候モニタリング仕組みを強化し、迅速な対応を可能にする。
４）組織的なナレッジマネジメントの推進
　今回のリスク対応の経験（兆候、原因分析、対策、効果）を具体的な教訓として整理し、組織ナレッジとして共有する。これにより、組織全体のプロジェクト遂行能力向上と類似問題の再発防止に貢献する。

（１１７８文字）

まとめ

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

参考図書

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

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