なぜ"声の大きい人"の案件が最優先になるのか
その優先順位、"納得" で決めていますか。それとも "声の大きさ" で決まっていませんか。
四半期のロードマップ会議。「機能A」「機能B」「機能C」の3つが候補に挙がっています。
機能A: ログ集計バッチのサーバコストを最適化する
機能B: 競合対抗の解約防止アラートを出す
機能C: シフト自動最適化AIで新規顧客を獲得する
どれも「やったほうがいい」のは間違いありません。でも、リソースは有限です。どれを先にやるべきでしょうか。
この問いに、あなたのチームは何で答えていますか。役員の一声でしょうか。一番声の大きい営業の要望でしょうか。それとも、なんとなくの勘でしょうか。
この連載では、この機能A/B/Cを最後まで使いながら、「順番を"納得感"のある数字で決める」ための考え方を追っていきます。
答えそのものは、連載の最後（⑤）でお見せします。まずは、なぜ今の決め方が壊れやすいのかから見ていきましょう。
主観的な優先順位付けが壊れる3つの理由
多くの現場で、優先順位付けは次のどれかで決まっています。そしてそのどれもが、全体最適からズレていきます。
1. MoSCoW 地獄
MoSCoW ＝ Must / Should / Could / Won't（必須／推奨／可能なら／やらない）で優先度を分類する手法です。
ロードマップ整理の定番ですが、運用しているとよくある病があります。それが「何でも Must になる」病、いわゆる MoSCoW 地獄です。
みんな自分の担当機能を守りたいので、Should や Could に格下げされることを嫌います。結果、気づけばバックログは Must ばかりになります。Must だらけの優先順位表は、優先順位表として機能しません。
2. HiPPO への追従
HiPPO ＝ Highest Paid Person's Opinion（最も高給な人の意見）の略です。会議で誰かが強く主張すると、その人の役職や声の大きさで議論が決まってしまう現象を指します。
役員の一声、声の大きい人の要望。これらは「その人が正しい」とは限りません。ただ「議論を打ち切る力」を持っているだけです。結果、本当に価値の大きい案件が後回しになることがあります。
3. 「価値順」「速い順」「先着順」も、実は全体最適ではない
声の大きさで決めるのは論外だとしても、では次の決め方ならいいのでしょうか。
一番「価値が大きい」ものから着手する
一番「早く終わる」ものから着手する
依頼が来た「順番（FIFO）」に着手する
実はこれらも、チーム全体で見た損失を最小化する並べ方には、必ずしもなりません。価値が一番大きい案件でも、着手までの所要期間が長ければ、他の案件を待たせている間の損失が積み重なります。逆に一番早く終わる案件ばかり優先すると、価値の大きい案件がいつまでも後回しになります。先着順（FIFO）は、そもそも価値も緊急度も見ていません。
「価値」「速さ」「順番」のどれか一つだけを見ていると、全体では損をする並べ方になりうる。これが、主観的な優先順位付けが壊れる根本の理由です。では、何を共通のものさしにすればいいのでしょうか。
共通尺度としての Cost of Delay
ここで出てくるのが Cost of Delay（CoD） という考え方です。CoD ＝ 遅延コスト。意思決定や提供を遅らせることで失われる価値のことです。
「声の大きさ」ではなく「実際にいくら価値を漏らしているか」で優先順位を語れるようになります。だからこそ CoD は、優先順位付けだけでなく、人を増やすか・スコープを削るか・分割するかといったトレードオフ判断でも使える、いわば共通尺度です。
ここで大事なポイントが一つあります。CoD は「総額」ではありません。レート（$/週 のような、単位時間あたりの値）です。
価値は崖から落ちるように一瞬で消えるわけではなく、時間とともに少しずつ漏れていきます。だから CoD は「合計でいくら失った」ではなく「1週遅れるごとにいくら漏れているか」という形で語られます。
機能A/B/C も、それぞれ違うスピードで価値が漏れていく案件だと考えてください。その漏れ方の違いこそが、次の話につながります。
CoD ＝ Value × Urgency（足し算ではなく掛け算）
CoD は、次の2つの構成要素でできています。
CoD（レート） ≒ Value（価値の大きさ） × Urgency（時間の敏感さ）Value … 時間の概念を含まない、価値そのものの大きさ
Urgency … その価値が、時間とともにどれだけ速く失われるか
ここで重要なのは、これが足し算ではなく掛け算だということです。なぜでしょうか。
もし足し算だったら、「価値は高いが急がない案件」と「価値は低いが今すぐ着手しないと価値が消える案件」が、同じスコアになってしまうことがあります。でもこの2つは、明らかに扱いが違うはずです。
「価値が大きく、しかも急速に失われるもの」を最優先にしたい。
この相互作用を表現するには、掛け算が必要になります。機能A/B/Cも、価値の大きさだけでなく「どれくらい急いでいるか」がそれぞれ違います。
この Urgency の違いを言葉にする方法は、次回（②Value）とその次（③Urgency）で詳しく扱います。
この連載の地図
Cost of Delay の提唱元である Black Swan Farming は、CoD を数値化する手順を4ステップで示しています。
Understand Value（価値を理解する） → ②Value
Learn Urgency Profiles（緊急度のパターンを学ぶ） → ③Urgency
Estimate Peak Benefits（価値のピークを見積る） → ②Value
Calculate CoD Rate（CoD をレートとして算出する） → ④定性9マス → ⑤CD3
この連載は、この4ステップに沿って進みます。
②Value: 機能A/B/Cの「価値」をどう見積るか
③Urgency: その価値が「どう時間で減っていくか」の4パターン
④定性9マス: 金額を出す前に、順序だけでも優先順位を語る方法
⑤CD3: いよいよ、機能A/B/Cを「どの順で作るべきか」に数字で答えます
答えを急ぎたい気持ちはよくわかります。ですが CoD は「価値」と「緊急度」を分けて理解して初めて、正しく使えるものさしになります。
次回は、この「価値（Value）」から見ていきましょう。
出典:
── 「納得感のある数字」で優先順位を語れる組織へ ──
「声の大きさ」ではなく共通のものさしで優先順位を語れる組織——本連載のテーマは、私が顧問として日々向き合っている問いそのものです。
山口徹（@zigorou）です。タイミーで執行役員CTOを務めるかたわら、マギステル社として複数社の技術・プロダクト顧問をしています。技術×組織×プロダクト×AI活用を軸に、認証・ID基盤や大規模プラットフォームの設計から、AI前提の「学習する組織」づくりまで、現役CTOの経営視点で伴走します。
▶ 顧問のご相談は X の DM（@zigorou）または メール（info[at]magister.co.jp）へ。フェーズ問わずお気軽にどうぞ。
