このユニットの結論
約1,500件の要件をすべて同じ重さで扱うと、どれも終わりません。
要件に優先度をつけるとは、「なくては業務が回らないもの」「あると大きく良くなるもの」「あれば嬉しいもの」「今回はやらないもの」に分け、分け方の基準と決める人を先に決めることです。優先度のない要件一覧は、終わりのない一覧です。
1. 何の話か
このユニットは、要件に優先度をつける基準と手順の話です。
04-01 要望と要件は何が違うのか で、要望を要件にするまでを学びました。要件になったものの間にも、重さの違いがあります。すべてを稼働の日までに作ることはできないし、作る必要もありません。何を先に作り、何を後に回し、何をやらないかを決めるのが優先度です。
2. なぜ必要か
優先度をつけずに進めると、
- 作る順番が「要望を出した人の声の大きさ」で決まる
- 期限が近づいたときに、何を落とすかをその場で決めることになり、業務に必要なものが落ちる
- 「全部必須」と言われた要件の山を前に、開発側が見積もりを出せない
ということが起きます。優先度は、期限が迫ってから決めるのではなく、要件を決める段階で決めます。
3. このユニットで分かること
- 優先度の分け方と、その基準
- 「全部必須」をどう解きほぐすか
- 優先度を決める人と、記録の残し方
4. 優先度の分け方
一般的な分け方の 1 つは、4 段階です。世界で共有されている考え方では、頭文字をとって MoSCoW と呼ばれます。
| 段階 | 意味 | 判断の問い（一般的な例） |
|---|---|---|
| なくてはならない | これがないと業務が回らない、法令を守れない | この要件がない状態で稼働したら、業務は止まるか |
| あるべき | なくても回るが、業務の負担や危険が大きく増える | ない場合の回避策はあるか。回避策の負担はどれだけか |
| あれば良い | あると便利だが、なくても困らない | ない場合、誰がどれだけ困るか |
| 今回はやらない | 価値はあるが、今回の範囲に入れない | 次の機会に回しても問題は起きないか |
分け方そのものより大切なのは、各段階の判断の問いを決めておくことです。問いがないと、「あるべき」に全部が集まります。
5. 「全部必須」を解きほぐす
業務部門から「全部必須」と言われることは普通です。解きほぐすには、問い方を変えます。
- 「必須ですか」ではなく、「これがない状態で稼働したら、何が起きますか」と聞く
- 「どれを落としますか」ではなく、「期限が 1 か月早まったら、どの順で作りますか」と聞く
- 段階ごとの上限を決める（「なくてはならない」は全体の 3 割まで、など）。上限があると、比べて選ぶようになる
優先度は業務部門だけでは決められません。開発の難しさと費用（開発側）、業務の影響（業務部門）、全体の期限と予算（PMO・責任者）の 3 つの視点をそろえて決めます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の要件に関する記載
- 約1,500件の要件
- 成果物に REQ-002 要件一覧、REQ-006 要件確定記録 がある
- P-005 藤本 遥 — 経理業務リーダー、P-006 川村 美咲 — プロジェクト管理業務リーダー、P-007 松本 健太 — 営業・契約業務リーダー、P-004 田辺 彩 — PMOリーダー
- 要件確定は、AIへ最終委任しない事項
約1,500件の要件がどの段階にどれだけ分けられたか、優先度の基準が何だったか、誰が決めたかは、正本に記録がありません。記録なし
6. THINK — 「全部必須です」
要件のレビューで、業務部門のリーダーが次のように言いました。
「この 120 件はすべて業務に必要です。優先度はつけられません。全部必須です。」
問題
PMO は、どう進めるべきでしょうか。
判断例を開く
判断
「必須」の意味を問い直し、段階ごとの判断の問いに答えてもらいます。
確認すること:
- 要件ごとに「ない状態で稼働したら何が起きるか」を答えてもらったか
- 回避策（手作業、別の機能、一時的な運用）がある要件を見つけたか
- 「期限が早まったらどの順で作るか」を聞き、順番を引き出したか
- 段階ごとの上限を示し、比べて選ぶ場を作ったか
- 開発の難しさと費用を開発側から示し、業務部門と同じ表で見たか
「全部必須」は優先度の拒否ではなく、問いが足りないという合図です。問いを変えれば、順番は必ず出てきます。
7. よくある失敗
- 優先度を「高・中・低」とだけ書き、基準がないので全部「高」になる
- 業務部門だけで優先度を決め、開発の難しさと合わない
- 優先度を決めた理由を残さず、あとで「なぜこれが後回しなのか」でもめる
- 期限が迫ってから優先度を決め、業務に必要なものが落ちる
8. 成果物との接続
- REQ-002 要件一覧：要件ごとに優先度の段階と、その理由を書く欄を持たせる
- REQ-006 要件確定記録：優先度を含めて確定したことと、決めた人・日付を残す
優先度は、要件が確定するまでに決めます。確定のあとに優先度を変えるなら、変更の手続き（04-06 途中で要件が変わったらどうするのか）を通します。
9. AI WORKFLOW — 優先度の理由の抜けを点検させる
AIは、要件一覧の優先度の欄と理由の欄を読み、理由が書かれていない要件や、理由と段階が合っていない可能性のある要件を探す下書きに役立ちます。
指示例:
「次の要件一覧について、要件ごとに『優先度の段階』『理由』を抜き出し、理由が空欄のもの、理由が『業務が止まる』と書かれているのに段階が『あれば良い』になっているような、段階と理由が合わない可能性のあるものを示してください。段階を変える提案はしないでください。」
10. REVIEW — AIの指摘を確認する
- AIが「合わない」とした要件について、理由の読み方が正しいかを人が確かめたか
- 理由が空欄の要件を、業務部門に確かめたか
- 要件一覧を AI に渡してよいか（業務情報の扱い）を事前に確かめたか
11. 人間が判断すること
- 段階の基準（判断の問い）と、段階ごとの上限
- 要件ごとの優先度
- 優先度を変えるときの手続き
要件確定は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
あなたの職場の業務で使っている道具（表計算、メール、業務システムのどれか）について、「あったら良い機能」を 8 つ挙げてください。
4 つの段階に分け、各段階の判断の問いに自分で答える形で理由を書いてください。「なくてはならない」に入れたものについて、「ない状態で業務をしたら何が起きるか」を具体的に書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
優先度は期限の前に決める。段階ごとの判断の問いと上限を先に決め、業務・開発・全体の 3 つの視点で分け、理由を残す。「全部必須」は問いが足りない合図。