要件の優先順位付け： 「全部盛り」でパンクさせないための取捨選択（MoSCoW分析）
「あれもこれも必要だと言われ、予算を大幅にオーバーしてしまった……」
「結局、何が一番大事なのか分からなくなり、中途端なシステムが出来上がった……」
要件定義の終盤、必ずと言っていいほど直面するのが、この「全部盛り」の壁です。
前回は、[要件定義シリーズ第5回：非機能要件の落とし穴]で、システムの品質（燃費や点検）について学びました。これで「やりたいこと（機能）」と「備え（非機能）」がすべて出揃ったわけですが、そのまま全部を叶えようとすると、プロジェクトは確実にパンクします。
今回は、家族旅行の「パッキング（荷造り）」や「観光スポットの絞り込み」を例に、限られたリソースの中で最大の結果を出すための優先順位付け（MoSCoW分析）の技術を解説します。
なぜ「優先順位付け」が必要なのか？（カバンは必ずあふれる）
旅行の準備をするとき、持っていきたいものをすべて並べると、大抵はスーツケースに収まりません。「念のためこれも」「あったら便利かも」という要望は無限に膨らみますが、持っていける荷物の量（予算・期間・リソース）は決まっているからです。
システム開発も全く同じです。
- リソースは有限： お金、時間、エンジニアの体力には限りがあります。
- 複雑性はリスク： 機能を増やせば増やすほど、バグが増え、テストの時間は膨らみます。
リーダーの役割は、単に要望を聞くことではなく、「今回の旅の目的を達成するために、何を持っていくべきか」を峻別することです。
MoSCoW分析：要望を4つのバケツに分ける
優先順位を「高・中・低」で分けると、結局みんな「高」にしてしまいます。そこで役立つのが、明確な基準で4つに分類するMoSCoW（モスコウ）分析です。
M：Must have（絶対必要：これがないと旅が成立しない）
- 旅行なら： 「パスポート、航空券、宿泊先の確保」。これがなければ旅行自体が中止になります。
- システムなら： 「法対応（増税対応）」や「コア業務（受注・決済）」。これがないとリリースする意味がない、致命的な機能です。
S：Should have（重要：なくても旅はできるが、かなり困る）
- 旅行なら： 「着替えの予備、スマホの充電器」。なくても現地で買えますが、ないと不便で不快な思いをします。
- システムなら： 「CSV出力機能」や「検索の高速化」。手作業でカバーは可能だが、現場の負荷が高すぎるため、次点で重要視すべき機能です。
C：Could have（あったほうがいい：あれば旅がもっと楽しくなる）
- 旅行なら： 「ガイドブック、おやつ、予備のカメラレンズ」。あれもこれもと詰め込んで、カバンのカギが閉まらなければ真っ先に置いていくものです。
- システムなら： 「ダッシュボードのグラフ表示」や「細かい通知設定」。便利ではあるが、主要業務には直接影響しない「おまけ」の機能です。
W：Won’t have (this time)（今回はやらない：次の旅まで取っておく）
- 旅行なら： 「重厚なハードカバーの本、ドローン」。魅力的ですが、今回の予算や時間、カバンの空き状況では「持っていかない」と明確に決めるものです。
- システムなら： 「将来的なAI連携」「高度な自動化」。将来のフェーズで検討すべきもので、今のリリースには含めないと合意します。
リーダーが意識すべき「トレードオフ」の視点
優先順位を決める際、リーダーは関係者に対して「トレードオフ（あちらを立てればこちらが立たず）」の現実を突きつける必要があります。
旅行の例：取捨選択の現場
「豪華なディナーも食べたいし、スカイダイビングもしたい。でも予算は足りない」というとき、あなたならどう言いますか？
「いいよ、全部やっちゃおう！」と安請け合いするのは、結果的に旅を台無しにする無責任なリーダーです。 「予算的に厳しいから相談なんだけど、ご飯を少しカジュアルなものに変えてアクティビティを全部楽しむ？ それとも、今回はアクティビティを一つ我慢して、最高においしいディナーに全力を出す？ みんなはどうしたいかな？」
このように、「何かを得るために、何を諦めるか」という選択肢を提示し、納得感を引き出すことが合意形成の鍵です。
優先順位付けを成功させる3つのステップ
現場の「全部盛り」を解きほぐし、プロジェクトを現実的な形に収めるための実践的な手順を紹介します。
ステップ1：第1回の「企画構想（コンセプト）」を再確認する
迷ったときは、プロジェクトの原点である「解決すべき課題」と「狙い」に立ち返ります。例えば「残業削減」が狙いなら、「この機能は本当に残業を減らすのか？ それとも個人のこだわりか？」と問い直します。企画構想という「旗印」こそが、議論を収束させる最強の物差しになります。詳しくは、[要件定義シリーズ第1回：企画構想]をぜひ読み返してみてください。
ステップ2：エンジニアに「実装コスト」を見積もってもらう
ユーザーが「簡単にできるはず」と思っている機能が、実は既存システムとの連携などで膨大な開発工数を必要とすることがあります。「その便利機能一つで、開発全体の2割の期間を使い切りますが、他の重要機能を削ってでも入れますか？」と現実的なコストを突きつけることで、ユーザーは冷静な判断（取捨選択）ができるようになります。
ステップ3：「やらないことリスト」を明文化する
「検討中」として曖昧に残すのではなく、「今回のリリースには含めない（フェーズ2以降の課題）」と明記することが重要です。これをドキュメントに記録し、ステークホルダーと合意することで、ずるずると要件が膨らむのを防ぎ、プロジェクトを予定通りに出発させることができます。
まとめ：パッキングの質が「旅の足取り」を軽くする
要件定義の優先順位付けは、決して「夢を削る作業」ではありません。「確実に成功させるために、焦点を絞る作業」です。
- MoSCoW分析： 要望を「最優先（Must）」から「おまけ」まで4段階で分ける。
- トレードオフ： すべては手に入らない。何かを捨てる決断をリードする。
- フェーズ分け： 欲張りすぎず、まずは「これだけで旅が成立する最小限のプラン（MVP：Minimum Viable Product）」で出発する。
パンパンに膨らんだスーツケースでは、移動だけで疲れてしまいます。必要なものだけを厳選した身軽なプランでこそ、プロジェクトは軽快に進み、本当に価値のあるゴールにたどり着けるのです。
次のステップ：誰が読んでも迷わない「旅のしおり」
優先順位が決まり、ついに「何を、どこまでやるか」が確定しました。最後はこれを、自分たちだけでなく、開発者や運営者が読んでも一寸の迷いもないドキュメントにまとめ上げる必要があります。
次回は、シリーズ最終回。「要件定義書の書き方：誰が読んでも迷わない『旅のしおり』の最終仕上げ」について解説します。 現場で本当に使われる「生きたドキュメント」を作るための記述のコツをお伝えします。
次の記事を読む：要件定義書の書き方：誰が読んでも迷わない「旅のしおり」の最終仕上げ
