Odooを入れると決めた。キックオフの日程も押さえた。では、明日から何をすればいいのか。
ここが曖昧なまま走り出すと、会議の回数だけが増えていきます。3か月たっても、誰が何を決めたのか分からない。よくある光景です。
けれども、最初の90日でやることは、順番が分かれば迷いにくくなります。90日で完成するのはシステムではなく、「あとから引き返しにくい決定」です。決める人、標準に合わせる範囲、持っていくデータ、切替の日。この4つを、13週を4つの区間に分けて順に確定させます。初回稼働のゴールは「数字が1か所に集まって見える」ことに置き、分析や改善は稼働後に積み上げます。
最初に決める項目には、時間の制約もあります。Odooの会計のローカライゼーションパッケージは、仕訳を1件でも計上した後は選び直せません（「あとで直せばいい」が通用しない項目）。
90日を決める順に使うと、たとえば次のことが変わります。
- 「これは誰が決めるのか」で会議が空転しにくくなる
- 作り込みを、競争力に直結する部分に絞れる
- 過去データを全部持ち込まず、テストの期間を守りやすくなる
- 切替を、当日の空気ではなく文書にした基準で決められる
ただし、製造や複数拠点、多通貨などが絡むと、90日では判断を出し切るところまでになることもあります。負担の側も、この90日プランの良い点と、気をつけることに並べました。
では、そのうち経営者が自分で判断すべきなのは、何週目の何でしょうか。答えは経営者が各週で判断すべきことの表にあります。
前提の確認：この記事は有償のEnterprise版を前提に書いています。無償のCommunity版はオープンソースとして利用できますが、サーバーの用意と保守を自社で行う必要があります。公式サポートの対象にもなりません。Community版を選ぶ場合は、第1〜2週に「環境を誰が構築し、誰が保守するか」を決める工程が加わります。
Odoo導入の最初の90日で何が決まるか
90日は「稼働までの日数」というより、「決定を出し切るための期限」です。
中小企業のOdoo導入では、要件の整理から本番切替までを90日前後で組むケースが多く見られます。ただし、この期間の中身の大半は作業ではありません。判断です。
90日で決まる4つのこと
| 決めること | 中身 |
|---|---|
| 決める人 | 誰が最終判断をするのか |
| 標準に合わせる範囲 | どこまで業務のやり方を変えるのか |
| 持っていくデータ | 何を移行し、何を捨てるのか |
| 切替の日 | いつ旧システムを止めるのか |
この4つは、あとから変えると費用と期間の両方にはね返るため、90日という区切りを置きます。
「あとで直せばいい」が通用しない項目がある
初期設定の段階でしか選び直せない項目も、Odooにはあります。代表は会計のローカライゼーションパッケージです。
これは、国ごとの勘定科目表・税設定などをまとめて導入する仕組みです。日本向けのパッケージも用意されています。
Odooの公式ドキュメントは、仕訳を1件でも計上した後は別のパッケージを選び直せない、と明記しています。テスト環境であっても、会計の初期設定は慎重に扱うべき項目です。
（出典：Odoo 19.0 公式ドキュメント（Fiscal localizations）、2026年10月確認）
つまり会計の初期設定は、第1〜2週で確定させておく項目です。90日の設計は、ここから逆算して組みます。
導入全体の流れをまだ押さえていない方は、Odoo導入の進め方と期間を先に読むと、この90日の位置づけが分かりやすくなります。
第1〜2週：現状把握と、決める人を決める
最初の2週間でやることは、要件の議論ではありません。議論を成り立たせる条件を整えることです。
決める人を決める
Odoo導入で最初に詰まるのは、たいてい「これは誰が決めるのか」という点です。決める役割は3つあります。
| 役割 | 何をするか | 置き方 |
|---|---|---|
| 意思決定者 | 投資と業務変更の最終判断 | 多くの中小企業では経営者本人 |
| 業務代表 | 現場の運用を代表して仕様に合意する | 部門ごとに1名ずつ |
| 窓口担当 | 進行管理と社内調整 | 専任でなくてよいが、必ず1名に固定 |
曖昧にしがちなのが、業務代表の権限です。「持ち帰って部内で相談します」が毎回出ると、意思決定の速度は半分以下になります。
どこまでをその場で決めてよいのか。最初に経営者が言葉にして、本人に伝えておきます。
4つの視点で現状を棚卸しする
現状把握は、次の4つに分けると漏れが減ります。
- 業務：受注から入金まで、実際に誰が何をしているか
- システム：今動いているもの、連携しているもの
- データ：どこに何が入っているか、誰が管理しているか
- 人：誰がどれだけプロジェクトに時間を割けるか
見落とされやすいのが4つ目です。業務の聞き取りを短い時間で進める型は、業務ヒアリングの進め方にまとめています。
稼働時間を先に押さえる
中小企業では、プロジェクトメンバーの大半が兼務です。本業が忙しくなると、レビューも意思決定も止まります。
止まった分は、そのまま切替日に向かってしわ寄せになります。テスト期間が削られ、品質が落ちるという連鎖です。
対策は単純で、「最初に時間を確保してしまうこと」です。
- 各工程で週に何時間必要かを、支援側と一緒に見積もる
- 会議の時間だけでなく、持ち帰りの調査時間も見込む
- 足りない分は外部の手を借りる前提で計画を立てる
仕様の判断と成果物の確認は、自社でしかできません。会議調整や現状ヒアリングの整理は外部に任せられるため、ここに線を引くだけで、社内の負担はかなり変わります。
会計の土台を決める
会社設定、通貨、勘定科目表の方針は、この2週間のうちに決めます。あとで直せない項目で見たとおり、仕訳を計上した後では選び直せないためです。
テスト用のデータベースでも、安易に取引を登録しないよう周知しておきます。
第1〜2週の完了条件
- 意思決定者・業務代表・窓口担当が名前で決まっている
- 週次の定例会が日程として押さえられている
- 各メンバーの投入時間が合意されている
- 会計の初期設定方針が確定している
第3〜6週：業務をどこまで標準に合わせるか
90日のうちで最も重い4週間です。プロジェクトの成否は、実質的にこの期間で決まります。
「現行踏襲」を禁句にする
要件を整理していると、必ずこの言葉が出ます。「基本は現行踏襲で」。
一見、リスクの少ない判断に見えます。しかし実際には、古いやり方をそのまま新しい画面に移すことになります。
出来上がるのは、「見た目だけが新しい、古い仕様のシステム」です。投資して手に入れたかったものは、それだったのか。経営者が問い直す論点です。
現行踏襲が起きる背景には、多くの場合、2つの事情があります。今のシステムがなぜその仕様なのか、説明できる人がもういない。変更の影響範囲が読めないので、触らない判断になる。心情としては自然ですが、投資判断としては割に合いません。
3つの層に分けて判断する
判断を進めやすくするために、業務を3つの層に分けます。
- 標準で回す：Odooの標準機能のまま運用する。業務側がやり方を合わせる
- 設定で寄せる：項目追加や画面調整など、標準機能の範囲で調整する
- 作り込む：開発を伴う個別対応をする
原則は、上から順に検討することです。作り込みは最後の手段です。
作り込んだ部分は、バージョンアップのたびに確認と修正が必要になるため、導入時の費用だけでなく、その後も続く負担として見積もっておきます。
判断の基準を1つ持っておく
3つの層に振り分けるとき、迷ったら次の問いを使います。
「そのやり方は、うちの競争力になっているか」
競争力になっている業務は、作り込む価値があります。昔からそうしているだけの業務は、標準に寄せる候補です。
この線引きは、現場だけでは決められません。経営者が判断する領域です。
要件整理の具体的な進め方は、Odoo導入の要件定義の進め方で詳しく扱っています。
第3〜6週の完了条件
- 主要業務が3つの層に振り分けられている
- 作り込む範囲がリスト化され、その理由が説明できる
- 業務側が「やり方を変える」ことに合意している
第7〜10週：データ移行と、捨てるものの判断
データ移行は、技術作業だと思われがちです。実際には、合意を取るのに時間がかかる工程です。
データを3種類に分ける
移行対象は、性質の違う3つに分かれます。
| 種類 | 例 | 性質 |
|---|---|---|
| マスタ | 取引先、商品、勘定科目 | 新システムでも使い続ける情報 |
| 残高 | 期首残高、在庫数量、売掛買掛の残高 | 切替時点の状態 |
| 履歴 | 過去の受注、請求、仕訳 | 取引の明細 |
扱いを決めるのが難しいのは、履歴です。
「全部持っていく」を疑う
過去データをすべて移行したい、という要望はよく出ます。気持ちは分かりますが、代償があります。移行の設計とテストに時間がかかり、古いデータの不整合も新システムに持ち込む。稼働後の検索性や動作速度に影響することもあります。
現実的な落とし所は、こうなることが多いです。
- マスタと残高は移行する
- 履歴は直近1〜2期分に絞る
- それより古いものは、旧システムまたは出力ファイルで参照できる形にして残す
「捨てる」のではなく「新システムには持ち込まない」という整理です。この合意を取ることが、この4週間の主な仕事になります。
設計書は古い前提で進める
長く使ってきたシステムほど、設計書が最新になっていないものです。緊急対応の際、真っ先に省かれるのがドキュメントの更新だからです。
そのため、移行のテスト段階で想定外のデータが出てきます。
- 定義書にないコード値が入っている
- 新システムでは必須の項目が、旧システムでは空欄だった
- 明細が1件もない伝票が残っている
これらは、設計書ではなく実データを見ることでしか分かりません。
だからこそ、「移行リハーサルは最低2回」行います。1回目で問題を洗い出し、修正した上で2回目を実施します。1回で済ませる計画は、事実上リハーサルなしと同じです。
データ移行の具体的な手順は、Odooへのデータ移行の進め方にまとめています。
第7〜10週の完了条件
- 移行するデータと、移行しないデータが一覧で確定している
- 移行しない判断について、業務側の合意が取れている
- 移行リハーサルを1回以上実施し、課題が洗い出されている
第11〜13週：教育・並行稼働・本番切替
最後の3週間は、システムではなく人に向き合う期間です。
「使い方」ではなく「仕事の順番」を教える
操作研修だけを行うと、稼働直後に「この場合はどうするんですか」という類の質問が集中します。
画面の操作は覚えても、業務の流れが変わったことを理解していないのが原因です。教える中身は次の3つです。
- 新しい仕事の順番（誰が、どの順で、何を入力するか）
- 変わった点と、その理由
- 困ったときの聞き先
3つ目を用意しておくだけで、稼働直後の混乱はかなり減ります。
並行稼働の範囲を決める
旧システムと新システムを同時に動かす期間を置くかどうか。ここは早めに決めます。
並行稼働では同じ入力を2回行うことになるため、全業務で行うと現場が疲れ切り、かえって品質が下がることもあります。
- 期間を区切る（多くの場合は1か月以内）
- 対象を絞る（受注と請求だけ、など）
- 何をもって並行稼働を終えるかを、事前に決めておく
切替判定の基準を先に決める
「切り替えられる状態かどうか」を、当日の空気で決めてはいけません。判定基準は、遅くとも第11週までに文書にしておきます。
- 受け入れテストの必須項目がすべて完了している
- 残っている不具合が、業務を止めないレベルである
- 移行データの検証結果が承認されている
- 切り戻しの手順が決まっている
忘れがちなのが4つ目です。切り戻しの手順があるかどうかで、当日の判断のしやすさが変わります。
稼働後2週間の体制を組む
切替日はゴールではありません。稼働後2週間は、質問と修正が集中します。
この期間だけは、窓口担当と支援側の体制を厚くしておきます。ここが薄いと、現場に残るのは「使えないシステム」という印象です。
定着までの進め方は、Odooを社内に定着させる方法で詳しく扱っています。
90日で決めきれなかったときに起きること
すべてが計画どおりに進むわけではありません。決めきれなかった場合に何が起きるかを知っておくと、早めに兆候に気づけます。
パターン1：決める人が決まらないまま進む
起きること：会議の回数が増えて同じ議題が何度も戻り、決定事項も議事録に残らないまま「そういえばあれはどうなった」が積み上がります。
兆候：定例会で「持ち帰ります」が3回続いたら、権限の設計を見直す時期です。
パターン2：現行踏襲のまま設計が進む
起きること：旧システムの仕様を再現するための開発が増えます。費用が膨らみ、バージョンアップのたびに修正が必要な部分も増えていきます。
兆候：要件の議論で「今はこうなっているので」という説明がくり返されるようになったら、要注意です。
パターン3：データを全部持っていく判断をする
起きること：移行の設計とテストが長引き、そのしわ寄せが受け入れテストの期間に来ます。テストが削られると、稼働後の不具合が増えます。
兆候：移行対象の一覧が「調整中」のまま第9週を迎えたら、範囲を絞る決断が必要です。
パターン4：教育を最後に回す
起きること：切替直後に問い合わせが集中して現場の作業が止まり、「前のほうが良かった」という声が出て、定着が遅れます。
兆候：第10週になっても研修の日程が決まっていない場合は、優先順位を上げます。
遅れそうなときに、まず動かすもの
期間が足りないとき、削ってはいけないのはテストと教育です。先に見直すのは、「初回稼働の対象範囲」です。
会計だけ先に切り替える、一部の拠点から始める。こうした段階稼働は、現実的な選択肢になります。全部を同時に切り替える必要は、必ずしもありません。
導入時に起きやすいつまずきは、Odoo導入の失敗パターンと回避策でも整理しています。
経営者が各週で判断すべきこと
経営者が関与すべき判断を、週ごとに並べました。すべての会議に出る必要はありません。この8つだけ押さえます。
| 週 | 経営者が判断すること | 判断しないと起きること |
|---|---|---|
| 第1〜2週 | 意思決定者と業務代表を指名し、その場で決めてよい範囲を伝える | 決定が現場に降りず、会議が空転する |
| 第1〜2週 | 各メンバーの週あたりの投入時間を承認する | 兼務メンバーの本業が優先され、進行が止まる |
| 第3〜4週 | どの業務を標準に合わせるかの方針を示す | 現行踏襲に流れ、開発費が膨らむ |
| 第5〜6週 | 作り込む範囲を承認する。競争力に直結するかで線を引く | 個別対応が増え、将来の更新負担が残る |
| 第7〜8週 | 過去データをどこまで持ち込むかを決断する | 移行が長引き、テスト期間が削られる |
| 第9〜10週 | 追加要望を今回受けるか、稼働後に回すかの基準を示す | 要望が際限なく増え、切替日が動く |
| 第11週 | 切替判定の基準と、切り戻しの条件を承認する | 当日の判断が感覚頼りになる |
| 第12〜13週 | 稼働後2週間の体制を承認する | 稼働直後の混乱が長引き、定着が遅れる |
並べてみると、経営者の判断が必要な場面に技術的な内容はありません。問われているのは、「どこまで会社のやり方を変えるか」です。
基幹システムの導入が、ITプロジェクトではなく経営プロジェクトだと言われるのは、この構造があるためです。
この表は、キックオフの席でそのまま配って構いません。自分の判断が何週目に必要かを、経営者と現場が同じ紙で見られます。
この90日プランの良い点と、気をつけること
決める順に90日を使う進め方には、得られることと、先に引き受けておきたい負担があります。
良い点は、次の5つです。
- 会議が空転しにくい：決める人と、その場で決めてよい範囲を第1〜2週に決めておく
- 費用と期間がぶれにくい：あとから変えるとはね返る4つの決定を、90日で出し切る
- 将来の更新負担を抑えやすい：作り込みは、競争力に直結する部分に絞る
- テストの期間を守りやすい：過去データの持ち込みを絞り、移行の長引きを防ぐ
- 切替を基準で判断できる：判定基準と切り戻しの手順を、第11週までに文書にする
気をつけることは、次の4つです。
- 経営者の判断が8つの場面で要る：標準に合わせる範囲などは、現場だけでは決められない
- 兼務メンバーの時間を先に確保する：本業が忙しくなると、レビューも意思決定も止まる
- やり方を変える合意が要る：業務側が「やり方を変える」ことへの合意が、第3〜6週の完了条件になる
- 90日に収まらないこともある：製造や複数拠点、多通貨が絡むと、判断を出し切るところまでになることもある
遅れそうなときに先に見直すものは、90日で決めきれなかったときに起きることにまとめました。
ベンチャーネットが90日計画を引く前に確かめること
ベンチャーネットは、週ごとの計画表を作る前に、次の順番で確かめます。90日の中身は、この確認で大きく変わるからです。
- 3〜5年後の姿：拠点や人数、扱う業務がどう増えるかを聞きます。今回の90日で入れる範囲は、そこから逆算して決めます
- 決める人と時間：意思決定者が誰で、業務代表がどこまでその場で決められるか。週に何時間を割けるかも、この段階で数字にしてもらいます
- 標準に乗る割合：主要業務を「標準で回す・設定で寄せる・作り込む」に仮で振り分けます。Fit to Standard（標準機能に業務を合わせる考え方）が前提です
- 初回稼働のゴール：最初は「数字が1か所に集まって見える」ことを目標にします。見える化→わかる化→儲かる化の順で、分析や改善は稼働後に積み上げます
- 合うかどうかの見極め：3つ目の振り分けの結果、作り込みが大きく膨らむなら、その時点で率直にお伝えします
4つ目の「見える化→わかる化→儲かる化」の流れは、データを1か所に集めると、経営はどう変わるかで詳しく扱っています。
5つ目の見極めで、別の選択肢が視野に入ることもあります。ベンチャーネットはNetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、製品ありきで話を進める必要がありません。なお、AIスクラッチ開発は開発費と保守費が別途かかる前提で比べます。
標準に合わせる考え方は、OdooとFit to Standard｜標準機能に業務を合わせる考え方で詳しく扱いました。
よくある質問
Q1. 90日で本当に稼働できますか？
会計と販売購買を中心に、標準機能を軸に組むなら、90日前後で切り替えている例はあります。
一方、製造や複数拠点、多通貨などが絡むと、90日では判断を出し切る段階までになることもあります。
期間そのものより、「何を90日以内に決めるか」を先に決めておくことが大切です。決定の期限がない計画は、業務範囲にかかわらず遅れます。
Q2. 専任の担当者を置けません。それでも進められますか？
進められます。多くの中小企業が同じ条件です。専任を置けるかどうかより、「時間を先に確保できているか」のほうが結果を左右します。
現実的な進め方は、次のとおりです。
- 意思決定と仕様の判断は、社内で行う（ここは外部に任せられません）
- 進行管理、議事録、現状ヒアリングの整理は、外部の支援を使う
- 業務代表には、週あたりの必要時間をあらかじめ伝えておく
「人がいないから進まない」の多くは、必要な時間が見積もられていないことが原因です。
Q3. 途中でOdooが合わないと分かったら、どうすればよいですか？
選択肢を並べ直します。第3〜6週の段階で、標準に寄せる検討をした結果、作り込みの範囲が想定を大きく超えると分かることがあります。
- 業務の規模や複雑さが想定より大きいなら、上位のERPを検討する余地があります。OdooとNetSuiteの違いで規模の考え方を整理しています
- パッケージの型に業務が乗らないなら、必要な機能だけを開発する選択肢もあります。ライセンス費はかからない一方、開発費と保守費は別途かかります。パッケージERPかスクラッチ開発かで判断の軸を扱っています
途中で方針を変えるのは失敗ではありません。稼働してから合わないと気づくほうが、はるかに損失は大きくなります。
Q4. Odoo導入のスケジュールは、どう組めばよいですか？
13週を4つの区間に分けて組みます。第1〜2週で決める人と会計の初期設定、第3〜6週で標準に合わせる範囲、第7〜10週で持ち込むデータを決めます。第11〜13週は、教育と本番切替の期間です。経営者が判断する場面は、経営者が各週で判断すべきことの表で週ごとに並べました。
まとめ：90日は「作る期間」ではなく「決める期間」
最初の90日でやることは、区間ごとに次のとおりです。
- 第1〜2週：決める人を決め、時間を確保し、会計の初期設定を固める
- 第3〜6週：標準で回す・設定で寄せる・作り込むの3層に振り分ける
- 第7〜10週：持ち込むデータと持ち込まないデータを合意する
- 第11〜13週：仕事の順番を教え、切替判定の基準に沿って切り替える
この90日で経営者が問われるのは、技術ではありません。どこまで自社のやり方を変えるか、という判断です。その判断を先送りしたプロジェクトほど、後半で苦しくなります。
Odooそのものをまだ把握していない場合は、Odooとは？中小企業の経営者が知っておきたいオープンソースERP入門から読み始めることをおすすめします。
1年後、次のアプリや拠点を追加する会議では、誰かが「まず決める人と切替判定の基準を決めよう」と口にしているはずです。最初の90日で作った決め方が、会社の段取りとして残っている状態です。
もう少し詳しく知りたい方へ
ERP導入支援を手がけるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。特定の製品に寄せた提案ではなく、規模と要件から適した選択肢をご提案できる立場です。
90日の計画づくりや、兼務メンバーでの体制の組み方について、自社の状況をそのままお聞かせください。
