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

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

問題文および設問

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

問題文

問１　未経験の技術やサービスを利用するシステム開発プロジェクトについて

　プロジェクトマネージャ（ＰＭ）は、システム化の目的を実現するために、組織にとって未経験の技術やサービス（以下、新技術という）を利用するプロジェクトをマネジメントすることがある。
　このようなプロジェクトでは、新技術を利用して機能、性能、運用などのシステム要件を完了時期や予算などのプロジェクトへの要求事項を満たすように実現できること（以下、実現性という）を、システム開発に先立って検証することが必要になる場合がある。このような場合、プロジェクトライフサイクルの中で、システム開発などのプロジェクトフェーズ（以下、開発フェーズという）に先立って実現性を検証するプロジェクトフェーズ（以下、検証フェーズという）を設けることがある。検証する内容はステークホルダと合意する必要がある。検証フェーズでは、品質目標を定めたり、開発フェーズの活動期間やコストなどを詳細に見積もったりするための情報を得る。ＰＭは、それらの情報を活用して、必要に応じ開発フェーズの計画を更新する。
　さらに、検証フェーズで得た情報や更新した開発フェーズの計画を示すなどして、検証結果の評価についてステークホルダの理解を得る。場合によっては、システム要件やプロジェクトへの要求事項を見直すことについて協議して理解を得ることもある。

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

設問ア

あなたが携わった新技術を利用したシステム開発プロジェクトにおけるプロジェクトとしての特徴、システム要件、及びプロジェクトへの要求事項について、８００字以内で述べよ。

設問イ

設問アで述べたシステム要件とプロジェクトへの要求事項について、検証フェーズで実現性をどのように検証したか。検証フェーズで得た情報を開発フェーズの計画の更新にどのように活用したか。また、ステークホルダの理解を得るために行ったことは何か。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた検証フェーズで検証した内容、及び得た情報の活用について、それぞれの評価及び今後の改善点を、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と要求事項

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

　私が担当したプロジェクトは、老朽化した顧客向け業務処理システムを、クラウド基盤上に再構築するプロジェクトであった。私はプロジェクトマネージャとして、このプロジェクトに参画した。
　本プロジェクトの特徴は、組織にとって初めてクラウドネイティブ技術を採用することであった。組織内にこれらの新技術に関する知識や経験が乏しいという、人的リソースの制約を抱えていた。また、プロジェクトには短納期での完了と、年間運用コストの大幅削減という、厳しい要求があった。

１．２．システム要件

　本プロジェクトでの主なシステム要件は、次の通り。

１）機能要件
　現行システムの主要業務処理を踏襲しつつ、一部プロセスは新技術を活かした改善を行う。
２）非機能要件
　主に以下の５点が重要であった。
・性能
　ピーク時応答時間を１秒以内に抑え、同時に５０件／秒以上のスループットを安定維持する。
・セキュリティ
　クラウド環境特有のリスクに対応し、組織基準及び外部規制に準拠する。
・可用性
　目標稼働率９９．９％とし、障害時の影響最小化する。
・運用容易性
　環境構築の自動化、効率的な監視・ログ収集・デプロイメント手法を確立する。
・スケーラビリティ
　将来のアクセス増加や拡張に柔軟対応できるアーキテクチャとする。

１．３．プロジェクトへの要求事項

　プロジェクトへの主な要求事項は以下の通りであり、ビジネス目標に結びついたものだった。
・新たな事業計画に合わせ、１年後の年度末までに本番稼働する。
・初期開発コストを抑えつつ、稼働後の年間運用コストを現行比で３０％以上削減する。
・性能、セキュリティ、可用性の目標値を達成し、目標稼働率９９．９％を安定維持する。

（７９０文字）

設問イ

２．検証フェーズにおける実現性検証と計画更新

２．１．検証フェーズでの実現性検証

　システム要件とプロジェクト要求事項について、未経験のクラウドネイティブ技術の実現性を検証するため、開発フェーズに先立って検証フェーズを設けた。主に、技術的適用可能性の評価、開発フェーズのリスク早期特定、計画策定に必要な情報収集が目的だった。制約事項を考慮し、検証範囲を絞り、最も技術的リスクが高い要件に焦点を当てた。

　検証内容は、技術部門、運用部門、情報セキュリティ部門と協議し、プロジェクトの早い段階で検証が必要な「性能」「セキュリティ」「運用容易性」の３つを検証することで合意した。
１）性能に関する検証
　ボトルネックになりやすい主要業務処理をサーバーレス機能として実装し、模擬データと負荷ツールを用いて応答時間とスループットを計測、評価した。
２）セキュリティに関する検証
　クラウド基盤セキュリティ機能とコンテナ／サーバーレス環境の組み合わせで、組織セキュリティ基準を満たせるか検証した。脆弱性管理、通信暗号化、アクセス制御などを確認した。
３）運用容易性に関する検証
　ＩａＣツールを用いた検証環境の自動構築と、アプリケーションの自動デプロイを試み、効率性や運用負荷削減の実現性を確認した。監視・ログ収集機能の活用も検証した。

　残りの「可用性」「スケーラビリティ」は、検証フェーズでの網羅的検証が困難であり、開発フェーズでの実装や稼働後のチューニング・監視強化で対応可能と判断し、対象外とした。

２．２．検証結果の開発フェーズ計画への活用

１）性能検証の結果
　主要業務処理の一部で想定応答時間が得られず、データベース連携設計に起因することが判明した。開発フェーズで設計を見直し、キャッシングやクエリ最適化に重点を置く必要性が生じ、関連タスク工数が増加予測された。
２）セキュリティ検証の結果
　クラウド基盤標準機能だけでは対応困難な要件や、脆弱性スキャンの組み込みが必要と判明し、開発計画に、セキュリティツールの追加導入等のタスクを追加した。これは当初予算外であり、予算増加要因となった。
３）運用容易性検証の結果
　デプロイ手順の複雑化と技術者の知識不足が明らかになった。開発計画に、デプロイメントパイプライン構築工数の追加と、新技術研修の実施期間を含めた。特に技術者スキルギャップは、短納期下での遅延リスクとして要員計画見直しに活用した。

　これらの結果から、開発フェーズのＷＢＳを詳細化し、見積もりを更新した。その結果、開発期間延長と予算増加が必要となった。特定されたリスクと対策は、リスク管理計画に反映させた。

２．３．ステークホルダの理解を得るための活動

　検証で得た情報や更新計画について、主要ステークホルダ（経営層、利用部門、ＩＴ部門など）の理解と承認を得るため、報告会を実施した。
　報告会では、検証結果（特に新技術の適合性と明らかになった、技術的課題）を、性能データやセキュリティ脆弱性パターンなど、定量的データや事例を交えて具体的に報告した。課題の深刻度や対策の必要性を理解させる狙いがあった。
　また、検証結果に基づく計画の変更が、ビジネス影響やプロジェクト成功に寄与するという観点で説明し、経営課題解決に不可欠であることを示した。
　さらに、質疑応答時間を十分に設け、懸念事項に対して具体的に回答した。予算増加や納期延長について、客観的データと代替案を示し、妥当性を説明した。報告会後、必要に応じて個別説明を行い、更新計画の正式承認を得た。検証結果を踏まえたシステム要件見直しについても協議し、関係者間の認識を統一した。この活動でステークホルダの納得を得られ、円滑な推進に繋がった。

（１５９７文字）

設問ウ

３．検証結果と情報活用の評価及び改善点

３．１．検証フェーズで検証した内容の評価と改善点

１）評価
①良かった点
・ＰｏＣによる事前検証は、未経験技術の適用可能性と、性能やセキュリティの技術的ボトルネック早期特定に極めて有効であった。具体的な課題把握で、開発フェーズでの手戻りリスクを大幅に低減できた。
・検証計画策定段階からの関係部門（技術、運用、セキュリティ）巻き込みと合意形成プロセスは、当事者意識を高め、協力体制構築に効果があった。
②課題点
　運用容易性に関する検証スコープが限定的で、ＢＣＰ／ＤＲやバックアップといった非機能要件を網羅できなかった。また、周辺機能や既存連携の検証が不十分で、開発フェーズで新たな課題が発見された。これは、人的リソースと期間の制約下での優先度付けの反省点である。
２）今後の改善点
　検証スコープに周辺機能、非機能要件（ＢＣＰ／ＤＲ、バックアップ、監視体制）を含める検討を行う。そのため、計画段階でシステム全体リスクを詳細分析し、制約下での優先度とスコープをステークホルダと十分協議し決定する必要がある。十分な検証のため、適切な期間とリソース確保の重要性を早期に訴求するスキルを向上させたい。

３．２．検証で得た情報の活用の評価と改善点
１）評価
①良かった点
　検証で特定された課題や必要な追加作業に基づき開発計画を更新したことは、見積もり精度を向上させ、現実的な計画策定に非常に有効であった。予期せぬ課題による計画崩壊リスクを低減できた。客観的な検証結果を根拠にステークホルダへ報告し承認を得たことは、計画変更への納得感を高め、協力的な姿勢を引き出す上で有効であった。リスク管理計画にリスクと対策を反映できたことも重要であった。
②課題点
　検証で得られた「技術者スキル不足」情報を、開発開始前の具体的なスキルアップ研修計画や要員計画に十分連動させきれなかった。結果、開発序盤で技術習得に時間を要し、一部遅延やリソース負荷増加を招いた。予算制約下での外部専門家確保不足も影響した。
２）今後の改善点
　検証で特定されたスキル情報を、開発フェーズ人的リソース計画と密接に連動させるプロセスを強化する。スキル評価に基づき、研修計画を具体的に策定・実行する。制約下では、外部専門家活用も含む要員計画全体を柔軟に見直す体制を構築する。開発フェーズ以降も技術知見を継続収集・共有し、計画やリスク管理に反映される仕組み（技術レビュー会議など）を強化し、技術リスクを継続管理する。

（１０８１文字）

まとめ

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

参考図書

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

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