ERP知識シリーズ The・MoSCoW 第三部：CRPとMoSCoW【後編】CRPで磨かれる要件定義
前編では、RFPに機能要求を細かく書き連ねることの危うさや、PoCを誤解した運用が誤ったMoSCoWを生み、結果としてCRPの質を損なうことを挙げました。CRPを正しく機能させるには、まずこうした前提を整えておくことが条件となります。
では、整えられた前提のもとでCRPを実施すると、MoSCoWはどのように進化していくのでしょうか。起票直後のMoSCoWはまだ抽象的で、検証に耐えるには不十分です。しかし、CRPを重ねることで要求は具体化し、不要なものはキャンセルされ、残るべきものは受入基準を備えた内容へと磨かれていきます。
本稿では、そのプロセスを三つのステップに沿って整理します。
MoSCoWを高める三つのステップ
- ステップ1：As-Is要求のキャンセルとTo-Be化
- ステップ2：受入基準を正確にする
- ステップ3：ソリューションを定義する
ステップ1で不要なMoSCoWを整理し、検証対象を絞り込んで、ステップ2で残った要求の受入基準を精査します。その上でステップ3に進むと、ソリューションは設計や運用に直結する具体性を備えるようになります。
ステップ1：As-Is要求のキャンセルとTo-Be化
構想策定までに起票されたMoSCoWは本来To-Beの業務要求であるべきですが、中にはAs-Isの踏襲にとどまるものも散見されます。こうした要求は、CRPの中でキャンセルされたり、To-Be要求へと書き換えられていきます。
鍵となるのは、ユーザーがTo-Beを理解するプロセスと、その体験から得られる気づきです。
- To-Beヒアリングで現行とは異なるやり方を知る
- 製品トレーニングでERPのコンセプトを学ぶ
- CRPサイクル1で基本的な要求を実機で評価する
この一連の流れを経て、ユーザーは「残すべき要求」と「キャンセルすべき要求」を見極め、As-IsにとどまっていたものをTo-Beへ書き換えることができるようになります。
例えば「受注入力時に在庫を必ず確認したい」という要求は、一見もっともらしく思えますが、在庫引当が自動で担保されることを実体験すれば、その必要性はなくなると理解できます。逆に「出荷計画を立てやすくしたい」という漠然とした要望は、「受注情報から出荷計画を立案する」という要求へと具体化されます。その際、納品リードタイム、輸送ルート、納入先カレンダー、出荷品の重量といった条件を考慮に入れることで、実機で検証可能なシナリオへと発展します。ここで大切なのは、ベンダーに「不要です」と言われて納得するのではなく、ユーザー自身がシナリオ体験を通じて理解することです。
もっとも、要求をキャンセルするのは心理的に容易ではありません。自ら出した要望を引っ込めることには抵抗感が伴います。それでもユーザーが納得できるのは、CRPを通じて「本当に必要なこと」と「そうでないこと」の境界が明確になるからです。そしてその背景には、組織的に変化を受け入れるためのチェンジマネジメント（OCM）の土台があります。OCMの観点については別の記事で詳しく扱いましたが、ここで強調しておきたいのは、OCMによって、ユーザーは単に要求を削除するのではなく、ERPに合わせて業務のあり方を再定義することに意義を見出せるのです。
さらに、キャンセルの数そのものが変革を示す指標となります。多くの要求が見直され、不要と判断されるということは、それだけAs-Isからの脱却が進んでいる証です。MoSCoWの更新履歴をたどれば、単なる削除の記録ではなく、組織がどのように変化を受け入れていったかの軌跡を読み取ることができます。
ステップ2：受入基準を正確にする
起票直後のMoSCoWは「〜を簡単にできること」といった抽象的な表現にとどまり、CRPで検証するには情報が不足しています。実機検証に進むと多くの場合、「標準機能で実現できるか」という適合性に意識が向きますが、必要なのは検証を成り立たせるための稼働性の視点であり、その具体性を高めていくことです。
この具体化はユーザーとベンダーの密なやり取りによって進みます。「要求はユーザーが書くもの」と決めつけるのではなく、初めはベンダーが伴走し、どう書けば受入基準になるかを示す。ユーザーはその過程でMoSCoWの書き方を学び、ベンダーは業務の背景を理解してシナリオに落とし込む。この相互補完のプロセスが、MoSCoWを検証可能な形へと育てます。
受入基準を整理する視点には以下があります。
- データ状態：在庫有無、引当優先順位、代替品、ロットや有効期限など
- 条件の幅：取引先、品目、税区分、締め日の違いなど
- トリガー：顧客からの注文、欠品の発生、月次処理など
- 例外やエラーの扱い：入力ミスや制約違反が起きた際の警告・ブロック・承認による解除可否
- 権限と操作手順：誰が、いつ、どの画面や設定を使うのか
- 合格判定の基準：どの状態をもって「成立」とみなすのか
例1：受注時に仕入先直送を実行する
- データ状態：在庫を持たない前提とし、仕入先リードタイム、輸送ルート、納入先カレンダーといった必要データが揃っていること。
- 条件の幅：直送の可否は仕入先と仕入品の組み合わせで決まる。
- トリガー：顧客から条件に合致した仕入れ品の注文が入った際に直送フローを起動する。
- 例外やエラーの扱い：受注がキャンセルや変更された場合、その内容が発注情報にどう影響するかを把握できるようにし、変更や取消の可否を判断できること。
- 権限と操作手順：受注が登録された後、購買担当が仕入先への発注を行う。仕入先から発送通知を受領したのち、購買担当が仕入計上を行い、営業担当が納入先カレンダーを踏まえて売上計上を行う。
- 合格判定の基準：顧客指定の納品場所が発注情報に正しく反映され、仕入先からの発送通知に基づいて仕入計上されること。さらに、納入先カレンダーを踏まえて顧客側で納品済みと認識されること。
例2：製造負荷超過を調整する
- データ状態：ボトルネック工程の負荷が100％を超えている場合、その超過率、該当品目、段取り時間を明示する。能力値や段取り条件はマスタで保持される。
- 条件の幅：対象は主要拠点の全ライン・全工程とし、週次で立案される製造スケジュールを検証対象とする。
- トリガー：新規大量受注が登録された時点、または週次のスケジュール更新時に負荷計算を実行し、超過が発生すれば最適化処理を起動する。
- 例外やエラーの扱い：ボトルネック負荷を100％以下に調整すると、受注納期に間に合わなくなる場合はアラートを表示し、そのリスクを明示する。そのうえで順序変更や別ライン振替などの候補を提示し、調整不能な場合は承認者の判断を求める。
- 権限と操作手順：生産管理担当がスケジュール画面で負荷計算を実行し、候補案を確認。承認者が調整後のスケジュールを確定する。
- 合格判定の基準：最適化後のスケジュールで、ボトルネック工程の負荷が100％以内に収まり、調整内容（順序変更・振替）がスケジュールに反映されること。
前述のように、こうしたやり取りを通じてMoSCoWは検証可能な形へと整えられていきます。初めはベンダーが伴走し、どう書けば受入基準になるかを示し、ユーザーはそのやり取りを通じてMoSCoWの書き方を学んでいきます。ベンダーは同時に業務の背景を理解し、それをシナリオへ落とし込みます。
その結果、操作の羅列ではなくTo-Be業務に沿って整理された要求となり、ベンダーにとっても業務のイメージをつかみやすいものになります。こうして、実機検証がユーザーの想定に沿って進められるのです。
ステップ3：ソリューションを定義する
最後のステップは、検証を設計へつなぐソリューション定義です。単に「標準機能でできるか否か」を答えるだけではなく、どの条件下でどの機能をどう組み合わせ、誰がどのように操作して業務を成立させるのかを明らかにする作業です。
RFP段階ではベンダーの回答は「どの機能で対応可能か」といった概要にすぎません。例えば「仕入先直送を実現できるか」という要求に対して、回答は「購買モジュールの直送機能で対応可能」といった程度にとどまるでしょう。
しかしCRPを経て受入基準が具体化されると、回答内容は「特定の品目のみ受注時に直送が選択される」「顧客注文に基づいて納品先が発注書に反映される」「仕入先から発送通知を受けて購買担当が仕入計上を行い、その後に営業担当が売上計上を行う」といった具合に、条件、データの流れ、役割分担、画面操作まで具体化します。
つまり、RFPでの回答が「機能の有無」の説明にすぎなかったものが、CRPを通して「どの条件と順序で業務を成立させるのか」を示すソリューションの要件定義へと進化していくのです。
MoSCoWがもたらす変革
CRPを通じて磨かれたMoSCoWは、もはや単なる要求の一覧表ではありません。ここに残った要求は、組織を変革へ導く羅針盤となります。残った要求は優先度の閾値を満たし、受入基準を備え、実機で検証されたものばかりです。その成熟度は、組織がどこまで変革を進めたかを示す指標となります。
特に重要なのは、MoSCoWが更新される過程そのものです。不要なものは取り下げられ、残るべきものは基準を伴う要求として定着する。その積み重ねが組織の学習であり、To-Be像を受け入れる準備でもあります。キャンセル数は変革の進展を示す指標であり、更新履歴は変化の軌跡を記録するものです。
こうして鍛えられたMoSCoWは、Must・Should・Could・Won’tを通じて、稼働後の基盤、将来の改善余地、意思決定の痕跡を明確に残します。つまりMoSCoWは優先度リストを超えて、変革の歩みを記録する“実務のバロメーター”なのです。
次の第四部では、このMoSCoWがBPRと結びつき、業務再設計を支える力としてどのように働くのかを解説していきます。
