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

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

問題文および設問

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

問題文

問２　システム開発プロジェクトにおける、助言や他のプロジェクトの知見などを活用した問題の迅速な解決について

　プロジェクトマネージャ（ＰＭ）には、プロジェクト推進中に品質、納期、コストに影響し得る問題が発生した場合、問題を迅速に解決して、プロジェクトを計画どおりに進めることが求められる。問題発生時には、ステークホルダへの事実関係の確認などを行った上で、プロジェクト内の取組によって解決を図る。
　しかし、プロジェクト内の取組だけでは問題を迅速に解決できず、プロジェクトが計画どおりに進まないと懸念される場合、ＰＭは、プロジェクト内の取組とは異なる観点や手段などを見いだし、原因の究明や解決策の立案を行うことも必要である。このような場合、プロジェクト外の有識者に助言を求めたり、他のプロジェクトから得た教訓やプロジェクト完了報告などの知見を参考にしたりすることがある。
　こうした助言や知見などを活用する場合、ＰＭは、まず、プロジェクトの特徴のほか、品質、納期、コストに影響し得る問題の内容、問題発生時の背景や状況の類似性などから、有識者や参考とするプロジェクトを特定する。次に、有識者と会話して得た助言やプロジェクト完了報告書を調べて得た知見などに、プロジェクト内の取組では考慮していなかった観点や手段などが含まれていないかどうかを分析する。そして、解決に役立つ観点や手段などが見いだせれば、これらを活用して、問題の迅速な解決に取り組む。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、及びプロジェクト内の取組だけでは解決できなかった品質、納期、コストに影響し得る問題について、８００字以内で述べよ。

設問イ

設問アで述べた問題に対して、解決に役立つ観点や手段などを見いだすために、有識者や参考とするプロジェクトの特定及び助言や知見などの分析をどのように行ったか。また、見いだした観点や手段などをどのように活用して、問題の迅速な解決に取り組んだか。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた特定や分析、問題解決の取組について、それらの有効性の評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と問題

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

　私がプロジェクトは、大手製造業Ａ社向けの生産管理システム刷新プロジェクトである。目的は、老朽化した既存システムを刷新し、ビジネス要求への対応速度向上、クラウド化によるコスト削減と拡張性確保であった。私はＰＭとして全工程を管理した。
　本プロジェクトの特徴は、大規模（期間約２年、ピーク時５０名）であること、クラウドネイティブ技術（マイクロサービス、コンテナ等）を全面的に採用したこと、主要夜間バッチに４時間以内完了という厳しい性能要件があったことである。また、経営資源の制約として、開発チームのクラウドネイティブ技術経験が不足しており、人的リソース（スキル）面に課題があった。

１．２．プロジェクト内の取組だけでは解決できなかった問題

　結合テスト後半で、主要夜間バッチ（部品所要量計算）の処理時間が目標の４時間を大幅に超え、８時間以上かかる性能問題が発生した。この問題は、品質（翌日生産計画遅延リスク）、納期（後続テスト遅延、稼働延期リスク）、コスト（要員・調査改修コスト増）の全てに深刻な影響を与えるものであった。
　直ちにチーム内でボトルネック調査と対策（ＳＱＬチューニング、ロジック見直し、インフラパラメータ調整等）を約３週間実施した。しかし、処理時間は６時間程度まで改善したが、目標には及ばず改善も頭打ちとなった。さらなる改善のためには、クラウドネイティブ技術特有の要因（サービス間通信、コンテナ挙動、ＤＢコネクション管理等）に起因する根本原因を解決する必要があるが、チーム内のスキル制約から、内部だけでは対処が困難だった。このままでは計画遅延は必至と考え、プロジェクト外部の助言や知見が必要と判断した。

（７５１文字）

設問イ

２．プロジェクト外の有識者や教訓を活用した問題解決の取組

２．１．有識者及び参考とするプロジェクトの特定

　外部の助言・知見を活用するにあたって、「問題の性質（クラウドネイティブ環境での複雑な性能問題）との類似性」「解決の迅速性（アクセスしやすく協力が得やすい社内リソース優先）」の観点で、以下の有識者とプロジェクトを特定した。

２）社内のクラウド推進専門チーム（ＣＣｏＥ）リーダーＡ氏
　Ａ氏は全社のクラウド導入支援を担当し、大規模システムのクラウド移行や性能問題解決の実績が豊富であり、アーキテクチャレベルでの的確な助言が期待できたためである。Ａ氏に状況を説明し協力を得た。

３）約３年前に完了した販売管理システム刷新プロジェクト
　社内ナレッジを検索したところ技術（クラウドネイティブ）、課題（類似の性能問題発生・解決実績）、成果物（完了報告書あり）の点で類似性が高く、このプロジェクトの教訓が今回の問題解決に直接役立つと考えた。

２．２．助言及び知見などの分析

１）有識者からの助言の入手と分析
　Ａ氏にアーキテクチャ図や性能データ等を共有しヒアリングを実施した。Ａ氏からは、「ＤＢコネクションプーリング設定の不備」「重い処理の同期実行によるボトルネック（非同期化検討）」「コンテナ環境のリソース監視不足」という３つの重要な指摘を得た。これらの助言によって、我々の検討がアプリロジック等に偏り、アーキテクチャやミドルウェア設定といったクラウドネイティブ特有の観点が欠けていたことが確認できた。

２）参考プロジェクトからの知見の入手と分析
　販売管理プロジェクトの完了報告書を精読した。そこには、性能問題への対応経緯、具体的な解決策（ＤＢコネクションプーリングの推奨値、非同期処理パターン、効果的な監視ツール設定例等）が詳細に記述されていた。これらの知見は、Ａ氏の助言を裏付ける具体的かつ実践的な情報であり、即座に試行する価値が高かった。

２．３．見いだした観点や手段などを活用した問題解決への取組

　問題解決には、下記の要領であたった。

１）対策候補のリストアップと優先順位付け
　助言と知見を統合し、対策候補として以下の４点をリストアップした。
①ＤＢコネクションプーリング見直し
②バッチ処理一部非同期化
③コンテナ環境監視強化
④キャッシュ活用
　これらのうち「期待効果」「実装期間」「影響範囲」を考慮し、即効性と効果が期待できる①を最優先とし、原因特定に不可欠な③を次点とした。②④は①③の結果を見て判断することとし、担当割り当てと１週間の作業計画、日次進捗確認を決定した。

２）解決策の実施と効果測定
　計画に基づき①を実施した。参考にしたプロジェクトの推奨値を適用した結果、処理時間は約５時間に短縮（約３時間改善）したが、目標未達であった。並行して③を進め、専用ツールで詳細監視したところ、特定コンテナでのメモリリークを発見し、これが新たなボトルネック特定に繋がった。該当コードを修正後、再測定で処理時間は目標内の３．５時間となり、問題は完全に解決した。そのため、②④は不要となった。

３）迅速な解決への貢献
　内部で３週間行き詰まっていた問題が、外部の助言・知見活用により、根本原因（ＤＢコネクション設定、メモリリーク）を特定し、約２週間で解決できた。この迅速な解決により、後続テストへの影響を最小化し、プロジェクト全体の納期遅延を回避できた。これは、外部の知見を活しなければ達成できなかった成果である。

（１５１３文字）

設問ウ

３．問題解決の取組の評価と今後の改善点

３．１．問題解決の取組の評価

　問題解決の取り組みを、下記の観点で評価した。

１）問題解決の迅速性
　内部で３週間行き詰った問題を、外部知見活用開始から約２週間で解決でき、納期遅延を回避した。
２）解決策の質
　外部知見により、内部で見落としていたアーキテクチャやミドルウェア設定、監視手法といった質の高い観点が得られ、メモリリーク等の根本原因特定と恒久対策に繋がった。
３）人的リソース制約の克服
　チームのスキル不足という制約を、迅速かつ低コスト（社内リソース活用）で効果的に補完できた。
４）チームの学び
　問題解決プロセスを通じて、チームは新技術環境での問題解決手法や外部知見活用の重要性を実践的に学び、今後の対応力強化に繋がった。

　以上のことから、一連の外部知見を活用した取り組みは、極めて有効であったと評価する。深刻な性能問題を解決し、プロジェクト目標達成に不可欠な貢献を果たした。内部での試行錯誤継続を選択していた場合、納期遅延やコスト超過のリスクは非常に高かったと考える。

３．２．今後の改善点

　今回の成功体験を踏まえ、更なる改善のため以下を実施すべきと考える。

１）リスク評価プロセスへの組込み
　プロジェクト計画段階で実施するリスク評価のアクティビティにおいて、「類似プロジェクトの教訓・失敗事例の分析」と「利用技術に関する専門家レビュー」を必須項目として組み込むプロセスを導入する。特に、今回のような新技術の採用や、厳しい非機能要件（性能、セキュリティ等）が課せられるプロジェクトにおいては、これらの活動を重点的に実施し、潜在的な問題を設計段階で洗い出し、予防策を検討する。これにより、後工程での手戻りリスクを低減する。

２）社内ナレッジ共有基盤の強化
　プロジェクト完了報告書、技術的な発見やノウハウ、トラブルシューティング事例、そして各分野の専門家リストといった「組織の知見」を、一元的かつ容易に検索・参照できる社内ナレッジポータルの整備・拡充を推進する。情報の登録・更新プロセスを明確化し、情報の鮮度と質を維持することも重要である。これにより、必要な時に必要な情報へ迅速にアクセスできる環境を整える。

３）教訓共有会の定期的開催
　プロジェクト完了時だけでなく、重要なマイルストーン達成時など、節目ごとにプロジェクトの成功・失敗体験や得られた教訓を共有する会を定期的に開催する。今回の性能問題解決事例も、具体的なプロセスや効果を含めて組織内で共有し、他プロジェクトへの横展開を図る。

　これらの改善を通じて、問題発生を予防し、万一発生した場合でも迅速かつ効果的に対応できる組織能力を高めていきたい。

（１１７７文字）

まとめ

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

参考図書

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

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