ERP知識シリーズ The・MoSCoW 第三部：CRPとMoSCoW【前編】CRPを歪める誤解を正す
500件もの機能要求が箇条書きで並ぶRFP。その多くは現行機能の焼き直しか、「今のやり方を簡単にする」程度の自動化にとどまる。それでもユーザー企業は、「このリストが満たされればERPは運用できる」と考えてしまう。こうした状態こそ、これまで繰り返し取り上げてきたERP導入プロジェクトにおける典型的な誤解です。第一部・第二部では、要求には優先度と要求レベルがあり、その中には未来像を示すTo-Beと、制約条件としてのAs-Isが存在することを整理しました。誤解を正し、要求を構造的に捉える視点がなければ、RFPの羅列はただの願望集に過ぎません。
こうした誤解を正すうえで欠かせないのがCRPです。これまでのブログで取り上げてきたCRPは、チェンジマネジメントの一環としての位置づけや、具体的な進め方に焦点を当てていました。今回の第三部では、そこから一歩踏み込み、MoSCoWとの関係を深掘りします。前編では、誤ったRFPやPoCの扱いを整理し、初期に起票されたMoSCoWが、どのような問題を抱えているのかを見ていきます。後編では、CRPを通じて要求がどのように見直され、適切に評価できるレベルへと高められていくのかを解説していきます。
機能要求とRFPの本来の役割
CRPの前提として押さえておきたいのは、まずMoSCoWの起点となるRFPです。これまでのRFPでは、ユーザー企業が機能要求を事細かに書き連ねるのが当たり前でした。業務要求に加え、「この機能があるかどうか」をリスト化することが、ベンダー選定の大きな基準とされてきたのです。
スクラッチ開発の時代には、こうしたやり方は必要なものでした。システムを一から作る以上、機能を一つひとつ明示しなければ開発は進まなかったからです。ところが、この発想はその後も半ばテンプレートのように踏襲され、ERP導入にまで持ち込まれてしまいました。その結果、カスタマイズプロジェクトが乱発し、計画通りに進まない事例が後を絶たなくなっているのではないかと推測します。
それにもかかわらず、いまもRFPに機能要求を細かく書き込んでしまうケースが後を立ちません。これはERPの自由度を奪い、プロジェクトの進め方を誤らせる原因となります。ERPにすでに実装されている機能をプロジェクトで改めて要求として列挙することは、結局「機能カタログの焼き直し」をしていることと同じです。
これをFit to Standard（FTS）を掲げるプロジェクトにまで持ち込んでしまえば、もはやひとたまりもないでしょう。この進め方は今となっては「いにしえの遺作」と言わざるを得ません。現代のSaaS ERP導入において、RFPに記載すべきはTo-Be業務をイメージできる要求や制約条件であり、機能要求そのものではないのです。業務要求に対して「どの機能で実現できるか」を提示するのはERP導入ベンダーの役割であり、その回答をもとにビジネスプロセスフローが描かれ、最終的にはCRPのシナリオへとつながっていくのです。
PoCの正しい位置づけ
加えて、ここで注意しておきたいのがPoC（Proof of Concept）の扱いです。PoCは評価の最終段階やプロジェクト初期に行われるものであり、それ自体を否定する必要はありません。重要なのは、目的を正しく定めて行うことです。PoCの目的は「システムが要件を満たせるかどうか」を評価することであり、「運用担当者に触らせて慣れてもらう場」ではありません。
評価する側のマインドが曖昧なままPoCを進めてしまうと、ユーザーは自然と慣れ親しんだ操作やAs-Isの業務に引き戻されてしまいます。「今のシステムと操作方法があまり変わらないからこれがいい」とか、「Excelに簡単にダウンロードしたりアップロードできるから使い勝手が良さそう」といった評価は最悪のパターンです。それはTo-Be業務を確かめるのではなく、As-Isの延長を肯定しているにすぎません。こうしたPoCの進め方では、ERP導入の目的そのものが吹っ飛んでしまいます。
MoSCoWの現実
実際のプロジェクトでは、高い確率で「現行システムの踏襲」に近い機能要求や、精査の浅いAs-Is業務要求が多くを占めます。CRPの段階に入ると、こうした要求の大半は見直しの対象になります。場合によっては、起票した要求をすべてゼロクリアすることさえあります。実際に、RFPに並んだ約400件の機能要求を、FTSの観点から「As-Isの再現を前提としており不適切」と判断し、CRPの検証対象から外したケースがありました。
ここで押さえておくべき点は、ゼロクリアの理由が「標準機能で代替できるから」ではないということです。標準機能が備わっていること自体に価値があるのではなく、To-Be業務に沿った形でどう活用するかが本質です。標準機能にあるからといって、As-Isの機能要求をそのままERPに置き換えてしまえば、結局は業務の在り方が変わらず、新しいシステムの上に古い習慣を再現することになります。Fit to Standard（FTS）の考え方では、To-Be業務の要求と制約条件を起点に据え、それをCRPで検証できるシナリオと受入基準へと結びつけていくことが道筋となります。
問題はユーザー企業だけにあるわけではありません。ERP導入ベンダー側にも、「ユーザーが要望したことだから」と鵜呑みにし、標準機能でできるからと、そのままCRPに持ち込んでしまう対応の甘さがあります。中には、プロジェクト開始直後から実機検証を求められ、十分な準備を経ないまま言われるがままに応じてしまうケースすらあります。その結果、CRPの準備段階で浅い要求が整理されないまま残り、As-Is課題とTo-Be課題がどっちつかずのまま混在し、ERPへのAs-Is踏襲として表面化します。業務の検証が進むたびに余計な調整ややり直しが増え、準備工数は際限なく膨らみ、やがてスケジュール全体の崩壊へとつながっていくのです。
そういった意味では、ERP導入ベンダーにも、RFPに挙がった機能要求に丸を増やすよう頑張るだけではなく、「この機能は〇〇のため不要です」と明確に回答できる恐れずに物言う姿勢が求められます。
まとめ、そして後編へ
今回確認したのは、誤ったRFPやPoCの扱いが、そのままCRPを歪めてしまう危うさです。とりわけ、機能要求を細かく書き連ねるアプローチは、ERP導入を現行踏襲に導き、無駄な労力と混乱を生み出します。このことからも、CRPを有効に進めるためには、実施前に要求事項をどれだけTo-Beに沿って見直せるかが重要な分かれ道になるのです。
そして次回後編では、こうして方向性が示されたMoSCoWが、どのように内容を精査され、CRPで検証可能な要求へと磨き上げられていくのかを見ていきます。
