解説

• 設問文の条件に従い、発注先の選定評価について確認すると〔新システム発注先の選定〕には、以下の記述があります。
  • Z社システム部は，新システムの構築は現行システムの機能保証にこだわらず，費用を抑える方針とした
  • 業務をSaaSの標準機能に極力合わせ，どうしても合わせられない機能に限りZ社独自の業務要求を追加することにした
  Z社は新システムについて、まず方針として費用を抑えることを明確にしています。同時に、SaaSの標準機能に業務を極力合わせるとしつつ、どうしても合わない部分はアドオンで補うとしており、業務要求への適合度（要求充足度）を外せない評価軸として据えていることが読み取れます。その他の評価軸について特に言及がありません。
  
  Z社が採用した加重総和法は、後述の計算例のように、評価項目ごとの点数に評価項目の重みを乗じた値の総和を求め、その多寡によって対象を定量的に評価する方法です。上記2項目の重要度を評価に反映するため、（単純総和方式ではなく）各項目に重みを設定できる加重総和法を採用したと言えます。
  
  ∴費用及び要求充足度を重要視するため
  
  
• 〔aについて〕
  本文中に記載されている選定ルールは次の2点です。
  • 評価点数に重みを乗じて再評価し，再評価値を算出する。…再評価値の合計が最も大きいベンダーを選定する
  • 一つでも評価点数が2点以下の評価項目があるベンダーは選定しない
  まず除外条件の確認です。表1より M社は"会社実績が2点"のため、この時点で選定対象外です。K、L、Nはいずれも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
  再評価値が最大となるのはK社（25.0）です。したがって、空欄aには「K」が入ります。
  
  ∴a＝K

解説

• 〔bについて〕
  まず、最早開始日・最遅開始日について確認します。

  最早開始日

  先行作業の完了を前提とし、その作業を最も早く開始できる日

  最遅開始日

  プロジェクト完了を遅らせないことを前提とし、その作業を最も遅く開始できる日

  本プロジェクトのクリティカルパスは「A→C→D→G」です。[B]は[D]の先行作業とされているので、プロジェクトを予定日数で完了するには、[D]が開始するまで（＝A→Cが完了するまで）には[B]が完了している必要があります。
  
  A→Cの所要日数は「A:30日＋C:40日＝70日目」なので、[D]も70日目までに完了していれば、プロジェクトの完了には影響を与えません。[B]の所要日数は30日ですから、完了日から逆算して「70－30＋1＝41日目」が[B]の最遅開始日となります。したがって、空欄bには「41」が入ります。
  
  ∴b＝41
  
  
• X課長が下線①のようなバッファ管理を行うこととしたのには、次のような状況を踏まえてのことです。
  • Z社システム部及び外部委託先の開発担当者(以下，開発担当者という)は，バッファを含んだ所要日数で作業スケジュールを作成し，作業の実施でバッファを不必要に消費する傾向にあった。これが原因で，開発スケジュール全体が遅延したことが度々あった
  『仕事は完成のために与えられた時間まで膨張する』というパーキンソンの法則で知られるように、作業時間に余裕があるとダラつきや追加作業で容易に使い切られてしまうことが世の常です。Z社でも同じ傾向にあることが読み取れます。
  
  クリティカルチェーン法（CCPM）では、アクティビティごと個別バッファを設けず、全体でバッファで管理することで、この心理的・行動的メカニズムを断ち、担当者が本来の所要時間に集中して仕上げることを促します。以上を踏まえると、X課長はクリティカルチェーン法を採用することで「バッファが不必要に消費されなくなること」を期待したと考えられます。
  
  ∴バッファを消費しなくなる
  
  なお、設問に「個々の開発担当者の作業に」と条件付けがあるため、答える際は「開発スケジュール全体の遅延回避」や「全体の開発効率向上」ではなく、担当者一人ひとりの作業レベルでの効果を示す必要があります。
  
  
• クリティカルチェーン法では、個々の作業にバッファ（安全余裕時間）をもたせず、バッファをプロジェクト全体で管理します。バッファには複数の種類があります。

  プロジェクトバッファ

  プロジェクトのクリティカルパスを守るために、クリティカルチェーンの最後に配置される

  合流バッファ

  クリティカルパス上にない作業の遅れが、クリティカルパス上のタスクに影響を与えることを防ぐために、作業の合流地点に配置される

  資源（リソース）バッファ

  同じリソースを使う作業が複数あるとき、後続タスクが遅れるのを防止するために配置される

  
  〔cについて〕
  クリティカルチェーンのアクティビティが遅延した場合に使用されるバッファであること、図2中でクリティカルチェーンの最後に配置されていることから「プロジェクト」バッファが答えとなります。
  
  〔dについて〕
  クリティカルチェーンにないアクティビティが遅延した場合に使用されるバッファであること、図2中で作業の合流地点に配置されていることから「合流」バッファが答えとなります。
  
  ∴c＝エ：プロジェクト
  　d＝イ：合流

解説

• まず、図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日
  クリティカルチェーン上の[D2]が12日遅れた場合、プロジェクトバッファの11日では吸収できず、完了予定日より「12－11＝1日」の遅れが生じる結果となります。
  
  ∴1（日）
  
• 70日目の遅延は[D2]（J2チーム担当）で発生しており、遅延の原因は作業量の増加です。リソース視点で考えると、人員の不足を補うための追加投入が必要な場面です。
  
  本文中では「J社内で[C]～[F]間の要員シフトの調整が可能」とあるので、対策として、J1チームまたはJ3チームから、問題の解決作業以外の作業を行う要員を融通してもらうことが考えられます。他のチームの状況を整理します。
  • （進捗報告より）並行作業している[D1]]（J1チーム担当）は，遅延していないが余裕はない状況である
  • （図2注記2より）J3チームの要員は、[F]の作業終了後に現行システムの維持管理対応に戻る予定である
  この状況を踏まえると、J1チームから要員を出してもらうのは難しいです。一方で、本文中に「これらのアクティビティ以外は，順調に進捗していた」とあるため、J3チームは70日目時点では作業を終えて維持管理対応に入っていると考えられます。J社は「各バッファ期間を含め十分な要員を確保」しているため、J3チームの予定を変更し、[D2]へ要員を再配分することが可能と考えられます。これがリソース視点の対応方法となります。
  
  ∴J3チームだった要員を[D2]に投入する