「AP過去問令和7年度春期午後問9 プロジェクトマネジメント」の版間の差分

2025年5月14日 (水) 18:09時点における版

AP 過去問題午後に戻る。

AP過去問_令和7年度春期_午後_問8_情報システム開発の同じ回の前の問題へ移動。

AP過去問_令和7年度春期_午後_問10_サービスマネジメントの同じ回の次の問題へ移動。

AP過去問_令和6年度秋期_午後_問9_プロジェクトマネジメントの前の回の同じカテゴリの問題へ移動。

令和7年度春期午後問9 プロジェクトマネジメント(AIプロンプト向け)

■問9 CCPM(Critical Chain Project Management)を用いたプロジェクトのスケジュール管理に関する次の記述を読んで、設問に答えよ。

　Z社は、小売業を営む中堅企業である。社内で10年以上利用してきた販売管理システムの老朽化対策として、販売管理の新システムを構築することになった。

〔新システム発注先の選定〕

現行の販売管理システム(以下、現行システムという)は、Ｚ社システム部がＺ社内の稼働システム全般の維持管理を委託しているＪ社によって開発された。現行システムは、利用部門の業務要求を広く受け入れたことで冗長なシステムになり、費用が膨れてしまった。そこで、Ｚ社システム部は、新システムの構築は現行システムの機能保証にこだわらず、費用を抑える方針とした。

　この方針の下で検討を進めた結果、新システムとして、販売管理系のSaaSの標準機能を導入(以下、SaaS導入という)し、業務をSaaSの標準機能に極力合わせ、どうしても合わせられない機能に限りＺ社の独自の業務要求を追加(以下、SaaSアドオンという)することにした。一方で、本稼働後の新システムの維持管理をJ 社に委託する予定で、Ｊ社には新システムの構築時に、SaaSと連携させる必要がある現行システムの周辺にある関連システム(以下、現行関連システムという)を改修してもらうことに同意を得ている。なお、新システムの構築期間中は、現行システムの機能変更を最小限にとどめることにした。

　Ｚ社システム部のＸ課長は、販売管理系のSaaSを提供する複数のベンダーにRFI及びRFPを段階的に提出し、それぞれの回答内容を基に発注先候補をK社、L社、M社及びN社に絞った。この4社に提案のプレゼンテーションを依頼し、多基準意思決定分析の加重総和法を用いて発注先候補を評価し、選定することにした。発注先候補を多面的に評価するため、評価項目及び主な評価内容を次のとおりとした。

費用: 初期費(SaaS導入費、SaaSアドオン費など)、運用費(SaaSライセンス費、SaaS環境利用料など)。ここで、現行関連システムの改修費及び運用費は、どのSaaSを採用しても同額とする。

要求充足度: Z社の業務要求の充足度。

保守性: SaaSアドオンの維持管理支援ツールの充実度。

会社実績: Z社との取引実績、会社規模・信頼度、業界での導入実績。

提案内容:プレゼンテーション、RFP記載事項以外の有効な提案の有無。

　各評価項目を5点満点で評価する。評価項目にZ社が重要視する度合いに応じて重みを設定し、評価点数に重みを乗じて再評価し、再評価値を算出する。選定基準として、再評価値の合計が最も大きいベンダーを選定する。ただし、一つでも評価点数が2点以下の評価項目があるベンダーは選定しない。発注先候補の選定評価結果を表1に示す。

<div><div class="table-container"><div class="table-header"><span class="table-title">表1 発注先候補の選定評価結果</span><span class="table-unit"></span></div>

<tr>

<td align="center" rowspan="2" style="border: 2px solid; width: 5em;">評価項目の重み</td>

</tr>

<tr>

</tr>

<tr>

</tr>

<tr>

<td align="center" style="border: 2px solid;">要求充足度</td>

</tr>

<tr>

</tr>

<tr>

</tr>

<tr>

</tr>

</table>

</div>

<div>注記評価点数 1: 著しく不足、2: 不足、3: 普通、4: ほぼ十分、5: 十分</div>

　再評価の結果、X課長は、今回の選定基準に従って[ ａ ]社(以下、SaaS提供会社という)を選定し、Z社内で承認された。

〔開発スケジュールの作成〕

　新システムの構築プロジェクトのPMに任命されたX課長は、部下のY君に開発スケジュールの作成を指示した。Y君は、図1に示すアローダイアグラムを作成した。

　図1 Y君が作成したアローダイアグラムここから

　ノード1からノード2は[A]要件定義で30日。

　ノード2からノード3は[B]SaaS導入で30日。

　ノード2からノード4は[C]SaaSアドオン設計で40日。

　ノード2からノード5は[E]現行関連システム設計で10日。

　ノード3からノード4はダミーアクティビティ。

　ノード5からノード6は[F]現行関連システム改修で20日。

　ノード4からノード7は[D]SaaSアドオン開発で60日。

　ノード6からノード7はダミーアクティビティ。

　ノード7からノード8は[G]システムテストで20日。

　ダミーアクティビティで繋がっているところは所要時間は0日だが、それ以前の作業が終わっていなければいけない。

　図1 Y君が作成したアローダイアグラムここまで

　ここで、アクティビティ[A]の開始日を1日目とする。各アクティビティの日数は1日単位で数え、依存関係にある先行アクティビティが終了した翌日に後続アクティビティを速やかに開始する。図1中の[B]に関して、最早開始日は[A]を開始してから31日目であり、最遅開始日は[ ｂ ]日目である。

　Z社の過去のプロジェクトでは、所要日数のうち10％の日数をアクティビティごとに安全余裕(以下、バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下、開発担当者という)は、バッファを含んだ所要日数で作業スケジュールを作成し、作業の実施でバッファを不必要に消費する傾向にあった。これが原因で、開発スケジュール全体が遅延したことが度々あった。

　このような状況を改善し、バッファを含む完了予定日までにプロジェクトを完了させるために、X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して、スケジュールを管理するようY君に指示した。

・アローダイアグラムの①アクティビティごとに設られたバッファを削除してクリティカルチェーンを設定する。

・クリティカルチェーンのアクティビティから削除したバッファを合計して[ ｃ ]バッファを設定する。クリティカルチェーンのアクティビティの進捗が遅延した場合はこのバッファを使い、これ以降のアクティビティのスケジュールを、遅延した日数分だけ後ろにずらす。

・クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように、クリティカルチェーンにつながるアクティビティの直後に[ ｄ ]バッファを設定する。

　SaaS提供会社のSaaSアドオンはローコード開発が特徴で、数日間のオンライン研修を受講すればローコード開発の技術を習得できるということであった。Ｊ社は、本稼働後の新システムの維持管理を見据え、現行システムの維持管理要員のうち数名に研修を受講させた。そこで良い感触をつかんだＪ社から、❝弊社がSaaSアドオンの設及び開発を担当すれば、御社の外部委託費用を抑えることがでる❞という提案があった。Ｘ課長は、元々J 社の現行システムの維持管理要員に委託する予定であった[Ｅ]、[F]に加え、SaaS提供会社に委託する予定であった[C]、[D]もＪ社に委託することにし、Ｊ社と新たに準委任契約を締結することに決めた。これによって、Ｊ社内で[C]～[F]の要員シフトの調整が可能になった。

　さらにＪ社から、[C]を独立に実施可能な[C1]と[C2]に分割して並行作業し、[D]も同様に[D1]と[D2]に分割して並行作業し、加えて当初予定の2倍の要員を投入して各アクティビティの所要日数を半分にするという提案があった。J社は、J1チーム([C1]及び[D1]を担当)、J2チーム([C2]及び[D2]を担当)、及びJ3チーム([E]及び[F]を担当)の3チーム体制を作り、各バッファの期間を含めて十分な要員を確保することを約束した。これらを反映した開発スケジュールを図2に示す。

　図2 開発スケジュールここから

おおよその経過日数の枠として、1～25日の枠、26～50日の枠、51～75日の枠、76～100日の枠、101日以降の枠を定めている。

[アクティビティ]内容=[A]要件定義、主担当=Z社: 経過日数1～25日の枠を少し超えた26～50日の枠の前の方にあるポイントAまで

[アクティビティ]内容=[B]SaaS導入、主担当=SaaS提供会社: ポイントAから51日～75日の枠の前の方にあるポイントBまで

[アクティビティ]内容=[C1]SaaSアドオン設計①、主担当=J社J1チーム: ポイントAから26～50日の枠の後ろの方のポイントCまでとポイントＣから[ ｄ ]バッファとして、ポイントBまで

[アクティビティ]内容=[C2]SaaSアドオン設計②、主担当=J社J2チーム: ポイントAから26～50日の枠の後ろの方のポイントCまでとポイントＣから[ ｄ ]バッファとして、ポイントBまで

[アクティビティ]内容=[D1]SaaSアドオン設計①、主担当=J社J1チーム: ポイントBから76～100日の枠のやや前の方のポイントDまで

[アクティビティ]内容=[D2]SaaSアドオン設計②、主担当=J社J2チーム: ポイントBから76～100日の枠のやや前の方のポイントDまで

[アクティビティ]内容=[E]現行関連システム設計、主担当=J社J3チーム: ポイントAから26～50日の枠の中ほどのポイントFまで

[アクティビティ]内容=[F]現行関連システム改修、主担当=J社J3チーム: ポイントFから51～75日の枠の前の方のポイントGまでとポイントGから[ ｄ ]バッファとして、ポイントDまで

[アクティビティ]内容=[G]システムテスト、主担当=Z社: ポイントDから76～100日の枠の後ろの方のポイントHまでとポイントHから[ ｃ ]バッファとして、101日以降の枠のポイントIまで

注記1　経過日数の数字は[A]の開始日を1日目とした作業日を表す。

注記2　J3チームの要員は、[F]の作業終了後に現行システムの維持管理対応に戻る予定である。

　図2 開発スケジュールここまで

　X課長は、要件定義に参加するZ社の利用部門との間で、費用、及びバッファを含む完了予定日を守ることを念頭においた要件定義の進め方を合意し、図2のとおり作業を開始した。

〔アクティビティの進捗遅延発生時の対応〕

　X課長は、週次(作業日ベースで5日ごと)で進捗会議を開催した。進捗会議において、次のとおりアクティビティの進捗が遅延していると報告された。これらのアクティビティ以外は、順調に進捗していた。X課長は、これら2件の遅延報告に対してそれぞれ対策を指示した。

(i) 40日目の進捗会議

遅延報告: 前日時点で[C1]の進捗が3日ほど遅れている。

対策: 4日の遅延で[C1]が終了する見通しとなったので、その4日分は[ ｄ ]バッファを使って作業を続けること。

(ii) 70日目の進捗会議

遅延報告: SaaSアドオン開発のスキルが必要とされる作業において、予期しない技術上の問題が発生したことによって作業量が増大したので、[D2]の進捗が遅延している。最大で12日の遅延となるおそれがあり、②その場合、プロジェクトの完了がバッファを含む完了予定日よりも遅れることが懸念される。なお、[D2]の作業手順に問題は見られず、中間成果物の品質は担保されていた。また、並行作業している[D1]は、遅延していないが余裕はない状況である。

対策: これ以上[D2]の遅延を拡大させないように、J2チームの要員を発生した問題の解決作業に専念させ、それ以外の作業を実施するために③早急にリソース視点の対策をとること。

(ii)の対策によって、[D2]の遅延は最小限に抑えられた。[D2]の終了後の[G]は順調に実施され、バッファを含む完了予定日より前にプロジェクトが完了した。

設問1　〔新システム発注先の選定〕について答えよ。

(1)　Z社が新システム構築の発注先の選定評価に加重総和法を用いた狙いを25字以内で具体的に答えよ。

(2)　本文中の[ ａ ]に入れる適切な社名を英字1字で答えよ。

設問2　〔開発スケジュールの作成〕について答えよ。

(1)　本文中の[ ｂ ]に入れる適切な数字を答えよ。

(2)　本文中の下線①について、Ｘ課長はこの対策によって個々の開発担当者の作業にどのような効果が期待できると考えたのか。20字以内で答えよ。

(3)　本文中及び図2中の[ ｃ ]、[ ｄ ]に入れる適切な字句を解答群の中から選び、記号で答えよ。

解答群

ア　キャパシティ

イ　合流

ウ　資源

エ　プロジェクト

設問3　〔アクティビティの進捗遅延発生時の対応〕について答えよ。

(1)　本文中の下線②について、対策せずに最大日数の遅延になった場合、プロジェクトの完了はバッファを含む完了予定日に対して何日遅れるか。数字で答えよ。

(2)　本文中の下線③について、対策の内容を25字以内で具体的に答えよ。

令和7年度春期午後問9 プロジェクトマネジメント(問題原文)

■問9 CCPM(Critical Chain Project Management)を用いたプロジェクトのスケジュール管理に関する次の記述を読んで、設問に答えよ。

　Z社は、小売業を営む中堅企業である。社内で10年以上利用してきた販売管理システムの老朽化対策として、販売管理の新システムを構築することになった。

〔新システム発注先の選定〕

現行の販売管理システム(以下、現行システムという)は、Ｚ社システム部がＺ社内の稼働システム全般の維持管理を委託しているＪ社によって開発された。現行システムは、利用部門の業務要求を広く受け入れたことで冗長なシステムになり、費用が膨れてしまった。そこで、Ｚ社システム部は、新システムの構築は現行システムの機能保証にこだわらず、費用を抑える方針とした。

　この方針の下で検討を進めた結果、新システムとして、販売管理系のSaaSの標準機能を導入(以下、SaaS導入という)し、業務をSaaSの標準機能に極力合わせ、どうしても合わせられない機能に限りＺ社の独自の業務要求を追加(以下、SaaSアドオンという)することにした。一方で、本稼働後の新システムの維持管理をJ 社に委託する予定で、Ｊ社には新システムの構築時に、SaaSと連携させる必要がある現行システムの周辺にある関連システム(以下、現行関連システムという)を改修してもらうことに同意を得ている。なお、新システムの構築期間中は、現行システムの機能変更を最小限にとどめることにした。

　Ｚ社システム部のＸ課長は、販売管理系のSaaSを提供する複数のベンダーにRFI及びRFPを段階的に提出し、それぞれの回答内容を基に発注先候補をK社、L社、M社及びN社に絞った。この4社に提案のプレゼンテーションを依頼し、多基準意思決定分析の加重総和法を用いて発注先候補を評価し、選定することにした。発注先候補を多面的に評価するため、評価項目及び主な評価内容を次のとおりとした。

費用: 初期費(SaaS導入費、SaaSアドオン費など)、運用費(SaaSライセンス費、SaaS環境利用料など)。ここで、現行関連システムの改修費及び運用費は、どのSaaSを採用しても同額とする。

要求充足度: Z社の業務要求の充足度。

保守性: SaaSアドオンの維持管理支援ツールの充実度。

会社実績: Z社との取引実績、会社規模・信頼度、業界での導入実績。

提案内容:プレゼンテーション、RFP記載事項以外の有効な提案の有無。

　各評価項目を5点満点で評価する。評価項目にZ社が重要視する度合いに応じて重みを設定し、評価点数に重みを乗じて再評価し、再評価値を算出する。選定基準として、再評価値の合計が最も大きいベンダーを選定する。ただし、一つでも評価点数が2点以下の評価項目があるベンダーは選定しない。発注先候補の選定評価結果を表1に示す。

表1 発注先候補の選定評価結果

評価項目	評価項目の重み	評価点数
評価項目	評価項目の重み	K社	L社	M社	N社
費用	2.0	4	3	4	3
要求充足度	1.5	4	3	5	3
保守性	1.0	4	3	5	4
会社実績	1.0	3	4	2	5
提案内容	1.0	4	4	4	5

注記評価点数 1: 著しく不足、2: 不足、3: 普通、4: ほぼ十分、5: 十分

　再評価の結果、X課長は、今回の選定基準に従ってａ社(以下、SaaS提供会社という)を選定し、Z社内で承認された。

〔開発スケジュールの作成〕

　新システムの構築プロジェクトのPMに任命されたX課長は、部下のY君に開発スケジュールの作成を指示した。Y君は、図1に示すアローダイアグラムを作成した。

　図1 Y君が作成したアローダイアグラムここから

　ノード1からノード2は[A]要件定義で30日。

　ノード2からノード3は[B]SaaS導入で30日。

　ノード2からノード4は[C]SaaSアドオン設計で40日。

　ノード2からノード5は[E]現行関連システム設計で10日。

　ノード3からノード4はダミーアクティビティ。

　ノード5からノード6は[F]現行関連システム改修で20日。

　ノード4からノード7は[D]SaaSアドオン開発で60日。

　ノード6からノード7はダミーアクティビティ。

　ノード7からノード8は[G]システムテストで20日。

　ダミーアクティビティで繋がっているところは所要時間は0日だが、それ以前の作業が終わっていなければいけない。

　図1 Y君が作成したアローダイアグラムここまで

　ここで、アクティビティ[A]の開始日を1日目とする。各アクティビティの日数は1日単位で数え、依存関係にある先行アクティビティが終了した翌日に後続アクティビティを速やかに開始する。図1中の[B]に関して、最早開始日は[A]を開始してから31日目であり、最遅開始日はｂ日目である。

　Z社の過去のプロジェクトでは、所要日数のうち10％の日数をアクティビティごとに安全余裕(以下、バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下、開発担当者という)は、バッファを含んだ所要日数で作業スケジュールを作成し、作業の実施でバッファを不必要に消費する傾向にあった。これが原因で、開発スケジュール全体が遅延したことが度々あった。

　このような状況を改善し、バッファを含む完了予定日までにプロジェクトを完了させるために、X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して、スケジュールを管理するようY君に指示した。

・アローダイアグラムの①アクティビティごとに設られたバッファを削除してクリティカルチェーンを設定する。

・クリティカルチェーンのアクティビティから削除したバッファを合計してｃバッファを設定する。クリティカルチェーンのアクティビティの進捗が遅延した場合はこのバッファを使い、これ以降のアクティビティのスケジュールを、遅延した日数分だけ後ろにずらす。

・クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように、クリティカルチェーンにつながるアクティビティの直後にｄバッファを設定する。