Loading article…
プロジェクト管理 において、不確実性のコーンは、プロジェクト中の最良ケースの不確実性の量の推移を表します。[ 1 ]プロジェクトの開始時には、製品や作業結果について比較的ほとんど知られていないため、見積もりには大きな不確実性が伴います。研究開発が進むにつれて、プロジェクトに関する情報が増え、不確実性は減少する傾向があり、すべての残存リスクが解消または移転されると、不確実性は0%に達します。これは通常、プロジェクトの終了時、つまり責任を別の保守グループに移管することによって起こります。
不確実性の円錐という用語は、技術的およびビジネス環境が非常に急速に変化するソフトウェア開発で使用されます。しかし、この概念は、異なる名称で呼ばれることもありますが、コストエンジニアリングの確立された基本原則です。ほとんどの環境は変化が非常に遅いため、典型的なプロジェクトの期間中は静的であると考えることができ、そのため従来のプロジェクト管理手法は、綿密な分析と計画を通じて環境を完全に理解することに重点を置いています。重要な投資が行われるずっと前に、不確実性はリスクを快適に負えるレベルまで低減されます。このような環境では、不確実性のレベルは初期段階で急速に低下し、円錐の形状はあまり明確ではありません。しかし、ソフトウェアビジネスは非常に変動が激しく、時間の経過とともに不確実性のレベルを低下させる外部圧力があります。プロジェクトは、不確実性のレベルを低下させるために、積極的かつ継続的に取り組む必要があります。
不確実性の範囲は、調査と、プロジェクトから変動要因を取り除く決定によって狭められます。これらの決定は、プロジェクトの範囲、つまりプロジェクトに何を含めるか、何を含めないかに関するものです。プロジェクトの後半でこれらの決定が変更されると、不確実性の範囲は広がります。
化学産業のエンジニアリングおよび建設に関する当初の研究では、実際の最終コストが最初の「基本」見積もりを最大 100% 上回る（または最大 50% 下回る）ことがよくあることが示されました[ 2 ] 。ソフトウェア業界の不確実性のコーンに関する研究では、プロジェクトライフサイクルの初期(つまり、要件収集前) では、見積もりは一般的に、高値側と低値側の両方で係数 4 の不確実性があると述べています。[ 3 ]これは、実際の作業または範囲が最初の見積もりの 4 倍または 1/4 になる可能性があることを意味します。この不確実性はプロジェクトの進行中に減少する傾向がありますが、その減少は保証されていません。[ 4 ]
プロジェクトの見積もりにおける不確実性の範囲を考慮する一つの方法は、まず「最も可能性の高い」単一点見積もりを決定し、次に（その時点での不確実性のレベルに応じて）事前に定義された乗数を使用して高低範囲を計算することです。これは、スプレッドシートに数式を適用することで実現できます。あるいは、タスクの担当者が低/高範囲の見積もりを入力すると、その不確実性のレベルを考慮したスケジュールを作成してくれるプロジェクト管理ツールを使用することで実現できます。
不確実性の円錐は、ハリケーン予報の図としても広く使用されており、最も象徴的な使用法は、より正式にはNHCトラック予報円錐[ 5 ]として知られ、より口語的には誤差円錐、確率円錐、または死の円錐として知られています。（ハリケーン予報での使用法は、ソフトウェア開発での使用法とは基本的に逆であることに注意してください。ソフトウェア開発では、不確実性はプロジェクトの現在の状態を取り巻いており、将来的に不確実性は減少しますが、ハリケーン予報では、嵐の現在の位置は確実であり、嵐の将来の進路はますます不確実になります）。[ 6 ]過去 10 年間、嵐は予測された範囲内を 3 分の 2 の時間通過しており[ 7 ]、方法論の改善により円錐自体も縮小しています。 NHCは2001年に初めて内部で5日間の予測を開始し、2003年に一般に公開し始めた。現在、内部で7日間の予測に取り組んでいるが、結果として生じる不確実性の範囲が非常に大きいため、災害管理における潜在的な利点は問題となっている。[ 8 ]
不確実性の円錐の概念の基礎は、米国コストエンジニア協会（現在のAACE International）の創設者によって化学産業のエンジニアリングと建設のために開発されました。彼らは1958年に不確実性の範囲を含む標準見積もりタイプの分類システム案を発表し[ 9 ]、当時業界文献で「円錐」の図を示しました[ 2 ] 。ソフトウェア分野では、この概念はバリー・ボームによって取り上げられました[ 10 ] 。ボームはこの概念を「漏斗曲線」と呼びました[ 11 ] 。ボームによる漏斗曲線の影響の最初の定量化は主観的なものでした[ 10 ] 。ボームとUSCの同僚による後の研究では、米国空軍やその他の情報源からのソフトウェアプロジェクトのデータを使用してモデルを検証しました。基本モデルは、NASAのソフトウェアエンジニアリングラボでの研究に基づいてさらに検証されました[ 12 ] [ 13 ]。
この概念を説明するために「不確実性の円錐」という名前が初めて使用されたのは、『ソフトウェアプロジェクトサバイバルガイド』でした。[ 14 ]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)