令和7年度 春期 プロジェクトマネージャ 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
システム開発プロジェクトにおける品質マネジメントの計画と実行について
設問ア
0 / 800 字あなたが携わったシステム開発プロジェクトの概要と、品質マネジメントを計画する上で考慮した特徴について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行で対象（業種／規模／自身の役割）を提示し、文脈を即座に把握できる構成にする
- 背景は3要素以上を挙げ、具体的な数値や事実を添える
- 設問イへの橋渡しとして、最終段落で次の論点に着地させる
- 「私は〜の立場で」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私は、大規模な基幹システムのリプレイスプロジェクトにおいて、プロジェクトマネージャとして品質マネジメントの計画と実行を主導した。このシステムは、複数の部門が利用し、年間数十万件のトランザクションを処理するものであり、停止が許されない高い可用性と正確性が求められた。主な機能は、顧客情報管理、受発注管理、在庫管理、会計連携であり、特に顧客情報については個人情報保護法の遵守が必須であった。 品質マネジメントを計画する上で考慮した特徴は以下の通りである。第一に、システムの複雑性が非常に高い点である。既存システムは20年以上の歴史を持ち、多数のカスタマイズが施されており、新システムへの移行においてはデータ移行の正確性と網羅性が最大の課題であった。第二に、利用部門が多岐にわたり、それぞれの業務プロセスや品質に対する要求が異なる点である。特に、営業部門は迅速な情報更新を、経理部門は会計処理の正確性を重視しており、これらの多様な要求を統合的に満たす必要があった。第三に、開発の一部を外部のベンダーに委託しており、内部開発チームと外部委託先との連携における品質確保が重要であった。第四に、将来的な機能拡張や法改正への対応を見据え、保守性の高いシステム構築が求められた。これらの特徴を踏まえ、網羅的かつ実効性のある品質マネジメント計画の策定が不可欠であると認識した。
採点の観点
【A評価相当】 - 対象事業／プロジェクトの概要（規模／自身の立場）が具体的に記述されている - 背景・前提が複数の論点から立体的に分析されている - 設問イ・ウへの伏線として論点の構造化が為されている 【B評価相当】 - 概要は記載されているが規模感や立場が曖昧 - 背景の記述が単発的で構造化が弱い 【C評価相当（要改善）】 - どの組織でも当てはまる一般論 - 背景・前提が当該事業／プロジェクトに紐付いていない
設問イ
0 / 800〜1600 字設問アで述べた特徴を踏まえて、あなたが計画した品質マネジメントの内容と、計画上で重視した点を、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 「重視した点」は2〜3点に絞り、それぞれを独立した節として論述する
- 各重視点には『なぜそう判断したか』『代替案を取らなかった理由』を添える
- 設問アとの整合を1対1で対応させ、論理的整合性を見せる
- 数値（投資額／期間／顧客数／市場規模）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問アで述べた特徴を踏まえ、私は以下の品質マネジメント計画を策定し、特に計画上で以下の点を重視した。 まず、品質目標の設定においては、システムの可用性99.99%、データ移行成功率100%、主要機能の応答時間2秒以内、セキュリティ脆弱性検出ゼロを具体的な数値目標として掲げた。特に個人情報保護法に準拠するため、データセキュリティとプライバシー保護に関する目標を明確にした。 次に、品質メトリクスとして、要件定義フェーズでは要件網羅率、変更要求数、設計フェーズでは設計レビュー指摘件数、設計書カバレッジ、開発フェーズではコードレビュー指摘件数、単体テストカバレッジ、結合テスト・総合テストフェーズでは不具合検出数、不具合密度、重要度別不具合件数、テストケース実行消化率を設定した。これらのメトリクスは、PMBOKガイドの品質マネジメントの考え方を参考に、各フェーズで測定可能かつ具体的な指標となるよう選定した。 レビューやテストの段階設計においては、V字モデルを基本とし、各フェーズで品質ゲートを設けた。要件定義段階では、利用部門との合同レビューを複数回実施し、要件の網羅性と整合性を確認した。設計段階では、内部開発チームと外部委託先が共同で設計レビューを実施し、設計原則と標準への準拠を確認した。特に、インターフェース設計については、ISO/IEC 27001のセキュリティ要件を考慮し、外部委託先との間で厳格なレビュープロセスを確立した。開発段階では、静的解析ツールとピアレビューを導入し、早期にコード品質を確保した。テスト段階では、単体テスト、結合テスト、システムテスト、そして利用部門による受け入れテスト（UAT）を計画した。UATでは、実際の業務シナリオに基づいたテストケースを作成し、利用部門が主体となって実施することで、業務要件との乖離がないかを確認した。 計画上で特に重視した点は、以下の三点である。第一に、品質課題の早期発見と是正プロセスの確立である。各フェーズで品質ゲートを設け、メトリクスが閾値を下回る場合は、次フェーズへの移行を一時停止し、原因分析と是正処置を徹底する仕組みを導入した。これにより、後工程での手戻りを最小限に抑えることを目指した。 第二に、外部委託先との品質連携強化である。外部委託先には、当社の品質基準とメトリクスを明確に提示し、定期的な品質進捗報告を義務付けた。また、共通の課題管理システムを導入し、不具合情報や変更要求をリアルタイムで共有することで、認識齟齬の発生を防いだ。困難だった点として、当初、外部委託先との間で品質基準の解釈に差異が生じ、特にテストカバレッジの定義で意見の相違があった。これに対し、私は両社の担当者を集め、IPAが公開している「ソフトウェア開発における品質保証ガイドライン」を参照しながら、具体的な測定方法と目標値を合意形成し、共通の理解を醸成した。 第三に、品質と工程・コストの両立である。品質向上策はコスト増に直結するため、費用対効果を常に意識した。例えば、自動テストツールの導入は初期投資が必要だが、リグレッションテストの工数削減効果が大きく、長期的にはコスト削減に寄与すると判断した。また、生成AIの活用については、テストケース生成支援やドキュメントレビュー支援への適用可能性を検討し、まずは一部機能でPoCを実施する計画とした。これにより、品質向上と開発効率化を両立させることを目指した。もう一つの困難は、利用部門からの追加要件が頻繁に発生し、品質保証期間が圧迫されそうになったことである。私は、変更管理プロセスを厳格に適用し、追加要件が品質目標やスケジュールに与える影響を明確に提示した上で、優先順位付けと、場合によっては次フェーズでの対応を提案することで、品質保証活動の計画通り実行を確保した。
採点の観点
【A評価相当】 - 戦略／設計／計画／監査手続の内容が具体的に記述されている - 設問アの背景と論理的に対応している - 「重視した点」が3つ程度、それぞれに具体的判断と理由が明示されている - 数値（金額／期間／規模）が適切に織り込まれている 【B評価相当】 - 戦略／設計／計画は記述されているが、提供価値が一般論にとどまる - 重視点が単に列挙されているだけで判断理由が弱い - 設問アとの連携が弱く、戦略が独立して語られている 【C評価相当（要改善）】 - 標語の繰り返しで具体性に欠ける - 自身の役割が見えず、評論的記述に終始
設問ウ
0 / 600〜1200 字設問イで述べた品質マネジメントについて、実行段階での工夫、関係者との合意形成、及び評価と今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 経営層／関係者への説明と合意形成を、それぞれ独立段落で論じる
- 反対意見や困難の具体例を必ず1つ以上盛り込み、それへの対応を描く
- 評価点と改善点を明確に分け、改善点には今後への具体的アクションを添える
- 数値（期間／工数／合意までのステップ数）を散りばめて当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
設問イで述べた品質マネジメント計画の実行段階では、以下の工夫を行い、関係者との合意形成に努めた。また、その評価と今後の改善点について述べる。 実行段階での工夫として、まず、品質メトリクスの定期的な可視化と共有を徹底した。週次で品質状況レポートを作成し、プロジェクト全体会議で進捗と課題を共有した。特に、不具合検出数や不具合密度については、傾向分析を行い、品質改善活動に繋げた。これにより、プロジェクトメンバー全員が品質状況を共通認識として持ち、品質に対する意識を高めることができた。 関係者との合意形成においては、特に利用部門との連携を強化した。UATの際には、利用部門のキーパーソンを早期から巻き込み、テスト計画の策定段階から意見を反映させた。これにより、利用部門は自分たちの手で品質を確認するという当事者意識を持つことができ、テスト実施への協力体制を円滑に構築できた。また、外部委託先とは、月次の合同品質会議を設け、進捗報告だけでなく、品質課題やリスクについてもオープンに議論する場を設けた。これにより、相互理解が深まり、問題発生時の迅速な連携が可能となった。 品質マネジメントの評価としては、プロジェクト完了後、目標達成度を定量的に評価した。結果として、システムの可用性は目標の99.99%を上回る99.995%を達成し、データ移行成功率は100%を維持した。また、本番稼働後3ヶ月間の重要度A（業務停止レベル）の不具合発生件数はゼロであり、目標を達成した。これにより、ユーザーからの信頼獲得に大きく貢献できた。さらに、プロジェクト全体での手戻り工数は、類似プロジェクトと比較して約20%削減され、品質マネジメント活動がコスト削減にも寄与したことが確認できた。 今後の改善点としては、第一に、生成AIの本格的な導入を検討する。今回のプロジェクトではPoCに留まったが、テストケース生成や要件定義書レビューにおける生成AIの活用は、品質向上と効率化の両面で大きな可能性を秘めていると実感した。今後は、より具体的な適用範囲と導入効果を検証し、標準的な品質マネジメントプロセスに組み込むことを目指す。 第二に、組織全体の品質文化の更なる醸成である。今回のプロジェクトを通じて、品質意識の向上は見られたものの、一部メンバーには品質活動が開発工数を圧迫するという認識が残っていた。今後は、品質活動の費用対効果をより明確に示し、品質が最終的な生産性向上に繋がるという意識を組織全体に浸透させるための教育プログラムやナレッジ共有の仕組みを強化する必要がある。例えば、ITILのサービス品質管理の考え方を取り入れ、開発段階だけでなく運用段階まで含めた品質保証の視点を強化していく計画である。これにより、継続的な品質改善サイクルを確立し、組織全体の品質マネジメント能力を向上させていきたい。
採点の観点
【A評価相当】 - 関係者への説明・合意形成の両方を具体的に記述 - 「評価」と「改善点」が両方明示され、改善点には次への学びがある - 反対意見・困難への対応プロセスが具体的に描かれている - 自身の関与と判断が明確 【B評価相当】 - 説明や合意形成は記述されているが、困難の描写が弱い - 評価のみで改善点が形式的、または逆 【C評価相当（要改善）】 - 「説明した」「合意を得た」と結果のみで過程が不明 - 改善点が当たり障りのない一般論