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

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

問題文および設問

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

問題文

問１　システム開発プロジェクトにおける非機能要件に関する関係部門との連携について

　システム開発プロジェクトにおいて、プロジェクトマネージャ（ＰＭ）は、業務そのものに関わる機能要件に加えて、可用性、性能などに関わる非機能要件についても確実に要件が満たされるようにマネジメントしなければならない。特に非機能要件については、利用部門や運用部門など（以下、関係部門という）と連携を図り、その際、例えば、次のような点に注意を払う必要がある。
・非機能要件が関係部門にとってどのような意義をもつかについて関係部門と認識を合わせる
・非機能要件に対して関係部門が関わることの重要性について関係部門と認識を合わせる
　このような点に注意が十分に払われないと、関係部門との連携が不十分となり、システム受入れテストの段階で不満が続出するなどして、場合によっては納期などに大きく影響する問題になることがある。関係部門と連携を図るに当たって、ＰＭはまずプロジェクト計画の段階で、要件定義を始めとする各工程について、非機能要件に関するＷＢＳを設定し、ＷＢＳの各タスクの内容と関係部門を定め、関係部門の役割を明確にする。次に、関係部門と十分な連携を図るための取組みについて検討する。それらの内容をプロジェクト計画に反映した上で、関係部門を巻き込みながら一体となってプロジェクトを推進する。

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

設問ア

あなたが携わったシステム開発プロジェクトの特徴、代表的な非機能要件の概要、並びにその非機能要件に関して関係部門と連携を図る際に注意を払う必要があった点及びその理由について、８００字以内で述べよ。

設問イ

設問アで述べた代表的な非機能要件に関し、関係部門と十分な連携を図るために検討して実施した取組みについて、主なタスクの内容と関係部門、及び関係部門の役割とともに、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた取組みに関する実施結果の評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトと非機能要件の概要

１．１．プロジェクト概要
　私が担当したプロジェクトは、全国数百店舗を持つ大手小売業向け新ＰＯＳシステムの導入である。目的は、既存システムの老朽化対策と、リアルタイムの売上・在庫連携強化による迅速な経営判断、顧客サービス向上であった。特徴は、既存システムとの複雑なデータ連携、クリスマス商戦前の１１月完了というタイトな納期、予算と情報システム部の運用要員という経営資源の制約であった。

１．２．代表的な非機能要件の概要
　本プロジェクトで特に重視した非機能要件は「性能」と「運用性」であり、関係部門との連携で注意が必要だった。
１）性能要件：ピーク時応答時間３秒以内
　これは、顧客満足度維持に直結する重要要件だった。しかし、関係部門間で認識のずれがあり、注意が必要だった。利用部門（店舗運営部、商品部）は感覚的に速さを求める一方、目標値のビジネスインパクト（レジ待ち短縮効果等）への理解が不足していた。対して運用部門（情報システム部）は、高性能インフラのコスト増を懸念し、目標値の妥当性に慎重だった。このずれは、テストでの性能未達や過剰スペックのリスクを生む。顧客満足度向上という経営戦略達成のため、関係部門間で性能要件の意義と目標値の根拠ある合意形成が不可欠だった。
２）運用性要件：目標復旧時間（ＲＴＯ）１時間以内、および限られた運用要員での対応可能な障害手順の簡便化。
　運用部門（情報システム部）と外部保守ベンダー間で、障害時の役割分担（作業範囲、責任、スキル）が曖昧だった点に注意が必要だった。特に、一次切り分けの主体やエスカレーション基準が不明確だった。この状態は、迅速な対応を阻害しＲＴＯ未達や販売機会損失のリスクを生む。限られた人的リソース下での効率的な運用体制構築のため、役割分担の明確化が急務だった。

（７９３文字）

設問イ

２．関係部門との連携強化のための取組み

　非機能要件に関する部門間連携の課題解決のため、以下の取組みを実施した。

２．１．プロジェクト計画段階での取組み

　計画段階で、非機能要件のタスクと責任体制を明確化した。
１）非機能要件に関するＷＢＳの明確化
　非機能要件定義、性能目標設定、性能テスト、運用テスト、障害復旧検証等のタスクをＷＢＳに設定した。非機能要件に関する作業をプロジェクト全体の中で可視化する必要があると考えたからである。
２）役割分担の明確化
　ＷＢＳタスク毎に、関係部門の役割と責任を役割分担表（ＲＡＣＩ）で定義し、関係部門代表者会議で合意した。例えば「性能目標設定」では、利用部門を「協業先（ビジネス要件提示）」、運用部門を「協業先（実現可能性・コスト評価）」、開発チームを「実行責任者」、ＰＭを「説明責任者」と定義した。「誰が何に責任を持ち」「誰と協力し」「誰に報告・相談すべきか」を、明確にすることが目的だった。
３）非機能要件専門チーム設置
　ＰＭ、開発リーダー、インフラ担当、利用・運用部門代表から成るチームを組成し、週次定例会議を設定した。非機能要件の課題を、部門横断での解決する機能が必要だからである。

２．２．性能要件に関する取組み

　性能要件の認識ずれ解消と合意形成のため、以下を実施した。
１）ワークショップ開催
　共通目標に向けた建設的な議論の場として、利用・運用部門、開発チームの主要メンバーで、応答時間とビジネスインパクト（レジ待ち時間等）の関係分析、性能目標値（３秒以内）の妥当性検証と合意などを行う、ワークショップを開催した。利用部門は実オペレーションに基づく要件提示、運用部門はインフラ構成案とコスト・実現可能性評価、開発チームは技術的実現方法提示を担った。特に、応答時間悪化時の影響をシミュレーションしたことが、目標値の妥当性合意に有効だった。
２）性能テスト計画への早期関与
　性能要件が確実に満たされることを確認するため、性能テスト計画の策定段階から利用部門と運用部門に関与してもらった。主なタスクは、業務シナリオに基づくテストケースの作成、本番環境に近いテスト環境の準備協力、テスト結果の評価であった。利用部門は「ピーク時の業務シナリオ（商品点数、同時利用レジ数など）の提供」、運用部門は「本番環境のインフラ構成や運用負荷を考慮したテスト環境の評価や、テスト結果からインフラサイジングの妥当性判断」の役割を担った。

２．３．運用性要件に関する取組み

　役割分担の曖昧さ解消と迅速な復旧体制構築のため、以下を実施した。
１）障害復旧手順の共同策定と役割明確化
　障害パターン洗い出し、切り分け・復旧手順書作成、ＲＡＣＩに基づく各手順書における役割明確にするため、運用部門、外部保守ベンダー、開発チームが共同で障害復旧手順を策定するタスクを設けた。運用部門は「主体的な手順策定と実現性評価」、外部ベンダーは「技術知見の提供とサポート範囲・連携方法の明確化」、開発チーム「技術情報の提供」を担った。これは、共同策定を通じて、運用部門の当事者意識を向上する狙いがあった。
２）運用テスト（障害復旧訓練）の共同実施
　障害復旧手順の実効性確認と連携強化のため、運用部門と外部ベンダーが共同で障害復旧訓練を実施した。具体的には、訓練シナリオ作成、訓練実施、結果評価と手順書へのフィードバックを実施した。運用部門は訓練計画・実行と評価、外部ベンダーはサポート体制機能確認を担った。また、訓練結果に基づき、手順書の不明確な点や連携上の課題を洗い出し、改善サイクルを回すプロセスとした。共同訓練は、机上の手順を実践的にスキルに昇華させ、スムーズな連携を確実にする上で不可欠だった。

（１５９６文字）

設問ウ

３．取組みの評価と今後の改善点

３．１．実施結果の評価
　前述の取組みは、プロジェクト目標達成と非機能要件充足に貢献し、有効であったと評価する。
１）性能要件評価
　「ピーク時応答時間３秒以内」の目標を達成した。また、受入れテストでの性能指摘は過去比約７０％削減され、テスト期間短縮にも繋がった。本番稼働後のピーク時も安定稼働し、レジ待ち時間短縮により顧客満足度向上という目的に貢献できた。これは、ビジネスインパクトの可視化による目標値の妥当性への合意形成と、早い段階で利用部門と運用部門に性能テストに関与してもらった結果である。
２）運用性要件評価
　共同での復旧手順策定と訓練で役割分担は明確化し、連携はスムーズになった。責任の所在を明確し図解された手順書は、運用部門から「分かりやすく自信を持って対応できる」と評価された。本番稼働後の障害発生時も、目標ＲＴＯである１時間以内を達成でき、店舗運営への影響を最小化できた。運用部門の、当事者意識と実践スキルを高めた結果と評価する。
３）全体評価
　プロジェクトは、計画通り納期・予算内で完了できた。これは、関係部門を巻き込みんで、非機能要件実現に取り組んだことが成功要因と考える。

３．２．今後の改善点

　今回の経験を踏まえ、今後のプロジェクトで非機能要件連携を改善するため、以下を強化したい。
１）非機能要件定義の早期化・網羅性向上
　今回は性能と運用性中心だったが、他非機能要件の検討開始がやや遅れた。今後は、非機能要求グレードなどのチェックリストを活用し、企画段階での要求レベル早期具体化と関係部門間で初期合意形成を目指す。これにより、手戻りはさらに削減できると考える。
２）関係部門間のコミュニケーション活性化
　情報共有が特定の担当者に集中したり、会議外での部門間のコミュニケーションが不足したりする場面も見られた。今後は、プロジェクト管理ツールやチャットツールを活用し、非機能要件に関する質疑応答、課題共有、意思決定プロセスをオープンかつ迅速に行う環境を整備する。
３）運用部門の計画的スキル向上支援
　新システムの導入に伴い、運用部門には新たな技術スキルが求められたが、その習得支援はプロジェクト終盤に集中しがちであった。今後は計画段階で必要スキルを定義し、体系的トレーニング計画（座学、技術移管、ＯＪＴ等）を策定・実行する。
４）外部ベンダー連携の早期化・精緻化
　外部ベンダーとの連携は、開発がある程度進んでから本格化するケースが多いが、今回は役割分担の細部で調整が必要な場面があった。今後は、計画段階あるいはベンダー選定段階から、運用部門／開発チーム／外部ベンダーで、ＳＬＡ／連携フロー／責任分界点を合意文書化し、契約上のリスク低減と、シームレスな保守運用体制を早期確立する。

（１２００文字）

まとめ

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

参考図書

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

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