フレームワーク活用ガイドひとことで言うと#
遅延コスト（Cost of Delay）をジョブサイズで割ることで、「小さくて価値の高い仕事」を先にやるべきだと定量的に示す優先順位づけ手法。Don Reinertsenが提唱し、SAFe（Scaled Agile Framework）が採用したことで広まった。
押さえておきたい用語#
- Cost of Delay（コスト オブ ディレイ）
- ある仕事の着手や完了が遅れることで失われる経済的価値のこと。WSJFの分子にあたり、3つの構成要素を合算して求める。
- User-Business Value（ユーザー ビジネス バリュー）
- その仕事が顧客や事業にもたらす直接的な価値を指す。売上増・満足度向上・コスト削減などが該当する。
- Time Criticality（タイム クリティカリティ）
- 時間経過によって価値がどれだけ急速に減衰するかを示す度合い。期限付きキャンペーンや法規制対応は高くなる。
- Risk Reduction / Opportunity Enablement（リスク リダクション）
- リスクを下げる効果、または将来の機会を切り開く効果である。技術負債の返済やプラットフォーム整備がこれにあたる。
- Job Size（ジョブ サイズ）
- その仕事を完了するのに必要な工数・期間の見積もりのこと。WSJFの分母にあたる。
WSJFの全体像#
こんな悩みに効く#
- バックログの優先順位を「声の大きい人」の意見で決めてしまっている
- 大きな機能ばかり先に着手して、小さいが価値の高い改善が後回しになる
- 施策の「緊急度」と「重要度」をどう天秤にかければいいかわからない
基本の使い方#
以下の3要素をそれぞれ 1〜13のフィボナッチ数列（1, 2, 3, 5, 8, 13）で相対評価し、合計する。
- User-Business Value: 顧客価値や売上への貢献度
- Time Criticality: 遅れるほど価値が下がるか（期限・季節性）
- Risk Reduction / Opportunity Enablement: リスク低減や将来の機会創出への寄与
ポイントは絶対値ではなく「候補同士を比べた相対値」で付けること。まず基準となるジョブを1つ選び、それを中間の 5 に設定すると揃えやすい。
具体例#
あるフィットネスアプリのチームが、次の4つの施策で優先順位を迷っていた。
| 施策 | User-BV | Time Crit. | Risk Red. | CoD合計 | Job Size | WSJF |
|---|---|---|---|---|---|---|
| プッシュ通知のパーソナライズ | 8 | 3 | 2 | 13 | 5 | 2.6 |
| Apple Watch連携 | 5 | 8 | 1 | 14 | 13 | 1.1 |
| 決済画面のUI改善 | 3 | 2 | 5 | 10 | 2 | 5.0 |
| ソーシャルシェア機能 | 5 | 5 | 1 | 11 | 8 | 1.4 |
決済画面のUI改善はWSJF 5.0 で最上位。離脱率 18% のボトルネックを 2スプリント で直せるため、小さな工数で大きなリターンが見込める。Apple Watch連携は話題性があるものの、工数13と重く、スコアは最下位の 1.1 だった。
従業員管理SaaSの開発チームがPI（Program Increment）計画で30のフィーチャー候補を抱えていた。全員でスコアリングに 90分 を使い、上位10施策に絞った。
スコアリング前は「大企業向けSSO対応」が最優先と思われていたが、WSJFを計算すると結果は違った。
- SSO対応: CoD = 16、Size = 13 → WSJF 1.2
- CSV一括インポート改善: CoD = 14、Size = 3 → WSJF 4.7
- 勤怠データのリアルタイム集計: CoD = 18、Size = 5 → WSJF 3.6
CSV改善は「地味だが問い合わせの 35% を占める」ペインポイントだった。工数3で着手でき、カスタマーサポートの月間対応時間を推定 40時間 削減できる。WSJFがなければ、SSO対応に3スプリントを費やしてからようやく着手する予定だった。
人口8万人の自治体が、住民サービスのデジタル化で5つの施策を検討していた。予算は年間 2,400万円、IT担当は 3名。
| 施策 | User-BV | Time Crit. | Risk Red. | CoD | Size | WSJF |
|---|---|---|---|---|---|---|
| オンライン住民票申請 | 8 | 5 | 3 | 16 | 5 | 3.2 |
| 庁内ペーパーレス化 | 3 | 2 | 8 | 13 | 8 | 1.6 |
| 防災情報LINE配信 | 5 | 13 | 5 | 23 | 3 | 7.7 |
| 公共施設予約システム | 5 | 3 | 2 | 10 | 8 | 1.3 |
| AI問い合わせチャット | 5 | 2 | 3 | 10 | 13 | 0.8 |
防災LINE配信が 7.7 で断トツの1位。台風シーズンまで残り4か月というTime Criticalityの高さと、実装が軽い（既存LINE公式アカウントに配信機能を追加するだけ）ことがスコアを押し上げた。住民アンケートでも「災害時の情報が遅い」が不満の 1位（42%） であり、数値で裏付けられた優先順位に議会の合意も得やすかった。
やりがちな失敗パターン#
- 絶対値で見積もってしまう — 「この機能は500万円の価値がある」と絶対額で付けると、基準が人によってブレる。WSJFの見積もりは候補同士を比べた相対値で行うのが鉄則
- ジョブサイズの粒度がバラバラ — 1日で終わるバグ修正と3か月の新機能開発を同列にスコアリングしても意味がない。比較可能な粒度に揃えてからスコアリングに入る
- スコアを絶対視して思考停止する — WSJFはあくまで「議論の出発点」。スコアが僅差なら依存関係やチームのスキルセットも加味して最終判断する。数字だけで決めるとチームの納得感が下がる
まとめ#
WSJFは Cost of Delay ÷ Job Size というシンプルな計算で、「小さくて価値が高く、急ぎの仕事」を先にやるべきだと可視化する手法。見積もりには絶対値ではなく相対値を使い、候補同士を比較することがポイントになる。スコアはチームの議論を促すための道具であって、最終判断そのものではない。迷ったらまずテーブルに数字を並べてみることから始めるとよい。