要件定義の優先順位付け｜「全部盛り」を防ぐMoSCoW分析と捨てる技術

本連載について
この記事は、IT現場で最も炎上しやすいと言われる「要件定義」の進め方を、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全7回のシリーズです。（※どの回からでも単独でお読みいただけます）

第6回となる今回は、予算と納期のパンクを防ぐ「優先順位付けと捨てる技術」についてお届けします！

「あれもこれもと要望を詰め込んだら、予算も納期も大幅にオーバーしてしまった……」
「結局どれが一番大事なのか分からず、開発チームが混乱している」

要件定義の終盤、こうした「パンク状態」に陥っていませんか？前回までに、第4回（業務・システム）や第5回（非機能要件）を通じて、やりたいことのリストは完成しました。しかし、すべての要望を100%叶えられるプロジェクトは稀です。

今回は、限られた資源（予算・期間）の中で最高の結果を出すための「優先順位付け」を学びます。旅行の「パッキング（荷造り）」を例に、プロジェクトを成功に導く「捨てる技術」を紐解いていきましょう。

「全部盛り」のカバンは閉まらない

想像してみてください。家族旅行の前夜、大きなスーツケースを広げています。

全員の要望をそのまま詰め込んだら、カバンは絶対に閉まりません。無理に閉めても、重すぎて運ぶことができず、旅行そのものが中止になってしまいます。

システム開発も全く同じです。予算と納期という「カバンのサイズ」は決まっています。 「何を入れるか」を決めることは、同時に「何を諦めるか」を決めることなのです。

優先順位を「重要」「普通」「低い」といった主観的な言葉で分けると、必ず関係者間で揉めます。（誰もが自分の要望を「重要」だと言い張るからです）。そこで活用したいのが、客観的な基準で要件を仕分ける「MoSCoW（モスコウ）分析」です。

ランク	意味	実務での判断基準	旅行の例え
M（Must）	絶対必要	これがないと業務が回らない、法的に必須。	航空券、パスポート、財布。
S（Should）	重要（高い優先度）	必須ではないが、ないと業務効率が著しく下がる。	予約した宿、予備の着替え。
C（Could）	できれば欲しい	あれば便利だが、なくても現行業務は回る。	ガイドブック、お菓子。
W（Won’t）	今回は見送り	価値はあるが、予算や期間内に含めない。	新しいカメラの購入。

「どれもMustだ！」と主張する関係者に対し、「もしこれが無かったら、旅行（業務）は中止になりますか？」と問いかけるのがリーダーの役割です。このフレームワークを使うことで、「感情」ではなく「論理」で、何をカバンに入れるべきかを議論できるようになります。

優先順位を絞り込む際、リーダーが持つべき「物差し」を整理しました。

視点	リーダーが自分に問いかけるべきこと	現場でのアクション
① 最小構成（MVP）	「まずはこれだけで出発できるか？」	Must要件だけで業務が回る最小単位（MVP）を特定し、早期リリースを検討する。
② 代替手段の有無	「システム化しなくても、手運用でカバーできるか？」	低頻度の作業は「今回は手運用のまま」と割り切り、システム化の範囲を絞る。
③ 費用対効果（ROI）	「その機能を作るコストに見合う利益（効果）は出るか？」	開発コストに対して利用頻度が低い機能は、CouldやWon’tへ移動を促す。

優先順位を付ける作業は、決してネガティブな「諦め」ではありません。限られたエネルギーを、本当に価値のある機能に「集中」させるための前向きな決断です。

この「捨てる技術」が身につけば、プロジェクトがパンクして空中分解するリスクを劇的に減らすことができます。

要件を絞り込む会議の際、リーダーは以下の3点を意識してファシリテーションを行いましょう。

[ ] Must要件を2割に絞る
全要件のうち、本当に「Must（これがないとリリースできない）」と言えるものを、全体の20〜30%程度まで絞り込むよう調整できているか。
[ ] 「手運用」を代替案にする
実装コストが高い要望が出た際、すぐに却下するのではなく「マニュアル対応（手作業）で逃げることは可能か？」をユーザーと検討しているか。
[ ] フェーズ分けを提案する
「やりたいこと」を無理に一度に詰め込まず、「リリース後の改善（フェーズ2以降）」として切り出す合意を取れているか。