Evidence-Based Scheduling（EBS）とは

**Evidence-Based Scheduling（EBS）は、Joel Spolskyが提唱した「開発者の見積もりデータをもとに完了予測を確率的に導き出す」**スケジューリング手法です。

  • Joel Spolsky: 元Microsoft社員で、Fog Creek Software（現Glitch）やStack Overflow共同創設者としても知られる人物。ソフトウェア開発のベストプラクティスを多数発信してきました。
  • EBSの特徴: 従来の「担当者の勘や経験値のみに頼る見積もり」を、タスクごとの見積もり履歴や実績との乖離を統計手法（モンテカルロ法）で補正し、完了日を確率的に予測するアプローチをとります。

なぜEBSがデスマーチ回避に効くのか

  1. “当たる見積もり”を作りやすい
    開発者が出す主観的なタスク見積もりを、過去の実績データと付き合わせることで補正します。
    • 「いつも過小評価しがち」
    • 「タスクAが思いのほか時間がかかる」
      などの“偏り”を数値化し、客観的に見積もりを調整できるようになります。
  2. リスクを“確率”で共有できる
    従来のガントチャートは「◯月◯日に完了」と断定しがちですが、EBSなら**「80％の確率で◯月◯日に完了する」**といった形でリスクを示せます。
    • 例：「80％の確率で終わるが、残り20％は遅れる可能性がある」
    • チームやステークホルダーとも不確実性を正直に共有できるため、無茶なスケジュールを押し付けられるリスクが減ります。
  3. 小刻みな学習サイクル
    EBSはタスクごとに「何時間かかるか」を見積もり、完了後に実績を即フィードバックしてデータをアップデートしていく考え方です。
    • 繰り返しイテレーションを回すことで、見積もりの精度やチームのリスク管理能力が上がる
    • デスマーチを未然に防ぎ、チーム全体が“正確な見積もり”に近づきやすくなります。

Evidence-Based Schedulingの流れ

Joel Spolskyのブログでも解説がありますが、大まかな流れは次のとおりです。

  1. タスク分割
    • 機能や修正点を細かいタスクにブレイクダウンする
    • 1タスクを数時間〜数日程度で終わるサイズにすること
  2. 開発者が見積もる
    • 担当者ごとに「◯時間（◯日）かかる」と見積もりを入力する
    • タスクが多い場合はスプレッドシートやツールで一括管理する
  3. 過去実績との乖離データ化
    • 例：見積もり2時間だったタスクが実際は4時間かかった…などを記録する
    • 開発者単位の“過去の見積もり精度”を統計処理する
  4. モンテカルロシミュレーション
    • 見積もり誤差の分布をもとにランダム試行し、プロジェクト完了日を確率で予測する
    • たとえば「80％の確率で◯月◯日までに終わる」「95％なら◯月◯日」など
  5. 進捗報告・調整
    • スプリントやマイルストーンごとにEBSの結果を更新・共有する
    • スケジュールに余裕がないとわかればスコープ縮小やリソース追加を検討する
    • この繰り返しで精度が高まっていく

実際に導入する際の注意点

  1. タスク分割の精度
    タスクが大きすぎると見積もりのブレも大きくなるため、ある程度細かい単位（数時間〜数日）に分割するのが前提。
  2. 見積もりの慣れ
    「よく分からない」「ざっくりしか言えない」など、最初は開発者が戸惑うことも。定期的な振り返りを行い、少しずつ慣らしていく。
  3. チームへの説明
    「モンテカルロ法？」といった疑問が出やすい。簡単な解説資料やワークショップなどを用意して、導入時にしっかり共有する。
  4. ツール選び
    かつてはFogBugz（現Manuscript）にEBS機能がありましたが、今では他ツールでも同様の拡張が可能。自前のスプレッドシートで組む方法もアリ。

私たちのチームでのカスタマイズ事例

Evidence-Based Schedulingは、本来「日次の実績記録＋モンテカルロ法」で精度を高めるアプローチですが、実際の現場では運用コストやチーム特性に合わせたカスタマイズが必要です。
私たちのチームでは、以下のようにEBSの考え方を部分的に取り入れています。

  1. 日次の実績記録は行わない
    • 理想としては日次の実績と見積もりを定期的に比較し、モンテカルロ法を回した方が精度は上がる。
    • しかし、メンバーの中には日次記録が不得意な人もいて、全員に強制すると運用コストが大きい。
    • そこで日次管理をあえてしない運用に。
  2. PBIと完了スプリント数だけ把握
    • アジャイル開発で「PBI（Product Backlog Item）」にポイント見積もりを付与し、**「何スプリントで完了したか」**を記録。
    • これにより「ポイントXのPBIは平均◯スプリントで終わる」という経験則が得られ、統計的かつ経験的な目安となる。
  3. 単一のPBIに集中しづらい環境を前提に
    • 現場ではマルチタスクや他の業務が常に入り込むため、1つのPBIに集中的に取り組むのは難しい。
    • EBS的な発想を活かしつつも、スプリント全体でPBIを少しずつ進める前提のスケジュールを作る。
    • **「◯ポイントのPBIは大体◯スプリントかかる」**と読めるようになり、無理のない計画につながっている。
  4. 理想と現実の折り合い
    • 日次記録＋モンテカルロ法が本来は理想だが、運用コストやメンバーの得手不得手を考慮して割り切り。
    • **「完全ではないが以前よりは格段にマシ」**というレベルで安定してきた。

なぜこのカスタマイズが良かったのか

  • 導入ハードルが低い
    日次ログを取らない分、メンバーの心理的負担が少なく、チームの反発を抑えられた。
  • “そこそこ役立つ”見積もりが得られる
    完璧を求めると挫折するリスクがあるが、チーム全体で「前よりは当たるスケジュール」を構築できている。
  • マルチタスク前提の計画作り
    EBS本来の考え方をアジャイルに応用し、無理のないプランを引きやすくなった。

まとめ：EBSを柔軟に使ってデスマーチをなくそう

Evidence-Based Schedulingは、「開発者の見積もりを統計・確率で補正し、完了時期を計算する」という強力な手法です。
ただし、運用コストやチーム特性を踏まえずに“教科書どおり”に導入すると、かえって挫折を招くこともあります。

理想の精度を追求しつつも、自分たちのチームに合った形で少しずつ取り入れることで、デスマーチになりがちなプロジェクトでも無理のないスケジュールを実現しやすくなるでしょう。

また、厳密なデッドラインを設定することに向いた手法ではないため、自社ソフトウェアの開発や社内プロジェクトなど、スケジュールにある程度の幅を持たせやすいプロジェクトにマッチします。ただ、厳密なデッドラインを求めるプロジェクトにおいても、想定しているスケジュールが現実的かどうかを一次判定するフィルタとして使えますので、その意味で有用です。

デスマーチをなくすためには、チーム全員が「無理なく終わるスケジュールとは何か」を共通認識し、実践していくことが大切。EBSは、その“無理なく”を科学的にバックアップしてくれる有力なツールの一つです。

参考リンク

ぜひ、自分たちのチームに合った運用方法を模索しながら、EBSをうまく活用してデスマーチを回避しましょう！