案件管理システムとは、営業段階の商談から受注後の進行・納品・請求までを「案件」という単位でまとめ、進捗・担当者・金額・工数を一元管理する業務システムです。この記事では、エクセル台帳による案件管理の限界、SFA型・プロジェクト管理型・業種特化型という3タイプの違い、プロジェクト管理ツールやCRMとの線引きを最初に押さえます。そのうえで、公開料金から読み取れる課金方式の差、案件・工数・請求をつなぐデータ構造の組み方、既製SaaSと受託開発の選び分けまでを順に整理します。読み終えた時点で、自社の案件管理をどのタイプでシステム化すべきかを判断できるようになることが、この記事の到達目標です。
まとめ：案件管理システムの選定と導入判断の要点
案件管理システムは「1つの案件に散らばる情報を1本のデータで通す」仕組みであり、並行する案件が増えて「誰が・どこまで・いくらで」を即答できなくなった段階が導入の目安になります。エクセル台帳の運用は案件数が少なく担当者が固定されているうちは成立しますが、複数人での同時更新と案件別の採算把握には構造的に向きません。
選定の分岐は3つです。受注前の商談・受注確度の管理が主目的ならSFA型、受注後の進行・工数・採算の管理が主目的ならプロジェクト管理型、工事や広告など業種の商習慣が強い業務なら業種特化型が候補になります。広告代理店・広告制作会社に絞った媒体費原価・工数配賦・脱エクセルの判断は広告業の案件管理システムの選び方で掘り下げています。会計事務所・税理士事務所の顧問先別の期限管理と案件別採算は会計事務所の案件管理システムの選び方で扱っている内容です。法律事務所の事件・期日・タイムチャージ・預り金を含む全体像は法律事務所のシステムの6領域と選定の順序で整理しています。事件記録の持ち方や期日の逆算まで踏み込んだ案件管理の要件は弁護士の案件管理システムの設計基準で扱っています。企業の法務部門が事業部からの相談や契約審査依頼を受け付けて回答をナレッジ化する案件管理は、法務の案件管理システムとは？相談受付から契約審査・ナレッジ化までの設計と選び方で整理しています。
料金は「1ユーザーあたり月額」で積み上がる製品と、「組織単位の定額」で人数が増えても変わらない製品に分かれます。人数が多く案件数が少ない会社と、その逆の会社では、同じ製品でも総額の順位が入れ替わります。大半の企業は既製SaaSで足りますが、基幹システムとの双方向連携や業種固有の商習慣が条件に入る場合は、受託開発またはカスタマイズが検討対象です。本文では、この判断に必要な機能・違い・料金・データ構造・進め方の各論を順に解説します。
案件管理システムの定義と受注前から納品・請求まで扱う管理範囲
最初に「案件管理」という業務の範囲を確定させます。ここが曖昧なまま製品比較に入ると、SFAとプロジェクト管理ツールのどちらを検討すべきかから迷走します。
営業段階から納品・請求後まで案件単位で情報を一元管理する仕組み
案件とは、引き合いの発生から納品・請求・入金までを1つのまとまりとして扱う単位です。受注前は「A社向け基幹システム更改の商談」、受注後は「A社案件の設計・開発・検収」というように、同じ案件が営業と現場をまたいで進みます。案件管理システムはこの一連の流れを案件IDでつなぎ、顧客情報・見積金額・受注確度・担当者・進捗・作業工数・請求状況を1画面で参照できるようにします。営業の商談リストと現場の進行表が別ファイルに分かれ、受注のたびに転記する運用からの脱却が本質です。
進捗・担当者・金額・工数までつなぐ案件管理システムの基本機能
製品によって幅はありますが、基本機能は次の系統に整理できます。
- 案件台帳：顧客・金額・受注確度・期日・担当者の登録と検索
- 進捗管理：ステータス更新、ガントチャートやカンバンでの可視化
- 工数・原価管理：作業時間の記録と案件別の採算集計
- 帳票連携：見積書・注文書・請求書の発行や販売管理への引き渡し
- 報告・共有：日報や活動履歴の記録、担当者間の引き継ぎ
すべてを備えた製品が優れているわけではありません。営業寄りの製品は受注確度や商談履歴が厚く、現場寄りの製品はガントチャートや工数集計が厚いというように、機能の重心が製品タイプごとに異なります。自社が困っている工程がどこかを先に特定し、その工程が厚い製品タイプを選ぶ順番が実務的です。
エクセル台帳による案件管理が限界を迎える案件数と担当者数の目安
エクセルでの案件管理は、並行案件が10件前後・更新者が1〜2名の規模なら実務上成立します。この段階で無理にシステム化する必要はありません。台帳に持たせるべき項目の設計は属人化しがちな案件情報をエクセルで一元管理するための必須項目と設計思想で解説しており、まず台帳の型を整えるだけでも属人化はかなり抑えられます。
限界が来るのは、並行案件が数十件を超えるか、営業と現場など複数部門が同じ台帳を更新し始めた時点です。複数人の同時更新で版の食い違いが生じ、案件ごとの最新状況を確認する社内問い合わせが増え、工数や原価は台帳と別の場所に記録されるため案件別の採算が締め後まで分かりません。「台帳の更新そのものが仕事になっている」と感じたら、それがシステム移行の分岐点です。案件別の労務費を自動集計する仕組みは工数管理システムの機能と選び方の解説で確認できます。
SFA型・プロジェクト管理型・業種特化型の3タイプと違いの整理
「案件管理システム」という名称の製品は、実際には出自の異なる3タイプに分かれます。タイプを取り違えると、導入しても困っている工程が改善されません。
営業案件の受注確度を管理するSFA型と顧客管理CRMとの関係
SFA（Sales Force Automation：営業支援システム）型は、商談の発生から受注までを管理対象とするタイプです。案件を「商談」として扱い、受注確度のランク管理、営業フェーズごとの進捗、活動履歴の記録、売上予測の集計が中心機能になります。Salesforceに代表される製品群がこの系統で、同社のSFAの解説ページでは、主な機能の筆頭に「見込み顧客から受注までの商談フェーズを一元管理する」案件管理機能を挙げています。つまりSFAでいう案件管理は、受注の瞬間までを指す言葉として使われるものです。
CRM（顧客関係管理）は顧客との関係全体を管理する概念で、SFAはその中の営業工程を担う位置づけにあたります。同じページでも、SFAが焦点を当てるのは営業の「プロセス」であり、CRMが焦点を当てるのは「顧客」そのものという整理です。SFA単体の機能と選び方はSFAとは？営業支援システムの機能・CRM/MAとの違いと選び方で、両者の使い分けはSFAとCRMの違いを目的・機能で比較した解説で詳しく扱っています。受注後の進行や工数の管理は対象外の製品が多いため、「受注してからの管理」が課題の企業がSFA型を選ぶと目的とずれます。
受注後の進行・工数・採算を管理するプロジェクト管理型の対象範囲
プロジェクト管理型は、受注後の案件をタスクに分解し、担当者・期日・工数を管理するタイプです。ガントチャートやカンバンでの進捗可視化、タスクの依存関係、メンバーの負荷状況の把握が中心となる機能群です。ツールの機能や既製か自作かの判断軸はプロジェクト管理ツールとは？機能・種類・選び方と既製か自作かの判断軸を解説で詳しく整理しています。案件管理システムとの違いは金額情報の扱いにあり、プロジェクト管理ツールは進行の管理に重心がある一方、案件管理システムは見積・受注金額・原価・請求という「お金の流れ」を案件に紐づける点が異なります。受託業で案件別の採算まで見たいなら、金額と工数を両方持てるタイプが対象です。
工事管理・広告など業種の商習慣を前提にする業種特化型の見分け方
業種特化型は、特定業種の案件構造をあらかじめ製品側が持っているタイプです。建設業向けの工事管理システムはその代表例で、実行予算・出来高・安全書類という業界固有の管理項目が標準で備わります。詳細は工事管理システムとは？機能・施工管理との違いから選び方・開発判断まで解説を参照してください。広告代理店では媒体・掲載枠・入稿期日の管理が案件と一体になるため、汎用の案件管理では項目が足りず、広告業向け製品か個別開発が候補になります。自社の業種名を冠した製品カテゴリが存在するなら、汎用型より先にそちらの機能一覧を確認する方が、要件の過不足を早く見極められます。
案件管理システムの3タイプの管理範囲を商談から請求まで工程別に並べた比較表
ここまでの違いを、案件が進む工程ごとに並べると次の通りです。「○」は標準機能で厚く扱う工程、「△」は製品によっては扱える工程を示します。
| 工程 | SFA型 | プロジェクト管理型 | 業種特化型 |
|---|---|---|---|
| 商談・受注確度 | ○ | △ | △ |
| 見積・受注金額 | ○ | △ | ○ |
| タスク・進行 | △ | ○ | ○ |
| 工数・原価 | △ | ○ | ○ |
| 請求・入金 | △ | △ | ○ |
表の通り、受注前から請求までを1製品で厚く扱えるのは業種特化型に限られがちです。汎用製品で全工程をまかなう場合は、SFA型とプロジェクト管理型を案件IDで連携させるか、弱い工程を割り切る判断が要ります。
導入で解消できる属人化・採算悪化の課題と現場定着までの導入負荷
導入効果と導入負荷は表裏の関係にあります。効果だけを見て契約すると、入力が定着せず台帳が二重化する失敗に陥りがちです。
対応漏れ・報告作業・属人化など案件管理で起きやすい定番の課題
案件管理の課題は型が決まっています。並行案件の期日を見落とす対応漏れ、上長やメンバーへの状況説明のためだけに資料を作る報告作業、そして「あの案件の経緯は担当者しか知らない」という属人化の3つです。システム化すると、期日はアラートで検知され、進捗は全員が同じ画面で参照できるため報告用資料が不要になり、活動履歴が案件に残るため担当者の交代や急な不在でも引き継ぎが成立します。営業担当が5名を超えたあたりから報告・確認のやり取りは急増するため、人数が増える局面ほど効果を金額換算しやすい領域です。
案件別の工数・原価を可視化して赤字案件を早期に見つける仕組み
受託業・制作業にとって、案件管理システムの価値の中心は採算の可視化です。メンバーが日々の作業時間を案件に紐づけて記録すると、案件ごとの投入工数×人件費単価で原価が算出され、見積金額と比べた粗利が進行中に把握できます。締め後の集計で赤字が判明しても手の打ちようがありませんが、進行中に分かれば追加請求の交渉や体制の見直しという選択肢が残ります。工数記録の仕組みそのものはExcel管理の限界を感じるPMが知るべき工数管理ツールの基本機能と導入価値で解説した通りです。外注費や経費まで含めた原価の集め方は原価管理システムとは？機能・原価計算との違いから選び方と受託開発の判断まで解説で整理しており、案件管理の採算機能で足りるか、原価管理を別に持つかの線引きにも触れています。工数の入力が定着しない場合、原価データは実態から乖離します。入力は1日1回・数分で終わる粒度に抑える設計が定着の条件です。
見積・受注・請求と基幹システムへつなぐデータ連携の設計と注意点
案件管理システムは単独では完結しません。見積書の発行、受注後の売上計上、請求書の発行は、販売管理や会計など既存システムとの間でデータが行き来します。連携方式にはAPI連携・CSV連携・個別開発の3段階があり、既製SaaSの標準連携先は主要な会計ソフトに限られる場合が大半です。自社に基幹システムがある企業は、案件データと受注・請求データの重複入力が発生しない設計になっているかを契約前に確認してください。基幹システム側の構成と刷新の考え方は基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説で全体像を整理しています。連携を後回しにした導入は、結局エクセルへの転記が残る中途半端な結果になりがちです。
案件・工数・請求の3テーブル設計とSQLで案件別粗利を集計する手順
製品を比べる前に、案件管理システムの中身がどんなデータ構造でできているかを一度組んでみると、製品の画面を見たときに「どのテーブルに当たる機能か」が読めるようになります。ここではPostgreSQLを例に、最小構成の3テーブルと案件別粗利の集計クエリを示します。既製SaaSを選ぶ場合でも、製品を評価する際の物差しとなるのは、この3つの関係が製品内で表現できるかどうかです。
案件台帳・工数記録・請求の3テーブルを定義するDDLの書き方
案件台帳（deals）を中心に、工数記録（time_entries）と請求（invoices）が案件IDで外部キー参照する構造です。受注確度とステージは台帳側に持たせ、工数と請求は案件に対して何行でも積み上がる形にします。
CREATE TABLE deals (
deal_id serial PRIMARY KEY,
customer text NOT NULL,
title text NOT NULL,
stage text NOT NULL CHECK (stage IN ('商談', '受注', '進行', '納品', '請求済')),
win_rate int CHECK (win_rate BETWEEN 0 AND 100),
order_amount numeric(12, 0),
owner text NOT NULL,
due_date date
);
CREATE TABLE time_entries (
entry_id serial PRIMARY KEY,
deal_id int NOT NULL REFERENCES deals (deal_id),
member text NOT NULL,
work_date date NOT NULL,
hours numeric(6, 2) NOT NULL CHECK (hours > 0),
unit_cost numeric(8, 0) NOT NULL
);
CREATE TABLE invoices (
invoice_id serial PRIMARY KEY,
deal_id int NOT NULL REFERENCES deals (deal_id),
amount numeric(12, 0) NOT NULL,
issued_on date NOT NULL
);
INSERT INTO deals (customer, title, stage, win_rate, order_amount, owner, due_date) VALUES
('A社', '基幹システム更改', '進行', 100, 3000000, '佐藤', '2026-12-25'),
('B社', 'LP制作', '進行', 100, 800000, '鈴木', '2026-10-31');
INSERT INTO time_entries (deal_id, member, work_date, hours, unit_cost) VALUES
(1, '田中', '2026-09-01', 120, 5000),
(1, '高橋', '2026-09-01', 80, 6000),
(2, '伊藤', '2026-09-01', 150, 5000);
INSERT INTO invoices (deal_id, amount, issued_on) VALUES
(1, 1500000, '2026-09-30');unit_cost（人件費単価）を工数行に持たせているのは、昇給や担当交代で単価が変わっても過去の原価が書き換わらないようにするためです。台帳側にだけ単価を置くと、過去案件の粗利が後から動いてしまいます。
進行中の案件ごとに原価・粗利率・請求残を出すSQL集計クエリの書き方
次のクエリは、受注済みで進行中の案件について、投入工数から算出した労務費・粗利・粗利率・請求残を一覧にし、粗利率の低い順に並べます。赤字に近い案件が一番上に来るため、週次の案件会議でそのまま使える並びです。
SELECT
d.deal_id,
d.title,
d.order_amount,
COALESCE(SUM(t.hours * t.unit_cost), 0) AS labor_cost,
d.order_amount - COALESCE(SUM(t.hours * t.unit_cost), 0) AS gross_profit,
ROUND((d.order_amount - COALESCE(SUM(t.hours * t.unit_cost), 0)) * 100.0
/ NULLIF(d.order_amount, 0), 1) AS margin_pct,
d.order_amount - COALESCE((SELECT SUM(i.amount) FROM invoices i
WHERE i.deal_id = d.deal_id), 0) AS unbilled
FROM deals d
LEFT JOIN time_entries t ON t.deal_id = d.deal_id
WHERE d.stage IN ('受注', '進行')
GROUP BY d.deal_id
ORDER BY margin_pct;上のサンプルデータで実行すると、次の結果になります。B社のLP制作は工数150時間で労務費75万円に達しており、受注額80万円に対して粗利率は6.3％まで落ちています。A社案件は粗利率64.0％で、請求残は150万円です。
deal_id | title | order_amount | labor_cost | gross_profit | margin_pct | unbilled
---------+------------------+--------------+------------+--------------+------------+----------
2 | LP制作 | 800000 | 750000.00 | 50000.00 | 6.3 | 800000
1 | 基幹システム更改 | 3000000 | 1080000.00 | 1920000.00 | 64.0 | 1500000請求を工数と同じ結合に入れず相関サブクエリで足しているのは、1案件に工数行と請求行が複数あると結合で行が掛け算になり、金額が膨らむためです。製品評価の場面では「工数と請求を両方持つ案件で、粗利と請求残が正しく同じ画面に出るか」を実データで試すと、集計の作りの甘さが見えます。
既製SaaSで足りる条件と受託開発へ進む案件管理システムの判断基準
ここまでの各論を導入判断の形に集約します。結論から言えば、案件構造が標準的な企業は既製SaaSで足り、受託開発が正解になるのは条件が明確な少数派です。
製品選定で確認する連携範囲・入力負荷・料金体系のチェック観点
製品を比較する際の確認観点は3つです。第一に連携範囲で、既存の会計ソフト・グループウェアと標準連携できるか、できない場合の回避手段があるかを見ます。第二に入力負荷で、現場が毎日触る画面の入力項目数と手数を確認します。項目が多いほど分析の粒度は細かくなる一方、入力されなければ意味がありません。第三に料金体系で、ユーザー数課金か組織単位の定額か、人数が増えた場合の総額を試算します。無料トライアルを実データの案件で試し、入力から報告までの手数を確認してから契約する進め方が堅実です。製品タイプごとの比較軸と既製・受託の選び分けは案件管理ツールの比較｜SFA型・プロジェクト管理型・脱エクセルの選び方と判断基準で解説しています。
ユーザー課金と組織定額で変わる案件管理ツールの人数・案件数別の料金の比べ方
料金体系の違いは、公開料金を並べると具体的に見えます。案件台帳を自作アプリとして組む用途で使われるkintoneの料金ページと、受注後の進行管理に使われるBacklogの料金プランを、2026年9月時点の掲載値（税抜）で比べます。
| 製品・プラン | 課金単位 | 掲載価格（税抜） | 主な上限 |
|---|---|---|---|
| kintone ライト | 1ユーザー | 月額1,000円 | 最低10ユーザー |
| kintone スタンダード | 1ユーザー | 月額1,800円 | 最低10ユーザー |
| Backlog スターター | 組織定額 | 月額2,700円 | 30ユーザー・5プロジェクト |
| Backlog スタンダード | 組織定額 | 月額16,000円 | ユーザー無制限・100プロジェクト |
30人で使う場合、kintoneスタンダードは1,800円×30人で月額54,000円、Backlogスタンダードは人数にかかわらず月額16,000円です。一方でBacklogはプランごとにプロジェクト数の上限があり、案件を1プロジェクトずつ切る運用だと上限に先に当たります。ユーザー課金は人数、組織定額は案件（プロジェクト）数が総額を動かす変数になるため、自社の「人数」と「年間の並行案件数」の両方を入れて試算してください。なおBacklogの料金ページには2027年1月1日からプランが新しくなる旨の告知が出ているため、契約時点の掲載値を必ず取り直す必要があります。
既製の案件管理システム導入で足りる企業条件と過剰投資の見送り
次の条件がそろう企業は、既製SaaSの標準機能で運用が成立します。受託開発は過剰投資です。
- 案件の進み方が業界標準的で、独自の承認・商習慣が少ない
- 既存システムとの連携がCSVの取り込み程度で足りる
- 管理したい項目が台帳・進捗・工数・簡易な採算に収まる
逆に、並行案件が10件未満で担当者も固定されている段階なら、システム自体を見送りエクセル台帳の設計改善で十分です。ツール導入は「管理の仕組みが回り始めてから」の方が定着します。標準機能に業務を寄せる割り切りが、導入コストと定着スピードの両方に効きます。
基幹システム連携・業種固有の商習慣がある企業に受託開発が向く条件
一方、次のいずれかに当てはまる場合、既製品の標準機能では吸収しきれず、受託開発またはカスタマイズ前提の製品が検討対象になります。基幹システムと案件データの双方向連携が必須の場合、業種固有の案件構造（工事の実行予算管理、広告の媒体・入稿管理など）を製品側が持てない場合、案件・工数・原価・請求を自社の管理会計の粒度で一体化したい場合の3系統です。当社（株式会社一創）でも基幹システム開発として、案件管理を含む業務の流れを一元管理する仕組みを個別要件で設計・開発しています。
逆に、既製SaaSを一度も運用していない段階でいきなり開発に進むのは推奨しません。まず既製品で管理の型を作り、標準機能の限界が具体的な項目名で言える状態になってから開発に進む順番が、要件のぶれを最小にします。前章の3テーブルのどこが足りないのか（たとえば「工数行に単価を持てない」「1案件に複数請求を紐づけられない」）まで言語化できれば、その内容をそのまま要件定義の入力として使うことが可能です。既製品の限界を要件に落とす段階から相談したい場合は、要件定義・RFP作成・PMO支援で、現行台帳の棚卸しから開発会社へ渡すRFPの作成までを支援しています。
よくある質問
案件管理システムの検討時に問い合わせの多い質問へ、本文の要点を踏まえて簡潔に回答します。
案件管理システムとSFA・CRMの違いは何ですか？
管理対象の範囲が違います。SFAは商談発生から受注までの営業工程、CRMは顧客との関係全体を管理する概念です。案件管理システムは受注前後をまたいで案件単位の進捗・工数・採算まで扱う点で守備範囲が広く、SFAの商談管理機能を内包する製品もあります。受注前の営業管理だけが課題ならSFA、受注後の進行・採算まで見たいなら案件管理システムが対象です。
エクセルでの案件管理はどこまで通用しますか？
並行案件が10件前後・更新者が1〜2名までなら、項目設計を整えたエクセル台帳で実務は回ります。費用もかかりません。ただし複数人の同時更新、期日アラート、工数と紐づけた案件別の採算集計はエクセルの構造上苦手です。並行案件が数十件を超えるか、複数部門で同じ台帳を触り始めた時点がシステム移行の目安になります。
プロジェクト管理ツールとどちらを導入すべきですか？
金額を管理したいかどうかで決まります。タスクの進捗・担当・期日の管理が目的ならプロジェクト管理ツールで足ります。見積金額・受注確度・原価・請求という「お金の流れ」を案件に紐づけたいなら案件管理システムが対象です。受託業で案件別の粗利を進行中に把握したい場合は、工数と金額を両方持てる案件管理システム側を選んでください。
無料で使える案件管理システムはありますか？
ユーザー数や案件数に上限を設けた無料プランを持つ製品はあります。少人数でまず管理の型を作る用途には有効です。ただし無料枠は履歴の保存期間・帳票発行・外部連携に制限がある場合が多く、運用が軌道に乗ると有料プランへの移行が前提になります。無料期間は「自社の案件構造がその製品で表現できるか」の検証に充てるのが実務的な使い方です。
案件管理システムの費用相場はどれくらいですか？
既製SaaSはユーザー単価の月額課金が主流で、1ユーザーあたり月額数百円台から数千円台まで機能に応じて幅があります。たとえばkintoneは2026年9月時点で1ユーザー月額1,000円〜1,800円（税抜・最低10ユーザー）、Backlogは組織単位で月額2,700円〜の定額です。初期費用がない製品も珍しくありません。一方、基幹連携や業種固有要件を含む受託開発は要件定義から設計・開発・テストまでを含め、規模により数百万円からの投資になります。人数×単価の年額と開発費を、想定利用年数の総額で比較してください。
関連記事
- プロジェクト管理ツールとは？機能・種類・選び方と既製か自作かの判断軸を解説：受注後の進行管理に重心を置く場合の選択肢を整理しています。
- タスク管理ツールとは？機能・種類・選び方と既製か自作かの判断軸を解説：案件より細かいタスク粒度の管理を検討する場合の起点です。
- 工事管理システムとは？機能・施工管理との違いから選び方・開発判断まで解説：建設業の案件（工事）管理に特化した業種特化型の代表例です。
- 受注管理システムとは？機能・受発注システムとの違いとEC一元管理・導入判断：受注処理から出荷・売上連携までを整えたい場合に参照してください。
