カーネギーメロン大学 ソフトウェア工学研究所 ソフトウェアコストの見積もりが時間とともに変化する理由と、DevSecOpsデータがコストリスクの低減に役立つ方法

こんにちは、丸山満彦です。

システム開発に不確実性はつきもので、それをうまくコントロールすることで、システム開発プログラムは成功したり、失敗したりするわけですが、、、

まずは、不確実性が伴うものですよ。。。というのは、すべての利害関係者が理解しておくべきことで、それがどの程度あるのか、というのをタイムリーに共有しておくことがいろいろなトラブルを防ぐ上でも重要なのでしょうね。。。

とはいえ、いろいろと背景を背負っているので、頭の中ではわかっていても、言葉や文字に落とせないこともあり、そういうことがトラブルの原因となっているのでしょうね。。。しらんけど。。。

カーネギーメロン大学のソフトウェア工学研究所に次の文書は興味深いですね。。。

● Carnegie Mellon University - Software Engineering Institute

・ 2023.09.21 Why Your Software Cost Estimates Change Over Time and How DevSecOps Data Can Help Reduce Cost Risk

・[PDF]

Introduction	序文
Program managers (PMs) must realize that early estimates are likely to be off by over 40 percent and that programs need to continually update estimates as additional information becomes available. It is important to understand how program risks can impact cost estimates. Tracking items—such as the decisions that have not yet been made, stability of the top capabilities needed, and measurements derived from the DevSecOps pipeline—can all help program management offices (PMOs) better understand program uncertainties that can impact estimates and help increase confidence in estimates over time.	プログラムマネージャ(PM)は、初期の見積もりは40%以上外れる可能性があり、追加情報が入手可能になるにつれて、プログラムは継続的に見積もりを更新する必要があることを認識しなければならない。プログラムのリスクがコスト見積もりにどのような影響を与えるかを理解することが重要である。まだ決定されていない事項、必要とされる上位の能力の安定性、DevSecOpsパイプラインから得られる測定値などの追跡項目はすべて、プログラム管理オフィス（PMO）が見積もりに影響を与える可能性のあるプログラムの不確実性をよりよく理解し、時間の経過とともに見積もりの信頼性を高めるのに役立つ。
DoD Program Estimation Background	国防総省のプログラム見積もりの背景
Department of Defense (DoD) programs are required to perform cost analyses at various stages of the program lifecycle. For Acquisition Category I (ACAT I) programs, an independent cost estimate is required for each milestone review. These estimates must be approved by the director, Cost Assessment and Program Evaluation (DCAPE), and their fidelity should increase at each successive review as program uncertainties resolve over time. New uncertainties may unfold as the program progresses, but in general, overall uncertainty should progressively be reduced.	国防総省（DoD）のプログラムでは、プログラムライフサイクルの様々な段階でコスト分析を行うことが求められている。取得カテゴリーI（ACAT I）プログラムでは、各マイルストーンのレビューにおいて、独立したコスト見積りが要求される。これらの見積もりは、DCAPE（Cost Assessment and Program Evaluation：コスト評価・プログラム評価）ディレクターの承認を得なければならない。プログラムの進行に伴い、新たな不確実性が発生する可能性はあるが、 一般的には、全体的な不確実性は徐々に低減していくはずである。
When discussing software cost estimates, it is important to remember this quote by Steve McConnell: “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.” A project should not be a “random walk;” instead, it should be a walk with a sequence of course corrections. A sound estimate assures that the outcome is achievable with the available time and resources.	ソフトウエアのコスト見積もりについて議論するとき、スティーブ・マッコー ネル（Steve McConnell）の次の言葉を思い出すことが重要である。"ソフトウ ェア見積もりの主な目的は、プロジェクトの結果を予測することではない。プロジェクトは "ランダムウォーク "であってはならない。健全な見積もりは、結果が利用可能な時間と資源で達成可能であることを保証する。
The cost estimation process typically starts during an analysis of alternatives (AoA), which is performed during the Materiel Solution Analysis phase leading up to Milestone A. An AoA includes a lifecycle cost baseline for each alternative, the lifecycle cost per unit system, and the lifecycle cost per specified quantity of systems. The AoA is typically performed under contract. The program office typically has a cost section staffed by a combination of military, civilian, and contactors. The program office is ultimately responsible for the program office estimate (POE).	AoAには、各代替案のライフサイクルコスト・ベースライン、単位システム当たりのライフサイクルコスト、特定数量のシステム当たりのライフサイクルコストが含まれる。AoA は通常、契約に基づいて実施される。プログラムオフィスには、通常、軍、民間、コンタクターが組み合わされたコストセクションがある。プログラム事務局は、プログラム事務局見積もり（POE）の最終責任を負う。
Design: REV-03.18.2016.0 | Template: 01.26.2023	設計を行う： REV-03.18.2016.0 | テンプレート 01.26.2023
Typically, multiple contractors submit proposals for the Technology Maturation and Risk Reduction phase. Estimates derived from these proposals are often used to further refine the POE.	通常、複数の契約者が技術熟成とリスク低減フェーズに提案書を提出する。これらの提案から得られた見積もりは、POEをさらに精緻化するために使用されることが多い。
All the POEs should follow the guidance from the DoD Cost Estimation Guide  [DoD 2020]. This guide calls for the estimation to account for risk:	すべての POE は、国防総省コスト見積もりガイド［DoD 2020］のガイダンスに従うべきである。このガイドでは、リスクを考慮した見積りを行うよう求めている：
A risk is a potential future event or condition that may have a negative effect on cost, schedule, and/or performance. An opportunity is a potential future event or condition that may have a positive effect on cost, schedule, and/or performance. Risk/opportunities have three characteristics: a triggering event or condition, the probability that event or condition will occur, and the consequence of the event or condition should it occur. Analysts often use the terms risk and uncertainty interchangeably. In fact, they are distinct from one another. Uncertainty is the indefiniteness of the outcome of a situation. Uncertainty captures the entire range of possible positive and negative outcomes associated with a given value or calculated result. In a cost estimating model, an analyst generally addresses uncertainty first. The analyst then addresses risks/opportunities if and only if the uncertainty assessment has not already captured them.	リスクとは、コスト、スケジュール、および／またはパフォーマンスに悪影響を及ぼす可能性のある、将来の潜在的な事象または状態のことである。リスクとは、コスト、スケジュール及び／又はパフォーマンスにマイナスの影響を及ぼす可能性のある潜在的な将来の事象又は状態である。リスク／機会には3つの特徴がある：引き金となる事象や条件、その事象や条件が発生する確率、万が一発生した場合の結果である。アナリストは、リスクと不確実性という用語をしばしば同じ意味で使用する。実際には、両者は別物である。不確実性とは、ある状況の結果が確定できないことである。不確実性は、所与の値や計算結果に関連する正負の結果の可能性の全範囲を捉える。コスト見積もりモデルでは、分析者は一般的にまず不確実性に対処する。次に、不確実性アセスメントがまだリスク／機会を捕捉していない場合にのみ、リスク／機会に対処する。
Another way to look at risk in cost estimates and the changes in estimates as a program progresses is using a framework called the Cone of Uncertainty. The first use of the actual term Cone of	コスト見積りにおけるリスクと、プログラムの進行に 伴う見積りの変化を見るもう一つの方法は、不確実性コーン と呼ばれるフレームワークを使用することである。コーン・オブ・アン ケラティという実際の用語が初めて使用されたのは、ソフ トウェアの開発者であった。
Uncertainty for software was by Steve McConnell is his book, Software Project Survival Guide [McConnell 1997]. Chris Adams provides a good summary of this concept on the web [Adams 2023]; we discuss this concept in the next section.	Uncertainty (不確実性コーン)という実際の用語をソフトウェアに初めて使用したのは、スティーブ・マコーネル(Steve McConnell)の著書「ソフトウェア・プロジェクト・サバイバル・ガイド」[McConnell 1997]である。クリス・アダムスは、ウェブ上でこの概念の良い要約を提供している[Adams 2023]。
The Cone of Uncertainty Background	不確実性コーンの背景
The Cone of Uncertainty is a term often used in project management that describes the phenomenon by which project unknowns decrease over time. The Cone of Uncertainty framework is used in software estimation to determine the most likely outcome; Chris Adams describes it as follows [Adams 2023]:	不確実性コーンとは、プロジェクトマネジメントでよく使われる用語で、プロジェクトの未知数が時間とともに減少する現象を表す。不確実性コーンのフレームワークは、最も可能性の高い結果を決定するためにソフトウェアの見積もりで使用される。Chris Adamsはそれを次のように説明している[Adams 2023]：
As the project proceeds and more research and development is completed the amount of uncertainty decreases, eventually approaching zero. Project unknowns, or uncertainty, largely correlate to variances in project estimates.  Plotting these variances over time creates a cone or funnel shape (variance percentages shown are only examples, values may vary).	プロジェクトが進行し、より多くの研究開発が完了するにつれて、不確実性の量は減少し、最終的にはゼロに近づく。プロジェクトの未知数、つまり不確実性は、プロジェクトの見積もりにおける差異と大きく相関している。 これらのばらつきを経時的にプロットすると、円錐形または漏斗形になる（示されているばらつきのパーセンテージはあくまで例であり、値は異なる場合がある）。
Figure: Cone of Uncertainty (This file is made available under the Creative Commons CC0 1.0 Universal Public Domain Dedication File:Cone of Uncertainty.jpg - Wikimedia Commons)	図： 不確実性コーン形（このファイルは、クリエイティブ・コモンズ CC0 1.0 Universal Public Domain Dedication File:Cone of Uncertainty.jpg - Wikimedia Commonsの下で利用可能である。）
The Cone of Uncertainty and Iterative Development	不確実性コーンと反復開発
Applying the Cone of Uncertainty to iterative projects is somewhat more involved than applying it to sequential projects.	不確実性コーン」を反復プロジェクトに適用するのは、逐次プロジェクトに適用するよりもやや複雑である。
If you are working on a project that completes a full development cycle in each iteration (i.e., requirements definition through release), then you will go through a miniature cone during each iteration. Before you do the requirements work for the iteration, you will be at the Approved Product Definition part of the cone, which is subject to 4x the variability from high to low estimates.	各反復（すなわち、要件定義からリリースまで）で完全な開発サイクルを完了するプロジェクトに取り組んでいる場合、各反復の間にミニチュアコーンを通過することになる。イテレーションの要件作業を行う前に、あなたは円錐の承認済み製品定義の部分にいることになり、この部分は、高い見積もりから低い見積もりまで、4倍の変動の影響を受ける。
In short iterations (less than a month), you can move from Approved Product Definition to Requirements Complete and User Interface Design Complete in a few days, which reduces your variability from 4x to 1.6x. If your schedule is fixed, the 1.6x variability applies to the specific features you can deliver in the time available rather than to the effort or schedule.	短いイテレーション（1ヶ月未満）では、数日で承認済み製品定義から要件完了とユーザーインターフェイス設計完了に移行できるため、変動は4倍から1.6倍に減少する。スケジュールが固定されている場合、1.6倍の変動は、労力やスケジュールではなく、利用可能な時間で提供できる特定の機能に適用される。
Although there are many uncertainties that affect predictability, requirements flow down to design and implementation decisions. Approaches that delay a full requirements specification until the beginning of each iteration also delay narrowing the cone of uncertainty—with respect to cost, schedule, and feature delivery—several iterations down the road. It is difficult, after all, to know when your project will be done if you do not at least specify what done looks like. Your program might highly prioritize flexibility, or it might prefer projects with more predictability.	予測可能性に影響する不確定要素はたくさんあるが、要件は設計と実装の決定に流れ込む。各反復の開始まで完全な要求仕様を遅らせるアプローチは、コスト、スケジュール、および機能の提供に関して、不確実性コーンを数回先の反復まで狭めることも遅らせる。結局のところ、少なくとも完了がどのようなものかを特定しなければ、プロジェクトがいつ完了するかを知ることは難しい。あなたのプログラムは、柔軟性を非常に優先するかもしれないし、より予測可能なプロジェクトを好むかもしれない。
Many development teams settle on a middle ground between flexibility and predictability in which a majority of requirements are defined at the front end of the project, but design, construction, test, and release are performed in short iterations. In other words, the project moves sequentially through the User Interface Design Complete milestone about 30% of the calendar time into the project, and then shifts to a more iterative approach from that point forward. This approach drives down the variability from the cone to about ±25 percent, which allows for project control that is good enough to hit targets while still tapping into the major benefits of iterative development.	多くの開発チームは、柔軟性と予測可能性の中間点に落ち着き、プロジェクトのフロントエンドで要件の大部分を定義するが、設計、構築、テスト、リリースは短いイテレーションで実行する。言い換えれば、プロジェクトは、ユーザーインターフェイス設計完了のマイルストーンを、プロジェクト開始の約30％のカレンダータイムで順次通過し、その時点から、より反復的なアプローチに移行する。このアプローチでは、コーンからの変動幅を±25％程度に抑えることができ、反復型開発の主なメリットを活用しながらも、目標を達成するのに十分なプロジェクトコントロールが可能になる。
Project teams can leave some amount of planned time for as-yet-to-be-determined requirements at the end of the project. Doing that introduces some minor variability related to the feature set, which, in this case, is positive variability because you will exercise it only if you identify new desirable features to implement. This middle ground supports long-range predictability of cost and schedule as well as a moderate amount of requirements flexibility [Construx 2023]. Even when using this method, unless there is a large user-driven change in the capability needed for the project, the requirements volatility should decrease over time.	プロジェクトチームは、プロジェクトの最後に、まだ決定していない要件のために、ある程度の計画時間を残すことができる。そうすることで、機能セットに関する若干の変動性が生じるが、この場合は、実装すべき新しい望ましい機能を特定した場合にのみ行使することになるので、プラスの変動性である。この中間領域は、コストとスケジュールの長期的な予測可能性と、要件の適度な柔軟性をサポートする[Construx 2023]。この方法を使用する場合でも、プロジェクトに必要な能力にユーザー主導の大きな変更がない限り、要件の変動性は時間の経過とともに減少するはずである。
Risk and Uncertainty	リスクと不確実性
Glen Alleman stated the following about uncertainty [Alleman 2018]:	グレン・アレマンは不確実性について次のように述べている[Alleman 2018]：
Uncertainty comes from the lack information to describe a current state or to predict future states, preferred outcomes, or the actions needed to achieve them. This uncertainty can originate from random naturally occurring processes of the program (Aleatory Uncertainty). Or it can originate from the lack of knowledge about the range of future outcomes from the work on the program (Epistemic Uncertainty).	不確実性は、現在の状態を説明したり、将来の状態、望ましい結果、またはそれらを達成するために必要な行動を予測したりするための情報が不足していることから生じる。この不確実性は、プログラムで自然に発生するランダムなプロセス（Aleatory Uncertainty）に由来することがある。あるいは、プログラムの作業から得られる将来の結果の範囲に関する知識の欠如に起因することもある（認識論的不確実性）。
Aleatory uncertainty can be thought of as common cause variation that is natural to the system. Epistemic uncertainty results from an incomplete understanding or characterization (e.g., a lack of understanding the range of natural variation or incomplete requirements). Finally, ontological uncertainty can be thought of as unknown-unknowns. Whereas epistemic uncertainty represents an incomplete understanding of something we know of, an ontological uncertainty appears as a complete surprise. Ontological uncertainty is often a form of special cause variation that was not anticipated or precedented.	Aleatory Unertaintyは、システムにとって自然な共通の原因による変動と考えることができる。認識論的不確実性は、不完全な理解や特徴付け（例えば、自然変動の範囲や不完全な要件の理解不足）から生じる。最後に、存在論的不確実性は、未知の未知と考えることができる。認識論的不確実性が、我々が知っている何かについての不完全な理解を代表するのに対して、存在論的不確実性は、完全な驚きとして現れる。存在論的不確実性は、多くの場合、予期されていなかったり先行していなかったりする特別な原因による変動である。
Common cause variation cannot be specifically reduced through management action; instead, it requires technical change. However, in Agile development, several approaches are commonly used to reduce epistemic uncertainty (incomplete knowledge). Frequent increments and product demonstrations allow feedback from both the users and the development process. Feedback with an incomplete product allows unforeseen uses, requirements, or component interactions to be discovered. Development spikes are designed to uncover information (e.g., about performance).	一般的な原因によるばらつきは、マネジメントの行動によって特に減らすことはできない。しかし、アジャイル開発では、認識論的不確実性（不完全な知識）を低減するために、いくつかのアプローチが一般的に使用される。頻繁なインクリメントと製品のデモンストレーションは、ユーザーと開発プロセスの両方からのフィードバックを可能にする。不完全な製品でのフィードバックにより、予期しない用途、要件、またはコンポーネントの相互作用が発見される。開発スパイクは、情報（性能など）を発見するために設計される。
Sequencing work such that important but uncertain features and capabilities start earlier, not only enables using what was learned in refining and developing those capabilities to “buy down” overall uncertainty, but it also reduces the remaining uncertainty later in the program when there is less opportunity to recover. Taking any or all of these actions early in a program can help improve the accuracy of the overall cost estimate and reduce risk exposure.	重要だが不確実な機能や能力をより早い段階から開始するような作業の順序を決めることで、それらの能力を洗練し開発する際に学んだことを使用して、全体的な不確実性を「買い取る」ことができるだけでなく、回復する機会が少ないプログラムの後半に残る不確実性を低減することもできる。プログラムの初期段階で、これらの措置のいずれか、またはす べてを講じることは、全体的なコスト見積もりの精度を改善し、リ スクエクスポージャーを低減するのに役立つ。
The level of risk and cost estimation uncertainty can also be viewed from the perspective of the lifecycle phases of a system’s development. Even in agile development, it is important to understand the top-level capabilities needed at the start of the program. In the Software Acquisition Pathway, these are described in a capability needs statement [DAU 2023]. These capabilities may change based on operational needs, but requirements changes may increase risk and can lead to increased cost if other capabilities are not swapped out.	リスクとコスト見積もりの不確実性のレベルは、システム開 発のライフサイクルフェーズの観点から見ることもできる。アジャイル開発においても、プログラム開始時に必要とされるトップレベルの能力を理解することが重要である。ソフトウェア取得経路では、これらは能力ニーズ記述書[DAU 2023]に記述される。これらの能力は運用上のニーズに基づいて変更される可能性があるが、要件の変更はリスクを増大させる可能性があり、他の能力を入れ替えなければコスト増につながる可能性がある。
Another important aspect to consider for reducing risk is to focus on the architecture early in the program. Ensuring the architecture is suitable for both the functional and non-functional requirements can help ensure that large-scale architecture changes will not be required later in the program. A facet of DevSecOps that can reduce risk is early integration and automated testing. The earlier you start integrating and testing code, the sooner any issues or defects can be found. This approach can also reduce overall risks and increase the confidence in cost estimates.	リスクを低減するために考慮すべきもう一つの重要な点は、プログラムの早い段階でアーキテクチャーに焦点を当てることである。アーキテクチャーが機能要件と非機能要件の両方に適していることを確認することで、プログラムの後半で大規模なアーキテクチャー変更が必要にならないようにすることができる。リスクを低減できるDevSecOpsの一面は、早期の統合と自動テストである。コードの統合とテストの開始が早ければ早いほど、問題や不具合を早期に発見することができる。このアプローチは、全体的なリスクを低減し、コスト見積もりの信頼性を高めることもできる。
Some areas to consider when determining your estimation uncertainty include	見積もりの不確実性を判断する際に考慮すべき領域には、次のようなものがある。
1. the decisions that have been made (e.g., reuse, computer languages, architecture)	1. 決定したこと（再利用、コンピュータ言語、アーキテクチャなど）。
2. what has been discovered (i.e., known unknowns and unknown unknowns)	2. 発見されたこと（すなわち、既知の未知と未知の未知）。
3. the overall scope and amount of requirements growth	3. 要件の全体的な範囲と増加量
4. what can be measured to help understand how much uncertainty remains	4. 不確実性がどの程度残っているかを理解するために測定できるもの
How Metrics from DevSecOps Pipeline Data Can Help Reduce Estimation Risk	DevSecOpsのパイプラインデータから得られるメトリクスは、見積もりリスクの低減にどのように役立つか
Metrics can help the program management team better understand and estimate program status and risks. Although measurement does not by itself reduce risk, measurement informs decisions that can reduce risk. Some metrics can originate from contract data requirements list (CDRL) deliveries, such as an earned value management (EVM) report or a metrics report. CDRLs typically provide data from the last one or two months. In modern software development, data obtained from the DevSecOps environment can provide real-time, helpful information.	メトリクスは、プログラムマネジメントチームがプログラムのステータスとリスクをよりよく理解し、見積もるのに役立つ。測定自体がリスクを低減するわけではないが、測定はリスクを低減する意思決定に役立つ。メトリクスの中には、アーンド・バリュー・マネジメント（EVM）レポートやメトリックス・レポートなど、契約データ要件リスト（CDRL）から得られるものもある。CDRLは通常、直近1～2ヶ月のデータを提供する。最新のソフトウェア開発では、DevSecOps環境から得られるデータは、リアルタイムの有益な情報を提供することができる。
A few metrics you can obtain through the pipeline to better understand and reduce estimation uncertainty include the following:	見積もりの不確実性をよりよく理解し、低減するために、パイプラインを通じて取得できるメトリクスには、次のようなものがある：
1. Completion Rate Volatility: An example of measuring completion rate volatility is measuring changes in sprint velocity to detect uncertainty. If teams properly estimate their sprint velocity and consistently work at the estimated rate, then overall uncertainty can be reduced because you have more confidence that the epistemic uncertainty has been quantified as a common cause variation and special cause (ontological uncertainty) variations can be identified and addressed. Likewise, teams that start with “low hanging fruit” may gain a false sense of confidence unless they recognize that completion rates closely match the actual progress for easier tasks.	1. 完了率のボラティリティ： 完了率のボラティリティを測定する例として、スプリント・ベロシティの変化を測定して不確実性を検知する方法がある。チームがスプリントベロシティを適切に見積もり、一貫して見積もりレートで作業していれば、認識的不確実性が共通原因の変動として定量化され、特別な原因（識別的不確実性）の変動を特定して対処できるという確信が持てるため、全体的な不確実性を低減できる。同様に、「低くぶら下がった果実」から始めるチームは、完了率がより簡単なタスクの実際の進捗と密接に一致していることを認識しない限り、誤った自信感を得る可能性がある。
2. Capability Development Progress: Your pipeline can provide data on how many capabilities are fully developed, how many are in progress, and how many remain in the backlog. When working in program increments, it is possible for capabilities to remain incomplete and for predecessors to create dependencies in other areas. Understanding how capability development compares to the plan can help reprioritize work so that key capabilities reach completion. This approach can also help you better understand what uncertainty may remain in your estimates.	2. 能力開発の進捗： パイプラインは、いくつの能力が完全に開発され、いくつの能力が進行中で、いくつの能力がバックログに残っているかについてのデータを提供することができる。プログラムインクリメントで作業する場合、ケイパビリティが未完成のままであったり、前任者が他の領域で依存関係を作成したりする可能性がある。ケイパビリティの開発が計画と比較してどうなっているかを理解することは、重要なケイパビリティが完成に達するように作業の優先順位をつけ直すのに役立つ。また、このアプローチは、見積もりにどのような不確実性が残っているかをよりよく理解するのにも役立つ。
3. Software Quality: Your DevSecOps pipeline should include static and dynamic code scanning tools. These tools, along with counts of defects discovered during testing, allow the PMO to better understand aspects of quality that can cause (1) delays in testing, (2) rework, or (3) operational failures. Good quality software not only requires less time to correct errors rather than produce a new product, but it also increases confidence in the estimates’ accuracy and precision.	3. ソフトウェアの品質： DevSecOpsパイプラインには、静的および動的コードスキャンツールを含めるべきである。これらのツールは、テスト中に発見された不具合の数とともに、PMOが(1)テストの遅延、(2)手戻り、(3)運用上の不具合の原因となる品質の側面をよりよく理解することを可能にする。良質なソフトウエアは、新しい製品を生産するよりも、エラーを修正する時間の方が短いだけでなく、見積もりの正確さと精度の信頼性を高める。
4. User Acceptance: One of the main tenets of agile development is user involvement. If users are regularly involved in end-of-sprint and/or end-of-increment demonstrations, then the PMO can gain an early understanding of how users are reacting to the capabilities being developed. If the user reaction is positive and the number of changes requested is in line with the estimated work, then this can also increase confidence in the initial estimate. On the other hand, unplanned rework can result in additional costs and delays, unless other work is removed to allow the new work requested by the user to take priority within the schedule and budget.	4. ユーザー受容： アジャイル開発の主な考え方の1つは、ユーザーの参加である。ユーザが定期的にスプリント終了時やインプリメント終了時のデモに参加すれば、PMOは開発中の機能に対するユーザの反応を早期に理解することができる。ユーザーの反応が肯定的で、要求された変更の数が見積もり作業と一致している場合、これは初期見積もりの信頼性を高めることにもなる。一方、ユーザーから要求された新しい作業がスケジュールと予算内で優先されるように、他の作業が削除されない限り、計画外の手戻りは追加コストと遅延をもたらす可能性がある。
5. Organization and Staffing: Using data from tools such as Confluence and Jira, a PMO should be able to see the development organizational structure and the number of people on each team to help understand if the project is fully staffed. Changes can also be tracked to understand staffing volatility. Staffing volatility, in turn, leads to a need to recalibrate team velocity estimates, thus increasing uncertainty until new baseline data is available. If the project is fully staffed with an organizational structure that supports it, then this can reduce estimation risks. If the project is slow to staff up or never reaches the full staffing profile, the estimate must be adjusted to reflect this.	5. 組織と人員配置： ConfluenceやJiraのようなツールのデータを使って、PMOは開発組織構造と各チームの人数を見ることができ、プロジェクトに十分な人員が配置されているかどうかを理解することができる。また、変更を追跡することで、人員配置の変動を把握することもできる。人員配置の変動は、チームベロシティの見積もりを再調整する必要性につながり、新しいベースラインデータが利用可能になるまで、不確実性を増大させる。もし、プロジェクトに十分な人員が配置され、それをサポートする組織体制が整っていれば、見積もりリスクを低減することができる。もし、プロジェクトの人員配置が遅かったり、完全な人員配置に達しなかったりする場合は、それを反映するように見積もりを調整しなければならない。
More information about using data from the DevSecOps pipeline is available in the white paper Program Managers—The DevSecOps Pipeline Can Provide Actionable Data [Cohen 2023].	DevSecOpsパイプラインからのデータの使用に関する詳細は、ホワイトペーパー「Program Managers-The DevSecOps Pipeline Can Provide Actionable Data」[Cohen 2023]に掲載されている。
The Bottom Line	結論
The primary takeaway from this paper is that early estimates are likely to be off by over 40 percent, and programs need to continually update estimates as additional information is available. Tracking items, such as what decisions have not yet been made, the stability of the top capabilities needed, and measurements derived from the DevSecOps pipeline, can all help the PMO better understand program uncertainties that impact estimates and help increase the confidence in estimates over time.	この論文から得られる主な教訓は、初期の見積もりは40%以上外れる可能性が高く、プログラムは追加情報が入手可能になるにつれて継続的に見積もりを更新する必要があるということである。どのような決定がまだなされていないか、必要とされる上位の能力の安定性、DevSecOpsパイプラインから得られる測定値などの項目を追跡することは、PMOが見積もりに影響を与えるプログラムの不確実性をよりよく理解し、時間の経過とともに見積もりの信頼性を高めるのに役立つ。