Odooのバージョンアップとサポート期間|年1回の宿題とどう付き合うか

導入の検討中に、この話が出ることはあまりありません。

けれども、稼働してからいちばん長く付き合うのがこのテーマです。

Odooは原則として年1回、メジャーバージョンが上がります。つまり、毎年やってくる宿題があるということです。

この記事では、その宿題とどう付き合うかを整理します。

目次

まず前提の整理

年1回のメジャーリリース

Odooは、原則として年1回メジャーバージョンをリリースします。バージョン番号が1つ上がる更新です。

これは早いペースです。国産の業務パッケージと比べると、更新の頻度が高い部類に入ります。

サポートされるのは新しい数世代

Odooのサポート対象は、直近の数バージョンに限られます。

古いバージョンを使い続けると、いずれサポートの対象外になります。セキュリティの修正も受けられなくなる可能性があります。

具体的に何世代が対象かは、時期やバージョンによって変わります。 検討時には必ずOdoo公式の情報でご確認ください。

アップグレードの支援には条件があります

Odoo公式は、アップグレードに関するサービスを提供しています。ただし、その対象や範囲には契約上の条件があります。

Community版を自社で運用している場合、公式のアップグレード支援は受けられません。

エディションの違いは Odoo Community版とEnterprise版の違い をご覧ください。

【本質】重さを決めるのは、カスタマイズの量です

ここが、この記事でいちばんお伝えしたい点です。

バージョンアップの負担は、Odooの都合で決まるのではありません。自社がどれだけ独自の作り込みをしたかで決まります。

カスタマイズの種類によってバージョンアップの負担が変わることを示した図 設定変更による対応は負担が軽く、ノーコードツールによる項目追加は中程度、独自開発モジュールやソースコードの改変は負担が重いという、3段階の構造を示した図です。 同じ「カスタマイズ」でも負担がまるで違う ① 設定で対応 アプリの選択・項目の設定・承認ルール・価格表 負担:軽い(基本的に引き継がれる) ② ノーコードで追加 Studioでの項目追加・画面調整・自動化ルール 負担:中(動作の確認が必要) ③ 独自開発 自社開発モジュール・第三者モジュール・コード改変 負担:重い(作り直しが必要になることも) 毎年、この確認が発生する

なぜ③が重いのか

Odooの本体が変われば、それに接続していた独自の部分も影響を受けます。

  • 参照していた機能の仕様が変わる
  • 画面の構造が変わる
  • 前提にしていた項目がなくなる

これを毎年確認することになります。 そして問題が見つかれば、直す作業が発生します。

導入時の判断が、毎年の負担を決めます

ここが重要です。導入時に「これくらいなら作り込んでもいいだろう」と判断した内容が、その後ずっと自社に返ってきます。

だからこそ、カスタマイズの判断は慎重に行う必要があります。考え方は OdooのカスタマイズはどこまでやるべきかOdooとFit to Standard にまとめています。

バージョンアップの進め方

バージョンアップ作業の基本的な流れを示した図 影響範囲の洗い出し、検証環境での試行、業務側での確認、本番反映という4段階の流れと、それぞれの段階で必要な作業を示した図です。 本番にいきなり当てない ① 影響範囲を洗う 独自部分の一覧化 ② 検証環境で試す 本番データの複製で ③ 業務側で確認 現場が実際に触る ④ 本番へ反映 業務の谷を選ぶ ③が抜けると、稼働後に現場から問題が出る 技術的に動くことと、業務が回ることは別 戻せる状態を確保してから実行する バックアップと、戻す判断の基準を先に決めておく

③を飛ばさないでください

技術的な検証だけで済ませて、業務側の確認を省く。これがいちばん多い失敗です。

技術的に動くことと、業務が回ることは別です。

画面の並びが変わっただけで、現場の作業手順は変わります。帳票の見た目が変われば、取引先から指摘が入ることもあります。

現場の人が実際に触る時間を、必ず計画に入れてください。

検証環境の重要性

検証環境があるかどうかで、この作業の安全性は大きく変わります。

Odoo.shには開発・ステージング・本番の3環境が用意されています。詳しくは Odoo.shとは?3つの環境で「壊さずに変える」仕組み をご覧ください。

オンプレミスの場合は、自社で検証環境を用意する必要があります。

計画に組み込んでおくべきこと

バージョンアップは、思い出したときにやる作業ではありません。最初から年間の計画に入れておくものです。

(1) 実施時期を決めておく

繁忙期を避けた時期に、あらかじめ枠を取ってください。決算期や、業界の繁忙期は外します。

(2) 独自部分の一覧を維持する

何を作り込んだのか、なぜ作ったのか。この記録がないと、毎回ゼロから調べることになります。

作った時点で残してください。半年後の自分は、他人です。

(3) 担当と体制を決めておく

誰が作業し、誰が確認し、誰が実行の判断をするのか。

担当者が1人しかいない場合、その人が動けない時期には実施できません。 体制の考え方は Odooの運用・保守で押さえるポイント一人情シスのためのOdoo運用術 にまとめています。

(4) 費用を見込んでおく

独自開発がある場合、バージョンアップのたびに確認と修正の費用が発生します。

これは「予想外の出費」ではなく、最初から見込んでおくべき運用費用です。総費用の考え方は Odoo導入にかかる費用の構造 をご覧ください。

「上げない」という選択について

正直に書きます。バージョンアップを見送り続ける会社は実際にあります。

短期的には合理的に見えます。作業も費用も発生しないからです。

しかし、時間が経つほど選択肢が減ります。

  • サポートの対象外になり、修正を受けられなくなる
  • 一気に複数世代を上げることになり、作業が重くなる
  • 新しい機能を使えない
  • 対応する技術者を見つけにくくなる

これは、Odooに限った話ではありません。古いシステムを使い続けた結果として起きる、よくある構図です。

その構図は レガシーシステム刷新Odoo導入の失敗パターンと回避策 でも扱っています。

毎年少しずつ上げるほうが、結果的に軽く済みます。

よくある質問

Q1. バージョンアップは必須ですか?

技術的には、使い続けること自体は可能です。ただし、サポートの対象期間には限りがあります。

対象外になると、不具合やセキュリティの修正を受けられなくなる可能性があります。対象期間は必ずOdoo公式でご確認ください。

Q2. 作業にどのくらいかかりますか?

カスタマイズの量によって、大きく変わります。

標準機能と設定だけで運用している場合は比較的軽く済みます。独自開発が多い場合は、確認と修正に相応の時間がかかります。

Q3. Community版でもアップグレードできますか?

技術的には可能です。ただし、公式のアップグレード支援は受けられません。

自社または委託先で、作業と検証を行うことになります。

Q4. 複数バージョンをまとめて上げられますか?

構成によっては可能ですが、確認すべき範囲が広がります。

離れているほど変更点が多くなり、独自部分への影響も大きくなります。可能なら、毎年上げるほうが安全です。

Q5. 上げたら前のバージョンに戻せますか?

戻す前提で計画してください。 バックアップを取り、戻す判断の基準を事前に決めておくことをおすすめします。

「戻れない」状態で実行するのは避けるべきです。

まとめ

Odooは原則として年1回、メジャーバージョンが上がります。毎年やってくる宿題があるということです。

サポートの対象は新しい数世代に限られます。古いまま使い続けると、いずれ修正を受けられなくなります。対象期間は必ず公式でご確認ください。

そして、この記事でいちばんお伝えしたい点をもう一度書きます。

バージョンアップの重さは、Odooの都合ではなく、自社がどれだけ作り込んだかで決まります。

設定で対応した部分は軽く済みます。ノーコードでの追加は中程度。独自開発は重く、毎年の確認が必要になります。

つまり、導入時のカスタマイズの判断が、その後ずっと自社に返ってきます。

進め方の原則は3つです。影響範囲を洗い出す。検証環境で試す。そして、業務側の確認を飛ばさない。 技術的に動くことと、業務が回ることは別です。

最後に。バージョンアップを見送り続けると、短期的には楽ですが、時間が経つほど選択肢が減ります。毎年少しずつ上げるほうが、結果的に軽く済みます。

もう少し詳しく知りたい方へ

ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。

導入時から「毎年のバージョンアップをどう回すか」を織り込んだ設計をご提案しています。作り込む前に、その判断が将来どれだけの負担になるかを一緒に見積もることを大切にしています。

あわせて読みたい記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

持田 卓臣(もちだ たくおみ)
株式会社ベンチャーネット 代表取締役

ヒューレット・パッカード社でITコンサルタントとして従事した後、2005年に株式会社ベンチャーネットを設立。
Oracle NetSuite Solution Provider Partner として、中堅・中小企業向けクラウドERP「NetSuite」の導入・運用支援を提供しています。
SEO・広告・SNS・ウェブ・MA・SFAと一気通貫で培ってきたデジタルマーケティング領域の業務知見を活かし、NetSuiteを軸とした経営DXを支援しています。
著書:『普通のサラリーマンでもすごいチームと始められる レバレッジ起業「バーチャル社員」があなたを救う』(KADOKAWA、2020年)

目次