Odoo（オドゥー：オープンソース由来の統合業務アプリ群）の見積もりを数社から取ったら、中身がばらばらで比べられない。
現場に必要な機能を聞いたら、今のExcelをそのまま再現してほしいという声ばかり集まった。
こうした行き詰まりの多くは、要件定義という工程の捉え方から生まれます。要件定義は「必要な機能を書き出す作業」ではなく、業務の決め方そのものを決める工程です。
決めるのは、範囲・深さ・順番の3つ。ここでの判断が、導入費用にも稼働後の使いやすさにも直結します。終わったときに業務フロー図・スコープ表・差分一覧・移行対象データの一覧がそろえば、見積もりの精度は大きく上がります（要件定義のアウトプット）。
5つの手順で要件定義を進めると、たとえば次のことが変わります。
- Excelの再現ではなく、手順ごとの「なぜ」から標準の型に寄せられる
- 3〜5年後の姿から逆算し、数年で窮屈にならない範囲を決められる
- 第1段階に入れる業務と、後回しにする業務を線引きできる
- 稼働後に追加の要望が出ても、スコープ表と差分一覧から話を始められる
Odooには無料のCommunity版と有償のEnterprise版があり、「標準でできること」の範囲は版によって変わります。また、差分の多くが開発になるなら、Odooが合っていない可能性もあります。
では、標準機能で埋まらない差分は、どう扱えばよいのか。判断の順番は差分を埋める4つの選択肢にあります。
Odooの要件定義とは、何を決める工程か
要件定義（システムに求める条件を整理し、文書として確定させる工程）は、ひとことで言えば「何を作らないかを決める工程」です。
ERPの導入では、やりたいことを全部並べると、予算と期間はほぼ確実に収まらなくなります。だから要件定義では、次の3つを決めます。
| 決めること | 中身 |
|---|---|
| 範囲 | どの業務をOdooに載せ、どの業務を今回は載せないか |
| 深さ | どこまで細かく管理し、どこは割り切るか |
| 順番 | 何を第1段階で稼働させ、何を第2段階に回すか |
この3つが決まっていない状態で見積もりを取っても、金額はほとんど参考になりません。前提となる範囲が、会社ごとに違って読まれるからです。
なぜ「機能一覧の作成」では足りないのか
要件定義でつまずく会社には、共通するパターンがあります。現場に「必要な機能を挙げてください」と聞いてしまうことです。
現場は、今の仕事のやり方を前提に答えます。すると出てくるのは、「今と同じことができる機能」の一覧です。その結果、こうなります。
- 今のExcelの様式をそのまま再現するカスタマイズが積み上がる
- 現行システムの制約に由来する手順まで移植してしまう
- 費用が膨らみ、稼働後のバージョンアップも重くなる
Odooのようなパッケージを選ぶ意味は、標準化されたやり方を取り込めることにあります。今と同じ形を再現するだけなら、その利点は残りません。
要件定義で問うべきは「今どうしているか」ではありません。「その管理は何のために必要なのか」です。
手順の1つずつに、「なぜそうしているか」を聞き直してください。理由を説明できない手順は、標準の型に寄せられる候補です。
ステップ1：現状の業務とデータを棚卸しする
最初にやるのは、現状の可視化です。細かい手順書は要りません。次の粒度で十分です。
| 整理する項目 | 具体例 |
|---|---|
| 業務の流れ | 引合→見積→受注→出荷→請求→入金 |
| 使っている道具 | 販売管理システム、Excel、会計ソフト、紙 |
| 誰が担当しているか | 部署名と人数（属人化している業務に印をつける） |
| データの持ち方 | 顧客マスタ、商品マスタが何か所に分かれているか |
| 月次の締めの流れ | 何日かかっているか、どこで止まるか |
このとき、同じ情報を何か所に入力しているかを数えておくと効果的です。二重入力の箇所が、そのまま統合の効果が出る場所になります。
現行システムへの不満も書き出します。ただし、不満と要件は別物です。この段階では、「事実の記録」にとどめます。
業務の流れの描き方は、ERP導入前にやるべき業務フロー可視化が参考です。
ステップ2：3〜5年後の姿から必要な範囲を決める
要件定義でもっとも軽視されがちなのが、この工程です。
多くの会社は、「今困っていること」を起点に範囲を決めます。しかし基幹システムは、入れ替えに時間も費用もかかるものです。今に合わせて設計すると、数年で窮屈になります。
考えるべきは、次の3点です。
- 3〜5年後、社員数と拠点数はどうなっているか
- 海外取引や新しい販売チャネルの予定はあるか
- 会社の出口として、事業承継やM&A（合併・買収）を視野に入れているか
急成長が見えているなら、途中での乗り換えは二度手間になります。データ移行・業務停止・再教育が、もう一度発生するためです。
その場合は、最初から上の段の選択肢を検討したほうが、総コストが小さくなることもあります。規模と要件によっては、NetSuiteのような上位の製品が適します。
両者の振り分けは、NetSuiteの教科書のOdooとNetSuiteの比較でも扱っています。見極めの軸は、Odooが向いている企業・向いていない企業で整理しています。
ERPは、ITの話である前に経営の話です。3〜5年後から逆算する視点を、要件定義の最初に入れてください。
ステップ3：Odooの標準機能と照らし合わせる
現状と将来像が整理できたら、Odooの標準機能と照らし合わせます。
机上の資料だけで判断しないことが大切です。Odooには無料で試せる環境があるため、実際に触って確認するほうが早く正確です。
照らし合わせるときは、次の3つに分けます。
- 標準機能でそのままできること
- 設定（項目の追加、ワークフローの調整）でできること
- 標準では実現できないこと
このとき、Community版とEnterprise版のどちらの話をしているかを、必ず区別してください。
Community版は、無料のオープンソース版です。ただし、ホスティングと保守は自社の責任になり、公式サポートの対象外で、一部の機能も含まれません。
Enterprise版は有償のサブスクリプションで、公式サポートと全アプリが含まれます。「標準でできること」の範囲自体が、エディションによって変わります。
エディション別の違いは、Odoo Community版とEnterprise版の違いで詳しく整理しています。
ステップ4：標準機能との差分をどう埋めるか判断する
要件定義の最大の難所が、ここです。標準機能で埋まらない差分を、どう扱うかを1件ずつ決めます。
選択肢は、大きく4段階あります。費用と保守の負担が小さい順に並べたのが、下の図です。
判断の順番は、図の上から下です。いきなり「開発します」と決めないでください。
業務を標準に合わせる
費用も保守の負担も最も小さく、長持ちする選択肢です。その手順が「昔からそうしているだけ」なら、標準に寄せられる可能性があります。
この考え方は、Fit to Standardと呼ばれます。詳しくはOdooとFit to Standardで解説しています。
設定で吸収する
項目の追加、承認ルート、権限設定などは、開発なしで調整できる範囲です。ここで吸収できる差分は、少なくありません。
ノーコードツールで調整する
Odooには、コードを書かずに画面や項目を調整できるStudioという機能があります。
ただし、利用条件に注意が必要です。スタンダードプランのデータベースにStudioをインストールした場合、カスタムプランへのアップセルが自動的に発生します。Odoo公式ドキュメントに、そう記載されています（出典：Odoo 19.0公式ドキュメント、2026年10月確認）。
Studioを使う前提なら、料金プランの選択も一緒に考える必要があります。
開発する
独自モジュールの追加開発です。実現できる幅は広がりますが、バージョンアップのたびに動作検証が必要になります。
そのため、開発は「競争力に直結する業務」に絞るのが原則です。判断の線引きは、Odooのカスタマイズはどこまでやるべきかでも扱っています。
標準と自社流の線の引き方は、どこを標準に合わせ、どこを自社流で残すかにもまとめています。
差分があまりに多い場合は、そもそもパッケージが業務に合っていない可能性があります。その場合は、必要な機能だけを自社資産として作るAIスクラッチ開発という選択肢もあります。ライセンス費はかかりませんが、開発費と保守費は別途かかります。
ステップ5：スコープと優先順位を確定する
最後に、第1段階でやることを線引きします。
すべてを一度に稼働させようとすると、教育も検証も追いつきません。稼働後の混乱は、たいていここに原因があります。
| 区分 | 線引きの基準 |
|---|---|
| 第1段階に入れる | 日々の業務が止まる領域（受注・在庫・請求など） |
| 第2段階に回す | 分析・レポート・周辺業務の自動化 |
| 今回は対象外 | 使う頻度が低く、当面Excelでも困らない業務 |
要件は、すべてそろえてから始める必要はありません。実際に使ってみないと判断がつかない項目もあります。先に決めるものと、後で決めてよいものを分けてください。
| 先に決めるもの | 後で決めてよいもの |
|---|---|
| 最終判断者が誰か | 画面表示の細かい並び順 |
| 移行するデータの範囲 | 帳票デザインの微調整 |
| 第1段階でやめる業務 | 一部の権限設定の粒度 |
「すべてを詰めてから」より「まず回す」ほうが、結果的に早く定着します。動かしながら磨くほうが、現場の納得も得やすくなります。
この要件定義の進め方の良い点と、気をつけること
5つの手順で進めると、得られることがある一方で、先に覚悟しておきたい負担もあります。両方を並べます。
良い点は、次の5つです。
- 見積もりを同じ前提で比べられる：範囲・深さ・順番が決まり、前提となる範囲が会社ごとに違って読まれなくなる
- Odooの標準の型を取り込める：今と同じ形を再現せず、理由を説明できない手順を標準に寄せる
- 数年で窮屈になりにくい：3〜5年後の社員数・拠点・販売チャネルから逆算して範囲を決める
- 費用と保守の負担を抑えやすい：差分は、費用も保守の負担も最も小さい「業務を標準に合わせる」から検討する
- 合わないことが早く分かる：差分の多くが開発になるなら、Odooが合っていない可能性に早めに気づける
気をつけることは、次の4つです。
- やめる判断が要る：「その管理はやめる」という決定は現場だけではできず、経営層の関与が欠かせない
- 判断できる人を会議に集める：持ち帰りが増えるほど、プロジェクトは止まる
- Studioは料金プランと一緒に考える：スタンダードプランのデータベースにStudioを入れると、カスタムプランへのアップセルが発生する
- データの整理を並行して進める：マスタの重複・表記ゆれ・廃番品の混在は、想像以上に手間がかかる
両方を1枚の図に並べました。
負担の多くは、要件定義を始める前に決めておけば軽くなります。準備ができているかは、社内会議用チェックリストで確かめられます。
Odooの要件定義でよくある4つの失敗
失敗1：現場の要望をすべて拾ってしまう
要望を集めること自体は、正しい行為です。問題は、優先順位をつけないまま要件にしてしまうことです。
要望には、「業務上必要なもの」と「慣れているだけのもの」が混ざっています。ここを仕分ける役が必要です。
失敗2：経営層が要件定義に関与しない
要件定義には、必ず経営判断が含まれます。「その管理はやめる」という決定は、現場だけではできないからです。
たとえば営業は柔軟な値引き承認を求め、経理は承認ルートの統一を求めることがあります。裁く人がいないと、会議は堂々巡りになります。
経営層が入らないと判断が保留になり、結局すべてをカスタマイズで解決する流れです。
失敗3：データの整理を後回しにする
要件が固まっても、移行するデータが汚れていると稼働できません。マスタの重複、表記ゆれ、廃番品の混在は、想像以上に手間がかかります。
データ整理は、要件定義と並行して始めるのが現実的です。詳しくはOdooへのデータ移行の進め方で解説しています。
失敗4：期間だけ先に決めてしまう
「4か月後に稼働」と先に決め、そこから逆算して要件を削るケースがあります。
期限を持つこと自体は有効です。ただし、範囲を決めずに期限だけ決めると、検証と教育の時間が真っ先に削られます。
誰が要件定義に参加すべきか
小さな体制で回すほうが、うまくいきます。参加者が多いほど決まらなくなるためです。
| 役割 | 担当 | 主な責任 |
|---|---|---|
| 意思決定者 | 経営層 | 業務を変える判断、投資判断 |
| プロジェクト責任者 | 管理部門または経営企画 | 全体の進行、優先順位づけ |
| 業務キーユーザー | 各業務の実務担当 | 現場の実態の提供、検証 |
| 導入支援側 | 外部パートナー | 標準機能との照らし合わせ、代替案の提示 |
判断できる人が会議にいることが、何より重要です。持ち帰りが増えるほど、プロジェクトは止まります。
外部の支援者に求められるのは、Odooの知識だけではありません。内側にいると気づけない社内の常識を、指摘できる立場であることです。
要件定義のアウトプット（成果物）
要件定義が終わったとき、手元に残るべきものは次の4点です。
- 業務フロー図：新しい業務の流れ（現状ではなく、稼働後の姿）
- スコープ表：第1段階の対象範囲と、対象外にしたもの
- 差分一覧と判断結果：標準に合わせる／設定／ノーコード／開発の区分
- 移行対象データの一覧：どのデータを、どこまで持っていくか
この4点があれば、見積もりの精度は大きく上がります。これがない状態の見積もりは、前提が違えば簡単に変わります。
この成果物をRFPや稟議につなぐ流れは、見える化の成果物を、システム選定につなぐが参考です。
要件定義に入れる状態か：社内会議用チェックリスト
要件定義の会議を始める前に、次の項目を確かめてください。チェックがつかない項目が、最初に手を付けるべき準備です。
- □ 業務を変える判断ができる人が、毎回の会議に出られる
- □ 部署間で要望がぶつかったとき、誰が決めるかが決まっている
- □ 3〜5年後の社員数・拠点・販売チャネルを、経営者が説明できる
- □ 同じ情報を何か所で入力しているかを把握している
- □ 顧客・商品マスタの重複を、誰が整理するかが決まっている
- □ Community版とEnterprise版のどちらを前提にするか、仮置きしている
- □ 「今回は対象外」にする業務を、1つ以上挙げられる
ベンチャーネットが要件定義の入口で確かめること
ERP導入支援を手がけるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。そのため要件定義も、Odooありきでは始めません。入口では、次の順で確かめます。
- 最終判断者と、やめる判断の権限：業務を変える決定を、誰がその場で下せるかを最初に確認します。ここが曖昧なら、要望集めより先に決めていただきます。
- 3〜5年後の姿とOdooの規模感：成長や拠点展開の計画を伺い、Odooで受け止められるかを見ます。規模や要件が上回るなら、NetSuiteを正直にお勧めします。
- 手順ごとの「なぜ」：現場の手順を目的から聞き直し、Fit to Standardで標準に寄せられる候補を仕分けます。
- 実機での照らし合わせと差分の4段階判定：標準機能を実際に触りながら、差分を「合わせる／設定／ノーコード／開発」に振り分けます。どの版を前提にした判定かも記録します。
- 第1段階の線引き：まず数字が一か所で見える状態を作ります。見える化→わかる化→儲かる化の順で、分析や自動化は後の段階に回します。
差分の多くが開発になる場合は、Odooが合っていないとお伝えします。パッケージに乗らない業務なら、AIスクラッチ開発も比較に入れます。その場合も、開発費と保守費が別途かかる点を前提に検討します。
よくある質問
要件定義にはどのくらい時間をかけるべきですか？
期間は、対象業務の数と、意思決定のスピードで大きく変わります。
目安としては、判断が止まっている期間が長いほど延びると考えてください。会議の頻度よりも、決裁のリードタイムが期間を左右します。
要件定義を自社だけで進められますか？
現状の棚卸しまでは、自社でできます。難しいのは、Odooの標準機能との照らし合わせです。
標準でできることを知らないと、不要なカスタマイズを要件にしてしまいます。ここは、経験のある支援者と進めるほうが確実です。
Community版でも要件定義の進め方は同じですか？
進め方の骨格は同じです。ただし、判断材料が変わります。
Community版は無料ですが、ホスティングと保守を自社で担う必要があり、公式サポートの対象外です。一部の機能も含まれません。
そのため、「差分を埋める手段」の選択肢が変わります。内製できる技術者がいるかどうかが、要件定義の前提条件になります。
補助金を使う場合、要件定義は先に済ませるべきですか？
スコープの線引きは、少なくとも先に済ませておくほうがスムーズです。デジタル化・AI導入補助金（旧 IT導入補助金）などを活用する場合、申請時点で対象範囲の説明が必要になるためです。
制度の要件は年度ごとに変わるため、最新の公募要領を確認してください。
要件定義で最初に決めるべきことは何ですか？
範囲・深さ・順番の3つです。
どの業務をOdooに載せるか、どこまで細かく管理するか、何を第1段階で稼働させるかを決めます。この3つが決まらないまま見積もりを取っても、金額はほとんど参考になりません（要件定義で決める3つ）。
まとめ
Odooの要件定義は、機能を選ぶ作業ではありません。業務をどう変えるかを決める作業です。
- 要件定義で決めるのは、範囲・深さ・順番の3つ
- 現状の再現を目指すと、パッケージを選ぶ意味が薄れる
- 3〜5年後の姿から逆算して範囲を決める
- 差分は「標準に合わせる→設定→ノーコード→開発」の順に検討する
- Community版とEnterprise版では、「標準の範囲」自体が変わる
- 第1段階を線引きし、すべてを詰めるより先にまず回す
- この進め方は見積もりの前提をそろえる一方、やめる判断と判断できる人が要る
この工程を丁寧に進めた会社ほど、稼働後の追加費用が少なくなります。ここを飛ばして見積もりから入ると、後から範囲が膨らみます。
1年後、現場から「この帳票も出してほしい」と声が上がっても、会議で最初に開くのは要件定義で作ったスコープ表と差分一覧です。「標準に合わせられないか」「第2段階の範囲か」から話が始まり、場当たりの追加開発が稟議に上がらなくなっています。
もう少し詳しく知りたい方へ
どこまでを第1段階に入れるか、標準機能でどこまで吸収できるか。こうした判断は、業務の実態を見ないと決められません。
ベンチャーネットは、ERP導入支援を手がける立場から、要件定義の段階から一緒に整理しています。自社の業務に照らして整理したい段階から、ご相談ください。
規模や要件によっては、Odooではなく上位のNetSuite、あるいはAIスクラッチ開発が適することもあります。AIスクラッチ開発はライセンス費がかからない代わりに、開発費と保守費が別途かかります。製品ありきではなく、選択肢を並べたうえでご提案します。
関連記事
