ステークホルダ・コミュニケーション重要度:★★★出題: PM1・PM2

機能要件の優先順位付け（MoSCoW分析）と部門間利害調整

きのうようけんのゆうせんじゅんいづけとりがいちょうせい / Requirements Prioritization (MoSCoW) & Cross-Department Coordination

複数の利用部門から相反する要求や予算・納期を超える要望が出された際、Must（必須）・Should（重要）・Could（あれば良い）・Won't（今回は対象外）に分類して合意形成する手法です。

3行速習ポイント

複数の利用部門から相反する要求や予算・納期を超える要望が出された際、Must（必須）・Should（重要）・Could（あれば良い）・Won't（今回は対象外）に分類して合意形成する手法です。
プロジェクト目標（ROIや業務KPIへの貢献度）という共通の物差し（評価軸）を提示することで、声の大きさではなく客観的価値に基づいた合意を引き出します。
試験対策：平成30年午後II問1（機能要件に関する関係者との連携）や午後Iの要件調整問題において、部門間の対立を乗り越える具体的プロセスとして論述します。

図解

図MoSCoW分析による機能要件の優先度階層と調整アプローチ階層・レイヤ構造

プロジェクト目標（KPI貢献度）を物差しとした4段階の要件仕分け

1stリリース必須

M：Must have（必須要件）

一次リリースで欠けると業務や法対応が成立しない中核機能

法令遵守、基幹業務の根幹フロー、プロジェクト目標達成に不可欠な最小限の要件（MVP）であり、最優先で初期開発スコープに確定させます。

⇅ レイヤ間連携・制御境界

優先実装 / 代替可

S：Should have（重要要件）

投資対効果は高いが短期的な運用回避策が存在する機能

業務効率化への貢献度は高いものの、初期稼働時は手作業や既存ツール併用で一時代替できる要件で、余力または直後の改修フェーズで実装します。

⇅ レイヤ間連携・制御境界

2ndリリース候補

C：Could have（希望要件）

利便性向上にとどまりスケジュール・予算制約時に見送る機能

「あれば便利」な画面装飾や個別帳票などの要望です。稼働後の利用状況を見た上で二次リリース以降での対応候補としてバックログ管理します。

⇅ レイヤ間連携・制御境界

スコープ外合意

W：Won't have（今回は対象外）

投資対効果が低い、またはパッケージ標準外のため除外する機能

プロジェクト目標への寄与が薄い独自仕様要求です。標準機能に合わせた業務プロセス変更（Fit to Standard）を合意し、今回スコープから明確に除外します。

💡 単に「要望を却下した」ではなく「二次リリースへ回した」「標準機能＋運用工夫で代替合意した」と論述するのが高得点の鍵

概要と本質

複数の利用部門から相反する要求や予算・納期を超える要望が出された際、Must（必須）・Should（重要）・Could（あれば良い）・Won't（今回は対象外）に分類して合意形成する手法です。プロジェクト目標（ROIや業務KPIへの貢献度）という共通の物差し（評価軸）を提示することで、声の大きさではなく客観的価値に基づいた合意を引き出します。

重要ポイント・コア概念

プロジェクト目標（ROI・業務KPI貢献度・法対応必須性）を共通評価軸に据えたMoSCoW分析（Must/Should/Could/Won't）による客観的優先順位付け
部門間の利害対立や予算・納期制約に対する「業務運用での代替案提示」および「段階リリース（フェーズ分け）」による合意形成
定量的効果例：営業部門と管理部門の追加要望42件をプロジェクト目標への貢献度とMoSCoW基準で評価し、必須18件を一次リリース、残り24件を二次リリースへ振り分けて納期を厳守