導入の打ち合わせで、現場から要望が30個出てきた。どれも「今のやり方ではこうしている」という切実なものです。
全部作れば、現場は喜びます。でも数年後、その作り込みを誰がどう守るのか。経営者が迷うのはここです。
Odoo（オドゥー：オープンソース由来の統合業務アプリ群）は、柔軟に手を加えられる製品です。手段を選べば、差がつく業務に投資しながら、将来の負担を軽くできます。
判断の軸になるのは、好みではなく、アップグレードのときにどう扱われるかです。手段は、設定・Studio・追加モジュール・独自開発の4つ。軽い順に検討し、それでも作るかどうかは5つの問いで決めます。
Odooの標準サポートは、各メジャーバージョン3年間です。同じバージョンに永久にとどまることはできません（アップグレード時の扱いが判断軸になる理由）。
手段の選び方を押さえると、たとえば次のことが変わります。
- 「標準ではできない」と言われた要件を、まず設定で吸収できる
- 標準の範囲に収めた部分は、バージョンアップでほぼ自動で移行できる
- Studioで作った調整を、条件を満たせば公式のアップグレード対象にできる
- 新しい要望が出ても、5つの問いに沿ってその場で仕分けられる
Odooには無料のCommunity版と有償のEnterprise版があり、使えるカスタマイズの手段が変わります。独自に作り込んだ部分は、バージョンアップのたびに改修と検証が要ります。
では、要望が多すぎるときはどうするか。そのときは、手段より先に、製品選びそのものを疑う必要が出てきます（カスタマイズが多すぎるときに疑うこと）。
なぜ「アップグレード時の扱い」が判断軸になるのか
Odooは、原則として年1回メジャーバージョンアップがあります。
Odoo公式ドキュメントによれば、各メジャーバージョンの標準サポートは3年間です。不具合の修正やセキュリティ更新も、この期間が対象です。3年を過ぎると、追加料金が必要な延長サポートになります。延長サポートを使えるのは、Odoo.sh（一部の版）とオンプレミスだけです（出典：Odoo公式ドキュメント、2026年10月確認）。
つまり、同じバージョンに永久にとどまることはできません。数年ごとに、必ず上げることになります。
このとき、カスタマイズした部分の扱いで負担が大きく変わります。
- 標準の仕組みの範囲なら、ほぼ自動で移行できる
- 独自に作り込んだ部分は、毎回改修と検証が必要になる
だから判断は、「今いくらかかるか」だけでは足りません。この先何年、何回分の負担を引き受けるか。それを決めることになります。
手段1：設定で対応する
もっとも安全な手段です。開発を伴わず、Odooの標準機能の範囲で調整します。
対応できる範囲は、思っているより広いことが多いものです。
- 項目の追加・非表示・並び順の変更
- ユーザーごとの権限、部門ごとの表示制御
- 承認ルートやステータスの設定
- 請求書などの帳票テンプレートの調整
- 単位・税区分・支払条件などのマスタ設定
「標準ではできない」と言われた要件が、設定を知らないだけだった。そんな例は珍しくありません。
まず、設定で吸収できないかを検討してください。考え方はOdooとFit to Standardで詳しく扱っています。
手段2：Studioで調整する
Odoo Studioは、コードを書かずに画面・項目・自動化を調整できるツールです。機能の詳細はOdoo Studioとは？にあります。
判断にかかわるのは、次の2点です。
利用条件がある
スタンダードプランのデータベースにStudioを入れると、カスタムプランへのアップグレードが自動的に発生します。Odoo公式ドキュメントに、そう記載されています（出典：Odoo 19.0公式ドキュメント、2026年10月確認）。
Studioを使う前提なら、料金プランの選択も一緒に考える必要があります。
アップグレードの対象に含まれる
Odoo公式ドキュメントは、Studioで作ったカスタマイズの扱いを次のように案内しています（出典：Odoo 19.0公式ドキュメント、2026年10月確認）。Studioがインストールされたままで、該当のサブスクリプションが有効なら、アップグレードサービスの対象です。
実務では、これが大きな違いになります。同じ調整でも、Studioで実現できれば将来の負担が軽くなります。
ただし、「Studioなら何でも変えてよい」わけではありません。この点は、Studioなら自由に変えていいかで触れます。
手段3：サードパーティ製モジュールを追加する
Odooには、公式のコアアプリのほかに、外部の開発者やコミュニティが提供するモジュールが多数あります。Odoo公式は、コミュニティ提供のアプリが5万を超えると案内しています（出典：Odoo公式 会社概要ページ、2026年8月確認）。
うまく使えば、開発せずに要件を満たせます。その一方で、導入前に確かめる点もはっきりしています。
| 確認する点 | なぜ重要か |
|---|---|
| 対応バージョン | 最新バージョンに対応していないものがある |
| 更新の頻度 | 更新が止まったものは、次のバージョンで使えなくなる恐れがある |
| 提供元 | 個人が趣味で公開したものか、事業として保守されているものか |
| 他モジュールとの干渉 | 同じ画面を書き換えるもの同士がぶつかることがある |
| ライセンス | 商用利用や再配布の条件を確認する |
最大のリスクは、自社ではコントロールできないことです。提供元が更新をやめれば、そのモジュールに頼った業務ごと止まります。
基幹業務の中核に置くなら、代わりの手段があるかまで考えてください。
手段4：独自に開発する
自社専用のモジュールを設計して作る方法です。自由度は最大になります。
Odoo公式ドキュメントは、開発したカスタマイズの扱いも案内しています（出典：Odoo 19.0公式ドキュメント、2026年10月確認）。カスタマイズの保守に関するサブスクリプションの対象となる開発は、アップグレードサービスの対象です。
裏を返せば、そうした取り決めがない開発は、自社の側で面倒を見ることになります。
独自開発を選ぶなら、次をセットで用意してください。
- 何を、なぜ、どう作ったかの設計文書
- バージョンアップ時の検証手順とテストデータ
- 改修を担当する体制（社内か、外部か）
これがない独自開発は、数年後に「誰も触れないブラックボックス」になります。
Odooでカスタマイズするメリットとデメリット
4つの手段を並べると、手を加える良さと、その代わりに引き受ける負担が見えてきます。使える版も添えます。
メリット
- 差がつく業務に合わせられる：Odooは柔軟に手を加えられ、競争力に直結する業務には手を入れる価値がある
- Studioならコードを書かずに調整できる：画面・項目・自動化を調整でき、条件を満たせば公式のアップグレードサービスの対象になる。Community版にStudioは含まれない
- モジュールで開発せずに要件を満たせる：コミュニティ提供のアプリは5万を超え、うまく使えば開発が要らない
- Community版は改造の自由度が高い：ソースコードに手を入れられ、内製できる技術者がいれば選択肢になる
デメリット・注意点
- 作り込むほどバージョンアップが重くなる：独自に作り込んだ部分は、毎回改修と検証が必要になる
- Studioは料金プランに影響する：スタンダードプランのデータベースに入れると、カスタムプランへのアップグレードが発生する
- モジュールは自社でコントロールできない：提供元が更新をやめれば、頼った業務ごと止まる
- 改造した分の面倒は自社で見る：Community版の改造や取り決めのない開発は、設計文書と改修体制がないとブラックボックスになる
両方を並べると、次の図のとおりです。
注意点の避け方は、カスタマイズすべきかを判断する5つの問いとベンチャーネットが確かめる順番にあります。
Odooでカスタマイズすべきかを判断する5つの問い
具体的な要望を前にしたら、次の順で問えば判断できます。
とくに見落とされがちなのが、問5です。作る費用は見積もりに出ますが、維持する体制は見積もりに出ないからです。
会議で要望を仕分けるときは、次の表を横に置くと話が早く進みます。
| 手段 | アップグレード時の扱い | 先に確かめること |
|---|---|---|
| 設定 | 標準の範囲なので、ほぼ自動で移行 | 本当に設定で足りないのか |
| Studio | 条件を満たせば公式のアップグレード対象 | プランへの影響と、作り込みすぎていないか |
| 追加モジュール | 提供元の対応しだい | 対応バージョン・更新頻度・提供元 |
| 独自開発 | 取り決めがなければ自社で改修・検証 | 設計文書と改修体制を用意できるか |
Community版とEnterprise版で何が変わるか
カスタマイズの選択肢は、エディションによって変わります。
| 版 | 中身 |
|---|---|
| Community版 | 無料のオープンソース版。ソースコードに手を入れる自由度は高いが、ホスティングと保守は自社の責任で、公式サポートの対象外。Studioなど一部の機能は含まれない |
| Enterprise版 | 有償のサブスクリプション。公式サポートと全アプリを含み、公式のアップグレードサービスを利用できる |
Community版は、「自由に改造できる」点が魅力に映ります。しかし、改造した分の面倒は、すべて自社で見ることになります。
分かれ目は、内製できる技術者がいるかどうかです。詳しくはOdoo Community版とEnterprise版の違いにまとめています。
カスタマイズが多すぎるときに疑うこと
差分が想定より多いとき、問題は手段の選び方にはありません。選んだ製品が合っていない可能性があります。
考えられる方向は、次の2つです。
規模が大きい／要件が高度な場合
グローバル連結や高度な内部統制が必要なら、上位の製品が合うことがあります。この場合は、NetSuiteやSAPが選択肢になります。
NetSuiteを選んだ場合のカスタマイズの手段は、NetSuiteのカスタマイズ完全ガイドが参考です。
業務が固有すぎる場合
パッケージの型に乗らない業務なら、必要な機能だけを自社資産として作る、AIスクラッチ開発という道もあります。
ただし、スクラッチ開発は、ライセンス費用がない代わりに開発費と保守費が別途かかります。「ライセンス不要＝安い」ではありません。
この場合も、設計文書と保守体制の整備は欠かせません。将来の事業承継やM&A（合併・買収）では、独自システムの属人化が論点になります。
考え方は、パッケージERPかスクラッチ開発かに書きました。
要望一覧を受け取ったとき、ベンチャーネットが確かめる順番
ERP導入支援を手がけるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。AIスクラッチ開発は、ライセンス費用がない代わりに開発費・保守費が別途かかります。製品に偏らない立場で、次の順に線を引きます。
- 要望を「目的」に言い換える：「この項目が欲しい」を「誰の、どの判断のために必要か」に直します。目的が同じ要望は、ここで1つにまとまります
- 標準機能で動かして差分を見る：Fit to Standard（標準機能に業務を合わせる考え方）で、標準のまま業務を流してみます。違和感が残る部分だけを、差分として記録します
- 差分を2つに分ける：競争力に直結する業務か、差がつかない事務処理かを分けます。後者は、業務の側を標準に合わせる案を先に出します
- 手段を軽い順に当てる：設定→Studio→追加モジュール→独自開発の順に検討します。Studioならプラン、独自開発なら改修体制まで同時に示します
- 差分が多ければ、製品を変える案も出す：3〜5年後の規模から逆算し、Odooが合わないときは合わないとお伝えします
カスタマイズの判断は、IT部門の作業ではなく経営判断です。何を標準に任せ、何に投資するかを決めることだからです。
AIの活用で、標準と自社流の線の引き方がどう変わったかは、どこを標準に合わせ、どこを自社流で残すかで扱っています。
よくある質問
カスタマイズは全部やらないほうがいいですか？
そうではありません。競争力に直結する業務なら、手を入れる価値があります。
問題は、差がつかない事務処理まで作り込むことです。判断は、業務ごとに分けてください。
Studioなら自由に変えていいですか？
無制限に変えてよいわけではありません。コードを書かないぶん安全度は高いものの、限度はあります。
作り込みすぎると、標準の画面が原形をとどめなくなります。担当者が代わったとき、誰も理解できなくなります。「変えられる」と「変えるべき」は別です。
導入時に決めたカスタマイズは、後から減らせますか？
減らせます。ただし、業務側の手順を戻す必要があるため、簡単ではありません。
だからこそ、稼働前の線引きが重要です。迷ったら第1段階では入れず、稼働後に本当に必要か確かめる。そのほうが安全です。
サードパーティ製モジュールは使わないほうがいいですか？
一律に避ける必要はありません。保守されているモジュールなら、開発するより早く要件を満たせることがあります。
確認したいのは、対応バージョン・更新頻度・提供元です。基幹業務の中核に置く場合に限り、慎重に判断してください。
開発した部分は、バージョンアップのときに必ず壊れますか？
必ず動かなくなるわけではありません。ただ、動くかどうかは、毎回検証しないと分かりません。
負担の中身は、「動かなくなるかどうか」より、「毎回検証する手間が発生する」ことにあります。
Odooでカスタマイズするメリットとデメリットは何ですか？
差がつく業務に合わせられる一方で作り込むほど保守負担が増えます。
Studio（Community版には含まれない）や保守されているモジュールを使えば、開発せずに要件を満たせることもあります。一方、独自に作り込んだ部分は、バージョンアップのたびに改修と検証が必要です（メリットとデメリット）。
まとめ
Odooのカスタマイズは、好みではなく構造で判断できます。
- Odooの標準サポートは、各メジャーバージョン3年間。いずれ必ず上げることになる
- だから判断軸は「今の費用」ではなく「この先の負担」
- 手段は、設定 → Studio → 追加モジュール → 独自開発の順に検討する
- Studioで作った調整は、条件を満たせば公式のアップグレード対象に含まれる
- サードパーティ製モジュールは、対応バージョンと提供元の継続性を確認する
- 独自開発は、設計文書と改修体制をセットで用意する
- 差分が多すぎるときは、製品選定そのものを疑う
- メリットは差がつく業務に合わせられること。注意点は作り込みに比例する保守負担
すべて作り込んでから稼働させるより、まず標準で回し、必要な部分だけ後から磨く。この順番のほうが、結果的に無駄が少なくなります。
1年後、最初のバージョンアップ計画を立てる会議で、作り込んだ箇所の一覧がA4一枚に収まっている。新しい要望が出ても、5つの問いに沿って担当者がその場で仕分けている。そんな姿を目指してください。
もう少し詳しく知りたい方へ
「この要望は標準で吸収できるのか、作るべきなのか」。要望一覧を前に迷っている段階から、線引きをご一緒します。
関連記事
