AP過去問 令和7年度春期 午後 問9 プロジェクトマネジメント
AP 過去問題 午後に戻る。
AP過去問_令和7年度春期_午後_問8_情報システム開発の同じ回の前の問題へ移動。
AP過去問_令和7年度春期_午後_問10_サービスマネジメントの同じ回の次の問題へ移動。
AP過去問_令和6年度秋期_午後_問9_プロジェクトマネジメントの前の回の同じカテゴリの問題へ移動。
令和7年度春期 午後 問9 プロジェクトマネジメント(AIプロンプト向け)
■問9 CCPM(Critical Chain Project Management)を用いたプロジェクトのスケジュール管理に関する次の記述を読んで、設問に答えよ。
Z社は、小売業を営む中堅企業である。社内で10年以上利用してきた販売管理システムの老朽化対策として、販売管理の新システムを構築することになった。
〔新システム発注先の選定〕
現行の販売管理システム(以下、現行システムという)は、Z社システム部がZ社内の稼働システム全般の維持管理を委託しているJ社によって開発された。現行システムは、利用部門の業務要求を広く受け入れたことで冗長なシステムになり、費用が膨れてしまった。そこで、Z社システム部は、新システムの構築は現行システムの機能保証にこだわらず、費用を抑える方針とした。
この方針の下で検討を進めた結果、新システムとして、販売管理系のSaaSの標準機能を導入(以下、SaaS導入という)し、業務をSaaSの標準機能に極力合わせ、どうしても合わせられない機能に限りZ社の独自の業務要求を追加(以下、SaaSアドオンという)することにした。一方で、本稼働後の新システムの維持管理をJ 社に委託する予定で、J社には新システムの構築時に、SaaSと連携させる必要がある現行システムの周辺にある関連システム(以下、現行関連システムという)を改修してもらうことに同意を得ている。なお、新システムの構築期間中は、現行システムの機能変更を最小限にとどめることにした。
Z社システム部のX課長は、販売管理系の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>
<table border="0" width="100%" style="border-collapse: collapse;border-style: solid">
<tr>
<td align="center" rowspan="2" style="border: 2px solid; width: 5em;">評価項目</td>
<td align="center" rowspan="2" style="border: 2px solid; width: 5em;">評価項目の重み</td>
<td align="center" colspan="4" style="border: 2px solid;">評価点数</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">K社</td>
<td align="center" style="border: 2px solid;">L社</td>
<td align="center" style="border: 2px solid;">M社</td>
<td align="center" style="border: 2px solid;">N社</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">費用</td>
<td align="center" style="border: 2px solid;">2.0</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">3</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">3</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">要求充足度</td>
<td align="center" style="border: 2px solid;">1.5</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">3</td>
<td align="center" style="border: 2px solid;">5</td>
<td align="center" style="border: 2px solid;">3</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">保守性</td>
<td align="center" style="border: 2px solid;">1.0</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">3</td>
<td align="center" style="border: 2px solid;">5</td>
<td align="center" style="border: 2px solid;">4</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">会社実績</td>
<td align="center" style="border: 2px solid;">1.0</td>
<td align="center" style="border: 2px solid;">3</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">2</td>
<td align="center" style="border: 2px solid;">5</td>
</tr>
<tr>
<td align="center" style="border: 2px solid;">提案内容</td>
<td align="center" style="border: 2px solid;">1.0</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">4</td>
<td align="center" style="border: 2px solid;">5</td>
</tr>
</table>
</div>
</div>
<div>注記 評価点数 1: 著しく不足、2: 不足、3: 普通、4: ほぼ十分、5: 十分</div>
再評価の結果、X課長は、今回の選定基準に従って[ a ]社(以下、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日目であり、最遅開始日は[ b ]日目である。
Z社の過去のプロジェクトでは、所要日数のうち10%の日数をアクティビティごとに安全余裕(以下、バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下、開発担当者という)は、バッファを含んだ所要日数で作業スケジュールを作成し、作業の実施でバッファを不必要に消費する傾向にあった。これが原因で、開発スケジュール全体が遅延したことが度々あった。
このような状況を改善し、バッファを含む完了予定日までにプロジェクトを完了させるために、X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して、スケジュールを管理するようY君に指示した。
・アローダイアグラムの①アクティビティごとに設られたバッファを削除してクリティカルチェーンを設定する。
・クリティカルチェーンのアクティビティから削除したバッファを合計して[ c ]バッファを設定する。クリティカルチェーンのアクティビティの進捗が遅延した場合はこのバッファを使い、これ以降のアクティビティのスケジュールを、遅延した日数分だけ後ろにずらす。
・クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように、クリティカルチェーンにつながるアクティビティの直後に[ d ]バッファを設定する。
SaaS提供会社のSaaSアドオンはローコード開発が特徴で、数日間のオンライン研修を受講すればローコード開発の技術を習得できるということであった。J社は、本稼働後の新システムの維持管理を見据え、現行システムの維持管理要員のうち数名に研修を受講させた。そこで良い感触をつかんだJ社から、❝弊社がSaaSアドオンの設及び開発を担当すれば、御社の外部委託費用を抑えることがでる❞という提案があった。X課長は、元々J 社の現行システムの維持管理要員に委託する予定であった[E]、[F]に加え、SaaS提供会社に委託する予定であった[C]、[D]もJ社に委託することにし、J社と新たに準委任契約を締結することに決めた。これによって、J社内で[C]~[F]の要員シフトの調整が可能になった。
さらにJ社から、[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までとポイントCから[ d ]バッファとして、ポイントBまで
[アクティビティ]内容=[C2]SaaSアドオン設計②、主担当=J社J2チーム: ポイントAから26~50日の枠の後ろの方のポイントCまでとポイントCから[ d ]バッファとして、ポイント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 ]バッファとして、ポイントDまで
[アクティビティ]内容=[G]システムテスト、主担当=Z社: ポイントDから76~100日の枠の後ろの方のポイントHまでとポイントHから[ c ]バッファとして、101日以降の枠のポイントIまで
注記1 経過日数の数字は[A]の開始日を1日目とした作業日を表す。
注記2 J3チームの要員は、[F]の作業終了後に現行システムの維持管理対応に戻る予定である。
図2 開発スケジュール ここまで
X課長は、要件定義に参加するZ社の利用部門との間で、費用、及びバッファを含む完了予定日を守ることを念頭においた要件定義の進め方を合意し、図2のとおり作業を開始した。
〔アクティビティの進捗遅延発生時の対応〕
X課長は、週次(作業日ベースで5日ごと)で進捗会議を開催した。進捗会議において、次のとおりアクティビティの進捗が遅延していると報告された。これらのアクティビティ以外は、順調に進捗していた。X課長は、これら2件の遅延報告に対してそれぞれ対策を指示した。
(i) 40日目の進捗会議
遅延報告: 前日時点で[C1]の進捗が3日ほど遅れている。
対策: 4日の遅延で[C1]が終了する見通しとなったので、その4日分は[ d ]バッファを使って作業を続けること。
(ii) 70日目の進捗会議
遅延報告: SaaSアドオン開発のスキルが必要とされる作業において、予期しない技術上の問題が発生したことによって作業量が増大したので、[D2]の進捗が遅延している。最大で12日の遅延となるおそれがあり、②その場合、プロジェクトの完了がバッファを含む完了予定日よりも遅れることが懸念される。なお、[D2]の作業手順に問題は見られず、中間成果物の品質は担保されていた。また、並行作業している[D1]は、遅延していないが余裕はない状況である。
対策: これ以上[D2]の遅延を拡大させないように、J2チームの要員を発生した問題の解決作業に専念させ、それ以外の作業を実施するために③早急にリソース視点の対策をとること。
(ii)の対策によって、[D2]の遅延は最小限に抑えられた。[D2]の終了後の[G]は順調に実施され、バッファを含む完了予定日より前にプロジェクトが完了した。
設問1 〔新システム発注先の選定〕について答えよ。
(1) Z社が新システム構築の発注先の選定評価に加重総和法を用いた狙いを25字以内で具体的に答えよ。
(2) 本文中の[ a ]に入れる適切な社名を英字1字で答えよ。
設問2 〔開発スケジュールの作成〕について答えよ。
(1) 本文中の[ b ]に入れる適切な数字を答えよ。
(2) 本文中の下線①について、X課長はこの対策によって個々の開発担当者の作業にどのような効果が期待できると考えたのか。20字以内で答えよ。
(3) 本文中及び図2中の[ c ]、[ d ]に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア キャパシティ
イ 合流
ウ 資源
エ プロジェクト
設問3 〔アクティビティの進捗遅延発生時の対応〕について答えよ。
(1) 本文中の下線②について、対策せずに最大日数の遅延になった場合、プロジェクトの完了はバッファを含む完了予定日に対して何日遅れるか。数字で答えよ。
(2) 本文中の下線③について、対策の内容を25字以内で具体的に答えよ。
令和7年度春期 午後 問9 プロジェクトマネジメント(問題原文)
■問9 CCPM(Critical Chain Project Management)を用いたプロジェクトのスケジュール管理に関する次の記述を読んで、設問に答えよ。
Z社は、小売業を営む中堅企業である。社内で10年以上利用してきた販売管理システムの老朽化対策として、販売管理の新システムを構築することになった。
〔新システム発注先の選定〕
現行の販売管理システム(以下、現行システムという)は、Z社システム部がZ社内の稼働システム全般の維持管理を委託しているJ社によって開発された。現行システムは、利用部門の業務要求を広く受け入れたことで冗長なシステムになり、費用が膨れてしまった。そこで、Z社システム部は、新システムの構築は現行システムの機能保証にこだわらず、費用を抑える方針とした。
この方針の下で検討を進めた結果、新システムとして、販売管理系のSaaSの標準機能を導入(以下、SaaS導入という)し、業務をSaaSの標準機能に極力合わせ、どうしても合わせられない機能に限りZ社の独自の業務要求を追加(以下、SaaSアドオンという)することにした。一方で、本稼働後の新システムの維持管理をJ 社に委託する予定で、J社には新システムの構築時に、SaaSと連携させる必要がある現行システムの周辺にある関連システム(以下、現行関連システムという)を改修してもらうことに同意を得ている。なお、新システムの構築期間中は、現行システムの機能変更を最小限にとどめることにした。
Z社システム部のX課長は、販売管理系のSaaSを提供する複数のベンダーにRFI及びRFPを段階的に提出し、それぞれの回答内容を基に発注先候補をK社、L社、M社及びN社に絞った。この4社に提案のプレゼンテーションを依頼し、多基準意思決定分析の加重総和法を用いて発注先候補を評価し、選定することにした。発注先候補を多面的に評価するため、評価項目及び主な評価内容を次のとおりとした。
費用: 初期費(SaaS導入費、SaaSアドオン費など)、運用費(SaaSライセンス費、SaaS環境利用料など)。ここで、現行関連システムの改修費及び運用費は、どのSaaSを採用しても同額とする。
要求充足度: Z社の業務要求の充足度。
保守性: SaaSアドオンの維持管理支援ツールの充実度。
会社実績: Z社との取引実績、会社規模・信頼度、業界での導入実績。
提案内容:プレゼンテーション、RFP記載事項以外の有効な提案の有無。
各評価項目を5点満点で評価する。評価項目にZ社が重要視する度合いに応じて重みを設定し、評価点数に重みを乗じて再評価し、再評価値を算出する。選定基準として、再評価値の合計が最も大きいベンダーを選定する。ただし、一つでも評価点数が2点以下の評価項目があるベンダーは選定しない。発注先候補の選定評価結果を表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 |
再評価の結果、X課長は、今回の選定基準に従って a 社(以下、SaaS提供会社という)を選定し、Z社内で承認された。
〔開発スケジュールの作成〕
新システムの構築プロジェクトのPMに任命されたX課長は、部下のY君に開発スケジュールの作成を指示した。Y君は、図1に示すアローダイアグラムを作成した。
図1 Y君が作成したアローダイアグラム ここまで
ここで、アクティビティ[A]の開始日を1日目とする。各アクティビティの日数は1日単位で数え、依存関係にある先行アクティビティが終了した翌日に後続アクティビティを速やかに開始する。図1中の[B]に関して、最早開始日は[A]を開始してから31日目であり、最遅開始日は b 日目である。
Z社の過去のプロジェクトでは、所要日数のうち10%の日数をアクティビティごとに安全余裕(以下、バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下、開発担当者という)は、バッファを含んだ所要日数で作業スケジュールを作成し、作業の実施でバッファを不必要に消費する傾向にあった。これが原因で、開発スケジュール全体が遅延したことが度々あった。
このような状況を改善し、バッファを含む完了予定日までにプロジェクトを完了させるために、X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して、スケジュールを管理するようY君に指示した。
・アローダイアグラムの①アクティビティごとに設られたバッファを削除してクリティカルチェーンを設定する。
・クリティカルチェーンのアクティビティから削除したバッファを合計して c バッファを設定する。クリティカルチェーンのアクティビティの進捗が遅延した場合はこのバッファを使い、これ以降のアクティビティのスケジュールを、遅延した日数分だけ後ろにずらす。
・クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように、クリティカルチェーンにつながるアクティビティの直後に d バッファを設定する。
SaaS提供会社のSaaSアドオンはローコード開発が特徴で、数日間のオンライン研修を受講すればローコード開発の技術を習得できるということであった。J社は、本稼働後の新システムの維持管理を見据え、現行システムの維持管理要員のうち数名に研修を受講させた。そこで良い感触をつかんだJ社から、❝弊社がSaaSアドオンの設及び開発を担当すれば、御社の外部委託費用を抑えることがでる❞という提案があった。X課長は、元々J 社の現行システムの維持管理要員に委託する予定であった[E]、[F]に加え、SaaS提供会社に委託する予定であった[C]、[D]もJ社に委託することにし、J社と新たに準委任契約を締結することに決めた。これによって、J社内で[C]~[F]の要員シフトの調整が可能になった。
さらにJ社から、[C]を独立に実施可能な[C1]と[C2]に分割して並行作業し、[D]も同様に[D1]と[D2]に分割して並行作業し、加えて当初予定の2倍の要員を投入して各アクティビティの所要日数を半分にするという提案があった。J社は、J1チーム([C1]及び[D1]を担当)、J2チーム([C2]及び[D2]を担当)、及びJ3チーム([E]及び[F]を担当)の3チーム体制を作り、各バッファの期間を含めて十分な要員を確保することを約束した。これらを反映した開発スケジュールを図2に示す。
図2 開発スケジュール
X課長は、要件定義に参加するZ社の利用部門との間で、費用、及びバッファを含む完了予定日を守ることを念頭においた要件定義の進め方を合意し、図2のとおり作業を開始した。
〔アクティビティの進捗遅延発生時の対応〕
X課長は、週次(作業日ベースで5日ごと)で進捗会議を開催した。進捗会議において、次のとおりアクティビティの進捗が遅延していると報告された。これらのアクティビティ以外は、順調に進捗していた。X課長は、これら2件の遅延報告に対してそれぞれ対策を指示した。
(i) 40日目の進捗会議
遅延報告: 前日時点で[C1]の進捗が3日ほど遅れている。
対策: 4日の遅延で[C1]が終了する見通しとなったので、その4日分は d バッファを使って作業を続けること。
(ii) 70日目の進捗会議
遅延報告: SaaSアドオン開発のスキルが必要とされる作業において、予期しない技術上の問題が発生したことによって作業量が増大したので、[D2]の進捗が遅延している。最大で12日の遅延となるおそれがあり、②その場合、プロジェクトの完了がバッファを含む完了予定日よりも遅れることが懸念される。なお、[D2]の作業手順に問題は見られず、中間成果物の品質は担保されていた。また、並行作業している[D1]は、遅延していないが余裕はない状況である。
対策: これ以上[D2]の遅延を拡大させないように、J2チームの要員を発生した問題の解決作業に専念させ、それ以外の作業を実施するために③早急にリソース視点の対策をとること。
(ii)の対策によって、[D2]の遅延は最小限に抑えられた。[D2]の終了後の[G]は順調に実施され、バッファを含む完了予定日より前にプロジェクトが完了した。
設問1 〔新システム発注先の選定〕について答えよ。
(1) Z社が新システム構築の発注先の選定評価に加重総和法を用いた狙いを25字以内で具体的に答えよ。
(2) 本文中の a に入れる適切な社名を英字1字で答えよ。
設問2 〔開発スケジュールの作成〕について答えよ。
(1) 本文中の b に入れる適切な数字を答えよ。
(2) 本文中の下線①について、X課長はこの対策によって個々の開発担当者の作業にどのような効果が期待できると考えたのか。20字以内で答えよ。
(3) 本文中及び図2中の c 、d に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア キャパシティ
イ 合流
ウ 資源
エ プロジェクト
設問3 〔アクティビティの進捗遅延発生時の対応〕について答えよ。
(1) 本文中の下線②について、対策せずに最大日数の遅延になった場合、プロジェクトの完了はバッファを含む完了予定日に対して何日遅れるか。数字で答えよ。
(2) 本文中の下線③について、対策の内容を25字以内で具体的に答えよ。
回答・解説
設問1
(1)
加重総和法を用いた狙いを25字以内で答える問題で、問題文に発注先候補を多面的に評価するためとあるので、これが答えになりますが、16文字とかなり短くなってしまいます。もう少し具体的に説明する必要がありそうです。多面的に評価もしていますが、重みもつけているので、重みが付けられている部分にも触れる必要があります。
したがって、
1 5 10 11 20
費用と充足度を重視し 多角的な評価で最適な
候補を選ぶ(25文字)
21 25
が答えです。
(2)
表1の加重評価マトリクスを読み取りできる能力を問う問題です。各会社の評価値の算出は以下のような計算によって得られます。
- K社: (4×2.0)+(4×1.5)+(4×1.0)+(3×1.0)+(4×1.0)=8+6+4+3+4=25
- L社: (3×2.0)+(3×1.5)+(3×1.0)+(4×1.0)+(4×1.0)=6+4.5+3+4+4=21.5
- M社: (4×2.0)+(5×1.5)+(5×1.0)+(2×1.0)+(4×1.0)=8+7.5+5+2+4=26.5
- N社: (3×2.0)+(3×1.5)+(4×1.0)+(5×1.0)+(5×1.0)=6+4.5+4+5+5=24.5
問題文にはただし、一つでも評価点数が2点以下の評価項目があるベンダーは選定しない。とあるので一般的な加重評価マトリクスを読み取り能力と問題文を理解する能力の両方が問われています。M社は最高得点になっていますが一つでも2.0があると採用されないということなので次に評価値が高いK社が採用されます。次のN社とは0.5ポイント差なので、きっちり間違えずに計算できるかというのも問われていると思われます。
したがって
a:K
が答えです。
設問2
(1)
[B]に関して、最早開始日は[A]を開始してから31日目であり、最遅開始日は b 日目である。のbの穴埋めです。
[C]が40日の作業で、[B]は30日の作業で合流します。つまり[B]には10日の猶予があるので、[A]が終わってすぐの31日目が再早開始日で41日目には開始しないと[A]が開始してから、70日目の[C]との合流に間に合わなくなります。
したがって
b:41
が答えです。
(2)
アクティビティごとに設けられたバッファを削除する対策によって個々の開発担当者の作業にどのような効果が期待できるのか20文字以内で答える問題です。
問題文に元々のアローダイアグラムのバッファの問題について作業の実施でバッファを不必要に消費する傾向にあったとあります。これをなくす効果が答えです。
したがって、
1 5 10 11 20
バッファを不必要に消 費する傾向を除く効果(20文字)
が答えです。
(3)
cについて、クリティカルチェーンのアクティビティから削除したバッファを合計して c バッファを設定する。の穴埋めで、図2では、全ての作業後に付けられるバッファとして描かれています。選択式なので、それぞれの選択肢について考えれば答えれる問題になっています。
アとウのキャパシティバッファと資源バッファのような表現は存在していませんので、残るイとエの2択問題です。
- プロジェクトバッファ:
- 意味: クリティカルチェーンの終わりに設けられるバッファです。
- 目的: クリティカルチェーン全体で発生する可能性のある遅延を吸収し、プロジェクト全体の完了遅延を防ぐことを目的とします。個々のタスクから削除された安全余裕(バッファ)の合計よりも一般的に短く設定されます。
- 合流バッファ(フィーダバッファ):
- 意味: クリティカルチェーンに合流する非クリティカルなパスの終わりに設けられるバッファです。
- 目的: 非クリティカルなパスにおける遅延が、クリティカルチェーンに影響を与え、プロジェクト全体の遅延を引き起こすのを防ぐことを目的とします。
したがって
c:エ プロジェクト
が答えです。
dについて、クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように、クリティカルチェーンにつながるアクティビティの直後に d バッファを設定する。
残りのイを当てはめるだけです。
したがって
d:イ 合流
が答えです。
問題文は長いですが、この問9を選択するのが一番楽に得点を稼げそうなイメージはありますね。
設問3
(1)
70日目の進捗会議のSaaSアドオン開発のスキルが必要とされる作業において、予期しない技術上の問題が発生したことによって作業量が増大したので、[D2]の進捗が遅延している。最大で12日の遅延となるおそれがあり、その場合、プロジェクトの完了がバッファを含む完了予定日よりも遅れることが懸念される。の対策をせずに最大日数の遅延になった場合、プロジェクトの完了はバッファを含む完了予定日に対して何日遅れるか。という問題です。
ここではじめて長い問題文を振り返る必要のある問題が掲示されました。図2では具体的な経過日数を明示していません。これは今までの問題文の内容から具体的な日数を自分で設定しなおせと言っています。まずガントチャートの経過日数を明確にしましょう。
[A]は30日の作業なので、ガントチャートでも30日で間違いないでしょう。31日目から[B]の作業が60日目の30日間として、設定されます。[C1][C2]は当初40日間の作業だったのですが、2チームによる並行作業で半分に縮小されています。20日間です。31日目から50日目までの20日間です。そうすると[C1][C2]は[B]が終わって合流しますが、10日間の合流バッファができることになります。まさに図2とおりの形ではあります。具体的な日数が無いだけです。そして、[E]は10日間の作業で31日目から40日目まで作業となりと[F]は20日間の作業で41日目から60日目までの作業となります。[D1][D2]は当初60日間の作業だったのですが、2チームによる並行作業で半分に縮小されています。30日間です。なので、61日目から90日目の30日間です。そして[G]は91日目から110日目の20日間です。そしてプロジェクトバッファが何日か?なのですが、問題文に所要日数のうち10%の日数をアクティビティごとに安全余裕(以下、バッファという)として設定していた。とあります。これが今回のプロジェクトでも適用されたとは書いていませんが、適用されたとしたらもともとの作業でバッファは[A]:30日の10%で3日、[B]:30日の10%で3日、[C]:40日の10%で4日、[D]:60日の10%で6日、[E]:10日の10%で6日、[F]:20日の10%で2日、[G]:20日の10%で2日です。何も書いてないので、問題の捉え方によっては半分になった部分がバッファを生み出しているとしたら、[C]が20日、[D]が15日のプロジェクトバッファを生み出したと解釈することもできます。その場合はガントチャートではBで30日の作業なので、[C]が生み出すバッファは10日で[D]が生み出すバッファはそのまま15日で合計25日のプロジェクトバッファができたと考えることもできますが、過去のバッファ適用日数を今回も適用していたとしたら、問題文にあるクリティカルチェーンのアクティビティから削除したバッファを合計して プロジェクト バッファを設定する。とありますから、クリティカルチェーン上にある作業は[A]→[B]→[D]→[G]なので3日+3日+6日+2日で14日のプロジェクトバッファがあったと考えることができます。すると0日の遅れで作業を終えることができます。これはあまり問題作成者の意図にそぐわないですが、バッファによって問題の12日遅れの状態から何日遅れになるかという答えに対してバッファの捉え方次第で12日より大きくなることを意味しています。この場合は0日になります。そして、問題作成者の意図どおりなのだとしたら、半分に短縮できた作業の10%をプロジェクトバッファとして再計算するならD1の部分のプロジェクトバッファが30日の10%で、3日となります。したがって3日+3日+3日+2日で11日のプロジェクトバッファだった考えることができます。すると12日遅れの状態だとバッファではとりもどせないので、1日遅れが答えになります。
したがって
0
または
1
が答えです。
問題にプロジェクトバッファの考え方を難しく表現しようとしたせいで、結局はっきり書かれてないので0日でも正解とせざるを得ない問題が作られてしまいました。はっきりいえば答えが1つ問題のはずのところに答えが2個以上あるのは問題不成立で全員に得点をあげなければなりませんが、この問題を選ばなかった人には得点を調整して変換することができませんので、一問まるまる不成立で全員の一番得点の低い午後の問題に対して20点を与えなければならないでしょう。この問題を選んだ人は、この問題を20点として扱うべきすが他の選ばなかった人の方が有利になるので、この問題の設問3(1)を全員正解としてみなした上に、この問題を含めて一番低い問題を20点として扱うべきでしょう。それくらいのことをやらかしていると思います。
(2)
J2チームの要員を発生した問題の解決作業に専念させ、それ以外の作業を実施するために早急にリソース視点の対策をとること。という対策について25字以内で答える問題です。
これ以上D2の作業が遅れないように、J社J3のチームの人員リソースをJ2チームに割り振ってサポートすることが望ましいと考えることができます。J3チームはすでに作業が完了していて手が空いてると考えることができます。違う仕事でJ3チームは現行の冗長な販売管理システムの維持管理対応に戻るだけなので、比較的手が空いていると考えることができます。なぜ維持管理対応に戻るだけの仕事あまりな計画になっているのかが謎なくらいです。なのでJ社のどこからか人員をひっぱってくる感じの答えなら全部正解だと思います。でも問題作者はJ3チームから人員を集めることを想定しているように感じます。
したがって、
1 5 10 11 20
J社の人員から構造改 革によりD2作業人員
を緊急招集(25文字)
21 25
が答えです。まぁ本来は
1 5 10 11 20
J社のJ3チームから [D2]作業に人員を
招集する(24文字)
21 25
を答えにしたかったんでしょうね。
この問題の設問3は論理が破綻しているような設問になっています。やばいです。それ以外は簡単な問題でした。最初に選ぶと時間が奪われる危険な問題でもあったと思います。不公平な問題ですね。
AP過去問_令和7年度春期_午後_問8_情報システム開発の同じ回の前の問題へ移動。
AP過去問_令和7年度春期_午後_問10_サービスマネジメントの同じ回の次の問題へ移動。
AP過去問_令和6年度秋期_午後_問9_プロジェクトマネジメントの前の回の同じカテゴリの問題へ移動。
AP 過去問題 午後に戻る。