, ,

ERP知識シリーズ　The・MoSCoW 第一部 Part1：要求管理における優先度と要求レベルの正しい理解

これまでの投稿に何度も登場してきた「要求管理のMoSCoW」。このMoSCoWは、業務やシステムをAs-IsからTo-Beへ移行するための重要な役割を担います。

ユーザー企業はBPRの実現に向けて最適なERPを選定しますが、これはAs-Isと決別してTo-Beへ移行することを意味します。しかし現場で必ず耳にするのが、「新しいシステムに業務の漏れがないのか心配だ」という声です。これを立証するのは簡単ではありません。当然のことながらERPのTo-Beはユーザー企業のAs-Is業務を前提にしてはいません。つまり、今の仕事の延長線ではなく、全く異なる仕組みへの転換であるため、単純に比較しても何が足りないかは分からないのです。

今回紹介するMoSCoWは、そのAs-IsとTo-Beの“架け橋” となり、ユーザーが「新しいシステムで漏れなく業務を実現できる」ことを示すための仕組みです。本シリーズでは、このMoSCoWの運用方法を5部に分けて解説します。

5部の構成
  1. 要求管理における優先度と要求レベルの正しい理解：
    MoSCoWの優先度（Must／Should／Could／Won’t）と要求レベル（ビジネス／業務／機能／移行）を整理し、その組み合わせとしてプロジェクトスケジュールと結びつけます。あわせて、要求票の主要項目を紹介します。
  2. Must have要求の抽出方法：
    経営課題や3M＋Method、取引パターンを基準に、ERP導入後も必ず必要となる業務を抽出する方法を解説します。
  3. CRPとMoSCoW：
    CRPの3サイクル（理解・展開・収束）とMoSCoWの適用範囲を対応づけ、各段階でどの要求を扱うのかを明確にします。
  4. BPRとMoSCoW：
    業務要求をAs-Isの便利化ではなくTo-Beの業務再設計としてとらえ、MoSCoW票に落とし込むことで改善の根拠を持たせる方法を示します。
  5. ケーススタディ：
    事例を通し、ビジネス要求から機能・移行要求までMoSCoWで管理し、BPRとCRPを組み合わせてAs-IsからTo-Beへ移行する流れを紹介します。
MoSCoWの優先順位と閾値

MoSCoWとは、要求に優先順位を付けるための枠組みであり、頭文字の M, S, C, W が以下を表します。重要なのは、「誰が見ても明らかになる閾値を設けること」です。これにより、属人的な判断で全ての要求がMustに分類されてしまう事態を防ぎ、優先順位付けの意味を保つことができます。

  • Must have：目的達成、法令/税制への対応、顧客の強い要望、設備や原材料といった制約条件
    これを実現しないとERPを本稼働できません。例えば「在庫最適化」「生産性向上」「意思決定の迅速化」といった導入目的に影響する要求、インボイス制度や電子帳簿保存法などの法令遵守、ロイヤルカスタマーの強い要望、さらには 3M（人・設備・材料）やMethod（方法）の制約などが該当します。詳しくは第2部で「Must have要求の抽出方法」を掘り下げます。
  • Should have：取引先（顧客／仕入先）との関係に基づく要求
    これは、社外との取引のためなくてはならない要求ではあるものの、フォーマット変更や手順調整によってERP標準機能で代替できる要求です。「取引先がシステムを変えたからといって合わせてくれるわけがない」と思いがちですが、実際には交渉の余地があり、むしろ導入を機に改善に合意するケースも多く見られます。
  • Could have：社内で完結する要求
    例えば「BOMの一括変更」「製造実績報告時に分析に利用する理由を登録」などの社内で完結する要求です。ERP標準機能で実現できることもあれば、そもそも仕事の仕方が変わって不要になる場合もあります。つまり、ERPによって仕事の仕方そのものを変える契機となる要求群です。
  • Won’t have (this time)：今回は見送る要求
    業務効率をさらに上げられる要求であっても、本稼働を優先するためにリリースから外すことがあります。CRP実施を通じて「なくても本稼働に影響しない」と判断された時点で、ほかの優先度からWon’t haveに格下げされるケースもあります。なお、完全に不要と判断された要求はWon’t haveではなく「キャンセル」として優先度の外に整理します。
要求レベルの4分類と関連付け

ERP導入で「何を必須とし、どこまで実現すべきか」を判断するには、経営課題から業務の仕組み、そしてシステム機能へと階層的にする必要があります。

そこで必要となるのが、要求レベルの4分類です。ビジネス要求・業務要求・機能要求・移行要求という4つの視点で整理し、相互に関連付けて考えることで、「この機能は何のために必要なのか」という疑問に即座に答えられるようになります。これにより、CRPの検証も単なる画面チェックではなく、To-Be業務がビジネス課題に対応できているかに焦点を合わせることが可能になります。

  1. ビジネス要求
    経営課題に相当するもので、プロジェクトの目的と直結します。必然的にMust haveとなります。
    例：「受注→出荷リードタイム短縮」「在庫適正化」「原価の見える化」
  2. 業務（ステークホルダー）要求
    ビジネス要求を実現するために、現場の業務プロセスにどう反映させるかを表す要求です。新しいシステムでの新しい仕事の仕方 を具体化します。
    例（ビジネス要求＝在庫適正化）：「需要情報の精度を高めて計画精度を向上させる」「安全在庫の算定ルールを標準化する」「期限切れ予約在庫の自動解放を行う」
  3. 機能（ソリューション）要求
    業務要求を支える具体的な機能としてERPに期待するものです。
    例（業務要求＝安全在庫の算定ルールを標準化）：「需要予測データを基に安全在庫を自動計算する機能」「期限切れ品を自動的に引当除外する機能」「引当優先度テーブルを柔軟に設定可能とする機能」
  4. 移行要求
    新しいTo-Beを成立させるために、現行システムやデータから確実に移行しておくべきもの。これがなければ業務要求が実現できません。
    例：現行の需要予測データ（過去2年分）を新システムに移行する」「ロット属性（賞味期限・分類コード）を新システムへ正規化して移行する」「出荷済未請求データと整合して、在庫データを移行初日に正しい残高としてセットする」
関連付けの意味

これらの要求レベルを関連付けて整理することによって、CRPでの検証の質を高めます。

ビジネス要求が「在庫適正化」であれば、それを支える業務要求は「需要精度を高める」「安全在庫ルールを標準化する」。さらに具体化した機能要求は「安全在庫自動計算」「期限切れ予約在庫の自動解放」などとなります。そして、それを支える移行要求は「マスタやトランザクションデータの正規化・移行」となります。

もし業務要求やビジネス要求に結びつかない機能要求があったとすれば、それは往々にして「現行システムにあったから」という理由だけで残っているものです。その場合は、逆算して「To-Beの業務に本当に必要なのか？」を問い直すことが重要です。

MoSCoWに起票されない業務要求

ERP導入で要求を整理していくと、「では全ての業務をMoSCoWに起票すべきなのか？」という疑問が生まれます。答えは“No”です。

製造業を例にすれば、仕入れて、製造して、受注して、出荷して、売上計上して、請求して、入金して、財務諸表を出力するといった一連の流れは、ERPであれば当然サポートされている基本業務です。これらを逐一MoSCoWに記載する必要はありません。

同じように「受注入力ができること」のように、ERPの存在を前提とすれば当たり前に備わっているものを業務要求として挙げるのは誤りです。これは「車を買うときに“タイヤが4つ付いていること”を要求する」のと同じで、言うまでもない要求に過ぎません。

MoSCoWで扱うべきは、「この業務が本当にTo-Beでどう実現されるべきか」「どのような条件を満たす必要があるか」といった差分や論点です。したがって、網羅性を担保するには、業務そのものをすべて起票するのではなく、基準となる観点を明確にすることが重要です。

その観点とは、次の4つです。

  1. トリガーイベント
    業務が始まるきっかけ（例：顧客からの注文、製造工程での仕損じ、締日など）。これを押さえておけば、自然と必要な業務の流れが見えてきます。
  2. 取引パターン（ものの流れ）：
    顧客・仕入先との取引や社内のものの流れを整理しておけば、仕入や出荷などの入出庫に関する漏れを防ぐことができます。
  3. 取引パターン（決済の流れ）：
    ものの流れと関連して、顧客・仕入先・金融機関との決済の流れを整理しておけば、入出金に関する漏れを防ぐことができます。
  4. 制約条件（3M＋Method）
    仕人・設備・材料・方法といった制約は、システムが変わっても必ず考慮が必要な要素です。これを整理すれば、Must have業務は自然に浮かび上がります。

この4つを手がかりにすれば、MoSCoWに何を記載すべきか、また逆に「記載しなくてもよい業務」は何かを判断できます。

まとめ

ここまでで整理したのは、MoSCoWにおける優先度と要求レベルの正しい理解でした。次に見ていくのは、この二つをマトリクスとして組み合わせ、ERP導入プロジェクトのスケジュールに沿って「どの段階で、どの要求を固めるのか」を明確にすることです。

その上で、要求票の主要項目やステータス管理を設計しておくことで、一覧性とトレース性を確保しながら、要求を確実に検証へと結びつけられるようになります。続く第一部Part2では、その具体的な方法を詳しく解説します。