「自分が倒れたら、この会社は止まる」
情報システムの担当が1人しかいない会社で、その担当者が抱えている感覚です。
有給休暇を取っても、電話が鳴る。パソコンの調子が悪いと呼ばれる。ネットワークも、会計システムも、勤怠も、全部ひとりで見ている。
そこに「基幹システムを入れよう」という話が降ってくる。
「これ以上、自分が見るものを増やして大丈夫なのか」
この記事は、その問いに答えるために書きました。Odoo（オドゥー：オープンソース由来の統合業務アプリ群）を、一人情シスという制約から逆算して選び、回す方法を整理します。
一人情シスの本当の敵は「仕事量」ではない
忙しいことは問題です。ただし、それは根本の原因ではありません。
一人情シスを苦しめている構造は、次の2つです。
(1) システムの数だけ、覚える対象が増える
会計ソフト、販売管理、勤怠、経費精算、グループウェア。それぞれに、次のものが付いてきます。
- 操作方法
- 権限設定の考え方
- バージョンアップの時期とやり方
- 障害が起きたときの連絡先
- ライセンスの契約更新日
5つのシステムがあれば、5セット覚えることになります。
(2) 連携の隙間は、必ず人が埋める
システムが分かれていると、その間をつなぐ作業が発生します。
CSVを書き出して、加工して、別のシステムに取り込む。この作業は、たいてい情シスに回ってきます。
そして、この作業は 手順が誰の頭の中にあるかで属人化します。 引き継ぎ資料がないまま、担当者だけが知っている状態になります。
統合することの価値は、機能が増えることではありません。
一人情シスにとっては、覚える対象と連携の隙間が減ることのほうが大きい。 ここが、この記事でいちばんお伝えしたい点です。
「もう1つ増える」のではないか、という懸念について
ただし、正直に書きます。
Odooを入れれば、それも1つのシステムです。統合が完了するまでの期間は、既存システムとOdooの両方を見る時期が必ずあります。
つまり、一時的には負担が増えます。
大事なのは、この期間をどう設計するかです。
段階移行の考え方
一人情シスの体制で、全業務を一度に切り替えるのは現実的ではありません。
- まず1つの業務をOdooに乗せる
- 安定するまで既存システムと並走する
- 落ち着いてから、次の業務を乗せる
この進め方だと、どの時点でも「新しく覚えること」がひとつだけになります。
進め方の全体像は Odoo導入の進め方と期間 をご覧ください。
【最重要】運用責任の分界点をどこに置くか
一人情シスにとって、Odooの選び方で最も重要なのはここです。機能ではありません。
サーバが落ちたとき、誰が対応するのか。
Odooには複数の使い方があり、それによって自分が負う範囲が大きく変わります。
Odoo公式によれば、有償プランには ホスティング・無制限のサポート・整備が含まれるとされています。インフラには日単位の増分バックアップ、メール統合、年中無休のモニタリングが含まれると案内されています（Odoo公式サイトより、2026年8月確認）。
一方、Community版はオープンソースとして無料ですが、サーバの用意・アップデート・障害対応はすべて自社の責任になり、公式サポートの対象外です。
一人情シスへの、正直な意見
担当者が1人の会社に、Community版の自社ホスティングは、おすすめしにくい選択です。
理由は明確です。夜中にサーバが落ちたとき、対応できる人が1人しかいないからです。その1人が休んでいたら、誰も対応できません。
技術的にできるかどうかの問題ではありません。組織として、その状態を許容できるかどうかの問題です。
もし社内の方針でオンプレミス運用が必要なら、外部の保守契約とセットで検討してください。1人で背負う構造だけは避けるべきです。
導入形態の違いは Odooの導入形態3つを比較、Community版との比較は Community版とEnterprise版の違い にまとめています。
カスタマイズは「将来の自分」への借金になる
一人情シスに、もうひとつお伝えしたいことがあります。
現場から「この項目を追加してほしい」「この画面をこう変えてほしい」という依頼が来ます。応えたくなります。
ただし、カスタマイズを増やすほど、バージョンアップのときに確認する箇所が増えます。
Odooは原則として年1回メジャーバージョンが上がります。その都度、独自に作り込んだ部分が動くかどうかを確認する必要があります。
そして、その確認をするのは自分です。
だから「標準でできないか」を先に考える
依頼が来たら、順番に考えてください。
- 標準の設定でできないか
- 運用の工夫（入力ルールや命名規則）で吸収できないか
- それでも必要なら、どこまでやるか
この順序を守るだけで、将来の負担は大きく変わります。
考え方は OdooとFit to Standard と Odooのカスタマイズはどこまでやるべきか にまとめています。
属人化を減らすために、いま仕込んでおくこと
一人情シスにとって、いちばん大事なのはここかもしれません。
(1) キーユーザーを業務側に立てる
すべての質問が情シスに来る状態は、健全ではありません。
各部門に「その業務のOdooに詳しい人」を1人ずつ立ててください。操作の質問は、まずその人が受ける。
これは負担を押し付けるのではなく、業務を知っている人が業務のシステムを持つという自然な形です。
定着の進め方は Odooを社内に定着させる方法 にまとめています。
(2) 設定変更の記録を残す
「なぜこの設定にしたのか」を残してください。
自分のためではありません。次の担当者のためです。そして、半年後の自分は、他人です。
形式は問いません。テキストファイルでも十分です。日付と、変えた内容と、理由。この3つがあれば足ります。
(3) 復旧できることを、実際に確かめる
バックアップが取れていることと、そこから戻せることは違います。
有償プランでバックアップが含まれている場合でも、復旧の手順は一度確認しておいてください。障害が起きてから初めて手順を読むのは、いちばん避けたい状況です。
セキュリティとバックアップの考え方は Odooのセキュリティとバックアップの考え方 をご覧ください。
(4) 一人で全部やろうとしない
これがいちばん重要です。
一人情シスの限界は、能力ではなく 時間と、休めないことにあります。
外部の伴走支援を使うことは、負けではありません。自分が休んでも会社が止まらない状態を作ることが、情シスの本来の仕事です。
運用の考え方は Odooの運用・保守で押さえるポイント にまとめています。
Odooが合わないケースもあります
正直にお伝えします。
ベンチャーネットは、SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っています。一人情シスの体制では、次のように整理できます。
| 状況 | 検討したい選択肢 |
|---|---|
| 業務が少数で、いまのシステムで回っている | 無理に統合しない判断もある |
| 複数システムの連携作業に時間を取られている | Odoo で覚える対象を減らす |
| 会社が大きく、内部統制や監査対応が重い | OdooとNetSuiteの違い を参照 |
| 必要な業務がごく限られ、固有性が高い | AIスクラッチ開発で必要な部分だけ作る |
最後の行について、一人情シスの視点で補足します。
スクラッチ開発した独自システムは、保守が属人化しやすいという弱点があります。作った人がいなくなると、誰も触れなくなります。
AIスクラッチ開発を選ぶ場合は、ドキュメント整備と保守体制をセットで設計してください。開発費と保守費が別途かかる点も、あわせてご確認ください。判断材料は パッケージERPかスクラッチ開発か に整理しました。
よくある質問
Q1. 情シスが1人でも、Odooの運用は回りますか？
Odooがホスティングするプランを選び、カスタマイズを最小限に抑えれば、回すことは可能です。
ただし「1人で全部やる」設計にはしないでください。業務側にキーユーザーを立て、外部の支援も併用する前提で組んでください。
Q2. Community版を選んではいけないのですか？
いけないわけではありません。ただし、担当者が1人の体制で自社ホスティングを選ぶと、障害対応が1人に集中します。
社内の方針でオンプレミスが必要な場合は、外部の保守契約とセットで検討してください。
Q3. バージョンアップの作業は自分がやるのですか？
Odooがホスティングするプランでは、アップグレードのサービスが提供されています。ただし、独自に作り込んだ部分の動作確認は自社側の作業になります。
だからこそ、カスタマイズを増やしすぎないことが効いてきます。
Q4. 既存システムを全部やめる必要がありますか？
必要ありません。むしろ、一度に全部やめるほうが危険です。
まず1業務をOdooに乗せ、安定してから次に進んでください。会計だけ既存のまま残す、という構成もよくあります。
Q5. 導入作業も自分がやることになりますか？
要件の整理や現場調整は、情シスが中心にならざるを得ません。ただし、設定・データ移行・トレーニングは外部に任せられます。
一人情シスの場合、通常業務を止めずに導入を進めることが最大の制約です。ここを見誤ると、導入も通常業務も両方が滞ります。
データ移行の進め方は Odooへのデータ移行の進め方 をご覧ください。
まとめ
一人情シスが苦しいのは、仕事が多いからだけではありません。
システムの数だけ覚える対象が増え、その隙間を人が埋めているという構造が原因です。
業務をひとつの基盤に統合すると、覚える対象と連携作業が減ります。機能が増えることより、この効果のほうが一人情シスには大きいはずです。
ただし、選び方を間違えると逆効果になります。とくに重要なのが 運用責任の分界点です。サーバが落ちたとき誰が対応するのか。ここを先に決めてください。
そして、カスタマイズは将来の自分への借金です。標準でできないか、運用で吸収できないかを先に考えてください。
最後にもうひとつ。一人で全部やろうとしないでください。
キーユーザーを業務側に立てる。記録を残す。復旧手順を確かめておく。外部の支援を使う。この4つは、いま仕込んでおけることです。
自分が休んでも会社が止まらない状態を作ること。それが、情シスの本来の仕事だと考えています。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。
「1人体制でどこまでやるべきか、どこから外部に任せるべきか」という切り分けからご相談を承っています。
あわせて読みたい記事
