ERP知識シリーズ The・MoSCoW 第一部：要求管理における優先度と要求レベルの正しい理解【後編】
ユーザーから「要求はいつまでにあげればいいんですか？」と尋ねられます。プロジェクトでこの疑問が生まれるのは、プロジェクト開始時点に「いつ、どの要求を決めるべきか」という基準が定義されていないからです。要求の優先度とレベルを正しく理解できたところで、次の焦点はそのタイミングに移ります。
後編の本稿では、優先度と要求レベルをマトリクス化し、それをERP導入プロジェクトのスケジュールに関連付けることで、どの段階でどの要求を判断すべきかを具体的に示していきます。
優先度 × 要求レベルマトリクスとプロジェクトスケジュールの関係
この二つの軸（優先度／要求レベル）をマトリクス化すると、それぞれの組み合わせに応じて「いつ起票して、いつまでに決めるべき要求なのか」が明確になります。ERP導入プロジェクトのスケジュールに関連付けると、次のようになります。
- Must have／Should have × ビジネス要求 ：
ERPプロジェクト開始前、すなわち構想策定段階で挙げておくべき要求です。これはそのままRFP（提案依頼書）に記載する事項になります。ERP導入の目的＝プロジェクトの大前提なので、ここを固めずにERP導入プロジェクトを開始することはできません。 - Must have／Should have × 業務要求：
この要求群は、フェーズ1完了までに起票しておくことが求められます。理想はプロジェクト開始前の構想策定フェーズで、プロジェクトの目的に沿った業務要求を挙げておくことです。ただし、フェーズ1のTo-Beヒアリングを通じて新しい気付きを得て、そこから追加されるケースもあります。
これらの要求は、CRPサイクル1または2で検証されます。サイクル1では、トレーニングで得た理解を踏まえながら、新しい仕事の仕方を実際に試し、限定的ながら検証を始めます。サイクル2になると、例外や応用を含む広い範囲を対象にし本格的な検証が行われます。 - Must have × 機能要求：
この要求群は、ビジネス要求から導かれる機能です。例えば「在庫適正化」というビジネス要求に対しては、「安全在庫を自動算定する機能」「期限切れ在庫を自動解放する機能」などがこれにあたります。
起票のタイミングはフェーズ1のTo-Beヒアリングで、業務要求を整理すると同時に、それを実現するために必要となるERP機能のおおよそのあたりを付けておきます。
そして本格的な検証はCRPサイクル2にて行います。サイクル2では業務全体に踏み込み、例外や応用も含めたプロセスを試す中で、Must have × 業務要求を実現するために必要な機能が漏れなく備わっているかを確認し、ERP標準機能で対応できるか、あるいは拡張が必要かを明確にしていきます。 - Should have × 機能要求：
この要求群は、CRPサイクル2で扱います。対象となるのは顧客や仕入先との取引に関わる要求であり、納品書や発注書などの帳票フォーマットや顧客／仕入先品番のデータ変換など、外部とのやり取りを前提とする機能が中心です。
ただし、インターフェース要求については、フェーズ1でスコープが確定しているので、CRPサイクル1で新システムのプロセスを通じて必要可否を判断し、リストアップしておきます。ゆえに、CRPサイクル2で検証するのは主に対外帳票や外部取引の項目レベルであり、ERP標準機能で代替可能かどうかを確認しながら、Should haveとしての妥当性を定義していきます。 - Could have × 業務要求：
この要求群は、社内で完結する業務に関する要求です。プロジェクトの目的や法令遵守に直接関わらないため、Must haveやShould haveではありませんが、業務効率や成熟度を高める役割を果たします。
例えば経理部門では、「入金消込を取引先ごとに自動集計し、未消込リストを出力する」といった要求が挙げられます。これがなくてもシステムは稼働しますが、あれば決算スピードや確認精度が向上し、業務が一段階高度化します。
つまり、Could haveに該当するのは、必須ではないが導入すれば業務の質を高める要求です。ERPを単に稼働させるだけでなく、将来的な発展や業務改善を後押しする余地として整理されます。 - Could have × 機能要求：
社内で完結する機能要求には「システムを実際に操作して初めて気付く」という特性があります。そのため、起票のタイミングはトレーニングやCRPサイクル1であり、これをCRPサイクル3までに検証するのが原則です。
ただし、CRP検証を後回しにすることも可能です。これは、ユーザー企業がノーコード開発を軸とした内製化体制を備えており、拡張機能を自社で開発・対応できる場合に限ります。注意すべき点は、社内業務の効率化や利便性に関わる要求であり、ERP標準でそのまま実現できるか、あるいは仕事の仕方を変えることで不要になるかを見極めることです。 - Won’t have (this time)：
本稼働に支障がないと判断された時点でここに移されます。多くは「効率をさらに上げるが今すぐでなくても良い」要求であり、本稼働後の拡張やエンハンスリクエストへと位置づけられます。
優先度と要求レベルのグレーゾーン
MoSCoWを実務で運用すると、「これは業務要求なのか、機能要求なのか」と迷うケースがあります。特に帳票のように業務と機能が直結しているものは、グレーゾーンになりやすい領域です。
例えば納品書や発注書を考えてみましょう。業務要求の出発点は「納品情報を顧客に通知する」「仕入先に発注内容を確定して伝える」といった取引上の必要性です。一方、これをシステムで実現する手段が「納品書を出力する」「発注データを仕入先がWebで確認できるようにする」という機能要求です。つまり、同じ要求でも「業務としての目的」と「機能としての手段」に切り分けて捉えることが重要になります。
優先度で見れば、これらは顧客や仕入先とのやり取りに関わるため、基本的にはShould haveに属します。納品書は「確かに納品した」という事実を顧客と共有する証憑であり、発注書は「仕入先に正式依頼を行う」ための根拠です。いずれも外部取引を円滑に進めるためには必要ですが、ERPの稼働そのものを左右する「Must have」ではありません。ただし、取引先から「この形式でなければ取引できない」と強い要望がある場合や、法令によって特定の書式が義務付けられている場合は、Must haveに引き上げられることもあります。
このように、帳票のような要求は業務要求と機能要求の両側面を持ち、かつ優先度も状況によって変動するため、プロジェクトでは「目的（業務要求）」と「手段（機能要求）」を明確に切り分けるとわかりやすくなります。これにより、属人的な判断で曖昧に扱われることなく、合理的に優先度を整理できるようになるでしょう。
「Must have × 機能要求」の誤解を避ける
ERPプロジェクトで「生産性の向上」が目的に掲げられると、操作の手間を理由にした要求が次々に挙がります。例えば「受注入力をもっと簡単にしたい」といったものです。一見すると生産性向上に直結しそうですが、これをそのままMust haveに分類してしまうのは早計です。
重要なのは、その要求が本当にビジネス上の効果を持つのかを定量的に検証することです。例えば、受注入力にかかる時間や件数を分析した結果、それが全体の業務工数の数％しか占めていないのであれば、システム改修による投資効果は限定的です。逆に、主要取引のボリュームが集中していて遅延や誤入力が顧客対応に影響しているのであれば、BPRや機能改善を含めて検討する価値があります。つまり、Must haveの機能要求になるのは「手間だから」ではなく、定量的に見てもビジネス課題に直結していると判断できるものです。そしてその判断を下すには、業務プロセスの見直し（BPR）を含めた検討が不可欠です。ERP導入は単に操作を楽にするものではなく、業務そのものの進め方を変える機会であるという原則を忘れてはいけません。
この視点は、MoSCoW起票における 「正当な理由の明示」や「却下された場合の影響」 に記載する事項です。なぜこの要求をMust haveとするのか、その根拠が定量的に示されていれば、後の検証や優先順位付けに説得力を持たせることができます。逆に根拠が弱ければCould haveやWon’t haveに整理され、要求は自然と絞り込まれていきます。
次に、要求事項の「優先度」と「要求レベル」以外の項目について解説します。主要な項目は次の通りです。
要求を明確にするための主要項目
MoSCoWを実務に適用するには、要求を名前や優先度だけでなく、誰が判断し、どの場面で検証し、どのように解決へつなげるかまで整理することが必要です。そのため、要求票には以下の主要項目を記録しておきます。これにより、後から振り返ったときにも「なぜこの要求が必要だったのか」「どう検証されたのか」が一目で分かり、検証性とトレース性が大幅に高まります。
- 要求の定義：ユーザー部門記載
要求名称：20文字以内で簡潔に表現します。形式は「名詞（何を）＋動詞（どうしたいか）」とすればわかりやすくなります。例えば「在庫データを自動集計する」など。曖昧な表現を避け、誰が見ても意図が伝わることが重要です。
要求説明：名称を補足し、業務的な狙いや背景を明確にします。「在庫差異の手作業確認に時間を要しているため、在庫データを自動集計し、日次で確認可能にしたい」といった具合に、現状の課題や改善効果を記載すると説得力が増します。 - 責任と体制：ユーザー部門記載
意思決定者：要求の妥当性を評価する責任者です。通常はBPO（Business Process Owner）が担います。BPOは業務に精通しており、新しい仕事の仕方に関する意思決定を行う役割を持ちます。
主担当チーム：要求を起票した主体です。販売、生産、購買など主要プロセスごとのチームを明記します。
関係チーム：主担当以外で影響を受ける部門です。例えば「経理主導の原価管理」に関する要求であれば、生産や購買も関係チームとして記載します。これにより、横断的な合意形成の漏れを防げます。 - 検証と影響：ユーザー部門記載
受入基準：どの状態になれば「この要求は満たされた」と判断できるかを定義します。シナリオテストで確認可能な形にすることがポイントです。
正当な理由：なぜこの要求を起票するのかを明記します。例：「在庫誤差による月次決算遅延を防ぐため」など。これが弱いと、要求がCould haveやWon’t haveに整理されやすくなります。
却下された場合の影響：実現しなかったときに残る工数負担や業務リスクを明確にします。例：「月次決算に人手が追加で10時間必要になる」。定量的に示すと説得力が増します。
検証サイクル：CRPサイクル1〜UATのどの段階で検証するのかを指定します。早めに検証すべきものか、本稼働直前のユーザー受入で確認すべきものかを区分けすることが大切です。 - 解決と実装：ベンダー記載
解決アプローチ：標準機能設定、軽微な拡張開発、運用対応、エンハンスリクエストなど、実現手段の方向性を示します。
ソリューション説明：解決アプローチを具体化した説明を記載します。対象モジュールや拡張開発のIDとひも付けることで、検証から開発・移送までを一貫して追跡できるようになります。
補足：要求名称に「〜や〜などの」といった表現が含まれている場合は、複数の要求がひとまとめにされているサインです。この場合は必ず要求を分解し、個別に記載してください。分解することで検証性とトレース性が保たれ、要求が実現したかどうかを正しく確認できます。
MoSCoWステータスとの関連づけ
これらの項目は、MoSCoWステータスの流れと結びつけることで一覧性とトレーサビリティをさらに高めます。
- プロダクトバックログ：
起票直後の状態。まだ検証対象とはされていない要求 - 検証対象：
ビジネスプロセスオーナーが承認し、どの場面で検証するかが決まった要求 - 再検証：
検証の結果NGとなり、再度検証が必要になった要求 - ソリューション定義済み（以下の三つに分類）：
標準機能で対応できることが確認された要求
軽微な拡張開発で対応可能と確認された要求
難易度が高い拡張開発が必要と確認された要求 - 延期：
プロジェクトの範囲内だが、今回は先送りする要求。本稼働後や次フェーズでの対応を前提とする - 検証対象外：
起票はされたが、今回のプロジェクトの範囲外にある要求。将来別プロジェクトで検討対象となる可能性がある - キャンセル：
一度は起票されたが不要と判断された要求。例：As-Is前提での要求がTo-Be設計により無効化された場合
このように要求票とMoSCoWステータスを連動させることで、要求がどこから来て、誰が判断し、どの検証を経て、どのソリューションに落ち着いたかを一気通貫で追跡できるようになります。
まとめ
要求の優先度と要求レベルを整理し、それらをプロジェクトスケジュールに結びつけることで、MoSCoWは「どの要求を、いつ判断すべきか」を明確にする枠組みとなります。さらに、要求票の主要項目とMoSCoWステータスを連動させることで、要求の発生から検証、そしてソリューションへの落とし込みまでを一貫して追跡できる仕組みが整います。ここまでで、MoSCoWを「体系的に理解する」段階は完了しました。
次の第二部では、その中でも最も重要なMust have要求の抽出に焦点を当てます。経営課題や3M＋Method、取引パターンといった制約条件を起点に、システムが変わっても必須となる業務をどのように見極めるかを具体的に解説していきます。
