Fit to Standardとは｜アドオンを増やさない導入と線引きの判定表
Fit to Standardとは、ERPの標準機能に業務を合わせることを原則とし、アドオン（追加開発）は審査を通った例外だけに限る導入の方針です。うまくいくかどうかは、「全部合わせる」と宣言することではなく、合わせない領域を先に決め、例外を認める手順を用意しておくことで決まります。この記事では、Fit to Standardの考え方、合わせる・合わせないの線引きの判定表、例外申請シートの記入例を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。
- 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（標準が前提） |
|---|---|---|
| 出発点 | 自社の現行業務と要件の一覧 | 製品の標準の業務プロセス |
| 確認の仕方 | 要件を1件ずつ製品に当てて、合うかを聞く | 標準の流れを実演で見て、自社で使えない箇所を探す |
| ギャップの扱い | 合わないものはアドオンを検討するのが基本 | 業務を合わせるのが基本。アドオンは審査を通った例外 |
| 決める人 | 要望を出した部門が強い | 例外を審査する場（会議体）が決める |
| フィットアンドギャップ分析の位置づけ | アドオンの範囲を見積もるための作業 | 例外の候補を洗い出し、合わせ方を決めるための作業 |
つまり、フィットアンドギャップ分析は「差を洗い出す作業」、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：差別化しない・社外の制約なし | どの会社でも同じようにやっている処理 | 標準に合わせる（例外は認めない） | 仕訳の起票、固定資産の管理、購買の承認の流れ、帳票のレイアウト |
| B：差別化しない・社外の制約あり | 法令や取引先との取り決めで決まっている処理 | 結果は守り、やり方は標準に合わせる。足りない部分は設定・周辺ツールで | 適格請求書の記載事項、得意先指定のEDI、銀行の振込データ |
| C：差別化する・社外の制約なし | 自社の強みになっている社内の仕組み | 標準で実現できないか検討し、無理なら例外として審査 | 独自の生産計画の立て方、品質記録のとり方、短納期の引当ルール |
| D：差別化する・社外の制約あり | 顧客との約束そのものが強みになっている処理 | 例外として審査し、認めた場合はアドオンや別製品で作る | 得意先ごとの専用の納品条件、業界特有の受託条件 |
※区分と例は説明用に整理したものです。同じ処理でも、会社によって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に入る処理ですが、設定と運用だけでは結果を守れないため、例外として申請しています。
| 項目 | 記入例 |
|---|---|
| 申請する処理 | 得意先ごとに賞味期限の許容日数（納品期限）を登録し、引当のときに期限を満たすロットだけを自動で選ぶ |
| 標準での扱い | 標準の引当は先入れ先出し。ロットの期限で絞り込む条件は、得意先単位では持てない |
| 標準に合わせた場合の影響 | 出荷担当がロットを手で選び直す作業が、1日約40件発生。選び間違えると、得意先から受け取りを拒否される |
| 判定表の区分 | B（得意先との取り決め）。結果は守る必要がある |
| 検討した代替案 | ①設定で引当の優先順位を変える（不可）②出荷前にリストで確認する運用（手間が残る）③引当の部分だけを外付けの機能で作る |
| 申請する対応 | ③。本体は変えず、引当の候補を出す機能を外付けで作る |
| 費用と保守への影響 | 開発と、バージョンアップのたびの動作確認が必要（概算はベンダーに依頼中） |
| 見直しの条件 | 製品の標準機能で同等の引当条件が提供されたら、外付けの機能を廃止して標準に戻す |
| 審査結果 | 承認（○月○日のステアリングコミッティ）。費用の概算が出た時点で再確認 |
※説明用の例です。実際のシートには、申請者、業務責任者の確認、関連する要件IDも書きます。
このシートで大事なのは、「検討した代替案」と「見直しの条件」の2つの行です。代替案の行があると、申請者は設定や運用での対応をまず考えるようになります。見直しの条件の行があると、作ったアドオンが永久に残ることを防げます。SAPの資料でも、標準機能が後のリリースで提供されたら、カスタム開発を外して標準に移せる可能性に触れています。アドオンの費用と保守の考え方はERPのアドオンとはを参照してください。
審査で見るポイント
審査の場では、申請ごとに次の3点を確認します。1つ目は、判定表の区分がCかDに入るか、Bの場合は設定や周辺ツールで結果を守れないか。2つ目は、標準に合わせた場合の影響が、件数や時間、取引先への影響として具体的に書かれているか。3つ目は、承認した場合に、バージョンアップのたびの確認作業を誰が担うか、です。3つ目を答えられない申請は、承認しても稼働後に保守の担い手がいなくなるため、保留にします。審査は申請がたまってからまとめて行うより、要件定義の期間中は定例の会議で毎回扱うほうが、判断の遅れでプロジェクトが止まることを防げます。
「今のやり方でないと困る」にどう向き合うか
Fit to Standardでつまずく場面として、IPAの同ガイドは次のような流れを挙げています。プロジェクトの当初はパッケージに業務を合わせるトップダウンの方針で進めていたのに、設計が進むにつれ、現行の業務運用と同じにしたいという要望が現場から上がり、機能拡張の規模が膨らんでいく、というものです。同ガイドは、次期システムで業務運用がどう変わるかを、早い段階でユーザ部門と認識を合わせることを求めています。
現場からの要望には、言葉の裏に別の理由があることがよくあります。代表的な3つの言い方と、確認の仕方を書き直し例の形で示します。
「同じ形」の要望の多くは、見慣れた配置で数字を探したいという理由です。使い道を確かめると、作る必要のない帳票が見えてきます。
標準の画面は、後工程に必要な項目を最初に入れる作りになっていることが多く、入力する人の手間だけを見ると増えたように見えます。
業界の特殊性は、分解すると数件の処理に絞られることがほとんどです。ひとまとめにすると、例外の範囲が際限なく広がります。
Fit to Standardが崩れるのは、多くの場合、プロジェクトの中盤です。標準の流れを見たときには納得していた現場が、テスト用の画面を触って初めて「やはり困る」と言い出します。これを防ぐには、標準の実演を見る段階から、実際に入力する担当者を参加させることです。もう1つは、経営者が最初に「標準に合わせる」と決めた理由を、プロジェクトの途中で何度も繰り返し伝えることです。決めた本人が途中で例外を認める発言をすると、方針はその場で崩れます。
中小企業でFit to Standardを進める5つのステップ
ここまでの判定表・例外申請シート・現場との向き合い方を、プロジェクトの順番に並べ直すと次の5ステップになります。ステップ2は「合わせる・合わせないの線引き」の判定表、ステップ4は例外申請シートと審査の手順をそのまま使います。
- 経営者が方針と理由を決める
「標準に合わせる」と決める理由（保守の費用、バージョンアップへの追随、導入期間など）を、経営者自身の言葉で文書にします。例外を審査する場と、最終判断者もここで決めます。 - 業務を判定表のA〜Dに振り分ける
業務フローの作業ごとに、差別化するか、社外の制約があるかで区分します。Cに入れる業務は、経営者の確認を経て決めます。 - 標準の流れを実演で見る
候補製品の標準の流れを、実際に入力する担当者も参加して確認します。自社の得意先・品目・例外を入れたシナリオを渡しておきます。 - 合わない箇所を例外申請シートで審査する
標準で困る箇所は、代替案を検討したうえで申請します。審査の場で承認・却下・保留を決め、記録を残します。 - 帳票・規程・権限・教育を一緒に変える
業務を合わせることにした箇所について、廃止する帳票、改定する規程、新しい権限、手順書を用意し、稼働前に練習します。
ステップ1で決めた方針は、製品やベンダーを選ぶときの条件にもなります。標準の機能が自社の業務の多くを満たす製品を選ぶことが、Fit to Standardの前提になるからです。パッケージの向き不向きはERPパッケージとはで解説しています。
ステップ5で一緒に変えるもの：帳票・規程・権限・取引先・教育
業務を標準に合わせるというのは、システムの操作を変えるだけでは終わりません。業務のまわりにある決まりごとも一緒に変えないと、システムの外で古いやり方が残ります。
| 変えるもの | 何を変えるか | 放置すると起きること |
|---|---|---|
| 帳票 | 社内帳票を標準の帳票や画面に置き換え、廃止する帳票を一覧にする | 旧帳票を作るためのExcelが復活する |
| 社内規程 | 承認の金額基準、締め日、伝票の起票ルールを標準の流れに合わせて改定する | 規程どおりに処理するために、システムの外で紙の承認が残る |
| 権限と役割 | 標準の役割に合わせて、入力・承認・閲覧の権限を設計し直す | 1人に権限が集中し、確認の仕組みがなくなる |
| 取引先との取り決め | 伝票の様式、締め日、データのやり取りを、標準に寄せる方向で取引先と話し合う | 取引先対応のためだけのアドオンが増える |
| 教育と手順書 | 新しい業務の流れで手順書を作り直し、稼働前に担当者が練習する | 稼働後に問い合わせが集中し、旧来のやり方に戻る |
なかでも、社内規程と取引先との取り決めは、システムの担当者だけでは変えられません。経営者や部門長が関わる必要があるため、プロジェクトの計画に作業として入れておきます。業務の流れがどう変わるかは、As-Is/To-Beの整理で、変わる作業に印をつけておくと説明しやすくなります。
Fit to Standardを始める前の10のチェックポイント
- 標準に合わせる理由を、経営者が文書にしている
- 例外を審査する場と、最終判断者が決まっている
- 業務が判定表のA〜Dに振り分けられている
- Cに入れた業務が、顧客や価格・納期への影響で説明できる
- 標準の実演に、実際に入力する担当者が参加している
- 例外申請シートに「検討した代替案」の欄がある
- 承認した例外に「見直しの条件」が書かれている
- 廃止する帳票と、改定する社内規程が一覧になっている
- 取引先との取り決めを変える交渉が、計画に入っている
- 稼働前に、新しい手順で担当者が練習する時間がとられている
よくある質問
Fit to Standardでは、アドオンを一切作ってはいけないのですか？
一切作らないという意味ではありません。標準に合わせることを原則とし、法令や取引先との取り決め、自社の強みに関わる処理など、審査を通ったものだけを例外として作ります。大事なのは、例外を認める基準と手順を先に決めておくことです。
中小企業でもFit to Standardは向いていますか？
販売・購買・在庫・会計の多くの処理は、規模を問わず標準的なやり方で回せるため、中小企業にも向いている考え方です。アドオンの保守を担う人員を社内に置きにくい中小企業ほど、標準のまま使うことの効果は大きくなります。一方で、製造の段取りや業界特有の取引条件など、強みに直結する部分は例外として検討する余地を残します。
標準に合わせると、業務の効率が下がることはありませんか？
一部の担当者の作業は増えることがあります。標準の流れでは、後工程で必要な情報を最初の入力で揃える作りになっていることが多いためです。業務全体で、転記や照合の作業がどれだけ減るかを数字で比べてから判断します。効率が下がる場合は、その処理を判定表で見直し、例外申請の対象にするかを検討します。
Fit to Standardは、どの製品でも使える考え方ですか？
考え方そのものは、製品を問わず使えます。ただし、標準の業務プロセスやベストプラクティスがどこまで用意されているか、拡張の方法がどう提供されているかは製品によって違います。候補製品ごとに、標準の流れを実演で確認し、拡張の方式とバージョンアップの影響をベンダーに確認します。
Fit to Standardにすると、導入の期間や費用は必ず小さくなりますか？
アドオンが減れば、開発とテストの量は減ります。ただし、そのぶん業務を変えるための作業が増えます。規程の改定、取引先との交渉、手順書の作り直し、担当者の練習といった作業です。これらはシステムの見積もりには出てこないため、社内の作業として計画に入れておかないと、稼働の直前に時間が足りなくなります。システムの費用と社内の作業の両方を見て判断します。
標準に合わせる範囲と例外を要件定義書にまとめるための、目次・機能要件一覧・非機能要件の記入例をそのまま使える形にした資料です。
資料をダウンロードする（無料）まとめ
Fit to Standardは、標準に業務を合わせることを原則にし、アドオンを審査を通った例外だけに限る方針です。成功させるには、差別化と社外の制約の2つの軸で合わせない領域を先に決め、例外申請シートと審査の場を用意し、帳票・規程・権限・教育まで一緒に変えること。「全部合わせる」と宣言するより、「ここは合わせない」と決めるほうが、方針は崩れにくくなります。
自社のどの業務を標準に合わせられるか、どこを例外として残すべきか迷う場合は、無料診断で現状の業務と、刷新の方針を一緒に整理します。
11章の目次、機能要件一覧、非機能要件の記入例
資料をダウンロードする
