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