令和6年度 春期 プロジェクトマネージャ 午後問題
練習用オリジナル問題です
本ページの設問・題材・模範解答は、IPA 試験本番の出題傾向を模して作成した練習用オリジナル問題であり、 実際の試験で出題された問題ではありません。AI 採点機能の動作確認用としてご活用ください。 本番形式の学習には、実際の IPA 過去問（午前問題）をご利用ください。
⚠️ 練習用オリジナル問題です。本ページに掲載している午後問題は、IPA過去問の形式を模して作成した練習用オリジナル問題であり、実際の試験で出題された問題ではありません。
AI採点は目安です。本試験の採点とは異なる可能性があります。 採点結果は学習の参考程度にご利用ください。
システム開発プロジェクトにおける不確実性の高い要求への対応について
設問ア
0 / 800 字あなたが携わったシステム開発プロジェクトの概要と、そのプロジェクトにおいて不確実性が高いと判断した要求の内容、及びその不確実性の発生原因について、800字以内で述べよ。
構成のポイント（ヒント）
- 冒頭2-3行でプロジェクト概要（業界／規模／予算／期間／自身の立場）を提示し、文脈を即座に把握できる構成にする
- 不確実性の高い要求は具体例を1〜2つ挙げ、業務上の意思決定とどう絡むかを描写する
- 不確実性の発生原因を「技術」「外部環境」「組織」など複数軸で整理する
- 設問イへの橋渡しとして、最終段落で「これら不確実性に対しPMとして取った方針」へつながる伏線を張る
- 「私はSIer〜のPMとして」と主語を明示し、当事者性を担保する
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私が携わったのは、地方銀行F社における法人融資業務の刷新プロジェクトである。F社は預金量約2.4兆円、法人取引先約3,800社の中堅地方銀行であり、私はSIerY社のPMとして、開発期間18か月・予算約9.2億円・要員ピーク時45名（うちF社側10名）の体制で本プロジェクトを統括した。プロジェクトの目的は、紙ベースで運用されてきた融資稟議・与信判断業務を、ワークフロー＋AIスコアリングによる新システムで置き換えることであった。 本プロジェクトには2つの不確実性の高い要求が存在した。第1に、AIスコアリングモデルが提示する与信判断結果を、最終的に支店長や審査役にどの粒度で提示するかという要求である。これは、業務プロセスとUI双方に大きく関わるが、F社内に「AI推定の不確実性をどう人間が引き受けるか」の合意がプロジェクト開始時点で存在しなかった。第2に、金融庁から2025年度に予定されていた中小企業向け融資審査ガイドライン改定が、プロジェクト中に最終確定する見通しであり、改定内容によっては業務フローの再設計が必要となる可能性があった。 これら不確実性の発生原因は、技術的なものと外部環境的なものの2系統に整理できた。技術的には、AIモデルの精度評価指標（再現率／適合率／F1）と業務上の判断品質（誤承認による損失額／審査時間）の対応関係が事前検証データのみでは確定できないことに由来していた。外部環境的には、ガイドライン改定の最終条文が金融庁の意見公募手続きを経るため、プロジェクト中盤まで内容が変動する性質に由来していた。 私はこれら2つの不確実性を、プロジェクト計画に組み込むべき「リスク」ではなく、「前提として変動する要素」として明示的に扱う方針を取った。
採点の観点
【A評価相当】 - プロジェクト概要（業界／規模／自身の立場）が固有名詞レベルで具体的に記述 - 不確実性の高い要求が複数または1つであっても具体的な業務／技術領域に紐付いて描写 - 不確実性の発生原因が技術／外部環境／組織のいずれかの軸で整理されている - 設問イへの伏線として、PMが対処すべき論点が示唆されている 【B評価相当】 - プロジェクト概要は記述されているが規模感や立場が曖昧 - 不確実性が「要求が決まらない」程度の抽象的記述 - 発生原因の分析が単一視点のみで構造化が弱い 【C評価相当（要改善）】 - どの企業でも当てはまる一般論 - 不確実性の中身が見えず、PMとして対応すべき対象が不明瞭
設問イ
0 / 800〜1600 字設問アで述べた不確実性の高い要求に対して、あなたがPMとしてプロジェクト計画に組み込んだマネジメント上の工夫と、その工夫を選択した理由について、800字以上1,600字以内で具体的に述べよ。
構成のポイント（ヒント）
- 工夫の全体像を冒頭で要約し、読み手に骨格を先に提示する（パラグラフ・ライティング）
- 工夫は2〜3点に絞り、それぞれを独立した節として論述する
- 各工夫には「具体的な内容」「選択した理由」「代替案を取らなかった理由」を必ず添える
- 設問アの不確実性と各工夫を1対1で対応させ、論理的整合性を見せる
- 数値（金額／期間／件数／割合）を最低3箇所に織り込む
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私がPMとしてプロジェクト計画に組み込んだマネジメント上の工夫は、(1)スコープを段階リリース型に再構成、(2)契約形態の二層化、(3)変更管理プロセスへの「保留」概念の導入、の3点である。 第1の工夫は、開発スコープを4つのリリース単位に分割し、不確実性が低い領域を先に確定させる段階リリース型計画への再構成である。具体的には、稟議ワークフローの基盤機能（リリース1: 4か月）を先行確定し、その上に与信スコアリングのUI層（リリース2: 5か月）、AIスコアモデルとの連携層（リリース3: 5か月）、ガイドライン対応の業務ルール層（リリース4: 4か月）を順次積層する設計とした。これにより、後段リリースの仕様確定を先送りしつつ、前段の早期リリースでビジネス価値を継続的に提供できる構造とした。私がこの工夫を選択した理由は、F社経営層から「全機能を一括稼働させたい」という当初の要望が出ていたが、これに従うとプロジェクト後半で要求変更が発生した際の手戻りコストが期待値ベースで2.8億円に達すると試算され、段階リリース型への変更により手戻りコスト期待値を約8,000万円まで圧縮できる見通しが立ったためである。 第2の工夫は、調達契約をリリース単位で二層化し、不確実性に応じて契約形態を使い分けたことである。具体的には、リリース1・2は要求が明確化していたため請負契約（成果物責任）で発注し、リリース3・4は不確実性が高いため準委任契約＋月次精算（プロセス責任）に切り替えた。私がこの工夫を選択した理由は、不確実性の高い領域に請負契約を適用すると、見積バッファが過大化（試算で約25%増）するか、または変更要求の都度の契約変更が頻発して進行が阻害されるリスクが高かったためである。準委任契約とすることで、要求変動を許容する代わりに、月次の進捗・成果物レビューを契約上の義務として組み込み、F社側の確認義務を明確化した。これにより、F社側に「不確実な要求の確定責任」を契約として位置付け、PMとしてのコントロール手段を確保した。 第3の工夫は、変更管理プロセスに「保留」という新たな状態を導入したことである。一般的な変更管理プロセスは「承認」「却下」「差し戻し」の3状態だが、本プロジェクトでは追加で「保留（次回ガイドライン改定発行後に再評価）」を設けた。私がこの工夫を選択した理由は、ガイドライン改定の確定タイミングを待たないと判断不能な変更要求が、プロジェクト中盤で5件程度発生する見通しがあったためである。これらを「却下」とすると後で改定確定後に再起票が必要となり、「承認」とすると改定内容によっては実装後の手戻りが発生する。「保留」状態を導入することで、変更要求を凍結しつつトラッキング可能な状態に保ち、ガイドライン改定確定後にバッチで再評価する運用を可能とした。これは、変更管理を「決める」プロセスから「決められないことを決められないまま運用可能にする」プロセスへ拡張する設計判断であった。
採点の観点
【A評価相当】 - マネジメント上の工夫が2〜3個、それぞれ独立した節として論述されている - 各工夫について「具体的な内容」「選択した理由」が両方明示されている - 設問アで述べた不確実性と工夫が論理的に対応している - 数値（金額／期間／割合）が複数箇所に織り込まれている - 代替案を退けた理由が示されている 【B評価相当】 - 工夫は記述されているが、選択理由が一般論にとどまる - 設問アとの連携が弱く、独立した工夫の列挙になっている - 数値根拠が乏しい 【C評価相当（要改善）】 - 「アジャイル開発を採用した」など標語の繰り返しで具体性に欠ける - 工夫の判断主体が曖昧で評論的な記述 - 不確実性との対応関係が不明
設問ウ
0 / 600〜1200 字設問イで述べたマネジメント上の工夫について、プロジェクト実行中の評価と、その評価を踏まえた今後の改善点を、600字以上1,200字以内で具体的に述べよ。
構成のポイント（ヒント）
- 評価点と改善点を明確に分け、それぞれを独立段落で論じる
- 設問イで挙げた工夫に対応する形で評価を述べ、論理的整合性を保つ
- 改善点には根本原因の分析と、今後の具体的アクションを必ず添える
- 数値（％／件数／期間）を散りばめて当事者性を担保する
- 最終段落で本プロジェクトを通じた抽象化された学びを述べる
参考解答・採点観点を読む（採点不要）
編集者作成の解答例です。設問条件を満たす別の表現も認められます。
私が組み込んだマネジメント上の工夫について、プロジェクト実行中の評価と改善点を以下に述べる。 評価点としては、3つの工夫がいずれも当初の意図通りに機能した点が挙げられる。第1の段階リリース型計画では、リリース1・2を予定通り計画期間内に稼働させ、F社の融資稟議業務に先行的なビジネス価値を提供できた。リリース1稼働後の現場アンケートで「業務効率が改善した」との回答が83%を占め、後段リリースに対する組織的な信頼を獲得できた点は副次的成果であった。第2の契約形態二層化については、リリース3でAIスコアリングのモデル更新が3回発生したが、準委任契約のため契約変更を伴わず月次レビューでスコープ調整が完結し、結果として見積比+5%の増加で吸収できた。第3の「保留」状態を含む変更管理プロセスでは、ガイドライン改定発行までに7件の変更要求を保留し、改定発行後に5件を承認・2件を却下する形で一括処理できた。改定発行から承認までの平均所要時間は11営業日と想定通りであった。 一方、改善点としては2点を認識している。第1に、段階リリース型計画における「リリース間の依存関係」の事前抽出が不十分であった点である。リリース2のUI層と、リリース3のAIスコアモデル連携層との間で、画面遷移制御に関する技術的依存関係が、リリース3の設計レビュー時点で初めて顕在化し、リリース2のUI仕様を一部後方互換修正する必要が生じた。これは、計画策定時点でリリース間IFを論理レベルでしか定義しておらず、物理レベル（DOM構造／状態管理粒度）まで踏み込めていなかったことに起因する。今後は、段階リリース型計画を採用する場合、リリース間IFを物理レベルまで含めて事前定義し、変更影響を局所化する仕組みを内蔵すべきである。 第2に、「保留」状態の運用において、保留中要求の関係者への可視性が不十分であった点である。F社の業務部門メンバーは、自部門が起票した変更要求が「保留」となった後、進捗が見えず不安を抱えるケースがあった。今後は、保留中要求についても月次の状態レビューを定例化し、保留理由・再評価予定・代替対応の有無を可視化する運用を組み込むべきである。これは、変更管理プロセスにおいて「決定すること」だけでなく「決定の遅延状態をマネジメントすること」もPMの責務に含まれるという、本プロジェクトを通じて得た重要な学びであった。
採点の観点
【A評価相当】 - 評価と改善点が両方明示され、改善点には具体的な今後のアクションが添えられている - 設問イの工夫それぞれに対して評価が紐付いている - 数値（％・件数・期間）が織り込まれている - 改善点が形式的でなく、根本原因まで踏み込んで分析されている - 学びが個別事例から再利用可能なレベルに抽象化されている 【B評価相当】 - 評価のみで改善点が形式的、または逆 - 設問イの工夫との対応が弱く、独立した感想記述に近い - 数値根拠が乏しい 【C評価相当（要改善）】 - 「うまくいった」「課題が残った」と結果のみで過程が不明 - 改善点が当たり障りのない一般論 - 自身の関与・判断が見えない評論的記述