SaaSタイプのERP導入における「機能がない要求」への第三の対処法 ーエンハンスリクエストー
SaaS ERPをFit to Standardで導入する。この言葉をRFPに掲げる企業が増えてきた一方で、現場から聞こえてくるのは、少し異なる声です。
「このERP、あの機能がないんですよ」
「これじゃ仕事が回らない」
業務を標準に合わせる。そのためにプロジェクトチームは何度もCRPを重ね、現場も覚悟を持って慣れない操作に臨む。しかし、どうしても超えられない壁が現れたとき、「アドオンするしかないんじゃないか？」という空気が流れ始めます。
果たして、本当にそれしか道はないのでしょうか。
本稿では、そうした局面に立ったとき、アドオンでもなく、運用による回避でもない、第三の選択肢「エンハンスリクエスト」に焦点を当て、その可能性と実践法をお伝えします。
「機能がない要求」は一括りにしてはいけない
まず大前提として、「機能がない」という言葉の背後には、まったく異なる種類の要求が混在しています。
あるものは、作業量が増えたことによる“手間”の問題。あるものは、法令や制度といった“回避不能な制約”。あるものは、単なる“慣れ”から来る心理的抵抗です。
この違いを見極めないまま、すべての要求を「機能がないからアドオンで対応しよう」とまとめてしまうと、システムの複雑化と品質リスクを抱え込む結果になりかねません。
業務量の問題は、まず運用でリカバリーを考える
「この業務、手作業が増えて大変です」といった声は、Fit to Standard導入ではよく耳にします。こうした“手間”に関する要求に対して重要なのは、「業務が回るかどうか」を定量的に評価する視点です。
例えば、1件あたりの処理に5分かかるとすれば、1日あたり何件発生していて、全体で何時間になるのか。その作業は一人で処理できるのか、人員を追加する必要があるのか。それでも業務時間内に収まるのか。これらを可視化した上で、運用で回避できるのであれば、それは“業務として成立している”と言えます。つまり、「手間が増えた＝アドオンが必要」ではなく、「処理しきれない場合は運用設計を見直す」という柔軟な判断が、Fit to Standard的なアプローチなのです。
法令や制度への対応は、製品としての機能に引き上げる
一方、インボイス制度や電子帳簿保存法、あるいはHACCP、COAのように、法令・制度が絡む要求については話が別です。これらは“業務の効率性”ではなく、“企業として対応が義務づけられている制度”であるため、本来であればERP選定の段階で要求事項に挙げ、対応の有無を見極めておくべき内容です。
実際、SaaS ERPベンダー側も、法令順守に関わる領域を製品対応の重点分野と位置づけており、あらかじめ整備された機能で対応できるよう努めています。そのため、ユーザー企業側は、RFPや機能要求一覧を通じて、選定段階で各ベンダーの対応状況を丁寧に見極めておくことが重要です。これは、いまやERP導入プロジェクトにおける基本動作とも言えるでしょう。
ただし、現場レベルで実際に運用イメージを描いていく中で、制度対応に“微細なズレ”が見つかるケースや、「制度対応＋α」の実務要件が判明することもあります。こうした“検証段階で判明したギャップ”に対しては、ERPベンダーにエンハンスリクエストを出す必要が生じます。
第三の道－エンハンスリクエストとは何か
エンハンスリクエストとは、ERPベンダーに対して「標準機能としてこのような機能を将来的に組み込んでほしい」と正式に要望を出す仕組みです。SaaS製品では、すべてのユーザーが同じバージョンの機能を使うことになるため、ある機能が標準に組み込まれれば、将来的な保守・アップグレード・サポートの恩恵をすべての顧客が受けられることになります。これにより、個別開発（アドオン）に伴う技術的負債を回避できるだけでなく、ベンダー側の将来計画とも整合しやすいというメリットが生まれます。
とはいえ、単に「この機能が必要です」と一覧にして提出するだけでは、現実的には何も動きません。エンハンスリクエストは、戦略的に“通す”必要があるのです。
エンハンスリクエストを通すための“4つの取り組み”
エンハンスリクエストは、「提出すれば通る」という仕組みではありません。むしろ逆で、ERPベンダーが製品戦略として価値を感じるかがすべてです。
そこで重要になるのが、次の4つの取り組みです。
まず“信頼関係”を築く：
日頃の信頼関係を活かす：ユーザー会への協力、リファレンス対応、製品セミナーへの参加など、普段から信頼を積み重ねておくことで、「この会社の意見には耳を傾けよう」という空気をつくることができます。
プロダクトマネージャーとの対話を持つ：窓口対応で終わらせるのではなく、製品の方向性を担う責任者と直接会話すること。ベンダーの戦略と自社の要望をどう接続させるかが、エンハンス成功の鍵です。
そして“戦略”として仕掛ける：
業界ニーズと結びつける：「この機能は化学業界では必須の商慣習であり、対応していないことでERPの導入障壁となっている」、こうした業界汎用性を示すことで、ERPベンダーにとってのマーケット訴求力が高まります。
ビジネスインパクトを示す：「この処理が自動化されれば、生産性が30%向上し、人的ミスの低減にもつながる」、具体的な経済的インパクトを示すことで、製品化の正当性を補強できます。
このように、エンハンスリクエストは単なる“お願い”ではなく、ビジネス上の提案として、戦略性と実行可能性を備えた内容へと仕立てていくことが求められます。
アドオンではなく、エンハンスでこそ対応すべき領域
ここで重要な補足があります。ERPに「機能がない」からといって、何でもかんでもアドオンで対応してよいわけではありません。むしろ、アドオンしてはならない領域があります。
それが、MRP（資材所要量計算）、価格決定、引当の三領域です。
これらはERPの“基幹ロジック”であり、プロジェクト単位での独自開発による変更は、整合性・保守性・将来拡張性のいずれにおいても、極めて大きなリスクをはらみます。
一方で、ERPベンダーによる製品レベルでのエンハンス対応であれば、標準仕様として整合性が担保され、アップグレードにも追従可能です。つまり、これらの領域について追加要求がある場合は、エンハンスリクエストこそが唯一健全な選択肢であるということです。
変化に対応するために、共に進化していく
エンハンスリクエストは、すべてが通るとは限りません。しかし、だからといって声を上げなければ、SaaSという進化し続ける製品を選んだ意味が失われてしまいます。変化への対応力、それこそが、SaaS ERPを選ぶ最大の価値であり、ユーザーに与えられた正当な“権利”でもあります。
どこに手を加えるのかではなく、どこに“未来の可能性”を託すのか。エンハンスリクエストという「第三の選択肢」は、その視点を持つ企業にこそ開かれた道なのです。
そして、ERPベンダーにとってもまた、ユーザーからの声は製品を進化させる原動力です。市場に根ざした本質的な要望が、SaaS製品の競争力を磨き、より広い業界ニーズに応える礎となるからです。機能を一方的に“提供する側”と“受け取る側”ではなく、変化を共有し合う対話のパートナーとして向き合うこと、それが、SaaS ERP時代の“共存共栄”のかたちなのだと思います。
