
プロジェクトマネジメントのトライアングル(三重制約、鉄のトライアングル、プロジェクトトライアングルとも呼ばれる)は、プロジェクトマネジメントの制約のモデルです。その起源は明らかではありませんが、少なくとも1950年代から使用されています。[1]それは次のように主張しています。
- 作業の品質は、プロジェクトの予算、期限、範囲 (機能) によって制約されます。
- プロジェクトマネージャーは制約間でトレードオフを行うことができます。
- 1 つの制約が変更されると、それを補うために他の制約も変更する必要があり、そうしないと品質が低下します。
たとえば、予算を増やしたり、範囲を縮小したりすることで、プロジェクトをより早く完了できます。同様に、範囲を拡大すると、予算とスケジュールも同等に増加する必要があります。スケジュールや範囲を調整せずに予算を削減すると、品質が低下します。
「良い、早い、安い。そのうちの 2 つを選ぶ。」これは、ジョン・ラスキンの名言とされているビジネスバランスの共通法則(「支払った分だけ得られる」と表現されることが多い) に述べられているが、根拠はなく、三角形の制約を簡潔にまとめるためによく似た表現が使われる。[2] [3]マーティン・バーンズ(1968) は、博士論文でコスト、時間、リソース (CTR) に基づくプロジェクト コスト モデルを提案し、1969 年には「契約管理における時間とコスト」と題するコースを設計し、各頂点がコスト、時間、品質 (CTQ) を表す三角形を描いた。[4]後に、品質をパフォーマンスとともに拡張し、CTP となった。三角形の面積は、固定され、固定コストと固定時間で知られているプロジェクトの範囲を表すことが理解されている。実際、範囲はコスト、時間、パフォーマンスの関数になる可能性があり、要素間のトレードオフが必要となる。
しかし、実際には、制約間のトレードオフは必ずしも可能ではありません。たとえば、人員が十分に揃っているプロジェクトに資金(と人材)を投入すると、プロジェクトが遅くなる可能性があります。[5]さらに、運営がうまくいかないプロジェクトでは、品質に悪影響を与えることなく予算、スケジュール、範囲を改善することは不可能であることがよくあります。
概要
時間制約とは、プロジェクトを完了するために利用できる時間の量を指します。コスト制約とは、プロジェクトに利用できる予算額を指します。範囲制約とは、プロジェクトの最終結果を得るために実行する必要があることを指します。これらの 3 つの制約は、多くの場合、競合する制約です。範囲が拡大すると、通常は時間とコストが増加し、時間制約が厳しいとコストが増加し範囲が縮小し、予算が厳しいと時間が増加し範囲が縮小する可能性があります。
プロジェクト管理の規律は、プロジェクト チーム (プロジェクト マネージャーだけではない) がこれらの制約を満たすように作業を整理できるようにするツールとテクニックを提供することです。
プロジェクト管理のもう 1 つのアプローチは、財務、時間、人的資源という 3 つの制約を考慮することです。より短い時間で仕事を終わらせる必要がある場合、より多くの人材をその問題に投入できますが、その結果、このタスクをより迅速に実行することでプロジェクトの他の部分のコストを同額削減しない限り、プロジェクトのコストが上昇します。
プロジェクト管理のグラフィック補助として、三角形は、時間、リソース、および技術目標を、三角形の角ではなく辺として示すことができます。 [6]アメリカ経営協会の「基礎プロジェクト管理」コースの元講師であるジョン・ストークは、三角形の外側と三角形の内側と呼ばれる一対の三角形を使用して、プロジェクトの意図は、許可された時間内またはそれ以前に、予算内または予算内で、要求された範囲を満たすか超えることであるという概念を表しました。内側の三角形と外側の三角形の間の距離は、3 つの要素のそれぞれに対するヘッジまたは偶発性を示しています。バイアスは距離によって示すことができます。時間バイアスが強いプロジェクトの例として、コストに関係なく基本的に時間どおりに完了する必要があったアラスカのパイプラインが挙げられます。何年もの開発の後、予定より 4 分以内にパイプの端から石油が流れ出ました。この図では、三角形の内側の時間側は、三角形の外側の線の上にありました。これは、技術目標の線にも当てはまりました。ただし、三角形の内側のコスト線は、プロジェクトが予算を大幅に超過したため、外側にありました。
ジェームズ・P・ルイス[7]は、プロジェクトの範囲は三角形の面積を表し、プロジェクトの成功を達成するための変数として選択できると示唆しています。彼はこの関係をPCTS(パフォーマンス、コスト、時間、範囲)と呼び、プロジェクトでは任意の3つを選択できると示唆しています。
プロジェクト トライアングルの真の価値は、あらゆるプロジェクトに存在する複雑さを示すことです。トライアングルの平面領域は、3 つの競合する値の間に存在する可能性のある優先順位のほぼ無限のバリエーションを表します。トライアングル内で可能な無限の多様性を認識することで、このグラフィック アシストを使用すると、プロジェクトの意思決定と計画がより適切になり、チーム メンバーとプロジェクト所有者間の連携が確保されます。
STR モデル
STRモデルは、「三角形モデル」を関係のグラフィック抽象化として捉える数学モデルです。
スコープは複雑さを指します (これは品質やパフォーマンスを意味する場合もあります)。リソースには、人 (労働者)、財務、物理が含まれます。これらの値は無制限とは見なされないことに注意してください。たとえば、1 人のパン職人がオーブンで 1 斤のパンを 1 時間で作れるとしても、オーブンの容量が限られているため、10 人のパン職人が同じオーブンで 1 時間に 10 斤のパンを作れるとは限りません。
プロジェクト管理の三角形のトピック
時間
分析目的で、成果物の作成に必要な時間は、いくつかの手法を使用して見積もられます。 1 つの方法は、作業分解図(WBS)に文書化された成果物を作成するために必要なタスクを特定することです。 各タスクの作業量が見積もられ、それらの見積が最終的な成果物の見積にまとめられます。
タスクには優先順位が付けられ、タスク間の依存関係が特定され、この情報はプロジェクト スケジュールに文書化されます。タスク間の依存関係は、プロジェクト全体の期間 (依存関係の制約) に影響する可能性があり、リソースの可用性 (リソースの制約) にも影響する可能性があります。時間は、他のすべてのリソースおよびコスト カテゴリとは異なります。
以前の類似プロジェクトの実際のコストを、現在のプロジェクトのコストを見積もるための基準として使用します。
プロジェクト管理知識体系(PMBOK)によれば、プロジェクト時間管理プロセスには次のものが含まれます。
- スケジュール管理を計画する
- アクティビティを定義する
- シーケンスアクティビティ
- アクティビティリソースの見積り
- アクティビティ期間の見積もり
- スケジュールの作成
- 制御スケジュール
アクティビティを定義する
- 入力: 管理計画、スコープベースライン、企業環境要因、組織プロセス資産
- ツール: 分解、ローリングウェーブ計画、専門家の判断
- 出力: アクティビティリスト、アクティビティ属性、マイルストーンリスト
アクティビティの順序付け
- 入力: プロジェクトスコープ ステートメント、アクティビティ リスト、アクティビティ属性、マイルストーン リスト、承認された変更要求
- ツール:先行図法(PDM)、矢印図法(ADM)、スケジュール ネットワーク テンプレート、依存関係の縮退、リードとラグの適用
- 出力: プロジェクトスケジュールネットワーク図、アクティビティリストの更新、アクティビティ属性の更新、変更要求
アクティビティリソースの見積もり
- 入力: 企業環境要因、組織プロセス資産、アクティビティリスト、アクティビティ属性、リソースの可用性、プロジェクト管理計画
- ツール: 専門家の判断の収集、代替分析、見積データの公開、プロジェクト管理ソフトウェアの実装、ボトムアップ見積
- 出力: アクティビティ リソース要件、アクティビティ属性、リソースの内訳構造、リソース カレンダー、変更更新の要求。
アクティビティ期間の推定
- 入力: 企業環境要因、組織プロセス資産、プロジェクト範囲記述書、活動リスト、活動属性、活動リソース要件、リソースカレンダー、プロジェクト管理計画、リスクレジスタ、活動コスト見積
- ツール: 専門家の判断収集、類似推定、パラメトリック推定、ボトムアップ推定、2 点推定、3 点推定、予備分析
- 出力: アクティビティ期間の見積もり、アクティビティ属性の更新と見積もり
スケジュール作成
- 入力: 組織プロセス資産、プロジェクト範囲ステートメント、アクティビティリスト、アクティビティ属性、プロジェクトスケジュールネットワーク図、アクティビティリソース要件、リソースカレンダー、アクティビティ期間見積もり、プロジェクト管理計画、リスクレジスタ
- ツール: スケジュール ネットワーク分析、クリティカル パス法、スケジュール圧縮、シナリオ分析、リソース平準化、クリティカル チェーン法、プロジェクト管理ソフトウェア、カレンダーの適用、リードとラグの調整、スケジュール モデル
- 出力: プロジェクト スケジュール、スケジュール モデル データ、スケジュール ベースライン、リソース要件の更新、アクティビティ属性、プロジェクト カレンダーの更新、要求の変更、プロジェクト管理計画の更新、スケジュール管理計画の更新
スケジュール管理
- 入力: スケジュール管理計画、スケジュールベースライン、パフォーマンスレポート、承認された変更要求
- ツール: 段階的な詳細化レポート、スケジュール変更管理システム、パフォーマンス測定、プロジェクト管理ソフトウェア、差異、分析、スケジュール比較棒グラフ
- 出力: モデルデータの更新スケジュール、ベースラインのスケジュール、パフォーマンス測定、要求された変更、推奨される是正措置、組織プロセス資産、アクティビティリストの更新、アクティビティ属性の更新、プロジェクト管理計画の更新
「時間」プロセス グループの複雑な性質のため、プロジェクト管理資格PMI Scheduling Professional (PMI-SP) が作成されました。
料金
プロジェクト コストの概算は、リソース、労働賃金などの作業パッケージ、コストの差異を生み出す影響要因の緩和または制御など、いくつかの変数に依存します。コストで使用されるツールは、リスク管理、コスト コンティンジェンシー、コスト エスカレーション、間接費です。ただし、固定費と変動費に対するこの基本的な会計アプローチ以外に、さまざまなプロジェクト コスト見積ツールを使用して計算される作業員のスキルと生産性など、経済コストを考慮する必要があります。これは、企業が臨時従業員や契約社員を雇用する場合や、作業を外注する場合に重要です。
コストプロセス領域
- コスト見積りは、アクティビティを完了するために必要なすべてのリソースのコストのおおよその見積もりです。
- コスト予算は、リソース、作業パッケージ、アクティビティの推定コストを集計してコスト ベースラインを確立します。
- コスト管理 - コストの変動や差異を生み出す要因は、さまざまなコスト管理ツールを使用して影響を受け、制御できます。
プロジェクト管理コスト見積ツール[8]
- 類似見積り: 類似プロジェクトのコストを使用して現在のプロジェクトのコストを決定する
- リソース コスト レートの決定: 見積または見積もりを通じて収集された単位別の商品および労働のコスト。
- ボトムアップ見積: 作業パッケージの詳細の最低レベルを使用して、それに関連するコストを要約します。次に、それをより高いレベルにロールアップして、プロジェクト全体のコストを計算します。
- パラメトリック推定: 履歴データと他の変数またはフロー間の統計的関係を測定します。
- ベンダー入札分析: プロジェクトに対してベンダーが提示した複数の入札の平均を取得します。
- 予備分析: ネットワーク パス上の各アクティビティのコストを集計し、プロジェクト マネージャーが決定した係数に基づいて、分析の最終結果に予備費または予備費を追加します。
- 品質コスト分析: 各アクティビティの最高品質でのコストを見積もります。
プロジェクト管理ソフトウェアを使用して、プロジェクトのコスト差異を計算できます。
範囲
最終結果を達成するために指定された要件。プロジェクトが達成すべきことの全体的な定義と、最終結果が何であるか、または何を達成すべきかの具体的な説明。スコープの主要な構成要素は、最終製品の品質です。個々のタスクに費やされる時間によって、プロジェクトの全体的な品質が決まります。一部のタスクは、適切に完了するために一定の時間を必要とする場合がありますが、より多くの時間を与えれば、例外的に完了できる場合があります。大規模なプロジェクトでは、品質が時間とコストに大きな影響を与える場合があります (またはその逆)。
これら 3 つの制約により、「時間どおり、仕様どおり、予算どおり」というフレーズが生まれました。この場合、「範囲」という用語は「仕様」に置き換えられます。
プロジェクト制約モデルの進化


伝統的に、プロジェクト制約モデルは、「コスト」、「時間」、「範囲」という 3 つの主要な制約を認識していました。これらの制約は、これらの要素間の強い相互依存関係を示す幾何学的比率の三角形を構成します。これらの要素のいずれかを変更する必要があるときは、他の要素の少なくとも 1 つも操作する必要があります。[9]
三角形モデルが主流として受け入れられているため、「コスト」と「時間」は一貫して表現されているように見えます。ただし、「スコープ」は、三角形の図のコンテキストや各プロジェクトの認識に応じて、同じ意味で使用されることがよくあります。スコープ/目標/製品/成果物/品質/パフォーマンス/出力はすべて比較的類似した一般的なバリエーションの例ですが、上記の「人的リソース」の提案は、より専門的な解釈を提供します。
このバリエーションの広範な使用は、3 番目の制約条件のニュアンスによってもたらされる曖昧さのレベルと、もちろん三角形モデルの柔軟性における価値のレベルを意味します。この曖昧さにより、プロジェクトの出力とプロジェクトのプロセスの間の焦点がぼやけ、上記の例の用語は 2 つのコンテキストで異なる推進力を持つ可能性があります。「コスト」と「時間」/「納品」はどちらも、プロジェクトの最上位レベルの入力を表します。
「プロジェクト ダイヤモンド」モデル[10]は、「範囲」と「品質」を「3 番目の」制約として別々に含めることで、このぼやけた焦点を生み出しています。プロジェクト管理の成熟度が高まっていることを踏まえて、「品質」を主要な制約要因として追加することにはメリットがありますが、このモデルでは、アウトプットとプロセスの間の明確さがまだ欠けています。ただし、ダイヤモンド モデルでは、三角形の頂点間の強い相互関係の類推は捉えられていません。
PMBOK 4.0 は、監視および管理される 6 つの要素を持つ 3 つの制約に基づく進化したモデルを提供しました。[11]これは、三角形のアナロジー (2 つの三角形が重なり合っている) の強さを維持しながら、同時に 1 つの三角形のプロジェクト入力/出力要素と、もう 1 つの三角形のプロジェクト プロセス要素間の分離と関係を表す 6 角形の星として示されます。星の変数は次のとおりです。
- 入力出力三角形
- 範囲
- 料金
- 時間
- プロセストライアングル
- リスク
- 品質
- リソース
3 番目の制約の曖昧さと「プロジェクト ダイヤモンド」の提案を考慮すると、代わりにプロジェクトの目標または成果物を 3 番目の制約として考えることができます。これは、サブ要素「スコープ」と「品質」で構成されています。プロジェクトの出力に関しては、「スコープ」と「品質」の両方を調整できるため、目標/成果物の全体的な操作が可能になります。この解釈には、元の三角形の入力/出力形式の 4 つの主要な要素が含まれます。これは、特に「品質」がプロジェクトの出力とプロセスの観点から個別に監視できることを示している PMBOK Star に組み込むこともできます。この提案に加えて、「目標」という用語の使用は、変更イニシアチブの出力を最もよく表す可能性があり、一方、成果物はより具体的な出力を最もよく表す可能性があります。[12]
プロジェクト成功基準の進化
3 つの制約は、プロジェクト成功基準の最小数を表していますが、それだけでは不十分です。そのため、基本的な入力-プロセス-出力の連鎖である変化理論に基づいて、プロジェクト成功のさまざまな基準を定義および拡張するための多くの研究が行われてきました。
バナーマン(2008)は、プロジェクト成功の5つのLレベル、すなわちチーム、プロジェクト管理、成果物、ビジネス、戦略から構成されるマルチレベルプロジェクト成功フレームワークを提案した。[13]
UNDPは2012年に、プロジェクトの成功の6つの段階(投入、プロセス、出力、結果、影響)からなる成果枠組みを提案した。[14]
Zidaneら(2016)は、結果フレームワークをPESTOLフレームワークに拡張してプロジェクトの成功を計画および評価し、各プロジェクトに費やされた「費用対効果」を効率性と有効性の観点から評価するために使用できるようにしました。[15]
したがって、3 つの制約は、プロジェクトの成功を可能な限り総合的に計画および評価するためのさまざまなフレームワークに開発されてきました。
制限事項
プロジェクト管理の三角形は、プロジェクトを分析するために使用されます。[16]これは、定められた予算とスケジュール内で、必要な範囲を妥当な品質で提供することを成功と定義するものとして誤って使用されることがよくあります。[17] [18] [19] [20]プロジェクト管理の三角形は、利害関係者への影響、 [21]学習[22]およびユーザー満足度 [ 23]を含む成功の重要な側面を省略しているため、プロジェクトの成功モデルとしては不十分であると考えられています。その後、ダイヤモンドモデル、ピラミッドモデル、6つ以上の制約、および制約理論など、基本的な3つの制約のいくつかの強化が提案されました。それに応じて、プロジェクトの成功基準も3つのパラメーターから複数のパラメーターに強化されました。
参照
参考文献
- ^アトキンソン 、ロジャー (1999 年 12 月)。「プロジェクト管理: コスト、時間、品質、2 つの最良の推測と現象、他の成功基準を受け入れる時期」。国際プロジェクト管理ジャーナル。17 (6): 337–342。doi :10.1016/S0263-7863(98)00069-6。
- ^ Wyngaard, Charles Van (2012). 「三重制約の理論 — 概念的レビュー」2012 IEEE 国際産業工学および工学管理会議pp. 1991–1997. doi :10.1109/IEEM.2012.6838095. ISBN 978-1-4673-2945-3. S2CID 12434391。
- ^ 「プロジェクト トライアングル」。
- ^ https://pmworldlibrary.net/wp-content/uploads/2018/11/pmwl-barnes-how-it-all-began-pmwt-july-2006.pdf [ベア URL PDF ]
- ^ ブルックス、フレデリック (1995)。『神話の人月』(アニバーサリー版)。ボストン、マサチューセッツ州、米国:アディソン・ウェズリー・ロングマン出版。ISBN 0-201-83595-9。
- ^ Carl S. Chatfield、Timothy D. Johnson (2003)。Microsoft Office Project 2003 ステップ バイ ステップ: ステップ バイ ステップ。476 ページ
- ^ Lewis, James P. (2005).プロジェクト計画、スケジュール、管理、第 4 版。McGraw Hill。ISBN 978-0-07-146037-8。
- ^ PMBOK 第3版 2004年 p.165
- ^ ( Chatfield, Carl. 「プロジェクト管理の短期コース」 Microsoft.)
- ^ (ブラウン、クレイグ。「かつては鉄の三角地帯だった」。ベター プロジェクト。)
- ^ プロジェクトマネジメント協会 (2009)プロジェクトマネジメント知識体系ガイド: PMBOK ガイド。第 1 章
- ^ Brem (2011) T214 複雑系の理解 – TMA02 . Q4
- ^ バナーマン (2008) https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
- ^ UNDP (2012) 開発成果フレームワークの概要
- ^ ジダン (2016) https://www.researchgate.net/publication/308727415_PESTOL_-_Framework_for_Project_Evaluation_on_Strategic_Tactical_and_Operational_Levels
- ^ Erik Bethke (2003).ゲーム開発と制作. p.65.
- ^ Michael W. Newell、Marina N. Grashina (2004)。プロジェクトマネジメントに関する質疑応答集。p.8
- ^ Pamela McGhee、Peter McAliney (2007)。『痛みのないプロジェクト管理』p.74。
- ^ Michael Gentile、Ronald D. Collette、Thomas D. August (2005)。CISOハンドブック。p.172
- ^ Sha, Mandy (2014-08-01). 「定性的方法を使用する調査研究プロジェクトへのプロジェクト管理アプローチの適用」. Survey Practice . 7 (4): 1–8. doi : 10.29115/SP-2014-0021 .
- ^ Ralph, Paul; Kelly, Paul (2014). 「ソフトウェアエンジニアリングの成功の次元」。第36回国際ソフトウェアエンジニアリング会議の議事録(PDF)。Icse 2014. ACM。pp. 24–35。doi : 10.1145 /2568225.2568261。ISBN 978-1-4503-2756-5. S2CID 14897722。
- ^ Shenhar, A.; Dvir, Dov (1997). 「プロジェクト成功の次元のマッピング」.プロジェクトマネジメントジャーナル. 28 (2): 5–13.
- ^ Delone, William H.; McLean, Ephraim R. (2003 年 4 月 1 日)。「情報システム 成功のDeLoneおよび McLean モデル: 10 年間のアップデート」。Journal of Management Information Systems。19 ( 4): 9–30。doi : 10.1080 /07421222.2003.11045748。ISSN 0742-1222。S2CID 3138489 。
