令和5年度 春期 プロジェクトマネージャ 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
システム開発プロジェクトにおけるステークホルダとのコミュニケーション計画について
設問ア
0 / 800 字あなたが携わったシステム開発プロジェクトの概要と、ステークホルダ構成の特徴について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行で対象（業種／規模／自身の役割）を提示し、文脈を即座に把握できる構成にする
- 背景は3要素以上を挙げ、具体的な数値や事実を添える
- 設問イへの橋渡しとして、最終段落で次の論点に着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、中堅企業の基幹システム刷新プロジェクトにおいて、プロジェクトマネージャを務めた。このプロジェクトは、老朽化したオンプレミス型基幹システムをクラウドベースのSaaS型ERPシステムへ移行するものであり、事業継続性の確保と業務効率化を主要な目的とした。プロジェクト期間は18ヶ月、予算は3億円であった。 本プロジェクトのステークホルダ構成は多岐にわたった。発注側の経営層として、情報システム部門担当役員、業務部門担当役員がおり、事業戦略と投資対効果に関心を持っていた。業務部門は、経理、販売、購買、生産管理の各部門長と実務担当者で構成され、現行業務の維持と新システムでの利便性向上を強く求めていた。利用部門は全従業員であり、システム変更への抵抗感や操作習熟度が懸念された。開発ベンダーは、ERPパッケージ提供元とSIベンダーの2社体制で、それぞれがパッケージ機能とカスタマイズ開発、インテグレーションを担当した。関連プロジェクトとして、並行して進められていたデータ連携基盤構築プロジェクトがあり、連携仕様の調整が不可欠であった。これらのステークホルダは、それぞれ異なる立場、関心事、専門知識、意思決定権限を持ち、特に業務部門間の利害調整と、ベンダー間の責任範囲の明確化がプロジェクト成功の鍵となると認識していた。
採点の観点
【A評価相当】 - 対象事業／プロジェクトの概要（規模／自身の立場）が具体的に記述されている - 背景・前提が複数の論点から立体的に分析されている - 設問イ・ウへの伏線として論点の構造化が為されている 【B評価相当】 - 概要は記載されているが規模感や立場が曖昧 - 背景の記述が単発的で構造化が弱い 【C評価相当（要改善）】 - どの組織でも当てはまる一般論 - 背景・前提が当該事業／プロジェクトに紐付いていない
設問イ
0 / 800〜1600 字設問アで述べたステークホルダ構成を踏まえて、あなたが立案したコミュニケーション計画の内容と、計画上で重視した点を、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 「重視した点」は2〜3点に絞り、それぞれを独立した節として論述する
- 各重視点には『なぜそう判断したか』『代替案を取らなかった理由』を添える
- 設問アとの整合を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／顧客数／市場規模）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、ステークホルダごとに伝える情報、頻度、方法と意思決定期限を整理し、合意形成、期待値調整、リスクの早期発見を目的とするコミュニケーション計画を立案した。 まず、「誰に」対しては、ステークホルダ分析の結果に基づき、経営層、業務部門長、業務実務担当者、開発ベンダー（ERP提供元、SIベンダー）、関連プロジェクトマネージャの5つのグループに分類した。各グループの関心事、影響度、意思決定権限をマトリクスで整理し、情報提供の粒度と頻度を決定した。 「何を」伝えるかについては、各グループのニーズに合わせて情報コンテンツを細分化した。経営層には、月次進捗報告会でプロジェクト全体の進捗（スケジュール、コスト、品質）、主要課題と対応策、経営判断を要する事項（例：追加投資の必要性）を簡潔に報告した。業務部門長には、週次定例会で各部門の業務要件定義進捗、課題、他部門との調整事項を共有し、部門間の利害調整を促した。業務実務担当者には、部門別ワークショップや操作説明会を通じて、新システムの操作方法、変更点、メリットなどを具体的に伝えた。開発ベンダーには、日次スクラムミーティング（SIベンダー）と週次定例会（両ベンダー）で、要件定義の詳細、設計進捗、テスト結果、課題、インターフェース仕様などを共有し、密な連携を図った。関連プロジェクトマネージャとは、隔週で連携会議を設定し、データ連携仕様のすり合わせや影響範囲の確認を行った。 伝達方法は、経営層への月次対面報告と緊急速報、業務部門長への週次会議、実務担当者への集合研修とeラーニングとした。ベンダーとはWeb会議と課題管理ツールを併用し、口頭の合意も担当者・期限とともに記録した。 計画上で特に重視した点は3つある。第一に、業務部門間の利害調整プロセスである。現行業務の維持を求める声と、新システム導入による業務変革の必要性の間で意見が対立することが予想されたため、業務部門長会議を定期的に開催し、各部門の要求事項をオープンに議論する場を設けた。ここで、各部門の要求事項を「Must」「Want」「Nice to have」で優先順位付けし、合意形成を促した。この過程で、特に経理部門と販売部門の間で、売上計上タイミングに関する要件の相違が顕在化する困難に直面した。私は、両部門の担当者と個別にヒアリングを行い、現行業務フローと新システムでの実現可能性を詳細に分析した上で、第三者的な視点から双方のメリット・デメリットを提示した。最終的には、新システムの標準機能に合わせた業務フロー変更を提案し、経営層の判断を仰ぐことで合意形成に至った。 第二に、ベンダー間の責任範囲の明確化と連携強化である。ERP提供元とSIベンダーの責任分界点が不明確になると、問題発生時の責任のなすりつけ合いが発生し、プロジェクトの遅延リスクが高まる。そこで、契約段階で明確なSLAと責任分界点を定めた上で、週次定例会では両ベンダーのPMを同席させ、課題やリスクを共有し、協力して解決策を検討する体制を構築した。これにより、インターフェース開発における仕様齟齬の発生を早期に発見し、手戻り工数を約20%削減できた。 第三に、情報セキュリティに関するコミュニケーションである。個人情報保護法やISO/IEC 27001（情報セキュリティマネジメントシステム）の要求事項を満たすため、全ステークホルダに対し、情報取り扱いの重要性、データ移行時の注意点、新システムでのセキュリティ機能について、定期的な説明会と啓発活動を実施した。特に、利用部門向けには、セキュリティポリシーの変更点やパスワード管理の徹底など、具体的な行動を促すための情報を分かりやすく提供した。
採点の観点
【A評価相当】 - 戦略／設計／計画／監査手続の内容が具体的に記述されている - 設問アの背景と論理的に対応している - 「重視した点」が3つ程度、それぞれに具体的判断と理由が明示されている - 数値（金額／期間／規模）が適切に織り込まれている 【B評価相当】 - 戦略／設計／計画は記述されているが、提供価値が一般論にとどまる - 重視点が単に列挙されているだけで判断理由が弱い - 設問アとの連携が弱く、戦略が独立して語られている 【C評価相当（要改善）】 - 標語の繰り返しで具体性に欠ける - 自身の役割が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べたコミュニケーション計画について、プロジェクト遂行中の運用上の工夫、関係者との合意形成、及び評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 経営層／関係者への説明と合意形成を、それぞれ独立段落で論じる
- 反対意見や困難の具体例を必ず1つ以上盛り込み、それへの対応を描く
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（期間／工数／合意までのステップ数）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
運用では、会議議事録、決定事項、課題とリスクを管理ツールで更新し、役割に応じたアクセス権を設けて共有した。匿名の意見箱と定期アンケートを併用し、会議で発言しにくい業務担当者の要望も拾った。要望への回答期限と担当者を記録し、採否の理由を返すことで、提出した意見が放置される不信感を防いだ。 関係者との合意形成においては、特に困難を伴う場面が複数あった。その一つが、新システム導入に伴う業務プロセスの変更である。一部の業務部門からは、現行業務の慣習を維持したいという強い抵抗があった。私は、業務部門長会議の場で、新システム導入による全体最適化のメリットと、将来的な競争力向上への貢献を具体的な数値（例：データ入力工数25%削減、月次決算早期化3営業日）を示しながら説明し、理解を求めた。また、業務改革の専門家を招き、客観的な視点から業務フローの再設計を支援してもらうことで、関係者の納得感を得る努力をした。この結果、当初予定よりも1ヶ月遅れたものの、主要な業務プロセス変更について関係者全員の合意を得ることができた。 もう一つの困難は、開発ベンダー間の連携不足による進捗遅延リスクであった。特に、ERPパッケージの標準機能とSIベンダーによるカスタマイズ開発部分のインターフェース仕様調整に時間を要し、テスト工程への影響が懸念された。私は、週次定例会とは別に、両ベンダーの技術責任者による「インターフェース調整会議」を緊急で設定し、具体的な仕様書を基に徹底的に議論させた。この会議には私も同席し、必要に応じて意思決定を促すことで、懸案事項を2週間で全て解消し、テスト工程への影響を最小限に抑えることができた。この対応により、テスト工程の遅延は当初懸念された1ヶ月から1週間に短縮され、最終的なプロジェクト完了時期への影響を回避できた。 コミュニケーション計画の評価としては、プロジェクト完了後のステークホルダ満足度調査を実施した。その結果、コミュニケーションの透明性、タイムリーな情報提供、課題解決への迅速な対応について、平均で4.2点（5点満点中）と高い評価を得ることができた。特に、経営層からは「プロジェクトの状況が常に把握でき、適切な意思決定ができた」とのコメントを頂いた。また、業務部門からは「システム導入後の問い合わせ件数が、類似プロジェクトと比較して約30%少なかった」という定量的な成果も確認できた。これは、事前の十分な情報提供と研修が奏功した結果と考える。 今後は、議事録の要約を支援するツールを検証する。ただし、決定事項と担当者・期限は会議主催者が原記録と照合して承認する。ステークホルダの満足度だけでなく、判断待ち日数や認識齟齬による手戻りも定期測定し、報告頻度を調整したい。
採点の観点
【A評価相当】 - 関係者への説明・合意形成の両方を具体的に記述 - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - 反対意見・困難への対応プロセスが具体的に描かれている - 自身の関与と判断が明確 【B評価相当】 - 説明や合意形成は記述されているが、困難の描写が弱い - 評価のみで改善点が形式的、または逆 【C評価相当（要改善）】 - 「説明した」「合意を得た」と結果のみで過程が不明 - 改善点が当たり障りのない一般論