Critical Chain Project Management（CCPM）は、バッファマネジメントによってプロジェクトを効率的かつ期日通りに完了させることを特徴とする、代表的なプロジェクトマネジメント手法の1つである。しかし、高い変動性と不確実性を持つ研究開発（Research and Development: R&D）プロジェクトにCCPMを適用する場合、バッファの変動が大きすぎて状況把握が難しく、また計画変更に多くの手間が必要だという課題がある。本論文ではこの課題を解決し、R&Dプロジェクトでも効果的なバッファマネジメントが実践できるプロジェクトマネジメントの仕組みとして、仮想バッファマネジメント（Virtual Buffer Management: VBM）を提案する。VBMは CCPMのようにクリティカルチェーンに指定されたタスクを基にプロジェクトバッファを計算するのではなく、プロジェクトの全てのタスクを基にバッファを計算する。これにより、プロジェクト状況の可視化を改善し、CCPMより少ない作業量で計画変更が可能な仕組みを実現した。VBMはCCPMの利用が困難なプロジェクトにおいて、有効な代替手段の一つとして利用できると考える。本論文ではVBMの仕組みについて詳細に説明する。

1. まえがき

ビジネス環境の競争が激化し、将来の予測が困難とされるVUCA時代において、革新的な成果を生み出す研究開発（R&D）プロジェクトは、成果創出までのスピードアップが求められる。R&Dプロジェクトのスピードアップには、早い段階での課題発見と軌道修正が重要であり、それにはプロジェクトマネジメントが必要である。

そこで、代表的なプロジェクトマネジメント手法の1つであるCritical Chain Project Management（CCPM）^1）に注目した。CCPMでは、プロジェクトの進捗率を横軸に、バッファの消費率を縦軸にとった傾向グラフ（図1）を用い、日々の進捗率とバッファ消費率をプロットする。傾向グラフは、進捗率に対してバッファの消費が少なく予定日数に余裕がある場合には「安全（緑）」、予定日数ぎりぎりなら「注意（黄）」、予定日数超過が予想される場合には「危険（赤）」と3段階に色分けされて（図1）おり、プロジェクトの状況を一目で確認することができる。これは各タスクに含まれているバッファをプロジェクトの最後に集約し、プロジェクトバッファとして管理することで実現しており、これをバッファマネジメントという^2,3）。

傾向グラフは、プロジェクトが進捗しながらバッファも適度に消費することを理想とし、基本的に左下から右上に向かって作業の進捗に伴い、バッファが消費されるという形で進展する。左下の点は進捗率とバッファ消費率がともに0％であり、プロジェクトの開始時点を表す。右上の点では進捗率とバッファ消費率がともに100％となり、予定通りの完了を表す。

さらに、傾向グラフでは現在日の進捗率とバッファ消費率だけでなく、過去の履歴も踏まえて状況を判断することが重要である。例えば、同じ進捗率55％、バッファ消費率70％の場合でも、過去の傾向によって異なるマネジメント判断を行うことになる（図2）。

CCPMは当社の商品開発プロジェクトで数多くの実績を残しており、その効果をR&Dプロジェクトでも発揮すべく導入を進めた。ところが、非常に高い変動性と不確実性を持つプロジェクトでは、傾向グラフでプロットした点と線が複雑に絡み合い、状況を正しく読み取れなくなるケースを複数観測した（図3）。

これは商品開発プロジェクトでは見られなかった現象であり、このような状態では、マネジメント判断の基準となる傾向グラフが機能しない。そこで、このようにCCPMを適用できないR&Dプロジェクトでも、傾向グラフを使った効果的なバッファマネジメントを実現する代替案として、仮想バッファマネジメント（Virtual Buffer Management: VBM）を考案した。

2. 課題

2.1 マネジメント判断が困難な傾向グラフ

R&DプロジェクトにCCPMを適用した際に傾向グラフが複雑化する現象は、R&Dプロジェクトが持つ高い不確実性に起因する。例えば、CCPMでは、プロジェクトバッファを計算するために、目標達成までの段取りを詳細に作成し、一連のタスクの中で一番期間の長いタスクの集合であるクリティカルチェーンを特定しなければならない。しかし、不確実性が高いR&Dプロジェクトは「やってみないと分からない」ことが多く、短期的な見通ししか立たない場合がある。このようなプロジェクトでCCPMを導入するには、目標を達成するためにまず手順を仮説として立て、それに基づいて具体的な段取りをとりあえず作ることになる。だが、プロジェクトが進展するにつれ、新たな発見や技術的な課題の発生によって、仮説と実態が乖離し、タスクの追加や削除、優先順位の変更が必要になる。この段取りの変更によってクリティカルチェーン上の残作業量が増加した場合、遅れが生じ、進捗率が減少するので傾向グラフは左側に移動する。この遅れを吸収するためにバッファも消費されるため、傾向グラフの点は上に移動するので、全体として左上に移動する（図4-①）。

さらに、R&Dプロジェクトでは、新しい技術に挑戦しながら品質を担保するため開発の難易度が高く、通常の商品開発と比べ遅れが生じやすい。これにより高い確率でバッファを使い切ってしまい、バッファ消費率が100％を超過する。このような時プロジェクトマネージャーは、目指す品質を担保するためにコストや納期の調整を迫られるが、組織の予算には限りがあるため、納期を延ばすことが多い。納期の延長により、バッファが回復し、傾向グラフの点は下方向に移動する（図4-②）。この①と②の変更が同時に行われた結果、グラフの点は変更前の点から左下に戻るようにプロットされる。

前述の通り、傾向グラフは通常進捗する過程で左下から右上に進むため、段取り変更後、再度右上に向かう際に以前と似た経路を通ることとなり、プロットした点と線が重なり、傾向グラフが複雑化する（図3）。①と②のどちらか一方の変更だけであれば問題ないが、①と②の両方の変更が同時に行われると、この現象が発生する。このようにグラフの点が複雑に移動するため、傾向グラフの視認性が低下する。その結果、進捗状況を正しく把握できず、最適なマネジメント判断ができなくなる。観測したプロジェクトの中でも、特に難易度が高いプロジェクトでは、このような現象が1週間に1回の頻度で繰り返し発生し、図3のグラフの様な、ますますマネジメント判断に使えないものとなってしまった。

2.2 技術者の実感とずれた可視化

CCPMでは、クリティカルチェーンは優先的に実行されるべき重要なタスクが配置されている。しかし、R&Dプロジェクトではタスクの優先度が頻繁に変わるため、クリティカルチェーン以外のタスクの重要度が上がり、そちらを優先して実行することがある。このような状況では、重要なタスクが進行していても傾向グラフの進捗率は上がらない。プロジェクトマネージャーや技術者は傾向グラフから正しい進捗状況を把握できず、計画の見直しや対応策の検討が遅れる可能性がある。

さらに、このような齟齬が頻発すると、技術者の傾向グラフに対する信頼性が低下する恐れがある。技術者は傾向グラフが実態を正確に反映していないと感じることで、グラフのデータを参考にしなくなり、プロジェクト管理全体の効率が低下してしまう。このように傾向グラフが示す進捗状況が技術者の実感とずれる状況も、視認性の問題といえる。

2.3 段取り変更の手間

R&DプロジェクトにCCPMを導入する際、視認性の低下以外にも段取り変更の手間がかかることが課題である。前述の通り、R&Dプロジェクトでは計画段階で立てた段取りが実際の進行にそぐわなくなることが多く、頻繁に段取りを変更する必要が生じる。しかし、段取り変更には、タスク間の依存関係を再考し、バッファ確保のためにリソースを確保する必要があり、多くの時間を要する。

結果、管理工数が増加して、複数のプロジェクトリーダーから不満が上がっていた。

さらに、頻繁な段取り変更は作業を止め、技術者の作業効率やモチベーションが低下する事例や、かかる手間から段取りの変更作業が追い付かず、段取りと実態が徐々に乖離してしまい、バッファマネジメントそのものに対する信頼性が低下する事例も発生した。

3. 技術内容

3.1 取り組みの狙い

上記の課題から、高い変動性と不確実性を伴うR&Dプロジェクトにおいて、以下2つの目的を果たす新しいバッファマネジメントの仕組みが必要と考えた。

• 傾向グラフの視認性を高める。
• 段取り変更の手間を軽減する。

CCPMの大きな特徴は、クリティカルチェーンの特定によるバッファマネジメントの実現である。計画時に特定したクリティカルチェーンは、原則としてプロジェクト完了まで変わらないものとされ、通常、計画と実績のずれはバッファで吸収するため、計画変更はほとんど発生しない。

しかし、高い変動性と不確実性を持つR&Dプロジェクトの場合、タスクの優先順位が変わることで、クリティカルチェーンが変わってしまう。これが、傾向グラフの視認性を低下させ、計画変更に大きな手間がかかる要因となっている。そこで、このクリティカルチェーンの特定に頼らずプロジェクトバッファを計算する代替手段を準備することができれば、課題を解決できると考えた。

そこで、本論文ではどんなプロジェクトであっても必ず収集できる「リソース」、「プロジェクトの期間」、「見積もり」の3つの要素だけを用いてバッファマネジメントを行う方法を提案する。後述するようにプロジェクトバッファを仮想して設定するため、VBMと名付けた。3要素の具体的な内容は、以下のとおりである。

• リソース：プロジェクトのメンバー数（人）
• プロジェクトの期間：開始から完了までの期間（日）
• 見積もり：タスクの期間見積もり（日）

なお、見積もりはその時点で見通しが立つ範囲内のタスクの期間見積もりでよい。

3.2 期間見積もりの工数への変換

VBMは、CCPMのようにクリティカルチェーンを特定しないため、プロジェクトで利用可能な全てのキャパシティ（リソース×期間＝工数）からプロジェクトバッファ（VBMでは「仮想バッファ」ともいう）を算出する。そのため、VBMは基本単位に工数を用いることとし、次の式で各タスクの期間見積もりを全て工数（E）へ変換する。

• Ei：タスクiの工数見積もり
• Ti：タスクiの期間見積もり
• Ni：タスクiに割り当てられる担当人数

3.3 VBMにおけるプロジェクトバッファの計算

クリティカルチェーンを使わずに仮想バッファを計算する式を次の通りとした。

• Bl：仮想バッファの長さ［人日］
• Ut：総工数［人日］

CCPMではABP見積もり（Aggressive But Possible：厳しいがなんとかできるぎりぎりの日数）を基にクリティカルチェーンを特定する。そしてこのクリティカルチェーンの1/2に相当する期間をプロジェクトバッファとして設定し、プロジェクトの最後に配置する^1,3）。つまり、プロジェクトバッファはプロジェクト期間のおよそ1/3になる。VBMでもCCPMの1/3の目安を用いてプロジェクトバッファを計算するが、全てのタスク工数を合計した総工数を基に計算することとした。これは、CCPMの知識がない技術者でも使える仕組みにするため、タスクの期間見積もりはバッファを含んだ見積もりを基に計算することにした。そのため、技術者は慣れた方法でバッファを含んだ見積もりをすれば良く、もしCCPMに慣れている場合はABP見積もりを1.5倍すれば良い。

3.4 総工数の定義と使い分け

VBMでは、進捗率とプロジェクトバッファを計算する重要な値として、プロジェクト期間中に実行する全てのタスクの工数見積もりを表す総工数（Ut）を用いる。ただしUtは、計画変更に合わせて変動する値である。さらにUtは、プロジェクトが短期的な見通ししか立たない場合に、納期までのプロジェクトバッファを算出できる値でなければならない。そのため、Utは以下の2つの値を使い分けることとする。

まず、Utの1つ目の考え方として、現時点で見通せる全てのタスクの工数見積り（E）を合計した値を、計画総工数（Up）とし、次の式で表す。

• Up：計画総工数［人日］
• Ei：タスクiの工数見積もり［人日］

しかし、前述の通りR&Dプロジェクトは短期的な見通ししかたたない場合がある。この場合、Upでは納期までの期間におけるバッファの計算ができない。そうした状況下でも納期までのプロジェクトバッファを算出し、バッファマネジメントを実現するために、Utのもう一つの考え方として最大総工数（Um）を用意し、次の式で表す。

• Um：最大総工数［人日］
• Pd：プロジェクト期間［日］
• R：プロジェクトメンバー数［人］

このUmから仮想的にプロジェクトバッファを算出することで、短期間の見通しから納期までのバッファマネジメントを可能とする。本手法をVBMとする所以である。

ただし、Umはプロジェクト期間とメンバー数を基に仮想的に設定した工数見積もりであり、プロジェクト完了時の計画総工数（Up）と合致するとは限らない。そのため、プロジェクト完了時までUmを使い続けてしまうと、計画した全てのタスクが完了しても進捗率が100％にならない可能性がある。この問題を解決するため、納期までの見通しが立ったタイミングで、UtをUmからUpに切り替えることにした。切り替えるタイミングは、UpとUmの差を％換算した見積もり工数の差異（Du）を見て判断する。

• Du：見積工数の差異［％］

短期的な見通ししか立たない場合、プロジェクトの初期段階ではUpを基に進捗率や仮想バッファが計算できないため、Umを用いる。プロジェクトの期間中は、見通しが立つにつれタスクの追加や削除により計画総工数が日々変化するため、差異も日々計算し直す。その差異があらかじめ設定した閾値までは、Umを使い続ける。プロジェクトが進み、差異が閾値を下回ったタイミングでUpに切り替えることで、計画した全てのタスクが完了した時点で進捗率が100％を示すようになる。

3.5 閾値の考え方

いくつかの閾値のパターンを検討した結果、現在当社では閾値を15％と設定している。

• Du≧15％：総工数（Ut）をUmとする
• Du<15％：総工数（Ut）をUpとする

閾値を15％に設定した理由は、1. 最大総工数（Um）とプロジェクト完了時の計画総工数（Up）のずれ、2. 納期までの見通しが確定する時期、の2つである。

見通しの立たないプロジェクトの初期段階では、洗い出されるタスクが限られているため、UpとUmとの間に大きな差がある。プロジェクトが進むにつれ、その差は縮小していくが、プロジェクト完了時にUpとUmが完全に一致することはなく、ずれが生じる。閾値がこのずれより小さいと、Upに切り替えることができないため、閾値はずれより大きい値を設定する必要がある。当社では、大半のプロジェクトで、プロジェクト完了時のUpとUmのずれが10％以内に収まることが観察された。この結果から、閾値は10％より大きい値が望ましいと判断した。

次に、プロジェクトが進行し納期までの見通しが確定する時期についても考慮した。閾値が大きすぎると、納期までの見通しが立っていない段階でUmからUpに切り替わることになる。早すぎる切り替えはその後の計画変更で傾向グラフの変動を招き、プロジェクトマネージャーを混乱させる恐れがある。当社では、例えば100日のプロジェクトの場合、納期まで残り10日（10％、2週間）程度の時点になれば大半のプロジェクトは最後までの見通しが立ったのに対し、納期まで残り20日（20％、約1か月）では、まだ見通しが立たなかった。この結果から、閾値は20％より小さい値が望ましいと判断した。

これら2つの要素を考慮し、小さすぎず、大きすぎず、の最適な閾値を10％と20％の間の15％に設定した。

3.6 計画変更に合わせて変動する仮想バッファ

前述の通り、CCPMではクリティカルチェーンを特定し、クリティカルチェーンの長さを分母としてプロジェクトバッファを算出する。クリティカルチェーンとプロジェクトバッファの値は、プロジェクトの進捗状況を分かりやすくし、評価を容易にするため、固定されている。この値の固定は、計画されたプロジェクトの段取りが比較的安定していることを前提としている。そのため、R&Dプロジェクトのように高い変動性と不確実性を持つプロジェクトでは、プロジェクトバッファの変動が大きくなり、進捗状況が分かりにくくなる。

一方、VBMは、バッファを含めた必要工数を表すため、Utの1/3を仮想バッファとした。仮想バッファの大きな特徴は、タスクの追加や削除によってUtが変動しても、常にこの比率を保ってバッファの量を調整することである。例えばUtが90の場合、仮想バッファは30となるが、タスクの追加によってUtが99に増えた場合仮想バッファは1/3の比率を保ち33となる。

3.7 進捗率とバッファ消費率の計算

VBMの進捗率（Pr）は、総工数（Ut）の内の完了工数（Uc）の割合で計算する。完了工数（Uc）とは、ある時点で、各タスクの残作業日数を工数換算し合計したものを、総工数（Ut）から引いた値である。ただし、実際には確定したUtはプロジェクト完了まで得られないため、仮想値であるUpまたはUmを用いる。

• Pr：進捗率［％］
• Uc：完了工数［人日］
• Ri：工数換算したタスクiの残作業日数

バッファ消費率（Br）は、標準バッファ消費率にバッファ差異率を足して計算する。

• Br：バッファ消費率［％］

バッファ差異率は、期間経過率と進捗率の差異である。期間経過率とは、プロジェクト期間（Pd）に対して現在までに経過した期間（De）の割合で示す。

• De：経過日数［日］

傾向グラフでは、プロジェクトがバッファを安定的に消費しながらプロジェクト完了した場合、進捗率0％・バッファ消費率0％の点と、進捗率100％・バッファ消費率100％の点を結んだ直線が、期間経過に対する理想的なバッファの消費量を表す。VBMではこの直線を「標準バッファ消費率」と呼び、期間経過率と標準バッファ消費率は1：1で比例する。

例えば、仮想バッファの総量が30の場合、期間経過率50％では標準バッファ消費率50％となり、理想的なバッファの消費量は15となる。この期間経過率が25％に低下した場合、標準バッファ消費率は25％となり、理想的なバッファの消費量は7.5となる。

以上のロジックを1つの式としてまとめるとバッファ消費率（Br）の計算式は以下の通りとなり、ロジックを視覚的に表現したものを図5で示す。

3.8 グラフの視認性を維持する仕組み

VBMでは、タスクが増えると、CCPMと同様に進捗率が低下し、バッファ消費率が上がる。これにより、グラフ上でのプロット点はCCPMと同様に左上方向に移動する（図6-①）。プロジェクトマネージャーがこのままではプロジェクトが間に合わないと判断し、納期を延長すると、プロジェクトの開始から完了までの期間が伸び、現在日の相対的な期間経過率は下がることになる。例えば、プロジェクトの総日数が10日間の計画に対し、5日が経過した場合、期間経過率は50％であるが、納期を10日間延長すると、20日間に対して5日が経過したことになり、期間経過率は25％となる。

期間経過率が低下するとバッファ消費率（Br）は低下し、プロット点は下方向に移動する。仕組みは異なるが、VBMの傾向グラフはCCPMと同様の動きをすることが分かる。これを、上記のタスク増加の現象と合わせると、結果的にプロットした点が左下方向へ移動することになり、課題で述べた点と線が重なってしまう現象が発生するように思える。しかし、VBMでは、納期延長により低下した標準バッファ消費率を基に、過去のプロットされたバッファ消費率の実績もすべて再計算される。そのため、過去の実績も最新の点と同様に、下方向へ移動することとなり、CCPMのように過去にプロットされた点と新しい点が重なることはない（図6-②）。なお、進捗率はプロットした時点での総工数を基に計算しているため、値は変わらない。これにより、プロジェクトの最新状況と過去の傾向の一貫性が保たれ、視認性を維持した形で適切な管理が可能となる。

4. 結果と考察

VBMの概念をMicrosoft Excel®でツール化し、複数のR&Dプロジェクトに導入した。VBMでの管理を開始してから1年が経過した現在、以下の結果が得られている。

4.1 視認性の向上

図3で示した実例の1つをもとに、CCPMの実績データをVBMデータに変換した結果を示す（図7）。CCPMの傾向グラフの視認性を低下させる現象は図中のAに現れている。このプロジェクトではバッファ消費率が100％を超え、さらにタスクが追加されたことをきっかけに、納期を1か月延長した。結果、CCPMの傾向グラフでは、点が左下にプロットされたことでグラフが複雑化し、視認性が低下していることが分かる。

一方VBMのグラフでは、納期を延長した際に全ての進捗率・バッファ消費率の実績が再計算されたことでグラフ全体が下方向へ移動していることが分かる。これは、3.6で述べた仮想バッファが常にUtの1/3の比率を保って変動する特徴と、3.8で述べた視認性を維持する仕組みによるものである。これにより、グラフ下部に過去のデータの傾向を残しつつ、グラフ上部に納期延長後の進捗をプロットするスペースが確保される。その結果、VBMでは納期延長後も、CCPMのように過去にプロットされた点と新しい点が重なることはなく、グラフの視認性を保っている。

4.2 技術者の実感に近い可視化

図7の検証を通じて、変動性の高いR&Dプロジェクトでは、CCPMよりVBMの方が技術者の実感により近い可視化を実現できることも確認した。

図7のBではクリティカルチェーン上のタスクが大きく進展し、CCPMの傾向グラフが急激に右下へ動いているのに対し、VBMでは緩やかに右下へ動いており、VBMの傾向グラフの変化がCCPMより小さい。この動きの違いは、進捗率とバッファ消費率を計算するときの分母の違いによる。CCPMではクリティカルチェーンは全タスクの一部であり、進捗率とバッファ消費率を計算するための分母となる。クリティカルチェーンのタスクが進捗すれば、グラフはそれを反映する。逆に言えば、クリティカルチェーンではないタスクが進捗しても、クリティカルチェーンのタスクの進捗に変化がなければ、グラフの進捗率は変化せず、バッファのみが消費される。そのため、クリティカルチェーン以外のタスクが優先的に実行されることがあるR&Dプロジェクトでは、重要なタスクが進捗しているにもかかわらず、傾向グラフの進捗率には反映されず、技術者の進捗の実感とずれてしまう。

一方、VBMでは全てのタスクを分母として進捗率とバッファ消費率を計算するため、すべての作業実績が進捗率とバッファ消費率に反映される。その結果、CCPMと比較して、VBMのほうが変化は少なく表示されるが、技術者が実施した全てのタスクがグラフに反映されることで、技術者の実感により近い進捗状況を傾向グラフで可視化できる。

4.3 計画変更における手間の軽減

CCPMでは、段取りを変更するためにタスクの依存関係、順序、リソース競合などを見直し、クリティカルチェーンを再度特定する必要があるため、一度の段取り変更に30分から数時間を要していた。

一方、VBMでは、3.2で述べた通り、プロジェクトのキャパシティからバッファを計算している。そのため、CCPMのようにタスク間の依存関係や順序、リソース競合を考慮する必要はない。計画変更をしたい場合は、計画総工数（Up）が最大総工数（Um）を超えないように注意しながらタスクの追加・削除を行うだけで済み、ほとんどの変更は数十秒から数分で完了する。その結果、VBMを導入したプロジェクトでは、毎日15分程度の進捗会議中に計画変更が行われており、CCPMと比較して大幅に手間が少なくなっている。

4.4 ユーザー評価

VBMによるプロジェクト管理の検証に協力いただいた技術者6名に、VBMの有効性に関して「1.そう思わない」～「5.そう思う」の5段階評価のアンケートを実施した（表1）。この結果から、VBMの計画変更の容易性・プロジェクト状況可視化の改善・VBMの高変動型プロジェクトでの有用性の評価がいずれも高いことが分かる。また、回答者からは「CCPMでは管理が難しかったが、VBMでは管理がとてもしやすい。上司から無理な要求が来た場合も、実際に動かせるリソースを工数で可視化できることで、達成可能な計画を上司と議論できるようになった。」とのコメントもあり、VBMが実際のプロジェクト管理において有効であると評価された。

5. むすび

5.1 VBMの適用条件

CCPMの基本概念のうち、クリティカルチェーンとそれに関連する合流チェーンや合流バッファ以外の要素は、VBMでの適用が可能である。期間見積もりやプロジェクトバッファの活用、傾向グラフによる進捗の可視化に加え、タスクの集中化やリソースの最適化はプロジェクト実行時の基本動作である。

VBMの導入により、これまでCCPMでの管理が困難であった複数のプロジェクトにおいて効果的にバッファマネジメントを実践するための可視化と、計画変更の手間の軽減が可能となった。ただし、VBMはCCPMから完全に置き換えることを意図した仕組みではない。

CCPMでは、タスクの依存関係からクリティカルチェーンを特定し、プロジェクトバッファを算出することで、タスクの遅れによる納期への影響を厳密に管理することができる。しかし、VBMではこれを厳密に管理することができない。CCPMで管理できるような、ある程度安定した段取りを作れるプロジェクトにVBMを導入すると、クリティカルチェーンが進捗していなくても他のタスクが進捗していることで進捗率が上がってしまう。このような場合、クリティカルチェーンの遅れに気づかず、マネジメント判断が遅れる可能性がある。そのため、プロジェクトの見通しが立ち、タスク間の依存関係が明確であり、頻繁な段取り変更を要しないプロジェクトでは、CCPMの利用を強く推奨する。VBMはあくまで高い変動性と不確実性によりCCPMの適用が困難なプロジェクトを管理するための仕組みである。

5.2 今後の展開

本論文では非常に高い変動性と不確実性をもつR&Dプロジェクトにおいて、それらの課題を解決しつつバッファマネジメントを実践できる新しい可視化と計画変更の手間軽減の仕組みとしてVBMを提案した。

本仕組みは、R&Dプロジェクトに限らず、CCPMの利用が困難なプロジェクト管理において、有効な代替案の一つとして活用できると考えている。例えば、市場調査や競合分析が必要となる製品企画や新規事業立ち上げ、新しい技術やシステムの導入、要件の変更、市場の変化など、多くの要因により影響を受けるITプロジェクトの構想や企画フェーズなどのプロジェクトにも適用できると考える。今後も、VBMの有効性の検証と改善を続け、技術者の負荷軽減とプロジェクトの生産性向上に努めていきたい。

参考文献

1）

西原隆,栗山潤, TOC/CCPM標準ハンドブック, 株式会社秀和システム, 2010, p. 69-82, 112-113, 271.

2）

岸良裕司, マネジメント改革の工程表, 中経出版, 2006, p. 70-71, 239.

3）

後藤智博 他, Project Management進化論, プレジデント社, 2022, p. 102-125, 199.