案件別採算管理システムの発注・外注は、業務要件と管理範囲を固めて方式と契約を選び、小規模な実証を経てから導入へ進む流れで行います。
この流れを守ると、採算改善につながります。その進め方を、発注の段階から委託先の選び方まで順に説明します。
▼全体ガイドの記事
・案件別採算管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
案件別採算管理システムを発注・外注する前に知るべき全体像
案件・プロジェクトを管理単位にして、受注前の見込から受注後の実績、完了時の利益まで追跡します。この仕組みの目的は、売上と直接原価・間接費を案件コードで集計し、途中で採算を予測して対策できる状態を作ることです。
一覧や進捗画面を作ること自体は、目的そのものではありません。管理対象と発注方式を先に整理しておくと、不要なカスタマイズや見積比較の迷いを減らせます。
外注するシステムで管理すべき範囲
管理対象は、案件コードで結びつけて集約する情報です。案件粗利を確かめるには、次の情報を扱える設計が求められます。
- 案件と契約：案件・顧客・契約・担当者のマスター
- 売上と予算：見積・受注・売上・請求・入金、実行予算、予算変更履歴
- 原価と工数：作業日報・勤怠・工数、外注・購買・経費
- 利益の確認：案件売上から直接原価と配賦間接費を差し引いた利益
社員の工数には標準原価または社員単価を掛け、内製労務費として集計します。また、外注費、クラウド・ライセンス費、交通費も原価に含めます。
SI企業では、受注前の見込工数や原価、受注後の実績工数、追加要件が利益を左右します。外注発注や請求時期も、利益を動かす要素です。そのため、採算管理は完成後の実績集計より前の段階から必要になります。
特に、受注見込みの段階で予定売上と予定原価を登録し、進捗に応じて実績値と残作業の予測に置き換えていく流れを、RFPの中心に置きます。
クラウド・パッケージ・ローコード・スクラッチの選び方
方式は、標準業務にどこまで合うかと、独自要件の多さで選びます。候補ごとに、既製品で賄える範囲と、作り込みが必要な範囲が違います。
- 専用クラウドERP・パッケージ：ERP導入支援を使い、標準業務を早く運用する
- ローコード：kintoneなどで案件・工数の機能を小さく試す
- スクラッチ・API連携：独自配賦、複数会社、内部取引などが競争力に直結する場合に検討する
- 既存システムへの追加：会計・販売システムに案件・工数モジュールを加える
販売・購買・勤怠・経費と案件別の収支をまとめて扱う企業では、標準業務への適合性を確かめます。特殊な契約や承認が競争力に直結する場合は、独自要件として扱います。
全社の基幹システムを一度に刷新せず、1部門または10〜30案件程度で実証する進め方もあります。その際は、見積から月次締めまでを通して、入力時間、工数入力率、赤字案件の発見時期を測ります。さらに、月次締めの日数や二重入力の件数も見て、効果が確認できた機能から対象範囲を広げます。
方式は、初期価格だけでなく、案件コードを最後まで追跡できるか、運用変更を受け入れられるかで判断します。
案件別採算管理システムの発注・外注の進め方
発注は、次の4つの段階を順に進めます。その前提として、目的と受入条件をつなぎ、各段階の判断基準を先に決めておきます。
- 現状を把握し、要件を整理する
- 候補先へRFPを提示し、提案と見積を比較する
- 契約後に要件定義、設計、構築、テストを行う
- 教育して本稼働し、運用を改善する
目的と受入条件がつながらないと、開発中に機能が増え、現場が入力しない状態になりやすいです。そのため、発注者側には、業務責任者とデータの決裁者を置きます。
現状把握と発注目的の整理
まず、管理場所と業務ルールを洗い出します。次の項目を見ると、現状の分断や判断待ちが分かります。
- 管理場所：案件コード、見積、受注、売上、工数、外注、経費、請求、会計
- 案件の扱い：受注前の調査工数、失注費用、部門間の内部販売
- 会計処理：未完了案件の仕掛と進行基準
現状把握の段階で、Excelの表記の揺れや、調査工数の付け先も確かめておきます。
導入目的を「入力を一か所にまとめる」で終わらせず、測れる形にしておきます。たとえば、赤字案件の発見を月末から月中へ早める目標を置けます。
さらに、月次締めを何日短縮するか、工数と勤怠の二重入力を減らせるかも指標になります。予算差異の説明時間を減らす目標も置けます。
目的が定まっていれば、AI予測や高度なダッシュボードを初期から入れるかどうかを判断できます。目的によっては、まず案件・工数・外注・予実に絞る案も検討できます。必要な機能は、目的に照らして決めます。
要件整理と小さな実証
業務フローと、データを更新する担当を決めておきます。見積から完了までの場面ごとに、扱う情報を分けて整理します。
- 引き合い・見積：予定売上、予定工数、予定外注費
- 受注・実行：実績工数、発注額、経費
- 月次：残工数、追加要件、着地見込
- 権限：経営、営業、外注先が閲覧する情報
引き合いから完了までの各段階について、使う画面と更新する担当者を決めておきます。閲覧の範囲は立場ごとに決め、たとえば、経営は全社、営業は担当案件、外注先は必要な発注情報だけを見られるように権限を定めます。
要件が固まりきらない場合は、本番開発を請負にせず、準委任で業務診断や試作を依頼する方法があります。そのうえで、1部門の10〜30案件で、見積入力から月次締めまでを試し、現場の入力負担やデータの欠落箇所を確かめます。
画面と計算ルールを確認したうえで、本開発の範囲を確定します。また、経理の集計結果と案件画面の粗利が一致するかも検証します。操作できるかだけでなく、数値が合っているかの照合まで必要です。
設計・開発・テスト・本稼働の管理
実装後に採算を正しく追うには、入力条件と原価計算の設計を固めておく必要があります。
- 案件管理：案件コードの採番と見積から受注への移行条件
- 予算・工数：予算変更の承認と工数の入力単位
- 原価管理：外注発注と請求の紐付け、間接費の配賦基準
実装前には、入力項目と計算式のサンプルを作っておきます。たとえば、売上1,000万円、予定工数500時間、外注費200万円の案件で、実績工数や追加外注後の粗利と着地見込を確かめます。
テストでは、機能だけでなく業務シナリオと会計の数字を照合します。見積から受注、外注発注、工数登録までの流れを通して試します。さらに、経費申請、請求、月次締めを経て案件完了まで進め、予算変更の履歴と承認者も確かめます。
本稼働の前に、操作マニュアルと入力期限を決め、問い合わせ窓口と障害時の連絡先も定めます。導入後は、月次で予算差異と入力率を確認します。
追加改修の受付は、プロダクトオーナーに一本化します。受付先が一つにまとまるため、要望の増加を抑えられます。
RFP・要件整理と契約形態の決め方
RFPは、製品名や画面一覧に加えて、自社の課題と依頼内容を候補先へ伝える文書です。候補先が同じ条件で理解できるよう、対象部門と案件数、既存システムなどをまとめます。
特に、要件が曖昧なまま価格だけを比べると、提案範囲がそろわず、安い見積が後から高くなる場合があります。
RFPには、課題、対象部門と案件数、既存システムを記します。ほかに、業務ルールや非機能要件、導入日程、予算の考え方も書きます。あわせて、提案書と見積書に求める項目も明記します。
RFPに入れるべき業務・データ・非機能要件
業務・データ・安全性の条件がそろっていると、候補先は運用まで提案できます。RFPには、次の内容を記載します。
- 業務要件：登録単位、採番、案件状態、見積・予算差分
- 運用要件：追加承認、工数締め、外注費・経費の計上
- データ要件：会計などとの連携、移行年数、所有権
- 非機能要件：認証、権限、暗号化、バックアップ、ログ
仕掛と売上原価の扱いも、RFPに記載します。粗利率の警告条件や、誰が入力・承認し、いつ確定するかも書いておくと、候補先が画面だけでなく運用面も示せます。
データ連携では、販売や勤怠、給与などの業務データも対象になります。CRMや請求書、購買も含まれます。また、APIか日次CSVか、エラー時に再送できるかも決めておきます。
移行するデータのエクスポート形式も定めます。認証では多要素認証を求め、通信と保存データの暗号化も確かめます。
さらに、復旧目標や、操作・訂正・削除ログの記録、再委託先管理の条件も定めます。最後に、データの返却と削除の手順も記載します。
請負契約と準委任契約の使い分け
開発の段階ごとに、成果物や作業内容に応じて契約形態を使い分けます。
- 請負契約：成果物を完成させ、検査・納品する開発に合う
- 準委任契約：要件定義、診断、試作、アジャイル改善に使いやすい
請負では、納期と不具合対応を具体化します。変更手続きと再委託の可否も、具体的に決めます。要件が未確定のまま完成責任を置くと、追加費用や納期延長の協議が増えます。
IPAは、要件定義や基本設計などのフェーズと契約類型の関係を資料で整理しています（出典: IPA「システム開発の健全化に向けて」、2025年）。
契約名とは別に、作業範囲や体制、時間を個別に記します。責任の分け方や成果物、品質基準も書きます。
検収・変更・知的財産・データ返却の契約条件
契約時に整理すべき条件は、検収、変更管理、権利とデータに分けて考えます。
- 検収：納品物、期間、テスト方法、不合格条件、不具合の扱い
- 変更管理：影響範囲、工数、費用、納期、承認者
- 権利とデータ：成果物の利用権、返却形式、期限、削除証明
変更要求票を使い、口頭の依頼をそのまま開発に流さない運用にします。帳票の追加や配賦基準の変更も、データモデルやテスト範囲に影響する可能性があります。
成果物は、ソースコードや設定情報、設計書を確認の対象とします。API仕様とテスト結果も含めます。移行データや運用マニュアルも、対象に入れます。
クラウド利用では、契約終了後のバックアップ保持期間と、サービス停止時の復旧方法も定めます。再委託先が顧客情報や外注単価を見る場合は、再委託の承認とアクセス範囲に加え、秘密保持や事故時の報告責任も確かめます。
案件別採算管理システムの費用相場とコスト内訳
案件別採算管理システムだけを対象にした公的な価格統計は、限られています。そのため、ここでは、NotebookLMリサーチノートに整理したERP・基幹相場や2026年時点の公開料金、類似システムの導入範囲をもとに、金額の幅を示します。
金額は、そのまま予算に組まず、比較の目安として扱います。比べる前に、案件数や利用者数、連携の条件をそろえ、移行や教育、保守の前提も確かめます。
方式別の初期費用レンジ
ローコードの想定は、一部門で案件台帳から予実までを構築する場合です。設計・設定・開発を含めると、100万〜600万円程度が推定の目安です。
- ローコード：一部門の基本機能で100万〜600万円程度
- 標準導入：専用クラウドERPやパッケージで300万〜1,500万円程度
- 連携込み：会計・勤怠・CRM・請求を含め800万〜2,500万円程度
- スクラッチ：独自要件や大規模連携で1,500万〜5,000万円超
スクラッチのレンジは、独自の原価計算や複数会社、内部取引を含む場合の目安です。特殊な契約や大規模連携も含まれます。
各方式の金額は、公開統計ではなく、類似するERP・業務システムの導入範囲からの推定です（出典：NotebookLMリサーチノート「案件別採算管理システム」、2026年）。
同じローコードでも、10〜30案件の部門実証と全社連携では費用が変わります。そのため、見積書にはユーザー数や案件数、連携本数を明記してもらいます。移行・カスタマイズの範囲と検証回数も、あわせて書いてもらいます。
公開ライセンス料金と導入費の区別
公開料金のある製品は、ライセンスの比較に使えます。kintoneを例にとると、2026年8月時点の料金は、プランごとに月額が異なります。
- ライト：月額1,000円
- スタンダード：月額1,800円
- ワイド：月額3,000円
初期費用は無料で、ライトとスタンダードの最低ユーザー数は10ユーザーです（出典: サイボウズ公式「kintone 料金」、2026年確認）。
アプリ設計や権限、帳票は別途かかります。会計連携や保守も別に発生するため、導入費の見積もりには、月額ライセンス料に加えて、これらの費用を足す必要があります。
また、Dynamics 365は、年払いで1ユーザー月額20,239円相当、税別です（出典：日本マイクロソフト公式「Dynamics 365 Project Operations の価格」、2026年確認）。含まれる機能は、案件管理やスケジュール、見積・予算などです。時間・経費や外注、請求も含みます。
日本の会計・請求・税務に合わせる設定や、導入支援の費用は別に確認します。公開料金は、機能の範囲を理解する材料として使います。自社の総保有コストを示す金額とは、そのまま読めません。
要件定義・連携・移行・保守・補助金の内訳
見積では、初期作業と継続費を分けて示してもらい、作業項目ごとに範囲を確かめます。
- 設計・構築：要件定義、業務設計、画面、計算ロジック
- 導入：システム連携、データ移行、テスト、教育、マニュアル
- 継続費：クラウド利用料、保守、追加改修
類似する基幹システムでは、要件定義を全体の10％程度、設計を10〜20％程度とみる考え方があります。実装は40〜60％程度、テストは10〜20％程度ですが、これらは固定料金ではありません。
2026年のデジタル化・AI導入補助金の通常枠は、補助率が原則2分の1以内です。プロセス数が1つ以上なら5万円以上150万円未満、4つ以上なら150万円以上450万円以下です（出典: 独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」、2026年）。
対象経費には、ソフトウェア購入費やクラウド利用料（最大2年分）が含まれます。導入コンサルティングや設定、研修、保守サポートなども対象です。登録済みのITツールとIT導入支援事業者が前提になります。
案件別採算の機能が、そのまま対象になるとは限りません。予算に反映する前に、公募要領を確認します。
案件別採算管理システムの委託先選定と見積比較のポイント
委託先は、知名度や営業担当者の印象だけでなく、案件別採算の業務理解と運用支援力で選びます。たとえば、株式会社オロの公式機能説明では、プロジェクトを単位に、受注前の実行予算や進行中の売上・コストを扱うとしています。仕入・勤怠・経費、着地見込も対象に含まれます。
同社の導入事例では、部門別採算や内部販売、勤怠と工数の連携が、選定理由として紹介されています。ただし、機能名よりも、自社の業務シナリオで確かめます（出典: 株式会社オロ「プロジェクト収支管理システム ZAC」「ハイテックシステム導入事例」、2026年確認）。
見積の前提条件の統一と比較
各社に示す条件と見積の範囲はそろえておきます。比較では、次の項目を確かめます。
- 依頼条件：部門、利用者・案件数、連携、移行範囲、期限、画面、テスト件数
- 見積内訳：要件定義、設計、開発、連携、移行、テスト、教育、保守、ライセンス
- 比較要素：提案範囲、前提・除外、納品物、体制、経験、期間、保守時間、SLA、改修単価、データ返却
移行や教育が含まれていない見積や、標準機能を前提にして後から追加費用が出る見積もあります。そのため、合計額を比べても、差の中身は見えにくいままです。
デモでは、サンプル案件を使い、見積から着地見込までを操作してもらいます。途中では、実行予算や工数、外注の扱いを確かめます。
さらに、追加要件と請求の流れも見てもらいます。操作を通すと、機能一覧では分からない入力の手戻りや承認の滞留が見えてきます。
案件採算とシステムSIの経験
候補先には、案件単位で原価が変わる企業への導入経験を尋ねます。システム開発や受託開発、コンサルティングなどの実績も見ます。
- 採算管理：受注前の見込原価、社員工数の労務費化、案件変更の履歴
- 連携・計算：外注費と購買、間接費配賦、会計との照合
- 運用経験：複数部門や内部取引、月次締めの運用
自社の業務を再現できるかは、導入社数や資格よりも、実際の方法で確かめます。
また、発注者と委託先の責任者が、定例会議で予算差異と課題を確認する体制かも見ます。担当者が一人に集中すると、異動や退職のあとに、仕様や運用が分からなくなります。
納品物には、設計書やデータ項目一覧、連携仕様を含めます。テスト結果と操作マニュアルも、あわせて受け取ります。これは、発注者側で管理者を育てられるようにするためです。
再委託がある場合は、実装や保守、データアクセスを担う会社を把握します。
失敗しやすい見積と発注リスク
要件定義が十分でないまま最安値の見積を採用すると、追加費用や納期変更が起こり得ます。そこで、漏れやすい範囲と運用上の注意を確かめます。
- 追加範囲：会計連携、権限、移行、テスト、教育
- 入力設計：現場負担を抑え、入力漏れを防ぐ
- 安全管理：権限、端末、ログ、バックアップ、委託先運用
見積の範囲が狭いと、追加作業によって最終的な総額と納期が変わります。また、管理項目だけを増やして、工数入力を簡単にする設計がないと、入力漏れが続き、採算データの信頼性が下がります。
クラウドでは、ベンダーの認証を理由に安全と判断せず、自社の権限設定と端末管理を確かめます。ログ監視やバックアップ、委託先運用も、あわせて確認します。
電子取引データや請求書・領収書を保存する場合は、電子帳簿保存法の保存要件を確かめ、検索性や訂正・削除の防止、社内規程も見ておきます。
インボイス制度に対応する項目があっても、証憑の保存責任や承認ルールは、自動では満たされません。
よくある質問（FAQ）
発注では、費用に加えて、どのデータをいつ確定し、誰が運用するかも検討します。外注先を探す段階で迷いやすい点を、ここで回答します。
案件別採算管理システムは内製と外注のどちらがよいですか？
業務ルールを自社で整理でき、開発・保守人材を継続して確保できる場合は、内製も選択肢になります。
連携から運用教育まで短期間で整える場合は、業務整理から支援してくれる外注先が進めやすいです。
内製か外注かの二択にせず、要件定義を共同で進める方法もあります。標準機能は外部に任せ、社内でデータと運用を担う分け方も有効です。
小規模な会社はどのくらいの予算で発注できますか？
一部門で案件台帳から予実までを試すローコード構築は、設計・開発込みで100万〜600万円程度の推定です。
標準導入のクラウドERPや専用パッケージは300万〜1,500万円程度、会計・勤怠・CRM連携込みは800万〜2,500万円程度が目安です。
公開統計ではなく類似システムからの推定のため、対象ユーザー・案件数、移行、保守の条件をそろえた相見積もりで確かめます。
請負と準委任はどのように組み合わせればよいですか？
開発の段階や作業の性質に応じて、請負と準委任を使い分けます。
- 準委任：作業内容が変わりやすい業務診断、要件定義、試作
- 請負：要件・成果物・検収条件が固まった画面や機能の開発
責任範囲は、成果物や品質基準、作業時間などを、契約書と個別仕様書に記して決めます。
変更管理や検収、再委託の扱いに加え、知的財産やデータ返却も書き込みます。そのうえで、発注者と委託先で認識を合わせます。
案件別採算管理システムに補助金は使えますか？
通常枠では、申請方法と対象経費を押さえておく必要があります。
- 申請：登録済みITツールをIT導入支援事業者を通じて申請する
- 対象経費：ソフトウェア、クラウド利用料、導入関連費など
通常枠の補助額とプロセス数には条件があります。独自のスクラッチ開発は、全費用が自動的に対象になるわけではありません。そのため、対象業務プロセスと申請時期、実施期間は、公募要領の最新版で確かめます。
まとめ
案件別採算管理システムの発注では、案件コードを中心に、売上や予定・実績の原価を整理します。工数や外注費、経費、着地見込も、その案件コードに結びつけます。そのうえで、専用クラウドERPやパッケージ、ローコード、スクラッチ、既存システムへの追加のなかから、業務と規模に合うものを選びます。
全機能を一度に作り込まず、1部門または10〜30案件程度で、入力負担と採算データの精度を見極めます。さらに、効果が確認できてから対象を広げれば、発注の失敗を抑えられます。
発注前のRFPと比較条件
RFPには、業務フローや案件コード、原価・粗利の計算を記載します。権限や連携、移行に加え、非機能要件と支援範囲も書き込みます。
見積は、要件定義や設計、開発を項目ごとに分けます。連携や移行、テストに加えて、教育やライセンス、保守の費用も分けて示します。さらに、前提と除外事項をそろえます。
契約では、要件が変わる段階と成果物を確定する段階を分け、請負・準委任を組み合わせます。
最安値ではなく採算改善につながる体制
発注額だけでなく、費用の幅と導入後に測る効果の両方から、体制を判断します。
- ローコード・標準導入：100万〜600万円程度、300万〜1,500万円程度
- 連携・独自要件：連携込み800万〜2,500万円程度、スクラッチ1,500万〜5,000万円超
- 改善効果：赤字発見時期、締め日数、工数入力率、二重入力件数、差異説明時間で評価する
- 定着条件：RFP・契約・運用ルールを一体設計し、自社と委託先の責任を明確にする
▼全体ガイドの記事
・案件別採算管理システム開発の完全ガイド
▼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を創業。