保守契約の更新案内が届き、見積もりには今年も業種別オプションの費用が並んでいる。けれど、そのオプションを毎月使っているのか、社内で即答できる人がいない。
長く使ってきた国産の基幹システムを、見直すかどうか。この迷いは、使っている範囲を棚卸しすると、判断できる形に変わります。想定しているのは、販売・会計を軸に業種別の機能を足してきたシステムです。SMILE V やスーパーカクテルのような製品群が代表例になります。
判断の軸は3つです。見直したい理由が移行で解決するものか。いま何をどこまで使っているか。そして、業種固有の要件を移行先でどう扱うか。
Odooでは、受注が在庫に反映され、請求につながる流れを作れます。販売と会計のあいだをExcelが埋めている状態から、この流れを作りたい場合に効果が出ます（Odooが候補になる条件）。
3つの軸で見直すと、たとえば次のことが変わります。
- 契約中の機能のうち、実際に動いている範囲が分かる
- 使っていない機能を外し、移行の範囲を小さくできる
- 譲れない要件の一覧をもとに、続けるか移るかを会議で決められる
- 段階的に移すなら、業種固有の要件がある領域を後に回せる
ただし、業種固有の要件が業務の中核なら、いまの製品を使い続けるほうが合理的です（Odooが候補にならない条件）。
では、続けるか移るかの分かれ目はどこにあるのか。答えは業種固有の要件をどう扱うかにあります。
CommunityとEnterpriseの区別について
Odooには無料のCommunity版と、有償のEnterprise版があります。販売・在庫・購買・製造といった基本機能は、両版で使えます。
一方、財務諸表の出力や部門別の管理会計といった会計のフル機能は、Enterprise版が前提です。販売から会計まで一続きで扱いたい場合は、この点が判断に関わります。
まず「なぜ見直したいのか」を切り分ける
移行の検討で最初にやるべきことは、製品の比較ではありません。見直したい理由をはっきりさせることです。
| 見直したい理由 | 打つべき手 |
|---|---|
| 費用が事業規模と釣り合わない | 契約の見直し、または規模の適正化 |
| 改修のたびに費用と時間がかかる | 原因は設計。製品を替えても解決しない可能性 |
| 業務範囲を広げたい | 対応範囲の確認。移行の理由になり得る |
| 他システムとつなげたい | 連携の可否を確認。移行とは限らない |
| 使いこなせていない | 定着支援。移行では解決しない |
| 更新の時期が来た | 継続か見直しかの分岐。検討の好機 |
表のとおり、移行では解決しない問題があります。
改修費用がかさむ原因が設計にあるなら、新しい製品でも同じ思想で作れば同じことが起きます。定着していないことが原因なら、製品を替えても定着しません。
費用の内訳から切り分けたい場合は、ライセンス費用の見直し方の記事が出発点になります。更新の時期を迎えて迷っている場合は、基幹システムは「更新」か「乗り換え」かで判断の分かれ目を扱っています。
国産中堅パッケージが積み上げてきたものを見る
「業種別の作り込み」で個別要件を吸収してきた
このタイプの製品は、標準機能だけで幅広い業種に対応しているわけではありません。業種別の製品やテンプレートを足すことで、個別の要件を吸収してきました。
たとえば SMILE V は、販売・会計・人事給与という基幹の業務に、業種別製品を足す構成です。製造業・建設業・運送業などが対象として挙げられています（出典：開発元の公式サイト、2026年9月確認）。
スーパーカクテルも同じ考え方です。業種・業務テンプレートに加えて、パラメータ設定とプログラムカスタマイズ機能を備えていると説明されています（出典：開発元の公式サイト、2026年9月確認）。
作り込みは、資産でもあり移行コストでもある
この構造は、使う側にとって大きな価値でした。業界特有の処理が最初から入っているので、ゼロから作らずに済みます。
ところが移行を考える段になると、この作り込みが負担に変わります。何がどこまで作り込まれているのかを、社内で正確に把握している人が少ないからです。
最初の一歩は「使っている範囲」の棚卸し
そこで、棚卸し（いま使っているものの洗い出し）が必要になります。確認したいのは、次の3つです。
- 契約している機能のうち、実際に動いているのはどこか
- 業種別の機能のうち、毎月使っているのはどれか
- 独自に作った画面や帳票のうち、いま参照されているのはどれか
「入っているが使っていない」機能が見つかれば、移行の範囲はそのぶん小さくなります。棚卸しをせずに「いまと同じものを」と発注すると、使っていない機能まで含めて見積もられてしまいます。
「クラウド化」の意味は、製品ごとに違う
3つの形がある
「クラウド対応」という言葉は、実際には違う3つの形を指しています。ここを混同したまま比べると、運用の負担を見誤ります。
| クラウドの形 | 誰が基盤を持つか | バージョンアップの考え方 |
|---|---|---|
| 自社サーバーでの運用 | 自社 | 自社の判断と作業で実施 |
| 基盤を借りる形 | 事業者の基盤に自社専用の環境 | 載せているソフトの更新は別途 |
| サービスとして使う形 | 事業者が共通の環境を運用 | 提供側が進め、常に最新 |
実際の製品ではこうなっている
SMILE V で提供されているのは、クラウド版（SMILE V Air）とオンプレミス版（SMILE V 2nd Edition）です。公式サイトの説明は次のとおりです（出典：開発元の公式サイト、2026年9月確認）。
- オンプレミス版：保守サービスの契約期間中に最新版をダウンロードする形
- クラウド版：常に最新の状態で使える形
同じ公式サイトでは、オンプレミス版のみの製品があることも示されています。業種別製品は、製品ごとに提供形態が異なります（出典：開発元の公式サイト、2026年9月確認）。2nd EditionとAirの違いと、使い続けるかどうかの物差しは、SMILE Vとは？2nd EditionとAirの違いで整理しています。
推奨環境の記載からも、運用に関わる条件が読み取れます。クラウド版でも、利用者の端末には専用のクライアント環境が前提です。ブラウザやモバイルで使える範囲は限られています（出典：開発元の公式サイト、2026年9月確認）。
スーパーカクテルのクラウド提供は、公式サイトで「IaaS（クラウド）環境で」と説明されています。IaaSは、サーバーなどの基盤を借りる形のことです。運用監視やヘルプデスクを含むマネージドサービスと、利用型のライセンスが用意されています（出典：開発元の公式サイト、2026年9月確認）。
Odooの場合はどうなっているか
Odooの運用の置き場所は3つあります。Odooが提供するクラウド（Odooオンライン）、開発環境つきのクラウド（Odoo.sh）、そして自社サーバーでの運用（オンプレミス）です。
ただし、Community版はOdooオンラインの対象外です。無償で使う場合は、ホスティングと保守を自社で持つことになります。運用の責任範囲の違いは、Odooの導入形態3つの比較で整理しています。
比較のときに確認したい2つのこと
ひとつは、いまの「クラウド化」が基盤の置き換えだったのか、使い方まで変わる話だったのかです。まだ自社サーバーで運用している場合も、次にどの形を選ぶかを先に決めておくと、比較がぶれません。
もうひとつは、利用者の端末に何を入れる必要があるかです。見落とされがちですが、台数が増えるほど運用の負担に響きます。候補ごとに、この条件を同じ粒度で並べてください。
移行の最大の論点：業種固有の要件をどう扱うか
ここが最大の論点になる
業種別の作り込みを使ってきた企業にとって、移行の最大の関門は業種固有の要件です。
たとえば食品を扱う事業なら、次のような要件が業務の前提になっていることがあります。
- 賞味期限・消費期限の管理
- ロット単位のトレーサビリティ（製品の履歴を追える状態）
- 原材料の配合管理
- 業界特有の取引条件や単位
これらは、汎用のERPの標準機能だけでは満たせない場合があります。
対応は3つある
| 選択肢 | 中身 | 合う場面 |
|---|---|---|
| 1. いまの製品を使い続ける | 無理に汎用製品へ移さない | 要件が製品の中核に組み込まれている |
| 2. 汎用ERPに拡張を組み合わせる | 標準機能に加え、設定や拡張モジュールで満たす | 実現できるかは要件の内容しだい |
| 3. 業務のやり方そのものを見直す | 「本当に必要なもの」と「惰性で続けているもの」を仕分ける | 見直しで要件そのものが減ることもある |
3つ目は軽く見られがちですが、実務では効果の大きい選択肢です。標準に業務を合わせる考え方は、Fit to Standardという方針で詳しく扱っています。
選択肢1と選択肢2を分ける線
判断に迷うのは、選択肢1と選択肢2の境目です。目安になる問いが2つあります。
ひとつは、売上の作り方そのものに、その要件が関わっているか。取引先との商流や、製品の作り方に組み込まれているなら、選択肢1に寄ります。
もうひとつは、その要件を扱う場面が月に何度あるかです。日常的に何度も通る道なら、標準機能で扱えることが欠かせません。年に数回なら、別の手段でも回ります。
製造の要件については、製造業のOdoo活用で、標準機能で扱える範囲と難しい範囲をまとめています。
会議で使える「続けるか、移るか」のチェック
次の項目に、社内で答えを出してみてください。上の3つに多く当てはまるほど、いまの製品を続ける理由が強くなります。下の3つが多ければ、移行を検討する意味があります。
- □ 業種別の機能を外すと、受注や出荷が止まる
- □ その要件は取引先との約束や、製品の作り方そのものに組み込まれている
- □ 困っている理由が、設計や定着の問題に行き着く
- □ 販売と会計のあいだを、毎月Excelと手作業で埋めている
- □ 棚卸しの結果、契約中の機能の多くが使われていなかった
- □ 業務範囲を広げたいが、いまの製品では対応が難しい
どちらとも言えない項目は、「業界特有だから」で止まっているサインです。何をどう管理する必要があるのかを、具体的な項目に書き出すところから始めてください。
Odooが国産パッケージの移行先候補になる条件
複数の業務をひとつにつなげたい
Odooの価値は、アプリ同士がデータでつながる点にあります。
受注が在庫に反映され、請求につながる。販売と会計が別のシステムで、あいだをExcelが埋めている。そんな状態からこの流れを作りたい場合に、効果が出ます。
ただし、この流れのうち両版で扱えるのは請求書発行までです。財務諸表の出力や部門別の管理会計まで求めるなら、Enterprise版が前提になります。
段階的に広げたい
Odooはアプリ単位で始められます。一度にすべてを切り替えなくてよい設計です。
業種固有の要件がある領域は後に回し、まず影響の小さい領域から始める進め方もできます。
ただし、課金の区切りは知っておいてください。1アプリのみ無料の One App Free から、2つ目のアプリを足した時点で有償プランに切り替わります。
同じ数字を、関わる全員が見られる状態にしたい
各アプリには標準の一覧画面があり、ピボットやグラフで集計できます。この範囲はCommunity版・Enterprise版の両方で使えます。
担当者ごとにExcelを持ち寄って数字を見比べている。その状態から抜けたい場合、ここが出発点です。
なお、標準で用意されたダッシュボードは両版で見られます。表計算（スプレッドシート）で自由に組むダッシュボードは、Enterprise版の範囲です。どこまで求めるかで、必要な版が変わります。
自社でソースを確認できる状態を保ちたい
Community版は、オープンソース（LGPL）として公開されています。中身を確認したり、自社の責任で手を入れたりできる状態です。
ただしCommunity版は、ホスティングと保守が自社責任で、公式サポートの対象外です。この条件を引き受けられるかが分かれ目になります。
自社環境での運用要件がある
社内規程やデータの扱いの制約でクラウドを使いにくい場合、Odooは自社サーバーでの運用も選べます。
ただし、選べることと自社で運用できることは別です。運用の責任も同時に引き受けることになります。
Odooへ移る良い点と、気をつけること
5つの条件のどれかに当てはまる会社にとって、Odooへの移行は、ばらばらだった業務と数字をつなぎ直す機会です。版ごとの違いも含めて、得られることと負担を並べます。
良い点は、次の5つです。
- 販売から請求までが一続きになる：受注が在庫に反映され、請求につながる。両版で扱えるのは請求書発行までで、財務諸表や部門別の管理会計はEnterprise版が前提
- 同じ数字を関わる全員で見られる：一覧画面のピボットやグラフでの集計は、両版で使える
- 段階的に広げられる：アプリ単位で始め、業種固有の要件がある領域は後に回せる
- 置き場所を選べる：Odooオンライン・Odoo.sh・オンプレミスから選べる（Community版はOdooオンラインの対象外）
- 中身を確認できる：Community版はオープンソース（LGPL）として公開されている
気をつけることは、次の4つです。
- 業種固有の要件は再現を確かめる：標準で足りるもの、設定や拡張で対応できるもの、難しいものに分かれる
- 給与は国産ソフトとの併用が現実的：Odooの給与計算は、日本のローカライズが公式に提供されていない
- 2つ目のアプリから有償になる：One App Freeから2つ目のアプリを足した時点で、有償プランに切り替わる
- 自社で持つなら責任も自社にある：Community版はホスティングと保守が自社責任で、公式サポートの対象外
両方を1枚の図に並べました。
気をつけることの避け方は、移行で失敗しないための注意点で扱います。
Odooではどこまで扱えるか（版ごとの対応範囲）
移行後に何がどこまでできるかは、版によって変わります。移行検討に関わる範囲は次のとおりです。
| 業務 | Community版 | Enterprise版 |
|---|---|---|
| 販売（見積・受注）・在庫・購買・製造 | 使える | 使える |
| 請求書発行など基本的な範囲の会計 | 使える | 使える |
| 会計のフル機能（財務諸表、分析会計、部門別の管理会計） | 対象外 | 使える |
| 画面・項目のノーコードでの変更（Odoo Studio） | 対象外 | 使える |
| 表計算で自由に組むダッシュボード（スプレッドシート機能） | 対象外 | 使える |
| ホスティング・保守・障害対応 | 自社責任 | 公式サポートに含まれる |
版ごとの対応範囲は改定されることがあります。導入を検討する段階で、Odoo公式のエディション比較ページで最新の内容をご確認ください。
アクセス権限や認証の基本的な仕組みは、両版で共通です。差が出るのは、ホスティングやバックアップ、障害対応を誰が担うかという運用面です。
Odooが候補にならない条件
次の場合は、Odoo以外の選択肢を検討してください。
- 業種固有の要件が、そのまま業務の中核になっている：いまの製品を使い続けるほうが合理的です
- 規模が大きくなり、海外展開や連結決算が視野に入る：NetSuiteなど上位のERPが合ってきます
- グローバルで複雑な要件がある：SAPも視野に入ります
- 給与を同じシステムで扱いたい：Odooの給与計算は、日本のローカライズが公式に提供されていません
- 業務が固有すぎてパッケージに乗らない：必要な機能だけをAIスクラッチ開発で作るほうが現実的なこともあります。この場合、開発費と保守費が別途発生します
Odooに寄せる理由がない案件を、Odooに寄せることはしません。
ベンチャーネットが移行の相談で最初に確かめる順番
ERP導入支援を手がけるベンチャーネットは、製品の比較から話を始めません。国産中堅パッケージからの相談では、次の順番で確かめます。
ステップ1：見直したい理由が切り分けの表のどこに当たるか決める
費用なのか、範囲なのか、連携なのか、定着なのか。見直したい理由の切り分けの表で、当てはまる行を決めます。設計や定着が原因なら、移行を勧めずに別の手を一緒に考えます。
ステップ2：使っている範囲を棚卸しする
契約している機能、業種別の機能、独自に作った画面や帳票。動いているものと止まっているものを分けます。止まっている機能は、移行の対象から外すのが基本です。
ステップ3：譲れない要件を、項目の粒度で書き出す
「業界特有だから」で止めず、何をどう管理するのかまで落とし込みます。この作業が、判断のすべてを左右します。
ステップ4：いちばん難しい要件から実現可否を確かめる
標準機能・設定・拡張のどれで満たせるかを見ます。少人数で本番と同じ環境を試すのが確実です。ここを越えられなければ、移行しないという結論も出します。
ステップ5：3〜5年後の姿から、移行先と段取りを決める
規模や海外展開の見通しによっては、NetSuiteが合うこともあります。パッケージに乗らなければAIスクラッチ開発も候補です（開発費・保守費は別途かかります）。領域を区切った段階移行を基本にし、稼働後の90日で何を確認するかもこの段階で決めます。
国産パッケージからの移行で失敗しないための注意点
現行システムをそのまま再現しない
長く使ったシステムほど、独自の設定や運用が積み上がっているものです。
それをそのまま再現しようとすると、費用も期間も膨らみます。しかも、非効率な業務まで移植することになります。
移行は、業務を見直す機会です。標準機能に業務を合わせる発想を、最初に方針として決めてください。
保守契約と法改正対応の関係を確認する
自社サーバーで使っている場合、最新版を入手する条件が保守契約に結びついていることがあります。
SMILE V のオンプレミス版は、保守サービスの契約期間中に最新版をダウンロードする形です（出典：開発元の公式サイト、2026年9月確認）。
つまり、保守を止めると法改正への対応も止まる構造になり得ます。移行の時期を決める前に、この条件を確認しておいてください。
データをそのまま持ち込まない
古い取引先、使われていない品目、重複した情報。
これらを移行すると、新しいシステムでも同じ混乱が続きます。移行の前に、何を残し何を捨てるかを決める工程が要ります。
取り出せる形式の確認も、同時に行ってください。公式サイトに連携手段が明記されていない製品もあります。何をどの形式で取り出せるかは、移行の前提条件です。進め方はOdooのデータ移行で扱っています。
よくある質問
いまの業種別機能は、Odooで再現できますか？
再現できるかどうかは、要件の内容で決まります。
標準機能で足りるもの、設定や拡張で対応できるもの、対応が難しいもの。この切り分けは、要件を具体的に書き出さないと判断できません。まず要件の言語化から始めてください。
移行せずに負担を減らす方法はありますか？
あります。
使っていない機能の整理、契約内容の見直し、あるいは定着支援で改善する場合があります。原因が設計や定着にあるなら、移行では解決しません。
クラウド版に移ったのに、手間が減らないのはなぜですか？
「クラウド化」が基盤の置き換えだった場合、使い方も運用の手間もあまり変わらないからです。
「クラウド化」の3つの形のうち、どれに当たるのかを確認してください。バージョンアップを誰がどう進めるかで、日々の負担は大きく変わります。
日本の会計や税制には対応できますか？
分野によって状況が違い、給与計算は日本のローカライズが公式に提供されていません。給与は国産ソフトと併用する形が現実的です。
インボイス制度や電子帳簿保存法などの日本固有の要件は、対応状況を確かめたうえで検討する必要があります。検討の初期に確認すべき項目です。
国産パッケージからOdooへ移るメリットとデメリットは何ですか？
業務と数字がつながる一方で業種固有の要件の確認が要ります。
Odooでは、受注から在庫、請求までをひとつの流れでつなげます。財務諸表や部門別の管理会計まで求めるなら、Enterprise版が前提です。一方で、業種固有の要件は再現できるかを確かめる必要があり、給与は国産ソフトとの併用が現実的です。両方の一覧はOdooへ移る良い点と、気をつけることにあります。
まとめ：国産パッケージの見直しは、棚卸しと言語化から始める
- まず「なぜ見直したいのか」を切り分ける。設計や定着が原因なら、移行では解決しない
- 国産中堅パッケージの価値は業種別の作り込み。移行の第一歩は、使っている範囲の棚卸し
- 「クラウド化」には3つの形がある。基盤を借りたのか、サービスとして使うのかで、運用負担が変わる
- 業種固有の要件は、具体的な項目に書き出し、難しいものから先に検証する
- 要件が業務の中核なら、いまの製品を続けるほうが合理的なこともある
システムの見直しでは、「いまの事業に、どんな基盤が釣り合うのか」を考え直します。システムの話であると同時に、経営の話でもあります。
1年後、次の保守契約の更新案内が届いたとき、手元には使っている機能と譲れない要件の一覧があります。続けるか移るかを、その一覧と照らして落ち着いて決められる会社になっています。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
「いまのシステムが、何をどこまで作り込んでいるのか分からない」という整理から、ご相談を承っています。
関連記事
