導入プロジェクトは、稼働日で一区切りつきます。しかしシステムの寿命は、そこから始まります。
ERP（Enterprise Resource Planning：基幹業務を統合管理するシステム）は、数年単位で使い続ける前提の仕組みです。その間に、バージョンは上がり、人は入れ替わり、業務も変わります。
運用・保守を軽く見積もると、数年後に困ります。バージョンが古くなり、担当者が誰もいなくなり、改修もできない状態になるからです。
この記事では、Odooの稼働後に必要な体制を4つの領域で整理します。
領域1：バージョン管理
もっとも計画的に扱うべき領域です。
Odooは原則として年1回メジャーバージョンアップがあります。Odoo公式ドキュメントによれば、サポートとバグ修正の対象は直近3つのメジャーバージョンです。各メジャーバージョンのサポート期間は3年とされています。（出典：Odoo公式ドキュメント、2026年8月確認）
つまり「上げない」という選択は、数年で行き止まりになります。
上げるときに確認すること
Odoo公式ドキュメントによれば、アップグレードでカバーされない範囲があります。たとえば、古いバージョンへの切り戻しや、エディションの変更は対象外とされています。Community版からEnterprise版への変更も、これに含まれます。（出典：Odoo公式ドキュメント、2026年8月確認）
実務では、次を順に確認します。
- 検証環境で先に試す：本番にいきなり適用しない
- カスタマイズ部分の動作を確認する：作り込んだ部分ほど影響が出やすい
- サードパーティ製モジュールの対応状況を確認する：新バージョン未対応のものがある
- 業務のピークを避ける：月次・年次の締め直前は避ける
カスタマイズの手段によって、この負担は大きく変わります。詳しくはOdooのカスタマイズはどこまでやるべきかで整理しています。
ホスティング形態で扱いが変わる
Odooの導入形態は、Odooオンライン、Odoo.sh、オンプレミスの3つがあります。
Odoo公式ドキュメントによれば、Odooオンラインでは中間バージョン（SaaS版）が提供されます。この中間バージョンは、Odoo.shやオンプレミスにはリリースされません。（2026年8月確認）
そのため、更新の頻度や関わり方が形態によって変わります。形態ごとの違いはOdooの導入形態3つを比較で解説しています。
領域2：バックアップと復旧
バックアップは「取っているか」よりも、「戻せるか」が重要です。
確認すべきは次の点です。
| 確認項目 | 具体的に決めること |
|---|---|
| どこまで戻せるか | 何日前まで、どの時点に戻せるか |
| 誰が復旧するか | 社内の担当者か、ホスティング提供元か |
| どのくらいで戻るか | 復旧までに何時間かかる想定か |
| その間どうするか | 業務を止めるのか、手作業で回すのか |
| 実際に試したか | 手順書だけでなく、一度は復旧を試したか |
最後の項目が抜けている会社が多くあります。手順書はあっても、実行したことがなければ、本番で通用するかはわかりません。
年に一度は、検証環境で復旧を試してください。
ホスティング形態による責任範囲の違い
- クラウド提供を利用する場合：基盤側のバックアップは提供元が担う。ただし操作ミスによるデータ削除は別の話
- 自社サーバーで運用する場合（Community版を含む）：取得から保管、復旧まですべて自社の責任
Community版は無料のオープンソース版ですが、ここが最大の実務負担になります。公式サポートの対象外のため、障害時の問い合わせ先も社内になります。
領域3：権限とセキュリティ
稼働直後は、権限設計に手が回っていることが多いです。問題は、その後です。
人事異動、入社、退職のたびに権限は変わります。しかし運用ルールがないと、次の状態になります。
- 退職者のアカウントが有効なまま残っている
- 異動した人が、前の部署のデータを見られる
- 承認権限が、実態と合っていない
これは監査でも指摘される論点です。半年に一度は棚卸しの機会を設けてください。
決めておくべきルールは次の3点です。
- 入社時：誰が申請し、誰が承認して、どの権限を付与するか
- 異動時：前の権限をいつ外すか
- 退職時：いつ、誰がアカウントを停止するか
セキュリティ全般の考え方はOdooのセキュリティとバックアップの考え方で扱っています。
領域4：改善と定着
稼働後は、必ず改善要望が出ます。これを放置すると、システムの外にExcelが増えます。
重要なのは、要望を受け付ける場所と、判断する場を用意することです。
推奨するのは、月次の運用会議です。次の内容を扱います。
- 今月出た困りごとと、その原因の分類
- すぐ直せるもの（設定変更など）の実施状況
- 検討が必要なもの（開発を伴うもの）の優先順位
- 第2段階として広げる範囲の議論
要望を分類するときは、次の3つに分けると判断が速くなります。
| 分類 | 対応 |
|---|---|
| 操作がわからない | 教育・手順書の問題。マニュアル改訂で対応 |
| 手順が非効率 | 設定で改善できないか検討 |
| 業務が回らない | 設計の問題。優先度を上げて対処 |
現場の定着そのものについてはOdooを社内に定着させる方法で詳しく扱っています。
誰が運用を担当するか
中小企業では、専任の情報システム担当を置けないことが多くあります。それでも、次の役割は決めておいてください。
| 役割 | 担うこと | 置き方の例 |
|---|---|---|
| 運用管理者 | 権限管理、マスタ管理、要望の集約 | 管理部門の兼任でも可 |
| キーユーザー | 部門内の一次対応 | 各部門1〜2名 |
| 技術対応 | バージョンアップ、障害対応、改修 | 外部の支援を使うことが多い |
| 意思決定者 | 追加投資と優先順位の判断 | 経営層 |
とくに危険なのは、運用管理者が1人だけの状態です。その人が辞めた瞬間、誰もマスタを触れなくなります。
最低2人が同じ操作をできる状態にしておいてください。
引き継ぎのために残すもの
担当者が代わっても回るように、次を残します。
- 設定の記録：なぜその設定にしたか（何を設定したか、だけでは足りません）
- カスタマイズの一覧：どのモジュールを、なぜ入れたか
- 運用ルール：権限付与、マスタ登録、月次処理の手順
- 問い合わせ先：どの事象を、どこに連絡するか
「なぜ」が残っていないと、次の担当者は怖くて何も変えられません。結果として、システムが硬直します。
よくある質問
運用・保守はどのくらいの工数がかかりますか？
規模と、カスタマイズの量で変わります。目安を出すことは難しいですが、傾向は明確です。
作り込んだ部分が多いほど、運用の負担は増えます。独自開発した部分は、バージョンアップのたびに検証が必要になるためです。
導入時の判断が、そのまま運用コストになります。
バージョンアップはやらないとどうなりますか？
しばらくは動きます。しかしサポート対象から外れると、不具合修正やセキュリティ更新の対象外になります。
さらに古くなると、次のアップグレードが一気に重くなります。飛び越える世代が増えるほど、検証範囲も広がるためです。
計画的に上げるほうが、結果的に負担は小さくなります。
Community版でも運用は同じですか？
考え方は同じですが、担う範囲が違います。
Community版は無料ですが、ホスティング、バックアップ、アップグレードの実施、障害対応をすべて自社で担います。公式サポートの対象外です。
対応できる技術者が社内にいるか、外部に委託できるかを、導入前に確認してください。
運用を外部に委託すべきですか？
すべてを外部に出す必要はありません。権限管理やマスタ管理は社内でできます。
判断が分かれるのは、バージョンアップと障害対応です。ここは頻度が低く、必要な知識が専門的なため、外部の支援を使う会社が多い領域です。
稼働してから運用体制を考えても間に合いますか？
間に合わないことが多いです。稼働直後は通常業務との並行で、体制を設計する余力がありません。
遅くとも稼働の準備段階で、役割分担だけは決めておいてください。
まとめ
Odooの運用・保守は、4つの領域で整理できます。
- バージョン管理：サポート対象は直近3メジャーバージョン。計画的に上げる
- バックアップと復旧：取っているかではなく、戻せるかを確認する
- 権限とセキュリティ：入退社・異動のたびに見直し、半年ごとに棚卸しする
- 改善と定着：月次の運用会議で要望を分類し、優先順位をつける
そして体制面では、次の2点が要になります。
- 運用管理者を1人にしない
- 設定の「なぜ」を記録として残す
ERPは入れて終わりではなく、育てていくものです。動かしながら磨いていく前提で、体制を先に決めておいてください。
もう少し詳しく知りたい方へ
運用・保守の負担は、導入時の設計でほぼ決まります。作り込みが多いほど、あとで効いてきます。
ベンチャーネットは、ERP導入支援を手がける立場から、導入設計の段階で運用まで見据えた提案を行っています。稼働後の体制づくりや、バージョンアップの計画づくりもご相談いただけます。
規模や要件によっては、Odooではなく上位のNetSuiteやSAP、あるいはAIスクラッチ開発が適することもあります。選択肢を並べたうえでご提案します。
関連記事
