ERP導入の打ち合わせで、現場から要望が次々に出てくる。一つずつ聞いていくうちに、開発の見積もりが膨らんでいく。
「全部聞けば費用が止まらない。でも断れば現場が動かない」。多くの経営者が、ここで判断に迷います。
この迷いには、整理のしかたがあります。Fit to Standard（フィット・トゥ・スタンダード）とは、業務をシステムの標準機能に合わせるというERP導入の考え方です。ERP（Enterprise Resource Planning：基幹業務を統合管理するシステム）の導入で、ほぼ必ず出てくる言葉です。
「カスタマイズは悪」という意味ではありません。どこを標準に寄せ、どこを自社の形で守るかを、意識的に分けるための考え方です。Odooは30種類以上のコアアプリを持ち、標準に寄せやすい領域が比較的多い製品です（標準に寄せやすい領域・寄せにくい領域）。
標準に寄せると、たとえば次のことが変わります。
- バージョンアップのたびに確かめる範囲が限られる
- 担当者が替わっても、公式ドキュメントや外部の情報で引き継げる
- 不具合が起きても、製品の問題か設定の問題かで切り分けられる
- 差がつかない事務処理を標準化し、空いた時間を強みに振り向けられる
Odooには無料のCommunity版と有償のEnterprise版があり、どちらを選ぶかで「標準」の範囲自体が変わります。また、すべてを標準に寄せると、会社の強みまで平準化されることがあります。
では、その線をどこに引けばよいのか。現場の要望一覧を前にしたとき、何を問えば仕分けられるのか。答えは標準に寄せる業務と、守る業務の分け方にあります。
Fit to Standardとは何か：Fit and Gapとの違い
Fit to Standardは、ERP導入の進め方のひとつです。
パッケージソフトの標準機能を前提に、業務のやり方を合わせていきます。標準で実現できない部分だけを、例外として個別に検討する形です。
従来の進め方は、Fit and Gap（フィット・アンド・ギャップ）と呼ばれます。現行業務を洗い出し、標準との差分（ギャップ）を開発で埋める方法です。
図のとおり、両者は出発点が逆になります。Fit and Gapは今の業務のやり方から始め、Fit to Standardは標準機能でできることから始めます。
| 観点 | Fit and Gap | Fit to Standard |
|---|---|---|
| 出発点 | 現行の業務手順 | 標準機能の業務の流れ |
| 議論の対象 | 差分をどう埋めるか | 業務を変えられるか |
| 開発量 | 増えやすい | 抑えられる |
| 稼働までの期間 | 長くなりやすい | 短くしやすい |
| 保守・更新 | 検証範囲が広がる | 標準更新に追随しやすい |
どちらが常に正しいわけではありません。ただ、中小〜中堅企業では、Fit to Standardのほうが現実的なことが多いのです。
規模が大きく、NetSuiteも候補に入る場合の差分の仕分け方は、NetSuite導入のFit&Gap分析で扱っています。
なぜ「業務をシステムに合わせる」のか
「うちの業務は特殊だから」という言葉は、導入現場でよく聞きます。
しかし業務を分解してみると、本当に特殊な部分はごく一部です。多くは次のどちらかに当てはまります。
- 過去のシステムの制約に合わせてできた手順
- 担当者が長年やってきた、変える理由のない手順
こうした手順を再現するためにカスタマイズを積み上げると、負担は導入時だけでは終わりません。
- 費用が増える：差分を埋める開発は、要件が細かいほど費用が上がります
- 更新のたびに検証が要る：Odooは原則として年1回メジャーバージョンアップがあります。独自開発した部分は、そのたびに動作確認が必要です
- 属人化が残る：「この処理はこうしないといけない」という知識が、システムの外に残り続けます
- 会社の引き継ぎで論点になる：事業承継やM&A（合併・買収）では、独自仕様の多いシステムは買い手が理解しづらく、引き継ぎの論点になります
Fit to Standardは、単なるコスト削減の話ではありません。システムを軽く保ち、変化に対応しやすくするための考え方です。
Fit to Standardのメリットとデメリット
標準のまま使う利点は、導入時点では見えにくいものです。運用が始まってから表れてきます。カスタマイズを検討する前に、次の4つを確かめてください。
1. バージョンアップで不具合が出にくい
標準のままなら、更新のたびに確認する範囲は限られます。作り込んだ部分は個別の動作確認が必要で、確認漏れが不具合につながります。
2. 人が替わっても引き継げる
標準の画面や手順は、公式ドキュメントや外部の情報から学べます。独自仕様は担当者の頭の中に残りがちで、退職や異動のたびに引き継ぎが止まります。
3. 不具合の切り分けが早い
標準機能なら、「製品側の問題か、設定の問題か」で切り分けられます。作り込んだ部分は原因の候補が増え、調査だけで日数がかかることもあります。
4. 他社の知見を借りられる
同じ標準機能を使う会社の事例や、ユーザーコミュニティ、外部の支援会社に相談できます。独自仕様は情報が社内に閉じ、自社だけで抱え込みがちです。
| 場面 | 標準のまま | 作り込んだ場合 |
|---|---|---|
| バージョンアップ時 | 確認範囲が小さい | そのたびに個別確認が必要 |
| 担当者交代時 | 公式情報や外部情報で学べる | 引き継ぎが属人的になりやすい |
| 不具合発生時 | 製品か設定かで切り分けられる | 原因調査に時間がかかる |
| 相談したいとき | 他社事例や外部の相談先がある | 自社で解決するしかない |
差が出やすいのは、人の交代や不具合対応といった運用の場面です。導入直後だけでなく、数年後の運用負担まで見て判断する価値があります。
気をつけること（デメリット）
一方で、標準に寄せる進め方には負担もあります。
- 業務を変える決定に時間がかかる：開発量は減っても判断の時間は減らず、「この業務をやめる」決定が遅れると導入は延びる
- 全部を標準に寄せると強みまで平準化される：独自の見積ロジックや品質管理の基準のような「差がつく業務」は守る必要がある
- 現場の納得が要る：理由を説明せずに進めると、現場には「一方的に決められた」と映る
- 「標準」の範囲は版で変わる：Community版を前提にすると、標準で実現できる範囲はその分狭くなる
両方を1枚の図に並べました。
避け方は、標準に寄せる業務と、守る業務の分け方とFit to Standardが失敗するときにまとめています。
それでも「全部標準」は間違い
一方で、Fit to Standardを極端に運用すると、別の失敗が起きます。すべてを標準に寄せると、会社の強みまで平準化されることがあるためです。
たとえば、次のような業務です。
- 独自の見積ロジックで、他社より速く正確に提案できている
- 特殊な受注形態に対応することで、大手が取れない案件を取れている
- 品質管理の独自基準が、顧客からの信頼につながっている
これらを「標準にないから」という理由でやめると、競争力が下がります。システムは軽くなっても、事業は弱くなります。
標準に寄せるべきは「差がつかない業務」であり、守るべきは「差がつく業務」です。
標準に寄せる業務と、守る業務の分け方
では、どう分けるのか。冒頭の問いには、2つの軸で答えます。
- 縦軸：その業務は、競争優位に直結しているか
- 横軸：Odooの標準機能でカバーできるか
| 区分 | 判断 | 補足 |
|---|---|---|
| 強みだが、標準でもできる（左上） | 標準機能で運用する | わざわざ独自の形にする理由はない。画面や項目の微調整で足りることが多い |
| 強みで、標準では実現できない（右上） | ここだけ手を入れる | 設定・ノーコード・開発の順に検討する。投資する価値がある領域 |
| 差がつかず、標準でもできる（左下） | 迷わず標準に寄せる | 経費精算、請求、在庫の基本処理など。最も効果が出る領域 |
| 差がつかないのに、標準では難しい（右下） | 業務側を見直す | 過去の制約が残っている可能性が高い。開発で埋めると負担だけが残る |
もっとも判断を誤りやすいのが、右下の領域です。
「標準では難しい」という事実だけを見て、開発で埋めてしまうケースが多くあります。しかしその業務が競争力に関係ないなら、費用と保守負担だけが残ります。
ここで問うのは、「なぜこの手順なのか」です。答えが出てこないなら、業務側を見直す余地があります。
AIの活用で線の引き方がどう変わったかは、どこを標準に合わせ、どこを自社流で残すかにまとめています。
「守る」と決める前のチェックリスト
現場から「標準では回らない」と挙がった業務ごとに、会議で次を確かめてください。
- □ この手順をやめたら、顧客や売上に目に見える影響が出るか
- □ 「なぜこの手順なのか」を、担当者以外も説明できるか
- □ 前のシステムやExcelの制約から生まれた手順ではないか
- □ 取引先に頼めば、相手側の手順を変えてもらえないか
- □ 設定の変更や、手作業を少し残すことで代わりにならないか
最初の2つに「はい」が付かない業務は、標準に寄せる候補です。残りの3つのどれかに当てはまる業務も、開発の前に業務側を見直せる可能性があります。
Odooで標準に寄せやすい領域・寄せにくい領域
Odooは30種類以上のコアアプリを持ち、業務範囲が広いのが特徴です（出典：Odoo公式 会社概要ページ、2026年8月確認）。そのため、標準に寄せやすい領域は比較的多くなります。
寄せやすい領域の例
- 見積・受注・請求といった販売の基本フロー
- 在庫の入出庫、ロケーション管理
- 経費精算、購買申請などの承認フロー
- 顧客・案件の管理（CRM）
慎重な確認が必要な領域
- 日本の商習慣に関わる処理（締め請求、手形、支払サイトなど）
- 業種固有の原価計算や積算
- 官公庁向けなど、様式が決まっている帳票
日本の会計慣行や制度対応は、変化が速い領域です。導入時点で、最新の対応状況を確認してください。詳しくはOdooの日本対応状況にまとめています。
Community版とEnterprise版で「標準の範囲」は変わる
見落とされやすい点ですが、Fit to Standardの「標準」が何を指すかは、エディションによって変わります。
- Community版：無料のオープンソース版。ホスティングと保守は自社の責任で、公式サポートの対象外。一部機能は含まれない
- Enterprise版：有償のサブスクリプション。公式サポートと全アプリを含み、ホスティングはOdooオンライン・Odoo.sh・自社サーバーから選べる
Community版を前提にすると、標準で実現できる範囲はその分狭くなります。同じ業務でも、Enterprise版なら標準で足りることがあります。
また、ノーコードで画面や項目を調整できるOdoo Studioには、利用条件があります。Odoo公式ドキュメントによれば、スタンダードプランのデータベースにStudioをインストールすると、カスタムプランへのアップセルが自動的に発生します。（出典：Odoo 19.0公式ドキュメント、2026年10月確認）
「標準に寄せる」と判断する前に、どのエディション・どのプランを前提にしているかをそろえてください。詳細はOdoo Community版とEnterprise版の違いで解説しています。
標準と自社流の線引き：ベンチャーネットが仕分けを進める順番
ERP導入支援を手がけるベンチャーネットは、Fit to Standardを「ITの設定作業」ではなく「経営の判断を積み重ねる工程」として進めます。順番は次の4段階です。
ステップ1：3〜5年後の会社の姿を先に確かめる
最初に聞くのは、機能の要望ではありません。3〜5年後の事業規模、拠点、扱う商材、事業承継やM&Aの予定です。
守るべき業務を決めるのは、この将来像からの逆算です。今の手順を守るかどうかは、その後で判断します。
ステップ2：標準の流れを先に見てもらう
要望を聞く前に、Odooの標準的な業務の流れを関係者で見ます。試用環境で、実際の取引を1件流してみるのが近道です。
先に要望を集めると、出てくるのは現状の再現案ばかりです。標準を見たうえで「これでは回らない」という部分だけを議題にすると、議題の数が大きく減ります。
ステップ3：経営層を交えて2軸で仕分ける
挙がった項目を、標準に寄せる業務と、守る業務の分け方のマトリクスとチェックリストで仕分けます。仕分けの軸は、「競争優位に直結するか」という問いです。
この問いに答えられるのは、経営層だけです。現場とシステム担当だけで決めようとすると、仕分けはそこで止まります。
ステップ4：手を入れる範囲を最小にする
対象は、右上に残った項目だけです。その中でも、設定で吸収できないかを先に検討します。
順番は「業務を変える→設定→ノーコード→開発」です。この順序を守るだけで、稼働後の保守負担は大きく変わります。
仕分けの結果、守るべき業務がOdooの標準から大きく外れることもあります。その場合は、Odooにこだわらずにそう伝えます。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。規模や要件が大きければNetSuite、パッケージに乗らない業務が中心ならAIスクラッチ開発も候補です。AIスクラッチ開発はライセンスがかからない代わりに、開発費と保守費が別途かかります。
Fit to Standardが失敗するとき
現場に説明せずに進める
「標準に合わせます」とだけ伝えると、現場には「一方的に決められた」と映ります。
現場と共有するのは、決定ではなく理由です。なぜその手順をやめるのか、やめると何が良くなるのかを説明してください。
例外を一切認めない
原則を厳格に運用しすぎると、本当に必要な業務まで削られます。稼働後に手作業が復活し、システムの外にExcelが増えます。
Fit to Standardは、「例外をゼロにする」考え方ではありません。例外を意識的に選ぶ考え方です。
標準の理解が浅いまま判断する
「標準ではできない」という結論が、実は設定を知らないだけだった。そういうケースは珍しくありません。
標準機能を十分に知っている人が照らし合わせに加わるかどうかで、結果が変わります。
よくある質問
Fit to Standardなら導入は早く終わりますか？
開発量が減るため、その分は短縮できます。ただし、判断の時間は減りません。
「この業務をやめる」という決定に時間がかかると、結局は延びます。早さを決めるのは開発量ではなく、意思決定の速度です。
現場が反発したらどうすればよいですか？
まず、変更で現場に生まれる利点を具体的に示してください。二重入力がなくなる、月次の締めが早くなる、といった実感できる変化が有効です。
反発の多くは、「手順が変わること」ではなく「理由がわからないこと」に向いています。
稼働後の定着についてはOdooを社内に定着させる方法でも扱っています。
標準に寄せると、他社と同じ会社になりませんか？
差がつかない業務を標準に寄せるだけなら、同じ会社にはなりません。会社の強みは、業務の手順そのものではなく、その手順が生む結果にあるからです。
差がつかない事務処理を標準化し、空いた時間を強みの部分に振り向けるほうが、結果的に差は広がります。
途中でFit and Gapに切り替えてもよいですか？
切り替えるなら、スコープと予算を見直すタイミングで明示的に切り替えてください。途中で方針が揺れると、判断基準が二重になり混乱します。
曖昧なまま進めるのが、一番よくありません。
Fit to Standardのメリットとデメリットは何ですか？
運用が軽くなる利点と業務を変える判断の負担の両方があります。
バージョンアップで不具合が出にくく、人が替わっても引き継げ、不具合の切り分けも早くなります。一方、「この業務をやめる」決定には時間がかかり、すべてを標準に寄せると強みまで平準化されることがあります（メリットとデメリット）。
まとめ
Fit to Standardは「カスタマイズをしない」という宣言ではありません。
- 出発点を現行業務ではなく、標準機能の流れに置く考え方
- 標準に寄せるべきは「差がつかない業務」
- 守るべきは「競争優位に直結し、標準では実現できない業務」
- 判断は「業務を変える→設定→ノーコード→開発」の順に検討する
- Community版とEnterprise版では「標準の範囲」自体が変わる
- 例外をゼロにするのではなく、例外を意識的に選ぶ
- メリットは運用の軽さ。注意点は業務を変える判断の時間と、強みの平準化
この線引きができている会社は、稼働後の追加費用が少なく、バージョンアップにも追随しやすくなります。隙のない設計を目指すより、まず標準で回し、動かしながら磨くほうが早く自社の形に近づきます。
1年後、Odooの次のバージョンの案内が届いても、確かめるのは自社流として残した数項目だけ。現場から新しい要望が出ても、「なぜこの手順なのか」の一問で、寄せるか守るかがその場で決まっていきます。
もう少し詳しく知りたい方へ
どの業務を標準に寄せ、どこを守るか。現場の要望一覧を前に迷っている段階でも、そのままお話しください。
この線引きには、Odooの標準機能への理解と、業務の意味を問い直す第三者の目の両方が要ります。ベンチャーネットは製品ありきではなく、規模と要件に合う形を一緒に考えます。
関連記事
