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点以下の評価項目があるベンダーは選定しない。発注先候補の選定評価結果をaに示す。

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

【開発スケジュールの作成】

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

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

Z社の過去のプロジェクトでは、所要日数のうち18%の日数をアクティビティごとに安全余裕（以下、バッファという）として設定していた。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に示す。

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

【アクティビティの進捗遅延発生時の対応】

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

（ⅰ） 40日目の進捗会議

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

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

（ⅱ） 70日目の進捗会議

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

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

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