「あの申請、承認もらえましたか」
社内でこの確認をしている時間は、意外と長いものです。
備品の購入、出張の申請、契約書の押印依頼、社外への持ち出し許可。どれも小さな判断ですが、止まると仕事が進みません。
そして止まっている原因を調べると、たいてい同じ結論にたどり着きます。
承認する人が、申請が来ていることを知らなかった。
チャットで送った申請が流れてしまった。メールが他の連絡に埋もれた。口頭で伝えた話が忘れられた。誰も悪くないのに、止まっています。
この記事では、Odoo（オドゥー：オープンソース由来の統合業務アプリ群）の承認ワークフローを、機能の各論として整理します。
⚠️ このアプリはEnterprise版限定です
Odooの承認アプリは、有償の Enterprise版 が対象と案内されています。無料の Community版では利用できません。この記事はEnterprise版を前提に書いています。
承認が止まる原因は、たいてい「見えなさ」
まず構造から見てください。
右側の形にすると、変わることは2つです。
- 承認者が、自分の未処理を1か所で見られる
- 申請者が、自分で状態を確認できる
2つ目のほうが効きます。「あの申請どうなりましたか」という確認が、そもそも不要になるからです。
記録が残ることの意味
もう1つ、副次的ですが大きな効果があります。いつ、誰が承認したかが残ります。
紙とチャットの運用では、後から「これは誰が決めたのか」をたどれません。監査や社内の振り返りで困るのは、この部分です。
承認ワークフローでできること
Odooの承認アプリは、おおむね次のような構成になっています（2026年8月時点の一般的な構成）。
承認の種類を定義する
- 「備品購入」「出張申請」「契約書の確認」のように、承認の種類（承認タイプ）を作る
- 種類ごとに、承認する人を設定する
- 種類ごとに、何人の承認が必要かを設定する
- 申請時に入力してもらう項目や、添付を求めるかを決められる
申請と承認
- 申請者が、種類を選んで申請を作成し、提出する
- 承認者の一覧に、未処理として表示される
- 承認者が承認、または却下する
- 申請者は、自分の申請の状態を確認できる
専門用語の整理：ここでいう「ワークフロー」とは、申請が承認を経て確定するまでの決まった流れのことです。回覧板の順番を、システム上に置いたものだと考えてください。
設定できる項目の細かな名称や範囲は、バージョンによって変わります。 検討時には対象バージョンの公式資料で確認してください。
設計は「何を承認しないか」から始める
ここが設計の要点です。
承認の仕組みを入れると、あれもこれも承認対象にしたくなります。 その結果、承認が業務の渋滞になります。
判断の基準
承認を置くかどうかは、次の1点で判断してください。
その申請を止めることで防げる損失が、待たせることで生じる損失より大きいか。
少額の消耗品を上長2名の承認にすると、防げる損失より、待っている時間の損失のほうが大きくなります。
承認を増やしすぎると起きること
- 承認者が中身を見なくなる（通す作業になる）
- 申請者が、承認の要らないやり方を探すようになる
- 「承認したのに問題が起きた」ときの責任があいまいになる
3つ目が深刻です。 形だけの承認は、統制を強めるどころか弱めます。
例外の手続きを、必ずセットで決める
承認の設計でいちばん忘れられるのが、ここです。
必ず起きること
- 承認者が休んでいる（出張、休暇、病気）
- 急いでいる（当日中に決めないと機会を逃す）
- 承認者本人が申請者になる
この3つは必ず起きます。そして、決めていないと現場が独自に回避します。
「部長が不在なので、とりあえず進めておきました」が常態化すると、仕組みそのものが形骸化します。
決めておくこと
| 場面 | 決めること |
|---|---|
| 承認者の不在 | 代理の承認者を誰にするか。事前に設定するのか、その都度か |
| 緊急時 | 先に実行して事後承認とする範囲。その場合の記録の残し方 |
| 承認者が申請者 | 上位の承認者に回すのか、別部門の同格者に回すのか |
例外の手続きは、抜け道ではありません。 決めておくことで、記録に残る形の例外になります。決めていないと、記録に残らない形の例外になります。
承認は「監視」ではありません
強調しておきたい点です。
承認の仕組みを入れると、細かく管理する目的だと受け取られることがあります。 そうなると、現場の抵抗が生まれます。
目的の説明を、先にしてください
承認の目的は、次のどちらかであるべきです。
- 判断の品質を上げる（一人で決めると見落とす点を、別の目で確認する）
- 記録を残す（後から「誰が決めたか」をたどれるようにする）
「信用していないから確認する」ではありません。 ここを説明せずに導入すると、申請する側は「疑われている」と感じます。
実務上の勧め
- 承認を置く理由を、種類ごとに1行で説明できるようにする
- 説明できない承認は、置かない
- 導入後、却下がほとんど発生していない種類は見直す
3つ目は有効な点検方法です。1年間ほぼ全件が承認されている種類は、承認である必要がないかもしれません。 事後の記録だけで足りる可能性があります。
社内への説明と定着の進め方は Odooを社内に定着させる方法 にまとめています。
各アプリに組み込まれた承認との違い
ここを整理しておかないと、設計が重複します。
Odooでは、いくつかのアプリに承認の仕組みがもともと組み込まれています。
| 対象 | どこで承認するか |
|---|---|
| 立替経費の精算 | 経費精算アプリの中 |
| 発注（購買） | 購買アプリの中 |
| 休暇の申請 | 休暇管理アプリの中 |
| 工数の確定 | 工数管理アプリの中 |
これらは、それぞれのアプリで完結させてください。 承認アプリで作り直す必要はありません。
では、承認アプリは何に使うのか
どのアプリにも属さない申請です。
- 備品の購入依頼（発注の前段階の相談）
- 出張や外出の届け出
- 社外への持ち出し許可
- 各種の社内手続き
つまり、紙の稟議書や申請書で回していたものが対象です。
経費と発注の各論は、それぞれの記事にまとめています。
Community版とEnterprise版の違い
Odooには、無料の Community版 と有償の Enterprise版 があります。
Community版はオープンソースとして無料で使えます。ただし、サーバの用意・アップデート・障害対応は自社の責任になり、公式サポートの対象外です。
承認アプリは、Enterprise版が対象です。Community版では利用できないと案内されています。
一方で、前章のとおり購買や休暇の承認は、各アプリの中に組み込まれています。 そちらはCommunity版でも利用できる範囲があります。
つまり、「承認アプリがないと承認ができない」わけではありません。 汎用の申請フォームが必要かどうかが、判断の分かれ目です。
どの機能がどちらの版で使えるかはバージョンによって変わります。 検討時には必ず対象バージョンで確認してください。
詳しくは Odoo Community版とEnterprise版の違い をご覧ください。
他のアプリとのつながり
| アプリ | つながり方 |
|---|---|
| 経費精算 | 精算の承認は経費側で完結する。役割を分ける |
| 購買管理 | 発注の承認は購買側で完結する。備品の購入相談は承認アプリ側 |
| 人事管理 | 申請者・承認者の所属と上長関係の元データ |
| 社内チャット | 申請ごとのやり取りが、その記録に残る |
| 文書管理 | 申請の根拠となる書類の最新版を、探さずに済む状態にする |
詳細はそれぞれの記事にまとめています。
- Odooの経費精算（Expenses）
- Odooの購買管理（Purchase）
- Odooの人事管理（Employees）
- Odooの社内チャット（Discuss）
- Odooの文書管理（Documents）
よくある質問
Q1. 承認の段階は、いくつまで作れますか？
種類ごとに承認者と必要な人数を設定できます。ただし、段階を増やすほど滞留します。
大半の申請は、上長1名で足りるはずです。 複数名の承認は、後戻りが難しい判断に限定してください。
Q2. 承認者が不在のときはどうなりますか？
代理の運用を、先に決めておいてください。
決めていないと、現場が独自に回避します。「不在なので進めておきました」が常態化すると、仕組みそのものが意味を失います。
Q3. スマートフォンから承認できますか？
Odooのモバイルアプリは、Enterprise版が対象と案内されています。承認アプリ自体もEnterprise版が対象のため、条件は揃います。
ただし操作性は実機で確認してください。 承認は移動中に行われることが多く、ここが使いにくいと滞留の原因になります。
Q4. 紙の稟議書と同じ様式にできますか？
同じ様式を再現しようとしないでください。 紙の様式には、紙だから必要だった項目が含まれています。
回覧の順序を記す欄や、押印欄はその代表です。再現すると、非効率まで引き継ぎます。
考え方は Odooの標準機能に業務を合わせる（fit to standard） にまとめています。
Q5. 承認の履歴は、どのくらい残りますか？
申請ごとに、承認の記録が残ります。保存期間の方針は、自社で決める必要があります。
監査で参照する可能性がある種類については、あらかじめ保存の考え方を決めておいてください。
まとめ
Odooの承認ワークフローが変えるのは、申請の速さそのものではありません。
今どこで止まっているかが、申請者にも承認者にも見えるようになること。 これが本質です。
承認者は自分の未処理を1か所で見られます。申請者は自分で状態を確認できます。その結果、「あの申請どうなりましたか」という確認が要らなくなります。
そして設計は、何を承認するかではなく、何を承認しないかから始めてください。
判断の基準は1つです。止めることで防げる損失が、待たせることで生じる損失より大きいか。 少額の消耗品を複数名の承認にすると、この計算は合いません。
例外の手続きも、必ずセットで決めてください。承認者の不在、緊急時、承認者本人が申請者になる場合。 この3つは必ず起きます。決めていないと、記録に残らない形の例外が生まれます。
最後に、承認は監視ではありません。 目的は判断の品質を上げることと、記録を残すことです。この説明を先にしないまま導入すると、申請する側は疑われていると感じます。
1年間ほぼ全件が承認されている種類があれば、それは承認でなくてよいのかもしれません。入れたあとに減らす点検を、運用に組み込んでください。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。
「今の稟議のうち、どれを承認から外すか」という整理からご相談を承っています。
あわせて読みたい記事
