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社に提案のプレゼンテーションを依頼し，多基準意思決定分析の加重総和法を用いて発注先候補を評価し，選定することにした。発注先候補を多面的に評価するため，評価項目及び主な評価内容を次のとおりとした。

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

注記　評価点数　1：著しく不足，2：不足，3：普通，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君に指示した。

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　開発スケジュール

この図の中に空欄 c・d があります

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

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

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

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

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

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