案件管理システム開発は、要件整理から定着・改善までの6フェーズで進みます。各フェーズの内容は、下の見出しで順に示します。特に、実案件での選定や段階的な導入を取り入れると、受注から検収・請求までの判断を早められます。
全体像は案件管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・案件管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
案件管理システム開発の全体像
案件管理システムは、商談後の実行状況と採算を追う業務基盤です。
案件管理システムは、営業活動だけを記録するSFAや、タスクを並べるツールとは役割が異なります。
営業、PM、現場、経理が同じ情報を見て次の判断を行うため、開発の成否は画面数では決まりません。大切なのは、誰がいつ情報を更新し、その情報で何を決めるかを定義することです。
案件管理システムで扱う情報
案件管理システムでは、顧客や担当者の基本情報から、工数、費用、請求、粗利までを案件ごとにひも付けて持ちます。扱う情報は、分類ごとに見ると中身をつかみやすくなります。
- 基本情報：番号、顧客、担当者を管理します。
- 契約と進捗：種別と受注確度、契約金額、開始・終了予定日を押さえ、フェーズと次回アクションも扱います。
- 工数と費用：受注後まで扱う場合は、WBSやマイルストーン、予定・実績工数に加えて、外注費と経費も案件にひも付けます。
- 請求と粗利：請求額、粗利、検収日も案件に含めます。こうすると、各部門が別々の表を持つ状態を解消し、案件番号から必要な情報を確認できます。
システムSIでは、進捗が順調でも、工数超過や外注費の増加で利益が消えることがあります。そのため、進捗率に加えて、予算工数と実績工数、予定原価と着地見込、未請求額を同じ画面で確認します。
CRM・SFA・タスク管理・ERPとの違い
各ツールは、管理対象が異なります。一方、案件管理は、受注後の契約や体制、作業を、原価と請求まで案件単位でつなぎます。
- CRM：顧客との関係や接点を管理します。
- SFA：営業活動や商談の進捗を追います。
- タスク管理：作業と期限の共有が中心です。
- ERP：会計や販売など全社の基幹業務を統合します。
ERPに案件管理が組み込まれる場合もあります。ただし、進捗の共有だけならタスク管理から始められます。粗利や請求まで一体で見る場合は、パッケージ、ローコード基盤、ERP連携を比較します。
SFAに顧客情報があっても、受注後の工数や原価を別々に管理しているなら、連携項目と責任部署を整理します。そのうえで、対象範囲を決めます。
SaaS・ローコード・パッケージ・スクラッチの使い分け
発注側は、標準機能への適合度、独自要件、運用体制を見て方式を選びます。初期段階では、現場の入力環境や原価計算の精度も確認しておきます。
- SaaS：標準機能に業務を合わせられる会社向けで、初期費用と期間を抑えやすい方式です。
- ローコード：案件台帳や承認を自社の言葉で作り、継続的に改善したい会社に合います。
- パッケージ：工数・原価・請求の業務知識を活用できますが、標準外の帳票や複雑な承認には追加費用がかかります。
- スクラッチ：独自の採算管理や複数連携に向きますが、要件定義と保守を長期にわたって担う必要があります。
まずは、案件台帳と進捗、担当者、期限を現場に定着させます。さらに、受注金額、実績工数、粗利も加えます。一方、請求・会計連携やAI予測は、そのあとに段階的に追加するのが現実的です。
方式を決めるときは、機能数に加えて、既存システムとの境界や、導入後に改善できる体制も判断材料にします。
案件管理システム開発の進め方｜6フェーズで解説
開発は、要件整理・企画から始まり、選定、設計開発の順に進みます。その後、テストと稼働を経て、定着・改善へ移ります。各フェーズの間には、短い確認サイクルを挟みます。たとえば、要件整理中に候補製品を試し、設計中に現場レビューを行います。さらに、テスト結果から運用ルールを見直すことも大切です。
フェーズ1：要件整理・企画
最初に決めるのは画面ではなく、解決すべき経営・現場の課題です。そのうえで、目的を測定可能なKPIに落とし込みます。
- 会議時間：週次の進捗会議を30分短縮します。
- 工数入力：入力率を95％以上にする目標です。
- 赤字兆候：検収前に赤字化の兆候がわかる状態。
- 失注理由：毎月の集計で見られる状態です。
目的を「情報を一元化する」のままにすると、残す情報と捨てる情報を判断できなくなります。
そこで、営業、PM、現場、経理、情報システムの代表者が集まり、問い合わせから請求までの業務を時系列に整理します。さらに、ステータスの開始・終了条件や、更新者、期限、例外処理も確認します。
情報は、Excelやメール、チャットのほか、紙や個人メモにも分散しています。
まず、これらを洗い出します。洗い出した内容は、業務フロー、用語・マスタ一覧、課題一覧、優先度付きの要求リストにまとめます。
案件の粒度を、顧客、契約、プロジェクト、作業のどこに置くかを決めます。また、案件番号を誰が発番するか、失注・中止・再開をどう扱うかも決めておきます。
協力会社が入力する場合は、社外ユーザーの権限と閲覧項目、アカウントの終了条件を確認します。
フェーズ2：SaaS・パッケージ・開発会社の選定
まず、要件ごとの対応方法を分類します。製品名や機能数で比べる前に、この分類を用意しておきます。そのうえで、実案件を使ったPoCで、操作と業務適合性を確かめます。
- 標準機能：製品の標準機能で対応します。
- 設定対応：設定やプラグインで対応します。
- 追加開発：個別開発が必要です。
- 対象外：システムの対象に含めません。
10〜20件の実案件を使い、登録、ステータス変更、工数入力を試します。さらに、承認、検索、帳票出力も確認します。表記揺れのある案件や途中で変更した案件、失注や赤字化した案件も入れると、適合性を確認できます。
比べる観点には、案件・契約・工数・原価の標準機能、スマートフォン入力、協力会社のゲスト利用を含めます。
会計・勤怠・CRMとのAPIまたはCSV連携を確認します。あわせて、権限や操作ログ、バックアップを見ます。さらに、データ返却や導入支援も確認します。
見積もりは、ライセンス費に加えて、初期設定とアプリ設計を分けてもらいます。移行、帳票、教育、保守も、それぞれ分けて示してもらいます。
開発会社は、同業界や同規模の実績で確かめます。そのうえで、共同で要件定義を進める体制、受入支援、納品物を見ます。さらに、再委託先と担当者の継続性も確認します。
製品ベンダーやローコード支援会社、大規模SI、スクラッチ開発会社では、責任範囲が異なります。そのため、障害対応とデータ移行の担当を契約書に明記しておきます。
フェーズ3：業務設計・システム設計・開発
設計では、業務の流れを入力項目や権限、連携に落とし込み、非機能要件もあわせて決めます。確認事項を分けて進めると、抜け漏れを防げます。
- 業務フロー：ステータス、入力項目、権限、通知、承認、一覧、ダッシュボードへ変換します。
- 入力と状態：必須項目を登録時と後日補完に分け、開始・完了条件を明確にします。
- データ設計：顧客、担当者、部門、商品、原価単価、案件、契約、タスク、工数、請求の関係。
- API連携：連携元・先、更新の正、失敗時の再送、重複防止、個人情報の項目を仕様書に記録します。
- 非機能要件：利用者数、応答時間、稼働時間、バックアップ、復旧目標、認証など。
必須項目が多すぎると、現場が入力を避けるようになります。そこで、「進行中」のような曖昧な状態を減らし、登録時に必要な項目と後日補完する項目を分けます。
金額の税区分や複数通貨、期間変更、値引きのルールも決めます。追加発注や外注費の計上時期も、同じように決めておきます。後回しにすると、請求・会計連携で手戻りが起きます。
非機能要件では、同時接続数やログ保管期間、データ保管場所を確認します。あわせて、脆弱性対応や障害通知、二要素認証、SSOも押さえます。
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの1位がランサム攻撃です。また、2位はサプライチェーンや委託先を狙った攻撃、3位はAI利用をめぐるサイバーリスクです（出典：独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2026」、2026年）。
案件情報を扱うため、設計の対象には、画面機能に加えて委託先の管理やAI利用のルールも含まれます。
フェーズ4：テスト・データ移行・受入
開発会社の動作確認だけで終えず、発注側が受入基準を満たしたと判断できるテストを行います。
- 機能と連携：単体・連携・権限のテスト。
- 性能と復旧：性能テストと障害復旧テスト。
- 移行と業務：移行リハーサルと業務シナリオテスト。
営業の登録からPMの体制・進捗更新、現場の工数入力、経理の請求確定まで、実データに近い条件で一連のシナリオを実行します。
過去データをすべて移すか、進行中の案件に絞るかを決めます。重複した顧客・担当者名や古い番号、欠損金額、終了したアカウントを整理します。そのうえで、整理に使った変換ルールを残しておきます。
移行の前後で件数・金額・ステータスを照合し、代表ユーザーの承認を得てから本番に移行します。移行責任者も、見積もりと契約に明記します。
不具合や仕様の差異は、課題台帳で管理します。記録するのは、重要度、再現条件、対応期限、追加費用の有無です。また、「使いにくい」という感想は、入力時間やクリック数など検証できる形に直します。
受入の完了条件、残課題の扱い、検収日を先に決めておくと、稼働直前の認識違いを抑えられます。
フェーズ5：段階的な稼働
全社一斉稼働が適するとは限らないため、一部門、案件種別、拠点でパイロットを行い、入力率、登録・更新時間、赤字案件の検知件数、問い合わせ件数を測ります。
実利用者が日々入力できるかを確かめ、項目名や通知頻度、一覧の並びを修正します。切り替えの前には、旧システムを参照専用にすることや、最終移行日時、切り戻しの方法を決めます。さらに、窓口と運用責任者も決めておきます。
価値が伝わらないまま入力だけを求めると、Excelに戻るリスクが高まります。そのため、操作説明に加えて、ステータス更新で次の担当者が判断できることや、工数入力で着地見込が更新されることも伝えます。
フェーズ6：定着・改善の仕組み
稼働は、ゴールではなく、入力と判断の習慣を作る開始点です。責任者を一人に集中させず、運用体制と、定期的に見る指標を決めます。
- 運営体制：業務部門のオーナー、システム管理者、現場の推進メンバーを置きます。
- 週次確認：未更新案件と期限超過の確認。
- 月次確認：案件別粗利、工数入力率、受注から請求までの滞留、問い合わせ。
- 運用点検：入力項目、モバイル入力、異動日の権限変更、マスタ担当、ログ・バックアップの見直し。
定期的な確認の結果から、改善テーマを決めます。AIの要約や着地予測を加える場合は、先にデータの品質を確認します。加えて、人が誤った提案をレビューするルールを設けます。
NTT DATAのSalesforce公式ページでは、導入後サポートや活用状況の分析が紹介されています。
プロフェッショナルサポートは、コンサルティング、開発、保守、運用代行を含むものです（出典：NTT DATA「Salesforceのソリューション」、2026年確認）。
案件管理でも、利用率を見ながら業務を改善できる支援体制があるかを確認しておきます。
案件管理システム開発の費用相場とコストの内訳
費用は、ユーザー数だけでなく、管理範囲や連携数、データ量によっても変わります。権限や帳票、移行、教育、保守も、費用に影響します。
ここで示す金額は公式の定価ではなく、リサーチノートの業務システム相場と、クラウド・ローコード・パッケージに設定や連携を加えた構成から整理した目安です。
クラウドのライセンス費用
クラウド製品は、ライセンス料金を基準に考えます。導入作業や連携の費用は、別に見積もります。料金体系の例を比べると、利用人数や管理範囲に応じた費用を把握できます。
- kintone料金：3つのプランから選べます。
- kintone人数例：原則10ユーザーからで、10人は月額1万〜3万円、50人は月額5万〜15万円です。
- 別途費用：初期設定、アプリ設計、プラグイン、API連携、帳票、教育は別に見積もります。
- Backlog料金：組織単位の料金体系です。
- プラン改定：2027年1月1日に新プランへ移行予定です。
Backlogは、課題やガントチャート、カンバンなど進捗管理向けの製品です。一方で、売上・原価・請求については、別製品との役割分担や連携費用を検討します。
契約時には、公式の料金と更新条件を確認します。
kintoneの料金は、1ユーザー当たり税抜で、ライトが月額1,000円、スタンダードが1,800円、ワイドが3,000円です（出典：サイボウズ株式会社「kintone 料金」、2026年8月確認）。
Backlogには、ユーザー数無制限のプランが含まれます。プラチナは月額7万5,000円（税抜）です（出典：株式会社ヌーラボ「Backlog 料金プラン」、2026年8月確認）。
方式別の初期費用と期間の目安
SaaS標準利用からフルスクラッチまで、方式ごとの初期費用と導入期間の目安を比べます。
- SaaS標準利用：初期設定・データ整備を含み、0万〜50万円程度、1〜3か月。
- SaaS・ローコード追加：台帳・承認・帳票・簡易連携を追加し、50万〜300万円程度、1〜4か月。
- パッケージ導入・カスタマイズ：300万〜1,500万円程度、3〜9か月。
- 中規模の業務システム：1,000万〜5,000万円程度、6〜12か月。
- フルスクラッチ：5,000万円〜数億円以上、1〜3年超の場合があります。
フルスクラッチ開発では、複数拠点やERP連携、独自の採算管理、複雑な承認、厳格な非機能要件を含む場合があります。
費用と期間の幅は、業界や規模、要件、既存資産によって変わる推定値です。
予算を相場どおりに固定せず、保守・運用費は初期開発費の年10〜20％程度で仮置きします。また、SaaSの月額に基盤保守が含まれるかは、契約ごとに確認します。
初期費用以外のTCO
総保有コスト（TCO）は、導入後に発生する作業や契約費も含めて見積もります。主な費目を押さえると、初期費用からは見えない負担も比べられます。
- 導入準備：データ移行、マスタ整備、連携、追加帳票、端末。
- 運用：教育、問い合わせ対応、保守、セキュリティ点検。
- 将来費用：契約更新や追加開発を見積もりに含めます。
たとえば、10人利用のSaaSは、月額数万円でも、初期の業務整理と教育に数十万円かかることがあります。
200人規模になると、権限や組織階層、利用率の管理、アカウント連携が増えます。そのため、設定や運用の工数がライセンス差額を上回る場合もあります。
請求書や取引情報を扱う場合は、電子帳簿保存法の要件を経理・法務と確認します（出典：国税庁「電子取引関係」、2026年確認）。
保存の対象や検索の要件、訂正・削除の管理、委託先からのデータ返却も、要件に含めます。
費用を下げたい場合でも、要件整理や移行、受入テスト、教育は削らず、対象部門や連携範囲を段階的に分けて進めます。
案件管理システムの見積もりを取る際のポイント
複数社を比べるには、合計金額だけでなく、同じ前提条件を示すRFPを用意します。RFPには、案件数、利用者数、部門・拠点数、既存システムを書きます。さらに、移行件数や帳票、承認経路、権限を示します。連携や納期、納品物、保守条件も記載します。
標準機能と追加開発を分けて回答してもらうと、見積もりの前提を比較できます。
RFPにまとめる要件と前提条件
RFPは、対象範囲、業務条件、データ、連携の前提を揃えて記載します。条件を具体的に書くと、会社ごとの解釈の差が小さくなり、見積もりを同じ前提で比べられます。
- 対象範囲：商談は既存SFAに残し、受注後の案件、工数、原価、請求を新システムで扱うなど、対象業務と対象外を明記します。
- 業務条件：ステータス、入力者、更新頻度、承認者、検索・通知条件、指標を示します。
- 移行データ：顧客・案件・タスク・工数・請求の件数、添付容量、移行する過去年数。
- システム連携：会計、販売管理、勤怠、CRM、チャット、BIの項目や頻度、即時性、通知、再送要否を記載します。
- 発注者の準備：マスタ準備と受入担当。
複数社の同じ条件での比較
見積書は、工程別に分けてもらいます。工程配分の目安と比べて、要件整理や受入に不自然に少ない工数が置かれていないかを確認します。
- 要件定義：10〜15％。
- 基本・詳細設計：基本設計15〜20％、詳細設計10〜15％。
- 開発：30〜40％。
- テスト：15〜20％。
- 移行・教育：5〜10％。
この比率は、固定の契約金額を示すものではなく、工程工数を点検する目安です。見積書の内容は、要件定義から保守まで工程ごとに確認します。
デモでは、案件登録や担当変更、期限超過、工数・予算超過を実演してもらいます。さらに、承認の差し戻しや顧客検索、帳票、権限別の閲覧も見せてもらいます。
問い合わせ窓口やSLA、更新の影響、障害復旧について質問します。あわせて、データ出力や、ソースコード・設計書の納品範囲も確認します。最後に、業務要件を満たす総額と、将来の変更しやすさで比べます。
過剰カスタマイズと定着失敗の防止
カスタマイズや定着は、例外業務の必要性と利用状況を確かめて判断します。観点を分けて確認すると、費用や入力負荷を抑えられます。
- 追加開発：画面・ルールの複雑化や更新・担当交代の費用を考慮し、例外の件数と金額で判断します。
- 業務の区分：標準化する業務、差別化する業務、法令・契約上必要な業務。
- 入力負荷：項目を絞り、スマートフォンやテンプレートを用意し、会議資料や請求処理に活用します。
- 利用状況：30日、60日、90日の目標を置き、未更新案件、工数入力率、検索数、問い合わせを見ます。
- AI活用：AI搭載自体より、正しい情報が蓄積され、判断に使われていることを優先します。
案件管理システム開発でよくある質問（FAQ）
導入判断では、会社の規模だけでなく、案件の複雑さ、採算管理、既存システム連携、現場の入力環境を合わせて検討します。
案件管理システムは何人規模から開発すべきですか？
人数より、情報の状態で判断します。情報が複数の表や担当者に分かれ、進捗・工数・粗利の確認に時間がかかるなら、検討する価値があります。
少人数であれば、SaaSやローコードで台帳と進捗から始められます。一方、複数部門や拠点で原価や請求まで統合する場合は、パッケージや個別開発を比べます。
SaaSとスクラッチ開発はどちらがよいですか？
短期間で標準化し、初期費用と保守の負担を抑えたい場合は、SaaSが適しています。
独自の採算計算や複雑な承認、基幹との深い連携が競争力に直結する場合は、スクラッチ開発が候補になります。その際は、将来の保守費用と担当者の継続性も含めて判断します。
迷う場合は、標準機能のPoCやローコードで最小業務を試し、追加開発の必要性を確かめます。
現場が入力してくれない問題はどう防げますか？
入力する情報を最小限にし、会議資料や次工程への引き継ぎ、請求や評価に役立つ状態を作ります。
代表ユーザーが参加するPoCで、実案件を登録し、入力時間を測ります。加えて、項目や通知、スマートフォン操作を改善します。稼働後は、入力率や未更新案件を見ながら、ルールの変更を繰り返します。
案件情報のセキュリティで何を確認すべきですか？
ユーザーや案件ごとの権限と、二要素認証やSSOを確認します。さらに、操作ログとバックアップ、復旧の体制を見ます。脆弱性対応や保管場所、委託先・再委託先、データ返却も確認します。
顧客情報や仕様書をAI機能に渡す場合は、学習利用の扱いと保存期間を確認します。さらに、アクセス権やログ、誤回答のレビュー方法も確認します。取引データを保存するなら、電子帳簿保存法の要件を経理・法務と整理します。
案件管理システム開発のまとめ
開発は6フェーズで、要件整理・企画から始まり、選定、設計開発へ進みます。テストと稼働を経て、定着・改善で締めくくります。案件の粒度や状態、担当、期限は、要件整理の段階で先に決めます。工数、原価、請求については、どこまでを誰が受け持つかも決めておきます。
10〜20件の実案件でPoCを行うと、機能比較では見えにくい入力負荷と業務適合性を確認できます。
費用よりも利益と運用を基準にした判断
費用の内訳と、規模別の推定レンジを分けて確認します。
- 費用の内訳：ライセンス、設定・開発、連携、移行、教育、保守。
- SaaS・ローコード：標準利用は0万〜50万円程度、追加開発は50万〜300万円程度。
- 中規模システム：1,000万〜5,000万円程度の推定レンジ。
案件数や利用者、連携、権限、帳票の内容で、金額は変動します。そのため、単一の金額を予算に置かず、RFPと実案件のPoCを使い、自社条件での見積もりに絞り込みます。
最初の一歩は現状の洗い出しと小さな検証
まず、営業、PM、現場、経理の代表者で、案件が止まる場所や分散した情報、時間のかかる判断を書き出します。そのうえで、案件台帳や進捗、工数など最小範囲の候補を比べます。
入力率や赤字案件の検知など、一つのKPIを測ります。そして、現場に定着した仕組みを段階的に広げます。これが、利益の改善につなげる進め方です。
▼全体ガイドの記事
・案件管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。