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

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

問題文および設問

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

問題文

問２　システム開発プロジェクトにおけるスコープのマネジメントについて

　プロジェクトマネージャ（ＰＭ）には、システム開発プロジェクトのスコープとして成果物の範囲と作業の範囲を定義し、これらを適切に管理することで予算、納期、品質に関するプロジェクト目標を達成することが求められる。
　プロジェクトの遂行中には、業務要件やシステム要件の変更などによって成果物の範囲や作業の範囲を変更しなくてはならないことがある。スコープの変更に至った原因とそれによるプロジェクト目標の達成に及ぼす影響としては、例えば、次のようなものがある。
・事業環境の変化に伴う業務要件の変更による納期の遅延や品質の低下
・連携対象システムの追加などシステム要件の変更による予算の超過や納期の遅延
　このような場合、ＰＭは、スコープの変更による予算、納期、品質への影響を把握し、プロジェクト目標の達成に及ぼす影響を最小にするための対策などを検討し、プロジェクトの発注者を含む関係者と協議してスコープの変更の要否を決定する。
　スコープの変更を実施する場合には、ＰＭは、プロジェクトの成果物の範囲と作業の範囲を再定義して関係者に周知する。その際、変更を円滑に実施するために、成果物の不整合を防ぐこと、特定の担当者への作業の集中を防ぐことなどについて留意することが重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトにおける、プロジェクトとしての特徴と、プロジェクトの遂行中に発生したプロジェクト目標の達成に影響を及ぼすスコープの変更に至った原因について、８００字以内で述べよ。

設問イ

設問アで述べた原因によってスコープの変更をした場合、プロジェクト目標の達成にどのような影響が出ると考えたか。また、どのような検討をしてスコープの変更の要否を決定したか。協議に関わった関係者とその協議内容を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたスコープの変更を円滑に実施するために、どのような点に留意して成果物の範囲と作業の範囲を再定義したか。成果物の範囲と作業の範囲の変更点を含めて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要とスコープ変更

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

　私が担当したのは、大手製造業Ａ社の基幹システム（販売・在庫管理）刷新プロジェクトである。Ａ社では老朽化したオフコン基幹システムが障害頻発、データ活用困難、保守困難といった課題を抱えていた。目的は、システム刷新による業務効率化、データ可視化、ＤＸ基盤構築であった。私はＡ社情報システム部門のＰＭとして、計画から終結までを統括した。
　本プロジェクトの特徴は以下である。
１）技術的挑戦
　オンプレミスからクラウド（ＩａａＳ／ＰａａＳ）へ全面移行し、拡張性のため一部マイクロサービス導入も試みた。
２）体制面
　複数事業部門（営業、生産管理、経理）が関連する複雑な業務プロセスが対象で、開発は複数外部ベンダーと協業した。
３）制約
　次年度４月１日稼働厳守で納期遅延は許されなかった。予算はあったがコスト管理も重要で、メンバーのクラウド等のスキルにばらつきがあり、技術共有が課題だった。

１．２．スコープ変更に至った原因

　要件定義・外部設計を完了し、内部設計・開発フェーズに着手した直後、競合Ｂ社がＡＩによる需要予測・在庫最適化機能をリリースし話題となった。Ｂ社は欠品減、在庫圧縮、顧客満足度向上、コスト削減を実現したと報じられた。
　これを受け、Ａ社経営トップから、開発中のシステムへ同様のＡＩ機能追加の強い要望が出た。これがスコープ変更要求の直接的な原因である。当初要件では、ＡＩ活用は想定外だった。この要求は競争優位性維持のための、事業戦略が背景にあった。しかし、ＰＭとして、この要求はＡＩ導入による未知のタスク増、工数増大を招くと認識した。特に納期達成を困難にし、予算超過、品質低下のリスクを強く懸念した。よって本件は、目標達成に重大な影響を及ぼすスコープ変更要求と判断した。

（７８９文字）

設問イ

２．スコープ変更の影響分析と要否判断

２．１．スコープ変更がプロジェクト目標に及ぼす影響の分析

　前述のＡＩ機能追加要求に対し、ＰＭとして、スコープ変更がプロジェクト目標（予算、納期、品質）に及ぼす影響を定量的に分析・評価した。
１）予算への影響
　ＡＩ機能実現に必要なライセンス費、インフラ費、専門家（データサイエンティスト）確保費等で、当初予算比約１５％増が見込まれ、予算超過は必至と判断した。
２）納期への影響
　ＡＩ特有のデータ準備、モデル構築、組込み、テスト等のタスクをＷＢＳに落とし込み工数・期間を見積もった結果、最低３ヶ月の追加期間が必要と結論付けた。これは厳守すべき年度末稼働目標に対し致命的な遅延だった。
３）品質への影響
　以下のリスクが大きいと考えた。
・ＡＩ予測精度：データの質・量、アルゴリズムに依存し、期待精度達成は不確実。
・連携リスク：既存機能との連携で不整合や意図しない挙動の発生。
・テスト不足リスク：納期優先で開発期間を圧縮すればテスト不十分となり、潜在バグ見逃しの可能性が高まる。基幹システムの安定性低下は許容できない。

２．２．スコープ変更の要否の検討プロセス
　影響分析を踏まえ、対応方針の選択肢（変更受入、変更見送り、代替案）を検討し、メリット・デメリットを整理した。
１）変更受入
　経営期待に応え競合対抗力強化。だが予算超過、納期大幅遅延、品質低下リスク受容必須。
２）変更見送り
　当初目標達成。だが経営戦略要求に応えられず市場競争力低下の恐れ、関係者の失望。
３）代替案
　双方の部分的要求充足を目指し以下２案検討。
・案Ａ（フェーズ分け）
　基幹システム本体刷新を予定通り完了させ、ＡＩ機能開発・導入は次フェーズ（第２）とする。
・案Ｂ（機能縮小）
　ＡＩ機能スコープを限定（例：対象製品群絞込）し当初納期内実現を目指す。

　これら選択肢を予算、納期、品質、経営的価値で評価し影響分析マトリクスに整理。ＰＭとして、案Ａ（フェーズ分け）を最善策と推奨した。理由は、基幹システムの安定稼働・納期厳守を達成しつつ、経営要求にも将来実現を約束でき、プロジェクトリスクを分散・低減できると考えたからである。

２．３．関係者との協議とスコープ変更の決定

　要否決定のため、主要関係者（オーナー役員、情報システム部長、利用部門長、開発リーダー、外部コンサルタント）を特定し緊急ステアリングコミッティを招集した。事前に影響分析結果とＰＭ推奨案を共有し、会議では客観データに基づき、各選択肢の影響・リスク、推奨案とその理由を丁寧に説明した。
　協議では、役員からＡＩの戦略重要性と納期遅延懸念が表明された。利用部門長からは基幹システムの安定稼働・予定通リリース最優先の意見が強く出た。開発リーダーは技術的観点からフェーズ分け案の妥当性を補足した。質疑応答を経て、最終的に私の推奨した「フェーズ分け」案を基本方針とすることで合意。ただし経営層意向を汲み、第１フェーズでＡＩ技術調査・検証目的のＰｏＣレベル機能開発をスコープに追加。これにより基幹システム本体の納期影響を最小限（約２週間調整）に留めつつ、次フェーズ準備を進める形でスコープ変更が正式決定され、変更管理プロセスを経て記録・承認された。

（１４０７文字）

設問ウ

３．スコープ変更の円滑な実施のための留意点

３．１．スコープ再定義における基本的な留意点

　決定したスコープ変更を円滑に進めるため、成果物・作業範囲の再定義では以下に留意した。
１）関係者への透明性確保
　スコープの変更内容や影響（予算・納期等）について、全関係者への正確かつ迅速な情報共有が重要と考えた。ステアリングコミッティ議事録配布、改訂版の要件概要書（変更点をハイライト表示）等を周知し、共通認識の確立を図った。
２）プロジェクト目標の再評価と再設定
　ＰｏＣ開発の影響を精査し、現実的な目標を再設定した。具体的には追加コストを見積もり予算を約３％増額修正、関連タスク影響を考慮し納期を約２週間延長した。品質目標は基幹システム本体は当初基準を維持、ＰｏＣ部分は実験的位置づけとし期待値を調整した。

３．２．成果物の範囲の再定義と留意点

　スコープ変更に伴い成果物範囲も再定義した。具体的には、ＰｏＣ関連の成果物（実施計画書、簡易仕様書、テストシナリオ等）を追加。既存の要件定義書はＡＩ本格導入を「第２フェーズ検討事項」と区分、システム構成図にはＰｏＣ環境を追記、計画書は予算・スケジュール・体制変更を反映し改訂した。
　成果物不整合や後続への影響を考え、特に以下に留意した。
１）トレーサビリティ確保
　ＰｏＣ要件と設計・実装・テストの追跡可能性確保のためトレーサビリティマトリクスを作成・維持した。これは結果評価や第２フェーズ引継ぎに不可欠と考えた。
２）インターフェース整合性確保
　ＰｏＣ機能と基幹システム連携は最小限とし、データ連携は一方向（読取専用）に限定、基幹システム影響リスクを遮断。仕様は文書化し合意した。

３．３．作業の範囲の再定義と留意点
　成果物範囲変更に合わせてＷＢＳを更新し、ＰｏＣ関連のタスク群（データ準備、モデル開発、評価等）を追加。各タスクの担当者、工数、依存関係を定義し全体スケジュールに反映させた。
　特に、担当者の負荷の偏りに留意し、以下対応を行った。
１）スキルマップ活用と役割分担
　メンバーのスキルマップを基に、ＰｏＣコアタスククラウド技術に長けた社内メンバー２名と外部データサイエンティストに割り当て、適切な役割分担とした。
２）計画的な負荷分散と知識移転
　ＰｏＣ担当者の既存タスクの一部を、他メンバーへＯＪＴ形式で引継ぎ、負荷分散とチーム全体のスキルアップを図った。属人化防止も期待した。

　上記に加え、円滑な推進のためコミュニケーション計画も見直した。週次定例にＰｏＣ進捗共有を追加、ＰｏＣチーム内での朝会で迅速な課題共有・解決を図った。また、リスク管理表にＰｏＣ特有リスクを追加し、定期モニタリングを行った。これらの工夫で変更に伴う混乱の抑制を目指した。

（１１９３文字）

まとめ

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

参考図書

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

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