応用情報技術者過去問題 令和7年春期 午後問9
⇄問題文と設問を画面2分割で開く⇱問題PDF問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社に提案のプレゼンテーションを依頼し,多基準意思決定分析の加重総和法を用いて発注先候補を評価し,選定することにした。発注先候補を多面的に評価するため,評価項目及び主な評価内容を次のとおりとした。
再評価の結果,X課長は,今回の選定基準に従ってa社(以下,SaaS提供会社という)を選定し,Z社内で承認された。
〔開発スケジュールの作成〕
新システムの構築プロジェクトのPMに任命されたX課長は,部下のY君に開発スケジュールの作成を指示した。Y君は,図1に示すアローダイアグラムを作成した。
ここで,アクティビティ[A]の開始日を1日目とする。各アクティビティの日数は1日単位で数え,依存関係にある先行アクティビティが終了した翌日に後続アクティビティを速やかに開始する。図1中の[B]に関して,最早開始日は[A]を開始してから31日目であり,最遅開始日はb日目である。
Z社の過去のプロジェクトでは,所要日数のうち10%の日数をアクティビティごとに安全余裕(以下,バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下,開発担当者という)は,バッファを含んだ所要日数で作業スケジュールを作成し,作業の実施でバッファを不必要に消費する傾向にあった。これが原因で,開発スケジュール全体が遅延したことが度々あった。
このような状況を改善し,バッファを含む完了予定日までにプロジェクトを完了させるために,X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して,スケジュールを管理するようY君に指示した。
さらにJ社から,[C]を独立に実施可能な[C1]と[C2]に分割して並行作業し,[D]も同様に[D1]と[D2]に分割して並行作業し,加えて当初予定の2倍の要員を投入して各アクティビティの所要日数を半分にするという提案があった。J社は,J1チーム([C1]及び[D1]を担当),J2チーム([C2]及び[D2]を担当),及びJ3チーム([E]及び[F]を担当)の3チーム体制を作り,各バッファの期間を含めて十分な要員を確保することを約束した。これらを反映した開発スケジュールを図2に示す。
X課長は,要件定義に参加するZ社の利用部門との間で,費用,及びバッファを含む完了予定日を守ることを念頭においた要件定義の進め方を合意し,図2のとおり作業を開始した。
〔アクティビティの進接遅延発生時の対応〕
X課長は,週次(作業日ベースで5日ごと)で進捗会議を開催した。進捗会議において,次のとおりアクティビティの進捗が遅延していると報告された。これらのアクティビティ以外は,順調に進捗していた。X課長は,これら2件の遅延報告に対してそれぞれ対策を指示した。
(ⅰ) 40日目の進捗会議
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記載事項以外の有効な提案の有無。

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

Z社の過去のプロジェクトでは,所要日数のうち10%の日数をアクティビティごとに安全余裕(以下,バッファという)として設定していた。Z社システム部及び外部委託先の開発担当者(以下,開発担当者という)は,バッファを含んだ所要日数で作業スケジュールを作成し,作業の実施でバッファを不必要に消費する傾向にあった。これが原因で,開発スケジュール全体が遅延したことが度々あった。
このような状況を改善し,バッファを含む完了予定日までにプロジェクトを完了させるために,X課長は次のとおりCCPMの考えを取り入れたガントチャート形式の開発スケジュールを作成して,スケジュールを管理するようY君に指示した。
- アローダイアグラムの①アクティビティごとに設けられたバッファを削除してクリティカルチェーンを設定する。
- クリティカルチェーンのアクティビティから削除したバッファを合計してcバッファを設定する。クリティカルチェーンのアクティビティの進捗が遅延した場合はこのバッファを使い,これ以降のアクティビティのスケジュールを,遅延した日数分だけ後ろにずらす。
- クリティカルチェーンにないアクティビティが遅延してもスケジュール全体に影響しないように,クリティカルチェーンにつながるアクティビティの直後にdバッファを設定する。
さらにJ社から,[C]を独立に実施可能な[C1]と[C2]に分割して並行作業し,[D]も同様に[D1]と[D2]に分割して並行作業し,加えて当初予定の2倍の要員を投入して各アクティビティの所要日数を半分にするという提案があった。J社は,J1チーム([C1]及び[D1]を担当),J2チーム([C2]及び[D2]を担当),及びJ3チーム([E]及び[F]を担当)の3チーム体制を作り,各バッファの期間を含めて十分な要員を確保することを約束した。これらを反映した開発スケジュールを図2に示す。

〔アクティビティの進接遅延発生時の対応〕
X課長は,週次(作業日ベースで5日ごと)で進捗会議を開催した。進捗会議において,次のとおりアクティビティの進捗が遅延していると報告された。これらのアクティビティ以外は,順調に進捗していた。X課長は,これら2件の遅延報告に対してそれぞれ対策を指示した。
(ⅰ) 40日目の進捗会議
- 遅延報告:
- 前日時点で[C1]の進捗が3日ほど遅れている。
- 対策:
- 4日の遅延で[C1]が終了する見通しとなったので,その4日分はdバッファを使って作業を続けること。
- 遅延報告:
- SaaSアドオン開発のスキルが必要とされる作業において,予期しない技術上の問題が発生したことによって作業量が増大したので,[D2]の進捗が遅延している。最大で12日の遅延となるおそれがあり,②その場合,プロジェクトの完了がバッファを含む完了予定目よりも遅れることが懸念される。なお,[D2]の作業手順に問題は見られず,中間成果物の品質は担保されていた。また,並行作業している[D1]は,遅延していないが余裕はない状況である。
- 対策:
- これ以上[D2]の遅延を拡大させないように,J2チームの要員を発生した問題の解決作業に専念させ,それ以外の作業を実施するために③早急にリソース視点の対策をとること。
設問1
〔新システム発注先の選定〕について答えよ。
- Z社が新システム構築の発注先の選定評価に加重総和法を用いた狙いを25字以内で具体的に答えよ。
- 本文中のaに入れる適切な社名を英字1字で答えよ。
解答入力欄
- a:
解答例・解答の要点
- 費用及び要求充足度を重要視するため (17文字)
- a:K (1文字)
解説
- 設問文の条件に従い、発注先の選定評価について確認すると〔新システム発注先の選定〕には、以下の記述があります。
- Z社システム部は,新システムの構築は現行システムの機能保証にこだわらず,費用を抑える方針とした
- 業務をSaaSの標準機能に極力合わせ,どうしても合わせられない機能に限りZ社独自の業務要求を追加することにした
Z社が採用した加重総和法は、後述の計算例のように、評価項目ごとの点数に評価項目の重みを乗じた値の総和を求め、その多寡によって対象を定量的に評価する方法です。上記2項目の重要度を評価に反映するため、(単純総和方式ではなく)各項目に重みを設定できる加重総和法を採用したと言えます。
∴費用及び要求充足度を重要視するため - 〔aについて〕
本文中に記載されている選定ルールは次の2点です。- 評価点数に重みを乗じて再評価し,再評価値を算出する。…再評価値の合計が最も大きいベンダーを選定する
- 一つでも評価点数が2点以下の評価項目があるベンダーは選定しない
3社について、項目ごとの評価点数に評価項目の重みを乗じた値の総和を計算します。結果は以下のとおりです。- K社:4×2 + 4×1.5 + 4×1 + 3×1 + 4×1 = 25.0
- L社:3×2 + 3×1.5 + 3×1 + 4×1 + 4×1 = 21.5
- N社:3×2 + 3×1.5 + 4×1 + 5×1 + 5×1 = 24.5
∴a=K
設問2
〔開発スケジュールの作成〕について答えよ。
- 本文中のbに入れる適切な数字を答えよ。
- 本文中の下線①について,X課長はこの対策によって個々の開発担当者の作業にどのような効果が期待できると考えたのか。20字以内で答えよ。
- 本文中及び図2中のc,dに入れる適切な字句を解答群の中から選び,記号で答えよ。
c,d に関する解答群
- キャパシティ
- 合流
- 資源
- プロジェクト
解答入力欄
- b:
- c:
- d:
解答例・解答の要点
- b:41
- バッファを消費しなくなる (12文字)
- c:エ
- d:イ
解説
- 〔bについて〕
まず、最早開始日・最遅開始日について確認します。- 最早開始日
- 先行作業の完了を前提とし、その作業を最も早く開始できる日
- 最遅開始日
- プロジェクト完了を遅らせないことを前提とし、その作業を最も遅く開始できる日
A→Cの所要日数は「A:30日+C:40日=70日目」なので、[D]も70日目までに完了していれば、プロジェクトの完了には影響を与えません。[B]の所要日数は30日ですから、完了日から逆算して「70-30+1=41日目」が[B]の最遅開始日となります。したがって、空欄bには「41」が入ります。
∴b=41 - X課長が下線①のようなバッファ管理を行うこととしたのには、次のような状況を踏まえてのことです。
- Z社システム部及び外部委託先の開発担当者(以下,開発担当者という)は,バッファを含んだ所要日数で作業スケジュールを作成し,作業の実施でバッファを不必要に消費する傾向にあった。これが原因で,開発スケジュール全体が遅延したことが度々あった
クリティカルチェーン法(CCPM)では、アクティビティごと個別バッファを設けず、全体でバッファで管理することで、この心理的・行動的メカニズムを断ち、担当者が本来の所要時間に集中して仕上げることを促します。以上を踏まえると、X課長はクリティカルチェーン法を採用することで「バッファが不必要に消費されなくなること」を期待したと考えられます。
∴バッファを消費しなくなる
なお、設問に「個々の開発担当者の作業に」と条件付けがあるため、答える際は「開発スケジュール全体の遅延回避」や「全体の開発効率向上」ではなく、担当者一人ひとりの作業レベルでの効果を示す必要があります。 - クリティカルチェーン法では、個々の作業にバッファ(安全余裕時間)をもたせず、バッファをプロジェクト全体で管理します。バッファには複数の種類があります。
- プロジェクトバッファ
- プロジェクトのクリティカルパスを守るために、クリティカルチェーンの最後に配置される
- 合流バッファ
- クリティカルパス上にない作業の遅れが、クリティカルパス上のタスクに影響を与えることを防ぐために、作業の合流地点に配置される
- 資源(リソース)バッファ
- 同じリソースを使う作業が複数あるとき、後続タスクが遅れるのを防止するために配置される
〔cについて〕
クリティカルチェーンのアクティビティが遅延した場合に使用されるバッファであること、図2中でクリティカルチェーンの最後に配置されていることから「プロジェクト」バッファが答えとなります。
〔dについて〕
クリティカルチェーンにないアクティビティが遅延した場合に使用されるバッファであること、図2中で作業の合流地点に配置されていることから「合流」バッファが答えとなります。
∴c=エ:プロジェクト
d=イ:合流
設問3
〔アクティビティの進捗遅延発生時の対応〕について答えよ。
解答入力欄
- 日
解答例・解答の要点
- 1
- J3チームだった要員を[D2]に投入する (20文字)
解説
- まず、図2のスケジュールにおけるプロジェクトバッファの日数を特定します。プロジェクトバッファは「クリティカルチェーンのアクティビティから削除したバッファの合計」と定義されています。
前述のとおり、図1のアローダイアグラムでは「A→C→D→G」がクリティカルパスでした。しかし、作業CとDが要員の追加投入(クラッシング)で分割されたことにより、図2のクリティカルチェーンは「A→B→D1/D2→G」であることが確認できます。
Z社では「所要日数のうち10%の日数をアクティビティごとに安全余裕(以下,バッファという)として設定していた」とあるので、各作業のバッファはアローダイアグラムで示された所要日数のうち10%です。プロジェクトバッファは以下のように計算できます。- [A]:30日×0.1=3日
- [B]:30日×0.1=3日
- [D1]/[D2]:(60日÷2)×0.1=3日
※人員2倍で半分=30日 - [G]:20日×0.1=2日
- 合計:3+3+3+2=11日
∴1(日) - 70日目の遅延は[D2](J2チーム担当)で発生しており、遅延の原因は作業量の増加です。リソース視点で考えると、人員の不足を補うための追加投入が必要な場面です。
本文中では「J社内で[C]~[F]間の要員シフトの調整が可能」とあるので、対策として、J1チームまたはJ3チームから、問題の解決作業以外の作業を行う要員を融通してもらうことが考えられます。他のチームの状況を整理します。- (進捗報告より)並行作業している[D1]](J1チーム担当)は,遅延していないが余裕はない状況である
- (図2注記2より)J3チームの要員は、[F]の作業終了後に現行システムの維持管理対応に戻る予定である
∴J3チームだった要員を[D2]に投入する
