受託開発、コンサルティング、デザイン、広告、保守サービス。
案件単位で仕事を受けるビジネスには、共通する悩みがあります。
「忙しいのに、利益が残らない」
売上は伸びている。社員も稼働している。それなのに、思ったほど利益が出ない。
この状態が続くとき、原因はたいてい同じところにあります。案件ごとの採算が、終わってからしか分からないことです。
この記事では、サービス業やプロジェクト型ビジネスがOdoo（オドゥー：オープンソース由来の統合業務アプリ群）で何を可視化できるのかを整理します。
サービス業の原価は「人の時間」
製造業なら、原価の中心は材料費です。数量と単価で計算できます。
しかしサービス業では、原価の大半が人件費です。そして人件費は、誰が、どの案件に、何時間かけたかで決まります。
ここが記録されていないと、次のことが起こります。
- 案件Aは黒字、案件Bは赤字。しかしどちらか分からない
- 「この規模ならこのくらい」という見積が、経験と勘のままになる
- 追加で発生した作業を、請求できずに飲み込む
- 特定の人に負荷が集中していることに気づけない
逆に言えば、工数が記録されるだけで、多くのことが見えるようになります。
Odooで統合できる範囲
Odooは業務ごとのアプリを組み合わせる構造です。プロジェクト型ビジネスに関わる主なアプリは次のとおりです。
| アプリ | 担う領域 |
|---|---|
| CRM | 引き合いから受注までの案件管理 |
| 販売 | 見積の作成、受注の記録 |
| プロジェクト | 案件ごとのタスクと進捗の管理 |
| タイムシート | 誰がどの案件に何時間かけたかの記録 |
| フィールドサービス | 現地作業の管理（訪問型のサービス業向け） |
| ヘルプデスク | 問い合わせ・サポート案件の管理 |
| 会計 | 売上・原価の計上、請求 |
（アプリ構成はOdoo公式サイトの案内にもとづく。2026年8月確認）
重要なのは、これらが同じ案件を軸につながっている点です。
見えるようになる4つのこと
案件ごとの採算
売上から、その案件にかかった工数分の人件費と外注費を引く。これで案件別の利益が出ます。
進行中に見えることが重要です。終わってから赤字だと分かっても、打つ手はありません。
進行中なら、次の判断ができます。
- 追加作業として交渉する
- 作業範囲を見直す
- 体制を組み替える
見積の精度
過去の案件の実績が蓄積されると、見積の根拠が変わります。
「この規模のサイト制作は、前回120時間かかった」という実績があれば、次の見積が現実的になります。
これは営業力にも直結します。根拠のある見積は、値引き交渉にも耐えやすくなります。
稼働の偏り
誰がどのくらい稼働しているかが見えると、負荷の偏りに気づけます。
特定の人に集中していれば、離職のリスクにもなります。数字で見えていれば、早めに手を打てます。
請求漏れ
追加で発生した作業が記録されていれば、請求の対象かどうかを判断できます。
記録がなければ、そもそも気づけません。サービス業の利益は、ここで静かに削られています。
最大の壁は「工数入力の定着」
正直に書きます。この仕組みが機能するかどうかは、工数が記録されるかどうかにかかっています。
そして、工数入力は最も定着しにくい業務のひとつです。
なぜ嫌がられるのか
- 自分の仕事が増えるだけに感じる
- 監視されているように受け取られる
- 忙しいときほど、入力が後回しになる
- あとからまとめて入力するため、精度が落ちる
定着させるための現実的な工夫
1. 粒度を細かくしすぎない
15分単位で全作業を記録させると、確実に破綻します。まずは案件単位、半日単位から始めてください。
精度は、続いてから上げれば十分です。
2. 入力の場所を減らす
タスクの画面からそのまま工数を入れられるようにする。日報と工数入力を二重にしない。入力の手間を最小にしてください。
3. 評価に直結させない
「稼働率が低い人を評価しない」という使い方をすると、入力は必ず歪みます。
工数データは案件の採算を見るためのものであり、個人を評価するためのものではない。この線引きを明示してください。
4. 現場に還元する
記録した結果を、現場にも見せてください。
「あの案件は想定より時間がかかった。だから次は見積を上げよう」という会話が生まれれば、入力する意味が実感できます。
定着の考え方はOdooを社内に定着させる方法で詳しく扱っています。
導入で優先すべき順番
第1段階：案件と工数
まず、案件を登録し、工数を記録する。ここだけで十分に効果が出ます。
会計との連携は後回しでも構いません。案件別の実績が見えるだけで、経営の会話が変わります。
第2段階：見積と受注
CRMと販売をつなぎ、見積の想定工数と実績を比較できるようにします。
第3段階：請求と会計
実績にもとづく請求、案件別の損益計算につなげます。
第4段階：分析と改善
案件の類型別の採算、顧客別の利益率などを見ていきます。
「完璧を目指すより、まず回す」という進め方が、とくにこの領域では効きます。工数入力が定着しないまま高度な分析を設計しても、使われません。
業態による違い
サービス業といっても、業態によって重点が変わります。
| 業態 | 重点になる領域 |
|---|---|
| 受託開発・制作 | 案件別の工数と採算、仕様変更の記録 |
| コンサルティング | 稼働率、案件の進捗、成果物の管理 |
| 保守・サポート | 問い合わせの管理、契約の更新管理 |
| 訪問型サービス | 現地作業の記録、スケジュール調整 |
| 常駐・派遣型 | 稼働時間の管理、請求との連動 |
契約形態の違いも重要です。
請負型（成果物に対して対価）と、準委任型（稼働時間に対して対価）では、請求の考え方が変わります。
自社の契約形態を整理したうえで、どう記録するかを設計してください。
Community版とEnterprise版で何が変わるか
- Community版：無料のオープンソース版。ホスティングと保守は自社の責任で、公式サポートの対象外。一部の機能は含まれない
- Enterprise版：有償のサブスクリプション。公式サポートと全アプリを含む
サービス業では、社員のほぼ全員が工数を入力することになります。利用人数が費用に影響する点は、事前に確認してください。
詳細はOdoo Community版とEnterprise版の違いで整理しています。
Odooが合わない場合もある
次のような場合は、別の選択肢を検討する価値があります。
すでに専門ツールが定着している場合
プロジェクト管理ツールが現場に深く根付いているなら、無理に統合しない判断もあります。会計側だけを整える進め方が合理的なこともあります。
業務の型が特殊で、既製の仕組みに乗りにくい場合
独自の契約形態や、特殊な原価計算が競争力に直結している場合です。
この場合、必要な機能だけを自社資産として作るAIスクラッチ開発という選択肢もあります。ただしライセンス費用がない代わりに、開発費と保守費が発生します。
判断の考え方はパッケージERPかスクラッチ開発かで整理しています。
よくある質問
工数入力はどのくらいの粒度で始めるべきですか？
案件単位、半日単位から始めることを推奨します。
細かくしすぎると入力されなくなり、データがそろいません。入力されない精密な設計より、入力される粗い設計のほうが価値があります。
少人数の会社でも意味がありますか？
意味があります。むしろ少人数のほうが、一人の稼働が採算に与える影響は大きくなります。
ただし、導入の負担と効果のバランスは考えてください。まずは案件と工数だけ、という始め方でも十分です。
既存のプロジェクト管理ツールから移行すべきですか？
必ずしもそうではありません。現場に定着しているツールを剥がすと、抵抗が大きくなります。
判断の基準は、会計や請求とつなぎたいかどうかです。つなぐ必要がないなら、無理に統合しなくても構いません。
案件別の原価には何を含めるべきですか？
まずは直接の人件費と外注費から始めてください。
間接費の配賦まで最初から設計すると複雑になります。直接費だけでも、案件間の比較には十分使えます。
進行中の案件の採算は、どのくらいの頻度で見るべきですか？
週次が現実的です。月次では、気づいたときには手遅れになりがちです。
ただし見る会議体がなければ、数字は活用されません。誰が、いつ見るかを決めてください。
まとめ
サービス業・プロジェクト型ビジネスがOdooを活用するときの要点は次のとおりです。
- サービス業の原価は人の時間。工数が記録されないと採算は見えない
- 案件を軸に、見積・工数・請求がつながることで、進行中に採算が見える
- 見えるようになるのは、案件採算・見積の精度・稼働の偏り・請求漏れの4つ
- 最大の壁は工数入力の定着。粒度を細かくしすぎない
- 工数データを個人の評価に使わない。使えば必ず歪む
- 導入は「案件と工数」から始める。会計連携は後回しでよい
- 記録した結果を現場に還元すると、入力する意味が実感される
まず回してみて、動かしながら精度を上げる。この進め方が、とくにこの領域では有効です。
もう少し詳しく知りたい方へ
案件採算の可視化は、機能を入れれば実現するものではありません。工数が記録される状態をどう作るか。ここが本質です。
そして、この設計には業務の理解が要ります。契約形態、案件の進め方、現場の負担感。これらを踏まえないと、入力されない仕組みができあがります。
ベンチャーネットは、ERP導入支援を手がける立場から、この設計と定着までご一緒しています。
規模や業態によっては、Odooではなく上位のNetSuiteやSAP、あるいはパッケージに乗らない業務向けのAIスクラッチ開発が適することもあります。製品ありきではなくご提案します。
関連記事
