先月辞めた営業担当のIDで、いまもログインできるかもしれない。取引先から届いたセキュリティ調査票の「バックアップからの復旧手順」の欄が、埋められない。
安全化とは、情報を守る仕組みを、担当者の注意力ではなく設計として作ることです。中身は、アクセス権限・バックアップ・BCP（事業継続計画）の3つ。中小企業の経営を「つなぐ」10の視点のひとつです。
「うちは狙われるような会社じゃない」と感じている経営者は多いはずです。しかし情報漏洩やシステム障害は、規模の大小を問わず起こります。
Odoo（オドゥー）では、アクセス権限を役割・データの種類・レコードの3段階で設計できます。この認証・権限の基本的な仕組みは、Community版とEnterprise版で共通です（安全化の対応範囲）。
安全化を仕組みにすると、たとえば次のことが変わります。
- 営業担当が退職した翌朝には、そのアカウントが止まっている
- 見てよい範囲を、「営業」「経理」といった役割の単位で決められる
- 取引先の調査票に、前回の復旧試験の記録を添えて答えられる
- 担当者が異動・退職しても、同じ水準で情報を守れる
ただし、版によって変わるのは、バックアップや障害対応を誰が担うかです。Community版では、ホスティングも保守も自社の責任になります。
では、設定を始める前に何を決めておけばよいのか。答えは守る対象とそれを担う人で、安全化を「設計」に移す進め方で順に説明しています。
CommunityとEnterpriseの区別について
アクセス権限などの認証・権限管理の基本的な仕組みは、Community版（無料）とEnterprise版（有償）で共通です。違うのは、バックアップや障害対応を誰が担うかという点です。
「安全化」とは何か
安全化とは、情報を守る仕組みを、担当者の注意力ではなく設計として作ることです。
「気をつけて運用する」は仕組みではありません。人は必ずミスをし、担当者は必ず異動・退職します。仕組みとして残していないものは、いずれ崩れます。
だから安全化は、人は必ずミスをするという前提（性弱説）に立って設計するものです。権限管理も復旧手順も担当者の頭の中にあれば、異動や退職のたびに穴が生まれる。ルールとして残っていれば、誰が担当しても同じ水準を保てます。
安全化ができていない中小企業に起きるリスク
リスク1：退職者のアカウントが残り続ける
異動・退職のたびにアカウントを止める運用が決まっていないと、使われなくなったアカウントが放置されます。
リスク2：バックアップは「取っているつもり」で終わる
バックアップを取得していても、復旧を試したことがなければ、本番で通用するかは分かりません。
リスク3：障害時に、誰が何をするか決まっていない
システムが止まったとき、誰が判断し、どの順番で戻すか。これが決まっていないと、対応が後手に回ります。
この状態が、事業継続計画の欠如です。事業継続計画（BCP）とは、災害や事故が起きても事業を止めない、または早く戻すための計画を指します。システムだけでなく、人が急に抜けたときの備えはあの人が明日、来なくなったらで扱っています。
そのまま1年続けると、どこで詰まるか
安全化は、何も起きていない限り成果が見えません。だからこそ、後回しにされ続けます。
最初に表に出るのは、誰が何を見られるかを把握できていない状態です。退職者のアカウントが残っている。取引条件を全員が見られる。指摘されるまで気づかないのが普通です。
次に来るのが、外部からの確認です。取引先のセキュリティ調査票や、金融機関からの確認に答えられない。答えられないこと自体が、取引の条件に影響します。
いちばん重いのは、実際に何かが起きたときです。データが消えた、外に出た。そのとき問われるのは被害の大きさだけでなく、「事前に何を決めていたか」です。決めていなければ、説明できることが何も残りません。
Odooのアクセス権限・バックアップ・BCPで安全化を進める考え方
考え方1：権限は「必要な人に、必要な範囲だけ」
Odoo（オドゥー：販売・在庫・会計などをひとつにつなぐERP）のアクセス権限は、段階を分けて設計できます。役割ごとの大枠、データ種類ごとの操作可否、個々のレコード単位の絞り込みの3段階です。
最初に広く与えて後から絞るのは難しいため、必要な範囲から始めます。詳しい設計の考え方はOdooのセキュリティとバックアップの考え方で解説しています。基幹システムに必要な機能と対策は、基幹システムのセキュリティとはで経営の視点から整理しています。
考え方2：バックアップは「戻せるか」で確認する
最初に決めるのは、取得の頻度・保管期間・復旧の手順です。そのうえで、実際に復旧を試したことがあるかを定期的に確認します。
考え方3：BCPは「誰が、いつ、何をするか」まで決める
障害時の連絡順序、判断できる人、復旧の優先順位。ここまで具体化して、初めて計画として機能します。
自社はどこまでできているか：会議で使えるチェックリスト
次の項目を、経営会議や管理部門との打ち合わせで1つずつ確かめてください。「はい」と即答できない項目が、着手すべき場所です。
権限
- □ いまシステムにアカウントを持っている人を、全員書き出せる
- □ 退職者や、一時的に作ったアカウントが残っていない
- □ 退職・異動の連絡から、誰がいつアカウントを止めるかが決まっている
- □ 管理者権限を持つ人を、名前で挙げられる
- □ 給与・原価・取引条件のうち、全員に見せるべきでない情報が、誰に見えているかを確認した
バックアップ
- □ バックアップの頻度と保管期間を、担当者に聞かずに答えられる
- □ バックアップから一度でも戻す手順を試したことがある
障害時の備え
- □ システムが止まったとき、最初に連絡する相手が決まっている
- □ 復旧を待つ間、手作業でも続けるべき業務（出荷・請求など）が決まっている
最初の5項目は、今週中に確かめられます。バックアップについては、取れていることと戻せることが別だという点を特に意識してください。
この視点をOdooで実装する記事
安全化は、権限の設計と、記録の残し方の両方で進めます。
| 記事 | 何が分かるか | どんな会社向けか |
|---|---|---|
| Odooのセキュリティとバックアップの考え方 | 守る対象の整理と、備えの基本 | 何から手を付けるか決まっていない会社 |
| 見せたい情報を見せたいメンバーだけに | 権限設計の考え方と実際の切り方 | 全員が同じ情報を見ている会社 |
| 税務調査で慌てない | 後から証明できる形で残す方法 | 証憑が紙とデータに分散している会社 |
| そのシステム、3年後に誰が守っていますか | 保守の担い手と責任範囲の決め方 | 運用を誰が持つかあいまいな会社 |
安全化の対応範囲（C/E別）
| 項目 | Community版 | Enterprise版 |
|---|---|---|
| アクセス権限・二要素認証 | 基本的な仕組みは共通 | 基本的な仕組みは共通 |
| ホスティング・バックアップ | 自社で取得・保管・復旧 | 利用形態により提供される |
| 障害対応の窓口 | 社内または委託先 | 公式サポートを利用可能 |
認証・権限の仕組み自体は、Community版とEnterprise版で共通です。差が出るのは、「バックアップや障害対応を誰が担うか」という運用面です。
Odooで安全化を進める良い点と、気をつけること
Odooで安全化を進めるときの良い点と注意点は、次のとおりです。使える版は、項目ごとに添えています。
良い点
- 権限を段階に分けて絞れる：役割ごとの大枠、データ種類ごとの操作可否、レコード単位の絞り込みの3段階で設計できる
- 認証・権限の仕組みは両版で共通：アクセス権限と二要素認証の基本的な仕組みは、Community版でもEnterprise版でも同じ
- 担う範囲を導入形態で選べる：Odooオンライン／Odoo.sh／オンプレミスによって、自社が担う範囲が変わる。Enterprise版は公式サポートを利用できる
- 誰が担当しても同じ水準を保てる：権限の型や復旧の手順をルールとして残せば、異動や退職で穴が生まれにくい
気をつけること
- Community版は運用が自社の責任：ホスティングも保守も自社で担い、バックアップの取得・保管・復旧も自社で行う
- 後から絞るのは難しい：全員に開放したまま始めると、絞る際に反発が起きる。必要な範囲から始める
- バックアップは戻せるかで確かめる：取得の設定だけで終わらせず、年に一度は復旧を試す
- 担い手がいない自社運用は負担が重い：社内に運用を担える人がいないまま自社サーバーで動かすなら、その負担を先に見極める
両方を並べると、次の図のとおりです。
注意点への手の打ち方は、安全化を「設計」に移す進め方とよくある2つの失敗で説明しています。
安全化を「人の注意」から「設計」に移す進め方
ERP導入支援を手がけるベンチャーネットは、安全化に取り組むとき、次の順番で確かめます。設定作業から入らず、守る対象と担い手を先に決める進め方です。
ステップ1：守る情報と、いま見えている人を並べる
給与・原価・取引条件・顧客情報などを挙げ、それぞれ誰に見えているかを一覧にします。ここで「見えてはいけない人に見えている」箇所が、最初の手当ての対象です。
ステップ2：役割ごとの権限の型を決める
見てよい範囲は、個人ごとより「営業」「経理」「管理職」といった役割単位で決めます。入社・異動・退職の手続きと、権限の変更は同じ流れに載せる。ここが外せないところです。
ステップ3：バックアップと障害対応の担い手を決める
導入形態（Odooオンライン／Odoo.sh／オンプレミス）によって、自社が担う範囲は変わります。Community版は、ホスティングも保守も自社の責任です。
社内に運用を担える人がいないのに自社サーバーで動かす計画なら、その負担をはっきりお伝えします。形態の違いはOdooの導入形態3つを比較にまとめました。
ステップ4：復旧を試す日と、連絡の順番を決める
年に一度の復旧試験の時期と、障害時に誰がどの順で動くかを決めます。試した結果を記録に残すと、取引先からの確認にもそのまま使えます。
製品や導入形態を決めるのは、この4ステップで自社が担える範囲を見極めてからです。
安全化でよくある2つの失敗
失敗1：権限設計を後回しにする
「まずは動かしてから」と権限を全員に開放したまま始めると、後から絞る際に反発が起きます。最初から必要な範囲で設計することが重要です。
失敗2：バックアップを取るだけで満足する
取得の設定をして終わりにすると、障害時に復旧できるかは確かめないままになります。年に一度は復旧を試す運用にしてください。
よくある質問
情報システム担当者がいない会社でも、安全化は必要ですか？
必要です。専任担当者がいないほど、手順を仕組みとして残しておく価値が高まります。
Community版はセキュリティが弱いのですか？
仕組みそのものに、版による差はありません。認証や権限管理の基本的な仕組みは、Enterprise版と共通です。違うのは、運用や障害対応を自社で担うか、外部の支援を受けられるかという点です。
BCPは大企業だけが用意するものですか？
いいえ。中小企業こそ代替の人員や資金の余裕が少ないため、事前の計画があるかどうかで復旧の早さが変わります。
安全化はどこから始めればよいですか？
管理者権限を持つ人を絞ることと、退職者のアカウント処理を決めることからです。この2つから着手すると効果が大きくなります。
Odooで安全化を進めるメリットと注意点は何ですか？
誰が担当しても同じ水準で情報を守れることです。
アクセス権限は、役割ごとの大枠・データ種類ごとの操作可否・レコード単位の3段階で設計できます。認証・権限の基本的な仕組みは、両版で共通です。一方で、Community版はホスティングも保守も自社の責任です。バックアップは取るだけで終わらせず、年に一度は復旧を試してください（良い点と気をつけること）。
まとめ：安全化は注意力ではなく設計で作る
安全化は、情報を守る仕組みを担当者の注意力ではなく設計として作ることです。
- 安全化ができていないと、退職者のアカウント放置などの穴が生まれる
- バックアップは「取っているか」ではなく「戻せるか」で確認する
- BCPは「誰が、いつ、何をするか」まで具体化して初めて機能する
- 認証・権限の基本的な仕組みはCommunity版とEnterprise版で共通
- 差が出るのは、バックアップや障害対応を誰が担うかという運用面
1年後、営業担当が退職した翌朝には、そのアカウントはもう止まっています。取引先の調査票が届いても、前回の復旧試験の記録を添えて、その日のうちに返送できるはずです。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
「自社の安全化を、どこから始めるべきか」という整理から、ご相談を承っています。
関連記事
