はじめに

不確実性の多いソフトウェアプロジェクトでは、単純な「いつ終わる？」ではなく、「どの確率でいつ終わる？」という問いが鍵になります。この記事では、確率分布を用いて納期予測の難しさや不確実性を捉え直し、スコープクリープやベロシティ安定化の重要性を考察します。

また、スクラムのようなフレームワークを採用したチームにおいて、モンテカルロシミュレーションを用いて終了確率を予想するWeb上で使えるツールを開発し、誰もが使える形で公開しました。

これらを用いて、単なる点の見積もりから一歩進んだ、現実的かつリスクを見据えたビジネス上のコミュニケーションを可能にする一助になればと考えています。

プロジェクト見積もりを確率分布で考える重要性

一般的なソフトウェアプロジェクトでは、納期は「○月○日までに完了する」という確定的な日付で示されることが多くあります。しかし、実際のプロジェクト運営では、要件変更・技術的難易度の上昇・チームメンバーの体調不良など、想定外の事象が発生することは決して珍しくありません。こうした不確実性を無視して単一の期日を提示してしまうと、計画と実績の乖離が生じ、結果として大幅な遅延やビジネスコストが発生するリスクが高まります。

このような課題に対処するためには、プロジェクトの「完了時期」を確定的な値ではなく、“確率分布”としてとらえる考え方が有効です。プロジェクト見積もりを確率分布で表すことで、たとえば「50％の確率で○月○日までに完了できる」「80％の確率で○月○日までに終えられる」といった形で、リスクと不確実性を計画段階から明示的に織り込むことが可能となります。これは言い換えれば、「終わるか終わらないか」ではなく、「いつまでにどれだけの確率で終わるか」という、より柔軟で現実に即したアプローチです。

さらに、この確率分布が示す特徴的なポイントは、“ロングテール”を伴う場合が多いことです。つまり、大部分のケースでは予想よりも早めに終わる、あるいはほぼ予定通りに進むことが見込まれる一方で、わずかな要因によって大きく納期が遅れるケースが一定の確率で存在するのです。この「裾が長い」分布は、従来の「計画通り行くはず」という期待からかけ離れたリアリティを突きつけます。わずかな逸脱が、長期間の遅延を引き起こす可能性がある—この事実を事前に理解しておくことで、ステークホルダー間の期待調整やリスク対策が格段にしやすくなります。

要するに、プロジェクト見積りを確率分布で考える意義は、現実的なリスクコミュニケーションを可能にし、計画時点から「不確実性との付き合い方」をチーム全体が共有できる点にあります。これにより、突発的な事象や漸進的な要件増加（スコープクリープ）にも柔軟に対応しやすい状況が生まれるのです。

アジャイル開発プロセスにおいては、プロジェクトマネジメントよりむしろプロダクトマネジメント的に継続的な価値提供を行うことが主眼となりますが、リリースのマイルストンに向けたスケジュール管理はビジネス上も重要な要素です。

そのため、確率分布を用いてステークホルダーと議論するために以下のようなシミュレーションを行うためのツールを開発しました。

見積り、コミットメント、ターゲット

本ツールでは、見積り、コミットメント、ビジネスターゲット（および安全ライン）を描画します。それぞれについて説明します。

見積りとは、プロジェクトにおける作業期間やリソースを予測するもので、確率的な性質を持つものです。見見積りはあくまで「予測」であり「約束」ではないため、エンジニアが提示する見積りをビジネスサイドが確定的な約束として受け取ると、誤解が生じやすくなります。そのため、見積もりは単なる可能性の範囲を示すものとして正しく理解される必要があります。

一方、コミットメントは、チームがいつ何を提供するかを具体的に約束する行為を指します。これは努力目標としての性質を持ち、プロジェクトにおける信頼を築くための重要な要素です。ただし、初期段階で不確実性が高い場合には、無理のない範囲で緩やかなコミットメントを設定し、状況に応じて段階的に確実性を高めることが求められます。一定程度の難易度を持ちながらも現実的で、かつ工夫の余地があるようなコミットメントラインとして60%完了している点を設定しています。

ターゲットは、ビジネスとして達成が求められる具体的なゴールや目標を指します。例えば、「この機能をX月までにリリースしないと事業に悪影響が出る」といった、ビジネス上の重要なマイルストーンがこれに当たります。ビジネス上の目標を実現するためにエンジニアはターゲットを十分に理解し、達成が難しい場合には代替案を提示するなど、ビジネス全体を考慮した行動を取る必要があります。

しかし、開発にはリスクがつきものです。コミットメント通りに達成しない可能性が40%もある状態で、ビジネスターゲットの達成に大きな影響のある外的要因を作るべきでしょうか。たとえば、ロードマップセリングとして開発予定のものを顧客に約束して販売したり、大規模なマーケティング予算を組んだキャンペーンの実施などを行うなどがそれにあたります。多くの場合このようなターゲットのためのデッドラインは、少なくともリリースしている蓋然性が高い8割程度のところには据えたいところです。よりクリティカル場合は、90%の成功確率は取りたいでしょう。

このように見積り、コミットメント、ターゲットの3つの概念を明確に区別することで、エンジニアとビジネスサイドの間での認識のズレを減らし、プロジェクトを効率的かつ円滑に進めることが可能となります。エンジニアがターゲットを理解し、コミットメントを適切に設定しつつ、見積もりを予測として活用することで、信頼関係が築かれ、結果的にプロジェクトの成功につながります。

プロジェクト、タスクで見るかリスクで見るか。

プロジェクトマネジメントにおける2つの異なるアプローチ、「タスクベース」と「リスクベース」について深く掘り下げてみたいと思います。

タスクベースの考え方

私たちは往々にして、プロジェクトを「タスクの集まり」として捉えがちです。新しいプロジェクトを始める際、まず最初に行うのが作業の洗い出し。「この機能の開発に2週間」「テストに1週間」といった具合に、必要な工数を見積もっていきます。

このアプローチの魅力は、その分かりやすさにあります。タスクという具体的な単位で考えることで、誰が何をいつまでにすべきか、進捗は何%か、といった管理がしやすくなります。まさに「足し算」的な考え方で、個々のタスクの所要時間を合計すれば、プロジェクト全体の期間が見えてくる――そんな単純明快さが特徴です。

足し算を起点としたプロジェクト管理は、プロジェクトのマネジメントに「正規分布的」な性質を付与します。

リスクベースという新たな視点

しかし、実際のプロジェクトで「予定通り」に進むことはむしろ稀かもしれません。なぜでしょうか？

ここで注目したいのが「リスクベース」という考え方です。プロジェクトには、技術的な不確実性、メンバーの突然の離脱、市場環境の変化、予期せぬ要件変更など、さまざまなリスク要因が潜んでいます。これらは単独で発生するだけでなく、相互に影響し合い、時には予想を超える大きな影響をもたらすことがあります。

例えば、ある技術的課題の解決に予想以上の時間がかかると、それは後続のタスクにも波及し、さらには別のリスクと重なって、指数関数に問題が拡大することもあります。これは「掛け算的」な影響と呼べるでしょう。

これらのかけ算的なリスクを起点としたプロジェクト管理はマネジメントに「対数正規分布」的な性質を付与します。

リスクドライバーのチェックリスト

ソフトウェアプロジェクトにおけるリスク管理を行うために、アジャイル開発に向けたリスク因子を洗い出しました。
要するに、このプロジェクトはなにか匂うなというリスクを引き起こしうるような「危険な匂い」です。

これらが増える毎にスコープクリープ（プロジェクト進捗毎に要件が増える）といった現象が加速するように設定しています。チェックリストを以下に示します。

これらのチェックリストはITプロジェクトのリスク予防への実践的アプローチをベースに筆者がアジャイル開発チーム向けにリライトしたものです。

- [ ] プロダクトビジョンが明確に定義されておらず、ROIや価値提供の指標が具体化されていない。

- [ ] チームが「なぜこの機能を作るのか」を理解できておらず、プロダクトゴールとの紐付けが不明確である。

- [ ] デイリースクラムが形骸化しており、impedimentsの共有や解決が適切に行われていない。

- [ ] レトロスペクティブで特定された問題（例：テスト自動化の不足、チーム間連携の課題）に対する改善アクションが実行されていない。

- [ ] プロダクトバックログの優先順位付けが不明確で、ビジネス価値やリスクの評価基準が標準化されていない。

- [ ] ユーザーストーリーが肥大化しており（2-3日以上の工数）、INVESTの原則に反している。（例：1スプリントで完了できないPBI）

- [ ] アクセプタンス基準があいまいで、Definition of Doneが具体的な検証項目まで落とし込めていない。

- [ ] CI/CDパイプラインが不安定で、自動テストのカバレッジが不十分である。

- [ ] 開発環境と本番環境の差異が大きく、環境依存の不具合が頻発している。

- [ ] パフォーマンス要件やセキュリティ要件が明確でなく、非機能要件のテスト基準が未確立である。

- [ ] 運用自動化が不十分で、デプロイやロールバックに手動作業が多く含まれている。

- [ ] インシデント対応やエスカレーションフローが標準化されておらず、障害時の対応が属人化している。

- [ ] モニタリングとアラート基準が適切に設定されておらず、問題の早期発見が困難である。（例：APM・ログ監視の未導入）

- [ ] プロダクトオーナーの権限が不明確で、意思決定プロセスに遅延が発生している。

- [ ] ステークホルダーとの定期的なデモやレビューが実施されず、フィードバックループが機能していない。

- [ ] 業務知識やドメイン用語の共有が不足しており、要件解釈に齟齬が発生している。

- [ ] 特定の技術スキル（例：セキュリティ、パフォーマンスチューニング）を持つメンバーが不足している。

- [ ] チーム間の知識移転が円滑でなく、ナレッジマネジメントが確立されていない。

- [ ] メンバーの入れ替わりに対するオンボーディングプロセスが確立されていない。

- [ ] スコープ変更や優先度変更の管理プロセスが不明確で、計画の一貫性が保てていない。

- [ ] 技術的負債の可視化と返済計画が不十分で、保守性の低下が進行している。

- [ ] データ移行やシステム統合などの大規模変更に対するリスク管理が不十分である。

- [ ] 経営層のアジャイル開発への理解が不足しており、従来型のマイルストーン管理が求められている。

- [ ] プロジェクトの成功指標が不明確で、ビジネス価値の評価方法が確立されていない。

- [ ] アジャイルガバナンスの体制が整備されておらず、組織横断的な調整が困難である。

これらのチェックリストを用いて、スコープや手戻りなどを含めたリスクを評価できるようにしています。

経験主義的プロセスにおける見積もり予測の方法

アジャイル開発の根底には「経験主義（Empiricism）」があり、実績に基づいてプロセスを改善していく思想が流れています。これは、過去のスプリントで達成できたストーリーポイントや要件達成度、そしてスコープクリープの発生具合といった現実的なデータを活用することで、より正確な予測へとつなげていくアプローチです。

実績データのフィードバックループ

たとえば、過去数スプリントでの平均ベロシティや、その変動幅を定期的に計測・振り返ることで、チームは自分たちの生産性を客観的に把握できます。スプリントレビューやレトロスペクティブで収集した定性・定量両面のフィードバックをもとに「次のスプリントでは何が変わるか」を議論し、その結果がまた次の見積もり予測に反映されることで、予測モデルは実績に即した形へと進化していきます。

過去トレンドからの確率分布更新

モンテカルロシミュレーションやベロシティ分布の初期パラメータは、過去データを元に継続的に更新できます。新たなスプリント結果が得られれば、それを基にベロシティの平均・標準偏差を再計算し、スコープクリープの発生頻度や増加率を修正することが可能です。こうした更新は、過去データが蓄積されるほど予測の精度を向上させ、実績を踏まえた現実的な計画策定を後押しします。

経験主義がもたらす透明性と適応性

この経験主義的なプロセスは、単なる「予測精度向上」にとどまらず、チームやステークホルダーが不確実性に正直でいられる文化を育てます。検証可能なデータと明確なフィードバックループが存在することで、「この計画はなぜそうなっているのか」が明示的になり、その都度改善を試みる「適応性」の精神が根付きます。このプロセスを継続することで、予測手法は常に現場の実態を反映し、より確度の高い納期見積もりやリスク低減策を提供できるようになります。

要するに、経験主義は予測手法に対する堅牢な基盤を築きます。計画段階で設定したモデルは、現場の学びによって定期的に調整され、不確実性を継続的に低減します。これはアジャイルの「Inspect and Adapt（検査と適応）」を見積もりにも適用する考え方であり、実務へのフィット感を高めながら、長期的なプロジェクトの成功確率を高める有効なアプローチなのです。

アジリティー（ベロシティ）の安定性と不確実性の関係

アジャイル開発では、チームの生産速度を「ベロシティ」という概念で表すことが一般的です。ベロシティは、あるスプリント（一定期間）でチームが達成できるストーリーポイント数を指し、これが一定していれば、将来の見積りや計画は比較的スムーズに行えます。しかし、現実にはさまざまな要因によってベロシティは変動することが多く、これがプロジェクト予測における大きな不確実性の源泉となります。

ベロシティの標準偏差が小さい場合の予測容易性
たとえば、あるチームが毎回のスプリントで30ポイント前後の開発量を安定的に達成できているとします。この場合、期待できる生産量が比較的一定であるため、次のスプリント、さらにその次のスプリントにおいて完了可能な範囲や進捗の見立てが明確になります。つまり、ベロシティが安定しているチームは、
「いつ頃までに、どれくらいのストーリーポイントを消化できるか」
を確率論的に考えた場合でも、その分布のばらつきが小さくなります。結果として、完了時期の予測に対する不確実性が低減し、期限やタスク規模の見積りが行いやすくなるのです。

ベロシティが変動する場合の予測困難性
一方、ベロシティが大きく変動する場合を考えてみましょう。あるスプリントでは50ポイントをこなせたと思えば、次のスプリントでは20ポイントしか消化できないといった乱高下が頻発すると、プロジェクトの完了予測は一気に難しくなります。こうした不安定さは、バックログの見直しや要員の交代、新技術の習熟、あるいは外部要因による中断など、さまざまな理由で起こり得ます。このような状況では、次のスプリント以降にどの程度の作業量が実現可能なのかを見極めるのが困難になり、結果として予測分布は広く、かつロングテールを形成しやすくなります。

要するに、ベロシティが安定しているほど、プロジェクト完了時期を確率的に予測する際のブレ幅は小さくなり、計画策定が容易になります。その反対に、ベロシティが大きく変動すると、計画担当者は幅広いシナリオを想定しなければならず、結果として「いつ完了するのか」を明確に示すことが難しくなります。プロジェクト計画者としては、チームのアジリティーを安定化させる取り組み（明確な要件定義、スキルトレーニング、作業環境改善など）が、長期的なプロジェクト予測精度の向上につながることを理解しておくことが重要です。

では、実際にベロシティの安定したチームとベロシティの不安定なチームのシミュレーションを行ってみましょう。

このグラフから言えることは、プロジェクトの成功にはベロシティ（作業速度）の安定性が極めて重要であるということです。左側の「ベロシティが安定している」場合、プロジェクト終了時期の予測範囲は中央値9.3スプリントを中心に集中しており、コミットメントライン（9.6スプリント）やビジネスターゲットライン（10.2スプリント）、安全ライン（10.7スプリント）に収まる確率が非常に高いことが示されています。一方、右側の「ベロシティが不安定」な場合、プロジェクト終了時期の分布が大きく広がり、中央値9.3スプリントから大きく外れるケースが増えています。安全ラインは25.3スプリントと大幅に引き上げられており、最悪のケースでは完了までに3倍近いスプリント数を要する可能性が示唆されています。この違いは、ベロシティが安定している状況では計画通りにプロジェクトを進めることができるのに対し、不安定な場合はスケジュール遅延のリスクが著しく高まることを意味します。不安定な状況下では、安全ラインを十分に確保し（例：25スプリント以上）、リスクを軽減する対策が求められます。このグラフは、ベロシティの安定性を保つ努力がいかにプロジェクトの成功に直結するかを具体的な数字で示しています。

実績が増える毎に予測精度が上がる。

本ツールでは、過去実績が増える毎に、精度が向上するようになっています。
たとえば、一度のスプリントでベロシティが50であったときより、過去五回の50,45,47,50,43のような数が増える毎にベロシティの想定が真の平均に近づくようになるはずです。このように安定した実績が予測精度を高めるということを実現しています。

スコープクリープが予測に及ぼす影響

「スコープクリープ（Scope Creep）」とは、プロジェクト進行中に要件が少しずつ追加・拡大し続ける現象を指します。本来の計画にはなかった新たな機能要求や仕様の変更が、スプリントごとに増えていくことで、プロジェクトの完了に必要な総ストーリーポイント数が膨れ上がっていきます。

このスコープクリープが起きると、当初設定していた計画や見積りはたちまち歪んでしまいます。なぜなら、チームが消化するタスクの総量が開発期間中に増大し続けるため、ベロシティが一定であっても、想定以上の時間を必要とするようになるからです。つまり、スコープクリープは、プロジェクト見積りの確率分布を変形させ、ロングテールをさらに伸ばしてしまう要因のひとつと言えます。

スコープクリープを定量化する意義

スプリントごとにどれくらいの割合でストーリーポイントが増えるのか、あるいはどの程度の新要件が持ち込まれるのかを定量的に把握することで、事前にスコープクリープを織り込んだ計画が可能となります。たとえば、「平均で毎スプリント2％の追加要件が発生する」と見積もることで、初期段階から本来のスコープに上乗せしたバッファを確率分布に反映できるのです。

管理と制御による予測精度向上

もちろん、理想はスコープクリープを抑制し、発生を最小限に抑えることです。要件定義の段階で顧客やビジネス側と慎重な調整を行い、優先度の明確化やリリース計画の明瞭化を図ることで、スコープが安定すれば、プロジェクト全体の予測精度は劇的に向上します。言い換えれば、スコープクリープをコントロールすることは、プロジェクト計画者やステークホルダーにとって「不確実性」という敵を弱体化させる重要な戦略なのです。

最終的に、スコープクリープへの対処は、単に要件を「削る」ことではなく、「将来どれだけ発生し得るか」を理解し、「発生したらどのように対応するか」を確立することにあります。これが、確率分布を用いた予測手法によって明示的に可能になるアプローチであり、結果としてプロジェクト全体の見通しを改善し、納期遅延などによるビジネスインパクトを最小限に抑える効果が期待できます。
リスク因子が増えていく毎に、プロジェクトのかけ算的性質が強まっていくことがわかります。
逆にプロジェクト初期において、リスク要因が多くても段階的に解決したり、ヘッジしたりしていくことで予測の精度を上げることができるわけです。

ツールを用いたモンテカルロシミュレーションによる可視化と改善

これまで述べてきたような不確実性—ベロシティの変動やスコープクリープ、そしてプロジェクト全体を支配する「確率分布としての予測可能性」—を現場でどのように扱えばよいのでしょうか。そこで有用なのが、モンテカルロシミュレーションを活用したツールです。

モンテカルロシミュレーションによる確率的予測
モンテカルロシミュレーションは、「何千回、何万回といった多数の試行を擬似的に行い、その結果分布から確率的な特性を導く」という手法です。プロジェクト計画においては、

• 各スプリントで発生しうるベロシティのばらつき
• スコープクリープによるストーリーポイントの増加率
  をモデル化し、シミュレーションを繰り返すことで「プロジェクト完了までに必要なスプリント数」の分布を求めることができます。

これにより、「50％の確率でこの期間内に終わる」「80％の確率ではこれくらいの期間が必要」といった複数の確率ライン（パーセンタイル）を算出できます。こうした情報は、単純な「○月○日までに終わるでしょう」といった確定的な約束よりもはるかに実践的な価値を持ちます。計画担当者は、より現実的な期待値設定やリスク管理を行えるようになるのです。

ビジュアライゼーションによる直観的理解
さらに、ヒストグラムやラインプロットを用いて、完了時期の分布を可視化すれば、チームやステークホルダーは直感的に「どれだけのばらつきがあるのか」「どの程度の確率で遅延が発生しうるのか」を理解できます。これにより、関係者間で透明性の高いコミュニケーションが可能となり、不確実性に対する共通認識が形成しやすくなります。

改善プロセスへのフィードバックループ
モンテカルロシミュレーションの結果は、単なる「現状の見える化」にとどまりません。その結果を分析することで、

• ベロシティ安定化に向けたプロセス改善
• スコープクリープ削減のための要件定義や合意形成方法の見直し
  といった具体的なアクションプランを立てることができます。これは、アジャイル開発で重要視される継続的改善（Continuous Improvement）のサイクルを加速させ、より予測可能性の高いプロジェクト運営を実現する基礎となります。

つまり、このツールは、プロジェクト計画者やチームが持つデータをリスク・不確実性込みで再評価し、意思決定を質的に高める有効な手段になるはずです。

アジャイル環境における予測手法改善のポイント

不確実性を前提にした確率分布ベースの予測手法を取り入れることは、アジャイルプロジェクトの計画精度向上に大いに役立ちます。しかし、それだけで状況が劇的に改善するわけではありません。

シミュレーションツールの活用によって可視化された課題やリスクに対し、組織・チームとして実際に改善へつなげていくステップが求められます。以下では、アジャイル環境で予測手法を改善する際の主なポイントを挙げます。

(1) ベロシティの安定化を目指した継続的改善
アジャイルチームは基本的に「適応と改善」を繰り返すことで、開発の効率と安定性を向上させていきます。ベロシティが大きく揺れ動く原因を特定するために、レトロスペクティブ（振り返り）を活用し、以下のような改善施策を行います。

• 明確で完結なユーザーストーリーの作成
• 過剰な文書作成やツール操作など「開発以外」の負荷軽減
• チームメンバー間のコミュニケーション改善や知識共有の活性化
  これらの取り組みにより、ベロシティの変動幅が徐々に小さくなり、予測精度は高まっていくでしょう。

(2) スコープコントロールと要件定義の徹底
スコープクリープの発生を完全に防ぐことは難しいかもしれませんが、要件定義段階で適切な優先順位づけや顧客・関係者との合意形成を行うことで、その影響を最小限に抑えることができます。

• 次のスプリントに着手する前に「本当に必要な要件か」を見極める
• ビジネス上の価値に基づくストーリー優先度再評価
• 変更要求が発生した際のスコープ調整プロセスを事前に合意
  これらを実行すれば、新たな要件が闇雲に追加される事態を軽減し、より安定した予測を維持しやすくなります。

(3) 不確実性を前提としたステークホルダー・マネジメント
プロジェクトが確率分布を伴う予測で動くことを、上位マネジメントやビジネス側が理解し、受け入れることが必要です。単一の確定納期を要求するのではなく、リスクや不確実性に対する対応策やバッファ計画、複数のパーセンタイルを用いた期待値調整を共有することで、実務レベルの判断や優先度付けがより現実的になります。

(4) 継続的なフィードバックループの確立
モンテカルロシミュレーションなどのツールを定期的に適用し、その結果を分析するプロセスを回し続けることで、予測モデルと実際のギャップを洗い出せます。この反復的なアプローチは、アジャイル原則の「継続的改善」を体現し、時間をかけて精度を向上させる基盤となります。

総じて、アジャイル環境で予測精度を高めるには、ツールによる不確実性の可視化に加え、ベロシティ安定化やスコープコントロール、そしてステークホルダーとの合意形成が欠かせません。そのうえで、継続的な改善と適応を実施することで、より正確で信頼性の高いプロジェクト運営が実現できるのです。

まとめ

アジャイル開発の計画や見積りにおいて、私たちはしばしば「いつ終わるか」という確定的な答えを求めがちです。しかし、実際のプロジェクト運営では、要件の不確定要素やチームベロシティの変動、さらにはスコープクリープ（追加要件の増大）など、多くの不確実性が存在します。このような不確実性を無視した見積りは、結果として納期遅延やビジネス損失をもたらす大きなリスクとなります。

そこで有効なのが、プロジェクトの完了時期を「確率分布」として捉える考え方です。単一の期日ではなく、「何％の確率でいつ終わるか」を示すことで、現実的な期待値を提示できます。その際、ベロシティが安定していれば予測は比較的容易になりますが、ばらつきが大きければ予測は困難になるという、チーム運営上の要改善点が明確になります。また、スコープクリープを定量的に捉え、計画段階から織り込むことで、より堅実な見積りが可能になります。

この確率的アプローチを具体化する手段として、モンテカルロシミュレーションなどのツールを活用できます。これらのツールは、ベロシティやスコープクリープを確率モデルに落とし込み、膨大な試行を行うことで、プロジェクト完了までのスプリント数や期間を分布として導き出します。その結果を可視化すれば、チームやステークホルダーは、計画が持つ不確実性やリスクを共有認識しやすくなり、適切なバッファ設定やリスク対策を検討できます。