ERP知識シリーズ The・MoSCoW 第二部：Must have の抽出方法【前編】法令遵守と顧客の強い要望
ERPを導入しようとしたとき、多くの企業が最初に不安に思うのが「必須の機能が不足していたらシステムを稼働できない」という点です。この不安を取り除くためには、ERP選定の構想策定段階で、必須となる要求をあらかじめ明確にしておくことが重要です。今回のMoSCoW第二部では、その必須要求であるMust haveをどのように抽出するのかに焦点を当てて解説します。
目的が弱いRFPの行き着く先
RFPには、ERP導入を決めた背景やプロジェクトの目的が記載されます。本来それはMust have要求に直結するものなのですが、中には「システムの保守切れや老朽化のため刷新する」だけで説明を終えてしまうRFPがあります。
このようなRFPには共通する特徴があります。記載されているのは大まかなAs-Is業務フローと、500件を超える細かな機能要求です。しかも、その多くは現行システムにすでに備わっている機能の焼き直しに過ぎません。それでいてプロジェクト方針には「標準機能を最大限活用」と書かれています。
このようなRFPでプロジェクトが始まった場合、ユーザーは「新しいシステムになっても自分たちの仕事は変わらない」と受け止めてしまいます。その結果、ERP導入は「新しいシステムは自分たちの仕事を楽にしてくれるだろう」という期待から始まり、やがてそうではないことに気付く段階を迎えます。落胆の矛先はベンダーやERPを選定したメンバーに向けられるでしょう。
問題の根本は、プロジェクトメンバーやユーザーに意識改革を促す材料がRFPに含まれていないことにあります。「システムの保守切れや老朽化」といった要素は、ただのきっかけに過ぎません。ところが、それだけでRFPの目的を語ってしまうと、プロジェクトは脆い土台のまま始動してしまいます。結局のところ、それを招いているのは、RFPに記された目的が不十分だからなのです。
構想段階におけるMust have要求の分類
第一部後編で触れたように、Must have要求のうちビジネス要求は、プロジェクト開始前の構想策定段階で必ずあげておく必要があります。業務要求についても、理想を言えばこの段階で整理しておくことが望ましいでしょう。もっとも「洗い出す」といっても、この時点ですべてを網羅的に列挙する必要はありません。一定の枠組みに沿って検討を進めれば、本当に必須な業務は自然と浮かび上がってきます。その具体的な方法については、第二部後編で解説します。
では、どのようにすれば漏れなくMust have要求を整理できるのでしょうか。そもそも「必須」とされる要求とは何を指すのか。まずはその全体像を押さえておくことが大切です。
大きく分類すると、Must have要求は次の四つに分けられます。
- 法令遵守・税制対応
- 顧客の強い要望
- プロジェクトの目的
- 制約条件
この四つの切り口から一つずつ確認していきます。
法令遵守や税制対応について、RFPに記載すること
法令遵守とは、食品であればHACCP、自動車であれば自動車安全基準、化学であれば危険物取扱や化学物質管理規制、輸出入ではREACHやRoHSといった国際規制、そして取引関係では下請法の遵守などが該当します。いずれもERPの業務プロセスと密接に関わるものであり、これを業務に置き換えると「必ず満たさなければ業務が成立しない最低条件」となります。すなわち、Must have要求として定義すべきものは、こうした法規制や基準に直結する要求事項であり、それが欠ければ事業継続そのものが不可能になる、という性質を持っています。
この基本的な考え方をRFPに適用すると、ビジネス要求レベルでは次のように定義されます。
- 内部統制の高度化と法令・品質規制対応の強化（統制力強化）
化学製品メーカーとして求められるREACH・RoHS等の国際規制への対応において、根拠ある検査記録・品質状態管理・出荷制御を実現できる仕組みを構築する。 - グローバルガバナンスの一元化
複数拠点で異なるローカル対応に依存せず、輸出規制・会計基準・品質保証ルールをグローバル共通の基盤上で統制する。 - 監査証跡と透明性の確保
財務・購買・在庫の取引履歴を一元的に管理し、外部監査や顧客査察において即時に証跡を提示できる体制を整備する。 - 製品責任（PL）リスクへの対応
出荷ロット・原材料・顧客先を追跡し、万が一のリコールや品質問題に迅速に対応できる仕組みを備える。
税制対応についても同様に、各国の消費税・付加価値税・インボイス制度など多様な税制要件に対し、取引データを一元的に管理し、法定様式での申告や請求を正確に、かつ期限内に確実に行える仕組みを構築します。これにより、グローバル税制対応を実現し、経営の透明性を高めることができます。
内部統制の位置づけと注意点
内部統制も法令遵守の一部に含まれます。なぜなら内部統制の本来の目的は、法令や会計基準に準拠した業務運営を保証し、外部監査に耐えうる証跡を確保することにあるからです。したがって、Must have要求としては法令遵守と同列に扱うことが妥当です。
ただし注意すべきは、ERP導入を契機に内部統制が形骸化していることに気づくケースが多いという点です。業務プロセスが変われば、統制すべき箇所やリスクも当然見直す必要があります。本来、内部統制は「何を防ぐために存在するのか」という目的を明確にしたうえで設計されるべきものであり、目的が曖昧なままでは形式だけが残ってしまいます。ERP導入時には、統制の目的とリスクを改めて点検することが重要です。
顧客からの強い要望
顧客からの強い要望、の『強い』とは、単なる利便性や改善希望ではなく、満たさなければ取引そのものが成立しない条件を意味します。ただし、ここで重要なのは、法令遵守との違いです。法令遵守は顧客が要望しなくても必須であり、企業が当然に対応しなければならない条件です。一方で顧客の強い要望は、法令で定められているわけではないため、もし要望がなければそこまで対応する必要はない、という性質を持っています。
例えば、食品メーカーなど主要顧客との取引では「品質保証体制を強化し、検査記録や証跡を確実に残すこと」が取引継続の条件として求められます。ここでは製品の出荷順序やロット管理を徹底することが前提となっており、仕組みとして担保できなければ出荷そのものが認められません。
グローバル医薬品メーカーとの契約においては「供給責任を果たすために、原材料や製品の完全なトレーサビリティを確保すること」が必須です。さらに、大手小売チェーンとの関係を維持するには「電子取引ルールやEDI基盤に準拠した商流対応」が前提とされ、これに応じられなければ取引機会そのものを失うことになります。
このように、顧客からの強い要望は、法令遵守とは異なり「顧客が提示するからこそ必須となる条件」です。交渉の余地がない取引上の前提として、ビジネス要求におけるMust haveに含めることが重要です。
補足：用語のあいまいさを避ける
上記にあげたように、“強い”といった表現を定義することは、伝え手と読み手の齟齬を防ぐために必要です。「強い」「弱い」「多い少ない」「緊急」といった表現は、読み手によって解釈が異なってしまうからです。人によっては「強い要望」と聞くと交渉次第で回避できると捉えたり、「緊急」といえば今日中の対応を意味すると思い込んだりします。こうした曖昧さを残したままでは、RFPに記載された要求の意味がぶれてしまい、正しい優先順位付けができません。
そのため、これらの言葉は思い込みに頼らず、あらかじめしきい値や判断基準を定めておくことが重要です。「強い要望」であれば、取引を停止すると明示されていることや、契約・品質協定に必須条件として記載されていることなど、具体的な基準を設定します。「多い」「少ない」であれば、対象期間や件数、比率を数値として示し、「緊急」であれば何日以内に重大な影響が発生するのかを明確にしておくのです。
こうして基準を明示することで、RFPを読む人が恣意的に解釈する余地が減り、全員が同じ前提で理解できます。特に「顧客の強い要望」をMust haveに位置づける際には、このような定義づけがあることで初めて、誰もが納得できる優先順位付けにつながるのです。
ビジネス要求から業務要求へ
ビジネス要求を現場に近い形で具体化したものが業務要求です。例えば、ビジネス要求として掲げられるのは「販路拡大に向けた品質保証体制の強化」や「ロイヤルカスタマーとの長期的な取引関係の維持」といった経営課題に直結するテーマです。これを業務レベルに落とし込むと、具体的な作業として「在庫引き当て時に、前回の出荷より古い製品が同じ納入場所に再び出荷されないように確認する」といった手順になります。これは、いわゆる「ロット逆転防止」の取り組みです。このように、ビジネス要求が上位の目的として存在し、その目的を実現するために業務要求が定義される、という構造を理解することが重要です。
したがって、RFPにおいて業務要求はあくまで大まかな方向性として示し、具体的な定義はプロジェクト開始後に検討していくのが健全です。ただしここで懸念されるのは、ビジネス要求レベルだけでは提案ベンダーが具体的な必須業務に気づかず、結果としてERPの選定時に重要な機能が漏れてしまう可能性があるという点です。
この問題を防ぐためには、RFPでビジネス要求を示す際に、その必須業務を想起できるような目的や前提条件を明記しておくことが大切です。たとえば「品質保証体制の強化」と記す際に、顧客との取引条件を満たすために出荷順序やロット管理を徹底する必要がある、といった文脈を添えておけば、ベンダーは自然と「ロット逆転防止」に対応する仕組みを検討の前提に組み込むことができます。
つまり、RFPで業務要求を細かく列挙しすぎる必要はありません。ビジネス要求を適切に定義し、その意図を明確に伝えることで、必須業務の抜け漏れを防ぎつつ、ベンダーの自由度も確保できるのです。
機能要求の注意点
さらに、業務要求をERP上に実装するために必要となるのが機能要求です。ただし、冒頭でも述べた通り、機能要求をRFPに細かく書き込むべきではありません。ERPの機能はパッケージごとに多様であり、Fit to Standardを前提とする以上、紙の上で網羅的に洗い出すのではなく、実際にCRPなどの業務検証の場で機能を動かしながら起票するのが適切です。
本来、標準機能で業務が成立するのであれば、それを改めて機能要求として挙げる必要はありません。にもかかわらず、既に備わっている機能を一つひとつ要求事項として列挙するのは、ERPベンダーが提供済みの内容をプロジェクト側で二重に書き直しているにすぎません。これはERPパッケージの特長を活かすどころか奪ってしまい、要求定義の作業も徒労に終わります。
したがって、機能要求はあくまで「業務要求を確実に成立させるために拡張が必要な場合」にのみ起票されるものです。そして、その妥当性は実機を用いた検証の中で確認するのが健全な進め方なのです。だからこそ、RFPに記載すべきは細かな機能ではなく、上位にあるビジネス要求と、その方向性を支える業務要求なのです。
まとめ
今回解説したように、Must have要求を抽出する際には、法令遵守や税制対応といった規制に加え、顧客からの強い要望を正しく理解し、明確な基準を持って整理することが必要です。これらを曖昧なままにせず、ビジネス要求としてRFPに位置づけることで、提案依頼側の企業とシステムを提案する側の認識を揃えることができます。前編ではここまでを整理しましたが、次回は、プロジェクトの目的をどのように抽出していくのかを解説していきます。
