【令和５年度：問２】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

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

問題文および設問

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

問題文

問２　組織のプロジェクトマネジメント能力の向上につながるプロジェクト終結時の評価について

　プロジェクトチームには、プロジェクト目標を達成することが求められる。しかし過去の経験や実績に基づく方法やプロセスに従ってマネジメントを実施しても、重要な目標の一部を達成できずにプロジェクトを終結すること（以下、目標未達成という）がある。このようなプロジェクトの終結時の評価の際には、今後のプロジェクトの教訓として役立てるために、プロジェクトチームとして目標未達成の原因を究明して再発防止策を立案する。
　目標未達成の原因を究明する場合、目標未達成を直接的に引き起こした原因（以下、直接原因という）の特定にとどまらず、プロジェクトの独自性を踏まえた因果関係の整理や段階的な分析などの方法によって根本原因を究明する必要がある。その際、プロジェクトチームのメンバーだけでなく、ステークホルダからも十分な情報を得る。さらに客観的な立場で根本原因の究明に参加する第三者を加えたり、組織内外の事例を参照したりして、それらの知見を活用することも有効である。
　究明した根本原因を基にプロジェクトマネジメントの観点で再発防止策を立案する。再発防止策は、マネジメントプロセスを煩雑にしたりマネジメントの負荷を大幅に増加させたりしないような工夫をして、教訓として組織への定着を図り、組織のプロジェクトマネジメント能力の向上につなげることが重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトの独自性、未達成となった目標と目標未達成となった経緯、及び目標未達成がステークホルダに与えた影響について、８００字以内で述べよ。

設問イ

設問アで述べた目標未達成の直接原因の内容、根本原因を究明するために行ったこと、及び根本原因の内容について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた根本原因を基にプロジェクトマネジメントの観点で立案した再発防止策、及び再発防止策を組織に定着させるための工夫について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と目標未達成の事象

１．１．私が携わったプロジェクトの概要と独自性

　私が担当したプロジェクトは、老朽化した基幹システムを刷新し、Ｗｅｂ統合業務システムを構築するものであった。私はプロジェクトマネージャ（ＰＭ）として参画した。

　本プロジェクトは、複数部門利用、大量かつ複雑なデータ移行（約８千種類、延べ３億レコード）、複数ベンダー連携という独自性があった。特に旧データは構造複雑で品質にばらつきがあった。また、厳格な納期とデータ移行専門家不足（人的リソース制約）という課題も抱えていた。

１．２．未達成となった目標とその経緯

　本プロジェクトでは、「移行後のデータ不整合を０．１％未満とする」という品質目標が未達成となった。

　目標未達成の経緯は、要件定義および開発遅延によるスケジュール圧縮にあった。これにより後続のテスト・データ移行リハーサル期間が大幅に圧縮された。結果、テスト回数・期間の削減、テストデータ網羅性不足が重なり、十分な品質チェックができないまま本番移行を迎え、目標を超える不整合が生じた。

１．３．目標未達成がステークホルダに与えた影響

　データ移行目標未達成は、以下のステークホルダに影響を与えた。

１）社内ユーザー
　必須項目欠損等に起因するシステムエラーや手作業でのデータ修正が頻繁に発生し、業務効率が著しく低下した。システムへの信頼感・満足度も低下した。
２）顧客
　データ不整合による請求・出荷の誤り、問い合わせ対応遅れが生じ、クレーム増加や信頼毀損リスクが高まった。
３）経営層
　不整合対応による運用コスト増加、業務停滞による機会損失、ブランドイメージ悪化といった影響が顕在化した。

（７８８文字）

設問イ

２．目標未達成の原因分析

２．１．目標未達成の直接原因

　移行後のデータ不整合率未達成の直接原因は、プロジェクト終盤でのスケジュール圧縮に起因する、データ移行テスト・検証プロセスの不十分さであった。具体的には、計画していた件数照合、突合チェック、ユーザー受入テスト等の重要な検証の回数・期間が遅延の影響で大幅に削減されたことにある。加えて、テストデータが本番データの複雑性や多様な不整合パターンを十分に再現できていなかった。さらに、ＥＴＬツールやカスタムスクリプトによる移行結果の検証手順が標準化されておらず、手動確認に依存した部分が多かったことが複合的に作用し、不整合の見逃しに繋がったのである。

２．２．根本原因分析

　目標未達成を受け、下記の要領で多様な観点で根本原因を特定・整理した。

１）ワークショップ開催
　プロジェクトチーム内で原因分析ワークショップを開催した。時系列を整理するタイムライン分析で問題発生経緯を追跡した。次に、なぜなぜ分析を繰り返し、問題の根源を深掘りした。例えば、「なぜテスト時間が不足したのか？」のように掘り下げた。データ移行テストプロセスについては、特性要因図で要因を「人」「プロセス」「ツール」「環境」に分類し、問題構造を可視化した。
２）ヒアリング実施
　チーム内部視点に加え、広い視点から情報収集するため、データ移行の影響を受けたユーザー部門へヒアリングを実施し、発生した不整合内容や業務影響、現場の懸念点を詳細に聞き取った。経営層へもヒアリングし、事業影響やＰＭへの期待を把握した。
３）第三者レビューと事例参照
　客観性確保のため、データ移行専門知識を持つ社内別部署のＩＴアーキテクトを第三者として加え、移行計画やテスト戦略についてレビューを受けた。組織内外の事例も参照し、過去プロジェクト報告書や公開情報から失敗事例や教訓を調査・比較検討した。

２．３．根本原因の内容

　分析結果から、目標未達成の根本原因は、プロジェクトの独自性や制約を踏まえたマネジメントプロセスの不備にあると結論づけた。具体的には以下の３点である。

１）計画・要件定義段階におけるデータリスク評価の不十分さ
　大量かつ複雑な旧データ（３億レコード規模）の構造複雑性や品質ばらつきは認識していたが、移行リスク（移行エラー、不整合多様性）を十分に深掘りせず、対策を計画に織り込めなかった。データ移行専門家の早期参画がなかったことも一因である。
２）計画段階におけるスケジュール・リスク管理の甘さ
　最初から厳格な納期に対し、要件定義・開発遅延リスクへの計画上のバッファが不足していた。遅延発生時にテスト期間を確保する代替策が事前に検討されておらず、遅延影響がテスト工程に集中し、結果的にテスト期間の圧縮を招いた。現実的なスケジュール計画・リスク対応計画が欠如していた。
３）テスト・検証フェーズにおけるプロセス標準化と関係者連携不足
　計画していた件数照合、突合チェック、ユーザー受入テストといった具体的なテスト・検証方法について、ベンダー間・ユーザー部門間での目的、テストデータ基準、実施手順、期待される検証結果、不整合報告・修正後の再検証プロセスが確立されておらず、不具合報告・修正後の再検証プロセスも曖昧だった。また、複数ベンダーとユーザー部門間でのデータ移行に関する課題・リスク情報（例：検出された不整合パターンの共有、未解決の問題）のタイムリーな共有が不足しており、問題の早期発見・対応が遅れた。

（１４９７文字）

設問ウ

３．再発防止策の立案と組織への定着

３．１．根本原因に基づく再発防止策

　特定した根本原因に基づき、以下の再発防止策を立案した。

１）データ関連のリスク管理の精度向上
　データ要件定義プロセスの強化を行う。企画・計画フェーズからデータ移行専門家を参画させ、既存データの詳細分析と移行リスク洗い出しを必須とするプロセスを標準化する。リスクに基づき、詳細なデータクレンジング計画やデータ変換ルール定義を要件定義・設計に明確に盛り込む。
２）スケジュール管理とリスク管理の実効性向上
　計画段階でのリスク評価強化と適切なバッファ設定ガイドラインを整備する。事例分析に基づき、主要リスク項目と評価基準を作成し、バッファ設定ルールを定める。遅延発生時の代替策（テスト範囲優先順位付け等）を計画に含めることを義務付ける。

３）品質管理とコミュニケーション管理の標準化
　データ移行テスト・検証プロセスの標準化とコミュニケーション強化を実施する。テスト・検証方法（件数照合等）について、目的、基準、手順、結果、不具合報告・再検証プロセスを明確に定義し、標準化する。テンプレートやチェックリストを作成する。データ比較ツール等の自動化活用を推奨する。複数ベンダー・ユーザーが関わる場合、関連課題・リスク・進捗共有のための定例会議や共通課題管理システム利用を必須とする。これは品質管理、コミュニケーションの質向上が目的である。

３．２．再発防止策を組織に定着させる工夫

　再発防止策を組織に定着させ、かつ負荷増加を最小限に抑えるため、下記の工夫をした。これらの工夫は、マネジメントプロセスを過度に煩雑にせず、現場の負荷増加を最小限に抑えることを意識したものだった。

１）教訓の体系的な共有と実践への活用促進
　今回の教訓を完了報告会や研修で共有し、意識改革を促す。標準プロセス等はナレッジベースに登録し、これらの教訓を参照しないと、新しいプロジェクト計画が作成できないように規定する。
２）定着を推進する組織体制と継続的改善活動
　導入・運用を推進する体制を構築する。ＰＭＯが中心となり、適用状況モニタリング、課題収集、改善を行う。リーダー検討会を設置し、ナレッジ共有や課題解決、標準改善を行う。成功事例等を定期報告し、定着の重要性を啓発する。
３）ツール活用による効率化と負荷軽減
　負荷増大を防ぐため、既存プロセス・ツールを最大限活用し、不必要な手続きは避ける。手作業負担を軽減するため、データ比較ツールや自動検証スクリプト活用を推奨する。導入初期には丁寧な説明・サポートを行い、実効性を高める。

（１１２４文字）

まとめ

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

参考図書

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

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