「優先順位を決める」が難しい理由
要件定義で最も合意が割れる工程が、優先順位付けです。
「全部Mustです」
「あった方が良いに決まっている」
「他社にもあるので入れたい」
ステークホルダーごとに価値観が違い、数を絞れずに膨張する。これが多くのプロジェクトで起きる現実です。
優先順位付けには定番の手法が二つあります。アジャイル界隈で広く使われる MoSCoW法 と、書籍『システムを作らせる技術』（白川克著）で紹介されている FM（ファンクショナリティ・マトリクス）法 です。
本記事では、両者を評価軸・運用負荷・適用フェーズの観点で比較します。結論から書くと、Beekle では業務システム／受託開発の文脈で FM 法を主に採用しています。理由は本文で詳述しますが、要件発散後の最初の取捨選択で「使われない機能」「無謀な機能」を客観的に弾けるためです。MoSCoW を否定するわけではなく、適用フェーズによって向き不向きがあります。
MoSCoW法とは
MoSCoWは、要件を以下の4カテゴリに振り分けるシンプルな手法です。
カテゴリ | 意味 | 扱い |
|---|---|---|
Must have | なくては成立しない | 必須実装 |
Should have | 重要だが致命的ではない | 可能な限り実装 |
Could have | あると望ましい | 余裕があれば実装 |
Won't have (this time) | 今回は対象外 | スコープ外 |
DSDM（Dynamic Systems Development Method）が起源で、現在はアジャイル開発全般のスプリント計画やリリース計画で使われています。
MoSCoWの強み
- 学習コストが低い: 4カテゴリだけなので、初見でも使える
- 意思決定が速い: 1要件あたり数秒で振り分けられる
- 「Won't」を明示できる: 今回やらないことを言語化する文化を作れる
- ステークホルダーとの会話に向く: カテゴリ名が直感的
MoSCoWの弱み
- 判断が主観に寄りやすい: 「Mustかどうか」は人によって違う
- Mustが膨張しがち: 強い人の声で全部Mustになる現象が起きやすい
- 「使われないリスク」を捉えにくい: 価値が高くても使われない機能を弾く軸がない
- 「実装難易度」を捉えにくい: 無謀な機能をMustに入れて炎上する
FM法とは
FM法は、要件を3つの軸で評価し、組み合わせで採否を判断する手法です。
軸 | 評価 | 内容 |
|---|---|---|
ビジネス価値 | ★1〜3 | 売上・コスト削減・差別化への貢献 |
現場で使えるか | ★1〜3 | 現場のスキル・運用体制・モチベーション |
技術コスト | 低/中/高 | 実装の難易度（書籍の「技術的容易性」を逆向きに表記） |
判定ロジックは以下の通り。
- どれか1軸でもL（★1または技術コスト=高）→ 作らない
- H（★3または技術コスト=低）が2つ以上 → 作る
- 3軸ともH → 確実に作る
- それ以外（M中心）→ 後回し
詳細は スコープ管理「FM法」の使い方 で解説しています。
FM法の強み
- 多軸で客観性が出る: 主観バイアスを軸ごとに分散できる
- 「使われない機能」を排除できる: 「現場で使えるか」軸で検出
- 「無謀な機能」を排除できる: 「技術コスト」軸で検出
- 判定根拠が明示される: ステークホルダーへの説明がしやすい
- 議論が深まる: 軸ごとに評価が割れた理由を掘れる
FM法の弱み
- 学習コストがやや高い: 3軸の意味を理解する必要がある
- 評価に時間がかかる: 1要件あたり数分かかる
- 要件数が多いと負荷が重い: 100件超えると評価疲れする
- 「現場で使えるか」の評価が難しい: 開発側だけでは判断できない
評価軸の比較
両者の評価アプローチを並べると、違いがはっきりします。
観点 | MoSCoW | FM法 |
|---|---|---|
評価軸の数 | 1軸（重要度のみ） | 3軸（価値・受入・技術） |
評価値 | 4カテゴリ（M/S/C/W） | 3段階×3軸 |
1要件あたりの評価時間 | 数秒〜数十秒 | 数分 |
学習コスト | 低 | 中 |
客観性 | 主観に頼りがち | 軸ごとに議論しやすい |
「使われないリスク」 | 検出しにくい | 「現場で使えるか」軸で検出 |
「無謀な実装リスク」 | 検出しにくい | 「技術コスト」軸で検出 |
ステークホルダーへの説明 | カテゴリ名で済む | 3軸の評価結果で根拠を示せる |
適した要件数 | 数十〜数百 | 5〜50程度 |
再評価の負荷 | 軽い | やや重い |
適用フェーズの比較
開発プロセスのどのフェーズで使うかで、向き不向きが変わります。
構想フェーズ（要件発散後の絞り込み）
要件を出し切った直後、最初の取捨選択を行う段階です。
- FM法が向く: 5〜50程度の要件を、客観的な3軸で評価しきる。「使われない機能」「無謀な機能」をこの段階で排除できる。
- MoSCoWだとMustが膨張して絞り込めないことが多い。
計画フェーズ（リリース計画・スプリント計画）
実装する機能が決まった後、リリース順を決める段階です。
- MoSCoWが向く: 「最初のリリースに入れるMustはこれ」と速く決められる。
- FM法は再評価コストが高く、計画変更のたびに重い。
実装フェーズ（スプリント中の調整）
スプリント途中で新規要望が入った時の判断です。
- MoSCoWが向く: 「これはMustかShouldか」で速く判断。
- FM法は3軸評価が間に合わない。
レビュー / 再評価フェーズ
3〜6ヶ月ごとの全体見直しです。
- FM法が向く: 軸ごとに状況変化（現場のスキル向上、技術進化）を反映できる。
- MoSCoWは「変わらずMust」で終わりがち。
運用負荷の比較
実プロジェクトでの運用負荷を、要件数別に整理します。
要件数 | MoSCoWの負荷 | FM法の負荷 |
|---|---|---|
〜20件 | 軽い | 適切 |
20〜50件 | 軽い | やや重いが効果大 |
50〜100件 | 適切 | 重い（一段階上のレベルでまとめる） |
100件超 | 適切 | 評価疲れで形骸化リスク |
要件数が多いプロジェクトでは、まず大きな機能群でFM法を適用し、採用する機能群の中の細かい要件にMoSCoWを使う、という階層的な使い分けが現実的です。
どちらを選ぶか: 判断フローチャート
プロジェクトの状況に応じた選択指針です。
FM法を選ぶべき状況
- 要件が膨張して取捨選択ができない
- ステークホルダーの利害が対立しており、客観的な根拠が必要
- 過去に「作ったけど使われない」失敗を経験している
- 経営層と現場の間で要件の温度差がある
- 構想フェーズで腰を据えて優先順位を決めたい
MoSCoWを選ぶべき状況
- アジャイル開発でスプリント計画を素早く回したい
- 要件数が多く、1件ずつ深く評価する余裕がない
- ステークホルダーが「Must/Should/Could」の概念に慣れている
- リリース計画など、絞り込みより順序付けが目的
Beekle のスタンス: FM 法をベースに、必要に応じて MoSCoW を補助
Beekle は業務システム／受託開発の現場で FM 法をベースに採用しています。理由は次の3点です。
- 「使われない機能」を構造的に弾ける: 「現場で使えるか」を独立軸にしているため、ビジネス価値だけで暴走しない。MoSCoW では「重要だけど使われない」要件をそのまま Must に入れがち。
- 「無謀な機能」を構造的に弾ける: 「技術コスト」を独立軸にしているため、スケジュール破綻リスクを早期に検出できる。
- 判定根拠が明示される: 経営層と現場で利害が対立しても、3軸の評価結果で説明ができる。MoSCoW の「Mustかどうか」は主観論争になりやすい。
とはいえ MoSCoW を完全に置き換えるわけではありません。スプリント計画やリリース順位付けなど、すでに「作る」が決まっている要件の順序付けには MoSCoW の方が向いていることがあります。
FM 法主導で MoSCoW を補助に使う場合の手順例:
- 構想フェーズ（FM 主役）: FM 法で「作る／後回し／作らない」を判定。ここが要件定義の山場。
- 計画フェーズ（MoSCoW 補助・任意）: 「作る」判定の機能数が多くて初回リリースに収まらない場合のみ、MoSCoW で Must/Should/Could に振り分け。スプリント数が少ない案件ではこの工程をスキップして良い。
- 実装フェーズ（MoSCoW 補助・任意）: スプリント中に新規要望が入った時、3軸評価が間に合わなければ MoSCoW で即決。
- 再評価フェーズ（FM 主役）: 半年ごとに FM で再評価。「作らない」「後回し」判定を見直す。
ケーススタディ: 業務システム開発での使い分け例
ある中小企業の在庫管理システム刷新プロジェクトを想定した使い分け例です。
状況
- 業務部門から80件の要望が出ている
- 経営層は「DX推進」で全部入りを希望
- 現場のITリテラシーは部署によってばらつきがある
- 開発予算は限られており、初回リリースは6ヶ月
Step 1: FM法で「何を作らないか」を決める
80件の要望をすべて評価。結果:
- 「作る」判定: 28件
- 「後回し」判定: 35件
- 「作らない」判定: 17件
「作らない」17件の内訳:
- ビジネス価値★1（あれば嬉しい程度）: 8件
- 現場で使えない★1（運用体制が組めない）: 6件
- 技術コスト=高（無謀）: 3件
ここで経営層に「ビジネス価値は高いが、現場で使う人がいないので外す」と説明できることがFM法の強みです。
Step 2: 必要なら MoSCoW で初回リリースを決める（任意）
「作る」28件は6ヶ月の初回リリースに全部入らないため、MoSCoW で順序付けします。要件数が少なく1スプリントで全部作れる場合はこの工程は不要です。
- Must: 12件（在庫照会・入出庫登録・基本帳票など）
- Should: 9件（アラート機能・分析ダッシュボードなど）
- Could: 7件（モバイル対応・外部連携など）
初回リリース（6ヶ月）はMustの12件に集中。ShouldとCouldは第2フェーズへ。
Step 3: 実装中の判断はMoSCoWで
スプリント中に新規要望が入っても、「これはMustかShouldか」で速く判断。
Step 4: 半年後の再評価でFM法
リリース後、現場の使い方を見て再評価。「後回し」だった35件のうち、現場のスキルが上がったことで★2→★3に上がる機能や、業務変更で価値が下がる機能が出てくる。
よくある失敗パターン
失敗1: MoSCoWだけで要件を絞り込もうとする
要件発散後、いきなりMoSCoWに行くとMustが膨張します。「全員がMustと言うMust」しか絞り込めず、結果として全部入りになります。
対策: 要件発散後の最初の取捨選択にはFM法を使う。
失敗2: FM法を全フェーズで使い続ける
スプリント中の細かい判断までFM法で評価しようとすると、運用が重すぎて形骸化します。
対策: フェーズに応じて使い分ける。実装中はMoSCoW。
失敗3: 「Won't」を曖昧にする
MoSCoWで「Won't have (this time)」と明記せず、「またそのうち」と濁すと、後で蒸し返されます。
対策: Won't判定の理由と再評価タイミングを記録する。
失敗4: FM法の判定を一度で終わらせる
要件は変わり、現場のスキルも上がります。半年経つと判定が古くなります。
対策: 再評価サイクル（3〜6ヶ月）を最初から計画に組み込む。
Beekle の FM 法ツール（無料）
Beekle では、FM 法を実装した スコープ管理ツール を無料公開しています。
機能:
- 3軸（ビジネス価値 × 現場で使えるか × 技術コスト）で評価し、自動で「作る／後回し／作らない」を判定
- Markdown 形式で要件を入出力
- ユーザーストーリー作成ツール で作ったユーザーストーリーをそのまま取り込み可能
FM の判定結果を社内のチケット管理ツール（Jira、Notion、Backlog など）にエクスポートし、そこで必要に応じて MoSCoW ラベルを付ける運用も可能です。
まとめ
Beekle は要件定義の主役を FM 法 に置いています。MoSCoW を否定するのではなく、フェーズによって向き不向きがあるという前提で使い分けます。
フェーズ | 推奨手法 | 理由 |
|---|---|---|
要件発散後の絞り込み | FM法 | 客観的に「作らない」を決めるため |
リリース計画 | MoSCoW | 順序付けを速く決めるため |
スプリント中の判断 | MoSCoW | 即決が必要なため |
半年ごとの再評価 | FM法 | 状況変化を3軸で反映するため |
「何を作るか」より「何を作らないか」を決める難しさを、両手法を組み合わせて乗り越えてください。
関連記事 / 関連ツール
ご相談
要件の優先順位付けでお困りなら、無料相談で具体的なアドバイスをお出しします。
参考文献
- 白川克『システムを作らせる技術: エンジニアではないあなたへ』日本経済新聞出版（ISBN: 978-4-532-32399-8）
- DSDM Consortium "MoSCoW Prioritisation" (https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html)