Fit to Standardとは｜アドオンを増やさない導入と線引きの判定表

Fit to Standardとは、ERPの標準機能に業務を合わせることを原則とし、アドオン（追加開発）は審査を通った例外だけに限る導入の方針です。うまくいくかどうかは、「全部合わせる」と宣言することではなく、合わせない領域を先に決め、例外を認める手順を用意しておくことで決まります。この記事では、Fit to Standardの考え方、合わせる・合わせないの線引きの判定表、例外申請シートの記入例を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

Fit to Standardとは：標準に業務を合わせ、アドオンを例外にする方針

Fit to Standard（フィット・トゥ・スタンダード）は、ERPやクラウドの業務システムを導入するときに、製品が標準で用意している業務プロセスを基本に据え、自社の業務をそちらに合わせていく考え方です。従来の導入では、自社の業務を前提にして、合わない部分をアドオンで作り込むやり方が多くとられてきました。Fit to Standardは、この前提を逆にします。

この言葉を広めたのは、ERPベンダーの導入方法論です。SAPの導入方法論「SAP Activate」は、プロジェクトをDiscover・Prepare・Explore・Realize・Deploy・Runのフェーズに分け、Explore（探索）フェーズで、SAPのベストプラクティスのコンテンツを使ったfit-to-standardワークショップを行うとしています。サンドボックスやスターターシステムで標準のプロセスを実演し、業務への適合度を確かめ、差分の設定要件やギャップをプロダクトバックログに記録する、という進め方です。

国内のユーザー企業でも、この考え方は取り組みとして定着しつつあります。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書2026」では、DXの効果を最大化するために実施した重要な施策を自由記述で尋ね、「業務プロセス改革・標準化」に分類された回答（38社）の具体例として「Fit-to-Standardによる既存プロセスの見直し」が挙げられています。

大事なのは、Fit to Standardは「アドオンを一切作らない」という意味ではないことです。標準に合わせることを原則にしたうえで、合わせない領域を明確にし、例外は手続きを経て認める。この「原則と例外の線引き」までを含めて、Fit to Standardの方針と考えます。線引きのない「標準に合わせる」は、最初の要望が出た時点で崩れます。

Fit to Standardとフィットアンドギャップ分析の違い

よく混同されるのが、フィットアンドギャップ分析（Fit&Gap分析）です。両者は対立するものではなく、役割が違います。

つまり、フィットアンドギャップ分析は「差を洗い出す作業」、Fit to Standardは「差をどう扱うかの方針」です。Fit to Standardの方針をとる場合も、ギャップの洗い出しは必要です。違いは、ギャップが見つかったときにまず業務の側を変えられないかを検討するという順番にあります。分析の具体的な進め方とギャップの埋め方はフィットアンドギャップ分析とはで解説しています。

なぜいまFit to Standardが選ばれるのか：3つの理由

理由1：アドオンの積み重ねが、システムを古くする

経済産業省の「DXレポート」（2018年）は、国内には「汎用パッケージでもカスタマイズを好むユーザ企業が多い」とし、「2025年の崖」の要因の1つとして「アドオン・カスタマイズの積み重ねによる一層の複雑化」を挙げています。さらに、システム刷新の失敗ケースとして「過剰なカスタマイズは、メンテナンスやバージョンアップ時のコスト増」になることも示しています。導入時に作り込んだアドオンは、製品のバージョンアップのたびに動作の確認と修正が必要になり、やがてバージョンアップ自体を見送る判断につながります。

理由2：パッケージを使うメリットは、標準のまま使ってこそ出る

IPAの「システム再構築を成功に導くユーザガイド 第2版」（2018年）は、パッケージ製品の利用では、製品が標準として提供する機能をできるだけそのまま利用することが望ましく、それによって既製品を使うメリットである高品質・短期導入・低コストが実現できると述べています。同ガイドは、パッケージ製品自体のソースコードを書き換えるやり方は、こうしたメリットが損なわれるうえ、保守やバージョンアップを自社で担うことになるため推奨しない、としています。

理由3：クラウド型のERPは、標準のまま使う前提で作られている

クラウド型のERPでは、製品側の更新が定期的に提供されます。SAPは「クリーンコア」という考え方を掲げ、拡張の方法として、まずキー・ユーザー向けの拡張機能（画面からの項目やロジックの追加）を使い切り、そのうえで複雑な拡張は本体の外の基盤で作る（サイド・バイ・サイド）順番を示しています。本体を直接書き換える従来型の拡張は、プライベートクラウド版とオンプレミス版でのみ可能で、一般には推奨されないとしています。クラウド化の考え方は基幹システムのクラウド化で解説しています。

付け加えると、アドオンが少ないことは、保守を頼む会社の選択肢にも関わります。自社のためだけに作り込んだ機能が多いほど、その中身を知っている導入会社にしか保守を頼めなくなるからです。この点はベンダーロックインとはで詳しく扱っています。

合わせる・合わせないの線引き：判定表

Fit to Standardでいちばん難しいのは、どこまで合わせるかです。「すべて標準に合わせる」と宣言すると、自社の強みまで失うおそれがあります。逆に、例外を広く認めると従来型の導入と変わりません。業務を「他社との違いを生む領域か」と「社外の制約があるか」の2つの軸で分けると、線を引きやすくなります。

※区分と例は説明用に整理したものです。同じ処理でも、会社によってAにもCにもなります。

この表を使うときの注意は、Cに入れる業務を厳しく絞ることです。どの部門も、自分の業務は特別だと考えがちです。「その処理がなくなったら、顧客は他社に移るか」「その処理のおかげで価格や納期で選ばれているか」と問い、答えが「はい」になるものだけをCに入れます。答えに詰まるものは、ほとんどがAです。

中小企業では、販売・購買・在庫・会計の多くの処理がAとBに入ります。Cに入りやすいのは、製造業の生産計画や原価のとらえ方、卸売業の引当や配送のルールなど、業種の特徴が出る部分です。業種ごとの考え方は製造業のERPも参考にしてください。

振り分けの会議の進め方

A〜Dの振り分けは、部門ごとに任せると、どの部門もCとDを増やします。経営者か、経営者から権限を任された責任者が同席する会議で、業務フローの作業を1つずつ読み上げながら決めていくのが確実です。1回の会議で扱う業務領域は1つか2つに絞り、決まった区分はその場で一覧に書き込みます。

迷った作業は、いったんAに置き、「Cにすべき理由」を部門に宿題として出します。理由が顧客・価格・納期の言葉で説明できたら、次の会議でCに移します。説明できなければAのままです。この「迷ったらA」のルールを最初に決めておくと、会議が長引きません。

例外を認める手順：例外申請シートと審査の場

Fit to Standardを宣言しても、例外を審査する仕組みがないと、現場から上がってくる要望に1件ずつ押し切られます。必要なのは、例外を申請する書式と、それを審査する場です。SAPも、クリーンコアの考え方から外れる開発については、ソリューション標準化ボード（Solution Standardization Board）が審査し、承認の理由を文書に残すという進め方を示しています。中小企業では、専任の会議体を新たに置かず、プロジェクトの意思決定の場（ステアリングコミッティ）の議題にこの審査を組み込む形が現実的です。会議体の作り方はステアリングコミッティとはで解説しています。

例外申請シートの記入例

次の表は、従業員90名の食品製造業（架空の会社）で、営業部門が出した例外申請の記入例です。判定表ではBに入る処理ですが、設定と運用だけでは結果を守れないため、例外として申請しています。

※説明用の例です。実際のシートには、申請者、業務責任者の確認、関連する要件IDも書きます。

このシートで大事なのは、「検討した代替案」と「見直しの条件」の2つの行です。代替案の行があると、申請者は設定や運用での対応をまず考えるようになります。見直しの条件の行があると、作ったアドオンが永久に残ることを防げます。SAPの資料でも、標準機能が後のリリースで提供されたら、カスタム開発を外して標準に移せる可能性に触れています。アドオンの費用と保守の考え方はERPのアドオンとはを参照してください。

審査で見るポイント

審査の場では、申請ごとに次の3点を確認します。1つ目は、判定表の区分がCかDに入るか、Bの場合は設定や周辺ツールで結果を守れないか。2つ目は、標準に合わせた場合の影響が、件数や時間、取引先への影響として具体的に書かれているか。3つ目は、承認した場合に、バージョンアップのたびの確認作業を誰が担うか、です。3つ目を答えられない申請は、承認しても稼働後に保守の担い手がいなくなるため、保留にします。審査は申請がたまってからまとめて行うより、要件定義の期間中は定例の会議で毎回扱うほうが、判断の遅れでプロジェクトが止まることを防げます。

「今のやり方でないと困る」にどう向き合うか

Fit to Standardでつまずく場面として、IPAの同ガイドは次のような流れを挙げています。プロジェクトの当初はパッケージに業務を合わせるトップダウンの方針で進めていたのに、設計が進むにつれ、現行の業務運用と同じにしたいという要望が現場から上がり、機能拡張の規模が膨らんでいく、というものです。同ガイドは、次期システムで業務運用がどう変わるかを、早い段階でユーザ部門と認識を合わせることを求めています。

現場からの要望には、言葉の裏に別の理由があることがよくあります。代表的な3つの言い方と、確認の仕方を書き直し例の形で示します。

中小企業でFit to Standardを進める5つのステップ

ここまでの判定表・例外申請シート・現場との向き合い方を、プロジェクトの順番に並べ直すと次の5ステップになります。ステップ2は「合わせる・合わせないの線引き」の判定表、ステップ4は例外申請シートと審査の手順をそのまま使います。

1. 経営者が方針と理由を決める
   「標準に合わせる」と決める理由（保守の費用、バージョンアップへの追随、導入期間など）を、経営者自身の言葉で文書にします。例外を審査する場と、最終判断者もここで決めます。
2. 業務を判定表のA〜Dに振り分ける
   業務フローの作業ごとに、差別化するか、社外の制約があるかで区分します。Cに入れる業務は、経営者の確認を経て決めます。
3. 標準の流れを実演で見る
   候補製品の標準の流れを、実際に入力する担当者も参加して確認します。自社の得意先・品目・例外を入れたシナリオを渡しておきます。
4. 合わない箇所を例外申請シートで審査する
   標準で困る箇所は、代替案を検討したうえで申請します。審査の場で承認・却下・保留を決め、記録を残します。
5. 帳票・規程・権限・教育を一緒に変える
   業務を合わせることにした箇所について、廃止する帳票、改定する規程、新しい権限、手順書を用意し、稼働前に練習します。

ステップ1で決めた方針は、製品やベンダーを選ぶときの条件にもなります。標準の機能が自社の業務の多くを満たす製品を選ぶことが、Fit to Standardの前提になるからです。パッケージの向き不向きはERPパッケージとはで解説しています。

ステップ5で一緒に変えるもの：帳票・規程・権限・取引先・教育

業務を標準に合わせるというのは、システムの操作を変えるだけでは終わりません。業務のまわりにある決まりごとも一緒に変えないと、システムの外で古いやり方が残ります。

なかでも、社内規程と取引先との取り決めは、システムの担当者だけでは変えられません。経営者や部門長が関わる必要があるため、プロジェクトの計画に作業として入れておきます。業務の流れがどう変わるかは、As-Is/To-Beの整理で、変わる作業に印をつけておくと説明しやすくなります。

Fit to Standardを始める前の10のチェックポイント

• 標準に合わせる理由を、経営者が文書にしている
• 例外を審査する場と、最終判断者が決まっている
• 業務が判定表のA〜Dに振り分けられている
• Cに入れた業務が、顧客や価格・納期への影響で説明できる
• 標準の実演に、実際に入力する担当者が参加している
• 例外申請シートに「検討した代替案」の欄がある
• 承認した例外に「見直しの条件」が書かれている
• 廃止する帳票と、改定する社内規程が一覧になっている
• 取引先との取り決めを変える交渉が、計画に入っている
• 稼働前に、新しい手順で担当者が練習する時間がとられている

よくある質問

まとめ

Fit to Standardは、標準に業務を合わせることを原則にし、アドオンを審査を通った例外だけに限る方針です。成功させるには、差別化と社外の制約の2つの軸で合わせない領域を先に決め、例外申請シートと審査の場を用意し、帳票・規程・権限・教育まで一緒に変えること。「全部合わせる」と宣言するより、「ここは合わせない」と決めるほうが、方針は崩れにくくなります。

自社のどの業務を標準に合わせられるか、どこを例外として残すべきか迷う場合は、無料診断で現状の業務と、刷新の方針を一緒に整理します。