プロジェクト管理の三角形
Lua エラー package.lua 内、80 行目: module 'Module:Message box/configuration' not found
プロジェクト管理の三角形(Project management triangle、鉄の三角形、プロジェクトの三角形とも呼ばれる) は、プロジェクトマネジメントの制約モデル。その起源は不明だが、少なくとも 1950 年代から使用されている [1]。
次のように言われている：
- 仕事の品質は、プロジェクトの予算、期限、範囲 (機能) によって制約される。
- プロジェクトマネージャは、制約間でトレードすることができる。
- １つの制約を変更すると、それを補うために他の制約を変更する必要が生じる。そうでなければ、品質が低下する。
たとえば、予算を増やしたり範囲を縮小したりすることで、プロジェクトをより早く完了することができる。同様に、範囲を拡大すると、予算とスケジュールも同様に増加させる必要がある。スケジュールや範囲を調整せずに予算を削減することは、品質の低下につながる。
"Good, fast, cheap. Choose two." は、 John Ruskinの著作であるCommon Law of Business Balance (「You get what you pay for.」と表現されることが多い) で述べられているように、何の証拠もなく、三角形の制約を簡潔にカプセル化するためによく使用される [2] [3] [4]。Martin Barnes (1968) は、博士論文でコスト、時間、およびリソース (CTR) に基づくプロジェクト コスト モデルを提案し、1969 年に「契約管理における時間とコスト」というタイトルのコースを設計し、各頂点に三角形を描いた。コスト、時間、品質 (CTQ) を表す。 その後、彼はパフォーマンスで品質を拡大し、CTQになりました。三角形の面積は、一定のコストと時間で固定され、既知であるプロジェクトの範囲を表すと理解される。実際、範囲はコスト、時間、およびパフォーマンスの関数になる可能性があり、要因間のトレードオフが必要である。
ただし、実際には、制約間の取引が常に可能であるとは限らない。たとえば、人員が十分に配置されたプロジェクトに資金 (および人員) を投入すると、プロジェクトの進行が遅くなる可能性がある [5]。さらに、不十分なプロジェクトでは、品質に悪影響を与えずに予算、スケジュール、または範囲を改善することはしばしば不可能である。
Project Management Triangleは、プロジェクトの分析に使用される[6]。確立された予算とスケジュールの範囲内で、妥当な品質で必要な範囲を提供することを成功と定義することは、しばしば誤用される。 [7] [8] [9]Project Management Triangleは、利害関係者への影響、 [10]学習[11]およびユーザー満足度を含む成功の重要な側面を省略しているため、プロジェクトの成功のモデルとしては不十分であると考えられてる。 [12]その後、ダイヤモンド モデル、ピラミッド モデル、6 つまたは複数の制約、および制約の理論など、基本的な三重制約のいくつかの拡張が提案された。それに応じて、プロジェクトの成功基準も 3 つから複数のパラメーターに強化された。
概要[編集]
時間的制約は、プロジェクトを完了するために利用できる時間の量を指す。コストの制約とは、プロジェクトで利用できる予算額を指す。範囲の制約は、プロジェクトの最終結果を生み出すために何をしなければならないかを示す。これら３つの制約は競合することがよくある。スコープの増加は通常、時間の増加とコストの増加を意味し、時間の制約が厳しいとコストの増加とスコープの縮小を意味し、予算の制約は時間の増加とスコープの縮小を意味する。
プロジェクト管理の規律とは、プロジェクト チーム (プロジェクト マネージャーだけでなく) がこれらの制約を満たすように作業を整理できるようにするツールと手法を提供することである。
プロジェクト管理のもう 1 つのアプローチは、資金、時間、人的資源という 3 つの制約を考慮すること。より短い時間で仕事を終わらせる必要がある場合、より多くの人を問題に投入することができ、その結果、プロジェクトのコストが上昇する。ただし、このタスクをより迅速に行うことで、プロジェクトの他の場所でのコストを同量削減する場合を除く。
プロジェクト管理のグラフィック支援として、三角形は時間、リソース、および技術目標を三角形の角ではなく側面として表示できる[13]。 アメリカン マネジメント アソシエーションの「基本的なプロジェクト管理」コースの元インストラクターであるジョン ストークは、外側の三角形と内側の三角形と呼ばれる三角形のペアを使用して、プロジェクトの意図が許可された時間内またはそれ以前に完了することであるという概念を表した。予算内または予算未満であり、必要な範囲を満たすか超えること。内側の三角形と外側の三角形の間の距離は、3 つの要素それぞれの垣根または不測の事態を示している。バイアスは距離によって示される可能性がある。時間の偏りが強いプロジェクトの彼の例は、アラスカのパイプラインであり、コストに関係なく、基本的に時間どおりに完了する必要があった。何年にもわたる開発の後、予定より 4 分以内にオイルがパイプの端から流出しました。この図では、三角形の内側の時間側が効果的に三角形の外側の線の上にありました。これは技術目標ラインにも当てはまりました。ただし、プロジェクトが予算を大幅に超過したため、トライアングル インナーのコスト ラインは範囲外であった。
James P. Lewis [14]は、プロジェクトのスコープは三角形の面積を表し、プロジェクトの成功を達成するための変数として選択できることを示唆した。彼はこの関係をPCTS (パフォーマンス、コスト、時間、スコープ) と呼び、プロジェクトは任意の 3 つを選択できると提案している。
プロジェクト トライアングルの真の価値は、どのプロジェクトにも存在する複雑さを示すことである。三角形の平面領域は、競合する 3 つの値の間に存在する可能性のある優先順位のほぼ無限のバリエーションを表す。トライアングル内で可能な無限の多様性を認めることで、このグラフィック支援を使用して、より良いプロジェクトの決定と計画を促進し、チーム メンバーとプロジェクト オーナー間の連携を確保することができる。
STRモデル[編集]
STR モデルは、「三角形モデル」を関係のグラフィック抽象化と見なす数学モデルです。
範囲とは、複雑さを指します (品質やパフォーマンスを意味することもあります)。リソースには、人 (労働者)、財務、物理が含まれます。これらの値は無制限とは見なされないことに注意してください。たとえば、オーブンの容量が限られているため、1 人のパン職人がオーブンで 1 時間で 1 斤のパンを作ることができるとしても、10 人のパン職人が同じオーブンで 1 時間で 10 斤のパンを作れるということにはなりません。
プロジェクト管理の三角形のトピック[編集]
時間[編集]
分析目的で、成果物を作成するのに必要な時間は、いくつかの手法を使用して推定されます。 1 つの方法は、作業分解構造または WBS で文書化された成果物を作成するために必要なタスクを特定することです。各タスクの作業量が見積もられ、それらの見積もりが最終的な成果物の見積もりにまとめられます。
タスクにも優先順位が付けられ、タスク間の依存関係が特定され、この情報がプロジェクト スケジュールに文書化されます。タスク間の依存関係は、リソースの可用性 (リソースの制約) と同様に、プロジェクト全体の長さに影響を与える可能性があります (依存関係の制約)。時間は、他のすべてのリソースおよびコスト カテゴリとは異なります。
現在のプロジェクトのコストを見積もるための基礎として、以前の同様のプロジェクトの実際のコストを使用します。
Project Management Body of Knowledge (PMBOK) によると、Project Time Management プロセスには次のものが含まれます。
- 計画スケジュール管理
- 活動を定義する
- シーケンス アクティビティ
- アクティビティ リソースの見積もり
- 活動期間の見積もり
- 開発スケジュール
- 制御スケジュール
活動を定義する[編集]
- 入力: 管理計画、スコープ ベースライン、企業環境要因、組織プロセス資産
- ツール: 分解、ローリング ウェーブ プランニング、専門家の判断
- 出力: 活動リスト、活動属性、マイルストーンリスト
アクティビティの順序付け[編集]
- 入力: プロジェクトスコープ ステートメント、アクティビティ リスト、アクティビティ属性、マイルストーン リスト、承認された変更要求
- ツール: Precedence Diagramming Method (PDM)、 Arrow Diagramming Method (ADM)、Schedule Network テンプレート、依存関係の縮退、リードとラグの適用
- 出力: プロジェクト スケジュール ネットワーク図、アクティビティ リストの更新、アクティビティ属性の更新、変更の要求
アクティビティ リソースの見積もり[編集]
- 入力: エンタープライズ環境ファクタリング、組織プロセス資産、活動リスト、活動属性、リソースの可用性、プロジェクト管理計画
- ツール: 専門家判断コレクション、代替分析、見積もりデータの公開、プロジェクト管理ソフトウェアの実装、ボトムアップ見積もり
- 出力: アクティビティのリソース要件、アクティビティの属性、リソースの内訳構造、リソース カレンダー、要求変更の更新。
活動期間の見積もり[編集]
- 入力: 企業環境要因、組織プロセス資産、プロジェクト範囲記述書、活動リスト、活動属性、活動リソース要件、リソース カレンダー、プロジェクト管理計画、リスク レジスター、活動コスト見積もり
- ツール：専門家判断収集、類推推定、パラメトリック推定、ボトムアップ推定、2点推定、 3点推定、リザーブ分析
- 出力: 活動所要時間の見積もり、活動属性の更新と見積もり
開発スケジュール[編集]
- 入力: 組織プロセス資産、プロジェクト スコープ ステートメント、アクティビティ リスト、アクティビティ属性、プロジェクト スケジュール ネットワーク ダイアグラム、アクティビティ リソース要件、リソース カレンダー、アクティビティ期間の見積もり、プロジェクト管理計画、リスク レジスター
- ツール: スケジュール ネットワーク分析、クリティカル パス法、スケジュール圧縮、シナリオ分析、リソースの平準化、クリティカル チェーン法、プロジェクト管理ソフトウェア、カレンダーの適用、リードとラグの調整、スケジュール モデル
- 出力: プロジェクト スケジュール、スケジュール モデル データ、スケジュール ベースライン、リソース要件の更新、アクティビティ属性、プロジェクト カレンダーの更新、要求の変更、プロジェクト管理計画の更新、スケジュール管理計画の更新
スケジュール管理[編集]
- 入力: スケジュール管理計画、スケジュール ベースライン、パフォーマンス レポート、承認された変更要求
- ツール: プログレッシブ エラボレーション レポート、スケジュール変更管理システム、パフォーマンス測定、プロジェクト管理ソフトウェア、差異、分析、スケジュール比較棒グラフ
- 出力: モデル データの更新をスケジュールし、ベースラインをスケジュールします。パフォーマンス測定、要求された変更、推奨される是正措置、組織プロセス資産、活動リストの更新、活動属性の更新、プロジェクト管理計画の更新
「時間」プロセス グループの複雑な性質により、プロジェクト管理資格PMI Scheduling Professional (PMI-SP) が作成されました。
料金[編集]
プロジェクト コストの概算を作成するには、リソース、人件費などの作業パッケージ、およびコストの差異を生み出す影響要因の軽減または制御など、いくつかの変数に依存します。コストで使用されるツールは、リスク管理、偶発コスト、コスト エスカレーション、および間接コストです。しかし、固定費と変動費に対するこの基本的な会計アプローチを超えて、考慮しなければならない経済的コストには、さまざまなプロジェクト コスト見積もりツールを使用して計算される作業員のスキルと生産性が含まれます。これは、企業が派遣社員や契約社員を雇用したり、業務を外部委託したりする場合に重要です。
原価プロセス領域[編集]
- コスト見積もりは、アクティビティを完了するために必要なすべてのリソースのコストの概算です。
- リソース、作業パッケージ、およびアクティビティの推定コストを集計して、コストのベースラインを確立するコスト予算。
- コスト管理 – コストの変動と差異を生み出す要因は、さまざまなコスト管理ツールを使用して影響を受け、制御できます。
プロジェクト管理コスト見積もりツール[15][編集]
- 類似見積もり: 類似プロジェクトのコストを使用して、現在のプロジェクトのコストを決定する
- リソース コスト レートの決定: 見積もりまたは見積もりによって収集された単位別の商品および労働のコスト。
- ボトムアップ見積もり: 最も低いレベルの作業パッケージの詳細を使用し、それに関連するコストを要約します。次に、目標とするより高いレベルにそれをロールアップし、プロジェクトの全体のコストを計算します。
- パラメトリック推定: 過去のデータと他の変数またはフローとの間の統計的関係を測定します。
- ベンダー入札分析: プロジェクトに対してベンダーが行った複数の入札の平均を取ります。
- リザーブ分析: ネットワーク パス上の各アクティビティのコストを集計し、プロジェクト マネージャーによって決定された要因によって、分析の最終結果に不測の事態またはリザーブを追加します。
- 品質分析のコスト: 各アクティビティの最高品質でのコストを見積もります。
プロジェクト管理ソフトウェアを使用して、プロジェクトのコスト差異を計算できます。
範囲[編集]
最終結果を達成するために指定された要件。プロジェクトが達成すべきことの全体的な定義と、最終結果が何を達成すべきかの具体的な説明。範囲の主要な構成要素は、最終製品の品質です。個々のタスクに費やされる時間は、プロジェクトの全体的な品質を決定します。一部のタスクは、適切に完了するのに一定の時間が必要な場合がありますが、例外的にそれ以上の時間がかかる場合があります。大規模なプロジェクトの過程で、品質は時間とコストに大きな影響を与える可能性があります (またはその逆)。
これら 3 つの制約が合わさって、「オン タイム、オン スペック、オン バジェット」というフレーズが生まれました。この場合、「範囲」という用語は「仕様」に置き換えられます。
プロジェクト制約モデルの進化[編集]
従来、プロジェクト制約モデルは 3 つの重要な制約を認識していました。 「コスト」「時間」「スコープ」。これらの制約は、これらの要因間の強い相互依存関係を示す幾何学的比率を持つ三角形を構築します。これらの要因のいずれかをシフトする必要がある場合は、他の要因の少なくとも 1 つも操作する必要があります。 [16]
トライアングル モデルが主流に受け入れられたことで、「コスト」と「時間」は一貫して表現されているように見えます。ただし、「範囲」は、三角形の図のコンテキストまたはそれぞれのプロジェクトの認識を考慮して、同じ意味で使用されることがよくあります。範囲 / 目標 / 製品 / 成果物 / 品質 / パフォーマンス / アウトプットはすべて、比較的類似した一般的なバリエーションの例ですが、上記の「人的リソース」の提案は、より専門的な解釈を提供します。
このバリエーションの広範な使用は、3 番目の制約条件のニュアンスによって運ばれる曖昧さのレベルと、もちろんトライアングル モデルの柔軟性における価値のレベルを意味します。このあいまいさにより、プロジェクトのアウトプットとプロジェクトのプロセスの間の焦点が曖昧になり、上記の例の用語は 2 つのコンテキストで異なる推進力を持つ可能性があります。 "Cost" と "Time" / "Delivery" の両方が、最上位プロジェクトの入力を表します。
「Project Diamond」モデル[17]は、「第 3 の」制約として「範囲」と「品質」を別々に含めることにより、このぼやけた焦点を生み出します。プロジェクト管理の成熟度が高まっていることを踏まえると、主要な制約要因として「品質」を追加することにはメリットがありますが、このモデルは依然としてアウトプットとプロセスの間の明確さに欠けています。ただし、ダイヤモンド モデルは、三角形の点間の強い相互関係の類推を捉えていません。
PMBOK 4.0 は、監視および管理される 6 つの要因を持つ三重制約に基づく進化したモデルを提供しました。 [18]これは、三角形の類推 (2 つの重ね合わせた三角形) の強さを維持する 6 つの尖った星として示されていると同時に、一方の三角形でプロジェクトのインプット/アウトプット要素と他方の三角形でプロジェクト プロセスの要素の間の分離と関係を表しています。スター変数は次のとおりです。
- 入出力三角形
- 範囲
- 料金
- 時間
- プロセストライアングル
- 危険
- 品質
- 資力
3 番目の制約のあいまいさと「プロジェクト ダイヤモンド」の提案を考慮すると、代わりに、プロジェクトの目標または成果物を 3 番目の制約として考慮することができます。これは、「範囲」と「品質」という下位要因で構成されます。プロジェクトのアウトプットに関しては、「範囲」と「品質」の両方を調整して、目標/製品の全体的な操作を行うことができます。この解釈には、元の三角形の入力/出力形式の 4 つの重要な要素が含まれています。これはPMBOKスターに組み込むこともでき、特に「品質」がプロジェクトのアウトプットとプロセスに関して個別に監視される可能性があることを示しています.この提案に加えて、「目標」という用語の使用は、変更イニシアチブのアウトプットを最もよく表している可能性があり、製品はより具体的なアウトプットを最もよく表している可能性があります。 [19]
プロジェクトの成功基準の進化[編集]
3 つの制約は、それ自体では不十分なプロジェクトの成功基準の最小数を表します。このように、基本的なインプット - プロセス - アウトプット チェーンである変化の理論に基づいて、プロジェクトの成功のさまざまな基準を定義および拡張するために、多くの研究が行われてきました。
Bannerman (2008) は、プロジェクトの成功の 5 つの L レベル、つまりチーム、プロジェクト管理、成果物、ビジネス、および戦略からなる、マルチレベルのプロジェクト成功フレームワークを提案しました。 [20]
UNDP は 2012 年に、インプット、プロセス、アウトプット、アウトカム、インパクトの 6 つのプロジェクト成功段階からなる成果フレームワークを提案しました。 [21]
Zidane et al (2016) は、結果フレームワークを PESTOL フレームワークに拡張して、プロジェクトの成功を計画および評価し、効率と有効性の観点から各プロジェクトに費やされた「費用対効果」を評価するために使用できます。 [22]
したがって、3 つの制約は、プロジェクトの成功を可能な限り全体的に計画および評価するためのさまざまなフレームワークに発展してきました。
関連項目[編集]
参考文献[編集]
- ↑ Atkinson, Roger (December 1999). “Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria”. International Journal of Project Management 17 (6): 337–342. doi:10.1016/S0263-7863(98)00069-6.
- ↑ Wyngaard, Charles Van (2012). “Theory of the Triple Constraint – a Conceptual Review”. 2012 IEEE International Conference on Industrial Engineering and Engineering Management: 1991–1997. doi:10.1109/IEEM.2012.6838095. モジュール:Citation/CS1/styles.cssページに内容がありません。ISBN 978-1-4673-2945-3.
- ↑ “The project triangle”. 20220816閲覧。
- ↑ “プロジェクトの三角形”. 20220817閲覧。
- ↑ Brooks, Frederick (1995). The mythical man-month (Anniversary ed.). Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.. モジュール:Citation/CS1/styles.cssページに内容がありません。ISBN 0-201-83595-9
- ↑ Erik Bethke (2003). Game Development and Production. p.65.
- ↑ Michael W. Newell, Marina N. Grashina (2004). The Project Management Question and Answer Book. p.8
- ↑ Pamela McGhee, Peter McAliney (2007). Painless Project Management. p.74.
- ↑ Michael Gentile, Ronald D. Collette, Thomas D. August (2005). The CISO Handbook. p.172
- ↑ Ralph, Paul; Kelly, Paul (2014). “The Dimensions of Software Engineering Success”. Proceedings of the 36th International Conference on Software Engineering (ACM): 24–35. doi:10.1145/2568225.2568261. モジュール:Citation/CS1/styles.cssページに内容がありません。ISBN 9781450327565.
- ↑ Shenhar, A.; Dvir, Dov (1997). “Mapping the dimensions of project success”. Project Management Journal 28 (2): 5–13.
- ↑ Delone, William H.; McLean, Ephraim R. (1 April 2003). “The DeLone and McLean Model of Information Systems Success: A Ten-Year Update”. Journal of Management Information Systems 19 (4): 9–30. doi:10.1080/07421222.2003.11045748. モジュール:Citation/CS1/styles.cssページに内容がありません。ISSN 0742-1222.
- ↑ Carl S. Chatfield, Timothy D. Johnson (2003). Microsoft Office Project 2003 Step by Step: Step by Step. P. 476
- ↑ Lewis, James P. (2005). Project Planning, Scheduling & Control, 4E. McGraw Hill. モジュール:Citation/CS1/styles.cssページに内容がありません。ISBN 978-0-07-146037-8
- ↑ PMBOK Third Edition 2004 p.165
- ↑ (Chatfield, Carl. “A short course in project management”. Microsoft)
- ↑ (Brown, Craig. “It used to be the Iron Triangle”. Better Project)
- ↑ Project Management Institute (2009) A Guide to the Project Management Body of Knowledge: PMBOK Guide. Chapter 1
- ↑ Brem (2011) T214 Understanding Complex Systems – TMA02. Q4
- ↑ Bannerman (2008) https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
- ↑ UNDP (2012) Overview of the development results framework
- ↑ Zidane (2016) https://www.researchgate.net/publication/308727415_PESTOL_-_Framework_for_Project_Evaluation_on_Strategic_Tactical_and_Operational_Levels
外部リンク[編集]
ウィキメディア・コモンズには、プロジェクト管理の三角形に関するカテゴリがあります。
This article "プロジェクト管理の三角形" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:プロジェクト管理の三角形.
